Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

19
4.11.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

description

Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement. Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik. Übersicht. 0. Einleitungsbeispiel (Mars Polar Lander) - PowerPoint PPT Presentation

Transcript of Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Page 1: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

4.11.2005

Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement

Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität

und

Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Page 2: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 2H. Schlingloff, Software-Engineering II 4.11.2005

Übersicht

•0. Einleitungsbeispiel (Mars Polar Lander)

•1. Eingebettete Systeme 1.1. Definitionen (eingebettetes System,

Realzeit, Prozess, Steuerung, …) 1.2. Anforderungsanalyse

- allgemeine Vorgehensweise

- Beispiel Türsteuergerät

- systematische Ansätze

Page 3: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 3H. Schlingloff, Software-Engineering II 4.11.2005

TSG-Sitz: Verhaltensbeschreibung (1)

• Generell: Die Sitzeinstellung kann nur verwendet werden, wenn das entsprechende Konfigurationsbit gesetzt ist.

• Ein Verstellen der Sitzposition über die Sitztaster ist nur möglich, wenn die dem TSG zugeordnete Vordertür geöffnet ist (F_OFFEN = 1). Das Verstellen der Sitzposition über das Benutzermanagement (betrifft nur Fahrerseite) ist auch bei geschlossener Tür möglich.

• Die Sitzposition wird entweder entsprechend der vom Benutzermanagement gesendeten Positionsangaben oder den Sitztasten eingestellt. Dabei gilt das Prinzip, dass immer die zuletzt benutzte Taste (Benutzermanagement oder Sitztaste) die Bewegung des Sitzes bestimmt.

• Ist die Batteriespannung BATT während der Sitzverstellung kleiner als 10V, so werden die Sitze nicht bewegt bzw. wird die Sitzbewegung abgebrochen. Statt dessen wird die Meldung B_LOW_SITZ = 1 generiert.

Page 4: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 4H. Schlingloff, Software-Engineering II 4.11.2005

TSG-Sitz: Verhaltensbeschreibung (2)

• Bewegung des Sitzes: Zur Bewegung des Sitzes werden die in Tabelle 3 (Seite 19) angegebenen Spannungen auf die Sitzmotoren gelegt. Die Bewegung wird solange durchgeführt wie Ist–Wert und Soll–Wert nicht übereinstimmen (bei Anfahren einer Sitzposition über das Benutzermanagement) bzw. die Sitztasten gedrückt werden (bei Verstellen der Sitzposition über die Sitztasten) und der Wert der Sitzposition keine Unterbrechung erkennt.

• Bewegung über Sitztasten: Bei der Verwendung der Sitztasten können maximal zwei Bewegungsrichtungen gleichzeitig verwendet werden. Wird während der Sitzverstellung über die Sitztasten eine Taste des Benutzermanagements gedrückt, so wird die Sitzverstellung über Tasten abgebrochen und die Sitzverstellung über das Benutzermanagement begonnen.

• Bewegung über Benutzermanagement: Die Sitzverstellung über das Benutzermanagement ist nur möglich, solange die Fahrzeuggeschwindigkeit (FZG V) kleiner als 5 km/h ist. Überschreitet die Fahrzeuggeschwindigkeit 5 km/h, so wird die Sitzbewegung sofort abgebrochen.

Page 5: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 5H. Schlingloff, Software-Engineering II 4.11.2005

TSG-Sitz: Verhaltensbeschreibung (3)

Es sind zwei Fälle zu unterscheiden:• Fall 1: (Auswahl einer Einstellung über Benutzermanagementtaste)

In diesem Fall ist anzunehmen, dass der Fahrer bereits auf dem Fahrersitz sitzt. Um die Bewegung so angenehm wie möglich zu gestalten, sind folgende Regeln bei der Ansteuerung der Sitzposition zu beachten: Zuerst werden die Bewegungen durchgeführt, die eine

Entspannung der Sitzposition zur Folge haben, d.h. das Vergrößern der Entfernung Sitz–Lenkrad, das Flacher–Stellen des Lehnenwinkels, das Absenken der Sitzfläche (vorne und hinten) sowie das Öffnen der Schalung.

Anschließend werden die entgegengesetzten Bewegungen durchgeführt.

Es dürfen zu einer Zeit maximal zwei Richtungen gleichzeitig bewegt werden. Dabei gilt die Reihenfolge Entfernung Sitz–Lenkrad, Lehnenwinkel, Schalung, Sitzfläche vorne, Sitzfläche hinten.

