Dostępne obecnie na rynku systemy sterowania o otwartej architekturze różnią się pod wieloma względami – architekturą, metodyką realizacji, użytymi narzędziami – i pomimo swoich licznych zalet nie są powszechnie akceptowanymi w praktyce przemysłowej rozwiązaniami. Dodatkowo, niewiele jest obecnie publikacji prasowych opisujących czy porównujących funkcjonalność tych systemów. Niniejszy artykuł stanowi próbę wypracowania zestawu kryteriów, którymi użytkownicy będą mogli się kierować przy ewaluacji poziomu otwartości systemów sterowania. Skupiono się tutaj na systemach sterowania obrabiarek sterowanych numerycznie CNC z jednego powodu – stanowią one współcześnie najbardziej złożone dyskretno-ciągłe systemy sterowania układami przemysłowymi. Dzięki opracowaniu zestawu kryteriów oceny poziomu otwartości systemów sterowania użytkownicy bardzo szybko będą mogli wychwycić wady i zalety oferowanych na rynku rozwiązań. Wielokryterialność tejże oceny stanowiła główne założenie niniejszego materiału. Najważniejsze przy tym wydają się wymagania użytkowników stawiane oferowanym systemom sterowania – to oni bowiem mają za zadanie dokonać oceny, a następnie wyboru rozwiązania, które będzie im odpowiadać.
Wprowadzenie
Systemy sterowania o otwartej architekturze stanowią coraz bardziej zauważalny w technologii trend rozwojowy. Zostały opracowane architektury sprzętowo-programowe, różniące się zarówno podejściem do konfiguracji użytego sprzętu, jak i rozwiązaniami w warstwie oprogramowania czy funkcji systemowych.
Jako pierwszy w Stanach Zjednoczonych opracowany został system Next Generation Controller NGC. W Europie organizacja OSACA (Open System Architecture for Control with Automation Systems) zaproponowała swoje oryginalne podejście do tematu otwartej architektury systemu sterowania. Wkrótce nadeszła odpowiedź z Japonii – organizacja OSEC (Open System Environment for Controller) opracowała interfejs aplikacji sterującej (Application Program Interface) – OSEC API. Konsorcjum firm Chrysler, Ford i General Motors powołało do życia organizację użytkowników układów sterowania OMAC (Open Modular Architecture Controls), która w niedługim czasie opracowała OMAC API dla otwartych systemów sterowania. W oparciu o prace OMAC nad swoim API organizacja NIST (National Institute of Standard and Technology) opracowała koncepcję otwartego sterownika maszyn – Enhanced Machine Controller (EMC). Chiński rząd również prowadził prace nad opracowaniem standardu otwartego systemu sterowania numerycznego. Dodatkowo, wiele uniwersytetów i politechnik, jak np. University of British Columbia, University of Michigan czy Shanghai Jiao Tong University, również zaproponowało swoje systemy sterowania o otwartej architekturze.
Spotykane obecnie na rynku otwarte systemy sterowania mają różne architektury czy też metody realizacji, jednakże dopiero obecnie zaczynają się cieszyć rosnącą popularnością i zainteresowaniem szeroko rozumianego przemysłu. Wydaje się zatem konieczne opracowanie efektywnych metod porównania dostępnych na rynku rozwiązań, dzięki którym możliwe stanie się oszacowanie, na ile zastosowanie otwartego systemu sterowania w porównaniu z istniejącymi rozwiązaniami „zamkniętymi” będzie korzystne dla użytkownika. Przestrzeń ewaluacji systemów sterowania dzieli się na dwie części: na część powiązaną z wymaganiami stawianymi przez użytkowników wybieranym przez nich systemom sterowania, z drugiej zaś strony na część związaną z różnymi znanymi obecnie architekturami otwartych systemów sterowania.
Część przestrzeni ewaluacyjnej związana z określeniem wymagań stawianych systemowi sterowania to nic innego, jak cały szereg funkcjonalności, których od wybieranego systemu oczekuje użytkownik. Z kolei część tejże przestrzeni związana z architekturami systemów sterowania definiuje różne sposoby realizacji regulatorów (układów sterowania) o otwartej architekturze. Wypracowane zależności pomiędzy obydwoma częściami przestrzeni ewaluacyjnej prowadzą do określenia stopnia otwartości – a o to chodzi potencjalnemu użytkownikowi.
Pojęcie przestrzeni ewaluacyjnej układów sterowania o otwartej architekturze
Przestrzeń projektowa architektury oprogramowania
Rozwiązanie pojedynczego systemu informatycznego na potrzeby sterowania złożonym obiektem, jakim jest obrabiarka sterowana numerycznie, może zostać zrealizowane na wiele sposobów. Pojęcie przestrzeni projektowej jest tutaj wprowadzone w celu rozróżnienia i ocenienia tych rozmaitych rozwiązań. W ramach przestrzeni projektowej można opracować pewne zasady projektowania, wskazujące zarówno na wady, jak i zalety przyjmowanych architektur. Dzięki tym zasadom możliwe jest wybranie odpowiedniej do danej aplikacji architektury. Przestrzeń projektowa może być swoistym „słownikiem” pojęć i reguł opisujących systemy sterowania, zapewniających ich lepsze zrozumienie.
Przestrzeń projektowa
Podstawową ideą przyświecającą pojęciu przestrzeni projektowej jest wielowymiarowe podejście do klasyfikacji architektur systemu sterowania. Każdy z wymiarów przestrzeni projektowej opisuje zmianę jednego z aspektów projektu systemu lub możliwy do wyboru wariant projektu. Zmienne w ramach każdego z wymiarów korespondują z alternatywnymi wariantami wymogów odnośnie projektowanego systemu. Dany system sterowania odpowiada punktowi w takiej właśnie przestrzeni projektowej. Identyfikuje się go poprzez określenie zmiennych przestrzennych zgodnie z charakterystycznymi cechami i strukturą danego projektu.
Na rysunku 1 przedstawiono trywialny przykład przestrzeni projektowej, w której sugeruje się, że kolejkowanie z użyciem komunikatów pozwala osiągnąć znacznie krótszy czas odpowiedzi, aniżeli mechanizm określany mianem „rendezvous”.
Tabela 1. Wartości punktowe dla wymogów co do aplikacji sterowników o otwartej architekturze
Wymiary
Wymiary przestrzeni projektowej mogą mieć charakter zarówno funkcjonalny, jak i strukturalny. Wymiary funkcjonalne opisują przestrzeń problemu jako alternatywy projektu systemu sterowania pod względem funkcjonalności i efektywności działania. Charakter strukturalny wymiaru przestrzeni oznacza, że przestrzeń rozwiązań podzielona jest pod względem alternatywnych struktur układu regulacji (sprzętowo-programowych).
Reguły
Niektóre z wymiarów przestrzeni projektowej są wzajemnie powiązane – inne zaś są zupełnie niezależne. Zależności pomiędzy wymiarami przyrównać można do zestawu zasad/reguł, które można podzielić na dwie kategorie: na zbiór reguł łączących wymiary funkcjonalny i strukturalny oraz na zbiór reguł opisujących związki pomiędzy różnymi wersjami wymiarów o charakterze strukturalnym. Pierwsza z kategorii pozwala wdrożyć stawiane systemowi wymagania do opracowywanego projektu struktury, podczas gdy kolejna kategoria zapewni użytkownikowi wewnętrzną spójność całego projektu w świetle wybranej przez niego architektury.
Tabela 2. Wartości punktowe dla wymogów co do otwartości SSOA
Ilościowa przestrzeń projektowa
Jest to swego rodzaju arkusz ewaluacji analizowanego systemu sterowania, w którym różnego rodzaju wykresy/tabele oceniają w sposób ilościowy (a nie tylko jakościowy) implementacje zasad obowiązujących w ramach danej przestrzeni projektowej. Jest to swego rodzaju „rachunek zysków i strat, zalet i wad” dla celów szybkiego efektywnego porównania możliwych opcji projektu. Kluczową sprawą w podejściu opartym na przestrzeni projektowej jest wybór jej wymiarów związanych z wymaganiami czy też kryteriami późniejszej ewaluacji (funkcjonalnych i/lub strukturalnych) – należy je wybrać w taki sposób, aby były przydatne podczas dokonywania wyboru określonej struktury układu sterowania. Jeżeli kryteria te zostaną określone w przemyślany sposób, wtedy dzięki nim uwydatnione zostaną najważniejsze cechy najbardziej odpowiedniego rozwiązania.
Koncepcja zastosowania przestrzeni ewaluacyjnej dla oceny systemów sterowania o otwartej architekturze
Każdy system sterowania o otwartej architekturze projektowany jest po to, by spełniał specyficzne wymagania co do funkcjonalności. Innymi słowy to, czy w danej aplikacji akurat system sterowania o otwartej architekturze będzie lepszy od rozwiązania standardowego (o architekturze zamkniętej) w olbrzymim stopniu zależy od tego, na ile spełnia specyficzne wymagania funkcjonalne (w domyśle np. wymagania, których nie jest w stanie zrealizować system standardowy). Tym samym widać wyraźnie, że w przypadku systemów o architekturze otwartej zastosowanie mogą mieć dowolne wymagania – różne architektury będą je spełniać w różnym stopniu. Dzięki koncepcji przestrzeni ewaluacyjnej systemów sterowania o otwartej architekturze możliwe jest wypracowanie i ilościowa (punktowa) ocena zależności pomiędzy wymaganiami a rodzajami architektur. Zależnie od liczby punktów (im więcej, tym lepiej) użytkownicy mogą w prosty sposób ocenić, na ile dana architektura (podejście) spełnia specyficzne wymagania aplikacji. Podejście to leży u podstaw koncepcji przestrzeni ewaluacji systemów sterowania.
Bazując na koncepcji przestrzeni projektowej architektury oprogramowania można wprowadzić pojęcie przestrzeni ewaluacji sterowników o otwartej architekturze. Przestrzeń ewaluacyjna SSOA (Systemów Sterowania o Otwartej Architekturze – Open Architecture Controllers) składać się będzie z wymiarów: wymagań aplikacji oraz sposobu realizacji określonej architektury SSOA. Zależności pomiędzy tymi wymiarami określają stopień spełnienia wybranych wymagań przez daną architekturę. W przestrzeni ewaluacyjnej może być wiele różnych wymiarów wymagań oraz wiele rozmaitych wymiarów, związanych z aspektami realizacji danej architektury SSOA. Wszystkie zestawienia można przedstawić w syntetycznej postaci tabelarycznej, co pozwala użytkownikom na sprawny i efektywny wybór spośród istniejących obecnie architektur, jak również na wskazanie funkcji, których obecnie dostępnym rozwiązaniom brakuje.
Opracowanie przestrzeni ewaluacji dla systemów sterowania o otwartej architekturze
Wymiary wymagań względem SSOA oraz sposoby ich pomiaru
Na rys. 2 przedstawiono podsumowanie wszystkich wymagań stawianych współcześnie systemom sterowania o otwartej architekturze. Bazując na zawartych na tym rysunku informacjach można określić następujące wymiary wymagań stawianych SSOA:
- dziedzina zastosowań,
- wymóg otwartości,
- modułowa struktura systemu,
- ustandaryzowany interfejs,
- wymagania funkcjonalności,
- wymagania wydajności,
- prostota opracowania aplikacji sterowania w oparciu o standard danego systemu sterowania.
Tabela 3. Ocena możliwości współpracy pomiędzy modułami
Aby móc ilościowo określić poziom spełnienia wymagań z danego wymiaru wymagań, należy w pierwszej kolejności wprowadzić konkretne wymiary tych wymagań. Każdy z wymiarów wymagań zawiera kilka poziomów, zatem każdy z tych poziomów może dać różny wynik – różną liczbę punktów. Punktacja związana z każdym wymiarem wymagań ustalana jest z przedziału od 0 do 10 punktów. Im wyższa liczba punktów zostanie przyznana za osiągnięcie danego poziomu spełnienia wymagań stawianych systemowi, tym wyższa jest ogólna ocena danego SSOA.
Dziedzina zastosowań
Sama nazwa „systemu sterowania o otwartej architekturze” wskazuje na fakt, że może on być zastosowany w wielu rodzajach aplikacji przemysłowych (jak np. obróbka maszynowa, robotyka, sterowanie procesami ciągłymi). Wymiar, jakim jest dziedzina zastosowań, wskazuje, w ilu dziedzinach dany system sterowania o otwartej architekturze może mieć zastosowanie. Mówiąc wprost, im większa jest liczba dziedzin, do których dany system sterowania może być zastosowany, tym jest pod tym względem lepszy. Poziomy oraz miary wymagań co do ilości dziedzin zastosowań przedstawiono w tabeli 1.
Wymóg otwartości
Ten wymiar wymagań definiuje w ogólności poziom otwartości SSOA, na którą składają się w głównej mierze: możliwość rozbudowy w przyszłości oraz skalowalność systemu, zależnie od aplikacji. Poziomy oraz miary otwartości SSOA przedstawiono w tabeli 2.
Modułowość struktury
Modułowość struktury systemu sterowania jest nieodłączną cechą SSOA. Odpowiednie wymiary mówią użytkownikom, czy dany rodzaj systemu sterowania ma lepiej czy gorzej zaimplementowaną właściwość, jaką jest modułowość struktury/architektury. Określenia tej własności można dokonać na podstawie dwóch czynników: możliwości efektywnej współpracy (wymiany danych) pomiędzy modułami systemu oraz możliwości wykorzystania modułów (komponentów) na różnych platformach. Własności te zostały opisane w tabelach 3 i 4.
Tabela 4. Ocena możliwości wykorzystania modułów na różnych platformach
Standaryzacja interfejsu
Wewnętrzne interfejsy wymiany danych pomiędzy komponentami systemu opisane są zwykle w standardzie danego systemu, jednakże wymiana informacji ze światem zewnętrznym wymaga już nieco bardziej uniwersalnego podejścia. Do tych zewnętrznych interfejsów zaliczyć można: interfejs operator-maszyna, interfejs programowania NC/PLC (numerycznego), interfejs sterowania nadrzędnego (zarządzania procesem produkcji, jeżeli maszyna stanowi jeden z elementów ciągu produkcyjnego), interfejs sterowania niższego poziomu (jak np. wysyłania informacji do serwonapędów realizujących zadania sterowania ruchem). Poziomy ustandaryzowania interfejsów oraz ich miary przedstawiono w syntetyczny sposób w tabeli 5.
Tabela 5. Ocena standaryzacji interfejsów
Wymagania funkcjonalne
Ten typ wymagań w ogólności definiuje wszystkie wymagania co do funkcji realizowanych przez system sterowania. Zależy głównie od dziedziny zastosowań systemu. Można co prawda określić kilka zależności pomiędzy tego typu wymaganiami a wymiarem architektury, jednakże jest ich tak niewiele, że zostały tutaj pominięte.
Wymagania wydajnościowe
Składają się na nie: niezawodność systemu oraz poziom jego bezpieczeństwa. Są one jednakże specyficzne dla danego modelu systemu sterowania.
Prostota opracowania aplikacji w oparciu o standard systemu sterowania
Łatwość, z jaką w oparciu o dany standard systemu sterowania opracowuje się aplikację, zależy w dużej mierze od sposobu realizacji poszczególnych komponentów architektury systemu. Im lepiej są przygotowane do użycia, tym krótszy jest czas wdrożenia takiego systemu. Jeżeli użytkownik otrzyma jedynie zestaw funkcji, z jakich może sobie budować system, wtedy sam zamienia się w projektanta systemu – wówczas nie jest już wcale łatwo zaimplementować taki system. Jeżeli zaś wszystkie funkcje mają dobrze opracowane interfejsy, a dodatkowo dostępne są przykłady (szablony), wtedy łatwość budowy systemu rośnie. W tabeli 6 „wyceniono” tę łatwość w formie punktowej.
Tabela 6. Ocena łatwości tworzenia aplikacji w oparciu o standardy wymagań
Wymogi interakcji pomiędzy komponentami w warunkach pracy w czasie rzeczywistym
Poziomy tych wymagań oraz ich miary przedstawiono w tabeli 7.
Tabela 7. Ocena wymagań interakcji komponentów systemu co do pracy pod rygorem czasu rzeczywistego
Chi Yonglin
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ń.
