Wie sichere Software bezüglich der Maschinenrichtlinie zu bewerten ist

Rein hardware-basierte Sicherheitssysteme sind betriebsbewährt, in ihrer Robustheit und Einfachheit unübertroffen und für viele Kleinapplikationen weiterhin das Mittel der Wahl. Doch schon Applikationen mit Varianz und/oder dynamischen Aufgaben, sind heute Software basiert auszulegen und zu entwickeln.

SPS mit der Eignung für Maschinensicherheits-Applikationen gibt es bereits seit den 1980er Jahren. Diese lange Zeitspanne lässt eigentlich vermuten, dass alle Facetten des Themas Software beleuchtet wurden. Die Praxis zeigt, dass dem nicht so ist: Sowohl Begrifflichkeiten als auch der Umgang aus dem Kontext „Software und Sicherheit“ haben noch viel Luft nach oben. Innerhalb des Technischen Ausschusses Sicherheitstechnik (TASi) im ZVEI wurde deshalb die Arbeitsgruppe „Software“ ins Leben gerufen, um dies zu beleuchten und nach Lösungen zu suchen.

Gestartet ist die Arbeitsgruppe mit den normativen Hintergründen und dem Entwicklungs-/Entstehungsprozess sowie wichtigen Fakten und betriebsbewährten Abläufen. In einem weiteren Schritt folgt eine Bewertung der rechtlichen Aspekte bei Erstellung und ‚Verkauf‘ von Software im Kontext der Maschinenrichtlinie.

Die ersten normativen Grundlagen, die sich unter anderem mit den Anforderungen an Software beschäftigt haben, sind in den 1980er- und 1990er Jahren entstanden:

• DIN V VDE 19250 „Messen, Steuern, Regeln; Grundlegende Sicherheitsbetrachtungen für MSR-Schutzeinrichtungen“ und
• DIN V VDE 0801 „Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben“.

Beide Normen entstanden in einer Zeit, als der Einsatz von Mikrocontrollern und Software in Applikationen der Maschinensicherheit noch nicht beschrieben war. Basierend auf diesen beiden Standards wurde international die Entwicklung der IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“ vorangetrieben. Darin wurde erstmals der Sicherheits-Lebenszyklus, als Basisnorm, von solchen Systemen umfänglich beschrieben.

Die aktuellen Ausgaben der IEC 62061 und der ISO 13849-1 enthalten Beschreibungen, wie der Anwender eines Gerätes Software im Allgemeinen „richtig“ einsetzt. An vielen Stellen wird jedoch auch aus diesen Normen auf die Grundlagen der IEC 61508 verwiesen.

Ausführbare Programme, Software, Skripte oder auch Apps - die Literatur kennt vielfältige Bezeichnungen für die unterschiedlichen Arten und Aggregierungen von Software. Als ein Ergebnis der TASi-Arbeitsgruppe Software, wurden Bezeichnungen erarbeitet, die auch im weiteren Verlauf des Artikels beschrieben und unterschieden werden:

• Anwendungsprogramm (ASW)
• Systemprogramm (ESW)
• Zusatzprogramme

Ein Anwendungsprogramm ist ein Programm, das der Anwender eines sicherheitsbezogenen Gerätes erstellt und zum Beispiel den sicheren Teil der Maschinensteuerung abdeckt. Im Allgemeinen enthält es Ablaufketten, Bedingungen, Grenzwerte und Ausdrücke, die die entsprechenden Eingänge, Ausgänge, Berechnungen und Entscheidungen beeinflussen. In einer sicherheitsbezogenen Steuerung sind das zum Beispiel die Sicherheitsfunktionen.

Systemprogramme werden als Bestandteil des Systems mitgeliefert und sind nicht dafür vorgesehen, durch den Anwender eines Geräts verändert zu werden. Systemprogramme werden meist auch als Embedded-Software oder Firmware bezeichnet. Die Hardware-Abstraktions-Schicht (HAL) zählt ebenfalls zu den Systemprogrammen. Sie umfasst insbesondere Treiber, die den direkten Zugriff auf die Hardware des Systems realisieren und stellt einheitliche Schnittstellen zur Verfügung.

Zusatzprogramme sind Software-Werkzeuge für die Erstellung, Pflege und Dokumentation von Software. Unter diese Programme fallen beispielsweise Compiler oder die Konfigurations-Software von Sicherheitssteuerungen oder Sicherheits-Laserscannern. Diese Hilfsprogramme sind für den Betrieb des Systems nicht erforderlich.

Sichere Software“ ist Bestandteil eines sicherheitsbezogenen Systems und stellt eine Sicherheitsfunktion zur Minderung eines Risikos bereit, „Standard-SW“ hat andere Aufgabenstellungen zu erfüllen. Zu jedem Sichere-Software-Projekt gehört eine detaillierte Projektplanung und die Umsetzung entsprechend einem Modell, beispielsweise nach dem V-Modell. Dieser Grundsatz sollte natürlich auch für Standardsoftware gelten – für sicherheitsbezogene Software ist sie jedenfalls Pflicht. Hier sind die Spezifikations-, Implementierungs-, Verifikations-, Validierungs- und Testschritte zusammen mit einer belastbaren Dokumentation besonders wichtig. Bei sicherheitsbezogener Software, zum Beispiel in Sicherheitsbauteilen, wird der gesamte Entwicklungsprozess in der Regel von einer ‚Notifizierten Stelle‘ begleitet und die Ergebnisse der einzelnen Phasen bewertet und testiert.

Standardsoftware wird in den unterschiedlichsten Programmiersprachen erstellt. Welche Programmiersprache zum Einsatz kommt, hängt wiederum von der umzusetzenden Aufgabe, der Komplexität, der Präferenz des Programmierers oder der zur Verfügung stehenden Hardware ab. Hier sind dem Entwickler normativ gesehen eigentlich keine Grenzen gesetzt.

Bei sicherheitsbezogener Software sind gewisse Randbedingungen zu beachten. Die Sicherheitsnormen IEC 61508, IEC62061 und ISO13849-1 fordern (abhängig vom Sicherheitsniveau) einen bewerten Codingstandard, mit dem Ziel die Programmiersprache einzuschränken, um Fehler zu vermeiden. Dadurch werden kritische Eigenschaften der jeweiligen Programmiersprache, beispielsweise Sprünge, von Anfang an unterbunden.

Hinzu kommt die Anforderung, dass Sichere Software nur von qualifizierten Personen entwickelt werden darf, Dies ist der wesentliche Unterschied zwischen einer „Standard“-Software und einer „Sicheren“ Software.

Welche Anforderungen werden an die Hardware gestellt?

Analog zum Schichten-Modell der Software mit Betriebssystem, ASW und ESW wird auch die Hardware betrachtet: Jede Software benötigt eine Logikeinheit als Plattform. Grundsätzlich unterschieden wird zwischen zuvor bewerteter sicherheitsrelevanter Hardware (zum Beispiel nach IEC 61508) und nicht bewerteter sicherheitsrelevanter Hardware

Sicherheitsrelevante Hardware ist basierend auf den Anforderungen aus einer relevanten Norm zur funktionalen Sicherheit (z.B. IEC 62061 oder ISO 13849-1) zu bewerten und erfüllt dann einen bestätigten Performance Level (PL) oder Safety Integrity Level (SIL). Bei nicht bewerteter sicherheitsbezogener Hardware muss der Integrator, also der Gerätehersteller oder ein Maschinenbauer, dafür sorgen, dass die systematische Sicherheits-Integrität der Hardware gegeben ist. Er muss dann alle Maßnahmen zur Beherrschung zufälliger Hardwarefehler treffen.

Die generellen Hardware-Anforderungen werden in den Normen zur funktionalen Sicherheit dargestellt. Hierunter fallen insbesondere die Struktur der Hardware und die Eigenschaften der Systemdiagnose. Ob die Logikeinheit/Hardware für die geplante Sicherheitsfunktion wirklich geeignet ist, hängt neben der eigentlichen Funktionalität von der systematischen Eignung der Software ab. Normativ werden je nach Sicherheitsniveau, unterschiedliche Maßnahmen und Techniken, für den Entwurf der Software empfohlen. Wurden alle Aspekte durch den Hersteller in Betracht gezogen, ist klar, ob die vorliegende Hardware für eine sicherheitsbezogene Applikation geeignet ist oder nicht.

Aktuelle sicherheitsbezogene Geräte und Systeme bieten diverse Kommunikationsschnittstellen. Für die Realisierung einer sicherheitsbezogenen Datenkommunikation gibt es grundsätzlich zwei mögliche Lösungsansätze:

• White Channel
• Black Channel

Beim White Channel muss der gesamte Kommunikationskanal (inklusive der benötigten Hardware) gemäß einer Norm zur funktionalen Sicherheit entworfen, implementiert und validiert werden. Dies trifft beispielsweise auf proprietäre, also herstellerspezifische Kommunikationsschnittstellen zu.

Beim Black Channel-Ansatz, der in der Sicherheitstechnik weit verbreitet ist, sind nicht alle Teile des Kommunikationskanals gemäß einer Norm zur funktionalen Sicherheit entworfen oder validiert. Bei diesem Prinzip wird die Kommunikation über eine „sichere Schicht“ (FSCP) realisiert, die auch bei der Qualifikation des sicherheitsrelevanten E/E/PE-Teilsystemen oder Elementen betrachtet wird. In diesem Fall müssen die Maßnahmen zur Beherrschung der Übertragungsfehler, um eine sicherheitsrelevante Übertragung zu realisieren, von der „sicheren Schicht“ gewährleistet werden. Alle sicheren Bussysteme wie Profisafe, Safety over Ethercat oder AS-i Safety ermöglichen entsprechend des Black-Channel-Prinzipsdie sichere Kommunikation zwischen den Busteilnehmern und/oder den Busteilnehmern mit der übergeordneten Steuerung.

Welche Anforderungen gibt es an die Security?

Im Gegensatz zu Safety, deren Hauptziel die Sicherheit von Personen und der Umwelt ist, hat Security die Informationssicherheit und damit in erster Linie den Schutz der Daten im Fokus. Das bringt einige Schwachstellen mit sich, sowie die Verwundbarkeit des Systems. Solche Einfallstore liegen unter anderem in der Verwendung von USB-Sticks, der Kommunikation vernetzter Systeme über WLAN oder die Nutzung externer Datenspeicher wie eine Cloud. Sobald sicherheitsbezogene Geräte und Systeme Schnittstellen zur Außenwelt haben, stellt sich das Security Thema im besonderen Maße.

Der Hauptunterschied zu Safety liegt in der Dynamik: Klassische Safety-Maßnahmen wie der Eingriffsschutz in eine Presse ist eine eher statische Lösung, ein Pre-Prozess. Der Betreiber führt eine Risikoanalyse durch und darauf aufbauend, werden Maßnahmen für Hardware und Software abgeleitet und weitgehend konstant gehalten.

Bei Security wird zwar auch eine Risikoanalyse durchgeführt, im Gegensatz zur Safety sind die Security-Maßnahmen jedoch hoch dynamisch, weil sich die Angriffsvektoren ständig ändern und daher die Maßnahmen permanent angepasst und nachgeführt werden müssen.

Mehr noch: Bei künftigen Industrie 4.0 Anwendungen verschmelzen Security- und Safety-Maßnahmen, da es keine klassischen geschlossenen Systeme mehr gibt und jede Teilkomponente Daten liefert und verarbeiten soll.

Dadurch entstehen für die Safety-Welt weitere Herausforderungen. Zum Beispiel gilt es zu verhindern, dass ein potentieller Angreifer Sicherheitsfunktionen manipulieren kann. Eine klassische Risikoanalyse, die nur die Anlage oder das System betrachtet, reicht daher nicht mehr aus, um die Sicherheit von Personen und Umwelt zu gewährleisten. Insbesondere der wirtschaftliche Schaden erreicht andere Dimensionen. Deswegen führt kein Weg an einer gesamthaften Risikobetrachtung vorbei.

Besonders die Kombination aus Safety- und Security-Anforderungen – die sich speziell bei den Anforderungen an Security je nach Bedrohungslage vom Prinzip her täglich ändern können – ist nicht ganz so einfach. Hier darf es nicht zu uneinheitlichen oder gar inkompatiblen Anforderungen in einzelnen europäischen Richtlinien und Normen kommen. Die eindeutige und damit ideale Lösung für alle Marktteilnehmer, und daher auch vom ZVEI propagiert, ist eine separate = horizontale Europäische Produktregulierung für Cybersicherheit.

Ziele in der Software-Wartung für den Ersteller eines Programms sind in der Regel die Reduzierung von Fehlern, die Erweiterung von Funktionen und auch die Erhöhung der Sicherheit – hier der Security. Der Anwender versucht nach Möglichkeit „einheitliche Versionsstände“ innerhalb einer Maschine oder Anlage zu haben. Nur so ist sichergestellt, dass sich die Maschinen und heruntergebrochen auch die einzelnen Geräte gleich verhalten. Software-Wartung passiert heute durch Updates oder Upgrades „im laufenden Betrieb“. Die erste Frage ist somit: Wer darf ein solches Update oder Upgrade in die sicherheitsbezogene Steuerung einspielen und dann in der Konsequenz auch ausführen?

