• Aucun résultat trouvé

Verification of a timed concurrent system with UPPAAL

N/A
N/A
Protected

Academic year: 2021

Partager "Verification of a timed concurrent system with UPPAAL"

Copied!
9
0
0

Texte intégral

(1)

HAL Id: hal-01149806

https://hal.archives-ouvertes.fr/hal-01149806

Submitted on 7 May 2015

HAL

is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire

HAL, est

destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Verification of a timed concurrent system with UPPAAL

Mohammed Achkari Begdouri, Houda Bel Mokadem

To cite this version:

Mohammed Achkari Begdouri, Houda Bel Mokadem. Verification of a timed concurrent system with

UPPAAL. QUALITA’ 2015, Mar 2015, Nancy, France. �hal-01149806�

(2)

Verification of a timed concurrent system with U PPAAL

Mohammed A

CHKARI

B

EGDOURI

Labtic – Ecole Nationale des Sciences Appliqu´ees de Tanger, BP 1818 Tanger Principal, Tangier, Morrocco

achkari.med@gmail.com Houda B

EL

M

OKADEM

Labtic – Ecole Nationale des Sciences Appliqu´ees de Tanger, BP 1818 Tanger Principal, Tangier, Morrocco

houda.belmokadem@gmail.com

Abstract

In recent years, the verification of timed systems has been subject of strong development, both in terms of its theoretical foundation as its applications. Its purpose is to check the properties of validity and dependability in a formal and exhaustive way. In particular, model checking allows the verification of properties by browsing all possible states of the system model. However, this method has often combinatorial explosion problem, which can be even worse in the case of concurrent systems. In this paper, we presents some effective abstractions, used for modeling this kind of systems, implemented through a case study with the tool UPPAAL. We then give a comparison, in terms of time execution and states space, between the proposed abstractions to model concurrency.

Keywords: Programmable Logic Controllers, Timed Automata, Model Checking, Concurrent Systems.

1 Introduction

In some critical embedded systems, errors of con- trol programs can cause serious system failures. Thus, verification of safety properties for PLC programs (Pro- grammable Controllers Logic) is now recognized as an important issue for manufacturers and users.This explains the increasing interest in the past few years for the appli- cation of formal methods to the analysis of such programs [1, 3]. In this area, work was mostly devoted to the un- timed framework [11], [6, 10]. When considering quanti- tative aspects related to time, modeling must involve addi- tional mechanisms. One model that has been widely stud- ied and successfully used since the 1990s is that of timed automata, introduced by [4, 5]. Validation becomes more difficult, because of the additional combinatorial explo-

sion due to time. The study of these models, however, led to positive decidability results and was followed by the development of verification tools like HYTECH[8], KRO-

NOS [7] or UPPAAL[9], which have been applied to in- dustrial case studies. Timed automata have recently been used for the modeling of timed features in PLC program- ming.

In this work, we are interested in the combination of multitask PLC programming with concurrent tasks exe- cution. Our case study concerns the so-called SOLUJET platform from Ravoux automatism [22] which is a Sys- tem of solutions conditioning in vials, these solutions can be toxic. The choice of this platform is mainly due to two reasons, the first is that this platform does not have a simulation module to check the correctness of the con- trol program, which makes formal verification an inter- esting contribution. The second reason is that this plat- form presents a concrete case of concurrent tasks execu- tion which is the aim of our study. The program is written in Grafcet Diagram, one of the languages most commonly used in this area. We give also semantics for timer func- tion blocks, in terms of timed automata, and we also pro- vide a timed automata based model for the operative part of the system. These timed automata are described in UP-

PAALsyntax. We propose here some abstractions which allow us to reduce significantly the size of the complete model, so these abstractions consist in reducing interlaces and merging of automata, which contribute to around the concurrency modeling problem, and lead to reasonnable verification times for the response property to be checked.

We also use a simpler model for timers as given in [1], using particular features of UPPAAL.

The next section of the paper explains the context of this study: the problem of concurrency in PLC programs, and includes a description of timed automata and a short presentation of UPPAAL. In Section 3, we give more de- tails on SOLUJET platform and in Section 4, we give the

(3)

semantics of the control program. Section 5 presents the timed automata which form the components of the net- work. While Section 6 gives the proposed abstractions to model concurrency, and gives a comparaison between these abstractions and results of verification task.

