ein konfigurierbares technisches Interlock System für RF-Stationen bei DESY derzeit im Einsatz bei FLASH, PITZ, beim Modulator-Teststand sowie bei Modultestständen in Hamburg Aufgabe im Fall von Fehlfunktionen Schaden von teuren Komponenten der RF-Stationen abzuwenden Anforderungen Konfigurier- und erweiterbar Modularer Aufbau Die Interlock-Funktionalität ist während des Betriebes unabhängig von Software auf dem Controller Handling unterschiedlichster Signaltypen (digitale, analoge, optische) Selbsttest nach Power on Systemarchitektur
Interlock Crate 19’’ 4HU Crate 20 verfügbare slave slots Backplane mit parallelem Bus	Interlock Crate
Interlock Module Controller Modul NIOS II Processor, 64MB RAM, 16MB Flash Ethernet Interface Slave Module Digital I/O, 32 input, 32 output channels Analog window comparator, 36 input channels Light I/O, 16 input, 16 output channels Analog I/O, 8 input, 8 output channels Distribution Panels
20mA Konverter	PT100-Interface
Output via Opto-Relais	Light In_Light Out
Software System-Selbsttest nach Power-up Zugriff auf Einstellungen via WEB-Browser Zugriff erfordert Authentifizierung Display des Status aller Signale und von maskierten Kanälen Konfigurationsmodus für Software- und Firmware (FPGA design) Updates

Die für das Interlock System Revision 3 speziell entwickelte Software erfüllt für den Betrieb folgende notwendige Aufgaben:

Systemüberblick

Eine typische Interlock-System Konfiguration besteht aus einem 19-Zoll 4HU Crate, einem Interlock-Controller und mehreren Interlock-Slaves. Die folgende Grafik zeigt den allgemeinen schematischen Aufbau eines Interlock-Systems und die wesentlichen Informationsflüsse. Ein wesentliches Design-Merkmal der Interlock-Software ist es gewesen, eine starke Trennung zwischen Interlock-Hardware-Funktion und Software-Stabilität zu erreichen. Die Trennung ist auch im Hardware-Design wieder zu erkennen (siehe folgende Grafik, rote Markierung). Damit ist die Sicherheit durch die Interlock-Funktion auch dann gegeben, wenn die Software unerwartet abstürzt und/oder vorübergehend nicht verfügbar ist.

Die Software, mit welcher der Interlock-Controller arbeitet, ist im Wesentlichen in Schichten unterteilt. Die unterste Schicht ist die Hardware-Abstraktion-Schicht (HAL) und stellt den Zugriff auf die Hardware-Resourcen des Interlock-Systems zur Verfügung. Auf dieser Schicht bauen benutzerdefinierte Treiber der Interlock-Hardware (Slave-Module) und die Netzwerk Treiber auf. Die mittlere Schicht ist für Dienstprogramme vorgesehen. In dieser Schicht befinden sich die Kommunikationsdienste sowie Verwaltungsdienste des Interlock-Systems. Es existiert ein integrierter Diagnose-Dienst, der mit dem Hardware-Watchdog des Systems gekoppelt ist und die Applikationsschicht überwacht sowie Konsistenzprüfungen der Software des Interlock-System periodisch durchführt.

Prozessor und Hardware

Die Software wird auf einem Softcore 32Bit RISC Prozessor NIOS2 von Altera ausgeführt, der in einer FPGA (Field Programmable Gate Array) mittels der Hardwarebeschreibungssprache VHDL synthetisiert wird. Ein an die FPGA extern angeschlossener Speicher von 32MB dient als Hauptspeicher für den Prozessor. Die konfigurierte Variante des Prozessor verfügt über keine Memory Management Unit (MMU) und keine Memory Protection Unit (MPU). Diese Hardware Zusatzfunktionen werden von Altera zwar angeboten, aber zum Zeitpunkt der Entwicklung gab es keine Unterstützung im Betriebssystem.
Der Prozessor wird mit einer Frequenz von 50Mhz betrieben. Als persistenten Speicher dient ein externer 8MB bzw. 16MB Flash-Speicher, in dem das Hauptprogramm, ein Dateisystem und die Interlock Konfiguration gespeichert sind.

Betriebssystem

Als Betriebssystem wird das „echtzeit-fähige“, preemptive Betriebssystem µCOS von der Firma Micrium eingesetzt, welches von Altera für den NIOS2 Prozessor zur Verfügung gestellt wird.Als Netzwerkschicht stellt das Betriebssystem den Netzwerk-Stack NicheStack zur Verfügung.

