Résumé Les Systèmes Cyber-Physiques (CPS) sont des systèmes intégrant des composants physiques et des aspects informatiques inter-connectés pour ofrir une fonctionnalité avancée. Leur analyse est cruciale pour garantir leur sûreté, leur fiabilité et leur eficacité. Cet article propose une approche novatrice qui combinent les diagrammes SysML et les spécifications AADL (Architecture Analysis and Design Language) afin de faciliter l'analyse formelle des CPS. Une transcription de certains concepts SySML à ceux du langage AADL est proposée et validée à travers une étude de cas de taille réelle, il s'agit d'un système intelligent de surveillance du taux de glucose pour les patients diabétiques.
Dans cette section, nous introduisons SysML; un langage de modélisation axé sur les systèmes,
et AADL, dédié aux systèmes embarqués et critiques. Tandis que SysML met en avant une
variété de diagrammes couvrant diverses facettes des systèmes, AADL [
Le SysML (Systems Modeling Language) est une extension standardisée de l’UML (Unified
Modeling Language), développée pour répondre aux défis spécifiques de l’ingénierie des systèmes.
Ce langage de modélisation vise à être un outil fondamental pour la description, l’analyse, la
vérification et la validation de systèmes complexes [
L’image 1 est une représentation hiérarchique des diférents types de diagrammes inclus dans le langage de modélisation SysML. Voici une brève description de chacun: Les principaux 1. Behavior Diagram: C’est une catégorie de diagrammes qui décrivent le comportement d’un système, tels que: • Activity Diagram: Représente le flux d’activités et de contrôle entre diférentes entités. • Sequence Diagram: Illustration des interactions entre diférentes entités dans un ordre séquentiel. • State Machine Diagram: Représente les états d’un objet ou d’une entité et les transitions entre ces états. 2. Requirement Diagram: Utilisé pour représenter les exigences d’un système et leurs relations. 3. Structure Diagram: C’est une catégorie de diagrammes qui décrivent la structure d’un système, on y trouve: • Block Definition Diagram : Représente les blocs (entités ou objets) et leurs relations. • Internal Block Diagram: Illustre l’interconnexion des parties à l’intérieur d’un bloc. • Package Diagram: Montre la manière dont les éléments sont regroupés et leurs dépendances. 4. Parametric Diagram: Utilisé pour définir des relations quantitatives et des contraintes entre les paramètres d’un système.
En somme, SysML est une extension de l’UML spécialement conçue pour les besoins de modélisation des systèmes d’ingénierie.
L’Architecture Analysis and Design Language (AADL), établi par la SAE, est un standard pour
les systèmes critiques, ofrant une description détaillée des architectures. Il est primordial pour
analyser performances et sécurité. Utilisé en aérospatiale, automobile et défense, AADL guide
les ingénieurs, assurant une conception robuste tout au long du projet [
La table 1 présente les composants fondamentaux pour la modélisation de systèmes en utilisant
AADL. Chaque élément a un rôle spécifique et ils peuvent être combinés de diverses manières
pour créer des modèles de systèmes complexes et critiques [
Matériel Matériel Matériel Matériel Matériel Logiciel Logiciel Logiciel Logiciel Logiciel – Élément AADL Processor Virtual Processor Memory Bus Device Thread Process Package System Data
Composant utilisé pour l’exécution de threads et de processus.
Peut être utilisé pour modéliser la distribution des threads sur un processeur matériel.
Peut être physique ou virtuelle utilisée pour le stockage de données et de programmes. Composant utilisé pour la communication entre les composants matériels.
Représente un dispositif matériel, tel qu’un capteur ou un actionneur, qui interagit avec le système.
Une unité (ou fil) de traitement dans un système. Une entité logicielle indépendante avec son propre espace d’adressage.
Pour l’organisation des éléments AADL en groupes logiques.
C’est le système global et représente l’élément racine de la hiérarchie.
Les données ou les variables utilisées dans le système.
Un élément abstrait qui peut être utilisé comme base pour d’autres éléments AADL matériels ou logiciels.
OSATE (Open Source AADL Tool Environment) est un environnement de développement intégré
destiné à soutenir la modélisation, l’analyse et la génération de code pour AADL [
Osate, de nature open-source avec une base de code dynamique, s’adapte constamment aux demandes de la communauté AADL.
Le domaine des systèmes cyber-physiques médicaux (MCPS) [
Notre approche se distingue nettement dans le paysage actuel de la modélisation des systèmes par ces principaux éléments: • Étape 1 - Mapping de SysML vers AADL: Le coeur de notre approche repose sur le mapping précis des éléments SysML vers AADL. Ce processus de cartographie assure que chaque composant, relation et attribut en SysML trouve son équivalent approprié dans AADL. • Étape 2 - Analyse Formelle Post-Mapping: Une fois le mapping efectué, une analyse formelle du modèle AADL est entreprise. Cette étape est cruciale pour s’assurer que le modèle transposé est non seulement correct, mais qu’il conserve aussi la sémantique du modèle SysML original. • Résultats de l’Analyse: L’analyse formelle met en lumière plusieurs propriétés essentielles du modèle. Le mapping entre SysML et AADL est bien plus qu’une simple conversion. Il s’agit d’une fusion stratégique qui, lorsqu’elle est bien efectuée, débouche sur un modèle robuste, sécurisé et conforme aux attentes. Notre approche vise à perfectionner ce processus de mapping pour garantir des résultats optimaux. comme le montre la figure 2 ci-dessous.
En mettant l’accent sur les systèmes cyber-physiques médicaux, ce travail reconnaît l’importance
cruciale de la sûreté dans les applications médicales. Les erreurs ou défaillances dans ces
systèmes peuvent avoir des conséquences catastrophiques. [
Pour illustrer la valeur ajoutée de notre approche, nous avons étudié le système de contrôle de la glycémie. Cette étude pratique permet de démontrer la pertinence de notre contribution dans des situations réelles, tout en mettant en avant ses aspects spécifiques via la modélisation SysML et sa correspondance avec AADL.
Le Continuous Glucose Monitoring System (CGMS) est conçu pour aider les patients diabétiques
en surveillant constamment leur taux de glycémie et en fournissant des recommandations pour
une meilleure gestion de la maladie [
Le système CGMS est un ensemble de composants (fig. 3) interagissant entre eux pour assurer une supervision eficace des patients: 1. Capteur de glucose: Inséré sous la peau du patient, il mesure en continu le niveau de glucose dans le liquide interstitiel. 2. Transmetteur: Collecte les données du capteur et les transmet au dispositif récepteur ou à un smartphone. 3. Récepteur/Dispositif d’afichage: Peut être un appareil distinct ou une application mobile. Il afiche les niveaux actuels de glucose et les tendances. 4. Application mobile: Si utilisée, elle ofre des fonctionnalités supplémentaires comme le partage de données et des notifications personnalisées.
La traduction entre SysML et AADL nécessite une compréhension approfondie des deux langages
et une méthode systématique pour assurer une correspondance précise. [
La table 2 compare deux approches liées à la traduction de modèles SysML en modèles AADL. Elle examine les diférents aspects, y compris les objectifs principaux, les domaines d’application, les méthodologies, les niveaux d’abstraction, les contributions, les résultats majeurs, les cas d’utilisation spécifiques et les outils utilisés.
Aspect/Caractéristique Objectif principal Domaine d’application Méthodologie Niveau d’abstraction Contribution Résultats Cas d’utilisation Outils
[
Systèmes critiques: aviation, au- Migration modèle: SysML vers tomobile. AADL.
Modèles SysML/AADL cohérents. Conversion automatisée SysML
vers AADL.
Conception système et logiciel. Traduction modèle SysML vers
AADL.
Intégration SysML/AADL: modéli- Transition simplifiée: SysML vers sation complète. AADL.
Cohérence et précision Réutilisation modèle SysML en améliorées. AADL.
Systèmes critiques: sûreté. Migration modèle: SysML vers
AADL.
Eclipse Papyrus (SysML), OSATE Outil de conversion SysML vers (AADL). AADL.
Deux approches sont comparées : [
Ainsi nous constatons que la traduction SysML vers AADL est une tâche complexe nécessitant une compréhension approfondie des deux langages. L’objectif est de faciliter la conception de systèmes critiques en capturant eficacement la sémantique des modèles SysML et en les reflétant correctement en AADL.
La traduction entre SysML et AADL est essentielle pour fusionner les avantages des deux
langages. SysML ofre une perspective de haut niveau de la conception du système, [
Bien que SysML soit un langage de modélisation puissant et flexible, adapté à la description de
systèmes complexes à diférents niveaux d’abstraction, il présente certaines limitations lorsqu’il
s’agit de décrire le comportement des systèmes en temps réel et d’analyser des propriétés
spécifiques telles que les performances, la sûreté et la sécurité [
La table 3 décrit les principaux choix faits concernant le passage de SysML vers AADL pour les éléments d’un diagramme de blocs SysML. Ainsi, nous avons opté pour: 1. Paquetage ↔ Package: En SysML, un paquetage sert à regrouper des éléments liés.
Dans AADL, un package remplit une fonction similaire. L’exemple montre un paquetage nommé "HealthSystem" défini en AADL. 2. Bloc ↔ Process/Thread/Device/Memory/processor/Bus: Un bloc SysML représente un ensemble cohérent d’informations ou de composants. Dans AADL, cette notion est représentée par des éléments comme les process, thread ou device. L’exemple illustre un "device" nommé "CapteurDeGlucose". 3. Block Interfaces↔ Features: Les "Interface Blocks" en SysML définissent les points d’interaction d’un bloc. Dans AADL, ce concept est capturé par les features. L’exemple montre des features associées au processus "CapteurDeGlucose". 4. Port ↔ Data/Event Port: Les ports en SysML permettent les interactions entre les blocs.
En AADL, les ports (qu’ils soient de données ou d’événements) servent à la même fin. L’exemple décrit un "device" appelé "Transmetteur" avec des ports d’entrée et de sortie pour transmettre des données. 5. Relations/composition ↔ Subcomponents: En SysML, les relations et compositions définissent comment les blocs sont reliés ou composés. En AADL, les subcomponents jouent ce rôle. L’exemple détaille la composition du "device CapteurDeGlucose" avec des sous-composants tels que "sensorUnit" et "processingUnit". 6. Flux ↔ Connections: Les flux en SysML décrivent les échanges d’informations entre blocs. En AADL, les connections remplissent cette fonction. L’exemple illustre les connexions entre les sous-composants du "device CapteurDeGlucose".
Bloc Interface Blocks Port Relations/ composition flux propriétés
package HealthSystem public ...
end HealthSystem; Process/Thread/Device Device CapteurDeGlucose ...
end CapteurDeGlucose; Features process CapteurDeGlucose features ...
end CapteurDeGlucose; Data/Event Port device Transmetteur features inputDataFromCapteur: in data port GlucoseData; outputDataToSmartphone: out data port GlucoseData; end Transmetteur; Subcomponents device implementation CapteurDeGlucose.impl subcomponents sensorUnit: abstract SensorUnitType; processingUnit: abstract ProcessingUnitType; end CapteurDeGlucose.impl; Connections device implementation CapteurDeGlucose.impl subcomponents sensorUnit: abstract SensorUnitType; connections conn1: port sensorUnit.dataOutput -> processingUnit.dataInput; conn2: port processingUnit.dataOutput -> outputGlucoseData; end CapteurDeGlucose.impl; Property Set property set HealthProperties is
Latency: aadlinteger; end HealthProperties; Élément SysML Paquetage 7. Propriétés ↔ Property Set: Les propriétés en SysML caractérisent les spécifications des blocs. En AADL, les property sets sont utilisés pour définir des propriétés spécifiques. L’exemple fournit un ensemble de propriétés "HealthProperties" qui spécifie la propriété latence.
Propriété ↔ Value (valeur): Dans le contexte d’un système, une propriété sert à définir une caractéristique ou un attribut particulier de ce système. En AADL, une value (valeur) est utilisée pour assigner une quantité ou une donnée spécifique à une propriété (voir table 4). Pour illustrer, considérer un système AADL nommé "MySystem" défini avec une propriété "HealthProperties" ayant une valeur de 50. Cela pourrait suggérer que "MySystem" est censé maintenir un niveau de santé de 50. Toutefois, l’interprétation exacte dépendrait du contexte du système et de la signification attribuée à "HealthProperties".
Élément SysML Équivalent AADL Exemple de code AADL Exigence spéci- Exigence (value) HealthProperties fique Properties:Value => 50;
end MySystem;
En SysML, un état représente une condition spécifique dans laquelle une entité (comme une machine ou un processus) se trouve à un moment donné. L’équivalent direct en AADL est le mode. Soit un dispositif AADL nommé "CapteurDeGlucose" (voir table 5). Ce dispositif peut avoir un mode "Actif", qui est défini comme son mode initial et pour lequel, on peut définir plusieurs autres modes.
Élément SysML État État de transition Transition mode Équivalent AADL Exemple de code AADL Mode device CapteurDeGlucose features outputGlucoseData: port; ... modes Actif: initial mode; ... end CapteurDeGlucose; device CapteurDeGlucose features outputGlucoseData: port; ... modes Actif: initial mode; ... end CapteurDeGlucose; out data out data
En SysML, un état de transition décrit le mouvement ou le passage d’un état à un autre. Son équivalent en AADL est la transition de modes. Bien que l’exemple fourni (table 5) ne montre pas explicitement de transition de mode, en pratique, AADL permet de spécifier les conditions ou événements qui déclenchent le passage d’un mode à un autre.
En SysML, une action représente une opération ou une activité spécifique efectuée par une entité ou un composant du système. L’équivalent direct en AADL est le thread. Un thread en AADL est conçu pour exécuter une action ou une série d’actions, souvent en réponse à des entrées et en générant des sorties. Soit un thread AADL nommé "AnalyseDonneesThread" (voir table 6) qui est conçu pour analyser des données. Ce thread possède une feature (caractéristique) "inputData" qui est un port d’entrée pour recevoir des données à analyser.
Élément SysML Action Équivalent AADL Thread
thread AnalyseDonneesThread features inputData: in data port; ... end AnalyseDonneesThread;
La relation entre SysML et AADL, axée principalement sur le mappage, s’avère cruciale dans le cadre de la modélisation et de la conception des systèmes Cyber-Physiques (CPS). Cependant, notre démarche ne se restreint pas seulement à cette étape intermédiaire. En réalité, notre vision de la recherche embrasse une gamme plus étendue de domaines et d’utilisations, dans le but d’optimiser l’emploi de l’AADL et de stimuler l’essor des CPS. Un des principaux axes de cette approche est d’intensifier l’étude et la caractérisation des MCPS via l’AADL. Ces systèmes, incarnant d’importantes intégrations logiciel-matériel, se distinguent par leur complexité et s’insèrent dans des environnements opérationnels rigoureux. En adoptant l’AADL comme langage de modélisation privilégié, nous aspirons à cerner avec une plus grande précision les caractéristiques essentielles des MCPS, spécifiquement en termes de sécurité, de fiabilité, et d’eficacité. Cette démarche s’inscrit dans une perspective plus vaste ayant pour dessein de fusionner les forces de SysML et d’AADL pour la représentation et l’appréciation des CPS, à l’instar du système de surveillance continue du glucose. Nous sommes résolus à mettre en avant des méthodologies et des outils améliorés pour l’élaboration et l’évaluation de tels CPS, renforçant ainsi leur solidité et eficience.
En conclusion, ce travail a mis en lumière notre proposition de mapping du langage SysML vers le langage AADL pour les systèmes cyber-physiques (CPS), avec comme étude de cas, un système de surveillance en temps réel de la glycémie. Cette démarche de liaison entre SysML et AADL est essentielle pour assurer la sûreté des CPS, particulièrement dans des domaines sensibles comme la santé.
Toutefois, nous reconnaissons les limites de notre étude. Malgré nos progrès, les CPS regorgent de challenges non résolus. Notre méthode, bien que robuste, requiert des optimisations et pourrait nécessiter des adaptations pour d’autres contextes MCPS. Le cadre de la surveillance glycémique, en tant qu’exemple, pourrait ne pas être universellement transposable à tous les CPS. Il s’impose donc de continuer à adapter et peaufiner notre approche pour diférentes applications CPS.
Ce travail a été partiellement soutenu par le projet LABEX-TA intitulé : "Méthodes Formelles pour le Génie Logiciel".