Page 6: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 6H. Schlingloff, Software-Engineering II 4.11.2005

TSG-Sitz: Verhaltensbeschreibung (4)

• Fall 2: (Auswahl einer Einstellung über Funksender)In diesem Fall soll die gewünschte Sitzposition so schnell wie möglich eingenommen werden. Dazu werden alle Sitzmotoren gleichzeitig angesteuert. Fehler: Wird während der Ansteuerung eines Sitzmotors über

den Zeitraum von 1 sec. keine Änderung des entsprechenden Positionswerts beobachtet, so wird die Ansteuerung des Motors beendet und der Fehlercode 0x31 in den Fehlerspeicher eingetragen.

Timeout: Wird ein Timeout der CAN–Botschaft FGZ_V erkannt, so wird der Fehlereintrag 0x14 gesetzt. Für die weitere Arbeitsweise des TSG wird angenommen, dass die Geschwindigkeit 10 km/h beträgt, bis die CAN–Botschaft wieder vorliegt.

Page 7: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 7H. Schlingloff, Software-Engineering II 4.11.2005

TSG: Weitere Bestandteile der Spec

• Form und Belegung der Stecker• Charakteristik (Mechanik und

Elektrik) der Taster• Beschreibung der Beleuchtungs-

elemente und Motoren• Bussysteme (CAN-B) und –Signale• Elektrische und mechanische Spezifikation

Betriebsspannung, Stromverbrauch, Ruhestrom Gehäuseabmessungen, Befestigungspunkte

• Speicher Daten im Permanentspeicher Fehlerspeicher Prüfroutinen (BIST)

Page 8: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 8H. Schlingloff, Software-Engineering II 4.11.2005

Und jetzt wieder zum Elfenbeinturm

• In der Praxis werden solche Dokumente aus bereits vorhandenen Vorlagen durch Änderung einzelner Teile erstellt. Unsystematische Vorgehensweise Mischung vieler Belange Möglichkeit von Auslassungsfehlern

• Requirements-Management-Systeme unterstützen die Aufschreibung und Verfolgung von

Anforderungen (Hyperlinks) unterstützen nicht die systematische Erstellung

und die formale Semantik von Anforderungen

Page 9: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 9H. Schlingloff, Software-Engineering II 4.11.2005

Systematik: Erstellung des Lastenheftes

1. Identifikation der relevanten Umgebungsgrößen physikalische Eigenschaften: Masse, Druck, Temperatur,

… gewünschte Benutzungsschnittstelle: Schalter, Displays,

Interaktionsformen

2. Repräsentation durch mathematische Variablen wichtig: Verbindung zwischen Variablen und ihrer

Bedeutung genau dokumentieren! (z.B. Länge in m, mm oder in)

3. Eigenschaften der Variablen festlegen mögliche Wertebereiche, Randbedingungen Relationen zwischen den Variablen

Page 10: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 10H. Schlingloff, Software-Engineering II 4.11.2005

• Die relevanten Variablen sind im Allgemeinen zeitabhängig Funktionen über der Zeit! Zustand: Wert aller Funktionen zu einem gegebenen

Zeitpunkt Trajektorie: Veränderung des Zustandes in der Zeit

• Festlegung: überwachte und geregelte Variablen („monitorierte“ und „kontrollierte“ Größen) geregelte Variable: Wert wird von der Regelung

eingestellt überwachte Variable: Wert beeinflusst das

Systemverhalten Achtung: manche Umgebungsgrößen sind beides! Realzeitsystem: Uhrzeit ist überwachte Größe

Page 11: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 11H. Schlingloff, Software-Engineering II 4.11.2005

das einfachste Beispiel

• informelle Anforderungen: Wenn f < min, Zulauf einschalten Wenn f > max, Zulauf ausschalten

• Stellvertretend für Heizungsthermostat, Batterieladegerät, Dämmerungslicht, …

Füllstandsanzeiger

Zulauf

Ablauf

max

min

Variable Typ BeschreibungWertebereich Einheit

Bemerkung

f m Füllstand 0-100 mm  

z c Zulauf 0-1  prozentuale

Öffnung

a   Ablauf 0-1  nicht

zugänglich

min konstant Minimalfüllstand 86 mm  

max konstant Maximalfüllstand 95 mm  

Page 12: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 12H. Schlingloff, Software-Engineering II 4.11.2005

Festlegung in Systemspezifikation

