3,10,20

ZAPISZ SIĘ DO NEWSLETTERA AUTOMATYKAONLINE.PL I POBIERZ DARMOWY NUMER "AUTOMATYKI"!

Okładka Automatyka

*Wyrażam zgodę na przetwarzanie moich danych osobowych przez Sieć Badawcza Łukasiewicz - Przemysłowy Instytut Automatyki i Pomiarów PIAP, z siedzibą w Warszawie przy ul. Al. Jerozolimskie 202, 02-486 Warszawa, w celach marketingowych, w tym marketingu bezpośredniego. Oświadczam, że zostałem poinformowany/a o prawie do wglądu, modyfikacji oraz usuwania moich danych osobowych.

Wyrażam zgodę na przesyłanie mi informacji handlowej (w tym informacji handlowej partnerów portalu AutomatykaOnline.pl) za pomocą środków komunikacji elektronicznej w rozumieniu ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. 2002 nr 144, poz. 1204).

Wyrażam zgodę na używanie przez Sieć Badawcza Łukasiewicz - Przemysłowy Instytut Automatyki i Pomiarów PIAP, z siedzibą w Warszawie przy ul. Al. Jerozolimskie 202, 02-486 Warszawa, telekomunikacyjnych urządzeń końcowych, których jestem użytkownikiem, dla celów marketingu bezpośredniego zgodnie z art. 172 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz.U. 2004 nr 171 poz. 1800).

*Akceptuję regulamin portalu AutomatykaOnline.pl oraz politykę prywatności serwisu.




ZAMKNIJ OKNO

Prawie gotowe ... Musimy potwierdzić Twój adres email.

Aby zakończyć proces subskrypcji, musisz kliknąć link w mailu, który właśnie wysłaliśmy do Ciebie. Po akceptacji zapisu na newsletter, zostanie przesłany do Ciebie numer promocyjny miesięcznika Automatyka.

ZAMKNIJ OKNO

Dziękujemy twój mail jest już w naszej bazie!

Napisz do nas maila a otrzymasz promocyjny numer miesięcznika Automatyka

redakcja@automatykaonline.pl

ZAMKNIJ OKNO

Ta strona używa ciasteczek

W celu zapewnienia najwyższej jakości usług strona używa plików cookies. Szczegóły w polityce prywatności serwisu.

POL ENG
a a a
Szukaj
  • Logowanie
  • Załóż konto
Mapa serwisu Mapa serwisu
AutomatykaOnline.pl
  • Strona główna
  • Z branży
  • Wywiady
  • Aplikacje
  • Artykuły
  • Kalendarium
  • Firmy
  • Produkty
Szukaj
Automatyka 5/2025

Automatyka5/2025

W numerze:
  • Rozmowa z Maciejem Sieczką, Endress+Hauser Polska
  • Roboty przemysłowe – przegląd aktualności
  • Wdrażanie robotyki w produkcji i usługach
  • O miesięczniku
  • Prenumerata
  • Kontakt
  • Reklama
ARTYKUŁY
  • Automatyka budynkowa
  • Bezpieczeństwo
  • Druk 3D
  • Elektryka
  • Energetyka
  • Energia
  • Hydraulika
  • Komunikacja
  • Komputery i HMI
  • Logistyka
  • Montaż i transport
  • Oprogramowanie
  • Pneumatyka
  • Pomiary
  • Prawo i normy
  • Przemysł 4.0
  • Robotyka
  • Sterowanie
  • Systemy wizyjne i RFID
  • Technika napędowa
  • Technika łożyskowa
  • Technologia obróbki
  • Usługi
  • Utrzymanie Ruchu
  • Inne
Rozwiń wszystkie
  • Strona główna
  • Artykuły
  • Oprogramowanie

Oprogramowanie AVEVA – co warto wiedzieć o projektowaniu i uruchamianiu systemu informatycznego dla przemysłu

Artur Połeć (ASTOR) drukuj

20 czerwca 2023 roku
Oprogramowanie AVEVA – co warto wiedzieć o projektowaniu i uruchamianiu systemu informatycznego dla przemysłu
Tweet

