Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

O tym, jak w trzy osoby stworzyliśmy nowy sposób analizy danych silników lotniczych

O półrocznej pracy nad APET (Advanced Production Engines Trending) - aplikacją usprawniającą finalne badanie silnika - od fazy koncepcji, Proof of Concept, backend, frontend, testy i wdrożenie.
Edc silniki

Transport powietrzny od lat uznaje się za bardzo bezpieczną formę przemieszczania się, a rok 2017 określono jako najbezpieczniejszy w historii lotnictwa cywilnego. Powodów takiego stanu rzeczy jest wiele, ale jednym z nich są na pewno testy zdawcze silników przed oddaniem ich do użytku.

W czasie finalnego badania silnika analizuje się takie parametry, jak konsumpcja paliwa, temperatury, przepływ powietrza, itd. Kiedyś taka analiza była żmudna, czasochłonna i kosztowna. Dziś może być dokładniejsza, bardziej interaktywna, szybsza i dużo łatwiejsza do przeprowadzenia dzięki aplikacji, którą wraz z dwoma innymi programistami miałem przyjemność tworzyć dla firmy GE w warszawskim Engineering Design Center.

Klasyczna analiza danych silnikowych

Jak wyglądała tradycyjna analiza parametrów silnika? Przede wszystkim - poza samą interpretacją danych - obejmowała także przygotowanie materiału, filtrowanie, obróbkę oraz wizualizację. Całość trwała około pięć godzin, a czasem proces ten jeszcze się wydłużał. Dostarczane inżynierom wykresy były statyczne. Inżynier nie mógł na żądanie zmieniać skali czy parametrów, a w przypadku pomyłki osoba odpowiedzialna za generowanie danych musiała dostarczyć je ponownie. W związku z kontrolą eksportu istniały także ograniczenia dostępu do surowych danych, co powodowało, że ich procesowanie możliwe było czasem tylko cztery razy w ciągu dnia. Co więcej, proces nie był spójny dla różnych programów silnikowych. W efekcie przeprowadzanie tych analiz było żmudne, uciążliwe dla analityka i… zajmowało dużo czasu, co przekładało się na wyższe koszty.

Co można zmienić, czyli jak powstał pomysł na APET

W sierpniu 2016 zauważono, że automatyzacja procesu analizy danych przyczyniłaby się do przyspieszenia samej obróbki materiału oraz spowodowałaby eliminację czynności przygotowawczych. W efekcie czas przeprowadzenia badania skróciłby się do około pół godziny, co - przy liczbie średnio 1200 rocznie badanych silników w danej linii silnikowej - spowodowałoby ogromną oszczędność czasu, a co za tym idzie – pieniędzy.

Powstał więc pomysł stworzenia nowoczesnego narzędzia, z łatwym dostępem przez przeglądarkę internetową oraz urządzenia mobilne o procesie spójnym dla kilku linii silnikowych. Celem miało być stworzenie aplikacji, która w sposób automatyczny i dynamiczny byłaby w stanie wizualizować istotne parametry do oceny przez wykwalifikowanego inżyniera. Program miał być elastyczny i zintegrowany, zdolny do obsługi błędów podczas działania aplikacji. Miał mieć także zdolność do radzenia sobie z uszkodzonymi danymi.

Do pracy nad projektem został wyznaczony nasz trzyosobowy scrumowy team, składający się z back-end i front-end developerów oraz testera, pełniącego jednocześnie obowiązki Scrum Mastera (więcej o pracy w modelu scrumowym przeczytasz tutaj). Spisaliśmy wymagania w postaci User Stories, tworząc początkowy backlog i rozpoczęliśmy prace nad aplikacją o nazwie APET (Advanced Production Engines Trending).

Od czego zaczęliśmy?

We wrześniu 2016 zostaliśmy zapoznani z Product Ownerem APET-a oraz grupą inżynierów wspomagających tłumaczenie wymagań biznesowych, od których mogliśmy zawsze oczekiwać merytorycznej pomocy przy automatyzacji procesu. Czas sprintu został ustalony na dwa tygodnie, w trakcie których odbywały się wszystkie charakterystyczne dla Scrumu „obrzędy”, jak: sprint planning, dsm, backlog grooming, retrospektywa oraz demo.

