Prinzipen und Komponenten Eingebetteter Systeme (PKES) · Prinzipien und Komponenten eingebetteter...

1 30.01.2015 Prinzipien und Komponenten eingebetteter Systeme

Arbeitsgruppe ESS Jun.-Prof. Dr. Sebastian Zug

Prinzipen und Komponenten Eingebetteter Systeme (PKES) (12) Softwareentwicklung für eingebettete Geräte

Sebastian Zug Arbeitsgruppe: Embedded Smart Systems



„Veranstaltungslandkarte“

Sensoren

Mikrocontroller

Anwendungen

Architekturen

Aktoren

Kommunikation Energieversorgung

Scheduling

Arithmetik

Fehlertoleranz, Softwareentwicklung



• Peter Marwedel, Eingebettete Systeme Springer 2008 • Karsten Berns, Bernd Schürmann, Mario Trapp Eingebettete Systeme - Systemgrundlagen und Entwicklung eingebetteter Software Vieweg+Teubner (Quelle der Grafiken, sofern nicht anders vermerkt)

Literaturhinweise



• Welche Herausforderungen ergeben sich insbesondere für die Entwicklung von eingebetteten Geräten?

• Beschreiben Sie den V-Prozess bei der Softwareentwicklung. • Welcher Grundidee folgt die modellgetriebene Softwareentwicklung? • Welche Herausforderungen ergeben sich aus dem Ansatz? • Nennen Sie die Ebenen der modellgetriebenen Softwareentwicklung. • Sie haben im Rahmen der Vorlesung Assembler und C programmiert

sowie eine Demo zum Einsatz von Simulink gesehen. Welche Vor- und Nachteil ergeben sich aus den Ansätzen. Begründen Sie Ihre Aussagen anhand von Beispielen.

• Welche Parameter bestimmen das effektive Testen? • Wie ist das allgemeine Vorgehen beim Testen? • Was ist der Unterschied zwischen Verifikation und Validierung? • Welches Grundproblem löst der JTAG Standard? • Welche Testmechanismen lassen sich damit umsetzen?

Fragestellungen an diese Veranstaltung



• Starttermin, 31. August 2003 scheitert wegen:

- Fehlfunktionen der OBU - Fehlenden Messbrücken und Automaten - Software Fehler in den Terminals - Maut-Terminals mit zu geringem Sprachunterstützung - Schwierigkeiten bei der Systemintegration

• Als neuer Termin wurde der 2. November 2003 festgesetzt • Anfang November 2003 sind 86 Fehler im Mautsystem

dokumentiert und die Einführung auf unbestimmte Zeit verschoben

• … • seit 1. Januar 2006 läuft das System mit der vollen

Funktionalität.

• Die Bundesregierung bezifferte den Ausfall bereits budgetierter Einnahmen auf mindestens 156 Millionen Euro pro Monat.

Motivation - Mautsystem

Vorführender

Präsentationsnotizen

as Konsortium will die neue Autobahnnutzungsgebühr größtenteils automatisch eintreiben, und zwar über komplexe On Board Units (OBU) in den Lkw, die über Satellitennavigation, Mobilfunk, Infrarotsender und Datenspeicher verfügen. Der ursprüngliche Zeitplan sah den Integrationstest der insgesamt zwölf Software-Module bis Ende November 2002 vor, bis Ende Februar 2003 dann dreimonatige Funktionstests im Echtbetrieb, schließlich eine "User Friendly Phase" mit 5000 Lastwagen, geplant von Juni bis August. De facto sind die Mitarbeiter noch mit der Einzelprüfung der Software-Module befasst, die bereits Ende August 2002 abgeschlossen sein sollte. Falsche Projektplanung und -steuerung seien die Ursachen für die Verzögerung, so der Kritiker: Die Mitarbeiter des früheren Debis Systemhauses, heute T-Systems GEI, entwickelten an zwölf verschiedenen Stellen zwölf verschiedene Software-Systeme, darunter das betriebswirtschaftliche System und die Erhebungsdatenverwaltung. "Es wurde nicht von einem gemeinsamen Kern aus entwickelt, es gab keine Standards", behauptet der Insider. So habe man sich zwar auf Oracle als Datenbank geeinigt, doch der Zugriff sei bei jedem Modul anders. Auch bei den Oberflächen gebe es keine Gemeinsamkeiten. Die dezentrale Datenspeicherung der Stammdaten von acht der zwölf Software-Module beurteilt der IT-Fachmann als "Todsünde". Später wurde bekannt dass Michael Rummel, der damalige Geschäftsführer von Toll Collect, den Einbau der On-Board-Units angeordnet hatte, obwohl er wusste, dass diese nicht funktionstüchtig waren.[1] Eine Rolle bei dieser Entscheidung dürfte die oben angegebene Fähigkeit zum Softwareupdate per GSM-Funk gespielt haben, durch die die Software kurz vor Scharfschaltung des Systems noch hätte aktualisiert werden können. Ironischerweise war aber auch diese Funktion von den Softwareproblemen betroffen, wie sich später herausstellte.



