10 porad: integracja w dobie IT

Integrowanie maszyn, sprzętu produkcyjnego i ich systemów sterowania z systemami wyższego poziomu nie zawsze jest łatwe, również w kontekście IT. Można jednak zminimalizować rozmaite poziomy ryzyka, stosując się do porad osób, które niejedno już w zakładach przemysłowych w tej kwestii przeżyły i widziały?

Jednym z takich fachowców jest Dennis Brandl, specjalista od IT w branży produkcyjnej. Wyróżnił on dziesięć głównych zagadnień związanych z IT, którym warto poświęcić szczególną uwagę, zajmując się procesami integracyjnymi.

1. JęzykUMLi diagramy sekwencji ? łatwo konwertowane na kod wykonywalny

Kombinacja modeli stanu, diagramów przypadków użycia (Use Case Diagrams ? UCD) oraz diagramów sekwencji definiuje logikę wewnętrzną i zachowanie systemu UML (zunifikowanego języka modelowania ? Unified Modeling Language), w tym odpowiedź systemu na warunki normalne i odbiegające od normalnych. Po połączeniu diagramów stanów, diagramów UCD i diagramów sekwencji z diagramami klasy UML otrzymujemy kompletną definicję systemu, który może być łatwo zrozumiany przez osoby nieznające się na programowaniu oraz błyskawicznie przekształcony na kod wykonywalny. UML jest językiem inżynierii oprogramowania, jaki wszyscy inżynierowie automatycy powinni rozumieć i wykorzystywać w swoich specyfikacjach oraz projektach.

2. Zrozumienie języka UML ? ważna część zestawu narzędzi

Rozwijanie systemu sterowania wymaga wymiany informacji pomiędzy wieloma osobami i systemami. Język UML może pomóc w uwydatnianiu niezgodności, usuwaniu niejednoznaczności oraz dostarczaniu standardowej drogi komunikacji informacji dotyczących projektu.

Diagram klas w UML dla urządzenia kartonującego. Dzięki jego wykorzystaniu możliwa jest redukcja całych stron tekstu do kilku prostych diagramów, na których łatwiej rozpoznać wzorce. Przykład pokazuje, że w kartoniarce zamontowano sterownik PLC z odpowiednim programem, zawierającym dane autora, numer wersji i inne informacje, z wykorzystaniem czujnika awarii. (Źródło: Control Engineering)

3. Złe nawyki inżynierów automatyków

Kiedy wykorzystujemy system z plikami współdzielonymi do zarządzania dokumentami projektowymi, dbajmy o to, by nie nabierać złych nawyków.

-> Podaj temat! Nazwa pliku i nazwa folderu są często jedynymi wskazówkami odnośnie zawartości dokumentu.

-> Nie twórz niepotrzebnych wersji. Niełatwo przeglądać system z plikami współdzielonymi i szybko sprawdzać treść dokumentu, podobnie jak trudno śledzić wiele wersji dokumentu.

-> Określ, jaki jest status dokumentu. Czy to wstępny szkic, czy dokument zatwierdzony, poprawiany, oczekujący na sprawdzenie lub znajdujący się na jakimś innym etapie?

-> Pamiętaj, że w systemie z plikami współdzielonymi brak funkcjonalności check-out (pobranie ? plików z serwera z zamiarem ich zmiany) i check-in (wstawianie ? zmienionych plików na serwer w celu udostępnienia ich wszystkim użytkownikom).

4. Siedem dróg do nieudanych projektów

Jeśli w naszym projekcie dostrzegamy trzy lub więcej z poniższych elementów, znaczy to, że znaleźliśmy się właśnie na najlepszej drodze do konieczności jego restartu, czyli podjęcia prac ponownie niemal od zera:

1. Nie ma architekta lub zespołu architektów.

2. Nie ma solidnego harmonogramu.

3. Harmonogramy są przechowywane w postaci arkuszy kalkulacyjnych.

4. Osoby zarządzające projektem prezentują mentalność w rodzaju ?porażka nie wchodzi w grę?.

5. Nie ma zarządzania konfiguracją lub kontroli źródła dokumentów czy kodu.

6. Nie wykonano oceny dokumentacji, testów czy kodu.

7. Dokumenty projektowe i testowe nie zostały zaktualizowane.

5. Czy dokumentacja pokrywa się z kodem?

Jak widać, nieaktualizowanie dokumentów użytkownika, projektowych oraz testowych, dotyczących projektu inżynieryjnego trafiło na listę siedmiu dróg do nieudanych projektów, sporządzonej w punkcie 4. Pamiętajmy jednak, że wprawdzie umniejszy ono użyteczność prac inżynierskich lub ich postrzeganą wartość, jednak w rzeczywistości stanowi nie tyle problem inżynierski, ile zły nawyk osób zarządzających projektem. Daje o sobie znać, gdy dokumenty nie pokrywają się z systemem, który ma być przetestowany lub dostarczony klientowi.

