Integrierte HW/SW Systeme: Anforderungen

Transkript

1 TECHNISCHE UNIVERSITÄT ILMENAU Integrierte HW/SW Systeme: Anforderungen Integrated Communication Systeme Analyseprozess Funktionelle Anforderungen Leistungsanforderungen Echtzeitanforderungen Sicherheit und Zuverlässigkeit Prinzipien und Elemente der Anforderungsanalyse

2 Systementwicklungsprozess Theorie Analyse Wasserfallmodell Entwurf Implementierung Entwicklung ist kein reiner top-down Prozess Nutzung von Standardkomponenten => bottom-up Fehlende akkurate Abschätzungen in frühen Phasen => feedback Fehlendes Vertrauen in die Machbarkeit => Machbarkeitsstudien, Prototyping Integration Wartung => in der Praxis ist der Entwicklungsprozess eine Mischung aus bottom-up und top-down Entwurf 2

3 Analysephase und Subphasen Problem Analyse Analyse Machbarkeits studie Anforderungen Analyse Die Ziele der Analysephase sind identifizieren von Zweck, Wert und Risiken, das Produkt zu entwickeln und identifizieren des Zwecks des Produktes und seiner exakten Anforderungen 3

4 Review des Entwicklungsprozesses Problem Analyse Analyse Machbarkeits studie Anforderungs- Analyse Entwurf Die Anforderungsanalyse ist eine detaillierte Studie der Anforderungen des Systems aus Sicht seiner Umgebung. Hauptaufgaben sind identifizieren, analysieren und klassifizieren der Anforderungen des zu bauenden Produktes 4

5 Anforderungsdefinition: Inhalte Identifikation des Systems (Schnittstellen zur Umgebung) Funktionelle Anforderungen (Funktionalität der Schnittstellen) Zeitliche und Leistungsanforderungen (Durchsatz, Reaktionszeit, Verzögerung, Jitter) Fehlertoleranz und Zuverlässigkeit Qualität (Abwesenheit von Fehlern) Sicherheit Plattform (OS, generelle HW) Energieverbrauch Hitzeentwicklung, Wärmeverlust Operationsumgebung (Temperatur, Schock- und Staubresistenz, etc.) Größe Mechanische Konstruktion EMC Wartbarkeit Erweiterbarkeit Support Dokumentation Kosten (Entwicklung, Inbetriebnahme und Operation) Fertigstellungsdatum... => Einige Details folgen 5

6 Die Bedeutung von Anforderungsanalysen Genaue Definition der Anforderungen ist A&O zur Qualitätssicherung! 6

7 Funktionelle Anforderungen Definition des exakten Verhaltens des Systems aus Sicht seiner Schnittstellen Beschreibungstechnik hängt stark von der Systemart ab: (Zustands)gesteuertes System -> state machine transformatorisches System -> Datenflussmodell (z.b. audio encoder) => siehe Abschnitt Verhaltensmodelle für Details Beispiel Steuerungssystem: Sicherheitsgurt-Steuerung Beispiel für transformatorisches System: FIR*) filter o(n) = c1 * i(n) + c2 * i(n-1) i(n) KEY_ON => START_ZeitR WAIT i(n) * c1 OFF KEY_OFF or BELT _ON => END_ZeitR_10 or BELT_ON or KEY_OFF => ALARM_OFF ALARM END_ZeitR_5 => ALARM_ON S i(n-1) * c2 c2 * i(n-1) *) FIR: finite impuls filter S: storage + c1 * i(n) o(n) 7

8 Leistungsanforderungen Wichtige Leistungsanforderungen Kapazität Reaktionszeit Jitter (z.b. zulässige Taktschwankungen) Beispiele für Leistungsanforderungen: Kapazität: Anzahl (und Art) von Ereignissen verarbeitet pro Sekunde Antwortzeit: Zeit, um ein Ereignis zu erzielen (95%) Die Leistung des Systems von der zugeordneten Last ab, d.h. dem Verkehrsmodell (Traffic model) Reaktionszeit Last Die Leistung ist stark vom Entwurf beeinflusst, speziell vom Modul/Komponentenentwurf Von verfügbare Verarbeitungs- und Kommunikationsressourcen Von der Scheduling-Strategie Leistung kann nicht zur Implementierung addiert werden 8

9 Real-Zeit (zeitliche) Anforderungen Brauchbarkeit des Resultats hard oder firm Echtzeit Anforderung soft Echtzeit Anforderung deadline Zeit Definitionen: Wenn das Resultat auch nach der deadline nützlich ist, heißt die deadline soft. Wenn das Resultat unbrauchbar nach der deadline ist, heißt die deadline firm. Wenn im die Nichteinhaltung der deadline zu Katastrophen führt, heißt die deadline hard. Ein Echtzeit-Computersystem dass mindestens eine hard deadline erfüllen muss, heißt hard Echtzeitsystem. Der Systementwurf für hard- und soft- Echtzeitsysteme unterscheidet sich fundamental. 9

