Entwicklung integrierter Hard- und Softwaresysteme: Aufgaben und Prozesse

Transkript

1 TECHNISCHE UNIVERSITÄT ILMENAU Entwicklung integrierter Hard- und Softwaresysteme: Aufgaben und Prozesse Integrated Communication Systems

2 Generelle Entwicklungsaufgaben Analyse der Umgebungsanforderungen an das System Modellierung des zu entwerfenden Systems und Durchführung von Experimenten mit den zugehörigen Algorithmen Verfeinerung (oder Partitionierung) der zu implementierenden Funktion in kleinere, interagierende Teile HW/SW-Partitionierung Zuordnung der Elemente des verfeinerten Modelle entweder auf HW- oder SW-Einheiten, die auf kundenspezifischer Hardware oder universellen Mikroprozessoren läuft Zeitverwaltung (Scheduling) Ausführungszeiten und Reihenfolgen (wichtig, wenn sich verschiedene Module der Partition die gleiche Hardware Einheit teilen) 2

3 Systementwicklungsprozess Theorie Analyse Wasserfallmodell Entwurf Implementierung Entwicklung ist kein reiner top-down Prozess Integration Nutzung von Subkomponenten von der Stange => bottom-up Fehlende akurate Abschätzungen in frühen Phasen => feedback Fehlendes Vertrauen in die Machbarkeit => Machbarkeitsstudien (feasibility studies) und Prototyping Wartung => in der Praxis ist der Entwicklungsprozess integrierter HW/SW-Systeme eher eine Mischung aus bottom-up und top-down Entwurf 3

4 Analyse und Unterphasen Analyse Problemanalyse Machbarkeitsstudie Anforderungsanalyse Ziele der Analysephase sind Identifikation des Zwecks, Wertes und der Risiken der Produktentwicklung, Identifikation des Zwecks des Produktes und der exakten Anforderungen 4

5 Problemanalyse Vorstudie zur Analyse, welche wichtigen Anforderungen die Systemumgebung an das System stellt Diskussion der prinzipiellen Lösungsstrategien Problem analysis Analysis => Problemdefinition (Lastenheft) Projektziele (Geschäftsziel) Produktziele, Hauptzielrichtung der Entwicklung Feasibility study Spezifikation von Variablen und Konstanten des zu entwickelnden Produkts Anforderungen analysis Identifikation von Ressourcen die zur Durchführung der Entwicklung notwendig sind (Kapitalinvestition, Arbeitskräfte und andere Ressourcen) 5

6 Problemanalyse Die Xerox-Maus bekam Steve Jobs im November 1979 zu Gesicht. Analysis Problem analysis Feasibility study Anforderungen analysis Jobs war von dem Konzept begeistert, sah aber auch die Probleme im Detail. Die Xerox-Maus kostete in der Herstellung allein 400 Dollar, fiel durchschnittlich nach einer Woche aus und konnte nur von Fachleuten repariert werden. Steve Jobs kam zu uns und sagte: Ich will eine Maus für 10 Dollar, die niemals ausfällt und die in Massen produziert kann, weil die Maus das wichtigste Interface des Computers der Zukunft werden wird, 6

7 Feasibility Study (Machbarkeitsstudie) Überprüfung der Machbarkeit der Produktentwicklung und des Produktes technische Machbarkeit (Verfügbarkeit effizienter Algorithmen,...) ökonomische Machbarkeit (time-to-market, Marktfenster, Investitionen, Gewinn) Problem analysis Analysis Fokus der Machbarkeitsstudie sind kritische Aspekte des Systems um die Zuversicht in einen erfolgreichen Abschluss des Projektes zu erhöhen. Feasibility study Anforderungen analysis => Ergebnis (hängt vom genauen Fokus der Machbarkeitsstudie ab) Info zu erwarteten Kosten und Vorteilen des Projektes Info zu technologischen und finanziellen Risiken des Projektes Benötigte Ressourcen für die Entwicklung und/oder das Marketing Evaluation möglicher technischer Alternativen 7

8 Anforderungsananlyse (Requirements Analysis) Detaillierte Untersuchung der Systemanforderungen aus Umgebungssicht Identifikation, Analyse und Klassifikation der spezifischen Anforderungen (Anforderungen) des zu entwickelnden Produktes Die Lösung, d.h. die Frage wie den Anforderungen entsprochen werden, kann bleibt typischerweise offen Problem analysis Analysis Feasibility study Anforderungen analysis => Pflichtenheft (Requirements Spezifikation) Vollständig und korrekt Definiert das Ergebnis des Entwicklungsprozesses (deliverables) Definition der Schnittstellen zur Umgebung (environment) Definition der Gesamtfunktionalität des Produktes Leistungsanforderungen (Performance Requirements) Einschränkungen (Contraints) für SW, Betriebssystem (OS) und HW Möglicherweise Richtlinien (Guidelines) für die interne Produktstruktur 8

9 Inhalte des Pflichtenheftes Identifikation und Abgrenzung des Systems (Schnittstellen zur Umgebung) Funktionelle Anforderungen (Funktionalität an den Schnittstellen) Temporale und Leistungsanforderungen (Durchsatz, Antwortzeit, Verzögerung, Jitter) Fehlertoleranz und Zuverlässigkeit Qualität (Abwesenheit von Fehlern) Sicherheit (Safety) im Sinne sicher funktionieren Operationsplattform (OS, generelle HW) Leistungsverbrauch Kühlung Betriebsumgebung (Temperatur, Schock- und Staubresistenz usw.) Größe Mechanische Konstruktion EMC (Tx/Rx) Wir werden Methoden zur Wartbarkeit Sicherstellung der Anforderungen Erweiterbarkeit Support im Entwurfskapitel kennenlernen Dokumentation Kosten (Entwicklung, Erstellung und Dauerbetrieb) Datum der Fertigstellung... 9

10 Entwurf und Unterphasen Entwurf Architektur- Entwurf detaillierter Entwurf Implementations- Entwurf Zweck: Festlegung wie das System den Anforderungen genügt -> Innenansicht Fokus auf die Lösung 10

11 Entwurf und Unterphasen Architekturentwurf (Top-level Entwurf) Def. der Module/Komp. des Systems und ihrer Schnittstellen(interfaces) Ziel: maximiere interne Zusammenhänge und minimiere Koordination zwischen Modulen Module sind typisch funktionelle Entities, können aber auch strukturelle Entities sein (strukturelle vs. Verhaltensmodularisierung) Architektur Entwurf Entwurf detaillierter Entwurf Implementations- Entwurf Detaillierter Entwurf (Modulentwurf) Def. der funktionalen/ Verhaltensdetails (Algorithmen) jedes Moduls unabhängig von der Implementierungstechnik Implementatierungsentwurf Berücksichtigung der Details der benutzten Implementierungstechnik, z.b. Schnittstellen zu Betriebssystem und HW Wann wird das Verhalten des Systems entschieden und wann die Struktur? 11

12 Der Entwurfsraum: Ein komplexes Optimierungsproblem... Systemarchitektur/Gesamtarchitektur (strukturelles Modell, oder Mapping von Funktionen auf HW, usw.) Entwurfmethoden (Entwurfswerkzeuge und Spezifikationssprachen) HW-Auswahl (System-on-Chip, ASIC, FPGA, DSP, NP, uc, up) HW-Entwurfsmethoden (Sprachen, HL-Synthesis, RTL-Synthesis, ) HW-Beschreibung (Algorithmen und Implementation) HW-Mapping und Scheduling SW-Beschreibung (Programmiersprachen, Algorithmen und Implementation) SW-Mapping und Scheduling HW/SW-Schnittstellen (als Folge der HW/SW-Partitionierung) Schnittstellen mit der Umgebung (embedding) Unterstützung durch das Betriebssystem oder Bibliotheken Selber entwickeln oder kaufen (HW, SW, OS) Verfügbare Personalressourcen und Know-how 12

13 Entwurfsmodelle und Sichten Überblick Unterschiedliche Modellierungsansätze betrachten unterschiedliche Systemaspekte & & & Strukturelle Sicht msc data_transfer application transport network medium network transport application datenorientierte Sicht System Funktionelle Sicht Verhaltenssicht 13

14 Strukturelle Modelle Strukturelle Modelle fokussieren auf die Struktur des Systems, d.h. seine Komponenten, Module, usw., weniger auf sein Verhalten Strukturelle Blöcke sind abstrakt (ALUs, Prozessoren, Speicher, Busse, Chipsets, Boards) oder detailliert (Flip-flops, Gatter) Beispiele: Netzliste, Blockdiagramm & & & 14

15 Verhaltensmodelle Verhaltensmodelle beschreiben das Verhalten des Systems oder seiner Teile Implementation der Verhaltensmodelle kann in SW oder HW realisiert werden einige Modelle sind besser für HW-Entwurf, andere besser für SW geeignet Beispiele: C-Programm, Petri-Netz, State Diagramm, Datenflussgraph o(n) = c1 * i(n) + c2 * i(n-1) KEY_ON => START_TIMER WAIT OFF KEY_OFF or BELT _ON => END_TIMER_5 => ALARM_ON Send msg END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF ALARM Process 1 Process 2 Send Ack Receive Ack 15

