Die Software wurde mit den Distributionen SUSE 6.3 und SUSE 7.1 mit verschiedenen Kernelversionen ab 2.2.14 bis 2.4 getestet.

Zum Einsatz kommt eine PCI-331 Karte von http://www.esd-electronics.de

Je nach LINUX-Kernelversion muß ein anderer Treiber geladen werden. Das liegt an der Versionierung der Kernel-Symbole. Treiber sind für alle Kernelversionen von 2.2.0 – 2.4.1 vorhanden. Die Installationsanleitung findet sich im Verzeichnis c331-driver. Damit der Treiber automatisch beim booten geladen wird ist er in das Verzeichnis /lib/modules/2.x.x/misc/ (2.x.x steht für die installierte Kernelversion z.B. 2.2.18) zu kopieren und der Dateiname auf c331-can.o zu ändern und in der Datei /etc/modules.conf ist ein entsprechender Eintrag anzufügen (siehe Datei modules.conf

Die neueste Version ist bei http://www.mysql.com zu finden (3.23.38). Es wurden 2 Versionen getestet 3.22.32 sowie 3.23.23 Beta. Die Versionen ab 3.23 unterstützen Replikationen was das backup vereinfacht. Um mySQL automatisch beim booten zu starten, müssen in /etc/rc.d/... noch einige Scripte installiert werden. Üblicherweise erfolgt die Installation in /var/lib/mysql/.

Der Zugriff von der JAVA Application auf die Datenbank erfolgt über einen JDBC Treiber. Ist im d3run/ Verzeichnis enthalten.

Die neueste Version findet man bei http://www.javasoft.com .Der aktuelle JDK kommt als rpm Datei. Installationsanweisungen finden sich im JDK-Verzeichnis.

Die Standard Installation des JDK erfolgt im Verzeichnis /usr/java . Dort wird für jede Version des JDK ein Verzeichnis angelegt, also in diesem Fall /usr/java/jdk1.3.1 . Die eigentlichen JAVA tools wie Compiler etc. befinden sich im Verzeichnis /usr/java/jdk1.3.1/bin . Am besten dieses Verzeichnis in den Pfad einbinden.

Dies ist das zentrale Installationsverzeichnis für alle selbstentwickelten Programme, Konfigurationsfiles, Quellcode etc.

*.gif und *.jpg Dateien enthalten die Grafiken und Detektorbilder.

can2 heißt die C++ Applikation

commands.txt enthält die Kommandos um die Applikationen zu starten und zu kompilieren.

d3run.cfg enthält die Konfigurations-Settings für

Hier sind die JAVA Klassen und der JAVA-Quellcode enthalten.

Hier findet man Code für den mySQL JDBC-Treiber (von mySQL.com)

Voraussetzung dafür ist die Installation des ODBC Treibers für mySQL. Auch dieser findet sich bei http://www.mysql.com . Bert Schöneich ist hier der Experte.

Die Tabellen und deren Spalten wurden nach Vorstellungen von D3 und FE gestaltet. Keys, Indices und Feldlängen sind daher nicht optimiert. Manche Felder werden bisher nicht benutzt und sind wahrscheinlich auch für die Anwendung in Zeuthen überflüssig. Solche Optimierungen können von den Anwendern in Zeuthen gemacht werden.

Tabelle aller Rohdaten, die über den CAN Bus geschickt werden. Die Speicherung der Rohdaten ist per default eingeschaltet, kann aber auch unterdrückt werden. Die Informationen sind sehr nützlich für das Debugging, also in der Regel eingeschaltet lassen. Die Datenstruktur entspricht

CAN-Telegramm Identifier, der die Herkunft (Kammer, PCI-CAN Karte oder Digital I/O Modul) sowie die Art des Telegramms bezeichnet. (siehe Liste der CAN-Telegramme in gesondertem Kapitel)

Länge des CAN Telegramms (0-8 Bytes). In der Regel haben die Telegramme 0 (remote Request) oder 8 Datenbytes.

Inhalt der Datanbytes 0-3 dargestellt als Long Integer.

Inhalt der Datanbytes 4-7 dargestellt als Long Integer

Wird automatisch beim Schreiben in die Datenbank gesetzt.

Aktuelle Daten der Detektoren, die Aufschluss über die aktuelle Strahlenbelastung geben. Die zentrale Tabelle für die Analyse der Kammern.

Zählerstand des internen 32 Bit-Zählers A der Kammer. Dieser Wert wird bei jedem Kammerimpuls weiter hochgezählt und auch intern in der Kammerelektronik gespeichert. Bei einer Neukalibration der Kammer wird der Wert auf 0 zurückgesetzt.

Differenz der Zählimpulse seit der letzten Auslese. In der Regel sendet jede Kammer bei einem neuen Impuls ein CAN-Daten-Telegramm an den Ausleserechner wodurch dieser Wert normalerweise = 1 sein sollte.

Falls Daten aber außer der Reihe manuell abgefragt werden (Button request Data auf dem User-Interface) kann dieser Wert auch 0 sein.

Die Kammern können aber auch autark ohne die Datennahme betrieben werden und erfüllen die sicherheitsrelevanten Aufgaben genauso und zählen dementsprechend die Kammersignale weiter hoch. Beim nächsten Start der Datennahme kann so auch eine Zählerdifferenz > 1 entstehen.

Die Kammer hat einen zweiten Zähler, der nur beim Anliegen eines externen gates hochgezählt wird.

Diese Funktionalität wird in Zeuthen nicht benutzt und kann somit ignoriert werden.

Wie f_counts_a für den Zähler mit externem Gate.

Aktueller Status des Detektors. Bit 0 – 5 sind belegt und haben folgende Bedeutung :

Bit 0 = 1 : externes Gate ist angelegt um Counter B hochzuzählen.

Bit 1 = 1 : Hochspannung für Kammer ist in Betrieb.

Bit 2 = 1 : Sicherheitsstecker ist auf Kammer aufgesteckt und Kammer kann softwaremäßig manipuliert werden.

Bit 3 = 0 : Power Failure Kammer ist nach Stromausfall abgeschaltet. Kann nur durch Ein und Ausschalten des Verteilerkastens in Betrieb genommen werden. Bei Power Failure wird auch gleichzeitig Alarm ausgelöst.

Bit 4 = 1 : Kammerausfall d.h. Kammer hat sich sich länger als eine definierte Zeit (Kammerausfallschwelle in Tabelle t_digital_module) nicht gemeldet.

Bit 5 = 1 : Alarm, d.h der Abstand zweier aufeinaderfolgender Pulse hat die Alarmschwelle unterschritten.

Zeit zwischen den beiden letzten aufeinanderfolgenden Pulsen in Einheiten von 2 ms. (Einheit hängt mit H/W Zählergröße und Clock zusammen). Diese Zahl wird benutzt um die aktuelle Dosisleistung zu berechnen.

Detektor-Nr von dem die Daten geschickt wurden. Referenz in die Tabelle t_detector;

Wird automatisch beim Schreiben in die Datenbank gesetzt.

Hier werden die wesentlichen Detektorparameter, Eichung etc. gehalten. Bei Änderung werden records nicht überschrieben sondern hinten angefügt um eine history zu erhalten.

Detektornummer (steht auf den Kammern) hier 1 – 5;

Wert = 0 Gamma Detector, Wert = 1 Neutron Detektor;

Datum der letzten Änderung, wird automatisch beim Schreiben eingetragen.

Nummer des zugehörigen eingebauten Digital-Kärtchens. Link in die Tabelle t_digital_module. Bisher identisch mit f_detector_id, da noch kein Kärtchen ausgewechselt wurde.

Eichfaktor, der angibt, welcher Dosis (in µSv) ein Detektorpuls entspricht. Der Wert wird bei der Detektoreichung bestimmt.

Nummer des zugehörigen Records in der Tabelle t_detector_location.

Gibt an, ob der Detektor sich in der Auslese befindet (=1) oder nicht (=0). Nur Detektoren, die sich in der Auslese befinden werden beim Programmstart berücksichtigt.

Kommentar, wird momentan nicht benutzt.

Art des Präparates, wird momentan nicht benutzt.

Automatisch erzeugter Record-Index.

Mittlerer zeitlicher Abstand zweier Impulse in Sekunden ohne Einwirkung eines äußeren Präparates. Dieser Wert wird bei der Kalibration gemessen. (Langzeitmessung). Siehe Auch Kapitel Kalibration.

Mittlerer zeitlicher Abstand zweier Impulse in Sekunden unter Einwirkung eines wohldefinierten äußeren Präparates. Dieser Wert wird bei der Kalibration gemessen. (Präparatezeitmessung). Siehe Auch Kapitel Kalibration.

Standardabweichung des mittlerer zeitlichen Abstandes zweier Impulse in Sekunden ohne Einwirkung eines äußeren Präparates. Dieser Wert wird bei der Kalibration gemessen. (Langzeitmessung). Siehe Auch Kapitel Kalibration.

Standardabweichung des mittlerer zeitlichen Abstandes zweier in Sekunden unter Einwirkung eines wohldefinierten äußeren Präparates. Dieser Wert wird bei der Kalibration gemessen. (Präparatezeitmessung). Siehe Auch Kapitel Kalibration.

Eingestellte Schwelle für die Erzeugung eines Strahlenalarmes in µSv/h. Aus diesem Wert und der Strahlendosis / Kammerpuls berechnet sich die Schwelle für den zeitlichen Abstand zweier Kammerpulse bei derun Unterschreitung Alarm ausgelöst wird.

Zeitpunkt des Beginns der Langzeitmessung bei der letzten Kalibration.

Zeitpunkt der Beendigung der Langzeitmessung bei der letzten Kalibration.

Zeitpunkt des Beginns der Präparatezeitmessung bei der letzten Kalibration.

Zeitpunkt der Beendigung der Präparatezeitmessung bei der letzten Kalibration.

Anzahl der Kammerpulse, die in der Langzeitmessung berücksichtigt werden.

Anzahl der Kammerpulse, die in der Präparatezeitmessung berücksichtigt werden.

Hier befinden sich Angaben über die Aufstellungsorte der Detektoren.

Eindeutige Nummer des Aufstellungsortes.

Beschreibung im Klartext wo sich der Ort befindet.

Zeitpunkt zu dem dieser Aufstellungsort erzeugt wurde.

Zeitpunkt der letzten Änderung

Index der Person in der User-Tabelle, von der die letzte Änderung vorgenommen wurde. (noch nicht benutzt)

x-Koordinate des Detektor-Symbols in der Gelände-Ansicht im JAVA Userr-Interface

y-Koordinate des Detektor-Symbols in der Gelände-Ansicht im JAVA User-Interface

Name der Grafik-Datei, die in der Detektor-Übersicht des JAVA User-Interface angezeigt wird. (Noch nicht benutzt)

Diese Tabelle enthält Eichkonstanten und andere Größen, die auf den Digital-Modulen gespeichert oder fest eingebrannt sind. Da die Digital-Module als getrennte Komponenten ausgetauscht werden können ist eine separate Tabelle angelegt.

Seriennummer des Digital-Moduls.

Versionsnummer der Mikrocontroller-Software.

Nicht benutzt.

Versionsnummer der Hardware

Voruntersetzungsverhältnis mit dem die Kammerpulse auf Ausgangspulse untersetzt werden. Dient als Integrator für die Neutronenkammern um statistische Fluktuationen der Zählrate zu verkleinern. Bei den Ionisationskammern ist der Wert auf 1 eingestellt (Nicht 0 !!!). Der Maximalwert beträgt 2047 (11Bit). Wert ist in der Kammer gespeichert und wird bei der Eichung festgelegt.

Schwelle für den minimalen zeitlichen Abstand zweier aufeinanderfolgender Kammerpulse, bei dessen Unterschreitung Strahlenalarm ausgelöst wird. Die Einheit ist 32ms, der Maximalwert 64K (16Bit Wert) Hängt von der Kammereinstellung ab (siehe f_alarm_schwelle_msvh ). Wert ist in der Kammer gespeichert und wird bei der Eichung festgelegt.

Schwelle für den maximalen zeitlichen Abstand zweier aufeinanderfolgender Kammerpulse, bei dessen Überschreitung die Kammerausfall-Warnung ausgelöst wird. Kammerausfall Die Einheit ist s, der Maximalwert 64K (16Bit Wert) Hängt von der Kammereinstellung ab (siehe f_alarm_schwelle_msvh ). Wert ist in der Kammer gespeichert und wird bei der Eichung festgelegt.

Obere 16 Bit der 48-Bit Seriennummer, die im DALLAS-EPROM der Karte fest eingebrannt ist. Diese Nummer dient als eindeutige Identifizierung der Kammer und wird beim Programmstart geprüft..

Untere 32 Bit der 48-Bit Seriennummer, die im DALLAS-EPROM der Karte fest eingebrannt ist. Diese Nummer dient als eindeutige Identifizierung der Kammer und wird beim Programmstart geprüft..

CAN-Bus Identifier der die Kammer bei der Kommunikation über den CAN-Bus identifiziert. Der Wert kann zwischen 1..127 liegen. 0 ist reserviert und kann nicht für eine Kammer verwebndet werden. Die Kammern haben der Einfachheit halber die gleiche CAN-ID wie Detector-ID.

Tabellenindex, autoincrement.

Tabelle der Fehlermeldungen und Systemereignisse

Eindeutige Nummerierung.

Zusätzlicher Code um unterschiedliche Messages zu unterscheiden. Bisher wird nur type=1 benutzt.

Text der Message

Zeitpunkt der Message

Bei jedem

DosisProKammerpuls : Spalte f_dose_pulse_conversion aus t_detector für den record mit der neuesten Datum

3600 : Anzahl der Sekunden / Stunde

AlarmCountsProSekunde : Konstante, 1 / 0,032 ms enthält die Anzahl der Zählimpulse / Sekunde des Alarmzähler, der im 32 ms Takt hochzählt.

AlarmCounter : Inhalt der Spalte f_alarm_counter in der Tabelle t_data

Die Dosis für einen gegebenen Zeitraum lässt sich einfach aus der Summe der Kammerpulse während dieses Zeitraums multipliziert mit der DosisProKammerpuls berechnen.

Basisklasse zur Festlegung der Gemeinsamkeiten aller Klassen, die eine cCommMsg erhalten können.

Zentrale Klasse zum Aufsetzen und der Verwaltung der eigentlichen Applikation. Hier werden zentrale Pointer gehalten um zwischen verschiedenen Modulen kommunizieren zu können.

Diese Klasse ist die zentrale Anlaufstelle für Aktionen aller Art. Vor allem wird hierüber die Socket Kommunikation mit der C++ Applikation abgewickelt und die empfangenen CommMsgs and die entsprechenden Adressaten verteilt. Auch die Befehle der zentralen Bedienelemente werden hier ausgeführt.

Einfache Datenstruktur für die Kommunikation mit der C++ Applikation. Wird in der Regel über TCP/IP Socket geschickt. Die Länge der Struktur ist variabel, es werden aber in jedem Fall mindestens 16 Langworte a 4 Byte geschickt (4 LongInts Header und 12 LongInts "Stammdaten" ) zusätzliche Informationen können in beliebiger Länge hinten angehängt werden. Das wird bisher nur für die Versendung von Strings benutzt. Verschieden Klassen sind in der Lage eine solche CommMsg zu empfangen.

Länge der zusätzlich angehängten Daten in Bytes. Falls der Wert < 0 ist, sind die Daten als Textstring zu behandeln. (wird benutzt für die Versendung von Error Messages)

Nummerierungsschema um ein einfaches Zuordnung der CommMsg an das zugehörige CommModule zu vermitteln. Die Detektoren haben der Eingachheit halber die MsgID = DetektorNummer (kann man auf dem Detektor ablesen).

Dient zur Unterscheidung unterschiedlicher CommMsgs für den gleichen Adressaten.

Versionsnummer der Datenstruktur. Aktuelle Version ist 1.

12 Langworte (4 Bytes) mit Daten, die abhängig von der MsgID und SubID sind.

Falls Length <> 0 stehen die weiteren Daten hinter dem gerade beschriebenen Header Block von 64 Bytes oder 16 Langworten. Bei einer Socketverbindung wird einfach ein zweites mal gelesen (mit der Anzahl Bytes aus Length als Parameter)

Die Kommunikation zwischen den beiden Applikationen erfolgt grundsätzlich über eine TCP/IP Socketverbindung mit der schon beschriebenen cCommMsg Datenstruktur. Auf beiden Seiten läuft ein TCP/IP Server und wartet auf eingehenden Messages. Die Server Port Nummer auf der Java Seite (also auch für den DOOCS – Server) ist 5567 , die Port Nummer auf der C++-Seite ist 5566. Der DOOCS-Server muß demnach aufdem Port 5567 auf eingehende Messages, die grundsätzlich im cCommMsg-Format verschickt werden, warten. Beim Eintreffen einer Message liest er 64 Bytes (Beschreibung siehe oben) und leitet die Message je nach MsgID an die Programmcode für den entsprechenden Detektor oder im Falle von Fehlermeldungen an das System weiter.

Die C++ Applikation schickt die Messages an den Server, der an erster Stelle in der Datei /usr/doocsadm/d3run/d3config.cfg eingetragen ist. In der Regel ist das 121.0.0.1 (also localhost) aber hier kann jede beliebige IP Adresse eingetragen werden. Auf diese Weise kann man provisorisch die JAVA-GUI-Applikation abschalten und die Messages an einen DOOCS server schicken.

Der Code für die Kommunikation mit der C++ Appliaktion findet man in den JAVA Files cD3Detector.java und cEventHandler.java in den Subroutinen cD3Detector.handleCommMsg(), cEventHandler.ciSockEventHandler.readCommMsg(), cEeventHandler.dispatchCommMsg().

Der aktuelle Status der Kammern wird regelmäßig eigenständig von den Kammern als CAN-Telegramm verschickt und von der C++ Applikation an das JAVA-GUI als cCommMsg weitergeleitet. Jede Kammer benutzt als MsgID ihren Kammer-Identifier (also 1-5) und als SubID den Wert 0x180 (hexadezimal). Dieser Wert hängt mit der Telegramm-Nummer auf dem CAN-Bus zusammen und hat keine weitere Bedeutung.

Um den aktuellen Status einer Kammer darzustellen muss der DOOCS Server eine cCommMsg mit MsgID = 1..5 und SubID=0x180 von einer Socketverbindung mit der C++ Applikation lesen. Die Datenworte sind folgendermaßen zu interpretieren.:

Data[0] = DetektorStatus

Beschreibung der einzelnen Statusbits siehe oben.

Data[1] = CounterA

Die unteren 16 Bit des Zählerinhaltes von Zähler_A. Diese werden automatisch von der Kammer bei jedem Inkrement geschickt, da aus Platzgründen nicht alle 4 Bytes des Zählerstandes von Zähler A und B in ein CAN-Telegramm gepackt werden können. Die C++ Applikation schickt deshalb einen zweiten Wert, TotalCountsA (s.u.).

Data[2] = CountsA

Beschreibung siehe Datenbank;

Data[3] = TotalCountsA

Alle 32 Bit des Zählerstandes, berechhnet von der C++ Appliakation.

Data[4] = CounterB

nicht benutzt

Data[5] = CountsB

nicht benutzt

Data[6] = TotalCountsB

nicht benutzt

Data[7] = AlarmCounter

Die Zeit zwischen den beiden letzten Impulsen. Wie sich daraus die Dosis und Dosisleistung berechnet siehe Berechnung der DosisLeistung

Data[8] = ConfiguredOK

Information ob die Konfigurationsdaten in der Datenbank mit den gespeicherten Werten im Detektor übereinstimmen (DallasID, Voruntersetzer, Kammerausfallschwelle, Alarmschwelle). Wert ist = 1 oder 0.