System diagnostyczny detektora BAC w eksperymencie ZEUS

System diagnostyczny detektora BAC w eksperymencie ZEUS.
mgr inż. Tomasz Jeżyński
Instytut Systemów Elektronicznych PW
ul. Nowowiejska 15/19 Warszawa
[email protected]
1. Wstęp.
W celu prowadzenia badań struktury protonu w Ośrodku Niemieckiego Synchrotronu
Elektronowego (DESY, Hamburg) w 1990 r. powstał kołowy akcelerator
przeciwbieżnych wiązek elektronów (lub pozytonów) i protonów HERA, osiągający
energię zderzenia w środku masy przekraczającą 300GeV. Poszukuje się bardzo
rzadkich oddziaływań, dlatego w celu uzyskania dostatecznej statystyki, przeciwsobne
pakiety cząstek są zderzane ze sobą co 96 ns. Metody badawcze oparte są na rejestracji
obrazów poszczególnych zderzeń cząstek w pełnym kącie bryłowym. Do tego celu służą
wielofunkcyjne detektory pozwalające na rejestrowanie produktów zderzeń. Jednym z
czterech tego typu urządzeń pracujących na akceleratorze HERA jest detektor ZEUS [2]
zbudowany w ramach współpracy międzynarodowej. W jego konstrukcję zaangażowany
był między innymi Instytut Fizyki Doświadczalnej Uniwersytetu Warszawskiego oraz
Akademia Górniczo-Hutnicza z Krakowa. W ramach współpracy został zaprojektowany
i wykonany kalorymetr uzupełniający BAC (Backing Calorimeter) stanowiący integralną
część detektora ZEUS. Istotny wkład w projekt i budowę układów systemu akwizycji
danych wnieśli elektronicy z Instytutu Systemów Elektronicznych oraz Wydziału Fizyki
Politechniki Warszawskiej.
Część elektroniczna systemu akwizycji danych detektora BAC jest rozmieszczona
wewnątrz detektora ZEUS (elektronika front-end) oraz na zewnątrz w 22 kasetach
VME [3]. Sterownikiem każdej kasety jest jednostka centralna wyposażona w
transputer[4]. Strukturę tego systemu przedstawiono na rys. 1.
Rys. 1. Struktura warstwy elektronicznej systemu akwizycji danych detektora BAC.
Detektor BAC jest wyposażony w duży, rozproszony elektroniczny system pomiarowy i
akwizycyjny. Jego komponenty rozmieszczone są w wielu miejscach detektora, długości
połączeń dochodzą do 100 m. Dane otrzymywane z komór gazowych detektora [5]
odczytywane są przez 2200 kanałów analogowych i ok. 40 000 kanałów cyfrowych. Ciągły
nabór informacji z tych kanałów odbywa się dla każdego potencjalnego zderzenia cząstek,
czyli co 96ns.
Wszystkie transputery połączone są bezpośrednimi łączami komunikacyjnymi zwanymi
„linkami transputerowymi” [4] tworząc sieć typu drzewo połączoną w wierzchołku do
komputera VAX pracującego pod systemem VMS. Przez ten komputer możliwy jest dostęp
do transputerów umieszczonych w kasetach VME. Komputer VAX podłączony jest do sieci
TCPIP. Poglądowy schemat struktury blokowej przedstawiono na rys. 2 (szczegóły zawarto w
[6]).
Sieć
transputerów
Link transputerowy
Centrum
komputerowe
DESY
TCPIP
C
A
P
L
I
N
Komputer VAX
system VMS
Program
nadzorujący
akwizycję danych
Rys. 2. Struktura warstwy programistycznej systemu akwizycji danych detektora BAC.
Na sieci transputerów pracuje oprogramowanie napisane w języku programowania
równoległego OCCAM [7], zadaniem którego jest sterowanie i kontrolowanie pracą
wszystkich płyt elektronicznych umieszczonych w kasecie VME oraz pobieranie i
gromadzenie w buforach pamięciowych danych obrazu zderzenia. Na komputerze VAX
pracuje program napisany w języku C oraz FORTRAN, zadaniem którego jest pełny
nadzór nad warstwą elektroniczną, siecią transputerów i procesem naboru danych.
Na etapie projektowania detektora BAC nie przewidziano układów diagnostyki dla
poszczególnych płyt elektronicznych. Założono, że ocena jakości zbieranych danych
dokonywana będzie na podstawie analizy danych fizycznych. Kilkuletnia eksploatacja
detektora wykazała, że system taki jest niewystarczający. Analiza danych fizycznych nie
daje dokładnej odpowiedzi na pytanie, która część detektora i w jakim stopniu jest
niesprawna. Jednocześnie nie jest możliwe jednoznaczne określenie, który element z
całego toru pomiarowego jest uszkodzony, co skutkuje niemożnością szybkiej naprawy.
Poszczególne bloki systemu pomiarowego wymagają także okresowych kalibracji co w
posiadanym systemie jest bardzo czasochłonne i wymaga doświadczenia eksperckiego.
Wynikające stąd wnioski stały się punktem wyjścia do opracowania niezależnego
systemu diagnostycznego, który zadania funkcjonalne obejmują:
•
•
•
•
•
•
•
•
•
•
•
wykonanie testów:
o całego detektora,
o poszczególnych bloków detektora,
o dedykowanych procesów testowych,
badanie ciągłości toru analogowego,
poszukiwanie kanałów nie spełniających specyfikacji,
badanie liniowości toru analogowego,
raportowanie wykrytych nieprawidłowości,
generowanie pliku konfiguracyjnego dla akwizycji danych z uwzględnieniem stanu
detektora,
kalibrację wzmacniaczy w odczycie energetycznym,
ustawianie progów komparatorów w odczycie pozycyjnym,
zapisanie danych z testu do późniejszej analizy,
informowanie o miejscu zainstalowania bloku zakwalifikowanego przez program jako
działającego nieprawidłowo,
kalibracja trygera.
2. Struktura funkcjonalna systemu diagnostycznego detektora BAC
Jak wspomniano we wstępie, sterowanie elektronicznym systemem pomiarowym i
akwizycyjnym detektora BAC odbywa poprzez programy działającego na transputerach i
interfejsy VME zainstalowane we wszystkich 22 kasetach. Komunikację z transputerami
poprzez sieć linków zapewnia komputer VAX. Wykorzystanie języka OCCAM i środowiska
VMS było podporządkowane celom eksperymentu natomiast są w praktyce nieefektywne dla
tworzenia otwartego, dynamicznie konfigurowalnego oprogramowania diagnostycznego. W
związku z tym opracowano koncepcję otwartej, rozproszonej platformy programistycznej
zaprezentowanej na rys. 2. Składa się ona z:
• programu sterującego interfejsem VME na transputerach,
• serwera komunikacyjnego TCPIP umieszczonego na komputerze VAX,
• klienckiego oprogramowania diagnostycznego realizowanego w środowisku PC,
• serwera bazy danych udostępnionego poprzez sieć komputerową.
Program sterujący VME – zadaniem tej części systemu jest zapewnienie wykonania
następujących operacji VME poprzez oprogramowanie wykonywane na transputerze:
• zapis i odczyt rejestru
• zapis i odczyt bloku pamięci
• obsługa przerwań
• wykonywanie operacji specjalizowanych dostępów VME
Program pracujący na transputerach został napisany w języku OCCAM. Realizuje polecenia
przekazywane siecią linków z serwera TCPIP zainstalowanego na komputerze VAX. Dane
będące rezultatem wykonania polecenia wysyłane są z powrotem do serwera.
TRANSPUTER
link
EVB
server
Hala eksperymentu ZEUS
TCPIP
PC
System
diagostyczny
Baza danych
Rys.2. Propozycja systemu diagnostycznego dla detektora BAC.
Serwer TCPIP – jego zadaniem jest odbiór przez sieć TCPIP żądań od klienckiego
oprogramowania diagnostycznego i przekazywanie ich siecią linków do transputerów.
Odwrotną drogą są zwracane rezultaty operacji. Serwer został napisany w języku „C” pod
systemem operacyjnym VMS i jest wykonywany na komputerze typu VAX.
Klienckie oprogramowanie diagnostyczne – jest to główne oprogramowanie nadzorujące
wykonywanie procesów diagnostycznych detektora BAC. Jego zadaniem jest zestawienie
połączenia z serwerem, załadowanie odpowiedniego oprogramowania do sieci transputerów,
rejestrację błędów odwołań do magistrali VME. Program diagnostyczny pracuje na
komputerach PC. W związku z tym dalszym funkcjonalny i strukturalny rozwój
oprogramowania testowego nie wymaga dokonywania zmian ani w oprogramowaniu
sterującym VME na transputerach, ani w programie serwera TCPIP. Bazową strukturę
oprogramowania zaprojektowano w sposób modułowy, co umożliwia dalszy rozwój systemu
diagnostycznego i jego dystrybucję na inne platformy systemowe. Jako narzędzie
programowania wybrano produkt firmy Borland Builder C++, głównie z uwagi na przyjazne i
dobrze udokumentowane środowisko programistyczne oraz narzędzia dostępu do bazy danych
ORACLE. Wykorzystanie właściwości języka „C++” umożliwia łatwe przeniesienie
poszczególnych modułów na inne platformy systemowe, takie jak np. Linux. Istnieje również
możliwość tworzenia nowych specjalistycznych testów jako osobnych programów.
Baza danych – przechowuje dane o całej strukturze detektora, o topologii sieci, wzajemnych
połączeniach poszczególnych bloków elektroniki detektora oraz adresy bazowe VME
wszystkich płyt elektronicznych. Baza przetrzymuje również dane konfiguracyjne dla testów
systemu i jest miejscem przechowywania wyników testów przeprowadzonych przez system
diagnostyczny. Stanowi także interfejs dla grupy niezależnych programów satelickich
przeznaczonych do analizy zgromadzonych danych testowych. Dla celów projektu
wykorzystano bazę danych ORACLE 8.0. Łączność z bazą zapewnia protokół TCPIP.
3. Budowa Systemu Diagnostycznego
W niniejszym rozdziale przedstawiono budowę systemu diagnostycznego w oparciu o jego
podział na podstawowe bloki strukturalne. W poniższych podrozdziałach zamieszczono opis
oprogramowania sieci transputerów, budowy aplikacji serwera funkcji VME oraz programu
diagnostycznego.
3.1 Program transputerów.
Transputery połączone są w sieć typu drzewo przedstawioną na rysunku 3. Każdy transputer
(node) posiada swój unikalny numer z przedziału od 1 do 22, któremu odpowiada
jednoznacznie mnemonik.
EVB
VAX
EQC
TOP
SP1
ST1
ST2
SP2
CTG
SP3
BEN
NP3
SWT
BHI
NP1
SH1
SH2
NT1
NP2
NWT
NT2
NH1
NH2
Rys. 3 Topologia sieci transputerowej.
Dane wysyłane linkiem transputerowym z komputera VAX do sieci transputerów muszą mieć
format zgodny ze specyfikacją oprogramowania pracującego na transputerach. Zakłada ona,
że ramka danych przychodzących linkiem transputerowym ma postać jak na rysunku 4.
NODE TASK FUNC BODY_size BODY[0]
gdzie:
-
...
BODY[BODY_size-1]
NODE – numer transputera w sieci
TASK – numer procesu wykonywanego na transputerze
FUNC - numer identyfikacyjny funkcji
BODY_size – długość „ciała” funkcji w długich słowach (w słowach 4 bajtowych)
BODY – dla ramki wysyłanej: „ciało” funkcji zależne od rodzaju funkcji
dla ramki powrotnej: wynik wykonania funkcji dla ramki powrotnej
Rys. 4. Postać ramki dla sieci transputerów.
Ramka danych składa się ze stałego nagłówka o długości 16 bajtów, tworzonego przez pola
NODE, TASK, FUNC, BODY_size. Każdy z tych obiektów jest liczbą czterobajtową (długie
słowo) oraz z opcjonalnego „ciała” funkcji. Jeżeli funkcja nie posiada „ciała”, wtedy
BODY_size = 0. Dla każdej funkcji mającej dostęp do magistrali VME w najmłodszym bajcie
pierwszego słowa BODY zawarta jest kopia rejestru statusowego płyty transputera,
zawierająca informacje o błędach szyny VME. Na każdym z 22 transputerów pracuje
funkcjonalnie identyczny program, różniący się jedynie częścią router’a, realizującą
transmisję pakietów pomiędzy transputerami. Składa się z następujących procesów
równoległych omówionych poniżej: statycznego, dynamicznego, obsługi przerwań, routera.
Proces statyczny – realizuje wszystkie typy dostępu do magistrali VME. Używany jest do
programowania i testów urządzeń wyposażonych w interfejs VME. Poniżej przedstawiono
klika funkcji, które może wykonać ten proces.
nazwa funkcji
vme_get_status(...)
vme_read_mem(...)
vme_write_mem(...)
vme_verify_mem(...)
vme_test_mem(...)
opis funkcji
pobranie rejestru statusowego
odczyt bloku pamięci
zapis bloku pamięci
zapis z weryfikacją bloku pamięci
testy bloku pamięci
Proces ten umożliwia zapis, odczyt, zapis z weryfikacją, test pojedynczych rejestrów, grupy
rejestrów (dane typu para adres – dana), grupy bloków pamięci. Funkcje, w których opisie
występuje słowo test, działają na zasadzie dokonywania wpisu wartości losowej i porównania
jej z wartością odczytaną. Jako ich wynik zwracana jest funkcja XOR z danych zapisanych i
odczytanych.
Proces dynamiczny – zapewnia pełną obsługę odczytu danych inicjalizowaną wystąpieniem
przerwania wystawianego przez urządzenia na magistralę VME. Zawiera specjalizowane
funkcje pozwalające zautomatyzować procesy naboru danych dla zadeklarowanych urządzeń,
np. odczytuje określone dane z pamięci buforowej urządzenia i wysyła je na zewnątrz sieci
transputerów. Dostępne funkcje zamieszczono poniżej:
nazwa funkcji
vme_declare_boards(...)
vme_activate_readout(...)
vme_deactivate_readout(...)
opis funkcji
jako ciało funkcji podaje się zbiór płyt do odczytu
aktywacja procesu automatycznego odczytu
deaktywacja procesu automatycznego odczytu
Proces obsługi przerwań – proces ten całkowicie obsługuje procedurę przerwania
sprzętowego na magistrali VME i przekazuje informację o jego wystąpieniu do
oprogramowania klienckiego. Dostępne funkcje w tym procesie są zamieszczone w tabeli:
nazwa funkcji
vme_irq_service(…);
vme_irq_config(…);
vme_irg_ack();
vme_irq_reset();
opis funkcji
określenie sposobu obsługi przerwania
wskazanie , z których płyt mają być obsługiwane przerwania
wymuszenie sygnału ACK ma magistrali VME
zakończenie obsługi przerwania
Ostatnie dwie funkcje wykorzystywane są w modzie kontroli obsługi przerwań przez
oprogramowanie klienckie. Funkcja vme_irg_ack() umożliwia wykonanie cyklu ACK
potwierdzającego przyjęcie przerwania, natomiast funkcja vme_irq_reset() zakończyć obsługę
przerwania w trybie RORA poprzez cykl odczytu dedykowanego rejestru w urządzeniu
zgłaszającym przerwanie.
Proces router - proces realizuje transmisję pakietów do transputerów. Dokonuje przyjęcia
pakietu o numerze zgodnym z numerem transputera lub przekierowania do odpowiedniego
podrzędnego nodu sieci transputerowej.
3.2.
Aplikacja serwera
Zadaniem serwera pracującego na komputerze VAX jest zapewnienie przekazywania danych
pomiędzy aplikacją serwera a programem pracującym na transputerach. Program serwera
napisano w języku C-VAX. Program serwera jest aplikacją nasłuchującą na ustalonym porcie
TCPIP. Dane przychodzące do serwera mają postać przedstawioną na rysunku 5.
frame_length count kind check
gdzie:
-
BODY_TR
frame_length – całkowita długość ramki danych w bajtach
count – numer kolejnej ramki wysłanej z aplikacji klienta
kind – miejsce przeznaczenia danych,
check – suma kontrolna po wszystkich bajtach ramki danych
BODY_TR – dane
Rysunek 5 Ramka danych przesyłana przez sieć TCPIP do serwera.
Pola frame_length, count, kind, check tworzą stały nagłówek ramki danych. Są to pola
czterobajtowe. Dane reprezentuje pole BODY_TR. Może mieć ono różną długość zależną od
typu przesyłanych informacji. Powrotna ramka danych posiada taką samą strukturę.
Uproszczony algorytm działania serwera funkcji VME przedstawia rysunek 6.
TCPIP
HADER
N
ERROR
DANE
HADER DANE z transputerów
Czy suma
kontrolna
OK ?
T
Czy dane
T
do transputerów ?
N
DANE
Wyślij DANE
do sieci
transputerów
Interpretuj
dane
DANE z transputerów
Obliczenie długości,
dodanie liczb kontrolnych
Sieć
transputerów
Rysunek 6. Uproszczony algorytm działania aplikacji serwera funkcji VME.
Po przyłączeniu się klienta do serwera może nastąpić transmisja danych. Rozróżnia się dwa
rodzaje danych:
• dane przeznaczone do sieci transputerów
• dane przeznaczone dla serwera – konfiguracja modu pracy serwera
Pole kind decyduje dla kogo są przeznaczone dane, czy dla serwera, wtedy są to dane
konfiguracyjne, czy dla sieci transputerów. Ramkę danych przeznaczoną dla sieci
transputerów przedstawia rysunek 7.
frame_length count kind check
NODE TASK FUNC BODY_size BODY[0]
BODY_TR
...
BODY[BODY_size-1]
Rys. 7 Ramka danych przychodząca do serwera funkcji VME.
Dane przesyłane do serwera to następujące polecenia:
• podłączenia do linku transputerowego
• odłączenia od linku transputerowego
• ładowanie sieci transputerów wskazanym plikiem binarnym
• włączenia podglądu transmitowanych danych
• zakończenia połączenia
Każda funkcja wykonana na transputerach zwraca jako wynik przynajmniej informacje o
błędach operacji na magistrali VME. Inne funkcje, np. vme_read_reg() oprócz informacji o
stanie magistrali VME zwracają wynik operacji czytania. Gdy na linku transputerowym są
dane z sieci transputerów, serwer wykonuje operację odwrotną niż przy odbieraniu danych
tzn. buduje nagłówek ramki, dołącza do niego dane, oblicza całkowitą długość ramki, wylicza
sumę kontrolną i odsyła ramkę do aplikacji klienta.
3.3 Obiektowy opis bloków układów elektronicznych detektora BAC
Przyjęta struktura programowania diagnostycznego pozwala na jej użycie zarówno w
rzeczywistym środowisku detektora BAC jak i na stanowisku laboratoryjnym. W celu
spełnienia tych wymagań opracowano dwie dedykowane biblioteki: tb.lib i bac.lib. Biblioteka
tb.lib zawiera funkcje umożliwiające dostęp do magistrali VME, a biblioteka bac.lib jest
obiektowym opisem zadań funkcjonalnych poszczególnych bloków elektronicznych detektora
BAC. Zostały one scharakteryzowane w poniższych rozdziałach.
3.3.1 Biblioteka tb.lib
Konstrukcja oprogramowania pozwala wybrać w łatwy sposób rodzaj sterowania
magistralą VME. W praktycznym rozwiązaniu zastosowano trzy rodzaje sterowników:
1) w detektorze BAC sterownikiem kaset VME jest transputer połączony linkiem
transputerowym z komputerem VAX pracującym z systemem operacyjnym VMS,
2) na stanowisku laboratoryjnym w ośrodku DESY sterownikiem kasety jest transputer
połączony linkiem transputerowym z komputerem PC pracującym w środowisku
Windows,
3) na stanowisku laboratoryjnym UW w Warszawie sterownikiem kasety jest karta firmy
BIT3 współpracująca z komputerem PC pracującym w środowisku Windows.
Biblioteka ta zawiera wirtualną klasę TVME definiującą wszystkie funkcje potrzebne do
obsługi magistrali VME. Jest to klasa – przodek dla innych klas, będących implementacją dla
konkretnego środowiska. Zawiera ona m.in. następujące metody:
nazwa funkcji
void Reset()
void Write(…)
unsigned long Read(…)
unsigned long WriteRead(…)
void ReadBlock(…)
opis funkcji
wymuszenie sygnału RESET na magistrali VME
zapis danej, pod adres wskazany argumentem funkcji
odczyt danej spod adresu wskazanego w argumencie funkcji
zapis danej a następnie jej odczyt
odczyt bloku pamięci, adresu początku i krok podawany w
ciele funkcji
Na bazie klasy TVME powstały klasy potomne dziedziczące wszystkie funkcje klasy TVME
oraz metody charakterystyczne dla konkretnych realizacji. Zależności pomiędzy klasą bazową
i powstałymi klasami potomnymi przedstawia rysunek 8.
TVME
virtual
TVMEExtBac
virtual
TVMEZeusNet
TVMEManager
virtual
TVMEZeusNetManager
TVMEZeusNetExtBac
Rys. 8 Klasy i zależności między nimi w bibliotece tb.lib.
Dla realizacji w środowisku detektora istnieją m.in. następujące klasy:
• TVMEZeusNetManager – klasa odpowiedzialna za tworzenie obiektów i zarządzanie
nimi, zawiązywanie połączenia z serwerem funkcji VME.
• TVMEZeusNet – klasa dziedzicząca wszystkie metody klasy TVME i definiująca
funkcje charakterystyczne dla środowiska eksperymentu- zawiera implementacje
funkcji zadeklarowanych w klasie TVME,.
• TVMEExtBac klasa zawierająca funkcje możliwe tylko do zaimplementowania w
DESY Jest ona używana tylko przy pracy z detektorem BAC, nie implementowana do
pozostałych miejsc.
• TVMEZeusNetExtBac – klasa dziedzicząca po klasie TVMEZeusNet oraz
TVMEExtBac zawierająca wszystkie funkcje niezbędne do sterowania układami
elektronicznymi detektora BAC.
Rozwiązanie takie uniezależnia funkcje zdefiniowane w klasie TVME od środowiska w jakim
one są wykorzystywane.
3.3.2 Biblioteka bac.lib
Celem zbudowania tej biblioteki było stworzenie obiektów reprezentujących rzeczywiste
urządzenia realizujące określone funkcje np.: pobieranie rejestru statutowego urządzenia.
Wykonanie funkcji ma spowodować takie sterowanie magistralą VME, aby w efekcie
wywołania funkcji otrzymać żądane informacje. Odpowiadają one rzeczywistym płytom
elektronicznym, posiadają metody służące do czytania i pisania ich wszystkich rejestrów i
przestrzeni pamięciowych. W całym systemie akwizycji danych detektora BAC wykorzystuje
się w sumie kilkadziesiąt różnych typów płyt elektronicznych. Posiadają one jednak pewne
cechy wspólne, m.in. każda z płyta umieszczona jest w kasecie VME i ma dostęp do jej
magistrali. Część z nich posiada dodatkowe cechy: może to być np. płyta generująca
przerwania lub płyta odczytująca dane z detektora. W związku z tym w obiektowym opisie
powstały następujące klasy (rysunek 9):
- IBoard - klasa bazowa dla typowych obiektów. Obiekt ten zapewnia dostęp do magistrali
VME, przez metody dostarczone przez klasę TVME z biblioteki tb.lib. Na bazie tej
klasy zbudowano przykładowo obiekt TPulser zarządzający urządzeniem
generującym programowalne pulsy testowe.
- IInterupterBoard – klasa dziedzicząca wszystkie metody po klasie IBoard. Posiada
zaimplementowane funkcje do obsługi przerwań. Klasa ta jest przodkiem obiektów
TScanner, TDistributor będących odpowiednikiem programistycznym płyt Scanner i
Dystrybutor, których zadaniem jest sterowanie akwizycją danych.
- IReadoutBoard - klasa dziedzicząca wszystkie metody po klasie IBoard. Posiada
zaimplementowane funkcje odczytu danych z detektora. Obiektami dziedziczącymi po
niej są m.in.: TFadc, TWtt, TStt, TBmbac, TEmbac, THitbox. Są to obiektowe
odpowiedniki płyt elektronicznych realizujących różnego rodzaju nabór danych
fizycznych z detektora BAC pod kontrolą płyt Scanner i Dystrybutor jak wspomniano
wyżej.
IBoard
IReadBoard
IInterupterBoard
TDistributor
TScanner
TPulser
TFadc
TStt
TBmbac
TEmbac
TWtt THitbox
Rys.9. Zależności pomiędzy klasami różnych obiektów.
Poniżej przedstawiono bardziej szczegółowo wybrany przykład budowy obiektu TScanner.
Scanner [8] jest urządzeniem nadzorującym nabór danych z przetworników analogowocyfrowych do pamięci buforowej w celu ich dalszej analizy komputerowej. Zakończenie
procesu akwizycji danych sygnalizowane jest wystawieniem przez płytę przerwania na
magistrali VME.
Wirtualny obiekt TScanner opisujący to urządzenie posiada następujące metody:
nazwa funkcji
void Reset()
void SetParams(TParams* params)
TParams* GetParams(…)
TStatus* GetStatus(…)
TControl* GetControl(…)
void GetNoAcceptAndInterrupt(int
&no_accept,int &no_interrupt);
opis funkcji
wymuszenie resetu płyty
ustawienie rejestrów
odczytanie wszystkich rejestrów
pobranie rejestru statutowego
pobranie rejestru kontrolnego
pobranie liczby zgłoszonych przerwań i zliczonych
sygnałów ACCEPT
Obiekt ten dziedziczy po klasie IInterrupreBoard. Funkcje te umożliwiają: sprzętową
inicjalizację płyty, ustawienie wszystkich parametrów, pobranie aktualnej wartości ustawień
rejestrów, pobranie rejestru statutowego, kontrolnego, aktualnie zliczonej liczby żądań
przeprowadzenia naboru danych przez eksperyment ZEUS oraz zgłoszonych przez tę płytę
przerwań w odpowiedzi na wykonanie procesów akwizycji.
Wywołanie funkcji np.: Reset() powoduje wykonanie sprzętowej inicjalizacji płyty. Fizyczne
odpowiada to wykonaniu na szynie magistrali VME kasety, w której umieszczony jest
Scanner, cyklu odczytu danej z określonego adresu. W implementacji funkcji Reset()
wykorzystywane są funkcje dostarczone przez bibliotekę tb.lib. W związku z tym obiekt
TScanner nie zależy od środowiska w jakim pracuje płyta ponieważ wywołuje te same
funkcje z biblioteki tb.lib. Adres bazowy Scanera nadawany jest w momencie tworzenia
nowego obiektu i odzwierciedla rzeczywisty adres sprzętowy w przestrzeni adresowej VME.
Jest to analogia nadawania adresu sprzętowego płycie w momencie włączenia jej do kasety
VME.
Biblioteka bac.lib wyposażona jest również w obiekt TCrate, odpowiadającemu rzeczywistej
kasecie VME. Posiada on metody umożliwiające umieszczenie w kasecie wszystkich
stworzonych obiektów płyt elektronicznych detektora oraz metody służce do odwołania się do
obiektu umieszczonego w kasecie, np.:
nazwa funkcji
Insert()
SetScanner()
SetDistributor()
SetGfltbi()
GetScanner()
GetDistributor()
GetHitbox()
opis funkcji
umieszcza obiekt (THitbox, TPulser, THitbox, TController itd.)
metody służące do umieszczenia pojedynczych obiektów
metody służące do odwołania się do obiektu umieszczonego w
kasecie
Na rysunku 10 przedstawione są trzy przykładowe kasety VME. Zawierają one różnego
rodzaju płyty elektroniczne (Controler, Pulser, 16FADC, Scanner1). W obiektowym opisie
przedstawionego środowiska, występują również trzy obiekty TCrate. Wskazane są w nich
metody, jakie muszą być wywołane, celem wypełnienia wirtualnego odpowiednika tych kaset.
1
Szczegółowe omówienie przeznaczenia tych płyt wykracza poza ramy niniejszej pracy
Detektor
BAC
Detektor BAC
S
C
A
N
N
E
R
P
U
L
S
E
R
P
U
L
S
E
R
P
U
L
S
E
R
P
U
L
S
E
R
1
6
F
A
D
C
1
6
F
A
D
C
1
6
F
A
D
C
S
C
A
N
N
E
R
TCrate[1]
1
6
F
A
D
C
1
6
F
A
D
C
1
6
F
A
D
C
1
6
F
A
D
C
1
6
F
A
D
C
1
6
F
A
D
C
C
O
N
T
R
O
L
E
R
TCrate[2]
SetScanner(new TScanner)
Insert(new TPulser(1) )
Insert(new TPulser(2) )
Insert(new TPulser(3) )
Insert(new TPulser(4) )
D
I
S
T
R
I
B
U
T
O
R
D
I
S
T
R
I
B
U
T
O
R
D
I
S
T
R
I
B
U
T
O
R
P
U
L
S
E
R
P
U
L
S
E
R
P
U
L
S
E
R
TCrate[3]
SetController(new TController)
Insert(new TDistributor(1) )
Insert(new TDistributor(2) )
Insert(new TDistributor(3) )
Insert(new TPulser(1) )
Insert(new TPulser(2) )
Insert(new TPulser(3) )
SetScanner(new TScanner)
Rys. 10. Klasa TCrate, przykładowa zawartość kasety.
Osobną klasą zawartą w bibliotece bac.lib jest klasa Ttest i jej klasy potomne. Rysunek 11
przedstawia zależności pomiędzy klasami.
TTest
TScannerTest
TDistributorTest
TFadcTest
TSttTest
TPulserTest
TWttTest
Rys. 11. Biblioteka testów.
Klasa TTest zawiera metody które muszą być zaimplementowane w każdym teście.
Najważniejsze z nich to początek testu, koniec testu, miejsce przeznaczenia wyniku (ekran,
baza danych), częstość powtórzenia testu. Dla każdego urządzenia stworzony jest proces
testowy, dziedziczący po klasie bazowej TTest. Biblioteka ta zawiera dla każdego urządzenia
testy o różnym stopniu złożoności. Daje to możliwość przeprowadzenia np. szybkich ale
przez to mniej dokładnych procesów testowych lub długoczasowych dokładnych testów.
Możliwe jest konstruowanie procesów testowych całych torów pomiarowych detektora.
Zastosowanie biblioteki testów umożliwia tworzenie ich nowych wariantów bez konieczności
zmiany oprogramowania systemu diagnostycznego.
3.3.2. System diagnostyczny.
Oprogramowanie systemu diagnostycznego powstało z wykorzystaniem wyżej
przedstawionych bibliotek. Informacja o rozmieszczeniu poszczególnych bloków
elektronicznych i ich adresach pobierana jest z bazy danych. Na tej podstawie budowana jest
lista aktualnie dostępnego sprzętu. Rysunek 12 przedstawia przykład wypełnienia kasety
VME (o nazwie SH1) w płyty elektroniczne.
Rys. 12. Widok drzewa reprezentującego rozmieszczenie poszczególnych
bloków elektronicznych.
Również z bazy danych pobierane są wszystkie niezbędne informacje jakie służą do
inicjalizacji poszczególnych płyt elektronicznych. Program systemu diagnostycznego pełni
także funkcję interfejsu graficznego dla obiektów stworzonych w bibliotece bac.lib.
4. Wyniki działania systemu diagnostycznego.
System diagnostyczny pozwala na szybki, wygodny i interaktywny dostęp do wewnętrznej
przestrzeni adresowania płyt elektronicznych podzielonej na rejestry, flagi i pamięci. Możliwe
jest odczytywanie danych oraz ich modyfikacja. System zapewnia możliwość obserwowania
zmian poszczególnych rejestrów w czasie obsługi przerwań przez wybrane płyty. Na rys. 13
zamieszczono przykład panelu kontrolnego dla obiektu TScanner.
Rys. 13. Panel obiektu TScanner.
Jednym z podstawowych celów budowy systemu diagnostycznego było zapewnienie
wykonania testów znacznej części lub całego systemu naboru danych detektora BAC, a
następnie prezentacji ich wyników. Rysunek 14 przedstawia rezultat wykonania testu na
urządzeniu o nazwie Controler [9] o adresie bazowym 0x100000 umieszczonym w kasecie
SH1. Urządzenie to ma charakter rozproszony, ponieważ częściowo jest umieszczony na
detektorze ZEUS, a częściowo w kasecie VME oraz modułowy, gdyż Controler może
zawierać do 15 Hitboxów [9], a każdy Hitbox do 15 Pipeline’ów [9]. Informacja o aktualnej
strukturze Controler’a zawarta jest w bazie danych. Prezentowany wynik testu pokazuje
elementy niesprawne i ich pozycję.
Rys. 14. Rezultat wykonania testu kontrolera.
Kolejnym ważnym zadaniem stawianym przed systemem diagnostycznym było umożliwienie
czasowej analizy danych, np. w celu strojenia układu trygera detektora BAC. W takim
wypadku system musi dostarczać w sposób zsynchronizowany dane pochodzące różnych
miejsc detektora. Na rysunku 15 przedstawione są w formie przykładu dwa wykresy czasowe:
stan poszczególnych sygnałów wyjściowych z płyty BMBAC oraz wykres energii mierzonej
przez płytę EMBAC. Widoczna jest korelacja pomiędzy rejestrowaną energią a podejmowaną
decyzją trygerową. Wykres ten umożliwia dobranie wartości poszczególnych rejestrów, celem
zestrojenie układu wyzwalania detektora.
Rys. 15. Przebiegi czasowe zarejestrowane przez system diagnostyczny.
5. Podsumowanie
Opracowany system diagnostyczny umożliwia wykonanie dokładnych testów detektora BAC.
Wyniki testów zapisywane są w bazie danych, co umożliwia późniejszą analizę
zarejestrowanych informacji oraz porównanie ich z danymi otrzymanymi we wcześniejszych
pomiarach. Można także dokonać dokładniejszych analiz numerycznych w trybie off-line.
Zapisane dane mogą być również wykorzystywane do poszukiwania korelacji pomiędzy
występującymi awariami sprzętu. Aktualnie system diagnostyczny detektora BAC umożliwia:
• testowanie całego detektora
• testowanie poszczególnych bloków elektronicznych
• strojenie układu trygera
• uruchomienie automatycznych testów określonej grupy sprzętu
Ponadto system diagnostyczny umożliwia badanie ciągłości toru analogowego, wykrywa
zaistniałe nieprawidłowości, np. kanały o odwróconej polaryzacji lub nieprawidłowym
wzmocnieniu.
Na podstawie przeprowadzanych testów system diagnostyczny generuje pliki konfiguracyjne
dla systemu akwizycji danych detektora BAC, m.in. ustala automatycznie poziom progów
komparatorów w torze odczytu pozycyjnego, blokuje nieprawidłowo działające kanały itp.
Zaproponowana koncepcja i przyjęte rozwiązania realizacji systemu diagnostycznego w
formie obiektowego i modułowego oprogramowania pozwoliły na zbudowanie niezawodnego
i łatwego w rozbudowie o nowe funkcje systemu.
Bibliografia
[1] http:\\www.desy.de
[2] Z E U S C o l l a b o r a t i o n : The ZEUS Detector Status Report, 1993
[3] W. Petersen “The VMEbus Handbook”
[4] I N M O S L t d : Transputer Reference Manual, Prentice Hall 1988.
[5] G. Grzelak i in. „System odczytu i układ wyzwalania kalorymetru wspomagającego BAC
dla detektora ZEUS”, Kwartalnik Elektroniki i Telekomunikacji tom 48, zeszyt 2, 2002
[6] T. Jeżyński i in. „Obiektowo i bazodanowo zorientowany system diagnostyczny dla
kalorymetru uzupełniającego BAC eksperymentu ZEUS, Kwartalnik Elektroniki i
Telekomunikacji tom 48, zeszyt 2, 2002
[7] Dick Pountain, David May, „A tutorial introduction to occam programming”
[8] “GFLT signals testing and distribution within the BAC sysyem” ZESU Note 96-116
[9] Poźniak K.: HIT-READOUT – pomiarowy system odczytu pozycyjnego dla detektora BAC
w eksperymencie ZEUS, Krajowy Kongres Metrologii, Gdańsk, wrzesień 1998