Funktionales Sicherheitskonzept (FSK)

Vom Safety Goal zur funktionalen Sicherheitsanforderung

Nach der HARA stehen Safety Goals und ASIL-Einstufungen fest. Damit ist aber noch nicht beschrieben, welches Verhalten ein Item im Fehlerfall zeigen muss. Genau an dieser Stelle entscheidet sich, ob aus einer Risikobewertung ein tragfähiger Anforderungssatz wird oder ob die spätere Systementwicklung mit unscharfen Vorgaben startet.

Das Funktionale Sicherheitskonzept, kurz FSK, ist das zentrale Arbeitsergebnis der Konzeptphase nach ISO 26262-3. Es beschreibt, wie die aus der HARA abgeleiteten Safety Goals auf Item-Ebene funktional erreicht werden sollen. Dabei geht es noch nicht um Steuergeräte, Sensorpfade, Softwaretasks oder konkrete Redundanzen. Das FSK beschreibt, welches sichere oder degradierte Verhalten erforderlich ist, damit kein unangemessenes Risiko verbleibt.

Im Kern beantwortet das FSK drei Fragen: Welche Safety Goals müssen funktional erfüllt werden? Welche Functional Safety Requirements konkretisieren diese Safety Goals? Und welche Annahmen, Reaktionen, Zeitgrenzen und Nachweise sind notwendig, damit die Anforderungen später technisch sauber umgesetzt werden können?

Was das Funktionale Sicherheitskonzept leistet

Das FSK bildet die Brücke zwischen abstrakten Safety Goals und der späteren technischen Umsetzung auf System-, Hardware- und Softwareebene. Es wird auf Basis der Item Definition und der HARA erstellt und bleibt bewusst technologieunabhängig. Diese Lösungsneutralität ist wichtig, weil das Konzept zunächst das erforderliche Sicherheitsverhalten festlegt, nicht die konkrete Architektur.

Die Kernaussage lautet: Das Funktionale Sicherheitskonzept beschreibt, was ein System funktional tun muss, um seine Safety Goals zu erfüllen, nicht wie dieses Verhalten technisch implementiert wird.

Daraus ergeben sich vier zentrale Aufgaben:

• Safety Goals in überprüfbare Functional Safety Requirements zu konkretisieren,
• Traceability von HARA über Safety Goals zu FSR sicherzustellen,
• die Eingangsgröße für das Technische Sicherheitskonzept nach ISO 26262-4 zu schaffen,
• einen belastbaren Baustein für den Safety Case zu liefern.

Das dokumentierte Functional Safety Concept umfasst damit nicht nur eine Liste von Anforderungen. Es muss nachvollziehbar machen, warum die funktionalen Anforderungen vollständig, ASIL-konsistent, verifizierbar und auf die ursprünglichen Safety Goals zurückführbar sind.

Safety Goals und Functional Safety Requirements

Safety Goals sind das oberste sicherheitsbezogene Zielniveau. Sie werden aus der HARA abgeleitet und beschreiben, was sicherheitsseitig verhindert oder begrenzt werden muss, um ein unangemessenes Risiko zu vermeiden. Sie sind gefährdungs- und szenarioorientiert, auf Item-Ebene formuliert, mit einem ASIL klassifiziert und bewusst abstrakt.

Ein vereinfachtes Safety Goal kann zum Beispiel lauten:

SG 01: Unbeabsichtigtes Beschleunigen des Fahrzeugs muss verhindert werden. ASIL D.

Eine Functional Safety Requirement, kurz FSR, ist die funktionale Konkretisierung eines Safety Goals. Sie beschreibt, welches funktionale Verhalten das System zeigen muss, um das jeweilige Safety Goal zu erreichen. Ein Safety Goal wird dabei typischerweise in mehrere FSRs zerlegt.

Die Beziehung zwischen Safety Goal und FSR ist:

• hierarchisch: Ein Safety Goal steht über mehreren FSRs,
• verfeinernd: Aus “Was darf nicht passieren?” wird “Welche Funktionen stellen sicher, dass es nicht passiert?”,
• vollständig und notwendig: Jedes Safety Goal muss durch mindestens eine FSR abgedeckt sein, und jede FSR muss eindeutig einem Safety Goal zugeordnet sein,
• ASIL-konform: Der ASIL des Safety Goals wird auf die zugehörigen FSRs vererbt.

Eine ASIL-Reduktion ist auf dieser Ebene nicht der normale Hebel. Wenn ASIL-Dekomposition später genutzt wird, gehört sie in die technische Architektur- und Systembetrachtung und muss dort explizit begründet werden.

Safety Goal	Functional Safety Requirement
beschreibt das Sicherheitsziel	beschreibt das funktionale Sicherheitsverhalten
gefahrenbasiert	funktions- und reaktionsbasiert
abstrakt	konkret und überprüfbar
Item-Ebene	Systemverhalten ohne technische Umsetzung

Was eine FSR enthalten sollte

Eine qualitativ hochwertige FSR beschreibt nicht nur eine grobe Absicht. Sie legt funktional fest, unter welchen Bedingungen ein Fehler erkannt werden soll, welche Reaktion gefordert ist und wie der sichere oder degradierte Zustand erreicht wird.

Typische Inhalte einer FSR sind:

• Bedingungen zur Fehlererkennung,
• geforderte Reaktion bei Fehlern,
• Übergang in einen sicheren oder degradierten Zustand,
• zulässige Reaktionszeiten,
• Anforderungen an Warnungen oder Fahrerinformation.

Für das Safety Goal “Unbeabsichtigtes Beschleunigen muss verhindert werden” können daraus mehrere FSRs entstehen:

• FSR 01: Das System muss ein Plausibilitätsmonitoring für Fahrpedalsignale bereitstellen.
• FSR 02: Bei Detektion eines inkonsistenten Fahrpedalsignals muss das Drehmoment innerhalb x ms auf einen sicheren Wert begrenzt werden.
• FSR 03: Der Fahrer muss bei Auftreten des Fehlers eindeutig gewarnt werden.

Alle FSRs zusammen bilden die funktionale Erfüllung des Safety Goals. Keine einzelne dieser Anforderungen erklärt bereits, welches Steuergerät, welcher Sensorpfad oder welche Softwarearchitektur verwendet wird. Genau diese Trennung hält das FSK auf der richtigen Abstraktionsebene.

Wie eine qualitativ hochwertige FSR formuliert wird

Eine FSR ist nicht nur formal korrekt. Sie ist methodisch sauber in den ISO-26262-Sicherheitslebenszyklus eingebettet. Sie ermöglicht Nachweisbarkeit, Architekturableitung und Auditfähigkeit und wird damit zu einem tragenden Baustein des Safety Case.

Für Reviews ist hilfreich, jede FSR gegen klare Qualitätskriterien zu prüfen:

• eindeutig: Die Anforderung lässt keinen Interpretationsspielraum bei Trigger, Reaktion oder Zustand,
• verifizierbar: Es ist erkennbar, wie die Erfüllung später geprüft werden kann,
• ASIL-konsistent: ASIL und Herkunft aus dem Safety Goal bleiben nachvollziehbar,
• vollständig bezogen auf das Safety Goal: Das relevante Sicherheitsziel wird nicht nur teilweise adressiert,
• notwendig: Die Anforderung ist sicherheitsrelevant und keine allgemeine Komfort- oder Qualitätsanforderung,
• lösungsneutral: Die Anforderung beschreibt funktionales Verhalten, nicht bereits die technische Implementierung,
• auf korrekter Abstraktionsebene: Sie ist konkreter als das Safety Goal, aber noch nicht direkt Hardware- oder Softwaredesign,
• zuweisbar und tracebar: Ursprung und spätere Weiterführung sind nachvollziehbar,
• konsistent: Sie widerspricht weder anderen FSRs noch Annahmen aus Item Definition oder HARA,
• funktional prüfbar: Die spätere Verifikation kann auf funktionaler Ebene geplant werden.

