FR2908909A1 - Procede de gestion d'une unite de calcul - Google Patents

Abstract

Procédé de gestion d'une unité de calcul (2, 102) réalisé pour contrôler au moins un appareil de commande (114, 116) selon lequel, sur l'unité de calcul (2, 102) on définit des droits d'accès (118, 120) réciproques entre les parties de programme (4, 6, 8, 106, 108, 110, 112) dans des mémoires relatives (5, 7, 9) d'origines différentes.

Description

1 Domaine de l'invention La présente invention concerne un procédé de

gestion d'une unité de calcul pour contrôler au moins un appareil de commande ; l'invention concerne également une telle unité de calcul et un programme d'ordinateur ainsi qu'un produit programme d'ordinateur. Etat de la technique Il est habituel pour les véhicules automobiles d'utiliser des parties de programme ou des codes programme pour une unité de calcul, c'est-à-dire pour un dispositif à microprocesseur ou un système à microprocesseur, en provenance de différents fabricants. Ces parties de programme sont ensuite combinées par un intégrateur de système pour donner un programme total qui fonctionne. Un tel système à microprocesseur peut servir par exemple à la commande ou gestion d'un moteur de véhicule automobile. Le programme global est ensuite chargé par le système à microprocesseur dans les mémoires en général persistantes. Les parties de programme des différents fabricants communiquent par des interfaces prédéfinies de manière fixe pour assurer la fonctionnalité globale prévue, du dispositif à microprocesseur. Ces parties de programme selon l'état de la technique sont mémorisées dans une mémoire flash et ne peuvent pas être modifiées. Des modèles de coopération tels que par exemple les projets ASAM (Association for Standardization of automation and Measuring Systems), MSR (Manufacturer Supplier Relationship) oder AUTOSAR (Automotive Open System Architecture), sont mémorisés et figés dans une mémoire flash et qui prévoient une coopération entre les fabricants et les fournisseurs dans l'industrie automobile. Les projets évoqués ci-dessus à titre d'exemple ont entre autre pour but, de fixer des interfaces standardisées pour les fonctionnalités de programme de façon qu'avec un tel standard, un constructeur automobile peut utiliser les composants de programme venant de différents fournisseurs, actuellement concurrents et les intégrer à son système global sans avoir à les adapter. Dans ces projets il est prévisible que l'on aura des effets d'interactions variables entre les différentes parties de programme venant de fabricants différents. 2908909 2 Dans les dispositifs actuels à microprocesseur les différentes parties de programme sont toutefois également en mesure d'influencer non seulement les interfaces définies, officielles, de manière intentionnelle ou non intentionnelle, le déroulement du programme de 5 n'importe quelle autre partie de programme et aussi des parties de pro-gramme d'autres fabricants. L'industrie automobile cherche pour cela d'éviter de telles influences gênantes entre autre par des lignes directrices standardisées, comme par exemple le standard MISRA. L'intégrateur de système pour un tel système de pro- 10 gramme fourni n'est toutefois pas en mesure, pour des raisons de propriété intellectuelle et de temps, d'effectuer un test fonctionnel complet de l'ensemble du système. De même, pout des raisons de droit de propriété intellectuelle, les fournisseurs ne distribuent que des composants de programmes exécutables sans fournir la source. Ainsi, en règle généraie l'intégrateur du système ne sait pas s'il peut exécuter un test fonctionnel complet. Cela signifie qu'il ne peut pas vérifier par exemple s'il a contrôlé le comportement de toutes les ramifications du code pro-gramme fourni dans leur comportement dans le contexte global. C'est pourquoi une couverture d'essai à 100 % n'est pas possible. 20 Même dans le cas où tous les fournisseurs mettent à dis-position la source des composants du programme, on ne pourrait faire une couverture d'essai totale car le travail de mise à l'échelle n'est pas possible en un temps fini puisque pour les programmes actuels ou les systèmes de programme il existe un nombre de possibilités de combi- 25 naisons tellement grand qu'un test complet nécessiterait un temps très long. Même si on se limitait à une configuration de programme, par exemple pour les valeurs d'entrée dans le système, notamment en tenant compte des aspects de durée, le nombre de possibilités de combinaisons à tester est très grand. 30 Même un test fonctionnel très détaillé effectué chez le fournisseur présente le risque qu'une fonction testée, intégrée dans le programme global, chez l'intégrateur de système, se comporte différemment de la phase de test chez le fournisseur. Cela peut résider par exemple dans ce que les conséquences d'un éventuel comportement er- roné ne sont pas les mêmes que dans le système global. Il peut même 2908909 3 arriver que les configurations testées par le fournisseur ne présentent pas de comportement défectueux mais que la configuration utilisée par l'intégrateur de système soit défectueuse dans le système global. Un comportement défectueux d'un premier composant de 5 programme d'un premier fournisseur qui est la conséquence d'un comportement défectueux d'un second composant de programme d'un second fournisseur est parfaitement envisageable et peut se traduire par des dommages personnels au cas où cela déclencherait un accident. Comme exemple rapporté à une application, il est prévu 10 d'intégrer dans une commande de moteur, deux implémentations concrètes de composants de programme, le premier composant de pro-gramme concernant la commande des lève-glace et un second composant de programme concernant dans le moteur, le calcul de la dose nécessaire à l'injection pour fournir un couple demandé. 15 Il peut arriver que dans les composants de programme pour la commande des lève-glace on rencontre un fonctionnement défectueux. De plus, dans la configuration décrite des composants de pro-gramme, le calcul de la dose à injecter par le système global peut être modifié de sorte que par suite d'une variation intentionnelle une posi- 20 tion de fenêtre se traduit par une augmentation de couple non voulue si bien que le véhicule accélère et peut provoquer un accident. Ce cas de défaut n'est pas à exclure même si l'on tient compte des mesures prescrites existantes. Déjà un calcul défectueux d'un index de champ peut générer un pointeur défectueux qui indique 25 un point quelconque de la mémoire, par exemple dans le domaine du calcul de la dose à injecter et peut conduire à des accès d'écriture. La directive de codage MISRA ne peut exclure un tel comportement défectueux car on utilise fréquemment les champs de données pour la programmation. 30 Il se pose ainsi la question sur le plan juridique de la responsabilité de l'intégrateur de système ou du fournisseur pour le dom-mage causé par le produit. Il faut tenir compte de ce que l'intégrateur du système n'est pas en mesure de tester la totalité du système. Le fournisseur dont le composant aura calculé une fausse augmentation 35 de quantité ne peut que difficilement assumer de l'extérieur, une telle 2908909 4 action défectueuse. De plus, le fournisseur dont le composant a effectué une modification non intentionnelle ne peut savoir dans quel système global concret sera utilisé son composant. Du point de vue technique, se pose le problème de la 5 preuve avant tout d'un tel fonctionnement défectueux temporaire. Habituellement, des défauts concrets ne se produisent que de façon limitée dans le temps et disparaissent, au plus tard lorsqu'on coupe l'appareil de commande. Pour prouver un tel défaut, de manière incontestable, il faudrait bloquer l'état complet de l'appareil de commande. Une reproduction d'un tel défaut est extrêmement difficile. Même si la reproduction devait être valable, elle prouverait seulement que ce défaut est possible mais non que le défaut reproduit a également été effectivement la cause de l'accident. Dans les systèmes de gestion actuels dans le domaine 15 des grappes serveurs (cluster) mais également dans le domaine des applications intégrées, on connaît pour cela des mécanismes de protection de mémoire. Ils interdisent de modifier des plages non autorisées. Les mécanismes de protection de mémoire sont implémentés différemment suivant le système de gestion et l'assistance par circuit. Par exemple à 20 l'aide d'une unité de carte de mémoire (MMU) disponible dans un circuit de processeur, le code à exécuter est copié ou enregistré dans une zone de mémoire virtuelle protégée. Dans certains systèmes de gestion, les plages de mémoire de différents procédés ou tâches sont verrouillées les unes par rapport 25 aux autres par l'utilisation de modes de fonctionnement assistés égale-ment par circuits et avec des droits d'accès différents. Dans le cas d'une tentative d'accès du code à exécuter en dehors de la plage attribuée, cela se traduit par des messages au système comme par exemple atteinte à la protection de l'écriture dans le module X . L'utilisateur a 30 ainsi la possibilité de terminer complètement le procédé déjà arrêté avec une propre entrée, par exemple OUI . Cette communication inter-procédés est en principe possible seulement par des fonctions du système de gestion. Cela signifie que les données d'un procédé A ne sont fournies à un autre procédé B 35 que par un dépôt intermédiaire. L'encapsulage demande toutefois des 2908909 5 ressources intensives dans le cas de grandes quantités de données car non seulement le déplacement de mémoire mais également la puissance de calcul pour copier les données de A vers B doivent être multipliées plusieurs fois. 5 Un changement entre deux procédés, par exemple d'un système de gestion par ordinateur de bureau D ou entre deux tâches, notamment dans la zone noyée ou intégrée, sera appelé changement de contexte. Un tel changement de contexte nécessite en général une protection compliquée de tous les contenus des registres de la pile de pro- lo grammes ou de la mémoire de pile de programmes et des informations d'état de programme. Suivant l'assistance par circuit, de telles opérations ont des durées de l'ordre de la milliseconde. Si l'utilisateur veut changer entre les tâches, le changement de contexte, par exemple dans un système Windows (marque déposée) d'une durée de quelques milli- 15 secondes ne sera pas perceptible pour l'utilisateur. Dans une machine à laver, un distributeur automatique de boissons mais également dans les installations industrielles d'une certaine dimension, de telles durées de changement de contexte ne créent pas de difficultés dans la mesure où la commande et la régula- 20 tion fonctionnent dans la plage du dixième de seconde. Si des solutions plus rapides sont nécessaires, on fournira pour cela en général moins de pièces et une variance gérable des différentes solutions. A la différence des exemples décrits, le domaine de l'automobile est concerné par des quantités importantes et une concur- 25 rence de plus en plus rude ce qui crée d'énormes contraintes de coût. Il en résulte que les systèmes de commande électronique ne peuvent être utilisés pour ce marché que s'ils peuvent être fournis avec une mise en oeuvre aussi réduite que possible de ressource notamment de mémoire RAM ou de mémoire Flash et de puissances de calcul. Un appareil de 30 commande électronique pour des commandes de moteurs présente actuellement une mémoire Flash ou mémoire RAM avec une capacité de mémoire de 2 MB et une mémoire RAM avec une capacité de 64 KB, comme calculateur 32 bits pour une fréquence d'horloge de 44 MHz. De plus, une individualisation dans le domaine automo- 35 bile avec en même temps des contraintes plus strictes pour le confort, 2908909 6 la puissance, la législation relative aux gaz d'échappement, crée une multiplicité de variantes de plus en plus grandes. Pour les programmes, cela signifie une individualisation croissante des composants de pro-grammes pour une complexité croissante. Dans un appareil de corn- 5 mande ou de gestion de moteur on a actuellement entre 10 et 30 tâches qui s'exécutent et qui, pour des systèmes automobiles ou des installations le domaine intégré, peuvent être réparties jusqu'à entre 1000 procédés. Ces procédés sont entre autres les régulations et les commandes avec des temps de réactions de l'ordre de la milliseconde. 10 Les deux exigences contradictoires connues dans le domaine des serveurs ou des équipements de bureaux et qui sont égale-ment des standards dans le domaine intégré ne peuvent s'appliquer qu'au domaine de l'automobile. Les systèmes de gestion actuels pour les applications automobiles sont très réduits par rapport aux fonctions de 15 calendrier et répondent à un standard OSEK propre. Les caractéristiques souhaitées pour le temps réel sont réalisées par un échéancier statistique fixé à l'instant de la conversion. La communication inter-procédés est réalisée de façon optimisée quant aux ressources lorsqu'on relie les différents codes objets à l'aide de variables globales. Les infor- 20 mations ne seront copiées que si cela est nécessaire pour des raisons de consistance des données. En général, on ne tient compte d'aucun pro-cédé de protection de mémoire. Un procédé prioritaire de générateur d'informations est décrit dans le document DE 103 34 535 Al. Le procédé prioritaire sert à 25 la commande coordonnée de la ligne de transmission d'un véhicule. En appliquant le procédé de priorité, on classe dans le sens montant ou descendant une liste avec des requêtes de priorité. La liste classée est traitée séquentiellement en commençant par le demandeur ayant la priorité la plus élevée. Le traitement de la liste sera arrêté dès qu'une 30 demande arrive avec un souhait de sélection de ce souhait de requête. Le document DE 103 34 536 Al décrit un système d'ordinateur ayant au moins un processeur et au moins une mémoire pour commander de manière coordonnée la ligne de transmission d'un véhicule automobile. Le système d'ordinateur a une architecture de pro- 35 gramme avec différents composants. Un premier composant est réalisé 2908909 7 comme système opérationnel avec le système de gestion et des services spécifiques comme base pour tous les autres éléments et applications. Un second composant est réalisé comme fonctionnalité de base pour convertir les requêtes universelles. Un troisième composant est une 5 couche pour coordonner les missions de fonction pour la fonctionnalité de base et pour réunir des dispositifs par branchement comme quatrième composant. Au moins un branchement sert à convertir des missions ou des fonctions concrètes qui dépassent les fonctions de fonctionnalité de base et sont coordonnées par la couche. Dans ces 10 conditions, les dispositifs à simple branchement, notamment modulaire, sont interchangeables. Exposé de l'invention La présente invention concerne un procédé de gestion d'une unité de calcul pour contrôler au moins un appareil de corn- 15 mande et selon lequel on définit sur l'unité de calcul, des droits d'accès réciproques entre les parties de programme dans les mémoires volatiles d'origines différentes. Dans le cas d'une mémoire volatile et ainsi variable ou fugitive, pour une partie de programme ou un code programme, il s'agit 20 par exemple d'une plage de données en forme de mémoire RAM dans laquelle on peut enregistrer la partie de programme. Dans le domaine automobile, les parties de programme sont décrites comme codes exécutables par un processeur. Dans le procédé, selon un développement on cloisonne 25 des parties de programme dans les mémoires volatiles avec des origines différentes, on les accumule, on les groupe et/ou on les fixe par des interfaces avec des droits d'accès. Les parties de programme peuvent être couplées entre elles dans les mémoires volatiles ou être configurées. De tels cloisonnements à accumulation ou groupage peuvent être par 30 exemple prévus notamment pour les variables statiques des parties de programme dans les mémoires volatiles. Contrôler au moins un appareil de commande par l'unité de calcul englobe la possibilité que l'unité de calcul régule ou commande au moins un appareil de commande. Les droits d'accès peuvent être subdivisés en plusieurs 35 blocs globaux. Cela peut signifier que seules les parties de programme 2908909 8 de mémoire volatile ou parties de programme de même origine peuvent être manipulées dans le sens de la lecture et/ou de l'écriture et ainsi accéder par manipulation à leur mémoire correspondante et ainsi aux plages de données. Pour des parties de programme ou dans les mémoi- 5 res volatiles d'origines différentes, on peut fixer de manière appropriée les droits d'accès. Cela peut signifier en fonction de l'origine que deux parties de programme possèdent dans deux mémoires volatiles des droits d'accès différents, réciproques. C'est ainsi qu'une première partie de programme peut être accessible dans une première mémoire volatile io en lecture et écriture pour une plage de données alors que la seconde partie de programme peut avoir dans une seconde mémoire volatile aucun droit d'accès à la plage de données. Ainsi, les parties de programme dans les mémoires volatiles peuvent être identifiées par leur origine et ainsi en particulier par 15 leur provenance. Cela signifie de manière caractéristique que les parties de programme dans les mémoires volatiles proviennent d'origines différentes, de fabricants différents et les parties de programme dans les mémoires volatiles de même origine provenant du même fabricant. Pour les parties de programme dans les mémoires volatiles de mêmes origi- 20 nes, le fabricant définit en général des droits d'accès réciproques. Un mode de réalisation de l'invention se traduit par une conception d'échéancier de procédé ayant les propriétés d'une mise en grappe de serveurs ou d'accumulation de tous les procédés de toutes les sociétés de fabrication et ainsi tous les procédés auront la même oh- 25 Bine. On peut par exemple répartir les grappes en trois blocs globaux d'un procédé d'information et le cas échéant prévoir une autre répartition de la grappe en faisant une analyse des références émission/réception. Par ces trois blocs globaux on fixe différents droits d'accès. 30 Selon une variante de l'invention, les parties de pro-gramme dans les mémoires volatiles sont en général liées statiquement par une programmation globale. Par un droit d'accès on peut réguler l'accès d'une première partie de programme dans une première mémoire volatile à une 35 seconde partie de programme dans une seconde mémoire volatile au 2908909 9 moins d'une manière univoque. Avec une régulation réciproque on peut protéger les parties de programme dans les mémoires volatiles contre une interaction non voulue. Selon un autre développement du procédé on définit 5 l'appartenance d'au moins un composant de programme d'une partie de programme dans une mémoire volatile par au moins une méta-donnée et au moins une indication pour une combinaison entre les parties de programmes dans les mémoires volatiles d'origines différentes. Dans ce cas, au moins cette méta-donnée peut être fournie pour les fonctions de 10 configuration à un instant de conversion pour configurer la chronologie et/ ou générer une stratégie d'optimisation. Les parties de programme dans les mémoires volatiles peuvent être exécutées dans l'unité de calcul et notamment dans un programme global statique de l'unité de calcul. Cela permet d'intégrer 15 dans l'unité de calcul, plusieurs implémentations de parties de pro-gramme dans les mémoires volatiles d'origines différentes. Dans une réalisation de l'invention, les systèmes de fonctionnement d'au moins une unité de calcul peuvent être pris en compte pour une durée de fonctionnement. 20 En outre, selon une variante du procédé, pour modifier la partie de programme dans la mémoire volatile, on peut libérer de manière adaptée seulement une plage de mémoire exclusive pour l'unité de calcul et cette plage de mémoire sera simplement reliée, en particulier pour protéger la mémoire cache ou la plage de mémoire cache de la 25 plage de mémoire pour réaliser une stratégie possible de l'invention. Selon un développement de l'invention, dans une plage ou zone de mémoire commune on accède à un message par un appel du système de fonctionnement. En variante ou en complément, on peut notamment avoir un accès commun par des plages de mémoire dis- 30 tinctes. Selon un autre développement on peut fournir ou appliquer au moins des composants des parties de programmes dans les mémoires volatiles ou à partir de composants de programmes, fournir des copies de la mémoire volatile et ainsi de plages de données volatiles. 2908909 10 L'invention concerne en outre une unité de calcul conçue pour contrôler au moins un appareil de commande. L'unité de calcul est prévue pour définir des droits d'accès réciproques pour des parties de programme dans des mémoires volatiles d'origines différentes. 5 Cette unité de calcul est réalisée comme un composant d'un appareil de commande ou du moins elle coopère avec un appareil de commande. L'unité de calcul est par exemple prévue pour contrôler au moins l'appareil de commande dans le domaine automobile. L'unité de calcul selon l'invention est conçue pour exécuter au moins un pas du programme de l'invention. L'invention concerne en outre un programme d'ordinateur avec des moyens de codes programme pour exécuter toutes les étapes d'un procédé selon l'invention lorsque le programme d'ordinateur est exécuté sur un ordinateur ou dans une unité de calcul, 15 notamment une unité de calcul selon l'invention. Le produit programme d'ordinateur selon l'invention avec des moyens de codes programme enregistrés sur un support de données lisible par un ordinateur est conçu pour exécuter toutes les étapes d'un procédé selon l'invention lorsque le programme d'ordinateur est exécuté 20 par un ordinateur ou dans une unité de calcul, notamment une unité de calcul selon l'invention. Selon une réalisation, en tenant compte des parties pro-venant des fabricants ou des fournisseurs, qui donnent les parties de programme en général dans les mémoires volatiles et qui définissent 25 ainsi les origines des parties de programme dans les mémoires volatiles, l'invention permet une protection de la mémoire dans des systèmes travaillant en temps réel et notamment des systèmes de programme en temps réel. L'invention permet d'assurer entre autres que différentes 30 parties de programme exécutables dans des mémoires volatiles de fabricants différents, indépendants, peuvent fonctionner sur l'unité de calcul ou dans un processeur sans s'influencer réciproquement. Selon un autre développement, l'invention concerne également les architectures de programme ou systèmes de programme dans lesquels différentes parties 35 de programme dans différentes mémoires volatiles doivent permettre de 2908909 11 réaliser un échéancier statistique ou un plan de déroulement dans des suites de séries de déroulements définies au moins en partie. Cela est par exemple le cas dans des appareils de commande utilisés dans le domaine automobile. 5 Ainsi, l'invention protège contre les accès réciproques étrangers des plages de données volatiles des parties de programme dans des mémoires volatiles d'origines différentes et provenant ainsi de différents fabricants indépendants, si les parties de programme dans les mémoires volatiles sont exécutées dans un microprocesseur dans un 10 programme global lié notamment de manière statistique ou dans un système correspondant de microprocesseur. Selon un développement, l'échéancier configuré de manière statistique et/ ou automatique à un instant de conversion ne nécessite à l'instant de l'exécution pratiquement pas de puissance de 15 calcul pour effectuer des travaux d'administration. En outre, une communication inter-procédé selon les stratégies d'optimation que l'on utilise actuellement à l'instant de conversion ne demande plus que de faibles ressources supplémentaires sous la forme d'une mémoire RAM et/ou d'une puissance de calcul. L'invention permet en outre d'éviter 20 tout changement de contexte supplémentaire critique pour le temps de fonctionnement. De plus, dans un mode de réalisation il est possible, dans le cas d'une atteinte à l'accès, de fournir des stratégies de solutions qui aboutissent à une réaction garantie de l'ensemble du système. Un autre développement de l'invention repose sur la coo- 25 pération des fonctions dans trois plans, à savoir la fourniture de méta-donnée pour les fonctions de configuration à l'instant de conversion, aux fonctions du système de fonctionnement réalisées pour le temps de fonctionnement et le matériel et ainsi l'unité de calcul. Selon une application envisageable, pour les modèles 30 d'interface et de configuration existants actuellement selon AUTOSAR, ASAM ou MSR, on peut fournir des méta-données différentes sous la forme d'un fichier XML. Cela concerne les informations d'échéance pour les procédés et les taches ainsi que leurs déclarations. Les méta-données peuvent correspondre aux relations d'émission et de réception 35 de messages ainsi que de relations d'appartenance, de variables, de 2908909 12 messages, de paramètres de calibrage, de procédés et autres à des parties de programme dans les mémoires volatiles ou pour leurs composants de programme. De plus, en complément ou en variante, on peut fournir des relations d'appartenance des composantes de programme 5 des parties de programme dans les mémoires volatiles à leurs fabri- cants. Un message obtenu selon un développement de l'invention peut être une variable globale utilisée pour la communication interprocédés. Cela garantit que dans le cas d'une incohérence 10 possible des données par l'accès décalé dans le temps à ces variables en cas d'interruption de tâche, on stocke de façon intermédiaire les conte-nus des variables par des copies de façon que tous les procédés qui accèdent disposent toujours des mêmes contenus de données pendant la durée d'exécution d'une tâche. 15 Dans le cadre de l'invention, on peut réaliser au moins l'un des différents droits d'accès. Habituellement, les trois différents bras d'accès sont groupés dans trois blocs globaux. L'unité de calcul comporte en général plusieurs plages de mémoires ou des mémoires RAM et chaque plage ou zone de mémoire et ainsi une mémoire volatile 20 sont prévues pour une partie de programme de cette origine. Ainsi, un premier droit d'accès comprend une accumulation ou une grappe de toutes les variables statistiques des sociétés fabricantes dans chaque fois une plage de mémoires RAM ou par SectionCompany[x].private avec x = O...n-1 de sorte que la plage respective de la mémoire RAM ne pourra être utilisée que par le fabricant lui-même. Ainsi, seul le fabricant a un accès aux plages de données volatiles ayant leur origine chez ce fabricant pour les opérations de lecture, d'inscription et de modification des parties de programme dans les mémoires volatiles. 30 Un second droit d'accès comprend un regroupement de toutes les variables statistiques des fabricants chaque fois dans une plage de mémoires RAM en appliquant SectionCompany[x].public.read avec x = O...n-1 . Cela signifie que seul le fabricant x des parties de programme peut modifier dans les mémoires volatiles, ces parties de 2908909 13 programme et peut ainsi les écrire. Les autres fabricants ou partenaires au développement n'auront qu'un droit d'accès pour la lecture. Un troisième droit d'accès comprend le regroupement de toutes les variables statistiques des fabricants chaque fois dans une 5 plage de mémoires RAM selon SectionCompany[x].public. avec x = O...n-1 . Ainsi, tous les autres partenaires au développement pourront manipuler les parties de programme dans les mémoires volatiles, c'est-à-dire les transcrire et les lire. Dans le domaine automobile, dans le cadre des conceptions d'échéancier de procédé on désigne par procédé une fonction de niveau vide-vide-top dans une mission ou une tâche. Une fonction de système est réalisée régulièrement par au moins un procédé desorte qu'au moins un procédé et ainsi également plusieurs procédés peuvent être traités dans différentes tâches. Par ce concept des procédés dans 15 une mémoire de pile ou plus simplement une pile, entre les différents appels de procédé on aura toujours des vides et ainsi les procédés ne risqueront pas de s'influencer par l'intermédiaire de la pile. En cas de besoin, on peut vérifier un pointeur de pile entre les appels de procédé. La séquence des appels de procédé est définie de manière 20 caractéristique par des relations émissions et réceptions ou des relations émissions et réceptions de messages pour une communication inter-procédés ainsi que par un procédé de traitement global des informations. Le développement concerne les procédés de communication inter-procédés dans le domaine automobile. Par des procédés de traite- 25 ment globaux d'informations on saisit et on traite les données fournies par des capteurs et on émet de plus des valeurs d'actionnement destinées aux actionneurs. Lorsque pendant le temps de parcours une tâche atteint une telle frontière de grappes on libèrera pour la tâche et ainsi pour la 30 grappe qui arrive ensuite à exécution, les plages de mémoires respectives spécifiques par leur origine ou leur fabricant en tenant compte des conception des mémoires RAM, par le système de gestion pour libérer la lecture ou l'inscription. Dans une variante de l'invention, ainsi il n'y a pas de changement de contexte entre deux composants de programme, 35 c'est-à-dire que l'on n'utilise pas de gestion de mémoire (unité de ges2908909 14 tion de mémoire MMU) et ainsi on n'utilise pas de mémoire virtuelle. Les parties de programme dans les mémoires volatiles et notamment les composantes de programme sont par exemple protégées les unes des autres par un contexte de tâche. Il en résulte que dans une variante de 5 l'invention, les problèmes évoqués ci-dessus des propositions de solutions provenant d'autres domaines comme par exemple une en-tête de temps de parcours excessive qui résulte de nombreux changements de contexte en liaison avec une gestion de mémoire MMU, ainsi que des problèmes de protection de mémoire dans les systèmes de gestion actuels sont des problèmes qui ne se présentent pas dans le domaine automobile. La présente invention peut également comporter un système de fonctionnement ou de gestion. Un tel système de gestion peut générer, en fonction d'une réalisation respective, un mécanisme pour 15 fixer les plages de mémoire qui ne peuvent être surscrites dans les composants de programme et notamment des jeux de composants de programme et ainsi des parties de programme dans les mémoires volatiles. Cela peut se faire pour une durée d'intégration de l'unité de calcul ou du système, en général à un moment lorsque l'on génère les images 20 de programme. Pour la durée de fonctionnement proprement dite, lors-que l'appareil de commande ou le système fonctionne dans le véhicule, ce système de gestion peut être réglé pour les composants qui se trou-vent chaque fois en exécution dans la plage de mémoire modifiable. L'invention permet de réaliser différentes stratégies de 25 protection d'une mémoire de l'unité de calcul dans le domaine automobile. On présentera ci-après quatre exemples de telles stratégies. Avec au moins l'une de ces stratégies on peut éviter l'accès par exemple à l'écriture, intentionnel et/ou non intentionnel à une plage de données exclusives d'un autre composant de programme. 30 Ainsi, en générant une succession d'échéances statistiques, on peut insérer une tâche entre les parties de programme dans des mémoires volatiles ou entre des grappes de composants de pro-grammes, c'est-à-dire une quantité de procédés simplement reliée dans le temps pendant la durée de fonctionnement, de chaque fabricant, avec 35 des appels automatiques de systèmes de fonctionnement. Ainsi, pour 2908909 15 ces grappes ou regroupement de parties de programme dans les mémoires volatiles on ne libérera qu'une plage de mémoire exclusive adaptée du fabricant pour la modification, de façon caractéristique pour la lecture et/ou l'écriture et on bloquera la plage de mémoire restante ou la 5 mémoire de données pour l'accès en lecture et/ou en écriture. Une combinaison à prévoir le cas échéant ou une liaison du programme global et d'un système comprenant les parties de pro-gramme dans des mémoires volatiles est conçue de façon que toutes les données statistiques d'un fabricant, en général dispersées entre plu-sieurs grappes de composants de programme se trouvent dans une plage de mémoire cohérente ou dans la plage de la mémoire RAM. Selon un développement, on peut interdire une association ou une attribution d'une mémoire dynamique par malloc()/free() . En plus, la mémoire en pile peut être complètement vidée 15 à chaque limite de grappe, ce qui peut par exemple signifier que le pointeur de piles sera dirigé vers le début pour fournir une mesure de sécurité étendue, redondante, Ces stratégies permettent de garantir que des grappes de composants de programme protégés les uns des autres permettent un 20 accès modifié aux plages de données exclusives de l'autre grappe ou grappe de composants de programme. En outre, à l'aide d'au moins l'une des stratégies on évite un accès d'écriture accidentel dans une plage de mémoire commune. Dans le cadre de l'invention, suivant la stratégie la plus appropriée, on 25 prendra des procédures différentes. Les stratégies peuvent être influencées par le matériel. Une première stratégie concerne un accès d'écriture et/ou de lecture à un message réalisé comme une donnée dans la plage de mémoire commune. Cette première stratégie est habituellement exé- 30 cutée seulement par un appel du système de gestion à l'unité de calcul. L'appel du système de gestion accède à la donnée dans le contexte d'un utilisateur ou d'utilisateurs privilégiés, c'est-à-dire d'un super utilisateur disposant de droits particuliers pour utiliser le processeur. Cette plage de mémoire commune ne peut être inscrite que par le super utili- 35 sateur ce qui englobe également la variante selon laquelle seul le super 2908909 16 utilisateur accède à la plage de mémoire commune. Il en résulte que toutes les modifications non voulues, par exemple un index défectueux, seront rejetées et d'autres mémoires appropriées seront prises telles que par exemple le déclenchement d'une exception/rejet. 5 Cette première stratégie permet la réalisation de messages d'entrée pour des composants de programme d'autres fabricants, en général protégés contre les modifications à cause des frontières entre les grappes. Dans le cas d'une seconde stratégie il est prévu plusieurs 10 modules de plages de mémoires, différents, habituellement séparés les uns des autres ou indépendants et par de plage de mémoire commune. Les messages sont enregistrés à cet effet chaque fois dans un module de plages de mémoires exclusives de la grappe de partie de programme ou de composants de programme. Il en résulte entre autres qu'aucune mo- 15 dification intentionnelle ou/et non intentionnelle ne sera possible pour d'autres grappes. Selon une troisième stratégie on peut utiliser un concept qui, entre autres, permet de réaliser des message d'entrée. Dans ce concept, pour construire tous les composants de programme on vérifie les 20 parties de programme dans les mémoire volatiles pour déterminer si ces composants décrivent une message d'entrée d'un composant d'un autre fabricant. Si cela est le cas, pour au moins un composant à inscrire, on dépose une copie du message sur laquelle au moins le composant à inscrire pourra opérer. Ce composant inscrit ou remplace par inscription 25 pendant son temps d'exécution, la copie du message déjà fournie par le système de gestion. Cette troisième stratégie tient compte de ce que seulement le fabricant du composant à inscrire peut écrire cette copie ce qui exclut des modifications par d'autres fabricants. Ensuite, on copie par exemple à la limite de la grappe du système de gestion qui tra- 30 vaille dans ce contexte comme utilisateur privilégié ou comme super utilisateur, la valeur de la copie au message d'origine. Dans ce mécanisme il est important que chaque fois seulement un autre composant inscrive sur ce message d'entrée. Cela peut toutefois être vérifié par le système de gestion au moment de la construction. 2908909 17 Selon une autre variante, également plusieurs composants à inscrire peuvent inscrire sur le message d'entrée d'un composant. Pour chacun de ces composants à inscrire le système de gestion fournit une copie propre du message d'entrée. Si l'on a par exemple les 5 composants à exécuter fournis par le message d'entrée, il est en outre prévu de le communiquer de manière appropriée au système de gestion comme cela a été fait avec plusieurs copies du message d'entrée. Cela pourrait par exemple se faire par une fonction de rappel d'un composant. Cette fonction de rappel peut être transmise et/ou fournie par le 10 système de gestion avant l'appel des composants proprement dits, par un nombre et un ordre d'inscription de toutes les copies. Ce composant peut en outre accéder par la fonction de rappel, totalement de façon générique aux données et pour appliquer le traitement approprié ; cela peut par exemple signifier que l'on tient seulement compte de la dernière valeur de la somme de plusieurs valeurs et/ou de la moyenne de toutes les valeurs. Selon une quatrième stratégie, on inscrit et/ou on lit la plage de mémoire commune pour chaque appel du système de gestion sans utilisateur privilégié. Pour la protection, dans cette quatrième 20 stratégie on prévoit une plage d'ombre de la plage de mémoire commune. Cette plage d'ombre permet de protéger la consistance de la plage de mémoire commune avec un mécanisme supplémentaire. La quatrième stratégie peut être réalisée par une première variante. Selon cette première variante, à chaque accès 25 d'inscription et/ou de lecture, on compare une donnée originale à une donnée correspondante ou associée dans la plage d'ombre. En cas de non concordance de la donnée avec la donnée d'origine, on réagit par un moyen approprié. En plus ou en variante, pour exécuter la quatrième stra- 30 tégie on peut utiliser une seconde variante. Dans cette seconde variante on a des algorithmes de sommes de contrôle pour les deux plages de mémoire qui seront ensuite comparées. En cas de non concordance des sommes de contrôle on réagit de manière appropriée. De façon caractéristique, dans l'exécution de l'algorithme de sommes de contrôle par des 35 accès d'écriture ou de lecture non atomique, par exemple par des ver- 2908909 18 rous lecture/écriture, on prend des mesures contre l'incohérence des données. Comme en cas d'accès non intentionnel, en général on ne modifie pas en synchronisme de façon aléatoire les deux plages de mé- 5 moire, dans ces deux variantes de la quatrième stratégie on reconnaît les inconsistances et on réagit de manière appropriée. La stratégie à exécuter dans ce développement en tenant compte des deux variantes, peut par exemple s'appliquer si le matériel utilisé n'assiste pas de concept d'un utilisateur privilégié (super utilisa- 10 teur) . Un exemple de réalisation de l'invention peut concerner une réalisation de mémoires RAM ou d'une conception de mémoires RAM de la mémoire de travail (RAM). Dans une combinaison de développement à (n) participants au développement, on peut par les corres- 15 pondantes décrites dans les méta-données entre les variables et les fonctions de programme, générer des indications de combinaisons ou de liaisons vers les composants de programme et ainsi vers les fabricants respectifs, qui conduisent à la conception de mémoires RAM avec trois droits d'accès stricts, différents, et les propriétés différentes qui en ré- 20 sultent. Dessins La présente invention sera décrite ci-après de manière plus détaillée à l'aide des dessins annexés dans lesquels : - la figure 1 est une vue schématique d'une architecture d'une mé- 25 moire de travail d'un premier mode de réalisation de l'unité de calcul selon l'invention, - la figure 2 est une vue schématique de la procédure pour manipuler des parties de programme dans des mémoires volatiles dans le cadre d'un second mode de réalisation

