Brevet FR3025036A1 — publié le 20160226

Procédé de traitement automatique d'un code source en vue de sa certification aéronautique ; produit programme d'ordinateur associé. L'invention a pour domaine celui des logiciels dans le domaine avionique. L'exécution d'une application logicielle sur une plateforme informatique embarquée à bord d'un aéronef permet de fournir une fonctionnalité particulière. Certaines fonctionnalités sont vitales pour la sureté de fonctionnement de l'aéronef. Il faut pouvoir garantir la bonne exécution d'une application logicielle embarquée, en particulier lorsqu'elle fournit une fonctionnalité vitale. Il est ainsi nécessaire de mettre en oeuvre un processus de certification pour chaque application logicielle embarquée. La certification d'une application logicielle embarquée induit différentes contraintes. En particulier, une application logicielle fournissant une fonctionnalité vitale pour l'aéronef doit être conforme à un niveau élevé de certification, qui définit des contraintes relatives à la manière d'écrire le code source de cette application logicielle. Dans ce qui suit, ces contraintes, relatives à la manière d'écrire le code source d'une application logicielle embarquée devant être certifiée, sont dénommées contraintes avioniques d'écriture. Parmi les contraintes avioniques d'écriture, il faut notamment que le code source ne contienne pas de code mort lié à la compilation, c'est-à-dire un ensemble d'instructions inutiles au sens où elles ne sont pas traitées par le compilateur lors de la compilation du code source afin de générer le code binaire. En effet, ces instructions inutiles complexifient le code source, qui devient alors difficilement lisible. De ce fait, la compréhension du code source ou sa maintenance deviennent difficiles. A cause de l'existence de ces contraintes avioniques d'écriture, le code source d'une application logicielle embarquée est spécifiquement écrit (c'est-à-dire développé) pour fournir la fonctionnalité correspondante à bord d'un aéronef. Ainsi, à l'heure actuelle, si l'on souhaite réutiliser (c'est-à-dire porter) dans le domaine avionique un code source qui existe déjà pour une fonctionnalité particulière, mais qui a été développé sans prendre en compte les contraintes avioniques, en particulier les contraintes avioniques d'écriture, il est nécessaire de reprendre entièrement et manuellement ce code source de manière à le modifier pour qu'il respecte les contraintes avioniques d'écriture et que l'application logicielle correspondante puisse être certifiée. 3025036 2 Cependant, la reprise manuelle d'un code source existant n'est envisageable que si la taille de celui-ci n'est pas trop importante. Par exemple, il n'est pas envisageable de porter dans le domaine avionique un système d'exploitation grand public, tel que le système d'exploitation « Linux ». Le code 5 source du noyau de ce système d'exploitation contient en effet plus de quatorze millions de lignes, ce qui rend impossible toute reprise manuelle en vue de garantir le respect des contraintes avioniques d'écriture et de passer avec succès les étapes du processus de certification relatives à la certification du code source. L'invention a donc pour but de pallier ce problème. 10 L'invention a pour objet un procédé de traitement automatique d'un code source initial, écrit dans un langage de programmation du type C ou C++, pour générer un code source simplifié respectant des contraintes avioniques d'écriture requises par un processus de certification, le procédé comportant les étapes consistant à : - suite à une analyse textuelle des fichiers de programmation et des fichiers de 15 commandes du code source initial, à générer : - une liste des fichiers de programmation utiles à la compilation parmi lesdits fichiers de programmation ; et, - un graphe d'appel des constantes et des fonctions définies par des directives de compilation contenues dans lesdits fichiers de programmation, 20 - marquer des noeuds dudit graphe d'appel qui correspondent à des constantes ou des fonctions qui sont utiles pour la compilation d'au moins un desdits fichiers de programmations utiles, et - à recopier les instructions desdits fichiers de programmation utiles, de manière à constituer des fichiers de programmation du code source simplifié, en ne recopiant pas 25 les instructions qui correspondent à des définitions de constantes ou de fonctions qui, d'après le graphe d'appel, ne sont pas utiles à la compilation. Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : 30 - le procédé comporte une étape d'interprétation des fichiers de commandes « Makefile » (MF) du code source initial pour générer une liste des commandes ; - le procédé comporte une étape de localisation des instructions utiles dans les fichiers de programmation du code source initial à partir de la liste des commandes, de manière à générer au moins une liste de fichiers de programmation utiles et une liste des directives 35 conditionnelles vérifiées ; 3025036 3 - le procédé comporte une étape de recherche des définitions inutiles consistant, à partir de la liste des commandes et de la liste des directives conditionnelles vérifiées, suite à une analyse textuelle des fichiers de programmation utiles, à générer le graphe d'appel des constantes et des fonctions définies par des directives de compilation contenues dans 5 lesdits fichiers de programmation et à marquer des noeuds dudit graphe d'appel qui correspondent à des constantes ou des fonctions qui sont utiles pour la compilation d'au moins un desdits fichiers de programmation, afin de générer un fichier contenant les constantes et des fonctions qui ne sont pas utiles à la compilation ; et, - l'étape de recopie à partir de ladite au moins une liste des fichiers de programmation 10 utiles, de la liste des directives conditionnelles vérifiées et du fichier des constantes et des fonctions qui ne sont pas utilisées ; -la génération du graphe d'appel se limite aux appels effectués à l'intérieur des directives de compilation hormis les directives conditionnelles qui ne sont jamais vérifiées ; - l'étape de recopie consiste à recopier chaque fichier de programmation indiqué dans la 15 liste des fichiers de programmation utiles et à recopier l'arborescence des répertoires contenant lesdits fichiers de programmation utiles ; - à l'étape de localisation des instructions utiles dans les fichiers de programmation du code source initial, est associée, à chaque entrée de la liste des directives conditionnelles vérifiées, une donnée indiquant si la condition est vérifiée dans toutes les occurrences 20 d'utilisation du fichier de programmation correspondant ou seulement dans certaines occurrences d'utilisation ; -au cours de l'étape de recopie d'un fichier de programmation : - les instructions correspondant à des définitions de constantes ou de fonctions définies par des directives de compilation qui ne sont pas utiles ne sont pas 25 recopiées ; - les directives conditionnelles sont modifiées de manière à ne conserver que les directives conditionnelles qui sont du type « parfois vérifiées » ; - les lignes de code non utilisées ne sont pas recopiées ; - les directives d'inclusion de fichiers de programmation d'objets standards sont 30 remplacées par des directives d'inclusion de fichiers de programmation d'objets spécifiques ; et/ou, - les fichiers de commandes « Makefile » (MF) sont recopiés, en supprimant les références aux fichiers de programmation inutilisés et aux fichiers binaires correspondants ; 35 - à l'étape de localisation des instructions utiles dans les fichiers de programmation du code source initial, est créée une liste des inclusions de fichiers de programmation 3025036 4 d'objets standards avec le nom du fichier de programmation concerné et la ligne où se fait l'inclusion, le nom du fichier de programmation d'objet standards inclus et le chemin d'accès au répertoire qui le contient ; - dans l'étape de recopie, chaque fichier de programmation est recopié dans un espace 5 mémoire d'une plateforme informatique de mise en oeuvre du procédé, qui est séparé d'un espace mémoire de ladite plateforme informatique comportant le code source initial ; - le procédé comporte, en outre, une étape de comparaison bit à bit d'un code binaire de référence résultant d'une compilation, sur une première plateforme, par un compilateur du code source initial et d'un code binaire secondaire résultant d'une compilation du code 10 source simplifié par ledit compilateur, qui est exécuté sur une seconde plateforme, physiquement différente de la première plateforme et ne contenant aucun fichier source autre que les fichiers source du code source simplifié. L'invention a également pour objet un produit programme d'ordinateur comportant des instructions propres à être exécutées par un calculateur de manière à mettre en 15 oeuvre un procédé de traitement automatique d'un code source initial, tel que défini ci- dessus. Ainsi, l'invention permet une automatisation de la reprise d'un code source existant, de manière à générer un code source simplifié, de taille réduite, qui respecte de manière certaine une partie des contraintes avioniques d'écriture, en particulier celles 20 relatives à l'absence de code mort lié à la compilation dans le code source. L'invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d'un mode de réalisation particulier, donné uniquement à titre d'exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels : 25 La figure 1 est une représentation schématique du système pour la mise en oeuvre du procédé de traitement selon l'invention ; La figure 2 est une représentation schématique, sous forme de blocs, du procédé de traitement selon l'invention ; La figure 3 est une représentation schématique d'une étape du procédé de la 30 figure 2 correspondant à la localisation du code utile, sur un exemple de fichiers de données ; et, La figure 4 est une représentation schématique d'une étape du procédé de la figure 2 correspondant à la recherche des définitions inutiles, sur un autre exemple de fichiers de données. 35 De manière connue en soi, l'obtention d'un code binaire, représentant une séquence d'instructions exécutables par le microprocesseur d'une plateforme 3025036 5 informatique cible, passe par l'écriture d'un code source, rédigé dans un langage de programmation compréhensible par le développeur. La façon dont est rédigé le code source est appelée langage de programmation. Le code source est ensuite converti en code binaire par un programme tiers, qui est soit un compilateur, soit un interpréteur. 5 Les langages C et C++ sont des exemples de langages de programmation largement utilisés. Il s'agit de langages de programmation destinés à être compilés par un compilateur adapté. Le langage C a été normalisé par l'Organisation Internationale de Normalisation (ISO). Sa dernière version a été définie en 2011 (ISO/IEC 9899:2011). Il est à noter que le 10 langage C était jusqu'à il y peu encore le seul langage, avec le langage ADA, a être autorisé dans le domaine avionique pour de développement d'applications logicielles critiques. Le langage C++ a été normalisé par l'Organisation Internationale de Normalisation (ISO). Sa première normalisation date de 1998 (ISO/ IEC 14882:1998) et a ensuite 15 évoluée jusqu'à la norme actuelle (ISO/IEC 14882:2011). Un code source écrit en C ou C++ comporte ainsi un ensemble de fichiers source, qui sont des fichiers textes, regroupant généralement des fichiers de programmation et des fichiers de commandes « Makefile ». Parmi les fichiers de programmation, on peut par exemple citer les fichiers « .c » 20 (ou « .cpp » en C++), qui correspondent à la programmation d'objets spécifiques au fichier de programmation considéré, et les fichiers « .h », qui sont appelés par les fichiers « .c » et qui définissent le comportement d'objet programmés ailleurs que le fichier de programmation considéré, soit dans un autre fichier de programmation du code source dont il est question, soit dans des bibliothèques. 25 En effet, pour faciliter l'écriture du code source, le développeur peut faire appel à des fichiers de programmation d'objets standards appartenant à une bibliothèque prédéfinie. Pour les langages C et C++, il existe de nombreuses bibliothèques possibles en plus de celles définies dans la norme ISO. Par opposition, les fichiers de programmation relatifs à des objets développés 30 spécifiquement pour l'application logicielle considérée sont dénommés fichiers de programmation d'objets spécifiques dans ce qui suit. Le fichier de commandes « Makefile » comporte une succession de commandes. Il comporte des commandes qui ne sont pas des commandes de compilation et qui permettent de préparer les fichiers de programmation à compiler, et des commandes de 35 compilation qui permettent de compiler les fichiers de programmation intermédiaire ainsi préparés. Une commande spécifie l'environnement de compilation par une pluralité de 3025036 6 paramètres dont les valeurs sont spécifiées dans la commande, tels que le chemin d'accès à un fichier de programmation d'un objet standard, etc. Le langage utilisé dans le fichier de commandes « Makefile » est un langage déclaratif 5 La génération d'un code binaire par un compilateur à partir d'un code source se déroule en trois phases principales, à savoir une phase de précompilation, une phase de compilation proprement dite et une phase d'édition de liens. Dans la phase de précompilation, un module d'interprétation (tel que le programme « Make ») du compilateur exécute les commandes du fichier de commandes 10 « Makefile » qui ne sont pas des commandes de compilation de manière à construire chaque fichier intermédiaire, en allant chercher les fichiers de programmation nécessaires. Chaque fichier de programmation appelé est alors parcouru (ou parsé) de manière à identifier, parmi les différentes lignes de code qui le composent, des directives de 15 compilation commençant par un « # », telles que des directives « #define » permettant de définir une constante, ou des directives « #include » permettant d'inclure un fichier de programmation dans le fichier de programmation courant considéré. À l'issue de cette étape de substitution textuelle, il n'y a plus de directives de compilation dans les fichiers intermédiaires. 20 Lors de la phase suivante de compilation proprement dite, le module principal du compilateur compile chaque fichier intermédiaire de manière à créer un fichier binaire (.o) par fichier intermédiaire. Enfin, durant la phase d'édition de lien, le module d'édition de lien du compilateur agrège chaque fichier binaire (.o) avec les éventuels fichiers binaires de bibliothèque qui 25 sont utilisés pour les objets standards (fichiers .a et .so sous « Linux » par exemple, fichiers .d11 et .lib sous « Windows » par exemple encore). A la fin de cette phase d'édition de lien, un code binaire exécutable (.exe sous « Windows », sans extension sous « Linux ») est créé, propre à être chargé dans la mémoire d'une plateforme cible, afin que le microprocesseur de cette plateforme cible 30 l'exécute. Le procédé de traitement 100 est mise en oeuvre sur un système informatique représenté à la figure 1. Le système 10 comporte une plateforme de référence 12, une plateforme de génération 14 et une plateforme cible 16, cette dernière étant embarquée à bord d'un 35 aéronef et permettant l'exécution d'un code binaire CB correspondant à une application logicielle fournissant une fonctionnalité requise. 3025036 7 Un code source initial CSI est un code source écrit en langage C ou C++. Le code source initial CSI est d'abord compilé par un compilateur 50 exécuté sur la plateforme de référence 12. Ceci conduit à la production d'un code binaire de référence CBRef. 5 Parallèlement et de manière indépendante, le code source initial CSI est traité par un module 60 propre à mettre en oeuvre le procédé de traitement 100 selon l'invention, qui sera décrit en détail ci-après, de manière à générer un code source simplifié CSS. Le code source simplifié CSS est ensuite chargé sur la plateforme de génération 14. 10 Le code source simplifié CSS est alors compilé par un compilateur 50 (identique à celui utilisé sur la plateforme de référence 12) exécuté sur la plateforme de génération 14. Ceci conduit à la production d'un code binaire secondaire CBS. La plateforme de génération 14 ne contient aucun fichier de programmation, hormis les fichiers source du code source simplifié CSS. Il est important que la plateforme 15 de génération 14 soit différente de la plateforme de référence 12, afin de garantir qu'aucun fichier du code source initial CSI ne soit utilisé lors de la compilation du code source simplifié CSS. Le code binaire secondaire CBS est recopié sur la plateforme cible 16. Cette copie constitue le code binaire CB exécuté. 20 La comparaison bit à bit du code binaire de référence CBRef et du code binaire secondaire CBS, réalisée par un module de comparaison 70 exécuté sur la plateforme de référence 12, permet de vérifier que ces deux codes binaires sont strictement identiques. Lorsque cette comparaison est positive et que les deux codes binaires sont effectivement identiques, les crédits d'expérience déjà acquis sur le code binaire lors de la 25 certification de l'application logicielle sont réutilisées. Cette certification, représentée schématiquement sur la figure 1 par le module 80, est alors essentiellement limitée aux étapes de certification du code source, qui sont appliquées au code source simplifié CSS. De plus, puisque l'équivalence entre le code source initial CSI et le code source simplifié CSS est garantie par l'identité des deux codes binaires obtenus, le code source 30 simplifié CSS est considéré comme le nouveau code source de l'application logicielle à certifier. De ce fait, c'est le code source simplifié CSS qui sera analysé en vue de la certification de l'application logicielle, notamment vis-à-vis des contraintes avioniques d'écriture. Ceci permet de sortir le module 60 de la chaîne de génération du code binaire CB. Par conséquent, le procédé de traitement automatique 100, qui n'apparaît pas dans 35 la chaîne de génération du code binaire n'a pas à être lui-même certifié. 3025036 8 Le procédé de traitement 100 est représenté à la figure 2. Il permet de supprimer automatiquement du code source initial CSI toutes les parties de ce code qui ne sont pas utiles pour la génération du code binaire secondaire CBS, c'est-à-dire tout le code mort lié à la compilation. 5 Pour cela, le procédé de traitement 100 supprime tous les fichiers de programmation ou parties de fichier de programmation du code source initial CSI qui sont inutiles au sens où ils ne seraient pas utilisés lors d'une compilation de ce code source initial CSI par le compilateur 50. Sont également supprimées toutes les directives de compilation inutiles, c'est-à-dire qui ne seraient pas utilisées ou qui seraient rendues 10 inutiles lors d'une compilation de ce code source initial CSI par le compilateur 50. Dans une première étape 110, les fichiers de commandes « Makefile » MF du code source initial CSI sont interprétés de manière à générer une liste des commandes LC. Une telle liste regroupe les commandes permettant la compilation. 15 L'interprétation des fichiers de commandes « Makefile » MF est réalisée par n'importe lequel des logiciels « make » connus de l'homme du métier. A l'étape 120, les instructions utiles sont localisées. Pour ce faire, chaque commande de la liste des commandes LC est interprétée. Si cette commande n'est pas une commande de compilation, elle est exécutée. 20 Si cette commande est une commande de compilation, chaque option définissant l'environnement de compilation est mémorisée, et les fichiers de programmation à compiler sont analysés. L'analyse syntaxique des fichiers de programmation s'effectue selon l'état de l'art. Plus précisément, à partir de la liste des commandes LC, les fichiers de 25 programmation FS des objets spécifiques ou standards du code source initial CSI, en particulier les fichiers de programmation ayant comme extension .c, .cpp et .h , sont parcourus et interprétés afin de générer un premier fichier d'information F1 et un second fichier d'information F2. Le premier fichier d'information F1 contient : 30 Une liste L1 des noms des fichiers de programmation FS utilisés, avec le chemin d'accès aux répertoires qui les contiennent ; et, Une liste L2 des directives d'inclusion d'un fichier de programmation de bibliothèque (qui correspondent à des directives de compilation qui, dans un fichier de programmation FS, débutent syntaxiquement par « # include»), avec 35 le nom et la ligne du fichier de programmation FS où se fait l'inclusion, le nom 3025036 9 du fichier de programmation de bibliothèque inclus et le chemin d'accès au répertoire qui le contient. Le second fichier d'information F2 contient : Une liste L3 des directives conditionnelles (qui correspondent à des directives 5 de compilation, qui dans un fichier de programmation FS sont de la forme #ifdef, #if, #elif, #else) qui sont vérifiées, c'est-à-dire les directives de compilation pour lesquelles le bloc d'instructions qui suit est utilisé lors de la compilation; cette liste est constituée, pour chaque directive conditionnelle vérifiée, du nom et de la ligne du fichier de programmation FS où se trouve 10 cette directive de compilation et du chemin d'accès au répertoire qui contient ce fichier de programmation FS ; et, Pour chaque directive conditionnelle vérifiée, une donnée indiquant si la condition est vérifiée dans toutes les occurrences d'utilisation du fichier de programmation FS, ou seulement dans certaines occurrences d'utilisation. 15 Il est à noter que l'analyse des fichiers de programmation FS à compiler se fait en traitant récursivement les inclusions de fichier. La figure 3 représente schématiquement un exemple de mise en oeuvre de cette étape 120. A l'étape 130, les définitions inutiles sont recherchées. 20 Pour ce faire, à partir de la liste des commandes LC et de la liste des directives conditionnelles vérifiées L3 du second fichier F2, les fichiers de programmation FS sont à nouveau parcourus et interprétés afin de générer un troisième fichier F3 contenant les constantes et les fonctions (« macros ») définies par des directives de compilation, mais qui ne sont pas utilisées. 25 Pour effectuer cette étape, comme dans l'étape 120, la liste des commandes LC est parcourue, mais ici l'analyse des fichiers de programmation FS diffère. En effet, cette analyse est maintenant réalisée en traitant récursivement les inclusions de fichiers de programmation FS, et en tenant compte de la liste des directives conditionnelles vérifiées L3 du second fichier F2, de manière à ignorer les lignes de code 30 des fichiers de programmation FS qui ne sont jamais utilisées. Lors de cette analyse, un graphe d'appel GA des constantes et des fonctions définies par les directives de compilation est construit, en se limitant aux appels effectués à l'intérieur des directives de compilation et en ne tenant pas compte des directives conditionnelles qui ne sont jamais vérifiées. 3025036 10 L'analyse permet également de marquer les noeuds du graphe d'appel GA qui correspondent à des constantes ou des fonctions qui sont utilisées dans au moins une ligne de code ou au moins une directive conditionnelle du type « parfois vérifiée ». A l'issue de l'analyse de toutes les commandes de la liste LC, le graphe d'appel 5 GA est parcouru pour marquer tous les noeuds parents d'une constante ou d'une fonction utilisée dans au moins une ligne de code ou au moins une directive conditionnelle du type « parfois vérifiée ». Le graphe d'appel GA sera avantageusement parcouru selon l'ordre topologique des noeuds du graphe. Le troisième fichier F3 contenant les définitions inutiles est alors généré à partir de 10 tous les noeuds du graphe d'appel GA qui ne sont pas marqués. La figure 4 représente schématiquement un exemple de mise en oeuvre de cette étape 130, avec notamment un graphe d'appel GA. Sur cette figure, les noeuds surlignés en gras et portant un indice « M » sont les noeuds marqués. L'analyse syntaxique des fichiers de programmation FS et la génération du graphe 15 d'appel GA s'effectuent en mettant en oeuvre des algorithmes connus de l'homme du métier. Enfin, à l'étape 140, le code utile des fichiers source du code CSI est recopié pour générer le fichier de programmation simplifié CSS. Plus précisément, à partir des résultats des deux étapes 120 et 130, les fichiers de 20 programmation FS sont à nouveau parcourus, afin de générer l'ensemble des fichiers source du code source simplifié CSS. Pour effectuer cette étape 140, chaque fichier de programmation FS apparaissant dans la liste L1 des fichiers utilisés du premier fichier F1 est analysé. Cette analyse est réalisée sans traiter les inclusions de fichier. 25 Durant cette analyse, chaque fichier de programmation FS (y compris les fichiers du programmation standards) est recopié dans un espace mémoire de la plateforme de référence 12 séparé de l'espace mémoire du code source initial CSI, en y recopiant également l'arborescence des répertoires. Au cours de cette recopie, les lignes de code non utilisées d'un fichier de 30 programmation FS ne sont pas recopiées. De même les définitions des constantes ou des fonctions (« macros ») non utilisées ne sont pas recopiées. De plus, les directives conditionnelles sont modifiées de manière à ne conserver que les directives conditionnelles qui sont parfois vérifiées. Enfin, les directives d'inclusion de fichiers de programmation d'objets standards 35 (directives de compilation avec des chevrons du type « #include ») sont remplacées par des directives d'inclusion de fichiers de programmation d'objets spécifiques (directives 3025036 11 de compilation avec des guillemets du type « #include "FS" », en précisant le répertoire du fichier de programmation inclus). Finalement, les fichiers de commandes « Makefile » FM sont recopiés. Lors de cette recopie, les références à des fichiers de programmation FS non utilisés (c'est à dire 5 n'apparaissant pas dans la liste L1 du premier fichier F1) sont supprimées, de même que les références aux fichiers compilés (fichiers .o) de ces fichiers de programmation FS non utilisés. L'ensemble de ces fichiers recopiés constituent le code source simplifié CSS. De manière générale, le procédé selon l'invention permet un traitement 10 automatique d'un code source initial, écrit en langage C ou en langage C++, de manière à obtenir un code source simplifié, qui présente une taille réduite par rapport à celle du code source initial et dans lequel a été supprimée la totalité du code mort lié à la compilation présent dans le code source initial, c'est-à-dire le code qui n'est pas utilisé lors de la compilation. 15 Ce procédé de traitement automatique est effectué sans impact sur le code binaire généré à l'issue de la compilation, c'est-à-dire que le code binaire résultant de la compilation du code source initial et le code binaire résultant de la compilation du code source simplifié sont identiques entre eux. L'étape de comparaison entre les deux codes binaires étant avantageusement effectuée systématiquement pour garantir cette identité. 20 La propriété de conservation du code binaire permet de conserver (c'est-dire de réutiliser) les crédits d'expérience (tels que par exemple les constats de bon fonctionnement durant une longue période d'exécution du code binaire, etc.) associés aux étapes de certification du code binaire dans le processus de certification, sans avoir à refaire les tests et vérifications correspondants. 25 De plus, en ce qui concerne les étapes de certification du code source dans le processus de certification et/ou de maintenance du code source, les tests et vérifications correspondants sont simplifiés du fait de la taille réduite du code source simplifié. REVENDICATIONS1.- Procédé (100) de traitement automatique d'un code source initial (CSI), écrit dans un langage de programmation du type C ou C++, pour générer un code source simplifié (CSS) respectant des contraintes avioniques d'écriture requises par un processus de certification, le procédé comportant les étapes consistant à : - suite à une analyse textuelle des fichiers de programmation et des fichiers de commandes du code source initial, à générer : - une liste (L1) des fichiers de programmation utiles à la compilation parmi lesdits fichiers de programmation ; et, - un graphe d'appel (GA) des constantes et des fonctions définies par des directives de compilation contenues dans lesdits fichiers de programmation, - marquer des noeuds dudit graphe d'appel qui correspondent à des constantes ou des fonctions qui sont utiles pour la compilation d'au moins un desdits fichiers de programmations utiles, et - à recopier les instructions desdits fichiers de programmation utiles, de manière à constituer des fichiers de programmation du code source simplifié, en ne recopiant pas les instructions qui correspondent à des définitions de constantes ou de fonctions qui, d'après le graphe d'appel, ne sont pas utiles à la compilation. 2.- Procédé selon la revendication 1, comportant : - une étape (110) d'interprétation des fichiers de commandes « Makefile » (MF) du code source initial (CSI) pour générer une liste des commandes (LC) ; - une étape (120) de localisation des instructions utiles dans les fichiers de programmation du code source initial (CSI) à partir de la liste des commandes (LC), de manière à générer au moins une liste (L1, L2) de fichiers de programmation utiles et une liste (L3) des directives conditionnelles vérifiées ; - une étape (130) de recherche des définitions inutiles consistant, à partir de la liste des commandes (LC) et de la liste (L3) des directives conditionnelles vérifiées, suite à une analyse textuelle des fichiers de programmation utiles, à générer le graphe d'appel (GA) des constantes et des fonctions définies par des directives de compilation contenues dans lesdits fichiers de programmation et à marquer des noeuds dudit graphe d'appel qui correspondent à des constantes ou des fonctions qui sont utiles pour la compilation d'au moins un desdits fichiers de programmation, afin de générer un fichier (F3) contenant les constantes et des fonctions qui ne sont pas utiles à la compilation ; et, 3025036 13 - ladite étape (140) de recopie à partir de ladite au moins une liste (L1, L2) des fichiers de programmation utiles, de la liste (L3) des directives conditionnelles vérifiées et du fichier (F3) des constantes et des fonctions qui ne sont pas utilisées. 5 3.- Procédé selon la revendication 2, dans lequel la génération du graphe d'appel (GA) se limite aux appels effectués à l'intérieur des directives de compilation hormis les directives conditionnelles qui ne sont jamais vérifiées. 4.- Procédé selon la revendication 3, dans lequel l'étape de recopie consiste à 10 recopier chaque fichier de programmation indiqué dans la liste des fichiers de programmation utiles et à recopier l'arborescence des répertoires contenant lesdits fichiers de programmation utiles. 5.- Procédé selon l'une quelconque des revendications 2 à 4, dans lequel, à 15 l'étape de localisation des instructions utiles dans les fichiers de programmation du code source initial (CSI), est associée, à chaque entrée de la liste (L3) des directives conditionnelles vérifiées, une donnée indiquant si la condition est vérifiée dans toutes les occurrences d'utilisation du fichier de programmation correspondant ou seulement dans certaines occurrences d'utilisation. 20 6.- Procédé selon la revendication 5, dans lequel, au cours de l'étape de recopie d'un fichier de programmation : - les instructions correspondant à des définitions de constantes ou de fonctions définies par des directives de compilation qui ne sont pas utiles ne sont pas recopiées ; 25 - les directives conditionnelles sont modifiées de manière à ne conserver que les directives conditionnelles qui sont du type « parfois vérifiées » ; - les lignes de code non utilisées ne sont pas recopiées ; - les directives d'inclusion de fichiers de programmation d'objets standards sont remplacées par des directives d'inclusion de fichiers de programmation d'objets 30 spécifiques ; et/ou, - les fichiers de commandes « Makefile » (MF) sont recopiés, en supprimant les références aux fichiers de programmation inutilisés et aux fichiers binaires correspondants. 3025036 14 7.- Procédé selon l'une quelconque des revendications 2 à 6, dans lequel, à l'étape de localisation des instructions utiles dans les fichiers de programmation du code source initial (CSI), est créée une liste (L2) des inclusions de fichiers de programmation d'objets standards avec le nom du fichier de programmation concerné et la ligne où se fait 5 l'inclusion, le nom du fichier de programmation d'objet standards inclus et le chemin d'accès au répertoire qui le contient. 8.- Procédé selon l'une quelconque des revendications 2 à 6, dans lequel, dans l'étape de recopie, chaque fichier de programmation est recopié dans un espace 10 mémoire d'une plateforme (12) informatique de mise en oeuvre du procédé, qui est séparé d'un espace mémoire de ladite plateforme (12) informatique comportant le code source initial (CSI). 9.- Procédé selon l'une quelconque des revendications précédentes, 15 comportant, en outre, une étape de comparaison bit à bit d'un code binaire de référence (CBRef) résultant d'une compilation, sur une première plateforme (12), par un compilateur (50) du code source initial (CSI) et d'un code binaire secondaire (CBS) résultant d'une compilation du code source simplifié (CSS) par ledit compilateur (50), qui est exécuté sur une seconde plateforme (14), physiquement différente de la première plateforme (12) et 20 ne contenant aucun fichier source autre que les fichiers source du code source simplifié (CSS),. 10. Produit programme d'ordinateur comportant des instructions propres à être exécutées par un calculateur de manière à mettre en oeuvre un procédé de traitement 25 automatique d'un code source initial selon l'une quelconque des revendications 1 à 9.