2 Context

2.1 Concurrency aspect

The exhaustivity of the model checking technique induces the problem of combinatorial explosion of the state space of the system. The analysis process is often limited by the complexity of memory space required to store the state graph. The total memory used depends on two criteria: the memory space for storing a given state, and the total number of states of the graph. Memory storage size of a state depends on the parameters of the system stored in this state: linear complexity in the number of variables of the system and the automata number (storing the state of each PLC model) and complexity of the continuous part of the state. In the context of systems modeled by timed automata, the state space is shown in a graph of regions where the number of states is exponential with the number of system clocks and the maximum constant present in the constraints on clocks [4, 5].The symbolic representation of the regions in zones [13] is used to represent the state space more compactly, with a memory complexity of storage zone dependent on the number of constraints on the clocks (in the worst case polynomial in the number of clocks, but on average less complex). Other existing and implemented in UPPAAL optimizations are intended to improve the implementation of the states in memory, and the number of stored [14] [15] [16] [9]. The accurate determination of the complexity of the analysis UPPAALprocess is very difficult, it remains dependent on previously mentioned factors.

Another important parameter of the analysis process complexity is the graph of zones states number. In the context of concurrent systems, this parameter has a very high complexity. The concurrency of these transitions is a major cause of the increasing number of states in the interlacing of transitions (see section 6). Reducing in- terlaces is a known problem in the field of concurrent systems. Many so-called partial order techniques [17]

[18] can prevent browsing of several execution paths when they are equivalent from the perspective of the property to check.These techniques, however, do not apply easily to real-time systems, and there is little work on timed au- tomata offers a solution to timed automata communicat- ing through buffers solution. Under the timed automata communicating through synchronization, a method is pro- posed by Bengtsson J. [19] then Minea M. [20] based on the consideration of the desynchronisation of local clocks of automata outside simultaneous transitions (transmis- sion / reception of a synchronizing signal). In this case,

a temporal resynchronisation of temporal regions is per- formed to ensure the reliability of the behavior. This tech- nique is based on a specific semantics and requires a spe- cial implementation of the algorithm for model checking.

Also, some partial-order techniques, could be applied un- der certain conditions to timed systems, at always the cost of a significant change of the analysis algorithm. As part of the modeling and validation with the UPPAALtool, we present in this paper some abstractions rules applied be- fore the analysis process, without modifying the model checking algorithm. These abstractions can reduce model elements: reducing the number of concurrent transitions, the number of automatons and hence the complexity of the analysis.

2.2 Timed automata

Timed automaton was introduced by Alur and Dill [4], [5]. It consists of finite automaton, which handles a finite set of variables called clocks. The clocks are used for the specification of quantitative time constraints which may be associated with transitions. These variables evolve syn- chronously with time (slope1).

For a setXof clocks,P(X)denotes the powerset ofX and we defineC(X)as the set of conjunctions of atomic formulas of the formx cfor a clockx, a constantcand in{<,≤,=,≥, >}.

A timed automaton is a tupleA = (Σ, X, Q, q0, I, E), whereΣis a finite set of actions, X is the finite set of clocks,Qis a finite set of locations, withq0∈Qthe initial location,Iis a mapping associating with each locationq a clock constraintI(q)∈ C(X), andE ⊆Q× C(X)× Σ× P(X)×Qis the set of transitions.

The clock condition I(q) is called an invariant for locationq, and contains usually only atomic formulas of the formx≤corx < cwhich must hold as long as time elapses in this location.

A transition of the automaton, writtenq −−−→g,a,r q ∈Eis equipped with a label containing three parts (each one is optional): a guardg expressing a condition inC(X)on clock values, which must be satisfied for the transition to be fired, an action name inΣ, and a clock resetr∈ P(X). The semantics of a timed automaton is given in terms of transition systems. A configuration of the system is a pair(q, v), whereqis a location of the automaton andv is a valuation of the variables, i.e. a mapping associating a real value with each clock. The initial configuration is (q0, v0)where all clock values are equal to0inv0. The system may change its configuration in two ways.

Either by a delay move of d time units, written (q, v) −→d (q, v+d), possible ifv+dsatisfies the invariantI(q)of locationq.

