Re-usable Software Design for Programmable Logic ... - CiteSeerX

ACM SIGPLAN Workshop on Languages, Compilers and Tools for Real-Time Systems, La Jolla, California, June 1995.

Re-usable Software Design for Programmable Logic Controllers

3

Flavio Bonfatti1 , Gianni Gadda2 , Paola Daniela Monari1

1

2

Faculty of Engineering, University of Modena

c/o CICAIA, via Campi, 213/B - 41100 Modena (Italy) CMA spa, via Ghiarola Vecchia, 73 - 41042 Fiorano Modenese (Italy)

[email protected] July 28, 1995

Abstract It is the aim of this paper to present a model conceived for supporting the initial, critical phases of PLC software life cycle, namely requirement speci cation, requirement analysis and software design, to obtain reusable code. The model, named EASIER, is based on an object-oriented paradigm where the message-method mechanism is replaced by the law and action primitives, since they are more suitable to cope with the real-time, cyclic nature of PLC software. Software re-usability is pursued by identifying independent control modules through a proper bedded encapsulation mechanism, representing system dynamics by means of synchronized state diagrams, expressing context-free behaviour of system components by introducing virtual objects. The EASIER approach is presently validated with respect to relevant reverse and forward engineering applications; from one of these cases we derive the examples used in the paper.

1

Introduction

Programmable Logic Controllers (PLCs) are widely used for automating a variety of industrial plants. Important applications are material handling and warehousing systems, weight lifting systems, transportation lines, packaging systems. A PLC is a general-purpose microprocessor system connected to sensors and actuators: the former provide information on the state of the controlled plant while the latter perform the actions prescribed by the controller. Mapping input information into output commands is the basic task of PLC software. Low hardware cost and exibility of a software-based solution make PLCs particularly suitable for one-of-akind and customized plants. On the other hand, the 3 This work is partially supported by the Commission of the European Communities (CEC) as project 10542 - EASIER (Enhancing Application Software Implementation for Programmable Logic Controllers) of the European Systems & Software Initiative ESSI of the ESPRIT programme.

market of automation is steadily growing and evolving towards higher levels of product customization. Then, an increasing use of PLCs can be expected in the next years. Due to the real-time, cyclic nature of PLC software, speci c languages have been studied for supporting the design and coding phases [2, 6, 19]. According to the IEC 1131-3 standard, ve basic languages are identi ed at dierent levels of abstraction: Instruction List, Structured Text, Ladder Diagram, Function Block Diagram, Sequential Function Chart (Grafcet). The last, developed in France in the late 70s [3], is speci cally deputed to support the design phase. It provides a number of graphic primitives to divide the process cycle into well de ned steps, separated by transitions. Grafcet is the core language of the standard, the other languages are used to describe the actions to perform within the steps and the logical conditions for transitions. Unfortunately Grafcet presents a number of limitations: (i) representation is focused on the overall framework of PLC software while details, often critical, must be expressed in natural language or in a lower level notation; (ii) it is not able to capture the structural aspects of the controlled system and the corresponding information contents; (iii) it views the control software as a whole, in that it does not oer any primitives for software module identi cation and construction. Although aected by these limitations, Grafcet and the other languages are still widely used and proposed in new software development tools [17]. Thus, in spite of its diusion and growth perspective, a number of relevant de ciencies of current PLC software engineering practice are observed: (i) communication with customers, to formalize and validate plant structural and behavioural requirements, is not adequately supported; (ii) modularity is not signi cantly considered, so that software re-usability is dicult to achieve and cooperation with subcontractors is not favoured; (iii) unit and integrated testing are hardly planned because of the absence of a complete and structured representation of plant behaviour; (iv) maintenance and functional im-

