Bewegung des Sitzes - Institut für Informatik

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
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 2
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.
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 3
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.
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 4
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.
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 5
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.
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 6
TSG: Weitere Bestandteile der Spec
• Form und Belegung der Stecker
• Charakteristik (Mechanik und
•
•
•
Elektrik) der Taster
Beschreibung der Beleuchtungselemente 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)
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 7
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 8
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 9
• 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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 10
das einfachste Beispiel
Zulauf
Füllstandsanzeiger
max
min
Ablauf
Variable
Typ
Beschreibung
Werteber
eich
Einheit
f
m
Füllstand
0-100
mm
z
c
Zulauf
0-1
prozentuale
Öffnung
Ablauf
0-1
nicht
zugänglich
a
min
konstant
Minimalfüllstand
86
mm
max
konstant
Maximalfüllstand
95
mm
Bemerku
ng
• informelle Anforderungen:
 Wenn f < min, Zulauf einschalten
 Wenn f > max, Zulauf ausschalten
• Stellvertretend für Heizungsthermostat, Batterieladegerät,
Dämmerungslicht, …
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 11
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 12
Zulauf
im Beispiel
Füllstandsanzeiger
max
min
• Randbedingungen
Ablauf
 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) = 1
f(t)  max  z(t) = 0
 als partielle Funktion
z(t) =
1
0
 undef
falls f(t)  min
falls f(t)  max
sonst
 als Abbildung
C ={(f(t), z(t)) | (f(t)  min  z(t) = 1)  (f(t)  max  z(t) = 0)}
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 13
Trajektorienbereiche
t
• intendierte, erlaubte und verboten
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 14
Zulauf
im Beispiel
Füllstandsanzeiger
max
min
Ablauf
• 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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 15
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 16
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
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 17
• 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: AB, BC, CB, BA
• Beschreibung von Modi?
 In jedem Modus können gewisse Konditionen
(engl. Condition: Aussage, Gegebenheit, Proposition)
zutreffen oder auch nicht
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 18
• 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)
H. Schlingloff, Software-Engineering II
4.11.2005
Folie 19