16 Verhalten trifft Struktur: Das Optimierungsproblem Verhaltensraum (Verhalten, die Pflichtenheft erfüllen) System Platform Struktureller Raum 16

17 Verhalten trifft Struktur: Das Optimierungsproblem Verhaltensraum System Platform Es gibt eine Vielzahl von Lösungen um das Verhalten konsistent mit den gegebenen Anforderungen zu definieren (Algorithmen, Datenstrukturen ) Es gibt eine Vielzahl von Wegen, das definierte Systemverhalten zu modellieren Es gibt eine Vielzahl von Lösungen um die Struktur des Systems zu definieren (Mikrocontroller, DSP, kundenspezifische HW, konfigurierbare HW,...) Es gibt eine Vielzahl von Wegen, die definierte Systemstruktur zu modellieren Struktureller Raum Entwurf bringt das Verhalten (inklusive Daten und Funktionen) mit der Struktur in Einklang (Mapping), so dass alle Anforderungen erfüllt sind (Kosten, Zeit Randbedingungen, Kapazitäten, Zuverlässigkeit, Wartbarkeit, Leistungsverbrauch,...) Mapping ist ein sehr komplexes Optimierungsproblem 17

18 Entwurf: Verhalten vs. Struktur (Behavior vs. Structure) Verhaltensspezifikationen beschreiben die Funktionalität des Systems unter Verwendung von Modellierungs- oder Programmierungssprachen Verhaltensspezifikationen können abstrakte Modelle (state charts, UML, SDL) oder konkrete Programme (C, VHDL, SystemC) sein Verhaltensspezifikationen können auf realer HW ausgeführt werden (C Programme, Assemblercode) oder auf virtueller HW simuliert/emuliert werden (VHDL, SystemC, SDL) Verhaltensspezifikationen stellen sicher, dass die funktionalen Anforderungen erfüllt werden. Allerdings besteht dadurch keine Sicherheit bzgl. nichtfunktionaler Aspekte des Systems, z.b. Leistung, Echtzeit, Fehlertoleranz, Kosten, Energieverbrauch, etc. Strukturelle Spezifikationen sind für die Implementierung in HW erforderlich. Damit stellt sich die Frage wenn der beste Zeitpunkt für die Strukturentscheidungen ist? 18

19 Implementierung Voraussetzungen: Funktionale Details wie Algorithmen, usw. sind spezifiziert... HW-Komponenten wurden ausgewählt HW/SW-Partitionierung kann entschieden werden Aufgaben: Codierung von Funktionen, Algorithmen, usw. in der gewählten Implementierungssprache Test von Modulen und Komponenten in Isolation unter Emulation anderer Module oder Komponenten Anmerkungen: Unter der Annahme das der Entwurf vollständig und korrekt ist, ist dies problemlos möglich Die Implementierungsphase repräsentiert einen kleinen Teil des Entwicklungsprozesses (ca. 20% bei reinen SW-Projekten) 19

20 Validierungsmethoden Konstruktionsprinzipien Inhärent korrekt. Verifikation Eigenschaften sind beweisbar. Test Prüfung des Verhalten bei verschiedenen Eingaben. Simulation Prüfung des Verhaltens am Modell. Intuition Aussage/Behauptung Einschüchterung Methoden sind absteigend nach Effektivität geordnet! :-) Validierung ist ein kontinuierlicher Prozess der in verschiedenen Phasen des Entwicklungsprozesses und auf verschiedene Modelle des Systems angewendet wird um die Konformanz mit verschiedenen Eigenschaften und Anforderungen an das System oder seinen Komponenten (Verhalten, temporale Anforderungen, Energieverbrauch, mechanische Stabilität, etc.) sicher zu stellen 20

21 Integration Zweck: Sicherstellung der Erfüllung der Systemanforderungen Fertigstellung des Systems zur Lieferung Aufgaben: Systemintegration: schrittweises Zusammenfügen von HW- und SW- Komponenten zum Komplettsystem Integrationstest: schrittweiser Test des Systems Systemtest: Test des (integrierten) Gesamtsystems Anmerkungen: Testen kann auf fast alle Anforderungen und Eigenschaften von Systemen, Systemkomponenten oder Module (Funktionalität, Leistung, Zuverlässigkeit, Temperaturverhalten, mechanische Stabilität, Ergonomy, Mensch-Maschine- Schnittstelle, Dokumentation, etc.) angewendet werden Testen ist die in der Praxis populärste Validierungsmethode 21

22 Wartung (Maintenance) Wartung ist für den kompletten Lebenszyklus des Systems relevant, von der Auslieferung bis zur Außerdienststellung Wartung behandelt Änderungen infolge von veränderten Umgebungsbedingungen, veränderten Funktionen oder veränderten Leistungsanforderungen Wartung dient der Behebung von Fehlern Anmerkung: Die Wartungskosten übersteigen die Entwicklungskosten oft um ein Vielfaches 22