• Ausfälle oder Fehlfunktionen sind in sicherheitskritischen Anwendungen nicht tolerabel

• häufig fehlende Wartbarkeit - Zugang schwierig (PKW Rückrufaktionen vs. geringwertige Güter) - Zugang nicht erwünscht

• Doppelte Herausforderung für eingebettete Geräte (Software/Hardware)

• Heterogene Struktur (Reaktive Ebene, Steuerungsebene, Leitebene) • Versionen (Featuremanagment) • Interdisziplinäre Teams -> Der Software/Hardware-Entwicklungsprozess braucht eine

übergreifende Steuerung

Herausforderung Softwareentwicklung für ES

Vorführender


Satelliten



Eingebettete Systeme - Systemgrundlagen und Entwicklung eingebetteter Software „Im Fokus standen die Hardware, die Sensorik und Aktuatorik, …

sowie die Entwicklung der benötigten Regler, Filter und Berechnungsmodelle. Software wurde letztlich nur als notwendiges Hilfsmittel gesehen den letzten kleinen Schritt … Die Entwicklung eingebetteter Software war in der Wahrnehmung also keine Aufgabe des Softwareengineerings, sondern beispielsweise eine Teilaufgabe der Regelungstechnik oder des Maschinenbaus.“

Forumeintrag „Die einzige Wahrheit liegt im Code, alles andere ist nur

inkonsistente Dokumentation.“

Ausgangspunkt



Aber: Lücke zwischen der Definition der Anforderungen, der Implementierung und der Validierung

Wie machen wir Komplexität handhabbar?

Assembler

C, C++

Simulink

Abstraktionen Hardwarenähe

Register

HAL-Libraries

Betriebssysteme

Programmiersprachen Frameworks



V-Prozess

Funktionsspezifikation

Systemspezifikation

Vorführender


Eingebettete Systeme – Verschiedene Systemspezifikationen Iterativer Prozess



• Modellbasierte Entwicklung zielt auf die abstrakte Definition des Systems anstatt der Programmierung

• Modellierungselementen bilden das Verhalten, Eigenschaften usw. abstrahiert nach anstatt mit Variablen, Schleifen und Funktionsaufrufen zu arbeiten

• in Modellierungssprachen stehen Konstrukte wie Übertragungs-funktionen, Fouriertransformationen oder Zustandsautomaten zur Verfügung.

• Quellcode wird nicht mehr manuell geschrieben, sondern weitgehend automatisch generiert.

• Modelle stellen sowohl Implementierung als auch Dokumentation dar.

Modellorientierte Entwicklung



V-Prozess am Beispiel

Differentieller Roboter, 8Bit, …

„Überwachen unseres Labortisches“

UML Modell Komponenten, Interaktion, Zustandsmaschine

Funktionale Beschreibung der Komponenten

Programmierung


Systemspezifikation



• Strukturmodelle • Interaktionsmodelle • Verhaltensmodelle

Welche Modellierungswerkzeuge kommen wo zum Einsatz?

Vorführender


Prinzipiell unterscheiden wir zwischen drei Klassen von Modellierungstechniken wie sie in Abb. 7-1.dargestellt sind. Betrachtet man sich die Aufgaben der Modellierung in der Softwareentwicklung, so ist es zunächst notwendig die Struktur des Systems zu beschreiben. Dazu werden die einzelnen Komponenten, deren Schnittstellen, sowie deren Verbindung zueinander modelliert. Dies erfolgt durch die Verwendung von Strukturmodellen. Beispiele für Strukturmodelle sind u.a. UML Klassendiagramme, kompositionale Strukturdiagramme, Komponentendiagramme oder auch Verteilungsdiagramme, wobei die Liste noch sehr lange fortgesetzt werden könnte. All diesen Modellen ist gemein, dass sie die Beziehungen zwischen Komponenten rein statisch beschreiben, die Interaktion zwischen Komponenten allerdings meist dynamisch erfolgt. Daher wird zusätzlich die Klasse der Interaktionsmodelle benötigt, die das dynamische Zusammenspiel zwischen Komponenten modellieren. Beispiele dafür sind Sequenzdiagramme, die Abläufe innerhalb eines Systems im Zusammenspiel der einzelnen Komponenten aufzeigen, indem zeitlich geordnet die ausgetauschten Informationen und Daten modelliert werden. Alternativ zu Sequenzdiagrammen lassen sich auch Kollaborationsdiagramme verwenden. Als weitere Alternative stehen beispielsweise auch Aktivitätsdiagramme zur Verfügung, sofern sich diese über mehrere Komponenten hinweg erstrecken und eher für die Beziehungen zwischen den Komponenten als für das interne Verhalten einzelner Komponenten verwendet werden. Verhaltensmodelle werden genutzt, um das Verhalten einer einzelnen Systemeinheit zu beschrieben, d.h. Verhalten, das sich nicht durch die Kollaborationen mehrerer Komponenten ergibt. Dies beinhaltet zum einen das Verhalten von Modulen, d.h. von Komponenten, die nicht mehr weiter strukturell verfeinert werden. Verhaltensmodelle sind aber vielfältig einsetzbar und kommen beispielsweise auch im Rahmen der Funktionsentwicklung zum Einsatz, um das Verhalten von Funktionen zu modellieren.



