Slides

Dependability
Mechanics
System Engineering
Software
Electronics
Méthodes et outils d’ingénierie de systèmes
mécatroniques fiables ….
Hubert Kadima
Directeur de Recherche en informatique EISTI
Journée GdrMACS du 03.05.2010 – SupMéca Paris
Dependability
Mechanics
Agenda
System Engineering
Software
Electronics
• 1. Introduction
• 2. Panorama d’outils mécatroniques actuels
• 3. Survol de méthodes MBSE (Model-Based System
Engineering)
• 4. Vérification formelle des systèmes mécatroniques
• 5. A titre de conclusion : quelques thèmes de recherche
sur ces aspects.
1. Introduction
Des processus aux méthodes, outils, méthodologies et standards
d’Ingénierie Systèmes … *
•
•
•
•
•
Un processus est une séquence logique de
tâches réalisées pour atteindre un objectif
particulier. Un processus définit ici le
“QUOI” sans spécifier “COMMENT” la
tâche sera réalisée.
Une méthode comporte les techniques pour
réaliser une tâche, le « COMMENT » de
chaque tâche. Les termes « méthode »,
« technique », »pratique » et
« procédure » sont interchangeables dans
ce contexte.
Un outil est un instrument qui, appliqué à
une méthode particulière permet
d’améliorer l’efficacité d’une tâche. Alors,
les méthodes comblent le fossé entre
processus et outils. L’objectif d’un outil
pourrait être de faciliter la réalisation des
“COMMENT”.
Une méthodologie peut être définie comme
une collection des processus, méthodes et
outils.
*Source: James N. Martin, Systems
Engineering Guidebook, CRC Press, 1997.
Espace de problèmes et de solutions de
l’ingénierie système
Apport de l’ingénierie système
Intégrer toutes les disciplines et corps de
métiers dans un effort d’équipe.
Comprendre le problème complet avant de
chercher à le résoudre
Traduire le problème en exigences
mesurables
Itérativement décomposer le problème
complexe en problèmes plus simples
pouvant être alloués à une seule discipline.
Examineer et modéliser toutes les
alternatives faisables avant de sélectionner
une solution.
Préparer l’intégration et la validation aussi
tôt que possible dans le cycle de de
conception.
Justifier et documenter tous les éléments de
la conception …
Une approche multidisciplinaire de
conception de systèmes :
–Centrée sur la satisfaction des
besoins de toutes les parties
prenantes (marketing,
commerciaux, techniques …)
–Permettant d’assurer le meilleur
compromis qualité, coûts,
performances, planning, maîtrise
des risques : choix basés sur des
critères qualititatifs et quantitatifs
Problèmes engendrés par l’ingénierie mécatronique ….
•
Discontinuité dans le
processus technique
d’ingénierie
•
Diversité d’outils et des
modèles
Maintien de la cohérence
des modèles et
raffinement …
Automatisation des
transformations ..
Cosimulation
multiphysique
Nécessité d’une approche
collaborative et
participative de tous les
corps de métier dans la
•
•
•
•
Vers une plateforme intégrée d’ingénierie système permettant
l’exécution du processus technique d’ingénierie système
conformément aux standards, normes et bonnes pratiques …
Conformité au standard ISO 15 288 : Systems
engineering – System life cycle processes
Cette norme étend les processus
techniques à tout le cycle de vie
du système (elle couvre ainsi les
processus d’exploitation,
de maintien en condition
opérationnelle et de retrait de
service).
La norme s’applique à l’ingénierie
des systèmes contributeurs qui
ont leur propre cycle de
vie (systèmes de fabrication, de
déploiement, de soutien
logistique, de retrait de service)
2. Panorama d’outils mécatroniques actuels
• 2.1. Quelques activités techniques d’ingénierie
mécatronique
• 2.2. Quelques outils remarquables ..
• 2.3. Intégration/Interopérabilité entre outils
Exemples des activités techniques en
mécatronique ..
•
•
•
•
•
•
•
•
•
–
Modélisation Systèmes Multi-domaines
( mécanique, électronique, informatique, automatique)
–
Modélisation dynamique 3D multi-corps (rigide et élastique)
–
Modélisation multi-physique par éléments finis:
(thermodynamique, fluidique, CEM, vibro-acoustique)
–
Intégration 3D : mécanique, électrique, électronique
–
Instrumentation, conditionnement et traitement du signal
–
Sûreté de fonctionnement
–
Algorithmes de commande avancée, capteurs logiciels et
diagnostic en ligne
–
Prototypage rapide (cibles DSP multi-coeurs, FPGA), HIL …
–
Optimisation énergétique et éco-conception etc …
Une diversité d’outils pour diverses activités techniques …
Analyse & identify
the environment
Matlab/Simulink
SysML
Different types
of Models
Capitalize & Share
Know-how
AMESIM
Explore & choose
Operational concepts
Simulink
RTW/EC
SysML
Estimate performances
& dependability
Matlab/Simulink
Formalize problem &
Validate requirements
Build Functional &
Physical Architecture
Fluent 3D
Flux 2D / 3D
PSpice
Catia
Design components
features
Prototype & autocode
software
Outils de gestion des exigences et
de modélisation/Spécification
Produits
Fonctions/Editeurs
DOORS
Gestion des exigences
Editeur Telelogic
REQTIFY
Editeur TNI
Gestion des exigences
Artisan Studio
Modélisation/Spécification
Rapsody
Modélisation/Spécification
Atelier B
Modélisation/Spécification
L’Atelier B est un environnement de développement se basant sur le
langage B et qui permet de spécifier, de raffiner et d’implanter une
application. La vérification de l’application est réalisée au travers de
la mise en place d’une phase de preuve de lemmes mathématiques.
Outils simulation/vérification …
MatLab/Simulink
Simulation/vérification
Utilisable dans tous domaines et systèmes
Modélisation et design des systèmes physiques compris.
StateMate
Validation de spécifications et prototypage rapide via la
modélisation comportementale et fonctionnelle exécutable
AMESim
Simulation
Scade
Editeur Esterel Technologies
Scade est un environnement de développement d’applications
embarquées critiques soumises à des fortes contraintes de
certification (DO-178B Level A ou IEC 61508 SIL3/SIL4).
Scade est basé sur les modèles synchrones qui sont des langages
spécialisés conçus pour la programmation sûre de systèmes réactifs
et temps réel.
Scilab/Scicos
Modélisation et simulation de systèmes dynamiques hybrides
Architectures/Cosimulation
Syndex
Modélisation de fonctionnalités, d’architectures
embarquées et d’implantation distribuée sous
temporelles
distribuées
contraintes
Dymola/Modelica
Dymola (Dynamic Modeling Laboratory)est unenvironnement
complet, basé sur le langage Modelica, pour la modélisation et la
simulation des systèmes complexes intégrés dans différents
domaines.
Cosimate
Un environnement de co-simulation qui permet à plusieurs
simulateurs (Simulink, Saber, AMESim, Statemate...) de
communiquer entre eux par le biais d'une architecture de bus de cosimulation .
Prototypage/Simulation HIL
DSPACE
Simulation HIL / Prototypage
SolidWorks
Conception mécanique – simulation
NASTRAN FEMAP
Conception – simulation par éléments finis
SynDEx
INRIA
Modélisation de fonctionnalités, d’architectures
embarquées et d’implantation distribuée sous
temporelles
Génération pseudo-code indépendant de la cible
distribuées
contraintes
Operational
Customer
Needs
USER
Repository
Traceability
results
User
Requirements
Functional
Architecture
Tools
SYSTEM
PRODUCT
Architecture Breakdown
Component
Requirements
REQTIFY
COMPONENT
Development
Tools
DISCIPLINE
Physical
Refined requirements
Design/Validation Elements
Exemple d’intégration d’outils dans le cycle de vie d’un
processus d’ingénierie système
Nécessité d’un environnement intégré d’outils de conception mécatronique
SystemVision fournit un environnement d’intégration d’outils de conception, modélisation, analyse
autour du noyau d’un moteur de simulation …
3. Survol de méthodes MBSE (Model-Based System
Engineering)
• 3.1. Bénéfices du MBSE
• 3.2. Principales méthodologies MBSE actuelles
• Modéliser les besoins avant de penser à la solution ….
Bénéfices du MBSE…
•
•
•
Amélioration de la qualité
– Identification au plus tôt des
problèmes en partant des exigences
– Amélioration de la spécification avec
la possibilité d’allouer les exigences
aux composants matériels et logiciels
– Traçabilité des exigences plus
rigoureuses
Amélioration de la productivité
– Amélioration de l’analyse de l’impact
lors du changement des exigences
– Réutilisation des modèles existants
pour supporter l’évolution de la
technologie/conception
– Auto-génération de la documentation
Réduction de risques
– Réduction des coûts de conception
– Validation/Vérification au plus tôt
des exigences
3.2. Principales méthodologies d’IS actuelles …
•
•
•
•
•
•
•
•
IBM Telelogic Harmony-SE
Harmony-SE : un sous-ensemble d’un processus plus large de développement
intégré logiciel/systèmes connu sous le nom de Harmony.
INCOSE Object-Oriented Systems Engineering Method (OOSEM)
Intègre une approche top-down basée modèle utilisant OMG SysML™ pour
effectuer la spécification, l’analyse, la conception et la vérification de systèmes.
(Systems and Software Consortium en collaboration avec Lockheed Martin
Corporation)
IBM Rational Unified Process for Systems Engineering (RUP SE) for ModelDriven Systems Development (MDSD). RUP est une méthodologie et un métaprocessus (IBM Rational) couramment utilisé en entreprises pour gérer les projets
logiciels.
Vitech Model-Based System Engineering (MBSE) Methodology
JPL State Analysis (SA)
Dori Object-Process Methodology (OPM)
Quelques éléments du process Harmony-SE basé SysML
INCOSE MBSE
Roadmap
MBSE Capability
Reduced cycle times
System of systems
interoperability
Design optimization across broad trade space
Cross domain effects based analysis
June 15, 2008
Institutionalized
MBSE across
Academia/Industry
Distributed & secure model repositories
crossing multiple domains
Well
Defined
MBSE
Maturity
Defined MBSE theory, ontology, and formalisms
Architecture model integrated
with Simulation, Analysis, and Visualization
Matured MBSE methods and metrics,
Integrated System/HW/SW models
Ad Hoc MBSE
Document Centric
Emerging MBSE standards
2010
Refer to activities in
the following areas:
•Planning & Support
•Research
•Standards Development
•Processes, Practices, & Methods
•Tools & Technology Enhancements
•Outreach, Training & Education
2020
2025
4. Vérification formelle de systèmes mécatroniques …
•
•
•
•
4.1. Problématique
4.2. Approche par model-checking
4.3. Vérification formelle des systèmes hybrides
4.4. Invariance des propriétés de systèmes à travers les
relations de composition et de raffinement …
• 4.5. Vers un environnement intégré d’outils PBSE (ProofBased System Engineering)
Vérification : Le système satisfait-il les propriétés
attendues
•
•
•
Comment fonctionne le système au point de vue opérationnel ? Architecture,
Communication, Comportements, Caractéristiques temporelles, ...
Quelles propriétés le système doit-il respecter?
Sûreté, Vivacité, Respect des contraintes temporelles,
•
De nombreuses méthodes existent actuellement pour effectuer ces
vérifications en se basant sur les méthodes formelles et surtout
l’approche par model-checking …
•
•
•
•
•
•
Analyse des propriétés
Classes de Propriétés
- Générales : blocage, borné, invariants, quasi-vivacité, ...
- Spécifiques: Logiques temporelles (linéaires, arborescentes)
Explosion Combinatoire / Espace d'états infinis
Abstractions : Représentation finie préservant certaines classes de propriétés (Prop Générales, Logiques temporelles,
Bisimulation)
- Abstraction d'espaces d'états Atemporels (Ordres Partiels)
- Abstractions finies d'espaces d'états temporels (Classes d'états)
•
•
La vérification à tous les étages !!
Exemple de mise en œuvre dans l’automobile avec la méthodologie
MeMVaTex ….
Différents types de vérification …
•
•
•
•
•
•
•
- Vérification visuelle (affichage du
graphe d'états)
- Vérification par équivalence de
comportement : Bisimulation
- Evaluation de formule de logique
temporelle (mu-calcul) : Evaluation
Techniques de résolution de la
problématique d’explosion
combinatoire
- Vérification à la volée (sur le
graphe d'états implicite)
- Vérification compositionnelle
- Vérification distribuée sur des
grappes d'ordinateurs
Un système mécatronique en tant
que système hybride …
•
Un système hybride est un système qui nécessite dans sa description la prise en
compte de sa dynamique continue et de sa dynamique discrète. La dynamique
continue est représentée par des variables continues, la dynamique discrète
représente les changements d’états dus à l’occurrence d’événements.
•
Ces modèles peuvent êtres classés selon deux approches : une approche
intégrée qui intègre, au sein d’un même formalisme, les aspects continus et
discrets ; une approche séparée qui sépare ces deux aspects en faisant
coopérer deux modèles différents.
•
L’assistance d’outil de preuve dans la preuve formelle d’un tel système
nécessite la formalisation complète du problème de vérification. La description
de l’algorithme, les hypothèses sur son environnement,et les propriétés
attendues doivent être exprimées dans un langage ayant une syntaxe et une
sémantique formelles, s’appuyant sur un cadre logique bien défini.
Représentation formelle des modèles hybrides
• L’approche intégrée englobe des modèles issus de
l’extension de modèles continus comme les Bond
Graphes à commutation et ceux issus de
l’extension de modèles à événements discrets
comme les réseaux de Petri hybrides.
• L’approche séparée regroupe les modèles à base
d’Automates hybrides, de Statecharts hybrides,de
réseaux de Petri mixtes ou de réseaux de Petri
Prédicats-Transitions-Différentiels (RdP PTD)
etc….
Composition
• Mise en parallèle d'instances des composants
de base
•
Définition de connexions entre les ports des
composants
Relation de raffinement …
•
Formellement, nous pouvons exprimer le raffinement comme une relation
notée ► reliant deux différents modèles, le premier est le modèle abstrait, le
second est le modèle raffiné :
• ModèleAbstrait ► ModèleRaffiné
• En effet, un modèle concret est un modèle abstrait raffiné en plusieurs étapes :
• ModèleAbstrait ► ModèleConcret
• Il peut être considéré comme un autre modèle architectural adéquat à
l’implémentation.
• La relation de raffinement peut être définie selon deux points de vue :
• o l’un externe où le raffinement relie seulement les comportements
observables et les ports des éléments architecturaux (par des connexions
libres),
• o l’autre interne où le raffinement relie les comportements sans restriction à
l’observabilité c’est-à-dire que les connexions restreintes sont également
observables.
Raffinement des éléments
architecturaux
• Raffinement vertical/Raffinement horizontal
• Une relation de raffinement d’un point de vue
externe ou interne s’établit sous l’une des quatre
formes suivantes :
• o raffinement du comportement,
• o raffinement de l’interface,
• o raffinement de la structure,
• o raffinement des données.
5. Conclusions : Constats …..
•
Manque actuel de méthodologie de conception pour les systèmes
multi-domaines/multiphysiques
couvrant selon un continuum, la
capture des exigences jusqu’à la définition numérique exhaustive du
prototype virtuel (pas de rupture numérique, traçabilité des choix…).
•
Manque de passerelles pour assurer ce continuum entre les différents
outils de conception utilisés.
•
Manque actuel d’outils pour l’analyse et la simulation/cosimulation
multi-physique avec couplage fort de champs, tel que la superposition
d’un champ thermique, d’un champ de contraintes mécaniques et d’un
champ électromagnétique au sein d’un composant compact.
Quelques axes de travaux de recherche ..
•
•
•
•
•
- Aspects théoriques et mise en œuvre pratique des modèles
(qualitatifs et/ou quantitatifs) pour la spécification de
comportement et/ou des propriétés de systèmes mécatroniques
considérés comme systèmes hybrides : automates hybrides, réseaux
de Petri, équations différentielles algébriques, logique temporelle,
logique temporelle probabilisée et/ou temporisée, ...
- Aspects méthodologiques : composition, raffinement, orientation
objet, approches multi-modèles, tissage des aspects ...
- Analyse : vérification formelle, raffinement, évaluation
(performances, sûreté de fonctionnement), test...
Amélioration des processus IS existants
•
Définir un processus itératif et incrémental, multivues prenant en considération les
cycles, les phases, les enchaînements d’activités, la réduction des risques, le contrôle
qualité, la gestion de projet et la gestion de configuration.
•
•
•
•
Les caractéristiques essentielles de ce processus peuvent être les suivantes :
La conformité au processus d’ingénierie système ISO 15288.
La traçabilité des exigences tout le long du cycle de développement.
L’extension par annotation des modèles SysML avec les propriétés non fonctionnelles
(performances, fiabilité, disponibilité ...).
La possibilité d’intégration de plusieurs langages et outils ; la construction des passerelles à
partir des modèles pivots SysML devrait être envisagée.
La mise en œuvre de l’approche MDA (Model-Driven Architecture) pour la transformation
des modèles et la construction des passerelles entre outils.
La vérification formelle des propriétés du système dans toutes les phases de conception
La vérification assistée de la cohérence entre les modèles SysML reflétant diverses vues de
l’architecture.
•
•
•
•
SysML en tant que plateforme d’intégration
basée modèles
Intégration ontologique de modèles …
Producer
Tools
Electrical
CAD Tools
Mechanical
CAD Tools
Eagle
NX
Mentor
Graphics
CATIA
AP210
AP203, AP214
Systems Engineering
Tools
DOORS
E+,
MagicDraw,
...
…
AP233, SysML
Federated System Model
Standards-based
Submodels
Meta-Building Blocks:
• Information models & meta-models
• International standards
• Industry specs
• Corporate standards
• Local customizations
• Modeling technologies:
• Express, UML, SysML,
COBs, OWL, XML, …
Quelques références bibliographiques (1)
•
•
•
•
•
[1] Friedenthal, Sanford, Moore, Alan, and Rick Steiner, Practical Guide to SysML:
Systems Modeling Language, Morgan Kaufmann Publishers, Inc.: San Francisco,
CA, 2008.
[2] “Object-Oriented Systems Engineering Method (OOSEM) Tutorial,” Ver.
02.42.00, Lockheed Martin Corporation and INCOSE OOSEM Working Group,
Apr. 2006.
[3] Kruchten, Philippe, The Rational Unified Process: An Introduction, Third
Edition, Addison-Wesley Professional: Reading, MA, 2003.
[4] Long, James E., “Systems Engineering (SE) 101,” CORE®: Product & Process
Engineering Solutions, Vitech training materials, Vitech Corporation, Vienna, VA,
2000.
[5] “Vitech Announces Participation in INCOSE’s 17th Annual International
Symposium, Delivering Five Key Systems Engineering Presentations, Papers and
Panels,” Vitech News Release, Vitech Corporation, Vienna, VA, Feb. 23,
2007.Dori, Dov, Object-Process Methodology: A Holistic Systems Paradigm,
Springer-Verlag: Berlin Heidelberg, Germany, 2002.
Références bibliographiques (2)
•
•
•
[6] E. Technologies. Efficient development of safe avionics software with do178b objectives using scade suite. Technical report, Esterel Technologies,
2006.
[7] E. Technologies. Simulink gateway guidelines. Technical report, Esterel
Technologies, 2006.
[8] S. Khalfaoui, E.Guilhem, H. Demmou, R. Valette, « Modeling critical
mechatronic systems with Petri Nets and feared scenarios derivation »,
ECM2S5 5th Workshop on Electronics, Control, Modeling, Measurement and
Signals, 30-31 May, 1er Juin, 2001, Toulouse, France p. 55-59.
Références bibliographiques (3)
• INCOSE SE HandBook Version 3
• http://www.incose.org/REGAL
• http://www.omg.org/mda/
• http://www.uml.org/
• http://www.omgsysml.org/
• http://www.VentureLab.gatech.edu-based start-up: tools for
executable SysML parametrics