Implementierung eines Personensicherheitssystems für eine Teilchenbeschleunigeranlage

Die Thomas Jefferson National Accelerator Facility (JLab) ist ein nationales Labor des Office of Science des US-Energieministeriums. Es beherbergt die Continuous Electron Beam Accelerator Facility (CEBAF), die einen Elektronenstrahl erzeugt, der für die Grundlagenforschung in der Kernphysik verwendet wird. Vom Start bis zum Ziel legen die Elektronen bis zu fünfeinhalb Runden auf der Rennstreckenkonstruktion der Anlage zurück und werden dabei auf bis zu 12 Milliarden Elektronenvolt (12 GeV) beschleunigt.

Um sicherzustellen, dass die Risiken für das in der Einrichtung arbeitende Personal so gering wie möglich gehalten werden (ALARA), entwirft, betreibt und wartet die JLab Safety Systems Group (SSG) ein technisches Personensicherheitssystem (PSS). Das PSS ist für eine Reihe von Sicherheitsfunktionen verantwortlich, einschließlich der Verhinderung einer direkten Exposition gegenüber ionisierender Strahlung.

Das PSS unterstützt das Personal bei der Kontrolle des Zutritts zu Bereichen, in denen Sicherheitsrisiken bestehen können. Beispielsweise bestehen im Tunnelsystem des Beschleunigers mehrere erhebliche Sicherheitsrisiken, während der Strahl in Betrieb ist. Hierzu gehören ionisierende und nichtionisierende Strahlung, Laserstrahlung und freiliegende elektrische Hochspannungsleiter an den Elektromagneten, die zur Rückführung des Strahls um die Tunnelbögen verwendet werden (Abbildung 1). Im schlimmsten Fall kann die Einwirkung ionisierender Strahlung innerhalb weniger Minuten zu einer tödlichen Dosis führen. Mithilfe des PSS kann das Personal sicherstellen, dass die Arbeiter vor dem Strahlbetrieb die Bereiche des Tunnelsystems des Beschleunigers verlassen haben und dass es den Mitarbeitern anschließend physisch nicht möglich ist, diese Bereiche zu betreten, bis der Strahlbetrieb abgeschlossen ist.

Das PSS wird derzeit einer umfassenden Aktualisierung unterzogen, bei der sämtliche Softwarefunktionen von Grund auf neu geschrieben werden. Zur Entwicklung der Software für das PSS haben wir eine grafische Sprache aus IEC 61131 namens Function Block Diagramming (FBD) ausgewählt.

Model-Based Design mit Simulink^® spielt eine zentrale Rolle in den Implementierungs- und Verifizierungs-Workflows, die wir zum Erstellen der PSS-Software verwenden. Alle Funktionen des PSS werden zunächst in Simulink modelliert und dann mithilfe von Testfällen simuliert, die von Simulink Design Verifier™ generiert werden. Wir haben uns für diese Arbeit für Simulink entschieden, da es eine ausgereifte, schnelle und gut unterstützte Möglichkeit bietet, die erforderlichen grafischen Funktionen zu modellieren und anschließend vor der Implementierung die logische Korrektheit der Entwürfe zu überprüfen. Darüber hinaus können wir mit Simulink Design Verifier unter anderem eine 100-prozentige Test-Abdeckung aller Programmfunktionen erreichen und so die Sicherheit der Designs nachweisen.

Es ist ein erheblicher Vorteil, alle erforderlichen Aktivitäten des Entwurf-, Test- und Sicherheitslebenszyklus – einschließlich Funktionstests, Rechenfehlerprüfung (z. B. Verletzungen des Ganzzahlbereichs) und Abdeckungsanalyse – in einer einzigen Umgebung durchführen zu können.

Herausforderungen hinsichtlich Umfang und Komplexität