6. Zła dokumentacja projektowa

Myślisz, że prowadzony przez Ciebie projekt związany z informatyką w produkcji, automatyką lub systemem sterowania dobiegł szczęśliwego końca? Lepiej ponownie sprawdź dokumentację! Po co? Jeśli jest błędna, źle napisana lub niekompletna, może wprowadzać chaos w eksploatacji stworzonego systemu, czyli doprowadzić do jednej z najgorszych sytuacji związanych z integracją.

Modele stanu w UML to rozszerzona wersja modeli matematycznych systemów dynamicznych, które są diagramami zawierającymi stany i zdarzenia. Przykład pokazuje prosty model zagnieżdżony dla pewnej maszyny.? Modele stanu w UML to rozszerzona wersja modeli matematycznych systemów dynamicznych, które są diagramami zawierającymi stany i zdarzenia. Przykład pokazuje prosty model zagnieżdżony dla pewnej maszyny.

7. System MES a system ERP

System planowania zasobów przedsiębiorstwa (Enterprise Resource Planning ? ERP) może wspierać działania związane z zarządzaniem operacjami produkcyjnymi (Manufacturing Operations Management ? MOM), jeśli:

-> obsługiwana jest podstawowa funkcjonalność MOM;

-> system ERP ma mały zasięg ? pokrywający najwyżej kilka fabryk;

-> ERP obsługuje definicje na poziomie zakładowych procedur przepływów roboczych;

-> w razie braku dostępu do systemu produkcja może być kontynuowana przez jedną lub więcej zmian roboczych.

W przeciwnym razie najlepszą odpowiedzią na nasze potrzeby zarządzania operacjami produkcyjnymi może być wdrożenie systemu realizacji produkcji (Manufacturing Execution System ? MES).

8. Trzy filary przemysłowego cyberbezpieczeństwa

Zazwyczaj, aby jakakolwiek struktura fizyczna była stabilna, trzeba ją podeprzeć przynajmniej w trzech punktach. Cyberbezpieczeństwo w przemyśle nie jest wyjątkiem ? jeśli chcemy otrzymać funkcjonalny i działający system, również potrzebujemy wspierających go struktur. Podstawę efektywnego systemu cyber-
bezpieczeństwa tworzą więc trzy filary: technologia, polityka i procedury oraz ludzie.

9. Wirtualna przyszłość informatyki w produkcji

Przyszłością informatyki jest wirtualność! Środowiska informatyczne będą budowane na systemach wirtualizowanych, co obejmie wiele systemów informatycznych wykorzystywanych w produkcji. Systemami tymi będą: bazy danych, programy do archiwizacji danych, programowe interfejsy HMI, programy do harmonogramowania, a nawet sterowniki, które wykorzystujemy w naszych operacjach produkcyjnych. Dzisiejsze systemy wirtualne przybierają wiele form ? od systemów opartych na technologii chmury, dostępnych przez Internet, do tych będących własnością firmową farm serwerów, na których są uruchamiane programy typu hipernadzorca (hypervisor). Korzyści z wirtualizacji dla informatyki w produkcji obejmują: szybciej działające aplikacje, rozruch w skali godzin zamiast miesięcy, większą moc obliczeniową oraz łatwiejsze modernizacje.

10. Czy znasz Prawo Wrighta?

Prawo Wrighta (prawo, zgodnie z którym wraz ze wzrostem produkcji maleje jego koszt, a wraz z rosnącym doświadczeniem pracowników zwiększa się szybkość wykonywanych przez nich działań) zapewnia nam wiarygodne uzasadnienie prób maksymalizacji ponownego użycia technologii i metodologii w projektach oprogramowania oraz budowania kompetencji technologicznych. Z drugiej strony, krzywa motywacji ostrzega przed szufladkowaniem ludzi w specyficznych obszarach, zamykającym szanse ich rozwoju. Balansowanie pomiędzy tymi dwoma współzawodniczącymi ze sobą siłami pozwoli naszym projektom oprogramowania na postępowanie zgodnie z prawem Wrighta, a także na utrzymywanie motywacji wśród zakładowego personelu.

Autor: Dennis Brandl jest prezesem firmy BR&L Consulting, specjalistą od IT w branży produkcyjnej.

Tekst pochodzi ze specjalnego wydania “Integratorzy systemów automatyki 2017?. Jeśli Cię zainteresował, ZAREJESTRUJ SIĘ w naszym serwisie, a uzyskasz dostęp do darmowej prenumeraty w formie drukowanej i/lub elektronicznej.