Zespół wspierający firmę DOVISTA Polska na drodze cyfrowej transformacji

Wymóg ciągłego rozwoju oprogramowania wymusił sięgnięcie po zestaw metod oraz praktyk z obszarów, które do tej pory nie były stosowane w zarządzaniu procesami produkcyjnymi czy projektami w ogóle w firmach produkcyjnych. Agile, czyli zwinna metodyka prowadzenia projektów, pozwala na pracę w kilkutygodniowych okresach (sprintach), w czasie których realizowane są zdefiniowane zadania. Umożliwia to efektywne rozwijanie aplikacji zgodnie z wymaganiami zamawiającego w każdej potrzebnej warstwie.

Na kompletny system na miarę Przemysłu 4.0 składają się trzy główne warstwy:

1. Warstwa percepcji, czyli poziom urządzeń gromadzących dane.
2. Warstwa transportowa stanowiąca most pomiędzy filarem percepcji oraz użytkownikiem (np. sieć LAN).
3. Warstwa aplikacji, która umożliwia bezpośredni kontakt z odbiorcą.

Ostatni filar, czyli zaprojektowanie odpowiednich aplikacji, firma DOVISTA powierzyła zespołowi ImFactory, którego zadaniem było opracowanie projektu architektury i oprogramowania oraz wsparcie w ciągłym rozwoju systemu. Głównymi wymaganiami stawianymi aplikacji były niezależność od technologii i wieloplatformowość.

Postawiono na rozwiązania Webowe, które można uruchomić na każdym rodzaju urządzeń. Aplikacje są opublikowane na serwerach lokalnych, dzięki czemu nawet w przypadku braku połączenia z Internetem, możliwe jest ich użytkowanie – to kluczowy aspekt w przypadku rozwiązań stosowanych w przemyśle.

W firmie DOVISTA głównym źródłem informacji jest System SAP. Potrzeba kontrolowania integracji wielu aplikacji oraz chęć śledzenia przebiegu produkcji w odzwierciedlonym modelu MES, zawiesiły wysoko poprzeczkę dla systemu integracyjnego. Istnieje wiele aplikacji, które oferują jednokierunkowe wysyłanie danych bez informacji zwrotnej, jednak takie rozwiązanie jest niewystarczające w rozbudowanych systemach.

Wybór padł na Enterprise Integrator. To stabilne oprogramowanie, które pozwala na integrację wielu systemów – począwszy od produkcyjnych aż po systemy typu ERP. Wyposażone jest w mechanizm typu Store&Forward, czyli lokalne gromadzenie informacji i przesłanie ich dalej na serwer. Dzięki temu zapewnia większe możliwości, niż jednokierunkowe wysyłanie danych.

Rys. 1. Schemat przepływu danych

Pochodzące z systemu SAP dane, po odpowiedniej agregacji, gromadzone są w bazie danych systemu MES. Najważniejszym założeniem dla danego środowiska jest wykorzystywany model relacyjny. W bazie dostępny jest zbiór tabel, w których zapisywane są informacje o danym typie, określane mianem encji. Różnorodność tabel, możliwość rozbudowywania struktury bazy, tworzenie nowych obiektów czy procedur stwarza nieograniczone możliwości rozwoju.

Konieczność wykorzystania języka DML (ang. Data Manipulation Language), czyli typu składni umożliwiającej wybieranie, umieszczanie oraz modyfikację elementów w bazie bezpośrednio w obiektach bazodanowych, jest skomplikowane oraz mało reprezentatywne. Rozwiązaniem są aplikacje komputerowe, mobilne oraz internetowe, odbierające surowe dane i prezentujące je zgodnie z oczekiwaniami klienta.

Każda z przygotowanych aplikacji opiera się na strukturze zaprezentowanej na rysunku 2.

Możemy wyróżnić dwa główne elementy: back-end (baza danych i logika biznesowa) oraz front-end (interfejs użytkownika).

Rys. 2. Struktura aplikacji

Ważną częścią jest Web Service, który umożliwia przepływ danych w sieci pomiędzy bazą danych a aplikacją internetową. Web Service to usługa sieciowa stanowiąca warstwę abstrakcji, która posługuje się zbiorem określonych standardów wymiany danych. Aplikację zrealizowano w oparciu o najnowsze biblioteki Microsoft .NET Framework. Zastosowana została również warstwowa architektura aplikacji (Onion Architecture Layers).

Taka struktura pozwala odseparować poszczególne poziomy od siebie, co ułatwia kontrolowanie kodu, pozwala szybko zlokalizować oraz wyeliminować błędy i, co najważniejsze, zapewnia dużą stabilność systemu, który dzięki temu jest zamknięty na modyfikacje, ale otwarty na rozszerzenia.

Celem tego typu architektury jest przede wszystkim wydzielenie czterech głównych płaszczyzn, powiązanych referencjami:

• Core/Domain – to centralny punkt projektu, który odpowiada za przechowywanie obiektów. Wykorzystuje strukturę typu ORM (ang. Object-Relational Mapping), czyli sposób mapowania, bądź rzutowania obiektów informatycznych na obiekty bazodanowe przy zachowaniu odpowiednich relacji. Projekt zawiera interfejsy niezbędne do implementacji repozytoriów.
• Infrastructure – to obszar złożony z dwóch podwarstw (serwisów oraz repozytoriów). Warstwa repozytorium jest pewnego rodzaju płaszczyzną abstrakcji. Łączy ona omówioną wcześniej powierzchnię z główną logiką biznesową. Zadaniem repozytorium jest odpytanie bazy danych o ich dostępność, wydobycie ich oraz zmapowanie do logiki biznesowej. Takie podejście określane jest mianem jednego ze wzorców projektowych (ang. Repository pattern). Warstwa serwisu implementuje interfejsy odpowiedzialne za komunikację międzywarstwową.
• UI (User Interface) – to warstwa kontaktu z użytkownikiem. Najczęściej tworzy ją aplikacja internetowa oraz projekt Web API, przechowujący kontrolery, odpowiedzialne za wystawienie danych z niższych warstw do klienta.