du procédé de l'invention, 30 - la figure 3 est une vue schématique d'un dispositif de calculateur avec deux modes de réalisation de l'unité de calcul selon l'invention. Description de modes de réalisation de l'invention La présente invention sera décrite à l'aide de modes de réalisation représentés schématiquement dans les dessins et décrits ciaprès de manière explicite en se référant aux dessins : 2908909 19 - la figure 1 montre schématiquement une architecture de mémoire de travail selon un premier mode de réalisation d'une unité de calcul 2 selon l'invention. Dans cette représentation schématique on a une première partie de programme 4 dans une première mémoire volatile 5 5, ici une première plage de mémoire RAM, une seconde partie de programme 6 dans une seconde mémoire volatile 7, ici une seconde plage de mémoires RAM ainsi qu'une troisième partie de programme 8 dans une troisième mémoire volatile 9, ici une troisième plage de mémoire RAM, ces différentes plages étant superposées. Il est prévu 10 que ces trois parties de programme 4, 6, 8 dans les trois mémoires volatiles 5, 7, 9 proviennent de fabricants différents, à savoir d'un premier fabricant dans le cas de la première partie de programme 4 inscrite dans la première mémoire volatile 5, d'un second fabricant dans le cas de la seconde partie de programme 6 inscrite dans la se- 15 conde mémoire volatile 7 et d'un troisième fabricant dans le cas de la troisième partie de programme 8 inscrite dans la troisième mémoire volatile 9. Cela signifie que les trois parties de programme 4, 6, 8 ont des origines différentes dans les trois mémoires volatiles 5, 7, 9. Il est prévu que chaque partie de programme 4, 6, 8 20 comporte un premier composant de programme 10 chaque fois dans une première mémoire volatile 5, 7, 9, qui dans le présent mode de réa- lisation est également défini comme composant de programme privé 10 et est ainsi protégé contre les accès par chaque fois une autre partie de programme 4, 6, 8 dans une autre mémoire volatile 5, 7, 9. Pour chaque 25 second composant de programme 12 des trois parties de programme 4, 6, 8 dans les mémoires volatiles 5, 7, 9 on a fixé un accès officiel de lecture, ce qui signifie que les parties de programme 4, 6, 8 peuvent également accéder aux mémoires volatiles 5, 7, 9 pour des origines dif- férentes, au moins en partie, pour accéder aux seconds composants de 30 programme 12. En outre, chaque partie de programme 4, 6, 8 dans chaque mémoire volatile 5, 7, 9 comporte un troisième composant de programme 14. Ces troisièmes composants de programme 14 peuvent être manipulés en écriture en accédant aux parties de programme. En outre, les seconds composants de programme 12 ont 35 des plages de lecture 16 pour lesquelles il y a un dépôt multiple pour 2908909 20 des problèmes à lire et ainsi des tâches avec consistance de données. Ainsi, les troisièmes composants de programme 12 ont des plages d'inscription 18 pour un enregistrement multiple de problèmes à inscrire et ainsi de tâches assurant une consistance des données.

5 Selon le présent mode de réalisation, l'unité de calcul 2 représentée schématiquement coopère avec un certain nombre d'appareils de commande non représentés et contrôle ces appareils de commande. Dans l'unité de calcul 2 on a couplé les différentes parties de programme 4, 6, 8 dans les mémoires volatiles 5, 7, 9 à l'intérieur 10 d'un programme global de façon à définir entre les parties de pro-gramme 4, 6, 8 dans les mémoires volatiles 5, 7, 9 d'origines différentes, des droits d'accès réciproques. Cela signifie que les parties de pro-gramme 4, 6, 8 peuvent accéder en lecture, en écriture ou pas du tout, deux mémoires volatiles 5, 7, 9 en fonction des composants de pro- 15 gramme, et selon le droit d'accès respectif. Par définition des droits d'accès, le fonctionnement de l'unité de calcul 2 évite que les parties de programme 4, 6, 8 des mémoires volatiles 5, 7, 9 s'influencent réciproquement de manière intentionnelle ou non intentionnelle risquant de provoquer un défaut de 20 fonctionnement accidentel d'un appareil de commande respectif. - la figure 2 montre schématiquement une procédure pour traiter les parties de programme dans des mémoires volatiles dans le cadre d'un mode de réalisation du procédé de l'invention. Dans le dia- gramme de la figure 2 on a représenté une première tâche 20 et une 25 seconde tâche 22. La première tâche 20 comprend des premières séquences d'exécution de procédé 24 d'un premier fabricant, des secondes séquences d'exécution de procédé 26 d'un second fabricant, une troisième séquence d'exécution de procédé 28 d'un troisième fabricant ainsi qu'une 30 quatrième séquence d'exécution de procédé 30 d'un quatrième fabricant. De façon analogue, la seconde tâche 22 est subdivisée en des premières séquences d'exécution de procédé 24 d'un premier fabricant, des secondes séquences d'exécution de procédé 26 d'un second fabricant, des troisièmes séquences d'exécution de procédé 28 du troisième 35 fabricant et des quatrièmes séquences d'exécution de procédé 30 du 2908909 21 quatrième fabricant. En outre, pendant la seconde tâche 22 il est prévu au moins un premier échange de contexte 32 et au moins un second échange de contexte 34. La présente invention permet dans le second mode de 5 réalisation, en générant des séquences de procédé, de tenir compte d'au moins un autre critère. Il est ainsi possible dans une association de développement entre des fabricants et ainsi des partenaires de développement, d'identifier l'appartenance des procédés aux tâches 20, 22. En outre, en générant la séquence d'exécution de procédé 24, 26, 28, 30, 10 on intègre la mise en grappe selon les fabricants pour minimiser les en- têtes de changement de procédé comme autres critères. Le diagramme de la figure 2 représente ainsi une grappe de procédé selon les fabricants. On a ainsi le second changement de contexte 34 se produisant entre les changements de procédé à 15 l'intérieur d'une grappe de procédés. A l'extérieur, on effectue le premier changement de contexte 22 correspondant à une réattribution des droits d'accès dans une gestion de mémoire par un système de gestion. - la figure 3 montre schématiquement un dispositif de calculateur 100 qui comprend un second mode de réalisation d'une unité de calcul 20 102 selon l'invention. A l'intérieur du programme global 104 de l'unité de calcul 102 on a couplé entre elles quatre différentes parties de programme 106, 108, 110, 112 dans des mémoires volatiles. En outre, l'unité de calcul 102 et ainsi également le dispositif de calculateur 100 sont reliés aux deux appareils de commande 114, 116 25 présentés ici de sorte que l'unité de calcul 102 coopère en alternance avec ces appareils de commande 114, 116 pour être influencée de manière fonctionnelle et par les données des appareils de commande 114, 116. Dans le cadre de ce mode de réalisation il est prévu que 30 les quatre parties de programme 106, 108, 110, 112 correspondent à des origines différentes dans les mémoires volatiles ce qui signifie que ces parties de programme 106, 108, 110, 112 correspondent à des mémoires volatiles de différents fabricants, indépendants les uns des autres et ce n'est que le dispositif de calculateur 102 qui les mémorise en 35 commun dans le programme global 104 et les exécute simultanément.

