Etude de cas CNES : Modélisation de la partie Commande/Contrôle dun GCU Alexandre Cortier, Eric Morand

PLAN I- Introduction II- Modélisation : vues globales III- Sous-composant : CC/Filtrage IV- Sous-composant : CC/Routage V- Sous-composant : CC/HK VI- Conclusion

I- Introduction : objectifs Modélisation de lélément CC relatif à un logiciel de vol charge utile Focalisation sur : – Le filtrage des TC – Le routage des TM/TC – La génération de TM HK (House Keeping) GCU PF CCMISSION I1 I2 I3

I- Introduction : Vue globale CC : Contrôle/Commande MISSION : Partition Mission PF : Plateforme I1, I2, I3 : Instruments CC PF I1 I2 I3 MISSION Arinc 1553

PLAN I- Introduction II- Modélisation : vue globale III- Sous-composant : CC/Filtrage IV- Sous-composant : CC/Routage V- Sous-composant : CC/HK VI- Conclusion

II- Modélisation : zoom sur CC Port group : CMD_data, fresh toPF Routing Filtering HK fromI1 toI1[3] fromI2 toI2[3] fromI3 toI3[3] fromM toM[4] fromPF > fromM filterTabmodes

II- Modélisation : vue globale I1 I2 I3 Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC PF MISSION o Passage au synchrone : nécessité de connaitre précisément les communications -Ex : A qui peut sadresser une TC de PF ? nombre de signaux au pire cas… o Communication avec lenvironnement : introduction de variables externes besoin de buffer ! (cf. au cours dun cycle de CC, un instrument peut recevoir plusieurs commandes ) toI1[3] buffers o Hypothèse Tous les sous-composants sont à la même fréquence

II- Modélisation : vue globale (2) Besoin de spécifier le comportement des buffers du MW… Autre solution : spécifier directement les buffers en Synoptic – le MW reçoit alors une seule donnée par cycle I1 I2 I3 Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC PF MISSION buffer Vecteur de données (N entrées) Séquence de données fréquence F Fréquence NxF

II- Modélisation : difficultés rencontrées Problèmes ? – Besoin dassocier à chaque donnée TM/TC sa fraîcheur Utilisation de port group Besoin de tester la fraîcheur dun port à chaque cycle Besoin de faire circuler des données même sil elle ne sont pas utiles… – Efficacité du résultat de la compilation des buffers Synoptic ? – Fréquence potentiellement très élevée en sortie ? Le MW doit pouvoir traiter les données dun port à une vitesse NxF – N : nombre maximum de message pouvant être émis par CC à un composant de lenvironnement en 1 cycle – F : fréquence du composant CC Et si les sous-composant de CC ne possède pas la même fréquence ? – Besoin de nombreux adapter/buffer entre les sous-composants – Comment détermine t-on la taille du buffer ? – Que fait-on dans le cas dun dépassement de buffer ? (Emission dune TM anomaly ?)

PLAN I- Introduction II- Modélisation : vue globale III- Sous-composant : CC/Filtrage IV- Sous-composant : CC/Routage V- Sous-composant : CC/HK VI- Conclusion Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC

III- Sous-composant : CC/Filtrage (1) Filtrage des TC en provenance de PF : – En fonction des modes (MISSION, CC, Instruments) – Configuré par un tableau (modifiable par TC : non modélisé pour le moment) Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC

III- Sous-composant : CC/Filtrage (2) type TC_TM_Data is record Type : integer; : 0=TM, 1=TC APID : integer ; -- identifiant de l'application destinatrice ack : integer; serviceType : integer; subServiceType : integer; sourceID : application_ID; -- id émétteru application_Data : string; errorCode : integer ; Fin Packet Data end; port group CMD_receiver features CMD_data : in data port TC_TM_Data; fresh : in data port boolean; end CMD_receiver; port group CMD_sender features CMD_data : out data port TC_TM_Data; fresh : out data port boolean; end CMD_sender; --nb de "composant" NbPartition : constant integer ; -- nb message pouvant être transmis NbTypPUS : constant integer ; -- le nombre maximal de modes de lensemble des partitions NbMaxModes : constant integer ; type MTab_DataType is array NbMaxModes of boolean ; type TypPUSTab_DataType is array NbTypPUS of MTab_DataType; type FilteringTab_DataType is array NbPartition of TypPUSTab_DataType; Difficultés rencontrés : certains champs des TM/TC sont variables… non représentable en Synoptic besoin de notion de sous-typage ou de type union

III- Sous-composant : CC/Filtrage (3) block type filtering_typ features CMD_in : port CMD_receiver; currentModes : in data port ModesTab_DataType; CMD_to_CC_TC_Routing : port CMD_sender; CMD_to_CC_TM_Routing : port CMD_sender; end filtering_typ; port group CMD_receiver features CMD_data : in data port TC_TM_Data; fresh : in data port boolean; end CMD_receiver; port group CMD_sender features CMD_data : out data port TC_TM_Data; fresh : out data port boolean; end CMD_sender; block type checkFiltering_typ features CMD_in : port CMD_receiver ; FilteringTab : in data port FilteringTab_DataType; currentModes : in data port ModesTab_DataType; isOK : out data port boolean; end checkFiltering_typ; dataflow checkFiltering_typ.checkFiltering_dtf flows fl1 : data FilteringTab[CMD_in.CMD_data["APID"]][CMD_in.CMD_dat a["serviceType"]][currentModes[CMD_in.CMD_data["APID" ]]] -> isOK ; end checkFiltering_typ.checkFiltering_dtf;

III- Sous-composant : CC/Filtrage (4) dataflow filtering_typ.filtering_dtf blocks FilteringTab : variable FilteringTab_DataType; check : dataflow checkFiltering_dtf; Flows … fl3 : data check.isOK and CMD_in.fresh -> CMD_to_CC_TC_Routing.fresh; fl4 : data CMD_in.CMD_data -> CMD_to_CC_TC_Routing.CMD_data fl3 : data not(check.isOK) and CMD_in.fresh -> CMD_to_CC_TM_Routing.fresh; fl5 : data {Type:=0 ; -- TM(1,11) (TM anomaly) APID:=5 ; -- PF ack := 0; serviceType:=1 ; subServiceType:=11 ; sourceID:="CC" ; application_Data CMDfromPF["application_Data"]; errorCode :=0 ; } ->CMD_to_CC_TM_Routing.CMD_data; … end filtering_typ.filtering_dtf;

PLAN I- Introduction II- Modélisation : vue globale III- Sous-composant : CC/Filtrage IV- Sous-composant : CC/Routage V- Sous-composant : CC/HK VI- Conclusion Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC

IV- Sous-composant : CC/Routage (1) block type routage_TC_typ features TM_fromPF : port CMD_receiver; TC_fromPF : port CMD_receiver; fromMISSION : port CMD_receiver; fromHK : port CMD_receiver; toI1[3] : port CMD_sender; toI2[3] : port CMD_sender; toI3[3] : port CMD_sender; toMission[4] : port CMD_sender; TMtoHK[3] : port CMD_sender; TCtoHK : port CMD_sender; end routage_TC_typ;

IV- Sous-composant : CC/Routage (2) dataflow routage_TC_typ.routage_TC_dtf blocks Null_CMD : constant TC_TM_Data ; flows MISSION -> I1 fl0 : data (fromMISSION.CMD_data when (fromMISSION.CMD_data.APID="I1")) default NullCMD -> toI1[0].CMD_data ; fl1 : data fromMISSION.fresh -> toI1[0].fresh ; PF -> I1 fl0 : data (fromPF.CMD_data when (fromPF.CMD_data.APID="I1")) default NullCMD -> toI1[1].CMD_data ; fl1 : data fromPF.fresh -> toI1[1].fresh ; HK -> I1 […] PF -> MISSION fl0 : data (fromPF.CMD_data when (fromPF.CMD_data.APID="MISSION")) default NullCMD -> toMISSION.CMD_data ; fl1 : data fromPF.fresh -> toMISSION.fresh ; end routage_TC_typ.routage_TC_dtf; Difficultés rencontrés : RAS pourrait être généré automatiquement à partir dune description tabulaire

