Basic Statechart: A Formalism to Model Industrial Applications

Basic Statechart: A Formalism to Model

Industrial Applications

Raimundo Santos Moura ∗, Luiz Affonso Guedes ∗∗

∗ Department of Informatics and StatisticsFederal University of Piaui, Teresina, Brazil

e-mail:[email protected]∗∗ Department of Computer Engineering and AutomationFederal University of Rio Grande do Norte, Natal, Brazil

e-mail:[email protected]

Submitted: 21/12/2009Accepted: 05/01/2010Appeared: 16/01/2010c©HyperSciences.Publisher

Abstract: Despite the many studies that have attempted to develop “friendly” methods forindustrial controller programming, they are still programmed by conventional trial-and-errormethods, and there is little written documentation on these applications. Accordingly, thispaper proposes a methodology to model plant and control programs for manufacturing systemsthat include sequential, parallel and timed operations, using a formalism based on Statechartdiagrams, denominated Basic Statechart (BSC). To improve the formal aspects of theoriginal Statecharts, we introduce the semantic of the Basic Statecharts using only characteristicsrelevant to the industrial area. We also present an algorithm to create a reachability tree forBSC models and analyze some properties about the complete model (plant and control) of theseapplications. One typical example of application in the manufacturing area is presented as casestudy to illustrate the proposed methodology.

Keywords: Industrial applications, Discrete event systems, System modeling and validation,Programmable logic devices, Basic Statecharts.

1. INTRODUCTION

Based on the IEEE Standard Glossary of Software En-gineering Terminology (IEEE-Std 610.12 1990), “a sys-tem can be regarded as a collection of components or-ganized to accomplish a specific function or set of func-tions”. The key point in this definition is the interactionamong system components. Cassandras and Lafortune, in(Cassandras & Lafortune 2008), discuss systems classifi-cation, especially for Discrete Event Systems (DES). Intheir definition, DES are systems that have discrete statespace and an event-driven dynamic, i.e., the state can onlychange as a result of instantaneous events occurring asyn-chronously over time. In this context, state-based methodssuch as Finite State Machines (FSM) and Petri Nets havebeen traditionally used to describe these systems.

The automation area uses concepts of system theory tocontrol machines and industrial processes. Consideringan industrial automation process based on ProgrammableLogic Controllers (PLC), the sensors are installed in theplant and generate events that represent input variables tothe PLC. The actuators are associated with the actionsproduced by the PLC program and represent outputvariables.

Industrial controller programming is currently performedby qualified technicians using one of the five languages

defined by IEC-61131-3 (IEC 61131 1993) standard andwho seldom have knowledge of modern software tech-nologies. Furthermore, controllers are often reprogrammedduring the plant operation life-cycle to adapt them tonew requirements. As a result, “for practically no im-plemented controller does a formal description exist”(Bani Younis & Frey 2006). By the way, PLC are stillprogrammed by conventional trial-and-error methods andthere is no written documentation on these systems.

On the other hand, in the academic field there are severalproposals for the systematic synthesis of controllers, suchas Supervisory Control Theory developed by Ramadge andWonham in the 1980’s(Ramadge & Wonham 1989). Thistheory is based on formal aspects of the automata thatautomate controller synthesis. However, despite advancesin this area, the scientific community has not managed toconvince industrial engineers to migrate from traditionalprogramming methods to the new approaches. Skoldstamet. al. (Skoldstam et al. 2008) indicate two main causesfor the failure of Supervisory Control Theory to imple-ment real world controllers: i) the discrepancy betweenreality based on the signal and the event-based automataframework, and ii) the lack of a compact representationof large models. In more general aspect, Gourcuff et al.(Gourcuff et al. 2006) present three reasons for not adopt-ing formal methods in industry: i) formal specification

Journal of Modelling and Simulation of Systems (Vol.1-2010/Iss.1) Moura and Guedes / Basic Statechart: A Formalism to Model ... / pp. 22-33

Copyright © 2010 HyperSciences_Publisher. All rights reserved 22 www.hypersciences.org

Basic Statechart: A Formalism to Model Industrial Applications 2

of properties in temporal logic or in the form of timedautomata is an extremely difficult task for most engineers;ii) model-checkers provide, in the case of negative proof,counterexamples that are difficult to interpret; and iii)PLC manufacturers do not provide commercial softwarecapable of automatically translating PLC programs intoformal models. Therefore, the use of higher-level method-ologies could be useful in developing of controller program-ming. However, it poses a great challenge to industry. Inaddition, to remain focused on the formal aspect is veryimportant for analysis, validation, and verification of themodels, but it must be abstracted for the designers to fullyunderstand the system.

In the Computer Science area, several models guidethe software development process, such as the Water-fall Model (Royce 1970), a sequential software devel-opment model in which development is seen as a se-quence of phases; the Spiral model (Boehm 1988), aniterative software development model that combines ele-ments of software design and prototype stages; and ag-ile methods, which emerged in the 1990. Examples ofthe latter are: Adaptive Software Development, Crystal,Dynamic Systems Development, eXtreme Programming(XP), Feature Driven Development, and Scrum. Boehm,in (Boehm 2006), presents an overview of the best softwareengineer practices used since 1950 (decade to decade) andhe identifies the historical aspects of each tendency.

In several software development models, the life-cycle usedcan be divided into three phases: Modeling - Validation- Implementation (see Figure 1). The “Modifications”arc represents multiple iterations that can occur in soft-ware modeling processes. The “Reengineering” arc repre-sents the research area that investigates the generation ofa model from the legacy code. Our focus is on forward en-gineering, which investigates model generation from user-specified requirements.

ModelingValidation

andTests

Implementation

Requirements

Modifications

Objectcode

modelmodel

model

Re-

engin

eeri

ng

Fig. 1. Application life-cycle: overview

Owing to the aforementioned problems, the main objectiveof this paper is to propose a methodology for plantand control modeling of the manufacturing systems thatinvolve sequential, parallel and timed operations, using anew formalism based on Statecharts, denominated as BasicStatecharts. For the validation phase, the reachability treeof complete model (control + plant) has been created

and its analysis must show that the model ensures theproperties of reinitiability, vivacity, and that there isno deadlock.

Although there are several formalisms for DES modeling,we propose the Basic Statechart for three main reasons:i) to allow formal validation of the models; ii) to be ahigh-level formalism, making controller design easier forindustrial engineers; and iii) to use Statecharts propertiesto model complex systems, a task that is very difficult inautomata or Petri net-based approaches.