• Randbedingungen von der Natur oder vom Auftraggeber vorgegeben

- z.B. physikalische Beschränkungen

- z.B. Altsysteme, zu beachtende Restriktionen etc.

Verantwortlichkeit des Auftraggebers!

• Steuerfunktionalität Abbildung von überwachten in gesteuerte Größen i.A. mehrdeutig, relational; Definitionsbereich von

Randbedingungen eingeschränkt, Wertebereich gibt zulässige Trajektorien an

Verantwortlichkeit des Systemingenieurs

Page 13: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 13H. Schlingloff, Software-Engineering II 4.11.2005

im Beispiel

• Randbedingungen 0 f(t) h 0 < f(t) < h f´(t)= k1*z(t) – k2*a(t)

• Steuerfunktionalität als Klauseln

f(t) min z(t) = 1f(t) max z(t) = 0

als partielle Funktion 1 falls f(t) min

z(t) = 0 falls f(t) max undef sonst

als AbbildungC ={(f(t), z(t)) | (f(t) min z(t) = 1) (f(t) max z(t) =

0)}

FüllstandsanzeigerZulauf

Ablauf

max

min

Page 14: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 14H. Schlingloff, Software-Engineering II 4.11.2005

Trajektorienbereiche

• intendierte, erlaubte und verboten

t

Page 15: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 15H. Schlingloff, Software-Engineering II 4.11.2005

im Beispiel

•Zulauf sei kontinuierlich regelbar (0 z(t) 1); der Füllstand sollte möglichst nahe an max gehalten werden intendiertes Verhalten: je näher der Füllstand

bei max ist, desto mehr wird der Zulauf geschlossen

erlaubtes Verhalten: voller Zulauf bis max erreicht wird, dann zu (ruiniert auf Dauer das Ventil)

verboten: max wird irgendwann überschritten

FüllstandsanzeigerZulauf

Ablauf

max

min

Page 16: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 16H. Schlingloff, Software-Engineering II 4.11.2005

Black-Box-Sicht

• Die Systemspezifikation darf nur die nach außen sichtbaren Größen (überwachte und gesteuerte Variablen) verwenden! interne Variablen der Regelung versteckt, interne

Zustände nicht sichtbar Implementierungsfreiheit

Page 17: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 17H. Schlingloff, Software-Engineering II 4.11.2005

mathematische Verhaltensbeschreibung

• Wdh.: Zustand = Wert aller relevanten Variablen zu einem gegebenen Zeitpunkt Zustand der Umgebung ist für das System (nur)

durch überwachte Variablen gegeben Systemzustand setzt sich aus überwachten,

gesteuerten und internen Variablen zusammen Ein Realzeitsystem (Zeit ist überwachte Größe)

kehrt niemals in den selben Zustand zurück

• Modus (engl.: mode) Menge von „äquivalenten“ Zuständen

• Modalpartitionierung (mode class) Partitionierung der Menge der Zustände in Modi

Page 18: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 18H. Schlingloff, Software-Engineering II 4.11.2005

• statt Zustandsübergängen betrachten wir Übergänge von einem Modus in einen anderen

• Im Beispiel Umgebungszustand=Füllhöhe f(t) Modalpartitionierung={A:f(t)min,

B:min<f(t)<max, C:f(t)max} mögliche Moduswechsel: AB, BC, CB, BA

• Beschreibung von Modi? In jedem Modus können gewisse Konditionen

(engl. Condition: Aussage, Gegebenheit, Proposition) zutreffen oder auch nicht

Page 19: Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

Folie 19H. Schlingloff, Software-Engineering II 4.11.2005

• Def. Kondition: boolesche Funktion über der Zeit, die mit Hilfe von Umgebungsvariablen definiert ist Beispiel: voll(t) = f(t)max, leer(t) = f(t)min

• Def. Ereignis (event): Umschalten einer oder mehrerer Konditionen , : Schalten auf wahr bzw. auf falsch Beispiel: voll(7): max wird zum Zeitpunkt 7 erreicht

• Def. Historie: Folge von Ereignissen Für jeden konkreten Systemablauf gibt es genau eine Historie endliche Variabilität: In jedem endlichen Zeitabschnitt

passieren nur endlich viele Ereignisse (non-Zeno-Eigenschaft)

• Der Modus eines Systems wird durch den Anfangszustand und die Historie eindeutig bestimmt Beispiel: voll(7), voll(9), leer(13), leer(16)