Technisches Sicherheitskonzept (TSK)

Von der Sicherheitsanforderung zur technischen Lösung

Nach dem Funktionalen Sicherheitskonzept ist klar, welches sichere Verhalten ein Item zeigen muss. Offen ist aber noch, wie dieses Verhalten technisch realisiert wird: über welche Systemelemente, Schnittstellen, Diagnosepfade, Redundanzen, Betriebsmodi und Verifikationsnachweise.

Das Technische Sicherheitskonzept, kurz TSK, ist das zentrale Arbeitsergebnis der Produktentwicklung auf Systemebene nach ISO 26262-4. Es beschreibt, wie die im Funktionalen Sicherheitskonzept definierten Functional Safety Requirements durch konkrete technische Maßnahmen und eine geeignete Systemarchitektur umgesetzt werden.

Damit beantwortet das TSK drei Kernfragen: Welche Technical Safety Requirements entstehen aus den FSR? Welche Architektur ist geeignet, diese Anforderungen ASIL-konform zu erfüllen? Und welche Safety Mechanismen müssen Fehler erkennen, beherrschen oder in einen sicheren Zustand überführen?

Was das TSK leistet

Das TSK verbindet funktionale Sicherheitsabsicht mit technischer Systemlösung. Nach ISO 26262-4, Abschnitt 6.2, ist es im Kern eine Aggregation aus technischen Sicherheitsanforderungen und zugehöriger Systemarchitektur. Diese Aggregation begründet, warum die gewählte Systemlösung geeignet ist, die aus der Konzeptphase nach ISO 26262-3 abgeleiteten Sicherheitsanforderungen zu erfüllen.

Wichtig ist dabei, dass die technische Lösung nicht isoliert betrachtet wird. Das TSK muss auch nicht sicherheitsrelevante Anforderungen, Designrestriktionen und Randbedingungen aus Produktion, Betrieb, Service und Außerbetriebnahme berücksichtigen. Genau dort zeigt sich die Systemebene: Safety wird nicht neben die Architektur gelegt, sondern in die Architektur integriert.

Die zentralen Aufgaben des TSK sind:

• Technical Safety Requirements zur Umsetzung der FSR zu spezifizieren,
• die Systemarchitektur inklusive Safety Mechanismen zu definieren und zu begründen,
• Konsistenz zwischen Functional Safety Concept und technischer Umsetzung sicherzustellen,
• Randbedingungen aus Produktion, Betrieb, Service und Außerbetriebnahme zu berücksichtigen,
• zu verifizieren, dass Architektur und Anforderungen den jeweiligen ASIL erfüllen.

Das TSK ist damit kein reiner Requirements-Anhang. Es ist die technische Begründung, warum eine Systemlösung die funktionalen Sicherheitsziele beherrschen kann.

Einordnung auf der Systemebene

Das TSK liegt zwischen Konzeptphase und detaillierter Hardware- und Softwareentwicklung. Es übernimmt die Safety Goals und FSR aus der Konzeptphase und macht daraus technische Vorgaben, Architekturentscheidungen und Nachweise auf Systemebene.

Typische Inputs sind:

• das Funktionale Sicherheitskonzept nach ISO 26262-3,
• eine vorläufige Systemarchitektur,
• die Item Definition,
• gegebenenfalls Sicherheitsanforderungen anderer Systeme.

Typische Outputs und Work Products sind:

• Technical Safety Requirements (TSR),
• das Technische Sicherheitskonzept selbst,
• eine Systemarchitekturspezifikation,
• eine Hardware-Software-Interface-Spezifikation (HSI),
• Sicherheitsanalysen und Verifikationsberichte.

Ein normkonformes TSK umfasst insbesondere vier Kernelemente. Erstens konkretisieren TSR die FSR in technische Maßnahmen, etwa Stimulus-Response-Verhalten, Zeitgrenzen und Betriebsmodi. Zweitens ordnet die Systemarchitektur diese TSR Systemelementen, Schnittstellen, Redundanzen und Partitionierungen zu. Drittens beschreiben Safety Mechanismen, wie Fehler erkannt, beherrscht und latente Fehler vermieden werden. Viertens wird der ASIL weitergeführt und, falls genutzt, ASIL-Dekomposition auf Systemebene nach ISO 26262-9 begründet.