Dafür hat die Arbeitsgruppe Software Empfehlungen für ‚Software-Updates im Feld‘ für:

• Hersteller sicherheitsbezogener Geräte/Komponenten,
• Maschinenhersteller und
• Maschinenbetreiber

erarbeitet.

Update per Download – weniger Aufwand aber mehr Risiko

Hersteller sicherheitsbezogener Geräte/Komponenten sollten Updates von Embedded Software (ESW), also der systemnahen Software, nur durch entsprechend geschulte und unterwiesene Personen zulassen. Ziel muss sein, das vorher bewertete Sicherheitsniveau der Geräte/Komponenten, auch nach dem Update zu erhalten. Hieraus ergibt sich auch die Anforderung, dass eine Schnittstelle für Updates im Security-Konzept entsprechend berücksichtigt sein muss, damit nur der zugelassene Personenkreis ein solches Update durchführen kann. Auch wenn der Hersteller eines Gerätes oder einer Komponente solche Updates per Download anbietet – er bleibt für die Sicherheit verantwortlich, mithin in der Haftung!

Für Maschinenhersteller gilt prinzipiell das Gleiche: Sie sollten ebenfalls Updates der Anwendungsprogramme (ASW), also der Ablaufsteuerung, nur durch entsprechend geschulte und unterwiesene Personen zulassen, um das Sicherheitsniveau auch nach dem Update zu erhalten. Auch in diesem Fall muss die Schnittstelle im Security-Konzept berücksichtigt werden. Der Maschinenhersteller bleibt für den Erhalt des Sicherheitsniveaus voll verantwortlich – egal auf welchem Weg (auch bei einem Download) das Update bereitgestellt wurde.

Für Maschinenbetreiber gilt: Der Betreiber einer Maschine ist nach dem Gefahrübergang, also nach der Inbetriebnahme incl. Abnahme und Unterweisung, in der Verantwortung, das Sicherheitsniveau seiner Maschine während der gesamten Betriebsdauer zu erhalten. Oft nutzt der Maschinenbetreiber hierzu den Service des Maschinenherstellers. In einigen Fällen müssen Maschinenbetreiber jedoch die Rolle des Maschinenherstellers übernehmen, etwa bei einer Insolvenz des Maschinenherstellers. Auch der Maschinenbetreiber sollte Updates der Steuerungssoftware nur durch entsprechend geschulte und unterwiesene Personen zulassen. Nur so ist sichergestellt, dass das vorher bewertete Sicherheitsniveau erhalten bleibt. Falls der Maschinenbetreiber nach der Inbetriebnahme die Steuerungssoftware modifiziert oder alternative ASW verwendet, ist er selbst für den Erhalt des ursprünglich realisierten Sicherheitsniveaus verantwortlich. Er übernimmt dann sozusagen die Rolle des Maschinenherstellers in Bezug auf die Verantwortung.

Knackpunkt Software und Maschinenrichtlinie

Die Maschinenrichtlinie entfaltet wie alle Richtlinien keine unmittelbare Wirkung. Sie muss in nationales Recht transformiert werden. In Deutschland ist dies durch das Produktsicherheitsgesetz (ProdSG) und die Maschinenverordnung geregelt.

Aber: Kann Software überhaupt ein Produkt sein?

Bei der Einhaltung der gesetzlichen Anforderungen an Systeme der Funktionalen Sicherheit mit Software bedarf es einer detaillierten Betrachtung. Der Anwender eines solchen Systems erwartet ein zuverlässig funktionierendes Produkt, das den Sicherheitsanforderungen ohne Funktionseinschränkungen genügt. Es gibt gesetzliche Regelungen, die bei Nichteinhaltung Anwendung finden:

• in der deliktischen Produkthaftung
• Produzentenhaftung nach § 823 Bürgerliches Gesetzbuch (BGB)
• Produkthaftungsgesetz (ProdHaftG)
• im Kaufrecht/Werkvertragsrecht
• Mängelhaftung nach §§ 434 ff, §§634 ff BGB),
• im öffentlichen Produktsicherheitsrecht
• Europäische Richtlinien
• Produktsicherheitsgesetz (ProdSG)
• im Strafrecht
• insbesondere §§ 222, 229 Strafgesetzbuch (StGB).

In diesem Zusammenhang lässt sich die Frage, ob Software (ESW und/oder ASW) ein Produkt sein kann, nicht pauschal beantworten.

