Ν 1. Τ 5 Error X. Error

Transcription

1 PLC-Automata: A New Class of Implementable Real-Time Automata? Henning Dierks?? University of Oldenburg, Germany Abstract. We introduce a new class of automata which are tailored for dealing with real-time properties modelling the behaviour of Programmable Logic Controllers (PLC) that are often used in practice to solve controlling problems. A semantics in an appropriate temporal logic (Duration Calculus) is given and an implementation schema is presented in a programming language for PLCs that ts the semantics. Finally, a case study shows the suitability of this approach. Introduction In this paper we propose a language to specify real-time systems that ts both the needs of computer scientists and programmers of such systems. Formal specication and verication of real-time systems that are used in practice depend on the communication between the scientist who models the behaviour of the system by formal methods and the programmer who is working in practice with it. This language is motivated by the experiences we made in the UniForMproject [7] with an industrial partner. The aim of the project is the development of real-time systems in a workbench using combinations of formal methods. We present a formal semantics that allows formal reasoning and proving correctness using the Duration Calculus [4] which is a suitable temporal logic. We also give an implementation of such systems in a particular hardware called Programmable Logic Controllers (PLC). These PLCs are very often used in practice to implement real-time systems. The reason is that they provide both convenient methods to deal with time and an automatic polling mechanism. Nevertheless, every computer system can be used to implement the proposed language if a comparable handling of time and an explicit polling is added. Furthermore, the language can be viewed as a denition of a very small but implementable subset of Timed Automata [].? This research was partially supported by the German Ministry for Education and Research (BMBF) as part of the project UniForM under grant No. FKZ IS 52 B3.?? dierks@informatik.uni-oldenburg.de See the appendix.