provements cannot rely on homogeneous software documentation. Software modularity is a fundamental goal of every good software engineering practice. This is particularly important in the case of PLC software, since the plants to automate are made of components belonging to a limited number of families: even if each plant requires a speci c component con guration, most of the control software could be re-used. In order to obtain a modular software it is necessary that the requirement speci cation model itself is conceived to support a modular design [4]. An interesting answer to this problem comes from the object-oriented paradigm [18]. However, it must be noted that most of the knowledge required to code PLC software concerns system dynamics: if expressed by methods, it results hidden and escapes possible controls. Even the availability of declarative constructs, as those proposed in Eiel [5], is not sucient for our purposes because of the residual use of routines and the lack of speci c primitives for expressing system dynamics and component interaction (recall the linguistic module units principle [4]). In order to overcome the above problems, a new representation model has been studied that meets the speci c needs of the initial phases of PLC software lifecycle: requirement speci cation, requirement analysis and software design. The model, called EASIER, is based on an object-oriented paradigm that was initially inspired by a Wand's work [7]. The model sets a strict dependence between structural and behavioural aspects through the introduction of the complex object and law concepts. In particular, laws express system legality and steadiness; they have associated the actions to undertake in the cases of violation, thus replacing the method (routine) primitive. The paper is organized into four main sections. Section 2 presents an ontological analysis of the application domain in order to derive the basic requirements that justify the model primitives. In Section 3, the EASIER approach is presented by reporting signi cant aspects of a real case modelling, that of a picking bay used in an automated warehouse. In Section 4, the resulting schema is analyzed with the purpose of showing how it can support the following code generation phase. Finally, Section 5 summarizes conclusions and prospects.

2

Model requirements

As it was recently recalled in [9] every model adopts its own ontology, that is, a particular way of perceiving the observed reality, and this holds also for our model [10, 11]. In this section we propose a concise ontological analysis of the automated system structure and behaviour in order to justify the model primitives pre-

sented in the following sections. An automated system is generally made of components (units) that interact with each other. A unit is any part that can be observed autonomously: a simple timer and a shuttle are both possible units. The system behaviour can be described in terms of the behaviours of its components and the ways how these interact. The behaviour of a single unit is perceived by the variations of its observable properties: we usually measure properties by associating values to them. The set of values associated, at each time, to the properties of a unit constitutes the unit state. The state space of the unit is given by the combination of all the values that its properties can assume, including the null value when applicable. A rst modelling need concerns the capability of representing properties, state space and current state of the system units. In practice, not all the combinations of property values are observed. For every unit, a partition of the state space delimiting the space of legal states is perceived. Moreover, a state variation can appear illegal even though it maps from a legal state to another legal state. Thus, a partition of the variation space delimiting the space of legal variations is also perceived. In synthesis, the dynamics of a unit is observed through the set of legal states it assumes and the set of legal variations it presents. Partitions of legal spaces from the relative whole spaces are obtained by selections the model should be able to express. A large part of PLC software is devoted to check anomalous situations and misfunctionings and react to them with restoration actions. We can consider such cases as violations of the conditions that partition legal spaces; then, a restoration action corresponds to moving the unit from the illegal state to a legal one. Association of restoration actions to legality condition is another model requirement. Most of the system units present an active behaviour: they are active if PLC functions are de ned to perform variations of their states, while passive unit states are only modi ed by external events. Going deeper into the analysis of active units, we discover that identifying legal states and state variations is not sucient to express dynamics. In fact, their states present the additional characteristic of being either steady or unsteady. A state is unsteady if the PLC is required to undertake actions to modify it. For example, the state of a shuttle is unsteady whenever its current position does not match its destination and the engine is o; as soon as the engine is turned on by the controller, the shuttle starts moving and the state becomes steady. Then, a further modelling requirement concerns the capability of expressing steadiness conditions and the corresponding stabilization actions. We have already seen that state variations are the

