WO2002039277A1 - Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur - Google Patents
Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur Download PDFInfo
- Publication number
- WO2002039277A1 WO2002039277A1 PCT/FR2001/003532 FR0103532W WO0239277A1 WO 2002039277 A1 WO2002039277 A1 WO 2002039277A1 FR 0103532 W FR0103532 W FR 0103532W WO 0239277 A1 WO0239277 A1 WO 0239277A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- task
- execution
- time
- system layer
- micro
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
Definitions
- control system to which the security method according to the invention is applied may include a memory protection unit and tables for the access rights on each of the segments of each context, which are predetermined and can if necessary be placed in ROM.
- the initialization of the table descriptor defining the rights of this context is done only once during the initialization phase of the whole system and, after this phase of initialization of the system, none of the processes executing on the central computing unit has, in its execution context, these tables there.
- a test 106 makes it possible to return to the initial node 101 if t (v) ⁇ s 2 and to pass to node 2 marked 107 if t (v)> s 2 .
- . var the set of messages accessible at the current time by the task.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Storage Device Security (AREA)
- Debugging And Monitoring (AREA)
- Alarm Systems (AREA)
- Hardware Redundancy (AREA)
Abstract
Le procédé est mis en oeuvre avec un système de gestion de type Architecture Cadencée par le temps en liaison avec un processeur d'unité centrale de calcul possédant un mode d'exécution privilégié dont l'accès est protégé par une instruction du type 'appel à la couche système'. Le seul appel à la couche système autorisé depuis une tâche de l'application considérée vers la couche système consiste à faire état du changement de noeud dans le graphe de contrôle de la tâche concernée. Lorsque la couche système a contrôlé que l'appel est licite par rapport au chemin d'exécution du graphe de contrôle qui est décrit dans les tables constantes de l'application, toutes les opérations à faire sur le noeud considéré, par la couche système, sont prédéterminées par les tables constantes de l'application associée de la couche système. Un pré-ordonnancement des listes des tâches d'une application considérée est effectué avant l'exécution temps réel au niveau d'un micro-noyau qui assurera ensuite, lorsqu'il sera appelé par la couche système, durant l'exécution temps réel, une mise à jour des listes des tâches de façon ordonnée selon les nouvelles caractéristiques temporelles des tâches, à savoir leur date d(i) de début au plus tôt et leur date f(i) de fin au plus tard calculées par la couche système.
Description
Procédé de sécurisation rendant déterministe l'exécution en temps réel d'applications multitâches du type contrôle-commande avec confinement d'erreur
La présente invention a pour objet un procédé de sécurisation rendant déterministe l'exécution en temps réel d'applications multitâches du type contrôle-commande dans un système de contrôle comprenant au moins une première horloge qui émet un signal d'interruption lorsqu'une quantité de temps réglable s'est écoulée, une unité centrale de calcul avec au moins un processeur pouvant recevoir au moins ledit signal d'interruption d'horloge, une mémoire principale et un ensemble de contrôleurs de périphérique pour la gestion d'entrées-sorties du système de contrôle.
Dans un système de gestion multitâche de divers traitements (entrées- sorties, calculs,...) ayant des échelles de temps différentes, aptes à échanger des données, avec synchronisation et coordination en temps réel de tous les traitements, il est souhaitable de pouvoir exécuter des traitements en temps réel de façon déterministe, c'est-à-dire avec une unicité et une invariance du comportement global de toutes les tâches qui interagissent entre elles et avec l'environnement. Il est également souhaitable que l'exécution des traitements en temps réel soit sécurisée, c'est-à-dire inclue la détection et le confinement d'anomalies de manière à assurer l'indépendance des diverses tâches par rapport aux défaillances, tout en demeurant le plus déterministe possible en présence d'anomalies de fonctionnement.
On connaît déjà de nombreux systèmes de gestion multitâches. Toutefois, ces systèmes de gestion sont la plupart du temps asynchrones et donc non déterministes. De plus, de tels systèmes présentent une conception qui n'empêche pas la propagation de certains modes de défaillance.
De façon plus particulière, on connaît par le document FR-A-2 771 828, un procédé de sécurisation d'un calculateur multitâche équipé d'un système de détection de défaillance par partitionnement temporel ou spatial qui repère à chaque instant la tâche dont l'exécution est licite.
Selon ce document, qui concerne un système du type à ordonnancement cyclique, le partitionnement est utilisé pour limiter la propagation des défaillances, mais il n'y a alors plus de communications entre les partitions, c'est-à-dire qu'il n'y a plus de gestion multitâche au niveau global. De plus, il existe toujours une possibilité de propagation des défaillances au sein d'une partition, ce qui ne permet pas d'avoir une sûreté maximale.
Le document FR-A-2 771 828 montre ainsi que l'obtention d'un déterminisme paraît contradictoire avec une gestion multitâche.
La présente invention vise à remédier aux inconvénients de l'art antérieur et à permettre de disposer de systèmes de contrôle plus intégrés, plus performants et plus sûrs.
De façon plus particulière, la présente invention vise à permettre une exécution sécurisée multitâche en temps réel et de façon déterministe par un calculateur avec confinement d'erreur et tolérance aux fautes. L'invention vise ainsi à permettre d'assurer une sécurisation assurant un haut degré de déterminisme de l'exécution en temps réel d'applications multitâches aussi bien pour des tâches cycliques que pour des tâches acycliques, avec des communications explicites (messages datés) et implicites (flots de données datées). Ces buts sont atteints grâce à un procédé de sécurisation rendant déterministe l'exécution en temps réel d'applications multitâches du type contrôle-commande dans un système de contrôle comprenant :
- au moins une première horloge qui émet un signal d'interruption sh lorsqu'une quantité de temps réglable s'est écoulée, - une unité centrale de calcul avec au moins un processeur pouvant recevoir au moins ledit signal d'interruption d'horloge sh,
- une mémoire principale, et
- un ensemble de contrôleurs de périphérique pour la gestion d'entrées-sorties du système de contrôle, procédé caractérisé en ce qu'il comprend les étapes suivantes :
(a) mémoriser, pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle
nécessitant un appel à une couche système, ces enchaînements se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système du système de contrôle, (b) mémoriser, pour chaque noeud du graphe de contrôle de chaque tâche, la nature de l'appel à la couche système et ses paramètres d'appel, y compris des paramètres temporels qui permettent les mises à jours de dates d(i) de "début au plus tôt" et de dates f(i) de "fin au plus tard",
(c) mémoriser, pour chaque tâche, un noeud initial dans le graphe associé,
(d) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, pour chaque tâche, le noeud initial et l'instant initial représentant l'état initial de la tâche considérée, (e) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps l'ordre de départ de chacune des tâches en effectuant un pré-ordonnancement des listes des tâches au niveau d'un micro-noyau atomique, (f) armer la première horloge pour émettre le signal d'interruption d'horloge sh constituant un appel au micro-noyau, au premier instant de l'application pour le démarrage de l'exécution de cette application en mode cadencé par le temps,
(g) en cours de fonctionnement normal après armement de la première horloge, provoquer le désarmement de la première horloge par le micro-noyau à chaque appel au micro-noyau ; lors d'un appel au micro-noyau par la couche système ou par le traitement du signal d'interruption sh, faire passer le micro-noyau à l'étape de mise à jour des listes des tâches de façon ordonnée selon les caractéristiques temporelles des tâches, à savoir leur date d(i) de début au plus tôt et leur date f(i) de fin au plus tard ; faire calculer au micro-noyau, après la mise à jour des listes, le plus petit instant futur où une tâche devra être réveillée et faire armer la première horloge par le micro-noyau,
à partir de ce plus petit instant futur, pour réveiller ladite tâche et sortir du micro-noyau,
(h) lors de l'exécution d'une tâche, effectuer un appel à la couche système seulement lorsqu'un noeud du graphe de contrôle de ladite tâche est atteint, en passant comme argument le numéro du noeud ; procéder à un contrôle, lors de l'entrée dans la couche système, pour vérifier si, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, afin de lancer au niveau de la couche système le traitement d'une anomalie si ledit enchaînement n'est pas autorisé et de poursuivre l'exécution si ledit enchaînement est autorisé, effectuer la mise à jour des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard à l'aide d'appels au micro-noyau par la couche système et poursuivre normalement l'exécution de la tâche en cours jusqu'à ce que celle-ci atteigne à nouveau un noeud de son graphe de contrôle.
De façon plus particulière, le procédé de sécurisation selon l'invention est appliqué à un système de contrôle comprenant en outre une unité de protection mémoire pour le contrôle des droits d'accès d'adressage, laquelle unité de protection mémoire, à partir d'une adresse demandée ad fournie par l'unité centrale de calcul et de droits (C) d'accès des contextes d'exécution du processeur sur l'espace mémoire adressable, produit de manière exclusive une adresse validée ay qui permet l'accès ou bien émet en direction de l'unité centrale de calcul un signal d'exception se d'adressage non autorisé, et le procédé de sécurisation comprend en outre les étapes suivantes : (i) lors d'une phase de préparation, mémoriser pour une application donnée, les droits d'accès à chacun des segments mémoire pour le micronoyau et pour chaque tâche de l'application et son prolongement dans la couche système de manière à constituer des premier et deuxième contextes d'exécution selon que les instructions se trouvent dans le code propre à l'application constituant la tâche ou que ces instructions se trouvent dans le code générique de la couche système constituant le prolongement de la tâche dans la couche système,
0") pour une application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, initialiser le contexte du micro-noyau et les premier et deuxième contextes d'exécution pour chaque tâche et pour son prolongement dans la couche système,
( ) lors de l'exécution d'une tâche, effectuer un appel à la couche système à l'aide d'une instruction de passage dans un mode d'exécution privilégié qui permet de passer du contexte d'exécution de la tâche au contexte d'exécution de son prolongement dans la couche système, et après avoir contrôlé que l'enchaînement à partir du noeud correspondant au précédent appel système est autorisé, et après mise à jour des paramètres temporels de la tâche à l'aide d'appels au micro-noyau par la couche système, retourner dans le code de la tâche à l'aide d'une instruction de retour dans le mode non- privilégié qui permet de passer du contexte d'exécution du prolongement dans la couche système au contexte d'exécution de la tâche.
De façon préférentielle, les contextes d'exécution de chaque tâche de l'application sont deux à deux disjoints.
Selon une caractéristique particulière du procédé selon l'invention, les prolongements des contextes d'exécution des tâches de l'application dans la couche système ne sont pas accessibles en écriture aux contextes d'exécution des tâches avec le code de l'application.
Le codage du graphe de contrôle d'une tâche interdit toute défaillance de cause commune entre le mécanisme de contrôle d'exécution d'une tâche quelconque de l'application et l'exécution de cette tâche elle-même. Le procédé selon l'invention peut encore comprendre les étapes suivantes :
(I) lors d'une phase de préparation, mémoriser pour une application donnée, pour tous les enchaînements autorisés dans chaque tâche, un quota de temps constituant un majorant du temps d'exécution maximum nécessaire pour passer d'un noeud à l'autre dans le graphe de contrôle de la tâche, chacun de ces quotas de temps englobant le temps passé dans l'exécution des
instructions propres de la tâche, mais aussi le temps passé dans l'exécution du code générique de la couche système en prolongement de la tâche,
(m) en cours de fonctionnement normal après armement de la première horloge, lors d'un appel au micro-noyau déclenché par le signal sh d'interruption sur le temps et provoquant le désarmement de la première horloge, procéder à un contrôle pour vérifier si le signal sh d'interruption sur le temps déclenchant l'appel au micro-noyau est lié à une tentative de violation d'un quota de temps, et si c'est le cas faire lancer par le micro-noyau le traitement de l'anomalie tandis que si le signal sh d'interruption sur le temps n'est pas lié à une tentative de violation d'un quota de temps, faire passer le micro-noyau à l'étape de mise à jour des listes de tâches et, après cette mise à jour des listes des tâches, faire calculer au micro-noyau d'une part le plus petit instant futur où une tâche devra être réveillée et d'autre part l'instant futur à partir duquel le quota de temps imparti à la tâche en exécution à la sortie du micro-noyau, déterminée lors de la mise à jour des listes, sera épuisé, et faire armer la première horloge par le micro-noyau au plus petit de ces instants futurs pour, selon le cas, soit réveiller la tâche, soit détecter une tentative de violation de quota de temps révélant une anomalie de fonctionnement, et sortir du micro-noyau après armement de la première horloge. Dans le cas où une deuxième horloge est mise en œuvre dans le système de contrôle, selon une caractéristique particulière de l'invention, on fait accéder le micro-noyau à cette deuxième horloge pour contrôler, par comparaison des signaux de temps, l'écoulement du temps cadencé par la première horloge. Le procédé de sécurisation selon l'invention, adapté pour rendre déterministe l'exécution en temps réel d'applications multitâches communicantes de type contrôle-commande, peut comprendre en outre les étapes suivantes :
(n) lors d'une phase de préparation, mémoriser pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle et de communication avec les autres tâches de l'application nécessitant un appel à la couche système, ces
enchaînements autorisés se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système, (o) mémoriser chaque zone tampon nécessaire à un échange de données entre tâches, en indiquant sa taille, la taille des éléments qu'elle contient, son emplacement ou adresse de base, ainsi que les relations entre les zones tampons permettant de valider les transferts d'informations nécessaires aux communications, (p) mémoriser pour chaque zone tampon les valeurs initiales de ses éléments,
(q) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps les valeurs des éléments de la zone tampon avec les valeurs précédemment mises en mémoire,
(r) lors de l'exécution d'une tâche, lors d'un appel à la couche système lorsqu'un noeud du graphe de contrôle de la tâche est atteint et après vérification que, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, effectuer les mises à jour successives des zones tampons en fonction de la nature de l'appel précédemment mémorisé par les mises à jour incrémentales et nécessaires des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard. Selon une caractéristique particulière de l'invention, au niveau de la couche système on autorise le partage des seule zones tampons par les prolongements des contextes d'exécution des tâches d'une application, une zone tampon donnée pour les communications dynamiques correspondant à l'envoi de messages ne pouvant être partagée que par deux prolongements de contextes d'exécution d'une tâche, tandis qu'une zone tampon donnée pour les communications statiques correspondant à un flot de données datées peut être partagée par plus de deux prolongements de contextes d'exécution d'une tâche
mais ne peut toujours être modifiée que par la tâche propriétaire dans le prolongement de son contexte dans la couche système.
Le procédé de sécurisation selon l'invention est applicable à des applications de contrôle-commande à haut degré de criticité en ce qui concerne la sûreté.
En particulier, le procédé selon l'invention peut être appliqué à un système de contrôle-commande d'un niveau de classe de sûreté 1 E pour un réacteur nucléaire.
D'autres caractéristiques et avantages de l'invention ressortiront de la description suivante de modes particuliers de réalisation, donnés à titre d'exemples en référence aux dessins annexés, sur lesquels :
- la Figure 1 est une représentation simplifiée de l'architecture d'un système de contrôle auquel est applicable le procédé de sécurisation de l'invention, - la Figure 2 est un schéma montrant la répartition en profondeur du code par rapport à une couche système et à un micro-noyau, avec le procédé conforme à l'invention,
- la Figure 3 est un organigramme correspondant au traitement d'un exemple de tâche temps réel selon le procédé de sécurisation conforme à l'invention,
- la Figure 4 est un graphe de contrôle correspondant à l'organigramme de la Figure 3,
- la Figure 5 est un exemple de chronogramme et de valeurs temporelles associées lors du traitement de l'exemple de tâche temps réel des Figures 3 et 4 selon le procédé de sécurisation conforme à l'invention,
- la Figure 6 est une table des noeuds du graphe de contrôle de la Figure 4, comportant la description des opérations à effectuer sur les dates de début au plus tôt d(i) et les dates de fin au plus tard f(i),
- la Figure 7 est un organigramme correspondant au traitement d'un exemple de première tâche temps réel destinée à communiquer avec une deuxième tâche, selon le procédé de sécurisation conforme à l'invention,
- la Figure 8 est un graphe de contrôle correspondant à l'organigramme de la Figure 7,
- la Figure 9 est un organigramme correspondant au traitement d'un exemple de deuxième tâche temps réel destinée à communiquer avec la première tâche temps réel illustrée par l'organigramme de la Figure 7,
- la Figure 10 est un graphe de contrôle correspondant à l'organigramme de la Figure 9,
- la Figure 11 est un exemple de chronogramme et de valeurs temporelles associées lors du traitement de l'exemple de tâches communi- cantes temps réel des Figures 7 à 10, selon le procédé de sécurisation conforme à l'invention,
- les Figures 12 et 13 sont des tables de noeuds des graphes de contrôle des Figures 8 et 10, comportant les descriptions des opérations à effectuer sur les dates de début au plus tôt d(i) et les dates de fin au plus tard f(i) et sur les messages, et
- la Figure 14 est une table détaillée faisant apparaître pour le processeur les droits d'accès aux segments de la mémoire relatifs à une tâche, à la couche système et au micro-noyau selon un exemple du procédé selon l'invention. On décrira d'abord en référence à la Figure 1 un exemple d'architecture type simplifiée d'un système de contrôle auquel est applicable le procédé de sécurisation selon l'invention.
Le système de contrôle comprend au moins une première horloge 14 qui transmet par une ligne 22 un signal d'interruption sh lorsqu'une quantité de temps programmable s'est écoulée. Une unité centrale de calcul 10 comprend au moins un processeur pouvant recevoir des données par une ligne 21 et le signal d'interruption sh par la ligne 22.
L'unité centrale de calcul 10 permet l'envoi, par des lignes 23, 24, de signaux d'adresse à une mémoire principale comprenant une mémoire morte 12 et une mémoire vive 13.
La mémoire morte 12 contient au moins les informations (A) comprenant les programmes de l'application concernée et les informations (B) comprenant les données et les tables constantes de l'application.
La mémoire vive 13 contient les données variables de travail des programmes de l'application.
Des contrôleurs 1 _ à 1 N de périphériques 1 à N permettent d'assurer la gestion en temps réel d'entrées et de sorties du système de contrôle.
Une deuxième horloge 15 peut être mise en oeuvre pour effectuer un contrôle supplémentaire du bon fonctionnement de l'horloge 14. Le système de contrôle peut en outre comprendre une unité de protection mémoire 16 permettant d'assurer un contrôle des droits d'accès d'adressage.
A partir d'une adresse demandée ad fournie par l'unité centrale de calcul 10 à l'unité de protection mémoire 16 par la ligne 23 et de droits (C) d'accès des contextes d'exécution du processeur sur l'espace mémoire adressable, fournis par une ligne 26 reliant la mémoire morte 12 à l'unité de protection mémoire 16, cette unité de protection mémoire 16 produit de manière exclusive sur la ligne 14 reliée aux mémoires 12, 13, aux contrôleurs de périphériques 1ι à 1 N et aux horloges 14, 15 une adresse validée a qui permet l'accès ou bien émet par une ligne 25 en direction de l'unité centrale de calcul 10 un signal d'exception se d'adressage non autorisé.
L'unité de protection mémoire 16 peut être constituée par un mécanisme présent dans une unité de gestion mémoire standard de type MMU ("Memory Management Unit") laquelle unité de gestion mémoire peut elle-même être incorporée dans le processeur de l'unité centrale de calcul 10.
Le processeur de l'unité centrale de calcul 10, qui peut recevoir au moins un signal d'interruption d'horloge sh et un signal d'exception se d'adressage non autorisé, possède un mode d'exécution privilégié dont l'accès est protégé par une instruction du type "appel à la couche système", qui peut être par exemple une instruction de dérivation ("trap").
D'une manière générale, l'invention concerne un système de gestion de type Architecture Cadencée par le Temps ou TTA ("Time Triggered
Architecture") multitâche déterministe sécurisé temps réel avec communication explicite (messages datés) et implicites (flots de données datées), le rythme des tâches étant indifféremment cyclique ou acyclique.
De façon plus particulière, selon le procédé de sécurisation conforme à l'invention, on procède à une gestion spécifique des appels à la couche système (par un appel au mode d'exécution privilégié) du système de contrôle, laquelle gestion spécifique permet la détection et le confinement d'erreur avec une garantie de comportement déterministe et prévisible.
Selon l'invention, la gestion des appels à la couche système opère de la façon suivante :
M le seul appel à la couche système autorisé depuis une tâche de l'application considérée vers la couche système consiste à faire état du changement de noeud dans le graphe de contrôle de la tâche concernée ; ii/ la couche système contrôle alors que cet appel est licite par rapport au chemin d'exécution du graphe de contrôle qui est décrit dans les tables constantes de l'application ; iii/ lorsque l'appel est licite, toutes les opérations à faire sur le noeud considéré, par la couche système, sont prédéterminées par les tables constantes de l'application associée de la couche système. Un pré-ordonnancement des listes des tâches d'une application considérée est effectué avant l'exécution temps réel au niveau d'un micronoyau atomique qui assurera ensuite, lorsqu'il sera appelé par la couche système, durant l'exécution temps réel, une mise à jour des listes des tâches de façon ordonnée selon les nouvelles caractéristiques temporelles des tâches, à savoir leur date d(i) de début au plus tôt et leur date f(i) de fin au plus tard calculées par la couche système.
Le procédé de sécurisation de base selon l'invention comprend essentiellement les étapes suivantes :
(a) mémoriser, pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle nécessitant un appel à une couche système, ces enchaînements se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la
tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système du système de contrôle,
(b) mémoriser, pour chaque noeud du graphe de contrôle de chaque tâche, la nature de l'appel à la couche système et ses paramètres d'appel, y compris des paramètres temporels qui permettent les mises à jours de dates d(i) de "début au plus tôt" et de dates f(i) de "fin au plus tard",
(c) mémoriser, pour chaque tâche, un noeud initial (Noeud 0) dans le graphe associé,
(d) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, pour chaque tâche, le noeud initial (Noeud 0) et l'instant initial représentant l'état initial de la tâche considérée,
(e) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps l'ordre de départ de chacune des tâches en effectuant un pré-ordonnancement des listes des tâches au niveau d'un micro-noyau atomique,
(f) armer la première horloge 14 pour émettre le signal d'interruption d'horloge sh constituant un appel au micro-noyau, au premier instant de l'application pour le démarrage de l'exécution de cette application en mode cadencé par le temps,
(g) en cours de fonctionnement normal après armement de la première horloge 14, provoquer le désarmement de la première horloge 14 par le micro-noyau à chaque appel au micro-noyau ; lors d'un appel au micro- noyau par la couche système ou par le traitement du signal d'interruption sh, faire passer le micro-noyau à l'étape de mise à jour des listes des tâches de façon ordonnée selon les caractéristiques temporelles des tâches, à savoir leur date d(i) de début au plus tôt et leur date f(i) de fin au plus tard ; faire calculer au micro-noyau, après la mise à jour des listes, le plus petit instant futur où une tâche devra être réveillée et faire armer la première horloge 14 par le micronoyau, à partir de ce plus petit instant futur, pour réveiller ladite tâche et sortir du micro-noyau,
(h) lors de l'exécution d'une tâche, effectuer un appel à la couche système seulement lorsqu'un noeud du graphe de contrôle de ladite tâche est atteint, en passant comme argument le numéro du noeud ; procéder à un contrôle, lors de l'entrée dans la couche système, pour vérifier si, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, afin de lancer au niveau de la couche système le traitement d'une anomalie si ledit enchaînement n'est pas autorisé et de poursuivre l'exécution si ledit enchaînement est autorisé, effectuer la mise à jour des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard à l'aide d'appels au micro-noyau par la couche système et poursuivre normalement l'exécution de la tâche en cours jusqu'à ce que celle-ci atteigne à nouveau un noeud de son graphe de contrôle.
Comme on l'a indiqué plus haut, le système de contrôle auquel est appliqué le procédé de sécurisation selon l'invention peut comprendre une unité de protection mémoire et des tables pour les droits d'accès sur chacun des segments de chaque contexte, qui sont prédéterminées et peuvent le cas échéant être placées en mémoire morte. Pour chacun des contextes d'exécution, l'initialisation du descripteur de table définissant les droits de ce contexte n'est faite qu'une seule fois lors de la phase d'initialisation de l'ensemble du système et, après cette phase d'initialisation du système, aucun des traitements s'exécutant sur l'unité centrale de calcul n'a, dans son contexte d'exécution, ces tables là.
Le procédé de sécurisation selon l'invention peut alors comprendre en outre les étapes suivantes qui s'intercalent avec les étapes précédemment définies :
(i) lors d'une phase de préparation, mémoriser pour une application donnée, les droits d'accès à chacun des segments mémoire pour le micronoyau et pour chaque tâche de l'application et son prolongement dans la couche système de manière à constituer des premier et deuxième contextes d'exécution selon que les instructions se trouvent dans le code propre à l'application constituant la tâche ou que ces instructions se trouvent dans le
code générique de la couche système constituant le prolongement de la tâche dans la couche système,
(j) P°ur une application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, initialiser le contexte du micro-noyau et les premier et deuxième contextes d'exécution pour chaque tâche et pour son prolongement dans la couche système,
(k) lors de l'exécution d'une tâche, effectuer un appel à la couche système à l'aide d'une instruction de passage dans un mode d'exécution privilégié qui permet de passer du contexte d'exécution de la tâche au contexte d'exécution de son prolongement dans la couche système, et après avoir contrôlé que l'enchaînement à partir du noeud correspondant au précédent appel système est autorisé, et après mise à jour des paramètres temporels de la tâche à l'aide d'appels au micro-noyau par la couche système, retourner dans le code de la tâche à l'aide d'une instruction de retour dans le mode non- privilégié qui permet de passer du contexte d'exécution du prolongement dans la couche système au contexte d'exécution de la tâche.
Le procédé de sécurisation selon l'invention peut également faire référence à des quotas de temps et peut alors comprendre en outre les étapes suivantes qui s'intercalent avec les étapes précédemment définies du procédé de base ou du procédé de base modifié pour tenir compte de l'existence de modes d'exécution privilégiés permettant un passage à un contexte d'exécution du prolongement d'une tâche dans la couche système :
(I) lors d'une phase de préparation, mémoriser pour une application donnée, pour tous les enchaînements autorisés dans chaque tâche, un quota de temps constituant un majorant du temps d'exécution maximum nécessaire pour passer d'un noeud à l'autre dans le graphe de contrôle de la tâche, chacun de ces quotas de temps englobant le temps passé dans l'exécution des instructions propres de la tâche, mais aussi le temps passé dans l'exécution du code générique de la couche système en prolongement de la tâche,
(m) en cours de fonctionnement normal après armement de la première horloge 14, lors d'un appel au micro-noyau déclenché par le signal sh
d'interruption sur le temps et provoquant le désarmement de la première horloge 14, procéder à un contrôle pour vérifier si le signal sh d'interruption sur le temps déclenchant l'appel au micro-noyau est lié à une tentative de violation d'un quota de temps, et si c'est le cas faire lancer par le micro-noyau le traitement de l'anomalie tandis que si le signal sh d'interruption sur le temps n'est pas lié à une tentative de violation d'un quota de temps, faire passer le micro-noyau à l'étape de mise à jour des listes de tâches et, après cette mise à jour des listes des tâches, faire calculer au micro-noyau d'une part le plus petit instant futur où une tâche devra être réveillée et d'autre part l'instant futur à partir duquel le quota de temps imparti à la tâche en exécution à la sortie du micro-noyau, déterminée lors de la mise à jour des listes, sera épuisé, et faire armer la première horloge 14 par le micro-noyau au plus petit de ces instants futurs pour, selon le cas, soit réveiller la tâche, soit détecter une tentative de violation de quota de temps révélant une anomalie de fonctionnement, et sortir du micro-noyau après armement de la première horloge 14.
La procédure de mise à jour des listes de tâches de l'application au niveau du micro-noyau peut encore être explicitée de la façon indiquée ci- dessous qui prend en compte un mode de réalisation préférentiel dans lequel il est fait référence à un quota de temps imparti à la tâche en cours de traitement, mais qui peut s'appliquer aussi à un mode de réalisation de base simplifié si l'on omet la référence à un quota de temps
Pour chaque appel au micro-noyau lors de l'exécution, quel que soit le prolongement du contexte d'exécution de la tâche concernée dans la couche système, deux paramètres comptent pour la mise à jour des listes des tâches : la date d(i) de début au plus tôt et la date f(i) de fin au plus tard. Deux listes de tâches sont gérées : la liste des tâches éligibies, prêtes pour l'exécution, c'est- à-dire dont la date de début au plus tôt d(i) est dans le passé, et la liste des tâches non éligibies, non prêtes pour l'exécution ou en attente de réveil, c'est-à- dire dont la date de début au plus tôt d(i) est dans le futur. La liste des tâches éligibies est ordonnée suivant les dates de fin au plus tard croissantes ; celle des tâches non éligibies est ordonnée suivant les dates d(i) de début au plus
tôt croissantes. Toute tâche en attente est assurée de passer dans l'état "prête" lorsque sa date de début au plus tôt est atteinte. α) Si, lors de l'appel au micro-noyau, la date d(i) de début au plus tôt d'une tâche est dans le futur, la tâche est non éligible et est alors transférée dans la liste ordonnée des tâches non éligibies. Cette date permet de calculer le prochain instant où une tâche devra être réveillée d'après l'ordre des dates de début au plus tôt : la plus petite des dates futures de début au plus tôt donnera l'instant futur où la prochaine tâche concernée sera éligible (pour être réveillée). β) Si, au contraire, lors de l'appel au micro-noyau, la date d(i) de début au plus tôt de la tâche concernée est dans le passé, la tâche est éligible et est transférée dans la liste ordonnée des tâches éligibies. Le micro-noyau donne alors la main à la tâche éligible qui a la date future de fin au plus tard la plus petite selon la suite ordonnée des dates de fin au plus tard et il calcule l'instant futur à partir duquel le quota de temps imparti à la tâche élue sera épuisé (le quota résultant de la différence entre la plus petite date future de fin au plus part et l'instant présent).
Y) Toutefois, si l'appel au micro-noyau est provoqué par l'horloge 14 dans le cas d'un armement pour quota de temps imparti à la tâche en cours de traitement, alors le micro-noyau exécute d'abord l'action de traitement d'anomalie prévue par l'application, puis les actions α) et β).
Le micro-noyau, à partir de ces deux instants (le plus petit instant futur de réveil d'une tâche et l'instant futur d'épuisement de quota de temps imparti à la tâche élue) arme ensuite l'horloge 14 de telle façon qu'elle soit activée au plus petit de ces deux instants (soit pour réveiller une tâche au bon moment, soit pour détecter une tentative de violation de quota de temps c'est-à-dire une anomalie de fonctionnement). L'horloge 14 étant armée, on sort du micronoyau éventuellement avec commutation.
Ainsi, pendant l'exécution, le changement de tâche active se fait soit par interruption au temps, soit consécutivement à un changement de noeud pour la tâche active.
L'interruption due au temps peut avoir pour origine soit le fait qu'une tâche en attente devient prête (compte tenu du cadencement par le temps), soit le fait que la tâche active a épuisé son quota de temps imparti, auquel cas un contrôle de sûreté est effectué. Lorsque la tâche active change de noeud dans son graphe de contrôle, soit sa date de fin au plus tard est reculée, soit sa date de début au plus tôt est reculée. Dans le premier cas, une autre tâche est susceptible de devenir active à sa place. Dans le deuxième cas, la tâche active est mise dans l'ensemble des tâches en attente si sa nouvelle date de début au plus tôt est dans le futur. Le nombre de préemptions est fini et borné et il est possible de calculer analytiquement une borne maximale du nombre de préemptions.
Par ailleurs, dans la mesure où les quotas de temps sont mis à jour et contrôlés à chaque changement de noeud, il est possible de détecter à temps les anomalies afin de confiner immédiatement la tâche. Dans la mesure où seuls les déplacements possibles dans le graphe de contrôle sont acceptés, il est impossible qu'une tâche ait un comportement temporel la conduisant à consommer plus de ressources (par exemple de ressource mémoire pour les communications) que ce qui a été statiquement évalué à l'aide du même graphe. On décrira maintenant en référence aux Figures 3 à 6 un exemple de mise en oeuvre du procédé de sécurisation selon l'invention avec une tâche temps réel particulière.
Selon cet exemple, la fonction de la tâche temps réel est de signaler une alarme si une valeur mesurée est telle que v dépasse un seuil s_ pendant une durée t(v) qui dépasse elle-même un seuil s2.
La Figure 3 représente un organigramme qui illustre le processus de traitement de la tâche correspondant à l'exemple ci-dessus.
La référence 101 désigne un noeud initial ou Noeud 0, au niveau duquel il est fait appel à la couche système. La référence 102 correspond à une première étape d'acquisition de la valeur mesurée v.
La référence 103 correspond à un test à la suite duquel on retourne au noeud initial 101 puis à l'étape 102, si v < si et par contre on passe au noeud 1 repéré 104 puis à l'étape 105 si v > s_.
Au niveau du noeud 104, il est fait appel à la couche système et à l'étape 105 on calcule la durée t(v).
Après l'étape 105, un test 106 permet de retourner au noeud initial 101 si t(v) < s2 et de passer au noeud 2 repéré 107 si t(v) > s2.
Après le deuxième noeud 107, où il est fait appel à la couche système, on passe à l'étape 108 de signalement de l'alarme à la suite de quoi on retourne au noeud initial 101.
La Figure 4 représente le graphe de contrôle avec les noeuds 101 , 104, 107 et les arcs associés qui correspondent à l'organigramme de la Figure 3.
Dans l'exemple considéré, les délais alloués pour effectuer les opérations "acquérir v" (étape 102), "calculer t(v)" (étape 105) et "signaler l'alarme" (étape 108) sont les suivantes :
étape 102 d'acquisition : 1 unité de temps étape 105 de calcul : 2 unités de temps supplémentaires étape 108 de signalisation : 1 unité de temps.
Pour chacun des noeuds 101 , 104, 107, on indique ci-dessous les services rendus par la couche système et les opérations effectuées sur les dates di de début au plus tôt et sur les dates fi de fin au plus tard, sachant que lors de l'initialisation on a une date d0 de début au plus tôt telle que d(0) = 0 et on a une date f(0) de fin au plus tard telle que f(0) = 1 unité de temps.
La Figure 6 présente de façon synthétique une table des noeuds 0, 1 et 2 avec la description des opérations à effectuer sur la date d(i) de début au plus tôt et la date f(i) de fin au plus tard.
Par ailleurs, le graphe de contrôle de la tâche illustré sur la Figure 4 peut être codé sous forme matricielle et se présente alors sous la forme suivante, dans le cas de l'exemple précité :
Noeud 0 1 2
0 fA A I
M = 1 A I A
2 ,A I I
où m = A si le déplacement du noeud i au noeud j est Autorisé
m = I si le déplacement du noeud i au noeud j est Interdit.
La Figure 5 illustre sous forme de chronogramme un exemple de mise en œuvre de la tâche temps réel décrite ci-dessus en faisant apparaître les valeurs temporelles associées. Les chiffres de 1 à 10 désignent l'heure réelle en nombre d'unités de temps depuis le début du fonctionnement en mode cadencé par le temps.
Le procédé de sécurisation selon l'invention est aussi adapté pour rendre déterministe l'exécution en temps réel d'applications multitâches communiquant par messages entre elles.
Dans ce cas, le procédé comprend les étapes particulières suivantes, qui s'intercalent avec les étapes précédemment décrites dans le cas d'un procédé de base avec applications multitâches sans indication de communication entre tâches :
(n) lors d'une phase de préparation, mémoriser pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle et de communication avec les autres tâches de l'application nécessitant un appel à la couche système, ces enchaînements autorisés se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système,
(o) mémoriser chaque zone tampon nécessaire à un échange de données entre tâches, en indiquant sa taille, la taille des éléments qu'elle contient, son emplacement ou adresse de base, ainsi que les relations entre les zones tampons permettant de valider les transferts d'informations nécessaires aux communications,
(p) mémoriser pour chaque zone tampon les valeurs initiales de ses éléments,
(q) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps les valeurs des éléments de la zone tampon avec les valeurs précédemment mises en mémoire,
(r) lors de l'exécution d'une tâche, lors d'un appel à la couche système lorsqu'un noeud du graphe de contrôle de la tâche est atteint et après vérification que, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, effectuer les mises à jour successives des zones tampons en fonction de la nature de l'appel précédemment mémorisé par les mises à jour incrémentales et nécessaires des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard. Dans le cas où des premier et deuxième contextes d'exécution sont définis pour chaque tâche de l'application et son prolongement dans la couche système, on a en outre les particularités suivantes :
Au niveau de la couche système, on autorise le partage des seule zones tampons par les prolongements des contextes d'exécution des tâches d'une application, une zone tampon donnée pour les communications dynamiques correspondant à l'envoi de messages ne pouvant être partagée que par deux prolongements de contextes d'exécution d'une tâche, tandis qu'une zone tampon donnée pour les communications statiques correspondant à un flot de données datées peut être partagée par plus de deux prolongements de contextes d'exécution d'une tâche mais ne peut toujours être écrite ou modifiée que par un seul contexte.
On décrira maintenant en référence aux figures 7 à 13, un exemple d'application du procédé de sécurisation selon l'invention à la mise en oeuvre de deux tâches temps réel communiquant par message. Dans cet exemple simple, la fonction réalisée consiste à allumer une lampe d'alarme si une valeur mesurée v est telle que v dépasse un seuil s-j , et
si la durée t(v) de dépassement du seuil s-| , par la valeur mesurée v dépasse elle-même un seuil s2.
Une tâche de traitement fait ainsi l'acquisition de v et envoie, si nécessaire, un message à une tâche d'alarme qui allume la lampe indiquée.
La Figure 7 représente l'organigramme correspondant à l'exécution de la tâche de traitement de l'exemple considéré.
La référence 111 désigne le noeud initial ou noeud 0 pour lequel il est fait appel à la couche système. La première étape 112 est une étape d'acquisition de la valeur mesurée v, à laquelle est associé un test 113 qui compare la valeur v au seuil si .
Si v < s-*, il y a retour au noeud initial 111 tandis que si v > s-] , on passe au noeud 1 désigné par la référence 114 et qui donne lieu à un appel à la couche système. La deuxième étape 115, qui fait suite au noeud 114, correspond au calcul de la durée t(v).
Le test 116 associé à l'étape 115 compare la durée t(v) au seuil s2. Si t(v) < s2, il y a retour au noeud initial 111 , tandis que si t(v) > s2, on passe au noeud 2 désigné par la référence 117 et qui donne lieu à un appel à la couche système.
Après le noeud 117, on passe au troisième noeud désigné par la référence 118 pour lequel il y a appel à la couche système et réalisation d'une troisième étape consistant à envoyer un message d'alarme, avant de retourner au noeud initial 111. La Figure 8 représente le graphe de contrôle correspondant à l'organigramme de la Figure 7, avec les noeuds et arcs autorisés.
La Figure 9 représente l'organigramme correspondant à l'exécution de la tâche d'alarme de l'exemple considéré.
La référence 121 désigne le noeud initial ou noeud 0 pour lequel il est fait appel à la couche système.
Un test 122 examine si un message est reçu.
Dans le cas où aucun message n'est présent, il y a passage à une étape 123 d'extinction de la lampe d'alarme et retour au noeud initial 121.
Si un ou plusieurs messages sont présents, il y a passage au premier noeud 124 avec appel à la couche système et passage à une étape 125 d'allumage de la lampe d'alarme avant un retour au noeud initial 121.
La Figure 10 représente le graphe de contrôle correspondant à l'organigramme de la figure 9, avec les noeuds et arcs autorisés.
Dans l'exemple considéré, les délais alloués pour effectuer les opérations "acquérir v", "calculer t(v)", "envoyer message", "éteindre", "allumer", respectivement aux étapes 112, 115, 118, 123 et 125 sont les suivants :
acquérir v : 1 unité de temps
"calculer t(v)" : 2 unités de temps supplémentaires "envoyer message" 1 unité de temps, mais le message sera disponible dans 2 unités de temps
"éteindre" : 1 unité de temps "allumer" : 1 unité de temps.
On indiquera ci-dessous pour chaque noeud de chacune des deux tâches le service rendu pour la couche système, et les opérations effectuées sur les dates d(i) de début au plus tôt et les dates f(i) de fin au plus tard (avec initialement d(0) = 0 et f(0) = 1 ) ainsi que sur la date dV de visibilité des messages.
Noeud Service rendu par la Opérations effectuées couche système sur d(i), f(i) et dV
(Tâche de traitement) Noeud initial III - attendre la fin du délai f(i+1 ) = f(i)+1 ; fixé précédemment d(i+1) = f(i)
- ajuster ensuite le nouveau délai
Ier noeud 114 - ajuster le nouveau délai f(i+1 ) = f(i)+2 ; d(i+1 ) = d(i)
2e noeud 117 - attendre la fin du délai f(i+1) = f(i) + 1 ; fixé précédemment d(i+1 ) = f(i)
- ajuster ensuite le nouveau délai
3e noeud 118 - copier le message dans f(i+1 ) = f(i) ; la zone d'émission du d(i+1) = d(i) prolongement du contexte dV = d(i) + 2 de la tâche dans la couche système
(Tâche d'alarme) Noeud initial 121 - attendre la fin du délai f(i+1 ) = f(i) + 1 fixé précédemment d(i+1) = f(i)
- ajuster ensuite le nouveau délai
- copier depuis la zone d'émission de la tâche de traitement les messages visibles dans la zone de réception du prolongement du contexte de la tâche dans la couche système
r noeud 124 - marquer, dans la zone f(i+1 ) = f(i) de réception du d(i+1 ) = d(i) prolongement du contexte de la tâche dans la couche système, que le premier message est consommé.
Les Figures 12 et 13 représentent respectivement pour la tâche de traitement et la tâche d'alarme de l'exemple considéré, des tables des noeuds comportant les descriptions des opérations à effectuer sur la date d(i) de début au plus tôt, la date f(i) de fin au plus tard et sur la date dV de visibilité.
Les graphes de contrôle de la tâche de traitement et de la tâche d'alarme peuvent être codés sous forme matricielle de la façon suivante :
Noeud 0 1 2 3
M = (2) (tâche de traitement)
Noeud 0 1
0 'A AN
M | (3) (tâche d'alarme)
1 I
où my = A si le déplacement du noeud i au noeud j est autorisé, et my = I, si le déplacement du noeud i au noeud j est interdit.
La figure 11 illustre sous forme de chronogramme un exemple de mise en oeuvre des deux tâches communicantes décrites ci-dessus en faisant apparaître les valeurs temporelles associées. Les chiffres de 1 à 10 désignent
l'heure réelle en nombre d'unités de temps depuis le début du fonctionnement en mode cadencé par le temps.
Un seul et unique type de message est stocké dans une file de messages donnée. Une date dV de visibilité du message est associée à chaque message envoyé. La date dV précise l'instant futur à partir duquel le destinataire peut consommer le message. Les consommations de messages s'effectuent par ordre de date de visibilité dV, puis par nom d'émetteur et enfin par ordre d'émission, ce qui permet d'ordonner totalement les messages en vue de leur consommation. Pour chaque file de message, il existe une zone d'émission dans le contexte de chaque émetteur et une zone de réception pour le propriétaire de la file de messages concernée.
Chaque producteur (émetteur) ayant une zone d'émission, il n'existe pas de problèmes de conflit entre deux expéditions de message par deux tâches différentes.
Par ailleurs, comme on l'a déjà indiqué plus haut, la segmentation mémoire permet de limiter l'impact des défaillances d'une tâche à son espace mémoire propre. La propagation d'une défaillance d'une tâche aux autres tâches de l'application est alors impossible. L'utilisation de la segentation mémoire permet d'autre part d'obtenir la propriété suivante : au sein d'un intervalle de temps du cadencement par le temps (TT) d'une tâche, le contexte d'exécution de cette tâche est invariant entre le début d'une nouvelle instruction et la fin de celle qui le précédait.
La segmentation mémoire est appliquée à la couche système elle-même afin de la cloisonner en interne ainsi que pour cloisonner le micro-noyau du reste de la couche système.
L'unité de protection mémoire 16 constitue le mécanisme matériel qui permet de vérifier que la segmentation mémoire est effectivement mise en oeuvre du point de vue de l'architecture physique. La Figure 2 représente la répartition en profondeur du code engendré depuis le niveau de l'application avec mode d'exécution utilisateur 201 ou mode
non privilégié jusqu'au micro-noyau 203 en passant par la couche système 202, avec mode d'exécution privilégié.
L'accès à la couche système 202 avec un mode d'exécution privilégié est protégé par une instruction de dérivation du type "trap" tandis que le passage de la couche système 202 au micro-noyau 203 est engendré par une instruction du type mouvement.
L'horloge 14 assure le cadencement par le temps et émet un signal d'interruption horloge sh lorsqu'une quantité programmable de temps s'est écoulée. Sur la Figure 2, on voit donc au niveau applicatif 201 le code et les données des différentes tâches tandis qu'au niveau de la couche système 202 on trouve d'une part les prolongements des contextes des tâches dans la couche système et d'autre part le code de la couche système. Au niveau du micro-noyau 213, on trouve les données et le code du micro-noyau pour la gestion de l'allocation du processeur aux tâches, et la gestion du temps.
On donnera maintenant en référence. à la figure 14 une table détaillée des droits des différents segments dans le cas d'un exemple de mise en oeuvre du procédé de sécurisation selon l'invention avec mémoire segmentée.
Comme on l'a déjà vu, une application multitâche comprend un code spécifique, des tâches, des flots de variables temporelles, des boîtes à messages, une couche système assurant les transferts d'information entre tâches, un exécuteur de graphe contrôlant les déplacements des tâches dans le code applicatif et un micro-noyau assurant la gestion du temps et le partage du processeur. La mémoire est découpée en segments ayant des droits d'accès dépendant du contexte d'exécution du processeur.
Pour comprendre le tableau de la figure 14, on donne les définitions suivantes :
. inst : ensemble d'instructions consécutives en mémoire ;
. const :ensemble de données consécutives de valeur constante ;
. var : ensemble de données consécutives modifiables par des instructions ;
I : droit d'exécuter les instructions du segment ;
M : droit de modifier et de consulter le segment ;
C : le droit d'accès au segment est limité à la consultation ;
R : l'accès au segment est refusé.
Les segments sont regroupés en zones selon qu'ils sont spécifiques de l'application ou liés au modèle selon l'invention sur le calculateur 10 avec son processeur.
Pour chaque tâche, on a des zones d'application successives CT, FT, BM, ME, VT et PU. La description de ces zones d'application est la suivante :
zone CT de calcul de la tâche :
. const et .var : les données de la tâche, dont la pile en mode non privilégié ;
. inst : les calculs de la tâche
Zone FT de fonctionnement de la tâche :
. const : la description du fonctionnement de la tâche (graphe d'exécution, description des noeuds, échéances, majorants des temps de calcul par l'unité centrale de calcul,...) ;
. var : la zone de passage d'arguments vers la couche système ; . inst : les fonctions de demande de changement de noeud auprès de la couche système.
Zone BM de boîte à messages :
. const : les caractéristiques de chaque boîte à messages de la tâche y compris les liaisons aux zones d'émission (zones ME) ;
. var : l'ensemble des messages accessibles à l'instant courant par la tâche.
Zone ME de stockage de messages :
. const : la description des zones de stockages des messages émis par la tâche et non visibles des tâches destinataires ; . var : les zones de stockages elle-même.
Zone VT de variables temporelles :
. const. La description des zones de stockage pour la tâche, des valeurs des flots de variables temporelles visibles par la tâche y compris les liaisons aux zones du producteur des valeurs ; . var : les zones de stockage pour la tâche des valeurs passées visibles.
Zone PU :
. var : les données temporaires de travail nécessaires au processeur, le contexte courant de la tâche, la pile en mode privilégié.
On a également une zone Globale d'application commune aux tâches, dont la description est la suivante :
Zone G globale : . const : la description des constantes globales de l'application (nombre de tâches, références des descripteurs de tâches, description des horloges...) et les constantes d'interface avec la couche système.
La couche système comprend elle-même une zone CS dont la description est la suivante :
Zone CS de la couche système : . const : pour mémoire ;
. var : vide (le passé est stocké dans le segment .var de la zone PU) ; . inst : les instructions de l'exécuteur de graphe, de la gestion des boîtes à messages, de la mise à disposition des valeurs passées des flots de variables temporelles et les instructions de gestion des horloges et de calcul des échéances.
La description de la zone TR de transfert commune à la couche système est la suivante :
Zone TR de transfert : . const : pour mémoire ; . var : l'identification de la tâche active
. inst : les instructions de changement des droits d'accès à la mémoire par le matériel et de branchement dans la couche système ou le micro-noyau.
Le micro-noyau comprend des zones MN et RS dont la description est la suivante :
Zone MN : .const : pour mémoire ;
.var : les données nécessaires à la gestion du matériel (gestion du temps, gestion des instructions "trap"...) ;
.inst : les instructions de gestion des ensembles de tâches prêtes ou au repos en fonction des échéances, de sauvegarde et de changement du contexte matériel, de gestion de l'interruption horloge pour droit d'utilisation du processeur épuisé et de mise en fonction de la protection mémoire disponible sur le calculateur.
Zone RS : .const : pour mémoire ; .var : vide ;
.inst : les instructions d'initialisation du calculateur et du logiciel qui s'exécutent sans protection de la mémoire.
A un instant donné, le processeur exécute des instructions soit pour le compte d'une tâche dans le code applicatif (en mode non privilégié), soit pour une tâche dans la couche système (en mode privilégié), soit dans le micronoyau.
Le tableau de la Figure 14 présente en ligne les segments d'une tâche, puis ceux de la couche système et enfin ceux du micro-noyau, tels que définis ci-dessus. Les colonnes représentent les droits d'accès à la mémoire selon que le processeur exécute des instructions du code d'application de la tâche
(colonne 301), du code de la couche système pour la tâche (colonne 302), du code de la couche système pour une autre tâche (colonne 303), du code pour le micro-noyau après initialisation du calculateur (colonne 304).
En général, la mémoire peut être découpée en pages et une page peut être protégée en écriture ou absente ou disponible. Dans cette situation, la taille des segments sera arrondie à un multiple de la page, .const et .var seront fusionnés et protégés en écriture, et les pages de droits R seront soit absentes, soit ôtées de la description.
Claims
1. Procédé de sécurisation rendant déterministe l'exécution en temps réel d'applications multitâches du type contrôle-commande dans un système de contrôle comprenant :
- au moins une première horloge (14) qui émet un signal d'interruption (sh) lorsqu'une quantité de temps réglable s'est écoulée,
- une unité centrale de calcul (10) avec au moins un processeur pouvant recevoir au moins ledit signal d'interruption d'horloge (sh),
- une mémoire principale (12, 13), et
- un ensemble de contrôleurs (1 ι à 1 [sj) de périphérique (1 à N) pour la gestion d'entrées-sorties du système de contrôle, procédé caractérisé en ce qu'il comprend les étapes suivantes : a) mémoriser, pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle nécessitant un appel à une couche système, ces enchaînements se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système du système de contrôle, b) mémoriser, pour chaque noeud du graphe de contrôle de chaque tâche, la nature de l'appel à la couche système et ses paramètres d'appel, y compris des paramètres temporels qui permettent les mises à jours de dates d(i) de "début au plus tôt" et de dates f(i) de "fin au plus tard", c) mémoriser, pour chaque tâche, un noeud initial (Noeud 0) dans le graphe associé, d) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, pour chaque tâche, le noeud initial (Noeud 0) et l'instant initial représentant l'état initial de la tâche considérée, e) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps l'ordre de départ de chacune des tâches en effectuant un pré-ordonnancement des listes des tâches au niveau d'un micro-noyau atomique, f) armer la première horloge (14) pour émettre le signal d'interruption d'horloge (sh) constituant un appel au micro-noyau, au premier instant de l'application pour le démarrage de l'exécution de cette application en mode cadencé par le temps, g) en cours de fonctionnement normal après armement de la première horloge (14), provoquer le désarmement de la première horloge (14) par le micro-noyau à chaque appel au micro-noyau ; lors d'un appel au micronoyau par la couche système ou par le traitement du signal d'interruption (sh), faire passer le micro-noyau à l'étape de mise à jour des listes des tâches de façon ordonnée selon les caractéristiques temporelles des tâches, à savoir leur date d(i) de début au plus tôt et leur date f(i) de fin au plus tard ; faire calculer au micro-noyau, après la mise à jour des listes, le plus petit instant futur où une tâche devra être réveillée et faire armer la première horloge (14) par le micronoyau, à partir de ce plus petit instant futur, pour réveiller ladite tâche et sortir du micro-noyau, h) lors de l'exécution d'une tâche, effectuer un appel à la couche système seulement lorsqu'un noeud du graphe de contrôle de ladite tâche est atteint, en passant comme argument le numéro du noeud ; procéder à un contrôle, lors de l'entrée dans la couche système, pour vérifier si, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, afin de lancer au niveau de la couche système le traitement d'une anomalie si ledit enchaînement n'est pas autorisé et de poursuivre l'exécution si ledit enchaînement est autorisé, effectuer la mise à jour des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard à l'aide d'appels au micro-noyau par la couche système et poursuivre normalement l'exécution de la tâche en cours jusqu'à ce que celle-ci atteigne à nouveau un noeud de son graphe de contrôle.
2. Procédé de sécurisation selon la revendication 1 , caractérisé en ce qu'il est appliqué à un système de contrôle comprenant en outre une unité de protection mémoire (16) pour le contrôle des droits d'accès d'adressage, laquelle unité de protection mémoire (16), à partir d'une adresse demandée (ad) fournie par l'unité centrale de calcul (10) et de droits (C) d'accès des contextes d'exécution du processeur sur l'espace mémoire adressable, produit de manière exclusive une adresse validée (av) qui permet l'accès ou bien émet en direction de l'unité centrale de calcul (10) un signal d'exception (se) d'adressage non autorisé, et en ce qu'il comprend en outre les étapes suivantes : i) lors d'une phase de préparation, mémoriser pour une application donnée, les droits d'accès à chacun des segments mémoire pour le micronoyau et pour chaque tâche de l'application et son prolongement dans la couche système de manière à constituer des premier et deuxième contextes d'exécution selon que les instructions se trouvent dans le code propre à l'application constituant la tâche ou que ces instructions se trouvent dans le code générique de la couche système constituant le prolongement de la tâche dans la couche système, j) pour une application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps, initialiser le contexte du micro-noyau et les premier et deuxième contextes d'exécution pour chaque tâche et pour son prolongement dans la couche système, k) lors de l'exécution d'une tâche, effectuer un appel à la couche système à l'aide d'une instruction de passage dans un mode d'exécution privilégié qui permet de passer du contexte d'exécution de la tâche au contexte d'exécution de son prolongement dans la couche système, et après avoir contrôlé que l'enchaînement à partir du noeud correspondant au précédent appel système est autorisé, et après mise à jour des paramètres temporels de la tâche à l'aide d'appels au micro-noyau par la couche système, retourner dans le code de la tâche à l'aide d'une instruction de retour dans le mode non- privilégié qui permet de passer du contexte d'exécution du prolongement dans la couche système au contexte d'exécution de la tâche.
3. Procédé selon la revendication 2, caractérisé en ce que les contextes d'exécution de chaque tâche de l'application sont deux à deux disjoints.
4. Procédé selon la revendication 2 ou la revendication 3, caractérisé en ce que les prolongements des contextes d'exécution des tâches de l'application dans la couche système ne sont pas accessibles en écriture aux contextes d'exécution des tâches avec le code de l'application.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le codage du graphe de contrôle d'une tâche interdit toute défaillance de cause commune entre le mécanisme de contrôle d'exécution d'une tâche quelconque de l'application et l'exécution de cette tâche elle-même.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend en outre les étapes suivantes :
I) lors d'une phase de préparation, mémoriser pour une application donnée, pour tous les enchaînements autorisés dans chaque tâche, un quota de temps constituant un majorant du temps d'exécution maximum nécessaire pour passer d'un noeud à l'autre dans le graphe de contrôle de la tâche, chacun de ces quotas de temps englobant le temps passé dans l'exécution des instructions propres de la tâche, mais aussi le temps passé dans l'exécution du code générique de la couche système en prolongement de la tâche, m) en cours de fonctionnement normal après armement de la première horloge (14), lors d'un appel au micro-noyau déclenché par le signal (sh) d'interruption sur le temps et provoquant le désarmement de la première horloge (14), procéder à un contrôle pour vérifier si le signal (sh) d'interruption sur le temps déclenchant l'appel au micro-noyau est lié à une tentative de violation d'un quota de temps, et si c'est le cas faire lancer par le micro-noyau le traitement de l'anomalie tandis que si le signal (sh) d'interruption sur le temps n'est pas lié à une tentative de violation d'un quota de temps, faire passer le micro-noyau à l'étape de mise à jour des listes de tâches et, après cette mise à jour des listes des tâches, faire calculer au micro-noyau d'une part le plus petit instant futur où une tâche devra être réveillée et d'autre part l'instant futur à partir duquel le quota de temps imparti à la tâche en exécution à la sortie du micro-noyau, déterminée lors de la mise à jour des listes, sera épuisé, et faire armer la première horloge (14) par le micro-noyau au plus petit de ces instants futurs pour, selon le cas, soit réveiller la tâche, soit détecter une tentative de violation de quota de temps révélant une anomalie de fonctionnement, et sortir du micro-noyau après armement de la première horloge (14).
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'une deuxième horloge (15) est mise en œuvre et en ce que l'on fait accéder le micro-noyau à cette deuxième horloge (15) pour contrôler, par comparaison des signaux de temps, l'écoulement du temps cadencé par la première horloge (14).
8. Procédé de sécurisation selon l'une quelconque des revendications 1 à 7, rendant déterministe l'exécution en temps réel d'applications multitâches communicantes de type contrôle-commande, caractérisé en ce qu'il comprend en outre les étapes suivantes : n) lors d'une phase de préparation, mémoriser pour chacune des tâches d'une application donnée tous les enchaînements autorisés de ses points de synchronisation temporelle et de communication avec les autres tâches de l'application nécessitant un appel à la couche système, ces enchaînements autorisés se traduisant par un graphe de contrôle de l'exécution d'appels à la couche système de la tâche considérée, chaque graphe comportant un ensemble de noeuds correspondant chacun à un appel à la couche système, o) mémoriser chaque zone tampon nécessaire à un échange de données entre tâches, en indiquant sa taille, la taille des éléments qu'elle contient, son emplacement ou adresse de base, ainsi que les relations entre les zones tampons permettant de valider les transferts d'informations nécessaires aux communications, p) mémoriser pour chaque zone tampon les valeurs initiales de ses éléments, q) initialiser, pour l'application donnée et préalablement au démarrage de l'exécution temps réel selon un mode de fonctionnement cadencé par le temps les valeurs des éléments de la zone tampon avec les valeurs précédemment mises en mémoire, r) lors de l'exécution d'une tâche, lors d'un appel à la couche système lorsqu'un noeud du graphe de contrôle de la tâche est atteint et après vérification que, selon le graphe de contrôle de la tâche en cours d'exécution, l'enchaînement à partir du noeud correspondant au précédent appel à la couche système est autorisé, effectuer des mises à jour successives des zones tampons en fonction de la nature de l'appel précédemment mémorisé et des mises à jour incrémentales et nécessaires des paramètres temporels de la tâche en cours d'exécution comprenant la date d(i) de début au plus tôt et la date f(i) de fin au plus tard.
9. Procédé selon les revendications 2 et 8, caractérisé en ce que, au niveau de la couche système, on autorise le partage des seule zones tampons par les prolongements des contextes d'exécution des tâches d'une application, une zone tampon donnée pour les communications dynamiques correspondant à l'envoi de messages ne pouvant être partagée que par deux prolongements de contextes d'exécution d'une tâche, tandis qu'une zone tampon donnée pour les communications statiques correspondant à un flot de données datées peut être partagée par plus de deux prolongements de contextes d'exécution d'une tâche mais ne peut toujours être écrite ou modifiée que par un seul contexte.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il est appliqué à un système de contrôle-commande d'un niveau de classe de sûreté 1 E pour un réacteur nucléaire.
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/416,564 US7299383B2 (en) | 2000-11-13 | 2001-11-13 | Security method making deterministic real time execution of multitask applications of control and command type with error confinement |
| AU2002220777A AU2002220777A1 (en) | 2000-11-13 | 2001-11-13 | Security method making deterministic real time execution of multitask applications of control and command type with error confinement |
| EP01993873A EP1337919B1 (fr) | 2000-11-13 | 2001-11-13 | Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur |
| CA002428467A CA2428467C (fr) | 2000-11-13 | 2001-11-13 | Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur |
| JP2002541533A JP3921447B2 (ja) | 2000-11-13 | 2001-11-13 | エラーを抑制して制御・コマンド型のマルチタスクアプリケーションを決定論的に実時間で実行するセキュリティ方法 |
| DE60127857T DE60127857T2 (de) | 2000-11-13 | 2001-11-13 | Sicherheitsverfahren mit deterministischer echtzeit-ausführung von multitask-anwendungen des steuer- und befehlstyps mit fehlereingrenzung |
| KR1020037006432A KR100837787B1 (ko) | 2000-11-13 | 2001-11-13 | 에러제한을 가진 제어 및 명령타입의 다중테스크 응용을위한 결정적 실시간 실행을 만드는 보안방법 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0014555A FR2816730B1 (fr) | 2000-11-13 | 2000-11-13 | Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle- commande avec confinement d'erreur |
| FR00/14555 | 2000-11-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2002039277A1 true WO2002039277A1 (fr) | 2002-05-16 |
Family
ID=8856366
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2001/003532 WO2002039277A1 (fr) | 2000-11-13 | 2001-11-13 | Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur |
Country Status (13)
| Country | Link |
|---|---|
| US (1) | US7299383B2 (fr) |
| EP (1) | EP1337919B1 (fr) |
| JP (1) | JP3921447B2 (fr) |
| KR (1) | KR100837787B1 (fr) |
| CN (1) | CN1282079C (fr) |
| AT (1) | ATE359549T1 (fr) |
| AU (1) | AU2002220777A1 (fr) |
| CA (1) | CA2428467C (fr) |
| DE (1) | DE60127857T2 (fr) |
| ES (1) | ES2284725T3 (fr) |
| FR (1) | FR2816730B1 (fr) |
| RU (1) | RU2285947C2 (fr) |
| WO (1) | WO2002039277A1 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8196178B2 (en) | 2005-10-05 | 2012-06-05 | Microsoft Corporation | Expert system analysis and graphical display of privilege elevation pathways in a computing environment |
| FR2993070A1 (fr) * | 2012-07-09 | 2014-01-10 | Commissariat Energie Atomique | Procede d'execution, au sein d'un systeme embarque multitaches, d'une application cadencee par plusieurs domaines de temps differents incluant une gestion d'interruptions |
| WO2014170569A1 (fr) | 2013-04-19 | 2014-10-23 | Krono-Safe | Procédé d'allocation temporelle de tâches permettant une récupération d'erreur deterministe en temps réel |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263598B2 (en) * | 2002-12-12 | 2007-08-28 | Jack Robert Ambuel | Deterministic real time hierarchical distributed computing system |
| US7689782B1 (en) * | 2003-08-04 | 2010-03-30 | Azul Systems, Inc. | Processor instruction used to determine whether to perform a memory-related trap |
| US8108628B2 (en) * | 2003-08-04 | 2012-01-31 | Azul Systems, Inc. | Processor instruction used to perform a matrix test to generate a memory-related trap |
| EP1522923A3 (fr) * | 2003-10-08 | 2011-06-22 | STMicroelectronics SA | Architecture de processeur à plusieurs contextes d'exécution simultanés |
| US8793602B2 (en) * | 2004-01-15 | 2014-07-29 | The Mathworks, Inc. | System and method for scheduling the execution of model components using model events |
| US8683426B2 (en) | 2005-06-28 | 2014-03-25 | The Mathworks, Inc. | Systems and methods for modeling execution behavior |
| US9070104B2 (en) * | 2004-11-12 | 2015-06-30 | Sap Se | Cross-context task management |
| CN100361081C (zh) * | 2005-01-18 | 2008-01-09 | 华为技术有限公司 | 处理多线程/多任务/多处理器的方法 |
| ATE535877T1 (de) * | 2005-10-20 | 2011-12-15 | Sap Ag | Gesteuerte pfadbasierte prozessausführung |
| JP2007133807A (ja) * | 2005-11-14 | 2007-05-31 | Hitachi Ltd | データ処理システム、ストレージ装置及び管理装置 |
| JP4609381B2 (ja) * | 2006-06-14 | 2011-01-12 | 株式会社デンソー | 異常監視用プログラム、記録媒体及び電子装置 |
| CN101266553B (zh) * | 2008-05-06 | 2010-06-02 | 无锡紫芯集成电路系统有限公司 | 基于嵌入式系统的多任务管理方法 |
| US7921195B2 (en) * | 2008-06-09 | 2011-04-05 | International Business Machines Corporation | Optimizing service processing based on business information, operational intelligence, and self-learning |
| FR2937439B1 (fr) * | 2008-10-17 | 2012-04-20 | Commissariat Energie Atomique | Procede d'execution deterministe et de synchronisation d'un systeme de traitement de l'information comportant plusieurs coeurs de traitement executant des taches systemes. |
| CN101853181A (zh) * | 2010-05-11 | 2010-10-06 | 中达电通股份有限公司 | 用于嵌入式系统的子程序相互调用的方法 |
| US8639809B2 (en) * | 2010-08-20 | 2014-01-28 | International Business Machines Corporation | Predictive removal of runtime data using attribute characterizing |
| CN102339029B (zh) * | 2011-06-30 | 2013-03-06 | 电子科技大学 | 一种嵌入式操作系统定时保护的实现方法 |
| US8850557B2 (en) | 2012-02-29 | 2014-09-30 | International Business Machines Corporation | Processor and data processing method with non-hierarchical computer security enhancements for context states |
| US8707316B1 (en) * | 2012-01-05 | 2014-04-22 | The Boeing Company | Methods and systems for mission-driven quality of service management |
| US9529614B2 (en) * | 2012-03-05 | 2016-12-27 | Board Of Regents The University Of Texas Systems | Automatically bridging the semantic gap in machine introspection |
| US20130290315A1 (en) * | 2012-04-30 | 2013-10-31 | Iac Search & Media, Inc. | Method and system of using an access control for temporarily overriding call number for representations |
| FR2990782B1 (fr) * | 2012-05-15 | 2015-06-26 | Sagem Defense Securite | Procede de gestion d'une execution de taches dans un systeme informatique |
| US8869148B2 (en) * | 2012-09-21 | 2014-10-21 | International Business Machines Corporation | Concurrency identification for processing of multistage workflows |
| FR3004274A1 (fr) | 2013-04-09 | 2014-10-10 | Krono Safe | Procede d'execution de taches dans un systeme temps-reel critique |
| CN103984277B (zh) * | 2014-05-26 | 2016-08-24 | 保定迈卓医疗器械有限公司 | 全数字化制氧机监测控制系统 |
| CN104980224A (zh) * | 2015-05-05 | 2015-10-14 | 电子科技大学 | Fc-ae-1553数据交换模式设计、网络控制及节能方法 |
| US10635831B1 (en) * | 2018-01-06 | 2020-04-28 | Ralph Crittenden Moore | Method to achieve better security using a memory protection unit |
| US20220078199A1 (en) * | 2020-09-09 | 2022-03-10 | Spyderbat, Inc. | Security event connectivity generated by linking enitities and actions from process tracking |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2771828A1 (fr) * | 1997-12-03 | 1999-06-04 | Sextant Avionique | Procede de securisation pour un calculateur |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4589093A (en) * | 1983-03-28 | 1986-05-13 | Xerox Corporation | Timer manager |
| FR2766592B1 (fr) * | 1997-07-23 | 1999-08-27 | Bull Sa | Dispositif et procede de regulation dynamique de l'attribution des ressources sur un systeme informatique |
-
2000
- 2000-11-13 FR FR0014555A patent/FR2816730B1/fr not_active Expired - Fee Related
-
2001
- 2001-11-13 AU AU2002220777A patent/AU2002220777A1/en not_active Abandoned
- 2001-11-13 CA CA002428467A patent/CA2428467C/fr not_active Expired - Lifetime
- 2001-11-13 AT AT01993873T patent/ATE359549T1/de not_active IP Right Cessation
- 2001-11-13 DE DE60127857T patent/DE60127857T2/de not_active Expired - Lifetime
- 2001-11-13 RU RU2003113302/09A patent/RU2285947C2/ru active
- 2001-11-13 ES ES01993873T patent/ES2284725T3/es not_active Expired - Lifetime
- 2001-11-13 KR KR1020037006432A patent/KR100837787B1/ko active IP Right Grant
- 2001-11-13 JP JP2002541533A patent/JP3921447B2/ja not_active Expired - Lifetime
- 2001-11-13 US US10/416,564 patent/US7299383B2/en active Active
- 2001-11-13 WO PCT/FR2001/003532 patent/WO2002039277A1/fr active IP Right Grant
- 2001-11-13 CN CNB018211259A patent/CN1282079C/zh not_active Expired - Lifetime
- 2001-11-13 EP EP01993873A patent/EP1337919B1/fr not_active Expired - Lifetime
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2771828A1 (fr) * | 1997-12-03 | 1999-06-04 | Sextant Avionique | Procede de securisation pour un calculateur |
Non-Patent Citations (4)
| Title |
|---|
| ASPELUND J ET AL: "A fault tolerant multimicroprocessor operating system modeled with locality Petri nets", IMPLEMENTING FUNCTIONS: MICROPROCESSORS AND FIRMWARE. SEVENTH EUROMICRO SYMPOSIUM ON MICROPROCESSING AND MICROPROGRAMMING, PARIS, FRANCE, 8 September 1981 (1981-09-08) - 10 September 1981 (1981-09-10), Amsterdam, Netherlands, North-Holland, Netherlands, pages 63 - 70, XP000745703, ISBN: 0-444-86282-X * |
| AUSSAGUES C ET AL: "Guaranteeing timeliness in safety critical real-time systems", DISTRIBUTED COMPUTER CONTROL SYSTEMS 1998 (DCCS'98) PROCEEDINGS VOLUME FROM THE 15TH IFAC WORKSHOP, PROCEEDINGS OF THE 15TH IFAC WORKSHOP ON DISTRIBUTED COMPUTER CONTROL SYSTEMS 1998, COMO, ITALY, 9 September 1998 (1998-09-09) - 11 September 1998 (1998-09-11), Kidlington, UK, Elsevier Science, UK, pages 83 - 89, XP002176734, ISBN: 0-08-043242-5 * |
| AUSSAGUES C ET AL: "Vérification de propriétés de sûreté dans le modèle OASIS pour les applications temps réel critiques", RTS '97 SALON DES SOLUTIONS POUR LES SYSTEMES TEMPS REEL ET LES APPLICATIONS ENFOUIES (RTS '97: REAL TIME SYSTEMS AND EMBEDDED APPLICATIONS), 1997, Toulouse, France, Teknea, France, pages 145 - 164, XP001025562, ISBN: 2-87717-059-4 * |
| DAVID V ET AL: "Safety properties ensured by the OASIS model for safety critical real-time systems", COMPUTER SAFETY, RELIABILITY AND SECURITY. 17TH INTERNATIONAL CONFERENCE, SAFECOMP'98. PROCEEDINGS, PROCEEDINGS OF 17TH INTERNATIONAL CONFERENCE ON COMPUTER SAFETY, RELIABILITY AND SECURITY, HEIDELBERG, GERMANY, 5 October 1998 (1998-10-05) - 7 October 1998 (1998-10-07), Berlin, Germany, Springer-Verlag, Germany, pages 45 - 59, XP002176733, ISBN: 3-540-65110-1 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8196178B2 (en) | 2005-10-05 | 2012-06-05 | Microsoft Corporation | Expert system analysis and graphical display of privilege elevation pathways in a computing environment |
| FR2993070A1 (fr) * | 2012-07-09 | 2014-01-10 | Commissariat Energie Atomique | Procede d'execution, au sein d'un systeme embarque multitaches, d'une application cadencee par plusieurs domaines de temps differents incluant une gestion d'interruptions |
| WO2014009213A1 (fr) | 2012-07-09 | 2014-01-16 | Commissariat A L'energie Atomique Et Aux Energies Alternatives | Procede d'execution, au sein d'un systeme embarque multitaches, d'une application cadencee par plusieurs domaines de temps differents incluant une gestion d'interruptions |
| US9785587B2 (en) | 2012-07-09 | 2017-10-10 | Commissariat A L'energie Atomique Et Aux Energies Alternatives | Method for executing, within a multitasking onboard system, an application timed according to a plurality of different time domains including interruption management |
| WO2014170569A1 (fr) | 2013-04-19 | 2014-10-23 | Krono-Safe | Procédé d'allocation temporelle de tâches permettant une récupération d'erreur deterministe en temps réel |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2816730A1 (fr) | 2002-05-17 |
| AU2002220777A1 (en) | 2002-05-21 |
| EP1337919B1 (fr) | 2007-04-11 |
| US20040078547A1 (en) | 2004-04-22 |
| CN1488097A (zh) | 2004-04-07 |
| US7299383B2 (en) | 2007-11-20 |
| FR2816730B1 (fr) | 2004-10-15 |
| CN1282079C (zh) | 2006-10-25 |
| ATE359549T1 (de) | 2007-05-15 |
| JP2004535607A (ja) | 2004-11-25 |
| JP3921447B2 (ja) | 2007-05-30 |
| RU2285947C2 (ru) | 2006-10-20 |
| CA2428467A1 (fr) | 2002-05-16 |
| ES2284725T3 (es) | 2007-11-16 |
| KR20030063378A (ko) | 2003-07-28 |
| EP1337919A1 (fr) | 2003-08-27 |
| KR100837787B1 (ko) | 2008-06-13 |
| CA2428467C (fr) | 2008-09-23 |
| DE60127857T2 (de) | 2007-12-20 |
| DE60127857D1 (de) | 2007-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1337919B1 (fr) | Procede de securisation rendant deterministe l'execution en temps reel d'applications multitaches du type controle-commande avec confinement d'erreur | |
| EP0030504B1 (fr) | Dispositif de synchronisation et d'affectation de processus entre plusieurs processeurs dans un système de traitement de l'information | |
| EP0536010B1 (fr) | Procédé et dispositif pour la gestion temps réel d'un système comprenant au moins un processeur apte à gérer plusieurs fonctions | |
| EP3295293B1 (fr) | Opérations d'écriture concurrentes sans verrou à fil sécurisé destinées à être utilisées avec une journalisation en ligne multifil | |
| EP3123344B1 (fr) | Procede de transfert de donnees entre taches temps reel utilisant un controleur memoire dma | |
| US9817771B2 (en) | Guarded memory access in a multi-thread safe system level modeling simulation | |
| FR2677474A1 (fr) | Dispositif permettant d'accroitre les performances d'un noyau d'executif temps reel associe a une structure multiprocesseur pouvant comprendre un nombre eleve de processeurs. | |
| US20150058859A1 (en) | Deferred Execution in a Multi-thread Safe System Level Modeling Simulation | |
| US9201708B2 (en) | Direct memory interface access in a multi-thread safe system level modeling simulation | |
| EP1158405A1 (fr) | Système et méthode de gestion d'une architecture multi-ressources | |
| Bruyninckx | Real-time and embedded guide | |
| US20150193268A1 (en) | File lock and unlock mechanism | |
| EP1365323B1 (fr) | Procédé d'échange d'informations entre systèmes d'exploitation cohabitant sur un même ordinateur | |
| US20060150185A1 (en) | Hard real-time response | |
| WO2019117854A1 (fr) | Files d'attente d'événements de contrôleur | |
| EP0264317B1 (fr) | Dispositif pour l'optimalisation des performances de primitives temps réel d'un noyau d'exécutif temps réel sur des structures multiprocesseurs | |
| EP1410178B1 (fr) | Procede et systeme de gestion du temps dans un systeme temps reel | |
| Muyan‐Özçelik et al. | Methods for multitasking among real‐time embedded compute tasks running on the GPU | |
| Max | Operating Systems and Middleware: Supporting Controlled Interaction | |
| Brandenburg et al. | Joint Opportunities for Real-Time Linux and Real-Time Systems Research | |
| Zoor et al. | User-level scheduling mechanisms | |
| Williams | Modeling nondisclosure in terms of the subject-instruction stream | |
| Do | Performance Analysis of Interprocess Communication Mechanisms on Windows XP and Linux | |
| FR2687236A1 (fr) | Procede de realisation d'automates de gestion multitaches pour systemes de traitement de donnees. | |
| EP0569290A1 (fr) | Processeur de traitement d'informations de vol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ CZ DE DE DK DK DM DZ EC EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| WWE | Wipo information: entry into national phase |
Ref document number: 2002541533 Country of ref document: JP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2001993873 Country of ref document: EP Ref document number: 2428467 Country of ref document: CA Ref document number: 1020037006432 Country of ref document: KR |
|
| ENP | Entry into the national phase |
Ref document number: 2003113302 Country of ref document: RU Kind code of ref document: A Ref country code: RU Ref document number: RU A |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 018211259 Country of ref document: CN |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 10416564 Country of ref document: US |
|
| WWP | Wipo information: published in national office |
Ref document number: 1020037006432 Country of ref document: KR |
|
| WWP | Wipo information: published in national office |
Ref document number: 2001993873 Country of ref document: EP |
|
| REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
| WWG | Wipo information: grant in national office |
Ref document number: 2001993873 Country of ref document: EP |