Z tego artykułu dowiesz się:

  • jak powinna wyglądać architektura prostych i złożonych systemów oprogramowania przemysłowego,
  • jakie są sprzętowe wymagania aplikacji AVEVA,
  • jakie zalety ma stosowanie technologii wirtualizacji,
  • dlaczego wsparcie ekspertów ASTOR może bardzo ułatwić zaprojektowanie każdego systemu IT dla przemysłu.

Każdy użytkownik komputera zna taką sytuację: mamy nowy program, którego dotąd nie używaliśmy – aby go uruchomić, trzeba go najpierw zainstalować. Albo inny przypadek: pojawia się nowa wersja naszej ulubionej aplikacji – aby jej użyć, trzeba przeprowadzić aktualizację. W komputerze domowym jest to zwykle dość łatwe. Uruchamiamy program „setup.exe”, gładko przechodzimy przez kilka etapów instalatora – i gotowe. W przypadku uruchamiania oprogramowania przemysłowego AVEVA sprawa jest nieco bardziej złożona.

 

W bardzo zamierzchłych już czasach, kiedy cały system informatyczny zakładu produkcyjnego ograniczał się do pojedynczej stacji wizualizacyjnej InTouch, instalacja oprogramowania wyglądała podobnie, jak w przypadku zwykłych programów. Wystarczyło uruchomić instalator – i za chwilę program był gotowy do pracy. Dzisiejsze systemy wyglądają zupełnie inaczej. Są to z reguły rozbudowane struktury, złożone – oprócz stacji wizualizacyjnych – również z serwerów Platformy Systemowej AVEVA lub Historian. Struktura taka – zanim przystąpimy do prac wdrożeniowych – wymaga dalece bardziej szczegółowego przemyślenia i zaprojektowania.

System może być stosunkowo prosty…

Na potrzeby tego artykułu zilustrujemy temat, posługując się dwoma dość typowymi przykładami systemów informatycznych w przemyśle. Pierwszy z nich to system „mniejszy”, w którym łączna liczba obsługiwanych sygnałów I/O nie przekracza 5 000. Z reguły w tego typu systemach aplikacje wizualizacyjne nie są bardzo skomplikowane, a tym samym wymagania stawiane serwerom i stacjom klienckim są mniejsze.

W tej aplikacji jeden komputer pełni jednocześnie funkcję Application Servera Platformy Systemowej AVEVA i serwera Historian. Jest na nim umieszczone również Galaxy Repository, a nierzadko też środowisko deweloperskie System Plarform IDE. System obejmuje także kilka stacji wizualizacyjnych AVEVA InTouch. Całość połączona jest siecią Ethernet.

Dlaczego tak? W przypadku tego rodzaju systemów wymagania w zakresie wydajności są mniejsze, natomiast jednocześnie większe są ograniczenia budżetowe, które sprawiają, że choćby tylko z powodów finansowych, nie mamy możliwości instalacji oddzielnych serwerów dla każdej usługi. Trzeba tu jednak podkreślić dwie rzeczy. Po pierwsze – taka architektura nie daje nam żadnych zabezpieczeń na wypadek awarii serwera. Żadna jego funkcja nie jest dublowana na innej maszynie, więc jeżeli serwer przestaje działać – cały system zatrzymuje się. Podobnie ma się sytuacja z planowymi pracami serwisowymi – również one powodują konieczność zatrzymania wszystkich usług.

Po drugie – jest prawdą, że mniejsze systemy mają mniejsze wymagania, więc często tego rodzaju prostsza architektura będzie wystarczająca. Czy jednak możemy zawsze mieć taką gwarancję? Oczywiście nie. Skąd zatem można mieć pewność? Do tego tematu wrócimy w dalszej części tekstu.

schemat2_opt-633x734

Przykładowa struktura mniejszego systemu (do 5000 I/O). Źródło: ASTOR

… ale może być też bardzo rozbudowany

W przypadku systemów większych, w których liczba obsługiwanych zmiennych I/O często znacznie przekracza 5 000, architektura powinna oczywiście wyglądać zupełnie inaczej. Na przykład tak, jak na poniższym schemacie.