means the observer has available to perceive unit dynamics. This holds also for those units that present a composition structure, in that they include simpler units. A complex unit is characterized by its own properties that usually are related to those of its components. Since the unit and the component states change contextually, a relationship is recognized among them. In other words, units are related if changes in the state of one or more of them depend on the states of the others. Complex units can interact with other units in their turn. The model will represent complex units of every kind and their state spaces. Not all the combinations of complex and component unit states are observed. In other words, the state of a complex unit can be illegal even though the states of all its component units are legal. This can occur for dierent reasons, for instance: the state of the complex unit is illegal in itself, or it is not consistent with that of a component unit; the states of two component units are not compatible with each other; the state of a component unit, although legal in itself, is not legal within this context. Morover, state variations are often bounded as it occurs for simple units. The model is required to represent all these cases by relating unit states and synchronizing state variations. In the analogy with simple units, we recognize active and passive complex units, depending on whether their states are changed or not by PLC functions. The control of an active complex unit performs supervision tasks to ensure its steadiness: in particular, a complex unit can be unsteady even though all its active component units are steady. When the PLC code detects an unsteady situation, it usually reacts by modifying the states of some components which, consequently, can fall unsteady. Further reactions follow to re-establish steadiness of these components: a propagation phenomenon occurs which ends once all the involved units reach a steady state. Representation of interdipendences between steadiness conditions constitutes another model requirement.

3

A study case: the picking bay

In order to meet the above requirements, the EASIER model has been de ned and tested on real cases. The model basic concepts are those of the classical objectoriented paradigm, but it substantially diers for introducing the primitives of law and action in place of the message-method mechanism. The model features and the syntax of the relative language are described in [11, 12, 14]; here we are more concerned with its expressiveness, intended as the capability of originating a natural and complete system representation, and the resulting schema modularity, intended as a knowledge organization that favours the design of modular and, possibly,

re-usable software. In this section, one of the application cases experimented within the ESSI project is described in some detail to introduce the EASIER approach and the characteristics of the resulting schema. The example, a picking bay, has been chosen for its completeness and for presenting an interesting modular structure. As we shall see, analyzing the physical structure is the means for a correct and eective identi cation of the schema components and, consequently, of the software modules. On the contrary, with traditional approaches, the picking bay behaviour is considered globally and software partition, when applied, is decided on the basis of mere implementative issues. 3.1

The picking bay

The picking bay is a component of a wider automated warehouse plant, enabling goods entering and getting out. It communicates with the warehouse by a shuttle moving along a gangway and transferring pallets. It is basically composed of ve conveyors, as it is shown in Figure 1: the exit and entry conveyors move, by chains, pallets coming from or going to the warehouse, respectively; the exit conveyor is followed by a shunter provided with a hoist device; the entry conveyor is provided with a shape checker and preceded by another shunter with hoist; the picking module, also provided with hoist, is the site where the pallet, or part of its contents, is drawn or loaded, depending on whether goods get out or enter the warehouse. The two shunters and the picking module move pallets by rollers. Photocells, semaphores, timers and other devices complete the picking bay structure. The picking bay works at 20-30 Hz. The picking bay behaviour is rather complex. Schematically, the basic operation consists in recalling a pallet for drawing or loading goods: the pallet is extracted from the warehouse by a traslo-elevator, carried to the exit conveyor by a shuttle, transferred to the picking module for operation, moved away on operator request through the entry conveyor, carried back to the warehouse by a shuttle and, nally, put in the original position by a traslo-elevator. Exit and entry conveyors, shunters and entrance into the picking module are activated by signals coming from photocells and semaphores, while exit from the picking module is activated by the operator. The hoists are used to lift or lower the pallet for changing its direction (in the shunters) and for drawing or loading it (in the picking module). The shape checker controls the pallet size and possible protrusions out of it. Anomalous situations are recognized from irregular sequences of photocell and semaphor signals and from expirations of deadlines assigned to the dierent operational phases. All the picking bay operations are controlled by a single PLC; synchronization with other plant automated units does not

fall within the scope of this paper. Representing the whole picking bay control is too expensive for the economy of this paper. Thus, we shall focus our attention on one of the ve conveyors, the rst shunter, which is complex enough to constitute a significant example. Figure 2 shows graphically its position within the picking bay schema. As we can see, the rst shunter is made of two components, a roller conveyor and a hoist. The roller conveyor is a specialization of basic conveyor which has three timers as components. For the sake of simplicity, photocells and semaphores are not considered autonomous entities, but their states are modelled as properties of the objects they control. The basic units of the system are modelled as object types. From the structural point of view, an object type is characterized by a name and a list of attributes. An attribute is declared by a pair (Attribute: domain) that gives the set of values it can take. The only basic unit of our representation is the timer: object Timer PresetTime, CurrentTime: integer Stop: boolean Status: (Preset, Reset, Running, Expired); The complex object primitive is used, in its turn, to represent complex units, that is, units that include simpler objects. The complex object structure is also described through a type declaration. It includes attribute and component declarations, the latter expressing the objects that participate in the relationship. A component is declared by a pair (Role: Object) de ning the type of object that can play the given role. The

