Flugzeuge sicher bewegen mit sicherer Steuerungstechnik

Anbieter zum Thema

Lenord, Bauer & Co. GmbH

SPN Schwaben Präzision Fritz Hopf GmbH

ISG Industrielle Steuerungstechnik GmbH

Sensor-Technik Wiedemann GmbH (STW)

Umsetzung in Codesys

Grundsätzlich werden für die Steuerung Entwicklungsumgebungen für die Programmierung in C, Matlab und Codesys angeboten. Für die Entwicklung des DLC im AST-2 wurde auf die Safety Variante Codesys Safety SIL2 basierend auf Codesys V3 gesetzt.

Gemäß den Vorgaben der anzuwendenden Normen wurde eine Risikoanalyse für die Funktionalitäten des Fahrantriebs durchgeführt, die für diverse Teilfunktionen einen geforderten Sicherheitslevel AgPLr >= c ergab. Da eine sicherheitsgerichtete Entwicklung einen wesentlichen Kostenfaktor bei der Produktentstehung und Wartung des späteren Produkts darstellt, wurde beim Entwurf des technischen Sicherheitskonzepts folglich großes Augenmerk auf die klare und eindeutige Definition der Sicherheitsfunktionen und deren Zuordnung zu den jeweiligen Software-Komponenten gelegt.

Hardware unterstützt die Trennung unterschiedlicher Softwareteile

Dabei wurde gezielt darauf geachtet, den sicherheitsrelevanten Teil auf das Notwendige zu beschränken und klare Schnittstellen zwischen sicherheitsrelevanten und nicht sicherheitsrelevanten Softwareteilen zu schaffen. Dies wird in der Softwarearchitektur in sicherheitsgerichteten und nicht sicherheitsgerichteten Modulen abgebildet.

Die klare Zuordnung von Funktionalitäten und die eindeutige Definition der Schnittstellen zwischen den sicherheitsgerichteten und den nicht sicherheitsgerichteten Softwareteilen sind in der Regel immer sinnvoll. Sie führt aber erst zu einer Kostenreduktion bei Entwicklung und Wartung, wenn die Trennung unterschiedlicher Softwareteile auch von der verwendeten Hardware unterstützt wird.

Entwicklung gemäß höchstem Sicherheitslevel

Entsprechend IEC 61508-3, 7.4.2.9 müssen Softwareteile mit unterschiedlicher Sicherheitseinstufung auf einer Steuerung gemäß dem höchsten Sicherheitslevel entwickelt werden. Nur bei geeigneter Unabhängigkeit durch zeitliche und räumliche Trennung sind Ausnahmen zugelassen. Die verwendete ESX-3XL-Steuerung unterstützt die zeitliche und räumliche Trennung von Applikationsteilen durch entsprechende Speicherschutz- und Watchdog-Funktionalitäten. Damit können Softwareteile mit unterschiedlichen Sicherheitsanforderungen unabhängig voneinander ausgeführt werden. Dies eröffnet dem Entwicklungsteam die Möglichkeit, die nicht sicherheitsrelevanten Teile der Applikation gemäß einem vereinfachten Entwicklungs- und Verifikationsprozess zu entwickeln.

Das Ziel war eine normkonforme Parametrierung zu gewährleisten. Außerdem sollte sichergestellt werden, dass Parameteränderungen an nicht sicherheitsrelevanten Applikationsteilen nachweislich keine Auswirkungen auf die sicherheitsrelevanten Applikationsteile haben, um auch an dieser Stelle den nötigen Validierungs- und Verifikationsaufwand möglichst gering zu halten.

So wenig parametrieren wie nötig

Grundsätzlich bringt jede Parametriermöglichkeit zusätzliche Komplexität, zusätzliche Fehlerquellen und somit erhöhten Validierungs- und Verifikationsaufwand mit sich. Bei der Spezifikation und dem Design der sicherheitsrelevanten Module wurde demzufolge darauf geachtet, die Parametriermöglichkeiten auf das Notwendigste zu beschränken.

Mit der klaren Abgrenzung des sicherheitsrelevanten Applikationsteils vom nicht sicherheitsrelevanten Applikationsteil wurde die Grundlage geschaffen, auch die Parametrierung demzufolge in sicherheitsrelevant und nicht sicherheitsrelevant aufzuteilen.

(ID:44623379)