Zespół, który pomaga firmie DOVISTA Polska ratować planetę

Projekt cyfryzacji procesów produkcyjnych w firmie DOVISTA miał wiele wymiarów i kilka konkretnych założeń. Także z perspektywy zespołu, który od samego początku wspierał transformację w fabryce drzwi i okien. Zbudowany na potrzeby projektu interdyscyplinarny zespół przede wszystkim zbadał wymagania, jakie system miał spełniać.

Stąd kluczowym etapem budowania systemu informatycznego było powołanie lidera projektu odpowiedzialnego za koordynację pracy grupy, przydzielanie zadań oraz kontakt z kierownikiem projektu od strony zamawiającego oraz przeprowadzonej wspólnie analizy biznesowej kluczowych potrzeb klienta.

Tocząca się w kosmicznie szybkim tempie globalna transformacja w zakresie stosowania cyfrowych rozwiązań dla fabryk i zakładów produkcyjnych dotarła także do Polski. I choć daleko nam do zaawansowanych krajów, to jednak coraz częściej i coraz bardziej świadomie

firmy produkcyjne sięgają po rozwiązania usprawniające i optymalizujące ich pracę.

Agile w służbie utrzymania efektywności procesów

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 kilku tygodniowych okresach (sprintach), w czasie których realizowane są zdefiniowane zadania. Pozwala to efektywnie rozwijać aplikację zgodnie z wymaganiami Zamawiającego/Użytkownika w każdej potrzebnej warstwie.

System na miarę Przemysłu 4.0

Mówiąc o kompletnym systemie na miarę Przemysłu 4.0, mamy na myśli trzy główne warstwy:

  • warstwa percepcji – poziom urządzeń, które gromadzą dane
  • warstwa transportowa – most pomiędzy filarem percepcji oraz użytkownikiem np. sieć LAN oraz
  • warstwa aplikacji – odpowiedzialna za bezpośredni kontakt z odbiorcą.
Nowe technologie wspierają rozwój wielu przedsiębiorstw

Rozwiązania MES jako krok do cyfrowej transformacji

Ostatni filar został powierzony zespołowi MES Solutions by ASTOR, który podjął się zaprojektowania architektury, oprogramowania oraz ciągłego rozwoju systemu. Głównymi wymaganiami stawianymi aplikacji były wieloplatformowość oraz niezależność od technologii. Postawiono na rozwiązania Webowe, które jesteśmy w stanie uruchomić na każdym rodzaju urządzeń. Aplikacje są opublikowane na serwerach lokalnych, co sprawia, że nawet w przypadku braku połączenia do Internetu, możliwe jest użytkowanie aplikacji. A jest to kluczowy aspekt w przypadku aplikacji stosowanych w przemyśle.

Tłumacz symultaniczny i integrujący różne systemy w jednym?

W przypadku projektu w DOVISTA, głównym źródłem informacji jest System SAP. Potrzeba kontrolowanej integracji wielu aplikacji oraz chęć śledzenia przebiegu produkcji w odzwierciedlonym modelu MES, zawiesiły wysoko poprzeczkę dla systemu integracyjnego. Wiele aplikacji oferuje jednokierunkowe wysyłanie danych bez informacji zwrotnej. W rozbudowanych systemach jest to niewystarczające.

Postawiono na stabilne rozwiązanie Enterprise Integrator. Oprogramowanie pozwala na integrację wielu systemów począwszy od produkcyjnych aż po systemy typu ERP. Narzędzie wyposażone jest w mechanizm typu Store&Forward (lokalne gromadzenie informacji i przesłanie ich dalej na serwer). Oferuje większe możliwości, niż jednokierunkowe wysyłanie danych.

Dane pochodzące z systemu SAP, po odpowiedniej agregacji, gromadzone są w bazie danych MES. Głównym założeniem dla danego środowiska jest wykorzystywany model relacyjny. Baza oferuje zbiór tabel, w których zapisywane są informacje o danym typie, co określa się mianem encji. Różnorodność tabel oraz możliwość rozbudowywania struktury bazy, tworzenie nowych obiektów, procedur stwarza nieograniczone możliwości rozwoju.

Konieczność wykorzystania języka DML (Data Manipulation Language), czyli typu składni umożliwiającego wybieranie, umieszczanie oraz modyfikację elementów w bazie bezpośrednio 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.

Skomplikowane?

Każda z przygotowanych aplikacji opiera się na strukturze, którą zaprezentowano na rysunku 2. Aplikacja składa się z dwóch głównych elementów: back-end (baza danych i logika biznesowa) oraz front-end (interfejs użytkownika).

Ważnym elementem jest Web Service, który umożliwia przepływ danych w sieci pomiędzy bazą danych a aplikacją internetową. Web Service to nic innego jak usługa sieciowa, czyli pewna warstwa abstrakcji, posługująca się zbiorem określonych standardów wymiany danych. Zrealizowano aplikację opierając się na najnowszych bibliotekach Microsoft .NET Framework.

Zastosowano także warstwową architekturę aplikacji (Onion Architecture Layers). Przedstawiona struktura pozwala odseparować poszczególne poziomy od siebie, co ułatwia kontrolowanie kodu, pozwala szybko zlokalizować oraz wyeliminować błędy oraz, co najważniejsze, zapewnia wysoką stabilność systemu, który jest zamknięty na modyfikacje, ale otwarty na rozszerzenia.