The remainder of this paper is organized as follows: Section2 defines the Basic Statecharts and discusses the concep-tual model used to model the plant and control softwareof the applications. Section 3 describes a methodology tomodel the plant and control software for manufacturingsystems, based on the PLC. Section 4 present the algo-rithm used to create the reachability tree of the BSC alongwith the validation technique used. One typical applicationis used as case study in Section 5, which analyses twoexamples of controllers, one sequential and other parallel,modeled by the our approach. In the last section, weconclude with a discussion about future projects.

2. BASIC STATECHARTS

The original Statecharts were described by David Harel inthe 1980s and it extends conventional automata with no-tions of hierarchy, concurrency, and broadcast com-munication. Statecharts have a compact graphic rep-resentation that can be translated into automata, ac-cording to the description in (Drusinsky & Harel 1989).Hierarchy and concurrency are represented through OR-decomposition and AND-decomposition, respectively. Itis worth mentioning that Statecharts do not explicitlyenumerate all the system states. Therefore, an implicitcombination of the parallel states must be performed toobtain the real configuration of the model; that is, the realstate of the system.

The absence of a formal semantic of the original State-charts makes the verification of these models very complexto carry out. In an attempt to minimize this problem,several Statechart variants were defined. Michael von derBeeck, in (Beeck 1994), makes a comparison between 20variants, and discusses a number of problems related tothe original Statecharts. In addition, the broadcast com-munication of the Statecharts allows a triggered event inone state to affect another state that has no dependentrelation with the former. Another drawback of the originalStatecharts is that they allow interlevel transitions withoutimposing any constraints, a situation that can generateunstructured models.

To incorporate the advantages of the original Statechartsand to avoid the aforementioned problems, we proposea formalism to model DES based on UML/Statechartdiagrams, but with a more limited syntax and semantic,denominated Basic Statechart (BSC).

2.1 Basic Elements

The BSC uses the syntax of UML/Statecharts with somevariations; for example: i) absence of history connectors;


23


ii) inclusion of input/output data channels to allow explicitcommunication between the components and to avoidbroadcast messages in the system; and iii) the transitionsare represented by the expression “[condition]/action”.The conditions are composed using variables, data chan-nels and the logical operators AND, OR and NOT. Theactions allow one to change the value of these variables.The semantic of Basic Statecharts is more restrictive thanthat of UML/Statecharts to avoid conflict and inconsis-tency in model evolution. We believe that this semantic ismore appropriate for modeling industrial systems.

The conceptual model describing the relationship betweenthe elements that make up a BSC diagram is shown inFig. 2.

Fig. 2. Basic Statecharts : conceptual model.

Definition 1. A BSC component is a structure used tomodel the behavior of a system element.

A component can contain states, input/output channels,internal variables, and other components, which can becalled subcomponents. The state of the component hasthe same semantic as Statecharts, and can be: i) BASIC,when it does not have children; ii) OR, has only one activestate at the moment; and iii) AND, when its children arerun in paralell way, i.e., there is more than one active statesimultaneously.

Definition 2. A data channel is a resource used to makecommunication between system components.

The input data channels are implicitly associated withinternal variables and thus their values are maintainedduring the entire execution cycle. They can be used tochange the value of guard condition from the componentor external entity, such as control software or a simulationenvironment. The output data channels are also asso-ciated with internal variables; however, their values areupdated only at the end of the execution cycle. They areused to publish the status of internal elements from onecomponent to another.

Definition 3. A internal variable is a local memory intoboth the component and its subcomponents.

The value propagation of these variables occurs in thesame execution cycle of the model. There are four basictypes of variable in BSC: bool, int, real, and timer. Inthis paper only bool and timer are used, but the otherscan be easily included in the projects.

2.2 Semantics of the BSC

The communication mechanism follows a publish/subscribepattern: the variables associated to output channels arepublished in a global area, and the variables associated toinput channels are consumers of these data. It is importantto note that a component can be both publisher and sub-scriber of a same data item. However, the published valuein one step is only consumed in the next step. It is alsovalid for different components. Moreover, one publishedvalue can be updated by several components in a samestep, but the value of all components is guaranteed to bethe same.

Timers are quite common in industrial applications; forexample: an actuator must execute for a specific time, oran actuator must execute only after a specific time.

The timers are modeled through basic components andtheir current values can be used to set the guard conditionsof the transitions in BSC. Furthermore, they can be startedand/or reset by some action of the model. Timers areglobal structures that have two proprieties: one used toenable/disable it and another to verify if it has reachedthe timeout. They belong to the component where it wascreated, and they only can be enable/disable for thiscomponent, through the actions tm = 1 and tm = 0,respectively. However, all components of the model canto access/consume their proprieties.

Timers are controlled by a global real-time clock thatexecutes in parallel to the system model, and they areupdated only at the beginning of each execution cycle.Thus, when a timer is enabled in a component, the timingprocess is initiated in the next execution cycle. When thetimer reaches or surpasses its specified limit, an internalvariable tm is made true (tm = true) to indicate end oftiming. In the timer, creating must define the time limitvalue in time units in format defined by the IEC 61131-3 standard, for example, “T#3s” defines time limit valueequal to 3 seconds.

The evolution of the BSC dynamic behavior is performedby sequential steps, called the execution cycle. One con-straint that is ensured by the BSC is that a componentcomposed of basic states can only trigger one tran-sition in each execution cycle (macrostep). As withoriginal Statecharts, each macrostep in BSC can be dividedinto several microsteps; however, the actions performedwhen one transition is triggered only update the variablesdefined in the component data area. Moreover, the BSCrun accordance with definition order of the components.Thus, in an execution cycle only one component can af-fect the components subsequently defined in the model.


24


This point represents a difference between the proposedapproach and the Harel diagrams specified by UML.

2.3 Formal Description

Basic Statecharts make the definition of validation tech-niques more practical, because their syntax and semanticare more constrainted than those of the original State-charts. Considering the previous definitions, a Basic Stat-echart can be, formally, defined as follows:

Definition 4. A Basic Statechart BSC is a 7-tuple

BSC = (S, p, s0,Ψ, δ, T,M)

where

• S is a finite set of states and parallel states;• p : S → 2S defines a tree structure with substate

descendants, i.e., direct children or children of de-scendants. Functions p∗ and p+ are extensions of p,defined by

p∗(x) =⋃

i≥0

pi(x)

and

p+(x) =⋃

i≥1

pi(x)

where pi(x) is the set of direct descendants of state“x” in hierarchy i. By the definition, p0(x) = {x}.Therefore, p∗(x) is the set of states containing “x”and all of the descendants in the hierarchy, and p+(x)is the set containing all of the descendants of “x”,except itself;

• s0 ∈ S is the initial state (root of the tree of the BasicStatechart), where ∀x ∈ S, s0 6∈ p(x);

• Ψ : S → {BASIC,AND,OR} is a function that de-scribes the type of state decomposition. For example,x ∈ S is “BASIC” if p(x) = ∅, i.e., a state withoutsubstates;

• δ : S → 2S is a default function, that defines a setof initial states for state x ∈ S, if x is not “BASIC”.If x is an “OR” state, it has only one default state;on the other hand, if x is an “AND” state, thenδ(x) = δ(p(x));

• T is a finite set of transitions (X, c,Ai, Y ), whereX ∈ S is the source state; c is a guard conditionused to enable/disable the transition. It is describedby one combination of variables and/or data definedin the datamodel area; Ai is a set of actions thatmust be executed when the transition is taken; Y ∈ Sis the target state. Informally, a transition can berepresented by the expression “[c]/a”, where theseelements are optional;

• M : S → { input/output channels and variables } isa function that defines the datamodel area of a statex ∈ S, if x is not “BASIC”.

3. PLANT AND CONTROL: MODELING

In industrial applications, normally the controller softwareis verified in conjunction with a model of the plant in which

it operates. So, it is necessary to obtain an accurate modelto maintain fidelity with the real plant (relation one-to-one).

3.1 Plant: Modeling

For plant modeling, our methodology is based on thehybrid approach - bottom-up and top-down. More specif-ically, it proposes to model the basic elements, groupingthem into larger structures. This process is repeated untilit generates the appropriate model of application. Themethodology consists of three phases described as follows:

(1) Modeling the basic application elements or usingmodels already defined in a component repository;

(2) Decomposing the basic states in substates, if neces-sary;

(3) Representing all automation plant components asparallel states.

Phases 1 and 2 consist of modeling and refinements ofthe basic elements which compose the application. Theycan be run several times as an iterative process. In eachiteration, we work with components which are more andmore complex. Further, these components can be groupedin a repository. The third phase determines that all appli-cation components must be executed at the same time, ina parallel way, where the communication between them ismade by input/output channels. We will present how ourmethodology works below.

Basic Components For automation systems, many com-ponents follow an On/Off pattern, for example, valvesand sensors. Fig. 3-a shows the dynamic behavior of thispattern, which can be in states: “Off” or “On”, and twotransitions to change from state: “[g1]” from “Off” to “On”and “[g2]” from state “On” to “Off”. Other componentsrequire adjustment in modeling to include new character-istics. For example: a temporary state (Wait) between thestates “On” and “Off” (see Fig. 3-b).

OnOff AlterOnOff

[g2][g1] [g2][g1]

[g3]

[g4]

Fig. 3. On/Off patterns: basic models.

Cylinder Component In the manufacturing field, one ofthe most common components is the pneumatic cylinderthat can be composed of more simple components (valves,arms and sensors) and can have displacement sensors/end-position initiators.

Fig. 4 depicts a single-action cylinder with advancingcontrolled by the valve, return carried through springs,and one end-position sensor which is triggered when thecylinder arm gets the full advance. In this figure, chis an input data channel, s is an output data channel,v1 and v2 are internal variables, and tm1 is a timerwhich define, implicitly, two I/O channels: tm1.tm (input)


25


and tm1 (output). The generic notation “[g]/A” in atransition means that: when a guard condition g is true,the action A will be executed. Therefore, if an actionin a component X1 updating one variable used in guardcondition of a component X2, then we will say that:X2 depends on component X1. According to figure, thetransition “[ch]/v1 = 1” and “[v1]/tm1 = 1” indicatethat: the cylinder arm depends on the valve, i.e., the armadvances while the valve remains open. When the valve isclosed through the action “ch = 0”, the cylinder arm gets“Returned”, in function of transitions “[v1]/tm1 = 0 or“[v1]/v2 = 0”.

ArmValve

Returned

Advancing*

Off

On

[v1]/tm1=1

[ch]/v1=1

Sensor

False

True

[v2]/s=1Advanced

[v1^tm1.tm]/v2=1

Cylinder Component

[ch]/v1=0

[v1]/tm1=0

[v1]/v2=0

[v2]/s=0

s

tm1stm1tm1.tm

ch

tm1.tm ch

Input:

Output:ch

s

Memory:bool: v1, v2timer: tm1(T#2s)

Fig. 4. Single-action cylinder: basic model.

The cylinder arm has the following behavior: when thevariable v1 gets true, the arm gets to “Advancing” in aspecified time, which depends on technical characteristicsand it is represented by “*” in the figure. If the valveis closed before this specified time (event tm1.tm), thecylinder arm gets to “Returned” and nothing happens tothe sensor. If the event tm1.tm occurs, then the arm getsto “Advanced” and the active state of the sensor passesfrom “False” to “True”, implicitly. So, when the valve isclosed, the arm gets “Returned” and the sensor passesfrom “True” to “False”.

The scenario that describes the desired operation of thecylinder is very simple: one external event allows theopening of the valve when the input channel gets equal1 (ch=1); then the transition “[ch]/v1 = 1” is run; andafter the sensor detects the total advance of the cylinder-arm, the valve must be closed (data channel equals 0, i.e.,ch=0); then the transition “[ch]/v1 = 0” is run. The eventsto open/close the valve represent the control police that isrun by the model and define the dynamic of the cylinder.

3.2 Control Software: Modeling

In the manufacturing area, actuator components are con-trolled through events that are triggered by devices, suchas buttons, sensors, and timers, which are defined in thecontrol model using temporary variables. The controlleris modeled through the composition of components; i.e.,complex models are constructed from simpler models. Thebasic components are: a) actuators that are modeled us-ing components with two states: OFF and ON; b) timersthat are modeled using components with three states:OFF, START and ON - the state “START” starts thetimer and the transition “Tm1.tm” from state “START”to state “ON” triggers the end of the timer event; andc) variables that are associated with input channels andtemporary elements. Fig. 5 shows the basic model for theseelements. In this figure, g1, g2, and g3 are guard condi-tions. For example, the datamodel area in Fig. 5-c defines

two Boolean variables (s1 and s2), both with the “false”value, using the syntax of the SCXML (SCXML 2006) thatis a XML specification for Statecharts from W3C.

Off

On

[g1]/A=1

[g2]/A=0

Timer T

Off

Start

[g3]/Tm1=1

[Tm1.tm

]

On

<datamodel><data name=“s1” expr=“false”/><data name=“s2” expr=“false”/>

</datamodel>

Actuator A

(a) (b) (c)

/Tm1=0

Fig. 5. Actuators: basic model.

Operational requirements of the actuators are inserted intothe model as transitions between the states, in the follow-ing general form: “[guard condition] / action”. The guardconditions are Boolean expressions composed of data chan-nel and internal variables, interconnected through logicalconnectors ¬ (negation), ‖ (disjunction) and & (conjunc-tion). The actions can be, for example, an assignmentstatement to set a value in the variable and/or data chan-nel. Therefore, operational requirements are constraints inthe model to implement dependencies and/or interactionsbetween the components. Such constraints allow us todefine sequential and parallel behavior in the model; thiswill be described in the next subsections.

Sequential Operation Consider a plant composed of twoactuators (Ai and Aj) that run sequentially one afterthe other, i.e., Ai;Aj . This sequence is run continuouslyin a cyclical way until user intervention. The sequentialbehavior of Ai and Aj is obtained through the executionof actions in actuator Ai, which generates internal eventtriggers in actuator Aj . In general, an action in an actuatorcan cause state changes in other actuators.

Fig. 6-a shows the Basic Statechart diagram for modelingthe sequential behavior between actuators Ai and Aj

discussed above. In this figure, ch1, ch2 and ch3 areinput data channels; ch1, Ai and Aj are output datachannels, and ev is an internal variable. Note that asame channel can be both input and output channel in amodel. This is possible because the channels are associatedimplicitly with internal variables. These elements are usedto generate the desired model behavior. In this case,the “ev” variable is used as an action by actuator Ai,which indicates the end of its actuation. It is perceivedby actuator Aj , which starts its operation, generating thesequential behavior between them. Note that the datamodel area is not represented in the figure. At the end ofAj actuation, data channel ch1 is updated, generating thecyclical behavior of the model. In its initial configuration,all the actuators of the model are set to “Off”. The systemstarts its operation when data channel ch1 is equal to 1(Boolean value “true”), a situation that can be simulatedwhen the operator pushes a “start” button on the InterfaceHuman-Machine (IHM), for example.

Parallel Operation Parallelism, an inherent characteris-tic of original Statecharts, is accomplished through AND-decomposition. However, the component synchronism de-mands additional mechanisms. Consider a plant composedof three actuators (Ai, Aj and Ak), where Ai and Aj run in


26


parallel, but Ak can only run after the execution of the twofirst components, i.e., (Ai||Aj);Ak. This sequence is runcontinuously in a cyclical way until operator intervention.The parallel behavior of Ai and Aj is obtained naturally;however, internal variables must be used to generate in-ternal event triggers in actuator Ak to indicate the end ofexecution in other actuators. Thus, Ak must wait for theseupdates to start its operation. After the Ak run, theseinternal variables must be updated to allow the executionof a new cycle in the system.

Fig. 6-b shows the Basic Statechart diagram for modelingthe parallel behavior between the aforementioned actua-tors. In this figure, chi(i = 1 . . . 5) are input data channels,Ai, Aj and Ak are output data channels, evi and evj areinternal variables. These elements are used to generate thedesired application behavior. In this case, the variable evi

is updated as an action by actuator Ai, indicating the endof its actuation, and the variable evj is updated to indicatethe end of Aj actuation. These updates are perceived byactuator Ak, which starts its operation, generating thesynchronism between them. At the end of Ak actuation,the evi and evj must be “reset” to generate the cyclicalbehavior of the model. In its initial configuration, themodel must have all actuators set to “Off”.

Timed Operation Consider a plant composed of anactuator Ai and a timer Tk, where Ai must act fort seconds before turning off. Fig. 6-c shows the BasicStatechart for modeling the temporal behavior of actuatorAi, controlled by timer Tk. In this figure, ch1 and ch2 areinput data channels used to start the operation of actuatorAi and of timer Tk, respectively, and tk.tm is an input datachannel used to indicate the timeout of Tk. The timers areupdated as a global action of the model, and, the timer Tk

is started when action tk = 1 is executed.

The guard condition “ev” used to turn off actuator Ai

becomes true when timer Tk reaches or surpasses thespecified limit (condition tk.tm). Thus, the constraint thatdefines that actuator Ai must execute for a specific timeis ensured.

4. CONTROL SOFTWARE: VALIDATION

The approach for modeling the control software discussedin Subsection 3.2 maintains the description and speci-fication aspects built into the Basic Statechart model.Transitions, guard conditions, and implicit actions areused to describe system constraints. Thus, the approachallows us to analyze some controller properties using thereachability tree of the formal model. Moreover, simulatedenvironments can be used to validate the control modelalong with the plant model.

For creating the reachability tree of the Basic Statecharts,we must consider all possible configurations generated bytransition triggers, which are interpreted as events thatoccur in the model. Thus, for automatic generation of theseevents, one simulation is executed with an adaption in theBSC model, that is: to include one extra component asan interface between the user and the model, known asHuman-Machine Interface (HMI). The HMI is a compo-nent that executes in parallel way with the system, andmust be defined as a first component in the model to

Off

On

Ai

Csequential

[ch ]/1

Ai=1

[ ]/ch2

A =0 &ev=1 &ch =0

i

1

Off

On

Aj

[ev]/

Aj=1[ ]/ch3

A =0&ch =1

j

1

Off

On

Ai

Cparallel

[ ]/ch2

A =0&ev =1

i

i

Off

On

Aj

[ ]/ch4

A =0&ev =1

j

j

Off On

Ak

[ /ev & evi j]

A =1k

[ ] /ch5 A =0 &ev ev =0

k

i=0 & j

Off

On

Ai

Ctimed

[ ]/ch1

A =1i

[ ]/evA =0i

Tk

Off

Start

[ ]/ch2

Tk=1

[tk.tm

]/ev=1

On

(a)

(b)

(c)

ch1

ch2

ch3

ch1

ch2

ch1

Ai

ch3 ch1

Aj

ch1

Ai

Aj

tk.tm

ch1

ch2

ch1 Ai /Tk=0

ch2

tk.tm

Tk Ai

Tk

chi

(i=1..5)ch1

ch2

Ai Ajch3

ch4

ch5 Ak

Ai

Aj

Ak

[ ]/ch &ev1 i

A =1i

[ ]/ch &ev3 j

A =1j

Fig. 6. Control model: operations

guarantee that its actions will be executed in the samemacrostep. This component is composed by two parts: onepanel to simulate the input events, for example, press ofthe button, one piece in a position, and so on; and oneglobal clock to control the timed events of the model, forexample, timeout of the timer variable or component.

Masiero et al., in (Masiero et al. 1994) propose an algo-rithm to create a reachability tree for Statecharts. Here,we discuss an adaptation of this algorithm to generate thereachability of the BSC that is presented using pseudocodein Algorithm 1. In the algorithm are used some terms,which represent data structures, functions and/or datatypes, with the following descriptions:

• CQ - is a queue of configurations;• TREE - is a root of the reachability tree;• T - is any transition;• C0, C and C ′ - are the configurations: initial, active,

and next, respectively;• SRC and SRC ′ - are set of possible transitions from

the active and next configurations, respectively;• C ′with DM - represents the current configuration of

the model with data module, i.e., the configurationof the active states and the values of the datamodelvariables;


27


• The structure of the model configuration containsthe attributes: name, type (if NEW, OLD or TER-MINAL), states, possible events, data module(DM), path (from initial configuration C0) and thedescendant configurations.

Algorithm 1 Reachability Tree for SCB.

1: Create an empty queue CQ;2: Make C0 the root of the reachability tree

TREE;3: Insert C0 in CQ;4: while (CQ 6= EMPTY ) do5: Remove C from CQ;6: Let C be the BSC configuration;7: Obtain SRC, the set all possible transitions

for C;8: if (SRC 6= EMPTY ) then9: while (SRC 6= EMPTY ) do

10: Let T be the first transition in SRC;11: Compute the step for T obtaining C ′;12: Create a node with C ′

13: if (C ′with DM NOT exists in TREE) then14: Make node C ′ a new configuration;15: Obtain SRC ′, the set all possible tran-

sitions for C ′;16: Remove the transition T from SRC ′, if

T ∈ SRC ′;17: if (SRC ′ = EMPTY ) then18: Remove all transitions from C ′;19: Insert transition “ empty” to stabilize

the model;20: end if21: Insert C ′ in CQ;22: else23: Make node C ′ an old configuration;24: end if25: Insert C ′ in TREE as a son of C;26: Label the arc from C to C ′ as “<event-

exp>”;27: Reinstate C as the active configuration;28: Remove the transition T from SRC;29: end while30: else31: Make node C a terminal configuration;32: end if33: end while

The reachability tree of the model allows us to analyze anumber of properties, such as:

• reachability – let s be a sequence of transitions(events). From C0, does the sequential trigger of sreach a valid configuration? This property is used toverify if bad sequences occur in the model. In thiscase, we must be made changes in some transitions ofthe path, with intent of avoid such sequences;

• reinitiability – for each Ci state configurationreached from the initial C0 configuration, is it possibleto return to C0 by a sequence of events? This propertyis used to verify if this model is cyclic - desire featurein systems of the industrial automation field. Pathsin tree that reach non-reinstate must be reanalyzed.

• vivacity – does the controller act in all of the com-ponents in the model? In negative case, the controllercontains some errors or these elements do not be im-portant for the plant and, therefore, can be removed

of the model. In this case, we must be made changesin such components.

• deadlock – is there a Ci state configuration in whichprogress cannot be made because no transition canbe triggered? This situation is identified when oneterminal configuration is reached in tree. Deadlocksmust be avoided, therefore, changes must be made atleast one transition of the path from C0 to terminalconfiguration.

Finally, these properties do not guarantee the right oper-ation of the system, but they help to identify bottlenecksin the control policy.

5. CASE STUDY

This section presents a case study about a cell, which isa typical example of the manufacturing sector where thedevices can run in a simultaneous mode. This example iswell explored in Supervisory Control Theory by Queirozand Cury in (Queiroz & Cury 2002). The problem withto these systems is the need for synchronization pointsbetween parallel blocks.

The manufacturing cell is composed of one circular tablewith four positions (P1, P2, P3, and P4) for carrying outdrilling operations and testing of pieces, and four moreactuator devices: an input belt, a drilling machine, a testdevice, and a manipulator robot. In each position existsone sensor for indicating presence/absence of piece in theplace. The table rotation is controlled by the single-actioncylinder (see Fig. 4) and the total advance of the cylinder-arm generates a 90 degree turn.

The belt model follow the AlterOnOff pattern (see Fig.3-b), whilst the drill, test, and robot models follow theOnOff pattern (see Fig. 3-a). Thus, to generate the plantmodel we must represent the four devices and the cylinderassociated to the table as a parallel component (see Fig. 7).This example is composed of the belt with three possiblestates, three devices with two states each, and one cylinderassociated with the table, which also has three states.The model with no control has 72 states, i.e., 3 x 2 x 2x 2 x 3 = 72 distinct configurations. Moura & Guedes,in (Moura et al. 2008), presented this process with moredetails.

For creating the tree, the follow events were generated inthe evolution of the model:

• buffer, to indicate piece in initial position;• b1.tm, to indicate time to run the belt;• piOn to indicate piece in position Pi(i = 2, 3, 4),

respectively;• tmi.tm to indicate timeout of Timer Tmi(i = 1, 2, 3),

respectively;• c1.tm, to indicate time for total advancing of cylinder

arm that control the table.

In next subsections, we discuss two control policy: onesequential and another parallel, which are used to controlthis cell.

5.1 Sequential Control

Consider the running scenario described as follows:


28


Manufacturing cell

Belt

Off

On

[b] [b] Wait

[b.tm]

[b]

Drill

Off

On

[d] [d]

Test

Off

On

[t] [t]

Robot

Off

On

[r] [r]

b.tm

bb

b.tm

d

d rt

t

r

ArmValve

Returned

Advancing

Off

On

[c11]/t11=1

[v]/c11=1

Sensor

False

True

[c12]/s1=1Advanced

[c11^t11.tm]/c12=1

Table

[v]/c11=0

[c11]/t11=0

[c11]/c12=0

[c12]/s1=0

s1

t11s1t11t11.tm

v

t11.tm v

v

t11.tm

s1

t11

Input:

Output:v

s1