W tym przypadku każdy serwer, zarówno Application Server, jak i Historian, powinien być osobnym komputerem. Również Galaxy Repository uruchomione jest na oddzielnej stacji, podobnie środowisko deweloperskie System Platform IDE. Stacje wizualizacyjne natomiast podłączone są za pośrednictwem serwera terminalowego. Wszystkie komponenty spina oczywiście sieć Ethernet.

Ponadto łatwo zauważyć, że oba kluczowe serwery (Application Server i Historian) zostały zdublowane w układzie redundancji, dzięki czemu awaria jednego komputera nie będzie miała wpływu na nieprzerwaną, prawidłową pracę całego systemu. Uszkodzony element możemy łatwo wymienić lub zmodernizować. To jeden z ważniejszych powodów, dla których architekturę systemu warto projektować właśnie w ten sposób.

Jednak są jeszcze inne powody. Takie rozproszenie funkcjonalności sprawia, że łatwiej jest zarządzać wydajnością – każda usługa ma swoje zasoby i jest niezależna od pozostałych. Podobnie w przypadku konieczności wykonania działań serwisowych możemy pracować na jednym fragmencie całego systemu, który jako całość nadal pracuje. Rozproszenie i zdublowanie usług pozwalają także przeprowadzać proces migracji z wersji na wersję oprogramowania, gdyż zastosowanie rozproszenia wraz z procedurą opisaną w dokumentacji, pozwala zminimalizować czas potencjalnego przestoju. W przypadku opisanej wcześniej „małej” architektury prozaiczna konieczność zrestartowania serwera całkowicie zatrzymuje działanie systemu.

W przypadku używania usług terminalowych, warto zastosować farmę takich serwerów. Gdy wykorzystujemy fizyczne komputery jako stacje wizualizacyjne i awarii ulegnie jedna z nich, to zwykle proces można prowadzić awaryjnie na innej stacji. W przypadku awarii serwera terminalowego wszystkie sesje terminalowe przestaną działać – i nie będzie skąd prowadzić procesu. Gdy zastosujemy farmę serwerów terminalowych, liczba potrzebnych stacji klienckich jest łatwa do skalowania. Możemy w razie potrzeby zwiększać zasoby serwerów lub ich liczbę, zapewniając podwyższenie dostępności oraz równoważenie obciążenia pomiędzy serwerami.

schemat1_opt

Przykładowa architektura dużego systemu (ponad 5000 I/O). Źródło: ASTOR

Ważne słowo: wirtualizacja

Częstą praktyką jest obecnie projektowanie i wdrażanie przemysłowych systemów informatycznych w środowisku zwirtualizowanym. Wszystkie komponenty takiego systemu, nawet najbardziej wymagające serwery, mogą być uruchomione na maszynach wirtualnych. Oprogramowanie AVEVA wspiera rozwiązania od dwóch największych dostawców technologii wirtualizacji: Microsoft Hyper-V oraz VMWare vSphere. W przypadku tego drugiego mamy do dyspozycji narzędzie vCenter, dzięki któremu możemy centralnie zarządzać wieloma hostami wirtualizacji, wykonywać kopie bezpieczeństwa, a także łatwo przenosić maszyny wirtualne pomiędzy serwerami, zapewniając ciągłość pracy instalacji w przypadku konieczności serwisowych samych serwerów do wirtualizacji.

Naturalne jednak wydaje się pytanie: dlaczego w ogóle warto stosować wirtualizację. Rozwiązanie takie ma kilka ważnych zalet:

1. Maszyny wirtualne nie są uzależnione od sprzętu, na którym są uruchomione. Każda maszyna może być w razie potrzeby szybko przeniesiona na zupełnie inny serwer. Pozwala to na dużo szybsze reagowanie na awarie oraz znacznie ułatwia wszelkie prace serwisowe.

2. Na jednym serwerze może być uruchomionych wiele maszyn wirtualnych, które w rzeczywistości współdzielą ze sobą zasoby tego serwera. To daje nam elastyczność w zarządzaniu przydzielaniem zasobów dla poszczególnych maszyn i pozwala skutecznie regulować wydajność ich pracy.

