Systems-Software-Engineering

Systems-Software-Engineering nach
Funktionale Sicherheit (ISO 26262) und Automotive SPICE

Anforderung ermitteln
Ziele, Anforderungen und Restriktionen an Ihr System ermitteln und geordnet umsetzen

Weiterlesen...

Struktur des Systems ordnen
Komplexität, Variantenvielfalt und Sicherheit Ihres Systems beherrschen

Weiterlesen...

Performance optimieren
Ihren Kunden unvergessliche Erlebnisse schenken

Weiterlesen...



Anforderungen ermitteln

An aller Anfang steht das Kundenproblem, das in verständliche und relevante Anforderungen übersetzt werden muss. In der Praxis erlebe ich immer wieder, wie für die einen Systemteile Pseudocode spezifiziert wird, wo das Problem noch gar nicht klar ist. Wiederum fehlen für andere Systemteile wichtige Vorgaben, z.B. zulässige Reaktionszeiten. Später in der Umsetzung steht das Team vor Widersprüchen, Unklarheiten und Konflikten, deren Ursprung teilweise in zwei Jahre alten Anforderungen liegt.

Ich entwickle mit Ihnen Ihre Anforderungen an die verschiedenen Systemebenen. Dabei ist entscheidend, dass Ihr Kunde, Ihr Team und Ihre Lieferanten die Anforderungen kennen und verstanden haben. Widersprüche löse ich auf und führe notwendige Entscheidungen herbei. Das ist die Grundlage für die wirksame und effiziente Umsetzung in den Teilsystemen und Komponenten.

IHR NUTZEN

  • Features und Anforderungen auf der richtigen Ebene, im richtigen Detail, im richtigen Umfang
  • Bewertete und abgestimmte Lasten und Pflichten
  • Klarheit, Verständnis und Akzeptanz im Team
  • Epics, Features, Stories und Tasks verknüpfen die Anforderungen mit der Umsetzung
  • ISO 26262 und Automotive SPICE sind erfüllt

Funktionale Sicherheit (ISO 26262)

  • Band 3: Safety Goals mit Fehlerreaktionszeiten (FHTIs)
  • Band 3: Funktionale Sicherheitsanforderungen
  • Band 3: Anforderungen an Other Technologies
  • Band 4: Technische Sicherheitsanforderungen
  • Band 5: Sicherheitsanforderungen an Hardware
  • Band 6: Sicherheitsanforderungen an Software

Automotive SPICE

  • SYS.1 Requirements Elicitation
  • SYS.2 System Requirements Analysis
  • SWE.1 Software Requirements Analysis
  • jeweils Verification Criteria
  • jeweils Verlinkung (Traceability)
  • jeweils Verification Review

Methodisch

  • Hazard Analysis & Risk Assessment
  • Anforderungsworkshops
  • Program Increment Planning
  • Umsetzung in einschlägigen Tools, z.B. DOORS, Polarion, CodeBeamer
  • Use Case Sichten
  • Requirements Sichten
  • Qualitätsszenarien (auch für FHTI)


Struktur des Systems ordnen

Kennen Sie das? Ihr Produktmanager möchte das System ausbauen, Varianten einfügen; die Entwicklung tut sich aber schwer mit der Erweiterung. Eine Änderung an einem Ende des Systems löst Probleme am anderen Ende aus. Meistens sind diese Systeme unzureichend gekapselt und strukturiert. Alles hängt mit allem zusammen. Erschlagende Komplexität, die Änderungen und Varianten verhindern.

Ich konstruiere die statische und die dynamische Struktur Ihres Systems von obersten Features bis zu konkreten Hardware-/Softwareblöcken. Die hierarchische Ordnung erlaubt, dass die sowohl Funktionen als auch personelle Zuständigkeiten klar zugewiesen sind und Änderungen sowie Integration deutlich vereinfacht werden.

IHR NUTZEN

  • Komplexität für die Fachdomänen wirksam reduziert
  • ASIL Dekomposition und Rückwirkungsfreiheit (Freedom from Interference) ermöglichen
  • Langfristig wartbares und erweiterbares System
  • Geordnete Anforderungen, Epics und Zuständigkeiten
  • Basis für Varianten- und Plattformentwicklung
  • ISO 26262 und Automotive SPICE sind erfüllt

Das Bild zeigt die Sichtweisen auf System-Architektur und Software-Architektur bestehend aus Kontext-Sicht, Laufzeit-Sicht, Komponenten-Sicht und Verteilungs-Sicht
Die typischen Sichtweisen auf Architekturen
(Angelehnt an Starke, G. (2015). Effektive Software-Architekturen: Ein praktischer Leitfaden. München: Carl Hanser.)
Hiearchical system architecture with 3 layer from kontext view over system concept to basis software
Hierarchisch geordnete Sichtweisen machen komplexe Zusammenhänge verständlicher.
(Angelehnt an Haberfellner, R., Fricke, E., de Weck, O., & Vössner, S. (2012). Systems Engineering : Grundlagen und Anwendung. Zürich: Orell Füssli.)
Das Bild zeigt eine einfache funktionale Regelstruktur zur Kraftberechnung
Funktionsprinzip eines Kraftreglers
(Eigene Darstellung)
Ausschnit einer Anforderunsspezifikation für Sicherheitskonzepte
Anforderungen beschreiben die zugehörigen Architektur-Elemente
(Eigene Darstellung.)
Das Bild zeigt Sicherheitsmechanismen mit zugehörigem ASIL-Level und Verteilung auf Hardware
Verteilung der ASIL-Funktionen nach ASIL-Level auf Hardware-Komponenten
(Eigene Darstellung)

         

Funktionale Sicherheit (ISO 26262)

  • Band 3: Item Definition
  • Band 3: Funktionale Sicherheitskonzept
  • Band 4: Technische Sicherheitskonzept
  • Band 4, 5, 6: Hardware-Software-Interface Specification
  • Band 5: Hardware Architektur
  • Band 6: Software Architektur
  • Band 9: ASIL Dekomposition

Automotive SPICE

  • SYS.3 System Architectural Design
  • SWE.2 Software Architectural Design
  • Entwurfsalternativen, wo notwendig
  • jeweils Verlinkung (Traceability)
  • jeweils Verification Review

 

Methodisch

  • Hierarchische Ordnung, Kapselung, Modularisierung, Kohäsion
  • Architekturworkshops
  • Visualisierung mit Sichtweisen
  • Umsetzung in einschlägigen Tools, z.B. Rhapsody, Enterprise Architect
  • Kontextsichten
  • Block- und Paketsichten
  • Laufzeitsichten
  • Verteilungssichten (Funktionen und Software auf Hardware zugewiesen)
  • Safety: Abschaltpfadkonzepte
  • Safety: ASIL Dekomposition


Performance optimieren

Qualität und Safety erkennt der normale Nutzer erst, wenn sie nicht vorliegen. Ein wesentlicher Aspekt ist dabei, dass ein System so schnell wie nötig reagiert. Nur dann hat der Nutzer ein erstklassiges Erlebnis. In der Safety kommt hinzu, dass Diagnosen in einer maximal zulässigen Dauer (FHTI) reagieren müssen, um Gefährdungen zu vermeiden. Wie aber übersetzt man Qualität in handhabbare und umsetzbare Arbeitspakete? Der Trick: das Laufzeitverhalten mit Qualitätsszenarien quantifizieren und die Umsetzung dagegen testen.

Ich entwickle für Ihr System Qualitätsziele und Qualitätsszenarien mit notwendigen Performance-Metriken. Durch wiederholte Tests ermitteln wir, wo der aktuelle Engpass liegt: Sind etwa Entpreller in den Signalstrecken inkonsistent? Werden die Systemressourcen kaum ausgereizt? Verursachen Fehlerreaktionen in verschiedenen Komponenten Deadlock-Situationen? Falls ja, ermitteln wir Engpässe und Stellschrauben sowie einen Umsetzungsplan. Wir optimieren das System so in iterativen Schritten.

IHR NUTZEN

  • Safety und Qualität im System erfüllt
  • Klarheit über Stellhebel und Roadmap
  • Transparente Status der IST-Performance
  • Auswirkung von Änderungen auf die Performance frühzeitig aufdecken
  • ISO 26262 ist erfüllt

Taktik zur Optimierung der Ressourcennutzung von Embedded Systemen: Die SW muss Flash, HDD, ROM und CPU des Systems voll auslasten
Taktik zur Performance-Optimierung: Solange die Software die Hardware-Ressourcen nicht voll nutzt, liegen die Engpässe im Laufzeitverhalten der Software.
(Eigene Darstellung)
Signalflussanalyse für eine hierarchische System-Architektur
Qualitätsmetriken: Qualität messbar machen.
(Eigene Darstellung)
Sequence-Chart für die Optimierung einer Fault Handling Time Interval Performance
Sequenz-Diagramm für Performance-Optimierung eines Sicherheitsmechanismus
(Eigene Darstellung aus internen Projekten)
Das Bild zeigt ein Dashboard für die Verbesserung von Qualitätsmetriken über mehrere Softwarestände
Realtime Dashboard für die Verbesserung des Fault Handling Time Intervals (FHTI)
(Eigene Darstellung aus internen Projekten)
Das Bild zeigt die zeitliche Entwicklung der Qualitätsmetrik Fault Handling Time Interval über mehrere Softwarestände
Entwicklungsziele sichtbar machen: Entwicklung der Qualitätsmetrik FHTI während einer Taskforce.
(Eigene Darstellung aus internen Projekten)

         

Funktionale Sicherheit (ISO 26262)

  • Fehlerdetektionszeiten (Fault Detection Time Interval)
  • Fehlerreaktionszeiten (Fault Reaction Time Interval)
  • Fehlerbehandlungszeiten (Fault Handling Time Interval)

Automotive SPICE

Verification Criteria für:

  • SYS.3 System Architectural Design
  • SWE.2 Software Architectural Design

Ressourcenverbrauch laut

  • SWE.1 Software Architectural Design
  • SWE.5 Software Integration and Test

Methodisch

  • Ressourcenmessung
  • Engpass-Analyse
  • Kontroll- und Signalflussanalyse
  • Schaltplan-, Code-, Modellreview
  • Visualisierung mit Sichtweisen
  • Automatisierte Berichterstellung
  • Block- und Schnittstellensichten
  • Laufzeitsichten
  • Safety: Abschaltpfadanalyse

Was Sie bekommen

  • Eine einzigartige Kombination an Erfahrungen: Aus über 15 Jahren in Safety-, Engineering- und Krisenprojekten. Aus der Entwicklung komplexer Systeme wie eAchsen, Inverter, KI-gestützte Instrument Cluster.
  • Aus der langjährigen Führung eines Ingenieursbüros für die Automotive Produktentstehung. Professionell im Handwerk, zupackend im Handeln, beherzt für die gemeinsame Sache.

Nächste schritte

Erzählen Sie mir von Ihrem Projekt

Wir lösen komplexe Probleme zu Ihrer Zufriedenheit.