rst two complex objects of our representation are the hoist and the basic conveyor: object Hoist T: Timer Up, Dp, Uc, Dc: boolean Error: integer Status: (Up, Down, Top, Bottom, Error); object BasicConveyor LoadTimer, TransitTimer, UnloadTimer: Timer Pin, Pout: boolean Sin, Sout: (Green, Red) Error, Datum: integer Status: (Ready, WaitForLoading, Loading, Transit, Busy, Unloading, Error); According to the object-oriented paradigm, an object type can be de ned as specialization of another type of upper level. The specialized type inherits the properties of the object it descends from, apart from those added or rede ned. Rede ning a component means mapping the role into a subtype. A specialized object type is related to its supertype by the keyword "isa" and may present additional attributes and components. Domain restrictions, as well as relationships between subtype and supertype attributes, are expressed by laws, as we shall see in the following. The object BasicConveyor has been introduced to characterize a generic unit that can take dierent forms depending on the speci c operational needs. One of these versions, the roller conveyor, is provided with a motor and presents a behaviour that will be expressed

by proper laws. Since most of these laws are inherited from those of Basic Conveyor, the roller conveyor is conveniently represented by specialization. In this particular case the motor is not seen as a component but simply as a property. object RollerConveyor isa BasicConveyor MotorStatus: (Go, Stop, Back); 3.2

Laws and actions

The main task of PLC code is solving unsteady situations by computing new states. In addition, PLC code is required to ensure legality of object states and state variations against possible errors or failures. Even though the two problems are dierent in nature, their management can be based on similar modelling solutions since both require de nition of (legality or steadiness) laws with associated the actions to undertake. Laws are written as expressions of the predicate calculus [13], applied to the current and previous states of the object and, if any, to those of its components; actions are algorithms that modify the current state of the involved objects for restoration or stabilization purposes. Laws and actions expressing the Timer behaviour are the following: laws on Timer L1: CurrentTime ge 0 and CurrentTime le PresetTime action msg "timer fault"; CurrentTime:=0 L2: PresetTime gt 0 action msg "wrong preset value"; abort T3: Status eq Running and CurrentTime eq 0 Status eq Expired action update Status T4: Status eq Preset Status eq Running and CurrentTime eq PresetTime and not Stop action update Status, CurrentTime, Stop L5: old CurrentTime ne CurrentTime and

f f

f

f

g

g

g !

!

g

)

Status eq Running CurrentTime eq old CurrentTime - 1 action update CurrentTime T6: Status eq Running and Stop Status eq Reset action update Status ;

f

f

g

g

!

The example reports both legality laws (those with Li labels) and transition laws (those with Tj labels); if taken in conjunction, all these laws express the socalled invariant of the object [4, 9,]. The keyword old denotes the attribute values before the last object state variation. More precisely, if Si01 and Si represent the previous and the current object states, respectively, all the values of Si01 are denoted as old, independently of whether they are changed or not in Si . Then, laws can be viewed as post-conditions and the old notation is similar to the homologous used in Eiel [5]. This is the means for referring control conditions to the history of units behaviour [1, 18]. Concerning the Timer legality laws, we observe that L1 and L2 limit the object state space while L5 limits the state variation space. In particular, law L5 shows that the timer behaves like a down-counter since, when it is running, its current value decreases of 1 whenever it changes (incidentally, this implies that the period of current time update should be longer than the PLC cycle time). Actions are written in a concise form because their operations are easily derived from the corresponding laws. Concerning steadiness laws, note that they express the transitions of the Timer state diagram reported in Figure 3 [1, 2, 15]. In general, a transition is written having in mind the following steps: a) the unsteady situation expressed by the left-hand predicate (with respect to the transition operator ) is detected on the object state;