FSK und TSK: Was-Ebene und Wie-Ebene

Die Trennung zwischen FSK und TSK ist ein zentraler Strukturierungsgrundsatz der ISO 26262. Sie trennt bewusst die Sicherheitsabsicht von der technischen Umsetzung und schafft damit Nachvollziehbarkeit, Variantenfähigkeit und Auditfestigkeit.

Perspektive	Funktionales Sicherheitskonzept (FSK)	Technisches Sicherheitskonzept (TSK)
Leitfrage	Was muss das System tun, um sicher zu sein?	Wie wird dieses sichere Verhalten technisch realisiert?
ISO-Teil	ISO 26262-3, Konzeptphase	ISO 26262-4, Produktentwicklung auf Systemebene
Abstraktion	funktional, technologieneutral	technisch, architekturbezogen
Ergebnis	Functional Safety Requirements (FSR)	Technical Safety Requirements (TSR) und Systemarchitektur

Das FSK beschreibt das erforderliche sicherheitsrelevante Systemverhalten unabhängig von konkreten technischen Lösungen. Es geht von Safety Goals aus der HARA aus und definiert funktionales Verhalten im Fehlerfall: Fehlererkennung, Fehlerreaktion, sicherer Zustand, Degradation und zeitliche Reaktionen, aber ohne technische Details.

Das TSK beschreibt dagegen, wie dieses Verhalten technisch erreicht wird. Erst hier werden Systemelemente, Schnittstellen, Diagnose- und Sicherheitsmechanismen, Redundanzen, Plausibilitätsprüfungen und gegebenenfalls ASIL-Dekomposition konkret benannt.

Ein vereinfachtes Beispiel zeigt den Unterschied:

FSR:

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

TSR:

• Zwei unabhängige Lenkwinkelsignale müssen zyklisch ausgewertet werden.
• Eine Plausibilitätsprüfung mit mindestens x Hz muss Inkonsistenzen erkennen.
• Bei Fehlerdetektion muss das Stellmoment innerhalb der geforderten Zeit auf höchstens y begrenzt werden.

Diese Trennung verhindert, dass Architekturentscheidungen zu früh festgeschrieben werden. Sie erleichtert Varianten- und Lieferantentrennung, hält die Safety-Case-Argumentation stabil und macht Anforderungen in Reviews prüfbar.

Technical Safety Requirements

Technical Safety Requirements übersetzen FSR in konkrete technische Vorgaben für Systemelemente und Schnittstellen. Sie sind der erste Schritt, in dem aus funktionaler Sicherheitsabsicht technische Systemverantwortung wird.

Qualitativ hochwertige TSR sind:

• technisch präzise, zum Beispiel mit Stimulus-Response-Verhalten, Zeitgrenzen und Grenzwerten,
• eindeutig zu Systemelementen zuweisbar, etwa ECU, Sensor, Aktor oder Kommunikation,
• auf Systemebene verifizierbar,
• ASIL-konsistent, einschließlich Vererbung aus der FSR und begründeter Dekomposition nur im TSK.

Typische Inhalte von TSR sind Anforderungen an Diagnose, Reaktion und Safe State, Zeit- und Leistungsgrenzen, Betriebs- und Fehlerzustände inklusive Übergängen sowie Kommunikationsanforderungen wie Timeouts, Alive Counter oder Plausibilitätsregeln.

Eine TSR kann zum Beispiel lauten:

Bei inkonsistenten Lenkwinkelsignalen muss die Plausibilitätsprüfung zyklisch mit mindestens x Hz erfolgen und innerhalb von 100 ms eine Stellmomentbegrenzung auf höchstens y auslösen.

Damit wird eine funktionale Sicherheitsanforderung nicht direkt implementiert, sondern zunächst in eine technische Systemanforderung überführt. Diese Anforderung kann anschließend Architektur, HSI, Hardware Safety Requirements und Software Safety Requirements treiben.

Systemarchitektur

Die Systemarchitektur zeigt, wie TSR im System realisiert werden können. Sie bildet das Bindeglied zwischen Anforderungen und späterer Implementierung.