Warstwy architektury systemu – informatyka w służbie przemysłu

Głównym celem tego typu architektury jest wydzielenie czterech głównych płaszczyzn powiązanych referencjami:

  • Core/Domain – punkt centralny projektu, odpowiedzialny za przechowywanie obiektów, wykorzystujący strukturę typu ORM (Object-Relational Mapping), czyli sposób mapowania, bądź rzutowania obiektów informatycznych na obiekty bazodanowe zachowujący odpowiednie relacje. Projekt zawiera interfejsy niezbędne do implementacji repozytoriów.
  • Infrastructure – obszar składający się z dwóch podwarstw (serwisów oraz repozytoriów). Warstwa repozytorium to pewna płaszczyzna abstrakcji, która łączy wcześniej omówioną powierzchnię z główną logiką biznesową. Repozytorium ma za zadanie odpytanie bazy danych o ich dostępność, wyciągnięcie ich oraz zmapowanie ich do logiki biznesowej. Takie podejście określane jest mianem jednego ze wzorców projektowych (Repository pattern). Warstwa serwisu implementuje interfejsy odpowiedzialne za komunikację międzywarstwową.
  • UI (User Interface) – warstwa kontaktu z użytkownikiem, najczęściej jest to aplikacja internetowa oraz projekt Web API przechowujący kontrolery, odpowiedzialne za wystawienie danych z niższych warstw do klienta.

Jak to działa? Łatwo i przyjemnie/ intuicyjnie

Przestrzeń wizualną warstwy aplikacyjnej oprogramowano, tworząc odpowiednie kontenery tak, by logika była odseparowana. Wykorzystano najnowsze biblioteki javascriptowe m.in. React, który swoją strukturę opiera na komponentach. Elementy umożliwiają podział interfejsu użytkownika na niezależne, pozwalające na ponowne użycie części. Jest to bardzo istotne, ponieważ pomimo różnych tematycznie aplikacji jesteśmy w stanie osadzać moduły, które wcześniej przygotowaliśmy.

Stworzona warstwa wizualna jest zgodna z zasadami RWD (Responsive Web Design). Programiści tworząc strony WWW, skupiają się nad tym, by strona była bardzo prosta i możliwa w użytkowaniu zarówno z wykorzystaniem myszki, jak i palca w przypadku ekranu smartphona czy tabletu. Dodatkowo, strony internetowe są tak przygotowane, by najmniejsze elementy klikalne nie miały mniej niż 40 px.

Układ elementów zmienia się w zależności od orientacji ekranu oraz rozdzielczości, co prezentuje rys. 4. Komponenty odpowiednio przeskalowują się, może również nastąpić ich reorganizacja, tak by wykorzystać całe dostępne miejsce, jakie oferuje ekran tabletu, komputera bądź telefonu.

A jeśli są inne potrzeby do zaadresowania?

Zrealizowaną aplikacją, która poniekąd łamie standardy przedstawione powyżej jest program E-dokumenty. To system wykorzystywany przez operatorów na liniach produkcyjnych. Dane wyświetlane na tabletach dotyczą szczegółowych informacji technologicznych wraz z dedykowanymi opisami dla poszczególnych operacji. Z racji tego, iż w bazie MES są dane umożliwiające śledzenie produkcji, nie ma konieczności przechowywania dodatkowych informacji na temat np. wymiarów poszczególnych elementów wraz z rysunkami technicznymi umożliwiającymi ich kompletację.

W związku z tym, że SAP jest głównym źródłem informacji, to również dane, które zostały opisane powyżej 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 poszczególnych działów, które z niej korzystają, a co za tym idzie, wyjątki poszczególnych lokalizacji nie wpływają na działanie całego systemu.

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

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

Aplikacja wybiera odpowiedni translator w zależności od tego, na jakiej lokalizacji została uruchomiona, dzięki czemu np. obszar zajmujący się wytwarzaniem listewek nie zobaczy elementów związanych z zasuwnicami. Co więcej, operator widzi tylko te elementy, które powinien wykonywać w ramach zlecenia, nie musi przechodzić przez wszystkie materiały, które uwzględnia dokument z SAPa.

Numery rysunków uwzględnione w pliku XML służą do pobrania odpowiednich plików pdf, które znajdują się na serwerze. Do wyświetlania dokumentów wykorzystano bibliotekę pdf.js, która zapewnia wsparcie na aplikacjach tabletowych, jest w pełni responsywna oraz oferuje narzędzia niezbędne do pracy z tego typu plikami. Biorąc pod uwagę fakt, iż aplikacje są używane w kilku państwach, każda z nich posiada wbudowane wsparcie językowe, co ułatwia operatorom pracę z narzędziem.

Aplikacje mobilne dla przemysłu 4.0 – to działa!

A zatem stworzenie unikatowego języka, który jest zrozumiały w określonym środowisku, wymaga nie tylko interdyscyplinarnej wiedzy. Potrzebne jest coś więcej. Umiejętność słuchania. Współpracy. Sprawnej komunikacji. To wszystko, zamienione na cyfrowy kod językowy, pozwala tworzyć coraz bardziej zaawansowane architektonicznie systemy i prowadzi do usprawnień w zakresie produkcji i lepsze jej planowanie.

Jacek Daukszewicz, Szymon Firlinger

<p>Udostępnij</p>Share on Facebook
Facebook
0Share on LinkedIn
Linkedin

Opublikuj

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *