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-coeur ou, à un instant donné, une seule tâche fonctionne. Or ces dernières années voient le développement des processeurs multicoeurs comme moyen principal de continuer la course à la puissance de calcul des processeurs. Il s'avère que les processeurs multicoeurs actuels ne permettent pas de garantir l'étanchéité de fonctionnement entre les différents coeurs. On ne peut pas garantir qu'une tâche s'exécutant sur un des coeurs et sujette à une défaillance ne puisse pas perturber le bon déroulement d'une autre tâche s'exécutant sur un autre coeur. 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 multicoeur. 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 coeurs 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 coeur de lancement de la tâche prévue en fonction des informations relatives reçues des autres coeurs. L'invention concerne un procédé de séquencement d'un ensemble de tâches sur un processeur disposant d'une pluralité de coeurs 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 coeur du processeur, le procédé étant exécuté par un ensemble de modules de séquencement implémenté sur les coeurs 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 oeuvre 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 coeur 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 coeurs 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 coeur 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 coeurs 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 coeur 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 coeur pour la partition courante ; - toute tâche de niveau de sécurité 2 présente sur un autre coeur 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 coeur pour la partition courante ; - toute tâche de niveau de sécurité 2 présente sur un autre coeur 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 coeur pour la partition courante ; - toute tâche de niveau de sécurité 3 présente sur un autre coeur 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 coeur 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 multicoeur.
La Fig. 3 illustre le fonctionnement du système, cadre de l'invention. La Fig. 4 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-coeur. Les tâches Ti, T2, T3 et T4 s'exécutent alternativement sur le coeur Cl. Le temps est divisé en intervalles de temps successifs I1 à I11. 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 oeuvre 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 multicoeur. Au sein d'un même composant, on dispose d'une pluralité d'unités de calculs, 2.11 à 2.14. Ces unités de calcul sont appelées les coeurs et disposent approximativement des mêmes capacités qu'un processeur mono-coeur traditionnel. Leur nombre varie entre deux et huit coeurs dans les processeurs proposés aujourd'hui, mais nul doute que leur nombre est appelé à augmenter dans les années à venir. Typiquement, ces coeurs 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 coeurs 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 oeuvre 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 coeurs du processeur. Par exemple, une tâche victime d'un dysfonctionnement sur l'un des coeurs 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 coeurs 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 oeuvre 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 coeur 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 coeurs du processeur. Ces coeurs 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, Pl à P11. On suppose que le processeur dispose de 4 coeurs Cl à C4. Pour chaque partition et chaque coeur, 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 coeur, 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 et 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 sécurité 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 coeurs du processeur. Ces modules 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 coeurs. Deux variantes d'implémentation peuvent être réalisées de cette instance de contrôle. Selon un premier mode de réalisation, dit mode centralisé, un module de séquencement sur l'un des coeurs est élu instance de contrôle. Ce module prend alors le nom de module de contrôle et communique avec les autres modules pour d'une part obtenir les informations nécessaires à sa prise de décision et d'autre part informer les autres modules des décisions prises. Selon un second mode de réalisation, dit mode réparti, chaque module de séquencement sur chaque coeur implémente le contrôle pour ses propres tâches. Tous les modules 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 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.
La Fig. 4 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 multicoeur. 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 coeurs 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 coeur. Chaque coeur 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 coeur 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 coeur. 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 coeur. 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 coeur pour la partition courante. - Toute tâche de niveau de sécurité 2 présente sur un autre coeur 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 coeur 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 coeur pour la partition courante. - Toute tâche de niveau de sécurité 2 présente sur un autre coeur 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 coeurs 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 coeur pour la partition courante. - Toute tâche de niveau de sécurité 3 présente sur un autre coeur 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 coeurs 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 coeurs. 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 coeurs. 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 coeur 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 coeur. 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 coeurs. 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 coeur 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.