2 2 The Behaviour of Programmable Logic Controllers Programmable Logic Controllers (PLC) are often used in industry for solving tasks calling for real-time problems like railway crossings, trac control, or production cells. Due to this special application background PLCs have features for making the design of time- and safety-critical systems easier: { PLCs have input and output channels where sensors and actuators resp. can be plugged in. { They behave in a cyclic manner where every cycle consists of the following phases: Polling all inputs and storing the read values. Compute the new values for the outputs. Update all outputs. The repeated execution of this cycle is managed by the operating system. The only part the programmer has to adapt is the computing phase. Thus, PLCs are implemented polling machines realising the typical method of solving time-critical problems in reality. { Depending on the program and on the number of inputs and outputs there is an upper time bound for a cycle that can be used to calculate the reaction time. { Convenient standardised libraries are given to simplify the handling of time. Although these characteristics are quite useful PLC-programmers have to face the following problem: If an input signal does not hold for at least the maximum amount of time needed for a cycle, one cannot be sure that the PLC will ever read this signal. This problem can be solved either by { changing the sensors used in the setting or by { using PLCs that are fast enough. The decision in which way the problem should be solved depends on availability and costs of both faster PLCs and sensors that assure longer lasting signals. Another important feature of PLCs is that they can be coupled: the output of one PLC can be the input of another PLC. In fact, their operating systems do not dierentiate between a sensor's input and a PLC's input and between an output to actuators or to PLCs respectively. Thus, the programmer is again obliged to consider how long an output signal from one PLC will be held and how long it must be held to make sure that it has been noticed by the other PLC. Note that this is one advantage of using PLCs. It obliges the programmer to check both his sensors and cycle time, which makes the assumptions concerning the hardware explicit.

3 3 The Denition of PLC-Automata In this section we propose a language which is designed for tting both the needs of computer scientists and engineers programming PLCs. Engineers, often being electrical engineers, are used to developing PLC-programs in assemblerlike languages or languages that are closely related to circuit diagrams. In the UniForM-project [7] we made the experience that automaton-like pictures can serve as a common basis for computer scientists and engineers because the latter gave them a semantics suitable to PLCs in an intuitive way. This was the motivation for us to formalise this language and to dene a formal semantics for it in a suitable temporal logic. On the one hand, this allows formal reasoning; on the other hand, this respects the behaviour of PLCs and the intuitive semantics given by the programmers. In the railway case study of the UniForM-Project we are dealing with problems like the following one: Problem 3.. Consider a train detecting sensor that signals \" if a train is approaching and \" if not. Unfortunately, the sensor can stutter for at most four seconds after a train has passed the sensor. Assume that the distance between two subsequent trains is at least six seconds. Develop a system that lters the stuttering. The automaton in Fig. shows such a device. This gure denes a PLCautomaton consisting of two states N and T. It reacts on the lter's input or accordingly. This automaton should behave as follows: { It starts in state \N". { It polls the input. { If it is in state \N" and the input is \", it changes to state \T". { Now the automaton holds this state for ve seconds. Afterwards it remains in this state as long as polling the input yields a \". { Otherwise it changes to state \N" and continues as before. Ν T 5 Figure. Filtering device. Thus, counting the trains that passed the sensor simply requires to count the changes from \N" to \T". Filtering the stuttering is done by ignoring the input for ve seconds. Note that we have to assume an upper bound for the cycle time in order to detect subsequent trains correctly. A semantics of these automata should enable us to calculate this upper bound. This sort of automaton and the informal description of its behaviour is a result of our discussions with industrial experts.

4 A more sophisticated problem is: Problem 3.2. Consider the train detecting sensor given in Problem 3. again, but now let it be equipped with a watch dog that detects failures of the device by the signal \Error". The task is now to lter the stuttering and to recognise such errors as soon as possible. Ν Τ 5 Error X Error Figure 2. Filtering device with detection of errors. Σ We want to enhance the automaton of Fig. in order to react on the \Error" signal immediately. Therefore, an error state X is added to represent this information (Fig. 2). The additional transitions are trivial: Whenever there is the signal \Error" the automaton should change its state to \X". However, this automaton does not solve Problem 3.2. Consider the case when an \Error" occurs immediately after a change from \N" to \T". In this case the automaton would not change to \X" immediately because it is required to stay at least ve seconds in \T". Ν,Σ Error X,Σ Τ 5,{,} Error Figure 3. Filtering device with immediate detection of errors. Read as f; ; Errorg. Σ To overcome this problem we introduce a set of inputs for each state of the automaton. The informal meaning of a state equipped with a delay time t and a set A of inputs is that inputs contained in A are ignored for the rst t seconds staying in this state. Inputs outside A are never ignored, i.e. they force the automaton to react immediately. Figure 3 shows how this extension can be used to solve Problem 3.2. It behaves the same way as the automaton of Fig. provided that no \Error" signal occurs. If an \Error" occurs, the automaton of Fig. 3 changes to state \X" regardless in which state it was before and how long

5 it was there. Summarising this we dene an automaton-like structure extended by some components: Denition 3.3. A tuple A = (Q; ; ; ; "; S t ; S e ; ;!) is a PLC-automaton if { Q is a nonempty, nite set of states, { is a nonempty, nite set of inputs, { is a function of type Q?! Q (transition function), { 2 Q is the initial state, { " > is the upper bound for a cycle. { S t is a function of type Q?! IR assigning to each state a delay time how long the inputs contained in S e () should be ignored, { S e is a function of type Q?! P() n f;g assigning to each state a set of delayed inputs that cause no change of the state during the rst time units the automaton stays in this state, { is a nonempty, nites set of outputs, {! is a function of type Q?! (output function) and it holds 8 2 Q; a 2 : S t () > ^ a =2 S e () =) (; a) 6= : () The additional components are needed to model PLC-behaviour and to enrich the language for dealing with real-time aspects. The " represents the upper bound for a cycle of a PLC and enables us to model this cycle in the semantics. More dicult to understand are the functions S t and S e. They attach to each state of A a delay time and a set of inputs. We want the automaton to remain in state for at least S t () seconds provided that only inputs in S e () are read. In other words inputs in S e () are ignored for the rst S t () seconds. An equivalent description is that the state is held for S t () seconds, but if during this period an input in n S e () is read the automaton will react immediately. The restriction () is introduced because the set n S e () is intended to be a set of \emergency exits" and we expect that such an exit leads to a state dierent from. PLC-Automata look similar to Timed Automata [] but the details are dierent. Although a transformation of a PLC-Automaton into a Timed Automaton can be given, the result is a much more complicated description because we have to switch from a state-based to an event-based formalism. Another reason is that we have to consider that the PLC is not obliged to react on all input signals. 2 4 The Duration Calculus In this section we recall the Duration Calculus, a logic which is particularly appropriate to formulate the semantics of a PLC-automaton (see Sect. 5). The 2 See the appendix for details.

6 Duration Calculus [4, 3] is a real-time interval temporal logic extending earlier work on discrete interval temporal logic of [9]. A formal description of a realtime system using Duration Calculus (DC for short) starts by choosing a number of time-dependent state variables or observables obs of a certain type. An interpretation I assigns to each state variable a function obs I : Time?! D where Time is the time domain, here the non-negative reals, and D is the type of obs. State assertions P are obtained by applying propositional connectives to elementary assertions of the form obs = v (v for short if obs is clear) for a v 2 D. For a given interpretation I state assertions denote functions P I : Time?! Bool: Duration formulae F are evaluated in a given interpretation I and a given time interval [b; e] Time. The basic syntax of duration formulae is as follows: R { Duration: P = k expresses that the duration of the R state assertion P in e [b; e] is k. Semantically, duration is the measurement P b I(t)dt. { Chop: The composite duration formula F ; F 2 (read as F chop F 2 ) holds in [b; e] if this interval can be divided into an initial subinterval [b; m] where F holds and a nal subinterval [m; e] where F 2 holds. { Connectives: Duration formulae are closed under propositional connectives. Besides this basic syntax R various abbreviations are used: length: ` = df true point interval: de = df ` R = everywhere: dp e = df P = ` ^ ` > somewhere: 3F = df true; F ; true always: 2F = df :3:F F t = df (F ^ ` = t) A duration formula F holds in an interpretation I if F evaluates to true in I and every interval of the form [; t] with t 2 Time. The following so-called standard forms are useful to describe dynamic behaviour: { followed-by: F?! dp e = df 2:(F ; d:p e) { timed leads-to: F?! t dp e = df (F ^ ` = t)?! dp e { timed up-to: F?! t dp e = df (F ^ ` t)?! dp e As before we have t 2 Time. Intuitively, F?! dp e expresses the fact that whenever a pattern given by a formula F is observed, then it will be \followed by" an interval in which P holds (cf. Fig. 4). In the \leads-to" form this pattern is required to have a length t (Fig. 4), and in the \up-to" form the pattern is bounded by a length \up to" t. Note that the \leads-to" does not simply say that whenever F holds then t time units later dp e holds; rather, a stability of F for t time units is required before we can be certain that dp e holds. The \up-to" form is mainly used to specify certain stability conditions. For example d:e ; de?! t de is an expression that is true i is stable for at least t seconds whenever becomes true.

7 F F P P t t2 Q time t t t2 t Q time Figure 4. Example for \followed by" and \leads to". The left gure exhibits an interpretation for F, P and Q. In this interpretation F?! dp e is true because for every interval in which F holds there is a succeeding interval in which dp e is true. F?! dqe is not true: choosing the interval [t,t2] there is no succeeding interval in which dqe holds. The t right gure demonstrates the meaning of?!. There are two phases where F is true and the former phase lasts longer than t seconds. F?! t dp e holds because for every interval of length t in which F holds there is a succeeding interval in which dp e is true. F?! t dqe is not true: choosing the interval [t; t2] there is no succeeding interval in which dqe holds. 5 A Duration Calculus Semantics for PLC-Automata In this section we dene the semantics of the PLC-automata proposed in Sect. 3 with DC-formulae. This enables us to prove real-time properties of such automata by means of logical reasoning. The semantics [A] DC of a PLC-automaton A = (Q; ; ; ; "; S e ; S t ; ;!) is given by the conjunction of the following predicates regarding the observables state : Time?! Q, input : Time?! and output : Time?!. First of all, the starting of the automaton in the proper initial state is expressed by: d e ; true _ de : (2) Note that d e is an abbreviation of dstate = e. Next, we want to describe the behaviour of the automaton in state. The cyclic behaviour of PLCs has to be reected in the semantics to achieve a realistic modelling. One question the semantics should answer is: When a state is entered, what kind of input can inuence the behaviour of the PLC? The answer to this question is: { only the inputs after entering and { only the inputs during the last cycle-time. This is expressed by the following predicates where A ranges over all sets of

8 inputs with ; 6= A : 3 d:e ; d ^ Ae?! d _ (; A)e (3) d ^ Ae?! " d _ (; A)e (4) The statement (3) formalises the fact that after a change of the automaton's state to only the set of inputs A that is valid after the change can have an eect on the behaviour in the future. The statement (4) represents the formalisation of the cyclic behaviour of PLCs. A PLC reacts only on inputs during the last cycle. Preceding inputs are forgotten and cannot inuence the PLC anymore. The quantication over all nonempty subsets of the input alphabet was motivated by the behaviour of the PLCs. The more we know about the inputs during the last cycle the more we know about the actions of the PLC. For example, it is necessary that an input a is held for at least " seconds to assure that the PLC reads this at least once. This is directly reected in the semantics as well. If there is an interval of length ", predicate (4) can be applied with A = fag to this interval. This implies that after this interval is over either the state changes to (; a) or remains unchanged. For states without a stability requirement we expect a change to (; a) or more generally we expect that the automaton reacts accordingly in at most 2" seconds. For states with a stability requirement we expect this behaviour after the required period of time. This leads us to additional statements in the semantics: S t () = =) d ^ Ae?! 2" d(; A)e (5) S t () > =) de ; d ^ Ae 2" 2"+S t()?! d(; A)e (6) S t () = ^ =2 (; A) =) d:e ; d ^ Ae "?! d:e (7) Statement (5) says that after at most 2" seconds the automaton reacts on the input accordingly if there is no stability required for. Note that " seconds are needed to assure that the PLC read at least once and " seconds are needed to react on this input in the worst case. Formula (6) states this behaviour after S t () seconds: if S t () seconds have elapsed the automaton reacts on inputs in at most 2" seconds. In the case that we know that the automaton has just changed the state then we want to be able to exploit the information that within the next " seconds another reaction on the input A has to occur. This is formalised by (7). Next we want to describe the automaton's behaviour if it is in a state where a stability is required and the S t () seconds have not elapsed. Then we want to hold this state provided that during this phase only inputs in S e () are read. That means inputs in S e () cannot cause a change of state during the rst S t () seconds: S t () > =) d:e ; d ^ Ae St()?! d _ (; A n S e ())e (8) 3 In the formulae we use A as an abbreviation for input 2 A resp. (; A) for state 2 f(; a)ja 2 Ag.

9 However, we have to take into account the cyclic behaviour of the hardware again. In particular, we should require that if is left during the stability phase then there has to be an input not contained in S e () at most " seconds ago: S t () > =) d:e ; de ; d ^ Ae " S t()?! d _ (; A n S e ())e (9) Furthermore, we know that the automaton reacts according to the input if there is a set A that is valid for the last 2" seconds and disjoint from S e (): S t () > ^ A \ S e () = ; =) d ^ Ae?! 2" d(; A)e () S t () > ^ A \ S e () = ; =) d:e ; d ^ Ae "?! d:e) () Formula () corresponds to (7). Due to () we know =2 (; A). Note that (3), (7), (8), (9), and () require a change from d:e to de to restrict the possible behaviour. But for the initial state there is no change and therefore the assertions are not applicable in this case. This can be expressed by ve corresponding assertions suitable for the initial state, which for brevity are omitted here as they do not provide any new insight into the PLC-Automaton. Finally, the relation between the observables state and output is established by 2(de =) d!()e) (2) 6 Implementing PLC-Automata on PLCs In this section we want to describe how the PLC-automata can easily be implemented in PLCs. To this end we use the language \ST" (structured text [8, 6]) that provides all usual basic constructs of imperative languages and that is used in reality for programming PLCs. We illustrate its usage by means of an example. Let A = (Q; ; ; ; "; S e ; S t ; ;!) be a PLC-automaton. Without loss of generality we assume Q = f; : : : ; ng, = f; : : : ; mg, and =. Then the behaviour of it can be implemented by the following ST-program: VAR state : INT :=; END VAR timer : TP; (* Timer Type *) time up : BOOL := FALSE; CASE state OF. i: (* state = i, no stability required *). state:= (i,input); (* end of state=i *)

10 k: (* state = k, stability required *). END CASE output:=!(state); timer(in:=true, PT:=t#S t (k)); time up:=not timer.q; CASE input OF. l: (* l=2 S e (k) *). state:= (k,l); timer(in:=false, PT:=t#S t (k)); m: (* m2 S e (k) *). END CASE; IF time up THEN state:= (k,m); timer(in:=false, PT:=t#S t (k)); END IF; For all three cases it is shown what the PLC has to do. If S t () = for a state, it just has to poll the input and behave accordingly (* state = i*). Otherwise it has to call the timer with the corresponding time value S t () (* state = k *). Setting the parameter IN to TRUE makes the timer start running for PT seconds if it has not started already. The next statement reads the output Q of the timer. It is TRUE if the time since the starting of the timer has not exceeded PT. Thus, the rst two statements for the case state=k in the listing start the timer if needed and check whether the stability time is over or not. Now the PLC has to check the input. If it is an input that is not in S e (k) (* l=2 S e (k) *) the PLC changes the variable state accordingly and stops the timer by calling it with IN set to FALSE. Otherwise (* m2 S e (k) *) it does the same provided that the time is over. Note that this ST-program is executed once in each cycle of the PLC. So it is the body of an implicit loop-forever statement. 7 Useful Theorems for PLC-Automata This section demonstrates one major advantage of using PLC-automata for specifying controllers: the semantics given in Sect. 5 allows formal reasoning in Duration Calculus leading to reusable theorems. Just to give an idea of what can be formally established we state the following theorem and demonstrate its usefulness. This theorem provides information on how long it takes at most to reach a certain set of states. Often it is necessary that the controller enters a set of

11 states provided that a special set A of inputs holds. Usually the controller is therefore specied in such a way that it will reach after several transitions. Provided that n (Q; A) for some n 2 IN the theorem estimates the delay until is reached in the worst case. 4 Theorem 7.. Let A = (Q; ; ; ; S e ; S t ; ;!) be a PLC-automaton and let Q and A with (; A) : Then we have for all n 2 IN : with where s(; A) = df c(n) =" df + max d ^ Ae c(n)?! d n (; A)e (3) 8 < kx : i= s( i ; A) "; if A \ S e () = ; S t () + 2"; otherwise k n ^ 9 ; : : : ; k 2 n n (; A) : 8j < k : j 2 ( j? ; A) 9 = ; (4) (5) Example 7.2. Consider Fig. 3 again. We can apply Theorem 7. to this automaton and get, for example, the assertions below. To get the last one Theorem 7. is applied with n =. d ^ :Xe 5+3"?! dne derrore?! 2" dxe d ^ T e?! " dt e 8 A Case Study The following case study illustrates how fast and ecient real-time systems can be specied and implemented by PLC-automata in comparison with the conventional ProCoS-style. To this end we choose the well-known case study of the ProCoS-project. It is a gasburner [] that is controlled by a thermostat; it can directly control a gas valve and monitor the ame @ Gas Valve - Thermostat ` ((( hhh Flame sensor Figure 5. The gasburner 4 (; A) = df and n+ (; A) = df f(q; a)jq 2 n (; A); a 2 Ag for Q and A.

12 There are three Boolean observables describing this physical system. hr (\heatrequest") represents the state of the thermostat. (\ame") represents the presence of a ame at the gas valve. gas (\gas") represents the state of the gas valve. One of the requirements is the formula below which assures that in every period of 3 seconds gas must not leak for more than four seconds: 2 ` 3 =) Z (gas ^ :fl) 4 : (6) In the ProCoS-project [2] this case-study was transformed rst from Duration Calculus into a certain subset of Duration Calculus called Implementables. This yielded a specication of a controller using four states (idle, purge, ignite, burn) fullling the following assertions: de _ didlee ; true (7) didlee?! didle _ purgee dpurgee?! dpurge _ ignitee (8) dignitee?! dignite _ burne dburne?! dburn _ idlee (9) d:purgee ; dpurgee 3?! dpurgee d:ignitee ; dignitee?! dignitee (2) dpurgee 3+"?! d:purgee dignitee +"?! d:ignitee (2) d:idlee ; didle ^ :hre?! didlee d:burne ; dburn ^ hr ^ e?! dburne (22) didle ^ hre?! " d:idlee dburn ^ :hre?! " d:burne (23) dburn ^ :e?! " d:burne (24) The gas valve should be opened i state is in fburn; igniteg. hr no gas hr no gas idle,σ 3,Σ purge fl hr Σ burn gas,σ Σ gas,σ ignite (fl,hr) Figure 6. The gasburner as PLC-automaton. In the ProCoS-project this specication was transformed via several steps and interfacing languages to hardware. Due to the special suitability of PLCs to control real-time systems we need not perform these transformations here. It is sucient to read the specication given above as a specication of a PLCautomaton, which leads us to the PLC-automaton in Fig. 6. The semantics of

13 the PLC-automaton in this gure renes the specication given in (7){(24). Table shows which assertion of the semantics fulls the requirements of the specication. The only assumption made is 2" ". This tells the implementor how fast his PLC has to cycle in the worst case. And this problem normally corresponds to the question: \How much money do we have to spend in order to guarantee that the upper time bound is not violated?" requirement is rened by : : : of the semantics (7) (2) (8){(9) (3) with A = (2) (8) with A = (2) (6) with A = and assuming that 2" " (22) (3) with A = f:hrg resp. A = fhr ^ g (23){(24) (5) with A = fhrg, A = f:hrg, or A = f:g Table. Fig. 6 renes (7){(24). 9 Concluding Remarks Currently we are investigating extensions that allow us to introduce additional variables in order to make the PLC-automata more exible. A typical problem that is dicult to solve by PLC-automata as presented here is: \Is this train the n-th one?". To answer this question with the PLC-automata proposed in this paper is likely to cause an explosion of states because we have to model n with the help of the states. To overcome this problem we are thinking about introducing variables and extending transitions by predicates over these variables. Depending on these predicates the PLC-automaton is allowed to make transitions or not. Furthermore, they should describe how variables are changed when a transition takes place. These extensions should allow a parametric design without loss of the advantages presented here. Moreover, it is necessary to structure the design for systems of higher complexity. To this end we are aiming at a combination of PLC-Automata with Z [] and CSP [5] which is part of our project UniForM [7]. We are also looking for comprehensive case studies to evaluate our approach. As a result of our experiences with case study of the UniForM-project we think that our approach is a very promising one, because we start from a formal temporal description technique and nally reach an implementation on hardware that is used in real life. Furthermore, we can make quantitative assessments of this hardware. Acknowledgements I would like to thank E.-R. Olderog, H. Becker, J. Knoop, C. Dietz, C. Fischer, and other members of the \semantics group" in Oldenburg for detailed comments and various discussions on the subject of this paper.

14 References. R. Alur and D.L. Dill. A theory of timed automata. Theoret. Comput. Sci., 26:83{235, J. Bowen, C.A.R. Hoare, H. Langmaack, E.-R. Olderog, and A.P. Ravn. ProCoS II: A ProCoS II Project Final Report, chapter 7, pages 76{99. Number 59 in Bulletin of the EATCS. European Association for Theoretical Computer Science, June Zhou Chaochen. Duration Calculi: An overview. In D. Bjrner, M. Broy, and I.V. Pottosin, editors, Formal Methods in Programming and Their Application, volume 735 of Lecture Notes in Computer Science, pages 256{266. Springer-Verlag, Zhou Chaochen, C.A.R. Hoare, and A.P. Ravn. A Calculus of Durations. Inform. Proc. Letters, 4/5:269{276, C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall International, K.-H. John and M. Tiegelkamp. SPS-Programmierung mit IEC 3-3. Springer- Verlag, 995. in German. 7. B. Krieg-Bruckner, J. Peleska, E.-R. Olderog, D. Balzer, and A. Baer. UniForM Universal Formal Methods Workbench. In U. Grote and G. Wolf, editors, Statusseminar des BMBF Softwaretechnologie, pages 357{378. BMBF, Berlin, March R.W. Lewis. Programming industrial control systems using IEC 3-3. The institution of Electrical Engineers, B. Moszkowski. A Temporal Logic for Multilevel Reasoning about Hardware. IEEE Computer, 8(2):{9, A.P. Ravn, H. Rischel, and K.M. Hansen. Specifying and Verifying Requirements of Real-Time Systems. IEEE Transactions on Software Engineering, 9:4{55, January J.M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science, second edition, 992. A A Timed Automata Semantics for PLC-Automata In this appendix we discuss the relationship between the PLC-Automata and the well-known Timed Automata []. We will dene a semantics for PLC-Automata expressed in terms of Timed Automata. This denition has several distinct sideeects: We get a denition of a subset of Timed Automata, namely the set of Timed Automata that are the semantics of a PLC-Automata. By the results of Sect. 6, this subset has an implementation in PLC. Thus, this subset fulls the criterion of realisability. Furthermore, we can apply the results established for Timed Automata. They include various theorems about their behaviour and their connection to tools built for Timed Automata, for example Kronos. Denition A.. For a given PLC-Automata A = (Q; ; ; ; "; S e ; S t ; ;!) with Q\ = ; we dene the corresponding Timed Automaton T A(A) as follows: T A(A) = df h ; S; S ; C; E; F i with df = [ Q, S = df f(; a) j 2 Q ^ a 2 g,

15 df S = f( ; a) j a 2 g, C = df fx a j a 2 g [ fy; zg, F = df S, and and E df = f((; a); (; a ); a ; fx a g; z ") j 2 Q; a 6= a 2 g (25) [ [ [ ((; a ); ( ; a ); ; C(; ); (; a; a )) 2 Q; a; a 2 ; = (; a) ((; a ); (; a ); ; fzg; (; a; a )) 2 Q; a; a 2 ; S t () > C(; ) = df (; a; a ) = df (; a; a ) = df (; a ); (; a ); ; fzg; S t() < y < S t () + " ^z " ( fy; zg 6= 8 >< >: S t () > (26) (27) (28) fzg = (29) z "; a = a ^ :(S t () > ^ a 2 S e ()) z " ^ y > S t (); a = a ^ S t () > ^ a 2 S e () x a < " ^ x a < y ^ z "; a 6= a ^ :(S t () > ^ a 2 S e ()) x a < " ^ x a < y ^ z " ^y > S t (); a 6= a ^ S t () > ^ a 2 S e () (3) ( z " ^ y S t (); x a < " ^ x a < y ^ z " ^ y S t (); a = a ^ a 2 S e () a 6= a ^ a 2 S e () (3) The Timed Automata semantics [A] TA for A is the timed language L(T A(A)). T A(A) is a Timed Automaton with the pairs of states and inputs of A as states. It is equipped with one clock x a for each input a. The x a are used to measure how long the input a has not held. The clock y is used to check whether S t () has already elapsed or not. To ensure progress an additional clock z is introduced. The transition relation consists of three parts. The rst part (25) introduces transitions that react on the inputs without any clock constraints. The inputpart of the state changes accordingly and the corresponding input-clock is reset. (26) introduces transitions that model the behaviour of A in after S t () seconds have elapsed. The clock y is reset i the state changes. The clock constraints ensure three properties: { The constraint z " models the cyclic behaviour of the PLC. { x a < z models the fact that the PLC can react on every input that has held during the last cycle. This constraint is only necessary when the last input a is not equal to a. { y > S t () ensures the required time of stability of state. This is not necessary if S t () = or if the input a that is read by the PLC is not in S e ().

16 (27) introduces transitions that model the behaviour of the PLC-Automaton during the rst S t () second in state. They allow input a to be read in a cycle but do not react on this input provided that a 2 S e (). Due to this Timed Automata semantics PLC-Automata can be understood just as an abbreviation of Timed Automata that full certain properties. However, we claim that it is more useful to work with PLC-Automata instead of a very restricted subset of Timed Automata. The reason is that it is quite complicated and error prone to check whether a Timed Automaton fulls the necessary conditions. Furthermore, we claim that is it much easier to specify PLC-Automata and to understand their behaviour. For example, consider the automaton in Fig. 3. The Timed Automata semantics of this PLC-Automaton consists of 9 states, 5 clocks, and 57 transitions.