Gerade die Abstraktionsebene ist in Projekten ein häufiger Streitpunkt. Eine zu abstrakte FSR wiederholt nur das Safety Goal und hilft der Systementwicklung nicht weiter. Eine zu technische FSR nimmt dagegen Architekturentscheidungen vorweg und verschiebt Inhalte aus dem TSK in die Konzeptphase. Tragfähig ist die Mitte: funktional konkret, aber noch nicht implementierungsgebunden.

Übergang vom FSK zum TSK

Der Übergang vom Funktionalen zum Technischen Sicherheitskonzept markiert den Schritt von der Was- zur Wie-Ebene. Aus Functional Safety Requirements werden Technical Safety Requirements, die in einer konkreten Systemarchitektur umgesetzt und nachgewiesen werden können.

Ziel dieses Übergangs ist es, sicherzustellen, dass alle FSR technisch umsetzbar sind, vollständig durch Systemmaßnahmen abgedeckt werden und auf System-, Hardware- und Softwareebene nachweisbar weitergeführt werden können.

Ebene	FSK / FSC	TSK / TSC
Fokus	funktionales Verhalten	technische Umsetzung
Leitfrage	Was muss passieren, um sicher zu sein?	Wie wird es technisch erreicht?
Artefakte	Safety Goals, FSR	TSR, Systemarchitektur
Abstraktion	technologieneutral	architektur- und elementbezogen

Im TSK wird erstmals die technische Systemarchitektur festgelegt: Systemelemente wie Steuergeräte, Sensoren und Aktoren, Kommunikationspfade, Redundanzen und Diagnoseketten. Dort werden FSRs technischen Systemelementen zugeordnet, ASIL-Anforderungen weitergeführt und Sicherheitsmechanismen systematisch platziert.

Eine beispielhafte Transformation kann so aussehen:

FSR:

• Bei Detektion eines inkonsistenten Lenkwinkelsignals muss das System innerhalb von 100 ms in einen sicheren Zustand übergehen.

TSR:

• Das Steuergerät muss zwei unabhängige Lenkwinkelsignale auswerten.
• Eine Plausibilitätsprüfung muss zyklisch mit mindestens x Hz erfolgen.
• Bei Fehlerdetektion muss das Stellmoment auf höchstens y begrenzt werden.

Ein ISO-26262-konformer Übergang braucht lückenlose Traceability, vollständige Abdeckung, Konsistenz zwischen Funktion und Technik sowie Nachweisfähigkeit. Die Kette reicht von Hazard und Safety Goal über FSR und TSR bis zu Architektur, Hardware-/Softwareanforderungen und Tests.

Typische Fehler im FSK

Viele Schwächen im FSK fallen erst später auf, wenn Systemarchitektur, Lieferantenabstimmung oder Verifikation bereits laufen. Genau deshalb lohnt sich eine frühe methodische Prüfung.

Der erste typische Fehler sind implizite Annahmen. Anforderungen setzen dann Randbedingungen voraus, etwa Sensorsignalqualität, Fahrerreaktionen, Betriebsmodi oder die Verfügbarkeit externer Systeme, ohne diese Annahmen zu dokumentieren. Erkennbar ist das an Formulierungen, die nur unter einem unausgesprochenen “wenn” funktionieren. Solche Annahmen sollten explizit als Randbedingungen, Anforderungen oder validierte Prämissen festgehalten werden.

Der zweite Fehler ist fehlende oder ungeeignete Verifikation. Eine FSR ist formuliert, aber es ist unklar, ob sie später durch Test, Analyse oder Inspektion geprüft wird. Besonders kritisch wird es, wenn funktionale Anforderungen erst auf Software- oder Hardwareebene verifiziert werden sollen, obwohl sie vorher auf Konzept- oder Systemebene hätten überprüft werden müssen.