10 Echtzeit Anforderungen Beispiele: soft deadlines öffentliche Verkehrssysteme Airport Gepäcktransportsystem firm deadlines audio processing video processing hard deadlines Steuerung von nuklearen oder chemischen Prozessen (Kettenreaktion) Eisenbahn Verkerssteuerung Luftverkehrssteuerung 10

11 Echtzeit Systeme Klassifikation Aufgrund der externen Anforderungen hard/firm Echtzeit versus soft Echtzeit Ausfallsicherheit vs. Fehlfunktionen (z.b. Zug Steuerungssystem, fly-by-wire System) Aufgrund der Entwurfsprozess-Implementierung garantierte Pünktlichkeit vs. best effort Ressourcen-Angemessenheit vs. keine Ressourcen-Angemessenheit (ausreichende Rechenressourcen um alle spezifischen Spitzenlasten und Fehlerszenarios zu berücksichtigen) ereignisgesteuert vs. zeitgetaktet 11

12 zeitgetaktet (TT) vs. ereignisgesteuert (ET) Systeme Ein System ist zeitgetaktet (TT) wenn die Steuerungssignale, wie z.b. senden und empfangen von Nachrichten erkennen einer extenen Zustandsänderung nur vom Fortschreiten einer (globalen) Zeitnotation abgeleitet sind. Ein System ist ereignisgesteuert (ET) wenn die Steuerungssignale ausschließlich vom Auftreten eines Ereignisses, z.b., Termination einer Aufgabe (task) Empfang einer Nachricht (message) externe Unterbrechung (interrupt) abgeleitet sind. Beachte: Die Taktungsmethode ist oft eine Eigenschaft der Implementierung und nicht notwendig eine Anforderung. 12

13 Sicherheitsanforderungen: Fail-Safe vs. Fail-Operational Sicherheitsanforderungen definieren die Aktionen, die im Fehlerfall durchführbar bzw. durchzuführen sind. Ein System ist fail-safe (ausfallsicher) wenn in der Umgebung ein sicherer Zustand existiert, der im Fehlerfall erreicht werden kann, z.b. ABS, Zugsignalsystem. In einer fail-safe Anwendung muss ein Rechner eine hohe Fehlererkennungsrate (error detection coverage) haben. Fail-safeness ist eine Charakteristik der Anwendung, nicht des Computersystems. Ein System ist fail-operational, wenn im Falle eines Systemfehlers kein sicherer Zustand erreicht werden kann, die Operation mit dem übrigen System jedoch noch durchführbar ist (z.b. Autopilot). In fail-operational Anwendungen muss das Computersystem ein minimales Service- Niveau garantieren, auch nach dem Auftreten eines Fehlers. 13

14 Zuverlässigkeitsanforderungen Zuverlässigkeit beschreibt die Wahrscheinlichkeit des Auftretens oder der Abwesenheit von Systemfehlern Beispiele von Zuverlässigkeitsmaßen sind MTTF (mean time to failure) MTBF (mean time between failures) (Wartungszyklus < MTBF) Wahrscheinlichkeit für fehlerfreie Zeit (z.b %) Die Zuverlässigkeit des Systems kann (theoretisch) geschätzt bzw. berechnet werden aus der Zuverlässigkeit seiner Komponenten Beachte: 99,995% bei 1TByte Festplatte bedeutet: Byte fehlerhaft! USB 3.0 theor. 5GBit/s % ok => Bit/s falsch! Ein System welches garantiert, dass es im Fall, dass einige Komponenten fehlerhaft sind, noch korrekt funktioniert, heißt fault tolerant system (d.h. es ist in der Lage Fehler einzelner Komponenten des Systems zu tolerieren) Fail-safe / fail-secure: automatische Türen öffnen/ schließen bei Stromausfall 14

15 Bestimmbarkeit in Situationen mit seltenen Ereignissen Ein rare event ist ein wichtiges Ereignis, dass sehr selten zur Lebenszeit (lifetime) eines Systems auftritt, z.b. das Zerbrechen eine Leitung in einem Nuklearreaktor. Ein seltenes Ereignis kann eine Kette von Service Anforderungen auslösen (z.b. Sprenkel Anlage). In einer Anzahl von Anwendungen hängt der Wert des System von der bestimmbaren Leistungsfähigkeit in Szenarien mit seltenen Ereignissen ab, z.b. Flugsteuerungssystem. In den meisten Fällen werden bei typischen Lasttestverfahren seltene Ereignisse nicht berücksichtigt. 15