Das PSS ist dafür ausgelegt, zwei breite Kategorien von Risiken der Sicherheitsintegritätsstufe 3 zu erkennen und darauf zu reagieren: Verstöße gegen die Zugangskontrolle und Verstöße gegen die Strahlsteuerung. Im Wesentlichen sind dies zwei Seiten derselben Medaille. Zwar sind die auslösenden Ereignisse unterschiedlich, doch führen beide Arten von Verstößen zu einem Verringerung des Abstands zwischen Menschen und Strahl. Wenn bei einem Verstoß gegen die Zugangskontrolle Personen einen Sperrbereich innerhalb der Anlage betreten, müssen sämtliche Gefahren innerhalb weniger Sekunden beseitigt werden (d. h. bevor Personen die unteren Ebenen der Tunnel erreichen). Bei einer Verletzung der Strahlsteuerung kann der Strahl fehlgelenkt werden, und zwar in Richtung eines zugänglichen Bereichs oder auf ein Strahlstoppgerät, das einen zugänglichen Bereich isoliert. Aufgrund der hohen Leistung des Strahls (1 Million Watt) muss der Strahl im letzteren Szenario in nur wenigen Millisekunden abgeschaltet werden.

Die Herausforderungen bei der Entwicklung und Überprüfung des PSS werden durch die Komplexität und den Umfang des Systems noch größer. Das PSS umfasst über 2.200 E/A-Kanäle (einschließlich Sensoren und Aktoren), die auf die neun Segmente der Anlage verteilt sind. Die einzelnen Segmente sind durch miteinander verbundene Tore und Türen voneinander getrennt. Die PSS für jedes Segment besteht aus einem doppelt redundanten Sicherheitssystem auf Basis von Sicherheits-SPS des Typs Siemens^® Series 1500.

Insgesamt enthält das System 18 verteilte Sicherheits-SPS und 200 Kommunikationskanäle zwischen den SPSen, die zum Datenaustausch verwendet werden. Bei jedem Taktzyklus werden Daten von fast 2.000 Sensoren ausgelesen und zur Verarbeitung über Glasfaserkabel an das Hauptkontrollzentrum zurückgesendet. Sobald die Ergebnisse berechnet sind, werden sie zurück an das Feld gesendet, um die verschiedenen Warn- und Abschaltgeräte zu steuern. Dieser gesamte Zyklus ist in nur wenigen Millisekunden abgeschlossen und läuft kontinuierlich. Etwa 50% des Codes im PSS werden für Diagnose- und Selbstüberwachungszwecke (d. h. Fehlererkennung) verwendet.

Jedes Steuerungssystem dieses Umfangs würde erhebliche technische Investitionen erfordern. Allerdings können Sicherheitssysteme bei der Implementierung derselben Funktionalität drei- bis zehnmal mehr kosten als Nicht-Sicherheitssysteme. Da wir uns auf die Sicherheits-SPS von Siemens mit der FBD-Sprache konzentrierten, war die Verwendung von Simulink PLC Coder™ zum Generieren von strukturiertem Text nach IEC 61131-Norm direkt aus unseren Simulink-Modellen nicht möglich. Stattdessen wurden alle Funktionsblöcke zunächst in Simulink entworfen und überprüft, bevor sie mithilfe der Function Block Diagram-Sprache im TIA-Portal (der integrierten Entwicklungsumgebung von Siemens für die Entwicklung und Bereitstellung von SPS) manuell neu implementiert wurden (Abbildung 2).

Erweiterung und Verbesserung des traditionellen Workflows

Angesichts des Umfangs und der Komplexität des PSS mussten wir prüfen, wie wir unseren vorhandenen Entwicklungsworkflow optimieren können. Im herkömmlichen Arbeitsablauf müssten, nachdem das Verhalten eines Funktionsblocks in Simulink definiert wurde, Testfälle in Simulink definiert werden, einschließlich Eingabevektoren (Stimuli) und Ausgabevektoren (Ziele). Die Testfälle würden mit Simulink Test™ ausgeführt und die Test-Abdeckung mit Simulink Coverage™ gemessen (Abbildung 3, Route 1).

Dieser Ansatz bringt zwei wesentliche Probleme mit sich. Erstens kann die Aufgabe, Testfälle für jede Funktion manuell zu generieren, selbst für erfahrene Testingenieure extrem zeitaufwändig sein. Zweitens: Wenn die Tests keine 100-prozentige Abdeckung für die getestete Funktion erreichen, kann es oft sehr schwierig sein, festzustellen, ob dies auf einen Entwurfsfehler in der Funktion selbst oder einen Mangel in der Testmethode zurückzuführen ist, für den weitere Tests definiert und ausgeführt werden müssten.