23 Prozessmodelle Übersicht Wasserfallmodell (top-down) typischer Ingenieuransatz um Gebäude, Brücken, etc. zu bauen kein Feedback vorgesehen Iteratives Wasserfallmodell Validierung und Feedback zu früheren Phasen Evolutionäres Modell Systementwicklungprozess wird als evolutionärer Prozess der Entwicklung von Prototypen betrachtet Anforderungen werden schrittweise zugefügt Spiralmodell Generalisierung verschiedener Prozessmodelle (Metamodell) mehrere Entwicklungszyklen mit Validierungsschritten V-Model kontinuierliche Validierung in der realen Umgebung bzw. Anwendung Komponenten-basiert (bottom-up) Konstruktion des Systems aus einer Menge vordefinierter/verfügbarer Komponenten (objectbasiert) 23

24 Klassisches und Iteratives Wasserfallmodell Analysis Klassisches Wasserfallmodell (top-down) Ingenieursansatz keine Rückkopplung Entwurf Implementierung Integration Wartung Iteratives Wasserfallmodell Validierung und Rückkopplung auf frühere Schritte 24

25 Evolutionäres Modell Grenzen des Wasserfallmodells unvollständige Anforderungen ungeeignet wenn Anforderungen nicht hinreichend verstanden oder bekannt sind keine vorläufigen Produktreleases oder Prototypen Idee des evolutionären Modells: inkrementelle Produktreleases schrittweise Verfeinerung und Erweiterung der Anforderungen während dem Entwicklungprozess Analyse Entwurf implementierung Test weitere Iteration nötig? n y Modifikation der Produktdefinition 25

26 Spiralmodell Metamodell zur flexiblen Kombination bekannter Prozessmodelle Definition der Ziele, Alternativen und Randbedingungen Bewertung der Alternativen, Identifikation und Auflösung von Risiken Review der Ergebnisse; Plan der nächsten Iteration Entwicklung und Verifikation 26

27 V-Modell Erweiterung des Wasserfallmodells zur Integration von Maßnahmen der Qualitätssicherung (Verifikation und Validierung) Anforderungsdefinition application scenarios Akzeptanztest Validierung top-level Entwurf High level test cases Systemtest detaillierter Entwurf Modulimplementierung test cases test cases Integrationstest Moduletest Verifikation Validierung: Sichert die Eignung des Systems zur Lösung der Aufgabe => Produktqualität: Entwickeln wir das gewünschte System? Verifikation: Sichert dass das Ergebnis eines Entwicklungsschrittes die spezifizierten Anforderungen erfüllt => Prozessqualität: Wird das System korrekt entwickelt? 27

28 Traditioneller Entwurf (Early Partitioning) vs. Codesign Frühe Partitionierung (Structure First) HW/SW CoEntwurf (Behavior First) Systemarchitektur Systembeschreibung HW-Beschr. SW-Beschr. Systemarchitektur HW-Impl. SW-Impl. HW-Impl. SW-Impl. Prototype/Produkt Prototype/Produkt + optimierte Beschreibung/Modelle für HW und SW - fehlende Flexibilität bzgl. HW/SW- Partitionierung - Probleme mit HW/SW-Integration + gemeinsame Systembeschreibung/ Modell erleichtert Validierung und Integration - fehlende Optimierung für HW- oder SW-Implementierung + flexible HW/SW-Partitionierung 28

29 Traditioneller vs. Co-Entwurf Ansatz (Polis, Cadence VCC) Traditioneller Systementwurf VCC Separation und Mapping Systemverhalten Systemarchitektur Systemleistung Systemverhalten Systemarchitektur 1 2 Mapping Verhalten auf Architektur Systemimplementierung Verfeinerung 3 4 Implementierung des Systems Data Sheets auf Papier Ausführbare Data Sheets 29

30 References Systementwicklung D. Gajski, F. Vahid, S. Narayan, J. Gong: Spezifikation und Entwurf of Embedded Systems. Prentice Hall, A. Mitschele-Thiel: Systems Engineering with SDL Developing Performance- Critical Communication Systems. Wiley, (section 2.1.2) J. Teich, Ch. Haubelt: Digitale Hardware/Software Systeme: Synthese und Optimierung. Springer, Ch. Haubelt, J. Teich: Digitale Hardware/Software-Systeme: Spezifikation und Verifikation, Springer, Softwareentwicklung H. Balzert: Lehrbuch der Software-Technik Band 1: Softwareentwicklung. Spektrum-Verlag, R. S. Pressman: Software Engineering A Practicioner s Approach. Fourth Edition, McGraw Hill,