mgr inż. Mariusz Postół SYSTEM KONTROLI URZĄDZEŃ

systemy czasu rzeczywistego, systemy pomiarowe,
nawigacja, lotnictwo, inżynieria programowania
mgr inż. Mariusz Postół•
SYSTEM KONTROLI URZĄDZEŃ RADIONAWIGACYJNYCH
Artykuł zawiera opis wybranych zagadnień związanych z realizacji projektu, konstrukcją oprogramowania
i sprzętu komputerowego systemu przeznaczonego do kontroli z powietrza naziemnych urządzeń
radionawigacyjnych, systemów łączności i radarów (nazwanego CFIS). Dyskusję poprzedzono opisem
zastosowania oraz podstawowych jego funkcji. Skoncentrowano się na omówieniu najistotniejszych czynników,
które ze względu na specyfikę zastosowania było przedmiotem szczególnie głębokiej analizy na etapie
opracowywania projektu. W artykule przedstawiono wybrane wyniki tej analizy od strony konstrukcji
oprogramowania oraz krótki opis przyjętych rozwiązań.
1. WSTĘP
1.1 PRZEZNACZENIE
Komputerowy system kontroli lotniczych urządzeń radionawigacyjnych przeznaczony jest
do:
•
•
•
•
•
pomiaru z powietrza i rejestracji wartości wszystkich istotnych sygnałów,
obrazowania na potrzeby inspektora w czasie rzeczywistym wybranych wielkości,
dokonywania automatycznej analizy aktualnych parametrów pracy,
wykonywania szczegółowych raportów z przeprowadzonych pomiarów,
archiwizowania danych zebranych w czasie pomiarów dla potrzeb kontroli powypadkowej
i oceny stabilności pracy urządzenia.
Zasadniczym celem jest natomiast umożliwienie inspektorowi dokonania oceny poprawności
pracy urządzenia i w konsekwencji wydanie certyfikatu upoważniającego do eksploatacji
w nawigacji lotniczej.
Przeznaczenie systemu zilustrowano na Rys. 1, który pokazuje przebieg przykładowego
pomiaru ustawienia wiązki nadajnika ścieżki schodzenia (GS). Nadajnik ten jest jednym z wielu
elementów tworzących system pozwalający na bezpieczne lądowanie na lotnisku przy ograniczonej
widzialności z wykorzystaniem przyrządów (ILS) i zapewnia nawigację w poziomie - utrzymanie
odpowiedniego kąta schodzenia samolotu. Jest to jedna z kilkunastu procedur potrzebnych do
•
CAS 94-104 Łódz ul. Obywatelska 137 tel.42'862 547,fax.42'844 840,Eml:[email protected]
pełnej inspekcji tego nadajnika i jedna z
kilkudziesięciu procedur realizowanych
przez system dla potrzeb inspekcji innych
urządzeń. Zestaw dostępnych procedur
umożliwia pomiar z powietrza wszystkich
typów eksploatowanych w kraju urządzeń
przeznaczonych dla lotnictwa cywilnego.
W trakcie realizacji przykładowego
pomiaru ustawienia ścieżki schodzenia
(Rys. 1) samolot inspekcyjny wyposażony
w aparaturę pomiarową porusza się po
prostej z prędkością 250km/h starając się
utrzymać na ścieżce. W tym czasie
rejestrowane są niezbędne do oceny pracy
sygnały z pokładowego odbiornika ścieżki,
stanowiącego
element
systemu
pomiarowego. Aby pomiary były możliwe
Rys. 1. Pomiar systemu lądowania na przyrządy (ILS)
system musi być wyposażony w precyzyjne
Fig.1. Instrument lending system inspection (ILS)
systemy odniesienia. W omawianym
RW-pas startowy
TEO- teodolit telemetryczny
rozwiązaniu wykorzystano:
GPS-globalna nawigacja satelitarna
• teodolit telemetryczny wyznaczający
LOC-kierunek systemu ILS
położenie
kątowe
samolotu
GS-ścieżka schodzenia systemu ILS
względem wybranego kierunku,
• globalny satelitarny system określania położenia (GPS),
• generatory pomiarowe.
Procedury pomiarowe, według których testowane są urządzenia nawigacyjne, wymagają
poruszania się samolotu inspekcyjnego po nietypowych trajektoriach, np. prostopadle do kierunku
lądowania. Dlatego system dodatkowo steruje specjalizowanymi wskaźnikami zainstalowanymi
w kokpicie pilota przeznaczonymi do wspomagania precyzyjnego prowadzenia samolotu po
zadanej trajektorii.
1.2 ZAŁOŻENIA KONSTRUKCYJNE
Oprogramowanie systemów czasu rzeczywistego jest takim elementem całości, który musi
współdziałać z otoczeniem z uwzględnieniem obowiązujących w nim ograniczeń. Punktem wyjścia
do konstrukcji muszą być ogólne założenia, mogące dalej służyć jako wspólna platforma do
budowy zarówno sprzętu, jak i oprogramowania. W celu sformułowania takich założeń, w
omawianym zastosowaniu, dokonano bardzo szczegółowej analizy wielu czynników, a do
najważniejszych należą:
• niezawodność - jest parametrem krytycznym decydującym o przydatności systemu
i wyznaczanych przez niego wyników do analizy poprawności pracy urządzenia,
• dokładność - z punktu widzenia inspektora system jest przyrządem pomiarowym i w
związku z tym musi dostarczać wyniki o odpowiednio niskiej stopie błędów,
• wytrzymałość - ponieważ system jest przeznaczony do zainstalowania na pokładzie
samolotu, jego konstrukcja mechaniczna i mocowanie musi wytrzymać duże przeciążenia,
• temperatura - w trakcie normalnej eksploatacji sprzęt musi być przystosowany do pracy
w temperaturach otoczenia w zakresie od -20° do 50°C,
• wibracje - praca silników i turbulencje powodują powstanie drgań o znacznym natężeniu
i szerokim spektrum,
• ergonomia - inspektor przebywa zwykle na pokładzie samolotu inspekcyjnego kilka godzin
dziennie i oprócz realizacji pomiarów jest odpowiedzialny za koordynację całego lotu,
• odpowiedzialność - zagadnienia tego nie trzeba w tym konkretnym zastosowaniu nikomu
uświadamiać. Zostało ono wymienione na końcu, ponieważ prowadzi do najbardziej
ogólnego założenia, a mianowicie lepiej żeby system nie mierzył nic, jak ma mierzyć źle.
Musi ono być rozumiane jako nadrzędne w stosunku do wszystkich innych.
1.3 BUDOWA
Z punktu widzenia realizacji pomiarów i sterowania otoczeniem konstrukcję zrealizowano na
bazie struktury rozproszonej (Rys. 2). W strukturze takiej występują zasadniczo dwa elementy:
• zestaw inteligentnych układów wej./wyj. służących do pomiarów sygnałów wejściowych i do
sterowania urządzeń zewnętrznych.
• główny komputer obliczeniowy, który komunikuje się z układami wej./wyj. za pośrednictwem interfejsu szeregowego, do którego układy te przyłączone są równolegle.
W omawianym rozwiązaniu
wykorzystano komputer o architekturze zdublowanej zgodny ze standardem IBM/PC w wykonaniu dla zastosowań przemysłowych firmy
TexasMicro typu FTSA (ang. Fault
Tolerant System Architecture) z procesorem Intel '2DX66. Jako układy
wej./wyj. wybrano natomiast moduły
pomiarowe firmy DGH (USA).
Komunikacja pomiędzy modułami
a komputerem odbywa się za
pośrednictwem interfejsu RS 485.
Rys. 2.Struktura systemu
Komputer główny wyposażono
Fig. 2. System structure
dodatkowo w inteligentne sterowniki
odciążających procesor od wykonywania niektórych zadań. W rezultacie otrzymano system wieloprocesorowy, w którym wybrane zadania są realizowane równolegle. Architektura systemu
charakteryzuje się tym, że zdwojono wszystkie istotne z punktu widzenia niezawodności elementy
systemu, a w tym wszystkie tory pomiarowe i elementy komputera głównego.
W rezultacie osiągnięto następujące właściwości układu:
• zwiększono niezawodności dzięki umieszczeniu elementów pomiarowych blisko źródła
mierzonego sygnału, wyeliminowaniu dużej ilości przewodów pomiędzy źródłem sygnałów
a komputerem i przesyłaniu wyników pomiarów w postaci cyfrowej,
• zminimalizowano możliwości powstania błędów pomiarowych na skutek zakłócenia
sygnałów w przewodach doprowadzających,
• odseparowano galwanicznie źródło sygnałów i komputer,
• uzyskano otwartość rozwiązania dzięki umożliwieniu rozbudowy przez dołączania
kolejnych modułów pomiarowych, co nie wymaga ingerencji w komputerze obliczeniowym,
• umożliwiono, by wiele komputerów korzystało z tych samych układów pomiarowych,
Zgodnie z wymaganiami system musi sterować wskaźnikami nawigacyjnymi
zainstalowanymi na lokalnej tablicy przyrządów i w kokpicie pilota. Są one sterowane za
pośrednictwem modułów dołączonych do wspólnego z modułami pomiarowymi interfejsu szeregowego.
Do współpracy z generatorem wzorcowym wykorzystano interfejs GPIB (IEEE488). Aby
dodatkowo ułatwić procedurę kalibracji sygnały w.cz. doprowadzono za pośrednictwem
przełączników pracujących w obwodach antenowych odbiorników nawigacyjnych.
Komputer czyta informacje na bieżąco z globalnego systemu nawigacji satelitarnej (GPS)
i układu telemetrii (TEO) z wykorzystaniem dwóch niezależnych kanałów interfejsu RS 232.
2. PODSTAWOWE PROCEDURY SYSTEMU
Rys. 3 przedstawia schematycznie proces przepływu danych w trakcie kolejnych etapów
przetwarzania. Źródłem danych są odbiorniki nawigacyjne. Przychodzące z nich sygnały można
podzielić na: analogowe, dwustanowe i cyfrowe (interfejs szeregowy ARINC 429).
Sygnały analogowe stałoprądowe są czytane za pośrednictwem przetworników analogowocyfrowych. Podobnie odczytywane są sygnały zmiennoprądowe, dla których dodatkowo
przewidziano przetworniki dokonujące konwersji na sygnał stałoprądowy.
Sygnały dwustanowe i cyfrowe są czytane bezpośrednio za pośrednictwem odpowiednich
interfejsów bez dodatkowego przetwarzania.
Wytworzone przez odbiorniki sygnały mogą być zakłócone i zaszumione. Dlatego przed
wprowadzeniem i zarejestrowaniem mogą być filtrowane przez filtry cyfrowe. Dla wszystkich
sygnałów analogowych filtr cyfrowy jest zintegrowany z przetwornikiem analogowo-cyfrowym.
Dla danych cyfrowych filtracja jest realizowana bezpośrednio przez komputer główny. Wszystkie
filtry mają programowo ustawiane parametry.
Ponieważ parametry torów odbiorników nie są dostatecznie stabilne w czasie, konieczna jest
kalibracja. Otrzymane w wyniku kalibracji dane, które reprezentują w postaci tablicy aktualną
charakterystykę toru pomiarowego, przechowywane są i umożliwiają precyzyjne wyliczanie
faktycznych wartości mierzonych sygnałów. Dopiero tak wyznaczone wartości sygnałów
są rejestrowane i wykorzystywane do realizacji innych funkcji.
System realizuje swoje funkcje przetwarzając dane wejściowe w dwóch praktycznie
niezależnych etapach: rejestracja i obrazowanie. W pierwszym etapie przetwarzanie danych
pomiarowych ograniczono do filtracji i przeliczenia wartości na podstawie funkcji kalibracyjnej.
Takie podejście umożliwia wykorzystanie danych archiwalnych nie tylko przez opisywany system.
Proces obrazowania czyta zarejestrowane dane, wylicza i pokazuje w ergonomiczny sposób
wartości i trendy zmian wybranych parametrów. Dane obrazowane są na: kolorowym monitorze
graficznym, drukarce graficznej, wyświetlaczu alfanumerycznym pilota i wskaźnikach
nawigacyjnych. Pierwsze dwa urządzenia są przeznaczone dla inspektora, a pozostałe dla pilotów
z zadaniem wspomagania precyzyjnego prowadzenia samolotu inspekcyjnego po zadanej
trajektorii.
Rys. 3. Schemat przepływu danych
Fig. 3. Data flow diagram
.
Zasadniczo sygnały analogowe po konwersji w przetworniku A/C są filtrowane przez filtry
cyfrowe. Wyjątek stanowią te sygnały, dla których wartości są dostępne tylko w postaci cyfrowej za
pośrednictwem interfejsów szeregowych (RS232 i ARINC). Są to położenie kątowe z teodolitu,
położenie geograficzne z GPS i namiar z odbiorników nawigacyjnych. Dla wymienionych danych
filtr realizowany jest przez komputer główny.
Dla wszystkich sygnałów wejściowych, zanim zostaną zarejestrowane i użyte do dalszego
przetworzenia, ich wartości wylicza się na podstawie wyznaczonych okresowo na podstawie
pomiarów sygnałów wzorcowych z generatorów sygnałowych funkcji kalibracyjnych.
Kalibracja dla sygnałów pochodzących z odbiornika nawigacyjnego jest realizowana
automatycznie. Generator wzorcowy w tej procedurze jest sterowany programowo.
Niezależnie od procedury pełnej kalibracji jest możliwe sprawdzenie wyrywkowe
poprawności pracy wybranych torów pomiarowych (test torów pomiarowych). Test ten ma za
zadanie wykrycie pomiędzy kolejnymi pomiarami pojawienia się nieakceptowalnych błędów
w trakcie wykonywania lotów inspekcyjnych.
Podczas realizacji procedur pomiarowych wybrane dla poszczególnych procedur wielkości
są rejestrowane. Z punktu widzenia rejestracji generalnie można wprowadzić następujący podział
sygnałów:
• dane z telemetrii,
• dane z GPS'a,
• wartości sygnałów analogowych,
• dane cyfrowe z odbiorników nawigacyjnych.
W każdej z wymienionych grup dane są wyznaczane przez zewnętrzne, autonomiczne
urządzenia pracujące asynchronicznie w stosunku do realizowanego algorytmu programu
głównego. Aby zachować stały okres impulsowania, przed rejestracją musi nastąpić ich
synchronizacja w czasie. Oznacza to, że dane będą opóźniane w czasie, co w efekcie powoduje
powstanie pewnego błędu dynamicznego, który zminimalizowano przyjmując następujące zasady
dla algorytmu synchronizującego:
• wszystkie dane są rejestrowane z częstością 5/s,
• bieżące - ostatnio przeczytane dane z GPS'a i telemetrii są opóźniane i rejestrowane jeden raz
zgodnie z najbliższym okresem impulsowania,
• w punktach, gdzie dane z GPS i telemetrii nie są znane (częstość ich wyznaczania to 2/s),
rejestrowana jest informacja o ich braku, a do analizy w tych punktach bierze się przybliżoną
wartość wyznaczoną z interpolacji dla najbliższych dwóch znanych wartości.
W trakcie realizacji procedur prowadzona jest analiza bieżąca. W jej wyniku inspektor ma
możliwość dokonania natychmiastowej oceny przebiegu pomiaru i podjęcia decyzji o celowości
jego kontynuowania. Możliwe jest również zażądanie od obsługi naziemnej wprowadzenia korekty
wybranego parametru bez konieczności przerywania i powtarzania pomiaru. Rezultaty
są obrazowane w postaci napisów tekstowych, wykresów słupkowych i wykresów liniowych.
Ocenę przebiegu pomiaru ułatwiają dwa mechanizmy nazwane lupa pomiarowa i kursor
pomiarowy. Lupa pomiarowa to mechanizm programowy umożliwiający oglądanie wartości
sygnałów prezentowanych w postaci graficznej w zmiennej skali. Nazwą kursor pomiarowy określa
się mechanizm programowy służący do dokładnego odczytywania wartości sygnału w wybranym
na wykresie punkcie.
Kontrola każdego urządzenia nawigacyjnego wymaga przeprowadzenia pewnego ciągu
operacji. Aby ułatwić pracę inspektorowi na ekranach sterujących poszczególnych procedur
pomiarowych umieszczono listy niezbędnych pomiarów, które trzeba wykonać w celu pełnej
realizacji inspekcji. Na każdym elemencie listy wyświetlana jest wartość wybranego parametru
charakterystycznego dla danej procedury, jeśli była ona realizowana.
Na podstawie danych odbieranych z nawigacyjnych urządzeń pokładowych system na
bieżąco wylicza błąd pilotażu i zobrazowuje go w postaci graficznej na ekranie wyświetlacza i
wskaźnikach nawigacyjnych w kokpicie w polu widzenia pilotów samolotu inspekcyjnego.
3. OPROGRAMOWANIE
3.1 PROCES TWORZENIA OPROGRAMOWANIA.
Punktem wyjścia do sformułowania funkcji realizowanych przez program są dokumenty
normalizujące wydane przez międzynarodową organizację ICAO [1], [2], które aktualnie formalnie
obowiązują w Polsce i administrację rządową FAA [3] odpowiedzialnej za bezpieczeństwo
w przestrzeni powietrznej USA. Po szczegółowym zapoznaniu się z treścią tych dokumentów
trzeba jednak stwierdzić, że nie są one wystarczające do zaprojektowania algorytmów i wykonania
oprogramowania. W związku z tym, należało przewidzieć prace projektowe w tym zakresie.
W rezultacie upraszczając, cały projekt zrealizowano w procesie wieloetapowym, a jego główne
etapy są następujące:
• Opracowanie projektu technicznego.
• Sformułowanie specyfikacji funkcji.
• Opracowanie oprogramowania.
• Testowanie oprogramowania.
• Wdrożenie.
W projekcie technicznym sformułowano zadania systemu i określono strukturę
oprogramowania. Na tej podstawie powstała szczegółowa specyfikacja realizowanych przez system
funkcji. W wielu zastosowaniach wyspecyfikowanie co system komputerowy ma robić jest
niewystarczające i trzeba dodatkowo zdefiniować jak ma realizować swoje funkcje. Jest to
szczególnie istotne w tych przypadkach, gdy nie można w sposób jednoznaczny i bez wątpliwości
bazując na metodach formalnych i zdroworozsądkowych oraz budując, co bardzo istotne,
rozwiązania z uwzględnieniem wymogów zapisanych w dokumentach normalizacyjnych wybrać
odpowiedni algorytm.
Opracowanie specyfikacji funkcji było elementem kluczowym, który zadecydował
o powodzeniu projektu. Dokument ten zawiera oprócz szczegółowej listy funkcji dokładny
matematyczny opis wszystkich algorytmów związanych z przetwarzaniem danych na potrzeby ich
analizy. Opisano w nim zawartość ekranów sterujących, zawartość baz danych i szczegóły
związane z rejestracją sygnałów i analizą wyników pomiarów. Dla każdej z procedur pomiarowych
zdefiniowano algorytm prowadzenia po zadanej trajektorii i zakres niezbędnych danych
przekazywanych pilotowi w trakcie lotu do wspomagania utrzymania samolotu możliwie blisko
zadanej trajektorii.
W trakcie analizy zrealizowanej na tym etapie stwierdzono, że w omawianym zastosowaniu
znaczna część oprogramowania musi być opracowana indywidualnie zgodnie z potrzebami
konstruowanego systemu. Oznacza to, że nie można wykorzystać tu żadnego ze znanych produktów
przeznaczonych do monitorowania i sterowania, stosowanych coraz częściej w zastosowaniach
przemysłowych.
W tej fazie pracy powstało również oprogramowanie symulatora. Symulator jest niezbędny
do testowania poprawności oprogramowania w etapie następnym.
Opracowana w pierwszej fazie projektu specyfikacja funkcji jest w drugiej fazie bazą do
realizacji przyjętych algorytmów. Po formalnym zaakceptowaniu jej dopuszczono jeszcze
możliwość wprowadzenia pewnych uzasadnionych modyfikacji. Przewidziano tu również
prezentacje wyników cząstkowych bezpośredniemu użytkownikowi w celu ich konfrontacji z jego
oczekiwaniami.
Testowanie to etap, który ma za zadanie wykrycie w programie możliwie wszystkich błędów
i stwierdzenie zgodności realizowanych funkcji ze specyfikacją. Wykonywanie weryfikacji
poprawności działania systemu w trakcie lotów inspekcyjnych, chociaż nieodzowne do ostatecznej
akceptacji systemu, jest ze względu na wysokie szeroko rozumiane koszty nieakceptowalne. Aby
tego uniknąć, do testowania wykorzystano specjalnie skonstruowany symulator, który pozwala
wygenerować wszystkie potrzebne sygnały normalnie odczytywane lub mierzone z odbiorników.
Możliwość wykorzystania tego urządzenia w tym etapie miała podobnie doniosłą wagę dla
powodzenia projektu jak opracowanie specyfikacji funkcji.
Po zakończeniu prac związanych z testowaniem system został zainstalowany na pokładzie
samolotu inspekcyjnego i rozpoczęto próby w powietrzu.
Jak wspomniano jednym z istotniejszych problemów w omawianym zastosowaniu jest
szeroko rozumiana niezawodność. Ponieważ system ma służyć do weryfikacji poprawności pracy
urządzeń decydujących o bezpieczeństwie ludzi, zagadnieniem samym w sobie było potwierdzenie,
że otrzymywane rezultaty są wiarygodne, a praca systemu stabilna. Aby to zapewnić wprowadzono
bardzo sformalizowaną i szczegółową procedurę weryfikacyjną, w której wszystkie etapy podlegały
podwójnej komisyjnej kontroli. Najpierw rezultaty były analizowane przez powołaną wewnętrznie
komisję, której zadaniem było sprawdzenie poprawności zastosowanych rozwiązań i sprawdzenie
zgodności z wcześniej przyjętymi założeniami oraz przygotowanie materiałów w postaci raportów,
zestawień i obliczeń dla prac komisji zewnętrznej. Przygotowane materiały przekazano
protokolarnie komisji składającej się z inspektorów w celu dalszej weryfikacji. Komisje pisemnie
określały swoje stanowisko, ewentualne zalecenia i uwagi o nieprawidłowościach.
Badania weryfikacyjne realizowane z wykorzystaniem symulatora uzupełniono, w celu ich
potwierdzenia, wynikami pomiarów z wykorzystaniem specjalistycznych generatorów
sygnałowych. Zakres tych badań jednak był ograniczony pomimo wykorzystania
najnowocześniejszych, zakupionych specjalnie do tego celu urządzeń renomowanych firm.
Następnie po otrzymaniu pozytywnych wyników przeprowadzono badanie porównawcze
z wykorzystaniem aktualnie używanej do pomiarów aparatury firmy AVI Model 2300. Ze względu
na ograniczony zakres jej funkcji badanie te również ograniczono tylko do wybranych parametrów.
3.2 KONSTRUKCJA OPROGRAMOWANIA
Najważniejszym zagadnieniem w rozważanej klasie zastosowań, to szeroko rozumiana
niezawodność tworzonego systemu. Uwzględniając specyfikę omawianego zastosowania można
stwierdzić, że paradoksalnie całkowity brak działania systemu to jedna z najlepszych awarii jakie
mogą się przytrafić. Praktyka inżynierska wymaga jednak, aby system był zaprojektowany na
najgorszy przypadek, którym jest w tym przypadku pozornie poprawne jego działanie. Jedynym
rozwiązaniem, które tu może być pomocne to samo-testowanie się obejmujące zarówno program
jak i sprzęt. W programie obok testów dla zakresów zmiennych i sposobu korzystania ze struktur
danych, realizowanych standardowo przez język programowania, wprowadzono w najbardziej
newralgicznych miejscach test niezmienników (ang assertions).
Przy aktualnym poziomie technologii wytwarzania sprzętu komputerowego i pomiarowego
podstawowym źródłem błędów w pracy jest realizowany program. Są tego dwa powody. Pierwszy
to brak praktycznie realizowalnych metod sprawdzania poprawności programu i algorytmu, na
bazie którego został on zbudowany. Drugi powód to fakt, że ze swej natury znaczna część programu
to zwykle rozwiązanie prototypowe. Z wymienionych powodów nie można z góry wykluczyć
powstania błędów, jednak konstrukcja oprogramowania powinna zapewniać wykrywanie błędów
i ich obsługę. W przyjętym rozwiązaniu obsługa błędu polega na odnotowaniu faktu, miejsca
i okoliczności jego zaistnienia, co pozwala na odtworzenie stanu programu i jest bardzo pomocne
do zrozumienia jego faktycznej istoty.
Ze względu na bardzo wysokie koszty lotów inspekcyjnych konieczne okazało się
skonstruowanie oprogramowania ze stopniową degradacją funkcji. Oznacza to, że wystąpienie
błędu powoduje tylko ograniczenie możliwości realizacji pewnych funkcji. Do implementacji
niezbędną okazała się tu technika programowania współbieżnego, która umożliwia zatrzymanie
błędnych procesów bez konieczności ograniczania pracy procesów realizujących inne zadania.
Podstawowym jednak zagadnieniem jest zastosowanie takich metod i organizacji pracy
w trakcie procesu tworzenia oprogramowania, które minimalizują prawdopodobieństwo
wystąpienia nieprawidłowości w jego realizacji. W tym celu zastosowano metodykę
programowania strukturalnego i modularnej funkcjonalne dekompozycji zadań z wykorzystaniem
techniki programowania współbieżnego. Dzięki technice programowania współbieżnego
poszczególne zadania mogą być realizowane praktycznie niezależnie od siebie. Współpracę ich
zorganizowano na bazie znanego modelu producent-konsument, co dodatkowo zwiększyło
niezawodność. Niezależnie od wymienionych rozwiązań bezpośrednio dotyczących konstrukcji
oprogramowania, zastosowano taką organizację tworzenia oprogramowania, w której jego elementy
podlegają wielokrotnej weryfikacji, a część oprogramowania jest uniwersalnym oprogramowaniem
systemowym sprawdzonym już wcześniej w wielu zastosowaniach przemysłowych [5].
Tworzony system przewidziano do pracy w czasie rzeczywistym. Oznacza to, że czynnik
czasu należy brać pod uwagę już na etapie tworzenia oprogramowania [4]. Dodatkową trudność
sprawia fakt, że w omawianym zastosowaniu wykluczona jest możliwość zastosowania jednego z
gotowych produktów programowych. Ze względu jednak na konieczność ograniczania zakresu
rozwiązań prototypowych należy zminimalizować obszar indywidualnie tworzonej warstwy
użytkowej oprogramowania i w maksymalnym stopniu wykorzystać dostępne oprogramowanie
systemowe jako platformę do budowy wspomnianej już warstwy użytkowej. Zastosowano tu
mianowicie unikalną autorską metodę programowania czasu rzeczywistego z wykorzystaniem
techniki programowania współbieżnego bazującej na koncepcji monitora [6]. Jako bazę do
implementacji tej koncepcji przyjęto język Modula-2, który został tak zdefiniowany, aby łatwo dał
się rozbudowywać przez użytkownika. Zaprojektowane w tym języku mechanizmy tworzenia i
synchronizacji zadań są praktycznie niezależne od systemu operacyjnego, a dostępne konstrukcje
językowe pozwalają na bezpośrednią obsługę sprzętu. W ten sposób w miejsce tradycyjnego
wielozadaniowego systemu operacyjnego wykorzystano opracowaną bibliotekę. Z punktu widzenia
programisty oba rozwiązania są równoważne. W tym przypadku istotne były dwie osiągnięte w ten
sposób własności. Pierwsza pozwala na wykorzystanie spójnego mechanizmu obsługi błędów,
również tych związanych z synchronizacją zadań. Druga daje możliwość modyfikacji biblioteki
zgodnie z aktualnymi potrzebami wynikającymi z zastosowania. W omawianym rozwiązaniu
zadania, których jest zwykle w trakcie realizacji pomiaru kilkadziesiąt, są szeregowane co 1ms.
Jedną z ważniejszych metod stosowanych do zmniejszania prawdopodobieństwa wystąpienia
błędów w pracy systemów komputerowych jest testowanie. Testowanie niestety może jedynie
pokazać, że błędy są. Nie może jednak służyć do wykazania, że ich nie ma, ponieważ w praktyce
nie można nigdy w rozsądnym czasie sprawdzić wszystkich możliwych kombinacji sytuacji
i zdarzeń jakie mogą się w ogóle pojawić. Pomimo to, intensywne testowanie jest nieodzowne.
W omawianym przypadku testowanie musi objąć nie tylko poprawność działania programu
realizującego wybrane algorytmy przetwarzania danych pomiarowych, ale również tory pomiarowe.
Planując proces testowania trzeba brać pod uwagę, że rzeczywiste sygnały analogowe z
odbiorników można uzyskać jedynie w powietrzu na pokładzie samolotu po uprzednim
zamontowaniu systemu. To jednak jest zdecydowanie zbyt późno. Dlatego, jak wspomniano,
niezależnie opracowano układ do symulacji wzajemnie synchronicznych przebiegów sygnałów
analogowych i cyfrowych.
4. PODSUMOWANIE
W opisywanym projekcie opracowano aparaturę kontrolno pomiarową zbudowaną na bazie
wieloprocesorowego systemu komputerowego z wykorzystaniem rozproszonego systemu układów
pomiarowych i elementów wykonawczych. Projekt obejmował wszystkie aspekty, a w tym
konstrukcję mechaniczną, zasilanie, okablowanie, opracowanie algorytmów i wytworzenie
oprogramowania. Oprogramowanie napisano na podstawie formalnej specyfikacji funkcji. Tworzy
je kilka tysięcy rozłącznie kompilowanych modułów o przeciętnej długości kilkaset linii. Program
został podzielony na 19 modułów, z których każdy jest niezależnym programem zbudowany
z wykorzystaniem techniki programowania współbieżnego, realizującym pomiary lub usługi
dodatkowe, jak obsługa bazy danych, kalibracja i testowanie.
Projekt był realizowany przez 3 lata, a w poniższej tabeli zestawiono orientacyjne czasy
trwania wybranych etapów pracy.
Projekt, kompletacja i wykonanie sprzętu 1.5 roku
Opracowanie specyfikacji funkcji
1,5 roku
Wykonanie oprogramowania
1 rok
Testowanie, wdrożenie
1.5 roku
Na omówienie zasługuje proporcjonalnie długi okres testowania, który nie obejmuje przecież
testowania realizowanego bezpośrednio w trakcie prac nad oprogramowaniem. Takie proporcje
czasowe potwierdzają raz jeszcze od dawna znaną prawdę, że znacznie łatwiej napisać program niż
wykazać, że działa on poprawnie. W tym przypadku dodatkowym utrudnieniem był brak
możliwości łatwej weryfikacji otrzymywanych wyników, ponieważ wykorzystane tu generatory
sygnałowe i pomiary porównawcze z inną aparaturą miały ograniczone zastosowanie.
Teoretycznie pełną weryfikację można było jedynie uzyskać korzystając z symulatora. W tym
przypadku wiarygodność otrzymanych wyników była ograniczona ze względu na to, że powstał on
w ramach tego samego projektu i mógł, co zresztą okazało się faktem, zawierać te same błędy co
oprogramowanie systemu.
Analizując przebieg projektu wydaje się, że pewne skrócenie czasu trwania można by
osiągnąć praktycznie tylko dla etapu testowania oprogramowania. W tym celu potrzebne jest
opracowanie niezależnej dokumentacji formalnie definiującej procedury testowe i odpowiednio
dobrane zestawy danych wejściowych. Wykorzystanie specyfikacji funkcji jako odniesienia
merytorycznego przy weryfikacji nastręczało poważnych trudności, ponieważ szybko okazało się,
że od pełnego zrozumienia jak funkcje systemu mają być realizowane, do opracowania testów
potwierdzających zgodne z oczekiwaniami ich działanie jest długa droga.
5. LITERATURA
[1]
[2]
[3]
[4]
[5]
[6]
Aeronautical Telecommunications Annex 10 To the Convention on International Civil
Aviation Volume 1; International Civil Aviation Organization, USA
Manual on Testing of Radio Navigation Aids, Volume I, Volume II; International Civil
Aviation Organization, USA
Flight Inspection Manual; United States Standard; Department of Army, the Navy, and
the Air Force and The Federal Aviation Administration, May 1993
N. Wirth, "Toward a discipline of real-time programming" Communication of the ACM,
20, 877-883, (1977).
D. Arendt and M. Postó³, "Real-time Multiprogramming system for mine control
center", Microprocessors and Microsystems, 14, 39-46 (1990).
C. A. R. Hoare, "Monitors: an operating system structuring concept", Ef, 21, 666-677
(1974).
NAVIGATION AIDS FLIGHT INSPECTION SYSTEM
The paper presents discussion on issues related to the project management, software and hardware development
of a computer system dedicated for air inspections of radio-navigation aids, communication and radar systems
(called CFIS). Main discussion is preceded by description of system destination and its basic functions and is
focused on the most vital questions, from the point of view of the specific application requirements, which was
detailed analyzed during development stage. The paper describes selected results oh this analysis related to
software development and implemented solutions.