!

b) the corresponding stabilization action is undertaken to calculate the new state;

Thus, the preset and reset laws of timer cannot but belong to the objects that include it as component. This choice appears rather natural in that it mirrors the way how controls are conceived. Note that the timer is used as basic means for assigning and controlling durations, thus constraining the system behaviour with respect to time. The controlled duration corresponds to the timer preset time, the timer count-down starts when its status moves to Preset, the count-down can be interrupted by moving the status to Reset, the timer deadline is expressed by the timer status Expired.

4 c) the new state is checked by the implicit legality condition of the right-hand predicate. Since the timer is used as component of more complex objects, the initial state Preset is set from outside to start the count-down. Likewise, the boolean attribute Stop is set from outside to interrupt the timer operation and move it to the Reset state. This is a rst example of external conditioning on object behaviour. How this conditioning is carried out becomes evident by examining two (of the seven) hoist laws: laws on Hoist T1: Status eq Bottom and Uc Status eq Up and T.Status eq Preset action update Status, T.Status T2: Status eq Up and Up Status eq Top and T.Stop and not Uc action update Status, T.Stop, Uc:=False ... ... ...

f

f

!

! g

g

and the following two (of the sixteen) basic conveyor laws: laws on BasicConveyor T1: Status eq WaitForLoading and Sin eq Green Status eq Loading and LoadingTimer.Status eq Preset action update Status, LoadingTimer.Status T2: Status eq Loading and Sin eq Red Status eq WaitForLoading and LoadingTimer.Stop action update Status, LoadingTimer.Stop ... ... ...

!

f

f

!

g

g

The dot notation is used to denote component attributes. We assume that, in a complex object, laws can only refer to the object state (previous and current) and to the (previous and current) states of its components.

Schema analysis

In this section we examine the schema resulting from the application of the EASIER model to show how it favours the de nition of re-usable software modules. 4.1

Modularity and re-use

The objects de ned in the previous section (Timer, Hoist, BasicConveyor) identify software modules in that they express all what is needed to control the corresponding units. Re-usability is ensured since such units present the described behaviour everywhere they are used as components of more complex units. In its turn, each complex unit may present further laws that express specialized behaviours of the component units, thus completing their representation, and this modelling process extends recursively. Modelling relationships among units as complex objects produces a composition graph where every object is a node and the composition links are expressed as oriented arcs (see Figure 2). In line of principle, the behaviour of an object could be related to those of: (i) all the objects belonging to the composition sub-graph originated by it, and (ii) all the complex objects whose sub-graphs include it. Fortunately, actual dependences between objects are few with respect to these possibilities: if this was not true, modularization would become hard to achieve. We hypothesize that most dependences only involve objects and their direct components. From the modelling point of view, it is already excluded that a law can refer to attributes of objects of upper level in the composition hierarchy. Now we also assume that it cannot refer to the states of components other than direct components. Thus, object modelling only involves its properties and those of direct components: this realizes what we call bedded encapsulation which is the condition for identifying re-usable software modules. Problems arising when the state of an object X is related to properties of a sub-component A1 of the component A of X are overcome by splitting the law into

two parts: the one is an A law that associates the A1 attributes of interest to homologous (imported) A attributes; the other is a X law that expresses the condition in terms of the imported attributes. At a rst sight, the application of the bedded encapsulation mechanism requires a slightly larger number of objects, attributes and laws, but the degree of independence between de nitions, as well as that of re-usability and replaceability, is substantially increased. Further steps forward modularity are ensured by the specialization mechanism and the virtual object primitive. Their use is presented while completing the rst shunter representation. We have already given the structural de nition of RollerConveyor as specialization of BasicConveyor. Seven additional laws are required to characterize the RollerConveyor behaviour with respect to the presence of the MotorStatus attribute (no transition law is added since the two objects share the same state diagram): laws on RollerConveyor L1: Status eq Ready MotorStatus eq Stop action update MotorStatus ... ... ... L7: Status eq Unloading MotorStatus eq Go action update MotorStatus

f

f

)

g ) g