Dienste

Das Betriebssystem bietet die Möglichkeit, mehrere Tasks mit Prioritäten zu versehen und (quasi) parallel auszuführen. „Parallel“ bedeutet nicht “zeitgleich“. Die einzelnen Tasks werden in kurze Zeitabschnitte gestückelt und die Ausführung wechselt von Task zu Task, abhängig von der Priorität. Jede Priorität-Stufe kann nur einmal vergeben werden. Tasks mit einer niederwertigen Priorität erhalten bevorzugt CPU-Zeit. Das Betriebsystem besticht mit einem kleinen Speicherverbrauch (Memory-Footprint). Durch die Aufteilung der Software in einzelne Tasks wird eine definierte Abgrenzung der Dienste im System gefördert. Weiter kann mit Hilfe der Prioritäten festgelegt werden, welche Dienste bei der Ausführung bevorzugt werden sollen.

Einen Sonderfall stellen Interrupt-Dienste dar, die gegenüber Tasks immer bevorzugt und sofort bearbeitet werden. Dies wird erreicht, indem die Interrupt-Quelle den Stack des aktuellen Tasks mitbenutzt und somit keine Zeit mit einer Kontex-Umschaltung verbraucht wird.
Im Folgenden ist die Task-Liste der Interlock3 Software aufgeführt.

Die niedrigen Prioritäten sind an kritische System-Dienste vergeben, die schnell auf Ereignisse reagieren müssen. Mit steigender Priorität steigt auch die Latenzzeit, mit welcher ein Task die anstehenden Aufgaben bearbeiten kann. Unkritisch sind Kommunikations-Dienste wie der http-Server, Socket-Server, Telnet-Server und UDP Logger.

Interlock Tests

Beim Start des Interlock Systems wird ein umfassender Test durchgeführt, mit welchem festgestellt wird, ob das Interlock System betriebsbereit ist und aktiviert werden darf. Erst wenn das Interlock System aktiviert ist, kann das Interlock-System dem gesamten System (z.Bsp. der RF-Station oder dem Gun Teststand) eine Freigabe für einen sicheren Betrieb erteilen.
Es wird ein Test der Rückverdrahtung (Backplane) durchgeführt um zu prüfen, ob alle Steckverbindungen vorhanden sind und keine Fehler in der Daten-Übertragung stattfinden können.

Bei der Entwicklung der Interlock Software wurde viel Aufwand in die Selbstdiagnose des Systems investiert, um eine hohe Verfügbarkeit der Software und der Kommunikationsdienste zu erreichen. Das Design sieht zwar vor, dass die Software während des Betriebs ausfallen kann, aber es ist wichtig, dass die Kommunikationsdienste nach möglichst kurzer Zeit wieder zur Verfügung stehen.
Es wurde als gegeben angenommen, dass es in der Realität kein perfektes System gibt und es nicht möglich ist, alle Fehlersituationen im Vorfeld zu bestimmen und entsprechende Behandlungen vorzubereiten. Stattdessen wird versucht, Anomalien in Daten und Programmverhalten zu erkennen und die Software gegebenenfalls zurückzusetzen.
Das Diagnosesystem läuft mit einer sehr geringen Priorität und hat somit vor fast allen anderen Tasks Vorrang. Dadurch kann der Diagnose-Tasks selbst dann aktiv werden, wenn andere Dienste ausfallen oder blockieren.
In periodischen Abständen wird das System auf Konsistenz überprüft. Zur Konsistenzprüfung gehört die Überprüfung von eventuell stattgefundenen Speicherzugriffsverletzungen, anwenden einer Watchdog-Funktion auf verschiedene Dienste. In Fehlerfall wird ein Neustart der Software veranlasst, so dass sich Fehler nicht weiter fortpflanzen können. Die Hardware-Schutz-Funktion des Interlocks wird dabei nicht beeinträchtigt.
Die Prüfung von Speicherzugriffsverletzungen ist problematisch und nicht einfach zu realisieren, da der Prozessor über keine MMU verfügt, die diese Funktion in Hardware abbildet. Im der Interlock Software werden mehrere Ansätze miteinander kombiniert um der Problematik zu begegnen.

