Integrierte HW/SW Systeme: Anforderungen

Transkript

1 TECHNISCHE UNIVERSITÄT ILMENAU Integrierte HW/SW Systeme: Anforderungen Integrated Communication Systeme Analyseprozess Funktionale Anforderungen Leistungsanforderungen Echtzeitanforderungen Betriebssicherheit 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 Problemanalyse Analyse Machbarkeits studie Anforderungsanalyse Ziele der Analysephase sind Identifikation des Zwecks, Wertes und der Risiken der Produktentwicklung Identifikation des Zwecks des Produktes und der exakten Anforderungen 3

4 Review des Entwicklungsprozesses Problemanalyse Analyse Machbarkeitsstudie Anforderungsanalyse 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 realisierende Produktes 4

5 Anforderungsdefinition: Inhalte Identifikation des Systems (Schnittstellen zur Umgebung) Funktionale Anforderungen (Funktionalität der Schnittstellen) Zeit- und Leistungsanforderungen (Durchsatz, Reaktionszeit, Verzögerung, Jitter, ggf. abhängig von der Last) Fehlertoleranz und Zuverlässigkeit Qualität (Abwesenheit von Fehlern) Sicherheit (Safety) im Sinne sicher funktionieren evtl. Plattform (Betriebssystem, Hardware) Leistungsverbrauch Kühlung Betriebsumgebung (Temperatur, Schock- und Staubresistenz usw.) Größe Mechanische Konstruktion Elektromagnetische Verträglichkeit (Tx/Rx) Wartbarkeit Erweiterbarkeit Support Dokumentation Kosten (Entwicklung, Erstellung und Betrieb) Datum der Fertigstellung => Einige Details u.s.w. folgen 5

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

7 Funktionale Anforderungen (2. Schritt) 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_TIMER WAIT i(n) * c1 OFF KEY_OFF or BELT _ON => END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF ALARM END_TIMER_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 Definition der Schnittstellen zur Umgebung (1. Schritt) Sicherheitsgurt-Steuerung FIR-Filter

9 Leistungsanforderungen Wichtige Leistungsanforderungen Kapazität (bearbeitbare Last) Antwortzeit/Reaktionszeit Jitter (z.b. zulässige Taktschwankungen) Beispiele für Leistungsanforderungen: Kapazität: Anzahl (und Art) von pro Sekunde verarbeiteter Anfragen Antwortzeit: Zeit, um ein Ergebnis zu erzielen (ggf. Wahrscheinlichkeit dafür) Die Leistung eines Systems hängt ggf. von seiner Last ab, d.h. dem Verkehrsmodell (Traffic model) Reaktionszeit Last Die Leistung hängt stark vom Entwurf ab, speziell vom Modul/Komponentenentwurf von verfügbare Verarbeitungs- und Kommunikationsressourcen von der Scheduling-Strategie Leistung kann typischerweise nicht während der Implementierungsphase zugefügt werden 9

10 Echtzeit (zeitliche) Anforderungen Brauchbarkeit des Resultats harte (hard) oder feste (firm) Echtzeitanforderung weiche (soft) Echtzeitanforderung deadline Zeit Definitionen: Wenn das Resultat auch nach der Deadline nützlich ist, heißt die Deadline weich. Wenn das Resultat nach der Deadline unbrauchbar ist, heißt die Deadline fest. Wenn die Nichteinhaltung der Deadline zu Katastrophen führt, heißt die Deadline hart. Der Systementwurf für Echtzeitsysteme mit harten und weichen Deadlines unterscheidet sich fundamental. 10

11 Echtzeitanforderungen Beispiele: Weiche Deadlines öffentliche Verkehrssysteme Flughafen-Gepäcktransportsystem Feste Deadlines Sprachverarbeitung Bildverarbeitung Harte Deadlines Steuerung von nuklearen oder chemischen Prozessen (Kettenreaktion) Airbag, ABS, ESP, Adaptive Cruise Control (ACC) Fly-by-wire, drive-by-wire,... 11

12 Echtzeitsysteme Klassifikation Aufgrund der externen Anforderungen harte/feste versus weiche Echtzeitanforderungen fail-safe vs. fail-operational (vgl. Zug-Steuerungssystem, Ampelanlage, fly-by-wire System) Aufgrund des Entwurfsprozesses bzw. der Implementierung Entwurf für garantierte Pünktlichkeit oder best effort ereignisgesteuerte vs. zeitgetaktete Echtzeitsysteme Angemessenheit der eingesetzten Ressourcen zum Umgang mit allen möglichen Lastsituationen und ggf. Fehlerszenarien 12