16 Prinzipe und Elemente der Analyse Modelle Richtlinien für die Analyse: Verstehe zunächst das Problem! (vor der Erstellung des Analysemodells) Notiere Ursprung und Grund für jede Anforderung Nutze unterschiedliche Sichten auf Anforderungen (Datenmodell, Funktionelles Modell, Verhaltensmodelle) Priorisiere Anforderungen Eliminiere Unklarheiten Elemente des Analysemodells: Data dictionary Prozessspezifikation (data-flow diagram) Steuerungsspezifikation (state-transition diagram) Datenobjekt Beschreibung (entity-relationship diagram) Funktionelle Spezifikation (sequence diagram) Spezifische Methoden und Werkzeuge für unterschiedliche Anwendungen: z.b. Echtzeit Systeme, transformatorische Systeme, Steuerungssysteme, Kommunikationssysteme, etc. 16

17 References H. Balzert: Lehrbuch der Softwsind-Technik Bund 1: Softwsindentwicklung. Spektrum-Verlag, R. S. Pressman: Softwsind Engineering A Practicioner s Approach. Fourth Edition, (Chapter 12: Analyse Modeling) A. Mitschele-Thiel: Systeme Engineering with SDL Entwickeln Performance - Critical Communication Systems. Wiley, B. Thomé (Editor): Systems Engineering Principles und Practice of Computer-based Systems Engineering, Wiley, K. Pohl, C. Rupp: Basiswissen Anforderungs- Engineering, dpunkt Verlag. Heidelberg,

18 TECHNISCHE UNIVERSITÄT ILMENAU Verhaltensmodelle und Spezifikationssprachen Integrated Communication Systeme Verhaltensmodelle Finite State Machine (FSM) NDFSM composed FSM Petri Net (PN) Data Flow Graph (DFG) Control Flow Graph (CFG) Control/Data Flow Graph (CDFG) Grundkonzepte concurrency hierarchy communication synchronisation exception handling non-determinism timing Spezifikationssprachen StateCharts SDL VHDL SystemC...

19 Warum brauchen wir Verhaltensmodelle? Modelle: Abstraktion von der realen Welt bis zu einem gewissem Grad (Beschreibung von Teilen des Systems unter einem bestimmtem Blickwinkel) Modelle können sehr unterschiedlichen Zwecken dienen, z.b. zum Dokumentieren, Begründen oder Beschreiben von dem Verhalten eines Systems, der Leistung eines Systems, oder andere Zwecke (Sicherheit, Zuverlässigkeit, Stoßfestigkeit, Temperatur..) Verhaltensmodelle (oder computation models) repräsentieren formale Umgebungen (frameworks), um das Verhalten von Systemen oder ihrer Teile zu beschreiben Formale Definitionen erleichtern das Beweisen (reasoning) und die Verfeinerung (refinement) Die Beschreibung des Verhaltens kann abstrakt oder konkret sein, z.b. eine abstrakte state machine des Verhaltens einer Fahrstuhlsteuerung ein C Programm, Assembler Programm oder eine VHDL Beschreibung Verhaltensmodelle können fokussieren auf Extern sichtbares Verhalten (Analysephase) und/oder interne Details des Systems (Entwurf- und Implementierungsphase) 19

20 Verhaltensmodelle und Spezifikationssprachen Verhaltensmodelle (z.b. FSM, PN, DFG) repräsentieren wohl definierte Grundmechanismen mit zugrunde liegender Syntax und Semantik um spezifische Aspekte eines Systems oder seiner Teile zu modellieren Spezifikationssprachen (z.b. Statecharts, SDL, VHDL) verwenden eine Menge von Grundmechanismen zur Systemspezifikation einer spezifischen Anwendungsdomäne Verhaltensmodelle und Spezifikationssprachen dienen zum: Erfassen der Unbestimmtheiten der geforderten Funktionalität Verifizieren der Korrektheit funktioneller Spezifikationen bzgl. gegebener Eigenschaften Synthetisieren von Teilen der Spezifikation und nutzen eine Vielzahl von Werkzeugen. wichtige Eigenschaften von Verhaltensmodellen und Spezifikationssprachen Ausdrucksmächtigkeit / Einfachheit (Simplicity) Generalität/Anwendbarkeit Kompilierbarkeit/ Synthetisierbarkeit Verifizierbarkeit 20

21 Verhaltensmodelle (diskret-zeit und Zustandsorientiert) State-oriented (Verhalten) Finite State Machines Petri Nets Hierarchical concurrent FSM reactive Systeme Action-oriented (Verhalten) data flow graph transformatorische control flow graph Systeme Structurelle Modelle Structure-oriented Component connectivity graph Data-oriented entity relationship diagram Jackson s diagram Heterogene Modelle Control /data flow graph structure chart programming language paradigm object-oriented model program-state machine queueing model (Warteschlangen) 21