The next step concerns the rst shunter representation with respect to its basic components: a hoist and a roller conveyor. If we analyze the interactions of these two units, we can distinguish a behaviour strictly related to the rst shunter operational role and a behaviour independent of it. The same holds when analyzing the dynamics of the second shunter and of other complex units with such components. As context-free behaviours are recognized, they should be represented in independent modules so as to improve software reusability. Context-free behaviour of interacting units is modelled by the virtual object primitive. The object is considered virtual since it does not represent a real system unit, as in the following example: object R&H as Roller: RollerConveyor, Hoist: Hoist Error: integer Status: (Ready&Bottom, Up, Transit&Top, WaitForLoading&Top, ... , Error); laws on R&H L1: Roller.Status eq Ready and Hoist.Status eq Bottom Status eq Ready&Bottom action update Status L2: Hoist.Status eq Up Status eq Up action update Status ... ... ...

f f

)

g ) g

L8: Roller.Status eq Error or Hoist.Status eq Error Status eq Error action update Status L9: Roller.Status eq Error and Hoist.Status ne Error Error eq Roller.Error action Error:=Roller.Error L10: Roller.Status ne Error and Hoist.Status eq Error Error eq Hoist.Error action Error:=Hoist.Error L11: Roller.Status eq Error and Hoist.Status eq Error Error eq 7 action Error:=7

) g )

f

f

)

f

f

)

g

g

g

Now, the rst shunter representation is limited to the only laws that express the speci c behaviour of the unit and, hence, it results much simpler: object FirstShunter H: Hoist R: RollerConveyor Pout: boolean Sout: (Green, Red) Error: def R&H(Roller=R, Hoist=H).Error Status: def R&H(Roller=R, Hoist=H).Status; laws on FirstShunter L1: Status in (Ready&Bottom, Up, Transit&Top, ... , Error) action msg "wrong status"; Status:=Error L2: Pout eq R.Pout action Pout:=R.Pout L3: Sout eq R.Sout action Sout:=R.Sout T4: R.Status eq Ready and H.Status eq Up and H.Up R.Status eq Transit action update R.Status L5: R.Status eq Ready and H.Status eq Top H.Dc action H.Dc:=True ;

f f f

f f

g

g g

!

g

g

)

In conclusion of this section we observe that much of the knowledge that has been modelled for realizing the rst shunter de nition is completely re-usable in de ning the second shunter and other similar units. These units are used, in their turn, to build up complex systems: the part of their behaviour that depends on the context, including interaction with other units and role speci cation within the system, will be modelled by system laws.

4.2

Syncronized state transitions

In Section 3.3 we have seen how an object can modify the state of its components. Other two noticeable types of mutual in uence are frequently met: one corresponds to the case when the state of a compound object is modi ed according to those of its components, the other corresponds to the case when component states within a compound object aect each other. An example of the former situation is found examining the state diagram of the basic conveyor, reported in Figure 4, where state transitions are triggered by time expirations of the component timers: T8: Status eq Loading and LoadingTimer.Status eq Expired Status eq Error and Error eq 1 action update Status, Error:=1

f

g

!

A similar relationship is that implicitly represented with the virtual object R&H where its Status and Error attribute values depend on the Status and Error attributes of the component units. A case of inter-dependence between the states of two components involves the roller conveyor and the hoist within the rst shunter de nition (see the previous section). Here, law T4 asserts that the roller conveyor status assumes the Transit status when the upper photocell of the hoist is activated. Moreover, law L5 asserts that as soon as the roller conveyor status becomes Ready, the hoist can lower. The combination of the three types of mutual in uence between states constitutes a natural and simple means of structuring and syncronizing the behaviour of interacting units. Observe that this involves both legality and transition laws. As far as transitions are concerned, the result is an actual syncronization of state diagrams. The idea of state diagram hierarchy is not new [1]; what we propose is a partitioning criterion that enforces the level of representation modularity. 4.3

Code generation