3. Wirtualizacja pozwala nam na wykonywanie tzw. snapshotów, czyli zapisywanie kompletnego stanu maszyny (w tym zawartości dysku i pamięci), który później może zostać odtworzony. Dzięki temu możemy „zatrzasnąć” dany stan maszyny wirtualnej np. gdy potrzebujemy wykonać jakieś testy. Gdyby w trakcie testów coś poszło nie tak, łatwo możemy powrócić do wcześniej zapisanego stanu maszyny, tym samym wycofując wszystkie wprowadzone zmiany.

4. Wirtualizacja ułatwia zarządzanie poszczególnymi komponentami systemu, ponieważ maszynami wirtualnymi możemy zarządzać centralnie, z jednego miejsca. Co więcej, również mechanizm wykonywania kopii bezpieczeństwa może być scentralizowany i skonfigurowany w taki sposób, aby kopie wszystkich maszyn wirtualnych były wykonywane automatycznie oraz zapisywane w jednym, przeznaczonym do tego miejscu.

5. Wirtualizacja bardzo ułatwia skalowanie systemu. Dużo łatwiej dodać do systemu nową maszynę wirtualną niż fizyczny komputer.

Jakie wymagania mają aplikacje?

Niezależnie od tego, czy jest uruchamiana na fizycznym komputerze, czy na maszynie wirtualnej, każda aplikacja AVEVA ma określone wymagania sprzętowe. Ich określenie jest łatwiejsze w przypadku środowiska zwirtualizowanego, w którym operujemy trzema parametrami: liczbą rdzeni wirtualnych procesora (vCPU) oraz ilością pamięci RAM i pojemnością dysku (storage), przydzielonymi pojedynczej maszynie. Dla poszczególnych aplikacji możemy określić zalecane/typowe wymagania, ale należy pamiętać, że zawsze będzie to jedynie punkt odniesienia, a rzeczywiste wartości mogą być uzależnione od specyfiki konkretnej aplikacji.

Zapotrzebowanie na zasoby serwera aplikacji Platformy Systemowej zależy od liczby wykorzystywanych silników aplikacyjnych. Przy skalowaniu zasobów można przyjąć, że każdy silnik wymaga 1 vCPU (jeżeli lepiej chcemy wykorzystać zasoby zakupionego sprzętu i wykorzystywać przetwarzanie równoległe, warto stosować wiele silników aplikacyjnych, gdyż te nie są już podzielne pomiędzy rdzeniami procesora). Dobrym punktem startowym będzie przydział 4 wirtualnych rdzeni – oraz 1 GB RAM (w przypadku skomplikowanych skryptów może to być 1,2 GB), zachowując rezerwy na obsługę sytuacji nieprzewidzianych oraz oczywiście na sam system operacyjny (wg specyfikacji i rekomendacji dla danej wersji systemu operacyjnego). Zapotrzebowanie na przestrzeń dyskową ma mniejsze znaczenie, 120 – 150 GB SSD będzie wystarczające.

AVEVA Historian wymaga zawsze od 4 do 6 rdzeni vCPU oraz minimum 16 GB RAM (sam serwer SQL wymaga 10 GB). Jeżeli będziemy wykorzystywać SQL Server Reporting Services lub własne bazy SQL, konieczne będzie 24 GB RAM. Jeżeli chodzi o storage, to powinniśmy wykorzystać dwa osobne, wirtualne dyski: jeden na pliki systemu operacyjnego oraz pliki bazy danych SQL (120-150 GB SSD), drugi na same bloki danych Historiana (nawet 1 TB – w zależności od wymaganego czasu przechowywania danych).

Galaxy Repository wymaga 4 rdzeni vCPU, 8-12 GB RAM i 120-150 GB SSD. Natomiast środowisko deweloperskie Aveva System Platform IDE potrzebuje 4 rdzeni vCPU, 8 GB RAM i 120-150 GB przestrzeni dyskowej SSD.