Rys. 3. Warstwowa architektura aplikacji

Przestrzeń wizualną warstwy aplikacyjnej oprogramowano, poprzez stworzenie odpowiednich kontenerów, tak aby logika była odseparowana. Zostały do tego wykorzystane najnowsze biblioteki javascriptowe, takie jak np. React, który swoją strukturę opiera na komponentach. Zastosowane elementy umożliwiają podział interfejsu użytkownika na niezależne, pozwalające na ponowne użycie, części. To bardzo istotne, ponieważ pomimo tego, że aplikacje różnią się pod względem tematycznym, jesteśmy w stanie osadzać moduły, które wcześniej przygotowaliśmy.

Stworzona warstwa wizualna jest zgodna z zasadami RWD (ang. Responsive Web Design). Programiści tworzący strony www, skupiają się nad tym, by były one proste i możliwe w użytkowaniu zarówno z wykorzystaniem myszki, jak i palca w przypadku ekranu smartphona czy tabletu. Dodatkowo, strony są przygotowywane w taki sposób, aby najmniejsze klikalne elementy nie miały mniej niż 40 px.

Układ elementów może się zmieniać w zależności od orientacji ekranu oraz rozdzielczości – zaprezentowano to na rysunku 4. Komponenty odpowiednio się przeskalowują, mogą się również reorganizować, tak aby wykorzystać całe dostępne miejsce, jakie oferuje ekran tabletu, komputera bądź telefonu.

Rys. 4. Przykład aplikacji responsywnej (rozmieszczenie elementów na stronie w zależności od rozdzielczości i orientacji)

Zrealizowaną w ramach projektu aplikacją, która w pewnym sensie łamie przedstawione wyżej standardy, jest program E-dokumenty. To system dla operatorów pracujących na liniach produkcyjnych. Dane wyświetlane na tabletach dotyczą szczegółowych informacji technologicznych wraz z dedykowanymi opisami dla poszczególnych operacji. Ponieważ w bazie MES znajdują się dane umożliwiające śledzenie produkcji, nie ma potrzeby przechowywania dodatkowych informacji na temat np. wymiarów danych elementów z rysunkami technicznymi.

Ponieważ głównym źródłem informacji jest SAP, opisane wyżej dane również są w niej uwzględnione. Dostarczenie ich bezpośrednio do aplikacji E-papier odbywa się w specyficzny, a zarazem uniwersalny sposób, który pozwala na odseparowanie aplikacji dla korzystających z niej działów. Dzięki temu wyjątki poszczególnych lokalizacji nie wpływają na działanie całego systemu.

System SAP, w ramach zlecenia produkcyjnego generuje pliki XML (tzw. IDOC). Znajdują się w nich wszystkie niezbędne informacje, dotyczące wybranego okna z podziałem na jego poszczególne części, z wymiarami i odniesieniami do dokumentacji w formacie pdf.

Dla każdej lokalizacji stworzone zostały odpowiednie translatory, które pozwalają wyciągnąć tylko te informacje, które są potrzebne dla danego obszaru. Do stworzenia spersonalizowanych dokumentów wynikowych wykorzystywany jest najpopularniejszy język przekształceń XML, a konkretnie XSLT (ang. XSL Transformations, Extensible Stylesheet Language Transformations).

Aplikacja dobiera odpowiedni translator w zależności od tego, na jakiej lokalizacji została uruchomiona. W efekcie np. obszar zajmujący się wytwarzaniem listewek nie widzi elementów związanych z zasuwnicami. Co więcej, operator ma udostępnione tylko te elementy, które powinien wykonywać w ramach zlecenia, nie musi więc przechodzić przez wszystkie materiały uwzględnione w dokumentach z SAP-a.

Numery rysunków uwzględnione w pliku XML pomagają w pobraniu odpowiednich plików pdf znajdujących się na serwerze. Do wyświetlania dokumentów użyto biblioteki pdf.js, która zapewnia wsparcie na aplikacjach tabletowych, a także jest w pełni responsywna, oferuje też narzędzia niezbędne do pracy z tego typu plikami. Każda z aplikacji posiada wbudowane wsparcie językowe, co może być znacznym ułatwieniem dla operatorów w ich codziennej pracy.

Stworzenie unikatowego języka, który jest zrozumiały w określonym środowisku, wymaga nie tylko interdyscyplinarnej wiedzy. Potrzebne są również takie cechy jak umiejętność słuchania, współpracy czy sprawnej komunikacji. To wszystko, zamienione na cyfrowy kod językowy, pozwala tworzyć coraz bardziej zaawansowane architektonicznie systemy i prowadzi do optymalizacji i lepszego planowania produkcji.

Wdrożone w firmie DOVISTA rozwiązania, nie tylko usprawniają produkcję, ale również przyczyniają się do ratowania planety. Więcej na ten temat przeczytasz w artykule: Transformacja cyfrowa sposobem na ratowanie planety – historia sukcesu DOVISTA Polska

Zapraszamy również do wysłuchania podcastu, w którym Piotr Bielkiewicz z DOVISTA opowiada do drodze do cyfryzacji: Cyfrowa Fabryka. Czyli jaka? Historia o tym, jak w cyfrowej transformacji zachować zdrowy rozsądek