Verhaltensmodellierung mit Simulink



• Labview

Alternativen zur Modellierung eingebetteter Systeme

Source: http://www.ni.com/newsletter/51735/de/

Vorführender


Flache Sequenzstrukturen vermeiden Daten effektiv weitergeben Mit Modularität Entwicklungszeit sparen Kompakte Blockdiagramme erstellen Ausführliche Dokumentation verfassen



• Xcos

Alternativen zur Modellierung eingebetteter Systeme

Source: http://www.scilab.com



Probleme: • Integration der Schnittstellen • Datentypen und Speicherplatzanforderungen • Zeitannahmen • Verteilung auf mehrere Steuergeräte

Häufig ist eine manuelle Nachbesserung notwendig!

Herausforderung Codegenerierung Modelle ausführbar = Softwareentwicklung abgeschlossen?




Systemspezifikation

Hälfte des Weges geschafft!

?



Was testen? • Chips auf einem Board, chipinterne Komponenten.

Wie testen? • Generelle Probleme: Komplexe Schaltungen erfordern ausführliche

Tests. Große Mengen von Testdaten, Probleme mit sequentiellen Schaltungen, Auswertung schwierig.

• Probleme auf Board-Ebene: Isolation von Chips vom Rest der elektronischen Schaltungen, Anlegen von Testmustern an die Pins der Testkandidaten.

• Probleme auf Chip-Ebene: Isolation von Komponenten, Anlegen von Testmustern an die internen Strukturen, eklatant schlechtes Verhältnis von verfügbaren Pins zu Anzahl der internen Komponenten.

Integrationstests



Anlegen eines Musters, das es erlaubt, einen bestimmten Fehler zu aktivieren und auf einem Pfad zum Ausgang zu propagieren.

• Kontrollierbarkeit: Kann ich einen bestimmten Fehler (Controllability) aktivieren ?

• Beobachtbarkeit: Kann der Fehler am Ausgang erfasst und (Observability) signalisiert werden?

• Vollständigkeit Wurden alle Zustände erfasst? (Coverage)

Grundprinzip

X

C

D

A

B

Out

A B C D Out Exp

0 0 0 1 0

0 0 1 0 0

0 0 1 1 1

0 1/0 0 0 0

… …

Vorführender


Fehlermodell !!!



Coverage Kombinatorische Schaltung Sequentielle Schaltung

0

n

0

n

m Zustände

2n Testmuster 2n+m Testmuster



1. Erzeugung der Testmuster, 2. Anwendung der Testmuster, 3. Beobachtung des Systemverhaltens und 4. Vergleich der Ergebnisse Vorteil der modellgetriebenen Softwareentwicklung ist die

vereinfachte Generierung von Vergleichsdaten.

Allgemeines Vorgehen

Target

Fehlerinjektion

Ausgaben

Simulation

Eingaben

Ausgaben

Fehlerinjektion



Praktische Umsetzung

Wie bringt man Testmuster an die Eingänge, wie erfasst man die Ausgangsdaten – intuitive Antwort „Bed of Nails“



JTAG Standard (IEEE 1149)

Boundary Scan

int. logic

int. logic

Testdaten Testergebnisse



JTAG (IEEE std. 1149.1 Compliant) Interface with access to: • all Internal Peripheral Units • Internal and External RAM • Internal Register File • Program Counter • EEPROM and Flash Memories Extensive On-chip Debug Support for Break Conditions, Including • AVR Break Instruction • Break on Change of Program Memory Flow • Single Step Break • Program Memory Breakpoints on Single Address or Address

Range • Data Memory Breakpoints on Single Address or Address Range • Programming of Flash, EEPROM, Fuses, and Lock Bits through

the JTAG Interface • On-chip Debugging Supported by AVR Studio

On-Chip Debugging with Atmel 2560



Vortragsankündigung



Danke für das große Interesse und die hohe Motivation!

Prinzipen und Komponenten Eingebetteter Systeme (PKES) · Prinzipien und Komponenten eingebetteter...

Documents

Transcript of Prinzipen und Komponenten Eingebetteter Systeme (PKES) · Prinzipien und Komponenten eingebetteter...