Rozwiązanie, które zaproponowaliśmy, to budowa narzędzia na platformie w chmurze, w której każdy uprawniony otrzymałby dostęp nie do surowych danych, a do spójnego narzędzia wizualizującego dla wszystkich programów silnikowych. Pozwoliłoby to każdemu inżynierowi generować te wykresy, które są mu potrzebne w danej chwili z możliwością skalowania, filtrowania oraz zapisywania danych do wybranego formatu plików. Dzięki spójności procesów pomiędzy poszczególnymi liniami silnikowymi program miał dawać także możliwość wymieniania spostrzeżeń i doświadczeń pomiędzy inżynierami z różnych test site’ów.

Proof of Concept

Pierwszą fazą projektu było dostarczenie w możliwie krótkim czasie aplikacji jako Proof of Concept (POC), w którym mieliśmy zaadaptować możliwość obsługi dwóch silników turbowentylatorowych. W pierwszym sprincie, nazywanym przez nas zerowym, skupiliśmy się na wyborze odpowiedniego stosu technologicznego. Przede wszystkim należało zdefiniować podstawowy stack dla zasadniczych warstw aplikacji webowej, tj. back-endu i front-endu.

Jednym z podstawowych założeń było rozwijanie aplikacji na Plaftormie Predix (Platform-as-a-service) opartej na Cloud Foundry, która po prześledzeniu naszych wymagań spełniała je w większości. Platforma pozwala na szeroki wybór stosu technologicznego, łatwy deployment oraz przyszłe skalowanie aplikacji. Pracując na platformie PaaS możemy liczyć na bardzo szybki development, gdyż jedyne, czym musimy zarządzać, to dane oraz aplikacja. Jest to wielka zaleta w stosunku do tradycyjnych rozwiązań IT czy nawet IaaS, gdzie musimy martwić się o środowisko uruchomieniowe oraz middleware, a także O/S, przestrzeń dyskową, czy sieć (w przypadku tradycyjnego modelu). Dodatkowo Predix daje szansę na skorzystanie z wielu wbudowanych mikroserwisów umożliwiających zdalne monitorowanie i diagnozę, developowanie w znanych językach, jak m. in. Java, .NET, Python, R, Rails oraz wysoki poziom bezpieczeństwa. Więcej o Predixie przeczytasz tutaj.

Back-end

Wiedząc, że chcemy pracować na Predixie, po serii kilku spotkań, ocenie kompetencji członków zespołu oraz wymagań projektowych POC-a, jeśli chodzi o back-end zdecydowaliśmy się na Javę 8 we frameworku Spring Boot. Przede wszystkim ze względu na dobre wspieranie technologii cloudowej, rozbudowaną integrację z Predix oraz dobre doświadczenia teamu z tym stosem technologicznym. Dane postanowiliśmy składować w relacyjnej bazie Oracle (Hibernate jako JPA provider). Informacje do plotowania miały być udostępniane poprzez interfejs REST-owy (zgodny ze standardem JAX-RS), w formacie JSON. Według klasyfikacji Leonarda Richardsona nasze API chcieliśmy budować na Poziomie 2 (HTTP Verbs), a do jego testowania użyliśmy oprogramowania SoapUI, które stanowiło niejako część integracyjną testów.

Nieodłączną częścią developmentu były również testy jednostkowe. Dla naszych potrzeb stwierdziliśmy, że przy ich pisaniu najlepiej będzie skorzystać z zalet podejścia TDD (Test Driven Development) oraz BDD (Behavior Driven Development). Technologicznie wspierał nas Junit 4 jako framework testowy oraz biblioteki Mockito oraz Hamcrest, umożliwiające mockowanie danych oraz assercje. Aplikacja budowana była przez narzędzie Maven, a kontrolą wersji sterował GIT. Testy integracyjne obejmowały między innymi sprawdzenie poprawności połączenia z bazą danych, synchronizację oraz poprawność danych źródłowych.

Front-end

