Czy nie za szybko uruchamiamy innowacje - czyli release now, patch later

| Gospodarka PLC, HMI, Oprogramowanie

Po miesiącach śledztwa dotyczącego katastrofy etiopskiego Boeinga 737 MAX 8 wszystko wskazuje na to, że do tragedii doprowadziła usterka techniczna powiązana z oprogramowaniem samolotu. Wydarzyło się to w branży, gdzie standardy bezpieczeństwa są jednymi z najwyższych na świecie, jeżeli nie najwyższymi.

Czy nie za szybko uruchamiamy innowacje - czyli release now, patch later

W przemyśle produkcyjnym również coraz więcej zależy od software'u, który kontroluje pracę zarówno pojedynczych sterowników, jak też złożonych instalacji procesowych. Tymczasem nadchodzą kolejne zmiany i w przyszłości algorytmy sztucznej inteligencji mają przejmować odpowiedzialność za kontrolę pracy systemów produkcyjnych. Czy doświadczenia sektora lotniczego nie powinny być ostrzeżeniem i skłonić nas do zadania pytania - czy aby nie za szybko wprowadzamy pewne innowacje?

Przesłanki dowodowe marcowej katastrofy lotu 302 linii Ethiopian Airlines oraz drugiej, dotyczącej zeszłorocznego lotu 610 linii Lion Air, wskazują na wadliwe działanie systemu MCAS (Maneuvering Characteristics Augmentation System). Został on dodany do modeli MAX ze względu na ich większe silniki, zaś jego zadaniem było… zwiększenie bezpieczeństwa. MCAS odpowiada za stabilizację toru lotu samolotu i ma zapobiegać jego przeciągnięciu.

 
Niepoprawne odczyty z czujników kąta natarcia powodowały błędne działanie systemu MCAS, doprowadzając do katastrofy lotu 302 linii Ethiopian Airlines

Dane z czarnych skrzynek etiopskiego Boeinga wskazują (rysunek obok), że odczyty z jednego czujnika były błędne, przez co system automatycznie obniżał dziób statku. W trakcie lotu piloci, chcąc ustabilizować sytuację, system wyłączali, jednak po kilku minutach starań samolot rozbił się. Po tym wydarzeniu na świecie uziemionych zostało około 400 podobnych samolotów (w tym pięć LOT-u), zaś koszty z tym związane Boeing szacuje na miliard dolarów kwartalnie. Firma wprowadza obecnie poprawki do oprogramowania MCAS, co de facto potwierdza jej odpowiedzialność za katastrofy, które pochłonęły w sumie 346 ludzkich istnień.

Jaki ma to związek z automatyką? Sądzę że duży, bowiem przemysł jest coraz bardziej zależny od oprogramowania. Cyfryzacja, wykorzystanie sieci czujnikowych, edge computing, analiza Big Data - wszystkie dają niesamowite możliwości, ale też wymagają nowych umiejętności organizacji, w tym w zakresie walki z zagrożeniami cybernetycznymi. Te ostatnie dotyczyć mogą występowania luk bezpieczeństwa w urządzeniach - takich jak te w sterownikach Simatic dekadę temu czy niedawno wykrytych luk w napędach PowerFlex 525, problemów z oprogramowaniem kontrolerów robotów współpracujących, jak też błędów w dużych systemach. Umożliwiły one w 2014 roku cyberatak na jedną z niemieckich hut, w efekcie którego nastąpiło uszkodzenie pieca, a także zatrzymanie dwa miesiące temu operacji norweskiego producenta aluminium Norsk Hydro. Na skutek ataku hakerów pracownicy firmy musieli manualnie wyłączać systemy produkcyjne w fabrykach na całym świecie!

Rosnąca liczba informacji o problemach software'owych i cyberatakach nie powinna dziwić. Wraz z tym, jak postępuje integracja systemów produkcyjnych i teleinformatycznych, szybko rośnie liczba włamań do nich, a także możliwości powstawania błędów po stronie dostawców technologii. Na porządku dziennym są też mniejsze incydenty z obszaru cyberbezpieczeństwa oraz nieupublicznione problemy z błędnym działaniem oprogramowania maszyn i urządzeń. Jako że od cyfryzacji nie ma odwrotu, pozostaje regularnie przypominać o istniejących zagrożeniach i zachęcać do stosowania odpowiednich metodyk bezpieczeństwa.

Rozmawiając z przedsiębiorcami o planach cyfryzacji zakładów, często dowiaduję się, że firmy robią w tym zakresie coraz więcej, ale jeszcze sporo brakuje do osiągnięcia docelowego stadium transformacji. Dzisiaj zbierają one i przetwarzają duże ilości danych, na ich bazie optymalizując produkcję, jednak przyszłość należy do sztucznej inteligencji. Ma ona zautomatyzować podejmowanie decyzji - przykładowo system ma przewidywać możliwe zmiany w procesach czy stanie maszyn i samemu wprowadzać odpowiednie działania zapobiegawcze. Jest to świetna perspektywa, o ile ów system będzie działał poprawnie i w "inteligentny" sposób reagował na niewłaściwe dane lub celowe zaburzanie jego pracy. Jeżeli natomiast operator będzie musiał z nim walczyć - niczym piloci Ethiopian Airlines ze swoim samolotem, to jest to jeden z gorszych możliwych scenariuszy.

"Release now, patch later" - to metodologia, gdzie poprawki software'u są do niego wprowadzane już w czasie użytkowania. O ile sprawdza się ona w przypadku gier i oprogramowania komercyjnego, o tyle takie podejście jest biegunowo odmienne od wymaganego przez przemysł. Pozostaje mieć nadzieję, że dostawcy z naszego rynku nie ulegną presji konkurencyjnej i nie zaakceptują podobnego schematu działania jako swojego modus operandi.

Zbigniew Piątek