W przypadku stacji wizualizacyjnych uruchamianych na serwerze usług terminalowych sprawa jest nieco bardziej skomplikowana. Po pierwsze, AVEVA InTouch WindowViewer jest aplikacją jednowątkową, dlatego ważne jest, aby procesory używane w serwerach hostujących sesje terminalowe były jak najwydajniejsze – minimum 2,6-2,8 GHz. Użycie procesorów wolniejszych (2,2 – 2,4 GHz) będzie powodować wolne działanie i gorszy komfort pracy operatorów.

Jeżeli chodzi o serwer terminalowy (Remote Desktop Server), należy przewidzieć jeden rdzeń vCPU na każde 2-3 sesje teminalowe. Jest to wartość szacunkowa, gdyż zapotrzebowanie mocno zależy od tego, jak przygotowane są aplikacje wizualizacyjne i jak bardzo obciążają procesor. Na każdą sesję terminalową powinniśmy też przewidzieć 1–1,5 GB pamięci RAM (choć należy pamiętać, że zapotrzebowanie na RAM rośnie w miarę czasu pracy aplikacji i otwierania kolejnych okien). Realnie rzecz biorąc, pojedynczy serwer usług terminalowych powinien być wyposażony w 26-32 GB pamięci RAM.

Dla serwerów terminalowych jako nośniki danych należy bezwzględnie zastosować dyski SSD (dla zapewnienia odpowiedniej wydajności). Trzeba przewidzieć odpowiednią ilość przestrzeni dyskowej dla samego systemu operacyjnego (120 – 150 GB), a także niezbędną przestrzeń dla kopii aplikacji wizualizacyjnej dla każdej z sesji.

Jak dobrze zaprojektować system? Kilka przydatnych wskazówek

Warto tu jeszcze przytoczyć kilka ogólnych wskazówek, przydatnych przy projektowaniu rozbudowanych, przemysłowych systemów IT, opartych na oprogramowaniu AVEVA:

1. W przypadku, gdy system ma posiadać więcej niż 5 stacji (komputerów fizycznych lub wirtualnych), wskazane jest skonfigurowanie środowiska domenowego. To znacznie ułatwia zarządzanie wszystkimi maszynami, użytkownikami i regułami – np. firewall poprzez polisy grupowe. Dodatkową zaletą jest dostępność pojedynczego logowania (single sign-on, SSO) w takiej konfiguracji – użytkownik loguje się raz, uzyskując dostęp do wszystkich zasobów i aplikacji w całym systemie.

2. Oprogramowanie AVEVA InTouch wykorzystuje tylko jeden rdzeń procesora, zatem dla jego wydajnej pracy (niezależnie, czy jest uruchamiane na fizycznym komputerze, czy na maszynie wirtualnej) znacznie ważniejsze jest taktowanie procesora niż liczba rdzeni.

3. W przypadku wykorzystywania serwerów terminalowych obowiązuje prosta zasada – im więcej równoległych połączeń klienckich, tym więcej potrzebnych rdzeni procesora.

4. Jeżeli w aplikacji wizualizacyjnej planujemy wykorzystać elementy 3D, warto zastosować dedykowaną kartę graficzną z odpowiednio mocnym GPU. Podobnie jest przypadku wyświetlania obrazu z wielu kamer.

5. Niezwykle ważne jest skonfigurowanie wiarygodnego źródła czasu (NTP) dla systemu. Można skorzystać z publicznego serwera lub wykorzystać lokalny moduł GPS.

6. Z każdym instalatorem aplikacji dostarczany jest dokument ze szczegółowymi wymaganiami sprzętowymi. Należy jednak pamiętać, że są to wymagania produktowe, a nie aplikacyjne. Oznacza to, że w zależności od tego, jak bardzo rozbudowaną aplikację będziemy tworzyć, mogą one okazać się niewystarczające.

Wsparcie ekspertów ułatwia zaprojektowanie każdego systemu

Nawet biorąc pod uwagę wszystkie powyższe wskazówki, poprawne zaprojektowanie architektury oraz wdrożenie przemysłowego systemu informatycznego jest skomplikowanym i odpowiedzialnym procesem. Pojawia się wiele pytań. Jakie produkty wybrać? Jak je połączyć? Na jakim sprzęcie je zainstalować? Czy to będzie niezawodnie działać? Czy to będzie działać wydajnie? I czy na pewno?