Or by an action move, written(q, v) −→a (q, v), as- sociated with a discrete transitionq−−−→g,a,r q, ifvsat- isfies the constraintg. In this case, the reset operation

(4)

yieldsv(x) = 0ifxbelongs torandv(x) =v(x) otherwise, andvmust satisfy the invariant ofq. 2.3 The tool UPPAAL

The tool UPPAAL(see [12] for the more recent devel- opments) offers a compact description language, a simula- tion module and a model-checker. A system is represented by a collection for timed automata, which communicate through binary synchronization: a channel c can be de- fined for two automata. Sending a message is denoted by the discrete actionc!while receiving the message is de- noted byc?. An UPPAALautomaton also handles integer variables. A guard is a conjunction of atomic clock con- ditions and similar conditions on integer variables. More- over, a clock reset may be augmented by an update of the integer variables.

A (global) configuration is of the form (, v) where is a location vector (indicating the current state in each component of the timed automata network) and v is a valuation of both clocks and discrete variables. An execution in the network starts in initial locations of the different components with all the clocks and variables set to zero. The semantics of this model is expressed by moves between the configurations. Three types of moves can occur in the system: delay moves, internal moves and synchronized moves. Delay moves and internal moves have already been described above for a single automaton, so we simply describe now the global evolution.

Delaying. Given a current location vector, time elapses for all automata synchronously, as long as no invariant is violated. All clock values increase by the amount of time elapsed. No change occur for the locations or the integer variables.

Performing an internal action. An internal action is an action which corresponds to neither c! (sending a mes- sage), norc?(receiving a message). If such an action is enabled (the variable values satisfy the guard condition), the component can perform this action alone, while the others do nothing. Only the location of this component is changed, as well as its variables, according to the transi- tion.

Synchronizing. If, in the network, some complementary actionsc!andc?are enabled in two components (in par- ticular, guards must be satisfied by the current valuation), then these components must synchronize. The location vector is changed for both components and the clock and variable values are changed according to the clock reset and updates of variables for the two transitions.

Finally, we introduce three additional features of UP-

PAALwhich will be very useful in our modeling.

An urgent location (decorated by the special labelU) semantically equivalent to adding an extra clock x, that is reset on all incomming edges, and having an invariant x <= 0 on the location. Hence, time is not allowed to pass when the system is in an urgent location.

A committed location (decorated by the special label C) is even more restrictive on the execution than ur- gent locations. A committed location is the same as a urgent location but the next transition must involve an outgoing edge of at least one of the committed lo- cations of the network. This difference is perceptible only when two transitions are concurrent: an outgo- ing transition from committed location will be exe- cuted in priority order, while that coming out from urgent location does not have priority over other ex- ecutable transitions at the same time.

A broadcast channel is a channel where more than two automata may communicate: emission of a mes- sagec!can be synchronized with several receptions c? in other components. Note that this is a non- blocking synchronization, since the sender is never blocked, although the receiver must synchronize if it can. Guards on clocks are not allowed on the receiv- ing edge.

3 Description of the SOLUJET platform

Figure 1: Presentation of SOLUJET platform

Presentation. The line Solujet (figure1) was inspired by an industrial process in the chemical sector. It was devel- oped by RAVOUX Automatism, which specializes in the design conditioning units. This line prepares and condi- tions solutions in vials that are sorted according to their statements. The process is carried out through three mod- ules: Module of solutions preparation, module of solu- tions conditioning and module of vials handling and sort- ing.

Our study is centered on module 2 (module of solutions conditioning) which is intended to dose a quantity of so- lutions for dumping in vials and to distribute caps on the vials and then screw them.

Schematic diagram. The vials, distributed automati- cally to an accumulation table, are conveyed by the tray and transferred successively to the filling station, plugging and screwing. The caps distributed by a ramp, are placed

(5)

on the vials. The filled and capped vials are evacuated on the conveyor (figure2).

Figure 2: Module of solutions conditioning

Issue detected. The system studied in this context in- volve modeling of concurrency. In fact, there may be two vials simultaneously at the filling and screwing posts, and therefore these two tasks are concurrent. This problem is one of the foundations of the parallel systems domain [21], in which the modeling is done by interlacing when several transitions are fireable simultaneously.

ta tb

