Jak poprawić stabilność oraz szybkość komunikacji między systemem SCADA, a układem sterowania?

Jesteś projektantem aplikacji SCADA? Zależy Ci, aby komunikacja ze sterownikami PLC była stabilna – niezależnie czy aplikacja jest mała i ma obsługiwać kilkaset punktów, czy duża, obsługująca kilkadziesiąt tysięcy sygnałów?

Na pewno wiesz, że warto poszukać możliwości zapewnienia rezerwacji komunikacji, niezależnie od tego, czy posiadasz aplikację rozproszoną, czy pracującą na jednym komputerze. Z kolei operatorom zależy na tym, aby elementy wykonawcze instalacji szybko reagowały na ich komendy. Zobacz, jak na te potrzeby odpowiadają programy komunikacyjne Wonderware OI Servers.

Programy komunikacyjne są jednym z najważniejszych elementów szeroko rozumianego systemu nadrzędnego – systemy SCADA, takie jak InTouch czy Platforma Systemowa Wonderware, przemysłowe bazy danych, takie jak Wonderware Historian lub systemy zarządzania produkcji, takie jak Wonderware MES nie będą spełniały swoich zadań, jeżeli nie będą bazowały na realnych wiarygodnych danych z systemu sterowania. Wszystkie w/w produkty zostały wyposażone w programy komunikacyjne klasy OI Servers (Operations Integration Servers). Są to programy komunikacyjne, które zastąpiły poprzednią generację, które nazywały się DAServers (Data Access Servers).

Wielką zaletą DAServerów była możliwość centralnego zarządzania wieloma programami komunikacyjnymi dla wielu różnych protokołów od wielu różnych dostawców z jednej wygodnej konsoli. W dobie systemów rozproszonych, pracujących w sieci na wielu stanowiskach, naturalną funkcjonalnością było wprowadzenie zdalnego zarządzania, monitoringu oraz diagnostyki oprogramowania na innych komputerach. Jaka więc była potrzeba, aby wprowadzić nową generację programów komunikacyjnych OI Servers?

