Adel RAHAL

CONTEXTE

La BCM (Body Control Module) ou UCH (Unité de Contrôle Habitacle) est l'un des calculateurs les plus importants dans le véhicule. Elle reçoit plusieurs signaux d'entrée ( contacteur d'allumage, pédale de frein, ondes électromagnétiques de la clé, etc.), et contrôle plusieurs sorites (ampoules des feux de stop, portes, etc.). Elle a aussi un rôle de passerelle dans le réseau des calculateurs ce qui en fait un support crucial pour l'ensemble des fonctionnalités du véhicule. Le logiciel est développé suivant l'architecture AUTOSAR Classic.

TRAVAIL

1ère Mission

Dans ma première mission, j'ai assuré le suivi du process imposé par la norme ISO26262 pour la sûreté de fonctionnement des logiciels automobiles. Du point de vue archictural, la BCM est divisée en plusieurs fonctionnalités. Chacune de ces fonctionnalités a des exigences de sûreté au niveau système. En me basant sur ces dernières, j'ai créé les documents (Software Safety Concepts) décrivant comment une version donnée du logiciel implémente (ou n'implémente pas) ces exigences. J'ai aussi assuré la traçabilité globale des exigences de sûreté au niveau système, à l'implémentation logicielle aux spécifications des tests sur véhicule. Cette traçabilité était faite sur la base de donnée DOORS du projet. J'ai aussi réalisé les Analyses de Sûreté de Code qui vérifient si les ASILS (Automotive Software Integrity Levels) étaient bien respectés dans le code. Tous ces documents ont dû être présentés à l'oral et validés dans un process de revue régulier.

2ème MISSION

Dans ma seconde mission, j'ai résolu des problèmes globaux dans le logiciel de la BCM. Notre cible est un stock de rapports (Problem Reports) constamment alimenté par les équipes de test système et le client (fabricant automobile). Ces rapports ont la forme d'une procédure de test dans laquelle le résultat obtenu est différent du résultat attendu. L'objectif est de trouver la cause racine. Il est très important de rappeler qu'un rapport ne constitue en aucun cas une vérité absolue, mais uniquement un phénomène qu'une entité pense avoir observé. Cet état d'esprit est nécessaire dans le sens où un bug peut être étudié correctement uniquement après reproduction du comportement décrit. Sans cela, il faut recueillir un maximum d'informations concernant la procédure de test, les exigences qu'elle était supposée tester, l'environnement dans lequel le test a été fait, la version exacte du code utilisé, tout en essayant simultanément de reproduire le problème sur banc (simulateur CANoe + debugger winIDEA ou Trace32). Une fois le comportement reproduit, l'investigation réelle du "bug" peut démarrer.

Les comportements décrits peuvent se situer dans n'importe quelle partie de l'architecture AUTOSAR : application, Runtime Environment, Basic Software (réseaux comme CAN et LIN, stockage non-volatile, gestion des modes, problèmes temps-réel, fonctionnalité complexe du véhicule comme le contrôle des portes à distance avec clé, etc.). Il est souvent nécessaire de créer des versions instrumentées du logiciel qui offrent l'opportunité d'observer des phénomènes inaccessibles par les moyens normaux (simulateur, debugger, etc.). Naturellement, cela requiert une compréhension pratique de l'architecture logicielle.

L'état de la recherche doit être documenté clairement et régulièrement dans le ticket Jira. Comme les activités sont effectuée en coordination avec plusieurs équipes à l'international, la langue employée à l'oral et à l'écrit est l'anglais dans la majorité des cas. En fonction de la priorité du ticket et de sa complexité, il peut aussi être requis de communiquer directement avec le client.

La nature variée des problèmes requiert la capacité de créer des scripts pour automatiser certaines tâches.