EP2776923A1 - Procédé de séquencement sur un processeur multicoeur - Google Patents

Procédé de séquencement sur un processeur multicoeur

Info

Publication number
EP2776923A1
EP2776923A1 EP12781350.9A EP12781350A EP2776923A1 EP 2776923 A1 EP2776923 A1 EP 2776923A1 EP 12781350 A EP12781350 A EP 12781350A EP 2776923 A1 EP2776923 A1 EP 2776923A1
Authority
EP
European Patent Office
Prior art keywords
task
level
certification
security
sequencing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12781350.9A
Other languages
German (de)
English (en)
Inventor
Christian Valpard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Safran Electronics and Defense SAS
Original Assignee
Sagem Defense Securite SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sagem Defense Securite SA filed Critical Sagem Defense Securite SA
Publication of EP2776923A1 publication Critical patent/EP2776923A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources

Definitions

  • the present invention relates to the field of real-time executives known by the acronym ETR.
  • ETRs are used in the industry where one must be able to ensure a high level of security to a software process.
  • these real-time executives are used for the management of nuclear power plants, for the management and control of the various components of an aircraft or for the management and control of sensitive vessels such as attack submarines and others.
  • partitioning In the field of real-time executives, a software concept called partitioning is used. This partitioning aims at a static allocation of resources among which memory and time. The time is typically divided into successive time intervals of generally the same length. This partitioning is intended to allow a set of tasks to run on a processor, each task having its own resources called partitions, typically a memory space and a set of time slots (time slot in English) reserved. It is then ensured that a problem during the execution of a task in one partition can not interfere with the smooth running of the other tasks in the other partitions.
  • This concept is implemented in the form, inter alia, of a periodic sequencing process that comes, at regular intervals of time, interrupting the current task and managing a failover on the execution of a new task by ensuring that it will dispose of its resources, it speaks of a context switch ⁇ context switch in English).
  • a certification level is defined for the development process used to perform a given task to be performed in such a system. This level of certification therefore defines the care and development techniques used, so it reflects a level of intrinsic quality of the software.
  • the standard defining the partitioning concept is the "ARINC 653" standard
  • the certification levels are, in turn, defined by the standards ED-12B and DO-178B.
  • DAL Design Assurance Level in English
  • the invention aims to solve the above problems by defining, in addition to the intrinsic certification level for each task, a security level relative to the criticality of the execution of the task instance in its context and by a sequencing process distributed over the different cores which makes it possible to exchange, at each time interval, the information relating to the level of certification and the security level of each of the tasks that are about to be launched. Decision making is then performed on each launching heart of the scheduled task based on the relative information received from the other cores.
  • a method of sequencing a set of tasks on a processor having a plurality of execution cores the processor resources being divided into a plurality of partitions, these partitions sharing time in the form of a succession of time slots synchronously on each core of the processor, the method being executed by a set of sequencing modules implemented on the cores of the processor, a control instance being implemented within said sequencing modules, which comprises a preliminary step of defining for each task instance to be executed on the system a security level relating to the criticality of the execution of the particular instance of the task, each task being otherwise provided with a level of certification related to the development processes implemented during its design; and which comprises for each partition a step of exchanging messages between the different sequencing modules of each core to inform the control body of the certification and security levels of the tasks that are to be executed by the different cores within of the current partition and a step of determining a launch authorization for each of the tasks that are ready to be launched on each core according to the certification and security levels of the other tasks that are about to be launched within the same partition.
  • the method furthermore comprises, for each partition, a step of updating the security level of the tasks that are about to be launched according to the execution context of said tasks.
  • control instance is centralized within a particular sequencing module on one of the cores and the message exchange step consists of a sending step by each module sequencing its information to this sequencing module.
  • control instance is distributed within the sequencing modules on each core and the message exchange step consists of a step of sending by each sequencing module its information to all sequencing modules.
  • the step of determining a launch authorization for each of the tasks, the security levels being 4, comprises the following rules:
  • a task with a security level 1, that is the lowest level, is executed if the following conditions are met:
  • any security level 2 task on another core has a level of certification that is less than or equal to its own level of certification
  • any security level 2 task on another core has a level of certification that is less than or equal to its own level of certification
  • a task with security level 3 executes if the following conditions are met:
  • any security level 3 task on another core has a certification level less than or equal to its own certification level, in case of equality, its identification number is greater than or equal to the others;
  • any security level 4 task on another core has a certification level lower than or equal to its own level of certification, in case of equality, his identification number is strictly superior to the others.
  • Fig. 1 illustrates a task sequencing in a classic real-time executive
  • Fig. 2 illustrates a typical multi-core processor architecture
  • Fig. 3 illustrates the operation of the system, the scope of the invention
  • Figs. 4a and 4b respectively illustrate two embodiments of the control module of the sequencing modules of the processor cores
  • Fig. 5 illustrates the sequencing method according to an exemplary embodiment of the invention.
  • Fig. Figure 1 illustrates a sequencing of tasks in a typical real-time executive running on a single-core processor.
  • Tasks T1, T2, T3 and T4 run alternately on the heart C1.
  • the time is divided into successive time intervals II to 111.
  • Each of these intervals represents the temporal component of a partition in the sense of the partitioning defined above.
  • Temporal partitioning is usually periodic in time slots of the same length, but it is not mandatory.
  • Each task has its own level of certification depending on the development methods implemented to program it.
  • Each partition therefore runs with the certification level associated with the task running in that partition.
  • the partitioning system ensures a temporal seal between the different partitions.
  • a partition running a task of lower certification level can not come, in case of malfunction of the task, disrupt the execution in another partition of another task for example higher certification level. This is important because at each certification level there is a risk of malfunction. It is therefore important that this risk can not be increased by the operation of other tasks in order to be able to control the overall risk associated with the use of the system. This is a major safety factor.
  • Fig. 2 illustrates a typical multicore processor architecture.
  • These Computer units are called cores and have approximately the same capabilities as a traditional single-core processor. Their number varies between two and eight hearts in processors proposed today, but no doubt that their number is expected to increase in the coming years.
  • these cores each have at least one local memory, 2.21 to 2.24, which serves as a dedicated local working memory.
  • a memory common to all 2.5 cores is typically present.
  • the component also has a set of modules 2.3, 2.4, dedicated to various operations such as the input-output of the processor or specific calculation units such as graphics coprocessors. These different modules communicate via a bus 2.6. In particular, access to the shared memory 2.5 is managed by a cache mechanism within the local memories 2.21 to 2.24.
  • This level of security is not an intrinsic property of a program, but a requirement related to the execution of a particular instance of that program in a particular context. It is therefore linked to the particular execution, on a particular heart, of the task that materializes this execution instance of the software.
  • This level of security is related to the critical nature of the execution of the particular instance of the task. For the same task, this criticality can evolve over time. For example, a control task of a flap is not very critical when taxiing an airplane, but can become so during the landing phase.
  • the solution developed concerns the notion of partitioning. In particular, the time is always divided into successive time intervals. This division is identical on all the cores of the processor. These hearts are synchronized temporally. Typically these time intervals are identical, but this condition is not essential for the proper functioning of the system.
  • Fig. 3 illustrates the operation of the system, the scope of the invention. It shows the temporal succession of the partitions on the abscissa, PI to Pl i. It is assumed that the processor has 4 cores C1 to C4. For each partition and each heart, it has been indicated the task occurrence that must execute according to the planned scheduling.
  • Each task, or more precisely task instances for each partition and each core, has a certification level and a security level.
  • the level of certification being relative to the development processes used to create the task is therefore indirectly related to its level of reliability, that is to say to the probability of a malfunction of said task.
  • the security level is related to the criticality of such a malfunction for this task instance in its execution context. It is therefore linked to the seriousness of the foreseeable consequences of such a malfunction.
  • the system relies on the certification levels defined in the DO-178B standard for the field of avionics. These levels are five in number labeled from A to E.
  • the level E corresponds to software developed without particular constraints. Any software can therefore, by default, claim certification level E.
  • Certification levels D to A impose increasing quality constraints.
  • the security levels are four in number, labeled from 1 to 4.
  • the security level 1 is the lowest level. It implies that a malfunction of the task does not have a critical impact. Depending on the impacts of a possible malfunction, the level of security increases to level 4, the highest. Typically, in avionics, this level is assigned to tasks whose malfunction can create an accident putting the lives of staff and / or passengers at stake. Assigning the level of security to a task can be done by any means. Typically, in the exemplary embodiment, this level of security is assigned by an expert to each task according to its context. We recall here that this level can vary in time, for the same task, for example depending on the flight phases. These certification levels and safety are specific to the exemplary embodiment. In other embodiments, they could be in different numbers and have other names.
  • the sequencing method according to the invention is composed of a sequencing module which executes on each of the cores of the processor.
  • Diagrammatically shown in Figs. 4a and 4b these sequencing modules 2.71 to 2.74 in a multicore processor architecture similar to that of FIG. 2.
  • These modules 2.71 to 2.74 can communicate in the form of information exchanges, typically messages.
  • a control instance will make the decision to allow or not the launch of the scheduled task within the partition on each of the cores 2.11 to 2.14. Two variants of implementation can be realized from this control instance.
  • a sequencing module on one of the cores is elected control instance.
  • this module is the 2.8 module on the 2.11 heart.
  • This module 2.8 then takes the name of the control module and communicates with the other modules 2.72 to 2.74 to, firstly, obtain the information necessary for its decision-making and, secondly, inform the other modules 2.72 to 2.74 decisions taken.
  • each sequencing module 2.71 to 2.74 on each core 2.11 to 2.14 implements the control for its own tasks in a control module 2.81 to 2.84 which is specific to it. All modules 2.81 to 2.84 then have an equivalent operation and the control instance is distributed among the different modules.
  • each module 2.81 to 2.84 communicates with the others to obtain the information necessary for its decision-making. He then makes his decision concerning his own tasks and it is not necessary to warn others, contrary to the first embodiment.
  • Fig. 5 illustrates the sequencing method according to the invention to ensure a controlled level of security in a system running on a multicore processor.
  • first step 4.1 each task instance to be executed within a partition on one of the cores of the system is assigned a security level as defined. This step is advantageously a preliminary step to the operation of the system.
  • the system repeats the following steps for each partition.
  • a step 4.2 optionally, the security level of the tasks that are to be launched in the current partition is updated. Indeed, since the security level is related to the execution context of the task instance, it is advantageous to allow an update of the latter as a function of a possible evolution of the context for each partition.
  • This updating step constitutes an optional improvement of the method of the invention.
  • a step 4.3 occurs an exchange of messages between the different sequencing modules of each heart.
  • Each heart informs the control body of the certification and security levels of the task that is about to be sequenced on that core within the current partition.
  • the message exchange is, for example, an exchange of each sequencing module to the module hosting the control instance.
  • each sequencing module informs each of the other modules on each core.
  • the control instance decides, during a step 4.4, a launch authorization for each of the tasks that are about to be launched on each core. This decision is made based on the level of certification and security of other tasks that are about to be started within the same partition.
  • the decisions are made according to the following rules.
  • Any security level 2 task on another core has a certification level lower than or equal to its own certification level.
  • a security level 1 task may coexist with a security level 2 task, each on a processor core, provided that its level of certification is at least equal to that of the security level 2 task. to not allow the security level 1 task to degrade the overall certification level of the partition.
  • a task with security level 2 runs if the following conditions are met:
  • Any security level 2 task on another core has a certification level lower than or equal to its own certification level.
  • Level 2 partitions with the highest level of certification run, and if they exist, partitions with security level 1, but with a certification level greater than or equal to.
  • a task with a security level 3 executes if the following conditions are met:
  • This rule involves a new job parameter, the identification number. This number uniquely identifies a task. If two tasks, on two different cores, have the same identification number, this indicates that it is the same task implemented in the form of parallel processes running on at least two cores. This rule implies that a security level 3 task runs alone on the processor, possibly distributed across multiple cores. No other task is allowed to work within the same partition.
  • a task with security level 4 executes if the following conditions are met:
  • Any security level 4 task on another core has a certification level lower than or equal to its own certification level. In case of a tie, his identification number is strictly superior to the others. This rule only allows the operation of a Level 4 task exclusively on a single core. It is no longer permissible here, as was the case in security level 3, to have a security level task 4 operating in a distributed manner on several cores. A security level 4 job always runs alone within its partition.
  • the last two rules use the task identifier to perform a method of electing a single task from a set of tasks.
  • any other method of election can be used, by message exchange, the use of another criterion for independently electing a single task in a distributed manner.
  • These distributed election algorithms are well known to those skilled in the art.
  • the use of the task identifier is therefore not necessary for carrying out the invention.
  • rules described are only one embodiment of the invention. Other rules can be defined to implement a security policy that may be different depending on the number of security levels defined and the context of use of the system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)
  • Multi Processors (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne le domaine des exécutifs temps réel et leur adaptation pour une exécution sécurisée sur un processeur multicœur. On définit, en outre du niveau de certification intrinsèque à chaque tâche, un niveau de sécurité relatif à la criticité de l'exécution de l'instance de la tâche dans son contexte et par un procédé de séquencement réparti sur les différents cœurs qui permet d'échanger, lors de chaque intervalle de temps, les informations relatives au niveau de certification et au niveau de sécurité de chacune des tâches s'apprêtant à être lancées. Une prise de décision est alors réalisée sur chaque cœur de lancement de la tâche prévue en fonction des informations relatives reçues des autres cœurs.

Description

Procédé de séquencement sur un processeur multicoeur.
La présente invention concerne le domaine des exécutifs temps réel connus par l'acronyme ETR. Ces ETR sont utilisés dans l'industrie où l'on doit pouvoir assurer un niveau de sécurité élevé à un processus logiciel. On retrouve typiquement ces exécutifs temps réel pour la gestion des centrales nucléaires, pour la gestion et le contrôle des différents composants d'un avion ou encore pour la gestion et le contrôle de navires sensibles comme les sous-marins d'attaque et autres.
Dans le domaine des exécutifs temps réel, on utilise un concept logiciel appelé partitionnement. Ce partitionnement vise à une allocation statique des ressources parmi lesquelles la mémoire et le temps. Le temps est typiquement divisé en intervalles de temps successifs généralement de même longueur. Ce partitionnement vise à permettre à un ensemble de tâches de s'exécuter sur un processeur, chaque tâche disposant de ses propres ressources appelées partitions, typiquement un espace mémoire et un ensemble d'intervalles de temps (time slot en anglais) réservés. On s'assure alors qu'un problème lors de l'exécution d'une tâche dans une partition ne puisse pas interférer avec le bon déroulement des autres tâches dans les autres partitions. Ce concept est implémenté sous la forme, entre autres, d'un procédé de séquencement périodique qui vient, à intervalle de temps régulier, interrompre la tâche courante et gérer un basculement sur l'exécution d'une nouvelle tâche en s'assurant qu'elle va disposer de ses ressources, on parle d'un basculement de contexte {context switch en anglais).
On définit un niveau de certification relatif au procédé de développement utilisé pour réaliser une tâche donnée devant s'exécuter dans un tel système. Ce niveau de certification définit donc le soin et les techniques de développement utilisées, il reflète donc un niveau de qualité intrinsèque du logiciel.
Le concept de partitionnement permettant d'assurer qu'en cas de défaillance d'une tâche donnée, cette défaillance n'aura pas d'impact sur les autres tâches, on peut développer chaque tâche avec un niveau de certification correspondant à son niveau de criticité. Ceci est particulièrement avantageux, car le coût du développement selon les critères correspondant au niveau de certification le plus élevé est important.
Par exemple, dans le domaine du logiciel embarqué avionique, le standard définissant le concept de partitionnement est le standard « ARINC 653 », les niveaux de certification sont, quant à eux, définis par les normes ED-12B et DO-178B.
Ces dernières définissent 5 niveaux de criticité ou DAL {Design Assurance Level en anglais), de A niveau de certification le plus élevé à E niveau le plus faible.
Ces normes permettent d' assurer un niveau de sécurité élevé au logiciel développé tout en maîtrisant les coûts de développement en permettant de développer chaque tâche du système en fonction de sa criticité. Ces normes sont adaptées à un développement sur processeur mono-cœur ou, à un instant donné, une seule tâche fonctionne.
Or, ces dernières années voient le développement des processeurs multicœurs comme moyen principal de continuer la course à la puissance de calcul des processeurs. Il s'avère que les processeurs multicœurs actuels ne permettent pas de garantir l'étanchéité de fonctionnement entre les différents cœurs. On ne peut pas garantir qu'une tâche s'exécutant sur un des cœurs et sujette à une défaillance ne puisse pas perturber le bon déroulement d'une autre tâche s'exécutant sur un autre cœur. Cette étanchéité, concept de base du partitionnement, ne permet donc pas d'utiliser une simple transposition du concept de partitionnement et des niveaux de certification pour réaliser un exécutif temps réel qui soit sûr dans le contexte d'un processeur multicœur. L'invention vise à résoudre les problèmes précédents par la définition, en outre du niveau de certification intrinsèque à chaque tâche, d'un niveau de sécurité relatif à la criticité de l'exécution de l'instance de la tâche dans son contexte et par un procédé de séquencement réparti sur les différents cœurs qui permet d'échanger, lors de chaque intervalle de temps, les informations relatives au niveau de certification et au niveau de sécurité de chacune des tâches s'apprêtant à être lancée. Une prise de décision est alors réalisée sur chaque cœur de lancement de la tâche prévue en fonction des informations relatives reçues des autres cœurs.
L'invention concerne un procédé de séquencement d'un ensemble de tâches sur un processeur disposant d'une pluralité de cœurs d'exécution, les ressources du processeur étant divisées en une pluralité de partitions, ces partitions se partageant le temps sous la forme d'une succession d'intervalles de temps de manière synchrone sur chaque cœur du processeur, le procédé étant exécuté par un ensemble de modules de séquencement implémenté sur les cœurs du processeur, une instance de contrôle étant implémentée au sein desdits modules de séquencement, qui comporte une étape préliminaire de définition pour chaque instance de tâche devant être exécutée sur le système d'un niveau de sécurité relatif au caractère critique de l'exécution de l'instance particulière de la tâche, chaque tâche étant par ailleurs dotée d'un niveau de certification lié aux procédés de développement mis en œuvre lors de sa conception ; et qui comporte pour chaque partition une étape d'échange de messages entre les différents modules de séquencement de chaque cœur pour informer l'instance de contrôle des niveaux de certification et de sécurité des tâches s'apprêtant à être exécutées par les différents cœurs au sein de la partition courante et une étape de détermination d'une autorisation de lancement pour chacune des tâches s'apprêtant à être lancées sur chaque cœur en fonction des niveaux de certification et de sécurité des autres tâches s'apprêtant à être lancées au sein de la même partition.
Selon un mode particulier de réalisation de l'invention, le procédé comporte en outre, pour chaque partition, une étape de mise à jour du niveau de sécurité des tâches s'apprêtant à être lancées en fonction du contexte d'exécution desdites tâches.
Selon un mode particulier de réalisation de l'invention, l'instance de contrôle est centralisée au sein d'un module de séquencement particulier sur l'un des cœurs et l'étape d'échange de messages consiste en une étape d'envoi par chaque module de séquencement de ses informations à ce module de séquencement. Selon un mode particulier de réalisation de l'invention, l'instance de contrôle est répartie au sein des modules de séquencement sur chaque cœur et l'étape d'échange de messages consiste en une étape d'envoi par chaque module de séquencement de ses informations à tous les modules de séquencement.
Selon un mode particulier de réalisation de l'invention, l'étape de détermination d'une autorisation de lancement pour chacune des tâches, les niveaux de sécurité étant au nombre de 4, comporte les règles suivantes :
- une tâche ayant un niveau de sécurité 1, c'est-à-dire le plus faible, s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante ;
• toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification ;
- une tâche ayant un niveau de sécurité 2, s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante ;
• toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification ;
- une tâche ayant un niveau de sécurité 3 s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 4 n'est présente sur un autre cœur pour la partition courante ;
• toute tâche de niveau de sécurité 3 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification, en cas d'égalité, son numéro d'identification est supérieur ou égal aux autres ;
- une tâche ayant un niveau de sécurité 4, s'exécute si les conditions suivantes sont réunies :
• toute tâche de niveau de sécurité 4 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification, en cas d'égalité, son numéro d'identification est strictement supérieur aux autres.
Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels :
La Fig. 1 illustre un séquencement de tâche dans un exécutif temps réel classique,
La Fig. 2 illustre une architecture typique de processeur multicœur,
La Fig. 3 illustre le fonctionnement du système, cadre de l'invention,
Les Figs. 4a et 4b illustrent respectivement deux modes de réalisation du module de contrôle des modules de séquencement des cœurs du processeur, et
La Fig. 5 illustre le procédé de séquencement selon un exemple de réalisation de l'invention.
La Fig. 1 illustre un séquencement de tâches dans un exécutif temps réel classique exécuté sur un processeur mono-cœur. Les tâches Tl, T2, T3 et T4 s'exécutent alternativement sur le cœur Cl . Le temps est divisé en intervalles de temps successifs II à 111. Chacun de ces intervalles représente la composante temporelle d'une partition au sens du partitionnement défini plus haut. Le partitionnement temporel est généralement périodique en intervalles de temps de même longueur, mais ce n'est pas obligatoire.
Chaque tâche dispose de son propre niveau de certification dépendant des méthodes de développement mises en œuvre pour la programmer. Chaque partition s'exécute donc avec le niveau de certification associé à la tâche s'exécutant dans cette partition. Le système de partitionnement garantit une étanchéité temporelle entre les différentes partitions. Une partition exécutant une tâche de niveau de certification inférieur ne peut pas venir, en cas de dysfonctionnement de la tâche, perturber l'exécution dans une autre partition d'une autre tâche par exemple de niveau de certification supérieur. Ceci est important, car à chaque niveau de certification est associé un risque de dysfonctionnement. Il est donc important que ce risque ne puisse être accru par le fonctionnement des autres tâches si l'on veut pouvoir maîtriser le risque global lié à l'utilisation du système. C'est un facteur de sécurité majeur.
La Fig. 2 illustre une architecture typique de processeur multicœur. Au sein d'un même composant, on dispose d'une pluralité d'unités de calculs, 2.1 1 à 2.14. Ces unités de calcul sont appelées les cœurs et disposent approximativement des mêmes capacités qu'un processeur mono-cœur traditionnel. Leur nombre varie entre deux et huit cœurs dans les processeurs proposés aujourd'hui, mais nul doute que leur nombre est appelé à augmenter dans les années à venir. Typiquement, ces cœurs sont dotés chacun d'au moins une mémoire locale, 2.21 à 2.24, qui leur sert de mémoire de travail local dédiée. Une mémoire commune à l'ensemble des cœurs 2.5 est typiquement présente. Le composant dispose également d'un ensemble de modules 2.3, 2.4, dédiés à des opérations diverses telles que les entrées-sorties du processeur ou encore des unités de calcul spécifique comme les coprocesseurs graphiques. Ces différents modules communiquent par un bus 2.6. En particulier, un accès à la mémoire partagée 2.5 est géré par un mécanisme de cache au sein des mémoires locales 2.21 à 2.24.
Du fait de cette architecture et des procédés de développement mis en œuvre pour concevoir ces composants, il n'est pas possible aujourd'hui d'assurer une étanchéité entre les tâches s'exécutant sur les différents cœurs du processeur. Par exemple, une tâche victime d'un dysfonctionnement sur l'un des cœurs peut lancer des séries d'opérations mémoires qui auront pour effet de saturer le bus 2.6. De ce fait, les tâches s'exécutant sur les autres cœurs peuvent voir leur fonctionnement perturbé par le dysfonctionnement de la première tâche. Dans un tel contexte, l'utilisation d'un niveau de certification pour le développement de chaque tâche ne permet pas à lui seul de garantir des niveaux de sécurité satisfaisants pour l'ensemble du système. Le concept même de partitionnement basé sur une étanchéité des partitions est remis en cause.
Nous avons défini le concept de niveau de certification qui est une propriété intrinsèque d'un logiciel donné liée aux procédés de développement mis en œuvre lors de sa conception. Nous allons définir un autre concept, que nous appelons niveau de sécurité. Ce niveau de sécurité n'est pas une propriété intrinsèque d'un programme, mais une exigence liée à l'exécution d'une instance particulière de ce programme dans un contexte particulier. Il est donc lié à l'exécution particulière, sur un cœur particulier, de la tâche qui matérialise cette instance d'exécution du logiciel. Ce niveau de sécurité est lié au caractère critique de l'exécution de l'instance particulière de la tâche. Pour une même tâche, cette criticité peut évoluer dans le temps. Par exemple, une tâche de contrôle d'un volet n'est pas très critique au roulage d'un avion, mais peut le devenir en phase d'atterrissage. La solution développée concerne la notion de partitionnement. En particulier, le temps est toujours découpé en intervalles de temps successifs. Ce découpage est identique sur l'ensemble des cœurs du processeur. Ces cœurs sont donc synchronisés temporellement. Typiquement ces intervalles de temps sont identiques, mais cette condition n'est pas indispensable au bon fonctionnement du système.
La Fig. 3 illustre le fonctionnement du système, cadre de l'invention. On y voit la succession temporelle des partitions en abscisse, PI à Pl i . On suppose que le processeur dispose de 4 cœurs Cl à C4. Pour chaque partition et chaque cœur, on a indiqué l'occurrence de tâche qui doit s'exécuter selon l'ordonnancement prévu.
Chacune des tâches, ou plus exactement des instances de tâches pour chaque partition et chaque cœur, est dotée d'un niveau de certification et d'un niveau de sécurité. Le niveau de certification étant relatif aux procédés de développement utilisés pour créer la tâche est donc indirectement relatif à son niveau de fiabilité, c'est-à-dire à la probabilité d'un dysfonctionnement de ladite tâche. Le niveau de sécurité étant lié à la criticité d'un tel dysfonctionnement pour cette instance de tâche dans son contexte d'exécution. Il est donc lié à la gravité des conséquences prévisibles d'un tel dysfonctionnement.
Dans l'exemple de réalisation de l'invention, le système s'appuie sur les niveaux de certification définis dans la norme DO-178B destinée au domaine de l'avionique. Ces niveaux sont au nombre de cinq labellisés de A à E. Le niveau E correspond à un logiciel développé sans contraintes particulières. Tout logiciel peut donc, par défaut, prétendre au niveau de certification E. Les niveaux de certification D à A imposent des contraintes de qualité allant croissantes.
Toujours dans l'exemple de réalisation de l'invention, les niveaux de sécurité sont au nombre de quatre, labellisés de 1 à 4. Le niveau de sécurité 1 est le niveau le plus faible. Il implique qu'un dysfonctionnement de la tâche n'a pas d'impact critique. En fonction des impacts d'un possible dysfonctionnement, le niveau de sécurité augmente pour atteindre le niveau 4, le plus élevé. Typiquement, dans l'avionique, ce niveau est attribué aux tâches dont le dysfonctionnement peut créer un accident mettant la vie des personnels et/ou des passagers en jeu. L'attribution du niveau de sécurité à une tâche peut se faire par tout moyen. Typiquement, dans l'exemple de réalisation, ce niveau de sécurité est attribué par un expert à chaque tâche en fonction de son contexte. Nous rappelons ici que ce niveau peut varier dans le temps, pour une même tâche, par exemple en fonction des phases de vol. Ces niveaux de certification et de sécurité sont propres à l'exemple de réalisation. Dans d'autres modes de réalisation, ils pourraient se retrouver en nombres différents et porter d'autres noms.
Avantageusement, le procédé de séquencement selon l'invention est composé d'un module de séquencement qui s'exécute sur chacun des cœurs du processeur. On a représenté schématiquement aux Figs. 4a et 4b ces modules de séquencement 2.71 à 2.74 dans une architecture de processeur multicœur semblable à celle de la Fig. 2. Les mêmes références représentant les mêmes éléments. Ces modules 2.71 à 2.74 peuvent communiquer sous la forme d'échanges d'information, typiquement des messages. Une instance de contrôle va prendre la décision d'autoriser ou non le lancement de la tâche prévue au sein de la partition sur chacun des cœurs 2.11 à 2.14. Deux variantes d'implémentation peuvent être réalisées de cette instance de contrôle.
Selon un premier mode de réalisation figuré à la Fig. 4a, dit mode centralisé, un module de séquencement sur l'un des cœurs est élu instance de contrôle. A la Fig. 4a, ce module est le module 2.8 sur le cœur 2.11. Ce module 2.8 prend alors le nom de module de contrôle et communique avec les autres modules 2.72 à 2.74 pour, d'une part, obtenir les informations nécessaires à sa prise de décision et, d'autre part, informer les autres modules 2.72 à 2.74 des décisions prises.
Selon un second mode de réalisation, dit mode réparti, figuré à la Fig. 4b, chaque module de séquencement 2.71 à 2.74 sur chaque cœur 2.11 à 2.14 implémente le contrôle pour ses propres tâches dans un module de contrôle 2.81 à 2.84 qui lui est propre. Tous les modules 2.81 à 2.84 ont alors un fonctionnement équivalent et l'instance de contrôle est répartie entre les différents modules. Dans ce mode de réalisation, chaque module 2.81 à 2.84 communique avec les autres pour obtenir les informations nécessaires à sa prise de décision. Il prend ensuite sa décision concernant ses propres tâches et il n'est pas nécessaire d'en avertir les autres, contrairement au premier mode de réalisation.
La Fig. 5 illustre le procédé de séquencement selon l'invention visant à garantir un niveau de sécurité contrôlé dans un système s'exécutant sur un processeur multicœur. Lors de la première étape 4.1 on attribue à chaque instance de tâche devant s'exécuter au sein d'une partition sur l'un des cœurs du système un niveau de sécurité tel que nous l'avons défini. Cette étape est avantageusement une étape préalable au fonctionnement du système.
Pendant son fonctionnement, le système répète pour chaque partition les étapes suivantes. Lors d'une étape 4.2, de manière optionnelle, on met à jour le niveau de sécurité des tâches s'apprêtant à être lancées dans la partition courante. En effet, le niveau de sécurité étant lié au contexte d'exécution de l'instance de la tâche, il est avantageux de permettre une mise à jour de celui-ci en fonction d'une possible évolution du contexte pour chaque partition. Cette étape de mise à jour constitue un perfectionnement optionnel du procédé de l'invention.
Lors d'une étape 4.3 intervient un échange de messages entre les différents modules de séquencement de chaque cœur. Chaque cœur informe l'instance de contrôle des niveaux de certification et de sécurité de la tâche qui s'apprête à être séquencée sur ce cœur au sein de la partition courante. Dans le cas où l'instance de contrôle est centralisée, l'échange de message est, par exemple, un échange de chaque module de séquencement vers le module hébergeant l'instance de contrôle. Dans le cas où le contrôle est réparti, chaque module de séquencement informe chacun des autres modules sur chaque cœur.
L'instance de contrôle décide, lors d'une étape 4.4, d'une autorisation de lancement pour chacune des tâches s'apprêtant à être lancées sur chaque cœur. Cette décision est faite en fonction du niveau de certification et de sécurité des autres tâches s'apprêtant à être lancées au sein de la même partition.
Dans l'exemple de réalisation, les décisions sont prises selon les règles suivantes.
Une tâche ayant un niveau de sécurité 1, c'est-à-dire le plus faible, s'exécute si les conditions suivantes sont réunies :
• Aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante.
· Toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification.
Il est à noter que cette règle permet de faire cohabiter des tâches de niveau de certification différente. Une tâche de niveau de sécurité 1 peut cohabiter avec une tâche de niveau de sécurité 2, chacune sur un cœur du processeur, à condition que son niveau de certification soit au moins égal à celui de la tâche de niveau de sécurité 2. On vise ainsi à ne pas permettre que la tâche de niveau de sécurité 1 vienne dégrader le niveau de certification global de la partition. Une tâche ayant un niveau de sécurité 2 s'exécute si les conditions suivantes sont réunies :
• Aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante.
· Toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification.
Cette règle permet principalement de faire cohabiter temporellement sur les différents cœurs des tâches de niveau de certification identique. Les partitions de niveau 2 ayant le plus haut niveau de certification s'exécutent ainsi que, si elles existent, les partitions de niveau de sécurité 1 , mais de niveau de certification supérieur ou égal.
Une tâche ayant un niveau de sécurité 3, s'exécute si les conditions suivantes sont réunies :
· Aucune tâche de niveau de sécurité 4 n'est présente sur un autre cœur pour la partition courante.
• Toute tâche de niveau de sécurité 3 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification. En cas d'égalité, son numéro d'identification est supérieur ou égal aux autres.
Cette règle fait intervenir un nouveau paramètre des tâches, le numéro d'identification. Ce numéro identifie de manière unique une tâche. Si deux tâches, sur deux cœurs différents, ont le même numéro d'identification, cela indique qu'il s'agit d'une même tâche implémentée sous la forme de processus parallèles fonctionnant sur au moins deux cœurs. Cette règle implique qu'une tâche de niveau de sécurité 3 s'exécute seule sur le processeur, éventuellement de façon répartie sur plusieurs cœurs. On n'autorise aucune autre tâche à fonctionner au sein de la même partition.
Une tâche ayant un niveau de sécurité 4, s'exécute si les conditions suivantes sont réunies :
· Toute tâche de niveau de sécurité 4 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification. En cas d'égalité, son numéro d'identification est strictement supérieur aux autres. Cette règle n'autorise le fonctionnement d'une tâche de niveau 4 que de manière exclusive sur un seul cœur. Il n'est plus permis ici, comme c'était le cas en niveau de sécurité 3, d'avoir une tâche de niveau de sécurité 4 fonctionnant de manière répartie sur plusieurs cœurs. Une tâche de niveau de sécurité 4 s'exécute toujours seule au sein de sa partition.
Les deux dernières règles utilisent l'identifiant de tâche pour réaliser un procédé d'élection d'une tâche unique parmi un ensemble de tâches. L'homme du métier comprend que tout autre procédé d'élection peut être utilisé, par échange de messages, l'utilisation d'un autre critère permettant d'élire indépendamment une seule et même tâche de manière répartie. Ces algorithmes d'élection répartis sont bien connus de l'homme du métier. L'utilisation de l'identifiant de tâche n'est donc pas nécessaire à la réalisation de l'invention. On pourrait, par exemple, utiliser un identifiant de numéro de cœur qui permettrait également une élection.
Il faut également comprendre que les règles décrites ne sont qu'un exemple de réalisation de l'invention. D'autres règles peuvent être définies visant à implémenter une politique de sécurité qui peut être différente en fonction du nombre de niveaux de sécurité définis et du contexte d'utilisation du système.

Claims

REVENDICATIONS
1/ Procédé de séquencement d'un ensemble de tâches sur un processeur disposant d'une pluralité de cœurs d'exécution, les ressources du processeur étant divisées en une pluralité de partitions, ces partitions se partageant le temps sous la forme d'une succession d'intervalles de temps de manière synchrone sur chaque cœur du processeur, le procédé étant exécuté par un ensemble de modules de séquencement implémenté sur les cœurs du processeur, une instance de contrôle étant implémentée au sein desdits modules de séquencement, ledit procédé comportant :
- une étape (4.3) d'échange de messages entre les différents modules de séquencement de chaque cœur et ladite instance de contrôle, et
- une étape (4.4) de détermination d'une autorisation de lancement pour chacune des tâches s'apprêtant à être lancées sur chaque cœur,
caractérisé en ce qu'il comporte en outre :
- une étape (4.1) préliminaire de définition pour chaque instance de tâche devant être exécutée sur le système d'un niveau de sécurité relatif au caractère critique de l'exécution de l'instance particulière de la tâche, chaque tâche étant par ailleurs dotée d'un niveau de certification lié aux procédés de développement mis en œuvre lors de sa conception ;
- ladite étape (4.3) d'échange de messages entre les différents modules de séquencement de chaque cœur étant prévu pour informer l'instance de contrôle des niveaux de certification et de sécurité des tâches s'apprêtant à être exécutées par les différents cœurs au sein de la partition courante, et
- ladite étape (4.4) de détermination d'une autorisation de lancement pour chacune des tâches s'apprêtant à être lancées sur chaque cœur se faisant en fonction des niveaux de certification et de sécurité des autres tâches s'apprêtant à être lancées au sein de la même partition.
21 Procédé selon la revendication 1 , caractérisé en ce qu'il comporte en outre, pour chaque partition, une étape de mise à jour du niveau de sécurité des tâches s'apprêtant à être lancées en fonction du contexte d'exécution desdites tâches.
3/ Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que l'instance de contrôle est centralisée au sein d'un module de séquencement particulier sur l'un des cœurs et que l'étape d'échange de messages consiste en une étape d'envoi par chaque module de séquencement de ses informations à ce module de séquencement.
4/ Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que l'instance de contrôle est répartie au sein des modules de séquencement sur chaque cœur et que l'étape d'échange de messages consiste en une étape d'envoi par chaque module de séquencement de ses informations à tous les modules de séquencement.
5/ Procédé selon l'une des revendications 1 à 4, caractérisé en ce que l'étape de détermination d'une autorisation de lancement pour chacune des tâches, les niveaux de sécurité étant au nombre de 4, comporte les règles suivantes :
- une tâche ayant un niveau de sécurité 1, c'est-à-dire le plus faible, s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante ;
• toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification ;
- une tâche ayant un niveau de sécurité 2 s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 3 ou 4 n'est présente sur un autre cœur pour la partition courante ;
• toute tâche de niveau de sécurité 2 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification ;
- une tâche ayant un niveau de sécurité 3 s'exécute si les conditions suivantes sont réunies :
• aucune tâche de niveau de sécurité 4 n'est présente sur un autre cœur pour la partition courante ;
· toute tâche de niveau de sécurité 3 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification, en cas d'égalité, son numéro d'identification est supérieur ou égal aux autres ; - une tâche ayant un niveau de sécurité 4 s'exécute si les conditions suivantes sont réunies :
• toute tâche de niveau de sécurité 4 présente sur un autre cœur possède un niveau de certification inférieur ou égal à son propre niveau de certification, en cas d'égalité, son numéro d'identification est strictement supérieur aux autres.
EP12781350.9A 2011-11-10 2012-11-08 Procédé de séquencement sur un processeur multicoeur Withdrawn EP2776923A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1160274A FR2982683B1 (fr) 2011-11-10 2011-11-10 Procede de sequencement sur un processeur multicoeur.
PCT/EP2012/072184 WO2013068494A1 (fr) 2011-11-10 2012-11-08 Procédé de séquencement sur un processeur multicoeur

Publications (1)

Publication Number Publication Date
EP2776923A1 true EP2776923A1 (fr) 2014-09-17

Family

ID=47143132

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12781350.9A Withdrawn EP2776923A1 (fr) 2011-11-10 2012-11-08 Procédé de séquencement sur un processeur multicoeur

Country Status (8)

Country Link
US (1) US9405580B2 (fr)
EP (1) EP2776923A1 (fr)
CN (1) CN104040502B (fr)
CA (1) CA2854868A1 (fr)
FR (1) FR2982683B1 (fr)
IN (1) IN2014CN03676A (fr)
RU (1) RU2623799C2 (fr)
WO (1) WO2013068494A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3054902B1 (fr) * 2016-08-04 2019-06-21 Thales Procede et dispositif de distribution de partitions sur un processeur multi-coeurs

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026371A1 (en) * 2004-07-30 2006-02-02 Chrysos George Z Method and apparatus for implementing memory order models with order vectors
US7941585B2 (en) * 2004-09-10 2011-05-10 Cavium Networks, Inc. Local scratchpad and data caching system
US7581087B2 (en) * 2006-01-17 2009-08-25 Qualcomm Incorporated Method and apparatus for debugging a multicore system
JP4947441B2 (ja) * 2006-11-02 2012-06-06 日本電気株式会社 マルチプロセッサシステム、マルチプロセッサシステムにおけるシステム構成方法及びそのプログラム
US8316368B2 (en) * 2009-02-05 2012-11-20 Honeywell International Inc. Safe partition scheduling on multi-core processors
US8458718B2 (en) * 2009-08-27 2013-06-04 The Boeing Company Statically partitioning into fixed and independent systems with fixed processing core

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2013068494A1 *

Also Published As

Publication number Publication date
WO2013068494A1 (fr) 2013-05-16
US9405580B2 (en) 2016-08-02
RU2623799C2 (ru) 2017-06-29
CN104040502B (zh) 2017-11-14
US20140310823A1 (en) 2014-10-16
IN2014CN03676A (fr) 2015-10-16
FR2982683B1 (fr) 2014-01-03
CA2854868A1 (fr) 2013-05-16
CN104040502A (zh) 2014-09-10
RU2014118539A (ru) 2015-12-20
FR2982683A1 (fr) 2013-05-17

Similar Documents

Publication Publication Date Title
EP2832069B1 (fr) Systeme de supervision de la securite d'une architecture
WO2018207551A1 (fr) Dispositif de traitement d'informations et procédé de réponse à une anomalie
US9870282B2 (en) Systems and methods for providing service and support to computing devices with boot failure
FR2936068A1 (fr) Procede et dispositif d'encapsulation d'applications dans un systeme informatique pour aeronef.
FR3025907B1 (fr) Mecanisme et procede pour permettre une communication entre un client et un serveur en accedant a des donnees de messages en memoire partagee.
FR2934693A1 (fr) Systeme aeronautique embarque a reconfiguration dynamique, procede associe et aeronef embarquant un tel systeme.
DE112019007432B4 (de) Elektronische steuereinheit und programm
US9588685B1 (en) Distributed workflow manager
KR102164040B1 (ko) 클라우드 기반 전사적 자원 관리 시스템과 외부 시스템 간의 양방향 연동을 위한 마이크로 서비스 아키텍처 기반 open api 허브 시스템
CN116039542B (zh) 一种智能驾驶域控制器的管理系统及其相关方法
EP2776923A1 (fr) Procédé de séquencement sur un processeur multicoeur
JP4866636B2 (ja) 分散型プログラム実行環境における稼動品質管理方法
US8139477B2 (en) Network element bypass in computing computer architecture
EP3660677B1 (fr) Procédé et dispositif de surveillance d'application(s) logicielle(s) avec période temporelle tampon précédant une section réservée pour un ensemble de ressource(s) partagée(s), programme d'ordinateur et système avionique associés
EP3819767B1 (fr) Procédé et dispositif électronique de surveillance d'une application logicielle avionique via des compteurs d'appel(s) système, programme d'ordinateur et système avionique associés
Guitart et al. Risk-driven proactive fault-tolerant operation of iaas providers
EP1501241B1 (fr) Procédé d'approvisionnement de règles de politique dans un réseau géré à base de règles de politique
US20140325280A1 (en) Fault-tolerant system, fault-tolerant method and program
CN113672374A (zh) 用于联邦学习和隐私计算的任务调度方法及系统
US9244736B2 (en) Thinning operating systems
Goswami A Comparative Study of Synchronous vs Asynchronous API Orchestration in MuleSoft-Led Enterprise Modernization
FR2957171A1 (fr) Methode et outil d'aide a la conception d'un aeronef utilisant un critere de disponibilite operationnelle
FR3009100A1 (fr) Systeme comprenant un ensemble de ressources commun a plusieurs gestionnaires de ressources et de taches
Sharma Reliability analysis for a repairable system under N-policy and imperfect coverage
FR2965077A1 (fr) Procede de gestion de taches dans un microprocesseur ou un ensemble de microprocesseurs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140610

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAFRAN ELECTRONICS & DEFENSE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170601