Memory:bool: c11, c12timer: t11(T#2s)

Fig. 7. Manufacturing cell: plant model.

“If there is one workpiece in the input buffer,then the belt advances until it gets to theposition P1; The table rotates 90 degrees;Then the piece is drilled; The table rotates 90degrees; Then the piece is tested; The tablerotates 90 degrees; At the last step, the robotremoves the piece, pushing it to the deposit.”

The control software allows to operate the cell, in sequen-tial way, only one piece by time. This constraint avoidproblems that can occur when the cell operates severalpieces simultaneously, however, this operation mode is fewefficient, considering that the belt, drill, test, and robotstay stopped a lot of time.

Another constraint that should be satisfied by the modelis that the table rotation must only be performed if thereis at least one piece in positions P1, P2, or P3.

The complete BSC model of a sequential controller isshown in Fig. 8. Guard conditions g1, g2, . . . , g10 arepresented in Table 1, where the variable IN indicates thepresence or absence of a piece in the input buffer. Note thatthe data area is not represented in the figure, but the IOchannels can be easily identified; E1 and Yi(i = 1, . . . , 3)are internal variables, and P1, . . . , P4, IN, S1 representsensors installed in the plant.

The reachability tree of the controlled model (control +plant) generated 20 different states, but they only act in 8distinct configurations, as described in Table 2, where thestates of the cylinder arm are: “Ret” (returned), “Aing”(advancing), and “Aed” (advanced).

The reachability tree analysis has shown that the modelensures the properties of reinitiability, vivacity, and thatthere is no deadlock. The configuration cfg5 is same asconfiguration cfg0, where all devices are in state “Off”, butthere is one piece in position P2. In cfg7, the drill is in state

Table 1. Sequential control: guards.

g1 ¬P1 & ¬E1 & IN

g2 P1 & ¬E1

g3 P2 & ¬E1 & Y1

g4 tm1.tm

g5 P3 & ¬E1 & Y2

g6 tm2.tm

g7 P4 & ¬E1 & Y3

g8 tm3.tm

g9 E1

g10 S1

Table 2. Sequential control: configurations.

Config Belt Drill Test RobotTable: Cylinder

V A S

cfg0 Off Off Off Off Off Ret F

cfg1 On Off Off Off Off Ret F

cfg2 Wait Off Off Off Off Ret F

cfg3 Off Off Off Off On Aing F

cfg4 Off Off Off Off On Aed T

cfg6 Off On Off Off Off Ret F

cfg11 Off Off On Off Off Ret F

cfg16 Off Off Off On Off Ret F

“On” (same as cfg6), but the model is waiting timeout ofthe timer Tm1. Cfg8 and cfg9 are configurations to rotatethe table (same as cfg3 and cfg4) respectively, but the piecestarts in position P2, rather than P1. The configurationscfg10, cfg12, cfg13, and cfg14 are same as cfg5, cfg7, cfg8,and cfg9, but with the timer Tm2 controlling the testdevice and the piece in position P3. Finally, cfg15, cfg17,


29


BeltCtrl

Off

On

[g1]/b=1

[g2]/b=0&E1=1&Y1=1

TimerT1

Off

Start

[Tm1]

[tm1.tm

]

Controller

DrillCtrl

Off

On

[g3]/d=1&

Tm1=1

[g4]/d=0&E1=1&Y2=1

TestCtrl

Off

On

[g5]/t=1&

Tm2=1

[g6]/t=0&E1=1&Y3=1

RobotCtrl

Off

On

[g7]/r=1&

Tm3=1

[g8]/r=0&Yi=0(i=1,2,3)

ValveCtrl

Off

On

[g9]/v=1

[g10]/v=0&E1=0

On

IN

Tmi(i=1..3)

IN

P1 b

S1 v

tm1.tm

P2

Tm1

d

/Tm1=0tm1.tm

Tm1 Tm1

TimerT2

Off

Start

[Tm2]

[tm2.tm

]

On

/Tm2=0tm2.tm

Tm2 Tm2

TimerT3

Off

Start

[Tm3]

[tm3.tm

]

On

/Tm3=0tm3.tm

Tm3 Tm3

tm2.tm

P3

Tm2

t

Tm3

r

tm3.tm

P4

tmi.tm(i=1..3)

Tmi(i=1..3)

b

d

t

r

v

P1

P2

P3

P4

S1

Fig. 8. Manufacturing cell: sequential control.

cfg18, and cfg19 are same as cfg5, cfg7, cfg8, and cfg9, butwith the timer Tm3 controlling the manipulator robot andthe piece in position P4.

From the controlled model, the execution of algorithm tocreate the reachability tree generated the follow sequenceof configurations:

• (cfg0, buffer); (cfg1, b1.tm); (cfg2, empty); (cfg3,c1.tm); (cfg4, empty); (cfg5, p2On); (cfg6, empty);(cfg7, tm1.tm); (cfg8, c1.tm); (cfg9, empty); (cfg10,p3On); (cfg11, empty); (cfg12, tm2.tm); (cfg13,c1.tm); (cfg14, empty); (cfg15, p3On); (cfg16, empty);(cfg17, tm3.tm); (cfg18, empty); (cfg1,).

According with Algorithm 1 (see lines 17-20), if, in a newconfiguration, the set of possible transitions is empty, theevent empty must be generated for synchronizing themodel.

5.2 Parallel Control

In the parallel control, we consider that the four deviceactuators can run simultaneously and that the table mustbe run only after the execution of these devices. Thus, asynchronization point between devices and the table mustbe created to enable proper system operation.

Other constraints imposed on the model are:

(1) Each device must execute only once before a tablerotation;

(2) If in a configuration there is no piece in the inputbuffer or in positions P2, P3, and P4, then the belt,the drill, the test, and the robot must not be turnedon;

(3) The table rotation must only be performed if there isat least one piece in positions P1, P2, or P3.

The inclusion of these constraints in the controller model iscarried out by determining new transitions between statesand/or changes in the guard conditions of the existingtransitions. Initially, to create the control model for thiscase study, extra variables must be included to ensuresynchronism between the devices and, therefore, the con-straint imposed on table rotation, i.e., the table cannotrotate while the devices are running. In this case, the vari-ables E1, E2, E3, and E4 indicate the “end-of-operation”

of the belt, drill, test, and robot, respectively. Thesevariables must be set to “true” for each of the devices.According to cell operation, the table must only be rotatedwhen all of devices have concluded their operations, i.e.,when the variables Ei = true(i = 1, . . . , 4). After the tablerotates 90 degrees, these variables must be reset to allownew operations in the system. These variables are also usedin the transitions to turning on/turning off the actuators;for example, the drill must only be turned on if the controlvariable E2 is equal to “false”.

Extra transitions to ensure constraints 2 and 3 must beincluded in the model. For example, if there is no piecein position P2, then the drill must not be turned on, butthe variable E2 must be set to “true” to indicate end-of-operation of the phase. A similar idea is applied to otheractuator devices. In the table model, if there is no piecein positions P1, P2 or P3, then the table must not rotate(constraint 3); however, variables E1, E2, E3, and E4 mustbe set to “false” to allow new operations in the devices.Thus, if there is no piece in the manufacturing cell, themodel will continually alternate the value of E1, . . . , E4between “false” and “true”. The complete BSC model ofthe control software is shown in Figure 9. Guard conditionsg1, g2, . . . , g15 are presented in Table 3, where the variableused has the same meaning of the variables in previoussubsection.

The reachability tree of the controlled model (control+ plant) generated 210 different states, in function ofthree timers included in the control model for simulatingthe processes of drilling, testing and moving the pieceto storage. However, these 210 configurations act onlyin 26 distinct configurations, where: i) 24 possibilities ofactuation of devices: 3 x 2 x 2 x 2 = 24 with the tablein stop position (cylinder in configuration [Off, Returned,False]); and ii) 2 possibilities for rotating the table withthe four devices in state Off. These 26 configurations aredescribed in Table 4, where the states of the cylinderarm are: “Ret” (returned), “Aing” (advancing), and “Aed”(advanced). In this example, we also included the column“children” with descendant configurations for indicatingthe possible branches of the tree.