Der dritte Fehler sind ASIL-Inkonsistenzen. Wenn ein Safety Goal mit ASIL D zu einer FSR mit ASIL D führt, darf daraus nicht ohne nachvollziehbare Begründung eine schwächere technische Anforderung entstehen. ASIL muss explizit weitergeführt werden. Dekomposition gehört in den technischen Kontext und braucht dokumentierte Unabhängigkeit und Wirksamkeit.

Der vierte Fehler ist unvollständige Coverage der Safety Goals. Ein Safety Goal wird dann nur teilweise durch FSRs adressiert. Häufig fehlen Fehlerübergänge, Degradationspfade oder Randbedingungen. Eine einfache Coverage-Matrix zwischen Safety Goals und FSRs macht solche Lücken früh sichtbar.

Der fünfte Fehler sind kombinierte Anforderungen. Eine FSR, die mehrere Trigger, Reaktionen und Zeitgrenzen in einem Satz bündelt, ist schwer eindeutig zu prüfen. Besser ist eine klare Trennung: eine Anforderung, ein Verhalten.

Der sechste Fehler ist fehlende Traceability. Anforderungen wirken dann fachlich plausibel, lassen sich aber nicht mehr sauber zu Hazard, Safety Goal, TSR, Architektur oder Test zurückführen. Für den Safety Case ist das ein strukturelles Problem, weil die Argumentationskette bricht.

Der siebte Fehler ist nicht spezifiziertes Zeitverhalten. Wenn eine Reaktion gefordert wird, aber keine Reaktionszeit oder zeitliche Randbedingung genannt ist, bleibt die Anforderung unvollständig. Zeitgrenzen müssen früh genug beschrieben werden, damit sie später analysiert, umgesetzt und verifiziert werden können.

Was ein qualitativ hochwertiges FSK im Projekt leistet

Ein FSK reduziert Unsicherheit vor der technischen Architekturarbeit. Es macht sichtbar, welche Safety Goals welche funktionalen Anforderungen treiben, welche Annahmen gelten und wo später Nachweise erforderlich werden. Dadurch wird der Übergang in das TSK nicht zu einer Interpretationsaufgabe, sondern zu einer kontrollierten Verfeinerung.

Für Reviews und Audits kann eine kurze Prüfliste helfen:

• Sind Annahmen explizit dokumentiert?
• Ist pro Requirement eine Verifikationsmethode definiert?
• Stimmt die Abstraktionsebene der FSR?
• Ist der ASIL konsistent weitergeführt?
• Ist die Coverage der Safety Goals vollständig?
• Sind Zustände, Trigger und Begriffe eindeutig?
• Ist die Traceability vorwärts und rückwärts sauber?
• Ist relevantes Zeitverhalten spezifiziert?

Damit wird das FSK zu mehr als einem Zwischendokument. Es stabilisiert die Anforderungsableitung, erleichtert die Abstimmung zwischen Safety, System Engineering und Lieferanten und liefert eine wesentliche Evidence-Linie für den Safety Case.

Fazit

Das Funktionale Sicherheitskonzept übersetzt Safety Goals in überprüfbare Functional Safety Requirements. Es bleibt technologieunabhängig, beschreibt aber bereits konkret, welches sichere oder degradierte Verhalten ein Item zeigen muss, um die aus der HARA abgeleiteten Safety Goals zu erfüllen.

Seine Qualität entscheidet darüber, ob der Übergang in das Technische Sicherheitskonzept kontrolliert erfolgt. Klare FSRs, konsistente ASIL-Weiterführung, dokumentierte Annahmen, definierte Verifikation und saubere Traceability verhindern spätere Lücken in Architektur, Nachweisführung und Safety Case.

Gerade in frühen Projektphasen wirkt ein belastbares FSK unspektakulär, aber entscheidend: Es schafft die fachliche Ordnung, bevor technische Lösungen festgeschrieben werden. Je klarer diese Ordnung ist, desto stabiler werden TSK, Verifikation und spätere Freigabeentscheidung.