Eingebettete systeme qualit t und produktivit t
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

Eingebettete Systeme Qualität und Produktivität PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

Eingebettete Systeme Qualität und Produktivität. Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik. War wir bislang hatten. Einführungsbeispiel (Mars Polar Lander) Automotive Software Engineering

Download Presentation

Eingebettete Systeme Qualität und Produktivität

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Eingebettete systeme qualit t und produktivit t

Eingebettete SystemeQualität und Produktivität

Prof. Dr. Holger Schlingloff

Institut für Informatik der Humboldt Universität

und

Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik


War wir bislang hatten

War wir bislang hatten

  • Einführungsbeispiel (Mars Polar Lander)

  • Automotive Software Engineering

  • Anforderungsdefinition und -artefakte

  • Modellierung

    • physikalische Modellierung

    • Anwendungs- und Verhaltensmodellierung

    • Berechnungsmodelle, zeitabhängige & hybride Automaten

    • Datenflussmodelle (Katze und Maus)

  • Regelungstechnik

    • PID-Regelung

    • HW für Regelungsaufgaben

    • speicherprogrammierbare Steuerungen

  • Fehler und Fehlertoleranz

  • Qualitätsnormen


Sicherheits lebenszyklus

Sicherheits-Lebenszyklus

  • Analyse der Bedrohung durch das EUC

  • Ableitung von Sicherheitsanforderungen

  • Planung und Realisierung von Sicherheitsmechanismen

  • Validierung und Betrieb der Systeme


Gef hrdungs und risikoanalyse

Gefährdungs- und Risikoanalyse

  • Gefährdung: potentielle Schadensquelle

  • Risiko: Verbindung / Kombination der Auftretenswahrscheinlichkeit eines Schadens und des zugehörigen Schadensausmaßes

  • Auftretenswahrscheinlichkeit: der Parameter des Risikos, der Auskunft über die Wahrscheinlichkeit gibt, mit der eine identifizierte Gefährdung bzw. ihre Ursache in der Praxis tatsächlich auftreten könnte.

    • Eintrittswahrscheinlichkeit

    • Entdeckungswahrscheinlichkeit

    • Möglichkeit zur Gefahrenabwendung

  • Schadensausmaß: quantitatives Maß für die möglichen Folgen / Konsequenzen einer Gefährdung

  • Sicherheit: Freiheit von nicht akzeptablen Risiken

Risiko = Eintrittswahrscheinlichkeit * Schadensausmaß


Iec 61508 prozess

IEC 61508 Prozess


Risikoanalyse

Risikoanalyse

  • Risiko = Eintrittswahrscheinlichkeit * Schadensausmaß

    • z.B. Aktienkursverlust

  • Problem bei sehr kleinen und sehr großen Zahlen

    • sehr großer Schaden bei sehr geringer Wahrscheinlichkeit

  • Problem der numerischen Einschätzung

    • Kosten bei Personenschaden?

    • Wahrscheinlichkeit von Katastrophen?

  • akzeptabeles Risiko?

    • abhängig vom persönlichen Einfluss


Alarp

ALARP

  • ALARP-Prinzip: „As Low As Reasonably Possible“

    • Wenn ein Risiko mit vertretbarem Aufwand reduziert werden kann, sollte dies getan werden

    • Oft auch: Wenn das Risiko nicht reduziert werden kann, muss der Nutzen des Systems (Nutzungsdauer * Gewinn) den Schaden übersteigen

  • “Cost per life saved”


Automobil versus luftfahrtsicherheit

Automobil- versus Luftfahrtsicherheit

  • Katastrophen werden subjektiv höher gewichtet


Planes trains and automobiles

Planes, Trains and Automobiles

E. Schnieder: 4. Bieleschweig Workshop, 14.-15.9.04: NEUE UND HERKÖMMLICHE MAßE ZUR QUANTIFIZIERUNG DES RISIKOS IM EISENBAHNVERKEHR

Quelle: http://www.ifev.bau.tu-bs.de/Workshops_Tagungen/Bieleschweig/bieleschweig4/pdf/Bieleschweig4_Folien_Schnieder.pdf


Quantitative absch tzung