Um diese Probleme zu lösen, haben wir Simulink Design Verifier verwendet, um automatisch Testfälle (unter Verwendung formaler Methoden) zu generieren, die eine 100-prozentige Abdeckung erreichen. Dadurch entfällt die Aufgabe, Testfälle manuell zu definieren. Darüber hinaus wird die Frage gelöst, wie Entwurfsfehler in der getesteten Funktion erkannt werden können. Wenn Simulink Design Verifier keine 100-prozentige Abdeckung erreichen kann, hebt es die Stelle des Entwurfsfehlers in der Funktion selbst hervor. Dieser Arbeitsablauf stellt eine wesentliche Verbesserung gegenüber der herkömmlichen Methode dar (Abbildung 3, Weg 2a).

Die Verwendung von Simulink Design Verifier bietet zwar erhebliche Vorteile, führt jedoch auch zu einer neuen Aufgabe. Bei der herkömmlichen Methode baut der Testingenieur das gewünschte funktionale Verhalten (die Ziele) normalerweise implizit in die Testfälle ein, während diese entwickelt werden. Vorausgesetzt, die Tests werden bestanden, verhält sich die Funktion ordnungsgemäß. Beim Einsatz automatischer Testfallgeneratoren verfügen die formalen Algorithmen allerdings über keine Kenntnis darüber, was als korrektes logisches Verhalten gilt. Aus diesem Grund ist es notwendig, die von Simulink Design Verifier generierten Testfälle (und die entsprechenden Ergebnisse) auf Verhaltenskorrektheit zu überprüfen, d. h. die generierten Tests zu prüfen, um sicherzustellen, dass sich die Funktion wie beabsichtigt verhält.

Dies kann entweder durch eine direkte Überprüfung der Testfälle (zusammen mit den erwarteten Ausgaben) mithilfe von Zeitdiagrammen oder durch eine Simulation der Testfälle und die Beobachtung der zeitbasierten Simulationsergebnisse am Modell selbst erfolgen. Beide Optionen können etwas kompliziert und fehleranfällig sein, insbesondere wenn Funktionen viele Ein- und Ausgaben haben. Für derartige Tests ist ein erfahrener Testingenieur mit installiertem Simulink erforderlich. Außerdem besteht die Gefahr der Prüfungsblindheit, wenn viele Funktionen geprüft werden müssen.

Da wir daran interessiert waren, unsere Entwurfsprüfungen von einer Gruppe in einer sitzungsartigen Umgebung durchführen zu lassen, entwickeln wir ein Konzept namens Behavioral Verification Checklists zur Überprüfung der Verhaltenskorrektheit unserer Softwarefunktionen. Wir haben ein MATLAB^®-Skript erstellt, das die Simulink-Testfälle in ein prozedurales Format konvertiert, damit sie schneller und einfacher zu lesen und zu interpretieren sind als herkömmliche Zeitdiagramme (Abbildung 3, Route 2b).

Ein genauerer Blick auf Checklisten zur Verhaltensüberprüfung

Ein zentraler Aspekt unseres neuen Workflows ist die Möglichkeit für Ingenieure, die Verhaltenskorrektheit von Funktionsblöcken mithilfe von Checklisten zu überprüfen, anstatt Zeitdiagramme zu lesen oder Simulationen auszuführen. Diese Methoden können oft zeitaufwändig und fehleranfällig sein, insbesondere bei einer großen Anzahl von E/A-Vorgängen. Um diesem Problem zu begegnen, wurden Checklisten zur Verhaltensüberprüfung entwickelt, die präzise und leicht lesbar sind und sich auf die Informationen konzentrieren, die für die Prüfer am interessantesten sind. Ingenieure können diese Checklisten entweder allein oder in Gruppen verwenden, um jeden Funktionsblock und seine Reaktion auf Änderungen der Eingangsstimuli (Tabelle 1) zu beurteilen, selbst wenn sie Simulink nicht regelmäßig verwenden oder es nicht installiert haben. Dadurch kann eine größere Anzahl von Fachexperten in den Entwurfsprüfungs-Prozess einbezogen werden und die Belastung des Testingenieurs wird reduziert. Da die Ergebnisse offline von mehreren Personen überprüft werden, erhöht sich die Wahrscheinlichkeit, logische Fehler zu erkennen. Die Checklisten werden automatisch mithilfe von MATLAB-Skripten aus Simulink-Testfällen generiert, die wiederum automatisch mithilfe von Simulink Design Verifier generiert werden.

Simulink-Testfälle ins TIA Portal importieren

Im letzten Abschnitt unseres Workflows implementieren und testen wir die Funktionsblöcke erneut in unserer Ziel-SPS-Umgebung. Wir beginnen mit der Verwendung eines zweiten MATLAB-Skripts, um die Simulink Testfälle in Siemens-Testfalldateien (Textdateien mit der Erweiterung .TAT) zu konvertieren (Abbildung 4). Wir übersetzen auch die Funktionsblockdesigns von Simulink in das TIA Portal. Abschließend führen wir die konvertierten Testfälle mit Siemens PLCSIM und Test Suite Advanced auf dem SPS-Code aus, um die Äquivalenz auf dem Ziel sicherzustellen.

TEST_CASE “TEST_OUTPUT_TEST_CASE_1”
 
PROPERTY
AUTHOR : “METCALF”
VERSION : “1.0”
COMMENT : “Test Case 1 for TEST_OUTPUT function block.”
SCOPE : “PSS_PLC”
END_PROPERTY
 
VAR
TEST_INITIAL_CONDITIONS : TEST_OUTPUT_IDB.TEST_INITIAL_CONDITIONS := FALSE;
TEST_CONFIGURED : TEST_OUTPUT_IDB.TEST_CONFIGURED := TRUE;
TEST_REQUESTED : TEST_OUTPUT_IDB.TEST_REQUESTED := FALSE;
TEST_CONTINUOUS_CONDITIONS : TEST_OUTPUT_IDB.TEST_CONTINUOUS_CONDITIONS := TRUE;
MINIMUM_TEST_DURATION : TEST_OUTPUT_IDB.MINIMUM_TEST_DURATION := T#74ms;
TEST_OUTPUT : TEST_OUTPUT_IDB.TEST_OUTPUT;
END_VAR
 
STEP : “STEP_1”
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 399);
END_STEP
 
STEP : “STEP_2”
TEST_CONFIGURED := FALSE;
TEST_CONTINUOUS_CONDITIONS := FALSE;
MINIMUM_TEST_DURATION := T#0ms;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
 
STEP : “STEP_3”
TEST_REQUESTED := TRUE;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
. . . 
. . . 
. . . 
END_TEST_CASE

Abbildung 4. Teil eines Siemens-Testfalls, der von einem MATLAB-Skript aus einem Simulink-Testfall generiert wurde.

Bereitstellung und Anwendung des Workflows auf andere Projekte

Hochintegritäts-Sicherheitssysteme wie das PSS erfordern strenge Entwicklungsabläufe, um das Risiko von Softwarefehlern zu minimieren, die zu unsicheren – und möglicherweise sogar katastrophalen – Folgen führen. Beim Duplizieren von Softwarekomponenten über redundante Verarbeitungsmodule hinweg vervielfachen sich diese Risiken noch, da jeder Fehler zu einer gemeinsamen Ursache (Common Cause, CC) wird. Aus diesen Gründen legt die IEC 61508 großen Wert auf die Vermeidung systematischer Fehler, die durch Software in Sicherheitssysteme eingebracht werden. Mit Model-Based Design und unserem neuen Workflow haben wir eine Steigerung unserer systematischen Kompetenz — wie in IEC 61608 definiert — auf einem Niveau, das ein sehr hohes Maß an Gewissheit bietet, dass wir ein sicheres und fehlerfreies System implementiert haben.

Wir befinden uns derzeit in der Endphase der Bereitstellung des aktualisierten PSS für die letzten verbleibenden Beschleunigersegmente (Abbildung 5). Die Fertigstellung ist für Herbst 2024 geplant. Nach der Fertigstellung des PSS wird eine unserer nächsten Entwicklungsprioritäten die Aktualisierung unseres Beam Loss Monitoring (BLM)-Systems sein, das Teil unseres Maschinenschutzsystems ist. Für dieses Projekt beabsichtigen wir, einen Arbeitsablauf zu verwenden, der dem für das PSS verwendeten sehr ähnlich ist. Da das Ziel für das BLM-System jedoch ein FPGA sein wird, planen wir, mit HDL Coder™ synthetisierbaren HDL-Code direkt aus unseren Simulink Modellen zu generieren und die manuelle Codierung auf dem Ziel fast vollständig zu vermeiden. Darüber hinaus hoffen wir, mithilfe der Hardware-in-the-Loop-Funktionen von HDL Verifier™ unseren Verifizierungs- und Validierungsworkflow auf dem Gerät vereinfachen und beschleunigen zu können.