Wymiary architektury systemów sterowania o otwartej architekturze
Kluczowym pomysłem podczas implementacji koncepcji systemu sterowania o otwartej architekturze jest dekompozycja funkcji tradycyjnych rozwiązań (zamkniętych układów sterowania) na cały szereg niezależnych modułów. Moduły te, realizujące w całości wszystkie funkcje regulatorów tradycyjnych – mają zunifikowane interfejsy współpracy ze światem zewnętrznym – mogą być przy tym opracowywane niezależnie przez różnych użytkowników/projektantów. Moduły te nazywane są komponentami systemu sterowania o otwartej architekturze.
Bazując na pojęciu komponentów architektury systemu sterowania, architektury SSOA mogą zostać zamodelowane w uniwersalny sposób poprzez określenie:
- komponentów: opisów ich typów, interfejsów, zachowania, sposobu łączenia komponentów w większą całość (agregacji);
- mechanizmów i metod interakcji pomiędzy komponentami systemu;
- interakcji pomiędzy komponentami a platformą: opisów interfejsów i mechanizmów interakcji pomiędzy komponentami a platformą. Platformą nazywa się tutaj całe środowisko, w ramach którego uruchamiane są komponenty. W ogólności platforma składa się z rozmaitych API (interfejsów implementacji aplikacji) związanych z działaniem oraz rozwojem systemu;
- konfiguracji: rozumianej jako metodyka tworzenia całej aplikacji z użyciem poszczególnych komponentów. Konfiguracja dzieli się na dwa główne etapy: konfiguracji statycznej i konfiguracji dynamicznej. Konfiguracja statyczna polega na połączeniu komponentów aplikacji systemu z interfejsami każdego z komponentów. Na konfigurację dynamiczną składają się: zarządzanie uruchamianiem, wykonywaniem oraz wychodzeniem z realizacji zadań, wykonywanych przez cały system aplikacji.
Opierając się na przedstawionej koncepcji, na wymiary architektury składać się mogą:
- sposób implementacji zestawu funkcjonalności,
- komponenty systemu,
- interakcje pomiędzy komponentami,
- interakcje pomiędzy komponentami a platformą,
- konfiguracja systemu.
Implementacja funkcjonalności systemu
System sterowania o otwartej architekturze może być opisywany poprzez rozmaite poziomy abstrakcji (zestawy sposobów implementacji funkcji systemu sterowania). Poziomy te sklasyfikować można następująco:
- poziom modelu: określa koncepcję modelu SSOA. Definiuje głównie funkcje realizowane przez komponenty systemu. Definicje składające się na ten poziom są niezależne od dziedziny zastosowań oraz sposobu implementacji systemu;
- poziom aplikacji: definiuje interfejsy komponentów zgodnie z wymaganiami stawianymi w przypadku konkretnej dziedziny zastosowań. Definicje składające się na ten poziom są niezależne od wybranej implementacji;
- poziom implementacji: określa sposób realizacji komponentów systemu sterowania.
Komponenty
Na ten wymiar architektury systemów sterowania o otwartej architekturze składają się typy, interfejsy, zachowania (sposób działania) oraz poziom rozdrobnienia elementów składowych systemu sterowania. Składają się na niego:
- typy: komponent łączący (LC – Linkable Component), komponent wykonywalny (EC – Executable Component);
- interfejsy: interfejs zmiennych (VI – Variable Interface), interfejs komunikatów (MI – Message Interface), interfejs funkcji (FI – Function Interface), interfejs obiektów (OI – Object Interface);
- zachowania/działania: jawna implementacja (EI – Explicit Implementation) oraz domniemana/niejawna implementacja (II – Implicit Implementation);
- rozdrobnienie systemu: wysoki stopień rozdrobnienia systemu (FG – Fine Granularity), niski stopień rozdrobnienia systemu (CG – Coarse Granularity).
Interakcje pomiędzy komponentami mogą występować na różnym poziomie: kompilacji, komunikacji, wywoływania procedur, maszyny wirtualnej.
Interakcje pomiędzy komponentami a platformą podzielić można na dwa poziomy: z niezdefiniowanym interfejsem dla danej platformy oraz ze zdefiniowanym interfejsem dla platformy, na której uruchamiane są komponenty systemu.
Konfiguracja systemu sterowania może być sklasyfikowana na trzy różne sposoby:
- nierekonfigurowalny,
- rekonfigurowalny statycznie: system aplikacji może zostać przekonfigurowany jedynie na etapie konfiguracji statycznej,
- rekonfigurowalny dynamicznie: system aplikacji może zostać zmieniony nie tylko na etapie konfiguracji statycznej, ale również podczas konfiguracji dynamicznej.
Zależności pomiędzy wymiarami architektury a wymaganiami stawianymi systemom sterowania
Ocena punktowa odpowiednich wymiarów wymagań, stawianych systemom sterowania, może dostarczyć cennych wskazówek podczas wyboru rodzaju systemu sterowania dla opracowywanej aplikacji. Korzystając z tabel od 8 do 12 użytkownik może indywidualnie określić zależności pomiędzy wymiarami architektury a wymiarami wymagań. Podczas wypracowywania przestrzeni ewaluacyjnej należy zwrócić szczególną uwagę na fakt, iż niektóre wymiary architektury nie wiążą się wprost z określonymi wymiarami wymagań – takie zależności w tabelach oznaczone są symbolem X.
Ewaluacja kilku spotykanych współcześnie systemów sterowania o otwartej architekturze
W tabeli 13 przedstawiono kilka wybranych, opracowanych (w stopniu pozwalającym na efektywną implementację) współcześnie, systemów sterowania o otwartych architekturach: NGC, OSACA, OMAC oraz OSEC. W tabeli tej przedstawiono cechy charakterystyczne oraz komponenty, jakie składają się na daną architekturę. Korzystając z pojęcia przestrzeni ewaluacyjnej, w kolejnej tabeli możliwe jest dokonanie oceny porównawczej opisanych w tabeli 13 systemów. Korzystając z tych dwóch tabel (jak również innych, przedstawionych w niniejszym artykule) użytkownicy będą mogli dokonać ewaluacji branych przez siebie pod uwagę podczas wyboru konkretnego rozwiązania systemów sterowania.
Niniejsze opracowanie pozwala na przeprowadzenie całościowej oceny porównywanych struktur otwartych systemów sterowania – jeżeli użytkownik dokona innego przyporządkowania odpowiednich wag podczas ewaluacji, wtedy z jego punktu widzenia klasyfikacja może wyglądać nieco inaczej. Przedstawione narzędzia mają charakter uniwersalny i z powodzeniem mogą być stosowane również dla innych systemów sterowania.
Na podstawie zebranych w powyższych tabelach informacji można wysnuć następujące kluczowe wnioski o porównywanych systemach sterowania o otwartej architekturze:
- architektura NGC, dostarczająca pełnego opisu interakcji pomiędzy komponentami a platformą, została obecnie poprawiona – w tej architekturze niestety nie ma wygodnych metod konfiguracji systemu;
- funkcjonalność architektura OSACA i OMAC jest podobna. Oba te rozwiązania dostarczają wygodnych narzędzi konfiguracji systemu. Z drugiej strony, nie definiują interakcji pomiędzy komponentami a platformą. Dodatkowo, standard opracowany przez OMAC opisuje tak funkcje komponentów w znacznie dokładniejszy aniżeli OSACA sposób;
- z powodu wielu niezdefiniowanych wymiarów architektury trudno jest poddać syntetycznej ocenie standard OSEC. Ponieważ każdy z wymiarów wymagań ma swoje znaczenie, porównanie systemów sterowania o tej architekturze w każdym z wymagań.
Dodatkowo możliwe jest poczynienie następujących spostrzeżeń:
- regulator NGC będzie lepszy w kwestii dziedziny możliwych zastosowań. Dzieje się tak z powodu architektury sterownika;
- pod względem spełnienia wymogu otwartości, architektury OSACA i OMAC są lepsze; obie dostarczają efektywnych metod konfiguracji systemu;
- OSACA i OMAC są lepsze również pod względem możliwości współpracy pomiędzy modułami; szczegółowo definiują interfejsy zachowań komponentów;
- system o architekturze NGC jest lepszy pod względem możliwości przenoszenia modułów pomiędzy platformami; dzieje się tak z uwagi na kompletny opis interakcji pomiędzy komponentami a platformą;
- architektura NGC jest lepsza od pozostałych również pod względem standaryzacji interfejsów; definiuje wiele rodzajów standardów zewnętrznych interfejsów;
- architektura OMAC jest stosunkowo prosta w implementacji; szczegółowo definiuje interfejsy wszystkich komponentów;
- wszystkie te systemy mają jednak podstawową wadę, żadna z architektur nie dostarcza efektywnej metody dla spełnienia wymogów działania aplikacji pod rygorem czasu rzeczywistego – jest to współcześnie indywidualna sprawa inżynierów, realizujących systemy sterowania zgodnie z jedną ze wspomnianych architektur.
Przestrzeń ewaluacyjna może zostać zastosowana również podczas opracowania nowej koncepcji systemu sterowania o otwartej architekturze:
- podczas procesu projektowania systemu przestrzeń ewaluacyjna może posłużyć do porównania kilku koncepcji, celem wyboru wersji optymalnej;
- podczas ewaluacji opracowanej koncepcji systemu sterowania – posłuży wtedy do porównania różnych układów sterowania, obnażając wady i uwypuklając najważniejsze zalety układu.
Podsumowując, zaprezentowana idea przestrzeni ewaluacyjnej została zaprezentowana i użyta do porównania kilku znanych architektur SSOA. Po przeprowadzeniu tejże ewaluacji nasuwa się bardzo istotny wniosek: istniejące obecnie na rynku systemy sterowania o otwartej architekturze nie mają optymalnej struktury – mają swoje wady i zalety – to od użytkownika zależy, co takie SSOA potraktuje za wadę, a co za zaletę.
Artykuł pod redakcją dr inż. Krzysztofa Pietrusewicza
Komentarz redakcji
Metody przedstawione w niniejszym artykule, choć związane ściśle z ewaluacją systemów sterowania o otwartej architekturze, stosowanych do sterowania obrabiarkami sterowanymi numerycznie CNC, mogą zostać z powodzeniem zastosowane podczas ewaluacji dowolnego systemu sterowania. Dodatkowo, poza wymienionymi w artykule SSOA, jak NGC, OMAC, czy OSACA, na rynku obecnie dostępnych jest wiele rozwiązań firmowych. Więksi producenci związani są poprzez uczestnictwo w komitetach i grupach roboczych wokół takich organizacji jak np. OMAC, implementując w swoich rozwiązaniach większość zaleceń opracowanych przez te organizacje standardów i zaleceń – ciekawym doświadczeniem dla potencjalnego użytkownika mogłoby być przeprowadzenie takiej ewaluacji dla tychże firmowych rozwiązań.