2908909 22 Pour cette réalisation des parties de programme 106, 108, 110, 112 dans les mémoires volatiles, pour éviter une interaction accidentelle entre les parties de programme 106, 108, 110, 112 dans les mémoires volatiles, on a défini des droits d'accès réciproques 118, 120 5 entre les parties de programme 106n, 108, 110, 112 dans les mémoires volatiles ; ces droits d'accès fixent une manipulation réciproque des parties de programme 106, 108, 110, 112 dans les mémoires volatiles. Les doubles flèches représentent des droits d'accès en lecture et écriture 118 ; les flèches simples représentent des droits 10 d'accès en lecture seule 120 entre parties de programme 106, 108, 110, 112 dans les mémoires volatiles. Ainsi, dans une première partie de programme 106, dans une première mémoire volatile, il est autorisé d'accéder à une seconde partie de programme 108 ; dans une seconde mémoire volatile l'accès est autorisé en lecture et en écriture ; dans une 15 quatrième partie de programme 112 l'accès concerne une quatrième mémoire volatile mais seulement en lecture. La seconde partie de pro-gramme 108 dans la seconde mémoire volatile est autorisée à accéder à la première partie de programme 106 dans la première mémoire volatile seulement en lecture et à la quatrième partie de programme 112 de la 20 quatrième mémoire volatile en lecture et en écriture et à une quatrième partie de programme 112 dans une quatrième mémoire volatile mais seulement en lecture. La seconde partie de programme 108 dans la seconde mémoire volatile est autorisée à accéder à la première partie de programme 106 dans la première mémoire volatile seulement en lecture 25 et à la quatrième partie de programme 112 de la quatrième mémoire volatile en lecture et en écriture. Une troisième partie de programme 110 dans la troisième mémoire volatile est autorisée à accéder en lecture à la quatrième partie de programme 112 dans la quatrième mémoire volatile. La quatrième partie de programme 112 dans la 30 quatrième mémoire volatile est autorisée à accéder à la première partie de programme 106 dans la première mémoire volatile et à la seconde partie de programme 108 dans la seconde mémoire volatile pour un accès en lecture ; de plus, la quatrième partie de programme 112 dans la quatrième mémoire volatile est autorisée à accéder à la troisième partie 35 de programme 110 dans la troisième mémoire volatile par lecture et 2908909 23 écriture. En outre, entre la première partie de programme 106 dans la première mémoire volatile et la troisième partie de programme 110 dans la troisième mémoire volatile, on n'a défini aucun droit d'accès. Ainsi, entre les deux parties de programme 106, 110 il n'est jamais possible 5 d'accéder aux mémoires volatiles respectives. io

