THALES VALENCE

THALES AVIONICS VALENCE (26)

 

SYNTHESE DE LA MISSION / PROJET :

REALISATION DU CYCLE V&V, DE LA SPECIFICATION A LA MISE EN SERIE.

Processus de conception aéronautique, notamment DO178B, DO254…

Réalisation d’interface avec l’équipe logicielle dans le domaine de l’embarquée.

Environnements techniques : Ada 83,95, ARINC 424, MCDU, Temps réel, system embarqué, protocole de communication, API, Rational Rapsody, UML, DO-178B, Clearcase, Doors, banc de test FM MCDU en NATIF & CROSS, Framework (FISTURE)

Uniformisation du modèle de données et du protocole pour l’API_FPLN et l’API_CORE_SERVICE

  • Développement à partir des spécifications des logiciels API_FPLN
  • Codage d’une nouvelle architecture du protocole de communication entre l’API_FPLN et l’API_CORE_SERVICE.
  • Participation à l’ensemble des phases du cycle en V (méthodologie agile) : design, codage, tests unitaires et intégration.
  • Estimation du temps et ressources nécessaires, planning
  • Analyse d’impact suite à modification des spécifications
  • 80 à 85% du CORE de la structure des modifications que j’ai réalisé n’a pas été changé, les modifications ont été apportées viens des parties qui ont été mal modélisées lors de la phase de maquettage ou que l’on a vu d’autres problématiques.
  • Avant que les modifications que je réalise rentrent dans une phase industrialisation et qu’ils soient déployés sur l’ensemble du produit FM.
  • Cela signifie que le projet était assez mature pour que les modifications soient réalisées, durant les différentes phases qui ont été réalisées en amont ont bien été accomplies. Mon travail consistait à de la correction sur des dépendances de classer et du travail sur des différentes parties du FMS.

Besoin : en entrée de l’IHM, une seule définition des données FM

But : rentabiliser les composants les plus couteux que l’on développe. Automatisation de test.

Objectif : uniformiser les types en sortie du FM

Exemple de données modifiées :

Les données modifiées :
Avant Après
String (4 Octets) Enum (1 Octet)
Enum (4 Octet) Boolean (1 Octet)
Int (4 Octet) Int (1 Octet)
Donner inexistante Insertions d’un chant entre l’entête et l’offset Int (4 Octet),

la Size Int (4 Octet)

Chants fin du message end Suppressions des chants inutiles

Transformation de la trame :

  • Travail effectué : modification du formatage de l’information « FPLN_identification»
  • Associé au FPLN :
  • Le travail consiste à la transformation d’un tableau d’un format T_String, coder sur
  • (8 octets) Sub-type : T_String.
  • Le transformer en un tableau de type T_String, coder sur (4 octets) Sub-type : T_String.

Détail des modifications apportées au code FPLN_identification :

Je suis parti d’un tableau sur 8 octet d’un format String. Sub-type : T_String.

Pour le transformer en un tableau de T_String de 4 octets Sub-type : T_String.

Changement De la valeur FPLN_identification de types T_String.

On modifie le type : FPLN_identification de types T_String.

On remplace le format de la taille du tableau T_String (64 bytes) en un tableau T_String (32 byte).

On copie la valeur de FPLN_identification pour le copier dans un T_String sur (32 byte).

Pour pouvoir l’insérer dans la trame il faut que le T_String pointe sur la même zone mémoire du tableau.

Pour cela on doit lui indiquer le début et la fin.

FPLN_identification pour pouvoir l’appeler et le transmettre dans le bon ordre au client.

Séparation du protocole de communication de l’API_CORE_SEVICES :

  • Réaliser une évolution iso fonctionnelle de l’API_CORE_SERVICES.
  • Isoler le protocole de communication pour pouvoir le réutiliser sur d’autre fonction du FM.
  • Evaluer les différentes taches à faire pour réaliser le projet.
  • Formaliser mon avancement pour pouvoir transmettre le projet à l’équipe qui le terminera.

1) Modification du design : Inversion des indépendances entre les classes. (Réalisé lors du stage)

Comportement Avant modifie du design :                                                   Comportement Après modifie du design :

Uniformisation des types :

  • Fournir au client une seule représentation des données en interface du FM.
  • Capitaliser sur le développement et les tests des interfaces.

Problématique du projet :

  • Inversion des dépendances de classe entre API_ CORE_SERVICE et Protocole de communication, le protocole devient indépendant et peut être réutilisé pour d’autre fonction du FM (architecture du Protocole).
  • Mon intervention sur le projet consisté à dissocier le Protocole de communication et l’Api_Core_Service, dans le but de le standardiser. Pour cela j’ai modifié le design en utilisant Rapsody sans en changer le comportement fonctionnel du protocole.

Trois étapes ont été identifiées : (technologie Protocole de communication : TCP-IP UDP)

  • Modification du design : Inversion des indépendances entre les classes. (Réalisé lors du stage)