Durch das Verwenden von eindeutigen ID’s, die zu Beginn jeder Speicherstruktur liegen, können Zeiger-referenzierte Zugriffe abgesichert werden. Nur bei einer gültigen ID kann ein weiter Zugriff auf Elemente der Struktur durchgeführt werden. Auf diese Weise werden alle Pointer die als Parameter an Funktionen übergeben werden vor einem Zugriff geprüft.

Verwenden von redundanten Speichern. Besonders wichtige Speicherstrukturen werden mehrfach (redundant) im Speicher gehalten und mit Prüfsummen überwacht. Vor jedem Zugriff wird die Gültigkeit des Speichers überprüft. Kam es vorher zu einer Speicherzugriffverletzung, dann stimmt die Prüfsumme nicht mehr überein. Die Struktur wird „repariert“ indem eine noch intakte Kopie der Speicherstruktur verwendet wird und der Fehler wird protokolliert.

Verwenden von konstanten Magic-ID’s vor und hinter Speicherbereichen wie Stacks, dynamisch allokierten Arrays und anderen Speicherstrukturen. Bei einer Bereichsüberschreitung werden die ID’s zerstört. Derartige Fehler werden somit erkannt und entsprechende Maßnahmen werden ergriffen.

Alle Standard-Befehlen (memcpy, memset, sprintf, etc.), die auf Speicherbereichen arbeiten, werden durch eigene Implementierungen ersetzt, die vor jedem Zugriff eine Registratur abfragt, ob es sich um einen zulässigen Zugriff auf einen zuvor registrierten Speicherbereich handelt. Verstöße werden protokolliert und abgewiesen.

Diagnose Dienst

Die Interlock Software verfügt über Dienste um eine Fehler-Diagnose zu unterstützen. Zum einen können die aktuellen Systemmeldungen über den http Service mit einem üblichen Internet-Browser abgerufen werden. Zum anderen stehen zusätzliche Hilfsprogramme zur Verfügung, die in LabVIEW, C/C++ und Java entwickelt wurden.

Interlock Log-Server
Der Interlock Log-Server empfängt Systemmeldungen von Interlocksystemen und schreibt diese in Dateien. Auf diese Weise können alle Nachrichten aufgezeichnet werden und im Nachhinein ausgewertet werden.
Interlock Flash-Update Tool
Mit dem Interlock Flash-Update Tool kann die Software und die Firmware des Interlock-System aktualisiert werden. Das Werkzeug kann nur von autorisierten Personen ausgeführt werden und ist in der Lage mehre Module eines Interlock-Systems gleichzeitig zu aktualisieren.
Anbindung an das Kontrollsystem
Das Personal im Kontrollraum benötigt im Fehlerfall den Status des Interlock-Systems, um die Ursache für die Abschaltung durch das Interlock zu finden. Zur Unterstützung werden die aktuellen Statusdaten vom Interlock-System an das Kontrollsystem übertragen und durch eine spezielle Oberfläche angezeigt. Für die Übertragung der Statusdaten wird ein Meta-Server verwendet, welcher die Daten vom Interlock-System kontinuierlich empfängt und dem Kontroll-System zur Verfügung stellt.
Zur Übertragung der Daten an den MetaServer wird das Network-Queue Protokoll verwendet. Das Protokoll wurde von Stefan Weisse (DESY) (siehe NetworkQueue auf http://tine.desy.de) entwickelt und bietet die Möglichkeit verschiedene Standard-Datentypen Plattform-unabhängig über das Netzwerk zu übertragen. Datenkonvertierungen werden transparent zur Plattform durchgeführt. Daten werden innerhalb des Protokolls mit IDs und Typidentifikation versehen, so dass dem Prokotokol Daten hinzugefügt werden können und die versendeten Pakete trotzdem noch von älteren Servern verstanden werden können.

Ausblick

Die Entwicklung der Interlock3 Software ist abgeschlossen und in verschiedenen RF-Anlagen in DESY Hamburg und DESY Zeuthen erfolgreich im Betrieb.
Für Interlock-System Rev.4 ist eine vollständige Überarbeitung und ein Redesign der Software Infrastruktur geplant. Gründe für die Überarbeitung sind Optimierung der Hardware-Architektur, Vereinheitlichung der Konzepte und der Softwarebasis und ein damit verbundener Wechsel des Betriebssystems.
Die Wichtigsten Änderungen aus Sicht der Software sind:

Daraus resultierende Vorteile sind zusammengefasst: