SysLand - FuSi bei einem Automobilhersteller
Bei einem großen Automobilhersteller kümmern wir uns um die Konzeption und die Werkzeugkette zur Modellierung funktionaler Wirkketten im Kontext der funktionalen Sicherheit (FuSi) gemäß ISO-Norm 26262.
Anforderungen des Kunden
- Nutung von UML und Enterprise Architect
- Import aus bestehenden Quellen
- Verlinkung in EA mit Komponenten und Systemen
- Export nach DOORS
- Relativ großer Nutzerkreis
- Grafische Erarbeitung der FuSi
- DOORS-Links werden in EA angelegt
- Spezifische Wirkkette je Sicherheitsziel
- Einheitliche und prüfbare Modellierung
SysLand - FuSi bei einem Automobilhersteller
Fakten
Das Projekt basiert auf unserem Framework (Bausteine und Bibliothek) PI-Mobile.
Aufgabenstellung
- Erarbeitung des Modellierungskonzepts
- Umsetzung auf Basis von Enterprise Architect
- Implementierung des Werkzeugkastens "SysLand3 Toolbox"
- Unterstützugn beim Import bestehender Modellierungen
Import aus bestehenden Quellen
- Abtippen vermeiden
- Zeitersparnis
- Keine „Fipptehler“
- Konsistenz
- Allokation nur auf existierende Komponenten und Systeme möglich
- Verwendete Signale existieren auch wirklich
- Beim Update werden Differenzen angezeigt
- Basis zum Erzeugen von Links beim Export
- Beispiele
- DOORS RD-Systemliste
- DOORS RD-Komponentenliste
- DOORS Projektspezifische Komponenten
- Excel Signalliste (z. B. K-Matrix)
Verlinkung in EA mit Komponenten und Systemen
- Allokation von Funktion auf Komponente bzw. System
- Komponenten und Systeme werden von DOORS importiert
- Funktion wird in EA angelegt und auf DOORS-Komponente bzw. -System verlinkt
- Verknüpfung von FuSi-Requirement mit Funktion
- FuSi-Requirement wird in EA angelegt und einer Funktion zugeordnet
- Requirement ist indirekt über Funktion dem System bzw. der Komponente zugeordnet
- FuSi kann komplett in EA erarbeitet werden
- Export erzeugt DOORS-Kapitel inkl. Links auf DOORS-Komponenten bzw. -Systeme
Export nach DOORS
- Erstellung des FuSi-Kapitels im Lastenheft inkl. Verlinkung (Pfeile und )
- Requirements und DOORS-Struktur werden in EA erzeugt
- Ein Teil des EA-Modells spiegelt die DOORS-Struktur exakt wieder
- Requirement ist indirekt über Funktion dem System bzw. der Komponente zugeordnet
- Unterstützung des DOORS Bereitstellungs-prozesses
- Beim Export von EA nach DOORS werden auch Links auf DOORS-Komponenten bzw. -Systeme mit erzeugt
- Safety-Goal (Feld )
- Verification-Criteria (Feld )
- Safe-State (Feld )
- Other References (Feld )
- Safety-Requirements in DOORS
- Link auf Komponente/System über Funktionsallokation
- Textspalten für interne Links
- Function (Feld )
- Hilfsmittel
- Finde EA-Element in DOORS und umgekehrt (siehe Pfeile bis )
Relativ großer Nutzerkreis
- Gemeinsames Werkzeug: SysLand Toolbox
- Vereinfacht den Umgang mit EA
- Komplexität der Modellierung teilweise verborgen
- effektiveres Arbeiten (weniger Klicks)
- Schnittstellen zu DOORS, Excel
- mächtige Funktionen basieren auf Standard-UML (Portierbarkeit)
- Installation erfordert keine Admin-Rechte
- Erfahrungsaustausch
- PI-Data stellt Brücke zwischen den Nutzern dar
- Hohe Tool-Qualität durch größeren Nutzerkreis
- Nutzer
- FuSi: 4 Projekte
- Entwicklung Fahrassistenzsysteme
- Entwicklung Steuerung Hybrid-Motoren
Grafische Erarbeitung der FuSi
- Bessere Übersicht in EA im Vergleich zu DOORS
- DOORS-Links werden in EA angelegt
- Erstellung der Wirkkette
- Funktion
- Allokation auf Komponenten
- Signalfluss
- gliedernde Funktionen, z. B. je Steuergerät
Spezifische Wirkkette je Sicherheitsziel/Safety-Goal
- spezifische Sicht je Sicherheitsziel
- ASIL-Einfärbung je Sicherheitsziel
- irrelevante Funktionen ausblenden
- Änderungen an der Master-Wirkkette werden automatisch in Klonen nachgezogen
- Safety-Requirements (Felder ) formulieren und Funktionen zuordnen
- Acceptance-Criteria (Feld ) formulieren
- Verification-Criteria (Feld ) formulieren
Einheitliche und prüfbare Modellierung
- Modellierung basiert auf UML-Standard
- Syntaktische Prüfung der Modellierung
- Portierbarkeit der Modellierung auf zukünftige Technologien
- Konsistenzprüfungen
- Meta-Model Check
- prüft, ob richtige Elemente im Modell sind
- prüft, ob Verbindungen zwischen Elementen zulässig sind
- ASIL-Level Check
- prüft, ob invalid ASIL vorhanden
- Funktionsaufruf ohne gültigen ASIL unter- halb einer Funktion
- prüft, ob unplausible ASIL vorhanden
- ASIL eines Funktionsaufrufs ist höher als der, der umgebenden Funktion
- Connector Check
- prüft, ob Verbindungen zwischen Pins bzw. Parametern zulässig sind
- Model Checks
- prüft, ob diese Zuordnungen zulässig sind:
- 1 Function 1 Component
- 1 Component x Requirements
- 1 Safety-Goal x Acceptance-Criterias
- x Safety-Requirements 1 Safety-Goal
- x Verification-Criterias 1 Safety-Requirement
- 1 Safety-Requirement x Verification-Criterias
- 1 Safety-Requirement x Actions/Activities
- Safety-Goal ASIL
- Safety-Goal Valid ASIL
- Safety-Requirement ASIL
- Safety-Requirement Valid ASIL
- Safety-Requirement’s ASIL Safety-Goal’s ASIL
- Activity’s ASIL Safety-Requirement’s ASIL
- Signal ActivityParameter
- ActivityParameter Signal