tb ta

(A0, B0)

(A1, B0) (A0, B1) (A1, B1)

Automaton A

B1

B0 tb

Automaton B

B1

B0 tb

Figure 3: concurrent automata and interlacing of their state space

The semantics of interlacing in our context can be il- lustrated by a simple example in Figure 3: let be a system (left) compound of two concurrents automata A and B.

Both transitions ta and tb are concurrent: they can both be taken from the initial state of the system. The state graph of the system, given to the right of Figure 3, in- cludes therefore both sequences of transitions ta, tb and tb, ta then lead to the same final state (A1, B1), transitions ta and tb being independent from each other. Two transi- tions are independent [17] if their execution order does not affect the system behavior. This situation is typical of interlacing, and can be very heavy in the context of pro- cess validation: n! execution paths are generated when n transitions are concurrent, while only one path is required for the analysis of this system.

So, Reducing interlacing has proved essential in our case to the termination of the analysis process. And besides, we also propose later in this paper, another aproach to model concurrency, which is based on the idea of merging con- current automata.

4 The control program

The purpose of this study is to model and validate the interaction between the control program and the controled system. We need to model the environment (tray, filling, screwing, etc).

1

2

M0

M2 M1

DCY

‹ƒŽ̴ˆ”‘–̴‘ˆ̴–”ƒ›

‹ƒŽ̴ˆ”‘–̴‘ˆ̴•…”‡™Ǧ

‹‰̴•–ƒ–‹‘ሺ…ሻ

ܾത. ܿҧ

end M1.end M2 + end M1.ܿҧ

end M1.end M2 + end M2.ܾത S

S Rotation_accumulation_table motor_conveyor

‹ƒŽ̴ˆ”‘–̴‘ˆ̴ˆ‹ŽŽǦ

‹‰̴•–ƒ–‹‘ሺ„ሻ 0

motor_conveyor Rotation_accumulation_table R

R

Figure 4: Grafcet program for Solujet conditioning module The models we design are abstractions of the real be- havior of the platform and environment.This step is neces- sary to reduce the size of the model and obtain an accept- able performance in terms of memory consumption and execution time. We will explain in detail the abstractions of each component when describing the model chosen to represent. The complete model is obtained by composi- tion of models of different components (environment and control program).

The control program was specified in Grafcet program (Figure 4) from the specifications, which the macro-steps M0, M1, M2 respectively represent the process of the tray rotation , the filling post and the screwing post. It also includes a timer (TON type), which allows to control the screwing post. The cyclical behavior of the program is modeled by a loop structure.

4.1 An overview of the model

Our model is built in a compositional way from a col- lection of non deterministic processes with finite control structure and real-valued clocks, communicating through

(6)

channels or shared variables. The two main parts are the environment and the control program, which communi- cate through shared variables and synchronization mes- sages. The modeling of the operative part (environment) is necessary for the verification of the safety and perfor- mance properties stated previously. The details are ex- plained in Section 5.

4.2 Modeling timers

The program control of the Solujet platform includes a timer as TON blocks. This TON block is modeled by a timed automaton (figure 5) with two discrete variables ine (input) and Qe (output), a clock to measure the time elapsed since the onset of the timer, and three states: idle, running and timeout. The variables Ine and Qe are shared with the model of the triggering task. The variable pte associated with timer is defined in the declaration part of UPPAAL. TON block communicate with the model of the master task through a binary synchronisation channel. At the beginning of each cycle, a synchronization message TON! is sent, forcing the timer model to evolve: initially the TON block is in the idle state, then it passes to the running state when it receives the message TON? and its ine variable is equal to one. When the timeout is reached the automaton goes in the Timeout state. The transition back from running to idle represents abandoning timer af- ter the receipt of the synchronization Tof! triggered by the master task.

Timeout

running x_ton<=pte idle

ine==0 Tof?

Qe:=0 x_ton==pte

Qe:=1 ine==0

ine==1 Ton?

Qe:=0, x_ton:=0

Figure 5: UPPAALmodel of a TON block

5 Modeling the environment

Interest. In order to validate not only the PLC program but also its integration in the system it has to control, we also need to model the operative part. This implies a thor- ough knowledge of the system to control, particularly the behavior of each element and its reaction time. Modeling the environment makes it possible to speed-up the veri- fication time, in particular by reducing the combinatorial aspects related to non deterministic definition of all possi- ble input values, including sometimes non relevant ones.

