Brevet FR2822558A1 — publié le 20020927

La présente invention concerne un procédé de réalisation d'un calculateur qui implémente des fonctions de commande-contrôle. Plus particulièrement, l'invention concerne un procédé de conception d'une partie du calculateur, celle permettant la réalisation de ces fonctions. De tels calculateurs peuvent être utilisés à bord de véhicules automobiles, de satellites ou d'avions afin d'assurer le contrôle de divers organes ou équipements nécessaires au bon fonctionnement du véhicule ou par extension au déroulement de la mission assignée au système. De plus de tels calculateurs peuvent aussi se trouver dans une installation industrielle ou domotique devant gérer les ressources d'un bâtiment ou d'un ensemble de bâtiments. Ces calculateurs se caractérisent par le fait qu'il remplissent, entre autres, les fonctions suivantes : communication avec un autre calculateur local ou distant par l'intermédiaire d'un réseau, surveillance d'organes ou d'équipements dont il a la responsabilité, commande de ces organes en fonction d'ordres reçus par l'intermédiaire du réseau et en fonction de l'état du système et des anomalies détectées. Le procédé proposé est basé sur le regroupement de l'ensemble de ces fonctions dans une entité appelée coeur de commande-contrôle)). Ainsi le calculateur est découpé en trois couches : couche de communication et d'interface, coeur de commande-contrôle, application. La couche de communication et d'interface permet à la fois de gérer les interfaces avec les organes à contrôler et avec le réseau de communication. La couche application implémente des traitements spécifiques (tels par exemple dans un satellite le traitement des données scientifiques provenant d'un senseur). Entre ces deux couches, se trouve la couche contenant le coeur de commande-contrôle qui agit alors comme un filtre intelligent entre la couche d'interface et de communication et la couche application. Le document EP-0 881 553 révèle un système de contrôle autonome pour un véhicule spatial. Ce système intègre une structure proche de celle décrite ci-dessus. Le coeur de commande-contrôle apparaît comme une partie du calculateur pouvant être constituée de matériel ou de logiciel voire des deux selon les contraintes de réalisation du calculateur. Le coeur de commande-contrôle échange, via la couche d'interface et de communication, des paquets de données avec un utilisateur distant. Ces paquets permettent à l'utilisateur de faire parvenir des commandes ou de recevoir des informations sur l'état du système géré par le coeur de commandecontrôle . Ils permettent aussi de modifier les paramètres internes du coeur de commande-contrôle comme par exemple la liste des surveillances ou les seuils de déclenchement des alarmes. Le coeur de commande-contrôle a aussi pour fonction de générer des actuations/acquisitions auprès des équipements pilotés par le calculateur dans lequel il est intégré. Il commande alors les modes opérationnels de ces organes et assure l'acquisition de paramètres de surveillance. Afin de détecter les anomalies de fonctionnement (paramètre hors limite, dépassement de délai,...) et de commander des actions de sauvegarde correspondantes, le coeur de commande-contrôle surveille l'application ainsi que les équipements dont il a la charge. En cas d'anomalie des messages sont envoyés par l'intermédiaire de la couche d'interface et de communication vers l'utilisateur afin de lui permettre de décider des actions nécessaires L'idée d'un calculateur tel que décrit ci-dessus comportant un coeur de commande-contrôle trouve son origine dans les développements de calculateurs embarqués à bord de satellites. Par exemple un satellite d'observation de la Terre en orbite basse met en oeuvre une architecture informatique dans laquelle chaque charge utile (radar altimètre, radar imageur, enregistreur, etc...) est gérée de façon autonome par un calculateur dédié. Toutefois, les domaines d'application de tels calculateurs ne sont pas limités au spatial. Dans le domaine automobile, un tel calculateur peut trouver une application notamment dans la commande de divers équipements connectés par un bus multi-plexé (par exemple de type CAN). On pourrait également utiliser un tel calculateur dans le domaine aéronautique, dans des process industriels et aussi dans des dispositifs domestiques tels ceux intégrés dans des systèmes domotiques. Pour implémenter les fonctions remplies par un coeur de commande- contrôle, il faut actuellement, pour chaque nouvelle application, retravailler manuellement les diverses applications déjà existantes et modifier les logiciels correspondants. L'ensemble doit alors être recompilé et validé pour obtenir un logiciel opérationnel. La présente invention a alors pour but de fournir un procédé permettant d'automatiser la réalisation d'un coeur de commande-contrôle, que celui-ci soit implémenté sous forme logicielle ou sous forme matérielle. Elle permettra avantageusement de réduire les temps de développement et de certification d'une nouvelle application. De préférence, cette réalisation d'un coeur de commandecontrôle se fera avec un haut degré d'autonomie et de sécurité. A cet effet, elle propose un procédé de réalisation d'un coeur de commande-contrôle pour un calculateur embarqué dans un dispositif destiné à exécuter des fonctions à partir de commandes d'un utilisateur ou en fonction de paramètres mesurés par exemple par des capteurs. Selon l'invention, ce procédé comporte les étapes suivantes : - entrée de données spécifiques au dispositif recevant le calculateur, pour créer une base de données caractérisant les fonctions à exécuter par le dispositif, - choix dans une bibliothèque de briques de base paramétrées, chaque brique étant formée par un logiciel préalablement écrit de telle manière qu'il puisse s'interconnecter avec d'autres briques, - assemblage des briques selon un principe architectural prédéfini, - compilation de l'ensemble obtenu afin de produire un code source. Grâce à l'utilisation de briques de base paramétrées, il devient possible d'automatiser la procédure de réalisation d'un coeur de commande contrôle. Il suffit de prévoir une fois pour toutes des briques paramétrées qui peuvent se combiner les unes avec les autres pour n'avoir par la suite qu'à choisir les briques nécessaires et les combiner. Le paramétrage des briques de base écrites par exemple sous forme de modules logiciels en langage C++ consiste par exemple à définir le contenu des données d'interface de ces modules. Ce procédé présente l'avantage de pouvoir être automatisé et mis en oeuvre avec des ordinateurs mais il peut bien entendu également aussi être mis en oeuvre manuellement. Même mis en oeuvre manuellement, ce procédé permettrait de faciliter la tâche des programmateurs qui jusqu'à présent programment pour chaque nouvelle application un nouveau logiciel. Ils utilisent certes des programmes déjà existant ou des morceaux de ces programmes mais ils doivent les adapter à chaque fois et reprendre l'ensemble du programme du début à la fin pour s'assurer de la cohérence de l'ensemble ainsi réalisé. Avantageusement, le procédé de réalisation selon l'invention comporte en outre l'étape suivante : - à partir du code source obtenu, à l'aide d'un logiciel de conception assistée par ordinateur, réalisation d'un plan d'un circuit intégré pour une application spécifique (ASIC) implémentant tout ou partie des fonctions du coeur de commande-contrôle. Dans ce cas les briques de base écrites dans le langage C++ seront par exemple converties en langage VHDL. Dans ce cas, un circuit intégré peut être réalisé à partir du plan obtenu après synthèse du code VHDL obtenu. Pour garantir une bonne réalisation du procédé selon l'invention, après l'entrée des données, la cohérence et la complétude de l'ensemble de celles-ci sont de préférence validées. Pour tester le produit issu du procédé de réalisation selon l'invention dès les premières étapes de sa mise en oeuvre, un scénario d'utilisation du coeur de commande contrôle est avantageusement créé et le comportement du code source obtenu après configuration et assemblage des briques de base peut être simulé. Les caractéristiques et avantages de l'invention ressortiront d'ailleurs de la decrisption qui va suivre, à titre d'exemple, en référence au dessin schématique annexé sur lequel : La figure 1 est une vue schématique d'un calculateur intégrant un coeur de commande-contrôle, La figure 2 est une vue schématique d'ensemble d'un procédé selon l'invention, La figure 3 représente schématiquement une architecture d'un coeur de commande-contrôle. La figure 1 représente schématiquement un calculateur organisé en couches. Comme on peut le voir sur cette figure, ce calculateur comporte trois couches. La première couche est une couche d'interface et de communication qui permet à la fois de gérer les interfaces locales d'actuation/acquisition et de communiquer avec un utilisateur distant. Cette première couche comporte tout d'abord un interface actuaction/acquisition 2 qui permet au calculateur de communiquer et d'interagir avec des équipements 4. Cette couche d'interface et de communication comporte également un interface de communication 6 permettant au calculateur de communiquer avec l'utilisateur 8 par l'intermédiaire d'un réseau. La seconde couche constitue le coeur de commande-contrôle 10 du calculateur. Ce dernier agit comme un filtre intelligent permettant de séparer les applications des événements externes non pertinents (gestion du système de communication, gestion des actuations/acquisitions, configuration par l'utilisateur du coeur de commande-contrôle,...). Enfin, la troisième couche, appelée couche application 12, implémente des traitements spécifiques, par exemple traitements de données image,... etc. Cette architecture du calculateur permet d'isoler les fonctions de commande-contrôle qui ne dépendent ni du type d'application ni des interfaces de communication. Les fonctions de commande-contrôle gèrent les événements externes au calculateur (actuation, acquisition, message de l'utilisateur, etc...) et assurent la cohérence logique et temporelle de ces événements. Le coeur de commande-contrôle 10 peut ainsi se définir comme un système d'exploitation qui gère les ressources externes au calculateur alors qu'un système d'exploitation informatique classique gère la ressource interne du calculateur constitué par le processeur. Le coeur de commande-contrôle 10 utilise des ressources spécifiques de traitement et de mémorisation. Son couplage avec la couche application 12 est très faible et se limite autant que possible à une zone mémoire partagée et bien délimitée lors de la conception du calculateur. Une telle architecture de calculateur a été développée pour permettre d'augmenter la modularité des applications exécutées par le calculateur, augmenter la tolérance aux pannes et éviter la propagation d'erreur vers la couche application 12. Le coeur de commande-contrôle 10 permet l'échange des informations avec l'utilisateur 8. Ainsi, l'utilisateur peut envoyer des demandes opérationnelles et recevoir des informations sur l'état du système. Le coeur de commande-contrôle décode également les commandes qui lui sont destinées. Ces commandes ainsi interprétées permettent la génération de séquences d'actuation/acquisition auprès des équipements 4 ainsi que la modification éventuelle de paramètres opérationnels de la fonction de commande-contrôle ellemême. Enfin, le coeur de commande-contrôle 10 surveille les équipements 4 afin de détecter des anomalies de fonctionnement (paramètre hors limite, durée dépassée,...) et de commander des actions de sauvegarde en cas de problèmes. Un message d'anomalies peut être envoyer à l'utilisateur 8 afin de permettre la reconfiguration du système après détection d'une anomalie. Le procédé selon l'invention permet de générer un code source qui implémente les fonctions du coeur de commande-contrôle 10 et ce procédé permet également de réaliser tout ou partie du coeur de commande-contrôle sous forme matérielle. La figure 2 illustre schématiquement les différentes étapes d'une variante de réalisation d'un procédé selon l'invention. Sur cette figure est notamment représenté un ensemble d'outils informatiques pouvant être mis en oeuvre pour la réalisation de cette variante de réalisation du procédé selon l'invention. Un premier ordinateur 14, muni d'un logiciel correspondant, permet l'acquisition de données nécessaires à la définition et la configuration des fonctions du coeur de commande-contrôle 10. Cet ordinateur 14 construit une base de données 16 qui caractérise complètement l'application de commandecontrôle que l'on veut développer. Cet ordinateur 14 permet par ailleurs de vérifier la cohérence et la complétude des besoins exprimés par un concepteur communiquant avec cet ordinateur 14. En outre, ce premier ordinateur 14 permet d'acquérir un ensemble de scenarii fonctionnels 17 utilisés par la suite pour effectuer des validations par simulation. Un second ordinateur 18 est destiné à la gestion des paramètres de configuration. Il travaille à partir de la base de données 16 générée par le premier ordinateur 14 ainsi qu'à partir d'une bibliothèque 20 dans laquelle se trouvent des briques de base disponibles. En fonction des données collectées dans la base de données 16 et des briques disponibles dans la bibliothèque 20, l'ordinateur 18 configure chaque brique de base nécessaire pour réaliser le programme du coeur de commande-contrôle 10 et assemble toutes les briques de base ainsi paramétrées pour former l'architecture du coeur de commande-contrôle 10. Une fois toutes les briques de base paramétrées et assemblées, le second ordinateur 18 génère un code source 22. Ce code source 22 est utilisé avec les scenarii fonctionnels 17 par un troisième ordinateur 24, ou ordinateur de simulation. Cet outil informatique permet d'évaluer dès les phases initiales d'un projet l'utilisation des ressources du calculateur du point de vue de la commande-contrôle, c'est-à-dire communication, mémorisation, traitement, etc.... Cet ordinateur de simulation 24 permet également de valider des scenarii de mission prenant en compte les comportements des protocoles de communication et les mécanismes de commande-contrôle. En sortie de cet ordinateur de simulation 24, des références de test 26 fonctionnelles entrant dans le processus de certification finale du système utilisant le coeur de commande-contrôle 10 sont obtenues. Le code source 22 est également compilé pour donner un logiciel. Un ordinateur 28 de compilation est alors prévu à cet effet. On obtient alors un logiciel 30. Le code source 22 peut également être traité par l'ordinateur de compilation 28 pour obtenir les plans d'un microprocesseur 32 remplissant les mêmes fonctions que le logiciel 30. Pour produire le logiciel qui implémentera le coeur de commandecontrôle 10 ou pour réaliser l'ASIC remplissant tout ou partie de ces fonctions, un concepteur doit tout d'abord entrer des données propres à l'application souhaitée. L'interface avec le concepteur se fait par l'intermédiaire de formulaires génériques préparés à l'avance qui permettent l'acquisition de données de commande- contrôle. Ces formulaires défilent donc sur l'écran du premier ordinateur 14 et le concepteur remplit ces formulaires à l'aide du clavier de cet ordinateur. Le tableau ci-après donne un exemple de différents paramètres qui devront être fournis par un concepteur dans le cas où le calculateur est destiné à équiper une charge utile d'observation de la terre. Nature des paramètres Exemple de structures de données Liste des modes opérationnels enum modes {standby, standbyoff, warmupû, du sous-système géré par le warmuplon, warmup1off, warmup2on, coeur de commande contrôle warmup2off, pause, biteon,........., nbmodes} ; Liste des durées min et max de const time delaytransition [nbmodes][nbmodes]= chaque transition entre les {{nc, 10, 50, 20,...}, {30, 30, 200,..... modes et Liste des durées min/max de chaque mode Matrice des transitions de const modes transitionmode [nbmodes] [nbra] = {standby, warmup0, standby, warmuploff, mode autorisées et liste des warmup2on, warmup2off, standby, standby, commandes permettant standby, biteon, standby,},... d'effectuer ces transitions Liste des commandes enum sequences {nul, seq1, seq2, seq3, seq4, équipement et des acquisitions seq5, seq6, seq7, seq8, seq9, seq10, seq11, de télémétries entre chaque seq12, seq13, transition de mode. Liste des macro-commandes enum statusmacro {go~standby, gowarmup0, pouvant être interprétées par go~warmup1on, go~warmup1off,....) le coeur de commandecontrôle. Liste des acquisitions enum telemetries {icutemp, icuvoltage, temp1, élémentaires (télémétries) temp2, mwssvoltagepluscinq, mwssvoltagemoinscinq, usovoltage, spsavoitagepluscing, spsavoltagemoinscinq, Matrice de l'état des const minvalue [nbmodes] [nbtelemeties] = équipements dans chaque { {{nc, 10, 20, 300.....}, mode (ON/OFF) et seuils de surveillance (min/max) des acquisitions élémentaires pour chaque mode Liste des actuations enum Isccommands {usoaboff, usoaon, osobon, mwssabonoff, mwssaon, mwssbon, élémentaires (commandes). spsaaboff, spsaaon, spsabon, Ivpsaover, Ivpsaen, Ivpsbover, Ivpsben, Une fois tous les paramètres définis par le concepteur dans le premier ordinateur 14, celui-ci les stocke dans la base de données 16. La bibliothèque 20 comporte un certain nombre de briques de base pouvant s'interconnecter selon un principe architectural prédéfini par des structures des tables génériques qui sont configurées en fonction du contenu de la base de données 16. Les briques présentes dans la bibliothèque doivent permettre de couvrir l'ensemble des besoins qui peuvent se présenter, ou tout du moins la plus grande partie de ces besoins. Les briques de base sont pré-développées dans un langage informatique de type C++ ou VHDL. L'abréviation VHDL est utilisée pour désigner un Very High Speed Integrated Circuit (VHSIC) Hardware Description Language. Il s'agit donc d'un langage informatique permettant de décrire un circuit intégré numérique. Les briques de base sont écrites de manière paramétrée et aussi de manière à pouvoir venir se raccorder à d'autres briques pour former un ensemble cohérent. Selon les briques de base disponibles dans la bibliothèque 20 et les données fournies par le concepteur et répertoriées dans la base de données 16, le second ordinateur 18 permet de choisir dans la bibliothèque les briques de base qui seront nécessaires à la réalisation du coeur de commande-contrôle 10. Ces briques sont complétées pour les adapter aux données présentes dans la base de données 16 et sont assemblées. Ce second ordinateur 18 permet également de vérifier la faisabilité d'une implémentation. La gestion des paramètres de configuration se fait au sens large puisque l'ordinateur 18 gère aussi bien la configuration opérationnelle relative à la mission décrite par le concepteur que la configuration des briques de base (configuration des produits logiciels/matériels, et que la configuration de l'architecture obtenue c'est-à-dire l'architecture du coeur de commande-contrôle 10). Tout changement survenu dans l'une de ces configurations doit pouvoir être géré et retracé. De plus, il faut pouvoir vérifier que les règles d'assemblage des briques de base sont respectées et que la configuration du coeur de commande-contrôle demandée par le programmateur est possible avec les briques de bases disponibles dans la bibliothèque 20. Le code source 22 obtenu en sortie du second ordinateur 18 est un modèle comportemental du coeur de commande-contrôle 10 qui sert de base à la réalisation de ce coeur de commande-contrôle. Ce code source est par exemple également rédigé en langage informatique C++. A partir de ce code source 22, l'ordinateur de compilation 28 réalise l'interface avec des outils de conception micro-électroniques ou des outils de conception de logiciels. Ainsi, dans le premier cas, le code source 22 permet de réaliser un ASIC (pour Application-Specific Integrated Circuit ou circuit intégré pour une application spécifique). Pour cela, on utilise par exemple des logiciels de conception assistés par ordinateur pour la réalisation d'un circuit intégré spécifique à une application. De tels logiciels sont connus de l'homme du métier. Ils permettent de réaliser les plans d'un microprocesseur puis celui-ci peut être réalisé à l'aide de ces plans. On retrouve alors dans l'ASIC final les codes source des briques de base utilisés avec leur configuration spécifique. Dans le second cas, le code source 22 est compilé pour obtenir un logiciel. Selon le domaine de mise en oeuvre, l'application de commandecontrôle sera implémentée sous forme purement logiciel, purement matérielle ou bien sous forme mixte c'est-à-dire en partie matérielle et en partie logicielle. Le partage matériel/logiciel dépend du domaine d'application et des contraintes d'implémentation. Dans certains cas, la plate-forme matérielle est imposée et il s'agit donc de produire du logiciel uniquement. Dans d'autres cas, il est adéquat de développer tout ou partie du matériel sous forme d'une puce complexe. Dans ce dernier cas, le coeur de commande-contrôle 10 est un sous-ensemble de cette puce complexe. La figure 3 montre un exemple d'architecture de coeur de commandecontrôle 10. Cet exemple peut par exemple être adapté à un coeur de commandecontrôle embarqué dans une charge utile de satellite. Cette figure montre le flux de données dans le coeur de commande-contrôle 10. Le coeur de commande-contrôle tel que représenté a six fonctions réparties en deux catégories : - des fonctions de gestion des interfaces externes : acquisition cyclique des paramètres à surveiller (bloc 34), acquisition des macrocommandes provenant de l'utilisateur (bloc 36) et exécution des actuations vers les équipements (bloc 38) - des fonctions de haut niveau : surveillance du sytème et analyse des anomalies (bloc 40), interprétation des commandes utilisateur (bloc 42) et prise de décision pour la génération d'actuations (bloc 44). La communication entre les six fonctions génériques du coeur de commande-contrôle 10 se fait par l'intermédiaire d'une base de données système. La fonction"gestion des acquisitions"34 doit assurer l'acquisition cyclique d'une liste de paramètres accessibles par l'interface avec les équipements 4. Des paramètres possibles sont par exemple : mesure d'une valeur analogique (température, courant, tension,...), état d'un relais (ouvert/fermé, valeur numérique, etc...). Les acquisitions sont faites à partir des adresses de paramètres 46 qui est une liste des adresses à parcourir pour obtenir les mesures nécessaires au bon fonctionnement du coeur de commande-contrôle 10. Cette fonction"gestion des acquisitions"génère une table des acquisitions 48 dans laquelle pour chaque adresse sont indiquées les valeurs mesurées. Cette table des acquisitions 48 est datée. L'acquisition des différentes mesures est faite de façon cyclique. Ce cycle peut être variable et compris par exemple entre 125 ms et 16 secondes dans le cas d'une charge utile satellite. Les mesures doivent être cohérentes dans le temps et la liste des acquisitions est faite en rafale en début de cycle. Les actuations sont des événements élémentaires qui donnent lieu à l'activation d'une interface vers les équipements 4 pour commander un élément externe tel par exemple un relais. La gestion des actuations assure l'exécution séquentielle des actuations à partir d'une table prédéfinie : c'est la table des actuations 50. Chaque entrée de la table 50 correspond à un événement sur les interfaces. La fonction"gestion des actuations"38 exécute pas à pas les événements inscrits dans la table des actuations. Le début d'exécution de la table 50 peut se faire à une heure de bord prédéfinie. Une table d'actuation contient par exemple un nombre maximum d'événements égale à 30. Un chronomètre est associé à la durée totale d'exécution de la table et en cas de dépassement d'un temps prédéterminé un message d'erreur est généré. Pour l'acquisition des commandes provenant de l'utilisateur (36), il est prévu d'utiliser un interface de communication 52. On suppose que l'interface de communication se fait par l'échange de paquets de données. On retrouve alors au niveau du bloc 36 les fonctions suivantes : dé-formatage des paquets reçus, formatage des paquets envoyés, génération d'une requête d'émission de paquets, et gestion de la queue d'attente des paquets. Les paquets de commande reçus de l'utilisateur 8 contiennent un champ qui correspond à la date d'exécution. Cette date est soit immédiate (dès réception) soit égale à une heure différée. Dans le cas d'une heure différée, le paquet est inséré dans une queue et sera activé à la date d'échéance. Un tampon de stockage 54 est prévu entre le bloc fonction 36 et l'interface de communication 52. Le bloc 42 d'interprétation de macro-commandes reçoit des paquets de données 56 par l'intermédiaire de la couche de communication. Ces données correspondent à des commandes générées par l'utilisateur 8. Ces commandes sont de trois types différents et correspondent à trois traitements différents : - changement de mode : cette commande est éxécutée par le coeur de commande-contrôle et il lui correspond à l'activation de la table d'actuation correspondante, - changement de paramètre du coeur commande-contrôle ou activation/désactivation de fonction, et - données 58 à destination de la couche application 12. On trouve donc en sortie du bloc 42 soit une demande d'activation d'une table d'actuation adressée alors au bloc 44, soit des paramètres mis à jour 60, soit un paquet de données 58 à destination de la couche application 12. La fonction de surveillance représentée schématiquement par le bloc 40 permet la génération d'alarmes. A partir des mesures 48 fournies par la gestion des acquisitions 34 la fonction de surveillance compare chaque mesure par rapport à des seuils (minimum et maximum) ou à des valeurs attendues. S'il y a un dépassement de seuil ou une anomalie, une alarme est générée. Le système surveillé se trouve soit dans un mode opérationnel, soit en transition entre deux modes opérationnels soit encore en état d'anomalies. La détection d'anomalies se fait en comparant l'état dans lequel devrait être le système avec l'état dans lequel il est. Un processus de filtrage, par exemple par prise de plusieurs mesures, doit permettre de ne pas déclencher d'alarmes intempestivement, par exemple déclencher une alarme suite à une mesure anormale (bruit). Les données entrant dans le bloc 40 proviennent des tables des acquisitions 48 générées par le bloc 34 et aussi d'une base de données 62 regroupant les seuils (mini/maxi) et les valeurs attendues. Les alarmes générées par ce bloc 40 de surveillance sont dirigées vers le bloc 44 de décision. Le bloc 44 représentant la fonction de décision reçoit, comme indiqué ci-dessus, des messages de la fonction interprétation 42 et de la fonction surveillance 40. La logique de décision est par exemple celle résumée dans la table cidessus : Etat surveillance Etat interprétation Action prise Inchangé Inchangé Aucune Active la table de reconfiguration Alarme Inchangé correspondant au mode actuel et à l'alarme Refuse l'exécution paquet (mcmd refuse Alarme Exécution paquet mode) et active la table de reconfiguration correspondant au mode actuel et à l'alarme Active la table de changement de mode Inchangé Exécution paquet correspondant à la macro-commande contenue dans le paquet En sortie, la fonction décision génère une table d'événements 50 et produit un historique 64 des décisions pour en informer l'utilisateur 8. Le procédé ci-dessus permet de générer de façon automatique des coeurs de commande-contrôle sous forme logiciel ou matérielle. Ainsi, ce procédé permet un gain de temps très sensible par rapport à l'élaboration manuelle d'un code source puis sa compilation pour obtenir un coeur de commande-contrôle. L'originalité à la base du procédé selon l'invention consiste en fait à concentrer l'offre sur une fonction générique : la commande contrôle, et à traiter sa conception de façon automatique dans toutes les phases du cycle de vie du système, alors qu'aujourd'hui les outils sont spécialisés sur une technologie (logiciel, matériel,...) ou sur une phase du cycle de vie (conception du système, conception de l'équipement, conception de la carte,...). La rationalisation du processus de conception et de développement du coeur de commande-contrôle permet de réduire notablement les coûts de développement, d'intégration et de validation d'un nouveau système. Les fonctions remplies par le coeur de commande-contrôle apparaissent dans de nombreuses applications embarquées, non seulement dans le domaine spatial, mais aussi dans le domaine automobile, domotique, les process industriels,.... Le procédé selon l'invention fournit au concepteur d'application de commande-contrôle un environnement de développement prédéfini correspondant à son domaine d'application et permettant de générer automatiquement les fonctions de commande-contrôle. La démarche à suivre par le concepteur est tout à fait différente de celle qui est la sienne lorsqu'il développe manuellement les fonctions de commande-contrôle. Il lui suffit ici de renseigner avec soin des tableaux prédéfinis pour exprimer ses besoins et il obtient par la suite un code source qu'il peut mettre en oeuvre industriellement. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites et représentées, mais englobe toute variante d'exécution et/ou combinaison de leurs divers éléments, dans le cadre des revendications ci-après. Un exemple non limitatif de coeur de commande-contrôle et de briques de base en langage C++ est donné ci-après. 1. 1 Brique de base acquisition 1. 1. 1 Fonctions Le module acquisition a pour fonctions : de récupérer et de mémoriser les données de mesure provenant des capteurs d'entrée, de surveiller le comportement des mesures et de déclencher en cas d'erreur (dépassement de seuil) un changement de mode au niveau du module Macro. 1.1. 2 Interfaces du module "acquisition" : Les interfaces du module acquisition sont les suivantes : # CLOCK # DATE > MODEGEN (out) : sortie de déclenchement d'un changement de mode > TELEM (in) : entrées provenant des capteurs externes (télémétries) La déclaration des interfaces du module acquisition en C++ est la suivante : SC~MODULE (acquisition) { scin clock ; sc-out modegen ;//chgt de mode si dépassement de seuils sc-in telem [nbtelemetries] ; sc~in date ; void acqtele () ; SCCTOR (acquisition) {SC~METHOD (acq~tele) ; sensitive~pos clock ;} } ; 1.1. 3 Algorithme du module "acquisition" Pour chaque télémétrie : effectuer l'acquisition (mémorisation de la valeur en entrée) selon le taux requis et si l'entrée est validée. tester selon la catégorie d'entrée : - la validité des états possibles de la valeurs lue - le dépassement d'un seuil - l'appartenance a un domaine de valeurs - le dépassement d'un double seuil avec changement de mode pour le second seuil > comptabiliser les dépassements de seuil pour mémorisation dans l'historique au-delà d'une certaine valeur avec incrément du compteur d'anomalies. retourner a la normale après dépassement de seuil mémorise dans l'historique. mémoriser la valeur lue et des min et max des valeurs précédentes et de leur date. stocker au taux voulu la valeur dans un tableau si mémorisation d'une série de valeurs, avec mémorisation de la date de début. 1. 2Module macro 1. 2. 1 Fonctions Le module macro analyse et gère les macro-commandes formatée en provenance de la couche de communication. Chaque macro-commande est analysée (vérification de l'entête) puis exécutée le moment venu. Le traitement d'une macro-commande conduit selon le type de macrocommande soit à un changement de mode, soit à la configuration d'éléments du système comme par exemple les seuils des télémétries. Un changement de mode conduit a l'exécution d'une séquence de microcommandes. 1.2. 2 Interface du module "macro" Les interfaces du module macro sont les suivantes : > CLOCK DATE RESET : reset du buffer de macro lors d'une nouvelle macro prioritaire (signal interne !) REDDEFA (out) : définition de la redondance entre instruments A et B SEQ (out) : séquence de microcommandes a exécuter STARTSEQ (out) : déclenche une séquence de microcommandes USERCMD (out) : 1 microcommande a exécuter > STARTCMD (out) : déclenche 1 microcommande MODEGEN (in) : déclenchement d'un changement de mode BUFMACRO (in) : 1 macro-commande a exécuter > LOADMACRO (in) : ordre d'exécution d'une nouvelle macro-commande SCMODULE (macro) { scinout seq ;//séquence de microcommandes à exécuter sc inout reddefa ; définition de la redondance entre instruments A et B sc~inout startseq ;//déclenche une séquence de microcommandes sc~out usercmd ;//microcommande a exécuter sc~inout startcmd ;//déclenche une microcommande scin bufmacro [taillebuf] ;//macrocommande sc~inout date ; sc~inout modegen ;//déclenche un changement de mode sc~in loadmacro ;//nouvelle macro à analyser sc~inout reset Il si macro prioritaire alors reset des pointeurs de la FIFO sc~in~clk clock ; modes currentmode ;//modes courant header *head, *headtmp ; ptr d'entête de macrocommande short fifo [taillefifo] [taillebuf] ;//FIFO de macrocommandes à exécuter int ecr ;//ptr d'écriture dans la FIFO int lec ;//ptr de lecture dans la FIFO void analyse-macroo ; void traitemacro () ; SCCTOR (macro) { SCMETHOD (analyse-macro) ; sensitive loadmacro ; SC~CTHREAD (traitemacro, clock. pos ()) ; } } ; 1. 2. 3 Algorithmes du module "macro" Fonction analyse macro : déclenchée par LOADMACRO. tester les champs de l'entête. incrément du compteur d'anomalies en cas d'erreur. insérer la nouvelle macro dans la FIFO et faire progresser ses pointeurs. détermination de la catégorie de la macro en fonction de son identificateur dans son entête. reset si conflit entre macro en cours et nouvelle macro. Fonction traite macro : si demande de changement de mode ou de switchdown alors passage en mode standby. parcours de la FIFO a la recherche de la prochaine macro a exécuter (en fonction de sa date d'exécution). si macro trouvée, l'indiquer dans l'historique, la retirer de la FIFO et l'exécuter. selon l'identificateur de l'entête de la macro, exécuter : - set monitoring : définition des paramètres des entrées à scruter - inhibit/enable monitoring : validation/invalidation de la scrutation - switch-down enablelinhibit - reset history - complément de redondance entre A et B - direct command : microcommande directe - time-code (resynchronisation) : mise a jour de DATE - enable non-nominal telemetries : définition du taux de stockage des échantillons - inhibit non-nominal telemetries - event macrocommands : changement de mode génération d'un changement de mode si la durée de transition ou de mode est non conforme déclenchement de la séquence de microcommandes correspondant a cette nouvelle transition et attente de sa fin d'exécution. changement effectif de mode et mise a jour de l'historique. 1. 3Module actuation 1. 3. 1 Fonctions Le module actuation se charge uniquement d'exécuter les séquences de microcommandes pilotant les sorties (commandes externes). Ces séquences sont fournies par le module macro, soit lors d'un changement de mode soit du fait de l'analyse du macrocommande. Ce module est chargé de générer des pulses sur les sorties en fonction de microcommandes dont la séquence dépend du mode de fonctionnement du système. Ce module déroule une séquence et pour chaque microcommande et pilote les sorties correspondantes. 1.3. 2 Interface du module"actuation" CLOCK SEQ (in) Il séquence de microcommandes à exécuter USERCMD (in) 11 1 microcommande à exécuter REDDEFA (in) définition de la redondance entre instruments A et B STARTSEQ (in) Il déclenche une séquence de microcommandes STARTCMD (in) Il déclenche 1 microcommande SOUT (out) Il tableau de signaux de commande externes SC~MODULE (actuation) { sc-in seq ;//séquence à exécuter sc~in usercmd ;//microcommande a executer sc-inout startseq ;//déclenchement d'une séquence sc~inout startcmd ;//déclenchement d'une microcommande scin clock ; sc~in reddefA ;//redondance entre A et B sc-out sout [nblsccommands] ;//sorties puisées int ind ; void sendcmd () ; sensitive startseq ; sensitive startcmd ; sensitivepos clock ;} } ; 1.3. 3 Algorithme du module"actuation" Fonction sent cm > si ordre d'exécution d'une séquence (STARTSEQ) alors parcours de la séquence et exécution de chaque microcommande en générant un créneau de durée liée a la sortie activée. > si ordre d'exécution d'une seule microcommande (STARTCMD) alors génération du créneau sur la sortie voulue. Structure de données La structure des données utilisée dans le coeur de commande-contrôle regroupe l'ensemble des données devant être fournies par l'utilisateur. La configuration des briques de base formant le coeur de commande-contrôle consiste simplement à expliciter les données contenues dans cette. Le logiciel de configuration doit simplement traduire les entrées utilisateur en des structures de données compatibles correspondant à la syntaxe décrite dans les paragraphes ci-dessous : Liste des modes Liste des macrocommandes # Liste des transitions entre modes Durée des transitions entre modes Catégories de macro # Long Switch closure commands Telemetries # Séquences de micro-commandes # Types d'entrées dans l'historique Constantes #include #include typedef int time ; const time TBD = 0 ; const time ne = 0 ; const int nbmodessupport = 10 ; nib de mode de type SUPPORT (avec durée à tester) const int delayintercmd = 2 ; nib de tops entre 2 microcommandes 1. 4 Liste des modes enum modes {standby, standbyoff, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, biteon, biteoff, groundcalibration, flightcalibration, presetocean, presetice, oceanacq, iceacq, trackingocean, trackingice, nbmodes} ; 1. 5Liste des macrocommandes enum statusmacro {go~standby, gowarmup0, gowarmuplon, gowarmuploff, go~warmup2on, go~warmup2off, go~pause, gogroundcalibration, go~uso~onoff, go~bite, go~presetocean, go~presetice, go~oceanacq, go~iceacq, gotrackingocean, go~trackingice, go~flightcalibration, nbstatusmacro} ; enum refmacro {ra4, ral6, ral7a, ral7b, ral8a, ral8b, ral9, ra20, ra21, ra22, ra23, ra24, ra25, ra26, ra27, ra28, ra29, rai, ra2, ra3, ra5, ra6, ra7, ra8, ra9, ra10, rail, ral2, ral3, ral4, ral5, nbref} ; const refmacro nbra=ral ; enum eventmacro {setmonitoring, inhibitmonitoring, enablemonitoring, rsstesting, inhibitswitchdown, enableswitchdown, resetcommanding, icuresethistory, redundancydefinition, directcommand, timecode, patchspsa, dumpspsa, raparametersetting, nbeventmacro} ; 1. 6Liste des transitions entre modes const modes transitionmode [nbmodes] [nbra] = { {standby, warmupO, standby, standby, standby, standby, standby, standby, standbyoff, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, standby, warmuplon, warmuploff, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, standby, warmuploff, warmup2on, warmup2off, standby, standby, standby, biteon, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, standby, warmup2on, warmup2off, standby, standby, standby, biteon, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, standby, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, standby, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, standby, groundcalibration, standby, standby, trackingocean, trackingice, trackingocean, trackingice, standby, standby, flightcalibration}, {standby, warmupO, warmuplon, warmuploff, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}, {standby, warmupO, warmuplon, warmuploff, warmup2on, warmup2off, pause, standby, standby, standby, standby, standby, standby, standby, standby, standby, standby}} ; 1. 7Durées des transitions entre modes const time delaytransition [nbmodes] [nbmodes] = { {nc, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, nc, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, nc, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, nc, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, nc, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, nc, 250,250, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, 250, nc, 250, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, 250,250, 250,250, 250, nc, TBD, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc, TBD, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc, TBD, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc, TBD, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc, TBD, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc, TBD}, {TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, TBD, nc} } i enum categoriemacro {catstandby, heater, statusmacro, eventmacro, nbcategoriemacro} ; const categoriemacro categoriestatusmacro [nbstatusmacro] = {catstandby, heater, heater, heater, heater, heater, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro, statusmacro} ; enum actionconflit {cont, aborted, nbactionconflit} ; const actionconflit conflitmacro [nbcategoriemacro] [nbcategoriemacro] = { {cont, cont, cont, cont}, {aborted, cont, cont, cont}, {aborted, aborted, cont, cont}, {aborted, aborted, aborted, cont} } ; 1. 8Long Switch Closure Commands enum lsccommands {usoaboff, usoaon, osobon, mwssabonoff, mwssaon, mwssbon, spsaaboff, spsaaon, spsabon, Ivpsaover, Ivpsaen, Ivpsbover, Ivpsben, hpaahvoff, hpabhvoff, hpaahvon, hpabhvon, hpaafilon, hpabfilon, hpaafiloff, hpabfiloff, rfswitchlon, rfswitchloff, rfswitch2on, rfswitch2off, txa, txb, inta, intb, dmaresetA, dmaresetB, nblsccommands enum lsccommandsID {ide, id2, id3, id4, id5, id6, id7, id8, id9, idle, idll, idl2, idl3, idl8, idl9, id20, id21, id22, id23, id24, id25, idl4, idl5, idl6, idl7, id26, id27, id28, id29, id30, id31, nblsccommandsID, idO} ; //enum loadmemory {spsaml, nbloadmemory} i 1. 9 Telemetries enum telemetries {icutemp, icuvoltage, templ, temp2, mwssvoltagepluscinq, mwssvoltagemoinscinq, usovoltage, spsavoltagepluscinq, spsavoltagemoinscinq, spsavoltageplussix, usotempA, sawdelaylinetempA, transmittedpowerA, temperatureA, usotempB, sawdelaylinetempB, transmittedpowerB, temperatureB, nbtelemetries} i enum telemetriesID {nb3, nb4, nbl, nb2, nb5, nb6, nb7, nb8, nb9, nblO, nbll, nbl3, nbl5, nb33, nbl2, nbl4, nbl6, nb34, nbtelemetriesID} ; const time minmodetime [nbmodessupport] = {24*3600*1000, ne, 3*60000, 6*60000, 6*60000, 2*60000, 2*60000, TBD, TBD, TBD 1 ; const time maxmodetime [nbmodessupport] = {ne, ne, ne, ne, ne, 20*60000,20*60000, 10*1000, ne, ne} ; enum sequences {nul, seql, seq2, seq3, seq4, seq5, seq6, seq7, seq8, seq9, seqlO, seqll, seql2, seql3, nbsequences} ; const sequences transitionseq [nbmodes] [nbref] = { {nul, seq6, nul, nul, nul, nul, nul, nul, seql2, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {nul, nul, nul, nul, nul, nul, nul, nul, seql3, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, nul, seq7, seq8, nul, nul, nul, nul, nul, seqll, seq2, seq2, seq2, seq2, seq2, seq2, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, nul, seq8, seq9, seqlO, nul, nul, nul, seq2, seq2, seq2, seq2, seq2, seq2, seq2, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seq1, seq6, seq7, nul, seq9, seqlO, nul, nul, nul, seqll, seq2, seq2, seq2, seq2, seq2, seq2, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seq1, seq6, seq7, seq8, nul, seqlO, seq2, nul, nul, nul, seq2, seq2, seq2, seq2, seq2, seq2, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, seq9, nul, seq2, nul, nul, nul, seq2, seq2, seq2, seq2, seq2, seq2, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seq1, seq6, seq7, seq8, seq9, seqlO, nul, seq2, nul, nul, seq2, seq2, seq2, seq2, nul, nul, seq2, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seq1, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, seq2, seq2, seq2, seq2, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seq1, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, seq2, seq2, seq2, seq2, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, seq2, seq2, seq2, seq2, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul}, {seql, seq6, seq7, seq8, seq9, seqlO, seq2, nul, nul, nul, nul, nul, seq2, seq2, seq2, seq2, nul, nul, nul, nul, seq2, seq3, seq4, nul, nul, seq5, nul, nul, nul} Lconst int delay [nblsccommands] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, delay des microcommandes 1. 10 Séquences de micro-commandes //séquences de microcommandes en fonction de la redondance const lsccommandsID cmd [nbsequences] [2] [10] =//A, B { { {idO, idO, idO, idO, idO, idO, idO, idO, idû, ido}, {idO, idO, idO, ido, idO, idO, idO, idO, idO, indo}}, { {nid4, id7, id22, id23, ide, idO, ide, idO, idO, idO}, { id4, id7, id22, id23, idO, indo, idO, ido, idO, ide}}, { {nid26, id27, id28, id29, id30, id31, idO, idO, idO, idO}, { id26, id27, id28, id29, id30, id31, idO, idO, idO, ido}}, { {idlO, idO, idO, idO, idO, idO, ido, idO, idO, idO}, { idl2, idO, idO, ide, idO, idO, idO, idO, idO, ide}}, { {idll, idO, idO, idO, ido, idO, ido, idO, idO, idO}, { idl3, idO, idO, ide, idO, idO, idO, idO, idO, ide}}, { {idl5, idl7, ido, idO, idO, idO, idO, idO, idO, idO}, { idl4, idl6, ide, idO, idO, idO, ide, idO, ide, idole, { {nid4, id7, idl8, id24, ide, idO, idO, idO, idO, ide}, { id4, id7, idl9, id25, idO, ide, idO, ide, idO, idol ides, id7, idl8, id26, id27, id28, id29, id30, id31, idO}, { id6, id7, idl9, id26, id27, id28, id29, id30, id31, ide}}, { {id5, id8, idl8, idO, idO, idO, idO, idO, idO, idO}, { id6, id9, idl9, ide, idO, idO, idO, idO, idO, ide}}, { {nid7, id20, idO, idO, ide, idO, idO, ide, idO, idO}, { id7, id21, idO, ide, idO, idO, idO, idO, idO, indo}}, { {nid8, id20, id26, id27, id28, id29, id30, id31, ide, idol, { id9, id21, id26, id27, id28, id29, id30, id31, idO, ide}}, { {id8, id26, id27, id28, id29, id30, id31, idO, idO, idO}, { id9, id26, id27, id28, id29, id30, id31, idO, ide, ide}}, { {idl, idO, idO, idO, idO, idO, idO, idO, idO, id0}, { idi, idO, idO, idO, ide, idO, ide, ide, ide, idole, { {id2, idO, idO, idO, idO, idO, ido, idO, idO, idO}, { id3, idO, idO, idO, idO, ide, idO, ide, idO, idole } ; 1. 11 Constantes const int taillebuf=20 ;//buffer intermédiaire pour 1 macrocommande a analyser const int taillefifo=8 ;//fifo de macrocommandes const int infini=1000000000 ;//date d'exécution de macrocommande == annulee const int beginval=202 Il 3 champs des macrocommandes const int endval=101 ; const int destval=303 ; const int maxnbsamples=512 ;//samples de non-nominal telemetries REVENDICATIONS 1. Procédé de réalisation d'un coeur de commande-contrôle (10) pour un calculateur embarqué dans un dispositif destiné à exécuter des fonctions à partir de commandes d'un utilisateur (8) ou en fonction de paramètres mesurés par exemple par des capteurs (4), caractérisé en ce qu'il comporte les étapes suivantes : - entrée de données spécifiques au dispositif recevant le calculateur, pour créer une base de données (16) caractérisant les fonctions à exécuter par le dispositif, - choix dans une bibliothèque (20) de briques de base paramétrées, chaque brique étant formée par un logiciel préalablement écrit de telle manière qu'il puisse s'interconnecter avec d'autres briques, - assemblage des briques selon un principe architectural prédéfini, - compilation de l'ensemble obtenu afin de produire un code source (22). 2. Procédé de réalisation selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape suivante : - à partir du code source (22) obtenu, à l'aide d'un logiciel de conception assistée par ordinateur, réalisation d'un plan d'un circuit intégré pour une application spécifique (ASIC) implémentant tout ou partie des fonctions du coeur de commande-contrôle. 3. Procédé de réalisation selon la revendication 2, caractérisé en ce qu'un circuit intégré est réalisé à partir du plan obtenu. 4. Procédé de réalisation selon l'une des revendications 1 à 3, caractérisé en ce qu'après l'entrée des données, la cohérence et la complétude de l'ensemble de celles-ci sont validées. 5. Procédé de réalisation selon l'une des revendications 1 à 4, caractérisé en ce que les briques de base sont sous forme VHDL. 6. Procédé de réalisation selon l'une des revendications 1 à 5, caractérisé en ce qu'un scénario d'utilisation (17) du coeur de commande-contrôle (10) est créé et en ce que le comportement d'un code source obtenu après configuration et assemblage des briques est simulé.