La splendeur et la pauvreté de la conception orientée modèle selon les normes aéronautiques DO-331

Dans des articles précédents sur la conception orientée modèle Comment ne pas répéter Tchernobyl , un entraînement électrique avec un moteur à courant continu sans balais , et Création d'un modèle fiable, en utilisant l'exemple d'un échangeur de chaleur pour l'aviation , j'ai montré avec des exemples que toutes les méthodes de conception orientée modèle (MOS) n'étaient pas également utiles.


Débutant mon activité d'ingénieur dans l'industrie nucléaire, je suis habitué au fait que la première étape de conception est la création d'un modèle objet. Le modèle de l'installation dans l'industrie nucléaire est une partie obligatoire du projet. Les outils de simulation pour les centrales nucléaires subissent une certification, où l'examen détermine leur applicabilité à la modélisation informatique des processus des centrales nucléaires. Et s'il existe un modèle de l'objet, alors le modèle du système de contrôle est naturellement développé ensemble comme un modèle complexe. C'est exactement ce qui, à mon avis, est une méthode de conception orientée modèle.


À mon avis, la modélisation d'un système de contrôle seul sans créer de modèle objet est défectueuse. Par conséquent, lorsque vous écoutez les histoires de fournisseurs de logiciels de modélisation pour le développement de logiciels, vous devez comprendre ce qui est en jeu: sur les nouvelles techniques avancées de développement de systèmes ou sur la conception orientée modèle dans la compréhension de la norme aéronautique DO-331.




Il ne faut pas oublier que le MOS dans les normes aéronautiques reflète une approche obsolète et conservatrice du développement logiciel orienté modèle. Et dans cette approche, même si votre modèle n'est qu'un ensemble de diagrammes UML où les exigences logicielles sont collectées, il restera une conception orientée modèle en termes de DO-331.


«DO-331 Model based development for engineer and manager», Vance Hilderman (vance.hilderman@afuzion.com) Vance Hilderman www.afuzion.com


DO-331, , .



«DO-331 - », DO-178C DO-278A 125 - (odel_Based Development (MBD)) . , DO-331 : , - ?


: « ?» : « 100% .» ( , ). , , 100% . , , , , .
: , . , , . BD « » , .


, . , . , , , . , DO-331 MBD


N
1, , « » « ?», ,
2?, ,
3?, ,
4, ?, ,
5, , , ?, ,

?


, . NASA. , , . «» , , , , «» (hardware) . ( «hardware» , , «firmware», «complex electronic hardware» via DO-254). , , . , , , , , , . «-».


, DO-331 2011 ? . :


  1. . .
  2. . , .
  3. . .
  4. . Simulink SysML.
  5. = . .
  6. . .
  7. . .


, . , , , . . , , . , , . , ? , :


  1. DO-331 ;
  2. C ;
  3. ;
  4. DO-330;
  5. , , ;
  6. -;
  7. ;
  8. , .

? , – « ». .


-, DO-331 . , , .


-, , . IBM’s Rhapsody and Magic Draw .


-, , , – , , .


-, . ( , , ), , .


-, , .


, . , IBM’s Rhapsody, 20- , .



, , .


(Code Generation), , ++, Ada
(Design Model), , , , , () . , , .
(Model), , , , . , .
- (Model-Based Development and Verification)
, () .
- (Model-Based Test)() .
(Model Checking), , .
(Model Coverage Analyses), , , , , , . , ().
(Model Element), .
(Model Element Library), . .
(Model Simulation).
(Model Simulator), , .
(Modeling Technique). , .
(Report Generation), .
(Reverse Engineering).
(Specification Model), , , , . , .
(Symbology). .
SysML, UML .
UMLUnified Model Language, , . UML , , .

.


DO-178C, , : (high level requirements (HLR’s), (low-level requirements (LLR’s) . HLR’s LLR’s . DO-331 – , :


image


, HLR’s LLR’s. : – , . , . , , .


UML (user cases) , – UNL ( , ) . (LLR’s) . , .


DO-178C DO-331, , , , . «Harmony Process for Embedded Software» ( Real-Time Agility Real-Time UML Workshop for Embedded Systems 2nd Edition, Bruce Powel Powel Douglass). .



user case ( Dr. Bruce Douglass, IBM)



( Dr. Bruce Douglass, IBM)




( Dr. Bruce Douglass, IBM)



Simulink ( c Mr Eric Dillaber, Simulink Certification Manager)


, , , . DO-331 5 . 5 MB1 MB5.



, , . , , .


:


MB1 — , :
+ , .
- . (HLR) .


MB2 – :
+ , .
- .


MB3 – :
+ (HLR)
- , .


MB4 – . :
+ . .
- .


MB5 – . :
+ - (HLR), , .
- .


. .


. «, »: , . . ? . , :



? , .. , . , – , ( ), .



, , . UML , . «», /, , . - Test Conductor IBM Rhapsody’s .


– , . , DO-333 ( DO-178C DO-278A). , « » .


. ( )


– . . :


  • ( )
  • ( )
  • PrĂ©cision et exhaustivitĂ©
  • VĂ©rifiabilitĂ©
  • Algorithmes de travail

Cependant, la modélisation n'est pas destinée à vérifier les aspects suivants:
  • CompatibilitĂ© informatique cible
  • ConformitĂ©
  • TraçabilitĂ©
  • IntĂ©gritĂ© des pièces

Vérification du modèle et du code.


Le profil de test UML (www.omg.org) propose une approche standard pour définir, exécuter et analyser des scripts de test dans le langage UML. Cela signifie que tous les avantages de la modélisation peuvent être obtenus non seulement à partir du modèle de spécification et du modèle de conception, mais également à partir des outils de vérification de ces modèles.


Test Conductor IBM Rhapsody’s DO-178. , , .


.


, , . , , . , .


() , . :

  • , .
  • , .

Bien sûr, la traçabilité des modèles peut être effectuée manuellement, mais les outils de modélisation ont des fonctionnalités intégrées pour prendre en charge et assurer la traçabilité


Conclusion


La modélisation est un outil puissant de plus en plus utilisé en avionique. La norme DO-331 fournit une base pour comprendre les principes de la modélisation, en utilisant toute la puissance des technologies de modélisation et décrit les moyens de prouver l'exactitude du modèle.


All Articles