PLAN I- Introduction II- Modélisation : vue globale III- Sous-composant : CC/Filtrage IV- Sous-composant : CC/Routage V- Sous-composant : CC/HK VI- Conclusion Routing Filtering HK fromI1 toM[4] > fromM filterTabmodes CC

V- Sous-composant : CC/HK (1) State : ON Automaton : HK State : OFF CMD_TC_in From PF TC(3,5) or TC(3,6) CMD_TM_in[3] From I1,I2 and I3 TM(3,25) CMD_TC_out To I1,I2 or I3 TC(3,9) CMD_TM_out to PF TM(5,2) on TC(3,5)on TC(3,6) do ON.reset=true on TC(3,6) do ON.reset=true on TC(3,5)

V- Sous-composant : CC/HK (2) automaton HK_typ.HK_aut states OFF : dataflow HK_PARAM_OFF_dtf ; ON : dataflow HK_PARAM_ON_dtf ; initial state OFF; transitions tr1: OFF -[on (CMD_TC_in.CMD_data.serviceType=3 and CMD_TC_in.CMD_data.subServiceType=5 and CMD_TC_in.fresh=true) do ON.reset:=true; end ]->> ON; tr2: ON -[on (CMD_TC_in.CMD_data.serviceType=3 and CMD_TC_in.CMD_data.subServiceType=6 and CMD_TC_in.fresh=true) ]->> OFF; tr3: ON -[on (CMD_TC_in.CMD_data.serviceType=3 and CMD_TC_in.CMD_data.subServiceType=5 and CMD_TC_in.fresh=true) do ON.reset:=true; end ]->> ON; end HK_typ.HK_aut;

V- Sous-composant : CC/HK/ON (1) Dataflow : HK/ON COUNTER Init 20 CMD_TC_in From PF TC(3,5) or TC(3,6) CMD_TM_in[3] From I1,I2 and I3 TM(3,25) CMD_TC_out To I1,I2 or I3 TC(3,9) CMD_TM_out to PF TM(5,2) 1 Hz checkResponse TM_HK_SENDER GENERATING TC_TM Cpt = TC_I1 [TM(5,2)] TC_I2 [TM(5,2)] TC_I3 [TM(5,2)] TC_I1 [TM(5,2)] … … TM(3,25) to PF >

Difficultés ? – Besoin de disposer dun ordonnanceur de requêtes – Nécessité dun compteur pour orchestrer les requêtes V- Sous-composant : CC/HK/ON (2)

VI- Conclusion : difficultés rencontrés Editeur graphique inutilisable en létat Manque de blocs primitifs (librairie) pour spécifier des conversions de flot Primitives de conversion tableau -> flot Types de données insuffisants – Associer à un type entier une représentation en nombre de bit – Pas de notion de sous-typage ou de type union (et des primitives dutilisation associées) : cf. champ variable des TM/TC Besoin dassocié à une TM sa « fraicheur » – Notion devent data permettrait de cacher le flag (et donc la construction des groupes de ports) – Routage dynamique : garde sur connexions entre « event data »

Sémantique des automates – Notion dhistorique / de reset à revoir – Différencier « suspend strong/weak transitions » et « abort strong/weak transitions » plus clairement ? Etude de cas est par nature asynchrone. Modélisable en synchrone en introduisant des booléens MAIS : risque dinefficacité (compilateur optimisé ?) VI- Conclusion : difficultés rencontrés (2)