Indeed, when the input values of the PLC program are

emitted by a model instead of a non deterministic process, the space of reachable states is reduced. However, these parts of the model are usually limited to the representation of nominal operation modes, which is the case here.

Modeling. Each physical device is represented by a timed automaton. In such an automaton, a given location repre- sents a particular configuration of the device. In the mod- els proposed here, clocks are the only continuous compo- nents, while physical continuous moves are discretized 5.1 Distribution and conveying of vials

The accumulation table is manually loaded by vials.

During its rotation, the vials are guided to the input con- veyor of the conditioning module. This leads the vials to the indexer tray. The tray rotates 1/6 turn and the vial is positioned below the filling post, a pump doses the quan- tity to injected into the vial, then a second rotation of the indexer tray led the filled vial to the screwing post. A cap is taken at the end of the ramp accumulator, which is man- ually loaded during passage of the vial between filling and screwing post. At screwing post, the vial is clamped with a jack, the screwing of the cap is performed by means of a screwdriver. Finally the vials evacuation is provided by an output conveyor driven by a motor. The input and output conveyor are motorized by a single asynchronous motor.

5.2 Rotation of the tray

Figure 6: Schema of the tray rotation.

The vials are presented to each processing station through an indexer tray pneumatically driven(figure 6).

This transfer operation must check the following opera- tion: When the order of rotation is given four actions will be implemented sequentially: return index, return transfer with keeping the first task, transfer out, return finger must be active during the last action. These tasks are performed by three jacks two simple-acting jacks (index and finger) and the third (transfer) is a double-acting jack. The model of this process is depicted in figure 7.

5.3 The filling post

The filling post comprises a pump which doses the quantity to be injected into the vial (the retraction and ex- tension of the pump is provided by a double-acting jack),

(7)

jack_finger_in := 0, end_rotation:=1

jack_transfert_in := 0 jack_finger_in := 1, jack_indexing_in := 0

jack_transfert_in := 1 jack_indexing_in := 1

rotation_order?

end_rotation:=0

Figure 7: Timed automaton for tray rotation.

Two electrovalves allowing entry and exit of liquid, and a sensor which detects the presence of the vial below fill- ing station. The extension and retraction of the pump are detected by the jack sensors.

This filling operation will check the following opera- tion (figure 8) : When a vial is below the filling station, is asked to open the electrovalve of liquid arrival which is located at the top level of the machine. After a delay of 500ms, the pump is retracted while maintaining the ”liq- uid arrival” task. Then another order will be issued to open the low level electrovalve which allowing the outlet of the liquid. After a delay of 500ms, the pump is output while keeping the action ”liquid out” active. A new cycle will begin after receiving the information ”pump out”.

x_fil<=5

get_out_pomp x_fil<=5 x_fil<=5

get_in_Pomp x_fil<=5

end_filling:=1

x_fil==5 pomp_in:=0, exit_liquid:=0

exit_liquid:=1, entry_liquid:=0, x_fil:=0

x_fil==5 pomp_in := 1 entry_liquid:=1,

x_fil:=0 filling_order?

end_filling:=0

Figure 8: Timed automaton for the filling post.

5.4 The screwing post

Upon arrival to the position of screwing, and just prior to clamping the vial by a simple-acting jack, the motor for the rotation of the screwdriver is operated. This ac- tion must remain active throughout the screwing opera- tion. Clamping the vial remains active after the descent of the screwdriver, which shall remain in that position 2s (controlled by the TON timer), it will be disabled after its rise. Finally the vials evacuation is provided by a conveyor driven by a motor is output. The corresponding automaton is represented in figure 9.

6 Modeling concurrency

In this section, we will proceed to modeling the even- tual concurrency of the two processes of filling and screw- ing. In fact, the concurrency will be held once two vials are detected simultaneously in both positions filling and screwing, so we are faced with this concurrency model- ing, for which we propose two abstractions adapted to the

Screwing

Tof!

end_screwing:=1

Q_screwing==1 down_pos_screwdriver:=0, screwdriver_motor:=0, vial_bloqued:=0, in_screwing:=0 Ton!