Comportement Avant modification du design : Comportement Après modification du design :

  • mise à jour de la documentation du Design du Protocole de communication entre le FMS et L’Api_Core_Service.
  • j’ai réalisé une nouvelle version du protocole de communication, qui répond aux nouvelles exigences du client.
  • Implémentation de la solution :
    • Réorganisation du Contrôleur : Redistribution des responsabilités des classes. (initialisé lors du stage finalisé par l’équipe)
    • Suppression de la dépendance vers l’Api_Core_Service : Mise en place d’une classe abstraite qui définit l’appel à l’API. Cela permet d’isoler le protocole de communication de l’Api (Fait par l’équipe, hors stage).
    • (Plus de détails voir : Annexe diagramme UML page 13 à 16).
  • Tests et Dossiers :
    • Ecriture des LLR et création du SDD (Fait par l’équipe, hors stage).
    • Ecriture des LLT et création du STD protocole (Fait par l’équipe, hors stage).
Bilan des modifications AVANT APRES
nombre lignes nombre fichiers nombre lignes nombre fichiers
PROTOCOLE DE COMUNICATION 793 17 810 17
Bilan des modifications AVANT APRES
nombre lignes nombre fichiers nombre fichiers nombre lignes nombre fichiers
API FPLN 2662 110 3124 120

DESIGN.

  • On est tous impliqués dans le design du logiciel de petite ou à grande Échelle lors de sa conception. Les facteurs importants à prendre en considération : la sécurité, la clarté des données utilisées.
  • De la conception des modifications que l’on réalise. Sur les différentes problématiques que l’on a surmontées. La conception du logiciel répond à des critères bien particuliers.

Mesure des temps de latence des chaines fonctionnelles du FMS et automatisation des tests.

 

  • Automatisation de test d’intégration création de plan de vol pour des tests de charge et pour calcule des temps de latence des chaînes fonctionnelles 30leg, 56leg, 100leg, 250leg (nombre de point dans un plan de vol).
  • Modification de code (utilisation de scripte Python)
  • Test en mode natif (PC) et cross banc de test (plateforme aéronef).en utilisent le MCDU ou Framework « FISTURE »
  • Réalisation de procédure des activités réalisées (procédure d’utilisation banc de test, procédure création plan de vol pour des tests de charge et pour calcule des temps de latence des chaînes fonctionnelles en utilisent le Framework « FISTURE ») .

FMS (système temps réel embarqué de Navigation aéronautique).

Mise en place de test en intégration continue Analyse temps réel, optimisation de traitement des chaines fonctionnelles. Environnement (Ada, Rhapsody, FISTURE, Clearcase, etc…)

Je suis en formation au CFA AFTI (Orsay, département : 91)

Cela comporte 2 temps :

– Une période au CFA AFTI de 5 mois

– Une période en entreprise Thales Avionics Valence de 7 mois

– cela 2 fois donc 2 ans de formation en alternance.

J’ai vécu ma première période en entreprise en découvrant le métier d’ingénieur logiciel chez Thales Avionics Valence.

– Un ingénieur se doit de comprendre le problème.

– Doit savoir anticiper sur les demandes des clients.

– Doit savoir réagir

– Doit savoir assimiler, analyser et synthétiser les informations et savoir les transmettre à ses collègues de projet ou des      techniciens.

– Doit rechercher des solutions.

– Doit être le plus rapide possible dans la résolution du problème. Sans nuire au résultat du projet.

– Doit trouver rapidement une solution à la problématique. Tout en restant raisonnable en aiguillant le client dans la voie la    plus économique pour lui et pour nous.

Ce stage m’a apporté :

– Une compréhension du comportement du FMS, son rôle, comment il est utilisé par le pilote.

– La programmation sous ADA avec deux missions, le protocole de communication et l’uniformisation des données en sortie de            FMS.

– L’expérience de développement avec une équipe qui utilise la méthode Agile sur du logiciel embarqué.

– D’être confronter à des normes aéronautiques.

– De l’expérience dans un projet avec des contraintes programme (coût et délais).

– La nécessité de formaliser ma contribution pour pouvoir la transmettre aux membres de l’équipes pour qu’ils puissent l’intégrer et poursuivre les travaux.

J’estime avoir rempli mes missions dans les temps qui m’étaient imparti.

Apres une année en collaboration avec ce service je suis ravi de faire partie de cette équipe.

Grace à ma formation et à mon cursus scolaire, je peux regrouper les deux aspects de ma formation – l’électronique (Baccalauréat et Brevet de Technicien Supérieur), Micro- Systèmes et Micro-Electroniques (Licence Professionnelle) l’aspect informatique : Génie Logiciel ETGL (école CFA AFTI ORSAY – conduite de projet génie logiciel).

Grace à mon expérience chez THALES Avionics j’espère avoir des propositions d’emplois en CDI dans ces domaines de compétence. (Systèmes embarqués, software, hardware, nouvelles technologies).

J’aimerai que l’on me réserve un poste dans cette équipe après mon stage. Parce que j’aimerai approfondir mes connaissances dans ces domaines là et surtout dans la programmation d’ADA et autres.