Rozwijanie aplikacji na Predixie wiązało się z koniecznością projektowania interfejsu użytkownika aplikacji zgodnie z wytycznymi Predix UI. Interfejs ten pozwala ujednolicić look and feel wielu aplikacji poprzez zestaw aplikacji startowych (tzw. seed application) oraz komponentów webowych, dostarczanych przez bibliotekę Polymer 2.0. Do budowania front-endu wybraliśmy zatem JavaScriptowy framework AngularJS. Do głównego zadania aplikacji, jakim jest generowanie wykresów, użyliśmy interaktywnych Highcharts.

Pobieranie i wstępna analiza danych

W pierwszej wersji aplikacji dane do wykresu generowane były na podstawie surowych danych z plików CSV (w następnej miały być już automatycznie ładowane z hurtowni danych do bazy poprzez ETL), gdzie jeden plik odpowiadał jednej linii silnikowej. Pliki te poprzez interfejs REST mogły zostać załadowane do bazy danych, a następnie użyte do rysowania wykresów. Proces ładowania plików składał się z walidacji poprawności danych, wstępnej obróbki oraz zapisu do bazy danych i został zarezerwowany dla administratorów aplikacji. Na każdym etapie użytkownik był informowany o statusie tego procesu. Po udanym załadowaniu takiego pliku inżynier pracujący nad konkretną linią silnikową mógł użyć narzędzia do wygenerowania dynamicznego wykresu z dowolnymi parametrami, które zdecydowaliśmy się wspierać w aplikacji. Możliwość dowolnego zestawienia parametrów zapewniały odpowiednie filtry rekurencyjne zaprojektowane w Javie.

Testy akceptacyjne i wdrożenie

Project APET w fazie Proof of Concept oddaliśmy do testów po dwóch miesiącach pracy. Pierwsze opinie użytkowników wykazały, iż większość zaproponowanych konceptów rzeczywiście znacznie przyspieszyło analizy. Z entuzjazmem spotkała się główna funkcjonalność, jaką była możliwość generowania wykresów dla wybranych parametrów ad-hoc przez każdego inżyniera.

Po dobrym przyjęciu POC-a zdecydowano się na właściwy development aplikacji. Pracując w niezmienionym składzie zespołu przez około pół roku dostarczaliśmy nowe funkcjonalności, które miały za zadanie spełnić wszystkie wymagania zaplanowane już na poziomie konceptu. Dodatkowo wdrażaliśmy takie funkcje, które okazały się potrzebne w trakcie testów z użytkownikami finalnymi – np. obsługa nowych parametrów silnika, dostarczanie precyzyjnych punktowych danych oraz liczenie wielu danych statystycznych, które inżynierowe wcześniej musieli liczyć sami. W efekcie w styczniu 2017 aplikacja została przekazana pierwszej grupie testerów spoza zespołu projektowego.

Finalna aplikacja

Po dwóch miesiącach użytkowania aplikacji dla pierwszych dwóch typów silników zdecydowaliśmy się rozpocząć prace nad adaptacją APET dla czterech kolejnych linii silnikowych, co zajęło nam następne dwa miesiące. W końcu w marcu 2017 szeroka wersja APET dla sześciu programów została przekazana potencjalnym użytkownikom końcowym - i cieszyła się bardzo dobrym odbiorem. 

Plany na przyszłość

Prace nad aplikacją będą z pewnością kontynuowane ze względu na perspektywy jej rozwoju i pozostały backlog. Najprawdopodobniej - w udoskonalonym kształcie -  zostanie wprowadzona na środowisko produkcyjne.

Podsumowanie

Aplikacja APET w dzisiejszym kształcie tworzona była przez trzy osoby w okresie pół roku. Gdyby została wdrożona, zaoszczędziłaby godziny pracy inżynierów i usprawniła proces analizy danych silnikowych. Dzięki niej praca nad analizą będzie elastyczna i interaktywna. Możliwe też stanie się porównywanie parametrów pomiędzy silnikami. Bycie częścią tego trzyosobowego zespołu wspominam jako prawdziwą przyjemność. 

Zobacz kogo teraz szukają