Prof. Dr. Holger Schlingloff

Slides:



Advertisements
Ähnliche Präsentationen
Benutzerorientierte Designprinzipien für die Microsoft-Guidelines
Advertisements

Prüfung objektorientierter Programme -1
Integrations- und Funktionstests im Rahmen des V-Modelles
Submodell Softwareentwicklung (SE)
Das V - Modell - Überblick
Informatik 12 | DAES Compilerbau Wintersemester 2010 / 2011 Dr. Heiko Falk Technische Universität Dortmund Lehrstuhl Informatik 12 Entwurfsautomatisierung.
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Eingebettete Systeme Qualität und Produktivität
Prof. Dr. Holger Schlingloff
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software-Entwicklung eingebetteter Systeme
Eingebettete Systeme Qualität und Produktivität
Die Softwarelebenszyklen
Das „Vorgehensmodell“
Kooperierende autonome Fahrzeuge
Inhaltsverzeichnis Einleitung zum Thema Was ist ein Lastenheft?
Konzeption und prototypische Implementierung eines zentralen Informationssystems für Systemmanagement Motivation Oft wird es schwierig, die benötigten.
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Modellbasierte Software-Entwicklung eingebetteter Systeme
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Eingebettete Systeme Qualität und Produktivität
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Eingebettete Systeme Qualität und Produktivität
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.
Prof. Dr. Holger Schlingloff
Schulung der Mitarbeiter
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Die SE Umgebung des Jahres 2003 am IKE Elemente der SE Umgebung –Omondo als Casetool.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
Java: Objektorientierte Programmierung
Die Beschreibung der Insula Ostia in XML
Der Testprozess als Bestandteil des SE Prozesses:
Vortrag 11: Reengineering - Refactoring
Erzeugung von Fahrgemeinschaftsplänen für Lehrer
Kennlinie Lichtregelung in JavaNNS Version 1.1
Simulation komplexer technischer Anlagen
Vorgehensmodelle: Schwergewichtige Modelle
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
Spezifikation von Anforderungen
Software-Projektführung
Das Wasserfallmodell - Überblick
Software Engineering SS 2009
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Das Pflichtenheft Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth
Steuerung externer Komponenten über ein USB-Interface.
Was macht eigentlich dieses ExsoForm? Ein Beispiel für eine Dokumentendefinition in Screenshots.
REQUIREMENTS ENGINEERING
IT-Projektmanagement SS 2013 Prof. Dr. Herrad Schmidt
Software-Technik „Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige.
UML-Kurzüberblick Peter Brusten.
Wasserfallmodell und Einzelbegriffe
Modellbildung und Simulation
Modellbasierte Software-Entwicklung eingebetteter Systeme
Software Engineering Grundlagen
Technische Universität München Zentralübung Automotive Software Engineering – Übungsblatt 6.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Kurze Rekapitulation aus der Einführungsvorlesung Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 20. Oktober 2011.
Software-Entwicklung
0 © 2015 Fujjitsu Aktivierung des Support Pack & SolutionPack Product Support Services.
 Präsentation transkript:

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 2.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 2.11.2005

1.2 Anforderungsanalyse rigorose Spezifikation der Anforderungen Vergleich zum Vorgehen eines Ingenieurs Plan auf Papier Analyse des Plans Bau des Systems Software informelle Anforderungen Implementierung Test und Dokumentation Das kann‘s nicht sein! Wie werden Anforderungen systematisch erfasst und beschrieben? Wie fließen sie in den Entwurf ein? 2.11.2005

Projektbeschreibung (Vorstudie) Vor Start irgendeines Projektes wird ermittelt Umfeld Markterfordernisse, Kundenwünsche Konkurrenzsituation, Time-to-market Integration vorhandener Produkte sonstige Randbedingungen Kosten (Entwicklung / Fertigung) Energieverbrauch, Leistungsanforderungen Kritikalität, Zuverlässigkeit, … Siehe Projektmanagement (später) Erstellung von Lasten- und Pflichtenheft 2.11.2005

Systemspezifikation (Lastenheft) vom Auftraggeber erstellt oder verantwortet zur Erstellung eines Angebotes oder Planes für die Produktentwicklung (Hardware und Software) und die Serienproduktion Grundlage für Systemarchitektur (Pflichtenheft) verbindliche Vorgabe zur Entwicklung des Systems Alle Abweichungen bedürfen der Schriftform und Genehmigung Bei Unklarheiten sofortige schriftliche Klärung Bei eingebetteten Systemen Grundlage für Software-Spezifikation und -Architektur 2.11.2005

Softwarespezifikation (Pflichtenheft) Auftragnehmer- bzw. Entwicklersicht Beschreibung der gewählten Realisierung Enthält HW/SW-Aufteilung, soweit sie nicht schon im Lastenheft vorgegeben ist Enthält Architekturpläne, Moduldekompositionen, Schnittstellenbeschreibungen usw. Wird an Hand des Lastenheftes erstellt Bildet die Anforderungen der Systemspezifikation vollständig und nachprüfbar (!) ab Grundlage aller nachfolgenden Entwicklungen Wird im Zuge der Produktentwicklung fortgeschrieben (Änderungsmanagement!) Bestandteil der Systemdokumentation 2.11.2005

nächster Schritt: formale Modellierung Erstellung von graphischen Modellen des Systems (Struktur und Verhalten) viele denkbare Modellierungssprachen UML hat viel Potential (Profile für Embedded) Analyse der Modelle Prüfung der Anforderungen (Validierung) Simulation und Test, Optimierungen Verifikation von Eigenschaften des Modells nachfolgende Entwicklungsschritte an Hand der Modelle traditionell: Codierung gemäß der Modellvorgaben „modellbasierte Entwicklung“: Verfeinerung, automatische Code-Erzeugung, automatische Testgenerierung 2.11.2005

Probleme Systematischer Umsetzungsprozess Bruch: Übergang von natürlicher Sprache (informell) in Maschinensprache (formal) Mehrdeutigkeiten, Unterspezifikation, Überspezifikation und Inkonsistenz Repräsentation von Randbedingungen Effizienz, Leistung (Energieverbrauch, Durchsatz, Fehlertoleranz, Codegröße, Allokation, …) Wiederverwendung von Komponenten Wie werden Anforderungen konsistent verknüpft? Produktlinienentwicklung 2.11.2005

Pause! 2.11.2005

Beispiel: Das Türsteuergerät (TSG) http://www.iese.fhg.de/pdf_files/iese-002_02.pdf (lesen!) Beispielspezifikation in FhG-Projekt (FIRST+IESE) State-of-the-Art, hinsichtlich Systemkomplexität und Beschreibungstiefe an reale Spezifikationen angelehnt reale Spezifikation eines fiktiven Türsteuergerätes, welches sich in den Hohlräumen der Türen von Kraftfahrzeugen befindet und Funktionen wie das Verstellen der Außenspiegel, Fenster und Sitze oder das Verriegeln der Fahrzeugtüren übernimmt. 2.11.2005

2.11.2005

Inhalt TSG-Spec 2.11.2005

Inhalt TSG-Spec (Fortsetzung) 2.11.2005

TSG: Randbedingungen Absatzmarkt Terminplan Entwicklungsablauf Der Einsatz der beschriebenen Komponente ist für die Baureihen … geplant. Die Fahrzeuge sollen weltweit vertrieben werden. Dazu muss die Komponente für die Varianten USA, Kanada, Großbritannien, Golfstaaten, Europa und Japan konfigurierbar sein. Terminplan Die Markteinführung ist für das 3. Quartal 2003 geplant. Die erwarteten Stückzahlen (für alle drei Baureihen) betragen ca. 20.000 Einheiten pro Jahr Entwicklungsablauf Angaben zum Entwicklungsablauf, beispielsweise beteiligte Personen, Hinweise zu Prototypen (wann werden wieviel Prototypen geliefert), Angaben zur Produktbewertung und Abnahmeprozesse 2.11.2005

TSG: Standards und Vorgehensmodelle Verweise auf interne und externe Standards, die im Zuge der Entwicklung zu beachten sind Beispiele: EMV Spezifikationen, DIN für Klemmenbezeichnung in Kraftfahrzeugen, IEC 61508 für Sicherheitsanforderungen, Automotive Spice für Vorgehensmodelle Regelungen u.a. für Unterauftragnehmer und Zulieferer, einzuhaltende Vorschriften, durchzuführende Tests, Dokumentation, Archivierung usw. 2.11.2005

TSG: physikalische Anforderungen Produktionsanforderungen Dieser Abschnitt beinhalten Angaben im Kontext der Produktion der Komponente und beschreibt beispielsweise Anforderungen zum Fertigungsprozess, zur Bereitstellung von Ersatzteilen, zur Reparatur von Komponenten, zur Gewährleistung, zu erlaubten und verbotenen Materialien sowie zum Recycling von Komponenten Betriebsanforderungen Einsatzprofil: z.B. Betriebsstunden pro Jahr, Fahrleistung des Fahrzeugs, wie oft die Komponente aktiviert wird etc. Elektromagnetische Verträglichkeit: Anforderungen, die über den generellen Firmenstandard hinausgehen; z.B. muss eine Komponente 400 Störspannungimpulse á 30V überstehen Physikalische Eigenschaften: Verhalten im Hinblick auf Umwelteinflüsse wie z.B. Vibration, Temperatur und Temperaturwechsel oder Luftfeuchtigkeit Lagerfähigkeit und Verpackung 2.11.2005