Die Einhaltung der Pflichten, die sich aus der Maschinenrichtlinie (2006/42/EG) ergeben, obliegt dem Hersteller einer Maschine. Die gesetzlichen Anforderungen an Hersteller von sicherheitsbezogenen Systemen mit Software werden in der Maschinenrichtlinie Anhang 1 Abschnitt 1.2 dargelegt. Dort heißt es: Sicherheitsbezogene Steuerungen und Befehlseinrichtungen sind unter anderem so zu konzipieren und zu bauen, dass es nicht zu Gefährdungssituationen kommt. Insbesondere müssen diese Komponenten so ausgelegt und beschaffen sein, dass ein Defekt der Hardware oder ein systematischer Fehler in der Software (ESW und ASW) nicht zu einer Gefährdungssituation führt.

Die Software (ESW und ASW) selbst kann keine Sicherheitsfunktion ausführen, sie ist ein Teil der Logikeinheit und besteht aus verschiedenen Software-Teilen (Betriebssystem, ASW, ESW, etc.) die zum Einsatz kommen. Deswegen ist eine aussagekräftige Bewertung nur im Gesamtsystem, bestehend aus allen Softwareteilen, Softwareschichten und der Logikeinheit (Hardware) möglich und nicht für einzelne Software-Funktionen.

Im Umkehrschluss: Wird Software gesondert in Verkehr gebracht, um Sicherheitsfunktionen einer Maschine zu realisieren, dann ist sie kein „Sicherheitsbauteil“, sondern die Logikeinheit in Kombination mit dieser (separaten) Software und allen Software-Schichten (siehe Abbildung 1) die darauf laufen. Diese Definition ist im Leitfaden für die Anwendung der Maschinenrichtlinie 2006/42/EG; vom Oktober 2019 beschrieben:

• §42 (safety components) und
• §418 (table of components which are considered to be logic units)

Die Konformitätserklärung bezieht sich somit auf die Hardware mit integrierter Software. Sofern die Software zum „Download“ für eine Hardware (physikalische Komponente) eigenständig bereitgestellt wird, müssen in einem solchen Fall bereits alle sich aus der Maschinenrichtlinie ergebenden Herstellerpflichten für sicherheitsbezogene Embedded Software (ESW) und Anwendersoftware (ASW) berücksichtigt werden.

Embedded Software (ESW) in Logikeinheiten zur Gewährleistung der Sicherheitsfunktion nach Maschinenrichtlinie, Anhang V, gilt somit als Sicherheitsbauteil im Sinne des Artikels 2 Buchstabe c der Maschinenrichtlinie, wenn diese als Teil eines sicherheitsbezogenen Steuerungssystems geliefert wird.

Gesondert, das heißt separat in Verkehr gebrachte sicherheitsbezogene Anwendersoftware (ASW) ist kein Sicherheitsbauteil im Sinne der Maschinenrichtlinie. Der Grund: Für sich alleine kann die Software keine Sicherheitsfunktion ausführen. Sie benötigt hierzu immer eine Umgebung d.h. Hardware. Realisierung, Verifizierung und Validierung dieser sicherheitsbezogenen Anwendersoftware (ASW) soll entsprechend des aktuellen Stands der Wissenschaft und Technik erfolgen (z.B. nach IEC 61508). Die korrekte Integration einer sicherheitsbezogenen Anwendungssoftware (ASW) in eine Maschine wird durch die Konformitätserklärung für diese Maschine bestätigt. Der Maschinenhersteller trägt somit die alleinige und unmittelbare Verantwortung für die Konformität seines Produkts mit den anzuwendenden Rechtsvorschriften.

Aus Sicht der TASi-Arbeitsgruppe Software ist eine aussagekräftige Bewertung von Software nur im Gesamtsystem möglich, bestehend aus allen Softwareteilen, Softwareschichten und inklusive Logikeinheit beziehungsweise Hardware. Deswegen kann Software auch kein Sicherheitsbauteil im Sinne des Anhang IV der Maschinenrichtlinie sein.

• Klaus Stark
  Senior Manager Innovation Management bei der Firma Pilz in Ostfildern und Vorsitzender des Technischen Ausschuss Sicherheitstechnik des ZVEI.
• Timo Loeffler 
  Functional Safety Manager bei der Sick Ag in Waldkirch.
• Frank Bauder
  Leiter Competence Center Services bei Leuze in Owen und Mitglied im Technischen Ausschuss Sicherheitstechnik des ZVEI.