Bild: v.l.n.r. Andreas Willert, Alexander Huwaldt, Stephan Roth, Tim Weilkiens und Jürgen Mottok
Tim Weilkiens ist Vorstand und Trainer der oose Innovative Informatik eG. Seine thematischen Schwerpunkte sind die Modellierung von Systemen, Software und Unternehmen. Er ist für oose Repräsentant bei der OMG und u.a. Koentwickler des Zertifizierungsprogramms OCEB und OCEB2.
Alexander Huwaldt ist Geschäftsführer der SiSy Solutions GmbH, seit 2007 als UML Professional nach OMG-Standards zertifiziert und in der Softwareentwicklung tätig. Er ist Hochschuldozent für Mikrocontrollerprogrammierung, Software Engineering, UML, SysML und BPMN.
Prof. Dr. Jürgen Mottok lehrt Informatik an der Hochschule Regensburg. Seine Lehrgebiete sind Embedded Software Engineering, Real-Time Systems, Functional Safety und IT-Security. Er ist in Programmkomitees zahlreicher wiss. Konferenzen vertreten.
Stephan Roth ist Trainer und Berater bei der oose Innovative Informatik eG. Seine Schwerpunkte sind modellbasiertes Systems und Software Engineering, Softwaredesign und Softwarearchitektur sowie Software Craftsmanship und Clean Code Development.
Andreas Willert ist Geschäftsführer der Willert Software Tools GmbH und als Trainer, Berater und Coach für Software und Systems Engineering tätig.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Tim Weilkiens
Tim.Weilkiens@oose.de
Alexander Huwaldt
a.huwaldt@sisy.de
Jürgen Mottok
juergen.mottok@oth-regensburg.de
Stephan Roth
Stephan.Roth@oose.de
Andreas Willert
awillert@willert.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: Frank Heidt
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print978-3-86490-524-7
PDF978-3-96088-593-1
ePub978-3-96088-594-8
mobi978-3-96088-595-5
1. Auflage 2018
Copyright © 2018 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
»Grau, teurer Freund, ist alle Theorie
und grün des Lebens goldner Baum.«
Faust – Der Tragödie erster Teil
(Johann Wolfgang von Goethe, 1749 – 1832)
Wir, die Autoren dieses Buches, sind überzeugt davon, dass die Modellierung von eingebetteten Systemen zu erfolgreichen Projekten führt und viele Probleme, die wir in Projekten beobachten, lösen kann. Gleichzeitig sehen wir, dass Modellierung häufig nicht oder ungünstig eingesetzt wird. Vor etlichen Jahren haben wir uns vorgenommen, dem entgegenzuwirken. Aus dem Impuls heraus ist das Manifest »Modeling of Embedded Systems« (www.mdse-manifest.org) sowie die nicht kommerzielle Konferenz »Modeling of Embedded Systems Conference« (MESCONF, www.mesconf.de) entstanden.
Schnell waren wir uns einig, dass wir unser Wissen und unsere Erfahrung in einem Referenzwerk zu Verfügung stellen wollen. Wir haben aus unserer langjährigen Projekterfahrung mit kleinen, mittleren und großen Projekten in diesem Buch wesentliche Aspekte der methodischen und systematischen Anwendung von Konzepten, Methoden, Techniken und Werkzeugen des Software Engineering von eingebetteten Systemen zusammengefasst. Wir wenden uns damit an Leser, die bereits über Kenntnisse in der Softwareentwicklung und Programmierung verfügen.
Der Inhalt bezieht sich speziell auf den Entwurf und die Realisierung von Mikrocontrollerlösungen und orientiert sich damit an den Bedürfnissen der Entwicklung von eingebetteten Systemen. Wir erörtern somit wichtige Aspekte der Softwareseite des Embedded Systems Engineering.
In den Inhalt dieses Buches flossen ebenfalls die Anforderungen und Erfahrungen aus unserer Lehrtätigkeit an Berufsakademien, Fachhochschulen und Universitäten ein. Gerade hier liegt ein Spannungsfeld: Die Ausbildung von Informatikern über Elektrotechniker bis zu Mechatronikern wird mehr und mehr zur Herausforderung. Dem Informatiker wird viel Softwaretechnik in einer zunehmend von der Hardware abstrahierten Welt und faktisch keine Elektrotechnik vermittelt. Dem Elektrotechniker wird naturgemäß viel Wissen über Elektrotechnik und Elektronik mit auf den Weg gegeben, aber für die besonderen Belange der Softwareentwicklung, obwohl oft hardwarenah vermittelt, fehlt die Zeit zur notwendigen Vertiefung. Mechatroniker klagen sowieso über die ungeheure Stofffülle zwischen Mechanik, Hydraulik, Pneumatik, Elektrotechnik und Informatik.
Oft wird Software Engineering und die in diesem Diskurs angebotenen Techniken und Werkzeuge der Modellierung als nett, aber in dem Bedürfnis, endlich seine Ideen in Quellcode umzuwandeln, als hinderlich angesehen. Das »Rush to Code«-Syndrom ist weit verbreitet (und auch allzu menschlich). Gleichzeitig vertreten wir den Standpunkt, dass eine Technik nur dann von praktischem Nutzen ist, wenn die Arbeitsergebnisse des einen Schritts in geeigneter Form im nächsten Arbeitsschritt möglichst direkt weiterverwendet werden können und von geeigneten Werkzeugen unterstützt werden. Das wird in theoretischen Abhandlungen nicht erlebbar. Deshalb basieren dieses Buch und der Lernerfolg auf der praktischen Anwendung des Vorgestellten und einer konsequenten Werkzeugnutzung.
Wir haben das Buch gemeinschaftlich geschrieben und dazu viele spannende Workshops und Diskussionen durchgeführt. Obwohl es im Autorenteam unterschiedliche Schwerpunkte und Sichtweisen gibt, konnten wir mit diesem Buch die verschiedenen Puzzleteile zu einem gemeinsamen Bild zusammensetzen.
Wir sehen es als einen kontinuierlichen Prozess, die Methoden, Techniken und Werkzeuge immer weiterzuentwickeln, zu optimieren und an die sich stetig ändernde Welt anzupassen. Dieses Buch ist allerdings naturbedingt statisch. Zukünftige Auflagen werden diese Entwicklung widerspiegeln und Sie können dem Prozess beispielsweise auf der MESCONF oder anderen Veranstaltungen der Community folgen.
»Wir lernen, was wir tun.«
John Dewey
Mai 2018
Tim Weilkiens
Alexander Huwaldt
Jürgen Mottok
Stephan Roth
Andreas Willert
1Einleitung
2Basiswissen
3Modellbasierte Softwareprozesse und Toollandschaften
4Modellbasiertes Requirements Engineering
5Modellbasierte Architekturbeschreibung
6Modellbasiertes Softwaredesign
7Modellbasiertes Testen
8Integration von Werkzeugen
9Modellbasierte funktionale Sicherheit
10Metamodellierung
11Einführung eines modellbasierten Ansatzes in einer Organisation
12Lebenslanges Lernen
13Fazit
Anhang
AAusblick: Skizze eines Reifegradmodells für MDSE
BKurzreferenz UML und SysML
CGlossar
DLiteraturverzeichnis
Stichwortverzeichnis
1Einleitung
1.1Warum gerade jetzt dieses Buch?
1.2Wie sollte man dieses Buch lesen?
1.3Was ist an eingebetteten Systemen so besonders?
1.4Wie sieht das typische Zielsystem aus?
1.5Fallbeispiele
1.5.1Die Anlagensteuerung
1.5.2Die Baumaschine
1.5.3Das Energie-Monitoring-System
1.5.4Das Beispielsystem SimLine
1.6Das Manifest
2Basiswissen
2.1Was sind eingebettete Systeme?
2.2Software Engineering für eingebettete Systeme
2.3Der Qualitätsbegriff
2.3.1Externe Qualität
2.3.2Interne Qualität
2.3.3Qualitätskriterien nach ISO/IEC 25010
2.4Einführung in Model-Driven Software Engineering
2.5Komplexität
2.6Unser Gehirn als Engpass
2.7Vorgehensweisen und Techniken, um einer steigenden Komplexität zu begegnen
2.8Komplexen Systemen lässt sich nicht mit simplen Methoden begegnen
2.9Verstehbarkeit und Redundanz
2.10Was ist ein Modell?
2.11Modelle helfen, die Zukunft vorwegzunehmen?
2.12Modelle helfen zu abstrahieren?
2.13Resümee: Nutzen von MDSE?
3Modellbasierte Softwareprozesse und Toollandschaften
3.1Klassifikation von Modellierungswerkzeugen
3.1.1Modellierungswerkzeuge der Kategorie A (universelle Malwerkzeuge)
3.1.2Modellierungswerkzeuge der Kategorie B (spezialisierte Malwerkzeuge)
3.1.3Modellierungswerkzeuge der Kategorie C (einfache Modellierungswerkzeuge mit Modelldatenbank)
3.1.4Modellierungswerkzeuge der Kategorie D (vollständiger Zyklus einer Embedded-Software-Engineering-Werkzeugkette)
3.2Vorgehensmodelle
3.2.1SYSMOD Zickzack trifft auf IBM Rational Harmony
3.2.2Spezifikation oder Lösung?
3.2.3Wiederverwendung
3.3Best Practice für kleine Teams
4Modellbasiertes Requirements Engineering
4.1Requirements Engineering
4.2Anforderungen in der Modellierung
4.3Anforderungen und Architektur im Zickzack
4.4Szenario: Modellbasierte Spezifikation mit UML erstellen
4.4.1Überblick über Methode
4.4.2Problemanalyse
4.4.3Basisarchitektur
4.4.4Systemidee und Systemziele
4.4.5Stakeholder und Anforderungen
4.4.6Systemkontext
4.4.7Anwendungsfälle und Aktivitäten
4.4.8Fachwissen
4.4.9Szenarien
4.5Mehr Modellierung: Ausführbare Spezifikation
4.6Weniger Modellierung: Diagramme für Anforderungsdokumente
4.7Neuentwicklung versus Weiterentwicklung
4.7.1Basisarchitektur
4.7.2Anwendungsfälle
4.7.3Szenarien
5Modellbasierte Architekturbeschreibung
5.1Architektur – Was ist das eigentlich?
5.2Die technische Softwarearchitektur
5.3Architekturmuster und deren Bedeutung
5.4Das Laufzeitsystem als Basismuster in eingebetteten Applikationen
5.5Referenzmuster für eine Laufzeitarchitektur
5.5.1Sensorik, Einlesen, Filtern, Bewerten
5.5.2Transformation der Sensorik in Aktivitäten (Verarbeitung)
5.5.3Ausgabe der Daten und Ansteuerung der Aktoren
5.6Fachliche Architektur
5.7Architektur-Assessment
6Modellbasiertes Softwaredesign
6.1Gesichtspunkte der fachlichen Architektur und des Designs
6.2Hierarchische Dekomposition
6.3Diskretisierungs- und Laufzeiteffekte im Design
6.4Softwaredesignprinzipien
6.4.1Was ist ein Prinzip?
6.4.2Grundlegende Designprinzipien
6.4.3Designprinzipien in der Modellierung
6.5Hardwareabstraktion
6.5.1Ausgangssituation
6.5.2Evolution der Mikrocontrollerprogrammierung in C
6.5.3Die klassische Vorgehensweise mit der UML
6.5.4Die graue Theorie
6.5.5Lösungsansätze für die Modellierung
6.5.6Lösungsansätze für die Codegenerierung
7Modellbasiertes Testen
7.1Warum eigentlich testen?
7.2Nicht nur sicherstellen, dass es funktioniert
7.2.1Ein angstfreies Refactoring ermöglichen
7.2.2Besseres Softwaredesign
7.2.3Ausführbare Dokumentation
7.2.4Tests helfen, Entwicklungskosten zu sparen
7.3Die Testpyramide
7.4Test-Driven Development (TDD)
7.4.1Viel älter als vermutet: Test First!
7.4.2TDD: Red – Green – Refactor
7.5Model-Based Testing (MBT)
7.6UML Testing Profile (UTP)
7.7Ein praktisches Beispiel
7.8Werkzeuge, die dieses Vorgehen unterstützen
8Integration von Werkzeugen
8.1Anforderungen an Schnittstellen zu Werkzeugen unterschiedlicher Disziplinen
8.1.1Digital Twin
8.1.2Traceability aus Safety-Gesichtspunkten
8.1.3Projekt- und Workload-Management
8.2Synchronisation der Daten zwischen Repositories
8.3Zentrales Repository
8.4Ein Werkzeug für alles
8.5OSLC – Open Services for Lifecycle Collaboration
8.6XMI – Austausch von Daten innerhalb der Fachdomäne MDSE
8.7ReqIF zum Austausch von Anforderungen
8.8FMI (Functional Mock-up Interface)
8.9SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS)
8.10AUTOSAR
8.11Stand der Praxis
9Modellbasierte funktionale Sicherheit
9.1Funktionale Sicherheit
9.2Entwurfsmuster der funktionalen Sicherheit
9.2.1Zufällige und systematische Fehler
9.2.2Symmetrische und diversitäre Redundanz
9.2.3Architekturmuster
9.2.4Monitor-Actuator Pattern (MAP)
9.2.5Homogenous Redundancy Pattern (HRP)
9.2.6Triple Modular Redundancy Pattern (TMR)
9.2.7SIL-Empfehlung für die Safety and Reliability Design Patterns
9.3Vom Modell zum sicheren Quellcode: Coding-Standards für die sichere Programmierung
9.3.1Normativer Hintergrund
9.3.2MISRA-C und MISRA-C++
9.3.3Prüfwerkzeuge
9.3.4Codegenerierung
9.4Das Safety and Reliability Profile der UML
9.5Praktische Anwendung der Modellierung im Kontext sicherheitskritischer Systeme
9.5.1Beweis der Korrektheit der Transformation
9.5.2Verifikation der Qualität des Werkzeugs
9.5.3Zertifiziertes Framework
9.6Vorteile der modellgetriebenen Entwicklung im Safety-Kontext
9.6.1Traceability
9.6.2Semiformale Spezifikation
9.6.3Normen empfehlen den Einsatz von formalen und/oder semiformalen Methoden und Notationen
9.6.4Automatisierte Transformationen
9.6.5Modellierungsrichtlinien (Guidelines)
9.6.6Dokumentation
9.7Modellgetriebene Entwicklung mit der UML
10Metamodellierung
10.1Modell und Metamodell
10.2UML-Metamodelle
10.3EAST-ADL
10.4AADL
10.5Vergleich EAST-ADL und AADL
11Einführung eines modellbasierten Ansatzes in einer Organisation
11.1Ausgangslage
11.2Vorgehen
11.2.1Problem analysieren
11.2.2Idee und Ziele des Vorgehens
11.2.3Stakeholder und Anforderungen
11.2.4Methodikkontext
11.2.5Anwendungsfälle
11.2.6Fachwissenmodell
11.2.7Verifikation und Validierung
11.3Auswahl der Modellierungssprachen
11.4Auswahl der Modellierungswerkzeuge
11.5Typische Fehler
11.5.1Schnellstart
11.5.2Übergewicht
11.5.3Einsame Insel
11.5.4Elfenbeinturm
11.5.5Aus der Lernkurve fliegen
12Lebenslanges Lernen
12.1Lernen – die Sicht des Konstruktivismus
12.2Kompetenzen – der Blick auf die modellbasierte Softwareentwicklung
12.3Agilität – Lernen mit Methoden und Praktiken
12.4Psychologische Grundlagen von Fehlern
12.4.1Denkfallen als Fehlerursache
12.5Software Craftsmanship – ein Beispiel
12.6Modellierungskultur – ein Kodex
12.6.1Manifest – Modeling of Embedded Systems
12.6.2Big Picture – der Blick auf den Kodex einer Modellierungskultur
12.6.3Moderation – die konstruktive Kommunikation
12.6.4Reflexion – Lernen durch Reflektieren
12.6.5Selbstverpflichtung – selbstgesteuertes Lernen als Entwickler und als Team
12.6.6Teamradar – ein Feedbackbarometer
12.6.7Experten als Teamcoach – Agenten der Veränderung
12.6.8Funktionale Sicherheit – ein Beitrag der normativen Sicherheitskultur
13Fazit
Anhang
AAusblick: Skizze eines Reifegradmodells für MDSE
A.1Hintergrund und Motivation
A.2Die Skizze als ein Start – Diskussionsforum
A.3Ausgangslage Manifest – Ziele kompakt
A.4Die Reifegrade – der Weg in die Modellierungskultur
A.5Evaluation und Fragenkatalog
BKurzreferenz UML und SysML
B.1Eine kurze Geschichte der UML
B.2Aufbau und Architektur der UML
B.3Anwendungsfalldiagramm
B.3.1Akteur
B.3.2Anwendungsfall
B.3.3Anwendungsfallbeziehungen
B.4Aktivitätsdiagramm
B.4.1Aktivität und Aktivitätsparameter
B.4.2Aktion und Pin
B.4.3Kontroll- und Objektfluss
B.4.4Start- und Endknoten
B.4.5Entscheidung und Zusammenführung
B.4.6Splitting und Synchronisation
B.5Klassendiagramm
B.5.1Klasse und Objekt
B.5.2Attribut
B.5.3Operation
B.5.4Assoziation
B.5.5Komposition
B.5.6Generalisierung
B.5.7Signal
B.5.8Datentyp
B.5.9Templates
B.6Kompositionsstrukturdiagramm
B.6.1Konnektor
B.6.2Port
B.7Sequenzdiagramm
B.7.1Interaktion
B.7.2Lebenslinie
B.7.3Nachricht
B.7.4Kombiniertes Fragment
B.7.5Zeitliche Zusicherungen
B.8Zustandsdiagramm
B.8.1Zustandsautomat
B.8.2Zustand
B.8.3Transition
B.8.4Start- und Endzustand
B.8.5Pseudozustand
B.9Paketdiagramm
B.9.1Paket und Modell
B.9.2Pakete importieren
B.9.3Modellbibliothek
B.10Querschnittselemente
B.10.1Kommentar
B.10.2Zusicherung
B.10.3Trace-Beziehung
B.11Profil
B.11.1SysML
B.11.2MARTE
B.11.3UML Testing Profile (UTP)
B.11.4MDESE-Profil (basierend auf SYSMOD-Profil)
CGlossar
DLiteraturverzeichnis
Stichwortverzeichnis
»Aus kleinem Anfang entspringen alle Dinge.«
(Marcus Tullius Cicero, 106 – 43 v. Chr.,
römischer Redner und Staatsmann)
Die Beherrschung von Komplexität ist wohl die größte Engineering-Herausforderung des 21. Jahrhunderts. Software wird der Rohstoff sein, aus dem zukunftsfähige, smarte Systeme erschaffen werden. Software ist schon jetzt ein zentraler Bestandteil unserer Infrastruktur. Täglich kommen wir Menschen – mehr oder weniger bewusst – mit vielen Systemen in Kontakt, in denen Software zentrale Aufgaben übernimmt: Sei es der Fahrstuhl, die Klimaanlage, der Fahrkartenautomat oder das Auto.
Mit dem Internet der Dinge (Internet of Things, IoT) und der vierten industriellen Revolution, sprich: der Zukunftsvision »Industrie 4.0« der deutschen Bundesregierung, wird der Anteil und somit auch der Einfluss von Software auf alle Lebensbereiche des Menschen noch weiter zunehmen.
So wie die Metallverarbeitung eine Schlüsseltechnologie in der industriellen Revolution war, wird Software und Systems Engineering die Schlüsseltechnologie des Informationszeitalters sein.
Im Kontext von Embedded Systems werden sich obige Anforderungen besonders auswirken und modellgetriebene Entwicklung wird hier eine zentrale Rolle im Software und Systems Engineering für eingebettete Systeme einnehmen.
Eingebettete Systeme unterliegen wie jedes IT-System ständigen Innovationen. Moore's Law lässt grüßen. Es gibt jedoch innerhalb der Genesis solcher Systeme immer wieder Umwälzungen, die der scheinbar stetigen Entwicklung sprunghaften Charakter verleihen. Für den Betrachter scheint sich innerhalb kurzer Zeit alles zu ändern. Neue Programmiersprachen, mit denen die Entwickler konfrontiert werden, sind nur die Spitze des Eisbergs. Schaut man aus der heutigen Perspektive auf das Themengebiet Software Engineering zurück (siehe Abb. 1–1), kann die Entwicklung auf drei Umbrüche verdichtet werden.
Abb. 1–1Entwicklung von Software-Engineering-Paradigmen
Dieser stark verdichtete historische Abriss zeigt, dass der zunehmende Komplexitätsgrad an ausgewählten Punkten zu Paradigmenwechseln geführt hat. Es stellt sich die Frage, ob sich das auf eingebettete Systeme übertragen lässt?
Schaut man sich die dominierende Programmiersprache für eingebettete Systeme an, so stellen wir fest, dass sich C seit geraumer Zeit durchgesetzt hat. Nur noch wenige ausgewählte Aufgabenstellungen werden in Assembler realisiert.
Offensichtlich folgte man hier dem Paradigmenwechsel zur Strukturierung. Es lässt sich sogar eine Kenngröße ausmachen, an der man diesen Wechsel festmachen kann. Es ist die Programmgröße für eingebettete Systeme, die Größe des Programmspeichers. Ab 1 bis 16 Kilobyte Programmgröße wird es zunehmend schwieriger, die Aufgabenstellung in Assembler zu lösen. C wurde, obwohl hungriger nach Ressourcen, die adäquatere Programmiersprache für eingebettete Systeme.
Oberhalb der 16 Kilobyte wird nicht mehr ernsthaft darüber diskutiert, das System in Maschinensprache zu programmieren. Für den Paradigmenwechsel zur Objektorientierung lässt sich ebenfalls diese Kennzahl heranziehen. Dieser wurde vollzogen, als die typische Programmgröße deutlich die 1-Megabyte-Grenze überschritten hatte. Spätestens ab 4 Megabyte Hauptspeicher waren alle Diskussionen, ob PC-Programme in C programmiert werden sollen, erledigt. Objektorientierte Programmiersprachen wie C++ und Java haben sich innerhalb kurzer Zeit, zwischen 1990 und 1995, durchgesetzt. Heute verfügen selbst kleine Mikrocontroller wie die ARM-Cortex-M-Familie über mehr als 1 Megabyte Programmspeicher.
Das Buch spannt einen weiten Bogen über das Fachgebiet der Entwicklung eingebetteter Systeme. Die Modellierung ist die Klammer, die die einzelnen Aspekte zusammenhält. Um das Fachgebiet als Ganzes zu verstehen, sollte das Buch kursorisch gelesen werden. Dabei können Details einzelner Aspekte auch übersprungen werden. Die Abschnitte sind in sich so weit abgeschlossen, dass eine zwingende Reihenfolge für die Bearbeitung nicht vorliegt. Für ausgewählte Leser sind einzelne Abschnitte von besonderem Interesse. Diese sollten intensiver studiert werden. Dafür sind im Anhang wichtige Erklärungen zu finden. Für die praktische Anwendung des Gelernten bietet die Webseite zum Buch unter www.mdese.de Werkzeuge, Beispiele und Tutorials an.
Studenten lernen das Fachgebiet Stück für Stück im Überblick kennen und werden für wichtige Aspekte sensibilisiert, deren Inhalte im Studium zu vertiefen sind. Zusammenhänge einzelner Disziplinen werden verstanden und die Möglichkeiten modellgetriebener Technologien können abgeschätzt werden. Dieses Buch ist auch als Nachschlagewerk geeignet.
Entscheider vertiefen ihr Beurteilungsvermögen und werden in die Lage versetzt, moderne modellgetriebene Technologien zu analysieren sowie qualifiziert zu bewerten.
Projektleiter erhalten wichtige Impulse zur Einführung von Modellierungstechniken. Das Verständnis der vorgestellten Technologien ist die Voraussetzung für deren Anwendung. In Kombination mit gesammelter Projekterfahrung gelingt es, für zukünftige Projekte eine neue Synthese mit modellgetriebenen Technologien zu erarbeiten.
Softwareentwickler verstehen den gesamten Prozess der modellgetriebenen Entwicklung und werden in die Lage versetzt, die für sie relevanten Technologien zu beurteilen und anzuwenden. Besonders modellgetriebene Realisierung und Test werden im Detail verstanden.
Hardwareentwickler lernen die Arbeitstechniken der Softwareentwickler kennen und sind in der Lage, mit diesen eine gemeinsame Sprache zu finden.
Eingebettete Systeme haben im Vergleich zu konventionellen Computern, wie unseren Desktop-PCs oder unseren Notebooks, geringe Ressourcen an Speicher und Rechengeschwindigkeit. Es gibt vielfältige Hardwarearchitekturen von 4 bis 64 Bit. Die verfügbaren Systeme bieten Single- und Multicore sowie sehr unterschiedliche Softwarearchitekturen von Bare-Metal-Programmierung über Real-Time Operation Systems bis Multitask/Multiuser-Betriebssysteme an.
Abb. 1–2Programmieradapter und Zielsystem
Der sinnliche Zugang wird für den Neueinsteiger dadurch erschwert, dass diese eingebetteten Digitalrechner als solche meist nicht zu erkennen, also quasi »unsichtbar« sind. Sie verfügen oft weder über gebräuchliche Eingabegeräte wie Maus und Tastatur noch über grafische Displays. Ein Taster und wenige LEDs bilden in vielen Fällen die einzige Mensch-Maschine-Schnittstelle.
Daher erfordert es auch ein spezielles Equipment für die Programmierung. Der Einsteiger muss sich ein Programmiergerät und wenn möglich Debugger-Hardware für das Zielsystem zulegen.
Zusätzlich sind eine spezielle Entwicklungsumgebung und Compiler nötig, die die gewünschte Hardware auch unterstützen. Die verfügbare Literatur ist entweder proprietär auf die Hardware- und Softwarearchitektur sowie die Entwicklungsumgebung des Chipherstellers fokussiert oder so allgemein gehalten, dass die konkrete Anwendung des Gelernten nur schwer möglich ist.
Von der breit angewendeten Softwaretechnologie im Mikrorechnerbereich ist der Biotop der eingebetteten Systeme eher abgeschnitten.
Abb. 1–3Hallo Welt, zwei Welten
So viel zu den Schwierigkeiten bei der Annäherung an eingebettete Systeme. Es gibt auch Erfreuliches zu berichten: Die Komplexität der Hardware eines eingebetteten Systems ist im Vergleich zu den großen Verwandten PCs, Notebooks und Co. oft noch bis auf die Registerebene durch- und überschaubar. Die gegebene Hardware ist in vielen Fällen bis ins Detail durch den Entwickler selbst determiniert. Es bestehen zahlreiche Alternativen zu einer Architektur, die damit eine entsprechende Vielfalt von Lösungsmöglichkeiten konkreter Aufgabenstellungen eröffnen. Die erlangte Kompetenz ist nicht so einfach nachzubilden und kann dadurch für längere Zeit einen Marktvorsprung darstellen.
Dieses Buch fokussiert auf Systeme, die aus softwaretechnologischer Sicht an einem Kipppunkt zu verorten sind. Diese Systeme sind nicht mehr klein, aber auch noch nicht wirklich groß. Sie sind so leistungsfähig und komplex, dass die klassische Entwicklung mit einem Zeileneditor in einer strukturierten Sprache wie C an ihre Grenzen stößt. Es ist sinnvoll, die anstehenden Herausforderungen mit einer modellgetriebenen Entwicklung und in einer höheren Programmiersprache wie z. B. dem objektorientierten C++ zu bewältigen.
Als kleine eingebettete Systeme bezeichnen wir in diesem Kontext Mikrocontroller, meist mit 8-Bit-Verarbeitungsbreite, mit wenigen Kilobyte Programmspeicher und vielleicht maximal 30-MHz-Taktfrequenz.
Abb. 1–48-Bit-Controller im Vergleich zu einer 1-Cent-Münze
Abb. 1–532 Bit ARM Cortex A8 Singleboard Computer
Als große eingebettete Systeme bezeichnen wir 32- bis 64-Bit-Multicore-Architekturen, oft mit grafischem Display, einem entsprechenden Betriebssystem, mehreren Gigabyte Speicher und Taktraten im Gigahertz-Bereich. Letztere sind vielleicht noch eingebettete Systeme, aber keine Mikrocontroller mehr, sondern gehören schon zur Klasse der Mikrorechner.
Die kleinen Systeme sind mit den klassischen Mitteln, also hardwarenah in Assembler oder C, beherrschbar. Für die großen Systeme stehen etablierte Betriebssysteme und standardisierte Plattformen zur Abstraktion von der komplexen Hardware zur Verfügung. Zwischen diesen öffnet sich jedoch zurzeit ein großes Feld von Mikrocontrollern, die zum einen zu komplex sind für die althergebrachte Vorgehensweise und zum anderen zu diversifiziert für standardisierte Betriebssysteme.
Da die Übergänge nicht scharf abgrenzbar sind, soll eine Bandbreite von Systemen angesprochen werden, für die eine modellgetriebene Entwicklung, wie sie in diesem Buch beschrieben wird, praktikabel und kommerziell sinnvoll ist (siehe Abb. 1–6). Die untere Grenze bilden leistungsfähige 8- und 16-Bit-Architekturen mit 16 bis 32 KByte Programmspeicher und 1 bis 30 MHz Taktfrequenz. Als typisches Zielsystem sind 32-Bit-Single-Core-Architekturen mit 32 KByte bis 4 MByte Programmspeicher und bis zu 300 MHz Taktfrequenz anzusehen. Die Obergrenze sollten wir bei 32-Bit-Multicore-Systemen mit vielleicht 1 GByte Speicher ziehen.
Abb. 1–6Bandbreite der Zielsysteme
In dieser Bandbreite können die hier vorgestellten modellgetriebenen Technologien wertvolle Beiträge zur Qualitätsverbesserung und zum betriebswirtschaftlichen Erfolg leisten. Die zur Vertiefung der Buchinhalte angesprochenen und auf der Webseite verfügbaren Beispiele sind für ein Referenzsystem auf der Basis eines 32 Bit ARM Cortex M4 von Infineon konzipiert. Mit 1 MByte Programmspeicher und 120 MHz Taktfrequenz liegt dieses System genau an der kritischen Schwelle, die den Einsatz modellgetriebener Technologien besonders wirksam werden lässt.
Die hier kurz charakterisierten Fallbeispiele beziehen sich auf Projekte, die von den Autoren durchgeführt oder begleitet wurden.
Das Projekt »Anlagensteuerung« ist bei einem mittelständischen Unternehmen mit ca. 100 Mitarbeitern zu verorten. Es werden Lüftungsanlagen in Kleinserien und nach Kundenspezifikation gefertigt. Die Entwicklungsabteilung der Firma besteht aus zwei Elektrotechnikingenieuren.
Für die Steuerung der Anlagen haben die Ingenieure im Laufe der Zeit eine kleine, modulare Hardwareplattform entwickelt. Die Ausstattung der Hardware bietet den Grundbedarf an Sensorik, Aktorik und einfachen Benutzerschnittstellen, die für jede Anlage benötigt werden. Zusätzlich kann die Steuerung mit weiteren Sensoren und Aktoren, grafischem Display, Netzwerkanschluss usw. ausgestattet werden.
Vor der Einführung modellgetriebener Technologien bestand das Hauptproblem darin, dass neue oder kundenspezifische Anlagenvarianten von der mechanischen und elektrotechnischen Seite her innerhalb weniger Tage realisierbar waren. Die Steuerungssoftware aber, sobald die neuen Anforderungen über eine einfache Parametrisierung hinausgingen, war erst nach Wochen oder gar Monaten verfügbar. Die Auslieferung der Anlagen verzögerte sich und Ressourcen (Kapital, Material, Fertigungs- und Lagerplätze) waren unnötig gebunden.
Mit der Einführung modellgetriebener Technologien wurde die Entwicklungszeit der Software so weit beschleunigt, dass diese jetzt in der Regel mit der Fertigstellung der Hardware zeitgleich zur Verfügung steht. Die Wettbewerbsfähigkeit der Firma wurde mit einer deutlich verkürzten Entwicklungszeit (Time-to-Market) entscheidend verbessert.
Ein traditionsreicher Hersteller von robusten Baumaschinen im unteren und mittleren Preissegment sah sich am Markt zunehmendem Wettbewerbsdruck ausgesetzt. Der Verkauf über den Preis konnte nur für begrenzte Zeit die Wettbewerbsfähigkeit erhalten. Als Alternative kam nur eine deutliche Verbesserung der Funktionalität der Baumaschinen infrage.
Die Herausforderung bestand jedoch darin, auf teure Zukaufkomponenten zu verzichten und trotzdem bessere Funktionalität anzubieten. Es wurde die Entscheidung getroffen, in Begleitung durch ein Beratungsunternehmen eine eigene Kompetenz zur Entwicklung von Hydrauliksteuerungen aufzubauen. Dabei wurde von Anfang an auf modellgetriebene Entwicklung gesetzt.
Innerhalb eines Jahres ist es gelungen, eine hauseigene Plattform für Steuergeräte zu entwickeln und vor allem durch modellgetriebene Tests die Konformität mit Normen und Sicherheitsanforderungen begleitend zur Hardwareentwicklung sicherzustellen.
Das Entwicklerteam konnte einen definierten und modellgetriebenen Entwicklungsprozess etablieren. Dabei herrscht ein hoher Grad an Arbeitsteilung. UML-Modelle dienen nicht nur zur Systemgenerierung, sondern auch als normierendes Element in der Kommunikation zwischen den beteiligten Entwicklerteams.
Heute wird ein wesentlicher Anteil der Wertschöpfung des Unternehmens über die Softwareentwicklung erbracht. Verifikation und Validierung neuer Entwicklungen erfolgen bereits auf Modellebene. Nicht nur die Quellcodes und automatisierte Tests, sondern auch weite Teile der Projektdokumentation werden aus den Modellen generiert.
Für die wissenschaftliche Untersuchung von besonders energiesparenden Gebäuden (Passivhäusern) wird eine Vielzahl unterschiedlicher Messwerte benötigt. Es müssen Hunderte Sensoren im und am Baukörper verbaut und vernetzt werden. Dabei kommen über verschiedene Kommunikationsmedien sehr unterschiedliche Protokolle und Datenformate zur Anwendung.
Herstellerspezifische Lösungen für moderne Zählersysteme (Smart Meter) erschweren die Integration. Das System besteht aus zahlreichen einzelnen Controllern zur Datenerfassung, -übertragung und -aufbereitung.
Die Komplexität der Gesamtlösung lässt sich mit folgenden Parametern umreißen: Individuelle, auf mehrere Hundert unterschiedliche Controller verteilte Softwarelösung, die mehr als zwei Millionen Messwerte am Tag erfasst, verarbeitet und an einen Server überträgt.
Die Lösung wurde innerhalb von weniger als drei Monaten durch ein kleines in der modellgetriebenen Entwicklung erfahrenes Team erstellt und automatisiert auf das Zielsystem übertragen. Späte und nachträgliche Anforderungen des Auftraggebers konnten zuverlässig und zügig implementiert werden. Das System wurde und wird in der Einsatzphase ständig an neue Anforderungen angepasst. Die Anforderungen an das System werden durch Akteure, die an der wissenschaftlichen Auswertung der Daten beteiligt sind, immer wieder erweitert.
Es hat sich herausgestellt, dass modellgetriebene Anpassungen zuverlässiger und um ein Vielfaches schneller sind als vergleichbare Lösungen.
Die Liste der Fallbeispiele lässt sich noch wesentlich länger gestalten. Eines ist allen Erfolgsbeispielen gemeinsam: Der zunächst nicht unerhebliche Aufwand für die Einführung modellgetriebener Technologien hat nicht nur zu moderaten Verbesserungen geführt, sondern zu völlig neuen Dimensionen. Die Auswirkungen sind vor allem in der Softwarequalität, der Prozessqualität, der Entwicklungsgeschwindigkeit und der Wartbarkeit der Systeme festzustellen.
Im Buch werden Anwendungsbeispiele anhand eines Referenzsystems erläutert. Dieses Referenzsystem wurde speziell für dieses Buch zusammengestellt und besitzt wichtige Merkmale, die für die genannten Fallbeispiele relevant sind. Zum Beispiel ein grafisches Display wie bei der Anlagensteuerung, ein Fahrzeugbussystem wie in der Baumaschine und Sensorik und Aktorik sowie eine Ethernet-Schnittstelle wie beim Energie-Monitoring-System.
Das Referenzsystem ist das Smart-Home-System SimLine. Es besteht aus einer Plattform, die die Kerninfrastruktur zur Verfügung stellt, um Sensoren und Aktuatoren anzuschließen, die Sensoren auszulesen und über definierbare Regeln die Aktuatoren entsprechend anzusteuern.
Zusätzlich gibt es einzelne SimLine-Sensoren und -Aktuatoren sowie spezielle SimLine-Module mit vordefinierten Regeln, beispielsweise für Einbruch- oder Sturmschutz.
Vertiefende Informationen, Beispielmodelle und Beschaffungsquellen für das SimLine-System finden Sie auf der Webseite zum Buch.
Das Manifest Modeling of Embedded Systems wurde 2015 von mehreren Personen erarbeitet, die überzeugt sind, dass Projekte den steigenden Anforderungen an die Entwicklung eingebetteter Systeme nur gerecht werden können, wenn sie modellbasierte Methoden verwenden. Gleichzeitig sahen die Autoren, dass trotzdem die Modellierung noch sehr verbreitet eingesetzt wird.
Unter den Autoren und Unterzeichnern des Manifests waren auch Autoren dieses Buches. Das Manifest ist somit auch ein Leitfaden für dieses Buch und Sie werden die einzelnen Thesen des Manifests im gesamten Buch wiederfinden.
Das Manifest postuliert 7 Thesen:
Das Manifest wurde erstmals 2015 auf der Konferenz MESCONF (www.mesconf.de) in München vorgestellt. Es ist auf einer eigenen Internetseite www.mdsemanifest.org publiziert und kann von jedem als Zeichen der Unterstützung unterzeichnet werden.
In Anhang A werden die Thesen des Manifests zur Entwicklung der Skizze eines Reifegradmodells für modellbasierte Softwareentwicklung herangezogen.
Legende
Am Ende der meisten Kapitel gibt es eine Zusammenfassung, die in kurzen Stichpunkten eine Art Essenz bildet. Dabei gibt es folgende Kategorien an Stichpunkten, die entsprechend dem Charakter des jeweiligen Kapitels mehr oder weniger ausgeprägt oder nicht vorhanden sind (z.B. hat Anhang B »Kurzreferenz UML und SysML« keine Zusammenfassung).
|
Checklisten: Die so gekennzeichneten Aussagen sind als Checkliste zu sehen. Sie helfen Ihnen, zu überprüfen, ob Sie die essenziellen Konzepte dieses Kapitels berücksichtigt haben. |
|
Hinweise: Die so gekennzeichneten Aussagen weisen noch einmal auf wichtige Aussagen des Kapitels hin. |
|
Warnungen: Die so gekennzeichneten Aussagen weisen explizit auf Fehlentscheidungen/Fehlannahmen hin, die in der Praxis immer wieder anzutreffen sind und deren Auswirkungen erfahrungsgemäß besonders aufwands- oder kostenintensiv ausfallen. |
»Die Wahrheit und Einfachheit der Natur sind immer die letzten
Grundlagen einer bedeutenden Kunst.«
(Paul Ernst, 1866 – 1933, deutscher Essayist, Novellist,
Dramaturg, Versepiker)
Als eingebettete Systeme werden Digitalrechner bezeichnet, die für die Steuerung, Überwachung, Regelung oder für andere Aufgaben, wie z. B. eine Signalverarbeitung, in den räumlich-technischen Kontext der zu erfüllenden Aufgabe integriert sind. Das System stellt mit dem möglichen Benutzer die Umgebung des eingebetteten Systems dar. Die Integration in das System bewirkt, dass der meist recht kleine Digitalrechner (Mikrocontroller) als solcher von außen oft nicht wahrgenommen werden kann. Für die zu erfüllende Aufgabe werden Informationen aus der Umgebung über Sensoren erfasst und verarbeitet, die dann wiederum über Aktuatoren auf das System einwirken. Die Benutzerschnittstellen solcher Systeme sind oft sehr schmal und bestehen mitunter nur aus einzelnen LEDs und wenigen Tastern. Da sich dieses Buch mit modellgetriebener Entwicklung eingebetteter Systeme beschäftigt, soll ein solches auch gleich modellhaft dargestellt werden (siehe Abb. 2–1).
Abb. 2–1Ein vereinfachtes Modell eingebetteter Systeme in ihrer Umgebung
Für ein tieferes Verständnis reicht dieses einfache Modell jedoch nicht aus. Das System selbst verfügt neben dem Mikrocontroller und den Sensoren und Aktuatoren noch über weitere physische Komponenten und steht mit der übergeordneten Umgebung in Wechselwirkung. Solche weiteren physischen Komponenten können z. B. hydraulische oder mechanische Teilsysteme sein. Die physikalischen Größen dieser Wechselwirkungen des Gesamtsystems mit seiner Umwelt sind unter anderem Temperatur, Feuchtigkeit und nicht zu vergessen die elektromagnetische Strahlung. Sensoren und Aktuatoren können nicht nur auf das System, sondern auch auf die Systemumgebung gerichtet sein. Für eingebettete Systeme ist inzwischen die Vernetzung mit anderen Systemen eine Selbstverständlichkeit.
Dieses Buch beschäftigt sich mit der Entwicklung solcher Systeme. Der Softwareentwickler hat seinen ganz eigenen Zugang zum System. Dazu nutzt er Werkzeuge und muss sich an Vorgaben halten. Fassen wir all diese Aspekte zusammen, erhalten wir das folgende Modell (siehe Abb. 2–2).
Abb. 2–2Ein detaillierterer Kontext eines eingebetteten Systems
Dieses Modell soll im Rahmen dieses Buches als Referenzmodell für eingebettete Systeme dienen. Das vollständige Modell finden Sie auf der buchbegleitenden Internetseite. Die einzelnen Modellelemente sind weiter verfeinert. Für das Verständnis der speziellen Problematik eingebetteter Systeme ist es wichtig, zu beachten, dass Embedded Software meistens nicht losgelöst von einer konkreten elektronischen Schaltung im direkten Umfeld des Mikrocontrollers betrachtet werden kann. Software und die zugehörige elektronische Schaltung bilden nur zusammen ein funktionierendes System.
Abb. 2–3