TSG: geforderte Dokumentation Als Nachweis für die Einhaltung der Spezifikationsvorgaben sind nachfolgend genannte Dokumentationen dem Auftraggeber vorzulegen. Werden keine anderen Vereinbarungen getroffen, sind alle Dokumente als PDF–Dateien abzuliefern. Hardwaredokumentation Konstruktionszeichnung, Schaltplan, Bestückungsplan, Teileliste FMEA, Ergebnisse EMV-Messungen Steckerbelegungen Softwaredokumentation Flashbare Binärfiles, Anleitung zum Flashen eines neuen Softwarestandes Programmlistings, Ablaufplan der Software, Modulbeschreibung, Softwarearchitektur, Interruptstruktur, Variablenbeschreibung mit Normierung und Wertebereich QS-Plan, Dokumentation der verwendeten Softwarewerkzeuge (Version, Patches, etc.), Nachweis der durchgeführten Prüfaktivitäten (Inspektions- und Testprotokolle) 2.11.2005

TSG: Beschreibung der Funktionalität Das TSG übernimmt folgende Funktionen im Fahrzeug: Sitzeinstellung Verstellen des Lehnenwinkels, der horizontalen Sitzposition, der Höhe des vorderen Sitzbereichs, der Höhe des hinteren Sitzbereichs und der Schalung des Sitzes Benutzermanagement Benutzerspezifisches Abspeichern von Sitz- und Außenspiegelposition Türschloß Auf- und Zuschließen des Fahrzeugs über Schlüssel, Funksender oder CAN Fensterheber Heben und Senken der Fensterscheiben des Fahrzeugs unter Beachtung einer etwaigen Kindersicherung Innenraumbeleuchtung Beleuchtung des Fahrzeuginneren als Hilfe beim Ein- und Aussteigen Außenspiegeleinstellung Verstellen der Außenspiegel entlang einer horizontalen und einer vertikalen Achse 2.11.2005

TSG-Aufbau (Benutzersicht) 2.11.2005

TSG: Aktivierung und Initialisierung Aktivieren: Das TSG wird geweckt, wenn eines der folgenden Ereignisse eintritt: Fahrertür oder Beifahrertür wird geöffnet CAN–Bus wird geweckt Anheben der Türgriffleiste (Eingang T GRIFF wird gegen Masse geschaltet) Schlossnussschalter schaltet Ab dem Zeitpunkt, zu dem das TSG geweckt wird, ist die Batteriespannung (BATT) zu überwachen. Ist die Batteriespannung innerhalb der ersten 2 sec. immer unter 8V, so legt sich das TSG nach diesen 2 sec. sofort wieder schlafen. Ist ausreichend Spannung vorhanden (d.h. BATT>8 V), wird der CAN-Bus geweckt (aktiviert) und damit werden auch die anderen Steuergeräte am Innenraumbus geweckt. Grundinitialisierung: Bei Inbetriebnahme prüft das TSG, ob sich die Funktionssoftware in einem integren Zustand befindet und die Konfiguration gültig ist (z.B. durch Prüfsummenberechnung). Kann die Integrität der Funktionssoftware nicht festgestellt werden, setzt das TSG eine interne Fehlermarke und legt sich sofort wieder schlafen. Solange das TSG aktiv ist (siehe auch Abschnitt 6.1), werden zyklisch die angegebenen CAN–Botschaften gesendet. Zykluszeiten und Werte der Signale finden sich im Abschnitt 4. 2.11.2005

TSG-Sitz: Benutzungsspezifikation 2.3 Sitzeinstellung Vor dem Antritt einer Fahrt kann der Benutzer den Sitz gemäß seinen Anforderungen einstellen. Er hat dabei folgende Einstellmöglichkeiten den Winkel, in dem die Sitzlehne steht, die Entfernung des Sitzes vom Lenkrad, die Höhe des hinteren Sitzbereichs, die Höhe des vorderen Sitzbereichs und die Schalung des Sitzes Die Möglichkeit der Sitzeinstellung wird auch dem Beifahrer angeboten Einstellung der Sitzpositionen ist nur bei geöffneter Tür möglich Detailanforderungen in nachfolgender Verhaltensbeschreibung 2.11.2005

TSG-Sitz: Schnittstellen 6.3 Sitzeinstellung Eingänge Konfiguration des TSG: CAN.LL, CAN.RL, CONFIG.TSG_LEFT Zustand der Vordertür S1.T_OFFEN Sitzbedienungstasten S2.SITZ_HOR, S2.SITZ_V, S2.SITZ_H, S2.SITZ_S, S2.SITZ_W Sitzposition S2.SPOS_HOR, S2.SPOS_V, S2.SPOS_H, S2.SPOS_S, S2.SPOS_W Batteriespannung CAN.BATT Fahrzeuggeschwindigkeit CAN.FZG_V Konfiguration Sitzeinstellung CONFIG.SITZ_F, CONFIG.SITZ_BF Intern gibt es eine Verbindung zum Benutzermanagement Ausgänge Sitzmotoren S2.SMOT_HOR1, S2.SMOT_HOR2, S2.SMOT_V1, S2.SMOT_V2 S2.SMOT_H1, S2.SMOT_H2, S2.SMOT_S1, S2.SMOT_S2 S2.SMOT_W1, S2.SMOT_W2 Warnmeldung CAN.B_LOW_SITZ 2.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. 2.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. 2.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. 2.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. 2.11.2005