Im TSK beschreibt die Architektur insbesondere:

• die Struktur der Systemelemente, etwa Sensoren, Aktoren, Steuergeräte und Busse,
• Schnittstellen und Datenflüsse, etwa Signale, Nachrichten und Abhängigkeiten,
• Partitionierung und Unabhängigkeit als Voraussetzung für ASIL-Dekomposition,
• Redundanzen und Diversität, funktional oder technisch,
• Betriebsmodi wie Normalbetrieb, Degradation und Notbetrieb.

Die Architektur muss begründen, warum die gewählte Lösung geeignet ist, die TSR unter ASIL-Vorgaben zu erfüllen. Eine Redundanz ist deshalb nicht schon dadurch sicherheitswirksam, dass sie gezeichnet wurde. Sie muss richtig zugeordnet, unabhängig genug, zeitlich geeignet und verifizierbar sein.

Besonders kritisch sind Schnittstellen. Viele Safety Findings entstehen nicht im einzelnen Element, sondern zwischen Elementen: unklare Signalverantwortung, fehlende Timeout-Regeln, implizite Annahmen über Datenqualität oder eine HSI-Spezifikation, die Safety-Anforderungen nur indirekt widerspiegelt.

Safety Mechanismen im TSK

Safety Mechanismen sind die konkreten technischen Mittel, mit denen sicherheitsrelevante Fehler erkannt, beherrscht oder in ihrer Wirkung begrenzt werden. Im TSK müssen sie aus TSR abgeleitet, Architektur und Systemelementen zugeordnet und später ASIL-konform verifiziert werden.

Typische Mechanismen sind:

• Fehlererkennung, etwa Plausibilitätsprüfungen, Monitoring und Watchdogs,
• Fehlerbeherrschung, etwa Umschaltung, Begrenzung oder Abschaltung,
• Fehlervermeidung, etwa Redundanz, Partitionierung und Diversität,
• Prävention latenter Fehler, etwa Selbsttests und Hintergrunddiagnosen.

Für jeden Mechanismus müssen mindestens Auslösekriterien, Reaktionslogik, Safe State, Zeitverhalten, Wirksamkeit und Verortung im System definiert sein. Die zentrale Frage lautet: Welches Element erkennt welchen Fehler, innerhalb welcher Zeit, mit welcher Diagnoseabdeckung, und welche Reaktion wird dadurch deterministisch ausgelöst?

TSR geben die Anforderungen vor. Die Architektur zeigt die technische Struktur. Die Mechanismen liefern die konkrete Umsetzung. Zusammen bilden sie den technischen Kern der Safety-Argumentation.

Diagnose, Degradation und Fallback

Diagnose, Degradation und Fallback greifen im TSK abgestimmt ineinander. Diagnose erkennt Fehler, Degradation beherrscht sie kontrolliert weiter, Fallback begrenzt das Risiko, wenn keine sichere Funktion mehr möglich ist.

Diagnose dient der frühzeitigen und zuverlässigen Detektion von Fehlern. Dazu gehören zufällige Hardwarefehler, systematische Fehler und Kommunikationsfehler. Typische Diagnosemechanismen sind Plausibilitätsprüfungen, Redundanzvergleiche, Zeitüberwachung, Selbsttests, Watchdogs und End-to-End-Überwachung.

Eine Diagnoseanforderung muss mindestens klären:

• was als Fehler gilt,
• welche Detection Time zulässig ist,
• wie die Diagnosewirksamkeit begründet wird,
• welches Systemelement den Fehler erkennt.

Degradation erhält eine eingeschränkte, aber sichere Funktion, wenn ein Teil der Funktionalität ausfällt. Sie vermeidet unnötige Komplettabschaltungen und erhöht die beherrschbare Verfügbarkeit. Typische Maßnahmen sind das Begrenzen von Stellgrößen, reduzierte Betriebsmodi, vereinfachte Regelstrategien oder die Nutzung verbleibender redundanter Kanäle.