vial_bloqued:=1, down_pos_screwdriver:=1, screwdriver_motor:=1 screwing_order?

end_screwing:=0, in_screwing:=1

Figure 9: Timed automaton for screwing post.

UPPAALtool, in the objective of completing the process of model validation and verification and therefore around the problem of combinatorial explosion encountered when in- terleaving transitions in the context of concurrent systems.

6.1 Merging concurrent automata

For this abstraction we propose to merge automata of filling and screwing, in order to model the system behav- ior when this two tasks are performed at the same time.

Proposed model for this automaton and the main program in this case is shown in figures 10, 11.

get_out_pomp x_fil<=5

x_fil<=5 x_fil<=5

Tof!

end_filling_screwing:=1

Q_screwing==1

down_pos_screwdriver:=0, screwdriver_motor:=0, vial_bloqued:=0, in_screwing:=0

x_fil==5

pomp_in:=0, exit_liquid:=0

exit_liquid:=1, entry_liquid:=0, x_fil:=0 x_fil==5 pomp_in := 1 Ton!

entry_liquid:=1, x_fil:=0, vial_bloqued:=1, down_pos_screwdriver:=1, screwdriver_motor:=1 filling_screwing_order?

end_filling_screwing:=0, in_screwing:=1

Figure 10: Timed automaton for filling-screwing.

6.2 Reducing interlaces

The second abstraction consists of reducing interlaces.

In fact, if we proceeds by interlacing approach to mod- eling the concurrency, reducing interlaces proves very essential for terminison of the analysis process, given the huge number of states generated in following of this aproach. In this regard, we propose new models for filling and screwing post, by introducing the concept of commit- ted and urgent states of UPPAAL, and based on the fact that an outgoing transition from a committed state will be executed in priority, while that issues from an urgent state has no priority over other executable transitions at the same time, even if in terms of time both transitions are fireable simultaneously, ie the time will not elapse in

(8)

Filling_and_screwing Screwing Filling

Rotation

end_filling_screwing==1 filling_screwing_order!

vial_below_screwingP==1 &&

vial_below_fillingP==1

end_screwing==1

screwing_order!

end_filling==1

filling_order!

vial_below_screwingP==1 &&

vial_below_fillingP==0 vial_below_fillingP==1 &&

vial_below_screwingP==0 vial_below_fillingP==0 &&

vial_below_screwingP==0

end_rotation==1

vial_below_screwingP:=vial_below_fillingP, vial_below_fillingP:=vial_front_tray_bfr_rot rotation_order!

vial_front_tray_bfr_rot :=

vial_front_tray vial_front_tray == 1

motor_conveyor:=1, Rotation_accumulation_table:=1

Figure 11: Timed automaton for main program in case of merging concurrent automata.

the states marked as such. We also use in this abstraction the concept of broadcast channels, which allows us to syn- chronize the triggering of the two processes of filling and screwing by one message (ordre generique!), and there- fore ensure simultaneity of the exceution for the two tasks.

The modeling of this abstraction is given in Figures 12, 13 and 14.

x_fil<=5

get_out_pomp x_fil<=5

x_fil<=5

get_in_pomp x_fil<=5

end_filling:=1

x_fil==5 pomp_in:=0, exit_liquid:=0

exit_liquid:=1, entry_liquid:=0, x_fil:=0 x_fil==5 pomp_in := 1 entry_liquid:=1,

x_fil:=0 vial_below_fillingP == 1 generic_order?

end_filling:=0

Figure 12: Timed automaton for filling post with urgent state.

Screwing

Tof!

end_screwing:=1 Q_screwing==1

down_pos_screwdriver:=0, screwdriver_motor:=0, vial_bloqued:=0, in_screwing:=0 Ton!

vial_bloqued:=1, down_pos_screwdriver:=1, screwdriver_motor:=1 vial_below_screwingP == 1

generic_order?

end_screwing:=0, in_screwing:=1

Figure 13: Timed automaton for screwing post with commit- ted state.

Filling_and_or_screwing Rotation

(end_filling && end_screwing) ||

(end_filling && !vial_below_screwingP)||

(end_screwing && !vial_below_fillingP) generic_order!

vial_below_fillingP==0 &&

vial_below_screwingP==0

end_rotation==1

vial_below_screwingP:=vial_below_fillingP, vial_below_fillingP:=vial_front_tray_bfr_rot rotation_order!

vial_front_tray_bfr_rot :=

vial_front_tray vial_front_tray == 1 motor_conveyor:=1,

Rotation_accumulation_table:=1

Figure 14: Timed automaton for main program in case of reducing interlaces.

6.3 Comparison of abstractions and Verification with UPPAAL

In order to validate the model of the system on the one hand and to compare the two abstractions implemented on the other hand we propose to verify the following prop- erty: ”filling the liquid cannot absolutely take place with- out the presence of a vial below of the filling station”.

Experiments. The table below (Table 1) gives the time and memory used for verification (on a windows machine with an i7 at 2.4 GHz with 8 Go RAM). The results pro- vide a comparison of the reaction times between the two proposed abstractions.

Indeed, on one hand, properties C1, C2 show that the two proposed models validate this system property, which is considered very essential, especially with the use of criti- cal solutions. On the other hand, property C2 shows that abstraction of reducing interlaces is much more efficient in terms of response time and memory used for verification, and that given the reduced number of states and automata proposed by this abstraction. However, a very important step in the interlaces optimization is to detect the concur- rent states. These states are difficult to detect by a static analysis of models, and appears very specific to the stud-

(9)

ied system.

Property Result Time Memory

- With Merging concurrent automata abstraction C1: E<>((filling post.

get out pomp or filling screwing.

get out pomp)

and vial below fillingP==0) non 0,71 s 27Mo

- With Reducing interlaces abstraction C2: E<>(filling post.

get out pomp and

vial below fillingP==0) non 0,64 s 19Mo

Table 1: Comparison of proposed abstractions used to model concurrency.

7 Conclusion

In this work, we model timed and the concurrency as- pect in programmable logic controller. The use of model checking technique for complete analysis of systems can lead to a problem of combinatorial explosion. Our scien- tific contribution aims to abstract the model of our sys- tem before analysis phase in order to reduce complexity.

Therefore, we propose and compare two different abstrac- tions. Experiment results have shown that these abstrac- tions were effective, with gains in execution time and used memory space. These techniques of abstractions defined here were adapted to the considered system. However, the generalization of these abstractions to validate other systems is considered interesting, and could provide an effective aid to model concurrency aspect using UPPAAL.

References

[1] H.Mokadem, B.Berard, V.Gourcuff, J.Roussel and O.De Smet. Verification of a timed multitask system with UP-

PAAL, 2005.

[2] K.Godary, I.Aug´e -Blum. Abstractions of timed automata models for temporal validation of embedded architectures, 2005

[3] I. Moon. Modeling Programmable Logic Controllers for Logic Verification. IEEE Control Systems Magazine, 1994.

[4] R. Alur and D. L. Dill. Automata for modeling real-time systems. In Proc. 17th Int. Coll. Automata, Languages, and Programming (ICALP’90), Warwick University, Eng- land, July 1990, volume 443 of Lecture Notes in Computer Science, pages 322–335. Springer, 1990.

[5] R. Alur and D. L. Dill. A Theory of Timed Automata. The- oretical Computer Science (TCS), 126(2):183–235, 1994.

[6] G. Canet, S. Couffin, J.-J. Lesage, A. Petit, and Ph. Sch- noebelen. Towards the automatic verification of PLC pro- grams written in Instruction List. In Proc. IEEE Int. Conf.

Systems, Man and Cybernetics (SMC’2000), Nashville, TN, USA, Oct. 2000, pages 2449–2454, 2000.

[7] C. Daws, A. Olivero, S. Tripakis, and S. Yovine. The tool

KRONOS. In Proc. Workshop Hybrid Systems III: Verifi- cation and Control, New Brunswick, NJ, USA, Oct. 1995, volume 1066 of Lecture Notes in Computer Science, pages 208–219. Springer, 1996.

[8] T. A. Henzinger, P.-H. Ho, and H. Wong-Toi. A user guide to HyTech. In Proc. 1st Int. Workshop Tools and Algorithms for the Construction and Analysis of Systems (TACAS’95), Aarhus, DK, May 1995, volume 1019 of Lecture Notes in Computer Science, pages 41–71. Springer, 1995.

[9] K. G. Larsen, P. Pettersson, and W. Yi. UPPAALin a nut- shell. Journal of Software Tools for Technology Transfer, 1(1–2):134–152, 1997.

[10] G. Frey and L. Litz. Formal methods in PLC- programming. In Proc. IEEE Int. Conf. Systems, Man and Cybernetics (SMC’2000), Nashville, TN, USA, Oct. 2000, pages 2431–2436, 2000.

[11] O. Rossi, O. de Smet, S. Lamprire-Couffin, J.-J. Lesage, H. Papini, and H. Guennec. Formal verification: a tool to improve the safety of control systems. In 4th Symposium on Fault Detection, Supervision and Safety for Technical Pro- cesses (IFAC Safeprocess 2000), Budapest, Hungary, pages 885–890, 2000.

[12] A. David, G. Behrmann, K. G. Larsen, and W. Yi. A Tool Architecture for the Next Generation ofUPPAAL. Technical Report 2003-011, Department of Information Technology, Uppsala University, Feb. 2003. 20 pages.

[13] Mller O., Structure and Hierarchy in Real-Time Systems, Phd thesis, BRICS PhD school, University of Aarhus, February, 2002.

[14] Larsen K. G., Larsson F., Pettersson P., Yi W., Com- pact Data Structures and State-Space Reduction for Model- Checking Real-Time Systems , Real-Time Syst., vol. 25, N 2-3, p. 255-275, 2003.

[15] Behrmann G., Bengtsson J., David A., Larsen K. G., Pet- tersson P., Yi W., UPPAALImplementation Secrets , 2002.

[16] Bengtsson J., Reducing Memory Usage in Symbolic State- Space Exploration for Timed Systems, Technical Report N 2001-009, Uppsala universitet, Institutionen fr information- steknologi, May, 2001.

[17] Wolper P., Godefroid P., Partial-Order Methods for Tem- poral Verification , CONCUR 93 : Proceedings of the 4th International Conference on Concurrency Theory, Springer- Verlag, London, UK, p. 233-246, 1993.

[18] Franois V., Pierre A., Franois M., Covering Step Graph , Proc. 17th International Conference in Application and The- ory of Petri Nets (ICATPN96), vol. 1091, Springer-Verlag, Osaka, Japan, p. 516-535, June, 1996.

[19] Bengtsson J., Jonsson B., Lilius J., Yi W., Partial Order Reductions for Timed Systems , ”Proceedings, Ninth Inter- national Conference on Concurrency Theory”, vol. 1466 of

”Lecture Notes in Computer Science”, ”Springer-Verlag”, p.

485-500, 1998.

[20] Minea M., Partial Order Reduction for Verification of Timed Systems, PhD thesis, Carnegie Mellon University, Pittsburg, PA 15213, December, 1999.

[21] Mateescu R., Verification des proprits temporelles des pro- grammes parallles, PhD thesis, Institut National Plytech- nique de Grenoble, 1998.

[22] Ravoux automatismes. Production Line Solujet.

http://www.ravoux-automatismes.info/

pdf/solujet\%2020120529-b420000.pdf.

Références

Documents relatifs

This article is inspired from the YouTube video “Ogni numero `e l’inizio di una potenza di 2” by MATH-segnale (www.youtube.com/mathsegnale) and from the article “Elk natuurlijk

On this network of timed au- tomata represented in U PPAAL syntax, we formally prove by model-checking that multitask programming reduces the reaction time of the conveyor,

The driver component of the split model serves as a specification in §5, where an assembly language driver is modeled and validated against the specification via timed trace

It turns out that, when considering the expressiveness as the untimed language, most subclasses of PTAs with integer parameters (including PTAs with bounded parameters, and

Assuming the correctness of QED calculations in electronic hydrogen atom, the problem can be solved by shifting by 5 standard deviations the value of the Ryd- berg constant, known

We give a condition for determinizability of automata over a timed domain without changing the timed domain, which allows us to recover several known determinizable classes of

We use the finite Markov chain embedding technique to obtain the distribution of the number of cycles in the breakpoint graph of a random uniform signed permutation.. This further

Throughout this paper, we shall use the following notations: N denotes the set of the positive integers, π( x ) denotes the number of the prime numbers not exceeding x, and p i