Małgorzata KołopieĔczyk - Uniwersytet Zielonogórski

,POGFSFODKBOBVLPXB,/84
v*OGPSNBUZLBT[UVLBD[ZS[FNJPT’P
D[FSXDB$[PDIB
ZASTOSOWANIE RELACYJNYCH BAZ DANYCH
W PROJEKTOWANIU I SYMULACJI STEROWNIKÓW LOGICZNYCH
Małgorzata KołopieĔczyk
Instytut Informatyki i Elektroniki, Uniwersytet Zielonogórski
65-246 Zielona Góra, ul. Podgórna 50
e-mail: [email protected]
STRESZCZENIE
Celem niniejszego artykułu jest przedstawienie metody opisu układu sterowania logicznego
przy wykorzystaniu mechanizmów relacyjnej bazy danych. Jako formalny jĊzyk specyfikacji
układu wybrano sieü Petriego, jako jĊzyk dobrze sformalizowany i wydajny przy automatyzacji
przetwarzania. Przeniesienie sieci Petriego do relacyjnej bazy danych to nie tylko efektywne
przeniesienie opisu układu do systemu komputerowego. Zastosowanie standardowego jĊzyka
zapytaĔ SQL pozwala na przeprowadzenie symulacji układu bezpoĞrednio w bazie danych.
1. UZASADNIENIE TEMATU
Ciągły postĊp w elektronice pozwala na implementacjĊ coraz to bardziej rozbudowanych
sterowników logicznych PLC (Programmable Logic Controllers). Równolegle z rosnącymi
moĪliwoĞciami technologicznymi poszukiwane są nowe metody projektowania takich
układów. WĞród nowoczesnych technik projektowania sterowników PLC wymieniü moĪna
jĊzyk Grafcet [5] i jĊzyki wyspecyfikowane w miĊdzynarodowej normie IEC:1131-3 [4].
W celu weryfikacji poprawnoĞci oraz w celu zbadania własnoĞci projektowanego układu
stosowane są formalne metody opisu układu. NajczĊĞciej stosowanym formalizmem na etapie
weryfikacji są sieci Petriego [6, 3]. Sieü Petriego stanowi uogólnioną, poĞrednią formĊ w
projektowaniu i badaniu właĞciwoĞci sterowników. Istnieją techniki łatwej i szybkiej
translacji innych jĊzyków projektowania sterowników do sieci Petriego [6]. DostĊpnych jest
wiele programów komputerowych wspierających projektowanie sterowników logicznych i ich
weryfikacjĊ przy wykorzystaniu sieci Petriego oraz bardzo im bliskich jĊzyków Grafcet i
SFC. Wymieniü tu moĪna m.in. aplikacje MX-SCADA, ISaGRAF, PC WORX.
Istotnym utrudnieniem w integracji róĪnych aplikacji jest sposób opisu projektowanego
układu w strukturach danych programów. Brak jest obecnie spójnych i ogólnie uznanych
metod opisu projektowanego układu, w tym samej sieci. Istnieją co prawda pewne formaty
takie jak PNSF, PNSF2 oraz zbliĪone do nich opisy oparte o jĊzyk XML. Jednak stanowią
one wyłącznie formĊ poĞrednią pozwalającą na przeniesienie opisu sieci z jednego narzĊdzia
do drugiego. Formaty takie nie pozwalają na bezpoĞrednią analizĊ układu w jej bieĪącej
131
postaci, nie pozwalają na badanie właĞciwoĞci dynamicznych, są mało czytelne i trudne do
bezpoĞredniego przetwarzania przez programy komputerowe. Analiza i symulacja
zaprojektowanego układu wciąĪ odbywa siĊ przez dedykowane aplikacje, które przechowują
opis sieci w swych wewnĊtrznych strukturach danych.
W artykule przedstawiono sposób zamodelowania układu logicznego w jĊzyku sieci Petriego
przy wykorzystaniu mechanizmów relacyjnej bazy danych. Relacyjne bazy danych to obecnie
najpopularniejszy sposób gromadzenia danych dla aplikacji [7, 9]. Sformatowana postaü
danych oraz jasno sprecyzowane relacje umoĪliwiają przejrzyste opisanie nawet
skomplikowanych struktur, zezwalając jednoczeĞnie na automatyczne przetwarzanie danych
przez programy komputerowe. Wykorzystanie baz danych pozwala takĪe na zwiĊkszenie
wydajnoĞci przetwarzania – wysoka skalowalnoĞü systemów zarządzania bazami danych
RDBMS (Relational Database Management Systems) pozwala na zakodowanie nawet bardzo
złoĪonych układów; techniki indeksowania i partycjonowania pozwalają na szybkie
przetwarzanie ogromnych iloĞci danych, dając nieporównywalnie wiĊkszą wydajnoĞü w
stosunku do przetwarzania standardowych plików komputerowych oraz niwelując ograniczenia związane z koniecznoĞcią zapamiĊtania całej struktury układu w pamiĊci operacyjnej.
Zapisanie układu sterowania w relacyjnej bazie danych pozwala ponadto na symulacjĊ
projektowania układu bezpoĞrednio przy wykorzystaniu standardowych jĊzyków zapytaĔ, w
tym przede wszystkim jĊzyka SQL [8]. Daje to moĪliwoĞü badania własnoĞci sterownika
bezpoĞrednio przez projektanta stosującego standardowy jĊzyk zapytaĔ i mającego
bezpoĞredni wpływ na operacje wykonywane na modelu.
2. SIEû PETRIEGO
Sieci Petriego [2, 3] umoĪliwiają badanie zjawisk współbieĪnych zachodzących w systemach
wzajemnie warunkujących siĊ w czasie i przestrzeni warunków i zdarzeĔ. Oprócz
projektowania i programowania sterowników logicznych, znajdują one zastosowanie takĪe w
róĪnych gałĊziach przemysłu, w zadaniach planowania i sterowania przepływem produkcji, w
syntezie oprogramowania systemowego itp.
W sieci Petriego zdarzenia i warunki reprezentowane są abstrakcyjnymi symbolami
naleĪącymi do dwóch rozdzielnych alfabetów (zbiorów). Zdarzenia odpowiadają przejĞciom
(tranzycjom), warunki miejscom, a związek przeyczynowo-skutkowy miĊdzy zdarzeniami i
warunkami oraz warunkami i zdarzeniami za pomocą relacji przepływu.
Graficznie sieü Petriego reprezentowana jest jako struktura złoĪona z prostokątów i kółek
połączonych łukami (strzałkami). Prostokąty reprezentują przejĞcia, kółka – miejsca, a łuki
relacjĊ przepływu miĊdzy miejscami i przejĞciami oraz przejĞciami i miejscami. Miejsca, z
których prowadzą łuki z rozpatrywanego przejĞcia nazywane są miejscami wyjĞciowymi
przejĞcia. Analogicznie okreĞlane są miejsca wejĞciowe przejĞcia oraz przejĞcia wejĞciowe i
132
wyjĞciowe dla miejsc. Miejsca wejĞciowe przejĞcia przedstawiają warunki – przyczyny
zdarzenia okreĞlonego tym przejĞciem. Miejsca wyjĞciowe przejĞcia reprezentują warunki –
skutki zdarzenia okreĞlonego tym przejĞciem. Wystąpienie (utrzymanie siĊ) pewnego
warunku przedstawione jest znakiem (znacznik, marker) wewnątrz miejsca odpowiadającego
temu warunkowi.
Dynamika działania modelowanego systemu dyskretnego znajduje odzwierciedlenie w
przesuwaniu siĊ znaczników pomiĊdzy miejscami sieci. Lokalne zdarzenia i związane z nimi
akcje przedstawiane są realizacją (zadziałaniem, zapaleniem) okreĞlonego przejĞcia. PrzejĞcie
moĪe byü zrealizowane (wystąpiü), gdy wszystkie jego miejsca wejĞciowe zawierają co
najmniej po jednym znaku. W kategoriach zdarzeĔ i warunków potencjalna realizacja
przejĞcia odpowiada spełnieniu warunków zajĞcia okreĞlonego zdarzenia (wzbudzenie
przejĞcia). Realizacja przejĞcia modeluje wystąpienie okreĞlonego zdarzenia. Realizacji
przejĞcia towarzyszy usuniĊcie po jednym znaku miejsc wejĞciowych przejĞcia i dodanie po
jednym znaku do miejsc wyjĞciowych przejĞcia. W ten sposób wskazuje siĊ nowe warunki –
skutki wystąpienia rozpatrywanego zdarzenia.
Formalnie sieü Petriego definiujemy jako uporządkowaną trójkĊ PN = (P, T, F) gdzie:
1) P ∩ T = ∅,
2) P ∪ T ≠ ∅,
3) F ⊆ (P × T) ∪ (T × P),
4) dom(F) ∪ cod(F) = P ∪ T.
F jest relacją przepływu w sieci PN, dom(F) jest dziedziną relacji F, czyli dom(F) = {x: ∀
y
(x, y) ∈ F}, cod(F) jeset przeciwdziedziną relacji F, czyli dom(F) = {y: ∀ (x, y) ∈ F}.
x
Elementy zbioru F nazywane są łukami, elementy zbioru P nazywane są miejscami (Pelementami), elementy zbioru T nazywane są tranzycjami (T-elementami).
Znakowana sieü Petriego to uporządkowana szóstka MPN = (P, T, F, K, W, M0) gdzie:
1)
2)
3)
4)
(P, T, F) jest siecią Petriego,
K: P → N+ ∪ {∞} jest funkcją pojemnoĞci miejsc,
W: F → N+ jest funkcją wagi łuków,
M0: P → N jest funkcją znakowania początkowego spełniającą warunek ∀ M0(p) ≤
p∈P
K(p).
Za pomocą znakowaĔ (markowaĔ) opisujemy stan w jakim znajduje siĊ układ, czyli jakie
miejsca są w danej chwili czasowej aktywne. Markowania zmieniają siĊ w czasie, pokazując
które miejsca zostały „wykonane” i w jakiej kolejnoĞci. Formalnie opiszemy to za pomocą
realizacji tranzycji:
Niech MPN = (P, T, F, K, W, M0) bĊdzie znakowaną siecią Petriego, wówczas:
1) funkcja M: P → N jest nazywana znakowaniem MPN ⇔ ∀ M(p) ≤ K(p),
p∈P
2) tranzycja t ∈ T jest przygotowana do realizacji (dozwolona) w oznakowaniu M ⇔ ∀
p∈P
W(p, t) ≤ M(p) ≤ K(p) – W(t, p),
133
3) jeĪeli tranzycja t ∈ T jest tranzycją, która jest dozwolona w oznakowaniu M to t moĪe
wystąpiü i zostaü zrealizowana. Nowe znakowanie okreĞlone M’(p) = M(p) – W(p, t) +
W(t, p) dla wszystkich p ∈ P,
4) wystąpienie tranzycji t ∈ T zmienia znakowanie M na znakowanie M’, co oznacza siĊ
t
→
poprzez M [t² M’ lub M 
M’.
W modelowaniu sterowników logicznych stosowane są sieci 1-ograniczne, czyli takie w
których pojemnoĞü miejsc wynosi 1. Definicja sieci n-ograniczonej jest nastĊpująca:
1) miejsce p ∈ P jest n-ograniczone (n ∈ N) ⇔ M ∈∀
M(p) ≤ n,
[M
0
2) MPN jest n-ograniczona (n ∈ N) ⇔ ∀ p jest n-ograniczone.
p∈P
3. STRUKTURA TABLIC W RELACYJNEJ BAZIE DANYCH
Sieü Petriego opisująca układ sterowania logicznego jest siecią 1-ograniczoną. Podstawowe
elementy sieci to miejsca i tranzycje. W relacyjnej bazie danych do opisu miejsc i tranzycji
wykorzystamy dwie tablice, o nazwach STATE i TRANSITION. STATE to lista stanów
(miejsc, kroków) układu, TRANSITION to lista tranzycji układu.
Relacje zachodzące pomiĊdzy miejscami i tranzycjami opisane zostaną w tablicy RELATION.
W tablicy tej dla jednej tranzycji moĪe wystąpiü kilka rekordów. Zbiór tranzycji z
prawdziwymi
warunkami
przejĞcia
opisano
za
pomocą
kolejnej
tablicy
TRANSACTIONACTIVE. Tablica opisuje, które tranzycje są aktywne, czyli które z nich mają
prawdziwe warunki i pozwalają na aktywacjĊ miejsca. WartoĞci w tej tablicy powinny byü
ustawiane na podstawie warunków przy tranzycjach, jednak ten element systemu nie jest
jeszcze opracowany. Wprowadzamy wiĊc do tej tablicy wartoĞü true/false, w zaleĪnoĞci od
tego czy dany warunek ma byü prawdziwy czy fałszywy. Aktywne stany układu (czyli stany
ze znacznikiem) opisane są w tablicy STATEACTIVE. Tablica informuje, które miejsca są
aktualnie aktywne. W tablicy tej mamy wiĊc wyjĞcie układu. Miejsca aktywne zmieniają siĊ
w miarĊ wykonywania kolejnych kroków symulacji w zaleĪnoĞci od warunków na
tranzycjach, z zachowaniem współbieĪnoĞci i synchronizacji.
4. SYMULACJA UKŁADU PRZY WYKORZYSTANIU JĉZYKA SQL
Symulacja składa siĊ z dwóch podstawowych kroków: inicjalizacji i wykonania kolejnych
kroków symulacji. Inicjalizacja (restart) tworzy tablice pomocnicze, które wykorzystywane są
dalej w trakcie symulacji układu. Wykonanie kroku (step) sprawdza warunki na tranzycjach i
odpowiednio aktywuje kolejne miejsca układu, symulując jego działanie.
Restart to inicjalizacja automatu, wygenerowanie tablic pomocniczych wykorzystywanych w
trakcie symulacji. Obecnie w momencie inicjalizacji jako aktywne ustawiane jest miejsce o
numerze 1, oczywiĞcie łatwo rozszerzyü system o moĪliwoĞü wyboru miejsca startowego. W
134
trakcie inicjalizacji nastĊpuje wyzerowanie miejsc i tranzycji „aktywnych”. Tabela
STATECOUNT jest tablicą pomocniczą w której przechowywana jest iloĞü miejsc
wejĞciowych dla kaĪdej tranzycji.
Step - wykonanie kolejnego kroku symulacji automatu. W trakcie takiego kroku sprawdzane
są warunki tranzycji oraz odpalane są te miejsca, dla których tranzycje wyjĞciowe są aktywne.
Spradzane są przy tym warunki współbieĪnoĞci automatu.
Tabela STATECOUNTACTIVE jest tablicą pomocniczą w której przechowywana jest iloĞü
miejsc wejĞciowych aktywnych dla kaĪdej tranzycji. Jak łatwo zauwaĪyü, kroki 6 i 7 mogłyby
zostaü zapisane w jednej instrukcji SQL wykorzystującej polecenie OUTER JOIN. Jednak
system testowany był na bazie danych MS Access, w której OUTER JOIN nie jest
zaimplementowany.
5. PRZYKŁAD SYMULACJI UKŁADU
W celu weryfikacji modelu wykonana została prototypowa aplikacja pozwalająca na
symulacjĊ układów opisanych za pomocą sieci Petriego. Jak system zarządzania bazami
danych wybrano popularną aplikacjĊ Microsoft Access w wersji 7.0. Cała symulacja odbywa
siĊ poprzez wywołanie odpowiednich skryptów SQL, tak wiĊc do symulacji układu nie są
potrzebne Īadne inne mechanizmy oprócz tych, jakie udostĊpnia jĊzyk SQL. W celu lepszej
prezentacji wyników przygotowana została prosta formatka do prezentacji danych, której
wygląd przedstawiono na rys. 1.
Rys. 1. Ekran symulatora
W celu demonstracji działania systemu przeprowadzono symulacjĊ prostego układu którego
schemat zamieszczono na rys. 2.
135
Jak widaü w układzie mamy sekwencjĊ współbieĪną oraz
sekwencjĊ dywergentną, pozwala to zbadaü zachowanie
modelu w przypadku współbieĪnego wykonania kilku
zadaĔ, synchronizacji współbieĪnych sekwencji oraz
alternatywny wybór nastĊpnej procedury sekwencyjnej.
S1
T1
S2
S3
T2
S4
Model układu po przeniesieniu do relacyjnej bazy. Ze
wzglĊdu na ograniczoną objĊtoĞü publikacji, szczegóły
translacji pominiĊto w artykule.
T3
S5
T5
S7
Symulacja układu polegała na zmianie warunków i
odpalaniu kolejnych tranzcyji. Testy wykazały poprawną
symulacjĊ układu. Prawidłowo zasymulowana została
współbieĪnoĞü i synchronizacja układu, jak równieĪ
alternatywne wybranie jednej z dwóch sekwencji.
T4
S6
T7
T6
S8
T8
Rys. 2. Schemat przykładowego
układu
6. PODSUMOWANIE
MoĪliwe jest zamodelowaniu sterownika opisanego siecią Petriego za pomocą relacyjnej bazy
danych. Istnieje moĪliwoĞü symulacji sterownika przy pomocy jĊzyka SQL. W dalszych
pracach planowane jest zbadanie moĪliwoĞci weryfikacji układu oraz badania jego własnoĞci
jakoĞciowych i iloĞciowych przy wykorzystaniu SQL i innych mechanizmów relacyjnej bazy
danych. W chwili obecnej system nie jest wystarczająco odporny na pewne nieprawidłowoĞci
w symulowanym układzie.
Kolejnym zagadnieniem wartym dogłĊbniejszej analizy jest zbadanie moĪliwoĞci
wykorzystania systemu do symulacji sieci Peteriego n-ograniczonych i nieograniczonych a
takĪe bezpoĞredniej symulacji układów opisanych za pomocą np. jĊzyków SFC i Grafcet.
LITERATURA
[1] M. Adamski, M. ChodaĔ: Modelowanie układów sterowania dyskretnego z
wykorzystaniem sieci SFC, Wydawnictwo PZ, 2000
[2] P. H. Starke: Sieci Petri, WNT, 1987
[3] W. Reisig: Sieci Petri, WNT, 1988
[4] International Electrotechnical Commision: International Standard IEC1131-3, 1993
[5] R. David, H. Alla: Petri Nets & Grafcet. Tools for modelling discrete event systems,
Prentice Hall, 1992
[6] M. KołopieĔczyk: Modelling Process of Programmable Logic Controllers, Proc.
Modelling and Symulation of Systems, 2002
[7] R. Muller: Bazy danych – jĊzyk UML w modelowaniu danych, Mikom, 2000
[8] American National Standards Institute: Databas Language-SQL ANSI X3.135, 1992
[9] T. J. Teorey: Database Modelling and Design, Morgan Kaufmann, 1999
136