The reachability tree analysis has shown that the modelensures the properties of reinitiability, vivacity, and that


30


BeltCtrl

Off

On

[g1]/b=1

[g2]/b=0&E1=1

TimerT1

Off

Start

[Tm1]

[tm1.tm

]

Controller

[g3]/E1=1

DrillCtrl

Off

On

[g4]/d=1&

Tm1=1

[g5]/d=0&E2=1

[g6]/E2=1

TestCtrl

Off

On

[g7]/t=1&

Tm2=1

[g8]/t=0&E3=1

[g9]/E3=1

RobotCtrl

Off

On

[g10]/r=1&

Tm3=1

[g11]/r=0&E4=1

[g12]/E4=1

ValveCtrl

Off

On

[g13]/v=1

[g14]/v=0&Ei=0

[g15]/Ei=0

On

IN

Tmi(i=1..3)

IN

P1 b

P2

P3

P1 v

tm1.tm

P2

Tm1

d

/Tm1=0tm1.tm

Tm1 Tm1

TimerT2

Off

Start

[Tm2]

[tm2.tm

]

On

/Tm2=0tm2.tm

Tm2 Tm2

TimerT3

Off

Start

[Tm3]

[tm3.tm

]

On

/Tm3=0tm3.tm

Tm3 Tm3

tm2.tm

P3

Tm2

t

Tm3

r

tm3.tm

P4

tmi.tm(i=1..3)

Tmi(i=1..3)

b

d

t

r

v

S1

P1

P2

P3

P4

S1

Fig. 9. Manufacturing cell: parallel control.

Table 4. Parallel control: configurations.

Config Belt Drill Test RobotTable: Cylinder

childrenV A S

cfg0 Off Off Off Off Off Ret F {1, 2, 3, 4}

cfg1 On Off Off Off Off Ret F {5, 6, 7, 8}

cfg2 Off On Off Off Off Ret F {9, 10, 11}

cfg3 Off Off On Off Off Ret F {12, 13, 14}

cfg4 Off Off Off On Off Ret F {15, 16, 17}

cfg5 Wait Off Off Off Off Ret F {18, 19, 20}

cfg6 On On Off Off Off Ret F {21, 22, 23}

cfg7 On Off On Off Off Ret F {24, 25, 26}

cfg8 On Off Off On Off Ret F {27, 28, 29}

cfg10 Off On On Off Off Ret F {31, 32, 33}

cfg11 Off On Off On Off Ret F {34, 35, 36}

cfg14 Off Off On On Off Ret F {39, 40, 41}

cfg21 Wait On Off Off Off Ret F {45, 46, 51}

cfg22 On On On Off Off Ret F {52, 53, 54}

cfg23 On On Off On Off Ret F {55, 56, 57}

cfg24 Wait Off On Off Off Ret F {47, 48, 58}

cfg26 On Off On On Off Ret F {60, 61, 62}

cfg27 Wait Off Off On Off Ret F {49, 50, 63}

cfg32 Off On On On Off Ret F {69, 70, 71}

cfg52 Wait On On Off Off Ret F {97, 98, 101}

cfg53 On On On On Off Ret F {108, 109, 110}

cfg55 Wait On Off On Off Ret F {99, 100, 104}

cfg60 Wait Off On On Off Ret F {102, 103, 105}

cfg108 Wait On On On Off Ret F {149, 150, 153}

cfg201 Off Off Off Off On Aing F {208}

cfg208 Off Off Off Off On Aed T {0}


31


Table 3. Parallel control: guards.

g1 ¬P1 & ¬E1 & IN

g2 P1

g3 ¬P1 & ¬E1 & ¬IN

g4 P2 & ¬E2

g5 tm1.tm

g6 ¬P2 & ¬E2

g7 P3 & ¬E3

g8 tm2.tm

g9 ¬P3 & ¬E3

g10 P4 & ¬E4

g11 tm3.tm

g12 ¬P4 & ¬E4

g13 E1&E2&E3&E4 & (P1 ‖ P2 ‖ P3)

g14 S1

g15 E1&E2&E3&E4 & ¬P1 & ¬P2 & ¬P3

there is no deadlock. From the controlled model, the execu-tion of algorithm to create the reachability tree generatedseveral sequences of configurations. Two examples are:

(1) (cfg0, buffer); (cfg1, b1.tm); (cfg5, p2On); (cfg18,p3On); (cfg45, p4On); (cfg97, tm1.tm); (cfg149,tm2.tm); (cfg185, tm3.tm); (cfg201, c1.tm); (cfg208,empty); (cfg0,).

(2) (cfg0, buffer); (cfg1, b1.tm); (cfg5, p4On); (cfg20,p3On); (cfg50, tm3.tm); (cfg105, tm2.tm); (cfg163,p2On); (cfg193, empty); (cfg206, tm1.tm); (cfg203,c1.tm); (cfg208, empty); (cfg0,).

In the sequences where any event is not possible tooccur between to detect piece in the positions (event:piOn, i = 2, 3, 4) and the timeout of Timer associated(event: tmi.tm, i = 1, 2, 3), the event empty must begenerated between them for synchronizing the model.

6. CONCLUSION

