Deutsche BlogsEN50128

EN 50128 Konfigurierbare Systeme: Fluch oder Segen?

Kapitel 8 der EN 50128 beschreibt die Anforderungen an Systeme, die durch Anwendungsdaten oder Anwendungsalgorithmen konfiguriert werden. Dieser Blog fasst die wesentlichen Anforderungen der Norm zusammen und zeigt praxisrelevante Herausforderungen von Software-konfigurierbaren Embedded Systemen auf.

Zunächst einmal bietet die Konfigurierbarkeit nur Vorteile. Das funktionale Verhalten des Gesamtsystems, kann durch einfache und schnelle Änderungen in den Anwendungsdaten an das jeweils gewünschte Verhalten angepasst werden. Hierbei muss weder der Source Code der generischen Software noch dessen Struktur angepasst werden. Eine mehrfache Wiederverwendung wird dadurch ermöglicht. Wenn es gut gemacht ist, sollten sogar die Unit Tests inklusive des Nachweises der strukturellen Source Coverage weitgehend wiederverwendbar sein. Die EN 50128 führt auch an, dass auf diese Weise bewährte, generische Software mehrfach wiederverwendet werden kann. Das sind durchaus gewichtige Vorteile.

Anforderungen der EN 50128 Kapitel 8:

Zunächst fordert die Norm, dass der generische Softwareteil eines konfigurierbaren Systems nach den gleichen Anforderungen der Norm wie auch nicht konfigurierbare Software entwickelt wird.

Normative Forderungen für die Anwendungsdaten:
In Kapitel 8.4.4 wird der Nachweis gefordert, dass die generierten Anwendungsdaten grundsätzlich kohärent und vollständig sind.
Desweiteren wird gefordert, dass jede Aktivität dokumentiert wird, sofern sie zur Sicherung der Richtigkeit und Vollständigkeit der Daten ausgeführt wird.

Normative Forderungen für die generische Software:
In Kapitel 8.4.8.4 wird eine klare und eindeutige Trennung, sowie die Definition einer entsprechenden Schnittstelle zwischen generischer Software und Anwendungsdaten gefordert.

In Kapitel 8.4.8.6 wird gefordert, dass eine deutliche Anwendungsbeschränkung der Software definiert werden muss, sofern es nicht möglich ist alle relevanten Kombinationen von Daten und Algorithmen im Verifikations- Test- und Validierungsprozess zu berücksichtigen.

Normative Forderungen für die Integration und die Verifikation des Gesamtsystems
In Kapitel 8.4.5 wird gefordert, dass Integrationstests im Rahmen der Gesamtinstallation ausgeführt werden, das Zielsystem in vollem Funktionsumfang in Betrieb genommen wird, sowie einem abschließenden Abnahmeprozess innerhalb der Gesamtanlage unterzogen wird.

Diese konzentrierte Auflistung wesentlicher Punkte zum Thema zeigt auf, dass die Norm sich der Komplexität solcher Systeme (sowie der damit verbundenen Schwierigkeiten einer vollständigen Verifikation) durchaus bewusst ist. Allerdings lässt sie bezüglich des angemessenen Umgangs mit dieser Komplexität viele Lösungswege offen.
Nachfolgend beschreibe ich meine Erfahrungen mit der Verifikation solcher Systeme in sicherheitsrelevanten Bereichen.

Erfahrungen aus der Praxis:

Die Komplexität der Verifikation steckt in der Vielzahl und der Varianz der Anwendungsdaten und der sich daraus ergebenden sehr variantenreichen, unterschiedlichen funktionalen Verhaltensweisen.
An funktionalen Requirements solcher Systeme erkennt man sofort, dass es aufgrund der Vielzahl der Konfigurationsmöglichkeiten nicht möglich ist, die Requirements auch nur annähernd 100% zu verifizieren.
Die Verifikation der konfigurierbaren Software und die Validierung/Verifikation der Anwendungsdaten, wie von der Norm gefordert ist der erste Schritt. Allerdings muss die Verifikation der generischen Software aus Tests und aus Begründungen (Äquivalenzklassen) bestehen, dass diese Tests ausreichend sind. Ideal geeignet für die Begründung ist die Software Architektur. Voraussetzung zum Gelingen dieser Vorgehensweise sind gute Requirements und eine detaillierte Architektur. Der große Vorteil liegt darin, dass man damit die Verifikation allgemeingültig machen kann, d.h. egal welche konkrete Konfiguration zur Anwendung kommt, die Verifikation gilt und muss nicht geändert werden!
Die durchaus auch mögliche Alternative (aufgrund der Ausführungen in der Norm) einer Verifikation der Anwendungsdaten, sowie einer Verifikation des konfigurierten Gesamtsystems, ist in ihrer Durchführung sicher deutliche einfacher, da nur genau eine Konfiguration getestet wird. Der große Nachteil hier ist, dass die Verifikation auch nur für diese eine ausgewählte Konfiguration gilt. D.h. für jede weitere Kombination von generischer Software und Anwendungsdaten muss die Verifikation des Gesamtsystems neu erstellt werden. Eine Wiederverwendung bereits vorhandener Tests wird erfahrungsgemäß nur sehr eingeschränkt möglich sein, da sich das funktionale Verhalten des Gesamtsystems aufgrund der Anwendungsdaten eben verändert.

Fazit:

Die Vorteile eines konfigurierbaren Systems, kommen dann voll zur Geltung wenn es gelingt die Verifikation allgemeingültig zu machen, d.h. unabhängig von den individuellen Anwendungsdaten.
Bis 2015 habe ich ein Projekt mit höchsten Sicherheitsanforderungen begleitet, bei dem diese Vorgehensweise (auf meine Initiative hin) erfolgreich zur Anwendung kam.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der HEICON Homepage.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.