Skriptums (als )
Werbung
Humboldt-Universität zu Berlin Skriptum zur Vorlesung "Modellbasierte Software-Entwicklung eingebetteter Systeme" Prof. Dr. H. Schlingloff Sommersemester 2014 Stand: 15.05.2016 14:26:00 Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 1 Inhalt 1 Eingebettete Systeme ..................................................................................................................... 3 2 System- und Anforderungsanalyse................................................................................................ 14 3 Modellierung ................................................................................................................................. 31 3.1 Systemmodellierung (SysML) ................................................................................................ 31 3.2 Kontinuierliche Modellierung (Simulink / Scilab) .................................................................. 31 3.3 Diskrete Modellierung (UML) ................................................................................................ 31 4 Codegenerierung und Modelltransformation ............................................................................... 31 5 Hardware für eingebettete Systeme ............................................................................................. 31 6 Sicherheit ....................................................................................................................................... 31 7 8 6.1 Funktionale Sicherheit ........................................................................................................... 31 6.2 Fehlertoleranzkonzepte ........................................................................................................ 31 6.3 Werkzeugqualifikation .......................................................................................................... 31 Validierung .................................................................................................................................... 31 7.1 Modellbasierter Test ............................................................................................................. 31 7.2 Verifikation und statische Analyse ........................................................................................ 31 Spezielle Domänen ........................................................................................................................ 31 8.1 Automotive Software Engineering ........................................................................................ 31 8.2 Medizintechnik ...................................................................................................................... 31 8.3 Automatisierungstechnik, Robotik ........................................................................................ 31 Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 2 1 Eingebettete Systeme Eingebettete Steuerungs-, Regelungs- und Überwachungssysteme sind zum integralen Bestandteil unseres Alltags geworden. Bereits heute gibt es mehr eingebettete Systeme als Menschen auf diesem Planeten. Ihre Funktion wird über immer umfangreichere Softwareanteile mit stark ansteigender Komplexität realisiert. Wir beginnen mit der Definition des Begriffs „eingebettetes System“: Ein System (von griechisch σύστημα) ist nach der Herkunft des Wortes etwas „Zusammengesetztes“, „Verbundenes“. Da absolut alle Dinge dieser Welt aus kleineren Bestandteilen zusammengesetzt sind, dient der Begriff also nicht dazu, eine Klasse von Dingen abzugrenzen, sondern betont den Aspekt eines Objektes, aus anderen Objekten (den Komponenten, „Zusammenzusetzenden“) zu bestehen. Die Norm ISO/IEC 15288:2008 definiert ein System als “a combination of interacting elements organized to achieve one or more stated purposes”; das “Systems Engineering Handbook“ des INCOSE (International Council of Systems Engineering) 1führt dazu weiter aus: [A system is] an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. (INCOSE) Interessant ist, dass beide diese Definitionen nur solche Zusammensetzungen als System bezeichnen, bei denen damit eine Absicht (purpose, objective) verfolgt werden kann. Das bedeutet, es fallen nur solche Systeme darunter, die von Menschen zusammengesetzt sind. In diesem Skript folgen wir dieser Sichtweise, d.h., wir beschäftigen uns nicht mit Ökosystemen, biologischen Systemen, sozialen Systemen oder anderen „natürlichen“ Systemen. Üblicherweise konstruieren Menschen Systeme, damit sie eine Funktion erfüllen. Wir sprechen von einem technischen System, wenn die Funktion des Systems in der Verarbeitung von Materie oder Energie besteht. Unter Verarbeitung verstehen wir die Umformung oder den Transport. Im Gegensatz zu technischen Systemen sind Informatiksysteme solche, deren Funktion in der Verarbeitung von Informationen besteht. Der griechische Philosoph Platon (428-348 v.Chr.) unterschied zwischen der „Welt der Dinge“ und der „Welt der Ideen“. Dabei schrieb er der ideellen Welt einen höheren Wirklichkeitsgrad als der materiellen Welt zu. Die Welt der Dinge besteht aus Materie (oder, nach Einstein, aus Energie), die Welt der Ideen besteht aus Informationen. Technische Systeme funktionieren in der Welt der Dinge, Informatiksysteme funktionieren in der Welt der Ideen. Die Begriffe „Materie“ und „Information“ sind Grundbegriffe, die hier nicht weiter erklärt werden. 1 INCOSE Systems Engineering Handbook v.3.2, A Guide for System Life Cycle Processes and Activities, Jan. 2010 Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 3 Ein technisches System ist ein System zur Verarbeitung (Umformung oder Transport) von Materie / Energie, ein Informatiksystem verarbeitet Informationen. Beispiele für technische Systeme sind: ein Heizkraftwerk (Umwandlung), eine Stanzpresse (Umformung), und ein Bagger (Transport). Beispiele für Informatiksysteme sind: ein Taschenrechner, ein Übersetzungsprogramm, und ein Mobiltelefon. Das letzte der genannten Beispiele weist auf eine Abgrenzungsproblematik hin: Da die Repräsentation von Informationen in der materiellen Welt immer an physische Objekte gebunden ist, enthält jede Informationsverarbeitung zwangsweise auch die Verarbeitung dieser physischen Objekte. Zur Festlegung, ob wir ein System als technisches System oder Informatiksystem bezeichnen, ist also entscheidend, welcher Aspekt überwiegt. Im Falle eines Taschenrechners ist die Einordnung relativ eindeutig; eine Funktionsbeschreibung der Art „Ein Taschenrechner ist ein Gerät zur Umwandlung von Batteriestrom in Licht und Prozessor-Abwärme“ wäre sicher unzureichend. Für ein Telefon ist die Situation nicht so eindeutig: Bei den ersten „Fernsprechern“ ab 1876 überwog der (technische) Aspekt der Umwandlung von Schallwellen in elektrische Signale und zurück, bei der so gut wie keine Informationsverarbeitung stattfindet: Der Spannungsverlauf am Mikrofon oder Lautsprecher entspricht mehr oder weniger genau der Amplitude der entsprechenden Schallwellen. Bei heutigen Smartphones hingegen überwiegt eindeutig der Aspekt der Informationsverarbeitung: Digitalisierung der Signale, Aufteilung in Pakete, Ver- und Entpacken gemäß dem verwendeten Übertragungsprotokoll usw. Die Definition von technischem System und Informatiksystem erlaubt uns, einen der zentralen Begriffe der Vorlesung zu definieren: Ein eingebettetes System ist ein Informatiksystem, welches Komponente eines technischen Systems ist. Lapidar ausgedrückt: Ein eingebettetes System ist ein Computer, der fester Bestandteil einer Maschine ist. Das bedeutet, dass die Informationsverarbeitung für einen spezifischen Zweck in einer technischen Umgebung entworfen, eingebaut und betrieben wird. Aus der Definition ergeben sich einige kennzeichnenden Merkmale eingebetteter Systeme: fester Bestandteil eines technischen Systems Ein eingebettetes System ist oft physisch mit dem Gesamtsystem verbaut, nicht leicht Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 4 austauschbar, von den räumlichen Abmessungen und logischen Kapazitäten auf das technische System abgestimmt. Zweckbestimmtheit Ein eingebettetes System erfüllt im technischen System einen fest vorbestimmten Zweck. Im Gegensatz zu einer universellen Turing-Maschine oder einem Desktop-Computer kann es daher oft nur bestimmte Berechnungen durchführen und lässt sich nicht oder nur in Grenzen frei programmieren. Interaktion mit physischer Umgebung Das technische System, in dass das Informatiksystem eingebettet ist, verarbeitet Materie oder Energie in der physischen Realität. Um mit dieser physischen Umgebung zu interagieren, benötigt das eingebettete System Sensoren und Aktuatoren. Reaktivität, meistens Realzeitabhängigkeit Reine Informatiksysteme sind oft so konstruiert, dass sie nach Berechnung der geforderten Funktion terminieren. Da die Funktion, die ein eingebettetes System erbringt, mit der Gesamtfunktionalität des technischen Systems gekoppelt ist, muss es ständig reaktionsbereit sein und terminiert im allgemeinen nicht (reaktives System). Meist sind für die Berechnung der Funktion äußere Zeitschranken vorgegeben, die mehr oder weniger strikt einzuhalten sind (hartes oder weiches Realzeitsystem). Neben diesen kennzeichnenden Merkmalen gibt es sekundäre Merkmale, die eingebettete Systeme überwiegend, aber nicht immer aufweisen: oft für Regelungs- / Steuerungsaufgaben vorgesehen Meist ist die Funktion, für die das eingebettete System vorgesehen ist, die Steuerung und Regelung des technischen Systems (etwa die Steuerung einer Waschmaschine). Es gibt aber durchaus auch eingebettete Systeme, die nicht für die Steuerung des technischen Systems benötigt werden (z.B. ein Messdatenerfassungsgerät). häufig Massenware Eingebettete Systeme sind oftmals in Konsumgüter eingebaut, und müssen daher billig hergestellt werden. Als Beispiel seien hier Steuergeräte im Auto genannt, bei denen im 0,01€-Bereich optimiert wird: bei 1.000.000 produzierten Stück bedeutet eine Kostenreduktion um 1ct eine Ersparnis von 10.000€! vielfach schlecht bzw. nicht wartbar und nicht erweiterbar Da das eingebettete System zusammen mit dem technischen System vertrieben wird, ist ein „Software-Update“ oft nur mit großem Aufwand oder gar nicht durchführbar (Beispiel: Waschmaschinensteuerung, Mars-Roboter); in vielen Fällen lohnt es sich auch einfach nicht, ein eingebettetes System zu warten (Beispiel elektronisches Spielzeug). Da das eingebettete Informatiksystem auf den speziellen Einsatzzweck zugeschnitten ist, ist es in den allermeisten Fällen nicht möglich, die Funktion wie bei Desktop-Software nachträglich zu erweitern („Version 2.0“). vielfach unverzichtbar, manchmal auch sicherheitskritisch Auf Grund der gestiegenen Leistungsfähigkeit elektronischer Informatiksysteme ist eine wesentlich bessere Regelung als mit mechanischen Komponenten zu erreichen; dadurch werden eingebettete Systeme notwendige Bestandteile der technischen Geräte die sie steuern. Zum Beispiel ließen sich die heutigen Abgasnormen für PKWs ohne eingebettete Motorsteuergeräte gar nicht mehr erfüllen. Zunehmend erfüllen eingebettete Systeme auch Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 5 sicherheitskritische Aufgaben (im Auto z.B. ABS, ASR, ESP, usw.), so dass ein Ausfall fatale Konsequenzen haben kann. zunehmend auch vernetzt Seit etwa einem Jahrzehnt ist der Trend zu beobachten, dass eingebettete Systeme mit anderen solchen Systemen kommunizieren, um im Verbund eine neue Leistung erbringen zu können. Man spricht hier auch von cyber-physischen Systemen (siehe unten). Wenn eingebettete Systeme überall in der menschlichen Umgebung zu finden sind, spricht man auch von ubiquitären Systemen. Typische Beispiele für eingebettete Systeme sind: die Lageregelung einer Ariane-Rakete das TCAS (Kollisionsvermeidungssystem) eines Airbus die ETCS-OBU (On-board-unit) eines ICE ABS, ESP, GRA, Motorsteuerung, … im Automobil die Temperaturregelung in einem Kraftwerk die Steuerung einer Stanzpresse ein Fahrradcomputer ein Herzschrittmacher Innenansicht einer Motorsteuerung aus einem Golf III TDI; Quelle: Wikipedia Man schätzt, dass in Deutschland jeder Mensch ca. 20 eingebettete Systeme besitzt und täglich die Funktion von 50-100 verschiedenen eingebetteten Systemen benutzt. Die „Nationale Roadmap Embedded Systems“ des ZVEI (Zentralverband Elektrotechnik und Elektronikindustrie e.V.) von 2009 zitiert eine BITKOM-Studie, in der der Weltmarkt auf 71 Mrd. € und der deutsche Markt für eingebettete Systeme in 2007 auf über 18,7 Mrd. € geschätzt wird, mit einer weiteren durchschnittlichen Wachstumsrate von 9-10 % pro Jahr. Eingebettete Systeme sind für den Wirtschaftsstandort Deutschland von herausragender Bedeutung. […] Eingebettete Systeme stellen in vielen für Deutschland wichtigen Branchen eine Schlüsseltechnologie dar, sind Innovationstreiber und durch Diversifizierung von Produkten in Bezug auf Funktionalität und Qualität maßgeblich am Erhalt von Wettbewerbsfähigkeit und Arbeitsplätzen dieser Branchen beteiligt. Beispielsweise nimmt der Wertanteil von elektrischen und elektronischen Komponenten im Automobil stark zu und beträgt derzeit etwa 25-35%. Etwa 90% der Innovationen im Automobil werden von eingebetteten Systemen bestimmt. Die wichtigsten Branchen, in denen eingebettete Systeme entwickelt werden, sind folgende. Verkehrstechnik o Flug- und Fahrzeuge: Motor/Triebwerkssteuerung, X-by-wire, Lagestabilisierung, Dynamikregelung, Fahrerassistenz, Insassenkomfort, Navigation, … o Verkehrsleitsystem, Ampelsteuerung, Radarerfassung, … Automatisierungs-, Produktions- und Umwelttechnik o Maschinen- und Anlagenbau und -steuerung o Kraftwerks- und Fabriksteuerungen, Emissionskontrolle, Robotik Energie- und Gebäudetechnik o Heizungs-, Lichtsteuerung, „intelligent home“, „smart grid“ Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 6 Medizintechnik o Patientensysteme, Behandlungsgeräte, Meß- und Diagnosegeräte Hausgerätetechnik o Mikrowelle, Waschmaschine, Gasbrenner, Fernbedienung, Spielzeug, … Eingebettete Systeme können zur Lösung wichtiger Herausforderungen unserer Zeit beitragen: Smart Cities Im Jahr 2050 werden neun Milliarden Menschen auf der Erde leben, davon 70% in städtischen Ballungsgebieten. Eingebettete Systeme können durch effiziente und integrierte Informationsflüsse zwischen Bürgern, Unternehmen, Institutionen und Verwaltung die Lebens- und Arbeitsqualität aller Beteiligten steigern. Beispiele sind „Smart metering“, bei dem der Stromverbrauch der aktuell verfügbaren Kapazität angepasst wird, „Smart buildings“, die sich auf ihre Bewohner einstellen, und „Smart mobility“, bei dem öffentliche und individuelle Verkehrsmittel kombiniert werden. Alternde Gesellschaft Unter „Ambient assisted living“ (AAL) versteht man häusliche Umgebungen, die es Menschen ermöglichen, auch im Alter selbständig in ihrer eigenen Wohnung zu leben. Dazu gehören Monitoring- und Notfallassistenzsysteme, Haushaltsroboter und Versorgungssysteme. Nachhaltige Mobilität Hybrid- und Elektrofahrzeuge können dazu beitragen, die hohen Emissionswerte unseres heutigen Verkehrssystems zu reduzieren. Car-Sharing-Konzepte helfen, die Gesamtzahl der benötigten Fahrzeuge zu reduzieren. Car-to-Car-Kommunikation und Verkehrsmanagementsysteme verbessern den Verkehrsfluss und die Effizienz des Individualverkehrs. Gesundheitsfürsorge Medizinische Diagnose- und Therapiegeräte können helfen, die Ausbreitung von Krankheiten einzudämmen bzw. deren Auswirkungen zu beschränken. Katastrophenschutz und –management Frühwarnsysteme können helfen, die Auswirkungen eines Erdbebens oder Tsunamis zu mildern, indem bei Erkennung erster Wellen z.B. Gasleitungen gesichert und Züge gebremst werden. Mit Hilfe vernetzter Lokalisierungssysteme können Helfer gezielt an Einsatzorte geführt werden. Energieversorgung Zur effizienten Regelung dezentraler Systeme zur Energieerzeugung und -verteilung (vor allem auf Basis erneuerbarer Energiequellen, Windräder, Photovoltaikanlagen usw.) sind vernetzte eingebettete Systeme erforderlich, die Bedarf und Produktion aneinander anpassen. Cyber-physische Systeme Vielfach werden heute eingebettete Systeme mit Kommunikationskomponenten (WLAN, Bluetooth, GSM/UMTS/LTE, Zigbee, …) ausgestattet, so dass sie mit anderen Informatiksystemen Informationen austauschen können. Durch den Verbund vieler eingebetteter Systeme kann so eine neue Qualität in der Funktionalität des Gesamtsystems entstehen. Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 7 Ein cyber-physisches System ist eine Menge eingebetteter Systeme, die miteinander und/oder mit anderen Informatiksystemen vernetzt sind. Der Begriff „cyber-physisches System“ ist ein aktuelles Modewort, welches aus der Rückübersetzung des amerikanischen „cyber-physical system“ entstanden ist. Von der Wortbedeutung her ist Kybernetik die Wissenschaft der Steuerung von Maschinen, Organismen oder Organisationen (griechisch κυβέρνησις = Steuerung, Leitung), also geht es um die Steuerung physischer Geräte oder Systeme. Beispiele für cyber-physische Systeme sind das Netz der Steuergeräte in einem KFZ in heutigen PKWs sind 50-80 Steuergeräte verbaut, die über verschiedene Bordnetze (CAN, LIN, MOST, FlexRay, …) miteinander kommunizieren. Zum Beispiel regelt die elektrische Heckklappe beim Schließen die Ventilation herunter. die Steuergeräte einer industriellen Produktionsstraße in Fabriken mit automatischen Produktionsstraßen werden die einzelnen Stationen immer mehr miteinander vernetzt und mit der Logistik verbunden, um eine „just-in-time“Produktion individualisierter Produkte zu ermöglichen. ein Sensornetz zur Erdbebenfrühwarnung während einzelne seismische Sensoren keine sichere Aussage über Epizentrum und Stärke eines Bebens machen können, lässt sich aus einem Netz solcher Sensoren bereits vor Eintreffen der zerstörerischen Wellen eine sichere Vorhersage treffen. ein Fußballteam humanoider Roboter erklärtes Ziel der internationalen RoboCup Federation ist es, bis spätestens zum Jahr 2050 ein Team humanoider Roboter gegen ein menschliches Team antreten und gewinnen zu lassen. Bereits heute gibt es jährliche Meisterschaften mit vereinfachten Regeln. Nach der obigen Definition ist ein eingebettetes System der Trivialfall eines cyber-physischen Systems (eine Menge mit nur einem Element); umgekehrt kann ein einzelnes Steuergerät heute durchaus mehrere miteinander kommunizierende Prozessoren enthalten und wäre demnach auch ein cyber-physisches System. Daher soll im Rahmen dieser Vorlesung nicht weiter zwischen eingebetteten und cyber-physischen Systemen unterschieden werden. Entwicklung eingebetteter Systeme Die Entwicklung eingebetteter Systeme bietet einige Herausforderungen, die über die „normalen“ Probleme bei der Software-Entwicklung hinaus gehen. Diese ergeben sich mehr oder weniger unmittelbar aus den kennzeichnenden und sekundären Eigenschaften eingebetteter Systeme. Komponente eines technischen Systems Diese Eigenschaft bedingt die Notwendigkeit des mechanischen Einbaus in das technische System. Das bedeutet, Abmessungen und physikalische Randbedingungen wie z.B. Wärmeentwicklung müssen bei der Konstruktion berücksichtigt werden. Oft muss der Einbau in unmittelbarer Nähe der technischen Umgebung erfolgen (beim Auto z.B. in Hohlräume, im Motorraum, in der Ölwanne, sogar im Inneren der Reifen). Dadurch ergeben sich teilweise Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 8 sehr starke physikalische Belastungen und Robustheitsanforderungen, sowie Platz- und Energieprobleme. Zweckbestimmtheit Da ein eingebettetes System nur eine bestimmte, vorher festgelegte Funktion zu erfüllen hat, lohnt es sich, das System auf diese Funktion hin zu optimieren. Die Effizienz der Erbringung der spezifizierten Funktion ist oft das wichtigste Kriterium; das System soll mit minimalem Ressourceneinsatz auskommen. Das bedeutet, dass anders als bei Desktop-Systemen z.B. Speicherplatz nicht in beliebiger Menge zur Verfügung steht, und dass die Prozessorleistung genau auf die Aufgabe zugeschnitten wird. Ein anderer Unterschied zu Desktop-Programmen ist, dass bei eingebetteter Software die Systemschnittstellen im Allgemeinen vorher festliegen und nicht vom Programmierer definierbar sind. Das bedeutet, dass die Phase der Anforderungsanalyse viel gründlicher als bei „herkömmlicher“ Software durchlaufen werden muss; spätere Änderungen sind normalerweise nicht oder nur mit sehr großem Aufwand realisierbar. Interaktion mit Umgebung durch Sensorik und Aktuatorik Eine unmittelbare Konsequenz dieser Eigenschaft ist, dass der Systemingenieur genaue Kenntnis der Umgebung des Systems haben muss: Welche physikalischen Werte haben Einfluss auf das System, welche soll das System beeinflussen können? Eine saubere Schnittstellenbeschreibung und Systemarchitektur ist für eingebettete Systeme unumgänglich. Des Weiteren muss der Systemdesigner aber auch genaue Kenntnisse über das Verhalten der Sensoren und Aktuatoren haben: Bis zu welcher Genauigkeit sind die erhaltenen Sensordaten verlässlich? Wie groß sind die mechanischen Ungenauigkeiten der Motoren? Es kann durchaus sein, dass sich das tatsächliche Verhalten des technischen Systems signifikant von dem eines „idealisierten“ Systems (etwa in einer Simulation) unterscheidet. Hinzu kommen Rückkopplungseffekte: Da das eingebettete System über die Aktuatoren Einfluss auf das technische System hat, führen Ungenauigkeiten der Aktuatoren zu abweichenden Sensorsignalen, welche wiederum zu fehlerbehafteten Aktuatorbefehlen führen können, usw. Schließlich ist durch die Interaktion mit der „realen“ Welt auch immer die Ausfallproblematik zu berücksichtigen: Bei herkömmlichen Programmen geht man in der Regel davon aus, dass die Hardware (Prozessor, Speicher, Ein- und Ausgabegeräte usw.) zuverlässig und korrekt arbeitet. Bei eingebetteten Systemen ist diese Annahme nicht gerechtfertigt: Motoren unterliegen mechanischer Abnützung, Sensoren können bei Überschreitung des vorgesehenen Messbereichs defekt werden. Selbst Prozessoren und Speicher können, wenn sie rauhen Umgebungsbedingungen ausgesetzt werden (etwa der erhöhten GammaStrahlung im Weltraum) nicht unbedingt als zuverlässig betrachtet werden. Reaktivität, meistens Realzeitabhängigkeit Auf Grund dieser Forderungen sind „herkömmliche“ Multitasking-Betriebssysteme wie Unix oder Windows in eingebetteten Systemen nur bedingt einsetzbar; es können keine Antwortzeiten garantiert werden. Aus dem gleichen Grund verbieten sich z.B. Sprachen wie Java mit automatischer Speicherbereinigung. Für eingebettete Systeme gibt es eine Reihe spezialisierter Betriebssysteme (QNX, VxWorks, PikeOS, Coqos, OSEK, Embedded Linux, WindowsCE), die für verschiedene Anwendungsdomänen optimiert sind. oft für Regelungs- / Steuerungsaufgaben vorgesehen Die Definition von „Steuerung“ und „Regelung“ wird später behandelt. Wichtig ist, dass Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 9 Regelungstheorie ein eigenes Fach im Rahmen des Maschinenbaus und der Elektrotechnik ist; Informatiker haben hier oft nur rudimentäre Grundkenntnisse. Andererseits sind Informatiker oft versierter in Fragen der Softwaretechnik als Ingenieure; daher folgt aus dieser Eigenschaft, dass bei der Entwicklung eingebetteter Systeme Informatiker und Ingenieure zusammenarbeiten müssen. Dies bewirkt oft Kommunikationsprobleme häufig Massenware, Konsumgut, billig Aus dieser Eigenschaft folgt ein hoher Kostendruck für die Produktion. Wir haben oben schon gesehen, dass Optimierungen im Cent-Bereich ein Einsparpotential im 5- bis 6-stelligen Bereich bieten. Andererseits bedeutet dies, dass man immer versuchen muss, mit den absolut minimal notwendigen Ressourcen auszukommen (z.B. Verarbeitungsbreite, Energie); daraus resultieren unter anderem Anforderungen an die zu verwendenden Algorithmen. vielfach schlecht bzw. nicht wartbar und nicht erweiterbar Diese Eigenschaft ist teilweise verbunden mit der vorhergehenden: In vielen Fällen sind für massenhaft gefertigte eingebettete Systeme die Instandsetzungskosten höher als die Produktionskosten, so dass sich eine Reparatur nicht lohnt. Bei Geräten wie Waschmaschinen oder Kühlschränken ergeben sich hieraus Umweltbelastungen. Selbst wenn sich die Reparatur lohnen würde, ist es oftmals nicht möglich (z.B. Raumsonde) oder wirtschaftlich sehr aufwändig (z.B. Rückrufaktion bei Autos), die Software zu aktualisieren. Ein Rückruf bzw. eine Garantieleistung kann leicht eine Firma ruinieren! Im Gegensatz zu Desktop-Software ist es im Allgemeinen nicht möglich, eine Haftungsbeschränkung zu vereinbaren und regelmäßig „Patches“ oder „Service Packs“ in das Gerät einzuspielen, alles muss bereits bei der Auslieferung richtig funktionieren. Daraus ergeben sich Forderungen an Entwicklungs- und Validierungsprozesse. für viele unverzichtbar, manchmal auch sicherheitskritisch Solange eine Technologie „neu“ ist, sind Kunden eher bereit, Ausfälle zu akzeptieren. Sobald sie jedoch „selbstverständlich“ geworden ist, ergeben sich erhöhte Anforderungen an Verlässlichkeit, Verfügbarkeit, und Instandhaltbarkeit (Reliability, Availability, Maintainability). Dies gilt vermehrt in den Bereichen, in denen eingebettete Systeme „klassische“ mechanische oder elektrische Lösungen ersetzen oder verbessern. Bei sicherheitskritischen Systemen ist zudem die Ausfallsicherheit (Safety) ein entscheidendes Kriterium. Diese wird meist durch Fehlertoleranz realisiert, wobei für Hardware und Software unterschiedliche Fehlermodelle zugrunde gelegt werden müssen. Man spricht von einer RAMS-Analyse, wenn die vier Bereiche gleichzeitig behandelt werden. zunehmend auch vernetzt Die Entwicklung ubiquitärer und cyber-physischer Systeme stellt neben den oben genannten eine Reihe weiterer Herausforderungen an den Entwurfsprozess. Zu nennen sind hier zunächst einmal Synchronisationsprobleme, die sich durch die parallele Ausführung der miteinander kommunizierenden eingebetteten Systeme ergeben. Dann kann natürlich die Kommunikation an sich ein Problem darstellen, wenn viele Teilnehmer über dünne bzw. verrauschte Kanäle mit möglichst wenig Energie effizient und schnell einzelne Nachrichten oder große Datenmengen austauschen wollen. Schließlich können sich durch die Tatsache, dass der Zustand des Gesamtsystems von außen nicht ohne weiteres erkennbar ist, so genannte Feature Interaction und Mode Confusion Probleme bei der Benutzung ergeben, die im Voraus nur schlecht vorhersehbar sind. Für cyber-physische Systeme mit vielen Komponenten, bei denen sich durch die Interaktion eine ganz neue Gesamtfunktion ergibt Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 10 (z.B. Sensornetze), sind die Fragen nach Spezifikation, Verifikation und Test weitgehend ungelöst. Realzeitsysteme Ein kennzeichnendes Merkmal eingebetteter Systeme ist, dass sie „meistens Realzeitabhängigkeit“ sind. Natürlich gibt es eingebettete Systeme, die nicht realzeitabhängig sind (z.B. ein elektronischer Schalter), und Realzeitsysteme, die nicht eingebettet sind (z.B. ein Streaming-Video –Player). Trotzdem sind die beiden Begriffe „eingebettetes System“ und „Realzeitsystem“ so stark überlappend, dass sie manchmal gleichgesetzt werden. Tatsächlich wurden bis vor einigen Jahren Vorlesungen zu eingebetteten Systemen unter dem Titel „Realzeitsysteme“ angeboten! Doch zunächst zur Definition des Begriffs „Realzeitsystem“: umgangssprachlich bedeutet „in Echtzeit“ oder „echtzeitfähig“, dass die Transformation von Daten (Encoding oder Decoding) durch ein Informatiksystem in derselben Geschwindigkeit wie der Dateneingang erfolgt. Im Allgemeinen ist dies jedoch ein zu eng gefasster Begriff; zum Beispiel wollen wir eine Ampelsteuerung oder ein elektronisches Bremssystem auch als Echtzeitsystem bezeichnen, obwohl sie so gut wie keine Eingabedaten benötigen. Ein Echtzeitsystem ist ein Informatiksystem, bei dem nicht nur die korrekte, sondern auch die zeitgerechte Erbringung der Funktion spezifiziert ist. Dabei bedeutet „zeitgerecht“ nicht unbedingt „möglichst schnell“, sondern „innerhalb vorgegebener Zeitschranken“. Im Beispiel einer Ampelsteuerung etwa: „Wenn der Knopf gedrückt wird, schaltet die Ampel frühestens nach 10 Sekunden (damit Autos noch bremsen können) und spätestens nach 120 Sekunden (damit Fußgänger nicht ungeduldig werden).“ Die Spezifikation der Echtzeit erfolgt dabei in Bezug auf eine äußere Uhr (die nicht Teil des Echtzeitsystems ist), z.B. die Atomuhr der physikalischtechnischen Bundesanstalt PTB in Braunschweig. Diese äußere Uhr dient zur Synchronisation zwischen dem System und seinen Benutzern (nicht-relativistische Weltsicht). DIN 443000 definiert den Echtzeitbetrieb eines Informatiksystems als „ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind.“ Die vorgegebene Zeitspanne bezieht sich hier auf die Spezifikation; der Echtzeitbetrieb eines bezüglich seiner Spezifikation korrekten Programms bedeutet, dass die spezifizierten oberen und unteren Schranken bei der Ausführung garantiert werden können. Manchmal unterscheidet man zwischen „harten“ und „weichen“ Echtzeitanforderungen (hard real time bzw. soft real time); harte Anforderungen sind solche, bei denen eine Verletzung einem Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 11 kompletten Funktionsausfall gleichkommt (z.B. Nichteinhaltung einer Abgabefrist für Hausaufgaben), während bei weichen Anforderungen eine Verletzung lediglich eine Verminderung der Leistung bedeutet (z.B. Klötzchenbildung im Videobild). Oft sind weiche Realzeitanforderungen als so genannte „nichtfunktionale Eigenschaften“ formuliert (siehe nächstes Kapitel), z.B. „die Übertragungsrate ist durchschnittlich x MB/s“. Neben der oben genannten Ampelsteuerung ist ein weiteres typisches Beispiel für ein eingebettetes System mit harten Echtzeitanforderungen ein Antiblockiersystem (ABS) im Auto. Die Zeitkritikalität dieses Beispiels ist offensichtlich: Man möchte nicht, dass das System „irgendwann“ die Bremse löst oder anpresst, sondern innerhalb fest vorgegebener unterer und oberer Schranken für die verminderte Druckphase. Der Echtzeitbetrieb eines Betriebssystems verbietet gewisse Freiheiten, die man im „Normalbetrieb“ in Anspruch nehmen kann. So ist es zum Beispiel nicht möglich, eine Speicherbereinigung (garbage collection) durchzuführen, wenn der Speicher erschöpft ist, da die dafür benötigte Zeit schwer abschätzbar ist. Daher werden für Echtzeitsysteme üblicherweise keine Sprachen (wir z.B. Java) verwendet, bei denen dynamische Speicherbereinigung fest vorgesehen ist. Auch ist Multitasking nur mit großer Vorsicht zu verwenden, da die Ausführungsgeschwindigkeit eines Prozesses stark von der Last abhängt, die von quasi-parallel ausgeführten Prozessen erzeugt wird. Daher erlauben Echtzeitbetriebssysteme Multitasking oft nur in sehr eingeschränkter Form. Schließlich ist selbst auf der Ebene der Prozessoren nicht alles erlaubt, was man von Arbeitsplatzrechnern her gewohnt ist: Zum Beispiel werden im Cache häufig benötigte Daten für einen schnelleren Zugriff vorgehalten, und weniger oft benötigte Daten werden in langsamere Hintergrundspeicher ausgelagert. Wenn die Strategie hierfür unbekannt ist, führt das zu einem nicht vorhersagbaren Echtzeitverhalten. Hardware-Aufbau eines eingebetteten Systems Prinzipiell interagiert ein eingebettetes System mit seiner Umgebung über Sensoren und Aktuatoren (manchmal fälschlicherweise kurz als Aktoren bezeichnet). Sensoren kommunizieren über AnalogDigital-Wandler (AD) mit dem System, und Aktuatoren über Digital-Analog-Wandler (DA). Falls die Aktuatoren eine hohe elektrische Leistungsaufnahme haben, sind hier entsprechende elektronische Leistungsregler (etwa sogenannte H-Bridges oder Vierquadrantensteller) verbaut. Da Sensoren immer „intelligenter“ werden, haben sie heute oftmals einen eigenen Prozessor integriert, der die Messdaten vorverarbeitet und über digitale Schnittstellen (wie etwa den I2C-Bus) mit dem eigentlichen eingebetteten System kommuniziert. Umgekehrt haben viele Motoren ihre eigenen digitalen Motorsteuerungen und/oder integrierte Sensoren, und sind deshalb ebenfalls über digitale Leitungen angeschlossen. Auf dem Bord selbst befinden sich der Prozessor und der Hauptspeicher. Für eingebettete Systeme werden aus Kostengründen vielfach „kleine“ (8-16 Bit-) Prozessoren und „kleine“ Speicher (8 KB-128 MB) verbaut. Der Speicher selbst besteht oft aus nichtflüchtigem EPROM, in dem BIOS bzw. Betriebssystem abgelegt werden, und RAM-Speicher für Berechnungen. Manchmal ist die Möglichkeit für Speichererweiterungen durch Flash-Karten oder andere Schnittstellen vorgesehen. Fast immer sind eine oder mehrere Schnittstellen für verschiedene Bus-Systeme (z.B. CAN, LIN, USB, …) und/oder drahtlose Kommunikation (WiFi, Bluetooth, IR, …) vorgesehen. Weitere digitale Kommunikationsschnittstellen betreffen Displays und Monitoring-Ports. Schließlich ist das eingebettete System mit Gehäuse und Stecker vom technischen System getrennt. Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 12 Eine detailliertere Beschreibung eingebetteter Hardware findet sich in einem späteren Kapitel. Programmierung eingebetteter Systeme Zur Programmierung eingebetteter Systeme wird üblicherweise ein Host-System (meist ein Arbeitsplatzrechner oder Laptop) verwendet. Manchmal ist zusätzlich ein Interface-Modul („Programmer“) erforderlich, mit dem der Speicher des eingebetteten Systems beschrieben werden kann. Die Software auf dem Host-Computer besteht üblicherweise aus einer IDE (integrierten Entwicklungsumgebung) aus Editor, Compiler, Linker und Übertragungsmodul. Zur Programmierung wird in der Praxis überwiegend die Sprache C verwendet, andere Sprachen kommen nur ausnahmsweise zum Einsatz. Die Software auf dem eingebetteten Gerät selbst (welches in diesem Zusammenhang als Zielsystem, target bezeichnet wird), ist meist in einer Schichtenarchitektur angeordnet: Die unterste Schicht ist das Betriebssystem (operating system, OS), welches von einer einfachen Befehlsschleife über verschiedene Firmware-Varianten bis hin zu voll ausgewachsenen Realzeitbetriebssystemen (RTOS) mit verschiedenen Treibern und Protokollstapeln reichen kann. Darauf aufbauend hat man oft eine Hardware-Abstraktionsschicht (hardware abstraction layer, HAL), die den direkten Zugriff auf die Hardware und Signale kapselt. Eine spezielle Treiber können die Schichtenarchitektur durchbrechen. Die oberste Schicht besteht aus der Anwendungs-Software (application layer), in der die logische Funktion des eingebetteten Systems realisiert wird. Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 13 2 System- und Anforderungsanalyse In den frühen Phasen der Entwicklung eines eingebetteten Systems sind vor allem die Systemanalyse (systems engineering) und die Anforderungsanalyse (requirements engineering) von Bedeutung. Die Systemanalyse beschäftigt sich mit Entwurfs- und Konstruktionsprozesse komplexer Systeme, die Anforderungsanalyse definiert Prozesse zur Anforderungserhebung, -verwaltung und –vernetzung. Systemanalyse Das Hauptproblem bei der Realisierung „großer“ technischer Systeme ist die wachsende Komplexität. Die Systemanalyse ist eine Disziplin, die sich mit den Entwurfs- und Konstruktionsprozessen komplexer Systeme beschäftigt. Der Gegenstandsbereich ist dabei nicht eingeschränkt auf eingebettete Systeme oder Informatiksysteme; auch z.B. der Bau eines neuen Flughafens ist ein Thema für die Systemanalyse. Die Systemanalyse soll dazu dienen, die Komplexität beherrschbar zu machen. Eine wesentliche Herangehensweise dabei ist es, alle verschiedenen Aspekte zu berücksichtigen, also sowohl technische als auch nichttechnische Gesichtspunkte wie Nutzerverhalten, kaufmännische Aspekte, Betrieb, Verwaltung und Entsorgung des Systems. Ursprünge der Verwendung von Methoden der Systemanalyse in der Softwaretechnik war der Vergleich zum Vorgehen eines (Maschinenbau-)Ingenieurs, der zunächst einen Plan des zu entwickelnden Systems auf Papier macht, diesen Plan dann analysiert, und erst dann das System baut. Im Gegensatz dazu wurde und wird Software oft mit „trial-and-error“-Methoden entwickelt: Man geht von gewissen Wunschvorstellungen aus, implementiert und testet einen Prototypen, und ändert diesen dann solange, bis das Ergebnis zufriedenstellend ist. Diese Herangehensweise ist insbesondere für eingebettete Systeme aus den im vorigen Kapitel besprochenen Gründen nicht möglich. Die Systemanalyse beschäftigt sich mit der Frage, wie Anforderungen systematisch erfasst und verwaltet werden und wie sie in den Entwurf einfließen. Der Hauptunterschied zu herkömmlichen Vorgehensweisen ist die eine Betonung der Systemziele, die ständige Exploration mehrerer Lösungswege, und die ganzheitliche Sicht auf Prozesse und Abläufe sowohl im Entwurf als auch bei der Realisierung des Systems. Systemanalyse ist der Prozess, ein komplexes System als Ganzes zu verstehen, zu entwerfen und zu entwickeln (im Gegensatz zur Komponentensicht). Wesentlich dafür ist die ganzheitliche Erfassung der Anforderungen, insbesondere bezüglich Integration und Betrieb des Systems im sozio-technischen Umfeld. INCOSE1 definiert: “Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.” Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 14 Sommerville2 gibt eine Schichtenarchitektur der Abstraktions- oder Betrachtungsebenen von (eingebetteten) Systemen: Die unterste Schicht ist die Hardware, auf der das System aufbaut. Dazu gehören Prozessor, Speicher, Sensoren, usw. Die darüber liegende Abstraktionsebene betrachtet die Plattform, das heißt, Hardware zusammen mit Betriebssystem und Middleware/HAL, Protokollstacks usw. Darauf aufbauend folgt die Betrachtungsebene der Applikationen, die die Anwendungslogik realisieren und Benutzungsschnittstellen bereit stellen. Als darüber liegende Schicht sind die Prozesse (die technischen und organisatorischen Abläufe) zu verstehen, in die das System eingebunden ist. Die oberste Schicht schließlich sind die Organisationen, innerhalb derer diese Prozesse ausgeführt werden. Die Softwaretechnik umfasst dabei überwiegend die Ebene der Applikationen, gegebenenfalls mit den angrenzenden Ebenen der Plattformen und Prozesse. Eine ganzheitliche Sicht in der Systemanalyse muss jedoch alle Ebenen mit berücksichtigen. Als Beispiel betrachten wir die Entwicklung eines Herzschrittmachers: die reine Hardware besteht aus einem Pulsgeber mit Elektrode, wobei man sich Gedanken über Material, Gehäuse, Batterielebensdauer, Fehlertoleranz und so weiter machen muss. Beim Entwurf der Plattform ist über Betriebssystem und Architektur zu entscheiden. Auf der Applikationsebene muss die Software, die den Schrittmacher betreibt und die Kommunikation mit dem behandelnden Arzt durchführt, realisiert werden. Dazu sind unter anderem Prozesse wie Implantation, medizinische Nachsorge und Langzeitdiagnose zu berücksichtigen. Diese Prozesse werden in Organisationen wie dem Krankenhaus oder beim behandelnden Hausarzt durchgeführt. Ohne gewisse Kenntnisse der gesamten Hierarchie kann ein großes Projekt nicht zum Erfolg geführt werden: Beispielsweise ist es nötig, zu verstehen, wie die Patientenverwaltung im Krankenhaus funktioniert, wenn man eine Exportschnittstelle für Datenlogging des Schrittmachers erstellen will. ISO 15288:2008 nennt die folgenden Prozesse, die bei der Systemanalyse behandelt werden müssen. 2 Ian Sommerville, Software Engineering. 9. Aufl. 2012, Pearson-Verlag, ISBN: 978-3-8689-4099-2 Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 15 Jedes System hat einen Lebenszyklus, der grob in die Phasen Konzeptentwurf, Entwicklung, Produktion, Einsatz und Entsorgung eingeteilt werden kann. Der Aufwand für die Systemanalyse, eingeteilt nach den verschiedenen Prozessgruppen, kann nach INCOSE wie folgt angegeben werden: Das bedeutet konkret, dass kein Prozess während der Entwicklung „abgeschlossen“ ist und beendet werden kann; alle Prozesse sind während der Systementwicklung (mit wechselndem Aufwand) zu betreiben! Systemanalyse ist demnach also ein Entwicklungs- bzw. Lebenslauf-begleitender Vorgang. Insbesondere wendet sich diese Auffassung gegen Wasserfall- und V-Modell-artige Vorgehensmodelle, bei denen eine Phase beendet wird bevor die nächste beginnt, und entspricht daher viel eher den in der Praxis häufig anzutreffenden Vorgehensweisen. Für jeden der oben genannten Prozesse ist im „INCOSE Systems Engineering Handbook“ 1 eine detaillierte, standardisierte Beschreibung zu finden. Sie besteht aus der Definition der Aktivitäten, die für diesen Prozess durchzuführen sind, den dafür nötigen Eingaben, den Ergebnissen, sowie Randbedingungen die den Prozess unterstützen oder einschränken. Als Beispiel betrachten wir die Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 16 Prozesse „Stakeholder Requirements Definition“ (auf Deutsch etwa: Lastenhefterstellung) und (weiter unten) „Requirements Analysis“ (auf Deutsch etwa: Pflichtenhefterstellung). Eingangsdaten für den Prozess der Lastenhefterstellung sind alle allgemeinen Quellen, die für das zu entwickelnde System oder vergleichbare Systeme zur Verfügung stehen, projektbezogene Rahmenbedingungen festlegen, und vor allem die Erfordernisse der „Stakeholder“. Auf Deutsch nur unzulänglich mit „Akteure“ oder „Interessentengruppen“ übersetzt, sind dies alle Personen oder Organisationen, die direkt oder indirekt mit dem System zu tun haben („any entity (individual or organization) with a legitimate interest in the system“). Im Beispiel „Herzschrittmacher“ sind dies etwa: Patient, Chirurg, behandelnder Arzt, Pflegepersonal, Klinik, Entwicklungs- und Herstellungsfirma, Zulieferer, Wartungstechniker, Notfallambulanz, TÜV, und gegebenenfalls weitere. Wir betrachten die Personen, die mit der Entwicklung des Systems befasst sind (Systemdesigner, Entwickler SW/HW, Tester, Systemintegrator, Manualschreiber, Softwarewartung, Management, Einkaufsabteilung, Buchhaltung, ...), nicht als Akteure in diesem Sinne (siehe weiter unten, Pflichtenheft bzw. Systemanforderungen). Eine wesentliche Aktivität bei der Lastenhefterstellung besteht darin, diese Erfordernisse in einem Lastenheft schriftlich zu erfassen. Oft geschieht dies im Rahmen einer Vorstudie, oder durch Workshops und Interviews mit den Beteiligten. Wichtig ist dabei, alle Akteure/Stakeholder mit zu beteiligen! Das Lastenheft ist eine Beschreibung der durch das System bereitgestellten Dienste und operationalen Randbedingungen; in der Sprache der Akteure verfasst und für diese verständlich; in vielen Fällen ist es die Grundlage für Auftragserteilung! DIN 69901-5 definiert das Lastenheft als „die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Lastenheft wird oft auch als Anforderungsspezifikation (requirements specification oder user requirements specification bzw. stakeholder requirements specification) bezeichnet. Es ist das für die Systementwicklung wesentliche Dokument und beschreibt das System in seiner Gesamtheit, aus Sicht der Stakeholder. Üblicherweise ist das Lastenheft ein Textdokument von 50-500 Seiten, das oft wie folgt aufgebaut ist: Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 17 1. 2. 3. 4. 5. 6. 7. 8. 9. Titel, Dokumentenname und –ID, Verfasser, Freigabe, usw. Änderungshistorie, Inhalts-, Abbildungs- und Tabellenverzeichnis vorgesehener Leserkreis, Abstrakt, Dokumentenwartung Verzeichnis von Abkürzungen, Definitionen und Fachbegriffen Sicherheitsanforderungen und relevante Standards System- und Schnittstellenübersicht, Nutzungsbeschreibungen Funktionale Anforderungen Nichtfunktionale Anforderungen Indices und Anhänge Für eingebettete Systeme gibt es einige besondere Anforderungen, die im Lastenheft vermerkt sein sollten. Da das Informatiksystem Teil eines technischen Systems ist, muss die physikalische Umgebung zu einem gewissen Teil mit spezifiziert werden. Zum Einen heißt das, dass spezielle operationale Randbedingungen, z.B. erlaubte Betriebstemperaturen, Beschleunigungswerte, zulässige Sensorbereiche usw., angegeben werden müssen. Zum Anderen bedeutet es, dass auch die physikalischen Gegebenheiten des eingebetteten Systems selbst Teil der Spezifikation sind: geplante Abmessungen, Formfaktor, zu verwendende Stecker und Buchsen usw. Die Spezifikation eines eingebetteten Systems bezieht sich, anders als eine reine Softwarespezifikation, auf das gesamte technische System, mit Software und Hardware des eingebetteten Informatiksystems. So müssen eventuelle Kosten- oder Leistungsbeschränkungen, etwa bezüglich des zu verwendenden Prozessors oder der Prozessorfamilie, der zu verwendender Architektur, dem maximalem Speicherausbau usw. im Lastenheft angegeben werden. Auch Randbedingungen zur Sensorik und Aktuatorik sind anzugeben: zum Beispiel die zulässigen Toleranzbereiche, erlaubten Mess- und Regelabweichungen, Leistungsgrenzen usw. Wichtig ist, dass im Lastenheft noch keine Festlegung auf eine spezifische technische Lösung stattfindet; dies ist späteren Entwicklungsstufen vorbehalten. Meist ist im Lastenheft auch ein domänenspezifischer Teil zu finden: ein Verzeichnis der verwendeten Fachbegriffe, der anzuwendenden Normen und Standards, einzuhaltenden gesetzlichen Vorschriften usw. Falls das System Teil einer Produktfamilie ist, wird dieser Teil allerdings oftmals als generisches Dokument ausgelagert und im Lastenheft durch eine Referenz ersetzt. Da eingebettete Systeme oft für Steuerungs- und Regelungszwecke vorgesehen sind, ist im Lastenheft die realisierte Funktion als Regelkreis oder Schaltfunktion beschrieben. Auch hier ist es wichtig, bei der Erstellung des Lastenheftes darauf zu achten, nur die Funktion, nicht jedoch die Realisierung der Funktion zu definieren. Üblicherweise besteht die Funktion aus kontinuierlichen und diskreten Anteilen, etwa dem Analysieren der Herzfrequenz und dem Auslösen eines elektrischen Pulses zum Stimulieren des Herzens. Formale Methoden zur Beschreibung solcher Funktionen werden in den nächsten Kapiteln behandelt. Oft werden Anforderungen in funktionale und nichtfunktionale Anforderungen aufgeteilt; funktionale Anforderungen betreffen die vom System zu erbringende Funktion, und nichtfunktionale Anforderungen sind alle anderen. Funktionale Anforderungen beschreiben die Dienste des Systems, wie es auf bestimmte Eingaben reagiert oder sich in bestimmten Situationen verhält (zum Beispiel: was passiert wenn ein bestimmter Knopf gedrückt wird). Die Formulierung hängt dabei ab von der zu erwartenden Nutzung und dem Einsatzbereich des Systems; wichtig ist im Lastenheft, eine Außensicht (Black-box-view) auf das System einzunehmen. Nicht-funktionale Anforderungen Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 18 beschreiben Randbedingungen für die Dienste, zum Beispiel zeitliche Einschränkungen, Entwicklungseinschränkungen, usw. Sie betreffen z.B. Lebensdauer oder Leistung des Systems. Es ist umstritten ob es überhaupt nicht-funktionale Anforderungen gibt, oder ob es nicht lediglich unterspezifizierte die Funktion betreffende Anforderungen sind. Manchmal separiert man eine dritte Klasse von Anforderungen, nämlich die Domänen-Anforderungen. Das sind allgemeine Anforderungen für alle Systeme einer bestimmten Anwendungsdomäne (Medizintechnik, Schienenverkehr, Automotive usw.). Domänen-Anforderungen sind z.B. anwendbare Standards der Domäne, oder die Indikationen und Kontraindikationen eines medizinischen Gerätes. Fallstudie Herzschrittmacher Als Beispiel für eine Anforderungsspezifikation soll in diesem Skript die „PACEMAKER System Specification“ der Fa. Boston Scientific dienen3. Oftmals sind Lastenhefte streng vertrauliche Dokumente, die zu den am besten gehüteten Geheimnissen eines Unternehmens gehören. Dieses Dokument wurde zu akademischen Zwecken vom Ersteller freigegeben und entspricht dem Stand der Technik auf dem Gebiet der Systemanalyse. Diese und weitere öffentlich freigegebene textuelle Anforderungsspezifikationen sind auf den Seiten des Projektes NLRPBench zu finden4. Um das Dokument zu verstehen, sind zunächst rudimentäre Kenntnisse des Anwendungsgebiets „Herzschrittmacher“ erforderlich. Wir beschränken uns hier auf das Wesentliche; eine tiefergreifende Domänenanalyse übersteigt den Rahmen dieses Skripts. Das menschliche Herz ist der “Motor” des kardiovaskulären Systems. Es besteht aus zwei Teilen (rechte und linke Seite des Herzens) für den Lungenkreislauf (rechte Seite) und den Körperkreislauf (linke Seite des Herzens). Jede Seite des Herzens besteht aus Vorhof (Atrium) und Kammer (Ventrikel), wobei das Herz als doppelte Pumpe wirkt, bei der beide Teile synchronisiert sind. Wir skizzieren kurz den Ablauf eines Herzschlags: Anfangs sind die Muskeln entspannt und das Blut fließt in die beiden Atria. Dann ziehen sich die Atria zusammen und pressen das Blut in die Ventrikel. Danach kontrahieren sich die Ventrikel und das Blut fließt in die Lunge bzw. den Körper. Schließlich entspannen sich die Muskeln wieder und der Zyklus beginnt von vorn. Kardiovaskuläre Krankheiten sind eine der Haupt-Todesursachen weltweit. Es gibt verschiedene Formen von Rhythmusstörungen: Bradykardie: das Herz schlägt zu langsam Tachykardie: das Herz schlägt zu schnell Flimmern (Fibrillation): das Herz schlägt unregelmäßig Stillstand: das Herz schlägt überhaupt nicht mehr Das Herz schlägt, indem elektrische Impulse vom Sinusknoten (im Atrium) generiert und durch den Atrioventrikularknoten (AV-Knoten, im Ventrikel) propagiert werden; diese verursachen das Zusammenziehen der Herzmuskeln Zur Therapie chronische Herzerkrankungen können beide Knoten 3 PACEMAKER System Specification, Boston Scientific 2007, http://sqrl.mcmaster.ca/_SQRLDocuments/PACEMAKER.pdf 4 http://nlrp.ipd.kit.edu/index.php/Main_Page Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 19 auch künstlich (durch elektrische Impulse) stimuliert werden. Diese Entdeckung (in den 1920-er Jahren) führte in den 1930-er Jahren zu den ersten Herzschrittmachern; dies waren externe Geräte mit implantierten Elektroden. Natürlich ergibt sich an der Durchgangsstelle durch die Haut eine permanente Infektionsgefahr. Der erste voll-implantierbare Schrittmacher wurde 1958 bei Patienten eingesetzt; er bestand aus einem Kondensator mit zwei Transistoren und einer Energiequelle (Akku oder Batterie), die einen regelmäßigen Puls auslösten. Das Ganze war in Dosenform mit Gießharz versiegelt. Es ergaben sich folgende Probleme: 1. Die ursprünglich verwendeten Batterien hatten nur eine vergleichsweise kurze Lebensdauer (Wochen bis Monate), was ständige Neuoperationen erforderlich machte. Zur Verbesserung der Energieversorgung wurde daher in den 1960-er Jahren unter anderem mit Plutoniumbatterien experimentiert; diese halten zwar bis zu 40 und mehr Jahre, sind aber sehr umweltschädlich. Heute werden Lithium-Verbindungen als Energieträger verwendet. Auf Grund verbesserter elektronischer Komponenten ist die aktuelle Batteriekapazität ausreichend für 5-8 Jahre, welches in etwa der Lebensdauer der Steuereinheit entspricht. Das Problem kann daher momentan als gelöst betrachtet werden. 2. Die einfache Transistorschaltung erzeugt einen gleichmäßigen Puls. Gleichmäßige Stimulation kann zu Herzflimmern führen (“Schrittmacherkrankheit”), falls der künstliche Impuls dem natürlichen zuwider läuft. Die entscheidende Idee zur Lösung dieses Problems war, dass die Elektroden auch als Sensoren genutzt werden können, um die im Sinusknoten bzw. AV-Knoten erzeugte natürliche Elektrizität zu messen. Natürlich ist eine Regelelektronik erforderlich, um den Aktuator (Elektrode zur Stimulierung) vom Sensor (Elektrode als Messfühler) abhängig zu machen. Durch die Fortschritte im Bereich der Mikroelektronik und eingebetteten Systeme ist auch dieses Problem inzwischen überwunden. Die Hauptprobleme der ursprünglichen Schrittmacher sind also gelöst, was dazu geführt hat, das Herzschrittmacher inzwischen eine Standardtechnik darstellen. Heutzutage werden weltweit jährlich mehr als 500.000 Schrittmacher implantiert. Natürlich bedeutet das nicht, dass die Entwicklung stehenbleibt und die Funktionalität nicht mehr verbessert werden kann. Die Hauptfunktionalität eines Schrittmachers ist es, einen Puls auszulösen dann und nur dann, wenn es nötig ist. Die Definition, wann ein Puls erforderlich ist, ist von vielen Faktoren, unter anderem vom Fortschreiten der medizinischen Erkenntnis, abhängig. Zum Beispiel können moderne Schrittmacher mit Beschleunigungssensoren die sportliche Aktivität des Patienten messen und die Pulsrate entsprechend adaptieren. Durch minimale Verzögerungen oder Verkürzungen der Pulsrate kann zudem die Herzmuskulatur trainiert werden, so dass bestimmte Herzerkrankungen mit Schrittmachern therapiert werden können. Wenn die Elektroden entsprechend angeordnet sind, kann das Gerät eine Neusynchronisierung und verbesserte Synchronisierung zwischen linker und rechter Herzhälfte herbeiführen. Durch eingebaute Kommunikationsschnittstellen kann das Gerät die Elektrode nutzen, um ein vollständiges EKG (Elektrokardiogramm) des Patienten zu erstellen. Aktuelle Trends bei der Entwicklung neuer Generationen von Schrittmachern betreffen die Integration von weiteren Funktionen, zum Beispiel die Integration von implantierbaren Defibrillatoren und Schrittmachern (ICDs). Zur Lösung mechanischer Probleme mit den Elektroden, die etwa 20% der Patienten betreffen, erforscht man die Möglichkeit drahtloser intrakardialer Schrittmacher (direkt im Herz implantiert), oder außerhalb vom Brustkorb implantierter subkutaner Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 20 Kardioverter-Defibrillatoren. Ein hochaktuelles Gebiet ist außerdem die telemedizinische Überwachung, Diagnose und Nachsorge von Schrittmacher-Patienten. Das von Boston Scientific verfügbar gemachte Spezifikationsdokument beschreibt das Gesamtsystem als aus drei Komponenten bestehend: Puls-Generator (PG) - Steuer-Elektronik - Energieversorgung (Lithium-Iodine) - Titangehäuse, implantiert in der rechten Brust - Beschleunigungssensor (Accelerometer) Elektroden (Leads) - ein oder zwei Elektroden (atrial / ventrikulär) - Standard- Steckverbindung (PG-Wechsel!) - Durch eine Vene ins Herz geführt Externer Device Controller Monitor (DCM) - Für Programmier- und Diagnosezwecke - Separates Gerät, zum Setzen und Anpassen der Parameter durch den behandelnden Arzt Ringmagnet (donut-shaped magnet) für Notfallzwecke Stimulationsmodi (Pacing Modes) • Z.B. Typ DDDR, VDDR, DDIR, D00R, AAIR, D00, V00, VVI, VVT, ... • X = “don’t care”; DXXX sind Zweikammermodi, 0X0 sind reine Diagnosemodi etc. Triggered: Puls wird generiert wenn Herzaktivität gemessen wird (um den natürlichen Impuls zu verstärken) Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 21 • Inhibited: Puls wird unterdrückt wenn Herzaktivität gemessen wird (um Interferenz mit dem natürlichen Stimulus zu vermeiden); d.h., Puls wird nur dann generiert wenn keine Herzaktivität gemessen wird • Tracked (D): gemessene atriale Aktivität löst nach definierter Verzögerungszeit (AV delay) einen ventrikulären Puls aus • Rate modulation: dynamische Adaption der Pulsrate an die sportlichen Aktivitäten des Patienten (nur im Modell DR1 verfügbar) • Multisite: kann mehrere Stellen innerhalb der gewählten Kammer stimulieren (n.a.) Beispiel-Modi • • • VVIR Nur eine Elektrode nötig Puls nach Bedarf: falls genügend Eigenaktivität vorhanden, keine Stimulation; falls die ventrikuläre Aktivität ausbleibt, wird ein Puls generiert Nachdem eine Aktivität gemessen wurde oder ein Puls generiert wurde, löst der Schrittmacher nach einer festgelegten Zeit einen Puls aus, falls bis dahin keine Aktivität gemessen werden kann Die Zeit zwischen zwei Pulsen wird durch die Werte des Beschleunigungssensors beeinflusst DDD Ständige Überwachung von Atrium und Ventrikel Falls eine erwartete atriale Aktivität ausbleibt, wird ein Puls im Atrium ausgelöst Nachdem eine Aktivität im Atrium gemessen oder stimuliert wurde, wird nach einer festgelegten Zeit (AV delay) ein ventrikulärer Puls ausgelöst, falls bis dahin keine vertrikuläre Aktivität gemessen werden konnte also: eine Aktivität im Atrium oder Ventrikel verhindert die Stimulation; eine gemessene Vorhofaktivität löst einen Puls im Ventrikel aus Sonderfälle: Atriale Tachykardie-Reaktion Falls eine unakzeptabel hohe Aktivitätsrate im Atrium erkannt wird, muss die Stimulation vorübergehend eingestellt werden Relevante Parameter im PG Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 22 Lebenszyklus und Betriebsmodi Permanent: normale Betriebsart; die eingestellten Parameter werden verwendet Temporary: zu Testzwecken; alle Parameter können vom Arzt (innerhalb vorgegebener Grenzen) beliebig gesetzt und ausprobiert werden Pace-Now: kommandierter Notbetrieb; ein fester Modus und feste Standardparameter werden verwendet Power-on Reset: bei nachlassender Spannung; auch „sicherer” Betriebszustand wenn die Spannung sich wieder erhöht Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 23 Magnet: ähnlich wie „Pace-Now“, aber durch Notfallambulanz durch einen externen Magneten ausgelöst (bei Elektroschock oder Herzflimmern); keine Messung mehr, aber die Pulsrate kann durch den Batteriestatus beeinflusst werden Anforderungen (Boston Scientific) 5.7 Rate-Adaptive Pacing The device shall have the ability to adjust the cardiac cycle in response to metabolic need as measured from body motion using an accelerometer. 5.7.1 Maximum Sensor Rate (MSR) The Maximum Sensor Rate is the maximum pacing rate allowed as a result of sensor control. The Maximum Sensor Rate shall be 1. Required for rate adaptive modes 2. Independently programmable from the URL 5.7.2 Activity Threshold The activity threshold is the value the accelerometer sensor output shall exceed before the pacemaker’s rate is affected by activity data. 5.7.3 Response Factor The accelerometer shall determine the pacing rate that occurs at various levels of steady state patient activity. Based on equivalent patient activity: 1. The highest response factor setting (16) shall allow the greatest incremental change in rate. 2. The lowest response factor setting (1) shall allow a smaller change in rate. 5.7.4 Reaction Time The accelerometer shall determine the rate of increase of the pacing rate. The reaction time is the time required for an activity to drive the rate from LRL to MSR. 5.7.5 Recovery Time Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 24 The accelerometer shall determine the rate of decrease of the pacing rate. The recovery time shall be the time required for the rate to fall from MSR to LRL when activity falls below the activity threshold. Anforderungsanalyse Analyse der (Nutzer / Stakeholder-) Anforderungen und Umformung in Entwickler-Sicht Anforderungsdefinition Siehe auch Sommerville ch2.ppt Sozio-technische Systeme Im Gegensatz zum oben beschriebenen Lastenheft, welches das „was“ aus Sicht der Anwender definiert, beschreibt das Pflichtenheft das „wie“ aus Sicht der Entwickler. Die schon oben genannte DIN 69901-5 definiert das Pflichtenheft als „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. Das Pflichtenheft wird oft auch als Systemspezifikation (system specification oder system requirements specification) bezeichnet; allerdings ergibt sich dadurch die Gefahr der Konfusion mit der oben genannten Anforderungsspezifikation (user requirements specification). Auch Begriffe wie Fachkonzept u.ä. sind gebräuchlich. INCOSE: „The purpose of the Requirements Analysis Process is to transform the stakeholder, requirement-driven view of desired services into a technical view of a required product that could deliver those services.” DIN 69901-5: Pflichtenheft = „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“ Systemspezifikation (System Specification, System Requirements Specification): beschreibt das System aus der Innensicht Keine Festlegung auf spezifische Lösungswege, aber Definition interner Parameter und Schnittstellen Funktionen und externe funktionale Schnittstellen des Gesamtsystems Grundlage für die Systementwicklung Pflichtenhefterstellung Iterative und rekursive Vorgehensweise Strukturierung und Verlinkung von Anforderungen Benennung von Evaluationskriterien (Measures of Performance) Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 25 Eigenschaften von Anforderungen • verständlich • • eindeutig kein Interpretationsspielraum, präzise aber nicht notwendigerweise: nur auf eine Art implementierbar! verifizierbar/testbar • • warum ist die Anforderung vorhanden, ist sie notwendig? konsistent keine Widersprüche zu anderen Anforderungen realisierbar, d.h. nicht in sich widersprüchlich abstrakt • wie kann die korrekte Implementierung festgestellt werden? nachvollziehbar • von allen Akteuren (nicht nur den Entwicklern) lesbar, klar keine unzulässige Einschränkung des Implementierungsraumes adaptierbar kann ggf. erweitert, ersetzt oder gelöscht werden Gängige Probleme in Spezifikationen Mangelnde Klarheit • • Mangelnde Klarheit Präzision versus Lesbarkeit shall / will / must / should / is to / ought to / … Konfusion • Amalgamation • Vermischung funktionaler und nichtfunktionaler Anforderungen Vermischung verschiedener Belange in einer Anforderung Ambiguität Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 26 • Überspezifikation • Selber Sachverhalt mehrfach beschrieben Unterspezifikation • Verschiedene Interpretationsmöglichkeiten Sachverhalte unvollständig oder gar nicht beschrieben Mangelnde Modularisierung Strukturierung in Prosa ist schwierig Traceability (Verfolgbarkeit) • Wichtigste Eigenschaft an Spezifikationen (neben Konsistenz & Vollständigkeit) • Anforderungen können ohne Bezüge nicht sinnvoll verwaltet werden! • Verfolgbar bedeutet, dass die folgenden Informationen da sind wer die Anforderung aufgestellt hat (Bezug zu Stakeholder) warum die Anforderung existiert (Bezug zu Lastenheft) welche anderen Anforderungen damit zusammenhängen (Querbezüge) wie die Anforderung weiter verwendet wird in - Systementwurf / Architektur, - Implementierung / Code, - Test / Testfälle, und - Dokumentation **************************************************** Erstellen von Spezifikationen • Standardformat verwenden • Konsistente Sprache e.g. shall for mandatory requirements, should for desirable requirements avoid the use of technical terms; if necessary, define them avoid constants (use identifiers with a table of values) formulate as precisely as possible Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 27 • Structure the requirements clearly identify key parts, derived requirements, implementation issues baumartige Strukturierung • Use diagrams and semi-formal notations as much as possible • Use tools to enhance consistency Requirements Properties • Verifiability / Testability • Comprehensibility • is the requirement properly understood by all stakeholders, or is there imprecision, vagueness, source of confusion? Purposefulness • is it clear whether the requirement is implemented or not? Can this realistically be tested? Test result clear? is the origin and intention of the requirement stated? Why is the requirement necessary? Adaptability Is the scope of the requirement well-defined? Can it be changed without a large impact on other requirements? What are the consequences of a change? Aufgaben bei der Anforderungsanalyse • Requirements elicitation • Requirements recording • grouping and documenting the requirements in a designated form, such as naturallanguage sentences, use cases, user stories, or process specifications Requirements analysis • communicating with customers and users to determine what their requirements are determining whether the stated requirements are clear, complete, unambiguous, and consistent Requirements tracing Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 28 linking the requirements to other design artifacts such as code fragments and test cases What can be tool supported • Requirements definition and elicitation • • • check lists, tables, templates, …, import functionaity Requirements recording, documentation and reporting interaction to word processing and document generation models, use cases, use case validator Requirements analysis, verification and validation refinement, model checking & transformation, consistency mostly academic methods Requirements tracing classification, prioritization, selection possibilities description, stakeholders, effort estimations linking, integration with other tools configuration/change control, history requirements reuse / software product lines Howto zur Formulierung von Anforderungen **************************************************** Funktionalität von RM Tools • • Kernfunktionalität: Datenbank (jede Anforderung ist ein Eintrag) Sammlung und Speicherung, Versionierung und Verwaltung, Verlinkung Zusätzliche Funktionalität Versionsmanagement (e.g. CVS) Konfigurationsmanagement (e.g. configurator) Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 29 • • Groupware (CSCW, Task lists usw.) Anforderungserhebungshilfe Checklisten, Tabellen, Schablonen, …, Importfunktionen Interaktion zu Texteditoren und Dokumentgenerierungssystemen Interaktion zu Modellierungswerkzeugen Validierungshilfe Formalisierung, Transformation & Verfeinerung, Modellprüfung, … Requirements Engineering – Tools • Industriestandard: DOORS® • 3-8K€/Lizenz Open Source Varianten verfügbar + Bemerkungen von Copreci Polarion Requirements / ALM Ausarbeiten Pohl5 klassifiziert drei Arten von Artefakten: Ziele, Szenarien und Lösungsorientierte Anforderungen (Strategien) Fabrice Kordon, Jerome Hugues, Agusti Canals, Alain Dohet: Embedded Systems - Analysis and Modeling with SysML, UML and AADL. ISBN: 978-1-84821-500-9 Wiley-ISTE, 320 pages (April 2013) 5 W. Pohl, Requirements Engineering: Grundlagen, Prinzipien, Techniken. Springer 2007 Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 30 3 Modellierung Ein Ansatz, die Software-technischen Herausforderungen bei der Erstellung und Absicherung eingebetteter Software zu meistern, ist die modellbasierte Entwicklung. Bei diesem Entwicklungsparadima werden unterschiedliche Phasen des Software-Entwicklungsprozesses durch verschiedenartige Modelle unterstützt. Die Veranstaltung führt in die verschiedenen Aspekte der modellbasierten Entwicklung eingebetteter Software ein. Themen sind neben der Formulierung von Anforderungen und Methoden der Modellierung auch Modelltransformationen sowie Code- und Testgenerierung. Es werden Modellierungssprachen und -werkzeuge vorgestellt, die in der industriellen Praxis weite Verbreitung erlangt haben. In den begleitenden Übungen werden Beispiele typischer Steuerfunktionalitäten und ihre Umsetzung in eingebetteten Systemen behandelt und von den Teilnehmern vorgestellt. 3.1 Systemmodellierung (SysML) 3.2 Kontinuierliche Modellierung (Simulink / Scilab) 3.3 Diskrete Modellierung (UML) 4 Codegenerierung und Modelltransformation 5 Hardware für eingebettete Systeme 6 Sicherheit 6.1 Funktionale Sicherheit 6.2 Fehlertoleranzkonzepte 6.3 Werkzeugqualifikation 7 Validierung 7.1 Modellbasierter Test 7.2 Verifikation und statische Analyse 8 Spezielle Domänen 8.1 Automotive Software Engineering 8.2 Medizintechnik 8.3 Automatisierungstechnik, Robotik Prof. Dr. H. Schlingloff, Modellbasierte Software-Entwicklung eingebetteter Systeme Seite 31