Association of actions to laws must be made taking into account serializability. In general, a state variation can determine violations of a number of laws and, hence, execution of the corresponding actions. It is necessary that the result of these actions is independent of their execution order, otherwise it means that laws are mutually dependent. To remove dependences law changes are required, typically involving conjunction of predicates into a unique law, with a compound action. In order to analyze better this problem it is useful to imagine the way how the PLC code can be generated starting from the legality and transition laws of the EASIER representation.

The software module that controls a given unit acts on the unit state and, if any, on the states of its components. We establish an execution precedence between software modules: the controls of the component units are executed before than that of the upper level unit; in other words, the complex unit control always considers legal and steady component states. Thus, the problem of ensuring that the control decisions are independent of the execution order of the triggered actions can be examined within the single module. We identify two dierent ways of generating PLC code from the EASIER schema. The one, called sequential, consists in translating every law into a PLC triggering condition and the corresponding action into a routine: whenever the condition is violated, the routine is executed immediately to update the object state. The other, called parallel, consists in separating condition checking from action execution: the conditions are all triggered by the initial state while each routine is applied to the state resulting from the previous update. By comparing the object laws, it is possible to nd out the cases when the former coding solution is suitable, the cases when the latter solution is required and, by dierence, the cases that point out modelling errors or system design inconsistencies. { Exclusivity. This case occurs when, at each time, only a law can be violated, and the execution of the related action does not introduce new violations; then, both coding solution are allowed. Exclusive laws are those of the RollerConveyor, since their conditions are disjointed and independent of action results. { Sequential independence. This case occurs when two or more laws can be violated at the same time, but the nal state is not aected by the execution order of the associated actions. In particular, a triggered law should not move, with its action, other violated laws to legality or steadiness otherwise their actions would not be executed in their turn. A pair of laws that satis es this condition is found in the BasicConveyor de nition: L3: Status eq Transit or Status eq Error Sin eq Red action Sin:=Red T11: Status eq Transit and TransitTimer.Status eq Expired Status eq Error and Error eq 2 action update Status, Error:=2

)

f

f

g

! g

The nal state becomes, independently of the execution order: Sin eq Red, Status eq Error, Error eq 2. Even in this case both coding solutions are allowed. { Parallel independence. This case occurs when two or more laws can be violated at the same time and one of them moves, with its action, other violated laws to legality or steadiness. In order to ensure that all violated laws are executed, the triggering condition must

be checked before actions are executed, that is, following the parallel coding solution. A pair of laws that satis es this condition is found again in the BasicConveyor de nition: L3: Status eq Transit or Status eq Error Sin eq Red action Sin:=Red T12: Status eq Transit and Pout and Sout eq Red Status eq Busy and TransitTimer.Stop action update Status, TransitTimer.Stop:=True

)

!

f

f

g

g

The nal state is, with parallel execution: Sin eq Red, Status eq Busy, TransitTimer.Stop eq True. Predictability of system behaviour and estimate of software cycle execution time are basic requirements of a PLC-based control [19]. Even though no nal conclusion has still been drawn on the EASIER model capability of meeting them, we consider the proposed approach very promising in both directions. Concerning the former aspects, remember that we are dealing with the design of a software control running on a single PLC, so that problems of synchronization across the whole plant are not faced. Within this context, the control software is coded by translating the pairs (law, action). At compile time, law serializability is checked to ensure that system behaviour does not diverge; in addition, the EASIER schema is suitable to support simulation since the laws violated by every sys-

tem status con guration are easily identi ed together with the eects of their actions. The execution cycle duration is dicult to estimate in presence of loops and complex nested branches. The software resulting from translating laws and actions is strictly linear, no matter if satisfying the sequential or parallel serializability criteria. Besides, the number of actions to undertake with respect to a given system state is xed and the relative execution time can be evaluated. The worst case corresponds to the system state con guration that violates the largest number of laws.

5

Conclusions

We have seen how a hard software engineering problem, the design of re-usable software for programmable logic controllers, can be faced with the support of an objectoriented model. The model is speci cally conceived for representing structure and behaviour of reactive, realtime systems. Important modelling features are: identi cation of independent control modules by applying a bedded encapsulation mechanism, representation of system dynamics by means of synchronized state diagrams, recognition and representation of context-free behaviours of system components by introducing virtual objects. The EASIER model is under veri cation within the cited ESSI initiative; in particular, three application experiments are presently ending:

{ The rst application is a reverse software engineering experiment, aimed at formalizing the results of previous analyses in order to make them available to future analogous projects. The experiment derives an EASIER schema starting from the PLC code currently in use for controlling a traslo-elevator in an automated warehouse. { The second application is a forward engineering experiment, aimed at developing the software control for a picking bay while the same control is realized with traditional methods. This experiment is producing the rst elements of comparison of the two approaches, and it is the source of the examples reported in this paper. { The third application is again a forward engineering experiment, but carried out from scratch on the basis of customer speci cations. The aim is measuring the capability of the EASIER approach to support the whole software design and development process, without other aids. These experiments are producing quantitative and subjective information useful to evaluate the EASIER approach. The rst achievements indicate signi cant bene ts in terms of lower development time and cost, independence of PLC code of the programmer personal style, homogeneous documentation, faster debugging and, especially, a good rate of software re-use. In order to furtherly extend these results and take the highest advantage of the EASIER approach, the following activities are in progress: { A computer-aided support, based on the EASIER model, is under development to help the software designer in realizing complex and reliable application schemas. The package provides a number of correctness and consistency controls and constitute the kernel of forthcoming applications. { An automatic technique for PLC code generation is under study that constitutes the ultimate goal of this research. It calls for mapping functions from object structures to data declaration statements, and from laws and actions to PLC conditions and operations.

References [1] Harel D. et al., "Statemate: a working environment for the development of complex reactive systems", IEEE Trans. on Software Engineering, 16, 1990. [2] IEEE Trans. on Software Engineering, Special issue on Software for Critical Systems, 19, 1993. [3] Michel G., Laurgeau C., Espiau B., "Les Automates Programmables Industriels", Dunod Technique, Paris, 1979. [4] Meyer B., "Object Oriented Software Construction", Prentice Hall, 1988.

[5] Meyer B., "Eiel, the Language", Prentice Hall, 1992. [6] Ravn A. P., Rischel H., Hansen K. M., "Specifying and verifying requirements of real-time systems", IEEE Trans. on Software Engineering, 19, 1, 1993. [7] Wand Y., "A proposal for a formal model of objects", in Object-Oriented Concepts, Databases and Applications, W. Kim F. Lochowsky eds., Addison Wesley, 1989. [8] OMRON, "Sysmac Series C Programmable Controllers - Operation Manual". [9] Greenspan S., Mylopoulos J., Borgida A., "On formal requirements modelling languages: RML revisited", 16th Int. Conference on Software Engineering, ICSE-16, Sorrento, 1994. [10] Bonfatti F., Pazzi L., "Modeling object complexity and behaviour: towards an ontological paradigm", COMPEURO 91 Int. Conference, Bologna, 1991. [11] Bonfatti F., Monari P. D., Paganelli P., "Objectoriented constraint analysis in complex applications", D. Karagiannis (Ed.), Database and Expert Systems Applications, LNCS n. 856, SpringerVerlag, 1994. [12] Bonfatti F. et al., "The EASIER model", Deliverable 1.3, ESSI 10542 project, 1994. [13] Bertino E. et al., "Object-oriented query languages: the notion and the issues", IEEE Trans. on Knowledge and Data Engineering, 4, 3, 1992. [14] Bonfatti F., Monari P. D., "Towards a general purpose approach to object-oriented analysis", E. Bertino and S. Urban (Eds.), ObjectOriented Methodologies and Systems, LNCS n. 858, Springer-Verlag, 1994. [15] Atlee J. M., Gannon J., "State-based model checking of event-driven system requirements", IEEE Trans. on Software Engineering, 19, 1, 1993. [16] Q-labs (ed.), "REBOOT methodology Handbook", Technical Report 8218, 1993. [17] CJ International, "IsaGraf Manual", 1993. [18] Bucci G., Campanai M., Nesi P., "Tools for specifying real-time systems", Real-Time Systems, 8, 1995. [19] Stoyenko A. D., "The evolution and state-of-theart of real-time languages", The Journal of Systems and Software, 4, 1992.