Tagungsband
Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteter Systeme VIII
Model-Based Development of Embedded Systems 06.02.2012 – 08.02.2012
fortiss GmbH Guerickestr. 25 80805 München
Organisationskomitee Holger Giese, Hasso-‐Plattner-‐Institut an der Universität Potsdam Michaela Huhn, TU Clausthal Jan Philipps, Validas AG Bernhard Schätz, fortiss GmbH Programmkomitee Dr. Mirko Conrad, The Mathworks GmbH Prof. Dr. Ulrich Epple, RWTH Aachen Prof. Dr. Holger Giese, Hasso-‐Plattner-‐Institut an der Universität Potsdam Dr. Michaela Huhn, TU Clausthal Dr. Hardi Hungar, OFFIS Prof. Dr. Stefan Kowalewski, RWTH Aachen Ulrich Nickel, Hella KGaA Hueck&Co Dr. Oliver Niggemann, dSPACE GmbH Jan Philipps, Validas AG Dr. Ralf Pinger, Siemens AG Prof. Dr. Bernhard Rumpe, RWTH Aachen Dr. Bernhard Schätz, fortiss GmbH Prof. Dr. Andy Schürr, TU Darmstadt Prof Dr.-‐Ing. Birgit Vogel-‐Heuser, TU München Prof. Dr. Albert Zündorf, Universität Kassel
Inhaltsverzeichnis Herausforderungen bei der modellbasierten Entwicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation Christian Dziobek, Dr. Thomas Ringler, Dr. Florian Wohlgemuth Ein Ansatz zur Qualitätsbewertung von modellbasierten Entwicklungsprojekten eingebetteter Software Hartmut Pohlheim, Ingo Stürmer
1
11
Solving Modeling Problems with Machine Learning - A Classification Scheme of Model Learning Approaches for Technical Systems Oliver Niggemann, Benno Stein, Alexander Maier 21 Automating Code Reviews with Simulink Code Inspector Mirko Conrad, Tom Erkkinen, Matt Englehart, Xiaocang Lin, Appa Rao Nirakh, Bill Potter, Jaya Shankar, Pete Szpak, Jun Yan (The MathWorks, Inc.)
31
Frontloading of Complexity – Experience with AUTOSAR Ulrich Freund (ETAS GmbH)
37
Einfluss von Wiederverwendung zeitkritischer Funktionen in AUTOSAR Michael Liebig, Jens Weiland
39
Scheduling shared memory multicore architectures in Af3 using Satisfiability Modulo Theories Sebastian Voss, Bernhard Schätz
49
Modeling for automated test generation - a comparison Hartmut Lackner, Holger Schlingloff
57
Towards Causality Checking for Complex System Models Florian Leitner-Fischer, Stefan Leue
71
A Model-Based Implementation of Function Block Diagram Sten Grüner, David Kampert, Ulrich Epple
81
Darstellungskonzepte für die zustandsabhängige Diagnose industrieller Kommunikationsnetzwerken für verteilte Automatisierungssysteme Dmitry Renzhin, Dorothea Pantförder, Jens Folmer, Birgit Vogel-Heuser 91 Modelling Technical Constraints and Preconditions for Alternative Design Desicions Alexander Pacholik, Matthias Riebisch
101
Towards an Extensible C for Embedded Programming Markus Voelter, Bernhard Schätz, Dan Ratiu, Bernd Kolb
107
Component Behavior Synthesis for Critical Systems Stefan Henkler, Tobias Eckardt
113
Unifying Probabilistic and Traditional Formal Model Based Analysis Frank Ortmeier, Matthias Güdemann, Michael Lipaczewski, Simon Struck
123
Formal Safety Analysis and Verification in the Model Driven Development of a Pacemaker Product Line Sara Bessling, Michaela Huhn
133
A framework for formal verification of systems of synchronous components Stefan Milius, Henning Günther, Jan Peleska, Oliver Möller, Helge Loeding, Martin Sulzmann, Ramin Hedayati, Axel Zechner
145
Components and Contracts: A Semantical Foundation for Compositional Refinement Hardi Hungar 157
Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteter Systeme VIII (Model-Based Development of Embedded Systems) In einigen Domänen, insbesondere in der Automobilindustrie, aber zu zuneh-‐ mend in der Automatisierungstechnik oder der Luft-‐ und Raumfahrttechnik, ist die modellgetriebene Entwicklung etablierter Stand der Technik bei der Entwick-‐ lung eingebetteter Systeme. Aktuelle Studien belegen, dass zwar die Synthese von ablauffähiger, zum Teil verteilter, einbettbarer Software aus ausführbaren Modellen mittels Codegenerierung noch immer im Zentrum der industriellen Anwendung liegt. Aber weitere Nutzungsmöglichkeiten – insbesondere durch das sogenannte Frontloading, also der Vorverlagerung der Qualitätssicherung durch Techniken wie der Simulation oder des Model-‐In-‐the-‐Loop-‐Tests – werden von der Industrie als weitere wesentliche Vorzüge wahrgenommen und zuneh-‐ mend umgesetzt. Der hohe Präzisierungsgrad von Modellen kombiniert mit der Möglichkeit der Abstraktion erlaubt weitere Nutzungsmöglichkeiten, wie dem Einsatz von Architekturmodellen zur Dokumentation von Entwurfsentscheidun-‐ gen, Testmodelle zur Verbesserung der Wiederverwendbarkeit von Tests, oder Plattformmodelle zur Unterstützung von Bewertung von Verteilungsvarianten. Auch das Thema der Modellqualität rückt immer mehr in den Vordergrund – verstärkt durch die Berücksichtigung der modellbasierten Entwicklung in Nor-‐ men und Standards wie z.B. in der ISO 26262. Durch den Fokus auf Feinentwurf und Realisierung stehen zwar oft noch Techniken wie Modellierungsrichtlinien und der (automatisierte) Prüfung im Vordergrund. Aber auch Techniken wie Modellinspektionen oder –Walk-‐Throughs gewinnen an Bedeutung. Auch die Kombination mit Aspekten über den rein funktionellen Entwurf der eingebette-‐ ter Systeme hinaus findet zunehmend – wenn auch erst punktuell -‐ Verbreitung, wie etwa die Erweiterung von Modellen um sicherheitsrelevante Aspekte wie Zuverlässigkeit und deren Nutzung für Sicherheitsnachweise. Wie in den Jahren zuvor, bestätigen auch dieses Jahr die Beiträge die Grundthese der MBEES-‐Workshop-‐Reihe, dass sich die Modelle, die in einem modellbasier-‐ ten Entwicklungsprozess eingesetzt werden, an der Problem-‐ anstatt der Lö-‐ sungsdomäne orientieren müssen. Dies wird einerseits durch die zunehmende Verbreitung der so genannten „Domain Specific Languages“ deutlich, anderer-‐ seits durch die Modellierung von „nichtfunktionalen“ Anforderungen wie Echt-‐ zeiteinschränkungen oder Sicherheitsanforderungen. Die verbesserte Werkzeug-‐ landschaft und die starke Kopplung zwischen Anwendungsdomäne und einge-‐ betteten Systeme haben spezifische Modellierungsansätze verstärkt aus Domä-‐ nen der „early adopters“ in der Automotive-‐ und Aeronautics-‐Branche in Anla-‐ genbau und Automatisierungstechnik, Bahntechnik, Robotik und andere Anwen-‐ dungsfehler getragen. Studien in den Domänen der „ Automotive-‐ und Aeronautics-‐Branche zeigen wiederholt, dass modellbasierte Entwicklung substantiell zur Effizienz-‐ und Qua-‐
litätssteigerung bei der Entwicklung eingebetteter Systeme beiträgt. Hier spielen nicht zuletzt das angesprochene Frontloading und die dafür verfügbare Werk-‐ zeugentwicklungslandschaft eine wesentliche Rolle. Während in einigen Feldern wie im Anlagenbau und Automatisierungstechnik oder Bahntechnik sich eine vergleichbare Entwicklung abzeichnet, verbreitet sich die modellbasierte Ent-‐ wicklung zwar zunehmend, aber deutlich langsamer in anderen Anwendungsfel-‐ dern wie der Robotik oder den Autonomen Systemen. Dies liegt zu Teilen daran, dass hier geeignete domänenspezifische Ausprägungen – oben erwähnten mit der Unterstützung der Trennung von Problem-‐ und Lösungsraum – noch nicht in gleichem Maße verfügbar sind. In bewährter Tradition stellen die in diesem Tagungsband zusammengefassten Papiere sowohl gesicherte Ergebnisse, als auch Work-‐In-‐Progress, industrielle Erfahrungen und innovative Ideen aus diesem Bereich zusammen und erreichen damit eine interessante Mischung theoretischer Grundlagen und praxisbezoge-‐ ner Anwendung. Genau wie bei den ersten sechs, in den Jahren 2005 bis 2011 erfolgreich durchgeführten Workshops sind damit wesentliche Ziele dieses Workshops erreicht: -‐ Austausch über Probleme und existierende Ansätze zwischen den unter-‐ schiedlichen Disziplinen (insbesondere Elektro-‐ und Informationstechnik, Maschinenwesen/Mechatronik und Informatik) -‐ Austausch über relevante Probleme in der Anwendung/Industrie und existie-‐ rende Ansätze in der Forschung -‐ Verbindung zu nationalen und internationalen Aktivitäten (z.B. Initiative des IEEE zum Thema Model-‐Based Systems Engineering, GI-‐AK Modellbasierte Entwicklung eingebetteter Systeme, GI-‐FG Echtzeitprogrammierung, MDA Initiative der OMG) Die Themengebiete, für die dieser Workshop gedacht ist, sind fachlich sehr gut abgedeckt. Die Beiträge adressieren verschiedenste Aspekte modellbasierter Entwicklung eingebetteter Softwaresysteme, unter anderem: -‐ Domänenspezifische Ansätze zur Modellierung von Systemen -‐ Modelle in der architekturzentrierten Entwicklung -‐ Bewertung und Verbesserung der Qualität von Modellen -‐ Modellbasierte Validierung und Verifikation -‐ Modellierung von Echtzeiteigenschaften -‐ Betriebssicherheit und Modellbasierte Entwicklung -‐ Modellgestützte Design-‐Space Exploration -‐ Formale Ansätze in der Modellbasierten Entwicklung Das Organisationskomitee ist der Meinung, dass mit den Teilnehmern aus Industrie, Werkzeugherstellern und der Wissenschaft die bereits seit 2005
erfolgte Community-‐Bildung erfolgreich weitergeführt wurde. Der nunmehr achte MBEES Workshop belegt, dass eine solide Basis zur Weiterentwicklung des Themas modellbasierter Entwicklung eingebetteter Systeme existiert. Der hohe Anteil von deutschen Forschern und Entwicklern an den in den in den letzten Jahren eingerichteten internationalen Konferenzreihen zu Modellierung und Cyper-‐Physical Systems zeigt, dass die deutsche Zusammenarbeit in diesem Themenfeld Früchte getragen hat. Die Durchführung eines erfolgreichen Workshops ist ohne vielfache Unter-‐ stützung nicht möglich. Wir danken daher den Mitarbeitern von Schloss Dagstuhl und natürlich unserem Sponsor, der Validas AG. Schloss Dagstuhl im Februar 2012, Das Organisationskomitee: Holger Giese, Hasso-‐Plattner-‐Institut an der Universität Potsdam Michaela Huhn, TU Clausthal Jan Philipps, Validas AG Bernhard Schätz, fortiss GmbH Mit Unterstützung von Dagmar Koß, fortiss GmbH
Innerhalb der Gesellschaft für Informatik e.V. (GI) befasst sich eine große Anzahl von Fachgruppen explizit mit der Modellierung von Software- bzw. Informationssystemen. Der erst neu gegründete Querschnittsfachausschuss Modellierung der GI bietet den Mitgliedern dieser Fachgruppen der GI - wie auch nicht organisierten Wissenschaftlern und Praktikern - ein Forum, um gemeinsam aktuelle und zukünftige Themen der Modellierungsforschung zu erörtern und den gegenseitigen Erfahrungsaustausch zu stimulieren. Die Arbeitsgruppe Grundlagen der Informatik am Institut für Informatik der TU Clausthal forscht auf dem Gebiet der formalen Methoden für sicherheitskritische, softwaregesteuerte Systeme. Dies umfasst modellbasierte Entwurfsmethoden sowie formale Validierung und Verifikation. Erarbeitet werden Methoden und Werkzeuge zum Nachweis der funktionalen Korrektheit, aber auch zum Echtzeit- und Störungsverhalten komplexer eingebetteter Systeme. In diesem Rahmen wird auch die Qualitätsplanung und Sicherheitsnachweisführung thematisiert. Die Anwendbarkeit der Lösungen wird immer wieder in industrienahen Projekten überprüft, wobei bisher auf Kooperationen mit der Automobilindustrie und ihren Zulieferern, der Bahnindustrie und aus der Robotik verwiesen werden kann. Schloss Dagstuhl wurde 1760 von dem damals regierenden Fürsten Graf Anton von Öttingen-SoeternHohenbaldern erbaut. 1989 erwarb das Saarland das Schloss zur Errichtung des Internationalen Begegnungsund Forschungszentrums für Informatik. Das erste Seminar fand im August 1990 statt. Jährlich kommen ca. 2600 Wissenschaftler aus aller Welt zu 40-45 Seminaren und viele sonstigen Veranstaltungen. Die fortiss GmbH ist ein Innovationszentrum für softwareintensive Systeme in Form eines An-Instituts der Technischen Universität München. Als Forschungs- und Transferinstitut liegt der Fokus auf der angewandten Forschung zukünftiger Software- und Systemlösungen mit Schwerpunkt eingebettete und verteilte Systeme sowie Informationssysteme. Bearbeitete Themenfelder sind dabei unter anderem Modellierungstheorien einschließlich funktionaler, zeitlicher und nicht-funktionaler Aspekte, Werkzeugunterstützung zur Erstellung von dömanenspezifischen, modellbasierten Entwicklungswerkzeugen, Architekturen insbesondere für langlebige und sicherheitskritische Systeme, sowie modellbasierte Anforderunganalyse und Qualitätsicherung. Lösungen werden dabei vorwiegend in den Anwendungsfeldern Automobilindustrie, Luft- und Raumfahrt, Automatisierungstechnik, Medizintechnik, Kommunikationstechnik, öffentliche Verwaltung und Gesundheitswirtschaft erarbeitet.
Die Validas AG ist ein Beratungsunternehmen im Bereich Software-Engineering für eingebettete Systeme. Die Validas AG bietet Unterstützung in allen Entwicklungsphasen, vom Requirements- Engineering bis zum Abnahmetest. Die Auswahl und Einführung qualitätssteigender Maßnahmen folgt dabei den Leitlinien modellbasierter Entwicklung, durchgängiger Automatisierung und wissenschaftlicher Grundlagen. Besonderer Fokus der Arbeit des Fachgebiets "Systemanalyse und Modellierung" des Hasso Plattner Instituts liegt im Bereich der modellgetriebenen Softwareentwicklung für software- intensive Systeme. Dies umfasst die UML- basierte Spezifikation von flexiblen Systemen mit Mustern und Komponenten, Ansätze zur formalen Verifikation dieser Modelle und Ansätze zur Synthese von Modellen. Darüber hinaus werden Transformationen von Modellen, Konzepte zur Codegenerierung für Struktur und Verhalten für Modelle und allgemein die Problematik der Integration von Modellen bei der modellgetriebenen Softwareentwicklung betrachtet.
Herausforderungen bei der modellbasierten Entwicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation C. Dziobek, Th. Ringler, F. Wohlgemuth Daimler AG 71059 Sindelfingen
Abstract: Die modellbasierte Funktionsentwicklung unter AUTOSAR ermöglicht eine deutlich höhere Konsistenz der Entwicklungsartefakte im Vergleich zu bisherigen Ansätzen. Auf Basis der Erfahrungen im Serieneinsatz, werden in diesem Beitrag zukünftige Handlungsfelder für eine effiziente, modellbasierte Entwicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation aufgezeigt. Es werden sowohl Anforderungen an die Werkzeuginfrastruktur im Gesamtkontext der verteilten Entwicklung, als auch konkrete Anforderungen an die Weiterentwicklung der Modellierungswerkzeuge aufgestellt. Die Anforderungen werden aus der Perspektive eines Fahrzeugherstellers unter Beachtung der Interaktion mit Lieferanten betrachtet.
1
Entwicklung von vernetzten Fahrzeugfunktionen
Der Wunsch, den Reisenden mehr Komfort und Sicherheit in Premiumfahrzeugen bieten zu können, führt dazu, dass die hierfür notwendigen elektronischen Systeme immer komplexer werden. So bestand in der Vergangenheit zum Beispiel das FahrzeugInnenlicht aus wenigen Schaltern und Leuchten, die direkt miteinander verkabelt waren. Heute ist das Innenlicht ein hochkomplexes Softwaresystem, das auf einer Vielzahl von Steuergeräten verteilt ausgeführt wird, die über mehrere verschiedene Kommunikationssysteme (CAN und LIN) kommunizieren. Diese Fahrzeugfunktionen werden, koordiniert vom Fahrzeughersteller, in enger Zusammenarbeit mit zahlreichen Lieferanten über einen Zeitraum von mehreren Jahren, in einer verteilten Entwicklungsorganisation zur Serienreife entwickelt. Um in dieser Organisation einen zielgerichteten Ablauf sicherstellen zu können, gibt es einen gemeinsamen Entwicklungsprozess mit den Lieferanten mit klar definieren Rollen, Aufgaben und Verantwortungen. Zur besseren Beherrschung dieser Komplexität kamen in den letzten Jahren formalisierte Ansätze und graphische Notationen zum produktiven Einsatz. Insbesondere im Bereich der Verhaltensbeschreibung und Implementierung wurde die modellbasierte Funktionsentwicklung sukzessive eingeführt [1] und ausgebaut. Die modellbasierte Entwicklung
1
ermöglicht es, bestehende Funktionen, die durch Funktionsmodelle repräsentiert werden, frühzeitig durch Simulation abzusichern und danach in einer Vielzahl unterschiedlicher Baureihen eines Fahrzeugherstellers wiederzuverwenden. Auf diese Weise ist es möglich, in immer kürzer werdenden Entwicklungszeiträumen neue innovative Fahrzeugfunktionen in hoher Qualität zu realisieren. Durch den herstellerübergreifenden AUTOSAR-Standard [2] wurde die bis dahin solitäre modellbasierte Entwicklung in einen formalisierten Gesamtkontext gestellt. Hierdurch können nun Funktionszusammenhänge und deren Schnittstellen konsistent und vollständig beschrieben, sowie einheitlich implementiert werden. Zusätzlich bietet der Standard die Möglichkeit, Entwicklungsergebnisse zwischen dem Fahrzeughersteller und den Lieferanten prozesssicher auszutauschen. Trotz dieser Erfolge der letzten Jahre gilt es, sich bei der Anwendung der modellbasierten Entwicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation unter AUTOSAR mit zahlreichen zukünftigen Herausforderungen in unterschiedlichen Themengebieten auseinanderzusetzen. In diesem Beitrag wird nach Analyse des Stands der Technik bei der Daimler AG eine Auswahl dieser Herausforderungen vorgestellt, um sie in der Fachwelt zu diskutieren.
2 2.1
Stand der Technik Modellbasierte Entwicklung unter AUTOSAR
Die modellbasierte Entwicklung unter AUTOSAR ermöglicht es erstmalig, toolgestützt und prozesssicher, auf Basis eines für den produktiven Einsatz geeigneten und durchgängigen Standards, Fahrzeugfunktionen zu entwickeln [3]. Mit diesem Ansatz werden verteilte Fahrzeugfunktionen im Komfort- und Innenraumbereich im Hause Daimler auf Basis von Systemspezifikationen entwickelt [4]. Diese Spezifikationen beschreiben detailliert die Funktionsanforderungen in textueller Form. Die Struktur der Spezifikation orientiert sich vorrangig an der Verteilung der Funktion auf die Hardware-Topologie. Dazu ist die Systemspezifikation in sogenannte „Komponentenbeiträge“, also in Beiträge einer Hardware-Komponente (Steuergerät) zu einem E/E-System, gegliedert [4]. Die Funktionszuordnung der Komponentenbeiträge erfolgt typischerweise entsprechend dem Prinzip der „minimalen Dekomposition“ und unterscheidet funktional mächtige MasterKomponentenbeiträge von einfachen sensor/aktornahen Client-Komponentenbeiträgen. Darüber hinaus wird bei der Dekomposition die Thematik der geplanten Wiederverwendung und der Funktionsverlagerung bei geänderter Hardware-Topologie berücksichtigt. Im Rahmen der Spezifikation werden für jedes System die Schnittstellen zu anderen Fahrzeugsystemen und die Funktionszuordnungen und Schnittstellen der einzelnen Komponentenbeiträge beschrieben. Das so entstehende System- und Komponentenbeitragsnetzwerk wird direkt, unter Anwendung des AUTOSAR-Standards, als Netzwerk von Software-Komponenten (SWCs) in einer Vernetzungsdatenbank beschrieben. Daraus ergibt sich die oberste Dekompositionsstufe der Software-Architektur. In den fol-
2
genden Entwicklungsschritten werden die Komponentenbeiträge in der Vernetzungsdatenbank, entsprechend der in der Spezifikation zu Grunde gelegten Hardware-Topologie, auf Steuergeräte verteilt. Die für den Informationsaustausch notwendigen Botschaften der jeweiligen Bustechnologie (LIN, CAN, FlexRay) werden definiert.
Test Implementierung
Definition Test Cases
MiL
Test Spezifikation
SiL Testfall
Simulation
Codegenerierung
Modell
SystemLastenheft
Update Lastenheft System-SignalSchnittstellen SignalPool
Funktionsmodel
Steuergerätelieferant
AUTOSAR-XMLAustauschformat
AUTOSAR Codegenerierung
Vernetzungsdatenbank
Abbildung 1: Zusammenhänge bei der modellbasierten Entwicklung
Die Schnittstellen der Funktionsmodelle werden als atomare Software-Komponenten in die hierarchische Software-Komponenten-Struktur eingebunden und um weitere Schnittstelleninformationen wie Parameter und Messgrößen angereichert. Beim Zuschnitt der Funktionsmodell-Schnittstellen wird im Hinblick auf eine spätere Absicherung darauf geachtet, möglichst große Funktionseinheiten zu bilden, die eine starke innere funktionale Kohäsion aufweisen. Dies ist dadurch begründet, dass die Absicherung von Netzwerken von Software-Komponenten [5] bisher mit einem hohen Aufwand verbunden ist und deshalb noch nicht im Serienentwicklungsprozess verankert ist. Die Vernetzungsdatenbank unterstützt das parallele Arbeiten von mehreren Anwendern. Ein integriertes Versions- und Release-Management ermöglicht es, unterschiedliche Entwicklungsstände integriert und konsistent zu verwalten. Diese Datenbank ist das zentrale Element des Entwicklungsprozesses, da hier alle, für die funktionale Produkterstellung notwendigen Datenobjekte, gehalten werden. Ein zusätzliches Element für den erfolgreichen Einsatz dieser Datenbank ist die Gestaltung eines in Phasen unterteilten Änderungsprozesses, der mehrere Präzisierungsstufen unterstützt. Auf Basis von AUTOSAR-konformen Exporten aus der Vernetzungsdatenbank können ECU-Konfigurationen mit externen Entwicklungspartnern und Beschreibungen von atomaren Software-Komponenten mit externen Modellierungswerkzeugen, wie z.B. MATLAB/Simulink [6] und TargetLink [7] ausgetauscht werden.
3
Auf Basis der Funktionsanforderungen der textuellen Spezifikationen wird ein Modelldesign durchgeführt und die Funktionsanforderungen in Form eines Simulink-, Stateflow- und TargetLink-Modells umgesetzt. Bei vielen Modellen wird versucht, die Modellstruktur an die Struktur der Spezifikation anzulehnen, um so eine hohe Verfolgbarkeit und Wartbarkeit sicherzustellen. Die – wie oben bereits ausgeführt – bislang fehlende Simulation von Netzwerken mehrerer Software-Komponenten im Serienprozess, führt teilweise zu sehr mächtigen Modellen mit komplexen inneren Strukturen und möglichst einfachen externen Schnittstellen. Für jedes System wird aus der Anforderungsspezifikation eine Testspezifikation abgeleitet, in der auch die Testfälle für die einzelnen Komponentenbeiträge (und damit für die Software-Komponenten) enthalten sind [5]. Auf Basis dieser Testfallspezifikationen werden Model- und Software-in-the-Loop Testfälle mit dem Testimplementierungswerkzeug TPT [8] durch reaktive Testautomaten implementiert. Dieser Prozessschritt ermöglicht es, frühzeitig die Funktionalität der einzelnen Software-Komponenten abzusichern. Für eine detaillierte Erläuterung des aktuellen Gesamtprozesses siehe [4]. 2.2
Erfahrungen mit der aktuellen Vorgehensweise
Die beschriebene Vorgehensweise und die damit einhergehenden AUTOSAR-XMLDatenaustauschformate kommen in dieser Stringenz und flächendeckenden Anwendung erstmalig bei einem Fahrzeughersteller zum Einsatz [4]. Im Vergleich zur klassischen handcodierten Steuergeräteentwicklung bringt die modellbasierte Entwicklung schon in frühen Entwicklungsphasen einen erheblichen Qualitäts- und Reifegradgewinn. Der integrierte AUTOSAR-basierte Entwicklungsprozess mit einer zentralen Datenbank nach dem Single-Source-Prinzip führen im Vergleich zu bisherigen Ansätzen zu einer signifikant höheren Konsistenz und Reife der Daten. Folgende Erkenntnisse, die für weitere Konzepte wichtig sind, können aus der aktuellen Vorgehensweise gewonnen werden:
4
•
Daten und Modelle bleiben nur dann aktuell, wenn sie unmittelbar in den Produktentstehungsprozess integriert sind. Nur wenn aus einem Architektur-/Funktionsmodell direkt Code generiert wird, wird es im Laufe der Entwicklung gepflegt.
•
Es sollte nur einen Datenmaster und eine zentrale Eingabe vorhanden sein. Nur so kann in einer heterogenen Werkzeugwelt einer Inkonsistenz der Daten vorgebeugt werden.
•
Eine gemeinsame Datenbasis mit vielen Anwendern erfordert eine differenzierte zeitliche Abstimmung der Bearbeitung voneinander abhängiger Objekte. Eine Erweiterung der Versionierung um eine Branching-Funktionalität ermöglicht es, getrennte Arbeiten an gleichen Objekten zeitweise zu entkoppeln.
•
Der Einsatz einer automatisierten Werkzeugkette ermöglicht innerhalb ihrer Teilabläufe keine manuelle Korrektur. Eine durchgängig hohe Qualität der Datenbereitstellung, die entsprechend automatisiert überprüft wird, ist daher unverzichtbar.
Künftig sind Werkzeugkonzepte gefordert, die eine schrittweise Präzisierung der Objekte unterstützen. •
Als primäre Dateneingangsquelle dienen Lastenhefte. Diese liegen jedoch in der Regel ausschließlich in grobstrukturierter textueller Form vor, und können nicht auf automatisierte Weise formalisiert und verfeinert werden. Das Anforderungsmanagement sollte um die Möglichkeit erweitert werden, komplexe Anforderungen in Form von „physikalischen“ simulierbaren PrinzipModellen semiformal beschreiben zu können. Bei der Erstellung von Spezifikationen in einem integrierten Entwicklungsprozess muss für formal beschreibbare Objekte wie z.B. Schnittstellen oder Parameter ein Abstimmungsprozess vorgehalten werden, der es nachvollziehbar ermöglicht, zunächst informell beschriebene Objekte im Verlauf der Entwicklung durch unterschiedliche Bearbeiter weiter zu präzisieren und letztlich zu implementieren. Die Praxis zeigt, dass Implementierungsdetails nur sehr eingeschränkt bei der Erstellung der Spezifikationen durch den Bearbeiter in der benötigten Datenqualität berücksichtigt und bereitgestellt werden können.
•
Der Austausch der Entwicklungsartefakte mit den Lieferanten und insbesondere die Update-Prozesse sind bisher noch sehr aufwändig [4]. Effiziente Update-Mechanismen sind insbesondere für die Lieferanten-Toolchain erforderlich, um teilweise feingranulare Änderungen durch den Fahrzeughersteller auch beim Lieferanten prozesssicher nachzuziehen.
•
Nicht zu vergessen ist die Qualifikation der Mitarbeiter. Von Funktionsentwicklern werden verstärkt informationstechnische Qualifikationen abverlangt. Hier sind entsprechende Qualifizierungs- und Schulungsprogramme notwendig. Gleichzeitig muss es der Anspruch an den Prozess, die eingesetzten Methoden und die darin integrierten Werkzeuge sein, die sprachliche Ebene der Entwickler zu treffen und sie bei der Bewältigung der vielschichtigen Arbeitschritte zu unterstützen.
Auf Basis dieser Erkenntnisse sehen wir vielschichtige Herausforderungen, wobei wir auf den Gesamtkontext der verteilten Entwicklung und die Herausforderungen innerhalb der modellbasierten Entwicklung in einem Werkzeug wie MATLAB-Simulink in den nächsten zwei Abschnitten getrennt eingehen werden.
3 3.1
Herausforderungen bei der verteilten Entwicklung Unterstützung eines verteilten Entwicklungsprozesses
In der Entwicklung verteilter Fahrzeugfunktionen sind zahlreiche verschiedene Rollen, sowohl beim Fahrzeughersteller, als auch bei den Lieferanten vertreten. Abbildung 2 skizziert vereinfacht das Zusammenspiel der verschiedenen Rollen und die verschiedenen Artefakte, die sie verantworten. Bisher erfolgt der Datenaustausch zwischen den einzelnen Rollen sehr oft über Dokumente, vereinzelt über Austauschformate. Aus die-
5
sem Prozess resultiert eine Reihe von Anforderungen an einen verbesserten Entwicklungsablauf und eine adäquate Werkzeugunterstützung, die nachfolgend aus der Perspektive eines Fahrzeugherstellers unter Beachtung der Interaktion mit den Lieferanten skizziert werden.
E/E-Systemsprecher Lastenhefte Test-Spezifikationen Parameter
Vernetzer
SchnittstellenBeschreibung
• • • • • •
Funktionsvarianten Wiederverwendung Produktlinien Konsistenz Wiederherstellung von Ständen …
Modellbibliothek Funktionsmodelle ModellBeschreibung
Software Integration
DiagnoseBedatung
Lieferanten
Diagnose Verantwortlicher
Modellablage Modelltests
Funktionsmodellierer
Abbildung 2: Skizzierte Rollen und Artefakte in der verteilten Entwicklung
3.2
Anforderung an eine Entwicklungsumgebung
3.2.1 Common Repository Zukünftig ist eine weitere Integration der Daten und Werkzeuge notwendig, mit dem Ziel ein „Common Repository“ aller relevanten Daten nach dem Single-Source-Prinzip zu erreichen. Rollenspezifische Sichten auf den gesamten Datenpool müssen die Übersicht für die entsprechende Rolle sicherstellen. Durch die gemeinsame Datenhaltung wird eine Nachverfolgbarkeit (Traceability) zwischen verschiedenartigen Entwicklungsartefakten möglich. Allerdings muss die Herstellung der Traceability weitestgehend automatisch ohne aktives Zutun des Anwenders erfolgen. Ein großer zusätzlicher Arbeitsaufwand zum Herstellen und Pflegen der Traces wird im allg. nicht akzeptiert; deshalb sind Techniken zum automatischen Verlinken notwendig. 3.2.2 Artefaktübergreifendes Management Zwischen den verschiedenen Artefakten gibt es eine hohe Abhängigkeit. So führt die Änderung einer Anforderung zu einer Änderung im Funktionsmodell, in der Testspezifikation, in der Schnittstellenbeschreibung, usw. Gleiches gilt für weitere Bereiche wie Varianten-Management, Wiederverwendung von Artefakten, oder Refaktorierung. Solche Aufgaben sind nicht auf einzelne Artefakte beschränkt, sondern sind gesamtheitlich und artefaktübergreifend zu betrachten.
6
Fahrzeugfunktionen werden nicht für jedes Fahrzeug neu entwickelt, sondern bestehende Funktionsmodelle werden auf neue Fahrzeugvarianten angepasst. Die Produktdifferenzierung führt dabei zu einem veränderten Funktionsumfang. Funktionen werden über die Fahrzeuggenerationen weiterentwickelt und erfahren eine Funktionsevolution. Dies erfordert eine effektive Wiederverwendung aller Artefakte der modellbasierten Entwicklung. Es ist deshalb eine durchgängige Methodik für eine effiziente und konsistente Wiederverwendung aller Entwicklungsartefakte unter Berücksichtigung der Variabilität, der Evolution und der Artefakt-Konsistenz [9] erforderlich. Refaktorierungen von Artefakten werden heute vornehmlich toolzentrisch betrachtet. Die Änderung der Aufteilung einer Software-Komponente ist beispielsweise in späten Phasen eines Entwicklungsprojekts praktisch nicht mehr möglich, da dies Änderungen über mehrere Artefakte in mehreren Werkzeugen zur Folge hätte. Zukünftig ist hier ein artefaktübergreifender toolgestützter Ansatz notwendig. 3.2.3 Prozessunterstützung beim Fahrzeughersteller Eine integrierte Werkzeugumgebung für die Entwicklung verteilter Funktionen in einer verteilten Entwicklungsorganisation erfordert Mechanismen für die Prozessunterstützung über die einzelnen Artefakte, wie sie typischerweise von dateibasierten Versions- und Konfigurationsmanagementsystemen bereitgestellt werden: •
Exemplarisch seien hier generische Funktionen zur Gruppierung und Versionierung von Objekten, zur Release-Bildung von Freigabeständen und Branching genannt, um ein paralleles Arbeiten zu ermöglichen. In diesem Zusammenhang sind zusätzlich Diff/Merge- und effiziente Refaktorierungsfunktionen zu nennen, um die Verfolgung von Datenständen und ggf. notwendige Umstrukturierungen sicherstellen zu können.
•
Das Änderungsmanagement zur Dokumentation von Änderungen muss in die Werkzeugumgebung integriert sein und eine direkte Referenzierung auf alle Artefakte ermöglichen.
•
Zur Sicherstellung einer hohen Prozessqualität ist ein Rollen- und RechteManagement mit unterlagertem Workflow notwendig, um so den Datenaustausch über die unterschiedlichen Entwicklungsphasen und Bereiche sicherstellen zu können. Dabei sind flexible Anpassungsmöglichkeiten an den Entwicklungsprozess erforderlich.
3.2.4
Prozessunterstützung für die Schnittstelle zwischen Fahrzeughersteller und Lieferanten Neben der Prozessunterstützung innerhalb des Fahrzeugherstellers hat die Prozessunterstützung zwischen dem Fahrzeughersteller und den Lieferanten eine besondere Bedeutung, da nicht von einer homogenen Werkzeugwelt ausgegangen werden kann. Bei dem dateibasierten Datenaustausch sollten neben den „Nutzdaten“ auch zusätzlich Versionsinformationen, und Informationen über gelöschte Objekte und ersetzte Objekte übergeben werden. Bei dem Rückfluss der Daten von den Lieferanten zum Fahrzeughersteller
7
sollten die erhaltenen Daten mit den Daten im Repository über Diff- und MergeWerkzeuge abgeglichen werden.
4
Herausforderungen bei Modellierungsmitteln
Das Modellierungswerkzeug MATLAB/Simulink [6] zusammen mit dem CodeGenerator TargetLink [7] ist in der PKW-Entwicklung von Mercedes-Benz für Steuerungs- und Regelsysteme der Defacto-Standard der modellbasierten Entwicklung. Zur Unterstützung der Modellierung verteilter Funktionen in einer verteilten Entwicklungsorganisation sehen wir eine Fülle von Herausforderungen. Eine Auswahl hiervon ist nachfolgend aufgeführt:
8
•
Das Werkzeug MATLAB/Simulink hat seine Ursprünge in der Regelungstechnik und hat über die Möglichkeit der automatisierten Code-Generierung Einzug in die Softwaretechnik erhalten. Es fehlen bislang grundlegende softwaretechnische Sprachkonstrukte zur vollständigen Beschreibung der Eigenschaften der SoftwareKomponenten generell, sowie für spezifische Standards wie AUTOSAR oder UML. Als grundlegendes Beschreibungsmittel fehlt die Abbildung der Client-ServerKommunikation und die Modellierung von Servern in Simulink. Mit den heute verfügbaren Lösungen kann jeweils nur eine SWC in Simulink beschrieben werden. Es fehlen bislang Mittel zur Beschreibung der Vernetzung mehrerer SWCs untereinander. Um eine frühzeitige belastbare Absicherung der Funktionen durchführen zu können [10], ist eine Simulation verteilter vernetzter Funktionen mit darunter liegender Software-Architektur, wie sie der AUTOSAR-Standard definiert, bereits im Modellierungswerkzeug auf Model-in-theLoop-Ebene notwendig. Bisherige Ansätze integrieren Software-Komponenten auf Software-in-the-Loop-Ebene [10]. Die langen turn-arround-Zeiten stehen heute einem größeren Serieneinsatz im Wege.
•
Mit dem Modellierungswerkzeug lässt sich sehr schnell ein simulationsfähiges Modell erstellen. Der Übergang von der Simulationswelt hin zu der Hardware-nahen ressourcenoptimalen Fixed-Point-Welt geschieht heute jedoch wenig geführt. Erst im Nachhinein ist es möglich, Fehler durch formale Checks, Simulation und formale Verifikation zu erkennen. Hierfür sind zukünftig konstruktive Konzepte wie Wizzards notwendig. Viele softwaretechnisch relevante Gesichtspunkte werden während der CodeGenerierung implizit ermittelt. Stattdessen sollten deklarative Festlegungen vom Modellierer gefordert werden.
•
Die grafische Modellierung ermöglicht eine gute Übersichtlichkeit über komplexe Modellstrukturen und erhöht die Wartbarkeit. Heutzutage werden jedoch geschätzte 30% der Arbeitszeit dafür verwendet, grafische Elemente „schön“ anzuordnen und beispielsweise eine Planarität eines Subsystems herzustellen. Hierfür sind zukünftig automatische Layout-Mechanismen notwendig, um einen Effizienzgewinn zu erreichen. Prototypische Realisierungen [11] zeigen hier vielversprechende Ergebnisse. Allerdings ist weiterhin unklar, wie die „Schönheit“ eines Subsystems zuverlässig bewertet und erreicht werden kann.
•
Trotz der Vorteile der grafischen Modellierung gibt es Fälle, bei denen die grafische Repräsentation keinen Mehrwert bringt. Dies ist beispielsweise bei automatisch generierten Modell-Rahmen zur Erfüllung der AUTOSAR-Schnittstelle der Fall. Es ist also darüber nachzudenken, nach welcher Methodik die unterschiedlichen Beschreibungsmittel von Simulink, Stateflow und Embedded MATLAB anzuwenden sind, um so den Aufwand der Erstellung gering, und gleichzeitig die Verständlichkeit und Wartbarkeit der Modelle hochzuhalten. Steuerungs- und Regelalgorithmen können mit den vorhandenen Beschreibungsmitteln hervorragend implementiert werden, doch zeigt sich immer mehr, dass die vorhandenen Beschreibungsmittel zur Informationsverteilung inklusive Daten- und Schnittstellenmanagement bei komplexen Systemen nicht skalieren.
•
Eine große Herausforderung ist der Umgang mit vielen gleichartigen Modellen. 50 Funktionsmodelle für Innenraumfunktionen sind nichts ungewöhnliches [3]. Es ist notwendig Modelle mit gleichen Patterns aufzubauen, die Einhaltung dieser Patterns zu prüfen und gegebenenfalls teilautomatisiert nachzubilden. Setzt man diesen Gedanken fort, stellt sich die Frage, wie Änderungen an diesen Patterns konsistent über viele Modelle durchgeführt werden sollen. Eine weitere Anforderung ist das einfache, automatisierte Nachziehen von Änderung an vielen Funktionsmodellen gleichzeitig (z.B. Änderung von zentralen Datentypen oder AUTOSAR-Port-Interfaces).
•
Funktionsmodelle sind heute vielfach 150% Modelle, die eine Übermenge der Funktionen für verschiedene Fahrzeugtypen realisieren [9]. Das hat zur Folge, dass bei der Verwendung einer spezifischen Funktionsvariante das Interface auch Elemente enthält, die in diesem speziellen Fall nicht verwendet werden. Eine variantenabhängige Steuerung des Input-/Output Interfaces ist jedoch mit den aktuellen Technologien nicht möglich. Bisherige Varianten-ManagementAnsätze [12], [13] beschränken sich auf die Variabilität innerhalb von Funktionsmodellen. Die Variabilität an der Schnittstelle kann zum jetzigen Zeitpunkt nur durch variantenspezifische Modelle realisiert werden, die unter Verwendung von wiederverwendbaren Bibliotheksmodellen realisiert werden. Es fehlen bisher Mechanismen zum Management von Schnittstellenvarianten und effiziente Methoden zur Einbindung bzw. Verknüpfung von Bibliotheksfunktionen in Funktionsmodellen.
•
Die grafischen Simulink-Modelle sind Implementierungsmodelle aus denen direkt Produktions-Code für ein Zielsteuergerät generiert wird. Aufgrund des daraus folgenden hohen Detailierungsgrads dieser Modelle, der alle funktionalen Details beschreibt, ist es vielfach schwierig, verteilte Funktions- und Wirkzusammenhänge in einem Modell zu erkennen. Hier wird deshalb, ein vom Anwender leicht zu konfigurierendes, Sichtenkonzept auf der Verhaltensbeschreibungsebene benötigt, um so eine bessere fallspezifische Übersicht zu erhalten und so das Funktionsverständnis erleichtert und beschleunigt wird [14].
9
5
Zusammenfassung und Ausblick
Die modellbasierte Funktionsentwicklung hat zu einem signifikanten Effizienzgewinn bei der Entwicklung eingebetteter Systeme geführt. Darüber hinaus hat der AUTOSARStandard zu einer einheitlichen Software-Architektur und zur Formalisierung des Datenaustauschs zwischen Entwicklungswerkzeugen beim Fahrzeughersteller und den Zulieferern beigetragen. Auf der inzwischen erreichten hohen Ausgangsbasis, sehen wir für die Zukunft die Notwendigkeit zur Weiterentwicklung einer integrierten Entwicklungsmethodik inklusive zugehöriger Werkzeuglandschaft für eine prozesssichere Entwicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation. In diesem Beitrag haben wir dazu einige Herausforderungen exemplarisch aufgeführt und sehen sie als Impulse für Wissenschaft und Werkzeughersteller, um diese Thematik weiter zu erforschen und mögliche Lösungen zu entwickeln.
Literatur [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
10
J. Bortolazzi, C. Dziobek: DaimlerChrysler setzt bei Motorsteuerungen auf TargetLink, dSPACE News, 2/2003 AUTOSAR GbR: http://www.autosar.org/ F. Wohlgemuth, C. Dziobek, Th. Ringler: Erfahrungen bei der Einführung der modellbasierten AUTOSAR-Funktionsentwicklung, Modellierung Berlin, März 2008 S. Schmerler et. al.: Mit AUTOSAR zu einem integrierten und durchgängigen Entwicklungsprozess, 15. Internationaler Kongress Elektronik im Kfz, Baden-Baden, Okt. 2011 S. Schmerler et. al.: AUTOSAR als Basis für modellbasiertes Entwickeln und Testen bei Daimler, 4. Symposium Testen im System- und Software-Life-Cycle, Stuttgart, Nov. 2011 http://www.mathworks.de/products/simulink/ http://www.dspace.de PikeTec GmbH: TPT – Time Partition Testing, www.piketec.com J. Thomas, C. Dziobek, B. Hedenetz: Variability management in the AUTOSAR-based development of applications for in-vehicle systems. In Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems, VaMoS, , 2011 A. Michailidis, Th. Ringler, B. Hedenetz, S. Kowalewski: Virtuelle Integration modellbasierter Fahrzeugfunktionen unter AUTOSAR, ATZ-Elektronik, Nr. 1, Feb. 2010 L. Klauske, C. Dziobek: Effizientes Erstellen von Simulink-Modellen mit Hilfe eines spezifisch angepassten Layoutalgorithmus, Tagungsband Dagstuhl-Workshop MBEES Modellbasierte Entwicklung eingebetteter Systeme VII, Januar 2011 C, Dziobek, J. Weiland: Variantenmodellierung und -konfiguration eingebetteter automotive Software mit Simulink, Tagungsband Dagstuhl-Workshop MBEES Modellbasierte Entwicklung eingebetteter Systeme ,April 2009 G. Botterweck, A. Polzer, S. Kowalewski: Using Higher-order Transformations to Derive Variability Mechanism for Embedded Systems, ACESMB 2009 A. Polzer, D. Merschen, J. Thomas, B. Hedenetz, G. Botterweck, S. Kowalewski: ViewSupported Rollout and Evolution of Model-Based ECU Applications. 7th Intern. Workshop on Model-based Methodologies for Pervasive and Embedded Software, 2010
Ein Ansatz zur Qualitätsbewertung von modellbasierten Entwicklungsprojekten eingebetteter Software H. Pohlheim, I. Stürmer, E.Salecker Model Engineering Solutions GmbH Friedrichstr. 55 10117 Berlin {pohlheim|stuermer|elke.salecker}@model-engineers.com
Abstract: Im Automobilbereich hat sich die modellbasierte Entwicklung eingebetteter Software industriell etabliert. Bei der herkömmlichen, d.h. codebasierten Softwareentwicklung, ist es üblich die Qualität und Indikatoren für den Erfolg des Projekts anhand der Qualität und des Umfangs des erzeugten Codes zu messen und zu bewerten. Bei der modellbasierten Entwicklung bietet es sich an, auch die Modelle in die Qualitätsbewertung mit einzubeziehen. In diesem Paper diskutieren wir Vorgehensweisen und Metriken, die in die Qualitätsbewertung von SoftwareModellen und des daraus generierten Codes mit einbezogen werden sollten. Das hierfür benötigte Qualitätsmodell und die daraus sich ableitenden Qualitätsoperationen werden erläutert. Wir zeigen die Vorgehensweise anhand des Tools MQAC (Model Quality Assessment Center), das wir für die Qualitätsbewertung von modellbasierten Software-Projekten entwickelt haben und zeigen prototypische Anwendungsbeispiele aus der Praxis.
1 Einleitung Die modellbasierte Entwicklung eingebetteter Steuerungs- und Regelungssoftware für das Automobil ist durch den durchgehenden Einsatz ausführbarer Modelle in allen Entwicklungsphasen charakterisiert. Modellierungs- und Simulationswerkzeuge, die hier weite Verbreitung gefunden haben, sind z.B. die datenfluss-orientierte Modellierungssprache Simulink® und die zur Modellierung von Zustandsautomaten verfügbare Erweiterung Stateflow® von The MathWorks [1]. Codegeneratoren wie TargetLink von dSPACE [2] erlauben es, automatisch effizienten C Code direkt aus diesen Modellen zu generieren. Immer häufiger wird der generierte Code in sicherheitsrelevanten Systemen im Automobil eingesetzt. Die Qualität des generierten Codes ist mittlerweile ein wesentlicher Erfolgsfaktor für Software-Projekte geworden, da Software-Fehler schwerwiegende finanzielle als auch körperliche Schäden verursachen können. Die Qualität des generierten Codes resultiert unmittelbar aus der Qualität der Modelle, die für die Codegenerierung verwendet werden. Daher ist es wichtig, qualitätssichernde Maßnahmen möglichst früh im Entwicklungsprozess, d.h. bereits auf Modellebene durchzuführen.
11
Die Absicherung der zu entwickelnden Funktion bereits auf Modellebene ermöglicht es systematisch Fehler frühzeitig aufzudecken und führt zur signifikanten Kostenreduzierung der Qualitätssicherung, insb. bei der Fehlerfindung und –beseitigung [3]. Die wichtigsten qualitätssichernden Maßnahmen, die Anwendung bei der modell-basierten Entwicklung und automatischen Codegenerierung von Software im Automobil finden, werden in [4] erläutert und hier nicht weiter vertieft. Ansätze zur Messung der Modellkomplexität, die in diesem Beitrag zur Anwendung kommen sind in [5] beschrieben.
Abbildung 1: Modell- und Code-Absicherung in der modellbasierten Entwicklung Das Grundprinzip der Modell- und Codeabsicherung bei der modellbasierten Entwicklung ist in Abb. 1 gezeigt. In einer frühen Entwicklungsphase werden die aus den funktionalen Anforderungen abgeleiteten Modelle dahingehend überprüft, ob diese den Anforderungen entsprechen (Modell-Absicherung). Dies erfolgt bereits, bevor der generierte Code vorliegt. Es werden hier konstruktive und analytische Qualitätsmaßnahmen angewendet wie z.B. (1) Anwendung von Modellierungsrichtlinien; (2) Reviews der Anforderungen und des Modells; (3) Simulation bzw. dynamisches Testen des Modells. In einer späteren Entwicklungsphase wird das Anforderungsmodell in ein Implementierungsmodell überführt, d.h. um Informationen für die Codegenerierung angereichert, wie z.B. Datentypen, Auflösung/Skalierungen, Funktionsaufteilung. Aus dem Implementierungsmodell wird anschließend Code generiert, der auf unterschiedlichen Teststufen abgesichert wird (Modultest, Integrationstest, Systemtest, usw.). Mit den Qualitätssicherungsmaßnahmen auf Codeebene (Code-Absicherung) wird festgestellt, ob (1) der Code dem Verhalten des Modells entspricht und; (2) ob der Code den Anforderungen an die Implementierung, wie z.B. max. Ausführungsgeschwindigkeit, entspricht. Im Laufe der Modell-/Code-Entwicklung und deren Absicherung entstehen unterschiedliche Artefakte, die für die Qualitätsbewertung des Modells, des Codes bzw. des gesamten Entwicklungsprojektes relevant sind. Wichtige Artefakte sind z.B.: (1) Textuelle Anforderungen (2) die Modelle selbst (Anforderungs- und Implementierungsmodell), (3) Testspezifikation, -implementierung und -berichte; (4) Review-Berichte für Anforderungen, Modell, Code; (5) Issue- bzw. Bug-Reports; usw. Hinzu kommen Berichte unterschiedlicher Werkzeuge, die Metriken bzw. Kennzahlen liefern. Beispiele solcher Berichte sind z.B. solche über (1) Einhaltung von Modellierungsrichtlinien; (2) Modell- und Code-
12
Coverage; (3) Testabdeckung der Anforderungen; (4) Komplexitätsmessung des Modells und des Codes; usw. Für die Qualitätsbewertung von modellbasiert entwickelten Software-Produkten hat sich noch keine einheitliche Vorgehensweise etabliert. Wir haben dabei mehrere Probleme identifiziert. (1) Die Qualitätsbewertung ist oftmals fokussiert auf einzelne Qualitätsmaßnahmen z.B. Tests im Fahrzeug, d.h. das Spektrum an verfügbaren Qualitätssicherungs-Methoden wird nur unzureichend oder sehr unsystematisch genutzt. (2) Die erhobenen Daten sind verteilt vorhanden. So dokumentiert z.B. der Modellierer die Durchführung von Richtlinien-Überprüfungen, während der Tester die Testberichte erstellt. (3) Die Zusammenführung, Aggregation und Dokumentation der Ergebnisse muss manuell vorgenommen werden und erfolgt oftmals nur punktuell. (4) Eine systematische Verfolgung von Entwicklungstendenzen und ein Vergleich über verschiedene Projekte hinweg sind aufgrund der zuvor genannten Punkte schwierig. (5) Vorhandenes Erfahrungswissen, das von Praktikern in erfolgreichen Projekten eingesetzt wird, wird nur unzureichend kommuniziert. Um die genannten Probleme zu lösen, haben wir (1) die aus der klassischen Software-Entwicklung bekannte Vorgehensweise für die Bewertung und Kontrolle eines entstehenden Produktes für die modellbasierte Entwicklung adaptiert und (2) ein Qualitätsmodell für die modellbasierte Entwicklung entwickelt. Der von uns adaptierte Prozess der Qualitätsbewertung wird durch das von uns entwickelten Model Quality Assessment Center (MQAC) implementiert, in welches das von uns vorgeschlagene Qualitätsmodell integriert ist. In die Entwicklung der adaptierten Vorgehensweise für die Qualitätsbewertung und das Qualitätsmodell sind unsere Erfahrungen aus zahlreichen Projekten eingeflossen. In den folgenden Kapiteln werden wir zeigen, wie sich Aussagen über die aktuelle Qualität der zu entwickelnden Software treffen lassen, welche Rolle die Wahl geeigneter Qualitätsoperationen dabei spielen und welchen Einfluss der Umsetzungsgrad bzw. Abdeckung der Anforderungen durch bestimmte Qualitätsoperationen auf die Gesamtqualität hat. 2 Qualitätsbewertung in Software-Projekten Die prinzipielle Vorgehensweise zur Qualitätsbewertung ist in Abb. 2 gezeigt. Als Basis der Bewertung werden Artefakte, die im Laufe des Entwicklungsprozesses entstehen, nach bestimmten Kriterien kategorisiert. Die Artefakte sind typischerweise Quellcode, Anforderungsdokumente und Modelle. Ein mögliches Kriterium für die Strukturierung der Artefakte ist z.B. der Automatisierungsgrad der anzuwendenden Qualitätsoperationen. Im zweiten Schritt wird das Qualitätsmodell für das Projekt festgelegt, auf dessen Basis die Artefakte analysiert und bewertet werden. Hier werden die anzuwendenden Qualitätsoperationen und die jeweils zugehörigen Metriken definiert. Ein Ansatz, wie ein Qualitätsmodell für Simulink Modelle entwickelt und angewendet werden kann, ist in [6] beschrieben. Bekannte Qualitätsmodelle (vgl. Kapitel 3) unterscheiden sich von unserer Vorgehensweise dadurch, dass diese einzelne Aspekte wie z.B. Wartbarkeit, Testbarkeit, Lesbarkeit, in den Vordergrund stellen und nur die für diesen Aspekt relevanten Metriken berücksichtigen. Unser Qualitätsmodell ist flexibel, so dass der Anwender die Möglichkeit hat, eine projektspezifische Adaptierung vorzunehmen. Diese Adaptierung erfolgt durch
13
die Integration der im jeweiligen Projektkontext benötigten Qualitätsoperationen. Qualitätsoperationen sind alle Tätigkeiten, die zur Bewertung der Qualität eines entstehenden Produktes angewendet werden wie z.B. Reviews der Anforderungsdokumente oder der Testspezifikation, Prüfung der Einhaltung von Modellierungsrichtlinien, Durchführung von Modellreviews und -tests. Beispielsweise fassen wir auch die Traceability der Safety Requirements von den Anforderungen zum Modell und zum Test als Qualitätsoperation auf.
Qualität Projekt
Qualitätsbewertung Bewertung der Artefakte aus Qualitätsaktionen und Metriken Aggregation aller Werte zu einem Gesamtbild Bewertung der Abdeckung (Coverage)
Bewertung Artefakte
Qualität Modell
Qualität Dokument
Metriken
Metrik 1
Metrik 2
Qualitäts-Modell
Aktion A
Aktion B
Quantitative Erhebung von Qualitätskennzahlen aus den Artefakten Messung der Abdeckung (Coverage)
Modell
Dokument
Qualitätsoperationen
Artefakte
Projekt Auswahl und Strukturierung der Artefakte
Abbildung 2: Prinzip der Qualitätsbewertung von Software-Projekten Die Qualität modellbasiert entwickelter Software-Produkte unterliegt vielen Einflussfaktoren die sich anhand typischer Fragen, die im Rahmen der Qualitätsbewertung aufkommen, identifizieren lassen. Zu diesen Fragen gehören die nachstehend aufgezählten.
Wie viele Tests sind spezifiziert? Wie viele der spezifizierten Tests sind implementiert? Wie viele der Tests laufen fehlerfrei (passed/failed Verhältnis) Wie viele der Anforderungen sind durch Tests abgedeckt? Wie viele der Anforderungen sind im Modell umgesetzt? Wie viele Safety-Anforderungen sind umgesetzt / getestet? Wie viele der Modellierungsrichtlinien sind im Modell eingehalten? Wie viele Modellteile sind leicht erweiterbar und nicht zu komplex? Wie viele Modellteile sind durch Tests abgedeckt? Wie viele Anmerkungen (Issues) aus dem Modell-Review liegen vor?
Abb. 3 zeigt die Faktoren, die wir aufgrund unserer Erfahrungen als die wichtigsten ansehen. Die Qualität eines Modells, das zum SW-Design und zur Codegenerierung verwendet wird, durch vier wesentliche Faktoren beeinflusst: (1) Der Umfang und die Qualität der Anforderungen, (2) der Umfang und die Intensität der Modellanalyse; (3)
14
der Umfang und die Intensität bzw. Tiefe des Testens; sowie (4) die Aufzeichnung und Nachverfolgung aufgekommener Anmerkungen (Issues) und Fehler (Bugs).
Abbildung 3: Einflussfaktoren auf die Modellqualität Diese Faktoren müssen einerseits alleinstehend bewertet werden, andererseits aber auch im Zusammenhang betrachtet werden. 1.
Requirementsanalyse: Es ist zunächst wichtig zu wissen, in welchem Umfang die Anforderungen im Modell umgesetzt wurden. Ziel ist es, 100% der Anforderungen im Modell umzusetzen. Eine Aussage, dass 80% der textuellen Anforderungen bereits umgesetzt sind, mag einen Projektleiter beruhigen. Aber man sollte im Hinterkopf behalten, dass oftmals aus Zeitgründen zuerst die „einfachen“ Anforderungen umgesetzt, bevor komplexere Probleme gelöst werden. Somit ist die Qualität einer Anforderung ein entscheidender Faktor, um einen aussagekräftigen Umsetzungsgrad zu erhalten. Eine einfache Methode, um dies zu berücksichtigen ist z.B. die zahlenmäßig Gewichtung der Anforderungen oder eine Einteilung in Kategorien wie z.B. leicht, mittel und schwer implementierbar.
2.
Modellanalyse: Die Modellanalyse umfasst Komplexitätsmessungen und Überprüfung von Modellierungsrichtlinien. Ersteres beinhaltet die zahlenmäßige Erhebung der Komplexität und Modellierungstiefe (Subsystemhierarchie) über Metriken Eine Erweiterung hierzu ist die Gewichtung der Subsysteme über die Komplexität. Vorgehensweisen hierzu werden in [5] erläutert. Letzteres dient der Überprüfung, in welchem Umfang das Modell gängigen sowie firmen- oder projektspezifischen Modellierungsrichtlinien entspricht. Zusätzlich kann die Anzahl der Verletzungen pro Subsystem in Verbindung mit der Komplexität des jeweiligen Subsystems betrachtet werden.
3.
Testmanagement: Das Testmanagement muss unterschiedliche Fragen beantworten können, beispielsweise (1) wie viele Tests sind spezifiziert; (2) wie viele Tests wurden implementiert; (3) wie viele der Tests wurden erfolgreich ausgeführt (Ziel:
15
100% passed); (4) wie viele haben einen Fehler erzeugt (fail); (5) wie viele Testfälle decken bzw. testen wie viele Anforderungen ab. Um eine effiziente Bewertung der Qualität zu ermöglichen, sollten insbesondere Methoden eingesetzt werden, für die Werkzeugunterstützung vorhanden ist. In Abb. 4 sind Beispiele von Werkzeugen gezeigt, die für die identifizierten Einflussfaktoren eingesetzt werden. Die Werkzeuge stehen hier stellvertretend für die zahlreichen auf dem Markt für die unterschiedlichen Aufgaben verfügbaren. Gezeigt sind die Werkzeuge, die unserer Erfahrung nach im Rahmen der modellbasierten Entwicklung auf Basis von Simulink in Verbindung mit TargetLink [2] am häufigsten bei den OEMs und Zulieferern der Automobilindustrie eingesetzt werden. Ausgenommen von dieser Betrachtung sind firmenspezifische Werkzeuge, die nicht frei auf dem Markt verfügbar sind.
Abbildung 4: Werkzeuge zur Qualitätsermittlung Zur Verwaltung der textuellen Anforderungen werden häufig komplexe Werkzeuge wie IBM Rational DOORS1 oder MKS2 eingesetzt, aber auch der Einsatz von MS Word oder MS Excel sind üblich. Zur Modellanalyse werden auf die Toolkette zugeschnittene Werkzeuge zur Modellanalyse eingesetzt. Die Komplexitätsmessung erfolgt entweder über die Simulink V&V Toolbox [1], welche die Anzahl der im Modell verwendeten Blöcke sowie die zyklomatische Komplexität auf Modellebene berechnet, oder M-XRAY3 [5] welches darüber hinaus das Modellvolumen sowohl des Gesamtmodells als auch individuell für .jedes Subsystem berechnet. Bei der Überprüfung der Modellierungsrichtlinien werden schwerpunktmäßig für Serienprojekte: (1) für reine Simulink Modelle, aus denen Seriencode mit dem Real-Time Workshop/Embedded Coder erzeugt werden soll, der Simulink Model Advisor [1]; (2) für TargetLink Modelle der Model Examiner4 [7] eingesetzt. Zur Analyse des generierten Codes oder der manuell implehttp://www-01.ibm.com/software/awdtools/doors/ http://www.mks.com/germany/mks.de 3 http://www.model-engineers.com/en/our-products/m-xray.html 4 http://www.model-engineers.com/en/our-products/model-examiner.html 1
2
16
mentierten Codeanteile wird –insbesondere in sicherheitsrelevanten Projekten – der Polyspace Design Verifier eingesetzt. Die Einhaltung von Code-Richtlinien wie z.B. MISRA C werden meistens durch QAC5 überprüft. Das Angebot von Testwerkzeugen für die hier betrachtete Toolkette ist umfangreich, jedoch überschaubar, wo diese Werkzeuge für Serienprojekte eingesetzt werden. Hier hat sich TPT6, Embedded Tester7, sowie MTest classic8 bei den am Markt verfügbaren Werkzeugen durchgesetzt. Für das Issue- bzw. Bugtracking werden unterschiedlichste Lösungen eingesetzt, die häufig aus Open-Source Projekten stammen wie z.B. Bugzilla und Redmine. MQAC-Qualitätsmodell Eine umfangreiche Qualitätsbewertung erfordert es, die sehr heterogenen Ergebnisse der unterschiedlichen Werkzeugen zu aggregieren, und zu einem Gesamtbild zu verdichten. Um dies zu ermöglichen, werden in unserem Qualitätsmodell die Bewertungssysteme der einzelnen Qualitätsoperationen auf ein vierstufiges Bewertungssystem abgebildet. Unser vierstufiges Bewertungssystem erweitert das in der Praxis verwendete dreistufige System mit den Werten gut-akzeptabel-ungenügend um den Wert unbekannt. Dieser vierte Wert ermöglicht es, bei der Qualitätsbewertung auch zu berücksichtigen, ob geplante Qualitätsoperationen noch nicht durchgeführt wurden.
Abbildung 5: Aggregation von Metrik(werten) einer Qualitätsoperation In Abb. 5 ist unser Verfahren zur Berechnung von Qualitätswerten für die Anwendung einer Qualitätsoperation auf ein Artefakt gezeigt. Hier wird der Qualitätswert eines Artefaktes über den Mittelwert der Ergebnisse berechnet, die durch die Qualitätsoperation erhoben wurden. Die Metrik kann hier Zahlenwerte für unterschiedliche Metrikwerte wie unknown, bad, acceptable oder good liefern. Die einzelnen Zahlen, die für diese Metrikwerte erhoben wurden, werden auf einen Qualitätswert für den jeweiligen Metrikwert abgebildet. So werden beispielsweise den vier Metrikwerten die Werte unknown=0, bad=0.2, acceptable=0.8 und good=1 zugeordnet. Daraus ergibt sich der treppenstufige Verlauf des Qualitätswerts, der als durchgängige Linie dargestellt ist. Konti5
http://www.qasystems.de/qac http://piketec.com/products/tpt.php 7 http://www.btc-es.de 8 http://www.mtest-classic.com/ 6
17
nuierliche Verläufe können bei Bedarf wie hier gezeigt durch die gestrichelte oder gepunktete Linie dargestellt werden. Die Qualitätswerte für die einzelnen Qualitätsoperationen berechnen sich dann über den Mittelwert der einzelnen Metrikwerte (siehe Formel in Abb. 5). Die einzelnen Metrikwerte i können bei Bedarf noch unterschiedlich gewichtet werden, mit Werten weighti ≥ 0 und ≤1 und ergeben so einen gewichteten Mittelwert. Qualitätswert Odometer (gesamt) = 0.89 0.8 * 0.93 + 0.2 * 0.74= 0.89
Bewertung Artefakt
Gewicht Modelltest = 0.8
Qualität Modell Odometer
Qualitätswert: Modelltest = 0.93 (80 * 1 + 5 * 0.2 + 2 * 0) / 87 = 0.93
Metriken + Bewertung
Modelltest Odometer
Qualitätsoperationen
Modelltest
Artefakt
Gewicht Guidelines= 0.2
Qualitätswert: Guidelines = 0.74 (68 * 1 + 7 * 0.8 + 34 * 0.2 + 0 * 0) / 109 = 0.74 Ergebnis: Passed (good): 80 Failed (bad): 5 Unknown: 2
Guidelines Odometer
Ergebnis: Passed (good): 68 Warning (acceptable): 7 Failed (bad): 34 Not executable (unknown): 0
Überprüfung Modellierungsrichtlinien
Modell Odometer
Abbildung 6: Beispiel: Berechung des Qualitätswerts für das Modell Odometer Diese Vorgehensweise zur Berechnung von Qualitätswerten soll an einem Beispiel erläutert werden (siehe Abb. 6). Hier soll der Qualitätswert für das Simulink Modell Odometer berechnet werden. Für das Modell wurden (1) der Modelltest und (2) die Überprüfung von Modellierungsrichtlinien durchgeführt. Die Ergebnisse der beiden Qualitätsoperationen sind wie folgt: (1) Modelltest: im Rahmen des Modelltests wurden insgesamt 87 Testfälle ausgeführt. 80 lieferten das Ergebnis passed, 5 den Wert failed und 2 lieferten ein ungeklärtes (unknown) Ergebnis. Um die Ergebnisse auf den Graphen in Abb. 5 abzubilden werden diese auf das MQAC-Ampelsystem zugeordnet und gewichtet: passed=good (1), failed=bad (0.2), unknown=unknown (0). Der Qualitätswert von 0.93 für den Modelltest wird mithilfe der Formel in Abb. 5 berechnet; (2) die Überprüfung der Modellierungsrichtlinien wurde äquivalent durchgeführt. Insgesamt wurden 109 Modellierungsrichtlinien am Modell überprüft. 68 lieferten das Ergebnis passed, 7 den Wert warning, 34 den Wert failed und 0 lieferten ein ungeklärtes (unknown) Ergebnis. Die Abbildung auf das MQAC-Ampelsystem ist wie folgt: passed=good (1), warning=0.8, failed=bad (0.2), unknown=unknown (0). Als Ergebnis wird die Überprüfung des Modells auf Richtlinienkonformität mit 0.74 bewertet. Für die Aggregation der Ergebnisse wird hier dem Modelltest eine höhere Bedeutung bzw. Gewichtung als der Richtlinienprüfung beigemessen, d.h. der Modelltest wird mit 0.8, die Richtlinienprüfung am Modell mit 0.2 gewichtet. Damit ergibt sich eine Gesamtqualität des Modells Odometer zum Zeitpunkt ti von 0.89. Es ist durchaus üblich, alle Qualitätsoperationen gleichwertig zu gewichten. Durch die Gewichtung der Qualitätsoperationen ist es z.B. in sicherheitsrelevanten Projekten möglich die Abdeckung der Safety-Requirements besser zu berücksichtigen. Die am Beispiel gezeigte Methodik kann dahingehend erweitert
18
werden, dass die Qualität einzelner Artefakte (Modelle) bzw. Versionen eines Modells zu einer Gesamtbewertung des Projekts über die Zeit aggregiert werden. Modellkomplexität
Qualitätsbewertung (Aggregation) Qualität Projekt
Bewertung Artefakte
Metriken
Qualität Modell 1
Modelltest Modell 1
Qualität Modell n
Modelltest Modell 2
Modelltest Modell n
Modell 1
Modell 2
Versionen
Guidelines Modell 1
Guidelines Modell 2
Guidelines Modell n
QualitätsModell
Modellierungsrichtlinien
Modelltest
QualitätsQualitätsoperationen operationen
Artefakte
Qualität Guidelines
Qualität Modelltest
Qualität
Bewertung QualitätsBewertung operationen Qualitäts-Aktionen
(Guidelines)
Modell n
Projekt
Abbildung 7: Aggregation von Qualitätswerten zur Qualitätsbewertung Die allgemeine Vorgehensweise, wie Qualitätswerte zur Qualitätsbewertung eines Projektes aggregiert werden ist in Abb. 7 exemplarisch gezeigt (vgl. auch Abb. 2). Dabei kommen beispielhaft wieder der Modelltest und die Richtlinienprüfung zum Einsatz, wobei alternative Qualitätsoperationen wie Reviews, Codeanalysen analog integriert werden. Ähnlich wie im Beispiel in Abb. 6 werden die Metriken der einzelnen Qualitätsoperationen zu einer Gesamtbewertung aggregiert. Die Qualitätsbewertung ergibt sich auch hier aus dem gewichteten Mittelwert der einzelnen Qualitätsoperationen. Bei einer Betrachtung mehrerer Versionen der Artefakte über die Projektlaufzeit (vgl. Abb. 7, oben rechts) lässt sich der Verlauf der Qualität aufzeichnen und beobachten (hier: Projektversion v56 ... v67 mit den entsprechenden Qualitätswerten).
3 Verwandte Arbeiten Ein generisches Qualitätsmodell stellt der Goal-Question-Metric-Ansatz (GQM) dar [8]. Hierbei wird wie bei der Verwendung eines FCM-Modells (Factors, Critera, Metrics) die Qualität von Software bzw. Modellen objektiv erfassbar. Weitere ähnliche Softwarequalitätsmodelle sind bspw. [9] und die ISO 9126. Allen gemeinsam sind Faktoren wie Zuverlässigkeit, Effizienz, Wartbarkeit und Portierbarkeit. Einen Ansatz zur Qualitätsbewertung von UML-Modellen wird in [10] beschreiben in. Hier wird zwischen Entwicklung und Wartung unterschieden, da in den jeweiligen Phasen andere Qualitätskriterien relevant sind.
19
4 Zusammenfassung Wir haben ein Verfahren zur Qualitätsbewertung von modellbasiert entwickelten Software-Systemen vorgestellt. Unser Verfahren basiert darauf, dass die Ergebnisse unterschiedlicher Qualitätssicherungsmethoden einheitlich betrachtet werden. Neben der rein quantitativen Erhebung von Qualitätsoperationen werden auch Zusammenhänge zwischen Artefakten zur Bewertung herangezogen, wie z.B. der Umsetzungsgrad von Anforderungen im Modell oder deren Abdeckung durch den Modelltest. Für die empirische Evaluierung unseres Qualitätsmodells gibt es aufgrund der im Kapitel 1 beschriebenen Probleme der Qualitätsbewertung in der modellbasierten Entwicklung keine ausreichenden Daten. Unser Werkzeug MQAC, das bereits in Kundenprojekten eingesetzt wird, ermöglicht es, diese Daten systematisch zu erheben und zu verwalten. Dies wird eine umfassendere Evaluierung des von uns vorgeschlagenen Qualitätsmodells ermöglichen. Unser Verfahren lässt sich aus unserer Sicht zukünftig dahingehend erweitern, dass projektspezifische quantitative Kennzahlen wie z.B. Aufwandsabschätzungen, Speicherverbrauch, Objektcodegröße, in die Berechnungen mit einfließen können. Hierdurch lassen sich Aufwände für die Umsetzung von Anforderungen, für die Testimplementierung, Testdurchführung und die Einhaltung von Vorgaben für das Projekt abschätzen und kalkulieren.
5 Literaturverzeichnis [1] [2] [3]
[4]
[5] [6] [7] [8] [9] [10]
20
MathWorks, (product information) http://www.mathworks.com/products, 2011. dSPACE: TargetLink – Production Code Generator at http://www.dspace.com, 2011. Broy, M., Kirstan, S., Krcmar, H., Schätz, B.: “What is the Benefit of a Model-Based Design of Embedded Software Systems in the Car Industry?”, in Rech, J., and Bunse, C. (Hrsg.) Emerging Technologies for the Evolution and Maintenance of Software Models, pp. 343-369, 2011. Fey, I., and Stürmer, I.: “Quality Assurance Methods for Model-based Development: A Survey and Assessment”, SAE World Congress, SAE Doc. #2007-01-0506, Detroit, 2007. Also appeared in SAE 2007 Transactions Journal of Passenger Cars: Mechanical Systems, V116-6, Aug. 2008. Stürmer, I., Pohlheim, H., Rogier, T.: „Berechnung und Visualisierung der Modellkomplexität bei der modellbasierten Entwicklung sicherheitsrelevanter Software“, in Keller, B. et. al. (Hrsg.), Automotive - Safety & Security, Shaker Verlag, S. 69-82, 2010. Scheible, J., Kreuz, I.: „Ein Qualitätsmodell zur automatisierten Ermittlung der Modellqualität bei eingebetteten Systemen“, in Proc. of the 8. GI Workshop, Automotive Software Engineering, Leipzig, Germany, 2010. Stürmer, I., Stamatov, S., Eisemann, U.: “Automated Checking of MISRA TargetLink and AUTOSAR Guidelines”, Proc. of SAE World Congress 2009, SAE Doc. #2009-010267, Detroit (USA), April, 2009. V. Basili, G. Caldiera und H.D. Rombach. Encyclopedia of Software Engineering, Wiley & Sons., S. 646–661, 1994. B. W. Boehm, J. R. Brown und M. Lipow, “Quantitative evaluation of software quality”, In Proceedings of the 2nd International Conference on Software Engineering, IEEE Computer Society Press, pp. 592–605, 1976. C. F. J. Lange und M. R. V. Chaudron. Managing Model Quality in UML-Based Software Development. In Proc. of the 13th IEEE International Workshop on Software Technology and Engineering Practice, pp. 7–16. IEEE Computer Society, 2005.
Solving Modeling Problems with Machine Learning A Classification Scheme of Model Learning Approaches for Technical Systems Oliver Niggemann1,2 1
Benno Stein3
Alexander Maier2
Fraunhofer IOSB – Competence Center Industrial Automation, Lemgo, Germany
[email protected] inIT – Institut Industrial IT Hochschule Ostwestfalen-Lippe, Lemgo, Germany
[email protected] 2
3
Bauhaus-Universität Weimar, Germany
[email protected]
Abstract: The manual creation and maintenance of appropriate behavior models is a key problem of model-based development for technical systems such as vehicles or production systems. Currently, two main approaches are considered promising to overcome this bottleneck: (a) The fields of software and system engineering try to develop better methods and tools to synthesize models manually. (b) The field of machine learning tries to learn such models automatically, by analyzing observations from running systems. While software and system engineering approaches are suited for new systems for which modeling expertise is at hand, machine learning approaches are suited for the handling of running systems such as monitoring, diagnosis, and system optimization. Given this background our contributions are as follows: To organize existing research, Section 2 introduces a classification scheme of models and model learning algorithms. Section 3 reports on two different case studies to illustrate the power of the machine learning approach.
Keywords: Model Formation, Simulation, Machine Learning, Technical Systems
1
Introduction
Learning models based on observations is a promising approach to overcome the modeling bottleneck. Learning is for many modeling formalisms state-of-the-art; but there exist also several formalisms for which learning is still a challenge: Especially formalisms comprising aspects such as timing or hybrid signals are a challenge for an automatic model generation. So in this paper, first of all a classification schema for model formalisms is given which allows for a qualification of formalisms with regard to their learnability (section 2). Then, in section 3, two case studies present learning algorithms for formalisms which are at the edge of the current state of the art of model learnability.
21
2 2.1
A Classification Scheme of Model Synthesis Classification of Model Formalisms
In all engineering fields, models are, among other things, used to predict a system’s behavior. Such predictions are the basis for fundamental tasks such as planning, verification, diagnosis, or optimization. These tasks can be subsumed as model-based engineering. The automatic learning of models for technical systems could be the next big step in model-based development. Automatic model learning would relieve an engineer from the difficult job of constructing a behavior model for a task in question. But, not all models can be learned automatically: In some cases, the models are too complex. In other cases, not enough observations exist to learn the model. In this section, first of all a classification scheme for models of technical systems is presented which is later on used to define the theoretical capability to learn a model automatically. Our scheme is oriented at two widely-used model classification principles in engineering and system theory: at a model’s structural variance of time as expressed by its number of modes and at the different forms of a model’s state space [Wym76, ZPK00, Ste01]. In addition, we will explicitly distinguish models whose behavior is governed by stochastic elements. How can such a classification scheme for models be developed? For this, a technical system’s most distinguishing feature is exploited: its time-dependence. Time has mainly two manifestations in a technical system: 1. Smooth Changes: All technical systems show a specific behavior over time. This is visible by the change of physical values such as temperature or positions. Usually, these changes over time are smooth—”Natura non facit saltus” (nature does not make jumps, Poseidonios) has been a main axiom of science since Aristotle. E.g. the flight curve of a cannon ball has clearly a smooth form. In engineering, this behavior is usually modeled using the notion of states. A technical system is always in one precise state and the next state is computed based on external inputs/events and on the previous states. Table 1’s bottom row classifies this time behavior by the means of five classes: Memoryless models Given a constant input signal, memoryless models do not show a behavior variation over time. Models of this type are also called stationary models. Dynamic models (with finite state number) The system behavior is comprised of a sequence of signal values where time is modeled explicitly. Each new model state is computed based on the state’s predecessors. Examples include temporal automata and temporal logic. Dynamic models (with infinite state number) Given a constant input signal and some internal arbitrary state, the behavior over time is created by iteratively computing all signal values along with their derivatives. I.e. the time characteristic is computed implicitly by a numerical solver. Dynamic stochastic models (with finite state number) Dynamic stochastic models show a non-deterministic behavior. This may be caused by random effects such as
22
Complexity of model function
Table 1: Classification of models oriented at the dimensions model dynamics and model function.
Multimode
Singlemode
Discrete models
Hybrid models
Discrete models with random states
Hybrid models with random states
Example: hierarchical automaton
Example: hydraulic circuit
Example: production system
Example: process industry
Function models
Discrete models
Differentialalgebraic models
Discrete models with random states
Differentialalgebraic models with random states
Example: resistor, Neural Network
Example: temporal automaton
Example: oscilator circuit
Example: robot with defects
Example: defect transitor
∅
finite #states Memoryless models
infinite #states
Dynamic models
finite #states
infinite #states
Dynamic stochastic models
Complexity of model dynamics
errors or by asynchronous parts of the systems that run independently and show therefore a stochastic timing behavior. Dynamic stochastic models (with infinite state number) These models are similar to the class of “dynamic stochastic models with finite state number” but comprise an infinite number of states. 2. Disruptive Changes: A system may, at some point in time, fundamentally change its behavior, e.g. the cannon ball from above hits the the ground. Or a vehicle changes its gear or a valve in a chemical reactor is opened. These disruptive changes correspond to a system’s modes. A mode is a discontinuity of the system, a point in time at which the model must be changed significantly because the system behavior changes significantly [Bue09]. Table 1 therefore differentiates between uni-modal and multi-modal systems. To the former belong all models which can can be described using a constant set of (differential) equations. The later may change their equation system as a reaction to specific events (discontinuity). Hybrid automata are an example for a formalism wich can explicitly express different system modes: Hybrid automata [ACH+ 95] are finite state machines which model a continuous system behavior within each state [ACH+ 95], i.e. each state comprises the model of one mode. At the occurrence of a specific input/events, the model goes from one state (mode) to the next state (mode). 2.2
Classification of Model Learning Algorithms
For these different model types, different learning algorithms are available. Table 2 characterizes some common machine learning algorithms according to the scheme from above: All uni-modal, memoryless models can be learned using function approximation approaches: For this, a function template is given a-priori and is then parameterized by minimizing the prediction error of the function on the observations. Generally speaking such approaches are well studied (e.g. in [MS03a, MS03b]). E.g. model formalisms such
23
Complexity of model function
Table 2: On the learnability of model behavior, considering the model types shown in Table 1.
Multimode
Singlemode
Rule learning
Hybrid Automata Learning
Examples: [MVN11, VdWW10]
Example: [VBNM11]
Function approximation
Rule learning
Learning of DAEs
Example: Regression
Examples: [MVN11, VdWW10]
Example: [SL09]
∅
finite #states Memoryless models
infinite #states
Dynamic models
Learnable?
Learnable?
Learnable?
Learnable?
finite #states
infinite #states
Dynamic stochastic models
Complexity of model dynamics
as Neural Networks or Support Vector Machines rely on optimization approaches [Alp10]; however, usually a large number of observations is required. Uni-modal, dynamic models are harder to learn because the states have to be identified. Since states capture the system timing behavior, all observations must be analyzed including their progression over time. So while memoryless model learning algorithms simply have to analyze all observations, dynamic models also have to analyze the temporal relations between observations. It is therefore not surprising that the learning of dynamic models is still an on-going research topic: E.g. the learning of timed automata [MVN11, VdWW10] or the learning of (temporal) rules [FGS02, WF05]. For uni-modal dynamic models with an infinite number of modes, the problem is even harder: Only a few projects try to identify such equation system. As a work-around, often an a-priori model comprising all modes is defined manually. Such model identification approaches identify missing model parameters by means of optimization algorithms [Ise04]. For multi-modal models, almost no learning algorithms exist: For hybrid automata, a first algorithm is presented in [VBNM11] which learns both the states and the temporal transitions of the automaton. In general, no learning algorithms exist for stochastic dynamic models. E.g. it is not possible to identify asynchronous system parts based on observations of the overall system. Again as a work-around, often the model structure is defined manually and then parameterized by means of optimization algorithms, e.g. for Markovian Chain [P. 99].
3
Case Studies
In the following, two case studies are given which describe approaches for learning models based on observations. Both case studies learn model formalisms which have been characterized in section 2 as being on the edge of learnability.
24
Production Plant
Model (Hybrid Automaton)
Controller
Controller
Network Energy Measurements
Comparison
Energy Predictions
Anomalies
Figure 1: Detecting Energy Anomalies using Hybrid Automata
3.1
Case Study: Energy Anomaly Detection of Production Plants
Use Case The automatic detection of suboptimal energy consumptions in production plants is a key challenge for the European industry in the next years [Gro06, VDI09]. Currently, operators are mainly concerned about a plant’s correct functioning; energy aspects are still regarded as of secondary importance. And even if energy aspects are seen as a problem, operators mainly replace single hardware components, e.g. the installation of an energy-optimized drive. Details about these passive approaches can be found e.g. in [EWO, EnH] or even in combination with simulation in [eS]. But a large optimization potential lies on the system level: Plant modules, engines, drives should be controlled in a way which takes energy aspects in consideration. E.g. the synchronized start of drives should be avoided because it can cause harmonics which have to be paid by the operators. Or a prediction of the energy price can be used to save on energy-intensive production steps. And furthermore, plant errors leading to suboptimal energy consumptions can be detected and repaired, e.g. blocked pipes, worn drives, or broken sensors. Such active approaches, implemented in the automation systems, can be found e.g. in [CKT09, DV08]. As a first step, suboptimal situations should be detected automatically. Suboptimal energy situations can be detected by means of model-based anomaly detection systems as depicted in figure 1: A model is used to simulate the normal energy consumption of a plant. For this, the simulation model, here a timed hybrid automaton, needs all input of the plant, e.g. product information, plant configuration, plant status, etc. If the actual energy measurements vary significantly from the simulation results, the energy consumptions is classified as anomalous. The details of this anomaly detection algorithm ANODA is given in [VBNM11]. But the manual creation of such a timed hybrid automaton is hardly feasible. Therefore, in [VBNM11, MVN11] a method is given which allows for an automatic learning for these models. The general idea can be seen in figure 2: During a plant’s normal operation, all sensor/actor data is measured by accessing directly the industrial networks; this data is
25
extended by data from the MES and the ERP systems. As a result, all data is stored in a database. For this, the time synchronization of the data is essential. Next, the algorithms BUTLA and HyBUTLA are used to learn a timed hybrid automaton from these data. In [VBNM11], some energy errors are detected which are caused by errors such as broken sensors (value offset by 10%) or incorrect control signal timing. The accuracy of this anomaly detection has been better than 93%. Classification according to the Taxonomy Production plants are multi-mode systems: E.g. production modules are turned on and off or gates of transportation systems are changed. So any learning algorithm must be able to detect mode changes. Unlike approaches such as the learning of Markovian Chains, here the states of the hybrid automaton themselves must be learned. If only probabilities or the timing of existing transitions are parametrized, the learning problem resembles a function approximation problem and can be solved by means of optimization algorithm. The learning of the states moves the problem into the class of dynamic model learning. Parts of such plants are often coupled in an asynchronous manner: Effectively, this leads to stochastic relations between the observations. So far, no learning algorithm is able to learn which parts of a plants are coupled asynchronously. In [VBNM11], this information is therefore given as input to the learning algorithm. 3.2
Case Study: Learning timing behavior by means of timed automata
Learning the timing behavior of discrete manufacturing plants is currently a big challenge (e.g. in [PH09], [JK01], [Ver10]). Such timing models can be used to analyze a system’s timing behavior and are the basis for tasks such as system optmization or diagnosis. Here, several algorithmic challenges exist: (1) One challenge in learning the timing behavior is the trade-off between abstraction and preciseness. The behavior of the plant has to be observed over a period of time. All these observations are then compiled into a more concise model, e.g. as timed automata. First, all observed event sequences are stored in a so-called prefix tree. Now compatible states are merged until the wanted trade-off between abstraction and preciseness is reached. Timing is an important criterion for defining the compatibility between states. Figure 3 shows an example: If timing is ignored, states 2 and 3 are compatible. But if the probability denSynchronized Sensor/Actor Values
Production Plant
Network Measurements
Controller
Controller
!! !!. !!..
Model (Hybrid Automaton)
Machine Learning
Network
Figure 2: Learning Models for the Energy Consumption using Hybrid Automata
26
a
2 1 a 2,3
1 a
3
Figure 3: Check for compatibility of timed events
sity functions at the transitions are taken into consideration, the new edge between 1 and the merged state 2, 3 shows a multi-modal probability density function, i.e. it is obviously created by two different technical processes and should not have been merged for the most cases. (2) Two system states are similar if they define a starting point for a similar future plant behavior. So in order to learn a unique state of a plant, the learning algorithm must analyze all state’s successor states. I.e. learning algorithms can not operate locally but must take the whole set of observations into consideration. (3) The timing behavior of a production plant can vary with the operating phase. E.g. during startup a plant often shows a different timing behavior than in regular operation because individual components must first reach the operating temperature. Furthermore, the timing behavior can change suddenly, e.g. after opening a valve or after closing a switch. Using normal timed automata, multi mode systems are hard to model; as a workaround, the mode switches can be turned into a specific event which leads to different sub-automata for each mode, i.e. to hierarchical automata (see also figure 2). [MVN11] describes an algorithm (BUTLA) to learn the normal behavior by means of timed automata using probability density functions. Similar to the case study "Energy Anomaly Detection of Production Plants" the applicability has been shown on the use case of timing anomaly detection. Here, the identified automaton was able to detect 88% of the timing failures correctly. In the remaining 12% an error was detected but the error cause was not identified correctly. Classification according to the Taxonomy Timed automata belong to the class of dynamic models and are normally used to model single mode systems; hierarchical automata are also able to model multi mode systems. Generally speaking, in the last years algorithms have been developed which are able to learn such models on the basis of observations from a running plant.
4
Summary and Future Work
The automatic learning of models helps to solve the key problem of the model-based development of technical systems: The modeling bottleneck—caused by high modeling efforts and the lack of domain experts. Currently, most projects choose the learning algorithm in a rather ad-hoc manner which leads to suboptimal learning results. But system, model, and learning algorithm must match. So in this paper a classification scheme of models is developed which may be used to assess the learnability of the model and which is related to a corresponding scheme of learning algorithms.
27
murray/.profile
References [ACH+ 95] R. Alur, C. Courcoubetis, N. Halbwachs, T. A. Henzinger, P. h. Ho, X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine. The Algorithmic Analysis of Hybrid Systems. Theoretical Computer Science, 138:3–34, 1995.
28
[Alp10]
Ethem Alpaydin. Introduction to Machine Learning. Mit Press, 2010.
[Bue09]
Dennis M. Buede. The Engineering Design of Systems: Models and Methods. John Wiley & Sons, 2009.
[CKT09]
Alessandro Cannata, Stamatis Karnouskos, and Marco Taisch. Energy efficiency driven process analysis and optimization in discrete manufacturing. In 35th Annual Conference of the IEEE Industrial Electronics Society (IECON 2009), Porto, Portugal, 3-5 November 2009.
[DV08]
A. Dietmair and A. Verl. Energy consumption modeling and optimization for production machines. In Sustainable Energy Technologies, 2008. ICSET 2008. IEEE International Conference on, pages 574 –579, November 2008.
[EnH]
EnHiPro. Energie- und hilfsstoffoptimierte Produktion. www.enhipro.de. Laufzeit 06/2009-05/2012.
[eS]
e SimPro. Effiziente Produktionsmaschinen durch Simulation in der Entwicklung. www.esimpro.de.
[EWO]
EWOTeK. Effizienzsteigerung von Werkzeugmaschinen durch Optimierung der Technologien zum Komponentenbetrieb. www.ewotek.de. Projektdauer: 01.07.2009 30.06.2012.
[FGS02]
A. Fern, R. Givan, and J. Siskind. Specific-to-General Learning for Temporal Events. In AAAI, 2002.
[Gro06]
High-Level Group. MANUFUTURE - Strategic Research Agenda. Technical report, European Commission, 2006.
[Ise04]
Rolf Isermann. MODEL-BASED FAULT DETECTION AND DIAGNOSIS - STATUS AND APPLICATIONS. In 16th IFAC Symposium on Automatic Control in Aerospace, St. Petersbug, Russia, 2004.
[JK01]
Shengbing Jiang and Ratnesh Kumar. Failure Diagnosis of Discrete Event Systems with Linear-time Temporal Logic Fault Specifications. In IEEE Transactions on Automatic Control, pages 128–133, 2001.
[MS03a]
M. Markou and S. Singh. Novelty Detection: A Review - Part 1. Department of Computer Science, PANN Research, University of Exeter, United Kingdom, 2003.
[MS03b]
M. Markou and S. Singh. Novelty Detection: A Review - Part 2. Department of Computer Science, PANN Research, University of Exeter, United Kingdom, 2003.
[MVN11]
A. Maier, A. Vodencarevic, and O. Niggemann. Anomaly Detection in Production Plants Using Timed Automata. In 8th International Conference on Informatics in Control, Automation and Robotics (ICINCO), 2011.
[P. 99]
P. Bremaud. Markov Chains - Gibbs Fields, Monte Carlo Simulation, and Queues. Springer Verlag, 1999.
[PH09]
S. Preuße and H.-M. Hanisch. Specification of Technical Plant Behavior with a SafetyOriented Technical Language. In 7th IEEE International Conference on Industrial Informatics (INDIN), proceedings pp.632-637, Cardiff, United Kingdom, June 2009.
[SL09]
Michael Schmidt and Hod Lipson. Distilling Free-Form Natural Laws from Experimental Data. SCIENCE, 324, April 2009.
[Ste01]
Benno Stein. Model Construction in Analysis and Synthesis Tasks. Habilitation, Department of Computer Science, University of Paderborn, Germany, June 2001.
[VBNM11] A. Vodencarevic, H. Kleine Büning, O. Niggemann, and A. Maier. Using Behavior Models for Anomaly Detection in Hybrid Systems. In 23rd International Symposium on Information, Communication and Automation Technologies-ICAT 2011, 2011. [VDI09]
VDI/VDE. Automation 2020 - Bedeutung und Entwicklung der Automation bis zum Jahr 2020, 2009.
[VdWW10] Sicco Verwer, Mathijs de Weerdt, and Cees Witteveen. A Likelihood-Ratio Test for Identifying Probabilistic Deterministic Real-Time Automata from Positive Data. In Jose Sempere and Pedro Garcia, editors, Grammatical Inference: Theoretical Results and Applications, Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2010. [Ver10]
Sicco Verwer. Efficient Identification of Timed Automata: Theory and Practice. PhD thesis, Delft University of Technology, 2010.
[WF05]
I. H. Witten and E. Frank. Data Mining: Practical Machine Learning Tools and Techniques. Morgan Kaufmann, 2005.
[Wym76]
A. Wayne Wymore. Systems Engineering for Interdisciplinary Teams. John Wiley & Sons, New York, 1976.
[ZPK00]
Bernard P. Zeigler, Herbert Praehofer, and Tag Gon Kim. Theory of Modeling and Simulation. Academic Press, New York, 2000.
29
!
30
Automating Code Reviews with Simulink Code Inspector Mirko Conrad, Matt Englehart, Tom Erkkinen, Xiaocang Lin, Appa Rao Nirakh, Bill Potter, Jaya Shankar, Pete Szpak, Jun Yan, Jay Clark The MathWorks, Inc., Natick, MA, USA Abstract: Safety standards such as DO-178B require source code reviews. Given the maturity of today‟s code generators, the effectiveness of manual reviews of automatically generated code is rather limited. This results in a strong desire to automate reviews of automatically generated code. This paper introduces Simulink Code InspectorTM, a novel tool to automate manual code reviews of C source code generated from Simulink® models.
1 Code Reviews according to DO-178B DO-178B [DO-178B] is a certification standard for civil aviation published in 1992. It provides “guidelines for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements”. To detect and report errors that might have been introduced during the software coding process, DO178B requires reviews and analyses to “confirm that the outputs of the software coding process are accurate, complete and can be verified” (cf. DO-178B, section 6.3.4). The objectives of software code reviews are detailed in DO-178B, table A-5. A common approach to satisfy these objectives is to carry out manual reviews of the source code. Manual code reviews are labor intensive and in case of automatically generated code typically not very effective. Practitioners estimate that about 50 lines of source code (LoC) can be reviewed in a one hour period, resulting in engineering costs of $150. Projected onto a 100.000 LoC project, the source code review would last 2000 hours and cost $ 0.3 million. Given the maturity of today‟s code generators, the efficacy of manual review of automatically generated code is quite limited. [Pot04] e.g. reports about the certification of DO-178B flight code at Honeywell. The amount of code certified exceeded 1.000.000 LoC per year. The study reports that only one code generation error was found in a one year time period. Using the above cost estimates, this would translate to a cost of $ 3million to find one bug. These numbers speak for themselves. The low efficacy of manual reviews of generated code creates a high demand for automating the code review process.
2 Simulink Code Inspector Overview To automate reviews for source code developed from Simulink models, the authors developed Simulink Code Inspector [SLCI] a novel tool to automate code reviews required by DO-178B and other functional safety standards. Simulink Code Inspector carries out a translation validation of C code generated from a Simulink [Simulink] model using the Embedded CoderTM [ECoder] code generator. In particular, SLCI systematically examines blocks, parameters, and settings in a Simulink model to determine whether they are structurally equivalent to operations, operators, and data in the C source code generated from the model (Fig. 1). Inputs to Simulink Code Inspector are a Simulink model and the C source code generated by the Embedded Coder code generator for this model. SLCI processes these two inputs into internal representations (IRs), called model IR and code IR. These IRs are transformed into normalized representations to facilitate further analysis. In this process, the model IR represents the expected pattern, whereas the code IR constitutes the actual pattern to be verified. To verify the generated code, SLCI attempts to match the normalized model IR with the normalized code IR. In this process SLCI examines aspects such as model interface, block behavior, block connectivity, execution order, data / file packaging, and usage of local variables.
31
Simulink model
C source code
Embedded Coder
Code IR
Model IR
IR transformations Normalized Model IR
Normalized Code IR
Matching
Code inspection report
?
Traceability report
Figure 1. Code Inspection Approach
The utilization of normalization techniques allows to inspect code generated by an highlyoptimizing code generator. The results of this matching process are reported to the user by means of a verification report and a traceability report. In case of a completed code inspection, the verification report documents the translation validation process whereas the traceability report maps the model elements onto their counterparts in the generated code and vice versa. The reports generated by Simulink Code Inspector are used as evidence to document the automated code review process. Upon DO-178B verification tool qualification, SLCI significantly reduces time and cost associated with verifying code against requirements. Instead of completing manual line-by-line code reviews with a project checklist, which is time intensive and error prone, users can run the Code Inspector and review a detailed inspection report.
3 Example: Roll Axis Autopilot Model In this section we illustrate the usage of Code Inspector by using the example of a Roll Axis Autopilot model and the C code generated from this model. Simulink Code Inspector can be invoked from a graphical user interface or via a MATLAB command line API. To kick-off the code inspection, the user can launch a compatibility checker that helps to identify modeling constructs and tool settings that are not supported by the Code Inspector. The compatibility checker leverages the Model Advisor infrastructure [MdlAdv] to statically analyze the model. If applicable, the compatibility checker also provides suggestions on how to replace incompatible modeling constructs with ones supported by the tool. After passing the compatibility check, the user can initiate the actual code inspection process. The tool can be configured to check an individual model or an entire hierarchy of referenced models. Fig. 2 (left) shows the top level of the Simulink model of a roll axis auto pilot representing the low-level requirements for the auto pilot functionality. In this example, the auto pilot functionality is represented by three different models, the top level model and separate referenced models for the HeadingMode and BasicRollMode calculations.
Figure 2. Roll Axis Autopilot Model – Top Level (Left) and Code Inspection Overview (Right)
32
If the code has been generated previously, it can be retrieved from the configuration management system. Alternatively it can be generated on-the-fly prior to the actual code inspection process. The code inspection results are presented in a hierarchical manner. An overview report provides aggregated status information and links to the detailed results for each model in the hierarchy (Fig. 2, right). The detailed results are divided into two parts, verification report (Fig. 3) and traceability report (Fig. 4). Verification report
Figure 3. Code Inspection Report – Verification Report for the Top-level System
Traceability report
Figure 4. Code Inspection Report – Traceability Report for the Top-level System
The verification report features information about verification of the interfaces of generated code functions, verification of structural equivalence between model and code, and usage of temporary variables. The example in Fig. 3 shows a result for generated code that is structurally equivalent to its corresponding model. Model elements that are outside of the supported language subset and corresponding code fragments would be indicated as „not processed‟ in the verification report. The traceability report documents the code lines that implement a particular model element and the model elements that contributed to the generation of a line of code. The lower part of Fig. 4 shows parts of code-to-model traceability information provided by SLCI.
33
To illustrate the error detection capabilities of Simulink Code Inspector, we‟ll intentionally modify the generated code (i.e. carry out a code mutation) to simulate a bug in the generated code. Then we‟ll carry out a code inspection of the original model against the modified code. This process is illustrated in Fig. 5. The upper left part of the figure shows a lower level of the RollAngleReference subsystem model. The algorithm contains an OR block indicated using red color. The upper right part of Fig. 5 shows the line of code implementing the OR block. To simulate a code generation bug, we create a code mutation that replaces the „||‟ operator with the „&&‟ operator. The lower parts of the figure show a section of the model-to-code verification results for the corresponding model. The report indicates that the matching process was not successful, i.e. Simulink Code Inspector did not find an expected code pattern for the OR block. Code mutation if ((U_Phi >= 6.0) || (U_Phi = 6.0) && (U_Phi = t (select (tasks i) start_time)) (< t (select (tasks i) complete_time)) (> t (select (tasks j) start_time)) (= t (select (messages i) start_time)) (< t (select (messages i) complete_time)) (> t (select (messages j) start_time)) (= (select (message i_write) start_time) (select (tasks send) complete_time))) where send and rec are id’s for the actual sender and
receiver tasks and i is the id for a corresponding message. Assertion 4 (Message Allocation Constraint 1): This assertion guarantees the disjoint access of messages to a shared communication resource, meaning that there is only one message at most which can be transmitted and written into the shared memory simultaneously. We describe this in a formal way as follows: 6|= ∃ t (t ∈ Time) ( mi .start_time ≤ t < mi .complete_time ∧ mj .start_time < t ≤ mj .complete_time ∧ mi 6=
54
Assertion 5 (Message Allocation Constraint 2) We need to distinguish two different cases: In case the sender task tsend and the receiver task trec are allocated to the same computing resource, the complete time is calculated as follows: mi .complete_time = mi .start_time iff: tsend .node = trec .node
In case, sender task tsend and receiver task trec are allocated to different computing resources, the complete time is calculated as follows: mi .complete_time = mi .start_time+ mi .communication_duration iff: tsend .node 6= trec .node
It is specified in YICES input language as follows: (assert (= (select (messages i) complete_time) (if (= (select (tasks send) node) (select (tasks rec) node)) (select (messages i) start_time) (+ (select (messages i) start_time) (select (messages i) communication_duration))))
We can use functions instead of quantifiers when it is necessary. Finally, we specify the given system requirement as a correctness property for the given SMT - based scheduling approach. This is presented in the next section. C. (Correctness) Properties As described in section IV, we specify the global discrete time base as a length | l |. Therefore, we need to define the function min which provides the minimum value and max which provides the maximum value. Using these functions, we are able to calculate the logical tick duration | l |. This is defined in YICES input language as follows: (define duration::(subtype (n::nat) (= n ((max (select (tasks 1) complete_time) (select (tasks 2) complete_time) ... (select (tasks n) complete_time)) (min (select (tasks 1) start_time) (select (tasks 2) start_time) ... (select (tasks n) start_time)) Finally, the check command checks whether the current
logical context is satisfiable or not. If the scheduling problem
is satisfiable using the constraints imposed by the given endto-end system requirement, a solution model is given. VII. I NDUSTRIAL U SE -C ASE In the following we present an automotive use case to demonstrate the usability of the presented approach using a real world example. A. Adaptive Cruise Control (ACC) - System The Adaptive Cruise Control (ACC) is an automotive use case. The ACC automatically adjusts the traveling speed of an automotive vehicle by controlling the acceleration and breaking momentum, based on a driver-defined reference speed, the current speed as well as the distance to a (possibly present) leading vehicle. Figure 4 shows the architecture of the application using AUTO FOCUS 3 , consisting of 5 main components (speed and distance plausibilization; speed- and distance-based control; (de-)acceleration computation). During deployment, these components are mapped to 5 corresponding tasks allocated to 2 cores and connected via an Avalon bus, that is connected to the shared memory (cf. figure 2 in subsection III-B).
values, namely the computation time (computation time) for each task t ∈ T and the expected values for the communication duration (communication duration) of all messages m ∈ M are set. We use the YICES assert command for specifying this: (assert (= (select (task SpeedPlausibilization) computation_time) 10)) ... (assert (= (select (m CurSpeed) communication_duration) 2)) ...
In a next step, we define constraints that are imposed by the precedence graph G. As tasks and messages cannot be scheduled in an arbitrary order, precedence relations are defined by the functions τ and ρ (cf. section II-A) are used to guarantee all precedence relations in G (e.g. τ (tDistanceP lausibilization ) = {mCurSpeed } and ρ(mCurSpeed ) = {tDistanceControl }). Furthermore, we specify the constraints that are imposed by the allocation of tasks to cores η (e.g. η(c0 ) = {tDistanceP lausibilization }). Finally, we specify the given system requirement. As we focus on minimizing the logical tick duration | l | in this paper, we demand for a schedule with a latency of 100 µs using the relation duration (cf. section VI-C). (assert (IN1 + pAdder->IN2; }
Listing 3: Type method of the example ADD block implementation
The fb/functionblock class, which is the base class by every function block implementation, inherits the mentioned scheduling properties from fb/task and extends them by the internal processing method (called typemethod) and an execution time limit. The typemethod is triggered by the execute method either on each computation cycle or conditional to input value changes. In it, the function block programmer implements the block behavior, e.g. a closed-loop controller or a standard IEC 61131 FBD block. The maximal calculation time is adjusted by the engineer in an experimental manner depending on both the FBD complexity and the runtime system configuration. Tasks are not interrupted on an overrun; however a scheduling warning is raised as soon as the runtime exceeds the bound. The execute method of an fb/functionblock instance is summed up as the C-style pseudo code in Listing 2. Returning to the example of an ADD block introduced in Section 2, the OV model from Listing 1 allows to generate a C stub where only the typemethod needs to be extended by the programmer (compare Figure 2). A typemethod for the given example is found in Listing 3. Line 8 is the single line that needs to be inserted into the pre-generated C stub.
4
Case Studies
ACPLT/FB is applied in numerous automation and software development tasks in industrial use e.g. INEOS and research projects shown below. These range from bit-level I/O up to complex software solutions for graphical user interfaces or automation of engineering tasks. We provide a set of highly tested, industrial-grade function blocks that can be used for the basic automation tasks and extended by custom-created ones. In order to illustrate the use of ACPLT/FB, this section contains two use cases as examples. Modular Factory In a current project, a fully automated modular factory is developed at the Chair of Process Control Engineering. This experimental plant consists of three autonomous cells that each implement a production stage (such as mixing and heating liquids) and can be combined to realize a multi-stage production process. Each cell is equipped with devices like pumps, tanks (approx. 20 `) and sensors to control the actual process and with drives that allow for a flexible spatial arrangement according to the pro-
88
duction process. A given recipe can thus be produced by arranging the cells automatically in an appropriate order, which provides much more production flexibility than usual fixedpiped plants. The movement and coupling of the cells is fully automated and controlled by an industrial PC in each cell, while the process control itself is handled by PLCs. These PLCs may be realized in different ways. In fact, some of them are ARM7-based systems, while some are soft-PLCs running on an industrial PC. The implementation of the device control logic is realized by standard function blocks as defined in IEC 61131, which is the current industrial standard. The overall plant is controlled by a central standard PC that serves as engineering station and is connected to each of the industrial PCs in the cells using ACPLT/KS over WLAN. The engineering station allows programming, supervising and controlling the plant; it also stores the production recipes. In this complex scenario, ACPLT/FB is an ideal basis for the implementation, since it allows flexible reprogramming, high-level communication via ACPLT/KS and low-level I/O for the device-control. A further advantage is the portability of the program code that enables using the same framework on different hardware platforms. Due to the intuitive concept of FBDs and their importance in the industrial practice, the modular factory will not only be used in research, but also in student labs to teach modern concepts of recipe-driven production. Plant Simulation A further use-case example is the usage of ACPLT/FB for the simulation of a plant. The process control laboratory at the Chair of Process Control Engineering is equipped with an automated pumping station (which in concept corresponds to a sewage treatment plant, in total 35 sensors and actuators) and process control systems of six major suppliers. Since only one process control system can access the plant at a time, a plant simulation has been implemented to circumvent this bottleneck in student labs. The simulation is running on industrial PCs which can be connected to the process control systems by PROFIBUS in the same way as the I/O of the actual plant. Since the simulation needs to behave in the same way as many devices (pumps, valves and sensors) in parallel, FBD is well suited for the implementation. While the communication with the process control system is realized using ACPLT/FB function blocks, the thermodynamics of the plant was modeled in MATLAB/Simulink. The Simulink model was then integrated by generation of C-code and by calling the code from an ACPLT/FB function block. The plant simulation provides a human-machine-interface (HMI) by offering a web interface. HMIs in the process control domain are strongly dependent on the particular plant that they access or represent and hence need to be highly configurable by the responsible engineer making ACPLT/FB a reasonable choice for a reconfigurable HMI. Therefore, the web interface interacts with function blocks that determine which information has to be displayed and how the simulation acts on user inputs.
5
Summary
Function block diagram is a meaningful programming language in the automation domain which incorporates the traditional understanding of control systems with today’s hard- and
89
software possibilities. Successful implementations not only need to meet basic requirements like safety and real-time behavior, but also possess a carefully designed model. Issues like flexibility on runtime, high-level communication, code portability and a clear development workflow need to be taken into account. While current process control systems cannot afford this, the framework ACPLT/OV, introduced in Section 2, has proven to be a useful basis to meet these challenges in the FBD implementation ACPLT/FB. In Section 3, an introduction to the development of function blocks for ACPLT/FB and its runtime behavior was given. ACPLT/FB has proven stability and usability in various research and industrial projects. Researchers are welcome to expand and apply the framework in their automation projects.
References [AAB+ 07]
G. Aiello, M. Alessi, M. Bruccoleri, C. D’Onofrio, and G. Vella. An Agile methodology for Manufacturing Control Systems development. In Industrial Informatics, 2007 5th IEEE International Conference on, volume 2, pages 817–822, june 2007.
[Alb03]
H. Albrecht. On Meta-Modeling for Communication in Operational Process Control Engineering. VDI Verlag, 2003.
[Epp10]
Ulrich Epple. Graph transformations and model-driven engineering. Chapter Model driven engineering in operative industrial process control environments, pages 749– 765. Springer-Verlag, Berlin, Heidelberg, 2010.
[GSDGF+ 10] V.M. Gonz´alez, A.L. Sierra D´ıaz, P. Garc´ıa Fern´andez, A. Fern´andez Junquera, and R. Mayo Bay´on. MIOOP. An object oriented programming paradigm approach on the IEC 61131 standard. In Emerging Technologies and Factory Automation (ETFA), 2010 IEEE Conference on, pages 1–4, sept. 2010.
90
[IEC03]
IEC (International Electrotechnical Commission). IEC 61131-3, 2nd edition. Programmable controllers – Part 3: Programming languages, March 2003.
[KSY10]
T. Krausser, S. Schmitz, and L. Yu. Regelbasierte Vollst¨andigkeits¨uberpr¨ufung von Automatisierungsl¨osungen. In Kurt D. Bettenhausen, editor, Automation 2010, volume VDI-Berichte 2092, pages 55–58. VDI Wissensforum GmbH, D¨usseldorf, Germany, 2010.
[Mey01]
D. Meyer. Objektverwaltungskonzept f¨ur die operative Prozessleittechnik. VDI Verlag, 2001.
[VHW08]
B. Vogel-Heuser and A. Wannagat. Modulares Engineering und Wiederverwendung mit CoDeSys. Number Bd. 3. Oldenbourg Industrieverlag, 2008.
[Wer09]
B. Werner. Object-oriented extensions for iec 61131-3. Industrial Electronics Magazine, IEEE, 3(4):36–39, dec. 2009.
[WVH09]
D. Witsch and B. Vogel-Heuser. Close integration between UML and IEC 611313: New possibilities through object-oriented extensions. In Emerging Technologies Factory Automation, 2009. ETFA 2009. IEEE Conference on, pages 1–6, sept. 2009.
Darstellungskonzepte für die zustandsabhängige Diagnose industrieller Kommunikationsnetzwerke für verteilte Automatisierungssysteme Dmitry Renzhin, Dorothea Pantförder, Jens Folmer, Birgit Vogel-Heuser Lehrstuhl für Automatisierung und Informationssysteme Technische Universität München Boltzmannstr., 15 85748 Garching bei München {renzhin | pantfoerder | folmer | vogel-heuser}@ais.mw.tum.de
Abstract: Die Diagnose von Feldbussystemen, bzw. industriellen Kommunikationssystemen, ist für verteilte Automatisierungssysteme eine wichtige Grundlage für die Inbetriebnahme, den Betrieb und die Wartung von Anlagen. PROFINET ist ein solches Kommunikationssystem, welches im Vergleich zu Feldbussen früherer Generationen eine erhöhte Flexibilität, Leistungsfähigkeit und Zuverlässigkeit bietet. In diesem Beitrag wird ein Diagnoseansatz beschrieben, bei dem für die Modellierung des Kommunikationsgrundmodells die Automatentheorie zum Einsatz kommt. Hierfür werden lernfähige Automaten durch die passive Analyse des Datenflusses mit dem notwendigen Wissen ausgestattet. Das Wissen wird zusätzlich durch aktive Abfragen der Netzwerkteilnehmer und durch Analyse des anomalen Verhaltens ergänzt. Zur Modelldarstellung dienen gerichtete Graphen und die Methoden der Graphentransformation.
1
Einleitung und Stand der Technik
Die zunehmende Globalisierung stellt steigende Anforderungen an die Automatisierungsanlagen und deren Vernetzungsstrukturen. Die Kürze von Planungs-, Entwicklungs- und Inbetriebnahmezeiten ist zum entscheidenden Qualitätsmerkmal geworden. Dies erfordert einen schnellen und effektiven Umbau einer Produktionsanlage bzw. die Anpassung für die Produktion anderer Güter, mit geringen Stillstandzeiten [Web07]. Die neuen technischen Möglichkeiten tragen dazu bei, dass die Kommunikationssysteme den steigenden Anforderungen gerecht werden, bei jedoch gleichzeitig steigender Komplexität schwer zu analysieren sind [Wel10]. PROFINET [Pop10] stellt solch ein modernes leistungsstarkes Kommunikationssystem dar und gehört zur Familie der Ethernet-Derivate. Im Gegensatz zu den klassischen Feldbussystemen steht bei PROFINET eine physikalische „Punkt-zu-Punkt“ Verbindung der einzelnen Komponenten im Vordergrund. Das führt dazu, dass kein gemeinsam hörbares Medium mehr existiert. Die einzelnen Datenübertragungsstrecken sind durch Switche verbunden. Diese schalten nur die Leitungen zusammen, welche für einen konkreten Übertragungsfall notwendig sind. Solch eine Netzwerkstruktur ermöglicht eine
91
flexible Kommunikation ohne Datenkollisionen, was in modernen und schnellen Netzwerken ausschlaggebend ist. Die Folge einer Unterteilung in kleine und voneinander unabhängige Netzwerksegmente (Punkt-zu-Punkt) ist der Übersichtsverlust auf das Geschehen im gesamten Kommunikationssystem. So findet in einzelnen Teilen der Anlage eine parallele Kommunikation statt. Dies führt dazu, dass nicht genau festgelegt werden kann, in welchem Netzabschnitt sich welches Telegramm gerade befindet. Außerdem werden Telegramme, die zeitgleich an einem Switch von mehreren Kanälen eintreten, zwischengespeichert und erst nacheinander weitergeleitet. Schlimmstenfalls werden sie gar verworfen, falls die Speicherkapazität des Switches erschöpft ist. Das kann zum Überschreiten von Zeitanforderungen führen. Falls obengenannte Probleme in Produktionsanlagen auftreten, sind deren Ursachen nur schwer zu entdecken, wenn dies überhaupt möglich ist. Existierende Werkzeuge lassen das Datenaufkommen an einem Netzwerkpunkt überwachen, was jedoch keine Aussage zulässt wann, wo und warum ein Datenpaket verzögert wurde. Der Entwurf eines Werkzeuges, welches den gesamten Netzverkehr zeitgleich überwachen könnte, ist aus technischen Gründen derzeit nicht möglich [Wel10]. Es existieren Tools, welche die Selbstdiagnosefunktionen einzelner Geräten abfragen und auswerten können. Die Funktionalität wird somit vom Tool auf die Geräte selbst ausgelagert. Dies macht die Diagnosequalität und die Aussagekraft von der Implementierung in dem jeweiligen Gerät abhängig und kann in komplexen verteilten Systemen zum Problem werden. Allein eine automatische Topologie-Ermittlung von IndustrialEthernet Netzwerken stellt eine Herausforderung dar. Die bisher existierenden Werkzeuge basieren meist auf dem Simple Network Management Protokoll (SNMP) [Sta99] oder verlassen sich auf die herstellerabhängige Implementierung vom „Rapid Spanning Tree Protokoll“ (RSTP) [IEEE 802.1D]. Diese Protokolle sind von der Idee sehr stark, aber von der Implementierung einzelner Hersteller abhängig. Somit kann ein einzelnes Gerät, dessen Implementierung nicht korrekt durchgeführt wurde oder ein Gerät der älteren Generation, das die obengenannten Protokolle gar nicht unterstützt, solche Diagnosemethoden deutlich stören. Außerdem hat der Einsatz von nur einem Protokoll einige schwer überwindbaren Schwachstellen. Beispielsweise basiert SNMP auf dem Internet Protokoll (IP) und kann deshalb nur innerhalb eines vorgegebenen IP-Bereiches eingesetzt werden. Das RSTP setzt eine „streng“ sternförmige Netzwerktopologie voraus, mit RSTPfähigen Switches als Sternzentren, was in Anlagennetzwerken nicht immer der Fall ist.
2
Topologie-Ermittlung
Für die Ermittlung der Netzwerktopologie können verschiedene Ansätze angewendet werden, um Interpretationen und Unvollständigkeiten der Implementierung von Industrial-Ethernet-Spezifikationen zu umgehen. Mittels SNMP und des Link Layer Discovery Protokoll (LLDP) kann die Netzwerkstruktur ausgelesen und ein vorläufiges Netzwerkmodell erstellt werden. Da SNMP nicht immer vollständig nach Spezifikation implementiert ist, sollen prozesstechnische Meldungen sowie ein Mitschnitt des Datenflusses in die Auswertung aufgenommen werden, um aussagekräftige Zusammenhänge mittels Fehlerklassifikation für die Diagnose zu ermitteln. Durch die Auswertung des Datenflussmittschnitts werden miteinander kommunizierende Geräte ermittelt und durch ganzheitliche Betrachtung der Nachbarschaftskommunikation, die Topologie durch eine Art Netzwerkautomat sukzessive aufgestellt. Jeder Teilnehmer wird hierbei als ein Gerätezustand im Netzwerkautomaten definiert. Die Übergangstransitionen stellen die Kommu-
92
nikationsbeziehungen zwischen den Teilnehmern dar. Ganzheitlich wird vorerst ein statischer Netzwerkautomat definiert, der durch Analyse des Datentransfers (vgl. Kapitel 2.1) zu einem dynamischen Netzwerkautomaten verfeinert wird. Zugrundeliegend ist hierbei die Annahme, dass jedes gesendete Datenpaket einen Zustand des Netzwerkteilnehmers definiert. Resultierend wird somit der im ersten Schritt erstellte Gerätezustand mit jedem unterschiedlichen Datenpaket durch mehrere Gerätezustände erweitert und die Übergangstransitionen durch Analyse (vgl. Kapitel 2.1) verfeinert, um Kommunikationszusammenhänge zwischen Netzwerkteilnehmer zu erkennen. Abbildung 1 zeigt die grundlegend wie die die automatische Topologie-Ermittlung angewendet wird. So werden z.B. mittels LLDP die Nachbarschaftsinformationen zwischen zwei unmittelbar miteinander vernetzten Geräten ausgetauscht. Die meisten Geräte haben mehr als einen Ethernet-Port. Diese Geräte verfügen über interne MAC-Bridges. In diesem Fall besitzt jedes Gerät ein internes Interface-MAC und jeweils ein Port-MAC für jeden physikalisch vorhandenen Ethernet-Port [IEEE 802.1D]. Gerät 1
ROM
Gerät N
µController
RAM
µController
ROM
Interface
MAC
Port 2
MAC
MAC
MAC
...
Bridge Port 1
RAM
Interface
...
Bridge
Port N
Port 1
Port 2
MAC
MAC
MAC
Abbildung 1: Schematische Aufbau der Automatisierungsgeräte
Die Interface-MAC wird für die allgemeine Geräteidentifikation benutzt, und ist in jedem üblichen Ethernet-Frame vorhanden. Jeder Netzwerkteilnehmer nutzt für den Informationsaustausch die Interface-MAC, die oft als MAC-Adresse bezeichnet wird. Die Port-MAC hingegen wird nur in speziellen Fällen genutzt und dient der Portidentifikation. Wenn ein Gerät registriert, dass an einem seiner Ports ein anderes Gerät angeschlossen ist, werden die LLDP-Telegramme, die die Port-MAC beinhalten, aus diesem Port gesendet. Das zweite Gerät empfängt diese und speichert die Interface-MAC des ersten Gerätes und den angeschlossenen Port. Die LLDP-Telegramme werden nur zwischen direkt angeschlossenen Ports ausgetauscht und im Regelfall nicht weitergeleitet. Auf diese Weise erfährt jedes Gerät wer seine Nachbarn sind und wo sie sich befinden. Die Nachbarschaftsinformationen werden in dem Gerät gespeichert und können mittels SNPM ausgelesen werden. Mittels eines PROFINET.DCP.Identify.request können alle PROFINET fähigen Geräte erfasst werden. Dabei können Informationen wie Gerätename, IP-Adresse und MACAdresse ermittelt werden [PN10]. Der Status von Geräten (vorhanden/nicht vorhanden) kann auch mittels ICMP.Echo.requests (ping) erfolgen. In diesem Fall werden die IPAdressen abgefragt und geprüft ob diese schon einem Gerät zugewiesen sind. 2.1
Erweiterungen des statischen Netzwerkautomaten durch Anomalie Detektion
Basierend auf den statischen Netzwerkautomaten soll durch Abhören der Kommunikationsteilnehmer und der Feldbusstränge der Datentransfer für Diagnosezwecke mittels Anomalie Detektion über das gesamte Netzwerk analysiert werden um sowohl Fehler eines Netzwerkteilnehmers zu diagnostizieren als auch voneinander abhängige Ursache-
93
Wirk-Zusammenhänge zu erkennen. Grundsätzlich basiert die Anomalie Detektion auf der Analyse von diskreten Ereignissen, um bspw. Hacker-Angriffe und Systemfehler durch den Vergleich von Sequenzen und durch Berechnung von Unregelmäßigkeiten in den Sequenzen zu entdecken. Diskrete Ereignisse sind in diesem Fall die durch die Netzwerkteilnehmer übertragenen Datenpakete über den Feldbus, die im Rahmen dieser Arbeiten den statischen Gerätezustand erweitern. Der Gerätezustand wird durch jedes gleichartige Datenpaket (gleicher Nachrichtentyp) eines Teilnehmers erweitert. Daraus resultiert eine Verfeinerung eines Netzwerkteilnehmer-Gerätezustands durch mehrere Gerätezustände. Die Übergangstransitionen zwischen den Gerätezuständen stellen zum einen die ordnungsgemäße Kommunikation zwischen den Netzwerkteilnehmern dar (Topologie) und zum anderen die Ursache-Wirk-Relationen von Fehlern (Diagnose), sowohl eines Netzwerkteilnehmers, als auch zwischen Netzwerkteilnehmern, die mittels Anomalie Detektion analysiert worden sind. Für die Analyse sind verschiedene Anomalie Detektionstechniken einsetzbar, die alle auf der statistischen Berechnung eines „Anomalie-Scores“ zurückzuführen sind, der einen signifikanten Unterschied von Unregelmäßigkeiten von Sequenzen, im Vergleich zu Normalsequenzen ausdrückt. Die drei grundlegenden Ansätze, die in detaillierte Techniken aufgeschlüsselt werden können, sind [CBK+10, CMK08]: Sequenzbasierte Anomalie Detektion (Subsequence based anomaly detection), Zusammenhängende Untersequenz-basierende Anomalie Detektion (Congiguous subsequence based anomaly detection) und Muster-Häufigkeit basierende Anomalie Detekion (Pattern frequency based anomaly detection) In dem hier beschriebenen Ansatz wird das Verfahren der Anomalie Detektion gewählt, um den Datentransfer zu analysieren und, unter Rücksichtnahme der hierarchischen Sicht, ausgewertet. Erfolgsversprechend ist eine Kombination aus „Windows Based“ Anomalie Techniken – diese sind Teil von den sequenzbasierten Anomalie Detektion Techniken – und der „Pattern Frequency Based“ Anomalie Techniken. Charakteristisch ist hierbei die mehrstufige Analyse. Zuerst werden durch die „Window Based“ Technik Datenpakete derart analysiert, dass ein Zeitfenster, das eine endliche Anzahl von Datenpaketen umschließt, mit maximalen „Anomalie-Score“ berechnet wird. Innerhalb dieser Zeitfenster kann darauf folgend mit „Pattern Frequency Based“ Anomalie Techniken nach Fehlermustern gesucht werden, um Fehlersequenzen zu finden. Die daraus berechneten Regeln, die den Zusammenhang von Datenpaketen, können zur Erstellung des dynamischen Netzwerkautomaten herangezogen werden, der das zusammenhängende Signal-Verhalten von Netzwerkteilnehmern darstellt. Dieser kann z.B. in Visualisierungen von Netzwerken integriert werden, um zum einen Problemursachen im Netzwerk darzustellen, als auch das Fehlverhalten von Netzwerkteilnehmer zu prognostizieren.
3
Darstellungskonzepte
Eine große Herausforderung stellt die Darstellung komplexer Netzwerkarchitekturen und deren Informationsflüsse dar. Um die Übersicht der gesamten Anlage zu behalten muss diese auf einem Bildschirm sichtbar sein, ohne in eine höhere Abstraktionsebene zu wechseln. Zudem muss sie den verschiedenen Anforderungen des Wartungs/Inbetriebnahmeingenieurs entsprechen und je nach Diagnose-Situation adaptierbar sein. Im Folgenden werden Darstellungskonzepte vorgestellt, die die unterschiedlichen Anforderungen bei der Diagnose unterstützen können und mittels Graphentransformation
94
ineinander überführt werden können. Die Idee ist, dass der Benutzer zwischen den verschiedenen Darstellungen mit wenigen Maus-Clicks umschalten kann, und somit durch die Anlage navigieren, bzw. nach Störungsursachen suchen kann. Jedes Darstellungskonzept stellt jeweils eine für den Anwender spezifische Sicht auf das Netzwerk und Störungen dar mit den für die Sicht wichtigen Informationen. Beim Darstellungswechsel werden dementsprechend andere Informationen und Zusammenhänge dargestellt. Um ein ganzheitliches Informationskonzept zu gewährleisten und um eine automatisierte Netzwerkanalyse zu realisieren, müssen demnach alle Graphen (Darstellungen) bidirektional transformiert werden können. Die einzelnen Darstellungskonzepte werden am Beispiel einer Demonstratoranlage des Lehrstuhls AIS, dem hybriden Prozessmodell, erläutert. Diese Anlage verfügt über 32 Servoantriebe und darüber hinaus über zwei weitere Stellantriebe, einen Roboter und 12 Barcodescanner die über Industrial-Ethernet an die Steuerungsebene angebunden sind. Nichtintelligente Sensoren/Aktoren (wie Lichtschranken und Hydraulikventile) werden mittels dezentraler E/A-Module an die Steuerungen gekoppelt. Die dezentralen E/AModule kommunizieren mit drei Steuerungen, und sind untereinander und mit den überlagerten Operator- bzw. Engineering-Stationen verbunden. Zum Bedienen und Beobachten stehen drei Touchpanels zur Verfügung, die in das Ethernet-Netzwerk eingebunden sind (Siehe Abbildung 2). 3.1
Strukturelle Sicht
Die strukturelle Sicht (Abbildung 2) dient der Darstellung der allgemeinen Anlagenstruktur. Die Übersicht über die gesamte Anlage oder deren Teilkomponenten soll mit einem Blick überschaubar sein.
Abbildung 2: Strukturelle Sicht
Dies erfordert eine Art der Abstraktion, die durch Gruppierungen der einzelnen Komponenten in für konkreten Anwendungsfall relevanten Einheiten erreicht wird. So sind alle Servomotoren der Beispielsanlage in zwei Gruppen, alle Barcodescanner in einer Gruppe, Motoren und Remote I/Os in mehreren Gruppen gruppiert worden. Die Gruppierung kann entweder manuell oder halb-automatisch erfolgen, in dem die im Diagnose-Tool automatisch ermittelte Geräte auf die jeweiligen Plätze mit der Maus verschoben wer-
95
den. Die einzelnen Gruppen werden anschließend per Hand auf die „richtigen“ Plätze gezogen. Es besteht die Möglichkeit, den Gruppen oder einzelnen Komponenten die Bilder und Namen zu zuweisen. 3.2
Geografische Sicht
Abbildung 3: Geografische Sicht
Abbildung 3 zeigt die geografische Netzwerksystemsicht. Die Automatisierungskomponenten mit Netzwerkanschluss so wie die Geräte der Netzwerkinfrastruktur sind als gefärbte Rechtecke dargestellt. In den Rechtecken sind die IP-Adressen des jeweiligen Gerätes eingeblendet. Durch verschiedene Farben, sind die Geräterollen sowie Zustandsinformationen im Ampelprinzip dargestellt. Der grüne Zustand signalisiert, dass das Gerät einwandfrei funktioniert, gelb bedeutet, dass eine Warnung vorliegt und rot signalisiert ein Fehler. Die Geräte mit Sicherheitsfunktionen (unten in Abb. 3) sind mit einem gelbroten Rand versehen. Die Rechtecke, die Netzwerkkomponenten wie Switche darstellen, haben einen schwarzen Rand und sind im fehlerfreien Zustand blau gefärbt. In sonstigen Zuständen sind die Füllfarben wie vorher beschrieben Rot oder Gelb. Die jeweiligen Geräte sind in dieser Darstellungsform so eingeordnet, wie sie in der Anlage tatsächlich verbaut sind. Die Anordnung kann, wie in der Strukturellen Sicht, manuell erfolgen oder halb-automatisch. Abbildung 4 rechts stellt die physikalische Vernetzung der Automatisierungsgeräte dar. Die Netzwerktopologie wurde nun in einen anderen Graphen überführt. Dieser zeigt alle Netzwerkteilnehmer mit ihren physikalischen Verbindungen. Da der Datenfluss bei den meisten Netzwerken bidirektional erfolgt, ist der Graph nicht gerichtet. Die einzelnen Verbindungen (Kanten des Graphen) können gewichtet werden. Die Gewichtung kann z.B. die Netzwerkauslastung der einzelnen Verbindungen repräsentieren. Mit den einzelnen Elementen, bzw. Geräten, können dazugehörige Metainformationen, wie Gerätenamen, IP-Adressen, Fehlerquote, Bestellnummern usw. verbunden werden. Das Beispiel in Abbildung 4 links zeigt die automatische Gerätegruppierung anhand der Namenspezifikation.
96
Abbildung 4: Überleitung von geografischer in die physikalische Vernetzung
3.3
Hyperbolic Tree
Der „Hyperbolic Tree“ ist ein nicht gerichteter Graph und kann aus den, bereits für die vorhergehende Darstellung, bereitstehenden Daten gebildet werden. Er eignet sich besonders um große vernetze Strukturen darzustellen und ermöglicht die Navigation durch große Datenmengen [Mun98].
Abbildung 5: Farbiger Hyperbolic Tree
Die baumkronenartige Struktur breitet sich vom Mittelpunkt sternförmig aus. In Abbildung 5 steht beispielsweise der Name eines Diagnose-Tools „TH-LINK“ [TH11]. Davon ausgehend sind die einzelnen Automatisierungsgeräte und Netzwerkkomponenten kreisförmig angeordnet. Von den jeweiligen Netzwerkkomponenten, bzw. Geräten, spreizen sich die jeweils weiteren – mit ihnen verbundenen – Geräte/Komponenten in hierarchischer Ordnung ab, wobei die äußere Form des gesamten „Trees“ in einem Kreis oder Oval endet. Die gesamte Netzwerkhierarchie bzw. Automatisierungsanlage kann auf einen Blick erfasst und bei Bedarf interessante Bereiche in den Mittelpunkt gezogen werden um detaillierte Informationen für einen bestimmten Bereich zu erlangen. Für die Diagnoseunterstützung wird der Hyperbolic Tree um Zustandsinformationen erweitert. Zu den als farbige Rechtecke dargestellten Geräten werden nun noch farbig gekennzeichnete Zustände der einzelnen Verbindungen hinzugefügt.
97
Mit diesen zusätzlichen Informationen kann man mögliche Fehlerkausalitäten nachvollziehen, bspw. ist die Verbindung zwischen dem Gerät 14.80.0.129 und dem Gerät 14.80.0.28 unterbrochen (siehe Abbildung 5). Dies ist die Fehlerursache für den Ausfall des Gerätes 14.80.0.28 und des dahinterliegenden 14.80.0.29. Das Gerät 14.80.0.129 ist im Warnzustand. Die mögliche Warnung wäre der Ausfall eines seiner Ports. 3.4
Hierarchische Sicht
Eine weitere Möglichkeit für die Darstellung der Netzwerkarchitekturen sind hierarchische Layouts. Das hierarchische Layout zielt darauf ab, den Datenfluss in einem Graphen zu markieren. Die Knoten des Graphen platzieren sich in hierarchisch angeordneten Schichten, sodass die Mehrheit der Verbindungen die gleiche allgemeine Ausrichtung zeigt, z.B. von oben nach unten [Ywo11]. Darüber hinaus werden die Knoten innerhalb jeder Schicht in einer solchen Weise eingeordnet, dass die Zahl der Kantenkreuzungen möglichst klein bleibt. Diese Darstellungsart eignet sich auch für redundante Topologien.
Abbildung 6: Grafische Beispieldarstellung einer analytischen Netzwerkmodells
Abbildung 6 zeigt die hierarchische Sicht mit zusätzlichen Metainformationen. Die Netzwerkteilnehmer sind, wie zuvor, als farbige Rechtecke dargestellt. Zusätzlich wird zwischen einem Device (oder Slave) und einem Controller (ggf. Master) unterschieden. Die Controller-Rechtecke haben eine dicke grüne Umrandung, andere Geräte sind dünn blau umrandet. Die Switche und ähnliche Netzwerkkomponenten haben einen schwarzen Rand. Im Zentrum jedes Rechtecks steht der Gerätename oder die IP-Adresse (die Einstellung wird durch den Benutzer gewählt). Die Kanten sind Flussgerichtet und können somit physikalische Voll-Duplex-Verbindungen darstellen. Die Netzwerklast zwischen einzelnen Knoten wird durch die Kantenstärke hervorgehoben. Zusätzlich zu den farbigen Zustandsinformationen (Rot/Grün/Orange) werden zwei Symbole: „oranges Ausrufezeichen“ für vorliegende Warnung und „rotes Kreuz“ für ein Fehler eingeführt. Redundante Pfade sind mit der gestrichelten Linie dargestellt. Diese sollen die Navigation durch komplexe Strukturen mit verschiedenen Zoom-Optionen erleichtern. Zusätzliche Metainformationen, wie z.B. „Redundance Manager“ (RM), „application relation“(ar) mit einem Controller, Safety-relevante Informationen usw. werden als klei-
98
ne lila ggf. gelb-schwarze Rechtecke. Die von Netzwerkteilnehmer abgehenden lila Pfeile, weisen auf die Zugehörigkeit des Metablocks zu einem Netzwerkknoten hin. Die Informationen für dieses Netzwerkmodell können zum Teil durch Abhören der Controllerkommunikation mittels Portspiegelung in einem Switch gewonnen werden. Der andere Teil kann durch direkte Abfragen eines Devices (z. B. PDev-Daten [PN10] oder SNMP) ermittelt werden. So kann man unsymmetrische Belastung der Verbindungen identifizieren. Wie in Abbildung 6 zu sehen ist, ist der Datenfluss in eine Richtung deutlich größer als in die Andere. Mögliche Ursache für die Warnung wäre die Überlastung dieser Teilstrecke. Anhand des Bildes kann man mit bloßem Auge erkennen, dass der integrierte Switch im Gerät D5 funktionsfähig ist, aber das Gerät reagiert auf die Aufrufe des Controllers C2 nicht. Es ist auch zu erkennen, dass die Verbindung D1-D5-D7-D6D4-D2 nur im halb-duplex Modus funktioniert und das zweite Kabel für die Redundanz reserviert wurde. Das Datenmodell kann auch manuell vervollständigt werden. So können z.B. die festgeplanten Redundanzen oder bevorzugte Datenwege markiert oder gezeichnet werden. 3.5
3D-Sicht
Die manuelle Diagnose von Netzwerkmeldungen im Fehlerfall stellt sich, durch die Flut an Daten die in einem Netzwerk entstehen, als schwierig und zeitaufwändig dar. Um den Bediener im Fehlerfall zu unterstützen soll mittels der gewonnen kausalen Zusammenhänge die eigentliche Ursache in einer 3D-Visualisierung dargestellt werden (vgl. dazu [FPV11]).
Abbildung 7: 3D-Sicht basierend auf der Anlagenstruktur
Andere Forschungsarbeiten haben bereits gezeigt, dass eine solche 3D-Visualisierung, im Gegensatz zu den üblichen 2D-Visualisierungen, Vorteile für die Prozessführung darstellen. Beuthel [Beu97] und Hoppe et al. [HEW+04] zeigten diese Vorteile der 3DProzessdatenvisualisierung bei Kohle-Kraftwerken und Stromnetzen indem sie mithilfe von 3D-Elemente (z. B. Balkendiagramme) räumlich auf einem 2D-Strukturdiagramm (CAD, P & ID), Istwerte des Prozesses anzeigten. Bei beiden Studien konnten Vorteile bei der Reaktionszeit und der Bearbeitungszeit bei Probanden während des Handlings von Problemsituationen gezeigt werden.
99
Im Rahmen der in diesem Beitrag vorgestellten Arbeiten sollen die logischen und physikalischen Netzwerkstrukturen automatisch durch den oben beschriebenen Ansatz in 3D erstellt werden. Durch eine 3D-Darstellung, aufbauend auf die Anlagenstruktur, sollen problematische Netzwerkteilnehmer örtlich kenntlich gemacht werden. Die Darstellung soll je nach Diagnosesituation auf Knopfdruck in verschiede Formen umwandelbar sein. Es soll ebenfalls gewährleistet werden, dass in die unterschiedlichen Sichten (logische Struktur, hierarchische Struktur und Anlagenstruktur) umgeschaltet werden kann.
4
Zusammenfassung
Die gezeigten Darstellungskonzepte erlauben dem Nutzer eine einfache Navigation durch komplexe Netzwerkstrukturen. Jede Darstellung ist für spezifische Zwecke aufgebaut. Dies ermöglicht eine schnelle Einschätzung des Netzwerkzustandes, eine erleichterte Suche nach Fehlerursachen und die Hervorhebung der gewünschten Diagnosebzw. Prozessdaten. Das Zustandsautomaten-Modell, kann sowohl für die analytische Analyse verwendet werden, als auch zur Prognose von Fehlerverhalten der Netzwerkteilnehmer im Kontext der Netzwerktopologie. So können kausale Fehlerfolgen vollautomatisch erhoben werden und die Fehlerursachen an den Benutzer gemeldet werden.
Literaturverzeichnis [Beu97]
[CBK+10] [CMK08]
[FPV11]
[HEW+04]
[Mun98] [PN10] [Pop10] [Sta99] [TH11] [Web07] [Wel10] [Ywo11]
100
Beuthel, C.: Dreidimensionale Prozessvisualisierung zum Führen technischer Anlagen am Beispiel eines Kohlekraftwerkes. Dissertation der Universität Clausthal. Papierflieger Verlag, Clausthal-Zellerfeld, 1997. Chandola, V.; Banerjee, A.; Kumar, V.: Anomaly Detection for Discrete Sequences: A Survey. In: IEEE Transactions on Knowledge and Data Engineering, 2010. Chandola, V.; Mithal, V.; Kumar, V.: Comparative Evaluation of Anomaly Detection Techniques for Sequence Data. In: Proc. 8th IEEE Int Conf.erence on Data Mining (ICDM '08), pp.743-748, 2008. Folmer, J.; Pantförder, D; Vogel-Heuser, B.: An analytical alarm flood reduction to reduce operator's workload. In: 14th International Conference on Human-Computer Interaction (HCI International), pp. 297-306, 2011. Hoppe, S.M.; Essenberg, G.R.; Wiegmann, D.A., Overbye, T.J.: Three-dimensional displays as an effective visualization technique for power systems monitoring and control. Technical Report. Universität Illinois US, 2004. Munzner, T., Exploring large graphs in 3D hyperbolic space, IEEE Computer Graphics and Applications, vol. 18, no. 4, pp. 18–23, 1998. Specification PROFINET. PN-AL-protocol_2722_d23_Mar10.pdf, PN-ALservices_2712_d23_Mar10 Popp, M., Das PROFINET-IO-Buch: Grundlagen und Tipps für den erfolgreichen Einsatz, 2nd ed. Berlin: VDE-Verl, 2010. Stallings, W., SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Reading, Mass. Addison-Wesley, 1999 Trebing und Himmstedt, http://www.t-h.de/de/industrial-communication/ produkte/th-link.html, Stand 01.11.2011 Weber, M. A., Unterstützung der Wandlungsfähigkeit von Produktionsanlagen durch innovative Softwaresysteme. Dissertation 2007. ISBN: 3875252691 Welter, J., Diagnosesystem für Industrial Ethernet Netzwerke, 2010. Dissertation. ISBN: 3868442928 http://www.yworks.com/en/index.html, Stand 28.11.2011
Modelling Technical Constraints and Preconditions for Alternative Design Decisions ∗ Alexander Pacholik, Matthias Riebisch Ilmenau University Technology {matthias.riebisch | alexander.pacholik}@tu-ilmenau.de
Abstract: For architectural design decisions, a high number of goals and constraints has to be considered. For a proper management of their complexity and as a precondition for tool support, they have to be modeled explicitly. Existing approaches fail to provide a predictable, rigor decision-making as well as a to deal with incomplete or even partly contradicting information. This paper presents an approach for an explicit modeling of constraints for architectural reasoning and of preconditions for existing solutions based on the concept of technical terms. The preconditions are modeled within the Goal Solution Scheme, and are combined with information about the impact of existing solutions on quality goals.
1
Introduction
Development and evolution of software systems are highly complex tasks that have to be performed with a high efficiency. Particularly, design decisions are complex because a high number of requirements and constraints have to be considered [HKN+ 07], with some of them being conflicting, vague or even undefined. Wrong decisions lead to high effort for revision. Furthermore, the utilization of solutions instruments – such as architectural patters, styles, frameworks, and evolution patterns in form of refactorings – is important for the efficiency of the development process, and for the quality of the resulting design. Many of them demand for preconditions for applicability, for example the provision of a platform, or the availability of a service. These preconditions have to be considered in design decisions as well. Most of them are of a technical nature. Embedded systems have to meet even more kinds of constraints than other systems, for example regarding platform, energy consumption, and cost [Kop08]. Different kinds of goals, requirements, and constraints have been considered by design methodologies. While functional ones are obviously in the focus of customers, newer architectural design approaches concentrate on quality goals when selecting existing solution instruments, for example the Goal Solution Scheme (GSS) [BR10] explained in section 3. However, the consideration of constraints and preconditions is not yet sufficiently solved for complex design situations, as they are typical for embedded system design. ∗ This research has been partly funded by the federal state Thuringia and the European Regional Development Fund ERDF through the Th¨uringer Aufbaubank under grant 2007 FE 9041 and under grant 2010 FE 9094.
101
The contribution of this paper consists in an explicit representation and evaluation of constraints and preconditions for the selection of existing solution instruments in order to support decision-making and problem-solving during design. The new concept extends the goal-oriented decision-making approach of the GSS. The formalization is achieved by using technical terms as references, and a set of operators to evaluate the satisfaction of constraints and preconditions. The evaluation can be performed by tools, thus reducing the complexity and error-proneness of decision-making.
2
Related Work
As a source of solution instruments, patterns and styles [HA07] are used. The architect’s set of solution instruments is frequently collected in form of a toolbox, thus representing a knowledge base of design knowledge. A toolbox should contain a catalogue of approved methods and solution templates (e.g. patterns and tactics [BKB02]), as well as a catalogue of fundamental technologies and tools (e.g. frameworks). For a goal-oriented way of selecting solution elements, the impact of the toolbox elements on quality properties is required as a decision criterion. Usually, pattern catalogues (e.g. [BMR+ 96, GHJV94]) provide descriptions for context, problem, and solution. The context part covers some of the needed information on preconditions. However, an impact on quality properties of the resulting architecture is not provided as a decision criterion. Influences on quality properties are considered as impact relations by our prior works [BR10]. Design constraints restricting the design or the solution space are described by [TvV09]. However, the relation between constraints and requirements as well as the modelling of preconditions for solution instruments requires for further elaboration. Modelling restrictions can be expressed by the Object Constraint Language (OCL) [LO03]. For the definition of preconditions and constraints, ontologies are applied as means of description [BL10]. The need for a firm set of relationships, however, contradicts to the open character of an ontology but is required for evaluation. The concept of technical terms [TNAKN11] constitutes another candidate for defining preconditions and constraints.
3
Design Decision Procedure with the Goal Solution Scheme
For design decisions regarding reusable solution instruments, goals and constraints have to be fulfilled, and applicable solution instruments have to be identified. A set of solutions instruments is usually collected by architects and is therefore referred to as architect’s toolbox. Such a toolbox may cover architectural patters, styles, frameworks, evolution patterns in form of refactorings, and even heuristics and design principles. Design decisions regarding the selection of solution instruments demand for a mapping of the goals and constraints – which are part of the problem space – onto solution instruments – which are part of the solution space – along with the impact of solution instruments on quality goals and preconditions for applicability. Recently, the Goal Solution Scheme (GSS) [BR10] was developed to represent this mapping between problem and solution space regarding
102
quality goals. In the GSS, this mapping is represented explicitly by impact relationships between solution instruments and quality goals. Different layers have been introduced (see Figure 1) to reduce the gap between goals and solution instruments by goal refinement. The GSS achieves a further reduction of the gap by introducing design principles (layer III) to represent the impact relationships independently of concrete circumstances of a project. An evaluation of the applicability of solution instruments stored in the toolbox can be performed, if the constraints for a specific design decision are compared with the preconditions of the solution instruments. This evaluation is the first part in the decision making chain, which is typically embedded into the incremental design process according to the specific conditions of a software project.
Figure 1: Layers of the Extended Goal Solution Scheme
Figure 2: Decision Procedure with Two Selection Steps
Figure 2 depicts the general procedure of selecting solution instruments as candidate solutions within one design cycle. The preselection is performed as the first step, which which enables the reduction of the set of solution instruments to the applicable ones. Its input is acquired by analysing constraints stemming from the existing design and constraints defined by requirements. Missing information is collected interactively from the designer. To perform the preselection, constraints are compared to the preconditions of solution instruments. In the second step, the preselected solution instruments are ranked according to their impact on the desired quality goals, in order to propose the most suitable solutions to the architect. This two-step selection procedure is supported by the open source tool QUARC as a part of the EMFTrace suite [EMF].
4
Constraints, Preconditions and Technical Properties
For the second step, impact relationships are sufficiently covered by the concepts of the GSS. However, constraints and preconditions and thus, restrictions and interdependencies between solution instruments demand for an explicit representation to enable the preselection as the first step. This representation is required to manage the complexity of decisionmaking, and to provide a foundation for method and tool support of this preselection step.
103
In this paper we focus on design constraints regarding technology and resource aspects, and their influence on architectural design decisions as restrictions of the solution space. A constraint constitutes a restriction which must be satisfied by a viable design solution. Preconditions express requirements for the applicability of a solution instrument in terms of e.g. expected services, platforms, resources or standards. Furthermore, preconditions can be used to express interdependencies between the application of solution instruments, e.g. caused by a conflict in resource consumption. The evaluation of preconditions and constraints in the preselection step described above requires an assessment of the compliance with information on the current and future design that we refer to as technical properties. The concept of technical properties provides a common foundation for both preconditions and constraints and expresses are used to express the properties provided by a solution instrument, e.g. provided interfaces, services, features definitions, and resources that can satisfy the preconditions of other solution instruments. Each technical property is bound to a technical term. Compared to the GSS, the technical terms constitute a semantic layer, which contains facts used for evaluating restrictions and interdependencies within the solution space. Technical terms are semantically defined in the solution space or in the application domain, in order to enable reasoning about the design. A technical term is composed of a unique identifier and type information. The actual value is contained an associated technical property object, as depicted in in Figure 3. The technical property is an OCL LiteralExpression as will be explained in Section 5, and contains the desired value for the technical term. A precondition refers to one or multiple technical term and contains instructions for their further evaluation. Not until evaluation, the associated technical properties are accessed.
Figure 3: Implementation of Technical Terms and Technical Properties
5
Formalization of Constraints and Preconditions
For the definition of constraints and preconditions, the Object Constraint Language (OCL) is used, because the OCL is widely accepted as an industrial standard, and it is supported by various tools. The OCL is by concept a declarative, side effect free language. Technical properties are defined as OCL literal expressions, which when evaluated, return a primary data type, such as Boolean, Integer, Real, String or a Collection data type. For the definition of constraints and preconditions we use the set of OCL’s pre-defined operations for these standard types, such as boolean operators, arithmetic operators, comparators, and collection operators. The operators can be used to evaluate the technical properties and to build complex OCL expressions for constraints and preconditions, whose evaluation results in a Boolean type. The mapping from technical terms of the GSS to OCL
104
expressions is depicted in Figure 3. The technical property itself is an OCL literal expression, which can be accessed by an OCL constraint expression using the technical term as a reference object, which already contains the type information. Figure 4 shows example preconditions between solution instruments on the left side and technical terms, written in curled braces, on the right side. Constraints are structurally visualized by a dotted arrow with the constraint annotated in curled braces. The OCL text is omitted for pure required dependencies. Figure 4 contains four example preconditions for solution instruments with references to technical terms of different types.
Figure 4: Examples for Technical Terms and Constraints
The first precondition denotes that the Thread Pool solution instrument can only be selected, if a Thread Management service is available. This precondition refers to the technical term Thread Management, representing a service requirement. It is evaluated using a boolean operator: If there is a property provider for the Thread Management capability – either in the current design or in a candidate for solution instrument – the precondition evaluates to true. The second precondition expresses that the ASIC solution instrument requires a production volume of at least 1 million number of units. The technical term #units refers to a technical property of type integer. In general, such numeric properties are well suited to describe resource requirements, e.g. for computing or memory. The third precondition example for the FPGA solution instrument states, that the ”Xilinx ISE” development environment constitutes a supported target for model-based code generation for FPGAs. It references the technical term Targets. To enable sets of requirements, a technical property with the type collection is applied. The OCL collection operator includes is used to express the condition. The evaluation of the technical property returns a collection of supported targets. OCL Collection types and operators can be used to model provided capabilities and characteristics. A fourth precondition expresses a mutually exclusive selection between the solution instruments ASIC and FPGA, visualized by the shaded box, containing the {xor} keyword.
6
Conclusion and Future Work
The presented approach provides an explicit modelling of complex preconditions and constraints that have to be considered during design decision on architectural level. These preconditions and constraints are expressed by references to so-called technical properties, which are evaluated by expressions. The technical properties refer to the concept of
105
technical terms, which have been introduced to provide the semantic definition. Technical properties, technical terms and expressions are formally defined using the OCL. Future works based on the approach include the extension to implementation constraints, to cover decisions regarding code evolution and reengineering. For a semantic definition of the technical terms, ontologies are a potential concept that has to be investigated. Using this concept, references between terms can be expressed by ontology relations.
References [BKB02]
L. J. Bass, M. Klein, and F. Bachmann. Quality Attribute Design Primitives and the Attribute Driven Design Method. In Revised Papers from the 4th International Workshop on Software Product-Family Engineering, pages 169–186. Springer, 2002.
[BL10]
M. Bennicke and C. Lewerentz. Towards Managing Software Architectures with Ontologies. In G. Engels, C. Lewerentz, W. Sch¨afer, A. Sch¨urr, and B. Westfechtel, editors, Graph transformations and model-driven engineering, pages 274–308. Springer, 2010.
[BMR+ 96]
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1 edition, July 1996.
[BR10]
S. Bode and M. Riebisch. Impact Evaluation for Quality-Oriented Architectural Decisions regarding Evolvability. In M. Babar and I. Gorton, editors, Proc. 4th European Conference on Software Architecture, ECSA 2010, pages 182–197. Springer, 2010.
[EMF]
EMFTrace repository suite. https://pix.theoinf.tu-ilmenau.de/trac/EMFTrace/.
[GHJV94]
E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Softwaresystemen. Addison-Wesley Professional, 1994.
[HA07]
N. Harrison and P. Avgeriou. Pattern-Driven Architectural Partitioning: Balancing Functional and Non-functional Requirements. In Second International Conference on Digital Telecommunications, 2007 (ICDT ’07), pages 21–26. IEEE, July 2007.
[HKN+ 07]
C. Hofmeister, P.e Kruchten, R. L. Nord, H. Obbink, A. Ran, and P. America. A general model of software architecture design derived from five industrial approaches. Journal of Systems and Software, 80(1):106–126, January 2007.
[Kop08]
H. Kopetz. The Complexity Challenge in Embedded System Design. In Object Oriented Real-Time Distributed Computing (ISORC), 2008 11th IEEE International Symposium on, pages 3 –12, may 2008.
[LO03]
S. Loecher and S. Ocke. A Metamodel-Based OCL-Compiler for UML and MOF. In OCL 2.0 - Industry standard or scientific playground?, Proc. 6th International Conference on the UML and its Applications, UML 2003 in ENTCS, October 2003.
[TNAKN11] A. Tamrawi, T. Th. Nguyen, J. M. Al-Kofahi, and T. N. Nguyen. Fuzzy set and cachebased approach for bug triaging. In T. Gyim´othy and A. Zeller, editors, SIGSOFT FSE, pages 365–375. ACM, 2011. [TvV09]
106
A. Tang and H. van Vliet. Modeling constraints improves software architecture design reasoning. In Software Architecture, 2009 European Conference on Software Architecture. WICSA/ECSA 2009., pages 253 –256, September 2009.
Towards an Extensible C for Embedded Programming Markus Voelter1 , Bernhard Schaetz2 , Daniel Ratiu2 , and Bernd Kolb3 1
independent/itemis 2 Fortiss GmbH 3 itemis AG
Abstract. Embedded software development suffers from inadequate languages and tools. The C programming language does not provide means for defining adequate abstractions. Furthermore, modeling tools and their languages are typically closed and cannot be adapted to particular domains. In this paper we present the current state of an extensible language based on C that combines the best of both worlds. The mbeddr C language is developed as part of the LWES KMU Innovativ research project run by fortiss, itemis, Lear and Sick.
1
Introduction
In the LWES KMU Innovativ project, the project partners explore how domainspecific extensions to C can increase the productivity and analyzability of C programming. We have implemented C in the MPS language workbench, which, as a consequence of MPS’s architecture, makes the language and IDE extensible in meaningful ways. We are now in the process of developing actual extensions to C. In this paper, we describe some of the challenges in embedded development, as well as some of the extensions we built to address them. The LWES project is still work in progress. Details can be found at http://mbeddr.com, and the project partners are itemis, fortiss, Lear Automotive and SICK Sensortechnik.
2
Challenges in Embedded Development
This section provides an overview over some of the typical challenges encountered in the development of embedded systems. Abstraction without Runtime Cost Abstractions that fit the problem domain are important for modular and maintainable software. In embedded software, these abstractions should come with minimal runtime cost, because the target environments for embedded software are often severely resource constrained. This means that many of the abstractions have to be resolved statically during translation, resulting in an efficient C implementation.
107
Static Checks and Verification To build safe, secure and real-time systems, various forms of static analysis are used, from the compiler’s type checks to sophisticated model checking approaches. To make verification feasible, those parts of a system that have to be verified should be isolated from the rest, and expressed in a formalism that makes the relevant verification feasible. An example formalism is state machines. However, these parts of the system still have to be integrated with the rest of the system, usually written in C. Extracting these parts into a completely separate environment, such as a state chart modeling tool, results in integration problems. C considered Harmful While being efficient and flexible, especially for low-level, machine-dependent code, some of C’s features are often considered harmful. Unconstrained casting via void pointers, using ints as Booleans or data structures like unions can result in hard-to-detect runtime errors. Consequently, these features of C, as well as others, are prohibited in many organizations. Standards such as MISRA-C limit the language subset to what is considered safe. However, most C IDEs are not out of the box MISRA-C aware, so separate checkers have to be used and they may or may not be integrated with developers’ tools. This makes it hard for developers to use the safe language subset of C efficiently. Inclusion of Meta Data Non-trivial embedded systems often associate various kinds of meta data with program elements. Examples include physical units, data encodings and value ranges for types, access restrictions, memory mappings and access frequency restrictions for (global) variables as well as trace information from code to other artifacts, typically requirements. These meta data often form the basis for checking and analysis tools. Since C programs cannot express these meta data directly (except as comments or pragmas, with the obvious drawbacks), they are stored separately, often in XML files, leading to unnecessary complexity and maintainability problems. Product Line Support Most embedded systems are developed as part of product lines. This leads to two problems. First, each product line, or domain, comes with its own set of abstractions. If those can be made available to the developer directly, writing code for that domain becomes much simpler, and checks and verifications become more meaningful. We have already discuss these limitations in building custom abstractions above. A second challenge is the support for product line variability where certain (parts of) artifacts are only included in some of the products in the product line. This variability typically cross-cuts all the artifacts and tools, yet still has to be managed efficiently. Today this variability on code level is often implemented with the preprocessor leading to the problems discussed above and preventing static analysis of variant consistency.
3
mbeddr C Solution Approach
mbeddr C addresses these challenges by providing an extensible version of C. Instead of artificially separating "programming" and "modeling" into different tools, with the resulting integration challenges, concepts at every abstraction
108
level can be used in one program. Extensions to C a modular and incremental; new abstractions can be added at any time. Full IDE support, including syntax coloring, code completion, go-to-definition as well as refactoring are provided for the base language and all extensions.
4
Example Extensions to C
In this section we show how to use the extensible C language and some example extensions to address the challenges discussed above (Section 2).
Fig. 1. A decision table evaluates to the value in the cell for which the row and column headers are true, the default value -1 otherwise.
Decision Tables are a new expression. An example is shown in Fig. 1. Since expressions need a type and a value, decision tables specify the expected type of the result expressions (int in the example) and a default value (-1). A decision table is basically a two-level if statement. It evaluates to the value in the cell whose column and row headers evaluate to true. Unit Tests are additional a new kind of top level constructs (Fig. 2). They are introduced in a separate unittest language that extends the C core. Unit tests are like void functions without arguments. The unittest language also introduces the assert and fail statements which can only be used inside of a test case. module UnitTestDemo imports multiplier { exported test case testMultiply { assert(0) times2(21) == 42; if ( 1 > 2 ) { fail(1); } } }
Fig. 2. Test cases are new top level constructs. The unittest language also introduces the assert and fail statements which can only be used inside of a test case. The arguments to assert and fail denote the index of the statement. In error messages this number is output as a way of finding the cause in the code. These indexes are automatically projected and cannot be changed in the editor.
State Machines provide a new top level construct as well as new statements and expressions to interact with state machines from regular C code. Entry, exit and transition actions may only access variables defined locally in state machines and set output events. This way, state machines are semantically isolated from the remaining system and can be model checked using the integrated NuSMV model checker. State machines can be connected to the surrounding C program by mapping output events to function calls and by regular C code triggering input events in the state machines. Both these aspects are not relevant to verification.
109
module Statemachine from cdesignpaper.statemachine { statemachine Counter { in start() step(int[0..10] size) out started() resetted() incremented(int[0..10] newVal) vars int[0..10] currentVal = 0 int[0..10] LIMIT = 10 states (initial = start) state start { on start [] -> countState { send started(); } } state countState { on step [currentVal + size > LIMIT] -> start { send resetted(); } on step [currentVal + size countState { currentVal = currentVal + size; send incremented(currentVal); } on start [ ] -> start { send resetted(); } } } }
Fig. 3. A state machine embedded into a C module. It declares in and out events as well as local variables, states and transitions. Transitions react to in events and out events can be created in actions. State machines can be verified with the NuSMV model checker, a topic not discussed further in this paper. Through bindings (not shown) they can interact with surrounding C code, e.g. by calling functions when an out event is created.
Components are new top level constructs used for modularization, encapsulation and the separation between specification and implementation (Fig. 4). Interfaces declare operation signatures that can be implemented by components. Provided ports specify the interfaces offered by a component, required ports specify the interfaces a component expects to use. Different components can implement the same interface operations differently. Components can be instantiated, and each instance’s required ports have to be connected to compatible provided ports provided by other component instances. Physical Units are new types that, in addition to defining their actual data type, also specify the physical unit (such as m/s or N ). They also specify a resolution. New literals are defined to support specifying values for these types that include the physical unit. The type checker takes into account unit compatibility. Scaling (e.g. if working with N and kN in one expression) is taken into account automatically. Requirements Traces Requirements traces are meta data annotations that point to requirements, essentially elements in other models imported from tools such as DOORS. Requirements traces can be applied to any program element without the definition of that element being aware of this (see Fig. 5). Presence Conditions Like requirements traces, presence conditions can be attached to any program element. They are Boolean expressions over features in a feature model (essentially configuration switches). Their semantics is that the
110
module Components { c/s interface Calculator { int multiply(int x, int y) ; } component Computer { provides Calculator calc requires LoggingService log int calc_multiply(int x, int y) = 500
ce := 0
(convoy,unregistered) cr = 200 unregister!
register!
ce >= 500 ce := 0 cr := 0 cr := 0 (convoy,registered) update! cr = 800 cr >= 200 ce := 0 lifetick!
startConvoy!
(noConvoy,registered) ce = 800
cr := 0 cr := 0 update! cr >= 400
breakConvoy?
Abbildung 5: Parallelly Composed Timed Automaton
The application of a state composition rule results in a state composition conform timed automaton. This automaton originates from the parallel composition but is modified such that the corresponding state composition rule has been applied to each automaton location. Automaton locations whose invariant is f alse are further removed from the automaton. The example state composition rule r1 applied to the parallel composition of the rear and registree role automata (Figure 5) results in the automaton depicted in Figure 6. (noConvoy,unregistered) unregister!
ce >= 500
register!
ce := 0
startConvoy!
(noConvoy,registered) ce = 800
breakConvoy?
cr := 0
ce := 0 update! cr >= 400
(convoy,registered) cr = 200 ce := 0 lifetick!
Abbildung 6: Synthesized Component Behavior of the RailCab Component
119
2.3
Preserving Role Behavior
In order to preserve the relevant role behavior, we need to ensure that in the refined component behavior all timed safety properties and all untimed liveness properties are preserved. This would imply that no deadlines of the original role automata are violated while still all events of the original automata are (in the correct order) visible within the original time interval. If both of these properties are preserved, we say that the refined component behavior is role conform. A detailed proof is discussed in [EH10b].
3
Related Work
Work which is related to our approach exists in the field of controller synthesis as well as in the field of component-based software development. The field of controller synthesis [AMP95, AT02, GGR08] deals with the problem of synthesizing a behavioral model for a controller which interacts with some environment. In a controller, interaction is specified through alternating actions between the controller and the environment. Consequently, for the behavioral model a special type of timed automaton, a timed game automaton [AMP95], is applied. In a timed game automaton, transitions are partitioned into those controllable by the controller and those controllable by the environment. There exist a number of approaches for the controller synthesis of system and componentlevel behavior models from system specifications which considers no time (e.g. [HKP05]). Current work in this domain focuses on synthesis approaches based on modal transition systems (e.g.[UBC09]). The motivation of these approaches is to capture the possible system or component implementations. In general, these approaches are also able to restrict the forbidden behavior by properties. In [GV06], Giese and Vilbig present a synthesis procedure for the behavior of interacting components. While the basic idea of their approach and our approach is the same, the main goal of the synthesis differs. Giese and Vilbig propose to synthesize a maximal consistent component behavior which allows for representational non-determinism by the explicit use of τ -transitions representing internal component behavior. Our goal, on the other hand, is to synthesize a correct refined component behavior with respect to safety and liveness properties where the behavior of other ports is treated as internal component behavior. Furthermore, we employ real-time behavioral models as input specifications in order to suit the requirements of safety critical systems.
4
Conclusion and Future Work
In this paper we proposed an approach to automatically synthesize the behavior of components applied in critical systems. Therefore, we propose to specify dependencies between several role behaviors separately by means of composition rules. Additionally, we defined a procedure to automatically integrate the composition rules for a given set of
120
role behaviors. Afterwards it is checked that the resulting component behavior refines each of the role behaviors properly. We exemplify the approach by extending the M E CHATRONIC UML. A first prototype and an evaluation of our approach is presented in [HGH+ 09, EH09, EH10b] which shows that in principle an implementation based on zone automaton seems to be a feasible approach for efficiently abstracting from the infinite state space inherently arising from timed automata. It can also be observed, however, that the efficiency varies depending the differences between the values used in clock constraints in the corresponding timed automata models. Concerning the composition rule formalism, it might also be of interest to specify composition rules which describe parts of the synchronization behavior which may not be removed from the parallel composition. Those rules might be called positive composition rules, as they would not remove any behavior of the underlying timed automaton semantics, but ensure that the described behavior is preserved. In addition to that, specification patterns (e.g. [DAC99]) could be applied for the specification of synchronization properties defined by composition rules. This way, a set of rule patterns of best-practice could be established to facilitate the specification of composition rules.
Literatur [AD90]
Rajeev Alur und David L. Dill. Automata for Modeling Real-time Systems. In Proceedings of the Seventeenth International Colloquium on Automata, Languages and Programming, Jgg. 443 of Lecture Notes in Computer Science (LNCS), Seiten 322–335, New York, NY, USA, 1990. Springer-Verlag New York, Inc.
[AMP95]
Eugene Asarin, Oded Maler und Amir Pnueli. Symbolic Controller Synthesis for Discrete and Timed Systems. In Hybrid Systems II, Seiten 1–20, London, UK, 1995. Springer-Verlag.
[AT02]
Karine Altisen und Stavros Tripakis. Tools for Controller Synthesis of Timed Systems. In Paul Pettersson und Wang Yi, Hrsg., Proceedings of the 2nd Workshop on Real-Time Tools (RT-TOOLS’02), August 2002.
[BSW00]
Jan Bosch, Clemens A. Szyperski und Wolfgang Weck. Component-Oriented Programming. In Jacques Malenfant, Sabine Moisan und Ana M. D. Moreira, Hrsg., ECOOP Workshops, Jgg. 1964 of Lecture Notes in Computer Science, Seiten 55–64. Springer, 2000.
[DAC99]
Matthew B. Dwyer, George S. Avrunin und James C. Corbett. Patterns in Property Specifications for Finite-State Verification. In Proceedings of the 21st International Conference on Software Engineering ICSE’99, Seiten 411–420, 1999.
[Dij76]
E.W. Dijkstra. A discipline of programming. Prentice-Hall Series in Automatic Computation, 1976.
[EH09]
Tobias Eckardt und Stefan Henkler. Synthesis of Component Behavior. In Pieter Van Gorp, Hrsg., Proceedings of the 7th International Fujaba Days, Seiten 1–5, Eindhoven University of Technology, The Netherlands, November 2009.
[EH10a]
Tobias Eckardt und Stefan Henkler. Component Behavior Synthesis for Critical Systems. In Holger Giese, Hrsg., ISARCS, Jgg. 6150 of Lecture Notes in Computer Science, Seiten 52–71. Springer, 2010.
121
[EH10b]
Tobias Eckardt und Stefan Henkler. Synthesis of Reconfiguration Charts. Bericht tr-ri10-314, University of Paderborn, Paderborn, Germany, January 2010.
[GB03]
Holger Giese und Sven Burmester. Real-Time Statechart Semantics. Bericht tr-ri-03239, Software Engineering Group, University of Paderborn, Paderborn, Germany, June 2003.
[GBSO04] Holger Giese, Sven Burmester, Wilhelm Sch¨afer und Oliver Oberschelp. Modular Design and Verification of Component-Based Mechatronic Systems with OnlineReconfiguration. In Proc. of 12th ACM SIGSOFT Foundations of Software Engineering 2004 (FSE 2004), Newport Beach, USA, Seiten 179–188. ACM Press, November 2004. [GGR08]
Stephanie Geist, Dmitry Gromov und J¨org Raisch. Timed Discrete Event Control of Parallel Production Lines with Continuous Outputs. Discrete Event Dynamic Systems, 18(2):241–262, 2008.
[GTB+ 03] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Sch¨afer und Stephan Flake. Towards the Compositional Verification of Real-Time UML Designs. In Proc. of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11), Seiten 38–47, September 2003. [GV06]
Holger Giese und Alexander Vilbig. Separation of Non-Orthogonal Concerns in Software Architecture and Design. Software and System Modeling (SoSyM), 5(2):136 – 169, 6 2006.
[HGH+ 09] Stefan Henkler, Joel Greenyer, Martin Hirsch, Wilhelm Sch¨afer, Kahtan Alhawash, Tobias Eckardt, Christian Heinzemann, Renate L¨offler, Andreas Seibel und Holger Giese. Synthesis of Timed Behavior from Scenarios in the Fujaba Real-Time Tool Suite. In Proceedings of the 31st International Conference on Software Engineering (ICSE 2009), May 16-24, 2009, Vancouver, Canada, Seiten 615–618, Washington, DC, USA, May 2009. IEEE Computer Society. [HKP05]
David Harel, Hillel Kugler und Amir Pnueli. Synthesis Revisited: Generating Statechart Models from Scenario-Based Requirements. In Formal Methods in Software and Systems Modeling, Seiten 309–324, Berlin/Heidelberg, Germany, 2005. Springer-Verlag.
[JS05]
Ethan K. Jackson und Janos Sztipanovits. Using separation of concerns for embedded systems design. In EMSOFT ’05: Proceedings of the 5th ACM international conference on Embedded software, Seiten 25–34, New York, NY, USA, 2005. ACM.
[Lam77]
Leslie Lamport. Proving the Correctness of Multiprocess Programs. IEEE Transactions on Software Engineering, SE-3(2):125–143, March 1977.
[Mil89]
R. Milner. Communication and concurrency. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1989.
[Sel96]
Bran Selic. Real-Time Object-Oriented Modeling (ROOM). In 2nd IEEE Real-Time Technology and Applications Symposium (RTAS ’96), June 10-12, 1996, Boston, MA, USA, Seiten 214–. IEEE Computer Society, 1996.
[TOHS99] Peri Tarr, Harold Ossher, William Harrison und Stanley M. Sutton, Jr. N degrees of separation: multi-dimensional separation of concerns. In ICSE ’99: Proceedings of the 21st international conference on Software engineering, Seiten 107–119, New York, NY, USA, 1999. ACM. [UBC09]
122
Sebasti´an Uchitel, Greg Brunet und Marsha Chechik. Synthesis of Partial Behavior Models from Properties and Scenarios. IEEE Transactions on Software Engineering, 35:384–406, 2009.
Unifying Probabilistic and Traditional Formal Model Based Analysis Matthias G¨udemann, Michael Lipaczewski, Simon Struck and Frank Ortmeier
[email protected], {michael.lipaczewski|simon.struck| frank.ortmeier}@ovgu.de INRIA Rhˆone-Alpes, FIN / ITI, CSE, Otto-von-Guericke University Magdeburg Abstract: The increasing complexity of modern software-intensive systems makes their analysis much more difficult. At the same time, more and more of theses systems are used in safety-critical environment. Model based safety analysis can help with this problem by giving provably correct and complete results, very often in a fully automatic way. Today, such methods can cope with logical as well as probabilistic questions. However, very often the models used in many model based approaches must be specified in different input languages depending on the chosen verification tool for the desired aspect, which is time consuming and often error-prone. In this paper, we report on our experiences in designing a tool independent specification language (SAML) for model based safety analysis. This allows to use only one model and analyze it with different methods and different verification engines, while guaranteeing the equivalence of the analyzed models. In particular, we discuss challenges and possible solutions to integrate SAML in the development process of real systems.
1
Introduction
Software is becoming a major innovation factor in many different application domains. With increasing demands and more features, the complexity of systems is growing steadily. The increased complexity of software-intensive systems and their increased application in safety critical domains makes the detection of possible malfunctioning more and more important, but unfortunately also more difficult. To tackle this problems, model-based safety analysis techniques have been developed. Their usage is today encouraged or even demanded by many domain specific norms like DO-178B for avionics, ISO26262 for automotive or the generic IEC61508. In the last decade, different safety analysis methods have been developed. Some approaches focus on qualitative safety analysis i.e. the determination of critical combinations of component failures that can lead to a system hazard. However, all technical systems may fail some time. The remaining question is the occurrence probability of a hazard under known failure occurrence probabilities of the components. Thus there are different approaches to compute the quantitative safety aspects.
123
Safety analysis of industrial applications requires qualitative and quantitative methods. It is our experience that applying both methods at the same time requires a lot of unnecessary effort. One reason is the lack of tool support for convenient specification. Verification tools are improved continuously but actually the front-ends only improve slowly. And last but not least, both methods often require different tools and thus rely on different modeling languages. To solve this problem, we defined the Safety Analysis Modeling Language (SAML). It allows for tool independent specification of models for safety analysis. For verification, these models are automatically transformed into model representations usable for different verification engines. The transformations are semantically well-founded and mathematically proven. This allows the decoupling of the model (and its safety properties) from the actual verification tools. In this paper, we will focus on our experiences an challenges for simplifying the process of qualitative and quantitative safety analysis. In Sect. 2 we will briefly describe the idea of SAML and by using an example from a recent case-study describe the language and the different aspects. Different approaches for current and further work are discussed in Sect. 3. Some related approaches are discussed in Sect. 4, followed by an conclusion in Sect. 5.
2
Safety Analysis Modeling Language (SAML)
2.1
Tool-independent Specification
The basic concept of a model-based approach for safety analysis is that system designers and the safety engineers share a common system model [JMWH05]. This has the advantage, that safety analysis is conducted using a system model, which will also be used for a sketch/blueprint for implementation. Therefore all implicit (stochastic) dependencies are automatically considered and consistency of the analysis with the engineering model is guaranteed. A key requirement for accurate model-based safety analysis is, that models must be capable of deterministic, non-deterministic and stochastic behavior. Deterministic behavior is typically (but not exclusively) necessary for modeling software functionalities. Nondeterminism is useful for modeling system environment or software faults (for both very often no stochastic information exist). Physical failure modes are most often modeled using probabilistic models (for example known failure rates of components). There exist numerous tool-specific specification languages, where each tool focuses on a specific class of problems and provides a fitting specification language. Just to name a few examples: NuSMV 1 is one of the most powerful model checkers for Computational Tree Logic. Its input specification are in the form of finite automata. MRMC 2 is a very powerful stochastic model checker which can deal with discrete and continuous time Markov chains, but 1 http://nusmv.fbk.eu 2 http://www.mrmc-tool.org
124
requires the specification directly as the transition relation. On the other hand, PRISM 3 is a little less time-efficient than MRMC but allows for a much more convenient specification of models and also supports discrete time Markov decision processes. As safety analysis often contains stochastic as well as logical analysis, we suggest using a tool-independent specification language and automatic model transformations to toolspecific languages of the verification engines. We defined the tool-independent specification language safety analysis and modeling language (SAML) to solve this problem (see Fig. 1). Tool−independent specification layer
SAML
NuSMV
Cadence SMV
qualitative analysis
PRISM
MRMC
Tool−specific verification layer
quantitative analysis
Figure 1: SAML overview
Tool-independent specification layer: Problems are of course tool-independent. All that is needed is a formalism, which is expressive enough to capture all joint model properties and simple enough to be understandable and usable. In this layer, functional behavior of the software and the controlled hardware are specified. It is also necessary to specify environment and failure mode models. However, modeling must not depend on the verification engine which will be used. We defined a tool-independent specification language – SAML – for usage on this layer. Precise syntax and semantics may be found in [GO10, G¨ud11], but a brief introduction and an application example may be found in the following section. Verification Layer: SAML does not provide its own verification tool (nor shall it). Instead system models expressed in SAML are transformed into the input language of different formal analysis tools, depending on the type of the system property that should be checked. These transformations result in trace-equivalent models expressed in the input language of specified verification tools (proofs may be found in [G¨ud11]). The results of an analysis are either counterexamples of the analysis models mapped back to the SAML model or the probability of the checked properties. For this, the connection between the modeling artifacts of SAML and the analysis formalism is kept track of. Such a separation offers two big benefits. Firstly, it is guaranteed that for example probabilistic analysis (maybe done with PRISM) and qualitative analysis (maybe done with NuSMV) are done using the same model. Therefore, the results are consistent with each other (in the sense that the same model was used). Secondly and maybe even more important, the separation allows to switch between different verification engines. For example, MRMC is much more time-efficient than PRISM for discrete time Markov chains and SPIN might be your first choice if you are interested in properties expressed in linear time temporal logic (instead of NuSMV). Such choice may now be done without changing/rebuilding the whole system model. 3 http://www.prismmodelchecker.org
125
2.2
A SAML Example Model
Syntactically, a SAML model describes a set of finite state automata that are executed in a synchronous parallel fashion with discrete time-steps. The automata are described as modules that contain state variables which are updated according to transition rules. Transitions can contain both non-determinism and probabilistic choice. The syntax is very much inspired by the syntax of PRISM (as a matter of fact it is an extended subset). The underlying semantic model is a Markov Decision Process (MDP). In this paper we do not present full formal semantics and syntax but only explain the idea of using SAML on a small example. Full syntax and formal semantics may be found in [GO10]. Fig. 2 shows (parts of) the SAML code for the example of an airbag controller software. The case-study was initially presented in [KHE11]. The core idea of this system is, that a (software) controller is fed by two separate sensors, aggregates their measures over some time and then decides whether to ignite an airbag or not. Fig. 2 shows the model of an environmental component, of a specific failure mode and a part of the software called sensor validator, which aggregates sensor inputs (which is later used as input for the actual software controller). 01 constant double p_magSensor_fail 02 constant int Detection_interval 03 constant int threshold 04 formula crash detected [...] 05 module env_crashOccurrence 06 env_crashOccur :[0..1] init 0; 07 env_crashOccur = 0 -> choice: ( + choice: ( 08 env_crashOccur = 1 -> choice: ( 09 endmodule [...] 10 module failure_magSensor 11 magSensor_faulty :[0..1] init 0; 12 magSensor_faulty = 0 -> choice: (
:= := := :=
2.78E-10; 5; 4; mechSensor_state > 0 & magSensor_state > 0;
1: env_crashOccur’=1 ) 1: env_crashOccur’=0 ); 1: env_crashOccur’=1 );
p_magSensor_fail: magSensor_faulty’=1 + 1-p magSensor_fail: magSensor faulty’=0 ); choice: ( 1 : magSensor faulty’=1 );
13 magSensor faulty = 1 -> 14 endmodule [...] 15 module sw_SensorValidator 16 counter :[0 .. 6] init 0; 17 sum :[0 .. 5] init 0; 18 //crash detected 19 crash detected & counter >=detection -> choice: ( 20 crash detected & counter < detection -> choice: ( 21 crash detected & counter < detection -> choice: ( 22 //crash not detected [..] 23 endmodule
ĞƚĞƌŵŝŶŝƐƚŝĐĚĞĐŝƐŝŽŶ
interval 1: (counter’=0) & (sum’= 1) ); interval & sum < sumLevel 1: (counter’=counter+1) & (sum’=sum+1) ); interval & sum >=sumLevel 1: (counter’=counter+1) & (sum’=sum ) );
EŽŶͲĚĞƚĞƌŵŝŶŝƐƚŝĐĐŚŽŝĐĞ
WƌŽďĂďŝůŝƚLJĚŝƐƚƌŝďƵƚŝŽŶ
Figure 2: Example SAML Model of Airbag Controller
Lines 1 to 3 contain definitions of constants, which may be used to define probabilities or other static parameters for global usage in the model. Valid types of constants in SAML are int, double and float. Line 4 shows the usage of a formula, which is often used as abbreviations for complex Boolean formulas.
126
Different components in SAML are described as modules (keywords: module and endmodule). Each module contains a set of state variables (see lines 6, 11, and 16-17) together with an initial value. The dynamic behavior is described by transition rules. A transition rule is a tuple of an activation condition 4 and a set of non-deterministic choices of probability distributions 5 . A probability distribution is a set of tuples, where the first part is a probability 6 and the second part is an assignment of a new value to the state variables of a model for the next time-step. For example the transition rule in line 12 is activated if “magSensor faulty = 0” holds. This transition rule includes no non-deterministic choice (i.e. only one choice keyword). Therefore by defining a non-trivial distribution (line 12, bold border) with probability “p magSensor fail” the next state will be 1; otherwise the next state will be 0. Different types of model components require different types of specification. For most software and hardware components behavior is typically deterministic as every possible situation leads to a single next situation. In SAML this leads to transition rules with only a single choice and a trivial probability distribution (i.e. exactly one assignment which is applied with a probability of 1). An example is the (software) module “sw SensorValidator” starting in line 15. In contrast failure occurrences are often considered in a purely probabilistic way. An example is the failure of the magnetic sensor (see lines 10 to 14). In SAML this leads to transition rules with only a single choice but non-trivial distribution functions. Environmental processes are often specified using non-determinism. For example the occurrence of crashes (modeled in lines 5 to 9). In SAML, this leads to multiple choice in one transition rule (line 7, bold border). However, there also exist many situations where combinations are needed (for example software faults or more elaborate environment models). This is no problem because SAML allows the combination of probabilistic and non deterministic choices.
2.3
Current State of SAML
In the last 18 months we focused on a prototypical realization of SAML. In a first step, we implemented a parser for SAML using the ANTlr[Par07] parser generation framework. This proved to be a very efficient choice as it runs robust and allows relatively easy adaptations to the syntax. Next, we implemented a simulator for executing SAML models and first model transformations. We implemented model transformations to NuSMV, Cadence SMV and PRISM. A transformation to MRMC is also possible by using existing PRISM2MRMC model transformations. From an algorithmic point of view, we had to choose whether to translate on a semantic level (for example extraction of the Kripke structure out of the Markov Decision Process) or on a syntactic level (for example transla4 For creating a well-founded model, it is necessary to have exactly one active transition for each possible state. This means all activation conditions must be pairwise contradicting and that their logical disjunction rewrites to true. This is necessary to guarantee existence of infinite trace (a pre-requisite for using CTL) as well as understandable probability spaces. If this restriction holds can only be decided on the semantic level. In the current implementation we rely on a special function of the PRISM model checker to evaluate this property. 5 Non-determinism differs from a probability distribution by allowing every possible distribution 6 which must together sum up to 1
127
tion of SAML modules to NuSMV automata). Both solutions are supposed to be difficult in realization and have both advantages and disadvantages. The first one is of course more charming and allows for more flexible transformations. However, it can become very costly as huge state spaces must be built, stored and handled. The second solution is much more performant (in terms of computation costs for the translation), but heavily depends on the input language of the chosen target tool. We chose the second option, in particular because it also yields human-readable intermediate models for the verification tools, which is a great help during debugging. More information on this choice and also the proofs for showing correctness maybe be found in [G¨ud11]. We now specified and analyzed about half a dozen case studies in SAML. We learned that the model transformations are working reliable and that specification in SAML is feasible and intuitive. In particular, qualitative and quantitative model-based safety analysis could efficiently be combined.
3
Next Steps and Outlook
During the exhaustive tests, we also learned that numerous open issues for improvements exist. This starts by extending the language with safety specific notions (i.e. failure modes). Another open issue is supporting specification with a state-of-the-art editor to increase performance. Finally, using SAML as an intermediate language between lowlevel verification tools and high-level CASE tools is a challenging topic. In this section, we will explain briefly our current work on these three topics.
3.1
Safety Specific Extensions
In the first version, SAML did not include any safety specific terms. This means that the grammar did not distinct between a software artifact, an environment specification and an failure mode. All are modeled as a simple module. In IEC 61508 there exists the generic distinction between per-time and per-demand failure modes. A per demand failure mode may only appear if there is a demand to the safety critical system at the moment (for example physical breakdowns are usually only possible when an actuator is working). Such a failure mode occurrence is described with a failure probability. In contrast, a per-time failure mode may occur at any time and is generally specified using a failure rate. In an orthogonal dimension, one may distinguish between transient and persistent failure. Transient failures may arbitrarily appear and disappear, while persistent failures occur once and then stay in this mode. A generic approach to model failure modes was already presented in [OGR07]. The key idea is to separate when a failure occurs and what its semantics are. This was extended for SAML models in [G¨ud11]. In the last months, we automated the modeling by adding new keywords to SAML for specific occurrence patterns (for example “hd-trans-failure” for an high-demand transient failure mode). This allows much more intuitive specification
128
of failure modes. Technically, the semantics of these keywords could be defined using only basic SAML constructs. This made it easy to extend the syntax in a prototypical implementation without changing the model transformations. Another ongoing work is to extend SAML to families of MDPs. This makes sense if several (similar) design alternatives for a system exist (for example threshold for certain sensor values or alternative components). It is then interesting to compute, which thresholds/components yield the best results for a given goal. If all alternatives (i.e. the whole family of MDPs) can be expressed in one model, then it is possible to apply optimization algorithms to it. We were able to successfully demonstrate that such a combination is efficiently possible for combining a multi-dimensional genetic algorithm with stochastic model checking to find best solutions (with respect to some model checking property) in a family of MDPs[GO11]. Currently, we are working on extending SAML such that families of MDPs can be described (and be analyzed).
3.2
Specification Environment
By modeling and analyzing the case-studies it became obvious that using the current toolchain for modeling, transformation, checking and result viewing becomes quiet exhausting. For specification in SAML we had to use a text editor, model transformation required calling of LISP functions, model checking was done by command line and interpretation of the results was done by hand. Therefore a single Safety Design Environment (SDE) would increase the usability of SAML and the model-based safety analysis techniques towards a full specification and modeling language. This SDE could not only integrate the transformation from SAML to the specific model checker language and all necessary transformations and program executions into a “push-the-button” approach7 , it would also give the developer a powerful editor with common interface and tools of other development frameworks. Our current idea is to create a SAML SDE by using the Eclipse framework. Eclipse was chosen, as it already comes with a powerful plug-in mechanism and reusable components. We implemented SAML specific syntax highlighting, auto-completion, outline module and in-time error checking with customized failure messages for the Eclipse editor. The user can invoke the model transformations and verifications by the use of customized menu entries. The overall experience is similar to the a software development environments. The current prototypical realization of the SDE,the model transformations and the optimization are implemented in different programming languages. We are currently working on porting all parts to the Java virtual machine based runtime environment. Next steps will be the automatic generation of deductive-cause-consequence-analysis proof obligation and visualization of the analysis results. 7 If
the failure modeling extension are also integrated and DCCA[ORS06] is selected as analysis method.
129
3.3
SAML as Intermediate Language
Beside using SAML as independent high-level modeling and specification language as suggested before, using it as an intermediate language could be even more beneficial (see Fig. 3). + Failure Mode Model
+Probabilistic Modelling
Engineering layer
SCADE
Matlab/Simulink
Intermediate layer
SAML
NuSMV
Cadence SMV
qualitative analysis
PRISM
MRMC
Verification layer
quantitative analysis
Figure 3: SAML as an intermediate language
In this scenario SAML would only be used as an intermediate layer. Specification would written in a high-level CASE tool like SCADE or Matlab and verified using NuSMV or PRISM. However there are numerous problems to be solved. Firstly, model transformation from the high-level to the intermediate level need to be specified and implemented. We did some experiments with SCADE resp. Lustre and learned this might be possible but difficult problems have to be solved. Some are of technical nature and others of computational nature. Secondly, in CASE tools typically only the software is modeled. Failure modes, environment and probabilistic behavior are usually not supported. So extensions need to be made at this point. Nevertheless, we think that such an approach is for sure worth further investigation.
4
Related Work
One prominent example of a formal language used for the development of safety critical applications is SCADE, which is based on the synchronous data-flow language LUSTRE. The SCADE suite 8 is developed by Esterel Technologies and includes a model-checker for safety properties. Nevertheless, this formal analysis is not well suited for more complex safety analysis as shown in [GOR07]. The language FIACRE [FGP+ 08] is included as intermediate language in the TopCased toolkit [VPF+ 06]. It is used to verify properties of the SysML models created in TopCased. Nevertheless, it turned out that the large number of supported SysML artifacts lead to very large formal models even for small case studies [FGP+ 08]. Therefore we designed SAML 8 http://www.esterel-technologies.com
130
deliberately as simple as possible while retaining the necessary expressiveness for safety analysis. A recent approach is developed in the COMPASS project [BCK+ 10]. Here, the already exiting FSAP-NuSMV/SA [BV03] framework is combined with the MRMC probabilistic model checker [KZH+ 10] to allow for the analysis of systems for Aerospace applications specified in the SLIM language, which is inspired by the Architecture Analysis and Design Language (AADL) and its error annex. The SLIM language describes the architecture and behavior of the system components, it allows for a combination of discrete and continuous (hybrid) variables. From the AADL error annex, exponentially distributed failure modes are supported and the effects can automatically be injected into the system specification. The hybrid behavior of the SLIM models and all internal transitions are removed by lumping and the resulting interactive Markov chain is analyzed with MRMC. COMPASS is one of the few existing approaches which also combines qualitative and quantitative modeling and analysis. Nevertheless, the design is very much tool-dependent and exchanging the model-checking tools would not be easy. It is also not possible to combine hybrid and probabilistic modeling in the very same model. In addition, none of the existing approaches allows for the integration of both per-time and per-demand failure modes as it is possible with SAML and our analysis approach. These two different probabilistic occurrence pattern are described in IEC 61508 [Lad08] as high or continuous demand and low demand failure modes. COMPASS and most other probabilistic safety analysis approaches use continuous time Markov chains models (CTMC) as system models which allows per-time failure mode modeling with failure rates. CTMCs are well suited for modeling asynchronous, interleaved systems but not for synchronous parallel systems [HKMKS00] as many safety critical system are.
5
Conclusion
The combination of quantitative and qualitative model-based safety analysis in a single framework has several advantages. It is ensured that the analyzed models are equivalent. Additionally the modeling overhead is minimized compared to the traditional approach to create a model for every safety analysis aspect. The combination and also the toolindependence of the model-based safety analysis approach based on SAML is technically possible and was successfully applied to several case studies. However the integration into a common modeling framework like the SAML SDE based on Eclipse is necessary to make the method accessible for broader acceptance in industrial contexts. Further work will at first concentrate on well integration into the modeling tool. Afterwards the work on system variant optimization, goal specification language etc. will be further conducted as it is expected that more case studies are available.
Acknowledgments Michael Lipaczewski is sponsored by the Deutschen Ministerium f¨ur Bildung und Forschung in the ViERforES project (BMBF, project-Nr.: 01IM08003C).
131
References [BCK+ 10]
M. Bozzano, A. Cimatti, JP. Katoen, VY. Nguyen, T. Noll, and M. Roveri. Safety, Dependability, and Performance Analysis of Extended AADL Models. The Computer Journal, 2010. [BV03] M. Bozzano and A. Villafiorita. Improving System Reliability via Model Checking: the FSAP/NuSMV-SA Safety Analysis Platform. In Proceedings of the 22nd International Conference on Computer Safety, Reliability and Security (SAFECOMP 2003), pages 49–62. Springer, 2003. + [FGP 08] P. Farail, P. Gaufillet, F. Peres, JP. Bodeveix, M. Filali, B. Berthomieu, S. Rodrigo, F. Vernadat, H. Garavel, and F. Lang. FIACRE: an intermediate language for model verification in the TOPCASED environment. In European Congress on Embedded Real-Time Software (ERTS 2008), http://www.see.asso.fr, janvier 2008. SEE. [GO10] M. G¨udemann and F. Ortmeier. A Framework for Qualitative and Quantitative ModelBased Safety Analysis. In Proceedings of the 12th High Assurance System Engineering Symposium (HASE 2010), 2010. [GO11] M. G¨udemann and F. Ortmeier. Model-Based Multi-Objective Safety Optimization. In Proceedings of the 30th International Conference on Computer Safety, Reliability and Security (SAFECOMP 2011). Springer LNCS, 2011. to appear: 19.9.2011. [GOR07] M. G¨udemann, F. Ortmeier, and W. Reif. Using Deductive Cause Consequence Analysis (DCCA) with SCADE. In Proceedings of the 26th International Conference on Computer Safety, Reliability and Security (SAFECOMP 2007). Springer LNCS 4680, 2007. [G¨ud11] M. G¨udemann. Qualitative and Quantitative Formal Model-Based Safety Analysis. PhD thesis, 2011. [HKMKS00] H. Hermanns, JP. Katoen, J. Meyer-Kayser, and M. Siegle. A Markov Chain Model Checker. In Proceedings of the 6th International Conference on Tools and Algorithms for Construction and Analysis of Systems (TACAS 2000), pages 347–362. Springer, 2000. [JMWH05] A. Joshi, SP. Miller, M. Whalen, and MP. Heimdahl. A Proposal for Model-Based Safety Analysis. In Proceedings of the 24th Digital Avionics Systems Conference (DASC 2005), Oct 2005. [KHE11] J. Kloos, T. Hussain, and R. Eschbach. Failure-based testing of safety-critical embedded systems. 2011. [KZH+ 10] JP. Katoen, IS. Zapreev, EM. Hahn, H. Hermanns, and DN. Jansen. The Ins and Outs of the Probabilistic Model Checker MRMC. Performance Evaluation, In Press, Corrected Proof:167–176, 2010. [Lad08] PB. Ladkin. An Overview of IEC 61508 on E/E/PE Functional Safety, 2008. [OGR07] F. Ortmeier, M. G¨udemann, and W. Reif. Formal Failure Models. In Proceedings of the 1st IFAC Workshop on Dependable Control of Discrete Systems (DCDS 2007). Elsevier, 2007. [ORS06] F. Ortmeier, W. Reif, and G. Schellhorn. Deductive Cause-Consequence Analysis (DCCA). In Proceedings of the 16th IFAC World Congress. Elsevier, 2006. [Par07] T. Parr. The Definitive ANTLR Reference: Building Domain-Specific Languages. Pragmatic Programmers. Pragmatic Bookshelf, 2007. + [VPF 06] F. Vernadat, C. Percebois, P. Farail, R. Vingerhoeds, A. Rossignol, JP. Talpin, and D. Chemouil. The TOPCASED Project - A Toolkit in OPen-source for Critical Applications and SystEm Development. In Data Systems In Aerospace (DASIA). European Space Agency (ESA Publications), 2006.
132
Formal Safety Analysis and Verification in the Model Driven Development of a Pacemaker Product Line Sara Bessling Michaela Huhn Department of Informatics, Clausthal University of Technology 38678 Clausthal-Zellerfeld, Germany {Sara.Bessling|Michaela.Huhn}@tu-clausthal.de Abstract: Cardiac pacemakers are a popular showcase for formal methods in the development of dependable, software-controlled embedded systems. We present the pacemaker as a case study on the product-line development of certifiable safety-critical software using S CADE Suite. The product line and and its products are specified by means of the Common Variability Language (CVL). CVL separates the variability modeling from the domain modeling of the base elements. CVL enforces a strict structuring of the product models (done in S CADE) that reflects the substitution concepts used to describe variability. From a formal safety analysis we derive a set of safety requirements which we can prove valid on the family of pacemaker product models by straightforward model checker using the built-in Design Verifier. This positive result indicates that the strict design discipline imposed by the formal variability modeling pays off in verification with a better applicability of automated state space reduction techniques.
1
Introduction
The tight integration of computational and mechatronic devices, nowadays called cyberphysical systems, has lead to numerous new applications in multiple domains. Whereas in classical domains like transport, defense or industrial automation, dependability has been a key issue for decades, software safety has become a concern in the new areas like living assistance, home-based medical support or smart home applications only recently. With the prospects of these markets also the demand grows for software development methodologies and tools that support both model-based design and the safety process. However, development conditions for these new cyberphysical systems slightly differ from the traditional large scale industrial processes performed for classical dependable systems: Since the applications aim at a mass market, variability of products as well as efficient development are essential. This leads to the request for seamless, tool-supported integration of artifacts and activities from different development phases and a higher degree of automation, not only for code generation but also for the safety analysis and resulting verification tasks. Here we consider a product line development for cardiac pacemakers. In order to model variability within the product line we decided for the Common Variability Language (CVL) [HMPO+ 08], as an EMF-based prototype implementation is available and CVL is pro-
133
posed for standardization by the OMG. Even more important, CVL separates the variability modeling from the domain modeling used to design the base elements of the product line. For the domain model we use the S CADE Suite as development framework, since S CADE is qualified for the design of certifiable, dependable software [Est09] and provides a ready to market automated verification facilities. Our motivation for applying a systematic product line approach on the family of pacemaker origins from the disillusioning results for automated verification we experienced in previous work [HB11, DHM11]: Even for medium size industrial design models, fully automated verification yields only very few results due to complexity problems but most properties could be proven only when applying advanced abstraction techniques manually. Thus the question arises whether the strict structuring and the formally defined replacements and substitutions needed for the product line specification will have a (hopefully positive) impact on verification tasks. The rationale for that is that product line systematics will be reflected in the design and give structural insights how to decompose safety requirements and where to apply verification heuristics in the design model for the products. The contribution of this paper is twofold: (1) We model a pacemaker product line by using CVL for the variability modeling and S CADE to model the domain. (2) We provide a showcase for the efficiency gain one may obtain from a strict product line design approach in the subsequent verification: We can easily prove a set of safety requirements to be valid for the pacemaker variants by fully automated model checking. The rest of the paper is organized as follows: Sec. 2 sketches the basics. The pacemaker is introduced in Sec. 3. Sec. 4 describes the design of a product line for a family of pacemakers for which safety analysis and verification is presented in Sec. 5. In Sec. 6 we conclude.
2 2.1
Background CVL - Common Variability Language
The Common Variability Language (CVL) [HMPO+ 08] is an approach to specify product lines upon a domain specific modeling language (DSL). CVL adds the possibility to model product lines or product variabilities on these models. To be able to model a product line with CVL one has to understand first the different layers of CVL (see fig. 1). The variability model of CVL consists of two layers, the feature specification layer (FSL) and the product realization layer (PRL). In the FSL the elements defining a particular product variability are speci- Figure 1: CVL layers, source: fied from a user’s point of view. The PRL consists of the [cvl10] definitions needed to build one product of the product line from the base models and their modifications. Beneath FSL and the PRL the base model has to be provided as the starting
134
point of the product line from which all possible product variabilities are derived. The base model and the library models are modeled in a DSL or UML. A single product variability is described by a resolution model, the last element of the CVL layers. A resolution model consists of a subset of elements of the PRL and FSL. With the help of these resolution models, new variability models can be created by a model-to-model transformation.
2.2
The SCADE Tool Suite
The acronym S CADE stands for Safety-Critical Application Development Environment. The main objectives of the S CADE Suite are (1) to support systematic, model-based development of correct software based on formal methods and (2) to cover the whole development process [Est09]. The language Scade underlying the tool is data-flow oriented. Its formal semantics is based on a synchronous model of computation, i.e. cyclic execution of the model. The S CADE Suite is an integrated development environment that covers many development activities like modeling, formal verification using the SAT-based S CADE Design Verifier [ADS+ 04], certified automatic code generation, requirements tracing, simulation and testing on the code level, inclusive coverage metrics.
2.3
Deductive Cause Consequence Analysis
A major goal in safety analysis is to determine how faults modes at the component level causally relate to system hazards. Among the various formally founded techniques proposed for this task we have selected Deductive Cause Consequence Analysis (DCCA) by Ortmeier et al. [ORS06, GOR07], because DCCA does not only formalize techniques like FTA (Fault Tree Analysis) and an FMEA (Failure Mode and Effect Analysis) [IEC06], which are well-established and recommended by the standards. In addition, the identified fault modes and hazards can be reused in safety assurance to formally verify that sufficient measures have been taken to prevent the identified hazards (for details and formalization see [GOR07, DHM11]). Hazards are specified as observer nodes that read signals from the control logic and evaluate them according to the negation of the hazard predicate.
2.4
Related Work
Since PACEMAKER Formal Methods Challenge [Sci07], pacemakers were investigated intensively within the formal methods community. For brevity, we only refer to three of them: Jee, Lee, and Sokolsky worked on assurance cases of the pacemaker software [JLS10]. They focused on the basic VVI mode, and employed UPPAAL for both, design and verification. In [TZT10] the authors used timed CSP to specify a number of pacemaker modes and to verify several timing constraints for them. Liu et al. [LDL07] explicitly model a product line of pacemakers and address its safety analysis.
135
3 3.1
The Pacemaker The Human Heart
From a bio-mechanical point of view, the human heart is the pump of the circulatory system. It consists of two atria and two ventricles. The contraction of the heart is initiated at the so-called sinoatrial node (SA node), an area of self-excitable cells within the right atrium known as P wave. The electrical impulses spread through the atria and ventricles with a dedicated timing characteristics (see the electrocardiogram (EKG) shown in Fig. 2), thereby causing the contraction of the chambers. Nowadays, a too low or sporadically missing pulse generation by the SA node, called bradycardia, and defects in the cardiac conduction system are cured by an implanted artificial cardiac pacemaker. Artificial pacemakers have to respect the timing characteristics of the sinus rhythms as they are critical. Foremost, pulses must not be generated within the refractory intervals after depolarization, as this may cause life-threatening cardiac fibrillation.
3.2
Informal Specification of Pacemakers
The most complex pacemakers are variants of the modern DDD mode [Sci07]. Here we consider a family of pacemakers with the aim to build a product line out of them. The functions of a pacemaker are given by a sequence of letters according to the international NASPE/BPEG Code [BDF+ 02]. The simplest pacemakers stimulate the heart, whenever a timer expires without sensing the natural pace. The A00 and V00 mode stimulate either the atrium or ventricle, respectively. The D00 stimulates both, atrium and ventricle. For this, it has two consecutive timers monitoring a modified base interval (BI) and the AV interval (AVI). The AVI is the time between an atrial impulse and a ventricle one. The modified BI of D00 is the time between a ventricle impulse and an atrial one. Todays most common mode is the VVI mode. It only stimulates the heart - in case of the VVI of the ventricle - when the natural pace is missing. The VVI uses a timer for the base interval as well to trigger pulse generation. The BI of the
136
Figure 2: Intervals of pacemaker variants
VVI is the maximal time between two ventricular paces. But the BI is reset if a natural pace of the ventricle is detected and no stimulation takes place in this case. After each artificial or natural pace the pacemaker starts a refractory period in which no detection or stimulation can occur. The pacemaker mode AAI functions analogously for the atrium. DDD means dual pacing, dual sensing, and dual response mode, see the NASPE/BPEG code. A DDD pacemaker senses both right chambers and can also stimulate them both, if no natural pulses are detected. The DDD pacemaker uses two timers for each chamber. The AVI is the time between an atrial pace and a ventricular one, the BI is the time between two atrial paces. Moreover, the DDD mode adapts the AVI (so-called AV hysteresis) for the next cycle, in case a stimulation occurs and it is able to handle a ventricular extrasystole (VES), i.e. an additional ventricle pace occurring in a particular interval. The DDD pacemaker also implements other modes: In case of a battery voltage drop it switches to VVI mode in order to save energy. The D00 mode is also integrated for usage during a magnet test, which may be performed by a doctor to check the pacemaker’s function. The single intervals of each pacemaker are illustrated in Fig. 2.
4 4.1
Creating a Product Line of Pacemakers Pacemaker Modeling Objects
Pacemakers are constructed in several variants, differing in possible features and functions. Furthermore, enhanced pacemakers implement simpler ones as an emergency or diagnostic mode. Thus a product line built from the various modes is helpful to illustrate these relations and even more important to simplify the modeling of the pacemaker modes. In order to create a product line due to [cvl10], first we have to identify the base elements of the pacemaker modes. We start with the simplest modes, the A00 or V00 pacemaker which consist of the same modeling objects. The A00 and the V00 differ only in the length of the base interval which is a single property of a modeling object. So we identify the following three modeling objects which are depicted in Fig. 3: • Timer: starts at zero and increments by one at each cycle • Reset: resets the timer to zero when it reaches the end of the base interval • Output: stimulates the heart chamber whenever a reset occurs Starting with these three base elements we study the D00 pacemaker. For each heart chamber we can reuse the known modeling objects but we have to adapt the timer interval to the atrium ventricle interval (AVI). Furthermore, we decide to rename when doubling the objects because
Figure 3: Schematic use of modeling objects to build an A00 pacemaker
137
of clarity. The timeout of the second timer is set to the sum of the BI and AVI because we can use the reset this way without changes. To model the consecutive order of the BI and AVI interval we insert a new element, the block. It blocks the restart of the AVI timer until the reset of the second timer occurs.
Figure 4: UML model of AAI pacemaker
Next we consider the AAI and VVI pacemaker, respectively. The AAI and VVI pacemaker coincide regarding the modeling objects as well as the base interval. In comparison to the A00 pacemaker we have an additional input to sense the heart’s impulses as a new modeling object and a refractory period which blocks the input. Hence we add an input which triggers the reset whenever a heart impulse occurs. Moreover, an additional timer and reset object for the refractory period are introduced and connected using block objects. The DDD pacemaker can be viewed as combination of two AAI pacemaker models. They are connected by a block object which is used for the AVI timer to wait for the reset of the BI timer. In order to adapt the hysteresis (AVI) and to detect a ventricular extra-systole (VES), we insert a new modeling object called hysteresis which can dynamically change the timeout value in the AVI timer in the DDD pacemaker and a hysteresis object which is connected with the output for the ventricle and the ventricle timer. The final modeling object VES is connected with the ventricular input to detect a natural pace. To regard the time constraints the VES object is also connected with the atrial input block (detect if refractory period is over) and the AVI timer block (detect if AVI timer is stopped). Furthermore, the VES is connected with the atrial reset and the block of the ventricular refractory period.
4.2
Modeling a Pacemaker Product Line with CVL
After identifying the modeling objects which represent single functions of the pacemaker, we model the different pacemakers in UML.We decide to define the AAI model as base model (see Fig. 4) and the models of the other pacemaker modes as library models. These UML models consist of several classes which represent the already defined modeling objects. The FSL of the CVL variability model consists just of the single modes of pacemaker
138
because they represent the different products of our product line. In the PRL we insert several replacements which consist not just of single modeling objects but of whole groups of modeling objects. This is done to keep the associations between the single classes. We derive an A00 pacemaker from the AAI model by eliminating all objects we do not need.
Figure 5: CVL model of pacemaker product line
To build the D00 pacemaker we first eliminate all objects to receive an A00 pacemaker and then we add the D00 library model which includes a V00 model combined with a block element. The DDD pacemaker is built by adding the DDD library model to the AAI base model. Furthermore we have to modify several values like class names and timeout values in the DDD and D00 product line descriptions. Several connections between classes had to be redefined, too, as we combine the base model with each of the library models. The complete CVL model is shown in Fig. 5.
4.3
A Pacemaker Product Line in SCADE
We use the named function structuring of the pacemaker modes again to model them in SCADE. In SCADE we construct a family of data flow models corresponding to the CVL modeling objects. I.e. we employ SCADE as the DSL for the base model. SCADE provides no means to Figure 6: From CVL model to SCADE model build product lines, but we can mimicry the product line modeling by modeling the CVL base elements with their behavior as operators and then reuse them and combine fragments
139
when building the different variants. Hence we start with the simplest pacemaker to ease reuse of already existing parts and operators in more complex ones. An exemplary development starting with a CVL description, generating a UML model und resulting in a SCADE model is shown exemplary for an A00 pacemaker in Fig. 6. So far, we transfer the CVL model manually and do not implement an interface for an automatic transformation from UML or SysML to SCADE because Esterel announced such an interface for the new version SCADE 6.3, to be published in early 2012.
5
The Safety Analysis and Verification
The safety standards [Int06, Com10] prescribe a safety analysis that identifies hazards and traces them back to potential failures. From the identified hazards, system safety requirements are deduced that are capable to eliminate failures or mitigate the effects. Figure 7: Principal architecture of a cardiac pacemaker In consistency with the architectural decomposition of the system (see Fig. 7), the safety requirements are split into subrequirements that are assigned to individual components. This process is iterated until basic software and hardware components are derived that are to be realized and for which evidence has to be provided that they fulfill their safety requirements.
5.1
Safety Analysis
For safety analysis we focus on those hazards and the induced safety requirements that refer to the functional level of the software control of the pacemaker whereas the mechanics, the electrics, and the deployment are analyzed no further. We performed an FTA and an FMEA [IEC06] and formalized it according to the DCCA approach [GOR07]. The resulting safety requirements for the functional level of the software control are as follows: Refractory periods: Within the refractory periods after the atrium (ARP) and ventricle pace (VRP), detection and impulse generation have to pause in that chamber in order to guarantee that neither an artificial pulse is sensed nor disturbances after depolarization are misinterpreted. Time intervals BI, AVI + AVH: The timing constraints as the base interval, the AV interval with the AV hysteresis and their sequencing are respected within specified tolerances. Pacing: An artificial atrium pace is triggered if the base interval expires without sensing a natural P wave. An artificial ventricle impulse is generated iff the AV timer was started and expires without sensing a natural pace there.
140
5.2
Verification of Safety Requirements
As described in Sec. 4 we designed a product line of pacemakers using the S CADE Suite. From the models, C-code is generated automatically by the certified code generator. Next we verify the safety requirements that we derived in the safety analysis. S CADE Design Verifier offers SAT-based model checking of reachability properties [ADS+ 04]. Therefore the predicate has to be encoded in an observer node and connected to the design model. Then S CADE Design Verifier searches through all possible input combinations and traces whether the predicate can be falsified. In case such an input configuration is found, this configuration and its trace yields a witness for the violation of the predicate. If model checking results in a positive answer, the property holds on all reachable states. From the safety analysis we derived eight constraints to be verified. The notation of the constraints is according to the NASPE/BPEG Code including placeholders. x is the placeholder for any possible letter at that position, 0 stands for any possibility except 0. • One pace x00 (mode without sensing) During the base interval, an artificial pace occurs exactly once. • At most one pace x0x (mode with sensing) Within each a specified interval at most one (natural or artificial) pace occurs. • At least one pace If no natural pace is detected in a specified interval, an artificial pace is triggered exactly once. • Atrial pace D0x (D with sensing) A natural or artificial atrial pace takes place only once in the BI and after the end of the AV Interval. • Refractory periods During a refractory period neither a pace detection nor a stimulation occurs. • No VES If no ventricular extra-systole is detected in the specified interval then a natural or an artificial pace occurs exactly once until the end of the BI. • VES If a ventricular extra-systole is detected then no atrial pace is sensed and no artificial pace is triggered during the following BI. • Hysteresis If an artificial pace is stimulated after the AVI, the AVI length is prolonged for the next cycle. We have two constraints for natural paces and two for exactly one pace. This is due to the different requirements of single chamber pacemakers in comparison to dual chamber pacemakers. Furthermore, the constraint One pace x0x is instantiated twice for the verification of the D00 pacemaker. Table 1 presents the verification results. In the columns we list the properties, the pacemaker variants are arranged in the rows. An ”−” indicates that a property doesn’t apply
141
1 pace x00 A00 V00 D00 AAI VVI DDD
0s 0s 0s -
max 1 pace x0x 0s 0s 0s
min 1 pace x0x 0s 1s 1s *
Atrial pace D0x 0s*
Refrac. periods 5379 s 4931 s 242 s*
No VES
VES
Hysteresis
0 s*
204 s*
0s
Table 1: Verification runtimes of the data flow models, * means time intervals divided by 10
on this pacemaker variant. The times indicate the time obtained for a positive proof from S CADE Design Verifier on executed on a Intel Core 2 Duo P9700 2,80 GHz. Most properties could be verified nearly instantly. Only the requirements about the refractory periods needed about one and a half hours. To prove for some of the properties of the DDD pacemaker we rescaled the timing constants by a factor 1:10, because only then we were able achieve verification results in reasonable time. When interpreting the current results we have to compare them to our previous work on the verification of monolithic data-flow-oriented pacemaker models [HB11]. For the previous models we derived the pacemaker variants more informally from each other. But we could not produce any verification results for most properties in a reasonable time by just using S CADE Design Verifier. Only when applying time abstraction by transferring the verification problem to UPPAAL, we could prove them correct. So, design preferences imposed by the product line modeling lead to a better applicability of built-in heuristics to speed up verification. This observation is backed by a manual inspection of the product models: The effort for manually applying abstraction heuristics like cone-of-influence abstraction or symmetry reduction is decreased significantly compared to the models we investigated in [HB11].
6
Conclusion
We have applied CVL as a product line approach to systematically develop a family of safety critical embedded systems, namely pacemakers. We employed the S CADE suite for domain modeling and code generation for the inner control logic, as S CADE is qualified for safety-critical software development due the most relevant safety standards. It turned out that the concepts for variability modeling strengthen a strict design discipline, e.g. decoupling and small interfaces are privileged. As a consequence we observed that efficiency of model checking for the safety requirements is improved significantly - compared to the previous, informally derived pacemaker variants from [HB11]. In short, the concepts introduced for the product line modeling pay off well for verification. The next steps are to integrate SysML as a bridge to S CADE into the CVL framework and further investigations on the interrelation between formally founded product line development and verification.
142
References [ADS+ 04]
˚ ˚ Abdulla, Deneux, St˚almarck, Agren, and Akerlund. Designing Safe, Reliable Systems Using Scade. In Tiziana Margaria and Bernhard Steffen, editors, ISoLA, volume 4313 of LNCS, pages 115–129. Springer, 2004.
[BDF+ 02]
Bernstein, Daubert, Fletcher, Hayes, L¨uderitz, Reynolds, Schoenfeld, and Sutton. The Revised NASPE/BPEG Generic Code for Antibradycardia, Adaptive-Rate, and Multisite Pacing. Journal of Pacing and Clinical Electrophysiology, 25:260 – 264, 2002.
[Com10]
Intern. Electrotechnical Commission. IEC 61508-3:2010: Functional safety of electrical/electronic/programmable electronic safety-related systems Part 3: Software requirements, 2010.
[cvl10]
D2.1.4 Consolidated CVL language and tool. http://www.omgwiki.org/variability/lib/exe/fetch.php?id=cvl tool from sintef&cache=cache&media=d2.1.4 - cvl consolidated sintef v1.0.pdf, 2010. June 2, 2010.
[DHM11]
Daskaya, Huhn, and Milius. Formal Safety Analysis in Industrial Practice. In Gwenn Sala¨un and Bernhard Sch¨atz, editors, 16th Intern. Workshop on Formal Methods for Industrial Critical Systems (FMICS), volume 6959 of LNCS. Springer, 2011.
[Est09]
Esterel Technologies. SCADE Suite KCG 6.1: Safety Case Report of KCG 6.1.2, July 2009.
[GOR07]
G¨udemann, Ortmeier, and Reif. Using deductive cause-consequence analysis (DCCA) with SCADE. In Proc. 26th Intern. Conference on Computer Safety, Reliability and Security (SAFECOMP), volume 4680 of LNCS, pages 465–478. Springer, 2007.
[HB11]
Huhn and Bessling. Towards Certifiable Software for Medical Devices: The Pacemaker Case Study Revisited. In 5th International Workshop on Harnessing Theories for Tool Support in Software, pages 8–14, 2011.
[HMPO+ 08] Haugen, Møller-Pedersen, Oldevik, Olsen, and Svendsen. Adding Standardized Variability to Domain Specific Languages. In Proceedings of the 2008 12th International Software Product Line Conference, pages 139–148. IEEE Computer Society, 2008. [IEC06]
International Electrotechnical Commission. IEC 60812: Analysis Techniques for System Reliability, 2006.
[Int06]
International Electrotechnical Commission. IEC62304: Medical device software Software life-cycle processes, 2006.
[JLS10]
Jee, Lee, and Sokolsky. Assurance Cases in Model-Driven Development of the Pacemaker Software. In Tiziana Margaria and Bernhard Steffen, editors, 4th Intern. Symposium On Leveraging Applications of Formal Methods, Verification and Validation (ISoLA), volume 6416 of LNCS, pages 343–356. Springer, 2010.
[LDL07]
Liu, Dehlinger, and Lutz. Safety Analysis of software product lines using state-based modeling. The Journal of Systems and Software, 80:1879–1892, 2007.
[ORS06]
Ortmeier, Reif, and Schellhorn. Deductive Cause Consequence Analysis (DCCA). In Proc. IFAC World Congress, Amsterdam, 2006. Elsevier.
[Sci07]
Boston Scientific. PACEMAKER System Specification, January 2007.
[TZT10]
Tuan, Zheng, and Tho. Modeling and Verification of Safety Critical Systems: A Case Study on Pacemaker. In 4th Conf. on Secure Software Integration and Reliability Improvement, pages 23–32. IEEE, 2010.
143
!
144
A framework for formal verification of systems of synchronous components∗ Henning G¨unther1 , Ramin Hedayati3 , Helge Loeding2 , Stefan Milius1 , Oliver M¨oller2 , Jan Peleska2 , Martin Sulzmann3 , and Axel Zechner3 1
Institut f¨ur Theoretische Informatik, Technische Universit¨at Braunschweig 2 Verified Systems International GmbH 3 Informatik Consulting Systems AG
Abstract: Large asynchronous systems composed from synchronous components (so called GALS—globally asynchronous, locally synchronous—systems) pose a challenge to formal verification. We present an approach which abstracts components with contracts capturing the behavior in a rely-guarantee style logic. Formal verification of global system properties is then done transforming a network of contracts to P ROMELA/SPIN. Synchronous components are implemented in S CADE, and contract validation is done by transforming the contracts into synchronous observers and using the S CADE Design Verifier for formal verification. We also discuss first experiences from an ongoing industrial case study applying our approach.
1
Introduction
State-of-the-art safety critical systems are often composed of other distributed (component) systems (system of systems (SoS)). While industrial standards for the development of safety-critical software systems highly recommend formal model-based methods, application of those methods to SoS still remains a challenge when scalability to real industrial applications is concerned. In this paper we report on work in progress concerning the development of an approach to modeling and verification of SoS that is innovative for the industrial practice and addresses the scalability problem. In our approach the nodes of a distributed system consist of controllers performing specialized tasks in hard real time by operating cyclically and in a synchronous way. For such a controller the model-based approach of S CADE1 is an attractive solution providing code generation and good support for (formal) verification and test automation. But for a distributed system, a synchronous implementation is neither realistic nor desirable. Hence, we focus on the model based development and analysis of asynchronously communicating embedded control systems that are composed from components that operate synchronously; this is known as a GALS (globally asynchronous – ∗ This
work was developed during the course of the project “Verifikation von Systemen synchroner Softwarekomponenten” (VerSyKo) funded by the German ministry for education and research (BMBF). 1 S CADE is developed and distributed by Esterel Technologies: www.esterel-technologies.com
145
locally synchronous) architecture [Cha84], and it is the preferred solution for complex safety relevant control tasks. The main idea to address the complexity issues of GALS systems is to provide for each synchronous component an abstract model in the form of a contract that can be locally verified for the component (e. g. by S CADE Design Verifier, the formal verification engine of S CADE). The network of component contracts then forms an abstract GALS model against which a system requirement (called system-level verification goal) can be formally verified. This is done by a model transformation of the abstract GALS model into an appropriate formalism/tool for model checking—we use P ROMELA/SPIN for model checking verification goals that do not refer to real time. Later during the course of our work UPPAAL timed automata for real time verification goals will be used. In the following we will describe our framework and the modeling languages for contracts and abstract GALS models (Sec. 2). Then in Sec. 3 we discuss our approach to system validation and give a brief description of the model transformations involved. In Sec. 4 we report about preliminary results using first prototypical implementations of the transformations on an industrial case study. Related Work. Numerous publications are devoted to combining synchrony with asynchrony and the verification of GALS systems (see e. g. [GT09, DMK+ 06, RSD+ 04]) or, less related to our work, to use synchronous modeling towards less synchronous applications (see e. g. [RS00, PBC07], the tool Model Build [Bau99, Bau04], the Polychrony workbench [LGJPJL02] or the work in [HM06, JHR+ 07, MLGT+ 04]). Using contracts as specifications for parts of a program or system is also not a new idea; see for example work on rely/guarantee logic [Jon83]. Abstracting system components by contracts appears recently, for example, in [GV06, GTB+ 03, BM09]. Alur and Hinzinger[AH99] treat the semantics of asynchronous component systems. Main Contribution. What is new in our work is the combination GALS verification with the idea of abstraction by contracts and its application to networks of synchronous S CADE models. In addition, the previous work on GALS systems pertains to systems whose components were designed to interact synchronously but are later integrated asynchronously. In our work we assume that GALS systems are designed to consist of synchronous components that are intended to be composed asynchronously (GALS systems by design). We introduce a specification language for GALS systems as well as domain specific represenations of it, and we design and implement model transformations between our language and appropriate model checking tools (P ROMELA/SPIN and S CADE Design Verifier). A detailed description of the work presented in this paper can be found in the technical report [Ver11].
2
Modeling framework for GALS systems
In this section we describe our modeling framework for GALS systems. Its overall architecture consists of three layers as shown in Fig. 1. The top layer contains domain specific modeling languages for the end-user to specify GALS systems. We describe one such language, the Contract Domain Specific Language (CDSL) in Subsec. 2.1. The middle layer is formed by the GALS Translation Language (GTL). As described in Subsec. 2.2,
2
146
Domain specific modeling 1
Domain specific modeling k
...
Ac trado Liquidus suffragium. Dito abeo solum captus fastigate, se Contentus gaza eduro redigo, se Cuneus aura stupeo tam ac Despero sedulo de Agrarius. Solito nego sepulcrum vos Ergo nam ualeo lex desero. Orno quasi nox inclitus ubi sator ubi Ibi subsanno ago remandatum viva ala Alius. Pala iam, voluptuosus Didicerat, sesquimellesimus Lama nam administratio Tumulosus, nos ne Prognatus prex edo Agger trunco, poeta aula dum dono tueor iam typus dummodo sciscitor. Faber for Neglectum ut heu do infrequens, profiteor ius Perpetuus stilla seu pax sufficientia jus far rego promus per fragilitas iur.
SCADE component 1
... SCADE component n
GALS translation language (GTL)
PROMELA UPPAAL
SCADE model
PROMELA SCADE UPPAAL observer
Test case generation
GALS verification
code generator
SCADE Design Verifier
simulation
C code
counterexample test cases
Figure 1: Framework for verification, validation and test of GALS systems
the GTL serves as a stable textual core language so that (1) on top of it one can define extensions and user friendly graphical representations tailored towards system engineers or certain application domains and (2) model transformations to test automation and formal verification engines are easy to define and may remain stable when languages at the top level are newly defined or changed. The bold arrows in the figure indicate model transformations and we describe some of them in Sec. 3. Dashed arrows indicate that each component in the abstract GALS model refers to a concrete synchronous (S CADE) implementation. Due to space constraints we do not describe the transformation of the CSDL to GTL, and the transformation pertaining to test case generation as well as the verification of GALS models using UPPAAL timed automata will be the topic of future work. 2.1
Domain specific contract modeling language for users
Elaborated as a profile of SysML, the CDSL is intended as a means for modeling SoS networks in an abstracted form at the top level of our framework in Fig. 1: nodes are represented by contracts abstracting their behavior in a way that still allows to verify systemlevel goals, but does not introduce the full behavioral information of the detailed model used to develop the node. The graphical high-level description is easier to comprehend than the (equivalent) GTL description, which is elaborated later. For the detailed CDSL description we refer to [Ver11]. A CDSL specification describes an inherently asynchronous network of synchronous components that are connected by interfaces. The network is represented by composite structure diagrams, its nodes by classes or composite structures, as will be explained below. While some nodes in the network may be unique and are therefore represented by sin-
3
147
gleton classes in the CDSL, many nodes may be regarded as multiple instances of the same class. These instances are distinguished by certain parameters (in the simplest case, numerical identifiers) which are specified as class attributes and can be defined via constructor invocation during the instantiation process. Since SoS usually consist of a very large number of nodes, the CDSL model abstraction does not require to draw object diagrams for representation of the SoS network; instead, the composite structures and classes are associated with instantiation rules in a tabular format, showing how many objects are created from their respective classes. This concept is applied to both behavioral objects representing nodes or node components, and interface objects. A contract consists of an interface description (represented by the stereotype defined in UML2) associated with a class or, for more complex nodes, a composite structure. Classes or composite structures specify the behavior of the node in abstracted form. The class, decorated with a contract stereotype which is introduced by the CDSL profile, offers two methods rely(c:computation):boolean and guarantee(c:computation):boolean whose bodies specify the rely and the guarantee parts of the node’s contract. For these specifications (timed) LTL formulas ρ (rely) and γ (guarantee) are used. Their free variables are the attributes defined in the node’s interface. The bodies of the two methods are defined by return (c |= ρ); and return (c |= γ);, respectively. Alternatively the class can be associated with a timed state machine or a decision diagram acting on the interface attributes and, optionally, auxiliary local variables specified as class attributes. This specification style expresses the rely-part of the contract in an implicit way as the set of all possible input sequences of the state machine. The body of the rely() method is now associated with constraint (c ∈ statemachineinputs). The guaranteepart is represented by the state machine’s traces, projected to the input and output attributes of the interface. The body of the guarantee() method is specified as return (c ∈ state machine computations);.
In addition to the rely/guarantee assertions the contract may specify guaranteed behavior, modeled by a method guaranteed(c:computation) : boolean which is also associated with an LTL formula γ � : guaranteed behavior are assertions of specific behavioral situations (“use cases”) which have already been exhaustively verified on component level. This redundant information can be used during system-level verification to uncover flaws in contract specifications or verification goals. More complex nodes may be represented by a hierarchy of composite structure diagrams, with contract classes in their leaf nodes, in order to structure the component’s behavior into sub-component behaviors. The sub-components act synchronously, i.e., run-to-completion steps do not consume time. Data flow between arbitrary elements is captured again by the standard interface concept, where each interface transports one or more typed values. Example. Component GEN in Fig. 2 generates a pair of values (a, b), which is used (asynchronously) by the composite structure PROC to compute RESULT = (a + b)2 . Components ADAPT, and MUL are (synchronous) sub-components of PROC, each instantiated four times. The special parameter id identifies the instance, both for components and for interfaces. ADAPT[id] organizes the input by means of interfaces X[id] and Y[id],
4
148
Figure 2: CDSL specification of system computing RESULT = (a + b)2
such that the four multiplications to be processed by MUL[0] to MUL[3] are a ∗ a, a ∗ b, b ∗ a, and b ∗ b, respectively. The one instance of SUM sums up these intermediate results, which yields finally RESULT = a2 + 2ab + b2 = (a + b)2 . If, for example, GEN[0] provides a guarantee γ: “always a + b = 1”, then system-level verification allows to infer the system property “always RESULT = 1”. 2.2
Textual contract specification language GTL
The GTL is used to specify networks of synchronous components and is intended as a simple textual language serving as a source for model transformations to model checkers and test automation tools. Fig. 3 shows a simplied and abbreviated GTL-specification from the industrial case study in Sec. 4. Each synchronous component is an instance of an abstract model. A model is declared by a name, the synchronous formalism in which it is implemented and formalism-specific information on how to retrieve the synchronous model and its interface description (e. g., the name of the model file), see lines 1 and 8. Inside the curly braces, the user can specify the cycle time of the synchronous model and its contract. Contracts are specified by one ore more LTL-formulas over the input and output variables of the component (line 4). For example, the rely and guarantee parts of a contract in CDSL yield the formula ρ ⇒ γ. In addition, it is also possible to specify contracts by using state machines, which can use local variables to describe the behavior of the model (line 11-21). Models may also specify guaranteed behavior; this is done by LTL formulas following the keyword guaranteed in the model’s body. Components can be declared by creating instances of models, as displayed in line 24-26. Instances may extend the contract of their model by LTL formulas, automata and/or guaranteed behavior. All declared instances can then be connected to a network by connecting input and output variables together (line 27). LTL formulas can be used to specify verification goals. Those formulas can use all in- and output variables of any component in the system (lines 30). It is usually unclear what the successor of a state of a GALS model is, so verification goals will use temporal connectives: the formula specifies that an event must happen no later than two seconds after another event.
5
149
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
model [ s c a d e ] u e b e r w a c h u n g s s i g n a l ( ” t r a i n . s c a d e ” , ” U e b e r w a c h u n g s S i g n a l ” ) { c y c l e t i m e 40ms ; i n i t UmgebungTfZug ’ T f Z u g H a l t b e g r i f f ; a l w a y s Kommando = ’ U e b e r w a c h u n g E n t s i c h e r n => n e x t ( UmgebungTfZug = ’ TfZugHaltbegriff ) ; always ( next . . . u n t i l ( Kommando = ’ U e b e r w a c h u n g E n t s i c h e r n ) ) ) ) ; } model [ s c a d e ] s t r a s s e n s i g n a l ( ” t r a i n . s c a d e ” , ” S t r a s s e n S i g n a l ” ) { c y c l e t i m e 100ms ; local int c ; automaton { init state uninitialized { t r a n s i t i o n [ Kommando = ’ S t r a s s e I n i t and n o t G e s t o e r t ] a u s ; ... } ... state wait { t r a n s i t i o n [ c f i n a l l y [ 2 s ] s t r s i g . Zustand0 = ’ StrasseRotAnGelbAus ) ; ... }
Figure 3: GTL contract specification Level Crossing
3
Validation of GALS systems
In this section we describe how GALS systems are formally verified in our framework. We first explain the general approach to system level verification, and then we outline how various model transformation from the GTL to different analysis tools are used to realize formal verification. 3.1
System-Level Verification Approach
As indicated above, our approach advocates system-level verification along the following lines: (1) System-level verification goals Φ are specified as (timed) LTL formulas expressing the desired behavior of the complete GALS system. (2) The behavior of each synchronous component C is abstracted by its contract ΦC which may be represented by LTL formulas or, alternatively, abstracted models, and, optionally, guaranteed behavior represented again by LTL formulas βC . (3) From the network of contracts an abstract 6
150
GALS model MG is derived, represented by a network of most non-deterministic component processes C � still satisfying the contracts ΦC . (4) The assertion “system satisfies Φ” is verified by property checking MG |= Φ.
The system-level verification result has to be validated with respect to the following verification threats: (VTH-1) the verification failed because the system is inadequate for its purpose, that is, Φ correctly reflects a system requirement, but this is not fulfilled by the designed system. (VTH-2) The verification fails though the system is adequate for its intended purpose (so-called false negative). (VTH-3) The verification succeeds though the system is inadequate for its intended purpose (false positive). (VTH-1) represents a “desired” verification result: the proof of MG |= Φ failed because some or more components C have been inadequately modeled, and this inadequacy has been duly reflected in their contracts ΦC .
(VTH-2) may have 3 root causes: firstly, the verification goal Φ may have been inadequately specified. This situation is most easily uncovered by analyzing the error trace π produced by the model checker as a witness for the violation of MG |= Φ, and determining whether π really reflects undesired system behavior2 . Secondly, a contract ΦC may have been specified too weakly, so that the projection πC of π to the interfaces of C results in a computation which is not a computation of C’s detailed model. This can be discovered by running the projection against a simulation generated from the detailed model of C. As a consequence ΦC has to be strengthened. Instead of elaborating a completely revised version of ΦC it may be helpful to investigate whether πC is inconsistent with the guaranteed behavior βC of C, in symbols: πC �|= βC . In this situation, it suffices to strengthen the contract by adding βC as a conjunct to the original version of ΦC . Thirdly, the contract may be inconsistent to C. This case should have been already detected during contract elaboration, by means of property checking MC |= ΦC .
(VTH-3) reflects the situation where at least one component C is faulty, but this is not detected in the verification of MG |= Φ. This may be caused by a specification error in Φ or by an undetected contract inconsistency masking the faulty behavior of C. The latter case is handled as described for (VTH-2). The former may be uncovered if simulation traces π are generated by exercising model-in-the-loop testing techniques on MG : if a test fails but the associated simulation trace is accepted by π |= Φ, the inadequacy of Φ is revealed. This technique relies on redundant specification of required behavior: instead of just using Φ as a global test oracle, tests are associated with their own specifications of expected results. Again, the guaranteed behavior specifications βC may be applied to strengthen these expected test results. 3.2
Realization by Model transformations
In this section we explain how various analysis tools are used for the validation of GALS systems described in the previous section. This is achieved by using model transformations as indicated by the bold arrows in Fig. 1. Due to space constraints we only describe the translation principles of some translations very briefly, a more detailed account 2 Observe that the abstracted GALS model M operates on the complete concrete interfaces specified for G each component C, so that abstraction only introduces more general behavior, but not abstracted data.
7
151
is in [Ver11]. Local verification of contracts. Contract inconsistencies can be uncovered using local model checking. For a component C implemented by a S CADE model one transforms the contract ΦC into a so-called synchronous observer node in S CADE (cf. [HLR94, HR99, DBCB04]). Each LTL formula contained in the contract is first translated to a state machine using the translation algorithm described by Gastin and Oddoux [GO01]. As a result, for each component C we obtain a set of automata. Then the product automaton is formed to obtain a single automaton describing the behavior specified by ΦC . This automaton is transformed into a S CADE synchronous state machine (cf. [And03]) representing the observer node, and S CADE Design Verifier is used to verify whether MC |= ΦC . Notice that due to restrictions of the Design Verifier, it is only possible to verify contracts with bounded liveness properties. Checking verification goals. In order to verify whether an abstract GALS model MG satisfies a verification goal Φ the network of contracts is transformed into a P ROMELA model. Each contract is transformed into an automaton as described above, and for each contract automaton a P ROMELA process is created. The different processes asynchronously communicate via shared variables that correspond to the connections of input and outputs of the synchronous component; for each connect statement in the GTL model one shared variable is generated in the P ROMELA model (There is no buffering; component outputs of previous cycles are simply overwritten.) In addition, our model transformation creates a scheduler that facilitates the fair synchronous execution of the components: in the P ROMELA model all component start at the same time and then proceed according to their cycle times. If the verification goal Φ is an ordinary LTL formula it can simply be verified whether MG |= Φ by using SPIN. If Φ contains temporal connectives, timers are introduced in the P ROMELA model. For example, the formula φ until[t] ψ holds in a state s of MG if MG , s |= φ until ψ and for every run s = s0 , s1 , s2 , . . . of MG from s a state si with MG , si |= ψ is reached within time t. The formula is translated to (c := t) ∧ ((φ ∧ c ≥ 0) until (ψ ∧ c ≥ 0)); a timer variable c is created which is initialized with time t. Each time a synchronous component (or rather its P ROMELA process) makes a step, the timer c is decremented by the amount of time that has passed since the last step was performed by a (possibly different) synchronous component. Detecting false negatives. The third transformation from GTL depicted in Fig. 1 can be used to validate verification results for an abstract GALS model. Suppose we have MG �|= Φ for a verification goal Φ and the formal verification produces the counterexample trace π. If each component comes with a S CADE implementation, we can check whether this is a real error trace or a false negative as follows: from the GTL specification one generates � which composes the S CADE models of the components by a concrete GALS model MG � on the inputs integrating the C-code generated from them. By using SPIN to simulate MG � from π we can verify whether π is indeed an error trace showing MG �|= Φ, or equivalently, � 3 . π is a legal trace of MG 3 Again, this simulation is possible since M operates on the complete concrete interfaces specified by each G component C (cf. e.g. Fig. 3 line 1)
8
152
Figure 4: Case Study Level Crossing - System Architecture
If so, we have found a real error, and one or several component implementations need to be corrected. To support this process one can project the global error trace π on a local trace πC for each component C, which can be used in the ensuing analysis: from each πC one can generate a S CADE simulator script which can be used to correct the S CADE models of the components. If the simulation finds that π is not a legal trace of the concrete � , then our verification result is a false negative, and one needs to analyze GALS model MG the contracts for weaknesses or inconsistencies.
4
Case studies
We have succesfully tested our approach and the prototypical tools on various small academic examples. We are also developing two real industrial case studies to demonstrate the use of our approach to GALS system verification: the first case study is a cabin smoke detection system of an airplane and the second one is a level crossing system from the railway domain. Due to space constraints we only describe the latter case study here, details concerning the former can be found in [Ver11]. The level crossing in the case study consists of several modules (traffic lights, supervision signals, barriers etc.). An overview of the level crossing architecture is given in Fig. 4. The modules have been implemented as synchronous reactive components of medium complexity within S CADE. The implementation can be found at the VerSyKo project web page. The level crossing fulfills the main requirement to protect the road traffic from the train traffic and vice versa. More detailed user- and system-requirements, on which the implementation is based, can be found in [SZH11]; this provides a more detailed informal description of the level crossing system and the overall system architecture. The user- and system-requirements from [SZH11] need to be verified outside the S CADE environment since the level crossing system has a GALS architecture. In a first experiment we have integrated the C-code generated from some of the S CADE models of the components and used the model checker SPIN for global verification. As expected, this yielded no result due to state space explosion, even using a reduced system model, validating our expectation that it is necessary to reduce state space by providing abstractions of the local synchronous components using contracts. For the level crossing case study we have formulated contracts for each of the components of the level crossing system. This experience shows that it can be non-trivial to define a 9
153
correct and adequate abstraction that is qualified for model checking, and leads to diagnostically conclusive result. It may be necessary to deeply investigate the implementation, and there seems to be no simple automated solution for deriving contracts. However, for the traffic light controller the contract validation has revealed a subtle error in the implementation. For two states in the S CADE model the transition priorities were wrong—in a situation where the model must proceed to a failure state it will instead transition to a different state, this error has been corrected in the implementation. Unfortunately, after this correction S CADE DV did not succeed to verify our contract correct; we only managed to prove correctness for a simplified version of the component’s S CADE model. First experiments with global verification show limitations of our approach to verification of GALS systems in connection with explicit state model checking as in SPIN. To address these problems we currently investigate a different approach using bounded model checking and a model transformation for global verification from GTL to an SMT-solver. Our first experiments using this approach indeed look promising and allow to check the absence of counterexamples to our global verification goals up to a fixed number of steps performed by the abstract GALS model.
References [AH99]
R. Alur and T. Henzinger. 10.1023/A:1008739929481.
Reactive Modules.
[And03]
C. Andr´e. Semantics of S.S.M (Safe State Machine). Technical Report UMR 6070, I3S Laboratory, University of Nice-Sophia Antipolis, 2003.
[Bau99]
P. Baufreton. SACRES: A Step Ahead in the Development of Critical Avoinics Applications (Abstract). In Proc. of HSCC, volume 1569 of LNCS, London, UK, 1999. Springer-Verlag.
[Bau04]
P. Baufreton. Visual notations based on synchronous languages for dynamic validation of gals systems. In CCCT’04 Computing, Communications and Control Technologies, Austin (Texas), August 2004.
[BM09]
T. Bouhadiba and F. Maraninchi. Contract-Based Coordination of Hardware Components for the Development of Embedded Software. In Proc. of COORDINATION, pages 204–224, Berlin, Heidelberg, 2009. Springer-Verlag.
[Cha84]
D. M. Chapiro. Globally-asynchronous locally-synchronous systems. PhD thesis, Stanford University, 1984.
[DBCB04]
S. Dajani-Brown, D. Cofer, and A. Bouali. Formal verification of an avionics sensor using SCADE. In Y. Lakhnech and S. Yovine, editors, Proc. FORMATS/FTRTFT, volume 3253, pages 5–20. Springer-Verlag, 2004.
[DMK+ 06]
F. Doucet, M. Menarini, I. H. Kr¨uger, R. Gupta, and J. P. Talpin. A Verification Approach for GALS Integration of Synchronous Components. Electron. Notes Theor. Comput. Sci., 146:105–131, January 2006.
[GO01]
P. Gastin and D. Oddoux. Fast LTL to B¨uchi Automata Translation. In G´erard Berry, Hubert Comon, and Alain Finkel, editors, Computer Aided Verification, volume 2102 of LNCS, pages 53–65, London, UK, 2001. Springer-Verlag.
10
154
FMSD, 15:7–48, 1999.
[GT09]
H. Garavel and D. Thivolle. Verification of GALS Systems by Combining Synchronous Languages and Process Calculi. In Proc. of SPIN, pages 241–260, Berlin, Heidelberg, 2009. Springer-Verlag.
[GTB+ 03]
H. Giese, M. Tichy, S. Burmester, W. Sch¨afer, and S. Flake. Towards the compositional verification of real-time UML designs. SIGSOFT Softw. Eng. Notes, 28:38–47, September 2003.
[GV06]
H. Giese and A. Vilbig. Separation of non-orthogonal concerns in software architecture and design. Software and System Modeling, 5(2):136–169, 2006.
[HLR94]
N. Halbwachs, F. Lagnier, and P. Raymond. Synchronous Observers and the Verification of Reactive Systems. In Proc. of AMAST, pages 83–96, London, UK, 1994. Springer-Verlag.
[HM06]
N. Halbwachs and L. Mandel. Simulation and Verification of Asynchronous Systems by means of a Synchronous Model. In Proc. of IFIP, pages 3–14, Washington, DC, USA, 2006. IEEE Computer Society.
[HR99]
N. Halbwachs and P. Raymond. Validation of synchronous reactive systems: from formal verification to automatic testing. In Proc. of ASIAN, December 1999.
[JHR+ 07]
E. Jahier, N. Halbwachs, P. Raymond, X. Nicollin, and D. Lesens. Virtual execution of AADL models via a translation into synchronous programs. In Proc. of EMSOFT, EMSOFT ’07, pages 134–143, New York, NY, USA, 2007. ACM.
[Jon83]
C. B. Jones. Specification and design of (parallel) programs. In Proc. IFIP Congress, pages 321–332, 1983.
[LGJPJL02] P. Le Guernic, Talpin J.-P., and Le Lann J.-L. Polychrony for system design. Journal of Circuits, Systems and Computers, 2002. Special Issue on Application-Specific Hardware Design. World Scientific. [MLGT+ 04] M. R. Mousavi, P. Le Guernic, J. Talpin, S. K. Shukla, and T. Basten. Modeling and Validating Globally Asynchronous Design in Synchronous Frameworks. In Proc. of DATE, DATE ’04, pages 10384–, Washington, DC, USA, 2004. IEEE Computer Society. [PBC07]
D. Potop-Butucaru and B. Caillaud. Correct-by-Construction Asynchronous Implementation of Modular Synchronous Specifications. Fundam. Inf., 78:131–159, January 2007.
[RS00]
B. Rajan and R.K. Shyamasundar. Multiclock Esterel: a reactive framework for asynchronous design. In Proc. of IPDPS, pages 201 –209, 2000.
[RSD+ 04]
S. Ramesh, Sampada Sonalkar, Vijay D’silva, Naveen Chandra R., and B. Vijayalakshmi. A Toolset for Modelling and Verification of GALS Systems. In Rajeev Alur and Doron Peled, editors, CAV, volume 3114 of LNCS, pages 385–387. Springer Berlin / Heidelberg, 2004.
[SZH11]
M. Sulzmann, A. Zechner, and R. Hedayati. Anforderungsdokument f¨ur die Fallstudie Bahn¨ubergangssicherungsanlage. Technical report, ICS AG, 2011.
[Ver11]
Contract Specification and Domain Specific Modelling Language for GALS Systems, An Approach to System Validation. Technical report, ICS AG, Verified Systems International GmbH, TU Braunschweig, 2011. Available at www.versyko.de.
11
155
!
156
Components and Contracts: A Semantical Foundation for Compositional Refinement Hardi Hungar∗ Carl von Ossietzky University Oldenburg, Germany
[email protected]
1
Overview
To develop a complex system which involves information processing, perhaps embedded into a physical enviroment, is a nontrivial task, which needs to be structured into several steps. The design will evolve, getting more precise as detail is added, and will be distributed into interacting parts, which themselves will be further elaborated until a working implementation is generated as the final result. For this implementation to meet the requirements, it is important to have clear notions of refinement and decomposition. Refinement means that a unit in design gets described with more accuracy. Sometimes, this just consists in adding detail. In other cases an abstract or conceptual point of view gets replaced by one which is closer to its technical realization so that the change is of a more fundamental nature. Decomposition introduces a level of interconnected subsystems whose collaboration shall provide all that is required of the decomposed unit. These parts—if they are already available components used in a new context—then become objects of design activities themselves and get refined or decomposed. And of course the activities on the parts should be largely independent of each other, to simplify work by limiting the required focus of attention, and to be able to perform development in a distributed fashion. And when a part is replaced by another meeting the part’s original specification, this change should not affect the correct functioning of the composed system. This sketches the landscape of what we call compositional design. The central notion is that of a component—every design entity at each stage of development, from the full system down to an atomic part of the final implementation—is called by that name. Design consists in creating components, describing them and relating them to previously designed ones. Means of descriptions may be manyfold. In this work, we consider explicitly two forms, operational ones in the form of behaviors, provided e. g. by models, and declarative ones, given as specifications. These two forms are related by explaining their meaning in a common semantical domain of traces. The trace semantics permits to directly relate behaviors and specifications: If all traces of the behavior of a component adhere to its specification, the component is correct. Sim∗ The work has been funded by the German Federal Ministry of Education and Research (BMBF) as part of the project “Software Plattform Embedded Systems 2020”, Grant No. O1|S08045 W while the author was employed at OFFIS, Institute for Information Technology, Oldenburg. The responsibility for the content rests with the author.
157
ilarly, refinement is explained as trace inclusion—the refined component should be described more precisely, with less ambiguity. When the level of abstraction changes significantly, or the viewpoint gets more technical, refinement must be generalized to a relation of realization, where data types get changed, or structures permuted, or communication concepts replaced. It is shown that if sufficiently good specifications of the new components are available, all these design steps can be checked on the level of specifications, i. e. enabling virtual integration. A distinguishing feature of the approach exposed in this work is that behaviors as well as specifications consist of two parts, a (so-called strong) assumption, which spells out requirements on the usage context of the component, and a promise, which describes how the component behaves if the strong assumption is met. The intended meaning of the strong assumption is to define conditions under which the modeling of the component is reliable. If the occurrence of phenomena not existing on a certain level of abstraction or not represented in the world of a particular model can be excluded by giving certain extra conditions on available observables, collecting them in a strong assumption provides a way to simplify descriptions without sacrificing accuracy. The notions of refinement and realization take this specific nature of strong assumptions into account, and the relation between the strong assumption of a composition and those of its parts is characterized in a formal way. Many of the concepts and ideas presented here have their root in the results of the SPEEDS project [SPE07] (Speculative and Exploratory Design in Systems Engineering, EU, 6th Framework), and draw on classic research on compositionality, see e. g. the overview in [dR97], as well as more recent ones [BCP09]. Current activities, to which this work contributes, are performed within the projects CESAR (Cost-Efficient methods and processes for SAfety Relevant embedded systems, ARTEMIS JU) and SPES 2020 (Software Platform Embedded Systems 2020, Federal Ministry of Education and Research, Germany).
2
Main Definitions and Results
Definition 1 (Variables, Formulas, Specifications) 1. X is a set of variables, x, y ∈ X . The set of ports P is a subset of X . An interface I is a finite set of ports. 2. F is the set of formulas. 3. A specification is a pair of formulas H = (A, F ) with strong assumption A and promise F . Definition 2 (Implementation, Behavior) 1. The set of implementations M(I) are atomic operational descriptions, e. g. models (for the interface I). 2. A behavior is a pair N = (A, M ) of a strong assumption A and an implementation M . The strong assumption may be a formula from F(I) or again an implementation from M(I).
158
3. A component over I is a tuple U = (I, H, B), where H is a specification and B is either a behavior or a composition. 4. A composition is U0 = I0 ,L kni=1 Ui is given by an (external) interface I0 , parts Ui with interfaces Ii and connectors L linking ports of the parts and the external interface. For ease of exposition in this abbreviated presentation, we will ignore most issues related to connections and corresponding renamings and assume that connected ports have the same name. Definition 3 (Traces, Semantical Domain, Refinement) 1. T is the set of points in time, V is the domain of values the variables may take. 2. The set of traces S is a subset of [X → [T → V]]. 3. S 2 =def P (S) × P (S) is the set of assume-promise pairs (AP pairs). 4. [[(Σ, Υ)]] =def ΣC ∪ Υ is the trace extract of an AP pair. 5. (Θ, Ξ) ∈ S 2 refines (-) (Σ, Υ) if [[(Θ, Ξ)]] ⊆ [[(Σ, Υ)]] and Θ ⊇ Σ. 6. The parallel composition of a set of AP pairs is defined as: \ [ \ kni=1 (Σi , Υi ) =def Σi ∪ (Σi ∩ ΥC ), Υi i i
i
i
The first component of an AP pair is the strong assumption, and the trace extract interprets a pair like an implication: Either the assumption is violated, or the promise is kept. The first condition in the definition of refinement is the common reduction on the set of possible traces (becoming more constrained). The second condition reflects the additional role of the strong assumption as defining the scope where the description is reliable: A refining entity must be at least as reliable as the refined one. Similar consideration guide the definition of the semantics of the parallel composition. Definition 4 (Semantics) 1. The semantics of implementations and formulas are sets of traces [[M ]] and [[F ]]. 2. The semantics [[[(Z1 , Z2 )]]] of a specification Z = (A, F ) or a behavior Z = (A, M ) is the AP pair ([[Z1 ]], [[Z2 ]]). 3. The semantics of a composition is given by [[[kni=1 Ui ]]] =def kni=1 ([[[Ui ]]]) 4. A component U = (I, H, B) is correct if [[[B]]] - [[[H]]]. Proposition 5 (Main Properties)
159
1. Refinement is a preorder, i. e. reflexive and transitive. 2. Parallel composition is monotonic w. r. t.. the refinement preorder, i. e. Ui - Vi ⇒ kni=1 Ui - kni=1 Vi . 3. If the parts of a composition are correct, and the main specification follows from the composition of their specifications, the composition is correct. Ui - Hi ∧ kni=1 Hi - H ⇒ kni=1 Ui - H Item 3. is the virtual integration mentioned in the overview section, which enables distributed development. It suffices to ensure that the final implementations of the parts meet their specification for the full design to be correct. This relies mainly on the monotonicity of the parallel operator w. r. t. refinement (Item 2.). Refinement is an adequate relation as long as a particular point of view on the design and a particular level of abstraction is kept fixed. But a significant change, which inevitably will happen in every complex development, calls for a more general notion. This will be studied in the ensuing section.
3
Realization
While (de)composition relates different levels of hierarchy, a change between perspectives or levels of abstraction calls for a more general semantical relation. We introduce representations and abstractions as formalizations of respective design steps. Representations go from abstract design entities to more concrete ones, and abstractions go the opposite way. Definition 6 (Representation and Abstraction) Let P and Q be sets of ports. 1. A representation function ρ from P to Q is a monotonic function ρ : P (S(P )) → P (S(Q)) with an associated domain dom(ρ) s. t. ρ({σ}) 6= ∅ for σ ∈ dom(ρ) . 2. An AP pair (Θ, Ξ) ∈ S 2 (Q) realizes (Σ, Υ) ∈ S 2 (P ) w. r. t. ρ, denoted by (Θ, Ξ) -ρ (Σ, Υ), if Σ ⊆ dom(ρ) and ρ(Σ) ⊆ Θ and [[(Θ, Ξ)]] ⊆ ρ([[(Σ, Υ)]]) . 3. An abstraction function α from Q to P is a monotonic function α : P (S(Q)) → P (S(P )) . 4. An AP pair (Θ, Ξ) ∈ S 2 (Q) realizes (Σ, Υ) ∈ S 2 (P ) w. r. t. α, denoted by (Θ, Ξ)α - (Σ, Υ), if Σ ⊆ α(Θ) and α([[(Θ, Ξ)]]) ⊆ [[(Σ, Υ)]] . Obviously, realization is a generalization of refinement—one may simply take identity as representation or abstraction function. Representation and abstrction in the form above are very general. In usual application scenarios, these functions on trace sets will be induced from more restricted forms of mappings. We spell out and discuss possibilities for representations. Abstractions are a largely dual concept.
160
Definition 7 (Levels of Modularity of Representation) Let P and Q be sets of ports. 1. Value Functions: Let ρ : V →part V be a partial function on the value domain. This induces a representation function with dom(ρ) =def {σ ∈ S(P ) | ∀t ∈ T , p ∈ P. ρ(σ(t)(p)) defined)} . 2. Evolution Functions: Let ρ : E →part E be a partial function on the domain of evolutions. This induces a representation function with dom(ρ) =def {σ ∈ S(P ) | ∀p ∈ P. ρ(σ(p)) defined)} . 3. Trace Functions: Let ρ : S(P ) →part S(Q) be a partial function on traces. This induces a representation function with dom(ρ) =def {σ ∈ S(P ) | ρ(σ) defined)} . 4. Multiple Evolution Functions: Let {P1 , . . . , Pm } and {Q1 , . . . , Qm } be partition 0 of P and Q, resp., and let {E1 , . . . , Em } and {E10 , . . . , Em } be corresponding evolu0 tions. Representations ρi : Ei →part Ei for each of the m blocks of the partition give rise to a representation by a trace function (ρ1 × . . . × ρk ) . Value functions are the simplest form of representation. If totally defined, they are easy to handle and differ barely from refinements. But very often, they are partial, for instance when an abstract data type like (mathematical) integers gets replaced by implementations like 32-bit numbers. Then, the strong assumption must rule out that the design ever encounters an overflow, or the overflow must be modeled explicitly on the abstract level, in order that the lower-level design realizes the abstract one. With an abstraction function, one might have to take care of error flags (e. g. NaN, “not a number”) in a similar way. Value function do not permit a reshuffling of values transmitted over a connector. The more general evolution functions are able to handle that. Trace function, still more general, cover fairly liberal changes of interface (e. g., number and types of channels) and timing. But still the relation between abstract and concrete level is a functional one. This can be relaxed by resorting to functions on trace sets. Or, to obtain modularity, by using relations between values, evolutions or traces. Such means might give good descriptions of the relation between abstract and concrete behavior. If computations on the concrete level are imprecise, for instance, if ideal reals get replaced by floating point numbers, the behavior on the concrete level will differ from the abstract one. To retain correctness, the specification on the abstract level must be permissive enough. This may be formalized by showing that an adequately relaxed (according to the representation) abstract level still satisfies its specification. We do not detail this approach further, here, but give another example. The main motivation for using modular definitions of representations or abstractions is to be able to relate decompositions from the abstract level or perspective with similar concrete decompositions, i. e., having a finer view on realization than the general one from Def. 6. We demonstrate the kind of result which can be achieved with “multiple evolution functions”: These can cope with type changes, channel splitting and retiming at the same time, and maintain a kind of modularity which should be useful.
161
Theorem 8 (Compositional Realization) Let U0 = (I0 , Ui , i = 1, . . . , n , L) and V0 = (J0 , Vi , i = 1, . . . , n , K) be compositions. Let {L1 , . . . , Lm } be a partition of L s. t. in each block Li , the sources of all connectors are in some Iji , and the targets in some Iki . Let {K1 , . . . , Km } be a similar partition of K, with Ki connecting Jji and Jki . Let ρi : S(Li ) → S(Ki ) be representations and αi abstractions on the connectors in the partition blocks. Then (ρ1 × . . . × ρk ) and (α1 × . . . × αk ) give rise to a representation ρ of the connectors of U0 , and an abstraction α of the connectors of V0 . Then the following hold. ! m ^ Vi -ρ Ui ⇒ V -ρ U (1) i=1 m ^
! Viα - Ui
⇒
V α- U
(2)
i=1
This theorem is the result of transferring concepts known from data reification (see e. g. [RE98], for a different usage of these concepts [Bro98]) to the domain of trace semantics. Representations or abstractions provide a way to relate different views of a system in a meaningful way. However, the representation resp. abstraction function must be chosen with care. It is, in general, possible that the mapping “does part of the work”, i. e., that part of the functionality present on a particular design level gets coded into a representation function. Since contracts and models are subjected to the same function, this might escape notice. Usually, this will not happen, for instance, if a modular function is used to translate between different formats—then it is quite obvious what is done by the representation function and what by the components. But nevertheless, representations and abstraction should be designed carefully.
References [BCP09] Albert Benveniste, Benoˆıt Caillaud, and Roberto Passerone. Multi-Viewpoint State Machines for Rich Component Models. In Pieter Mosterman and Gabriela Nicolescu, editors, Model-Based Design of Heterogeneous Embedded Systems. CRC Press, 2009. [Bro98] Manfred Broy. A Functional Rephrasing of the Assumption/Commitment Specification Style. Formal Methods in System Design, 13(1):87–119, 1998. [dR97]
Willem-Paul de Roever. The Need for Compositional Proof Systems: A Survey. In Willem P. de Roever, Hans Langmaack, and Amir Pnueli, editors, Compositionality: The Significant Difference, (Int. Symp. COMPOS 97), volume LNCS 1537, pages 1–22. Springer, 1997.
[RE98]
Willem-Paul de Roever and Kai Engelhardt. Data Refinement: Model-Oriented Proof Methods and their Comparison. Cambridge University Press, New York, NY, USA, 1998.
[SPE07] SPEEDS. SPEEDS Core Meta-model Syntax and Draft Semantics, 2007. SPEEDS D.2.1.c.
162
