Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników
Powiadomienia systemowe
  • Sesja wygasła!

Znaleziono wyników: 6

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  UML activity diagrams
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
PL
W artykule przedstawiono ideę zastosowania diagramów aktywności UML do specyfikacji wymagań dotyczących zachowania sterownika logicznego. Lista wymagań podlegających weryfikacji zwykle definiowana jest bezpośrednio za pomocą formuł logiki temporalnej. Użycie przyjaznych dla użytkownika, powszechnie znanych i wykorzystywanych diagramów pozwala na prostsze i bardziej intuicyjne zapisanie wymagań. Diagramy są następnie formalnie przekształcane do formuł liniowej logiki temporalnej (LTL).
EN
The article introduces an idea to use UML activity diagrams [1-5] for specification of requirements regarding logic controller behavior. Requirements list to be verified [14] (using model checking technique [6, 7]) is usually directly defined using temporal logic formulas [12, 15]. Using user-friendly, commonly known and practiced diagrams allows to easier and more intuitively write down the requirements easier and more intuitively. Activity diagrams are then formally transformed into linear temporal logic (LTL) formulas. In this paper some sample UML activity diagrams which specify global properties are presented, together with their interpretation using LTL logic. To perform model checking process, model description (based i.e. on a control interpreted Petri net [8] or indirectly on an UML activity diagram [11]), and requirements list are needed. Afterwards it is checked, whether defined properties are satisfied in specified model description. If a requirement cannot be fulfilled, appropriate counterexample is generated allowing to localize error source. The article is structured as follows. Section 1 is an introduction. Background of a logic controller specification and its verification is presented in section 2. A novel approach to logic controller requirements definition using activity diagrams is shown in section 3. The paper ends with a short summary.
PL
Specyfikacja zachowania projektowanego urządzenia powinna uwzględniać wszystkie elementy behawioralne. Z uwagi na złożoność projektowanych systemów szczególnie istotną rolę odgrywa możliwość dekompozycji. Z wykorzystaniem hierarchii można podzielić specyfikację na logiczne elementy połączone ze sobą na diagramach wyższego poziomu. W artykule przedstawiono zagadnienia związane z formalną weryfikacją hierarchicznych specyfikacji sterownika logicznego wyrażonych za pomocą interpretowanych sieci Petriego oraz diagramów aktywności języka UML.
EN
Specification of a designed logic controller should include all behavioral aspects. By complex systems design decomposition is especially valuable. Specification can be divided into parts using hierarchy. Logical elements are joined together at higher-level diagrams. The paper focuses on formal verification [1] of logic controller hierarchical specification by means of UML activity diagrams and interpreted Petri nets. Although hierarchy itself is presented in the considered specification techniques in different ways (complex activities by UML activity diagrams and macro-places/ macrotransitions by Petri nets), it is possible to use both techniques together in one project and to transform anytime one diagram into the another [5, 9, 10] (example in Figs. 1 and 2). In the transformation process, UML activity diagram actions correspond to Petri net transitions [7, 8]. Model checking [2, 3] of hierarchical specification can be performed step by step, e.g. by means of the NuSMV tool [11]. Rule-based specification (based on a Petri net) can be checked against behavioral properties [12, 13] expressed by temporal logic formulas [4]. Macroplaces can be verified separately (Fig. 3 considering local properties) and/or concurrently (Fig. 4, Fig. 5 considering mutual correlation and global properties). Next, the whole Petri net with macroplaces can be checked (Fig. 6). Sometimes it is convenient to verify a complete net (not hierarchical), like in [14]. Formal verification of specification can significantly increase its quality, and the support for hierarchy simplifies complex systems verification.
3
EN
The paper presents a novel approach to rule-based logic controller specification and its verification. The proposed abstract model is suited for formal verification (using model checking technique) as well as for logic synthesis (using hardware description language VHDL). Special focus is put on Interpreted Petri Nets with inhibitor and enabling arcs, their realization in rule-based model and, additionally, their interpretation in another logic controller specification technique - UML Activity Diagrams (version 2.x).
PL
Artykuł przedstawia nowatorskie podejście do regułowej specyfikacji sterownika logicznego, wraz z jej weryfikacją (walidacją). Proponowany abstrakcyjny model logiczny jest dogodny zarówno do formalnej weryfikacji modelowej, jak również do syntezy logicznej (język opisu sprzętu VHDL). Szczególną uwagę poświęcono łukom zakazującym i zezwalającym interpretowanych sieci Petriego. Po krótkim wprowadzeniu do omawianej tematyki (rozdział 2), przedstawiono przykład interpretowanej sieci Petriego z łukami zakazującymi i zezwalającymi (rys. 1). Podano sposób ich realizacji w abstrakcyjnym modelu logicznym (rozdział 3, schemat kompletnego proponowanego systemu na rys. 2 oraz przykład regułowego modelu sterownika logicznego na rys. 3). Zaproponowano interpretację łuków zakazujących i zezwalających sieci Petriego w innej postaci specyfikacji zachowania sterownika logicznego (rozdział 4) - diagramach aktywności języka UML (w wersji 2.x). Ze względu na bezstanowość diagramów aktywności, nie jest możliwe bezpośrednie odwzorowanie rozpatrywanych łuków. W artykule zaproponowano dwa rozwiązania - opierające się na wprowadzeniu dodatkowego sygnału (rys. 4a) oraz alternatywne - bazujące na etykietowaniu przepływów (rys. 4b). Przedstawiono sposób formalnej weryfikacji tak przygotowanej specyfikacji regułowej oraz jej syntezy logicznej (rozdział 5). Publikacja kończy się podsumowaniem oraz wnioskami (rozdział 6)
EN
Behavioural specification is one of the most important steps in embedded systems design. This phase play a key role cause in this step the shape and behaviour of the final product is established. The process can be realized with use of various technologies and tools supporting the phase. Two of the technologies supporting behavioural modelling are UML activity diagrams and Petri nets. The paper presents transformation of UML activity diagrams into control interpreted Petri nets. Transformation is targeted for project in which both technologies are used in parallel. The system described in the paper is realized as a bridge between mentioned modelling technologies fully supporting automation of the transformation process. Moreover, the system enables use of additional techniques such as formal verification or hardware description language code generation.
PL
Specyfikacja zachowania systemu jest jednym z kluczowych elementów procesu projektowania sterowników logicznych. Etap ten odrywa ważną rolę ze względu na fakt definiowania kształtu i sposobu zachowania docelowego produktu. Może ona zostać wykonana na wiele sposobów z wykorzystaniem różnych narzędzi wspomagających ten proces. Jednymi z technologii, w których istnieje możliwość opisu zachowania docelowego urządzenia, są diagramy aktywności języka UML i sieci Petriego. Artykuł przedstawia koncepcję transformacji pomiędzy diagramami aktywności języka UML a interpretowanymi sieciami Petriego sterowania. Transformacja dedykowana jest dla projektów, w których inżynierowie wykorzystuję obie wspomniane technologie. Dodatkowo omówiony w artykule system do transformacji ma na celu stworzenie mostu pomiędzy obiema technologiami w pełni automatyzując proces przemieszczania się pomiędzy nimi. Umożliwia on także wykorzystanie dodatkowych narzędzi wspomagających proces projektowania, takich jak formalna weryfikacji czy generowanie kodu w językach opisu sprzętu.
PL
Proces specyfikacji zachowania odgrywa istotną rolę z powodu określania na tym etapie cech i sposobu funkcjonowania sterownika logicznego. W artykule omówione zostały dwie metody graficznego specyfikowania zachowania sterowników logicznych - diagramy aktywności języka UML 2.x oraz sieci Petriego sterowania. Zaproponowana została metoda transformacji hierarchicznych diagramów aktywności do hierarchicznych sieci Petriego. Dzięki przedstawionej metodzie możliwe jest połączenie zalet obu typów graficznego opisu specyfikacji urządzeń. Dodatkowo, zaproponowana została metoda formalnej weryfikacji hierarchicznej formy specyfikacji umożliwiająca wykrycie potencjalnych błędów na tym wczesnym etapie projektu.
EN
Behavior specification is one of the most important steps in embedded systems design. It plays a significant role because system properties and functionality are specified in this phase. There exist some techniques which can be helpful for a designer. In the paper two methods for graphical specification of logic controller behavioral specification [1, 2, 6], namely UML 2.x activity diagrams [10] and control Petri nets [11], are considered. A novel transformation method for transformation of hierarchical activity diagrams into hierarchical Petri nets is proposed. The presented method allows combining the advantages of both types of graphical system specification. Additionally, a formal verification method for hierarchical specification form is proposed. It enables detecting potential errors at early stage of system development. Hierarchical form of specification is commonly used in design process. Activity diagrams can include complex actions (Fig. 1) which describe some subprocesses. Petri nets also support hierarchy, but it can be realized in two different forms [9] - as macroplaces or macrotransitions (Fig. 2). According to the transformation method from [3, 8], actions in activity diagrams are interpreted as transitions in Petri net. In hierarchical processes by means of Petri nets two elements, macrotransitions (Fig. 3) and macroplaces (Fig. 4), have to be considered. The macroplace (Fig. 5a) can be surrounded by two transitions (Fig. 5b), decomposed (Fig. 5c), and finally compressed to macrotransition (Fig. 5d), then transformed into complex activity in an UML 2.x activity diagram (Fig. 5e). Verification of both considered specification forms [3] allows comparing two versions of the same behavior description. The model checking technique [4] can be used to verify the whole system or a part of it. Partial verification can be used for hierarchical specifications, as the verification process can be performed step by step (Fig. 6).
PL
Język UML jest technologią powszechnie stosowaną w świecie naukowym oraz w przemyśle. Sieci Petriego są modelem matematycznym ogólnego zastosowania ugruntowanym od wielu lat. Obie te techniki doskonale nadają się do specyfikacji procesów sterowania. Jednakże jako odmienne, każda z nich posiada unikatowe właściwości. Technika weryfikacji modelowej jest jedną z metod formalnej weryfikacji specyfikacji pozwalającą na zdiagnozowanie błędów w specyfikacji wymagań albo w opisie modelu. Artykuł przedstawia metodę transformacji pomiędzy obiema wymienionymi technikami specyfikacji w celu formalnej weryfikacji projektu sterowania opisanego w języku UML.
EN
Unified Modeling Language (UML) [1-3, 5, 6-8] is commonly used in scientific and industrial world. Petri nets [9] are mathematical model used for a long period of time. Both techniques are well suited for control processes specification. However, they are quite different. Each technique has its own unique properties. Model checking technique [14-17] is one of formal verification methods [18] for specifications. It allows detecting errors either in requirements specification or in model description. The paper presents the method for transformation between both mentioned specification techniques - from UML activity diagram (Fig. 1) to Petri net (Fig. 4), using some defined rules [10, 11]. Mapping of particular elements is presented in Table 1. Petri net after direct transformation may include redundant places which can be after-wards removed. Then, it is possible to formally verify control process described in UML. The proposed model checker tool is NuSMV [20]. NuSMV (Fig. 5) compares model description (Fig. 6 - 8) and requirements (Fig. 9) which have to be fulfilled. The requirements are defined using temporal logic. If a specified requirement may not be fulfilled, appropriate counterexamples are generated (Fig. 10) which allow detecting an error source. Then, the specification can be corrected and model checking process can start again, sometimes including only the particular part of a designed system.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.