Eine tragfähige Degradation braucht definierte Eintrittsbedingungen, klar beschriebene Degradationsstufen, einen deterministischen Übergang, zulässige Rückkehrbedingungen und eine Verifikation der Sicherheitswirkung im degradierten Betrieb.

Fallback greift, wenn Degradation nicht mehr ausreicht oder Safety Goals sonst nicht eingehalten werden können. Formen sind Fail Safe, also der Übergang in einen sicheren Zustand, und Fail Operational, also die Aufrechterhaltung einer sicherheitsrelevanten Funktion trotz Fehler. Typische Fallback-Aktionen sind das Abschalten von Aktoren, der Übergang in einen Notbetrieb, die Übergabe an den Fahrer oder ein externes System sowie die Aktivierung mechanischer Sicherungen.

Für den Fallback sind ein eindeutig definierter sicherer Zustand, ein deterministischer Auslösepfad, eine definierte Reaktionszeit und eine konsistente Warn- oder Informationsstrategie entscheidend.

Verifikation des TSK

Die Verifikation des TSK weist nach, dass TSR korrekt abgeleitet, die Systemarchitektur geeignet und die Safety Mechanismen wirksam sind. Sie ist ein zentraler Baustein des Safety Case, weil sie aus technischen Behauptungen prüfbare Evidenzen macht.

Nachzuweisen ist zunächst die Ableitung und Vollständigkeit. Jede FSR aus dem FSK muss vollständig durch mindestens eine TSR abgedeckt sein. Gleichzeitig darf keine TSR ohne FSR-Bezug existieren. ASIL-Vererbung und gegebenenfalls ASIL-Dekomposition müssen nachvollziehbar begründet sein. Typische Nachweise sind Traceability-Matrizen von Safety Goal über FSR zu TSR, Review-Protokolle und Dekompositionsnachweise.

Für TSR ist nachzuweisen, dass sie eindeutig, technisch umsetzbar, ASIL-konform und auf Systemebene verifizierbar sind. Dafür eignen sich Systemtests, Stimulus-Response-Szenarien, Zeit- und Leistungsanalysen sowie Reviews für strukturierende Anforderungen.

Für die Architektur ist zu zeigen, dass sie die Umsetzung aller TSR ermöglicht, notwendige Unabhängigkeit sicherstellt, Redundanzen, Partitionierung und Schnittstellen konsistent definiert und keine unbegründeten Single Points of Failure im sicherheitsrelevanten Pfad enthält. Typische Evidenzen sind Architekturbeschreibungen, Architektur-Reviews, System-Level-Safety-Analysen wie FTA und HSI-Spezifikationen.

Für Safety Mechanismen muss belegt werden, dass Fehler zuverlässig erkannt werden, Reaktionen deterministisch ablaufen, Safety Goals auch im Fehlerfall eingehalten werden und die Priorisierung von Diagnose über Degradation zu Fallback stimmt. Fehlereinspeisetests, Übergangsszenarien und Coverage-Argumente sind hier zentrale Nachweise.

Zusätzlich muss das Zeitverhalten stimmen. Detection und Reaction Times müssen innerhalb der geforderten Grenzen liegen, und Architektur sowie Kommunikation müssen diese Grenzen deterministisch unterstützen. Konsistenz-Reviews und Impact Analysen prüfen schließlich, ob TSK, FSC, Architektur, TSR und weitere Systemanforderungen widerspruchsfrei sind und ob Annahmen aus dem FSC eingehalten wurden.

Übergang zu Hardware- und Softwareentwicklung

Der Übergang vom TSK in Hardware- und Softwareentwicklung ist der formale Staffelstab von der Systemebene zur Implementierungsebene. Ziel ist es, alle TSR vollständig, eindeutig und ASIL-konform in Hardware Safety Requirements und Software Safety Requirements zu überführen.

Dieser Übergang ist ein Hochrisikopunkt für Safety Findings, wenn Traceability oder Abstraktionsebenen nicht sauber eingehalten werden. Typische Fragen sind: Welche Anteile einer TSR gehören in Hardware? Welche in Software? Welche Verantwortung liegt in der HSI? Und wo wird das geforderte Zeitverhalten tatsächlich abgesichert?

Aus TSR werden abgeleitet:

• Hardware Safety Requirements nach ISO 26262-5,
• Software Safety Requirements nach ISO 26262-6,
• klare Allocation zu Hardwareelementen, Softwareelementen und Schnittstellen.

Eine TSR kann zum Beispiel lauten:

• Bei Erkennung eines Sensorsignalausfalls muss das System das Stellmoment innerhalb von 100 ms auf einen sicheren Wert begrenzen.

Daraus können HSR entstehen:

• Das Sensorinterface muss eine Unterbrechung innerhalb von x ms erkennen.
• Die Aktorendstufe muss eine sichere Begrenzung ermöglichen.

Und SSR:

• Die Softwarekomponente muss Sensorwerte zyklisch überwachen.
• Die Stellgrößenbegrenzung muss innerhalb des geforderten Zeitfensters ausgelöst werden.

Der ASIL der TSR wird auf HSR und SSR vererbt. Eine weitere ASIL-Dekomposition ist möglich, muss aber explizit über Unabhängigkeit und Wirksamkeit begründet werden. Hardwarearchitekturen müssen Diagnose und Sicherheitsmechanismen unterstützen, keine unerkannten Single Points of Failure enthalten oder diese begründen und die Basis für quantitative Analysen wie FMEDA liefern. Softwarearchitekturen müssen eine klare Sicherheitsarchitektur, Partitionierung, Unabhängigkeit sicherheitsrelevanter Funktionen und deterministisches Zeitverhalten stützen.

Typische Fehler im Übergang sind, dass TSR direkt implementiert werden, ohne HSR oder SSR abzuleiten, dass HW/SW-Verantwortung implizit bleibt, dass Safety Mechanismen in Software “verschwinden”, dass Timing-Annahmen nicht übernommen werden oder dass Traceability auf Systemebene endet. Die praktische Regel ist entsprechend streng: keine Implementierung ohne explizite HW- oder SW-Safety-Requirement.

Was ein qualitativ hochwertiges TSK im Projekt leistet

Ein TSK reduziert technische Interpretationsspielräume, bevor Hardware- und Softwareentwicklung tief in die Umsetzung einsteigen. Es zeigt, welche FSR welche TSR treiben, welche Systemelemente verantwortlich sind, welche Mechanismen wirken sollen und wie diese Wirkung später nachgewiesen wird.

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

• Ist jede FSR vollständig durch TSR abgedeckt?
• Sind TSR technisch präzise, zuweisbar und verifizierbar?
• Ist die Systemarchitektur als Safety-Lösung begründet?
• Sind Diagnose, Degradation und Fallback eindeutig spezifiziert?
• Sind ASIL-Vererbung und Dekomposition nachvollziehbar?
• Sind Timing-Annahmen in TSR, Architektur, HSI, HSR und SSR konsistent?
• Ist bidirektionale Traceability bis zu Tests und Evidenzen angelegt?
• Sind Verifikationsmethoden und Nachweise klar zugeordnet?

Damit wird das TSK zu mehr als einer Durchgangsstation. Es stabilisiert die Systementwicklung, erleichtert Lieferantenabstimmung und schafft eine belastbare Evidence-Linie für den Safety Case.

Fazit

Das Technische Sicherheitskonzept übersetzt funktionale Sicherheitsanforderungen in eine technische Systemlösung. Es verbindet Technical Safety Requirements, Systemarchitektur, Safety Mechanismen, ASIL-Behandlung und Verifikation zu einem nachvollziehbaren Arbeitsergebnis der ISO 26262-4.

Seine Qualität entscheidet darüber, ob der Übergang von der Konzeptphase in Hardware- und Softwareentwicklung kontrolliert erfolgt. Klare TSR, begründete Architektur, definierte Mechanismen, konsistente Traceability und belastbare Verifikation verhindern, dass Safety erst in der Implementierung interpretiert wird.

In der Projektrealität ist das TSK oft der Punkt, an dem sich zeigt, ob das Sicherheitskonzept technisch trägt. Je früher Anforderungen, Architekturentscheidungen, Mechanismen und Nachweise gemeinsam geprüft werden, desto stabiler werden Implementierung, Safety Case und spätere Freigabeentscheidung.