Funktionale Sicherheit nach IEC 61508 bis SIL 3
iFSM: zertifizierter Prozess für Norm-konforme Software bei infoteam
Safety-Lifecycle nach IEC 61508: von der Gefährdungsanalyse bis zum Betrieb
SIL-Einstufung per Risk Graph und LOPA – nachvollziehbar, nicht geschätzt
iFSM: TÜV-zertifizierter Prozess, reduziert die Assessment-Tiefe
SIL 4 nach DIN EN 50716: unabhängige Verifikation, hohe MC/DC-Coverage
Werkzeugqualifizierung: auch der Compiler muss nachgewiesen werden
Warum Funktionale Sicherheit entscheidend ist
Funktionale Sicherheit für Software: infoteam entwickelt Embedded- und Anwendungssoftware für Industrie und Bahn nach IEC 61508 bis SIL 3 und nach DIN EN 50716 bis SIL 4. Grundlage ist unser von TÜV SÜD Rail zertifizierter iFSM-Prozess, der den gesamten Safety-Lifecycle abdeckt – von der Gefährdungsanalyse bis zum Betrieb – und die Assessment-Tiefe reduziert.
Funktionale Sicherheit beschreibt den Teil der Gesamtsicherheit eines Systems, der davon abhängt, dass eine Funktion korrekt auf ihre Eingaben reagiert. Im Softwarekontext bedeutet das: Die Software muss unter allen definierten Betriebsbedingungen – einschließlich Fehlerzuständen, Grenzwerten und unerwarteten Eingaben – zuverlässig das sicherheitlich korrekte Verhalten zeigen.
IEC 61508 definiert dafür vier Safety Integrity Levels (SIL 1 bis SIL 4), die aus einer systematischen Gefährdungs- und Risikoanalyse abgeleitet werden. Je höher das SIL, desto strenger die Anforderungen an Entwicklungsprozess, Testtiefe, unabhängige Verifikation und Dokumentation. Software ist dabei die schwierigste Disziplin, weil Softwarefehler – anders als Hardware-Ausfälle – keine statistisch beschreibbare Ausfallrate haben. Sie sind systematischer Natur und lassen sich nur durch Prozessqualität beherrschen.
Vertrauen über alle regulierten Märkte hinweg
Unsere Referenzprojekte und ausgewählten Kunden zeigen, wie wir innovative Ideen in erfolgreiche digitale Lösungen verwandeln – partnerschaftlich, praxisnah und branchenübergreifend.
Funktionale Sicherheit: Wenn ein Fehler keine Option ist
Ein Softwarefehler in sicherheitskritischen Systemen kann Menschen gefährden. Genau deshalb reicht gewöhnliche Testpraxis hier nicht aus. IEC 61508 begegnet systematischen Softwarefehlern mit abgestuften Safety Integrity Levels, die aus einer dokumentierten Risikoanalyse abgeleitet werden. Je höher das SIL, desto strenger sind die Anforderungen an Entwicklungsprozess, Architektur, Testtiefe, Nachweisführung und unabhängige Verifikation. Funktionale Sicherheit entsteht deshalb nicht durch einzelne Tests, sondern durch einen durchgängigen, kontrollierten Engineering-Prozess.
Prozesssicherheit: Nachweise von Anfang an beherrschbar machen
Mit iFSM, unserem zertifizierten Prozessleitfaden, steuern wir Lifecycle-Aktivitäten von der Gefährdungsanalyse bis zur Validierung konsistent und nachvollziehbar. Auch Coverage, Reviews, Verifikation, Konfigurationsmanagement und die Qualifizierung eingesetzter Werkzeuge werden systematisch berücksichtigt. So wird funktionale Sicherheit nicht erst vor dem Audit dokumentiert, sondern von Beginn an in den Entwicklungsprozess integriert. Das schafft klare Verantwortlichkeiten, belastbare Nachweise und reduziert das Risiko aufwendiger Nacharbeiten in späteren Projektphasen.
Nehmen Sie Kontakt zu uns auf!Sicherheit rechnet sich – von Anfang an.
Ein System nach SIL 4 reduziert die Wahrscheinlichkeit eines gefährlichen Ausfalls um das bis zu 100.000-Fache gegenüber einem ungeschützten Referenzsystem. Der wirtschaftliche Hintergrund zeigt, warum dieser Aufwand relevant ist: Allein in Deutschland verursachen Arbeitsunfälle jährlich Kosten von rund 42 Milliarden Euro, bei 754.660 meldepflichtigen Fällen im Jahr 2024. Ein Teil dieser Fälle geht auf technisches Versagen sicherheitsrelevanter Systeme zurück – genau hier setzt funktionale Sicherheit an. Eine DGUV-Studie beziffert den wirtschaftlichen Nutzen von Prävention auf 2,20 Euro Ersparnis pro investiertem Euro in Arbeitsschutz.
Genau dieser Gedanke liegt auch unserem iFSM-Prozess zugrunde: Funktionale Sicherheit soll nicht nachträglich ergänzt, sondern von Anfang an systematisch mitentwickelt werden. Das reduziert technische Risiken, vermeidet aufwendige Korrekturen in späten Projektphasen und schafft belastbare Nachweise für Entwicklung, Verifikation und Audit.
Quellen: IEC 61508 (Safety Integrity Level Tabelle) · DGUV, Statistik Arbeitsunfallgeschehen 2024 · Tompa et al. 2021, „Economic burden of work injuries and diseases“ · DGUV/IVSS-Studie (Prof. Bräunig, Return on Prevention)
≤ 100k
mal geringere Ausfallwahrscheinlichkeit
42 Mrd.
Euro Kosten durch Arbeitsunfälle p. a.
2,20 €
Ersparnis pro investiertem Euro in Arbeitsschutz
754.660
meldepflichtige Arbeitsunfälle 2024
Funktionale Sicherheit in der Praxis: Risiken beherrschen, Nachweise sichern
Safety Engineering: Von der Risikoanalyse bis zur Verifikation
Funktionale Sicherheit beginnt nicht beim Test, sondern bei der systematischen Bewertung von Gefährdungen und Risiken. Daraus werden Sicherheitsanforderungen, Architekturentscheidungen und notwendige Verifikationsmaßnahmen abgeleitet. Je nach gefordertem Safety Integrity Level steigen die Anforderungen an Unabhängigkeit, Testtiefe, Dokumentation und Nachweisführung.
infoteam begleitet diesen Prozess über den gesamten Software-Lebenszyklus – von der Gefährdungsanalyse über Architektur und Implementierung bis zu Integration, Verifikation und Validierung. So entsteht Sicherheit nicht als nachträgliche Zusatzschicht, sondern als Bestandteil jeder technischen Entscheidung.
Nachweisführung: Safety muss jederzeit belegbar bleiben
In Safety-Projekten reicht es nicht, dass eine Funktion korrekt arbeitet. Es muss auch nachvollziehbar sein, warum sie sicher ist, wie sie geprüft wurde und welcher Entwicklungsstand freigegeben wurde. Traceability, Reviews, Coverage-Nachweise, Konfigurationsmanagement und dokumentierte Freigaben schaffen dafür die notwendige und belastbare Grundlage.
Mit etablierten Prozessen und einem strukturierten Safety-Lifecycle lassen sich Nachweise kontinuierlich im Projekt erzeugen, statt sie erst vor dem Audit zusammenzutragen. Das reduziert Unsicherheit, erleichtert Bewertungen durch unabhängige Stellen und sorgt dafür, dass Änderungen kontrolliert, nachvollziehbar und auditfähig umgesetzt werden können.
Mehr zum Software-Audit
Kundenstimmen aus Engineering-Praxis seit 1983
Firmware-Entwicklung für Gaswarngeräte
„Im Rahmen der Entwicklung der Gaswarngeräte greifen wir auf infoteam als verlässlichen Partner zurück, welcher uns mit innovativen Lösungsansätzen und Fachkompetenz im regulativen Umfeld zur Seite steht. An der Zusammenarbeit schätzen wir das proaktive Engagement bei interdisziplinären Fragestellungen, das Vertrauensverhältnis sowie die offene Kommunikation auf Augenhöhe.“
Dr.-Ing. Sebastian Draack – Software Project Manager, Dräger Safety AG & Co. KGaA
Softwareerweiterung für ein Kraftwerks-Diagnosesystem
„In einem komplexen technischen Umfeld führten die agilen Methoden von infoteam zu einem überzeugenden Ergebnis und damit zu einem Erfolg der Aufgabe.“
Dr. Stephan Schuh – Framatome Deutschland
Damit Software in regulierten Märkten erfolgreich produktiv geht, muss sie mehr leisten als nur funktionieren.
Sie bestehen ein Audit nur dann, wenn Ihre Software …
performant ist (Echtzeit-fähig)
ergonomisch bedienbar ist
auditierbar dokumentiert ist
modular ist (austauschbare Komponenten)
echten Geschäftsmehrwert liefert
auf die jeweilige Norm zugeschnitten ist
„Der Zweck des Software Engineerings ist es, Komplexität zu beherrschen, nicht sie zu erschaffen.“ – Pamela Zave
Safety im Entwicklungsalltag: Komplexität kontrolliert beherrschen
Änderungen sicher beherrschen: Impact-Analyse statt Bauchgefühl
In sicherheitskritischen Projekten kann selbst eine kleine Änderung große Auswirkungen haben. Eine neue Anforderung, ein geändertes Interface oder ein Update der Middleware kann Architektur, Risikoanalyse, Tests und bestehende Nachweise gleichzeitig betreffen. Entscheidend ist deshalb eine belastbare Impact-Analyse, die Abhängigkeiten sichtbar macht und zeigt, welche Artefakte tatsächlich angepasst, erneut bewertet oder verifiziert werden müssen. Und weil sicherheitsrelevante Systeme heute vernetzt sind, gehört die Security-Seite von Anfang an dazu: Warum Functional Safety und Cyber Security zusammen gedacht werden müssen, erklärt unser Fachartikel.
Ein strukturierter Safety-Prozess schafft dafür die notwendige Transparenz. Anforderungen, Risiken, Architektur und Tests bleiben miteinander verknüpft, sodass Änderungen gezielt bewertet und nachvollziehbar dokumentiert werden können. Das reduziert unnötige Aufwände und schafft Sicherheit darüber, welche Nachweise weiterhin gültig bleiben. So lassen sich unnötige Re-Tests vermeiden, Freigaben nachvollziehbar vorbereiten und bestehende Sicherheitsnachweise kontrolliert erhalten.
Werkzeuge und Prozesse: Automatisierung schafft reproduzierbare Sicherheit
Funktionale Sicherheit lebt von konsequenten Prozessen – und davon, dass diese im Entwicklungsalltag zuverlässig eingehalten und dokumentiert werden. Versionierung, automatisierte Tests, statische Code-Analyse, Coverage-Auswertungen und kontrollierte Reviews helfen dabei, Qualitäts- und Safety-Anforderungen kontinuierlich abzusichern und notwendige Nachweise direkt im Entwicklungsprozess zu erzeugen.
Gerade bei langen Produktlebenszyklen schafft Automatisierung einen klaren Vorteil: Entwicklungsstände bleiben reproduzierbar, Änderungen nachvollziehbar und Nachweise müssen nicht erst kurz vor Audit oder Freigabe rekonstruiert werden. So verbindet sich regulatorische Sicherheit mit effizientem Engineering – ohne den Entwicklungsfluss unnötig auszubremsen.
Gemeinsam starten: vom Erstgespräch zum nächsten Schritt
1
Erstgespräch & Software-Audit
Im Rahmen eines strategischen Erstgesprächs lernen Sie uns als Ihren Trusted Partner für AI-powered Secure Solutions kennen. Wir verstehen uns als technologischer Sparringspartner auf Augenhöhe: Gemeinsam analysieren wir Ihre Unternehmensziele, technologischen Visionen und regulatorischen Anforderungen, um Potenziale frühzeitig zu erkennen und eine fundierte Basis für die weitere Zusammenarbeit zu schaffen.
2
Architektur- &
System-Assessment
In einer initialen Evaluierung analysieren unsere Experten Ihre bestehenden Systeme oder Konzepte hinsichtlich Architektur, Security, Skalierbarkeit und Normenkonformität. Im Rahmen einer kompakten Videokonferenz spiegeln wir Ihnen unsere fundierten Beobachtungen: Wir validieren technologische Stärken, identifizieren gezielt Optimierungspotenziale und zeigen konkrete, maßgeschneiderte Lösungsstrategien.
3
Bereit für den nächsten Schritt?
Vereinbaren Sie jetzt Ihren persönlichen Beratungstermin mit unseren Experten für AI-powered Secure Solutions. Sie erreichen uns telefonisch unter +49 9131 78 00-0 oder per E-Mail an info@infoteam.de. Die infoteam Software AG mit Hauptsitz in Bubenreuth steht seit vielen Jahren für exzellentes Software Engineering, technologische Innovationskraft und partnerschaftliche Zusammenarbeit.
Sechs Bausteine funktionaler Sicherheit
Von der Risikoanalyse bis zur Werkzeugqualifizierung – was hinter jedem SIL-Nachweis steckt.
1
Safety-Lifecycle nach IEC 61508
Von der Gefährdungsanalyse über Safety-Requirements bis zum Betrieb: Warum funktionale Sicherheit ein kontinuierlicher Prozess ist – keine einmalige Zertifizierung.
2
SIL-Einstufung: Risk Graph & LOPA
Wie sich ein Safety Integrity Level tatsächlich herleitet – anhand von Schadensausmaß, Aufenthaltswahrscheinlichkeit und Eintrittshäufigkeit, nicht per Bauchgefühl.
3
iFSM – unser TÜV-zertifizierter Prozess
Warum ein TÜV-Assessor bei iFSM-Projekten weniger Vor-Ort-Auditierungstiefe braucht – und was das für Ihren Zeitplan konkret bedeutet.
4
Funktionale Sicherheit in der Bahntechnik
SIL 4 nach DIN EN 50716 verlangt unabhängige Verifikationsteams und sehr hohe MC/DC-Coverage.
5
Werkzeugqualifizierung in SIL-Projekten
Selbst der Compiler muss nachgewiesen werden: Warum Entwicklungswerkzeuge in sicherheitskritischen Projekten selbst zum Prüfgegenstand werden.
6
TÜV-Assessment & unabhängige Verifikation
Ab SIL 2 muss ein vom Entwicklungsteam getrenntes Team verifizieren. Wie ein Assessment abläuft und worauf akkreditierte Prüfstellen besonders achten.
SIL ist kein Zustand – SIL ist ein Weg.
IEC 61508 definiert einen Safety-Lifecycle, der mit der Gefährdungs- und Risikoanalyse beginnt. Auf dieser Grundlage wird das erforderliche Safety Integrity Level (SIL) festgelegt.
Anschließend folgen Safety-Requirements, Software-Design, Implementierung, Verifikation und Validierung – jede Phase mit klaren Nachweispflichten.
Auch der Betrieb ist Teil des Lifecycles: Änderungen an SIL-relevanter Software erfordern eine erneute Impact-Analyse, um die Einhaltung des SIL sicherzustellen. Funktionale Sicherheit ist damit ein kontinuierlicher Engineering-Prozess – keine einmalige Zertifizierung.
1983
seit Gründung: Engineering in sicherheitskritischen Projekten
SIL 3
Zertifizierter Entwicklungsprozess (iFSM)
100 %
Nachweisorientierter Safety-Lifecycle
8
Safety-Standards aus einer Hand
Softwareentwicklung für regulierte Märkte: Unsere Expertise im Überblick
Unsere Expertise verbindet regulatorische Sicherheit, technologische Exzellenz und langfristige Verlässlichkeit – entscheidende Faktoren für erfolgreiche Audits und anspruchsvolle Ausschreibungen.
100 % Mitarbeiter-Eigentum
Als vollständig mitarbeitergeführtes Unternehmen stehen wir für außergewöhnliche Kontinuität, minimale Fluktuation und langfristige Verantwortung – unabhängig von externen Investoren oder kurzfristigen Renditeinteressen.
Normative Souveränität:
ISO 13485 & IEC 61508
Wir entwickeln sicherheitskritische Software nach ISO 13485 und IEC 61508 und integrieren Functional Safety sowie Cyber Security in einen durchgängigen Engineering-Prozess. Entwickelt für regulierte und sicherheitskritische Märkte.
Interdisziplinärer
Technologietransfer
Durch den Transfer bewährter Engineering-Methoden zwischen MedTech, Industrial Applications, Transportation und Public Service reduzieren wir Entwicklungsrisiken und beschleunigen Innovationen in regulierten Märkten.
Häufige Fragen zur funktionalen Sicherheit
?
Was bedeutet funktionale
Sicherheit bei Software?
Funktionale Sicherheit beschreibt die Fähigkeit eines Systems, auch bei Fehlern keine unvertretbaren Risiken zu verursachen. Bei Software bedeutet das, Gefährdungen systematisch zu analysieren, Sicherheitsanforderungen abzuleiten und deren Umsetzung durch Architektur, Tests, Verifikation und dokumentierte Nachweise abzusichern.
?
Was ist ein Safety
Integrity Level (SIL)?
Der Safety Integrity Level beschreibt, wie hoch die Anforderungen an die Risikoreduzierung und die Absicherung sicherheitsbezogener Funktionen sind. Je nach Norm und Anwendung werden unterschiedliche SIL-Stufen verwendet. Mit steigender Einstufung wachsen die Anforderungen an Entwicklungsprozess, Unabhängigkeit, Testtiefe und Nachweisführung.
?
Nach welchen Normen entwickelt infoteam sicherheitskritische Software?
Je nach Projekt arbeitet infoteam unter anderem mit Anforderungen aus IEC 61508 sowie branchenspezifischen Normen für sicherheitskritische Systeme. Entscheidend ist dabei nicht nur die einzelne Norm, sondern ihre konsequente Übersetzung in Risikoanalyse, Architektur, Implementierung, Verifikation und Validierung.
?
Was ist iFSM
von infoteam?
iFSM ist der Prozess von infoteam für funktional sichere Softwareentwicklung. Er unterstützt einen strukturierten Safety-Lifecycle von der Gefährdungsanalyse bis zur Validierung und hilft dabei, notwendige Aktivitäten, Verantwortlichkeiten und Nachweise konsistent und auditierbar umzusetzen.
?
Wie wird funktionale Sicherheit im Entwicklungsprozess nachgewiesen?
Der Nachweis entsteht aus dem Zusammenspiel von Anforderungen, Risikoanalyse, Architektur, Implementierung, Tests und Verifikation. Traceability, dokumentierte Reviews, Coverage-Auswertungen, Konfigurationsmanagement und definierte Freigaben sorgen dafür, dass jederzeit nachvollziehbar bleibt, wie eine Sicherheitsanforderung umgesetzt und geprüft wurde.
?
Welche Rolle spielen automatisierte Tests und Code-Analyse?
Automatisierte Tests, statische Code-Analyse, Coverage-Auswertungen und kontrollierte Reviews helfen dabei, Safety-Anforderungen kontinuierlich abzusichern. Dadurch werden Abweichungen früh sichtbar, Entwicklungsstände bleiben reproduzierbar und notwendige Nachweise entstehen direkt im laufenden Engineering-Prozess statt erst kurz vor dem Audit.
?
Wie werden Änderungen in
sicherheitskritischer Software bewertet?
Änderungen werden über eine strukturierte Impact-Analyse bewertet. Dabei wird geprüft, welche Anforderungen, Risiken, Architekturkomponenten, Schnittstellen und Tests betroffen sind. So lässt sich gezielt entscheiden, welche Artefakte angepasst oder erneut verifiziert werden müssen, ohne unnötig das gesamte System neu bewerten zu müssen.
?
Wann sollte funktionale Sicherheit
im Projekt berücksichtigt werden?
So früh wie möglich. Funktionale Sicherheit sollte bereits bei Risikoanalyse, Requirements Engineering und Architektur berücksichtigt werden. Wird Safety erst nach der Implementierung ergänzt, entstehen häufig zusätzliche Änderungen, Tests und Nachweise. Eine frühe Integration reduziert technische Risiken und erleichtert Audit, Freigabe und langfristige Weiterentwicklung.
Autor: Christopher Schemm – Senior Sales Development Manager
Christopher Schemm verbindet als Senior Sales Development Manager Kundenanforderungen mit technischem und regulatorischem Verständnis. Sein Fokus liegt auf der frühen Einordnung von Safety-Anforderungen, Machbarkeit und Projektzielen. So entstehen belastbare Grundlagen für Projekte, die funktionale Sicherheit, technische Umsetzung und wirtschaftliche Anforderungen sinnvoll verbinden.