In this work we have presented a methodology for sys-tematizing the process of plant and control modeling ofmanufacturing systems. Our proposal uses a formalismbased on Statecharts diagrams, called Basic Statecharts(BSC). The plant modeling has three phases which canbe executed as many times as necessary. In general, thismethodology represents a hybrid approach - bottom-up andtop-down, allowing components reuse and keeping a one-to-one relation between plant and model (i.e., it is faithfulto the actual system). The control model is generatedalso using Basic Statecharts. One typical example of themanufacturing application was described as a case studyto illustrate our proposal.

Thus, the main contributions of this work are the follow-ing:

• A methodology to model plants and industrial controllogics using Basic Statecharts ;

• An algorithm to create the reachability tree of theBasic Statecharts ;

• A procedure to integrate plant and control modelsin order to analyze and/or validate several structural

proprieties of the modeled system, such as deadlockabsence, vivacity, and reinitiability. This is veryimportant in the project phase of every industrialcontroller.

Based on our experience, we believe that Basic Statechartsare a very interesting formalism for modeling the dynamicbehavior of complex DES. Some advantages are: i) sinceBasic Statecharts are a high-level language, it allows usto model control logic and document it in an easier tounderstand manner for automation engineers than do low-level languages such as Ladder diagram; ii) as Statechartsare incorporated in UML 2.0, they are widespread bothin academic and industrial areas; iii) because BSC are inline with original Statecharts, we believe that their will beeasily understood bt academic and industrial professionals;iv) BSC use channels to communicate explicitly betweencomponents. Thus, the broadcast approach used by orig-inal Statecharts is avoided; v) because BSC work witha condition/action paradigm instead of an event-basedmechanism, we believe that BSC are more appropriatethan the automata-based approach (for example: Supervi-sory Control Theory) for modeling industrial applicationsin the real world; and vi) as Basic Statecharts retain formalproperties, they can be used to verify and/or validateseveral structural proprieties of the modeled system, suchas deadlock absence, vivacity, and reinitiability. Thisis very important in the project phase of every industrialcontroller.

A prototype using Java language is currently being de-veloped to create and simulate models generated by ourmethodology. The aim is to test how much easier and nat-ural the creation of industrial applications will become, aswell as to produce more “user-friendly” documentation forthe designers, giving more autonomy to the developmentand maintenance teams.

REFERENCES

[Bani Younis & Frey 2006] M. Bani Younis and G. Frey.UML-based Approach for the Re-Engineering of PLCPrograms. In 32nd Annual Conference of the IEEEIndustrial Electronics Society (IECON’06), pages3691–3696, 2006.

[Beeck 1994] M. von der Beeck. A Comparison of State-charts Variants. In ProCoS: Proceedings of the ThirdInternational Symposium Organized Jointly with theWorking Group Provably Correct Systems on FormalTechniques in Real-Time and Fault-Tolerant Systems,pages 128–148, Springer-Verlag, London, UK, 1994.

[Boehm 1988] B. Boehm. A Spiral Model of SoftwareDevelopment and Enhancement. Computer, volume21(5), pages 61–72, 1988.

[Boehm 2006] B. Boehm. A view of 20th and 21st centurysoftware engineering. In ICSE ’06: Proceeding of the28th international conference on Software engineer-ing, pages 12–29, ACM Press, New York, 2006.

[Cassandras & Lafortune 2008] C. Cassandras and S.Lafortune. Introduction to Discrete Event Systems- Second Edition. Springer Science, 2008.

[Drusinsky & Harel 1989] D. Drusinsky and D. Harel. Us-ing Statecharts for Hardware Description and Syn-thesis. In IEEE Transactions on Computer-AidedDesign, volume 8(7), pages 798–807, 1989.


32


[Gourcuff et al. 2006] V. Gourcuff and O. De Smet andJ-M. Faure. Efficient representation for formal verifi-cation of PLC programs. In 8th International Work-shop on Discrete Event Systems (WODES 2006, AnnArbor, Michigan, USA, 2006.

[IEC 61131 1993] IEC. International EletrotechnicalCommission. Programmable Controllers Part 3, Pro-gramming Languages, IEC61131-3, 1993.

[IEEE-Std 610.12 1990] IEEE Std 610.12-1990. StandardGlossary of Software Engineering Terminology, 1990.

[Masiero et al. 1994] P. Masiero and J. Maldonado andI. Boaventura. A reachability tree for statechartsand analysis of some properties. In Information andSoftware Technology, pages 615–624, 1994.

[Moura et al. 2008] R. Moura and F. Couto and L.Guedes. Control and Plant Modeling for Manufactur-ing Systems using Statecharts. In IEEE InternationalSymposium on Industrial Electronics (ISIE 2008),pages 1831-1836, Cambridge, UK, 2008.

[Queiroz & Cury 2002] M. Queiroz and J. Cury. Synthesisand Implementation of Local Modular SupervisoryControl for a Manufacturing Cell. In 6th Interna-tional Workshop on Discrete Event Systems (WODES2002), Zaragoza, Spain, 2002.

[Ramadge & Wonham 1989] P. Ramadge and W. Won-ham. The Control of Discrete Event Systems. Pro-ceedings of the IEEE, volume = 77(1), pages = 81–98,1989.

[Royce 1970] W. Royce. Managing the Development ofLarge Software Systems. In Proceedings of IEEEWESCON, pages 1–9, 1970.

[SCXML 2006] SCXML. The JakartaProject Commons SCXML.http://jakarta.apache.org/commons/scxml/, 2006.

[Skoldstam et al. 2008] M. Skoldstam and K. Akesson andM. Fabian. Supervisory Control Applied to Au-tomata Extended with Variables - Revised. Goteborg:Chalmers University of Technology, 2008.

Raimundo Moura received a graduate in Computer Sci-ence from the Federal University of Piaui (UFPI), Brazil,in 1994, and a PhD degree in Electrical and ComputerEngineering at Federal University of Rio Grande do Norte,Brazil, in 2009. Since 1997, he is an associate professorin the Department of Informatics and Statistics at UFPI,Brazil. His main research interests include industrial infor-matics and high level modeling languages.

Luiz Affonso Guedes has a graduate in electrical engi-neering from Federal University of Para, Brazil, in 1987,and PhD degree in Computer Engineering from StateUniversity of Campinas, Brazil, in 1999. Since 2003, heis an associate professor in the Department of ComputerEngineering and Automation at Federal University of RioGrande do Norte, Brazil. His main research interests in-clude Communication System to Industrial Applicationand High Level Programming Languages to IndustrialAutomation.


33

Basic Statechart: A Formalism to Model Industrial Applications

Documents

Transcript of Basic Statechart: A Formalism to Model Industrial Applications