SysLand-Toolbox

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