Claims (3)

REVENDICATIONS

1 ) Procédé de gestion d'une unité de calcul (2, 102) réalisé pour contrôler au moins un appareil de commande (114, 116) selon lequel, pour l'unité de calcul (2, 102) on définit des droits d'accès (118, 120) récipro- ques entre les parties de programme (4, 6, 8, 106, 108, 110, 112) dans des mémoires volatiles (5, 7, 9) d'origines différentes.

2 ) Procédé selon la revendication 1 selon lequel on cloisonne les parties de programmes (4, 6, 8, 106, 108, 110, 112) dans les mémoires volatiles 10 (5, 7, 9) d'origines différentes.

3 ) Procédé selon la revendication 1 ou 2, selon lequel on définit une appartenance d'au moins un composant de programme d'une partie de programme (4, 6, 8, 106, 108, 110, 112) dans une mémoire volatile (5, 15 7, 9) par au moins une méta-donnée et on génère au moins une indication pour une combinaison entre les parties de programme (4, 6, 8, 106, 108, 110, 112) dans les mémoires volatiles (5, 7, 9) d'origines différentes. 20 4 ) Procédé selon la revendication 3, caractérisé en ce qu' au moins une méta-donnée est fournie à un instant de conversion. 5 ) Procédé selon la revendication 1, 25 caractérisé en ce que les parties de programme (4, 6, 8, 106, 108, 110, 112) dans les mémoires volatiles (5, 7, 9) sont exécutées à l'intérieur d'un programme global (104) sur l'unité de calcul (2, 102) de l'appareil de commande (114, 116). 30 6 ) Procédé selon la revendication 1, caractérisé en ce que la durée de fonctionnement de l'unité de calcul (102) dépend des parties de programme (106, 108, 100, 112) dans les mémoires volatiles (5, 7, 9), 35 qui sont exécutées à l'intérieur d'un programme global (104). 2908909 25 7 ) Procédé selon la revendication 1, caractérisé en ce que on libère une plage de mémoire de l'unité de calcul (2, 102)pour modifier une partie de programme (4, 6, 8, 106, 108, 110, 112) dans une 5 mémoire volatile (5, 7, 9). 8 ) Procédé selon la revendication 7, caractérisé en ce qu' on fournit une mémoire cache de la zone de mémoire. i0 9 ) Procédé selon la revendication 1, caractérisé en ce qu' au moins les composants des parties de programme (4, 6, 8, 106, 108, 110, 112) sont fournis sous forme de copies de la mémoire volatile (5, 7, 15 9). 10 ) Unité de calcul pour contrôler au moins un appareil de commande (114, 116) réalisé pour définir des droits d'accès (118, 120) réciproques entre les différentes parties de programme (4, 6, 8, 106, 108, 110, 112) 20 dans les mémoires volatiles (5, 7, 9) d'origines différentes. 11 ) Programme d'ordinateur avec des moyens de codes de programme pour exécuter toutes les étapes d'un procédé selon l'une des revendications 1 à 9 lorsque le programme d'ordinateur est exécuté sur un ordi- 25 nateur ou par une unité de calcul (2, 102), notamment une unité de calcul (2, 102) selon la revendication 10. 12 ) Produit programme d'ordinateur comportant des moyens de codes de programme enregistrés sur un support de données que peut lire un 30 ordinateur pour effectuer toutes les étapes selon un procédé de l'une des revendications 1 à 8 lorsque le programme d'ordinateur est exécuté sur un ordinateur ou une unité de calcul correspondante (2, 102), notamment une unité de calcul (2, 102) selon la revendication 10. 35