22 More Models and Languages... to complete the confusion! More Modelle... continuous time continuous state structure-oriented data-oriented... Each of these provides a formal framework for reasoning about certain aspects of the system Focus here Behaviour rather than structure Tower of Babel, Bruegel, 1563 discrete time rather than continuous discrete state (digital) rather than continuous (analog) 22

23 Verhaltensmodelle Anwendung Needs Telekommunikation Heterogene Spezifikationen Datenverarbeitung (data processing) Steuerungsfunktionen Data processing, z.b. Verschlüsselung (encryption), forward error correction, Berechnungen während regulären (oft kurzen) Intervallen Effizient spezifiziert und synthetisiert unter Verwendung von Datenflussmodellen Steuerungsfunktionen (Datenabhängig und in Echtzeit) Bestimmen wann und wie die Berechnung erfolgen soll Effizient spezifiziert und synthetisiert unter Verwendung von FSM Modellen Benötigen ein allgemeines Modell für globale Systemanalyse und -optimierung Reaktive Echtzeit Systeme Reagieren (react) auf externe Umgebung Führen eine permanente Interaktion durch Terminieren idealerweise nie Haben Zeitanforderungen (timing constraints) (Echtzeit) Gegenteil zu transformatorischen Systeme interaktiven Systeme 23

24 Finite State Machines (FSM) Funktionelle Dekomposition in Operationszustände Endliche Menge von Zuständen (finite states ) Übergänge (transitions ) zwischen Zuständen Ereignisgesteuerte Übergänge Weder Parallelität noch Zeitmodellierung (sequential FSMs) Typische Anwendungen: reaktive (Steuerungs-) Systeme Protokolle (Telecom, Computerschnittstellen,...) 24

25 FSM Beispiel: Seat Belt Control Informal Spezifikation: Wenn der Fahrer mit dem Schlüssel einschaltet und den Sicherheitsgurt nicht innerhalb von 5 sec anlegt dann ertönt ein Alarmton 5 sec lang, oder bis der Fahrer den Gurt angelegt hat, oder bis er mit dem Schlüssel wieder ausschaltet Formale Spezifikation: KEY_ON => START_TIMER OFF KEY_OFF or BELT _ON => END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF Interpretation: Conditional expression => Output If none of the conditions is satisfied, implicit self-loop in the current state WAIT ALARM END_TIMER_5 => ALARM_ON 25

26 Non-deterministic FSM (NDFSM): Incomplete Spezifikation Beispiel: parity error checking und synchronization after 8 bit Partially specified (incomplete): BIT or not BIT => BIT or not BIT => BIT or not BIT => ERR Focus on synchronization after 8th bit, not on parity More completely specified as even parity: BIT or not BIT => SYNC => not BIT => BIT => p1 not BIT => BIT => BIT => not BIT => p7 not BIT => not BIT => ERR BIT => BIT => ERR 0 d1 d7 8 SYNC => 26

27 NDFSM: Unknown parts der Verhalten Modeling the Umgebung Nondeterminism ist useful to: optimize (don t csind conditions) verify (exclude impossible cases) Beispiel: driver model KEY_ON => START_ZeitR OFF KEY_OFF or BELT _ON => WAIT END_ZeitR_10 or BELT_ON or ALARM KEY_OFF => ALARM_OFF END_ZeitR_5 => ALARM_ON s0 1 => KEY_ON or KEY_OFF or BELT_ON Can be refined z.b. introducing timing conszugts (minimum reaction Zeit of 0.1 s between actions) 27

28 NDFSM: Spezifikation eines Zeitbereichs Spezialfall von unspezifiziertem / unbekanntem Verhalten, aber allgemein genug, um eine Spezialbehandlung zur Effizienz zu verdienen. Beispiel: nichtdeterministische Verzögerung (zwischen 6 und 10 s) START => SEC => SEC => SEC => START => SEC => END 0 9 SEC => END SEC => END SEC => END 6 SEC => 8 SEC => 7 SEC => SEC => 5 SEC => 28

29 NDFSMs und FSMs Formal sind FSMs und NDFSMs äquivalent (Rabin-Scott construction, Rabin 59) In praxi, sind NDFSMs meist kompakter (exponentielle Zustandsexplosion für Überführung in FSM) Beispiel: non-deterministische Auswahl der Transition a in Zustand s1 Äquivalente deterministische FSM s1 a s1 a c c a s2,s3 b c s3 s2 b s3 a b a a s2 29

30 Finite State Machines Diskussion Vorteile: Einfach zu nutzen (graphische Sprachen) Leistungsstarke Algorithmen für Synthese (SW und HW) Verifikation Nachteile: Teilweise Überspezifikation der Implementierung (Zustandsfolge ist vollständig spezifiziert) Anzahl der Zustande kann unbeherrschbar werden Numerische Berechnungen können nicht kompakt spezifiziert werden (=> Extended FSMs) 30