13 Zeitgetaktete (TT) vs. ereignisgesteuerte (ET) Systeme Ein System ist zeitgetaktet (TT) wenn die Steuerungssignale, wie z.b. das Senden und Empfangen von Nachrichten oder das Erkennen einer externen Zustandsänderung nur vom Fortschreiten einer (globalen) Zeitnotation abgeleitet sind. Ein System ist ereignisgesteuert (ET) wenn die Steuerungssignale vom Auftreten eines Ereignisses, z.b. Terminierung einer Aufgabe (task) Empfang einer Nachricht (message) externe Unterbrechung (interrupt) abgeleitet sind. Anmerkung: Die Taktungsmethode ist oft eine Eigenschaft der Implementierung und nicht notwendigerweise eine Anforderung. 13

14 Sicherheitsanforderungen: Fail-Safe vs. Fail-Operational Sicherheitsanforderungen definieren die Aktionen, die im Fehlerfall durchführbar bzw. durchzuführen sind. Ein System ist ausfallsicher (fail-safe) wenn in der Umgebung ein sicherer Zustand existiert, der im Fehlerfall erreicht werden kann, z.b. ABS, Zugsignalsystem, Straßenampeln. In einer fail-safe Anwendung muss ein Rechner eine hohe Fehlererkennungsrate (error detection coverage) haben. Fail-safeness ist eine Anforderung bzw. Charakteristik der Anwendung, nicht des Computersystems. Ein System ist betriebssicher (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. Flugsteuerung). In fail-operational Anwendungen muss das Computersystem auch nach dem Auftreten eines Fehlers ein minimales Service-Niveau garantieren. 14

15 Zuverlässigkeitsanforderungen Zuverlässigkeit beschreibt die Wahrscheinlichkeit des Auftretens oder der Abwesenheit von Systemfehlern Beispiele für Zuverlässigkeitsmaße MTTF (mean time to failure) reine Betriebszeit, ohne Instandsetzungszeit MTBF (mean time between failures) inkl. Instandsetzungszeit Wahrscheinlichkeit für fehlerfreien Betrieb (z.b %) Die Zuverlässigkeit des Systems kann (theoretisch) geschätzt bzw. aus der Zuverlässigkeit seiner Komponenten berechnet werden Anmerkung: 99,995% bei 1TByte Festplatte bedeuten fehlerhafte Byte! USB 3.0 theor. 5GBit/s % ok => Bit/s falsch! Ein System welches auch nach Ausfall bzw. Fehlfunktion von Komponenten noch korrekt funktioniert, heißt Fehlertolerantes System (fault tolerant system) Fail-safe/fail-secure: automatische Türen öffnen bzw. schließen bei Stromausfall 15

16 Vorhersehbarkeit seltener Ereignissen Ein seltenes Ereignis (rare event) ist ein wichtiges Ereignis, dass sehr selten zur Lebenszeit (lifetime) eines Systems auftritt, z.b. der Ausfall einer Leitung in einem Nuklearreaktor. Ein seltenes Ereignis kann eine Kette von Folgeereignissen (alarm shower) auslösen. In einer Anzahl von Anwendungen hängt der Wert des Systems von der vorhersagbaren Leistungsfähigkeit in Szenarien mit seltenen Ereignissen ab, z.b. Flugsteuerungssystem. Von typischen Lasttestverfahren werden seltene Ereignisse meist nicht berücksichtigt. 16

17 Prinzipien und Elemente der Analysemodelle 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, funktionales Modell, Verhaltensmodell) Priorisiere Anforderungen Eliminiere Unklarheiten und Mehrdeutigkeiten Elemente des Analysemodells: Wörterbuch mit Begriffsdefinitionen (Dictionary) Prozessspezifikation (Datenfluss Diagramm) Zustandsdiagramme (Zustandsautomaten) (Daten-)Objekt-Beschreibung (Entity-relationship Diagramm) Funktionale Spezifikation (Sequenzdiagramme) Spezifische Methoden und Werkzeuge existieren für verschiedenste Anwendungen: z.b. Echtzeitysteme, transformatorische Systeme, Steuerungssysteme, Kommunikationsprotokolle bzw. -Systeme, etc. 17

18 References H. Balzert: Lehrbuch der Software-Technik Band 1: Softwareentwicklung. Spektrum-Verlag, R. S. Pressman: Software Engineering A Practicioner s Approach. Eighth revised Edition, (siehe Kapitel zu Analyse Modeling) A. Mitschele-Thiel: Systems Engineering with SDL Developing Performance- Critical Communication Systems. Wiley, K. Pohl, C. Rupp: Basiswissen Requirements Engineering, dpunkt Verlag. Heidelberg,