Home

Embedded Systems Engineering Vorlesung V1_01

1. Hardware Mikroprozessor Speicher Input Output Bild 6 2 Betriebssystemaufgaben Das BIOS und das File Management System auch als Disk Operating System DOS bezeichnet sind nat rlich gute alte Bekannte Sie bieten Methoden um am Rechnersystem einfach auf den Input Output Bereich sowie den Massenspeicher zuzugreifen und z hlen damit klassisch zu der Erweiterung der Funktionalit t Gleiches gilt f r das Communication System CS das aber erst in den letzten Jahren verst rkt aufgekommen ist Hier muss klar festgehalten werden In Zukunft wird es kaum noch Betriebssysteme im Embedded Bereich geben die keine Kommuni kation mehr beinhalten Memory Management System MMS und Resource Management System RMS geh ren zur Verwaltung der Betriebsmittel Hierzu z hlt auch die Ausgabe an Bildschirmen h ufig als Graphical User Interface GUI bezeichnet Eigentlich k nnte man auch das Process Management System TMS das die Ressource Rechenzeit Time verwaltet hier hinzuz hlen aber dieser Teil hat eine besondere Stellung denn hier wird der Gesamtablauf kontrolliert 6 Betriebssysteme als virtuelle Maschinen 89 6 2 Betriebssystemarchitekturen F r ein einfaches Betriebssystem das keine Kontrollfunktion im Sinne des TMS enth lt reicht es ggf aus eine Funktionssammlung anzubieten Das Betriebs system wird dadurch ausschlie lich von Applikationen via API Application Pro grammering Interface aufge
2. AD Converter State Machine for Reading ADC V AD Converter L V Upper Limit gt Compare Unit ers z Microcontroller 4 p Init Data INT Signal ADC Value PLD ADC Register lt gt Bild 5 6 Implementierung der AD ISR in PLD Zur Unterbringung von Ereignisbehandlungen ist nat rlich auch hergestellte Hard ware ASIC geeignet dies stellt lediglich eine Frage der Herstellungszahlen und kosten dar F r den Jitter und die Bearbeitungszeiten der Hardware Routinen kann man allgemein sagen dass diese in der Gr enordnung eines oder weniger Takte liegt 5 4 Zusammenfassung der Zeitkriterien f r lokale Systeme Aus den bisherigen Betrachtungen l sst sich res mieren dass einige Zeitkriterien existieren die die Behandlung und die Implementierungsart entscheidend beein flussen Im Wesentlichen sind dies drei Kriterien die aus der Prozessumgebung stammen e Der zeitliche Jitter Tjiner auch als maximale Latenzzeit zu bezeichnen siehe Definition 2 6 gibt diejenige Zeit an mit der der Start der Reaktionsroutine schwanken darf Gr nde hierf r k nnen zeitsynchrone Aktivit ten sein f r die nur geringe Abweichungen akzeptierbar sind Liegt dieser Jitter unterhalb ca 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 81 10 Befehlsausf hrungszeiten so kann mit Sicherheit davon ausgegangen werden in einem f r Prozessoren kritischen Bereich zu liegen Die unkritische Grenze ab
3. Mit Hilfe einer nochmalig erweiterten Hardwareunterst tzung im Prozessor und im Interrupt Request Controller kann dann ein erweitertes IRQ Handling eingef hrt werden Die erg nzende Hardware ist in Bild 3 6 dargestellt Die Erg nzung besteht darin einen weiteren Timer pro Interrupt Request im IRQ Controller vorzusehen Dieser Timer wird mit jeder IRQ Speicherung gestartet und enth lt einen Ablaufwert der der maximalen Reaktionszeit entspricht Ist die Interrupt Service Routine beendet so muss der Timer nat rlich gestoppt werden z B explizit durch zus tzliche Befehle oder implizit durch Hardwareerweiterung in der CPU erweiterter RETI Befehl Return from Interrupt mit IRQ Nummer Der Ablauf eines solchen Timers soll dann eine Time Exception ausl sen und damit eine Ausnahmebehandlung initiieren Es ist hierbei m glich alle derart erg nzten IRQs mit einer Time Exception zu versehen und damit in einer Routine zu behandeln 36 Embedded Systems Engineering Skript V1 00 Storing ra e IRQ Controller ext IRQ Interrupt l Priority RE Request e POT Management Service In Service Timer_runs 1 Timer per IRQ e Timer_Start Channel Timer B Exception gt Tecin 1 Exception Timer to CPU per IRQ Channel ISR done Bild 3 6 Erweiterter IRQ Controller mit Time Exception Die Ausnahmeroutine kann dann von fallweise entscheiden wie vorzugehen ist E
4. Abtastung Quantisierung N X E wert und zeitdiskret digital t L gt 0 T N t Codierung zweiwertig und zeitdiskret 0 T t Bild 1 4 Vorg nge bei der AD Wandlung Peripherie Digital Analog Wandler Der Digital Analog Wandler kurz D A Wandler Digital Analog Converter DAC erzeugt aus digitalen Signalen ein analoges Signal meist eine Spannung Dies stellt die Umkehrung der A D Wandlung dar Die Umsetzung erfolgt exakt abgesehen von Schaltungsfehlern d h ohne prinzipiellen Fehler wie bei der A D Wandlung G ngige Verfahren sind Pulsweiten Modulation pulse width modulation PWM und R 2R Netzwerke 10 Embedded Systems Engineering Skript V1 00 Peripherie Sensoren Zun chst sei die Definition eines Sensors gegeben 3 Definition 1 9 Ein Sensor ist eine Einrichtung zum Feststellen von physikalischen oder chemi schen Eingangsgr en die optional eine Messwertzuordnung Skalierung der Gr en treffen kann sowie ggf ein digitales bzw digitalisierbares Ausgangssignal liefern kann Sensoren stellen also das prim re Element in einer Messkette dar und setzen vari able im Allgemeinen nichtelektrische Eingangsgr en in ein geeignetes insbeson dere elektrisches Messsignal um Hierbei k nnen ferner rezeptive Sensoren die nur passiv Signale umsetzen Beispiel Mikrofon sowie signalbearbeitende Sensoren die die Umwelt stimulieren und die A
5. 54 Embedded Systems Engineering Skript V1 00 Definition 4 4 Error Irrtum Fehlhandlung Es handelt sich um eine fehlerhafte Aktion die zu einer fehlerhaften Programmstelle f hrt Daraus ergibt sich dass Fehlhandlungen errors bei der Programmentwicklung oder durch u ere Einfl sse z B H henstrahlung Hardwareprobleme z B bei Flash EEPROM Zellen oder durch Bauteilestreuungen zu Fehlern faults im Pro gramm f hren die ihrerseits zu einem Fehlverhalten failure bei der Ausf hrung f hren k nnen Hier soll die Qualit tssicherung entgegenwirken und zwar sowohl konstruktiv als auch analytisch Um die Definitionen f r Validierung und Verifikation zu verstehen muss man den kompletten Designprozess betrachten Bild 4 1 Aus einer informellen Problembe schreibung folgt eine formale Anforderungsdefinition aus der heraus dann das ei gentliche Rechnersystem z B mit Mikroprozessor und Software konstruiert wird Die bereinstimmung von Problem und Anforderungsbeschreibung ist sehr schwierig festzustellen allein weil die Problembeschreibung informell und damit nicht maschinenpr fbar ist Dieser Vorgang wird Validierung genannt Anforderungs Problem P definition R 4 Validierung Verifikation Korrektheits berpr fung Softwaresystem S Bild 4 1 Einordnung der Begriffe Validierung und Verifikation Die Verifikation hingegen in grunds tzlich durch formales Vorgehen l sbar aller dings oft eben
6. 78 5 4 Zusammenfassung der Zeitkriterien f r lokale Systeme 80 5 4 1 Vergleich Zeit Steuerung und modifizierte Ereignis Steuerung 82 5 4 2 bertragung der Ergebnisse auf verteilte Systeme 84 5 4 3 Verteilung der Zeit in verteilten Systemen unsnesnessesnesnnennesnennnennn 85 6 Betriebssysteme als virtuelle Maschinen 87 6 1 Betriebssystem als Teil der Systemsoftware ecuscossonssorsonssossonenonsnnennnene 87 6 2 Betriebssystemarchitekturen 000s0000s000s000000n0se0nsennnnonnsesnnsnnsnnsnenssnnene 89 6 3 Scheduling Strategien ursoussorsonssossnessssnnennesnnennssnnsnnsnnssonssnnssnennnsnnennnene 90 6 3 1 Gr hdbegrifie aea e a aree EE AE AEA AEAEE 90 6 3 2 Ans tze zum Scheduling e seseeeeesseeeseesreessreersrrereresrerrsreererenerrereersseer 92 7 Fallstudie Verteiltes eingebettetes System 95 7 1 Systemkonfiguration eseesessesessesessosoesessesossosossesossessesoosesossesoesessesoesesoeseses 95 7 2 Auslegung des lokalen Busses esessesesseseosesoosessosessosoesosoesessoseesosoessesossesose 96 7 3 Architektur der Software sesueseonesennenennenennenennenennenennenennenennenennenennenennenene 97 Literatur dena aneheiiuie 98 Sachwortverzeichnis 2222442440 200 00a0nnnn ann nnnnnnnnnnnnnnn nn 100 1 Einf hrung in eingebettete Systeme Eingebettete Systeme embedded systems sind Computersysteme die aus Hard ware und
7. 2 Alle markierten Knoten d rfen nicht entfernt werden 3 Alle nicht markierte Knoten die keine Verzweigung enthalten werden entfernt 4 Kanten die zum Beginn einer Schleife f hren die nur unmarkierte Knoten ent h lt werden entfernt 5 Kanten die zwei Knoten so verbinden dass kein Alternativpfad f r diese Ver bindung mit markierten Knoten existiert werden entfernt Der reduzierte Graph muss nun nur noch getestet werden 4 2 8 Systemtests Zum Schluss folgen die Systemtests Sie beziehen sich auf das gesamte System also die Zusammenf gung von Hard und Software Hierbei ist h ufig Kreativit t gefordert denn dem Test fehlt ggf die Au enumgebung Einige M glichkeiten wie Teiltests aussehen k nnen seien hier aufgez hlt e Belastungs und Performancetests Diese stellen fest wie das Verhalten unter erwarteter Last Performancetest bzw unter berlast Belastungstest ist Was hierbei eine berlast ist ist wiederum nicht exakt definierbar aber es gibt An haltspunkte So k nnen Eingaberaten h her sein als die Pollingrate bei Timer triggered bzw Event triggered Systemen Ger te die das System beeinflussen werden auf h chste oder niedrigste Geschwindigkeit gestellt usw e Failover und Recovery Test Hier wird gepr ft wie sich verschiedene Hard wareausf lle bemerkbar machen ob beispielsweise Daten verloren gehen in konsistente Zust nde erreicht werden usw e Ressource Test Die im Vordergrun
8. Zu diesem Prozess geh ren der gesamte Code und die statischen und dynamisch angelegten Datenbereiche einschlie lich Stack Heap und Register Der Code wiederum kann mehrere Teile enthalten die unabh ngig voneinander arbeiten k nnen Solche Tei le werden Threads Aktivit tsf den genannt Ein Thread ist also ein Teil eines Prozesses bestehend aus einem in sich geschlos senen Bearbeitungsstrang und einem recht minimalen eigenen Datenkontext Letz terer wird ben tigt damit die Threads berhaupt parallel zueinander arbeiten k n nen und meist beschr nkt sich dieser auf den Registersatz des ausf hrenden Pro zessors Welche Formen des Multiprocessing oder Multithreading gibt es denn Das am h ufigsten angewandte Konzept ist das pr emptive Multiprocessing Hier wird von einem Betriebssystem kern der aktive Prozess nach einer Weile verdr ngt zu Gunsten der anderen Diese Umschaltung wird Scheduling genannt Die andere Form ist das kooperative Multiprocessing das von jedem Prozess er wartet dass dieser die Kontrolle an den Kern von sich aus zur ckgibt Letztere Version birgt die Gefahr in sich dass bei nicht kooperativen Prozessen bzw Feh lern das gesamte System blockiert wird Beim Multithreading ist es hnlich wobei allerdings die Instanz die ber das Scheduling der Threads entscheidet auch im Programm liegen kann Beispiel Java Umgebung Das Umschalten zwischen Threads eines Prozesses ist dabei we sentlich unau
9. dass unterschiedliche Compiler eingesetzt und zwei verschiedene Versionen von unterschiedlichen Designteams erstellt werden m ssen oder die Software muss in einem komplexen Prozess zertifiziert werden oder auch beides 4 4 Coding Rules Abschlie end in diesem Kapitel sollen beispielhaft Codierungsregeln Coding Rules zitiert werden die gerade f r Softwareentwicklung in sicherheitskritischen Bereichen gelten und anerkannt sind ber Codierungsregeln kann man sich na t rlich sehr ausf hrlich auslassen jede Firma jede Entwicklungsgruppe die etwas auf sich h lt hat mindestens ein Regelwerk das auch sehr umf nglich sein kann Die hier zitierten Regeln 23 stellen mit einer Anzahl von 10 ein bersichtliches Regelwerk dar Regel 1 Im gesamten Code sollen nur einfache Kontrollflusskonstrukte verwendet werden Insbesondere sollen goto direkte oder indirekte Rekursion vermieden werden Dies resultiert insbesondere in einer erh hten Klarheit im Code der leichter zu analysieren und zu beurteilen ist Die Vermeidung von Rekursion resultiert in azyklische Codegraphen die wesentlich einfacher bez glich Stackgr e und Aus f hrungszeit analysiert werden k nnen Die Regel kann noch dadurch versch rft werden dass pro Funktion nur ein ein ziger R cksprung erlaubt ist Regel 2 Alle Schleifen m ssen eine Konstante als obere Grenze haben Es muss f r Code check Tools einfach m glich sein die Anzahl der
10. erreichen Wird diese Abdeckung nicht erreicht bedeutet dies dass die erdachten F lle zum Integrationstest nicht die volle Systemfunktionalit t abdecken und es muss nachgebessert werden 4 2 7 3 Strukturiertes Testen Die strukturierten Integrationstests SIT wurden 1982 von Thomas McCabe eingef hrt Sie beruhen darauf die minimal notwendige Anzahl von voneinander unabh ngigen Programmpfaden zu bestimmen Unabh ngig ist dabei ein Pro grammpfad wenn er nicht durch eine Linearkombination anderer Programmpfade darstellbar ist a b c Bild 4 3 Kontrollflussgraphen mit den zyklomatischen Komplexit ten a 1 b 3 c 6 Ausgangspunkte ist dabei ein Kontrollflussgraph des Programms Bild 4 3 Hierin werden die voneinander unabh ngigen Programmpfade bestimmt dies ergibt die so genannte zyklomatische Komplexit t Es gilt hier die Formel 4 Softwarequalit t 65 CC E N 2 mit E Anzahl der Kanten N Anzahl der Knoten F r den Integrationstest kann der Graph reduziert werden denn hier sollen ja nur die Aufrufe der Unterprogramme getestet werden Alle Programmpfade die keinen solchen Aufruf enthalten k nnen somit ausgeschlossen werden allerdings nur unter der Voraussetzung dass das Dateninterface zu den Unterprogrammen aus schlie lich ber Parameter realisiert ist In diesem Fall k nnen folgende Operatio nen zur Reduktion durchgef hrt werden 1 Alle Knoten die ein Unterprogramm aufrufen werden markiert
11. hrt dann zur eingangs schon erw hnten perfekten Synchronie Insbesondere werden hier 3 Design von eingebetteten Systemen 49 durch keine k nstlichen Verz gerungen notwendig etwa um die angenom mene Zeit auch wirklich zu erreichen Esterel basiert auf der Hypothese dass Signalaustausch und elementare Berech nungen keine Zeit ben tigen und somit Systemausgaben mit ihren Eingaben syn chron ablaufen Hierdurch wird in Esterel ein nebenl ufiges deterministisches Verhalten m glich 3 5 2 Determinismus Ein Programm in Esterel verarbeitet Str me von Ereignissen events Diese Ereig nisse dienen zur internen und externen Kommunikation und ein Ereignis kann aus mehreren Elementarereignissen z B Signalen bestehen die ihrerseits nicht unterbrechbar sind Die interne Verarbeitung ist schnell genug dass w hrend der Berechnungszeit keine weitere Eingabe eintritt Dieses Berechnungsintervall wird Moment oder Augenblick instant genannt und ist in der Annahme unendlich kurz instantaneous Nun ist Esterel so definiert dass hiermit deterministische reaktive Systeme be schrieben werden sollen F r ein einzelnes Programm gilt dann dass dieses garan tiert deterministisch ist aber bei der Parallelkomposition mehrerer Programme kann es dennoch zu Nichtdeterminismus kommen Wie kann man sich das vorstellen Angenommen es existiert ein oder mehrere Ereignisse auf die mehrere Esterel Programme reagieren und zwar mit Ausgaben
12. integriert werden kann So kann eine Task die berhaupt keine Zeitbindung besitzt dies d rfte in der Praxis selten vorkommen nat rlich in die Klasse der generellen Tasks mit Zeit bindung sortiert werden Diese Taskklasse ist in Bild 5 1 dargestellt wurde jedoch nicht in die Klassifizierung aufgenommen da sie irrelevant f r das hier dargestellte Designprinzip ist Streng zyklisch ablaufende Tasks und Ereignis gesteuerte Tasks sind in ihrer De signpriorit t in etwa gleichzusetzen gt Bild 5 1 In der Praxis kann die Imple mentierung auch sehr hnlich sein indem die zyklischen Tasks in Interrupt Service Routinen ISR mit Timersteuerung und die Ereignis gesteuerten Tasks in 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 73 anderen ISRs behandelt werden Die Unterscheidung soll dennoch aufrecht erhal ten bleiben da zwischen beiden Implementierungen ein fundamentaler Unterschied existiert 5 1 2 L sungsans tze f r die verschiedenen Aufgabenklassen Im n chsten Schritt des Designverfahren werden die Mitglieder der einzelnen Klassen zun chst getrennt voneinander implementiert und die maximale Ausf h rungszeit jeweils berechnet In erster N herung werden daf r die WCET der ein zelnen Teilaufgaben als voneinander unabh ngig angenommen Um dies wirklich zu erreichen muss auf ein blockierendes Warten bei Kommunikation zwischen den Tasks unbedingt verzichtet werden denn dies kann zu gro en Pro
13. und die Freigabe free sowie die Garbage Collection zeigen oftmals unvorhersagbare Verhaltensweisen daher sollte hiervon im eigentlichen Betrieb Abstand genommen werden Zudem stellt die dynamische Speicherverwaltung im Programm eine hervorragende Fehlerquelle dar bez glich Speichernutzung nach R ckgabe Speicherbereichs berschreitung etc Regel 4 Keine Funktion soll mehr als 60 Zeilen haben d h bei einer Zeile pro Statement und pro Deklaration soll die Funktion auf einer Seite ausgedruckt werden k nnen Diese Regel dient einfach der Lesbarkeit und der bersichtlichkeit des Codes Regel 5 Die Dichte an Assertions siehe auch Regel 2 soll im Durchschnitt mindestens 2 pro Funktion betragen Hierdurch sollen alle besonderen Situationen die im Be trieb nicht auftauchen d rfen abgefangen werden Die Assertions m ssen seiten effektfrei sein und sollen als Boolesche Tests definiert werden 4 Softwarequalit t 69 Die assert Funktionen selbst die bei fehlgeschlagenen Tests aufgerufen wer den m ssen die Situation explizit bereinigen und z B einen Fehlercode produ zieren bzw zur ckgeben Untersuchungen zeigen dass Code mit derartigen Assertions die z B Vor und Nachbedingungen von Funktionen Werten R ckgabewerten usw testen sehr de fensiv arbeitet und einer raschen Fehlerfindung im Test dient Die Freiheit von Sei teneffekten l sst es dabei zu dass der Code bei Performance kritischen Absch
14. 2 5 Eine asynchrone Unterbrechung Asynchronous Interrupt Request IRO ist ein durch das Prozessor externe Umfeld generiertes Signal das einen Zustand anzeigt und oder eine Behandlung durch den Prozessor anfordert Dieses Signal ist nicht mit dem Programmlauf synchronisiert 2 Echtzeitsysteme 17 Bei zeitgesteuerten Systemen erfolgt keine Reaktion auf Eingabeereignisse die Unterbrechungen werden lediglich durch einen ggf mehrere periodische Zeitgeber Timer ausgel st Sensoren werden dann vom Steuerger t aktiv abgefragt ein Verfahren das Polling genannt wird Dieses Verfahren hat den gro en Vorteil dass das Verhalten s mtlicher System aktivit ten zur Compilezeit vollst ndig planbar Dies ist gerade f r den Einsatz in Echtzeitsystemen ein erheblicher Vorteil da priori berpr ft werden kann ob Echtzeitanforderungen eingehalten werden Dies wird in Abschnitt 3 2 genauer untersucht Das Design dieser Zeitsteuerung muss allerdings sehr pr zise durchgef hrt werden um die Ereignisse zeitlich korrekt aufzunehmen und zu verarbeiten Ggf m ssen auch Zwischenpufferungen z B bei einer schnellen Datenfolge eingef gt werden Um den zeitlichen Ablauf und seine Bedingungen quantifizieren zu k nnen seien folgende Zeiten definiert Definition 2 6 Die Latenzzeit Latency Time ist diejenige vom Auftreten eines Ereignisses bis zum Start der Behandlungsroutine Diese Zeit kann auf den Einzelfall bezogen werden si
15. 40 72 I Broadcasting cnene 49 TER E eu 84 a 2 Follow Up Message nnd 85 nicht blockierend ii 20 Sync Message 85 Be 2 Ehren N a Installationstest enen 64 Ir RER en Integrationstest nneeseeeen 62 ZU Zn A E 63 synchron AATE E E 20 kun 63 Time Triggered 84 eo ee ee a konstruktive Semantik 50 2 ron pan i 62 kontinuierlich 4 Be Br Kontrolleinheit 5 7 en 15 Kurzschlussstrom eee 24 Clear Interrupt Enable 74 L Ereignis gesteueit unene 74 ggT Methode ne 28 Latency Time Siehe Latenzzeit NUMMER 44 Latenzzeit 16 29 74 75 Interrupt Request Controller30 34 Leakage Current Siehe Leckstrom Interrupt Service Routine 27 Leckstrom nerien 24 Koinzidenz unncneneen 28 Leistungseffizienz 37 Kombination 28 komplexes Schema 29 M Be EBEN NET 2 Maschinensicherheit 65 modifizierter Interrupt Request Comm E Controll 33 diversit tre Redundanz 66 a EA Performance Level 65 Non Maskable 39 Sachwortverzeichnis 103 Security Integrity Level 65 Power Dissipation Siehe Mechatronik 5 Verlustleistung Mikroprozessor Power State Machine 39 Betriebszustand 39
16. Definition 4 6 Die Verf gbarkeit availability eines Systems ist der Zeitraum gemessen am An teil der Gesamtbetriebszeit des Systems in dem es f r den beabsichtigten Zweck eingesetzt werden kann Defintion 4 7 Ein Systemausfall failure liegt vor wenn ein System sein geforderte Funktion nicht mehr erf llt Definition 4 8 Ein Risiko ist das Produkt der zu erwartenden Eintrittsh ufigkeit Wahrscheinlich keit eines zum Schaden f hrenden Ereignisses und des bei Eintritt des Ereignisses zu erwartenden Schadensausma es Mit Grenzrisiko wird das gr te noch vertretbare Risiko bezeichnet Hier sollte ganz deutlich sein dass das was noch zumut oder vertretbar ist durch die technologische Machbarkeit beeinflusst bzw definiert wird Dies kann beispielsweise so geschehen dass eine neue Maschine z B Flugzeug zugelassen bzw zertifiziert wird wenn eine katastrophale Fehlersituation nur noch mit einer Wahrscheinlichkeit von 10 pro Betriebsstunde auftreten kann integriert ber alle Maschinen dieses Typs Wie dies berechnet werden kann steht u a in den Normen zur Maschinensicherheit gt 4 3 56 Embedded Systems Engineering Skript V1 00 4 2 1 Konstruktive Ma nahmen Eine der wichtigsten Fragen f r die Konstruktion bzw das Design sicherheitskri tischer Maschinen ist diejenige nach konstruktiven Ma nahmen zur Vermeidung von Fehlern oder wenigstens Fehlerfolgen Diese Art der Fehlertoleranz basiert
17. Landebahn ab fing Feuer so dass 2 Menschen starben und 54 verletzt wurden Der Fehler lag in der Entscheidung der Konstrukteure und Software Ingenieure wie die Messungen der Bodensensoren interpretiert wurden Der aufgetretene Fall war nicht abgedeckt und somit kam es zum Ungl ck Im zweiten Fall musste die europ ische Tr gerrakete Ariane 5 bei ihrem Jung fernflug gesprengt werden weil sie von ihrer geplanten Bahn stark abwich und in bewohntes Gebiet abzust rzen drohte Die Ursache hier war ein nicht abgefangener Daten berlauf bei der Berechnung der Flugbahn Die Software war einfach von der Vorg ngerrakete bernommen worden bei der bewiesen werden konnte dass dieser berlauf niemals stattfinden konnte Die Ariane 5 hingegen war schub st rker und die Rakete erreichte Geschwindigkeiten deren interne Darstellung 32767 16 bit Integer mit Vorzeichen berschritt Der Datenunterlauf f hrte dann 4 Softwarequalit t 53 zur Bahnabweichung und zur Sprengung Ein Klassiker unter den Softwarefehlern der mithilfe von Datenbereichskontrollen h tte abgefangen werden k nnen Beide Fehler resultierten in Tod Verletzung oder Gef hrdung von Menschen sowie in erhebliche wirtschaftliche Verluste Kriterien daf r dass die Systeme sicher heitskritisch waren 4 1 2 Grundlegende Begriffe und Definitionen Als zentral in einem modernen Projekt wird heute die Softwarequalit t erachtet Dabei stellt sich nat rlich die Frage was dar
18. Precision Time Protocol 84 Idles nase net 39 preemptives Scheduling 91 Sleep nn ehe 39 Prozess 8 19 89 Modellerde ienne 41 Kommunikation e 19 formal Satien 41 Synchronisation eee 19 Modellierungssprachen Zustandsmodell 90 SYSTEME osise 41 45 Prozesszustandsmodell 90 UML BER N 41 43 PTP Siehe Precision Time Protocol Modultest seeno 61 Black Box Test e 61 R Pinten ng in quivalenzklassen61 Randbedingungen 1 monolithisches System 4 3 Multiprocessing 18 90 Papio Frototypitg IR SR kKooperativ uuneeesssnesnennesnennenn k 19 Reaton TE SNE BEAKEUN Z i pr emptiv ars raen 19 Reaki I i 0 Multithreadingnanannnn 18 Se AAT Mutithreadin anna 90 Ba a O a Real Time System Siehe N Echtzeitsystem Rechtzeitigkeit 2 14 Nebenl ufigkeit ne 18 Redundanz 55 Netzwerk dynamisch 55 Byte Flight eeene 84 hybrid nasser 55 CSMAI CA nununsesenssenserseensennnn 84 N Version Programming 56 ESMA ED uunnsissenisenstens 84 Recovery Blocks 56 Time Triggered Protocol 84 SOWAT E asneiras naeio 56 NFA ninaona o ieas 3 St tisch u ine 55 Non Deterministic Finite Automaton rekonfigurierbare Mikroprozessoren ESEL RUE R IL aT Siehe NFA een
19. Punkt ist fast automatisch dadurch erf llt dass sich diese Methode auf kleine Mikrocontroller low MIPS world bezieht Diese Mikrocontroller be sitzen keinen Cache weil sie zumeist auch nur mit geringen Taktraten versehen sind etwa 20 MHz und weil der Cache Speicher sehr teuer w re Punkt 3 die Bestimmung der Anzahl der Ausf hrungstakte im Rahmen des Codes ist auf Ebene einer Hochsprache zurzeit nicht m glich Hier muss man auf As sembler ausweichen was mit erheblichen Problemen verbunden ist Hierunter f llt 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 77 auch zugleich Punkt 2 denn die eventuelle Auff llung von schnelleren Pfaden mit NOP Befehlen no operation zwecks Angleichung kann wiederum nur auf Assemblerebene erfolgen Bild 5 4 Mischung zweier Threads zwecks Software Thread Integration a Prim rthread zeitkritisch b Sekund rthread zeitunkritisch c Thread Integration 78 Embedded Systems Engineering Skript V1 00 Folgerichtig bem ht sich der Autor in 16 um eine neue Compilertechnologie die nach bersetzung in Assemblercode diesen analysiert die unterschiedlichen Wege in ihrer Ausf hrungszeit angleicht und schlie lich den Code mischt Nach Bestimmung der Ausf hrungszeiten wird gt Bild 5 4 der zeitkritische Code zyklusgenau in den auszuf hrenden Softwarethread eingef gt Hier ist auch offen sichtlich dass alle Zweige einer Verzweigung die gleiche Laufzeit
20. Software Hier k nnen spezielle Instruktionen oder das Setzen von Flags zum Einsatz kommen Im IDLE Modus ist die Taktversorgung prinzipiell einge schaltet insbesondere eine vorhandene PLL und die Peripherie eines Mikrocon trollers bleibt meist ebenfalls versorgt Aus diesem Grund k nnen Ereignisse im IRQ Controller wahrgenommen werden und f hren zum Aufwecken des Prozes sorkerns Im SLEEP Modus wird die Taktversorgung komplett ausgeschaltet die PLL ist ausgeschaltet Dadurch sinkt die Leistungsaufnahme nochmals auch die periphe ren Elemente werden ausgeschaltet Der Nachteil ist derjenige dass das Starten des Prozessors Controllers jetzt recht lange dauert weil die PLL sich erst wieder einphasen muss Au erdem k nnen nur noch asynchrone Ereignisse wahrgenom men werden meist ist dies ein singul res Ereignis z B der Non Maskable Interrupt NMI oder der Reset Die eigentliche Schwierigkeit mit der Power State Machine besteht darin Kriterien zu finden wann in welchen Zustand bergegangen werden kann Man denke dabei nur an die verschiedenen Energiesparmodi bekannter Rechner In Bild 3 9 ist es so dass der bergang nur Zeit keine Leistung kostet Dies kann im allgemeinen Fall jedoch anders sein und ein verkehrtes Abschalten k nnte sogar zu erh hter Verlustleistung f hren 3 Design von eingebetteten Systemen 41 Zurzeit sucht man nach neuen Methoden die die berg nge definieren F r den Systementwickler stellt dies
21. aufgerufen Dies ist zwar auch eine Art Ereignis Steuerung dar sie ist aber geplant und zyklisch auftretend In der Interrupt Ser vice Routine werden dann aller Prozesszust nde abgefragt und entsprechende Reaktionsroutinen aufgerufen e Beim kooperativen Systemaufbau ist jede Task verpflichtet eine Selbst Unter brechung nach einer definierten Anzahl von Befehlen einzuf gen Diese Unter brechung ist als Aufruf eines Schedulers implementiert dieser ruft dann eine weitere Task auf Dieses Verfahren ist unsch rfer und aufwendiger die Zeiten m ssen festgelegt werden sodass meist die erste Variante bevorzugt wird Innerhalb der entstandenen Zykluszeit kann dann das Gef ge der Aufgaben verteilt werden Es m ssen folgende Ungleichungen gelten t lt t 3 10 cycle critical baon t oycle 3 1 1 Mit teritica ist hierbei die systemkritische Zeit angenommen die f r ein ordnungs gem es Arbeiten nicht berschritten werden darf Diese Zeit wird durch den Prozess definiert Ungleichung 3 11 kann auch Tasks enthalten die mehrfach ber cksichtigt wer den weil sie beispielsweise mehrfach in einem Zyklus vorkommen m ssen F r 3 Design von eingebetteten Systemen 29 diese Tasks kann eine andere systemkritische Zeit gelten und diesem Umstand kann man durch den zeitlich verteilten Mehrfachaufruf Rechnung tragen Die Zeitdefinition im Mikrocontroller kann durch einen Timer erfolgen sie kann ggf sogar entfallen
22. aufweisen m s sen weil ansonsten von dem Zeitschema abgewichen wird Die L cken werden dann durch zeitlich unkritische Teile aufgef llt Dieses Verfahren wirft eine Reihe von Fragen auf die Compilertechnologie betref fend M glich ist es grunds tzlich wenn die Worst Case Execution Time WCET gleich der Best Case Execution Time BCET ist Die in 16 dargestellten Me thoden um den Code zu mischen sind dann von der G te der WCET Bestimmung und den M glichkeiten des Compilers m glichst einfache Threadwechsel einzu bauen abh ngig Der Gewinn an Performance verglichen mit einem normalen Scheduling ist allerdings betr chtlich er wird mit bis zum Faktor 2 an Perfor mance quantifiziert 5 3 Co Design Ansatz Partitionierung in PLD und Prozessoranteile Implizit wurde bei allen bisherigen Modellen zur Echtzeitf higkeit vorausgesetzt dass die charakteristischen Zeiten wie Reaktionszeit Antwortzeit usw wesentlich gr er sind als die Zeit die ein Prozessor zur Bearbeitung eines Befehls ben tigt Dies muss vorausgesetzt werden weil der Prozessor in der zeitsequenziellen Aus f hrungsdimension arbeitet Er ben tigt einfach viele Befehle um ein Programm zu bearbeiten und jeder Befehl ben tigt etwas Zeit ca 1 Takt Bild 5 5 a zeigt nun ein Beispiel f r eine relativ einfache Ansteuerung eines AD Wandlungsvorgangs Diese Routine ist als Interrupt Serviceroutine ausgelegt An gesto en beispielsweise durch einen zykli
23. dann die Betriebssystem software einen anderen Prozess schedulen Bei verdr ngenden Strategien preemptive wird der Prozess an beliebiger Stelle unterbrochen indem beispielsweise ein Timerinterrupt im Prozessor aufl uft Als Folge dieses Interrupts wird das Betriebssystem aktiviert und der Umschaltvor gang l uft an Hier sind zus tzlich nat rlich auch Ereignissteuerung und kooperie rendes Verhalten m glich 6 3 2 Ans tze zum Scheduling Im Allgemeinen sollte man von einem preemptiven System also ohne eingebaute Kooperation ausgehen Grunds tzlich muss man weiterhin beachten dass nicht nur die Ressource Zeit sondern ggf auch andere reale Ressourcen wie V O Ports oder Ger te auf ihre Verf gbarkeit hin berpr ft werden m ssen Dies versch rft das Schedulingproblem noch weiter sodass sich verschiedene L sungsstrategien entwickelt haben 4 verschiedene Schedulingklassen haben sich entwickelt Statische Tabellen gest tzte Ans tze In diesem Fall geht man davon aus dass das System komplett zur Compilezeit bekannt ist Es werden zur Laufzeit also keine neuen Tasks zugelassen und damit kann w hrend der bersetzung berechnet werden wann welche Task ablaufen bzw starten soll Dieser statische Ansatz ist zwar unflexibel garantiert aber die Multitaskingf hig keit a priori Insbesondere bei periodischen Abl ufen kann dies erfolgreich einge setzt werden Bekannte Verfahren zum Scheduling die hier eingesetzt werden si
24. daraus resultierenden booleschen Bedingungen Diese Ereignisse sind synchron zum Erzeugerobjekt jedoch asynchron zum Empf ngerobjekt Um diese Ereignisse modellieren zu k nnen werden an den berg ngen zwischen Aktivit tszust nden Bedingungen formuliert Innerhalb einer Workflow Modellie rung eine beliebte Art der Modellierung werden zwischen solchen Aktivit ten berg nge beschrieben Diese berg nge k nnen dabei unbedingt sein verzwei gend zusammenf hrend oder eben mit Bedingungen verkn pft Bild 3 11 gibt ein kurzes Beispiel daf r Es sollte hierbei deutlich sein dass dieses Aktivit tsdiagramm das im brigen nur Aktivit tszust nde und berg nge enth lt das in 5 4 1 gegebene Beispiel modelliert Schlussfolgerungen kann man daraus jedoch nur ziehen wenn f r die Signale IRQ_1 bis IRQ_3 ein bestimmtes Verhalten angenommen wird und nat rlich die angenommenen Bearbeitungszeiten auch wirklich stimmen 46 Embedded Systems Engineering Skript V1 00 Main_Program When IRQ_1 When IRQ_3 After 10 us When IRQ_1 After 10 us After 20 us When IRQ_1 When IRQ_2 Bild 3 11 Aktivit tsdiagramm f r asynchrone Unterbrechungen Beispiel aus 5 4 1 3 4 3 SystemC SystemC wird derzeit als eine Sprache behandelt und entwickelt die insbesondere zur Beschreibung von Hardware geeignet ist Tats chlich stellt SystemC lediglich eine Klassenbibliothek f r C und eine Entwicklung
25. handelt es sich um eine theoretische Maschine aus dem Gebiet der Theoretischen Informatik 1 1 2 Klassifizierung eingebetteter Systeme Eingebettete Systeme die mit einer Umgebung in Wechselwirkung stehen sind na hezu immer als reaktives System ausgebildet Interaktive Systeme sind zwar prinzi piell m glich doch die Einbettung macht in der Regel eine Reaktivit t notwendig Die wichtigsten Eigenschaften im Sinn der Einbettung sind Nebenl ufigkeit zu mindest oftmals hohe Zuverl ssigkeit und Einhaltung von Zeitschranken Noch eine Anmerkung zum Determinismus W hrend man davon ausgehen kann dass alle technisch eingesetzten eingebetteten Systeme deterministisch sind muss dies f r die Spezifikation nicht gelten Hier sind nicht deterministische Beschrei bungen erlaubt z B um Teile noch offen zu lassen Wird die Einhaltung von Zeitschranken zu einer Hauptsache d h wird die Verlet zung bestimmter Zeitschranken sehr kritisch im Sinn einer Gef hrdung f r Mensch und Maschine dann spricht man von Echtzeitsystemen Echtzeitf hige eingebettete Systeme sind eine echte Untermenge der reaktiven Systeme die ihrerseits eine ech te Untermenge der eingebetteten Systeme darstellen Bild 1 1 Eingebettete Systeme Reaktive Systeme Echtzeitsysteme Bild 1 1 Klassifikation eingebetteter Systeme 4 Embedded Systems Engineering Skript V1 00 Eingebettete Systeme lassen sich weiterhin nach einer Reihe von unterschiedlichen Krit
26. in das gleiche Signal Dann ist der Wert dieses Signals abh ngig von der Reihen folge in der die Programme ausgef hrt wurden tats chlich werden diese ja se quenziell hintereinander ausgef hrt und damit ist das Ergebnis nicht voraussag bar In Esterel ist es so gel st dass Algorithmen vor einer bersetzung in reale Pro gramme testen ob es zu Nichtdeterminismus kommen kann 3 5 3 Eigenschaften von Esterel Das Grundprinzip der Esterel Programme besteht darin Zustandsmaschinen Auto maten zu beschreiben die bedingt durch externe Events einen Zustandswechsel durchf hren und dabei neue Ereignisse aussenden Diese Events sind nicht ge speichert vorliegend sondern sind nach Bearbeitung wieder verschwunden im Gegensatz zur Hardware Implementierung bei endlichen Automaten Parallelit t Angenommen es sind Pl und P2 zwei Esterel Programme dann ist auch P1 I P2 ein Esterel Programm mit folgenden Eigenschaften e Alle Eingaben die von der Systemseite empfangen werden sind gleicherma en f r Pl und P2 verf gbar 50 Embedded Systems Engineering Skript V1 00 e Alle Ausgaben die von Pl bzw P2 generiert werden sind im gleichen Au genblick f r P2 bzw P1 sichtbar Prinzip der perfekten Synchronie e P1 und P2 werden nebenl ufig ausgef hrt und ihre Parallelkomposition P1 I P2 terminiert wenn beide Pl und P2 terminieren e P1 und P2 teilen sich keine gemeinsamen Variablen Zwischen zwei verschied
27. llen 59 Failover und Recoverytest 64 Installationstest ne 64 Integrationstest ncnenee 62 Modellierung der Software Umgebung 59 Modultest nneesesneneneenn 61 Performancetest ne 64 Phasen im Testprozess 58 Ressource Test 64 Schnittstelle zum Betriebssystem IE Re RELEUR ER RO E 59 Schnittstelle zur Hardware 59 Secure Testarea 65 SysteEMte Sta neninn is 64 Test Coverage 61 Testfortschritt eenee 60 White Box Test 62 zyklomatische Komplexit t 61 63 Testf lle su 0 amp 2 22 Re 59 Testfortschritt eeeeeeen 60 Testpr zess 202 008 58 Thread 19 89 Multithreading 90 Threshold Voltage Siehe Schwellenspannung time triggered Siehe zeitgesteuert timeliness Siehe Rechtzeitigkeit Timer Ausnahmebehandlung 34 Timer Interrupt eee 27 ggT Methode ne 28 komplexes Schema 29 mehrere ss en 28 Time Triggered Protocol 84 Time triggered System Siehe Zeit gesteuertes System TTP Siehe Time Triggered Protocol U bersetzungszeit ene 27 bertragbarkeit e 52 UML Siehe Unified Modelling Language Unfall 8a 57 Unified Modelling Language 41 43 dynamisch modellierendes Diagramm nnne 43 Freisfis u ase
28. m glich indem diese im Hauptprogramm untergebracht werden und so automatisch die brigbleibende Zeit zugeteilt bekommen Die Bestimmung und der Nachweis der Echtzeitf higkeit sind au erordentlich schwierig Bei harten Echtzeitbedingungen droht eine erhebliche berdimensionierung des Systems Die Annahme der maximalen IRQ Frequenz ist meist eine reine Annahme die weder berpr fbar und automatisch einhaltbar ist So k nnen z B prellende Schalterfunktionen IRQs mehrfach aufrufen ohne dass dies in diesem System vermieden werden kann 3 2 5 Modified Event driven Systems Einer der wesentlichen Nachteile der Ereignis gesteuerten Systeme liegt in der An nahme dass die asynchronen Ereignisse mit einer maximalen Wiederholungsfre quenz auftreten Diese Annahme ist notwendig um die Machbarkeit bzw die reale Echtzeitf higkeit nachweisen zu k nnen Andererseits zeigen gerade die Ereignissteuerungen eine bessere Ausnutzung der Rechenleistung weil sie den Overhead der Zeitsteuerung nicht ber cksichtigen m ssen Es stellt sich die Frage ob ein Ereignis gesteuertes System nicht so mo difiziert werden kann dass die Vorteile bleiben w hrend die Nachteile aufgehoben oder gemildert werden IRQ Controller Storing IRQ Priority ext_ RQ gt Interrupt i M IRQ to CPU gt Request e PQI anagement q Service In Service EN 1 Timer per IRQ Timer_Start Channel Bild 3 5 Modifizierter IRQ Cont
29. nat rlich eine gute Methode dar unter der allerdings die Echtzeitf higkeit leiden d rfte Meist sind jedoch Echtzeitsysteme nicht unbe dingt batteriebetrieben energiesparend sollten sie jedoch trotzdem sein Die andere Methode w re diejenige auf die Power State Machine zu verzichten und die Betriebsfrequenz an das untere Limit zu fahren Den Netteffekt erf hrt man f r einen Vergleich nur durch intensive Simulationen und auch hier d rfte die Echtzeitf higkeit ggf leiden 3 3 4 Neue Ans tze zur Mikroprozessor Architektur Clock Domains und GALS Architektur Eine optimale L sung in Richtung minimaler Energieumsatz bei der Programmaus f hrung w re es wenn Betriebsspannung und frequenz den aktuellen Anforderun gen angepasst werden k nnen In 19 wird ein derartiger Ansatz diskutiert und zwar in einer vergleichsweise feink rnigen Form Die Idee zielt eigentlich auf das Design superskalarer Prozessoren 20 Diese Pro zessoren die in der Regel sehr gro und damit auch auf der Siliziumfl che ausge dehnt sind haben besondere Probleme mit einer gleichm igen Taktverteilung ohne Skew die entweder sehr viel Verlustleistung oder eine Verlangsamung mit sich bringt Der in 19 vorgestellte Ansatz zeigt nun dass synchrone Inseln asyn chron untereinander verbunden die bzw eine L sung hierf r darstellen Diese Architektur wird GALS Globally Asynchronous Locally Synchronous ge nannt Die lokalen Inseln werden jeweils m
30. ndigen Verkleinerung der Strukturen sum mieren sich die Str me zu mittlerweile signifikanten statischen Verlustleistungen Pie kags gt V i Tun 3 4 Ps witching_1osses Switching Losses Schaltverluste ist derjenige Anteil der aktuell als dominant betrachtet wird Dieser Anteil entstammt dem Umladestrom der durch das Laden und Entladen der Transistorkapazit ten entsteht Die daraus resultie rende mittlere Verlustleistung ist bei gegebener Umladefrequenz f C y Fovichii _ losses Denn V i f 3 5 2 Vernachl ssigt man insbesondere den statischen Verlustleistungsanteil ein Vor gang den man bei einigen h chstintegrierten Schaltungen bereits nicht mehr ma chen kann dann gilt der bekannte Zusammenhang dass bei konstanter Spannung die Verlustleistung P linear mit der Frequenz f steigt Also ein linearer Zusammenhang zwischen Verlustleistung und Rechengeschwin digkeit Nein denn Gl 3 5 gilt bei konstanter Spannung und genau diese Be triebsspannung l sst sich bei sinkender Betriebsfrequenz in modernen CMOS 26 Embedded Systems Engineering Skript V1 00 Schaltungen ebenfalls absenken Um diesen Effekt zu quantifizieren sei folgende Ableitung gegeben Die Kapazit t C im Transistor bleibt konstant und muss beim Umschalten geladen werden Die daf r notwendige Ladungsmenge ist I O C V Ita 3 6 Der Ladestrom I ist von der Betriebsspannung und der Schwellenspannung Vn Threshold Voltage abh ngig Diese Abh ngigkei
31. nen durch verschiedene Entwicklungsteams erstellt die dann real oder im Zeit scheibenverfahren nebeneinander laufen Und definierte Synchronisationspunk te haben An diesen Synchronisationspunkten werden die Ergebnisse verglichen und durch einen Voter bestimmt welches Ergebnis das wahrscheinlich richtige ist Mehrheitsentscheidung Diese Verfahren ist sehr aufwendig e Dynamische Redundanz Recovery Blocks Es wird eine permanente Fehler berwachung durchgef hrt um beim Erkennen eines Fehlers den entsprechen den Softwareblock gegen eine alternative Softwarekomponente auszutauschen 4 2 2 Analytische Ma nahmen Um bei komplexen Systemen die Zuverl ssigkeit zu beurteilen muss man dieses in seine Einzelfunktionalit ten zerlegen Die Zuverl ssigkeit einer einzelnen Kompo nente sei dann bekannt und mit R t mit 0 lt R t lt 1 bezeichnet Die Kopplung der Systemkomponenten kann dann stochastisch abh ngig oder un abh ngig sein Im einfacheren unabh ngigen Fall m ssen dann bei serieller Kopp lung der Komponenten hei t das System f llt aus wenn mindestens eine der Komponenten ausf llt die Einzelwahrscheinlichkeiten multipliziert werden R serien R t Bei paralleler Kopplung in diesem Fall soll das System noch intakt sein wenn mindestens eine Komponente intakt ist ergibt sich die Zuverl ssigkeit R zaratte Zi 1 m Il R Bei stochastischer Abh ngigkeit wird die Analyse entschieden komplexer den
32. ren Dies kann beliebig ausgestaltet werden und sehr komplexe Interrupt Schemata k nnen erzeugt werden Allerdings bleibt festzustellen dass bliche Mikrocontrol ler die hierzu notwendige Hardware nicht enthalten Diese Form der L sung bleibt also z B den rekonfigurierbaren Prozessoren Mikroprozessor programmierbare 3 Design von eingebetteten Systemen 31 Logik bzw der Zusammenstellung solcher Komponenten auf Boardlevel vorbe halten l l Timer ISR A l l Timer ISR B Timer IRQ A gt 1 a Timer IRQ B Timer IRQ A OR B Timer ISR A OR B Task A und B Nur Task A Nur Task B Bild 3 4 Zusammenfassung zweier Unterbrechungsquellen mittels Hardware a Verkn pfung der IRQ Signale b resultierendes Timingschema 3 2 4 Ereignis gesteuerte Systeme Event triggered Systems Timersignale stellen zwar auch eine Unterbrechung des blichen Programmlaufes dar allerdings ist dies grunds tzlich planbar w hrend Unterbrechungen aus dem Prozessumfeld nicht planbar sind In einem Ereignis gesteuerten System reagiert das Gesamtprogramm auf die Ereig nisse des Prozesses Insbesondere werden die Prozesszust nde nicht zyklisch abge fragt sondern es werden Zustands nderungen an den Prozessor per IRQ gemeldet Diese Form der Systemauslegung die selten in reiner Form auftritt bedingt nat rlich einen vollkommen anderen Systemansatz 1 Der Prozess muss mit exklusiver
33. verstanden 6 3 1 Grundbegriffe Ein sequenzieller Prozess Process besteht hingegen aus einem eigenen Adress raum und einer dynamische Folge von Aktionen die durch Ausf hrung eines Pro gramms auf einem Prozessor zustande kommt Der Prozess ist damit durch seinen zeitlich ver nderlichen Zustand gekennzeichnet Er wird durch das Betriebssystem als Folge eines Auftrags erzeugt au erdem k nnen Betriebssysteme die Erzeugung mehrerer Prozesse unterst tzen Da ein Prozess immer einen gro en Kontext Dateisystem etc mit sich f hrt entstand der Wunsch nach Leichtgewichtsprozessen mit Thread Programmfaden bezeichnet Hiermit wird ein sequenzieller Ausf hrungsfaden mit minimalem Kon text Stack Registersatz innerhalb einer Ausf hrungsumgebung Prozess be zeichnet Jeder Prozess hat damit mindestens einen Thread mehrere Threads eines Prozesses teilen sich den gesamten Adressraum sowie weitere Betriebsmittel des Prozesses 6 Betriebssysteme als virtuelle Maschinen 91 Mit einem Multithreading zielt man also darauf ab einen Prozess selbst wenn m glich zu parallelisieren Je nach Gesamtauslegung des Systems kann es nun von Vorteil sein Teilaufgaben in Threads besserer Datenaustausch schnellere Um schaltung zwischen Programmteilen oder in Prozessen sch rfere Trennung zwi schen den Systemteilen zu implementieren Je nachdem welche Formen durch das Betriebssystem unterst tzt werden und wie die Inter Prozess Kommunikatio
34. 29 eB ene 52 54 0 Ressource Test 64 Operating System nun Siehe ne _ Betriebssystem ir EHEN 57 Risiko anienel lan see 54 en Grenzrisiko een 94 ni S BEI A nee a Schaltverluste enen 24 Performance Level 65 Pettorminc test 64 Scheduling 19 27 89 N ER A O Earliest Deadline First 91 104 Sachwortverzeichnis Least Laxity First 92 Switching Losses Siehe preemptiv is inas seietan seise 91 Schaltverluste Shortest Job First 91 Synchronit t uneeeeeeneseen 45 Schwellenspannung 25 Syste Manin enitn een eu 4 SECUFE Test een 65 Auslegung f r Echtzeit 31 Security Integrity Level 65 dynamisch seen 4 Self Contained System 2 Ereignis gesteuertt nene 30 SENSO eu m ee 9 ged chtnislos eee 4 rezepliv ann eass aata 9 hybrid 22er 4 signalbearbeitend 9 PEAKUV tee iesita 4 Smart eier 9 verteilt asien 4 Service Time Siehe Ausf hrungszeit Zeit analog een 9 SEIVICEZEI een 80 Zeit diskret eeneee 11 Short Current Siehe Zeit gesteuertes nnnenee 29 Kurzschlussstrom Zeit unabh ngi 11 Sicherheit an 2 2 288 2 Systemausfall 54 Signal SystemC uisi oesi 41 45 absent naeh 50 Systemdesign Prasent na RN 50 kooperati
35. 3 26 fault tree analysis 57 Design Pattern 70 Fehlt aita 32 diskret nu ee Betr 4 Fehlertoleranz one 55 Echtzeitsystem ene 3 Redundanz isien 55 Klassifizierung 4 Fehlhandlung 0 53 kontinuierlich 4 Fehlverhalten 0 52 Kontrolleinheit 5 7 Fl chen Zeit Effizienz 23 logischer Aufbau 5 FMEA Siehe failure mode and effect monolithisch 0 0 4 analysis Teak V ne ne 7 Frist 2 2 02 ran 16 Referenzarchitektur 6 FLO iiien Siehe fault tree analysis Sicherheit u ssiessnstsss 4 Funktionalit t 52 verteilt anna h 4 102 Sachwortverzeichnis G Priorit ten osineen iins 30 GALS Architektur 40 Set Interrupt Enable 74 ae en 57 ADT E E 27 74 Te ON 57 TAA STA EE T 27 Interrupt Request 15 failure mode and effect analysis 57 fanleitresamaly is 57 Interrupt Service Routine 73 Be a T Interrupt Service Routine 27 Globally Asynchronous Locally aor Senchronous Siehe GALS Inter Task Kommunikation 72 er ine ISR Siehe Interrupt Service Routine Grenzrisiko neeeesnesennennenennn 54 J H teanais ana 74 78 79 81 Hardware Software Co Design 77 K hazard sauna 57 hybrides System 4 Kommunikation asynchron cese 20
36. BE Zeit diskretes System 11 White Box Test ne 62 Zeitdiskretisierun 7 Worst case Execution Time 72 77 an i BEE 1 5 Worst Case Execution Time 75 zeitgesteuert nee Worst Case Analyse 34 Zeit gesteuertes System 26 29 a Zeit unabh ngige Systeme 11 Z Zuverl ssigkeit 52 54 analytische Ma nahmen 56 Zeit Fehlertoleranz 55 AUSPT gUNB nonas 9 Gefahrenanalyse 57 Betriebssystem ncenen 86 konstruktive Ma nahmen 55 Reaktionszeit 26 zyklomatische Komplexit t 61 63 Rechenzeit ccccseeseeeneeee 26 Zykluszeit uaina 27 29 Scheduling e 27
37. Diese Variante hat folgende Vor und Nachteile Garantierte Einhaltung kritischer Zeiten Bei verteilten Systemen Erkennung von ausgefallenen Teilen durch Planung von Kommunikation und Vergleich in den anderen Systemteilen Das System muss hoch dimensioniert werden weil f r alle Teile die Worst case Laufzeiten angenommen werden m ssen Die Einbindung zeitunkritischer Teile erfolgt entweder unn tig im Scheduling oder das System wird durch die Zweiteilung komplexer Die Kombination mehrerer Zeit gesteuerter Tasks kann sich als sehr aufwendig erweisen falls die einzelnen Zeitabschnitte in ung nstigem Verh ltnis zueinan der liegen siehe n chsten Abschnitt 3 2 2 Kombination mehrerer Timer Interrupts Grunds tzlich ist es nat rlich m glich mehrere Zeitsteuerungen durch mehrere Timer Interrupts durchzuf hren Beispiele hierf r sind die Kombination mehrerer Schnittstellen etwa RS232 und PC Bus die mit unterschiedlichen Frequenzen arbeiten sowie die Kombination aus Messwertaufnahme und serieller Schnittstelle In diesem Fall wird f r jeden Timer die entsprechende Zeitkonstante gew hlt also etwa die Zeit die zwischen zwei Messungen oder zwei Transmissionen liegt Das Problem das sich hierbei stellt ist die zuf llige zeitliche Koinzidenz mehrerer Interrupts die behandelt werden muss Das gleichzeitige oder doch sehr kurz auf einander folgende Eintreffen der Requests bedeutet dass die Behandlung eines Vo
38. Embedded Systems Engineering V1 01 Prof Dr Christian Siemers TU Clausthal Institut f r Informatik Clausthal Zellerfeld H Inhaltsverzeichnis Inhaltsverzeichnis 1 Einf hrung in eingebettete Systeme nuuuusnnnnnnnnnnn 1 1 1 Klassifizierung iasssssssseneesssensensncnscnuennsssuessinsnennennsanssehssnnssnsenenssntsenssinsnennnen 1 1 1 1 Allgemeine Klassifizierung von Computersystemen ensensesenseennen 2 1 1 2 Klassifizierung eingebetteter Systeme uuneesssnesnennesnennnennonnnennen nenn 3 1 1 3 Definitionen as ie else iesfern 4 1 2 Aufbau und Komponenten eingebetteter Systeme srsussnssessnsonennsnnsonene 5 1 3 Die Rolle der Zeit und weitere Randbedingungen rserssorsonesossnnennenne 10 1 3 1 Verschiedene Auspr gungen der Zeit ucersesnesneenesnesnnennennennnennn 10 1 3 2 Weitere Randbedingungen f r eingebettete Systeme nnceeeneee 12 1 4 Design Space Exploration eusorsossssssonessssnsesnssnnennsonssnnsnnnsonssnnssnensnsnnnnnnene 13 2 Echizeitsysteme s iesiuu s50uuuuuansnunannnsnanananann nun enanunnansnnnn 15 2 1 Echtzeit essssssossnsnsossnsonsnsonsnsonsnsensnsansnsonsnsonsnsonsnsnnsssansnsnnsnsansnsonsnsansnsansnsansen 15 2 1 1 Definitionen um die Echtzeit 202000nensensenneennenesnnennennennnennn 15 2 1 2 Ereignissteuerung oder Zeitsteuerung ucsersersnernernnesnernnennennennnen nn 16 2 1 3 Bemerkungen zu weichen und harten E
39. Hardware ausgestattet sein die ein Interface zum Prozessor bildet Diese Hardware muss Zustands nderungen erkennen und per IRQ zum Prozessor signalisieren 2 Im Prozessor und h chstwahrscheinlich dem Interrupt Request Controller muss ein Priorisierungssystem festgelegt werden das die IRQs priorisiert und 32 Embedded Systems Engineering Skript V1 00 entsprechend behandelt Zu dieser Priorisierungsstrategie geh ren auch Fragen wie Unterbrechungen von Unterbrechungs Serviceroutinen 3 Es ist wahrscheinlich dass neben den IRQ Serviceroutinen ISR auch weitere normale Programme existieren Dies erfordert eine Kopplung zwischen ISR und Hauptprogramm Hieran ist zu erkennen dass die Planung dieses Systems alles andere als einfach ist Insbesondere stecken Annahmen in dem IRQ Verhalten des Prozesses die Aussagen zur Machbarkeit erst erm glichen so z B eine maximale Unter brechungsrate Unter bestimmten Umst nden kann die Erf llung der Realtime Bedingungen garantiert werden Nimmt man einmal an dass e keine ISR unterbrochen wird e jede ISR den IRQ vollst ndig behandelt e f r jede ISR eine eigene Priorit t 0 k 1 gegeben wird 0 bedeutet dabei die h chste Priorit t e f r jeden IRQ eine maximale Frequenz des Auftretens und eine maximale Reaktionszeit gegeben ist und e das Hauptprogramm jederzeit unterbrechbar ist dann gilt F r IRQG sei F i die minimale IRQ Folgezeit und T i die maximal zul ss
40. Modelle identifizieren deren Eigenschaft darin besteht dass die Beschreibung nicht nur das Modell wiedergibt sondern durch einen geeigneten bersetzungs prozess in ein funktionierendes System automatisch berf hrt werden kann Dies f hrt dann zu den sogenannten Programmiersprachen und derartige funktionale Modelle sind im Rahmen von Rapid Prototyping und Softwareentwicklung f r Prozessor basierte und struktural programmierbare Systeme denkbar Bei den allgemeinen formalen Modellen sind nat rlich auch Randbedingungen einbeziehbar die nicht in Funktionalit t zu bersetzen sind leider Es k nnen beispielsweise Reaktionszeiten und ben tigte Leistung modelliert werden etwa f r Teileinheiten und daraus k nnen Schlussfolgerungen gezogen werden F r derar tige Modelle gilt dann Man trifft Annahmen und zieht aus den Ergebnissen die aus der Modellsimulation entstehen dann Schlussfolgerungen Allgemein kann man sagen dass Modelle zu folgenden Zwecken entworfen und implementiert werden e Visualisierung e Spezifizierung Lasten Pflichtenheft z B als Executable Specification ESpec e Konstruktion z B Programmierung e Dokumentation 44 Embedded Systems Engineering Skript V1 00 3 4 2 UML Unified Modelling Language UML ist eine Modellierungssprache und bedient sich Diagrammen um ein System darzustellen Ein Diagramm kann dabei als spezifische Projektion eines Systems bezeichnet werden denn es stellt eine jeweilige Si
41. Operationsfrequenz im Modellsystem Zahlen in Klammern Erweitertes Timer IRQ System f r Priorit t 0 mit zwei Serviceroutinen pro Zyklus Als Fazit dieses Vergleichs bleibt an dieser Stelle festzuhalten dass die modi fizierten Ereignis gesteuerten Systeme insbesondere Forderungen nach kurzen Reaktionszeiten wesentlich besser erf llen k nnen Die Dimensionierung des Zeit gesteuerten Systems ist in dem Modell gerade deshalb so hoch weil die Reak tionszeit der h chsten Priorit t zwar weit von der f r die Befehlsbearbeitung ent fernt ist jedoch die Zykluszeit dieser Gr e angepasst werden muss Eine Sch tzung des Effekts durch Einf hrung von Modified Event triggered with Exception Handling kann f r das Modell ebenfalls gegeben werden Verringert man die Arbeitsfrequenz beispielsweise auf 8 MHz so kann f r aller Priorit ten die Echtzeitbedingung eingehalten werden lediglich f r Priorit t 3 ist dies nicht immer m glich Hier wird nun im Ausnahmefall drohende Zeit berschreitung eine Not routine angesprungen die eine vorl ufige Reaktion darstellt Das Down Scaling in diesem Fall f hrt zu Einsparungen von ca 20 Dies ist im Einzelfall zu berpr fen und stellt lediglich eine erste Sch tzung dar 5 4 2 bertragung der Ergebnisse auf verteilte Systeme Das Wesen der verteilten Systeme die Einbindung und der Zugriff auf ein nicht exklusives Kommunikationsmedium erfordert eine gesonderte Behandlung 5 Desi
42. Software bestehen und die in komplexe technische Umgebungen einge bettet sind 3 Diese Umgebungen sind meist maschinelle Systeme in denen das eingebettete System mit Interaktion durch einen Benutzer arbeitet oder auch voll automatisch autonom agiert Die eingebetteten Systeme bernehmen komplexe Steuerungs Regelungs und Datenverarbeitungsaufgaben f r bzw in diesen tech nischen Systemen Diese Vorlesung ist dem Design solcher Systeme gewidmet Die Vorlesung wurde so konzipiert dass weder Software noch Hardware im Vor dergrund stehen sollen Es geht um bin rwertige digitale Systeme die program mierbar sind und deren Entwurf insbesondere in eingebetteten Systemen Hierzu sollte gleich zu Beginn beachtet werden dass mit System sowohl das Rechnersy stem als auch die relevante Umgebung gemeint sein kann Um hier Verwirrungen zu vermeiden sei f r diese Vorlesung mit System das digitale System gemeint also dasjenige das konzipiert und konstruiert werden soll w hrend die Umgebung mit Prozess oder pr ziser mit Umgebungsprozess bezeichnet wird Im Vordergrund steht also das System Die eingebetteten Systeme zeigen dabei eine gro e Spannweite denn es ist ein gro er Unterschied eine Kaffeemaschine oder ein Flugzeug zu steuern Zun chst muss also einmal klassifiziert werden um die Vielfalt zu beherrschen und dann werden bestimmte Teile n her behandelt Damit ist das Feld etwa abgesteckt in dem sich die Vorlesung und dies
43. Zur Kommunikation wird also nicht nur die eigentliche bertragungszeit sondern auch die Verarbeitungszeit gerechnet 48 Embedded Systems Engineering Skript V1 00 Esterel beschreibt nun das Zusammenleben von parallelen Prozessen Zur His torie Esterel ist eigentlich ein H henzug in Frankreich bei Cannes und der Name erinnerte die Entwickler an das franz sische Wort f r Echtzeit temps r el Este rel wurde in den 80er Jahren in Frankreich formal und praktisch entwickelt und ist nunmehr ein Produkt dass industriell genutzt wird 21 z B in der Avionik und Automobilindustrie Im Folgenden werden Eigenschaften und Ans tze dieser Sprache beschrieben es wird jedoch keine Einf hrung in die Programmierung Syntax etc gegeben Diese ist u a in 21 zum Download bereit 3 5 1 L sungsans tze zur Modellierung der Zeitspanne zwischen Ein und Ausgabe Grunds tzlich hat man verschiedene M glichkeiten Annahmen ber das Zeitver halten eines Programms zu machen Wie bei den zeitgesteuerten Systemen gt 3 2 1 bereits gezeigt wurde ist es auch m glich dem System ein Zeitverhalten einzupr gen Esterel hingegen ist eine ereignis orientierte Sprache die f r reaktive Systeme konzipiert und entwickelt wurde Damit muss das System auch so beschreibbar sein dass es Ereignis gesteuert arbeitet Nun ist oder wird es Standard sein das System zun chst zu be schreiben auf Konsistenz zu pr fen und anschlie end erst z
44. ale entf llt Selbst wenn der Kontext wechsel in eine Interrupt Service Routine einen vergleichbaren Aufwand zum Polling darstellt ist der Gewinn an Rechenzeit genau dann vorhanden wenn die Ereignisse nicht regelm ig kommen Wie an einem kleinen Modell gezeigt werden wird ist dieser Gewinn vergleichsweise gering F r den maximal zul ssigen Jitter gilt dass dieser nicht berschritten werden darf Dies bedeutet dass im Zeit gesteuerten System entweder die Zykluszeit hiernach auszurichten ist oder f r die kritischen Teile muss eine Behandlung mehrfach innerhalb eines Zeitzyklus durchlaufen werden L sung 1 f hrt dazu das System f r alle Teile mit einer Zykluszeit zu versehen die nicht berall ben tigt wird L sung 2 erh ht die Pollingrate nur individuell bedeutet aber auch mehr Pro grammaufwand intern Die Kombination der Einsparung von Rechenzeiten bei ereignislosen Abschnitten und der individuellen Anpassung der Latenzzeiten ergibt die wesentlichen Vorteile f r modifizierte Ereignis gesteuerte Systeme Um dies zu quantifizieren sei hier ein Modell angegeben Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 83 Es wird ein RISC basiertes Mikroprozessorsystem gew hlt bei dem verein fachend 1 Befehl Takt als Geschwindigkeit angenommen wird Jeder IRQ wird durch einen IRQ Controller priorisiert und der Sprung in die Interrupt Service Routine ISR wird mit 10 Takten veranschlagt in der Reaktio
45. apitel dient dazu die im vorangegangenen Kapitel bereits skizzierten Probleme der Integration der Zeit noch n her zu spezifizieren und vor allem die L sungen aufzuzeigen Dies f hrt zu den Echtzeitsystemen und im ersten Teil dieses Kapitels werden Definitionen und Entwicklungsmethoden hierzu formuliert Die wirkliche Problematik beginnt genau dann wenn mehrere Algorithmen nebenl ufig zueinander zum Ablauf kommen Dies ist Inhalt des zweiten Teils in dem nebenl ufige Systeme betrachtet werden 2 1 Echtzeit 2 1 1 Definitionen um die Echtzeit Die DIN 44300 des Deutschen Instituts f r Normung beschreibt den Begriff Echtzeit wie folgt 3 Definition 2 1 Unter Echtzeit real time versteht man den Betrieb eines Rechensystems bei dem Programme zur Verarbeitung anfallender Daten st ndig betriebsbereit sind derart dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verf g bar sind Die Daten k nnen je nach Anwendungsfall nach einer zeitlich zuf lligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen Demgegen ber wird im Oxford Dictionary of Computing das Echtzeitsystem wie folgt beschrieben Definition 2 2 Ein Echtzeitsystem real time system ist ein System bei dem der Zeitpunkt zu dem Ausgaben vorliegen bedeutend ist Das liegt f r gew hnlich daran dass die Eingabe mit einigen nderungen der physikalischen Welt korrespondiert und die Ausgabe sich auf diese nderungen beziehen
46. ar er sie w hrend des Designs und des Programmierens damit be fasst eine ordentliche Software herzustellen so dass die destruktive Sicht sicher lich schwer fallen w rde Aus diesem Grund muss der Test von anderen nicht mit der Entwicklung befassten Personen durchgef hrt werden Um den Testprozess genauer zu beschreiben wird er in 4 Phasen eingeteilt 25 e Modellierung der Software Umgebung e Erstellen von Testf llen e Ausf hren und Evaluieren der Tests e Messen des Testfortschritts 60 Embedded Systems Engineering Skript V1 00 4 2 5 1 Modellierung der Software Umgebung Eine der wesentlichen Aufgaben des Testers ist es die Interaktion der Software mit der Umgebung zu pr fen und dabei diese Umgebung zu simulieren Dies kann eine sehr umfangreiche Aufgabe sein e Die klassische Mensch Maschine Schnittstelle Tastatur Bildschirm Maus Hier gilt es z B alle erwarteten und unerwarteten Eingaben und Bildschirm inhalte in dem Test zu organisieren Einer der Ans tze hierzu hei t Replay Tools die Eingaben simulieren und Bildschirminhalte mit gespeicherten Bit maps vergleichen k nnen e Das Testen der Schnittstelle zur Hardware Ideal ist nat rlich ein Test in der Form Hardware in the loop d h die zu testende Hardware ist vorhanden und offen Falls nicht m ssen hier entsprechende Umgebungen ggf sogar entwic kelt werden Zudem gilt es bei dem Test auch nicht erlaubte F lle einzubinden d h es m ssen Fehl
47. bar und kann den jeweiligen Gegebenheiten angepasst werden Noch modularer und austauschbarer ist der Mikrokernansatz Microkernel Bild 6 3d Dieser bietet nur noch einen minimalen Funktionsumfang als Infrastruktur z B Inter Prozess Kommunikation Inter Process Communication IPC Prozess verwaltung Speicherverwaltung Scheduling und hardwarenahe E A Funktionen Die eigentlichen Funktionen des Betriebssystems wie z B das FMS sind dann in Form von Systemprozessen angelegt und dadurch frei austauschbar Was bedeutet die jeweilige Architektur in der Praxis Zun chst wird man die Aus wahl des Betriebssystems nicht nur an quantifizierbaren Aussagen wie Reaktions zeiten messen sondern auch an Qualit tsaussagen Modulare Systeme sind nicht nur wartbarer und skalierbarer sie sind ggf auch fehlertoleranter d h Abst rze in Systemprozessen m ssen nicht zugleich das gesamte System lahm legen Auch der Nachteil soll nicht verschwiegen werden Je modularer ein System ist desto mehr Rechenzeit wird aufzuwenden sein denn Schnittstellen und IPC kosten Rechenzeit 6 3 Scheduling Strategien Der f r Echtzeitbetriebssysteme wichtigste Teil folgt nunmehr mit dem Schedu lingsystem Um zu verstehen worum es sich dabei eigentlich handelt muss man die Begriffe Programm Prozess und ggf auch Thread n her erl utern Mit einem Programm wird die statische Folge von Anweisungen in einer Programmiersprache unter Nutzung von Daten 9 Abschnitt 7 3
48. ber ansonsten getrennte Aktivi t ten modelliert und auch implementiert werden e Die Anzahl der ausf hrenden Einheiten in einem Rechner kann durchaus gt 1 sein Im Zeitalter von Hardware Software Co Design Multiprozessorcores konfigurierbaren Prozessoren Prozessoren mit eigenem Peripherieprozessor usw k nnen Aufgaben auf verschiedene Teile abgebildet werden und dazu m ssen sie auch dergestalt modelliert sein Hier wird die Performance des Systems entscheidend verbessert wenn die parallelen M glichkeiten auch wirk lich ausgenutzt werden 2 2 1 Multiprocessing und Multithreading Mit Multitasking wird allgemein die F higkeit von Software beispielsweise Be triebssystemen bezeichnet mehrere Aufgaben scheinbar gleichzeitig zu erf llen 20 Embedded Systems Engineering Skript V1 00 Dabei werden die verschiedenen Tasks in so kurzen Abst nden immer abwech selnd aktiviert dass f r den Beobachter der Eindruck der Gleichzeitigkeit entsteht Man spricht hier auch oft von Quasi Parallelit t aber mikroskopisch wird nat rlich nichts wirklich parallel zueinander bearbeitet Doch was ist eine Task Dies wird blicherweise als allgemeiner berbegriff f r Prozesse und Threads Leichtgewichtsprozesse genannt Nun sind auch diese beiden schwer zu unterscheiden zumindest pr zise zu unterscheiden aber meist reicht auch schon eine etwas unscharfe Definition Ein Prozess process ist ein komplettes gerade ablaufendes Programm
49. blemen bei der Bestimmung der WCET bis hin zur Unm glichkeit f hren Diese Forderung f hrt zu einem sicheren Design da sich Abh ngigkeiten etwa in der Form dass falls Task 1 den maximalen Pfad durchl uft Task 2 garantiert einen kleineren Pfad als seinen maximalen w hlt nur positiv auf die WCET des Gesamtsystems auswirken k nnen Bild 5 2 zeigt den gesamten Designprozess ohne Entscheidungen bzw R ckwir kungen Tats chlich sind in seinem Verlauf einige Abstimmungen und Entschei dungen notwendig insbesondere in dem grau schattierten Teil der Implementie rung zweier ISRs mit gegenseitiger Beeinflussung Das Zusammenf gen der einzelnen Applikationsteile bestehend aus generellen Tasks Timer ISRs und ggf Event ISRs beinhaltet die Organisation der Kommu nikation zwischen den einzelnen Teilen sowie die Abstimmung des Zeitverhaltens Als Kommunikation zwischen diesen Tasks ist ein nicht blockierendes Semapho ren Mailbox System ideal Semaphore die seitens einer Task beschrieben und seitens der anderen gelesen und damit wieder gel scht werden k nnen zeigen den Kommunikationsbedarf an w hrend die eigentliche Meldung in einer Mailbox hinterlegt wird Blockieren kann durch eine asynchrone Kommunikation wirksam vermieden werden Tasks warten nicht auf den Empfang bzw Antwort sie senden einfach via Semaphor Mailbox Auch die Abfrage von empfangenen Sendungen erfolgt dann nicht blockierend Dies l sst sich durch einfache Method
50. chaltnetze in der digitalen Elektronik H ngt dagegen dieser von vorhergehenden Eingangssignalen ab spricht man von einem dynamischen System Beispiel Schaltwerke Definition 1 4 Ein reaktives System reactive system kann aus Software und oder Hardware bestehen und setzt Eingabeereignisse deren zeitliches Verhalten meist nicht vor hergesagt werden kann in Ausgabeereignisse um Die Umsetzung erfolgt oftmals aber nicht notwendigerweise unter Einhaltung von Zeitvorgaben Definition 1 5 Ein hybrides System hybrid system ist ein System das sowohl kontinuierliche analoge als auch diskrete Datenanteile wertkontinuierlich verarbeiten und oder sowohl ber kontinuierliche Zeitr ume zeitkontinuierlich als auch zu diskreten Zeitpunkten mit ihrer Umgebung interagieren kann 1 Einf hrung in eingebettete Systeme 5 Definition 1 6 Ein verteiltes System distributed system besteht aus Komponenten die r umlich oder logisch verteilt sind und mittels einer Kopplung bzw Vernetzung zum Er reichen der Funktionalit t des Gesamtsystems beitragen Die Kopplung bzw Ver netzung spielt bei echtzeitf higen Systemen eine besondere Herausforderung dar Definition 1 7 Ein Steuerger t electronic control unit ECU ist die physikalische Umsetzung eines eingebetteten Systems Es stellt damit die Kontrolleinheit eines mechatroni schen Systems dar In mechatronischen Systemen bilden Steuerger t und Senso rik Aktorik of
51. che Unterbrechungen mitbetrachtet werden Kritisch wird es f r die Reaktionszeit wenn diese etwa lt 100 Befehlsausf hrungszeiten ist die Grenze ist auch hier wieder individuell Die unkritische Grenze wird wieder bei der Summe ber alle Reaktionszeiten bzw der Zykluszeit erreicht Tabelle 5 1 fasst die charakteristischen Zeiten zusammen Ist f r eine von diesen Zeiten f r ein konkretes System die kritische Grenze erreicht so ist der System designer aufgefordert exklusive Hardware hierf r bereitzustellen Sind hingegen alle Zeiten unkritisch kann man zu einem Sharing Betrieb bergehen Im Zwi schenbereich hingegen muss individuell konzipiert werden was die geeignete Wahl darstellt siehe Bild 5 7 82 Embedded Systems Engineering Skript V1 00 Exklusiv NS In diy uoy Sharing u kritisch unkritisch Zeiten Bild 5 7 Designraum exklusiv sharing f r Systeme mit zeitlichen Randbedingungen 5 4 1 Vergleich Zeit Steuerung und modifizierte Ereignis Steuerung Aus den berlegungen zu den charakteristischen Zeiten kann man weiterhin eine Unterscheidung f r Zeit gesteuerte und modifizierte Ereignis gesteuerte Systeme ableiten Beide sind in der Lage deterministische Echtzeitbedingungen zu erf llen Der erste Vorteil f r die modifizierten Ereignis gesteuerten Systeme besteht darin dass die Abfrage der Inputleitungen die bei der Zeit Steuerung im Pollingverfah ren erfolgen muss durch die Ereignissign
52. cht dar Zudem werden nicht Elektronik oder Software dargestellt sondern Systeme Derartige softwareintensive Systeme zeichnen sich dabei durch eine Architektur aus F r Architekturen im informatorischen Sinn gelten 5 Sichten Die statische Entwurfs oder Prozesssicht die statische Anwendungsfallsicht die statische Ein satzsicht die statische Implementierungssicht und die dynamische Sicht Es mag dabei berraschen dass es so viele statische Sichten gibt aber tats chlich kann man ein System vielfach beleuchten und modellieren F r die Modellierung der statischen Entwurfs oder Prozesssicht dienen das Klas sendiagramm und das Objektdiagramm Hierbei werden entweder die Klassen beziehungen objektorientiertes Programmieren oder die tats chlich instanziierten Objekte dargestellt Andere statische Sichten werden durch das Komponenten diagramm und das Einsatzdiagramm behandelt Objekte m main_prog i isr Interrupt Request i Kontrollfokus l Return from IRQ l Lebenslinie Bild 3 10 Sequenzdiagramm Z An dieser Stelle sind nat rlich die dynamisch modellierenden Diagramme interes sant Interaktionsdiagramm Zustandsdiagramm und Aktivit tsdiagramm Das 3 Design von eingebetteten Systemen 45 nachfolgend dargestellte Sequenzdiagramm ist eine spezielle Art des Interaktions diagramms Es stellt die verschiedenen Objekte hier mit Bezug auf diese Vorlesung je ein Obje
53. chtzeitsystemen 18 2 2 Nebenl ufigkeit esesssssssnssonssonsnnsssssonsnsssnnennsnnnsnnssnnsnnssnnsonssnsssnsnnnsnnensnnene 19 2 2 1 Multiprocessing und Multithreading mersesesseennenseeseennennn 19 2 2 2 Prozesssynchronisation und kommunikation ssseseeseeeeseeeeeereeeesseeese 20 2 2 3 Grundlegende Modelle f r die Nebenl ufigkeit enseeene 21 3 Design von eingebetteten Systemen nnnseeeenn 23 3 1 Der quantitative Zusammenhang zwischen Rechenzeit Siliziumfl che und Verlustleistung e eesosoesessesossosoesossesessesossesossesoeseosesossesossessesoesesoeseseo 23 3 2 Ans tze zur Erf llung der zeitlichen Randbedingungen esseso0s00000 27 3 2 1 Zeit gesteuerte Systeme Time triggered Systems 27 3 2 2 Kombination mehrerer Timer Interrupts usseseennenseeseennennn 29 3 2 3 Flexible L sung durch Programmierbare Logik neeene 30 3 2 4 Ereignis gesteuerte Systeme Event triggered Systems 31 3 2 5 Modified Event driven Systems nuesessersesnersersnennnennennesnnennnnnnennn nn 33 3 2 6 Modified Event triggered Systems with Exception Handling 35 Inhaltsverzeichnis IH 3 3 Ans tze zur Minderung der Verlustleistung sesessesssonsoossonssossonssenne 37 3 3 1 Auswahl einer Architektur mit besonders guten energetischen Daten 37 3 3 2 Codierung von Programmen in besonders e
54. d stehende Frage ist hier ob die Hard wareressourcen ausreichen Beispiel ist hier der Hauptspeicher wobei Stack und Heap spezielle Kandidaten sind denn deren Verhalten ist zumeist un berechenbar Bei beiden gilt Gro z gige Dimensionierung schafft Vertrauen e Installationstests Installationstests verfolgen zwei Ziele Die Installation der Software muss unter normalen wie abnormalen zu wenig Speicher zu wenig Rechte usw Bedingungen korrekt verlaufen und die Software muss danach 66 Embedded Systems Engineering Skript V1 00 auch richtig lauff hig sein Letzteres muss vor allem dann getestet werden wenn es bereits eine Installation gab e Security Testing Dieser Test betrifft die Sicherheit d h inwieweit das System vor Hackern oder anderen Angreifer gesch tzt ist Hierzu muss sich der Ent wickler so verhalten wie ein Hacker und versuchen in das System einzudrin gen 4 3 Die andere Sicht Maschinensicherheit Letztendlich ist entscheidend was die Anwender von Software basierten Systemen haben wollen bzw welche Eigenschaften sie garantiert haben wollen Die Funktio nalit t einschlie lich der Zuverl ssigkeit ist n mlich entscheidend f r die Sicher heit der Maschinen in die diese Systeme eingebaut sind Die entscheidenden neuen Normen zur Maschinensicherheit sind DIN ISO 13849 Maschinensicherheit voraussichtlich 2006 g ltig und DIN EN 61508 Funktio nale Sicherheit sicherheitsbezogener elektrischer elektroni
55. darin keinen expliziten Inte grationstest zu machen und stattdessen die Modultests entsprechend zu arrangieren Dies wird als Bottom Up Unit Test BUUT bezeichnet Wie beim Black Box Modultest auch als Isolationstest bezeichnet werden die low level Module einzeln getestet indem sie von einer Testumgebung stubs drivers umfasst werden Sind diese Module hinreichend getestet werden sie zu gr eren Modulen zusammengefasst und erneut getestet wobei h here Soft waremodule nur auf bereits getestete Module zur ckgreifen d rfen Der Ansatz h rt sich gut an ist auch wirklich die sauberste Methode hat aber auch Nachteile e Die Entwicklung wird erheblich verlangsamt da Entwicklung und Test sozu sagen Hand in Hand gehen m ssen Zudem ist eine erhebliche Menge an Code zus tzlich zu schreiben stubs driver e Folglich wird sich die BUUT Methode auf kleinere Softwareprojekte beschr n ken e Das Softwareprojekt muss von Beginn an sehr sauber definiert sein d h die Modulhierarchie muss streng gew hrleistet sein 64 Embedded Systems Engineering Skript V1 00 4 2 7 2 Testabdeckung der Aufrufe von Unterprogrammen Die zweite Methode zum Integrationstest besteht in einer m glichst hohen Ab deckung aller Unterprogrammaufrufe call pair coverage Messtechnisch wird der Code hierzu wiederum instrumentiert d h mit zus tzlichem Code zur Messung der Abdeckung versehen Es wird nun verlangt eine 100 Call Pair Coverage zu
56. das Problem der maximalen System auslegung hierdurch noch nicht gel st oder wesentlich gemildert Die Einschr n kung schafft nur den Determinismus der zuvor lediglich angenommen werden konnte Die berdimensionierung eines Systems r hrt von der erfahrungsgem gro en Diskrepanz zwischen Worst Case Sch tzung und realistischen Normalwerten Nat rlich l sst sich ein System nicht auf Erfahrungswerten so aufbauen dass es zugleich auch beweisbar deterministisch ist Folgender Weg bietet unter bestimmten Umst nden eine M glichkeit einen guten Kompromiss zwischen beweisbarer Echtzeitf higkeit und Dimensionierung des Systems zu finden Dieser Ansatz wird als Modified Event triggered System with Exception Handling bezeichnet Folgende Voraussetzungen sind notwendig um einen Interrupt Request der zu der deterministischen Ereignisreihe geh rt in eine zweite Kategorie die mit Ereig nisreihe mit variierter Reaktionsm glichkeiten bezeichnet wird zu transferieren e Alle Ereignisse die weiterhin zur ersten Kategorie gez hlt werden m ssen in der Lage sein diese Ereignisbehandlung zu unterbrechen insbesondere h here Priorit t besitzen e F r das ausgew hlte Ereignis muss eine Notreaktionsm glichkeit existieren beispielsweise ein allgemein g ltiger ungef hrer Reaktionswert der in einer gesonderten Reaktionsroutine eingesetzt werden kann oder e Die Berechnungszeit f r das ausgew hlte Ereignis kann erweitert werden
57. dass das Ger t trotz seiner Verteilung in einem Geh use sitzt f llt die Wahl f r den lokalen Bus auf ein sehr preiswertes Inter IC Bussystem Hier stehen mehrere zur Auswahl der von Philips definierte PC Bus wird als Grundlage gew hlt wobei Multimasterbetrieb vorgesehen wird Aufgabe 1 Suchen Sie die Definition des PC Bus und arbeiten Sie sie durch Welche Adres sierung finden Sie dort gibt es Formatbeschr nkungen wie etwa die Anzahl der gesendeten Bytes pro Paket Wie ist der Zugriff bei Multimasterbetrieb geregelt Ergibt sich hierdurch ein Echtzeitverhalten Aufgabe 2 Wie steht es um die Unterst tzung des PC Bus durch die Mikrocontroller der A Tmega Serie von Atmel Kl ren Sie wie dies durch die Hardware m glich ist und wie Sie dies in ein Programm mit Kommunikation durch Semaphoren gt 5 1 2 abbilden k nnen Die in Bild 7 1 gezeigten Optokoppler k nnen die maximal zul ssige Bitwechsel frequenz begrenzen W hrend in der PC Bus Definition 100 bzw 400 kbit s genannt sind wird f r diese Studie angenommen dass die Transmissionsfrequenz auf 8 kbit s reduziert werden muss 7 Fallstudie Verteiltes eingebettetes System 97 Aufgabe 3 Sch tzen Sie in der angedachten Applikation ab wie viele Datenpakete Sie pro Sekunde erzeugen und versenden m ssen wenn Sie a im MessMonitor nur messen b im MessMonitor auch auswerten und maximal pro Welle einen Statuswert erzeugen Wie regeln Sie j
58. de Optimization Techniques for Data Flow Dominated Embedded Software Kluwer Academic Publishers Boston Dordrecht London 2004 Booch G Rumbaugh J Jacobson I Das UML Benutzerhandbuch Addison Wesley M nchen 2 Auflage 1999 http www systemc org Benini L Bogliolo A De Micheli G A Survey of Design Techniques for System Level Dynamic Power Management IEEE Transactions on Very Large Scale Integration VLSI Systems Vol 8 No 3 pp 299 316 2000 Mudge T Power A First Class Architectural Design Constraint IEEE Computer Vol 34 No 4 pp 52 58 2001 Brooks D et al Power Aware Microarchitecture IEEE Micro Vol 20 No 6 pp 26 44 2000 Steinke S Wehmeyer L Marwedel P Software mit eingebautem Power Management Elektronik Vol 50 H 13 S 62 67 2001 Uwe Schneider Dieter Werner Hrsg Taschenbuch der Informatik Fachbuchverlag Leipzig im Carl Hanser Verlag 3 Auflage M nchen Wien 2000 http www fags org fags realtime computing list http www dedicated systems com encyc buyersguide rtos Dir228 html Special Issue on Real Time Systems Proceedings of the IEEE 82 1 January 1994 Special Issue on Real Time Systems Proceedings of the IEEE 91 7 July 2003 Alexander G Dean Efficient Real Time Fine Grained Concurrency on Low Cost Microcontrollers IEEE Micro 24 4 pp 10 22 2004 Timo Gramann Dirk S Mohl Precision Time Protocol IEEE 1588
59. der also mit einem garantierten Verhalten des Pro zessors zu rechnen ist ist nat rlich individuell von dem System abh ngig In jedem Fall ist das System sicher konzipiert wenn der erlaubte Jitter gr er ist als die Summe aller h herpriorisierten Ereignisse unter Einbezug der Auftritts h ufigkeit bei Ereignis gesteuerten Systemen bzw die Zykluszeit bei Zeit gesteuerten Systemen e Die Servicezeit Tservice spielt eine scheinbar unwichtige Rolle da sie ja sowieso eingeplant werden muss Bei Servicezeiten die mehr als 30 der gesamten Rechenzeit im Normalfall oder Worst Case einnehmen muss man jedoch davon ausgehen dass diese Zeit sehr dominant ist und die brigen Teile des Systems stark beeinflusst Diese 30 Grenze ist allerdings unscharf w hrend Servicezeiten lt 1 sicher keinen Einfluss nehmen Kritischer Wert Unkritischer Wert T jitter lt 10 Befehlszeiten gt alle h herpriorisierten Reaktionszeiten Ereignis gesteuert oder gt Zykluszeit Zeit gesteuert T service gt 50 der gesamten Rechenzeit lt 1 der gesamten Rechenzeit TReaction lt 100 Befehlszeiten gt alle h herpriorisierten Reaktionszeiten Ereignis gesteuert oder gt Zykluszeit Zeit gesteuert Tabelle 5 1 Zusammenfassung der charakteristischen Zeiten von Ereignissen e Die maximal geforderte Reaktionszeit Treaction setzt sich aus der Latenzzeit und der Servicezeit zusammen allerdings m ssen noch m gli
60. dern sek Zu einem Ruckeln o f hrt Als Anmerkung sei hier beigef gt dass fast immer nur die oberen Zeitschranken aufgef hrt werden Dies hat seine Ursache darin dass die Einhaltung einer oberen Zeitschranke im Zweifelsfall einen erheblichen Konstruktionsaufwand erfordert w hrend eine untere Schranke d h eine Mindestzeit vor der nicht reagiert werden darf konstruktiv unbedenklich ist Ein Beispiel f r ein System bei dem beide Wer te wichtig sind ist die Steuerung des Z ndzeitpunkts bei der Verbrennungsmaschi ne Dieser darf nur in einem eng begrenzten Z ndintervall kommen 2 1 2 Ereignissteuerung oder Zeitsteuerung Es stellt sich nun unmittelbar die Frage wie die harten Echtzeitsysteme denn kon zipiert sein k nnen Auf diese Frage wird im Kapitel 3 2 noch n her eingegangen denn die Grundsatzentscheidung welches Design zum Tragen kommen soll hat nat rlich erhebliche Konsequenzen f r die gesamte Entwicklung Zwei verschiedene Konzeptionen die in der Praxis nat rlich auch gemischt vorkommen k nnen k nnen unterschieden werden Ereignisgesteuerte event triggered und zeitgesteuerte time triggered Systeme Ereignisgesteuerte Systeme werden durch Unterbrechungen gesteuert Liegt an einem Sensor ein Ereignis was das ist muss nat rlich definiert sein vor dann kann er eine Unterbrechungsanforderung interrupt request an den Prozessor sen den und damit auf seinen Bedienungswunsch aufmerksam machen Definition
61. die Verlustleistung auch die Siliziumfl che die sich in Kosten niederschl gt soll minimiert werden Als vorl ufiges Fazit kann nun gelten dass die Entwicklung f r eingebettete Syste me bedeutet eine Entwicklung mit scharfen und unscharfen Randbedingungen durchzuf hren 1 4 Design Space Exploration Bei all den bisher dargestellten Fakten sollte eines deutlich geworden sein Ein eingebettetes System besteht im Kern aus einem programmierbaren Rechner zu mindest ist das die Regel und die Wahl des Rechners sowie dessen Programmie rung m ssen sich Randbedingungen unterwerfen z B der Erf llung von zeitlichen Bedingungen Die zu erf llenden Randbedingungen sind zwar formal definierbar aber fast nie durch einen Compiler in Funktionalit t umzusetzen Zwar k nnte man sich gerade dies bei Laufzeiten recht gut vorstellen aber die Probleme sind sehr gro Zudem gibt es kaum Programmiersprachen die die Codierung zeitlicher Bedingungen erlauben Auf diese Problematik wird in Kapitel 3 n her eingegangen de Fan 0 01 ASIC 0 001 Full om log flexilibity 1 h 2 100000000 10000000 1000000 100000 10000 1000 100 10 log cost Bild 1 6 Kosten versus Flexibilit t f r verschiedene Implementierungsbasen Hier soll etwas anderes dargestellt werden eine Studie 18 die sehr viel Motiva tion liefert Unter der Annahme man h tte sehr viel Entwicklungszeit K nnten 14 Embedded Systems Engineeri
62. dient dem Zweck den Zusammenhang zwischen den Systemen die programmiert werden k nnen den Entwurfssprachen und den in Kapitel 1 bereits diskutierten Randbedingungen darzustellen Als erstes wird hierzu der quantitative Zusammenhang zwischen Fl che A Zeit T und Verlustleistung P untersucht Dieser Zusammenhang d rfte existieren die Quantifizierung ist interessant Hat man nun mehrere M glichkeiten kann man das Design optimieren Man spricht dann auch von dem Designraum Im Anschluss daran werden grunds tzliche L sungsans tze f r das Zeitproblem und zur Verlustleistungsminderung besprochen Den Abschluss dieses Kapitels bil det ein Blick auf m gliche Modellierungssprachen 3 1 Der quantitative Zusammenhang zwischen Rechenzeit Siliziumfl che und Verlust leistung Rechenzeit und Siliziumfl che Folgende Gedankenkette zeigt einen zumindest qualitativen Zusammenhang zwi schen Zeit und Fl che F r einen 8 Bit Addierer existieren viele Implementie rungsm glichkeiten e Sequenziell 1 Bit Addierer mit Shift Register als Speicher getaktete Version Dieser Addierer berechnet in einem Takt nur ein Summenbit sowie das Carry Bit beide werden gespeichert und weiter verwendet e Seriell Ripple Carry Adder 8 1 Bit Addierer mit seriellem bertrag Dieser Addierer ist die bekannte Form und wird gelegentlich auch als sequenziell be zeichnet e Total parallel Addierschaltung bei der alle bertr ge eingerechnet sind Hier i
63. durchlaufenen Schleifen anhand einer Obergrenze statisch bestimmen zu k nnen Diese Regel dient dazu unbegrenzte Schleifen zu verhindern Hierbei m ssen auch implizit unbegrenzte Schleifen wie das folgende Beispiel verhindert werden die wichtige Regel ist also diejenige dass der Codechecker die Obergrenze erkennen k nnen muss Es gibt allerdings eine Ausnahme von dieser Regel Es gibt immer wieder explizit unendlich oft durchlaufene Schleifen etwa while 1 die f r bestimmte Auf gaben notwendig sind Process Scheduler Rahmen f r endlos laufendes Programm etc Diese sind selbstverst ndlich erlaubt 68 Embedded Systems Engineering Skript V1 00 Eine M glichkeit diese Regel zu erf llen und bei berschreiten dieser oberen Grenze einen Fehler bzw eine Fehlerbehebung einzuf hren sind so genannte assert Funktionen siehe auch Hardwarebeschreibungssprachen wie VHDL Bei berschreiten wird eine solche Funktion aufgerufen diese kann dann entspre chende Aktionen einleiten Es ist zwar m glich die Fehlerbehebung auch in den eigentlichen Sourcecode einzubauen die explizite Herausf hrung dient aber der bersicht int k m array 1024 for k 0 m 0 k lt 10 k t m IE array m 0 k 0 Beispiel 4 1 Implizit unbegrenzte for Schleife als Negativbeispiel Regel 3 Nach einer Initialisierungsphase soll keine dynamische Speicherallokation mehr erfolgen Die Allokationsfunktionen wie malloc
64. e heute verf gbaren Computersysteme k nnen in drei unterschiedliche Klassen eingeteilt werden 3 rein transformationelle interaktive und reaktive Systeme Die Unterscheidung erfolgt in erster Linie durch die Art und Weise wie Eingaben in Ausgaben transformiert werden Transformationelle Systeme transformieren nur solche Eingaben in Ausgaben die zum Beginn der Systemverarbeitung vollst ndig vorliegen 3 Die Ausgaben sind nicht verf gbar bevor die Verarbeitung terminiert Dies bedeutet auch dass der Benutzer bzw die Prozessumgebung nicht in der Lage ist w hrend der Verarbei tung mit dem System zu interagieren und so Einfluss zu nehmen Interaktive Systeme erzeugen Ausgaben nicht nur erst dann wenn sie terminieren sondern sie interagieren und synchronisieren stetig mit ihrer Umgebung 3 Wichtig hierbei ist dass diese Interaktion durch das Rechnersystem bestimmt wird nicht etwa durch die Prozessumgebung Wann immer das System neue Eingaben zur Fortf hrung ben tigt wird die Umgebung also ggf auch der Benutzer hierzu aufgefordert Das System synchronisiert sich auf diese proaktive Weise mit der Umgebung Bei reaktiven Systemen schreibt die Umgebung vor was zu tun ist 3 Das Com putersystem reagiert nur noch auf die externen Stimuli die Prozessumgebung syn chronisiert den Rechner und nicht umgekehrt Worin liegen die Auswirkungen dieses kleinen Unterschieds wer wen synchroni siert Die wesentlichen Aufgaben eines in
65. e kann auch als allgemeine Angabe Minimum Maximum Durch schnittswert mit Streuung gew hlt werden Definition 2 7 Die Ausf hrungszeit Service Time ist die Zeit zur reinen Berechnung einer Reak tion auf ein externes Ereignis In einem deterministischen System kann diese Zeit bei gegebener Rechengeschwindigkeit prinzipiell vorherbestimmt werden Definition 2 8 Die Reaktionszeit Reaction Time ist diejenige Zeit die vom Anlegen eines Satzes von Eingangsgr en an ein System bis zum Erscheinen eines entsprechenden Satzes von Ausgangsgr en ben tigt wird Die Reaktionszeit setzt sich aus der Summe der Latenzzeit und der Ausf hrungs zeit zusammen falls die Service Routine nicht selbst noch unterbrochen wird Definition 2 9 Die Frist Dead Line kennzeichnet den Zeitpunkt zu dem die entsprechende Re aktion am Prozess sp testens zur Wirkung kommen muss Diese Fristen stellen eine der wesentlichen Randbedingungen des Umgebungsprozesses dar Dies bedeutet also dass zu jedem zu den Echtzeitkriterien z hlendes Ereignis eine Frist definiert sein muss innerhalb derer die Reaktion vorliegen muss Folglich ist nicht die Schnelligkeit entscheidend es ist Determinismus im Zeitsinn gefragt 18 Embedded Systems Engineering Skript V1 00 2 1 3 Bemerkungen zu weichen und harten Echtzeit systemen Die Konzeption eines harten Echtzeitsystems und vor allem der Nachweis dieser F higkeit ist au erordentlich schwi
66. ei 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 75 chen muss kurzzeitig der Interrupt gesperrt werden durch die beiden Assembler befehle cli Clear Interrupt Enable und sei Set Interrupt Enable Hierdurch erreicht man im Code die geforderte Atomarit t die f r einen ungest rten Ablauf zwingend erforderlich ist unsigned char semaMess 0 unsigned int globalMesswert main interrupt TIMER void timer_comp_isr void unsigned int messwert Die beiden Operationen sind wieder while 1 atomar globalMesswert ADC_OUT if semaMess 0 semaMess 1 Neuer Wert vorliegend Atomare Operation asm cli semaMess 0 messwert globalMesswert asm sei Ende der atomaren Operation b Bild 5 3 Nicht blockierende Kommunikation zwischen Main a und Interrupt Routine b Die zeitliche Abstimmung der einzelnen Tasks ist wesentlich aufwendiger und muss folgende berlegungen einschlie en Wie beeinflussen ununterbrechbare Teile in der generellen Task bzw einer ISR die Latenzzeiten der Interrupts Die Beantwortung dieser Frage ist insbesondere f r die zyklischen Tasks mit strenger Zeitbindung wichtig da man hier davon ausgehen muss dass Jitter nur in sehr geringem Umfang erlaubt ist Die praktische Ausf hrung sieht so aus dass tats chlich die entsprechenden Befehle im Maschinencode sei cli gesucht und die WCETs der ununterb
67. eme Die Pr fung eines Esterel Programms auf Reaktivit t und Determinismus ist kei neswegs trivial da es z B zu Verklemmungen aufgrund der gegenseitigen Kom munikation kommen kann Beispielsweise k nnen zwei Programme gegenseitig auf ein Signal des jeweils anderen warten um fortzufahren 3 Design von eingebetteten Systemen 51 Die Pr fung der logischen Korrektheit wird also auf die Pr fung der Signale und ihrer Beziehungen abgebildet Signale haben einen von zwei Zust nden wobei absent als Defaultstatus definiert ist Im Koh renz Prinzip wird nun definiert wann ein Signal present ist Definition 3 4 3 Ein Ausgangssignal bzw ein lokales Signal x ist zu einem Zeitpunkt pr sent genau dann wenn zu diesem Zeitpunkt die Anweisung emit x im Sichtbarkeitsbereich von x ausgef hrt wird Nun kann es eben Zyklen geben bei denen emit x genau dann ausgegeben wird wenn x bereits pr sent ist so ist es nat rlich trivial in mehrfacher Form jedoch nicht signal x in present x then emit x end end signal L sst man nun solche Zyklen zu droht ein Deadlock L sst man andererseits ber haupt keine Zyklen zu w re dies eine zu starke Einschr nkung Also wird richti gerweise das Programm aufwendig gepr ft NP vollst ndiges Problem In der so genannten konstruktiven Semantik wird diese Pr fung vereinfacht 4 Softwarequalit t Eingebettete Systeme sind immer Bestandteil einer bergeordneten Ma
68. en Die Multiplikation mit 5 z B wird dann auf einen zweifachen Shift nach links Multiplikation mit 4 und an schlie ender Addition mit dem urspr nglichen Wert ausgef hrt wenn dies ener getisch g nstiger sein sollte siehe Bild 3 8 mov R3 5 asl R3 R5 Se mul R3 R3 R5 5 R5 gt asl R3 R3 4 add R3 R3 R5 5 R5 Bild 3 8 Umsetzung einer Multiplikation mit Konstanten in energetisch g nstigere Form Um dies wirklich auszunutzen muss die Hilfe eines Compilers in Anspruch genommen werden Derartige Ans tze sind in der Forschung vertreten z B dar gestellt in 10 Es d rfen jedoch keine Gr enordnungen an Energieeinsparung dadurch vermutet werden die Effekte bleiben im Rahmen einiger 10 3 3 3 Einrichtung von Warte und Stoppzust nden oder Optimierung der Betriebsfrequenz Eine andere M glichkeit zur Energieeinsparung entsteht durch die Einf hrung von verschiedenen Betriebsmodi insbesondere von Mikrocontrollern Diese Modi im Folgenden mit RUN IDLE und SLEEP bezeichnet bieten neben variiertem Funk tions und Reaktionsumfang auch differierende Energiebilanzen Bild 3 9 zeigt ein Beispiel aus 7 f r den Intel StrongARM SA 1100 Mikroprozessor 40 Embedded Systems Engineering Skript V1 00 P 400 mW Wait for Wait for Interrupt Wake Up Event FEINE P 50 mW Bild 3 9 Power State Machine f r SA 1100 Der bergang von RUN in IDLE sowie RUN in SLEEP erfolgt blicherweise durch
69. en diese Fehler vermieden oder das Risiko minimiert werden Die Fehlerliste f hrt dann zu einer System berarbeitung und die Analyse beginnt von vorne Die FMEA hat folgende Ziele e Kein Fehler darf einen negativen Einfluss auf redundante Systemteile haben e Kein Fehler darf die Abschaltung der Stromversorgung eines defekten System teils verhindern e Kein Fehler darf in kritischen Echtzeitfunktionen auftreten Letztendlich ist dies auch Forschungsthema So gibt es in Deutschland beispiels weise die Initiative Organic Computing die Methoden der Biologie nachzuvoll ziehen versucht 4 2 4 Software Review und statische Codechecker Software Review ist ein Teil des analytischen Prozesses der alleine aufgrund der Trefferquote zwingend notwendig ist 30 70 aller Fehler werden in dieser Phase gefunden Leider kostet ein solches Review wird es ernsthaft betrieben sehr viel Zeit Eine gewisse Hilfe sind die statischen Codechecker die den Code analysieren und wertvolle Hinweise liefern In 24 kann z B ein von lint abstammender statischer Codechecker als Freeware Tool gefunden werden Statische Codechecker k nnen z B folgende Aktionen durchf hren 4 Softwarequalit t 59 e Initialisation Tracking Variablen werden darauf untersucht ob sie vor der ers ten lesenden Verwendung initialisiert wurden Dies erfolgt auch ber if else Konstrukte usw so dass im Gegensatz zu vielen Compilern wirkliche Initialis
70. en implementieren wie am folgenden Beispiel ersichtlich ist Entscheidend ist die Einf hrung einer globalen Variablen zur Steuerung der Kom munikation semaMess Tr gt diese den Wert 0 so liegt kein Messwert vor und die Hauptroutine die in eine Endlosschleife eingepackt ist l uft weiter Ansonsten wird der Messwert lokal kopiert und die Semaphore semaMess wieder zur ck gesetzt um f r den n chsten Schleifendurchlauf einen korrekten Wert zu haben 74 Embedded Systems Engineering Skript V1 00 Informelle formale Aufgabenstellung Klassifizierung der Tasks gem zeitlichen Randbedingungen S Ereignis gesteuerte Tasks Generelle Tasks mit Zeitbindung Streng zyklisch ablaufende Tasks Implementierung als Timer ISR Implementierung als ISR Implementierung als Main Bestimmung Bestimmung WCET Anteil pro WCET maximale E e Zyklus IRQ Frequenz Bestimmung Bestimmung Jitter WCET ISR a er Pr f Zul ssigkeit gesamt Pr fung zeitlicher Bedingungen f r Systemdesign Bild 5 2 Gesamtablauf Systemdesign Die Interrupt Service Routine hier f r einen Timer beschrieben setzt zugleich den Messwert und die Kommunikationsvariable Es wird im Codebeispiel davon ausge gangen dass die ISR nicht unterbrechbar ist so dass also die beiden Operationen immer hintereinander ausgef hrt werden Um dies im Hauptprogramm zu err
71. enen Esterel Programmen existieren keine gemeinsamen Variablen und andere Konstrukte f r den gezielten Austausch von Daten sind auch nicht zu verzeichnen Aus diesem Grund muss die Kommunikation anders gereglt sein hier durch ein Broadcasting Jeder bertragene Wert steht sofort allen Em pf ngern zur Verf gung ein gezieltes Senden an einen oder bestimmte Empf nger ist nicht m glich Deklarationen Esterel ist keine vollst ndige Programmiersprache sondern dient der Beschreibung der Prozesskontrolle Die ben tigten Datentypen Konstanten Signale Funktionen etc werden in einer Hostsprache C oder Ada implementiert und in Esterel importiert Dementsprechend m ssen diese Bestandteile auch deklariert werden Eine Besonderheit nehmen Signale ein Sie dienen der Kommunikation per Broad casting und k nnen als Input Output oder InputOutput bidirektional deklariert werden Ferner besitzt jedes Signal zu jedem Zeitpunkt einen eindeutigen Status entweder present oder absent Dieser Zustand wird nicht gespeichert und muss daher immer neu abgefragt werden Instruktionen Im Instruktionsteil eines Esterel Programms werden Anweisungen durch folgende Konstrukte aufgebaut e Deklarationen von lokalen Signalen und Variablen e elementare Anweisungen wie Zuweisungen Prozeduraufrufe e Verzweigungen Schleifen e Eingaben Ausgaben und Testen von Signalen e zeitliche Anweisungen e Ausnahmebehandlung 3 5 4 Kausalit tsprobl
72. er gingen die Gr nderv ter davon aus dass man eine feste Hardware haben m sste auf der dann eine Software laufen w rde Ein einfaches Prinzip lag den Rechnern zugrunde sie waren in der Hardware so universell dass jedes Programm ausf hrbar war und ist und die Software legte die Funktionalit t fest Offenbar haben wir uns von diesem einfachen Standpunkt schon weit entfernt denn jeder gr ere Rechner und in zunehmendem Ma e auch die eingebetteten Systeme besitzen zwischen Hard und Software noch ein Betriebssystem Allein die Definition eines Betriebssystems zeigt was dort eigentlich hinzugekommen ist Ein Betriebssystem Operating System stellt das Bindeglied zwischen der Hardware eines Computers einerseits und dem Anwender bzw seinen Programmen andererseits dar Es umfasst Programme die zusammen mit den Eigenschaften des Computers die Grundlage der m glichen Betriebsarten dieses Systems bilden und insbesondere die Abwicklung von Programmen steuern und berwachen 9 Abschnitt 7 1 Offenbar hat das Betriebssystem eine Art Oberhoheit insbesondere ber die Zeit Gerade diese Gr e wurde ja in den vorangegangenen Abschnitten als besonders kritisch dargestellt Grund genug sich Aufgaben Architekturen und Angebot am Markt Betriebssysteme betreffend einmal n her anzuschauen 6 1 Betriebssystem als Teil der Systemsoftware Ein Betriebssystem z hlt in jedem Fall zur Systemsoftware zu der alle Programme die eine e
73. er in der Hardware erzeugt werden insbesondere bei Schnittstellen e Die Schnittstelle zum Betriebssystem ist genau dann von Interesse wenn Dienste hiervon in Anspruch genommen werden Hier sind Fehlerf lle z B in Form zu geringen Speicherplatzes auf einem Speichermedium oder Zugriffs fehlern zu testen e Dateisystem Schnittstellen geh ren im Wesentlichen auch zum Betriebssystem seien hier jedoch explizit erw hnt Der Tester muss Dateien mit erlaubtem und unerlaubtem Inhalt sowie Format bereitstellen Letztendlich ist es der Phantasie und der Erfahrung des Testers zu verdanken ob ein Test m glichst umfassend oder eben ein Sch nwettertest ist Beispielsweise m ssen oft ungew hnliche Situationen getestet werden wie z B der Neustart einer Hardware w hrend der Kommunikation mit externen Ger ten 4 2 5 2 Erstellen von Testf llen Das wirkliche Problem der Erstellung von Testf llen ist die Einschr nkung auf eine handhabbare Anzahl von Test Szenarien Hierbei hilft zumindest ein bisschen die so genannte Test Coverage Man stellt sich die Frage welche Teile des Codes noch ungetestet sind Hierf r sind Tools erh ltlich bzw in Debugging Tools eingebaut die den Sourcecode anhand der Ausf hrung kennzeichnet Mit dem Ziel die gew nschte Testabdeckung am Quellcode zu erreichen wird der Tester daher Szenarien ausw hlen die e typisch auch f r die Feldanwendung sind e m glichst b sartig sind und damit e
74. erien klassifizieren Hierzu z hlen e Kontinuierlich versus diskret Diese Auspr gung der Stetigkeit bezieht sich sowohl auf Datenwerte als auch auf die Zeit gt 1 2 Enth lt ein System beide Verhaltensweisen wird es als hybrides System bezeichnet e Monolithisch versus verteilt W hrend anf nglich alle Applikationen f r einge bettete Systeme als monolithische Systeme aufgebaut wurden verlagert sich dies zunehmend in Richtung verteilte Systeme Hier sind besondere Anforde rungen zu erf llen wenn es um Echtzeitf higkeit geht e Sicherheitskritisch versus nicht sicherheitskritisch Sicherheitskritische Syste me sind solche deren Versagen zu einer Gef hrdung von Menschen und oder Einrichtungen f hren kann Viele Konsumprodukte sind sicherheits unkritisch w hrend Medizintechnik Flugzeugbau sowie Automobile zunehmend auf si cherheitskritischen eingebetteten Systemen beruhen 1 1 3 Definitionen In diesem Abschnitt werden einige Definitionen gegeben die u a 3 entnommen sind Diese Definitionen beziehen sich im ersten Teil auf die informationstech nische Seite weniger auf die physikalisch technische Definition 1 3 Unter einem System versteht man ein mathematisches Modell S das einem Ein gangssignal der Gr e x ein Ausgangssignal y der Gr e y S x zuordnet Wenn das Ausgangssignal hierbei nur vom aktuellen Wert des Eingangssignals ab h ngt spricht man von einem ged chtnislosen System Beispiel S
75. erig insbesondere wenn man bedenkt dass die Unterschiede im Laufzeitbedarf f r einzelne Aufgaben sehr hoch sein k nnen f r Fu ball spielende Roboter wird von 1 1000 berichtet Es muss also auf den Maximalfall ausrichtet werden wenn das System wirklich in jedem Fall in fest gelegten Zeiten reagieren soll Man muss allerdings auch sagen dass dieses Echtzeitkriterium aufweichbar ist was auch z B von Anbietern der Echtzeit Betriebssysteme gemacht wird Harte Zeit Hard Real Time Harte Logik System Weiche Zeit Harte Logik Harte Zeit Weiche Logik Soft Real Time Emergency Reaction System System Bild 2 1 Darstellung verschiedener Applikationsklassen Kann die vollst ndige harte Reaktion nicht eingehalten werden so bietet sich die Wege A und B in Bild 2 1 an Weg A gilt dabei f r Systeme bzw Ereignisse bei denen aus einer versp teten Reaktion Sch digungen bis zur Zerst rung resultieren k nnen Hier wird nicht mit dem vollst ndig berechneten Ergebnis gehandelt son dern mit einem ungef hren Wert also eine Art rechtzeitige Notreaktion 2 Echtzeitsysteme 19 Weg B ist der gew hnliche Ausweg Hier werden Systeme vorausgesetzt bei de nen eine zeitliche berschreitung zu einer G teverminderung Soft Degradation nicht jedoch zu einer Sch digung f hrt Wie bereits erw hnt bezeichnet man dies dann als Soft Real Time und dies wird gerne f r Betriebssysteme genutzt 2 2 _Nebenl ufigkeit Nebenl uf
76. ersteres geht nat rlich bereits Im Folgenden soll der aktuelle Stand dargestellt werden und zwar an zwei Beispielen UML und SystemC Hierzu werden einige Voraussetzungen definiert und anschlie end die beiden Sprachen in Hinblick auf ihre Eigenschaften Randbedingungen einzubeziehen diskutiert 3 4 1 Der Begriff Modellierungssprache Um mit dem Begriff Modellierungssprache umgehen zu k nnen muss zwangs l ufig zun chst der Begriff des Modells gekl rt werden Hierunter kann man landl ufig die vereinfachte Abbildung der Realit t verstehen Eine pr zisere Defi nition ist die folgende Definition 2 3 Ein Modell ist die idealisierte Repr sentation eines Systems Die Vollst ndigkeit und die Detailtreue eines Modells im Sinn einer Realit tsn he werden durch die zu kl renden und zu untersuchenden Fragen den Wissensstand und die Modellumge bung bestimmt Mit einem derartigen Modell verfolgt man nat rlich Ziele es ist kein Selbstzweck Wie in der Definition schon dargestellt wurde Die Realit tsn he h ngt tats chlich von den zu kl renden Fragen und dem Wissensstand ab Bei den Modellen unterscheidet man weiterhin eine wichtige Unterart die in folgenden Definitionen spezifiziert ist Definition 2 4 Ein formales Modell formale Spezifikation ist ein Modell eine Spezifikation mit einer eindeutigen Interpretation Die formale Spezifikation bersetzt eine informelle oder teilformale Spezifikation in ein
77. es Skript bewegen Es ist zugleich deutlich dass es sich um ein interdisziplin res Feld handelt da viele Komponenten hier hineinspielen werden In diesem ersten Kapitel werden einige Begriffe definiert um f r Einheitlichkeit zu sorgen Im Anschluss daran soll verdeutlicht werden worin die eigentlichen Schwierig keiten bei der Entwurfsmethodik bestehen werden Der Umgebungsprozess setzt Randbedingungen und diese Randbedingungen constraints m ssen neben der algorithmischen Richtigkeit zus tzlich eingehalten werden Dies wird anhand der Zeitbedingungen deutlich werden Abschnitt 1 3 1 1 Klassifizierung Definition 1 1 Ein eingebettetes System embedded system ist ein bin rwertiges digitales System Computersystem das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht 2 Embedded Systems Engineering Skript V1 00 Das Gegenst ck zu Embedded System wird Self Contained System genannt Als Beispiele k nnen Mikrocontroller basierte Systeme im Auto die Computertastatur usw genannt werden Hinweis Die Definition der eingebetteten Systeme ist eine weiche Defi nition aber sie ist trotzdem sehr wichtig Der Grund bzw der Unterschied zu den Self Contained Rechnern besteht darin dass wie erw hnt die Korrektheit bzw Erf llung auch in den Rand bedingungen und nicht nur im Algorithmus einzuhalten ist 1 1 1 Allgemeine Klassifizierung von Computer systemen Di
78. et werden Das modifizierte Ereignis gesteuerte System wird hierdurch genauso deterministisch wie das Zeit gesteuerte System mit dem Zusatz dass keinerlei Pollingaktivit ten ablaufen m ssen und ungenutzte Ereignisrechenzeiten den zeitunkritischen Pro grammteilen zugute kommen F r das Modified Event Triggered System sind folgende Vor und Nachteile anzu geben Deterministische Berechenbarkeit des Zeitverhaltens wie beim Time triggered System Ungenutzte Zeit die f r Ereignisse vorgesehen war wird an zeitunkritische Teile des Systems weitergegeben es entsteht kein Overhead Verfahren ist mit Einschr nkung auch auf Netzwerke bertragbar indem die einzelnen Knoten maximale Senderaten bekommen und eine unabh ngige Hardware dies berwacht Die Einschr nkungen betreffen den Netzzugang hier sind nur Collision Avoidance Verfahren z B CAN zul ssig Die Systemauslegung orientiert sich weiterhin an Worst Case Sch tzungen Alle IRQs z hlen zu der Reihe der deterministischen Ereignisse die auf diese Weise behandelt werden m ssen Ereignisse mit beliebigen Reaktionszeiten oder weichen Behandlungsgrenzen existieren nicht Die variierte Hardware ist derzeit nicht erh ltlich 3 Design von eingebetteten Systemen 35 3 2 6 Modified Event triggered Systems with Exception Handling W hrend die Einschr nkung der tats chlichen IRQ Raten den Determinismus in Event triggered Systemen erzeugen kann ist
79. ette die ein eingebettetes System ein schlie lich der Umgebung bildet Der zu regelnde oder steuernde Prozess ist ber Sensoren und Aktoren an das Steuerger t gekoppelt und kommuniziert mit diesem dar ber Sensoren und Aktoren fasst man unter dem aus dem Von Neumann Mo dell wohlbekannten Begriff Peripherie peripheral devices oder O System input output zusammen Zu den einzelnen Einheiten seien einige Anmerkungen hier eingef hrt Kontrolleinheit Die Kontrolleinheit bildet den Kern des eingebetteten Systems wobei sie selbst wieder aus verschiedenen Einheiten zusammengesetzt sein kann Sie muss das Interface zum Benutzer falls vorhanden und zur Umgebung bilden d h sie empf ngt Nachrichten bzw Signale von diesen und muss sie in eine Reaktion umsetzen Wie bereits in Abschnitt 1 1 2 dargestellt wurde ist diese Kontrolleinheit fast aus schlie lich als reaktives System ausgef hrt Die Implementierung liegt in moder nen Systemen ebenso fast ausnahmslos in Form programmierbarer Systeme also als Kombination Hardware und Software vor Hierbei allerdings gibt es eine Viel 8 Embedded Systems Engineering Skript V1 00 zahl von M glichkeiten ASIC Application Specific Integrated Circuit PLD FPGA Programmable Logic Devices Field Programmable Gate Arrays General Purpose Mikrocontroller DSP Digital Signal Processor ASIP Application Specific Instruction Set Processor um nur die wichtigsten Implementierungsklas se
80. etzt das Echtzeitverhalten des Busses Die Meldungen des Mess Monitors m ssen in jedem Fall sofort versendet werden die der Display Einheit k nnen auf eine L cke warten Welche maximale Wartezeit ergibt sich dabei f r eine Meldung des MessMonitors 7 3 Architektur der Software Nach reiflicher Analyse wird das System so ausgelegt dass der MessMonitor nicht nur Messungen sondern auch Auswertungen durchf hrt und diese an die Display einheit meldet Tritt hierbei eine Situation auf wo gewarnt oder alarmiert werden muss was dies ist sei hier undefiniert wird die Meldung sofort gesendet an sonsten wird nur eine Statusmeldung pro Kanal pro 2 Sekunden und eine Werte meldung Werte Aktuelle Frequenz Maximalwert pro 10 Sekunden gesendet Aufgabe 4 Stellen Sie einen Programmrahmen auf mit dem die Zeitsteuerung f r die Werte und Nachrichten bertragung ohne St rung anderer Routinen realisiert werden kann Literatur 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Schmitt F J von Wendorff W C Westerholz K Embedded Control Architekturen Carl Hanser Verlag M nchen Wien 1999 Beierlein T Hagenbruch O Hrsg Taschenbuch Mikroprozessortechnik Carl Hanser Verlag M nchen Wien 2 Auflage 2001 Scholz P Softwareentwicklung eingebetteter Systeme Springer Verlag Berlin Heidel berg New York 2005 Falk H Marwedel P Source Co
81. fahren beruhen auf der Idee die zeitkritischen Teile in eine Unterbrechungsroutine einzuf gen und den Rest der Zeit die relativ zeitunkritischen Teilaufgaben zu rechnen Es fehlt jedoch noch die Zusammenfas sung dieser Teile in einem Programm bzw ein Design Pattern f r das komplette Systemdesign Das hier vorgestellte Designverfahren beruht auf drei Schritten e Klassifizierung der Teilaufgaben e Implementierung der Einzelteile e Zusammenfassung zum Gesamtprogramm Ein Hauptaugenmerk muss dabei auf die Kommunikation zwischen den Tasks gelegt werden 5 1 1 Klassifizierung der Teilaufgaben Das hier dargestellte Designverfahren beruht darauf die einzelnen Teilaufgaben diese werden hier immer als Task bezeichnet zu klassifizieren ihren gew nschten Eigenschaften nach zu implementieren und das System dann zu integrieren Die folgende Klassifizierung ist notwendig da insbesondere im Zeitbereich verschie dene Randbedingungen f r die einzelnen Klassen angenommen werden m ssen e Streng zyklisch ablaufende Tasks Fester Bestandteil dieser Teilaufgaben sind exakte Zeitabst nde in denen diese Tasks zumindest gestartet werden und generell auch komplett ablaufen m ssen um der Spezifikation zu gen gen Beispiele hierf r sind Messwertaufnahmen oder die Bedienung von asynchro nen Schnittstellen zur Datenkommunikation Ereignis gesteuerte Tasks Das Starten bzw Wecken einer Task mit dieser Cha rakterisierung ist an ein externes Erei
82. falls mit Schwierigkeiten Hierzu sei einmal ein Software basiertes System betrachtet Eine logisch arithmetische Anforderungsdefinition etwa in UML kann durch eine geeignete Software gegen ein daraus entstandenes Software system verifiziert werden bzw umgekehrt mehr noch Aus einer solchen Anfor derungsdefinition kann mithilfe von Codegeneratoren das Softwaresystem sogar erzeugt werden Weitere Randbedingungen hingegen wie sie z B in Form von zeitlichen Randbedingungen Echtzeitsystem vorliegen k nnen zwar formalisiert werden 4 Softwarequalit t 55 sie sind jedoch meist nicht funktional also durch einen Compiler bersetzbar und im Zielsystem nicht oder zumindest nur unter weiteren Randbedingungen formal pr fbar Hier spielt auch die Systemkonzeption eine gro e Rolle gt 2 6 5 1 Die formale Verifikation ist damit nur ein Bestandteil der Ma nahmen zur Erh hung der Softwarequalit t der weitaus gr ere besteht in dem Testen 4 2 Zuverl ssigkeit Von elektronischen Systemen wird ein hohes Ma an Zuverl ssigkeit erwartet Dieser Satz kann sicherlich als allgemein g ltig angesehen werden aber was ist Zuverl ssigkeit eigentlich Definition 4 5 Zuverl ssigkeit reliability ist die Wahrscheinlichkeit dass ein System seine defi nierte Funktion innerhalb eines vorgegebenen Zeitraums und unter den erwarteten Arbeitsbedingungen voll erf llt das hei t intakt ist und es zu keinem System ausfall kommt
83. fe Rot erg be 4 2 5 4 Messen des Testfortschritts Gewinn gt Testaufwand Bild 4 2 Gewinn versus Testaufwand Ein Testprojekt sollte wie jedes andere Projekt genau geplant werden Teil dieses Plans ist die Festlegung des Projektziels etwa in der Form wie viele unentdeckte Fehler die Software nach Testende noch haben darf Art und Umfang der Tests 62 Embedded Systems Engineering Skript V1 00 werden sich nach dieser Gr e richten insbesondere darf nicht bersehen werden dass sich der differenzielle Gewinn mit wachsendem Testaufwand wieder ernie drigt Bild 4 2 Um dies zumindest absch tzen zu k nnen ist das Wissen ber die Komplexit t des Codes wichtig Eine passende Codemetrik ist die zyklomatische Komplexit t cyclomatic complexity nach McCabe Diese bestimmt die Anzahl der if while do und for Kommandos im Code und damit die Anzahl der m glichen Ver zweigungen Tools hierf r sind auch frei verf gbar 4 2 6 Modultests Die meisten Software Entwicklungsmodelle unterscheiden zwischen Modultests Integrationstests und Systemtests Modultests sind dabei das erste und wirkungs vollste Instrument denn durchschnittlich 65 aller nicht schon in Reviews abge fangener Software Fehler werden hier gefunden F r einen Modultest kann man verschiedene Strategien anwenden Ein m glicher Weg kann der folgende sein 1 Man teilt alle Eingangsgr en Variablen in so genannte quivalenzklassen ein Eine qu
84. felder Den Fehlern auf der Spur Teil 4 Integrationstests das ungeliebte Stiefkind Elektronik 54 13 S 73 77 2005 Stephan Gr nfelder Den Fehlern auf der Spur Teil 5 Systemtests die letzte Teststufe ist alles andere als eine exakte Wissenschaft Elektronik 55 14 S 45 51 2006 Sachwortverzeichnis A acc dent 22 3 57 ADC Siehe Analog Digital Wandler Adde n oiae Siehe Addierer Addieren u 4 s mein 22 Aktu tor u ner n 9 Analog Digital Wandler 7 nderbarkeit uneeeee 52 Asynchrone Kommunikation 40 Ausf hrungszeit nceneen 16 Ausnahmebehandlung Timer 34 yalability enient ni i 54 B BCET Siehe Best Case Execution Time Belastungstest neeneeen 64 Benutzbarkeit ee 52 Best Case Execution Time 77 Betriebssystem u eeeen 86 Architektur 88 Hauptaufgaben 87 Kern Schale Modell 89 Microkernel 89 monbolithisch ee 88 Multiprocessing ene 90 Multithreading 90 Prozess ae ann 89 Prozesszustandsmodell 90 Scheduling e 89 Schichtenmodell 88 Thread Rat 89 ZEILE 86 Black Box Test e 61 Byte Flight eeeneen 84 C GER Siehe Common Causation Failure elding rules 66 Codechecke
85. ffiziente und komfortable Nutzung eines Computers erm glichen zusam mengefasst sind 9 Abschnitt 7 2 Hierzu z hlen z B auch Programmierum gebungen Compiler Linker Debugger und weitere Dienstprogramme die h ufig nicht vom Betriebssystem zu trennen sind da sie dessen Schnittstellen nutzen Mit einer gro en Berechtigung kann das Betriebssystem damit als virtuelle Maschine aufgefasst werden die dem Nutzer das native Interface der Hardware Befehlssatz Registermodell sowie erweiterte Funktionen zur Verf gung stellt Bild 6 1 Welche Aufgaben sind konkret in der virtuellen Maschine verankert Hierzu z hlen die Erweiterung der Funktionalit ten die Organisation Steuerung und Kontrolle des gesamten Betriebsablaufs die Verwaltung der Betriebsmittel und weitere Aufgaben z B Protokollierung oder Nutzerverwaltung Bild 6 2 zeigt die wesentlichen S ulen die zusammen ein Betriebssystem bilden und darin wird f r Echtzeit oder Real Time Betriebssysteme die Verwaltung der Zeit nat rlich eine besondere Rolle spielen 88 Embedded Systems Engineering Skript V1 00 Nutzer Programme Hardware CPU Peripherie Speicher Betriebssystem Bild 6 1 Betriebssystemsicht Applikationsprogramme Basic File Memory Time Resource Communi Input Manage Manage 5 Manage i Others Output ment ment ee ment i RN e g User System System System System System TS admin BIOS FMS MMS Te RMS
86. formales Modell Informell bedeutet hierbei die M glichkeit zur mehrdeu tigen Interpretation w hrend sich teilformal auf Modellteile mit formaler sowie andere mit informeller Spezifikation bezieht wobei das Gesamtmodell hieraus zusammengesetzt ist 3 Design von eingebetteten Systemen 43 Die eindeutige Interpretation ist es woran man in der Technik interessiert ist Die se gew hrt eine M glichkeit zur kompletten Simulation seines Verhaltens Hierzu wird ein Simulator ben tigt Definition 2 5 Ein Simulator ist eine Vorrichtung zur wirklichkeitsgetreuen Darstellung be stimmter Bedingungen und Verh ltnisse in Auswertung eines Modells Die Kunst der Systementwicklung l sst sich sehr weitgehend auf die Kunst der Auswahl des richtigen Modells zur ckf hren denn die Modelle haben sehr starken Einfluss auf die sp tere L sung Als allgemeine Modellierungsprinzipien kann man folgendes festhalten e Jedes Modell kann in unterschiedlichen Pr zisionsgraden ausgedr ckt werden und die Wahl des Pr zisionsgrads muss anhand der darzustellenden und zu erforschenden Details ausgew hlt werden e Jedes Modell sollte einen Realit tsbezug haben e Ein einzelnes Modell ist nie ausreichend es sollten immer verschiedene Sichten modelliert werden e Jedes nichttriviale System wird am Besten durch eine kleine Menge fast unabh ngiger Modelle angen hert Bei den formalen Modellen kann man dann noch die Teilmenge der funktionalen
87. fpass Filter Sample amp Hold Verst rker 4 Zeit diskret Zwischenzustand Werte analog AD Converter Zeit diskret Digitales System Werte diskret isochron DFA Zeit diskretes System IT System asynchron isochron aH Zeit diskret Digitales System Werte diskret isochron DA Converter Tiefpassfilter Direkte digitale Zeit quasi analog Ausgabe Werte quasi analog Bild 1 5 berg nge zwischen den Zeitbindungen 12 Embedded Systems Engineering Skript V1 00 Definition 1 11 In Zeit diskreten Systemen gilt dass das System beschrieben z B durch eine Funk tion von abz hlbare vielen Zeitpunkte abh ngt Hierbei k nnen abz hlbar unend lich viele oder endlich viele Zeitpunkte relevant sein Folglich wird jede Funktion g t f r alle Werte re N oder hnlich m chtige Men gen oder f r t to t tk definiert Zeit diskrete Systeme sind fast immer mit Werte Diskretheit gekoppelt man spricht dann auch von der digitalen Welt Definition 1 12 Zeit unabh ngige Systeme sind Systeme die keine Zeitbindung besitzen Dies be deutet nicht dass sie ber die Zeit konstant sind sie sind nur nicht explizit daran gebunden Die Zeit unabh ngigen Systeme werden h ufig auch als informationstechnische Systeme IT Systeme bezeichnet In der Praxis sieht die Kopplung zwischen diesen drei Zeitbindungen so aus dass berg nge durch bestimmte Bausteine oder Vorg nge geschaffen werden Bild 1 5 stellt dies zusam
88. fw ndiger verglichen mit Prozessumschaltung weil im gleichen Adressraum verweilt wird Allerdings sind auch die Daten des gesamten Prozesses durch alle Threads manipulierbar 2 2 2 Prozesssynchronisation und kommunikation Die Prozesssynchronisation dient dem Ablauf der nebenl ufigen Programmteile und erm glicht eine Form der Wechselwirkung zwischen diesen Das Warten eines Prozesses auf ein Ereignis das ein anderer ausl st ist die einfachste Form dieser Prozesssynchronisation gleiches gilt auch f r Threads Die Prozesskommunikation erweitert die Prozesssynchronisation und stellt somit dessen Verallgemeinerung dar Hier muss es neben den Ereignissen auch M glich keiten geben die Daten zu bertragen Die praktische Implementierung ist dann 2 Echtzeitsysteme 21 z B durch ein Semaphoren Mailbox System gegeben ber Semaphoren wird kommuniziert ob eine Nachricht vorliegt in der Mailbox selbst liegt dann die Nachricht F r ein Multithreadingsystem kann dies direkt ohne Nutzung eines Be triebssystems implementiert werden da alle Threads auf den gesamten Adressraum zugreifen k nnen Dies gilt nicht f r Multiprocessingsysteme hier muss ein Betriebssystem zur Implementierung der Mailbox und der Semaphoren verwendet werden Wie dies im Fall eines Multithreading erfolgen kann ist als Beispiel im Kapitel 5 gezeigt Bei diesen Kommunikation wie auch der einfachen Synchronisation kann es zu Verklemmungen kommen Eine Menge von Th
89. g Es verbessert sich zwar noch weiterhin wenn die IRQs noch sporadischer auftreten dennoch d rfte der Effekt auf wenige Prozent begrenzt bleiben Der Unterschied in der Auslegung der Betriebsfrequenz ist sehr gro Die Ur sache hierf r liegt in der geforderten maximalen Reaktionszeit Die notwendige Frequenz kann f r die Zeitsteuerung dadurch heruntergesetzt werden dass die extrem kritischen Teile mehrfach vorkommen oder die Zykluszeit verringert wird Letztere Ma nahme ist begrenzt die Berechnungszeit der Prozess gekop pelten Software setzt das Limit ein h ufigerer Timer IRQ erzeugt mehr Overhead Klammerwerte in Tabelle 5 2 F r Priorit t O0 werden zwei Timer IRQ pro 2000 Takte Zyklus erzeugt 84 Embedded Systems Engineering Skript V1 00 Time triggered Modified Event triggered Anzahl Takte f r Prozess 3300 3420 3120 gekoppelte Software auf 12000 Takte Anzahl Takte Hauptprogramm 8700 8580 8880 auf 12000 Takte Relativer Gewinn 1 1 02 1 035 Maximale Latenzzeit Takte 0 2000 1000 0 0 1 2100 1 100 2 2300 2 300 3 2600 3 600 Mittlere Latenzzeit Takte 0 1000 500 0 0 1 1050 1 2 5 2 1150 2 22 6 3 1300 3 90 Maximale Reaktionszeit 0 2100 1100 0 100 Takte 1 2300 1 300 2 2600 2 600 3 3000 3 1000 Resultierende Taktfrequenz 105 55 MHz 10 MHz Reaktionszeit MHz Reaktionszeit Priorit t 0 Priorit t 3 Tabelle 5 2 Taktzahlen und
90. gemeint F r RS232 auch eine asynchrone Schnittstelle bedeutet a synchron dass der Beginn einer Aussendung f r den Empf nger spontan er folgt Auf h herer Ebene ist diese Kommunikation nat rlich nicht zuf llig son dern geplant Das perfekt synchrone Modell geht davon aus dass Kommunikation keine Zeit kostet sondern st ndig erfolgt Dies lehnt sich an die Planetenbewegung an wo die gegenseitige Gravitation und die der Sonne zu den Bahnen f hrt und wird deshalb auch Newtonsches Modell genannt Die synchronen Sprachen basieren auf diesem Modell Das dritte Modell das synchron aber mit konstanter Zeitverz gerung kommuni ziert wird auch Vibrationsmodell genannt Dieser Name entstammt der Analogie 22 Embedded Systems Engineering Skript V1 00 zur Kristallgitterschwingung bei der eine Anregung sich ber den Austausch von Phononen fortpflanzt Wozu dienen diese Kommunikationsmodelle Der Hintergrund hierzu besteht da rin Kommunikation und Betrieb in nebenl ufigen ggf auch verteilten Systemen modellieren zu k nnen Die Annahme einer perfekt synchronen Kommunikation beinhaltet eigentlich nicht dass Null Zeit ben tigt wird vielmehr ist die Zeit zur Bestimmung eines neuen Zustands im Empf nger kleiner als die Zeitspanne bis zum Eintreffen der n chsten Nachricht Dies bedeutet dass sich das gesamte Sys tem auf diese Meldungen synchronisieren kann 3 Design von eingebetteten Systemen Dieses Kapitel
91. gende generelle Aufgaben kommen auf dieses System zu 1 Messwertaufnahme Auf 4 Kan len wird mit einer Abtastfrequenz von je 1 kSPS Sample per Second aufgenommen Die Grundfrequenz des aufzuneh menden Signals sei 40 Hz die Aufl sung des AD Wandlers 8 bit 96 Embedded Systems Engineering Skript V1 00 2 Bestimmung aller notwendigen Parameter zur Beurteilung der G te der Signale Hierzu z hlen die tats chliche Frequenz pro Kanal sowie die ber bzw Unter schreitung von gegebenen zul ssigen Bereichen f r den Spitzenwert 3 Anzeige der gemessenen Werte Spitzenwert pro Kanal aktuelle Frequenz pro Kanal aktuelle Warnsituation 4 Abfrage der Bedientasten Anzeige des Men s Aufnahme neuer Grenzwerte 5 Reprogrammierung bei Update der Software Ohne auf die Einzelheiten der Messwertauswertung etc einzugehen soll dieses System konzipiert werden Hierzu z hlen im ersten Ansatz die Aufteilung der Auf gaben auf die beiden Rechner im Verbund sowie die Auslegung des lokalen Bus ses im zweiten Ansatz dann die Konzeption der Software auf den Rechnern Grundsatz ist dabei dass das System garantiert in Echtzeit arbeiten soll Hierzu z hlt dass e alle Messwerte garantiert verarbeitet werden und e eine Alarmmeldung mindestens zwei der vier Kurven sind ausgefallen d h das Maximum ist lt 10 vom zul ssigen Minimalwert in 4 ms bei der An zeigeeinheit ist 7 2 Auslegung des lokalen Busses Geht man davon aus
92. gn Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 85 bedingt eben durch die Nicht Exklusivit t Ein derartiges System kann so ausgelegt sein dass der jeweils lokale Teil auf Basis einer modifizierten Ereignissteuerung l uft die Kommunikation ggf jedoch entkoppelt davon Auf Seiten des Netzwerks muss ein deterministisches Verfahren zur Buszuteilung existieren das zumindest f r einen Satz von Nachrichten die echtzeitf hige bertragung garantiert Hier folgt eine kurze Diskussion der Zuteilungsverfahren e CSMA CD Carrier Sense Media Access with Collision Detection Dieses bei Ethernet verwendete Verfahren scheidet aus da der Zugriff probabilistisch ist und somit keine maximale bertragungszeit garantiert werden kann e CSMA CA Carrier Sense Media Access with Collision Avoidance Das Con troller Area Network CAN verwendet dieses Verfahren bei dem bei einem Zugriff eine Kollision vermieden wird Dies bedeutet dass ohne weitere Ma nahmen die h chste Priorit t garantiert bertragen wird alle anderen aber wiederum keine Echtzeitf higkeit besitzen Die besonderen Ma nahmen k nnen die maximale Wiederholungsfrequenz be treffen Durch diese Einschr nkung k nnte ein CSMA CA Netzwerk echtzeitf hig werden Dadurch w re ein Ereignis gesteuertes Netzwerk tats chlich m g lich e TTP C Time Triggered Protocol Class C In diesem Zeit gesteuerten Proto koll besitzen alle Knoten eine gemeinsame Zeit mit geri
93. gnis gebunden meist in Form eines In terrupt Requests Der Startzeitpunkt ist somit nicht zur Compilezeit bestimm bar so dass diese Tasks st rend auf den zeitlichen Gesamtablauf wirken k nnen Typische Vertreter dieser Klasse sind der Empfang von Nachrichten via Netzwerk bzw die Reaktion darauf oder Schalter in der Applikation die besondere Zust nde signalisieren etwa Not Aus o Generelle Tasks mit Zeitbindung Die dritte Klasse beschreibt alle Tasks in dem System die zwar keine scharfen Zeitbedingungen enthalten im Ganzen jedoch 72 Embedded Systems Engineering Skript V1 00 Zeitschranken einhalten m ssen Hiermit sind Tasks beschrieben die beispiels weise Auswertungen von Messwerten vornehmen W hrend die einzelne Aus wertung ausnahmsweise ber einen Messwertzyklus hinaus dauern darf muss insgesamt die mittlere Auswertezeit eingehalten werden Ereignis gesteuerte Tasks Streng zylisch ablaufende Tasks Generelle Tasks mit Zeitbindung Designpriort t Tasks ohne Zeitbindung Bild 5 1 Taskklassen und Designpriorit ten Diese drei Grundklassen zeitabh ngiger Teilaufgaben stellen das Grundger st zum Systemdesign dar Die erste Aufgabe des Systemdesigners besteht darin alle in der Beschreibung vorkommenden Aufgaben in dieses Grundger st einzuteilen mit allen dabei auftretenden Schwierigkeiten Generell gilt dass eine Teilaufgabe in eine h here Klasse
94. her Fehler provozieren als die bereits zitierten Sch nwettertests e Grenzf lle ausprobieren 4 Softwarequalit t 61 Bei der Testabdeckung gilt es noch zu berlegen ob die Ausf hrung einer Source codezeile berhaupt gen gt Hierzu werden noch Testabdeckungsmetriken dar gestellt gt 4 2 7 4 2 5 3 Ausf hren und Evaluieren der Tests Zwei Faktoren beeinflussen die Ausf hrung des Tests der manuell halbautoma tisch oder vollautomatisch sein kann die Haftung bei Software Fehlern und die Wiederholungsrate der Tests Anwendungen mit Sicherheitsrelevanz etwa erzeu gen einen erheblichen Druck in Richtung automatischer Tests allein um die exak te Wiederholbarkeit zu erreichen Derartige Wiederholungen k nnen notwendig sein wenn an anderer Stelle ein Fehler gefunden wurde dessen Behebung nun auf R ckwirkungsfreiheit getestet werden soll so genannte Regressionstests Nach Ausf hrung der Tests was sehr gut automatisch durchf hrbar ist m ssen die Tests bewertet werden was meist nicht automatisch durchzuf hren ist Zumindest m ssen die Kriterien wann ein Test bestanden ist und wann nicht vorher fixiert werde ansonsten droht ein pures Herumprobieren Last not least bleibt die Frage der Vertrauensw rdigkeit des Tests denn ein st ndiger Erfolg sollte Misstrauen erzeugen Um dies zu pr fen werden bewusst Fehler eingebaut Fault Insertion oder Fault Seeding deren Nichtentdeckung nat rlich eine Alarmstu
95. icht erh ltlich Die erweiterte Hardware ist derzeit nicht erh ltlich 3 3 Ans tze zur Minderung der Verlustleistung Wie bereits in Abschnitt 3 1 gezeigt wurde existiert ein quantitativer Zusammen hang zwischen Verlustleistung und Rechenzeit Das dort abgeleitete Gesetz dass P T const gelten soll gilt allerdings nur unter der Voraussetzung dass man sich in einem Design sprich eine Architektur bewegt und Versorgungsspannung sowie Taktfrequenz ndert Das ist nat rlich auch eine Methode aber eben nur eine die zur Verlustleistungs minderung in Frage kommt In der Realit t sind es 4 Methoden die zur Anwen dung kommen e Auswahl einer Architektur mit besonders guten energetischen Daten e Codierung von Programmen in besonders energiesparender Form e Einrichtung von Warte und Stoppzust nden e Optimierung der Betriebsfrequenz und Betriebsspannung nach Energiegesichts punkten Und um es vorweg zu nehmen Dies ist ein hochaktuelles Forschungsgebiet es gibt Ans tze 7 aber noch keinerlei analytische L sungen Im Folgenden sollen diese Ans tze kurz diskutiert werden 3 3 1 Auswahl einer Architektur mit besonders guten energetischen Daten Es mag auf den ersten Blick nat rlich unwahrscheinlich erscheinen warum einige Architekturen mehr andere weniger Verlustleistung bei gleicher Geschwindig keit ben tigen dennoch stellt sich in der Praxis immer wieder heraus dass es drastische Unterschiede bei Mikroprozes
96. iergeeiins 44 statisches Diagramm 43 Unterbrechung Siehe Interrupt ASADI iners oisein islais 52 A4 Validierung 53 Verf gbarkeit 54 Verhalten asynchron ueeseessessenneeneneenn 11 Ausf hrungszeit nen 16 deterministisch 3 Echtzeitsystem 14 26 Frist ie 16 186Chron ernennen 11 kooperativ ennennesennennennennenennnn 27 Latenzzeit iur ns 16 Profiling es 27 Reaktionszeit 16 Simulation ceeeneeen 27 stochastisch eeene 3 bersetzungszeit definiert 27 Worst case Analyse 27 Zeit analog eeen 9 Zeit diskret eenee 11 Verifikation 53 Verklemmung ese 2 18 Verlustleistung e XI GALS Architektur 40 Kurzschlussstrom 24 eckson nrinn ns 24 Minderung 36 Schaltverluste 24 Schwellenspannung 25 SOWArE est 38 Stoppzustand Mikroprozessor 39 verteiltes System 4 106 Sachwortverzeichnis Verteiltes System neen 83 systemkritisch 0 27 SYSLEMWEIL eeneenennennennennennennennenn 27 W Worst Case Analyse 27 WCET Siehe Worst Case Execution Zykluszeit e a aee 27 i Zeit analoges System 9 Time BR u Zeitbindungen ncnenee 10 Wertediskretisierung 7
97. ierungsfehler gefunden werden e Value Tracking Indexvariable f r Arrays m gliche Divisionen durch Null so wie Null Zeiger stellen potenzielle Fehlerquellen im Programm dar Sie werden ausf hrlich analysiert e Starke Typpr fung Abgeleitete Typen typedef in C werden darauf berpr ft dass nur sie miteinander verkn pft werden und nicht die Basistypen Wie terhin erfolgt eine sehr genaue Typpr fung also z B ob Vergleiche zwischen int und short usw gef hrt werden und eine entsprechende Warnung wird aus gegeben e Falls es so genannten Funktionssemantiken gibt das sind Regeln f r Parame ter und R ckgabewerte etwa so dass der erste Funktionsparameter nicht O sein darf dann sind weitere Checks m glich Letztendlich erzwingt der Einsatz von statischen Codecheckern dass sich der Ent wickler sehr um seinen Sourcecode bem ht Und genau das d rfte in Zusammen hang mit Codierungsregeln 4 4 einen sehr positiven Effekt auf die Software qualit t haben 4 2 5 Testen allgemein In der Praxis steuert alles auf das Testen hin dies erscheint als die ultimative L sung Ein gute Einf hrung in dieses beraus komplexe Thema ist in 25 29 gegeben Testen muss als destruktiver Prozess verstanden werden Man versucht die Soft ware zu brechen ihre Schwachpunkte zu finden Fehler aufzudecken Es ist na t rlich sehr schwierig f r den Entwickler sein bislang konstruktive Sicht aufzu geben Bislang w
98. ige Antwortzeit A i die Bearbeitungszeit alle Zeiten ausgedr ckt in Prozessortakten bei angenommen 1 Instruktion pro Takt IPC A sei diejenige Zeit die sich als KGV kleinstes gemeinsames Vielfaches aller minimalen Folgezeiten F i ergibt Ferner sei fG A F i die maximale Anzahl der Auftritte pro Zeitintervall A Jetzt m ssen die Ungleichungen 5 F Ad lt A 3 12 Yne 0 k 1 5 f A max A j A n lt T n 3 13 ai k gelten 3 12 bedeutet dabei dass die Summe aller im Zeitintervall 1 auftretenden IRQ Bearbeitungszeiten dieses Intervall nicht berschreiten darf eine ver gleichsweise einfach zu realisierende Forderung 3 13 bedeutet hingegen dass f r alle IRQ Ebenen und Priorit ten die Einhaltung der maximal m glichen Antwort zeit gew hrleistet sein muss Hierzu muss angenommen werden dass ein niedriger priorisierter IRQ kurz zuvor auftrat und bearbeitet wird und dass alle h heren IRQs ebenfalls auftreten und bearbeitet werden Hinzu kommt die eigene Bearbeitungszeit A n 3 Design von eingebetteten Systemen 33 Gl 3 13 ist au erordentlich schwierig im Nachweis oder sie bedeutet dass das System planm ig berdimensioniert werden muss Insgesamt sind folgende Vor und Nachteile f r diese Form der Systemauslegung aufzuz hlen Bei weicher Echtzeit ist eine gute Anpassung an die real ben tigten Res sourcen m glich Die Einbindung zeitunkritischer Teile ist sehr gut
99. igkeit bildet das Grundmodell f r Multiprocessing und Multithreading 3 Zwei Prozesse bzw Threads sind dann nebenl ufig wenn sie unabh ngig von einander arbeiten k nnen und es keine Rolle spielt welcher der beiden Prozesse Threads zuerst ausgef hrt oder beendet wird Indirekt k nnen diese Prozesse den noch voneinander abh ngig sein da sie m glicherweise gemeinsame Ressourcen beanspruchen und untereinander Nachrichten austauschen Hieraus kann eine Synchronisation an bestimmten Knotenpunkten im Programm resultieren Hier liegt eine Fehlerquelle denn es kann hier zu schwerwiegenden Fehlern Verklemmungen deadlocks und damit zu einem Programmabsturz kom men Die Hauptargumente warum es trotz der Probleme sprich neue Fehlerm glich keiten f r Softwareentwickler sinnvoll ist Programme nebenl ufig zu entwickeln sind e Die Modellierung vieler Probleme wird dadurch vereinfacht indem sie als mehr oder weniger unabh ngige Aktivit ten verstanden werden und entsprechend durch Sprachkonstrukte umgesetzt werden k nnen Jede Aktivit t kann dann isoliert betrachtet werden nur die Kommunikation und Synchronisation ist zu beachten Nebenl ufigkeit f hrt hier zu einer abstrakteren Modellierung und ob die entstandene Nebenl ufigkeit dann wirklich zu einer gleichzeitigen Bearbei tung f hrt ist nebens chlich Ein Beispiel hierzu wird in Kapitel 5 behandelt wo Messwertaufnahme und Auswertung in zwei miteinander gekoppelte a
100. immer auf einer Form der Redundanz d h zur Erkennung von Fehlern sind mehr Informationen als zum eigentlichen Betrieb notwendig daher wird das System komplexer Der naheliegende und vor einigen Jahren auch fast ausschlie lich genutzte Ansatz liegt dabei in der Erweiterung der Hardware um fehlererkennende Teile wie Pari t tsbits Pr fsummen fehlererkennende bzw korrigierende Codes usw Dieser Ansatz wird aktuell jedoch als zu einengend angesehen so dass man sich nun um Mischformen bem ht 4 2 1 1 Einsatz redundanter Hardware Redundante Hardware kann im wesentlichen durch Vervielfachung mit einem Mehrheitsentscheider erreicht werden Dies wird auch als Voting bezeichnet und bis auf den Entscheider selbst ist alles mehrfach ausgelegt Der Vorteil dieses Ansatzes liegt darin dass die gleiche Hardware kopiert wird Das Fehlermodell geht davon aus dass die Hardware aufgrund eines Defektes nicht funktioniert nicht aufgrund eines konstruktiven Mangels Die eigentliche Fehlertoleranz d h die fehlervermeidende Reaktion kann dann in Form dreier Varianten erfolgen e Statische Redundanz Die Hardware bleibt immer erhalten die Mitglieder stimmen laufend an vorgesehenen Punkten ab und die Mehrheitsentscheidung gilt e Dynamische Redundanz Bei Erkennen eines Fehlers wird die fehlerhafte Hardware rekonfiguriert d h Reservekomponenten kommen zum Einsatz Hier existieren z B Modellen f r Prozessoren Operationen wie Additio
101. in der Praxis Elektronik 52 24 S 86 94 2003 Literaturverzeichnis 99 18 19 20 21 22 23 24 25 26 27 28 29 Holger Blume Hendrik T Feldk mper Thorsten von Sydow Tobias G Noll Auf die Mischung kommt es an Probleme beim Entwurf von zuk nftigen Systems on Chip Elektronik 53 19 S 54 59 und Elektronik 53 20 S 62 67 2004 Emil Talpes Diana Marculescu Toward a Multiple Clock Voltage Island Design Style for Power Aware Processors IEEE Transactions on Very Large Scale Integration VLSI Systems 13 5 pp 591 603 2005 Christian Siemers Prozessor Technologie tee CHANNEL Compact Verlag Interactive GmbH M nchen Mai 2004 http www esterel technologies com http ieee1588 nist gov Gerad J Holzmann The Power of 10 Rules for Developing Safety Critical Code IEEE Computer 39 6 pp 95 97 2006 http www splint org Stephan Gr nfelder Den Fehlern auf der Spur Teil 1 Das Handwerk des Testens will gelernt sein wird aber kaum gelehrt Elektronik 53 22 S 60 72 2004 Stephan Gr nfelder Neil Langmead Den Fehlern auf der Spur Teil 2 Modultests Isolationstests Testdesign und die Frage der Testumgebung Elektronik 53 23 S 66 74 2004 Stephan Gr nfelder Den Fehlern auf der Spur Teil 3 Automatische statische Codeanalyse Elektronik 54 9 S 48 53 2005 Stephan Gr n
102. ird analysiert und die Test Coverage wird bestimmt Hieraus soll der Tester nun ableiten mithilfe welcher Einganswerte er weitere Teile durchlaufen und damit testen lassen kann Der Test wird dann mit den 4 Softwarequalit t 63 neuen Werten weitergef hrt bis eine zufriedenstellende Test Coverage erreicht ist Diese Form des Tests wird White Box Test genannt da nun die Eigenschaften des Quellcodes ausgenutzt werden Weiterhin entsteht die Frage nach dem Testsystem Host oder Target Testing Grunds tzlich hei t die Antwort nat rlich Zielsystem denn nur hier k nnen versteckte Fehler wie Bibliotheksprobleme Datentypabweichungen wie viele Bits hat int usw erkannt werden Weiterhin k nnen gemischte C Assemblerprogram me tats chlich nur dort getestet werden In der Praxis weicht man jedoch h ufig auf Hostsysteme aus weil diese besser verf gbar sind Festplatte und Bildschirm haben ggf schneller sind usw 4 2 7 Integrationstests Der Test der einzelnen Module erscheint vergleichsweise einfach da insbesondere die Modulkomplexit t in der Regel noch begrenzt sein wird Der nun folgende Integrationstest fasst nun mehrere bis alle Module zusammen testet die Schnittstellen zwischen den Modulen und ergibt hiermit den Abschlusstest der Software da der darauf folgende Systemtest auf das gesamte System einschlie lich Hardware zielt 4 2 7 1 Bottom Up Unit Tests Die wohl sicherste Integrationsteststrategie besteht
103. it einem Takt Clock Domain versorgt der nun sehr genau an den aktuellen Rechenbedarf angepasst werden kann Hard ware VCO Voltage Controlled Oscillator mit DVS Dynamic Voltage Scaling Wie aber kann man sich die asynchrone Kommunikation vorstellen Asynchron ist eigentlich das falsche Wort hierf r selbst synchronisierend ist rich tig Hiermit ist gemeint dass ber die Kommunikationsleitungen nicht nur Daten und ggf ein Takt gef hrt werden sondern dass mit den Daten ein Handshake verbunden ist In etwa verl uft dies nach dem Handshake 1 S Daten sind g ltig 2 E Daten sind bernommen 3 S Daten sind nicht mehr g ltig 4 E Wieder frei f r neue Daten Hiermit ist grunds tzlich ein Verfahren m glich wie die Ausf hrung von Program men Energie bzw Verlustleistungs optimal angepasst werden kann 42 Embedded Systems Engineering Skript V1 00 3 4 Modellierungs und Programmiersprachen zur Einbeziehung der Randbedingungen Bisher wurden einige L sungswege im Sinn von Design Pattern besprochen Diese bedeuten dass der die Designer in das Problem in einer ingenieurm igen L sung bearbeitet Es wird nicht programmiert es wird designed Im Zeitalter der Programmierbarkeit ist es nat rlich von Interesse die Randbedin gungen auch innerhalb einer genormten Sprache formulieren zu k nnen und viel leicht sogar in Funktionalit t zu bersetzen Letzteres ist derzeit noch ein Wunsch traum aber
104. ivalenzklasse enth lt all jene Eingangsgr en oder Resultate eines Moduls f r die erwartet wird dass ein Programmfehler entweder alle oder keinen Wert betrifft Beispiel Die Absolut Funktion int abs int besitzt drei quivalenzklassen negative Werte die Null und positive Werte 2 Aus jeder quivalenzklasse nimmt man nun zum Test des Moduls mindestens einen Vertreter Im Testdesign werden die Eingangswerte die Aktion und die erwarteten Ergebnisse festgelegt Bei der Testdurchf hrung werden dann die erwarteten mit den tats chlichen Ergebnisse verglichen wobei ggf ein Tole ranzbereich zu definieren ist z B bei Floating Point Zahlen Dieser Test orientiert sich nicht am inneren Design des Moduls und wird daher auch als Black Box Test bezeichnet Wichtig ist dabei auch die Erkenntnis dass ggf auch Software zum Testen geschrieben werden muss z B zum Aufruf oder falls auf andere noch nicht fertige oder nicht getestete Module zur ckgegriffen wird Im letzteren Fall werden die fehlenden Module durch so genannte Pro grammst mpfe program stubs ersetzt Der Test wird im Allgemeinen ergeben dass keineswegs alle Codezeilen durchlau fen wurden Um dies auch wirklich nachweisen zu k nnen werden Test Coverage Tools eingesetzt Diese instrumentieren den Originalcode d h sie f gen Code hinzu der dem Tool den Durchlauf meldet Nach dieser ersten Testphase werden also weitere Schritte folgen 3 Der bisherige Test w
105. kt f r die Haupt und eines f r die Interrupt Service Routine nebeneinander dar und den Zeitverlauf nach unten Wichtig ist dass Ereignisse synchrone Aufrufe asynchrone Unterbrechungen den Kontrollfokus jeweils verlagern k nnen Dieses Sequenzdiagramm modelliert ein planbares System also die Variante der Zeit gesteuerten Systeme unabh ngig davon ob die Implementierung nun durch Timer Interrupt oder durch regelm igen Aufruf aus einem Programm heraus erfolgt Wie allerdings bereits eingehend diskutiert wurde sind die planbaren Systeme mit einigen Nachteilen belegt was u a zur Konzeption der modifizierten Ereignis gesteuerten Systeme gef hrt hat Dies kann nur modelliert werden wenn asynchro ne Ereignisse das in Bild 3 10 enthaltene Ereignis ist synchron zur Verf gung stehen Hierf r stellt UML vier verschiedene Ereignisse bereit e Signale Dies sind asynchrone Ereignisse die von einem Ereignis ausgel st und von dem anderen abgefangen werden In diese Kategorie geh ren die Exceptions die Ausnahmen e Aufrufe Aufrufe stellen synchrone Ereignisse dar sie bestehen aus dem Aufrufen einer Operation e Verstreichen von Zeit Das Verstreichen eines Zeitintervalls bzw das berschreiten einer Zeitmarke wird hierunter verstanden Diese Ereignisse k nnen sowohl synchron als auch asynchron aufgefasst werden e Zustands nderung Ein nderungsereignis entsteht aus der dauernden berpr fung von Bedingungen und
106. kte unterhalb der Kurve siehe auch Bild 3 1 optimal sind Definition 3 1 Die Fl chen Zeit Effizienz space time efficiency Esr ist definiert als 3 Design von eingebetteten Systemen 25 1 1 E e SIT A T JAT W hrend das A T Gesetz als Zusammenhang f r eng begrenzte Operationen also etwa einen Addierer gefunden wurde wird es aktuell auch zur Beurteilung ganzer ICs benutzt beispielsweise f r Mikroprozessoren Rechenzeit und Verlustleistung Der Zusammenhang zwischen Verlustleistung und Rechengeschwindigkeit kann etwas genauer betrachtet und auch hergeleitet werden Bei einem CMOS Design wie es f r Mikroprozessoren State of the Art ist z hlen 3 Komponenten zur Ver lustleistung hinzu Poa Psc P total eakage P switching _ losses 3 2 Psc Short Current Kurzschlussstrom resultiert aus demjenigen Strom der kurz zeitig beim gleichzeitigen Umschalten beider Transistoren eines CMOS Paares flie t Dies ist prinzipbedingt im CMOS Design verankert und die Anzahl der Umschaltungen pro Zeiteinheit ist nat rlich proportional zum Takt Pe V Isc 3 3 Pieakage Leakage Current Leckstrom entstammt aus dem dauerhaft flie enden Leckstrom einer elektronischen Schaltung Dieser Strom ist bei CMOS Schaltungen nat rlich sehr klein weil in jedem Stromkreis mindestens ein Transistor sperrt er ist aber nicht 0 Aufgrund der enormen Anzahl an Transistoren in aktuellen Schaltungen sowie der st
107. m Fall wohl jede Task einen Performanceverlust haben wird nat rlich nichts garantiert wird ist dieser Ansatz f r Echtzeit unbrauchbar Zusammenfassung Man kann die unterschiedlichen Schedulingstrategien so zusammenfassen dass statische Systeme auch gro e in den Griff zu bekommen sind F r diese Systeme gibt es hervorragende M glichkeiten der Berechnung ein berblick ist in 12 13 gegeben Dynamische Systeme sind derzeit immer noch in einem Forschungsstadium 7 Fallstudie Verteiltes eingebettetes System Nach viel Theorie soll ein Beispiel besser eine Fallstudie vieles von den darge stellten Dingen erl utern Die Fallstudie basiert dabei auf realen Entwicklungen Sie beinhaltet ein verteiltes System eingebettet in eine Messumgebung 7 1 Systemkonfiguration Bild 7 1 zeigt den Aufbau des gedachten Systems Aus technischen Gr nden Ex plosions gesch tzter Bereich gef hrliche Spannungen lange bertragung per op tischem Kabel etc wird die eigentliche Messeinheit MessMonitor von der Anzeige und Bedieneinheit getrennt und durch einen lokalen Bus miteinander verbunden Die dritte Einheit das serielle EEPROM beinhaltet Grunddaten des Ger ts z B Hersteller Fabrikationsnummer sowie Speicherplatz f r Ger te weite Daten Einschaltwerte Betriebsstundenz hler etc MessMonitor Optokoppler Display amp Serial Bedienung EEPROM Bild 7 1 Systemkonfiguration im Fallbeispiel Fol
108. menfassend dar Hieraus lassen sich zwei Probleme identifizieren e Es gibt einen Informationsverlust beim bergang zwischen der analogen und der Zeit und Werte diskreten Welt vor Dieser Informationsverlust ist seit langem bekannt Shannon Abtasttheorem und ausreichend behandelt e Im System liegt eine Kopplung zwischen isochronen und asynchronen Teilen vor Die isochronen Teile behandeln den Umgebungsprozess mit gleicher Zeit bindung w hrend die asynchronen Systemteile ohne Bindung laufen dennoch jedoch algorithmischen Bezug dazu haben Diese Schnittstelle ist sorgf ltig zu planen Die im letzten Aufz hlungspunkt geforderte sorgf ltige Planung der Schnittstelle f hrt dann zu den Echtzeitsystemen 2 bei denen die Anforderung an das IT System so gestellt werden dass das System auf einem gewissen Level wieder isochron arbeitet 1 3 2 Weitere Randbedingungen f r eingebettete Systeme Die Zeit spielt in Embedded Systems aus dem Grund eine bergeordnete Rolle weil der Rechner in eine Maschine eingebettet ist deren Zeitbedingungen vor herbestimmt sind Insofern hat die Zeit eine bergeordnete Bedeutung Aber Es existieren noch weitere Randbedingungen insbesondere f r den Ent wurfsprozess e Power Dissipation Verlustleistung Welche Durchschnitts und oder Spitzen leistung ist vertretbar gefordert nicht zu unterschreiten usw 1 Einf hrung in eingebettete Systeme 13 e Ressourcenminimierung Nicht nur
109. muss Die Verz gerung zwischen der Zeit der Eingabe und der Zeit der Ausgabe muss ausreichend klein f r eine akzep table Rechtzeitigkeit timeliness sein Echtzeitsysteme sind also Systeme die korrekte Reaktionen innerhalb einer defi nierten Zeitspanne produzieren m ssen Falls die Reaktionen das Zeitlimit ber schreiten f hrt dies zu Leistungseinbu en Fehlfunktionen und oder sogar Gef hr dungen f r Menschen und Material Die Unterscheidung in harte und weiche Echtzeitsysteme wird ausschlie lich ber die Art der Folgen einer Verletzung der Zeitschranken getroffen 16 Embedded Systems Engineering Skript V1 00 Definition 2 3 Ein Echtzeitsystem wird als hartes Echtzeitsystem hard real time system bezeich net wenn das berschreiten der Zeitlimits bei der Reaktion erhebliche Folgen haben kann Zu diesen Folgen z hlen die Gef hrdung von Menschen die Besch digung von Maschinen also Auswirkungen auf Gesundheit und Unversehrtheit der Umgebung Typische Beispiele hierf r sind einige Steuerungssysteme im Flugzeug oder im Auto z B bei der Verbrennungsmaschine Definition 2 4 Eine Verletzung der Ausf hrungszeiten in einem weichen Echtzeitsystem soft real time system f hrt ausschlie lich zu einer Verminderung der Qualit t nicht jedoch zu einer Besch digung oder Gef hrdung Beispiele hierf r sind Multimediasysteme bei denen das gelegentlich Abweichen von einer Abspielrate von 25 Bil
110. n auf ande re Einheiten bzw eine Sequenz davon abzubilden e Hybride Ans tze Die Mischung aus Mehrheitsvotum und Rekonfiguration stellt einen hybriden Ansatz dar der zwar komplexer ist aber nat rlich die gr te Flexibilit t besitzt Genau genommen darf man das Fehlermodell der Hardware dass diese zun chst fehlerfrei ist und keinen konstruktiven Mangel hat nat rlich nicht unbedarft ber nehmen So sind so genannte Chargenprobleme bekannt d h eine Produktions charge eines Hardwarebausteins zeigt den gleichen Mangel Dies w rde zu einem bereinstimmenden Verhalten mehrerer Komponenten im Betrieb f hren mit dem Ergebnis dass die Fehlertoleranz in eine Fehlerakzeptanz bergeht Um solche F lle auszuschlie en m ssen konstruktive Ma nahmen ergriffen wer den die dann verschiedene Hardwarekomponenten miteinander verbinden 4 Softwarequalit t 57 4 2 1 2 Einsatz redundanter Software Der mehrmalige Einsatz der gleichen Software ist zwecks Fehlertoleranz sinnlos da Software nicht altert und somit keine neuen Fehler entstehen Fehler sind von Beginn an enthalten um hier fehlertolerant zu sein m ssen verschiedene Versio nen verwendet werden Dies bedeutet einfach dass mehrere unabh ngige Designteams verschiedene Ver sionen herstellen m ssen Auch hier kann dann wieder zwischen statischer und dynamischer Redundanz unterschieden werden e Statische Redundanz N Version Programming Es werden mehrere Versio
111. n ausgebaut ist kann die Auswahl eines geeigneten Betriebssystems beeinflusst werden Der Begriff der Task wird h ufig etwas unscharf verwendet meist synonym zum Prozess manchmal auch zum Thread Aus diesem Grund wird Multitasking syno nym zu Multiprocessing und Multithreading verwendet falls nicht unterschieden werden muss Start Suspended n Suspend Resource request Resume Resource ready Execute Ready Bild 6 4 Beispiel f r ein Prozesszustandsmodell Neben den grunds tzlichen Fragen zur Unterst tzung ist nat rlich die Verwaltung von Prozessen bzw Threads entscheidend f r die Funktionalit t des Betriebs 92 Embedded Systems Engineering Skript V1 00 systems Dieser Teil wird als Scheduler bezeichnet und Bild 6 4 gibt ein Beispiel f r Prozesszust nde zwischen denen umgeschaltet werden kann In diesem Modell werden nur die Prozesse die sich im Zustand Ready befinden in Betracht gezogen ausgef hrt zu werden und einer davon wird dann in Running versetzt Wann genau kommt es nun dazu dass das Betriebssystem berhaupt einen solchen Vorgang starten kann Um es deutlich zu sagen bislang sind alle Betriebssysteme Softwareprogramme d h sie m ssen ausgef hrt werden um eine Aktion zu starten Bei nicht verdr ngenden Strategien non preemptive ist das Betriebssystem auf die Kooperation der Prozesse angewiesen Der Aufruf Suspend bzw Resource request wird von Prozess selbst durchgef hrt damit kann
112. n hier bewirken Einzelausf lle Kopplungen zu anderen In diesem Fall kommen Ana lyseverfahren wie z B Markovketten zum Einsatz 4 2 3 Gefahrenanalyse Unter Gefahrenanalyse wird ein systematisches Suchverfahren verstanden um Zu sammenh nge zwischen Komponentenfehlern und Fehlfunktion des Gesamtsys tems aufzudecken Hierzu m ssen noch einige Begriffe definiert werden 58 Embedded Systems Engineering Skript V1 00 Definition 4 9 Als Gefahr hazard wird eine Sachlage Situation oder Systemzustand bezeichnet in der dem eine Sch digung der Umgebung Umwelt Maschine Mensch m glich ist Ein Gefahrensituation ist also eine Situation in der das Risiko gr er als das Grenzrisiko ist Die urs chlich zugrundeliegenden Fehler sollen nun zur ckverfolgt werden unabh ngig davon ob diese zuf llig Alterung oder konstruktiv bedingt sind Definition 4 10 Tritt eine Sch digung tats chlich ein so bezeichnet man dieses Ereignis als Unfall accident Die systematischen Suchverfahren k nnen nun prinzipiell berall ansetzen in der Praxis w hlt man jedoch einen der beiden Endpunkte Man spricht dann von Vorw rts bzw R ckw rtsanalyse Bekannt sind hierbei die Ereignisbaumanalyse FTO Fault Tree Analysis und die Failure Mode and Effect Analysis FMEA Im letzteren Fall werden folgende Fragestellungen untersucht e Welche Fehler ursachen k nnen auftreten e Welche Folgen haben diese Fehler e Wie k nn
113. n zu nennen Man spricht hierbei von einem Design Space bzw von Design Space Exploration gt 1 4 Peripherie Analog Digital Wandler Ein Analog Digital Wandler Analog Digital Converter ADC kurz A D Wand ler erzeugt aus einem wert und zeit Janalogen Signal digitale Signale Die Um setzung ist ein vergleichsweise komplexer Prozess der in Bild 1 4 dargestellt ist Hierbei handelt es sich nicht um eine Codierung und der Prozess ist nicht exakt reversibel Der technisch eingeschlagene Weg besteht aus der Abtastung zuerst Bauteil Sample amp Hold bzw Track amp Hold Schaltung gefolgt von einer Quantisierung und der Codierung Die Abtastung ergibt die Zeitdiskretisierung die Quantisierung die Wertediskretisierung Man beachte dass mit technischen Mitteln sowohl die Abtastfrequenz als auch die Aufl sung zwar beliebig verbessert werden kann aber niemals kontinuierliche Werte erreicht werden In eingebetteten Systemen werden diese Werte den Erfordernissen der Applikation angepasst F r die Umsetzung von analogen Werten in digiatle Werte sind verschiedene Ver fahren bekannt Flash Half Flash Semi Flash Sukzessive Approximation Sigma Delta Wandler usw 1 Einf hrung in eingebettete Systeme 9 wert und zeitkontinuierlich s t analog gt i a Sa Quantisierung Abtastung 4 s t wertdiskret und zeitkontinuierlich a s t wertkontinuierlich und zeitdiskret
114. nd e Shortest Job First Shortest Processing Time Dies erfordert die Kenntnis der anstehenden Rechenzeiten der Scheduler w hlt dann die Kurzl ufe zuerst aus e Terminabh ngige Zuteilung Die n chste auszuf hrende Task wird durch das Kriterium Earliest Deadline First Antwortzeitpunkt am n chsten bestimmt 6 Betriebssysteme als virtuelle Maschinen 93 Statische Priorit ts bestimmte Ans tze Die Analyse ob das System berhaupt ablauff hig ist wird statisch durchgef hrt Es wird daraus allerdings keine Tabelle generiert nach der verfahren wird sondern es werden Priorit ten vergeben und zur Laufzeit wird die jeweils h chste Priorit t ausgef hrt Durch diesen Ansatz wird nicht mehr eine exakte Reihenfolge festgelegt sondern es werden Priorit ten fest vergeben bei Rate Monotonic oder dynamisch be stimmt In jedem Fall bleibt die Anzahl der Tasks zur Laufzeit konstant Beispiele hierf r sind e Shortest Job First Shortest Processing Time Wie bereits im Fall der Tabel lensteuerung kann dieses Verfahren zur statischen Priorit tszuteilung genutzt werden insbesondere bei periodischen Tasks Im Rate Monotonic Algorithmus wird bestimmt ob ein solches System berhaupt arbeiten kann Gilt hier yo lt n 2 1 6 1 El i im z 1 a 62 n so kann das System garantiert gescheduled werden C ist dabei die Ausf h rungszeit T die Periode der Task i und einer k rzeren Periode wird eine h he re P
115. nergiesparender Form 39 3 3 3 Einrichtung von Warte und Stoppzust nden oder Optimierung der Betriebsfrequenz hnsenngssntsse ns nE eea NETE S 39 3 3 4 Neue Ans tze zur Mikroprozessor Architektur Clock Domains und GALS Architektub s a a nrin ae ebene ES 41 3 4 Modellierungs und Programmiersprachen zur Einbeziehung der Randbedingungen cr cuss0s000000s0nn00nsennsonssonsonssonsssssnnsnnnsnsennsnnnsnnssonsonssnnne 42 3 4 1 Der Begriff Modellierungssprache ursrsesnnennesnesnnennenneenennn 42 3 4 2 UML Unified Modelling Language uursssnesnnennesnesnnennenseenennn 44 3 4 3 Syse MC reer she A E EEE nit gestern 46 3 5 Esterel als Beispiel f r eine synchrone imperative Sprache een 47 3 5 1 L sungsans tze zur Modellierung der Zeitspanne zwischen Ein und Ausgaben ana as A E EES E EE EEE EEE KE KEES 48 3 5 2 Determinismus u 8 2 5128er a 49 3 5 3 Eigenschaften von Estere 2 200220200020nsnesnennnennennennnennnnnnenennn 49 3 5 4 Kausalit tsprobleme 22 22402442000200nsenensnnsnennnennenesnnennnnnn ern 50 4 Softwarequalit t ssssssussssnssnnnnannnsnesiennnnnannnnnnnnn 52 4 1 Beispiele Begriffe und Definitionen essessssssssnssonssossonssossonensnsnnennnene 52 4 1 1 Herausragende Beispiele 22022002202000nnennnesnennnennennennnennnnnnenennn 52 4 1 2 Grundlegende Begriffe und Definitionen rsensesses
116. ng Skript V1 00 verschiedene L sungen f r ein Problem erarbeitet und miteinander verglichen werden Genau dies wurde in der Studie unternommen und zwar f r kommunika tionsorientierte Algorithmen Bild 1 6 zeigt das wesentliche Ergebnis dieser Studie die als Implementierungs basis General Purpose Prozessoren Digitale Signalprozessoren DSP Applika tions spezifische Instruktionssatz Prozessoren ASIP Field Programmable Gate Arrays FPGA als spezifische Klasse der PLDs Applikations spezifische Inte grierte Schaltungen ASIC und Fully Customized Integrated Circuits also voll kundenspezifische Schaltungen nimmt Die Kosten die hier als Produkt von Silizi umfl che Verlustleistung und Ausf hrungszeit genommen werden variieren ber einen Bereich von 8 Zehnerpotenzen bei den Werten zur Flexibilit t gemessen am Zeitverbrauch f r eine nderung immerhin noch um 3 Zehnerpotenzen Dies sagt aus dass die Implementierung die daraus resultierenden Nebenwirkun gen in drastischem Ma beeinflusst Bei programmierbaren Architekturen ergeben sich immerhin noch 4 Zehnerpotenzen Leider muss man deutlich sagen dass sich die Entwicklung f r FPGAs deutlich von der f r Mikrocontroller unterscheidet typische Programmiersprache VHDL versus C Programmiermodell parallel ver sus sequentiell Die Studie ist damit wertvoll aber sie entbindet noch nicht von der Last der unterschiedlichen Programmentwicklung 2 Echtzeitsysteme Dieses K
117. ngem Jitter Dies wird durch spezielle Verteilung erreicht ber eine Zeittabellen gesteuerte Nachrich tensendung erh lt jeder Knoten eine garantierte Sendem glichkeit au erdem k nnen alle anderen Knoten die Betriebsf higkeit des sendenden erkennen und vor allem auch den Ausfall e Byte Flight Das Byte Flight Protokoll ben tigt einen ausgezeichneten Sender der ber ein Zeitsignal eine gemeinsame Zeit verteilt Diese gemeinsame Zeit basis Jitter 100 ns veranlasst die anderen Knoten nacheinander Pakete zu senden oder ruhig zu bleiben Dadurch wird es m glich f r eine begrenzte Anzahl von Sendungen einen exklusiven Zugriff zu gestatten Der Rest in einem Zeitschlitz wird nach dem CSMA CA Verfahren verteilt sodass der Bus optimal ausgenutzt wird und zugleich f r eine begrenzte Anzahl von Daten echtzeitf hig ist 5 4 3 Verteilung der Zeit in verteilten Systemen Letztendlich steht und f llt die Echtzeitf higkeit in Time Triggered Kommunika tionssystemen mit der Verteilung einer gemeinsamen Zeit Hier wurde bei IEEE ein pr zises Zeitprotokoll definiert Precision Time Protocol IEEE 1588 17 22 mit dessen Hilfe diese Verteilung erfolgen Kann Die Verteilung erfolgt so dass eine Clock in dem zu betrachtenden Netzwerk als Master bezeichnet wird Diese Uhr soll m glichst genau sein ggf Anschluss an exakte Zeitgeber haben usw Der Master sendet nun eine spezielle Meldung als 86 Embedded Systems Engineering Skri
118. nit ten sp ter auskommentiert werden kann Regel 6 Alle Datenobjekten m ssen im kleinstm glichen G ltigkeitsbereich deklariert wer den Dies ist das Prinzip des Versteckens der Daten um keine nderung aus anderen Bereichen zu erm glichen Es dient sowohl zur Laufzeit als auch zur Testzeit dazu den Code m glichst einfach und verst ndlich zu halten Regel 7 Jede aufrufende Funktion muss den R ckgabewert einer aufgerufenen Funktion checken falls dieser vorhanden ist und jede aufgerufene Funktion muss alle Aufrufparameter auf ihren G ltigkeitsbereich testen Diese Regel geh rt wahrscheinlich zu den am meisten verletzten Regeln aber der Test z B darauf ob die aufgerufene Funktion erfolgreich war oder nicht ist mit Sicherheit sinnvoll Sollte es dennoch sinnvoll erscheinen den R ckgabewert als irrelevant zu betrachten dann muss dies kommentiert werden Regel 8 Die Nutzung des Pr prozessors muss auf die Inkludierung der Headerfiles sowie einfache Makrodefinitionen beschr nkt werden Komplexe Definitionen wie vari able Argumentlisten rekursive Makrodefinitionen usw sind verboten Bedingte Compilierung soll auf ein Minimum beschr nkt sein Der Pr prozessor kann leider so genutzt werden dass er sehr zur Verwirrung von Softwareentwicklung und Codechecker beitragen kann daher die Begrenzung Die Anzahl der Versionen die man mittels bedingter Compilierung und entsprechend vielen Compilerswitches e
119. nszeit enthalten Jeder h herpriorisierte IRQ 0 h chste Priorit t kann niedrigere ISR unterbrechen das Hauptprogramm ist jederzeit unterbrechbar Es werden 4 Zust nde des Prozesses angenommen Priorit t 0 ben tigt 100 Takte zur Bearbeitung Priorit t 1 200 Priorit t 2 300 und Priorit t 3 400 Takte alles Maximalwerte F r das Zeit gesteuerte System sollen diese Zust nde nacheinander abgefragt und bearbeitet werden wobei die Abfrage 10 Takte beanspruchen soll F r die H ufigkeit der IRQs wird angenommen dass sie alle mit maximaler Frequenz von 10 kHz auftreten k nnen Zur Simulation wird eine Variation angenommen also beim ersten Mal nach 100 us beim zweiten Mal nach 200 us dann nach 300 us wieder nach 10 us usw Als maximal zul ssige Reaktionszeiten werden f r Priorit t 0 20 us f r 1 50 us und f r die anderen 100 us angenommen F r das Verh ltnis von ISR und Hauptroutinenrechenzeit wird ca 1 1 angenom men d h der Zyklus soll auf 2000 Takte ausgelegt werden F r das Haupt programm wird gefordert dass im zeitlichen Mittel ca 2 10 Instruktionen pro Sekunde ausf hrbar sind F r dieses Modell ergeben sich dann folgende in Tabelle 5 2 wiedergegebene Sch tzungen Die darin vorhandenen Ergebnisse k nnen so zusammengefasst werden Das Verh ltnis der Taktanzahlen die dem Hauptprogramm zur Verf gung ste hen ist nahezu konstant d h der Overhead f r die Zeitsteuerung ist vergleichs weise gerin
120. ntwort aufnehmen Beispiel Ultraschall Sensoren zur Entfernungsmessung unterschieden werden Als Smart Sensors bezeichnete Sensoren beinhalten bereits eine Vorverarbeitung der Daten Peripherie Aktuatoren Aktuatoren bzw Aktoren verbinden den informationsverarbeitenden Teil eines ein gebetteten Systems und den Prozess Sie wandeln Energie z B in mechanischen Arbeit um Die Ansteuerung der Aktuatoren kann analog Beispiel Elektromotor oder auch digital Beispiel Schrittmotor erfolgen 1 3 Die Rolle der Zeit und weitere Randbedingun gen 1 3 1 Verschiedene Auspr gungen der Zeit In den vorangegangenen Abschnitten wurde bereits verdeutlicht Die Zeit spielt bei den bin rwertigen digitalen und den analogen Systemen Umgebungsprozess eine Rolle die genauer betrachtet werden muss Wir unterscheiden folgende Zeitsyste me Definition 1 10 In Zeit analogen Systemen ist die Zeit komplett kontinuierlich d h jeder Zwi schenwert zwischen zwei Zeitpunkten kann angenommen werden und ist Werte relevant Als Folge hiervon muss jede Funktion f t f r alle Werte r o bzw f r endliche Intervalle mit 7 to t definiert werden Zeit analoge Systeme sind fast 1 Einf hrung in eingebettete Systeme 11 immer mit Werte Analogie gekoppelt Zusammengefasst wird dies als analoge Welt bezeichnet Zeit analog Werte analog Umgebungsprozess Au enwelt Tie
121. nzeit nicht berschrei ten F r die Latenzzeiten gelten die gesonderten oben beschriebenen Bedingungen 5 2 Komplett statischer Ansatz durch Mischung der Tasks Ein in 16 dargestellter Ansatz verzichtet sowohl auf ein Scheduling durch ein Betriebssystem Kapitel 6 als auch auf die Einbindung von Interrupt Service Routinen Kurz gesagt besteht die Methode darin den zeitkritischen Teil derart mit dem unkritischeren Teil zu mischen dass sich zur bersetzungszeit berechnet ein richtiges Zeitgef ge in der Applikation einstellt Die Idee wird als Software Thread Integration STD bezeichnet und ist nat rlich bestechend einfach Prinzipiell kann jeder Softwareentwickler dies durchf hren in dem nach sorgf ltiger Analyse die Sourcecodes der einzelnen Threads gemischt werden Das Problem ist dass zugleich ein zyklusgenaues Ausf hren des Programms gefor dert wird wenn harte Echtzeitbedingungen einzuhalten sind Zyklusgenauigkeit ist aber derzeit nur unter mehreren Bedingungen erreichbar e Die Anzahl der Ausf hrungstakte im Mikrocontroller muss zur bersetzungs zeit bestimmbar sein Hiermit scheiden bisherige Cache Konzepte aus denn sie erm glichen nur statistische nicht deterministische Aussagen e Alternativpfade if else m ssen die gleiche Anzahl an Taktschritten aufwei sen e Die Bestimmung der Anzahl der Ausf hrungstakte WCET muss in der Pro grammiersprache m glich sein Der erste
122. o untere Grenze cmp r0 rl Grenzen werden verglichen bgt T1 berschreitung spezielle Routine cmp r0 r2 bge T2 Keine Unterschreitung dann Sprung TI call OUT_OF_RANGE T2 pop r2 pop rl pop m reti Beenden der Serviceroutine Bild 5 5 b Assembler bersetzung Wiederholungsfrequenz gt 1 100 1 1000 Prozessorfrequenz Geforderter Jitter Abweichung des Starts der Reaktionsroutine lt 10 1000 Instruktionszeiten Bearbeitungszeit einer ISR gt 10 Gesamtbearbeitungszeit Die angegebenen Grenzen sind unscharf sie sollen lediglich zeigen dass man bei keinem noch so gut ausgelegten Prozessor basierten System beliebig kleine und scharfe Reaktionszeiten erwarten kann F r diesen Fall bietet sich eine Partitionie rung des Systems an die besonders kritischen Teile k nnen in exklusiver Hard ware untergebracht werden Aktuell sind hierf r Kombinationen aus Prozessor und PLD am Markt erh ltlich Beide sind programmierbar wenn auch auf vollkommen verschiedene Weisen so dass der Entwickler in das Gebiet des Co Designs ger t Wie Bild 5 6 zeigt wird in 80 Embedded Systems Engineering Skript V1 00 dem Beispiel die Abfrage des AD Wandlers sowie der Vergleich mit den Grenzen in dem PLD Teil implementiert der damit das komplette Interface zum ADC ent h lt Der Mikrocontroller wird lediglich dann unterbrochen wenn die Grenzwert verletzung auftritt und somit eine echte Behandlung notwendig ist
123. pt V1 00 Broadcast aus die Sync Message Diese Meldung enth lt einen Zeitstempel insbe sondere eine Sch tzung wann sie auf dem Netzwerk sein wird Falls hohe Pr zision gefordert und m glich ist wird die Sync Message von einer zweiten Meldung der Follow Up Message Diese enth lt dann die tats chlich gemessene Zeit der bertragung also des physikalischen Zugriffs auf das Medium Netzwerk Misst nun der Slave die Empfangszeit mit entsprechender Pr zision kann er die interne Uhr auf den Master abstimmen mit der Ausnahme dass die bertragungszeit nicht ber cksichtigt wurde Diese bertragungszeit kann ebenfalls bestimmt werden Die Slaves die diese Sendung empfangen haben m ssen nun mit allerdings geringerer H ufigkeit diese Prozedur wiederholen indem sie wieder eine Sync Message und ggf eine Follow Up Message senden nun nur an den Master adressiert Hierin wird die ber tragungszeit der Master Slave Abstimmung ebenfalls bermittelt und nun stehen beide Messungen hin und R ckweg zur Verf gung Unter der Annahme dass die bertragung eine symmetrische Latenzzeit aufweist kann nun also auch diese Zeit bestimmt werden Die Synchronisation reicht hierdurch bis in den Sub Mikrosekundenbereich zur ck allerdings m ssen Router aufgrund ihrer langen Verz gerung ausgeschlossen werden hierzu bietet IEEE 1588 ebenfalls Methoden an 6 Betriebssysteme als virtuelle Maschinen Bei der Einf hrung der ersten Comput
124. r 220ueeeeennee 58 69 Codierungsregeln 0 66 Common Causation Failure 65 Compile Time Siehe bersetzungszeit Computersystem neeenenennen 2 interakiV nannte 2 Klassifizierung 2 reak v nennen 2 transformationell 2 constraints Siehe Randbedingungen cyclomatic complexity 61 63 D DAC Siehe Digital Analog Wandler Dead Line Siehe Frist deadlock Siehe Verklemmung Design Pattern 41 70 Ereignis gesteuerte Task 70 Hardware Software Co Design 77 Klassifizierung der Teilaufgaben ERS E E A 70 Leistungseffizienz 37 Software Thread Integration 75 streng zyklisch laufende Tasks 70 Verlustleistung 36 Design Space Exploration 7 12 22 Designraum ceeee 22 81 Rechenzeit 23 24 Siliziumfl che 23 Verlustleistung 24 Determinismus ueeeeen 48 Deterministic Finite Automaton Siehe DFA deterministisches Verhalten 3 DEPA ra R A 3 Digital Analog Wandler 8 diskret u 2 2 32 2a 4 Sachwortverzeichnis 101 diversit re Redundanz 66 Ereignis gesteuertes System 30 modifiziertes en 32 E modifiziertes mit BEL 14 ls Echt
125. reads Prozessen hei t verklemmt wenn jeder Thread Prozess dieser Menge auf ein Ereignis im Zustand blockiert wartet das nur durch einen anderen Thread Prozess dieser Menge ausgel st werden kann Dies ist im einfachsten Fall mit zwei Threads Prozessen m glich Jeder Thread wartet blockierend auf ein Ereignis des anderen Im Fall der Prozess oder Threadkommunikation kann dies gel st werden indem nicht blockierend kommuniziert wird Die Threads Prozesse senden einander Meldungen und Daten zu warten aber nicht darauf dass der andere sie auch ab holt Am Beispiel in Kapitel 5 wird gezeigt dass dies auch notwendig f r die Echt zeitf higkeit ist allerdings sollte nicht bersehen werden dass hierdurch Daten auch verloren gehen k nnen 2 2 3 Grundlegende Modelle f r die Nebenl ufigkeit Bez glich der Zeit f r das Aufbauen der Kommunikation zwischen zwei Prozessen Threads gibt es drei Grundannahmen Asynchron perfekt synchron mit Null Zeit und synchron mit konstanter Zeit Asynchrone Kommunikation bedeutet in diesem Fall dass die Kommunikationspartner sozusagen zuf llig in Kontakt treten wie Molek le in einem Gas und dann wechselwirken Dieses Modell als che misches Modell bezeichnet ist daher nichtdeterministisch und f r eingebettete Systeme unbrauchbar Anmerkung Spricht man im Zusammenhang von Network on Chip NoC von asynchroner Kommunikation so ist damit selbst synchronisierende Kommuni kation
126. rechbaren Zwischenr ume bestimmt werden Diese Zeiten k nnen mit WCIDT Worst Case Interrupt Disable Time bezeichnet werden und sollten auf das absolute Minimum beschr nkt sein z B auf atomare Aktionen zur Kommunikation Die Bestimmung hierzu muss am endg ltigen Maschinencode erfolgen um eingebundene Laufzeitroutinen zu erfassen Timer ISR und Event ISR stehen in Konkurrenzbeziehung was die Zuteilung der Rechenzeit betrifft Grunds tzlich sollte der strengen Zeitbindung der Vor rang gegeben werden und die Routinen hierf r sind auch Kandidaten f r eine Ununterbrechbarkeit Dies allerdings bedeutet die Erh hung der Latenzzeit f r die Event ISR was f r den Einzelfall zu pr fen ist Eine Ausnahme bildet der Fall dass die Event ISR sehr hoch priorisiert werden muss weil bei Auftreten ein sicherer Zustand zu erreichen ist Dieses Ereignis 76 Embedded Systems Engineering Skript V1 00 muss sofort behandelt werden so dass die Timer ISR in diesem Fall unter brechbar sein sollte Nach dem Zusammenf gen der einzelnen Teile und der Abstimmung der zeitlichen Randbedingungen kann dann die korrekte Funktionsweise des gesamten Systems nachgewiesen werden Hierzu wird ein Zeitraum betrachtet in dem ein gesamter Zyklus ablaufen kann Insbesondere muss die generelle Task die Berechnung been den k nnen In diesem Zeitabschnitt darf die Summe der WCETSs multipliziert mit den entsprechenden Auftrittsh ufigkeiten die Gesamtreche
127. rgangs zur ckgestellt wird Dies muss zwangsl ufig in jeder Kombination m g lich sein da nichts vorbestimmbar ist Ein anderer Weg ist ggf einfacher zu implementieren Alle Teilaufgaben die zyk lisch auftreten werden in einer einzigen ISR die von einem zyklisch arbeitenden Timer aufgerufen wird zusammengefasst Die Probleme die dabei auftreten lie gen weniger im grunds tzlichen Design als vielmehr darin mit welcher Frequenz bzw mit welchem Zeitwert die ISR aufgerufen wird W hrend bei einer einzigen Aufgabe mit streng zyklischem Verhalten die Wahl einfach ist die Zeitkonstante die zwischen zwei Messungen oder zwei Trans missionen liegt wird als der Timerwert gew hlt muss nunmehr der gr te gemeinsamen Teiler ggT der Periodenzeiten als Zeitwert gew hlt werden Die ggT Methode Bild 3 3 ist so vorteilhaft weil zu Beginn einer Timer ISR bes timmt werden kann was alles und auch in welcher Reihenfolge behandelt werden soll Hierdurch lassen sich auch Zeitverschiebungen planen bzw bestimmen 30 Embedded Systems Engineering Skript V1 00 Andererseits kann der ggT Ansatz sehr schnell in ein nicht lauff higes System m nden Die Anzahl der ISR pro Zeiteinheit kann stark zunehmen gt Bild 3 3 und jeder Aufruf einer ISR erfordert einen zeitlichen Overhead auch wenn keine weitere Routine darin abl uft Als Faustregel sollte man mit mindestens 10 20 Befehlsausf hrungszeiten rechnen die f r Interrupt La
128. riorit t zugeordnet Die Grenze konvergiert f r gro e n nach In 2 0 69 und stellt eine g ltige aber meist pessimistische Grenze dar Es gilt die Grenze 1 wenn die Perioden ganzzahlig zur kleinsten Periode sind e Terminabh ngige Zuteilung Die Priorit ten und damit die n chste auszuf hrende Task werden durch das Kriterium Earliest Deadline First Antwortzeitpunkt am n chsten oder Least Laxity First Differenz zum sp ttestm glichen Startzeitpunkt bestimmt Dynamisches Plan basiertes Scheduling Um ein dynamisches Scheduling zu erm glichen das auch die Hinzunahme neuer Tasks gestattet m ssen diese neuen Tasks mit Informationen ber ihren Rechen zeitbedarf sowie die erwarteten Antwortzeiten ausgestattet sein Der Scheduler berpr ft dann bei Start der neuen Tasks ob und wie er diese einbauen kann Wird sie garantiert dann darf sie auch weiterlaufen Bei Multiprozessorsystemen kann die Task im Negativfall auch an andere Prozessoren weitergegeben werden Dynamisches bestm gliches Scheduling Diese Form des Scheduling wird in den meisten dynamischen Echtzeitbetriebs systemen verwendet obwohl dieses Verfahren keine Echtzeitf higkeit garantiert 94 Embedded Systems Engineering Skript V1 00 Eine neu hinzukommende Task wird also eingebaut und es wird versucht Wechselwirkungen zu den anderen Tasks m glichst zu vermeiden Man kann sich sicherlich vorstellen wie dies im Fall eines Overload aussehen wird Da in diese
129. roller 34 Embedded Systems Engineering Skript V1 00 Der Schl ssel hierzu liegt in einer Variation der Hardware zur bermittlung und Verwaltung der Interrupt Requests Mit Hilfe eines spezifisch konfigurierten Ti mers pro Interrupt Request Kanal im IRQ Controller kann jeglicher Interrupt nach Auftreten f r eine bestimmte Zeit unterdr ckt werden Bild 3 5 zeigt das Block schaltbild des hypothetischen IRQ Controllers Die vorgesehene Wirkungsweise des Timers ist diejenige dass weitere IRQ Signale die vor dem Start der ISR auftreten weder ber cksichtigt noch gespeichert werden w hrend Signale die nach dem Start der ISR aber vor dem Ablauf des Timers eintreffen gespeichert werden jedoch vorerst keine Aktion hervorrufen Diese etwas aufwendige Definition dient dazu ein Maximum an Systemintegration zu erreichen Die Unterdr ckung aller weiteren IRQ Signale bis zum Eintritt in die ISR ent spricht dabei der g ngigen Praxis mehrfache IRQs nur einmalig zu z hlen Die aktionslose Speicherung nach dem Eintritt l sst dabei keinen IRQ verloren gehen und nach dem Timerablauf wird der gespeicherte IRQ aktiv und startet den Timer sofort neu Diese Funktionsweise zwingt die asynchronen Interrupt Requests in ein Zeit schema f r das das Rechnersystem ausgelegt wird Sind alle IRQs mit diesem Verfahren der Beschr nkung der Wiederholungsfrequenz ausgestattet k nnen f r alle Teile des Systems die maximalen Bearbeitungszeiten berechn
130. rufen Dies reicht im Allgemeinen jedoch nicht mehr f r Multiprocessing f hige Systeme aus denn in diesem Fall ben tigt das Betriebssystem selbst Rechenzeit und eine entsprechende Architektur Die einfachste Architektur ist monolithisch aufgebaut Bild 6 3a Diese Architek tur d rfte zwar die schnellste Variante sein andere Forderungen wie Wartbarkeit Modularisierung und Flexibilit t sind so jedoch kaum zu erf llen Ein ebenfalls klassischer Aufbau ist der eines Schichtenmodells bei dem exakt definierte Funk tionen sowie Interfaces pro Schicht vorhanden sind Dieses Modell Bild 6 3b ist vergleichbar mit dem ISO OSI Layermodell f r Netzwerke und hier wie dort offenbaren sich Nachteile die sich in Rechenzeitbedarf oder Durchgriff durch die Schichten quasi Konsistenz Treppenschichtenmodell zeigen 3 Schicht 2 Schicht 1 Schicht b Betriebssystem Hardware Betriebssystem Schale Ca gt Betriebssystem Mikrokern d Betriebssystem Kern Hardware Bild 6 3 Betriebssystemarchitekturen a monolithischer Aufbau b Schichtenmodell c Kern Schalen Modell d Mikrokern Modell 90 Embedded Systems Engineering Skript V1 00 Modern sind Architekturen nach Bild 6 3c und 6 3d Im Betriebssystemkern kernel sind alle wichtigen Funktionen oftmals im privilegierten Prozessormodus ablaufend vereint erg nzende Funktionen insbesondere ein API bietet die Schale shell an Die Schale ist damit prinzipiell austausch
131. rzeugen kann w chst exponentiell Bei 10 Compilerswitches erh lt man bereits 2 1024 verschiedene Versionen die alle getestet werden m ssen Regel 9 Die Nutzung von Pointer muss auf ein Minimum begrenzt sein Grunds tzlich ist nur ein Level von Dereferenzierung zul ssig Pointer d rfen nicht durch Makros oder typedef verschleiert werden Pointer zu Funktionen sind verboten Die Einschr nkung bei Zeigern d rfte allgemein verst ndlich sein insbesondere aber soll die Arbeit von Codecheckern nicht behindert werden 70 Embedded Systems Engineering Skript V1 00 Regel 10 Der gesamte Code muss vom ersten Tag an so compiliert werden dass die h chste Warnstufe mit allen Warnungen zugelassen eingeschaltet ist Der Code muss ohne Warnungen compilieren Der Code muss t glich gecheckt werden m glichst mit mehr als einem Codeanalysator und dies mit 0 Warnungen Diese Regel sollte peinlichst beachtet werden denn Warnungen bedeuten immer etwas Sollte die Warnung als verkehrt identifiziert werden muss der Code umge schrieben werden denn dies kann auch bedeuten dass der Codechecker den Teil nicht versteht Als Tipp f r einen Codechecker Lint bzw splint Secure Programming Lint 24 ber die Funktionalit t dieser Programme wurde in Kapitel 4 2 bereits berichtet 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontroller 5 1 Dynamischer Ansatz zum Multitasking Die in Kapitel 3 diskutierten Ver
132. schen Timer IRQ wird der AD Wandler auf einen neuen Wert abgefragt und dieser neue Wert wird mit gegebenen Grenzen verglichen Bleibt der Wert in den Grenzen passiert nichts ansonsten wird die out_of_range Routine aufgerufen Bild 5 5 b zeigt nun die Assembler bersetzung dieser Routine f r einen hypo thetischen Prozessor In dem Fall dass kein Grenzwert verletzt wird ben tigt die Routine 14 Instruktionen bei 1 Instruktion Takt RISC Verh ltnis also 14 Takte oder 140 ns bei 100 MHz Dies erscheint als nicht besonders viel aber bei einer AD Wandlungsrate von 1 MSPS Mega Samples per Second sind das 14 der gesamten Rechenkapazit t des Prozessors Hieraus l sst sich schon ein ungef hres Ma daf r ableiten wann die Behandlung von Ereignissen in nicht exklusiver Hardware schwierig bis unm glich wird Folgende Kriterien k nnen angegeben werden 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontrollern 79 int p_adc adc_value upper_limit lower_limit void interrupt read_and_compare_ADC adc_value p_adc Access to AD converter if adc_value gt upper_limit adc_value lt lower_limit out_of_range call to exception routine Bild 5 5 a C Sourcecode f r ISR zur AD Konvertierung mit Grenzwertvergleich TIMER push rO 5 push rl push r2 mov r0 ADC Lesen des AD Werts zugleich Neustart der Wandlung mov rl UP_LIMIT Speicherstelle f r oberes Limit mov r2 DN_LIMIT dit
133. scher programmierbarer elektronischer Systeme Oktober 2005 Diese beiden sind eng aufeinander bezo gen und verweisen gegenseitig Tabelle 4 1 zeigt die so genannten Performance Level PL bzw Security Integrity Level SIL die in den jeweiligen Normen definiert werden Tabelle 4 1 Vergleich PL und SIL PDF Probability of dangerous failures per hour auch PFH abgek rzt Interessant ist dabei die Sicht auf elektronische bzw programmierbare elektroni sche Systeme Programmierbare Hardware gilt dabei als Hardware Wenn man nun ein sicheres System aufbauen will m ssen zus tzlich zu allen anderen Fehlern auch die Common Causation Failure CCF also die Fehler gleichen Ursprungs beachtet werden Normalerweise reicht eine einfache Redundanz also die Verdopplung der Hard ware mit einer Entscheidungsinstanz aus wenn es einen sicheren Zustand gibt Hiermit ist gemeint dass dieser sichere Zustand angenommen wird wenn eine Hardware berwachung eine entsprechende Situation detektiert Die CCF ent stehen nun durch Bausteinfehler die gemeinsam in beiden Bausteinen sind Die 4 Softwarequalit t 67 Maschinensicherheit fordert daher bei sicherheitskritischen Applikationen eine diversit re Redundanz d h zwei verschiedene Bausteine mit zwei verschiedenen Konfigurationen falls es sich um programmierbare Hardware handelt Die Software in derartigen Systemen muss entweder redundant diversit r aufgebaut sein dies bedeutet
134. schine Feh ler in der Software dieser Systeme k nnen also zu Sch digungen der Maschine und von Menschen f hren Dies allein ist sicher Motivation genug in die Software qualit t zu investieren Dies ist eine hehre Aufgabenstellung die schnell formuliert und schwierig umzu setzen ist Zun chst werden Begriffe erl utert und Definitionen gegeben Speziell auf das Thema Zuverl ssigkeit zugeschnitten ist der n chste Abschnitt gefolgt von einem Kapitel zum anderen Blickwinkel Die Sicht der Maschine bzw Maschi nenbauer Den Abschluss bildet ein Vorschlag f r Codierungsregeln in Projekten mit sicherheitskritischer Software 4 1 Beispiele Begriffe und Definitionen 4 1 1 Herausragende Beispiele Leider gibt es einige herausragende sehr bekannte Beispiele daf r dass ein Soft ware basiertes System nicht ordnungsgem funktioniert hat Hierzu z hlen die Bruchlandung eines Airbus A 320 auf dem Warschauer Flughafen am 14 09 1993 und der Absturz der Ariane 5 am 04 06 1996 in Kourou Franz sisch Guayana Beim Beispiel der Bruchlandung des Airbus A 320 war die Ursache eine fehler hafte Bodenber hrungserkennung im Flugzeug Bedingt durch pl tzlich auftreten den starken Seitenwind setzte der Airbus mit nur einem Rad auf dem Boden auf die Software erkannte dies nicht als Bodenkontakt an und schaltete nicht aus dem Flight Mode heraus Die Piloten konnten somit keine Schubumkehr einschalten das Flugzeug kam nur wenig gebremst von der
135. shold spannungen was wiederum zu drastisch steigenden statischen Verlustleistungen f hrt Die Herleitung insbesondere der Teil nachdem 3 5 den einzigen nennenswerten Beitrag zur Verlust leistung liefert gilt dann zuk nftig nicht mehr Es kann sogar so sein dass die statische Verlustleistung berwiegt 3 Design von eingebetteten Systemen 27 P T 4 Power Dissipation P conSs Design Point for Server Workstations Area A A T const2 Design Point for Time T Embedded System Bild 3 2 Zusammenhang zwischen P Tund A 3 2 Ans tze zur Erf llung der zeitlichen Randbedingungen Die im vorangegangenen Abschnitt angegebenen Formeln helfen nur bedingt denn sie zeigen welcher Gewinn m glich ist aber nicht wie dieser im Design zu er halten ist Zudem ist die Rolle der Zeit in den Formeln diejenige der Rechenzeit also mit der Performance in Zusammenhang stehend Gerade in eingebetteten Systemen ist der entscheidende Zeitbegriff aber derjenige der Reaktionszeit der mit dem deterministischen Echtzeitverhalten des Systems korreliert Hier geht es nicht um Einsparungspotenzial sondern um die Erf llung der zeitlichen Randbedingungen Um dies zu erreichen bieten sich Design Pat tern an die in den folgenden Abschnitten dargestellt werden sollen 3 2 1 Zeit gesteuerte Systeme Time triggered Systems Eine M glichkeit den realen Au enbezug im Sinne der Zeit zu schaffen besteht darin eine fe
136. smethodik dar mit der ein Systementwickler in der Lage ist synchrone Software zu entwickeln Gerade die Synchronit t der Software erm glicht eine Synchronisierung auf ex terne Ereignisse z B einen Takt Man beschreibt also einen Teil oft als Thread bezeichnet in Form von C oder C Funktionen Methoden und das Interface nach von au en ist synchronisiert Genau dies entspricht der Hardware Entwicklung In sich geschlossene kleine Teile asynchrone Hardware werden mit Hilfe von Registern Synchronisie rung nach au en sichtbar und k nnen so zu gro en Schaltungen zusammengebaut werden 3 Design von eingebetteten Systemen 47 Scheinbar hat dies nichts mit dem Problem der Einbindung von Randbedingungen wie der Zeit in ein Systemdesign zu tun Die Entwicklung von SystemC geht jedoch aktuell in die Richtung dass mit V 3 0 ein virtuelles Echtzeit Betriebssys tem integriert werden soll Damit ist zumindest denkbar dass Compiler entstehen die das zeitliche Gef ge eines Softwaresystems ebenfalls beherrschen Aktuell allerdings gilt dass man auch in SystemC nur ein simulierbares Zeitgef ge einbauen kann Dazu wird einfach angenommen dass einzelne Laufzeiten bekannt sind und aus SystemC heraus k nnen Trace bzw Timingdiagramme erzeugt wer den z B Value Change Dump VCD Diese Diagramme zeigen dann den zeitli chen Verlauf in der Simulation 3 5 Esterel als Beispiel f r eine synchrone imperative Sprache Bei dem Ti
137. snenseeseennennn 53 4 2 Zuverl ssigkeit sessssssonsenssnnsnonsnnssessonensssnsennsnnnsnnssnnsnnssnssonssnsssnsssnsnnesnnene 55 42 1 Konstruktive Ma nahmen 0 22442220000ssnnensnsnnennnennnnnsenn nennen 56 4 2 2 Analytische Ma nahmen ssseeeessseeessesreessreersreersresseresrerssresrenreseereseeees 57 4 2 3 Gefahrenaial ys siran iaee ain aeiee eet i eee ee ao o KE eno E Tea SaaS 57 4 2 4 Software Review und statische Codechecker unsneenenn 58 4 2 5 Testen allgemem 2 0 0 slens 59 4 2 6 Mo dultests 2 2 2184822 20 20 ete nissen 62 4 2 7 Integr tionstests u essheanlnnesi steige 63 4 2 8 SYStEMtests r e aa e aE E VEAS EE S SES R SR 65 4 3 Die andere Sicht Maschinensicherheit srsesssossnsrsnsnsonsnsonsnnnsnnsnsneen 66 4 4 Coding Ru les ecseisssiesiussnnssnessisss ins sn sse snese orseson soria Sr Essos s eSa 67 5 Design Pattern f r Echtzeitsysteme basierend auf Mikrocontroller aasaanannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 71 IV Inhaltsverzeichnis 5 1 Dynamischer Ansatz zum Multitasking sersessessnssnsossnnsorsossnennssesnnsnnne 71 5 1 1 Klassifizierung der Teilaufgaben u 2 202 sneennennenseennennn 71 5 1 2 L sungsans tze f r die verschiedenen Aufgabenklassen 73 5 2 Komplett statischer Ansatz durch Mischung der Tasks 76 5 3 Co Design Ansatz Partitionierung in PLD und Prozessoranteile
138. soren und Mikrocontrollern gibt 9 Bild 3 7 zeigt einige Mikroprozessoren im Vergleich 9 Hierzu wurden die erh lt lichen SpecInt2000 Werte pro eingesetzter elektrischer Leistung bezogen auf den ltesten und schlechtesten Sparc Il Prozessor dargestellt und zwar als SPEC W mit x 1 3 Die unterschiedliche Metrik war bereits in den Darstellungen aus Abschnitt 3 1 sichtbar Ist nun P T konstant oder P T Diese Unterschiede sind in der unterschiedlichen Mikroarchitektur begr ndet manchmal auch darin dass viel Kompatibilit t mitgeschleppt wird Bild 3 7 zeigt allerdings nur die H lfte der Wahrheit indem kommerzielle Mikroprozessor produkte miteinander verglichen werden 38 Embedded Systems Engineering Skript V1 00 Relative Power Efficiency E Specint W 25 E Specint W O Specint W A i Intel PIII AMD Athlon IBM Power3 Intel Celeron Sparc III Bild 3 7 Relative Leistungseffizienz im Vergleich In 8 werden zwei Produkte etwa gleichen Erscheinungsdatums miteinander verglichen Ein AMD Mobile K6 und ein Intel Xscale Mikrocontroller der von der ARM Advanced RISC Machine StrongARM Architektur abgeleitet wurde Der AMD Mobile K6 ben tigt bei 400 MHz eine elektrische Leistung von 12 W der Xscale bei 600 MHz nur 450 mW Nimmt man grob an dass beide etwa gleich schnell arbeiten aufgrund der Superskalarit t im AMD Pro
139. st die Berechnungszeit unabh ngig von der Breite der Eingangsw rter e Carry Look Ahead Adder Zwei Schaltnetze eines f r Carry ein folgendes f r die Addition Hier wird zwar die im Vergleich zum total parellelen Addierer doppelte Zeit ben tigt aber immer noch unabh ngig von der Datenbreite e Zwischenformen wie 4 2 Bit Paralleladdierer usw Bild 3 1 zeigt reale Werte f r einen 12 Bit Addierer Als Standardverz gerungszeit sind 10 ns pro Gatter angenommen zur Fl chenbestimmung wurde die Zahl der Terme Disjunktive Normalform DNF herangezogen 24 Embedded Systems Engineering Skript V1 00 Hieraus und aus anderen Schaltungen kann man zun chst empirisch schlie en dass es f r begrenzte Schaltungen ein Gesetz wie A T const technology mit k 1 2 3 1 gibt Dieses Gesetz ist zwischenzeitlich auch theoretisch best tigt worden Die Exponenten k tendieren f r arithmetische Operationen gegen 2 lasi 3e9 bei t 10 A T const 1 50 100 150 200 250 t Bild 3 1 AT Gesetz f r 12 Bit Addierer verschiedene Implementierungsvarianten Interpretation Es liegt hier eine Trade Off Funktion vor die verdeutlichen soll dass man je nach Randbedingungen ein applikationsspezifi sches Optimum finden kann Weiterhin k nnen einzelne Implementierungen von diesem Zu sammenhang signifikant abweichen Man kann daher die durch diese Funktion gezogene Grenze als Optimalit tskriterium heran ziehen so dass Pun
140. ste Zeitplanung einzuf hren Hierzu m ssen nat rlich alle Aufgaben bekannt sein 28 Embedded Systems Engineering Skript V1 00 Weiterhin m ssen folgende Voraussetzungen gelten e Die Verhaltensweisen des Embedded Systems und des Prozesses m ssen zur bersetzungszeit vollst ndig definierbar sein e Es muss m glich sein eine gemeinsame Zeit ber alle Teile des Systems zu besitzen Dies stellt f r ein konzentriertes System kein Problem dar bei verteilten miteinander vernetzten Systemen muss aber diesem Detail erh htes Augenmerk gew hrt werden e F r die einzelnen Teile des Systems also z B eine Task m ssen exakte Werte f r das Verhalten bekannt sein Exakt hei t in diesem Zusammenhang dass die Zeiten im Betrieb nicht berschritten werden d rfen Es handelt sich also um eine Worst Case Analyse die mit Hilfe von Profiling Simulation oder einer exakten Laufzeitanalyse erhalten werden Hieraus ergibt sich dann ein planbares Verhalten Man baut dazu ein statisches Scheduling Verteilung der Rechenzeit zur Compilezeit auf indem die Zyk luszeit Gesamtzeit in der aller Systemteile einmal angesprochen werden aus dem Prozess abgeleitet wird Die praktische Ausf hrung eines Zeit gesteuerten Systems kann dabei auf zwei Arten erfolgen Ausl sung durch Timer Interrupt und ein kooperativer System aufbau e Beim Aufbau mit Hilfe von Timer Interrupts wird ein zyklischer Interrupt De finition siehe Abschnitt 3 2 3
141. t ist etwas komplexer aktuell wird folgende N herung angenommen I const V V I 3 7 Die maximal m gliche Frequenz ergibt sich durch Einsetzen von 3 7 in 3 6 und Aufl sung nach fmax Hierbei kann eine weitere N herung f r den Fall angenommen werden dass V von Vn weit genug entfernt ist v Vn Ba faa Zeonst_1 const_2 V f r V V 2V 3 8 Diese Formel sagt also aus dass mit der Skalierung der Betriebsspannung V auch die maximale Betriebsfrequenz fmax skaliert Insgesamt gilt mit allen N herungen der quantitative Zusammenhang P T const 3 9 Interpretation Dieser Zusammenhang zeigt auf wie Verlustleistung und Rechen geschwindigkeit sich gegenseitig beeinflussen wenn Betriebs spannung und Frequenz ver ndert werden d rfen Der gewaltige Zuwachs der Verlustleistung bei verdoppelter Frequenz 8fache Verlustleistung ist sehr signifikant Bild 3 2 zeigt den Zusammenhang zwischen P A und T in qualitativer Form Es wird f r die Zukunft angenommen dass Server Architekturen optimiert auf Re chengeschwindigkeit Architekturen f r eingebettete Systeme jedoch mehr auf Ver lustleistungsminimierung und damit Fl chenminimierung ausgelegt sein werden Anmerkung Die Reduzierung der Strukturbreiten in den ICs haben aktuell Auswirkungen auf die Betriebsspannung und die Verlustleistung Durch die kleiner werdenden Strukturen muss die Betriebsspan nung gesenkt werden Dies f hrt auch zu sinkenden Thre
142. tel dieses Abschnitts empfiehlt sich gleich eine kurze Erl uterung der Begriffe imperativ und synchron Definition 3 2 Eine Programmiersprache wird als imperativ bezeichnet wenn ihre algorithmische Beschreibung auf der vollspezifizierten und vollst ndig kontrollierten Manipula tion benannter Daten in einer schrittweisen Art basiert Dies bedeutet dass in der Programmcodierung alle Daten als Variablen benannt und komplett kontrollierbar sind Dieses Paradigma entspricht am besten der menschlichen Denkweise Bekannte Vertreter f r das imperative Programmierparadigma sind C und ADA Dies bedeutet dass jede Datenmanipulation explizit beschrieben wird auch in ihrem Weg und die Datenzuweisungen sind sequenziell beides aus der C Welt bekannte Tatsachen mit allen Vor und Nachteilen Das perfekt synchrone Modell f r eine Sprache war bereits in Kapitel 2 erw hnt worden Definition 3 3 3 Eine Sprache wird als synchron bezeichnet wenn sie das perfekt synchrone Kom munikationsprinzip verwendet Hierbei handelt es sich um eine Hypothese dass Kommunikation keine Zeit verbraucht Das System arbeitet somit perfekt synchron zueinander Die Annahme keine Zeit zu verbrauchen ist in der Realit t nat rlich nicht einzu halten In Wahrheit ist dies die Annahme dass das System zur Verarbeitung weni ger Zeit ben tigt als die Zeitspanne zwischen zwei aufeinanderfolgenden Signalen die verarbeitet werden m ssen 3
143. tenzzeit Retten und Restau rieren von Registern und den R cksprung in das Programm ben tigt werden In einem System das 1 us Befehlsausf hrungszeit hat und alle 200 us unterbrochen wird sind das aber bereits 5 10 der gesamten Rechenzeit die unproduktiv vergehen Daher sollte soweit dies m glich ist die Periode so gew hlt sein dass der ISR Overhead klein bleibt lt 5 Timer ISR A Timer ISR B Timer ISR ggT Keine Aktion Task A und B Nur Task A Nur Task B Bild 3 3 Zusammenf gen mehrerer Zeit gesteuerter ISR zu einer Routine Im Idealfall besteht darin die Zykluszeiten gegenseitig anzupassen so dass der ggT gleich dem k rzesten Timerwert ist Dies f hrt zumindest zu einem System das keine ISR Aufrufe ohne Netto Aktion wie in Bild 3 3 dargestellt hat 3 2 3 Flexible L sung durch Programmierbare Logik Die Tatsache dass durch die Wahl des ggT aller Zykluszeiten als die einzige Zyk luszeit im Allgemeinen leere Unterbrechungen erzeugt werden l sst sich da durch umgehen dass man von der periodischen Erzeugung abgeht und nun eine be darfsgerechte Generierung einf hrt Dies ist durch die Belassung bei mehreren Timern und anschlie ende OR Verkn pfung der Unterbrechungssignale zu errei chen wie Bild 3 4 darstellt Damit w re dann ein effizientes Timingschema f r die Unterbrechungen erzeugt und die Unterbrechungsroutine w rde unterscheiden welche Aktionen durchzuf hren w
144. teraktiven Systems sind die Vermeidung von Verklemmungen deadlocks die Herstellung von Fairness und die Erzeu gung einer Konsistenz insbesondere bei verteilten Systemen Reaktive Systeme hingegen verlangen vom Computer dass dieser reagiert und zwar meistens recht zeitig Rechtzeitigkeit und Sicherheit sind die gr ten Belange dieser Systeme Zudem muss von interaktiven Systemen kein deterministisches Verhalten verlangt werden Diese k nnen intern die Entscheidung dar ber treffen wer wann bedient wird Selbst die Reaktion auf eine Sequenz von Anfragen muss nicht immer gleich sein Bei reaktiven Systemen ist hingegen der Verhaltensdeterminismus integraler 1 Einf hrung in eingebettete Systeme 3 Bestandteil Daher hier die Definition von Determinismus bzw eines deterministi schen Systems Definition 1 2 Ein System weist determiniertes oder deterministisches Verhalten Deterministic Behaviour auf wenn zu jedem Satz von inneren Zust nden und jedem Satz von Eingangsgr en genau ein Satz von Ausgangsgr en geh rt Als Gegenbegriffe k nnen stochastisch oder nicht deterministisch genannt werden Diese Definition bezieht sich ausschlie lich auf die logische algorithmische Ar beitsweise und das klassische Beispiel sind die endlichen Automaten DFA Deter ministic Finite Automaton Nicht deterministische Maschinen werden auf dieser Ebene in der Praxis nicht gebaut beim NFA Non Deterministic Finite Automaton
145. tmals eine Einheit Defnition 1 8 Wird Elektronik zur Steuerung und Regelung mechanischer Vorg nge r umlich eng mit den mechanischen Systembestandteilen verbunden so spricht man von ei nem mechatronischen System Der Forschungszweig der sich mit den Grundlagen und der Entwicklung mechatronische Systeme befasst hei t Mechatronik mecha tronics Mechatronik ist ein Kunstwort gebildet aus Mechanik und Elektronik In der Praxis geh rt allerdings eine erhebliche Informatik Komponente hinzu da nahezu alle mechatronischen Systeme auf Mikrocontrollern Software basieren 1 2 Aufbau und Komponenten eingebetteter Systeme W hrend der logische Aufbau eingebetteter Systeme oftmals sehr hnlich ist sie he unten h ngt die tats chliche Realisierung insbesondere der Hardware stark von den Gegebenheiten am Einsatzort ab Hier k nnen viele St rfaktoren herr schen zudem muss das eingebettete System Sorge daf r tragen nicht selbst zum St rfaktor zu werden Einige St rfaktoren sind W rme K lte Staub Feuchtigkeit Spritzwasser mecha nische Belastung Schwingungen St e Fremdk rper elektromagnetische St rungen und Elementarteilchen z B H henstrahlung Allgemeine und Hersteller spezifische Vorschriften enthalten teilweise genaue Angaben zur Vermeidung des passiven und aktiven Einflusses insbesondere im EMV Umfeld Elektromagne tische Vertr glichkeit Dieses Gebiet ist nicht Bestandteil dieser Vorles
146. u implementieren Dies bedeutet dass Annahmen ber die Zeitspanne zur Reaktion gemacht werden m s sen und hier bieten sich 4 M glichkeiten an 3 1 F r jeden Zeitschritt wird die exakte Zeit angegeben die f r die Implemen tierung notwendig sein wird Dies zwingt zu sehr fr hzeitigen und aufwendigen Sch tzungen ein Vorgang von dem gerade abstrahiert werden soll 2 Jeder Systemreaktion wird eine konstante endliche Zeitdauer zugeschrieben Dies bedeutet dass eine obere Grenze f r die Reaktionszeit dar auch f r die Implementierung die weder ber noch unterschritten werden darf Somit k nnte es auch passieren dass Vorg nge k nstlich verz gert werden m ssen Ein weiteres Problem ergibt sich wenn man in der Modellierung eine Reaktion in eine Folge von Subreaktionen aufteilen will In diesem Fall nimmt die mo dellierte Zeit linear zu was sicher nicht der Realit t entspricht 3 Die n chste Alternative besteht darin individuelle Zeiten f r jede Reaktion an zunehmen Dies ist sicher sehr flexibel und auch abstrakt jedoch ist der Frei raum letztendlich so gro dass kaum gesicherte Aussagen daraus gewonnen werden k nnen 4 Jeder Systemreaktion wird eine Zeitdauer von 0 Zeiteinheiten zugewiesen und damit wird angenommen dass die Systemreaktion stets schneller ist als die Rate der Ereignisse Dass diese Annahme korrekt ist daf r muss in einer sp teren Phase der Entwicklung ein Nachweis gef hrt werden Dies f
147. ung aber es soll an dieser Stelle darauf hingewiesen werden Der logische Aufbau der eingebetteten Systeme ist jedoch recht einheitlich in der Regel k nnen 5 strukturelle Bestandteile identifiziert werden 3 e Die Kontrolleinheit bzw das Steuerger t gt Definition 1 7 d h das einge bettete Hardware Software System 6 Embedded Systems Engineering Skript V1 00 e die Regelstrecke mit Aktoren bzw Aktuatoren actuator und Sensoren sensor d h das gesteuerte geregelte physikalische System e die Benutzerschnittstelle e die Umgebung sowie e den Benutzer Aktoren Benutzer Kontroll Regelstrecke Benutzer Schnittstelle einheit g e W Sensoren Umgebung Bild 1 2 Referenzarchitektur eines eingebetteten Systems 3 Bild 1 2 stellt diese Referenzarchitektur eines eingebetteten Systems als Daten flussarchitektur dar in der die Pfeile die gerichteten Kommunikationskan le zei gen Solche Kommunikationskan le k nnen zeit und wert kontinuierliche Signa le oder Str me diskreter Nachrichten bermitteln Regelstrecke und Umgebung sind hierbei auf meist komplexe Weise miteinander gekoppelt die schwer for malisierbar sein kann 1 Einf hrung in eingebettete Systeme 7 Kontrolleinheit Stellgr en Prozessgr en Eingriff Messung Umgebung Bild 1 3 Wirkungskette System Umgebung Bild 1 3 zeigt die geschlossene Wirkungsk
148. unter eigentlich zu verstehen ist Definition 4 1 ISO IEC 9126 Softwarequalit t ist die Gesamtheit der Merkmale und Merkmalswerte eines Soft wareprodukts die sich auf dessen Eignung beziehen festgelegte oder vorausge setzte Erfordernisse zu erf llen Konkret wird die Beurteilung erst dann wenn man sich auf die Qualit tsmerkmale bezieht Diese stellen Eigenschaften einer Funktionseinheit dar anhand deren ihre Qualit t beschrieben und beurteilt werden Allerdings enthalten sie keine Aussage ber den Grad der Auspr gung Beispielsweise existieren folgende Softwarequali t tsmerkmale die im brigen miteinander in Wechselwirkung stehen oder von einander abh ngig sein k nnen e Funktionalit t o Zuverl ssigkeit e Benutzbarkeit e Effizienz e nderbarkeit e bertragbarkeit Die nachfolgenden Definitionen stellen klar was unter Softwarefehlern bzw Feh lern allgemein verstanden wird Hierbei wird zwischen tats chlich auftretenden Fehlern m glichen Fehlern und fehlerhaften Handlungen die zu den beiden erst genannten f hren K nnen unterschieden Definition 4 2 Failure Fehlverhalten Fehlerwirkung u erer Fehler Hierbei handelt es sich um ein Fehlverhalten eines Programms das w hrend seiner Ausf hrung auch wirklich auftritt Definition 4 3 Fault Fehler Fehlerzustand innerer Fehler Es handelt sich um eine fehlerhafte Stelle eines Programms die ein Fehlverhalten ausl sen kann
149. v eunesnesennennenenenennnn 27 SIL Siehe Security Integrity Level systemkritische Zeit 27 Simulation 42 Systemtest enu sciiniiane 64 Simulator 42 Belastungstest e 64 Software Failover und Recoverytest 64 synchrone uessesneseeseesneneenn 45 Installationstest 64 Software Review 57 Performancetest nene 64 Software Thread Integration 75 Ressource Test 64 Softwarequalit t 51 52 Secure Test 65 A nderb rkeil neues 52 Benutzbarkeit 52 T Codechecker ETAETA 58 Taskklassen EFFIZIENZ Aene isorosi 52 ESS j Bo Designpriorit ten ue 71 Funktionalit t 52 32 Ereignis gesteuert ne 70 Mefkmale huria oteras 52 ER A Kommunikation 72 TEVIEW eher 57 mit Zeitbindun 70 bertragbarkeit en 52 E a A NA streng zyklisch laufend 70 Zuverl ssigkeit 52 i si Test Coverage 61 Space Time Efficiency Siehe 5 Testabdeckung nne 60 Fl chen Zeit Effizienz Testausf hrung 60 Sprachparadigma EEE 46 Testen 82a 58 Be ee ER Ausf hrung ee 60 Steuerger t nie 5 rk are Tirscaonstler 63 Belastungstest cnene 64 ee bottom up unit test 62 call pair coverage 63 Sachwortverzeichnis 105 Dateisystemschnittstelle 59 Erstellen von Testf
150. xistiert ein Notwert der z B eine bereits berechnete ungef hre N herung aber nicht den exakten Wert darstellt kann dieser eingesetzt und die Service Routine damit f r diesen Fall beendet werden Es kann auch entschieden werden einen weiteren Zeitabschnitt zu durchlaufen falls dies f r dieses Ereignis m glich ist Gerade die M glichkeit N herungswerte einzusetzen stellt ein m chtiges Instru mentarium dar um harte Echtzeit bei weicher Logik zu erhalten Dies ist bei bisherigen Verfahren nur mit sehr gro em Rechenaufwand m glich Aufwand der gerade aus Zeitknappheit entfallen muss F r diesen Ansatz zur Erreichung eines echtzeitf higen Systems k nnen folgende Vor und Nachteile angegeben werden Deterministische Berechenbarkeit des Zeitverhaltens wie beim Time triggered und Modified Event triggered System Ungenutzte Zeit die f r Ereignisse vorgesehen war wird an zeitunkritische Teile des Systems weitergegeben es entsteht kein Overhead Die Systemauslegung orientiert sich nicht mehr an Worst Case Sch tzungen mit vollst ndigem Rechenweg sondern f r eine deterministische Auslegung nur noch bis zu den N herungswerten Komplexe Klassifizierung der Ereignisse notwendig Welche Events sind immer vollst ndig durchzurechnen welche k nnen N herungen haben f r welche sind Zeiterweiterungen in Grenzen zul ssig 3 Design von eingebetteten Systemen 37 Softwareunterst tzung ist derzeit n
151. zeitbetriebssystem 86 Sr Eee SE 53 Echtzeitsystem er 3 14 26 75 Espee Siehe Execufable Speciiestion Betriebssystem ncneneeen 86 non Estere lenat ei ner 47 ereignisgesteuert seese 15 A Deklarationen nene 49 Ereignis gesteuett 31 81 et Determinismus cneee 48 Hart nenne 15 Instrukti 49 112 78 79 81 Be ETA i Koh renz caiit ieii 50 Mischung von Threads 76 ae ER Ea Kommunikation 49 modifiziertes Ereignis gesteuert 83 ER RR Kommunikationsprinzip 47 Netzwerk 83 F konstruktive Semantik 50 Reaktionszeit 80 Eu Parallelit t e 48 Scheduling e 89 rd Sieh Soft Degradation a 18 en PERS Soft Real Time System 18 ne verteilt 83 Event triggered System Siehe teilt nenn Preienis posts uertes System Welche i za net 15 18 Exception Handling Siehe ZEILgESLEUEIL pirrer 15 i Ausnahmebehandlung Zeit gesteuert nneeen 81 83 Executable Specification 42 ECU sesiis Siehe Steuerger t De EINEIENCY aan 52 F Efficiency Siehe Effizienz Effizienz sen 52 Failover und Recoverytest 64 Fl chen Zeit ceesenee 23 failure 52 54 Eingebettetes System Siehe failure mode and effect analysis 57 Embedded System fault nine naar 52 Embedded System 1
152. zessor ist dieser bei gleicher Arbeitsfrequenz schneller ergibt dies ein Verh ltnis der elektrischen Leistung von ca 1 27 Welches Fazit kann man hieraus ziehen Die aktuelle Entwicklung der integrierten Schaltkreise geht mehr in die Richtung Leistungseffizienz nicht mehr Perfor mance Dies wurde bereits in Bild 3 2 angedeutet und derzeit sind gro e Bem hungen zu verzeichnen diese Effizienz noch zu steigern Dies betrifft das Hardwaredesign und der Systemdesigner kann als Anwender nur die geeignete Architektur ausw hlen Ist die Leistungsbilanz bei einem Design im Vordergrund stehend oder auch nur eine wesentliche Randbedingung sollte man mit der Auswahl des Mikroprozessors Mikrocontrollers anhand der Daten begin nen und alle anderen Werte wie Betriebsfrequenz usw als nachrangig betrachten 3 Design von eingebetteten Systemen 39 3 3 2 Codierung von Programmen in besonders energiesparender Form Vor einigen Jahren war ein Thema wie energiesparende Software undenkbar mitt lerweile hat es sich jedoch schon etabliert 10 Man kann die spezifische Leis tungsaufnahme pro Befehl bestimmen und dann ausw hlen welcher tats chlich ausgef hrt werden soll falls es Variationsm glichkeiten gibt Kandidaten hierf r sind z B Multiplikationsbefehle und deren bersetzung in eine Reihe von Additionsbefehlen Insbesondere die Multiplikation einer Variablen mit einer Konstanten kann in diesem Beispiel als m glicher Kandidat gelt

Embedded Systems Engineering Vorlesung V1_01

Contents

Download Pdf Manuals

Related Search

Related Contents