quantitative Abschätzung

  • Eintrittswahrscheinlichkeitsklassen

  • Schadensauswirkungsklassen


Risikomatrix

Risikomatrix

I: Unakzeptabel

II:Unerwünscht; nur tolerierbar falls Risikoverminderung nicht oder nicht mit vertretbarem Aufwand möglich

III: Tolerierbar falls die Kosten die Verbesserungen übersteigen

IV: Akzeptierbar, sollte möglicherweise überwacht werden


Sicherheitsanforderungsstufen

Sicherheitsanforderungsstufen

  • SIL: Safety Integrity Level


Beispiel

Beispiel

  • Sicherheitsanforderung:

    • When the hinged cover is lifted by 5 mm or more, the motor shall be de-energised and the brake activated so that the blade is stopped within 1 second. The safety integrity level of this safety function shall be SIL2.

  • Trennung von sicherheitsgerichteten und nicht sicherheitsrelevanten Forderungen!

    • Architekturprinzip!

    • Einfluss auf die SW-Architektur


Iec software safety lifecycle requirements

IEC Software safety lifecycle requirements

  • 7.1.2.1 A safety lifecycle for the development of software shall be selected and specified during safety planning

    • NOTE – A safety lifecycle model which satisfies the requirements of clause 7 of IEC 61508-1 may be suitably customised for the particular needs of the project or organisation

  • 7.2.2.2 The specification of the requirements for software safety shall be derived from the specified safety requirements of the E/E/PE safety-related system, and any requirements of safety planning (see clause 6). This information shall be made available to the software developer.

  • 7.2.2.8 The software safety requirements specification shall specify and document any safetyrelated or relevant constraints between the hardware and the software.

  • 7.3.2.1 Planning shall be carried out to specify the steps, both procedural and technical, that will be used to demonstrate that the software satisfies its safety requirements


Software design and development

Software design and development

  • 7.4.2.2 In accordance with the required safety integrity level, the design method chosen shall possess features that facilitate:

    a) abstraction, modularity and other features which control complexity;

    b) the expression of:

    – functionality,

    – information flow between components,

    – sequencing and time related information,

    – timing constraints,

    – concurrency,

    – data structures and their properties,

    – design assumptions and their dependencies;

    c) comprehension by developers and others who need to understand the design;

    d) verification and validation.


Softwarearchitektur forderungen

Softwarearchitektur-Forderungen

  • muss explizit dargestellt werden

  • muss in den Entwicklungszyklus eingebunden sein

  • muss zu den einzelnen Komponenten Erklärungen liefern

    • neu, reimplementiert, verifiziert, sicherheitsrelevant etc.

  • muss alle Schnittstellen enthalten

  • muss beschreiben wie die Datenintegrität gesichert wird

  • muss Integrationstests spezifizieren

  • kann werkzeugunterstützt verwaltet werden

    („To the extent required by the safety integrity level, …“)


Weiterer aufbau der forderungen

weiterer Aufbau der Forderungen

7 Software safety lifecycle requirements .......................................... 23

7.1 General ................................................................................... 23

7.2 Software safety requirements specification ................................ 35

7.3 Software safety validation planning ........................................... 39

7.4 Software design and development ............................................. 43

7.5 Programmable electronics integration (hardware and software) ... 55

7.6 Software operation and modification procedures.......................... 57

7.7 Software safety validation ......................................................... 57

7.8 Software modification................................................................ 61

7.9 Software verification ................................................................. 65

  • Anforderungsklassen

    • M = mandatory

    • HR = highly recommended

    • R = recommended

    • -- = no recommendation

    • NR= not recommended


Wrap up

Wrap-Up

  • Eingebettete Systeme als

    • gesellschaftlich enorm bedeutend

    • wirtschaftlich spannend

    • Motor der aktuellen Informatik-Entwicklung

  • Forschungsfragen

    • Multi-Core, Many-Core, SoC, NoC

    • neue Sensorik, Aktuatorik, Kommunikationswege (Zigbee)

    • Designprozesse, MBD, MBT, UML, OCL

    • Validierung, MBT, Analyse, Debugging

    • Zulassung & Zertifizierung, Reengineering, Security, gesellschaftliche Verantwortung


  • Login