Są to bardzo stresujące pytania, szczególnie jeżeli nie mamy zbyt dużego doświadczenia w takich wdrożeniach. Wymagana jest też oczywiście rzetelna wiedza techniczna o poszczególnych produktach.

Warto zatem pamiętać, że jeżeli stoimy przed takim wyzwaniem, możemy zwrócić się do firmy ASTOR. Nasi eksperci skutecznie pomogą na każdym etapie projektowania i wdrożenia systemu:

  • pomożemy zaprojektować architekturę systemu,
  • wskażemy zalecaną konfigurację aplikacji,
  • doradzimy w zakresie konfiguracji sprzętu i/lub środowiska wirtualnego,
  • pomożemy określić, jakie zasoby będą niezbędne dla poszczególnych komponentów,
  • doradzimy, jak zaprojektować zabezpieczenia takie jak redundancja czy system kopii bezpieczeństwa.

W ramach naszych usług doradczych klient może otrzymać od nas projekt kompletnego środowiska IT z konfiguracją dedykowaną do oprogramowania AVEVA, wraz z dokumentacją tego środowiska, tak aby mógł je przejąć i samodzielnie nim zarządzać. 

Więcej artykułów o oprogramowaniu AVEVA dostępnych na Poradniku Automatyka!

źródło: ASTOR

Słowa kluczowe

ASTOR, automatyka, AVEVA, oprogramowanie

Ostatnio dodane

  • Universal Robots przedstawia UR15
  • Technika napędowa
  • Nowoczesne technologie pomiarowe to oszczędności w zakładach przemysłowych

Najczęściej czytane

  • Języki programowania robotów przemysłowych
  • Bezpieczeństwo dla maszyn mobilnych
  • Wyznaczanie poziomów bezpieczeństwa SIL i PL

Polecane

  • Przemysł 4.0 w polskich realiach
  • Systemy wizyjne – nieodzowny element nowoczesnej kontroli
  • Czy robot może ponieść odpowiedzialność karną?

Czytaj także

  • Monitorowanie i zarządzanie procesami produkcyjnymi
  • AI w służbie ludzi – od automatyzacji do personalizacji doświadczeń
  • ERP w produkcji elektroniki – efektywność, kontrola, optymalizacja
  • W jaki sposób Proalpha umożliwiła modelowy przebieg cyfryzacji w MBV AG
  • CMMS w świecie automatyki przemysłowej – skuteczne narzędzie w walce z przestojami

Newsletter

Bądź zawsze na bieżąco z aktualnymi informacjami.

Inżynier wie

Kalendarium

Więcej
1 sty Szkolenie

Zwiedzanie centrum efektywnej prefabrykacji szaf sterowniczych

1 stycznia 2025 – 31 grudnia 2025
20 maj Szkolenie

Ethernet przemysłowy w praktyce – konfiguracja i diagnostyka

Wrocław 20 maja 2025
20 maj Targi

Battery Forum Poland 2025

20–22 maja 2025
20 maj Targi

PLASTPOL 2025

Kielce 20–23 maja 2025

Wideo YouTube

Zobacz więcej
  • facebook
  • Tweeter
  • Instagram
  • Linkedin
  • RSS AutomatykaOnline
  • O nas
  • Marketing i obsługa klienta
  • Polityka prywatności
  • Informacje o portalu
  • Regulamin
  • Deklaracja Dostępności
  • Kontakt
  • Formularz kontaktowy
  • Współpraca medialna
  • Redakcja portalu
  • Redakcja miesięcznika
  • Zamów
  • Wpis do katalogu
  • Reklama na portalu
  • Reklama w miesięczniku
  • Newsletter
AutomatykaOnline.pl

ISSN 2392-1064. © 2014 by Sieć Badawcza Łukasiewicz – Przemysłowy Instytut Automatyki i Pomiarów PIAP. All rights reserved.
created by: TOMP