Publicyści piszący o lotnictwie przekonują nas, że organizacja synoptyki w kokpicie samolotu, jak i cała technika lotnicza są „krwią pisane”, a więc dopracowane najlepiej, jak tylko można. Czy aby na pewno? No to spójrzmy na rys.1 pokazujący przykład rozrzucenia informacji o UAR prędkości po całym kokpicie, większy obraz tutaj.
Wartość mierzona prędkości jest w lewym dolnym rogu, obok sztucznego horyzontu. Wartość zadana prędkości jest po środku u góry, na zadajniku autopilota. Poziom rozkazów wyjściowych z regulatora prędkości nie jest uwidoczniony, natomiast owszem widzimy poziom rozkazów zrealizowanych, tj. moc silników, ale w zupełnie innym miejscu, tj. po prawej na dole.
Czy to jest właściwa organizacja synoptyki automatyki ? No skądże. Tak mamy, ponieważ każdą z tych skrzynek dostarcza inny producent, tudzież konstruktor chciał, aby je można było łatwo wymieniać. Ale to na pewno nie jest prawidłowy interfejs użytkownika automatyki!
Na rys.1 w prawym górnym rogu dla porównania pokazano standardową konfigurację stacyjki dowolnego regulatora, na przykład w energetyce. Czytelnicy od razu zauważą, że te trzy wskazania w oryginale rozrzucone po całym kokpicie tu są przedstawione w sposób skoordynowany razem.
„Lotnicze” rozwiązania można próbować jakoś tłumaczyć, wskazując, że info o wartości zadanej prędkości jest zdublowane i ma postać ramki w kolorze magenta, również obok sztucznego horyzontu, ale chyba zgodzimy się z tym, że w oczy to ta ramka się nie rzuca.
Z regulatorami kursu i wysokości mamy w rzekomo „dopracowanym" lotniczym rozwiązaniu tak samo, a nawet jeszcze gorzej. Owszem, w różnych, oddalonych od siebie miejscach da się znaleźć setpoint i measurement, ale info o żądanym i zrealizowanym wychyleniu sterów już zginęło. A postępując systematycznie, wg. zasad wizualizacji automatyki nigdy byśmy tej informacji nie zgubili.
Zatem - po kolei.
Po pierwsze musimy sobie uświadomić, że:
- operator kotła i turbiny nie nadzoruje pracy kotła i turbiny, tylko nadzoruje automatykę
prowadzącą nadzór nad kotłem i turbiną,
- pilot nie pilotuje samolotu, tylko nadzoruje automatykę pilotującą samolot.
(Uwaga do bardziej krewkich pilotów, w tym miejscu jeszcze nie komentujemy, zresztą autor znając język polski z góry zna treść przewidywanych tutaj komentarzy).
Pełna informacja o pracy dowolnego regulatora wymaga przedstawienia następujących wielkości:
- wartości mierzonej (wyjście z pomiaru),
- wartości mierzonej ( na wejściu do regulatora),
- wartości zadanej wpisywanej przez operatora,
- wartości zadanej bezpośrednio na wejściu regulatora,
- poziomu rozkazów wyjściowych,
- stanu konfiguracji kaskady regulacji,
- stanu Auto / Manual
- wybranych informacji o ograniczniku prędkości zmian wartości zadanej,
- wybranych informacji o ograniczniku prędkości zmian na wyjściu,
- położenia organu wykonawczego.
Z braku miejsca na synoptyce mamy tendencję do nieodróżniania wartości mierzonej na wyjściu z przetwornika, od wartości mierzonej na wejściu regulatora, ale dla porządku przypominamy, że to nie to samo.
Jeśli chodzi o działanie ograniczników, to najczęściej na synoptyce praktycznie brakuje miejsca na pokazanie kompletu informacji o działaniu ograniczników. Co najmniej musimy wyświetlać wartość żądaną/zadaną/progową opisującą akcję, jaką powoduje ogranicznik.
To co w języku opisowym zajmuje dużo miejsca – bardzo łatwo się kontroluje, gdy na synoptyce jest pogrupowane po prostu razem, obok siebie, patrz rys.2, gdzie pokazuje się przykładowy, minimalny, wymagany zestaw informacji o układzie automatycznej regulacji.
Pewne wątpliwości może budzić podwójny wiersz wartości zadanych. W lotnictwie raczej nie będzie potrzeby korzystania z tego rozwiązania, ale dla systematyki autor wymienia je, jako bardzo potrzebne, zapewniające pełną jawność działania automatyki. W przykładzie na rys.2 zadano dla turbiny 35,0 MW mocy elektrycznej i ta wpisana wartość zadana przepisuje się na wartość zadaną bezpośrednio na wejście regulatora z prędkością 1 MW/min. Tak więc za sześć minut wartość zadana z 29,0 podniesie się do 35,0 MW. Natomiast realna moc turbiny wynosząca 28,9 MW stosunkowo szybko podąża za wartością zadaną 29,0 MW.
W przedmiotowym obszarze panowała dość duża swoboda, programiści umieszczali na synoptyce stacyjki zadawania celu i tempa / żądanego gradientu realizacji celu wedle fantazji. Swego czasu autor w trakcie pracy nad nowym regulatorem turbiny wręcz wymógł na Wykonawcy systematykę jak wyżej. Jeśli wartość zadana "wpisywana" znacznie się różni od wartości zadanej "dla regulatora", ma to być uwidocznione, a stacyjki mają być zgrupowane jedna nad drugą.
W przykładzie na rys.3 ten dodatkowy wiersz wartości zadanej pominięto. Jak to powiedziano, ograniczniki mogą oddziaływać przed wejściem regulatora lub po wyjściu regulatora. Autor zwykle żąda pełnej jawności automatyki, ale przyznaje, że czasem rzeczywiście brakłoby miejsca na pokazanie wszystkiego nad i pod stacyjką regulatora. Dlatego autor preferuje jeden wspólny wiersz dla nastaw ograniczników. Stracimy przy tym informację strukturalną, czy to set point regulatora nadpisuje się z prędkością 4 m/s, czy też żądane 4 m/s jest opanowywane post factum, ale trzeba przyznać, że dla operatora efekt jest ten sam.
Jak widać na rys.3, chcieliśmy z prędkością 4 m/s osiągnąć 10300 m wysokości, ale zatrzymaliśmy się na 10258 m, bo UAR wypadł w Manual. UAR ten będzie tylko biernie naśledzać za położeniem sterów, czyli jego wyjście prawie natychmiast zejdzie z 6,7 ° do położenia sterów 6,1 ° i w zasadzie stanu, jak na rysunku nigdy nie powinniśmy spostrzec. Po właściwym zgrupowaniu informacji o automatyce możemy tych informacji przekazać znacznie więcej i to w sposób znacznie lepiej uporządkowany, patrz rys.4, na którym pokazuje się przykład synoptyki przekazującej pełną informację o trzech regulatorach jednocześnie.
Zasady pracy z synoptyką, jak na rys. 4. są dość proste i łatwo je operatorowi wpoić.
Pracę rozpoczynamy od sprawdzenia stanów L/R i stanów A/M.
A więc ustalamy, czy zadajniki wartości zadanej przyjmują rozkazy spod właściwych adresów, tj. z zadajnika lokalnego, czy z regulatorów nadrzędnych realizujących jakieś gotowe funkcje lub całe programy. (Albo inaczej, sprawdzamy, czy cała kaskada regulacji od UAR nadrzędnego do kolejnego, wymaganego UAR podrzędnego jest załączona).
No i przede wszystkim ustalamy, czy w ogóle regulatory są załączone w Auto.
Jeśli tak, to nadzór sprowadza się do sprawdzenia zgodności między wartością mierzoną, a zadaną.
W tym przykładzie prędkość jest utrzymana idealnie, kierunek lotu będzie podciągany o 2 °,
wysokość nie jest regulowana, bo UAR jest w manualu. Gdyby ktoś nacisnął guzik z jakąś gotową funkcją, np. odejścia na drugi krąg, to „guzik” z tego będzie, bo organ wykonawczy jest odłączony w „M”, chyba, że tenże gotowy guzik realizuje także konfigurowanie stanów załączenia automatyki. Tak czy siak, informacja o wyłączeniu automatycznej regulacji wysokości jest dobrze zwizualizowana.
Proszę zauważyć, jak mało miejsca przeznaczono na przekazanie aż 23 informacji o automatyce i to w przyzwoitej rozdzielczości. W oryginale, jak to już wspomniano, informacja o żądanych i zrealizowanych położeniach sterów w ogóle zaginęła, tutaj systematyka sama te informacje wymusiła.
Przy organizacji automatyki j.w. w ogóle nie ma znaczenia, czy operator nadzoruje automatykę samolotu, czy automatykę produkcji serów topionych. Przebiegamy wzrokiem dwa wiersze i sprawdzamy zgodność wiersza w kolorze jasnoniebieskim z górnym wierszem białym – do takiego banału sprowadza się nadzór nad dobrze zorganizowaną automatyką.
Na rys.5 można zauważyć, że czwarty silnik nie zrealizował zadanej wartości mocy.
Na rys.5 można zauważyć, że ster kierunku zablokował się w skrajnym położeniu i ma wychylenie -15 ° zamiast żądanych 1,3 °.
Na rys.5 można zauważyć, że utraciliśmy kontakt z nadajnikiem położenia steru wysokości. Nie wiemy, czy wynosi ono 6,1 °, wiemy tylko, że prawdopodobnie sygnał z nadajnika położenia nie mieści się w zakresie 4-20 mA.
Na rys.6 pokazujemy wizualizację stanu, w którym tryb Forced przejął ster wysokości.
Pojawienie się czerwonej literki „F” zamiast „A” oznacza wymuszone przejęcie samolotu przez automatykę. Np. czujnik przeciągnięcia żąda opuszczenia nosa samolotu i operator nie ma wyjścia (chyba, że projektant dopuścił jakiś sposób na wyłączanie automatyki). W przypadku błędu automatyki – i tak jesteśmy „do przodu”. Przynajmniej operator nie musi szukać, co go trzyma, od razu wiadomo, gdzie odbywa się jakieś wymuszenie.
33 lata temu autor miał wątpliwości, czy synoptyka cyfrowa będzie lepsza od analogowej, która między innymi znaczniej lepiej pokazuje dynamikę zmian, tudzież łatwo zorganizować pokazywanie zgodności sygnałów ( typu „dwie kreski razem ).
Ale po 33 latach tych wątpliwości autor nie ma. Na rysunkach powyżej pokazano, że korzystając z dzisiejszych możliwości technicznych można operatorowi przekazać znacznie więcej i znacznie lepiej pogrupowanych informacji. Pokazane na rys.7 dwie liczby 220 km/h są znacznie większe i znacznie lepiej widoczne, niż analogowa ramka w kolorze magenta również mająca obrazować setpoint.
Dzisiejszy młody człowiek jest przyzwyczajony do techniki cyfrowej. Nie stanowi problemu oderwanie na chwilę wzroku od sztucznego horyzontu i przebiegnięcie wzrokiem stanów regulatorów, jeśli będą one duże, wyraźne, zgrabnie pogrupowane. Tylko trzeba wypracować nawyk kontrolowania kilku miejsc, a nie gapienia się w jedno. Bardzo często kontrola okresowa jest lepsza od stałej – lepiej pozwala wykrywać zmiany.
Interfejsy użytkownika we współczesnej technice lotniczej są po prostu źle zorganizowane, a technika lotnicza nie wykorzystuje współczesnych możliwości techniki.
Autor napisał ten artykuł na bazie własnych doświadczeń w rozwoju automatyki, doświadczeń we współpracy z firmą Valmet i wykorzystując i rozwijając jej zasady.
Lotnicy dość dumnie nazywają swoją automatykę „skomplikowaną awioniką”, tymczasem dla „automatyka” jest to zwykła, najzwyklejsza w świecie automatyka, złożona z regulatorów, czasem zapewne z regulatorów pogrupowanych w kaskady regulacji. Regulator nie wie, czy steruje mocą silnika, kursem statku, czy poziomem skroplin w regeneracji niskoprężnej. Regulator wie tylko, że na podstawie sygnału dostarczanego na jego wejściu ma wypracować jakiś wymagany poziom sygnału wyjściowego. Natomiast człowiek nadzorujący jego pracę musi zawsze dostać najmniej od 5 do 7 informacji charakteryzujących stan pracy regulatora, rzadko kiedy dopuszcza się wizualizację uproszczoną, autor jest zdania, że to i tak za mało, tylko nigdy nie będzie dość miejsca na jego fanaberie. Ale im więcej informacji wyświetlimy, tym rzadziej będziemy wzywali specjalistę do diagnostyki błędów w automatyce – operator powinien sam zauważyć, który sygnał nie przechodzi dalej, jest ucinany, etc.
Autor pracuje w energetyce i na dużym bloku energetycznym ilość automatycznych regulatorów może być dużo większa, niż w samolocie. I energetyka problemy wizualizacji stanów automatyki musiała rozwiązać.
Praca w kokpicie samolotu niczym się nie różni od pracy w nastawni bloku energetycznego – nadzorujemy automatykę. Owszem jest jeden „drobny niuans” – w przypadku nieprawidłowości prawie zawsze podejrzenie pada na czujnik i jest nadzieja, że to nie jest prawdziwy błąd technologiczny – prawie zawsze wysyła się człowieka do sprawdzenia czujnika i jest prawdą, że pilot samolotu w locie takiej możliwości nie ma. Ale reszta doświadczeń między energetyką i lotnictwem jest wymienna.
Ostatecznie trzeba powiedzieć, że autor uruchomił autorską wersję regulatora turbiny, który może realizować kilkanaście funkcji:
- utrzymywanie mocy elektrycznej brutto,
- utrzymywanie mocy elektrycznej netto,
- utrzymywanie stałego przepływu pary z kotła do turbiny,
- utrzymywanie ciśnienia w upuście ciepłowniczym za pomocą zaworów turbiny,
- utrzymywanie ciśnienia w upuście ciepłowniczym za pomocą diafragmy,
- utrzymywanie ciśnienia pary przed turbiną,
- utrzymywanie obrotów turbiny,
- regulację ręczną,
- realizację wielu ograniczeń przed regulatorem,
- realizację wielu ograniczeń za regulatorem,
- realizację wymogów obrony systemu el.en. ( zrzuty mocy, itp. ).
Jest to realizacja nietypowa, znacznie przekraczająca dotychczasowe standardy. Gdyby autor zlekceważył tutaj zagadnienia synoptyki to zapewne operatorzy by go zlinczowali.
A jednak dało się to pogrupować w czytelny sposób wg. zasad, jak wyżej, więc autor nie jest gołosłowny w tym, co proponuje dla kolegów lotników. Mowa jest o wdrożonym układzie regulacji dla turbiny o mocy porównywalnej z mocą turbin lotniczych.
Na rys.8 pokazano, że układy regulacji kaskadowej można mnożyć bez utraty jakości informacji. W tym przykładzie aktywne jest zadawanie parametrów z nadrzędnego programatora lotu. Sygnalizowane jest także wykrycie aktywnej wiązki ILS, ale automatyki ILS jeszcze nie załączono. Gdy ją włączymy wyłączy się zadawanie parametrów z programu lotu. Ideałem byłaby prezentacja kompletu parametrów regulatorów nadrzędnych i przy odrobinie uwagi da się to zrobić „w stylu autora”. Np. przy odejściu na drugi krąg powinniśmy widzieć w kolorze jasnoniebieskim prędkość, jaka zostanie zadana na wejście podrzędnego „wykonawczego” UAR prędkości. Jednak w tym przykładzie autor dla regulatorów nadrzędnych pokazał z całej 5-cio elementowej stacyjki tylko przyciski A/M dlatego, że gdyby zastosować stacyjki pełne - podstawowe stacyjki regulatorów lotu „wylądowałyby” zbyt nisko. A najważniejsze stacyjki mają być tam, gdzie wzrok ludzki kieruje się w pierwszej kolejności ( czyli nie pod kolanami ).
Podano przykład, w którym UAR prędkości jest w „L” i nie przyjmie rozkazów z zadajnika nadrzędnego. Oczywiście można tak zrobić, że jedno naciśnięcie przycisku „Odejście na drugi krąg” przejmie ten UAR w „R” - rzecz jest do dyskusji, w każdym bądź razie pamiętając o pierwszej z podanych zasad obserwacji, tj. sprawdzania, czy są „R”-ki oraz czy są „A” bardzo szybko wykryjemy, czy automatyka podrzędna regulatorów nadrzędnych posłucha, czy nie.
Amerykanie lubują się w stosowaniu skrótów nazw. Posługiwanie się takim slangiem daje potem wrażenie „fachowości”. A w rzeczywistości wydłuża szkolenie i utrudnia zrozumienie automatyki. Autor pokazuje na rys.8, że stosowanie pełnych opisów znacznie ułatwia zrozumienie, a wcale nie zajmuje więcej miejsca na synoptyce. Także i wcale więcej miejsca nie zajmuje stosowanie większych czcionek. Nie wiedzieć czemu programiści lubią korzystać z czcionki „Small fonts 6” – „wywalenie” tekstu Boldem 72 znacznie poprawia korzystanie, a miejsca na to, jak się wszystko dobrze zorganizuje jest dość.
Wróćmy jeszcze do energetyki.
Swego czasu autor omal się nie pobił z pewnym projektantem, który jako schemat synoptyki dostarczył podkolorowane technologiczne schematy ideowe. „A automatyka gdzie ? No… jak się kliknie w pomiar, to się otworzy stacyjka automatyki”…Takie podejście oznaczało, że operator nie widziałby konfiguracji regulatorów, musiałby ją dopiero otwierać na żądanie, przy czym zależności między regulatorami w kaskadzie regulacji i tak by nie zobaczył.
Wyobraźmy sobie, że nadrzędny regulator różnicy ciśnień na końcu miasta na końcu sieci ciepłowniczej wydaje rozkazy do podrzędnego regulatora ciśnienia na tłoczeniu pomp w elektrociepłowni, a ten z kolei wydaje rozkazy do czterech podrzędnych regulatorów obrotów pomp sieciowych.
Co w tej sytuacji mamy pokazać operatorowi do nadzoru:
- kreskę symbolizującą kolektor tłoczny pomp i kółka symbolizujące pracę pompy,
czy też
- stacyjki kolejno ulokowanych pod sobą regulatorów nadrzędnych i podrzędnych?
Szczerze mówiąc, gdyby operator w elektrociepłowni nie wiedział, że ma zasilanie, powrót i pompy, to jak on się na tym stanowisku znalazł...Choć oczywiście w przypadku rozbudowanych schematów technologicznych trzeba je jednak zamieścić. Jeśli jest miejsce. Jeśli nie ma miejsca, to stoimy przed wyborem: prosta synoptyka, czy struktura automatyki.
Górnolotnie rozumianym celem operatora hydrauliki systemu ciepłowniczego jest bezpieczne dostarczenie ciepła do każdego odbiorcy. Ale w praktyce przecież jego celem jest zapewnienie, że dp na osiedlu Bohaterów Lotnictwa musi wynosić 1,00 bar, a ponieważ wynosi 0,83 bar to musi poobserwować, czemu UAR dP się nie wyrabia i ewentualnie podgonić obroty pomp ręcznie. Wymienione osiedle jest w PECu na końcówce, tam jest wiecznie zimno, więc to miejsce wybrano, jako obiekt kluczowy do automatyzacji.
Aby sprawdzić, czy wielkość "0,83 dogania 1,00" operator musi patrzeć, czy wielkość "7,32 dogania 7,35", oraz czy obroty pomp "dochodzą do 960". Celowo pominięto jednostki i precyzyjny opis, aby pokazać, że cel "górnolotny" znacznie się różni od celu roboczego. Praca operatora de facto polega tutaj na obsłudze pięciu regulatorów, a o każdym regulatorze trzeba przekazać minimum 5 informacji. Tu trzeba pokazać (w skrócie po angielsku) me, set, out, A/M regulatora różnicy ciśnień, me, set, out, A/M, L/R regulatora ciśnienia na tłoczeniu pomp, komplet informacji opisujących pracę czterech regulatorów wykonawczych obrotów pomp, ich prąd/moc i info o dozwolonym punkcie pracy (kolejne 3 liczby). To znacznie więcej, niż namalowanie kreski mającej symbolizować rurociąg tłoczny, ssawny i namalowanie czterech zielonych kółek ze strzałką po środku. Autor pokazuje, że na synoptyce znakomicie da się pokazać strukturę automatyki, a przecież to w niej tkwi sedno pracy operatora. W nadzorze nad regulatorami. Rurociągi są już dawno pospawane, spawy prześwietlone, ich operator nie nadzoruje.
Notabene, na podanym przykładzie autor wrysował w UAR dP oraz UAR P wielkości wyjściowe rzędu ułamkowych części procenta, a nie wielkości z zakresu 0-100 %, dlaczego? Ponieważ w takim układzie wymarzonym rozwiązaniem są regulatory inkrementalne. W tradycyjnym rozwiązaniu w przypadku 4 regulatorów wykonawczych obrotów pomp nie dałoby się zorganizować naśledzania MANUAL AUTO w kaskadzie regaulacji. Regulator inkrementalny w samolocie pozwala (o zgrozo) sterować lotem bez wyłączania autopilota. Oczywiście jeśli pilot chce walczyć z autopilotem, to nazwie autora idiotą. Ale pilot, który by chciał dopomóc ręcznie autopilotowi we właściwym kierunku znakomicie wspomoże jego pracę, może go po prostu podgonić i... dalej spać. Rzecz tylko w rozumieniu pracy automatyki, nie samolotu. Incydent lotniczy wynikły z niewiedzy w tym obszarze także już się zdarzył.
Górnolotnie rozumianym celem pilota jest bezpieczne przewożenie ludzi i towarów. Ale bieżącym celem roboczym jest sprawdzenie, czy mierzona wartość 81⁰ dogania zadaną 90⁰, o ile chcemy lecieć tam, gdzie musi być jakaś cywilizacja. Albo czy mierzona wartość 930 km/h schodzi do zadanych 900 km/h. Albo czy, jak to już wspomniano ogólnie, wartości wyświetlane na biało oscylują wokół wartości wyświetlanych na jasnoniebiesko.
Dlatego właśnie współczesne schematy synoptyczne powinny się koncentrować na uwidocznieniu struktury automatyki – kluczem do sukcesu jest jej jawność.
A zatem nawet skomplikowana automatyka nie jest problemem. Problemem jest chaotyczna synoptyka nie przekazująca operatorowi / pilotowi właściwie pogrupowanych informacji.
Teoretycznie dominowało założenie, że wszystko musi być „przed oczami operatora”, czyli wokół sztucznego horyzontu, a w praktyce wyszedł kociokwik, z powodu którego „awionika jest skomplikowana”, a „lotnicy się gubią i nie wiadomo, czy to człowiek rządzi samolotem, czy na odwrót”.
Już od pierwszego uruchomienia pierwszego automatycznego regulatora na świecie, a był to regulator kursu statku, wiadomo, że automatyka jest lepsza od człowieka. I po pierwszym uruchomieniu opisywanego regulatora i pozytywnym wyniku testu – zaprzestano prac nad nim. „Bo co by to było, gdyby jakaś maszyna kierowała statkiem, to ja dumny marynarz z fajką w zębach wiem lepiej, gdzie mam płynąć”. I od tego czasu nic się nie zmieniło – automatyka w 99 % przypadków jest lepsza od człowieka, a wątpliwości mamy nadal.
Argumentacja przeciwników automatyki zarówno 100 lat temu, jak i dzisiaj była zawsze taka sama: „bo co będzie, jak coś się stanie i kto za to będzie ponosił odpowiedzialność”. Autor słyszał tą argumentację dziesiątki razy przy każdej próbie modernizacji każdego kolejnego urządzenia. Pominąwszy inwektywy i ustalanie, kto się zna lub nie zna, jest spoza branży, nigdy nie leciał i nie wie, jak to jest w powietrzu - argumentacja taka zawsze zdradza tylko jedno: ignorancję jej autora. Inżynier już przed pierwszym załączeniem automatyki doskonale ma wiedzieć, „co będzie, jak coś się stanie”. Jedyne, czego nie znamy w chwili załączania automatyki to optymalnych nastaw regulatorów, bo wstępne też już musimy mieć.
Modernizacyjne spory od tysięcy lat mają podobny przebieg: mistrz w swoim fachu potrafi szybko zapędzić młodzika w kozi róg. Ale po stosunkowo niedługim czasie okazuje się, że stary, doswiadczony wyjadacz fachura nie nadąża za postępem techniki. Młody, nieopierzony, prosto po szkole znał nowinki, ale nie potrafił ich wyargumentować, nie potrafił scalić wiedzy nowej ze starą. Ale autor już nie jest młody. Na dodatek wie, czym kończy się rutyna u starego wyjadacza, który od dawna jest przekonany, że już wszystko wie.
Prawda jest taka: owszem, w niektórych przypadkach ręcznie można wyregulować lepiej, ale nie można regulować ręcznie więcej, niż jednej, dwóch wielkości jednocześnie. Próba ręcznej regulacji trzech parametrów, np. kursu, wysokości i prędkości sprawia już znaczne problemy. Przy kilkuset wielkościach do regulowania to jednak komputer, a nie człowiek będzie lepszy.
Z tym, że autor po latach doświadczeń z automatyką maszyn energetycznych ma dość jasno sprecyzowany pogląd – nie ma dyskusji o tym, czy automatyka jest lepsza od człowieka, czy na odwrót. Każde służy do czego innego, potrzebne są oba segmenty zarządzania, tylko trzeba wiedzieć, jak nie wchodzić sobie w drogę. Na dodatek mamy, jak wspomniano regulatory inkrementalne, za pomocą których można zorganizować sterowanie ręczne bez wyłączania automatyki, to wspaniała oferta, rzecz tylko w nabyciu innych nawyków.
Interfejs użytkownika automatyki ma być dostosowany do potrzeb nadzoru nad automatyką, a nie do potrzeb „bohaterskiego pilota” – wtedy będzie dobrze.
90 % czasu zadaniem pilota jest nadzór nad automatyką, nie "latanie". Oczywiście jest problem, jak nie zapomnieć, co się robi przez te 10 % czasu, kiedy jednak trzeba umieć prowadzić ręcznie, ale piloci sobie z tym radzą, choćby ćwicząc w aeroklubie na szybowcu. Niemniej powtórzmy - skoro elementem pracy pilota jest zarówno obsługa automatyki, jak i ręczne pilotowanie, to umowa o pracę przewiduje obecnie obsługę automatyki i ręczne pilotowanie. Kto uważa, że jego zadaniem jest tylko romantyczne latanie, a automatykę lekceważy - nie wykonuje swoich obowiązków. I stwarza zagrożenie, bo wypadków w obszarze interfejsu człowiek - maszyna było dość.
Na koniec trzeba jeszcze omówić sprawę chyba najsłynniejszego błędu w automatyce – błędu z czujnikiem przeciągnięcia w B737 MAX. Fizyczne uszkodzenia systemów sterowania zdarzają się niezwykle rzadko. Tu był ordynarny błąd projektowy.
Standardem zabezpieczeniowym w automatyce jest stosowanie zasady „dwa z trzech”. Taką akcję zabezpieczeniową, jak w przypadku czujnika przeciągnięcia B737 MAX powinno się rozpoczynać po zadziałaniu 2/3 czujników. Wtedy jest jasne, że gdy jeden się uszkodził, a dwa pokazują normalnie, to problemu nie ma. Gdy są pobudzone 2/3 czujników, to prawdopodobieństwo prawdziwego zagrożenia jest znaczne i akcję zabezpieczeniową należy rozpocząć. Autor ze zdumieniem czyta oświadczenia producenta, że teraz będzie lepiej, bo będą brane pod uwagę wskazania dwóch czujników, a nie ( o zgrozo ) jednego, jak dotychczas. Owszem jest to dwa razy lepiej, niż dotychczas, ale konia z rzędem temu, kto wymyśli algorytm rozpoznający, który z dwóch czujników jest niewiarygodny. No może w przypadku całkowitego wyjścia poza zakres sprawa będzie jasna, ale w przypadku lekkiego rozstrojenia przetwornika – wg. znanych zasad logiki błąd jest nie do wykrycia. Można wykryć, jak to zdecydowano rozbieżność, ale w przypadku lekkiego rozkalibrowania czujników – na szybko ustalić, który pokazuje źle w żaden sposób się nie da. Autor rozumie, że żąda minimum 3 czujników, a skrzydła w samolocie są dwa, ale to nie jest przeszkoda nie do pokonania.
W każdym bądź razie błąd B737 MAX to nie wina automatyki, tylko oślego uporu. Jak to już wielokrotnie autor napisał – po dostosowaniu lotnictwa do zasad automatyki problemy z automatyką w lotnictwie się skończą. 17.09.2021, rev. 27.10.2022