Autor: Dr. Simon R\u00f6sel, Model Engineering Solutions GmbH<\/p>\n
Die modellbasierte Entwicklung ist eine moderne Methode, um eingebettete Regel- und Steuersysteme zu entwickeln. Das gew\u00fcnschte Systemverhalten wird durch ein Modell als zentrales Entwicklungsartefakt beschrieben. Entsprechende Teile des Modells bilden den Ausgangspunkt f\u00fcr die automatisierte Codegenerierung f\u00fcr Steuerger\u00e4tesoftware, die der Laufzeitumgebung angepasst wird und anschlie\u00dfend auf den Controller geladen werden kann. Dabei ist der Einsatz von Modellierungsrichtlinien im Hinblick auf Funktionale Sicherheit und Qualit\u00e4tssicherung unverzichtbar.<\/strong><\/p>\n Im Automotive-Bereich sind die meisten Steuerger\u00e4te-Funktionen, die mit Hilfe der modellbasierten Softwareentwicklung entstehen, sicherheitsrelevant. Standardisierte verl\u00e4ssliche Methoden sind somit unerl\u00e4sslich. F\u00fcr die Entwicklung elektrisch\/elektronischer Kraftfahrzeugsysteme spielt die ISO 26262 („Road Vehicles \u2013 Functional Safety“) als zentrale ISO-Norm eine herausragende Rolle [1]. Die ISO 26262 widmet das komplette Kapitel 6 der Produktentwicklung auf Softwareebene und empfiehlt dabei explizit den Einsatz von semi-formalen Modellierungssprachen, wie z.B. Simulink.<\/p>\n Neben Fragen der Funktionalen Sicherheit steht in Softwareentwicklungsprozessen die Qualit\u00e4tssicherung im Vordergrund. Beide Aspekte h\u00e4ngen wesentlich vom effizienten Einsatz von Modellierungs- und Konformit\u00e4tsrichtlinien ab. Dabei gilt der Grundsatz, dass die Modellqualit\u00e4t f\u00fcr den gesamten Entwicklungsprozess entscheidend ist und damit auch die Qualit\u00e4t der generierten Software bestimmt. Weiter finden auch bekannte Elemente der statischen Quellcodeanalyse (z.B. Range Checking, Komplexit\u00e4tsanalysen, Pr\u00fcfung starker Typisierung) ihre Entsprechung in der statischen Modellanalyse.<\/p>\n Modellierungsrichtlinien lassen sich grob hinsichtlich des relevanten Modellierungsgegenstandes, der Werkzeugspezifik und der jeweiligen Ziele unterscheiden. Design-Aspekte von Simulations- und Controller-Modellen stehen bei den\u00a0MathWorks Automotive Advisory Board (MAAB)-<\/em>Regeln im Vordergrund und f\u00f6rdern durch die Einhaltung von Best Practices die Les- und Wartbarkeit [2]. Die\u00a0MISRA Simulink\/Stateflow<\/em>– und\u00a0MISRA TargetLink-Regeln<\/em>\u00a0stellen auf Sicherheitsaspekte der Modelle und des daraus zu generierenden Codes ab\u00a0[3]\u00a0[4].<\/p>\n Die\u00a0dSPACE TargetLink Modeling Guidelines\u00a0<\/em>beziehen sich ebenfalls auf die effiziente Code-Generierung mit TargetLink\u00a0[5]. Insbesondere schlie\u00dfen diese Richtlinien die Verwendung von Modellierungsmustern aus, die inkompatibel mit der automatischen Codegenerierung sind, oder zu ineffizientem Code f\u00fchren. Mit der gleichen Intention werden auch einheitliche Festlegungen f\u00fcr Modellkonfigurationen und Code-Generator-Einstellungen getroffen.<\/p>\n Steht der Entwurf sicherheitsrelevanter Software im Vordergrund steht, finden die\u00a0MES Functional Safety Guidelines<\/em>, die aus den Anforderungen der ISO 26262 und anderen Sicherheitsstandards abgeleitet sind, Anwendung [6]. Zur optimalen Vorbereitung auf dynamische Modelltests dient das\u00a0MES Fit for Testing<\/em>\u00a0Richtliniendokument [7]. Hier kommen insbesondere Regeln zum Tragen, die eine eindeutige Beziehung zwischen Modell- und Testobjekten sowie die automatische Testbed-Generierung unterst\u00fctzen.<\/p>\n Die vollst\u00e4ndige Abdeckung aller relevanten Aspekte erfordert eine sinnvolle Kombination der verschiedenen Regelwerke.<\/p>\n Siehe Bilder 1 und 2 (PDF<\/a>) .<\/p>\n 1) Vermeidung nicht-robuster Modellierungstechniken:<\/strong><\/p>\n Um nicht-robuste Modellierungstechniken zu umgehen, ist vor allem die Definition eines „Safe Subset“, d.h. die Festlegung einer Untermenge sicherer syntaktischer Elemente der jeweiligen Modellierungssprache, notwendig.<\/p>\n 2) Erh\u00f6hung von Effizienz und Sicherheit:<\/strong><\/p>\n Wesentliche Ma\u00dfnahmen, um dieses Ziel zu erreichen, sind die einheitliche Modell- und Werkzeugkonfiguration sowie einheitliche, gesicherte Einstellungen f\u00fcr Codegenerierung und -optimierung. Des Weiteren k\u00f6nnen bekannte ineffiziente oder funktional riskante Modellierungsmuster, beispielsweise die Verwendung von Gleitkommavariablen f\u00fcr Boolesche Signale, durch Modellierungsrichtlinien verboten werden.<\/p>\n 3) Bessere Lesbarkeit, Wiederverwendung, Erweiterbarkeit, Wartbarkeit:<\/strong><\/p>\n Diese Ziele k\u00f6nnen durch Vorgaben, die das graphische Layout, Namenskonventionen sowie spezifische Restriktionen f\u00fcr die Verwendung von Modellierungselementen betreffen, erreicht werden. Insbesondere wird dadurch die verteilte Entwicklung, beispielsweise zwischen OEM und Zulieferer, gef\u00f6rdert.<\/p>\n 4) Einhaltung von Sicherheitsstandards:<\/strong><\/p>\n Die Einhaltung von Sicherheitsstandards (z.B. IEC 61508, ISO 26262, ISO 25119, DO-178C) stellt ein \u00fcbergeordnetes Ziel dar (s.u.).<\/p>\n Die Wart- und Testbarkeit von Modellkomponenten h\u00e4ngt wesentlich von einer sinnvoll gew\u00e4hlten Modellarchitektur ab. Die Herausforderung liegt hierbei darin, Funktionalit\u00e4ten so zu kapseln, dass Module beherrschbarer Komplexit\u00e4t entstehen, die durch effektive Interfaces gekoppelt sind. Ein weiterer Aspekt, der bei der Modellstrukturanalyse eine Rolle spielt, ist die Vermeidung von\u00a0Model Clones [8]<\/em>. Solche semantisch \u00e4quivalenten Teilstrukturen reduzieren die Wartbarkeit des Modells deutlich und sollten deshalb vermieden werden. Um Modelle automatisiert hinsichtlich dieser Fragestellungen zu analysieren, kommen in der Praxis verschiedene Metriken zum Einsatz. Neben der Anzahl relevanter Sprachkonstrukte geh\u00f6ren die Metriken\u00a0local complexity<\/em>\u00a0und\u00a0global complexity<\/em>\u00a0sowie die f\u00fcr Modelle adaptierte\u00a0Halstead-Metrik\u00a0<\/em>zu den wichtigsten Vertretern\u00a0[9].<\/p>\n Als generische Norm f\u00fcr sicherheitsrelevante E\/E\/PE-Systeme definiert die IEC 61508 eine Reihe von Ma\u00dfnahmen, die sowohl den Entwicklungsprozess als auch das Produkt betreffen, um die Sicherheit des Systems zu gew\u00e4hrleisten. Als kraftfahrzeugspezifische Auslegung fordert die ISO 26262 in Kapitel 6 („Product Development at the Software Level“) die Ber\u00fccksichtigung einer Reihe von Aspekten (Topics<\/em>), die je nach\u00a0Automotive Safety Integrity Level (ASIL)<\/em>\u00a0der zu entwickelnden Funktion unterschiedliche Relevanz haben [1].<\/p>\n Daher muss beim Einsatz von Richtlinien f\u00fcr sicherheitsrelevante Softwarekomponenten beachtet werden, dass die von der ISO genannten\u00a0Topics<\/em>\u00a0adressiert werden, in dem die abgeleiteten Regeln am Modell (und im Code) umfassend gepr\u00fcft werden, um, falls n\u00f6tig, entsprechende Anpassungen vorzunehmen. Die speziell f\u00fcr Modellierungs- und Coderichtlinien relevanten Aspekte aus der ISO 26262 sind in Abbildung 3 zusammengefasst. Teil 6 der ISO 26262 enth\u00e4lt dar\u00fcber hinaus auch konkrete Implementierungsvorgaben zum Design von Softwaremodulen. Diese dienen haupts\u00e4chlich dazu, die korrekte Ausf\u00fchrung von Programmteilen innerhalb von Modulen sicherzustellen sowie die Schnittstellenkonsistenz zwischen Modulen zu erreichen. Die f\u00fcr die modellbasierte Entwicklung relevanten\u00a0Topics<\/em>\u00a0sind in Abbildung 4 zusammengefasst.<\/p>\n techniques<\/td>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Abb. 3: ISO 26262-6, \u00a7 5.4.7, Tabelle 1 (o keine Empfehlung \/ + empfohlen \/ ++ sehr empfohlen)<\/em><\/p>\n Des Weiteren enth\u00e4lt ISO 26262-6 abstrakte Prinzipien zum Entwurf der Softwarearchitektur, die darauf abzielen, Fehler, die durch hohe Komplexit\u00e4t entstehen, zu reduzieren. In vielen F\u00e4llen k\u00f6nnen auch hier konkrete Richtlinien f\u00fcr den modellbasierten Ansatz abgeleitet werden, die f\u00fcr eine Konformit\u00e4tspr\u00fcfung bez\u00fcglich der Prinzipien der ISO herangezogen werden k\u00f6nnen [9].<\/p>\n Abb. 4: ISO 26262-6, \u00a7 8.4.4, Ausschnitt Tabelle 8 mit Aspekten, die f\u00fcr die modellbasierte Softwareentwicklung relevant sind F\u00fcr den praktischen Einsatz von Modellierungsrichtlinien sind statische Modellanalysen fortlaufend w\u00e4hrend des Entwicklungsprozesses automatisiert zu integrieren. Dies gilt insbesondere f\u00fcr Pr\u00fcfroutinen zur Richtlinienkonformit\u00e4t. Als Grundlage der Automatisierungs-Infrastruktur werden in der Regel Jenkins-Server eingesetzt. Diese sind f\u00fcr die Ausf\u00fchrung verschiedener Auftr\u00e4ge von Modell-Ingenieuren, Modul-Testern und Software-Testern konfiguriert. Insbesondere k\u00f6nnen statische Modellanalysen, h\u00e4ufig im nahtlosen Zusammenspiel mit Versionsverwaltungssystemen, automatisiert ausgewertet werden und somit Qualit\u00e4tsschranken ressourcenschonend und effizient \u00fcberpr\u00fcft werden.<\/p>\nStatische Modellanalyse: Die Anwendung von Richtlinien und Standards<\/h2>\n
Quellen f\u00fcr Modellierungsrichtlinien, Beispiele<\/h2>\n
Ziele f\u00fcr den Einsatz von Modellierungsrichtlinien<\/h2>\n
Modellstruktur-Analyse und Komplexit\u00e4tsreduzierung<\/h2>\n
Vorgaben von Standards wie ISO 26262 und IEC 61508 zu Richtlinien und Designprinzipien<\/h2>\n
\n\n
\n Topic<\/strong><\/td>\n ASIL A<\/strong><\/td>\n ASIL B<\/strong><\/td>\n ASIL C<\/strong><\/td>\n ASIL D<\/strong><\/td>\n<\/tr>\n \n Enforcement of low complexity<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Use of language subsets<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Enforcement of strong typing<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Use of defensive implementation<\/p>\n o<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Use of established design principles<\/td>\n +<\/td>\n +<\/td>\n +<\/td>\n ++<\/td>\n<\/tr>\n \n Use of unambiguous graphical representation<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Use of style guides<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Use of naming conventions<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n
\n Topic<\/strong><\/td>\n ASIL A<\/strong><\/td>\n ASIL B<\/strong><\/td>\n ASIL C<\/strong><\/td>\n ASIL D<\/strong><\/td>\n<\/tr>\n \n Initialization of variables<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n No multiple use of variable names<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n Avoid global variables or else justify their usage<\/td>\n +<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n No implicit type conversion<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n \n No hidden data flow or control flow<\/td>\n +<\/td>\n ++<\/td>\n ++<\/td>\n ++<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n(+ empfohlen \/ ++ sehr empfohlen)
\n<\/em><\/p>\nContinuous Integration von statischer Modellanalyse<\/h2>\n
Literaturverzeichnis<\/h3>\n