Korzyści dla działów IT – kompatybilność
Po pierwsze istnieje konieczność zapewnienia kompatybilności z nowymi technologiami – w tym przypadku wsparcie dla nowych systemów operacyjnych. Serwery OI zapewniają poprawną pracę na systemach serwerowych Windows Server 2012 R2 oraz Windows Server 2016. Od strony systemów klienckich typu Workstation są to Windows 8.1 oraz Windows 10 (przy czym należy pamiętać, że firma Microsoft w ramach Windows'a 10, średnio co 6 miesięcy aktualizuje ten system, nadając mu nowy numer kompilacji, a w rzeczywistości jest to prawie nowa wersja systemu operacyjnego aktualizowanego w locie).

Korzyści dla projektantów i administratorów systemów przemysłowych
Po drugie – i na tym się skupimy w ramach tego artykułu – istnieje możliwość podniesienia własności wydajnościowych programów komunikacyjnych, przy coraz większych aplikacjach, obsługujących coraz większą ilość punktów polowych (I/O).

Pojedyncze wystąpienie programu komunikacyjnego jest pojedynczym procesem w systemie operacyjnym, już niepodzielnym względem ilości rdzeni procesora CPU w komputerze / serwerze. Oznacza to tyle, że wraz ze wzrostem ilości obsługiwanych punktów pomiarowych, rośnie obciążenie pojedynczego rdzenia procesora. Przy naprawdę dużych aplikacjach (kilkanaście / kilkadziesiąt tysięcy I/O) może osiągnąć 100% jego wykorzystania i dalszy przyrost obsługiwanych zmiennych będzie negatywnie wpływał na częstość odpytywania o nowe dane oraz na stabilność całej komunikacji. Przez to, że pojedynczy proces w systemie operacyjnym nie jest już podzielny względem rdzeni procesora, w komputerach / serwerach wielordzeniowych możemy mieć sytuację, że dużo zainwestowaliśmy w zasoby sprzętowe, których nie da się optymalnie wykorzystać.

Programy komunikacyjne OI Servers wyposażone w licencję OI Servers Professional pozwalają na konfigurację wielu instancji tego samego programu do obsługi danego protokołu (np. Modbus TCP, GESRTP, CODESYS lub innych). Każda ze zdefiniowanych instancji jest niezależnym procesem w systemie operacyjnym, dzięki czemu system może zarządzać pracą danego procesu na różnych rdzeniach CPU, równomiernie rozkładając obciążenie.

Oprócz podniesienia samej wydajności komunikacji, mamy możliwość zwiększenia jej stabilności. W jednym z projektów, nad którym pracowaliśmy z klientem, wymagana była konieczność łączenia się i zbierania danych z kilkudziesięciu urządzeń. Ilość punktów pomiarowych z pojedynczego urządzenia była na poziomie 100, wśród nich zmienne analogowe i dyskretne. Sumaryczna ilość około 5000 IO nie wymaga jakichś zabiegów, aby podnieść wydajność samej komunikacji, ale brak połączenia z jednym z urządzeń lub z grupą urządzeń bezpośrednio wpływały na stabilność komunikacji z pozostałymi. Zastosowanie OI Serverów w wersji Professional pozwoliło na pogrupowanie urządzeń i rozproszenie komunikacji z nimi pomiędzy wieloma instancjami.

Jak zainstalować komponenty do programów OI Servers?
Aby skonfigurować wiele instancji w OI Servers, należy w pierwszej kolejności zainstalować część wspólną wszystkich serwerów klasy OI Server, czyli OI Core, a następnie program komunikacyjny do obsługi danego protokołu np. GESRTP. Producent zmienił architekturę programów OI Servers i działają one teraz na zasadzie „pluginów", obsługujących konkretne protokoły.

Obecnie dostępne są następujące wtyczki do najczęściej używanych urządzeń: GESRTP – obsługa sterowników i kontrolerów firmy GE, MBTCP – obsługa protokołu Modbus TCP, SIDirect – obsługa protokołu Industrial Ethernet do sterowników firmy Siemens, ABICP – obsługa protokołu CIP sterowników i kontrolerów Allen Bradley, BACLite – obsługa protokołu BACNet, CODESYS – obsługa protokołu o tej samej nazwie, np. do komunikacji ze sterownikami Astraada ONE, MELSEC – obsługa sterowników Mitsubishi, OMRONFINS – obsługa protokołu FINS sterowników Omron, OIGateway – konwerter protokołów oraz OPC UA i WEBSVC – pozwalający na traktowanie WEB Services typu SOAP i REST jako urządzeń i odpytywanie ich cyklicznie o dane.

Jak tworzyć instancje programów komunikacyjnych i je konfigurować?
W konsoli SMC (System Management Console) należy rozwinąć gałąź Operations Integration Server Manager / Default Group / Local / Operations Integrations Supervisory Servers / General Electric – GESRTP (sam etap tworzenia i nazywania instancji programu komunikacyjnego musi się odbywać w konsoli SMC lokalnie na komputerze, gdzie jest zainstalowany dany program komunikacyjny, sama konfiguracja może odbywać się już zdalną konsolą).

Do dyspozycji mamy dwie opcje tworzenia instancji:
1. Tworzenie całego zestawu pustych konfiguracji, które zostaną nazwane korzystając z indeksów
liczbowych i stałej części literalnej. Wybieramy z menu kontekstowego opcję Create Server Instance, a nstępnie określamy pierwszy i ostatni numer indeksu do utworzenia.

2. Klonowanie wstępnie skonfigurowanej instancji domyślnej (cała dotychczasowa konfiguracja zostanie skopiowana do nowej, nazwanej instancji).
Wybieramy z menu kontekstowego skonfigurowanej już instancji Clone Instance, a następnie określamy swoją nazwę.

Na każdym etapie możemy zmienić przydzielone wcześniej nazwy instancji danego protokołu (nazwa instancji musi być unikalna w ramach danego programu komunikacyjnego do protokołu w ramach jednego systemu operacyjnego).

Po skonfigurowaniu, z jakim urządzeniem dana instancja programu komunikacyjnego ma się łączyć, określeniu jego parametrów oraz cyklów (jak często dane mają być wymieniane), należy określić sposób uruchamiania się instancji OI Serverów. Każda z nich może być konfigurowana niezależnie i uruchamiana w inny sposób (usługa systemu Windows uruchamiana automatycznie lub ręcznie, lub jako zwykły proces). Dzięki temu mamy pełną elastyczność możliwych wariantów konfiguracji.

Jak skonfigurować dostęp z aplikacji klienckiej?
Ostatnim etapem konfiguracji i uruchomienia komunikacji, jest określenie parametrów, jak aplikacja kliencka (InTouch, Application Server czy Historian) ma zidentyfikować odpowiednią instancję programu OI Server – pokażemy to na przykładzie konfiguracji komunikacji w ArchestrA IDE, w obiekcie komunikacyjnym DDE_Suitelink_Client. Chcąc odczytać dane ze zdefiniowanej instancji, musimy odczytać ją z konsoli SMC. Nazwa, którą należy zastosować dla poniżej skonfigurowanej instancji to GESRTP_MIXER – nazwa dostępna jest także w oknie zmiany nazwy instancji.

Konfigurując zatem obiekt komunikacyjny DDE/ Suitelink Client, ostateczna konfiguracja powinna wyglądać następująco – w polu Server name należy wpisać odczytaną wcześniej nazwę instancji.

Uruchamiając bądź zatrzymując daną instancję, należy używać do tego konsoli SMC, gdyż jedynie w ten sposób można rozpoznać, którą z wielu instancji zatrzymujemy. Panel procesów lub usług systemu Windows będzie pokazywał wszystkie procesy lub usługi tak samo nazwane – w tym przypadku GESRTP.

Jak zapewnić ciągłość dostępu do danych i bezpieczeństwo procesu?
Funkcje wielu instancji można także wykorzystać po to, aby zapewnić ciągłość w dostępie do danych w aplikacjach klienckich – InTouch, Historian czy Application Server, niezależnie od ewentualnej konieczności restartu programu komunikacyjnego, np. w celu zmiany niektórych parametrów konfiguracyjnych wymagających zatrzymania i ponownego jego uruchomienia. Wystarczą do tego dwie instancje o różnych nazwach o takiej samej konfiguracji.

Następnie należy zastosować funkcje zapewniające redundancję źródeł danych, jak np. tę z InTouch – definicję podwójnych Access Name. Dzięki temu, jeżeli wykryje on, że aktywne źródło nie jest dostepne (zatrzymane), automatycznie przełączy się na źródło rezerwowe w przypadku zaplanowanego restartu, jak i nieplanowanej awarii.

Reinstalacja i rekonfiguracja? Niekoniecznie!
Jak widać, zastosowanie zaawansowanych funkcji nowych serwerów komunikacyjnych generacji OI Servers związane z możliwością definiowania wielu instancji, ma szerokie zastosowanie praktyczne, wcale nie należy do skomplikowanych, a jego dostępność uzależniona jest tylko od posiadanych licencji.