Duration Calculus with Iteration and Software Graph in an Embedded Control Application

However, the design technique using DC* can be solved successfully only under some assumptions about the behavior of the environments and the relationship between continuous variables an

Duration Calculus with Iteration and Software Graph in

an Embedded Control Application

Pham Tran Nhu1, Nguyen Van Truong2

1Institute of Information Technology, P.O Box A3, 18 Hoang Quoc Viet, Hanoi, Vietnam

ptnhu@ncst.ioit.ac.vn

2Thai Nguyen University of Education, Luong Ngoc Quyen Road, Thai Nguyen, VietNam

nvtruongtn@hn.vnn.vn

Abstract We present a syntactical approach given in a formal design technique

for combining Duration Calculus with Iteration (DC*) and software graph (s-graph) The technique is used for designing real-time embedded systems Integrating these two formal methods to work together in the spirit of hardware/software co-design may allow co-operating their strengths, while alleviating some of their weaknesses

Keywords: DC*, s-graph, formal methods.

1 Introduction

Each of the software methods has typical advantages and disadvantages For example, automatic verification methods are desirable since they are exhaustive and require minimal human intervention; however, the effectiveness of such methods decreases rapidly with the size of the checked systems Integrating formal methods to work together may allow combining their strengths, while alleviating some of their weaknesses [5]

Duration Calculus (DC), a logic based on Interval Temporal Logic, is powerful enough for specifying and reasoning about the behavior of real-time systems in continuous time model It has been used successfully in many case studies as specification language Duration Calculus with Iteration (DC*) is an extension of DC with the iteration operator to play the role of interface between DC and timed automata model However, the design technique using DC* can be solved successfully only under some assumptions about the behavior of the environments and the relationship between continuous variables and discrete ones This idea leads

to the natural choice of combining DC* with other methods to evaluate and estimate exactly environment and system restrictions

In this paper, we present a syntactical approach for combining DC* and s-graph from a formal specification of the requirements of real-time systems The main idea is

to model the discretization at the state level by introducing the discrete states approximating the continuous ones, and then derive a specification of the system over discrete states Moreover, the approach provides a logical framework that can handle

effectively consumptions about the time latency in designing steps, which were not solved in many case studies using DC*, see e.g [1, 2, 13]

The remaining of the paper is organized as follows In Section 2 we give a brief summary of DC* and s-graph The combination technique is presented in Section 3 Section 4 concludes the paper

2 DC* and S - Graph

It is not the purpose of this paper to give a complete description of these formalisms but just a simple introduction to make easier the understanding of the following Readers may find more details in [1, 12] about DC* and in [7] about s-graph

2.1 DC*

A language for DC* is built starting from the following sets of symbols: a set of constant symbols {a, b, c, }, a set of individual variables {x, y, z, }, a set of state variables {P, Q, }, a set of temporal variables {u, v, }, a set of function symbols {f, g, }, a set of relation symbols {R, U, }, and a set of temporal propositional letters {A, B, }.

A DC* language definition is essentially that of the sets of state expressions S, terms t and formulaeof the language These sets can be defined by the following BNFs:

S ≙0PSS S

t ≙cxu∫Sf(t, , t)

≙AR (t, , t)()(◠)(*)x

A state variable P is interpreted as a function I(P): IR+ {0,1} (a state) I(P)(t) =

1 means that state P is present at time t, and I(P)(t) = 0 means that state P is not present at time t.

We assume that a state has finite variability in any finite time interval A state expression is interpreted as a function, which is defined by the interpretations for the state variables and boolean operators

For an arbitrary state expression S, its duration is denoted by ∫ S Given an interpretation I of the state variables and an interval, duration ∫ S is interpreted as the accumulated length of time within the interval at which S is present So for any interval [t, t’], the interpretation I(∫ S)([t, t’]) is defined as t t'I(S)(t)dt.

A formulais satisfied by an interpretation in an interval [t, t’] when it evaluates

to true for that interpretation over that time interval This is written as I,[t, t']⊨

Given an interpretation I, a formula◠’ is true for [t, t’’] if there exists a t’ such that t t’t’’ andand’ are true for [t, t’] and [t’, t’’], respectively.

We consider the following abbreviations: 1≙0, ≙∫1, S≙(∫ S =)(> 0),

◊≙(true◠◠true), □≙◊,k≙◠ ◠(k times, for k > 0).

The proof system for DC* consists of a complete Hilbert-style proof system for first order logic (cf e.g [8]), axioms and rules for interval logic, Duration Calculus axioms and rules and axioms about iteration (cf e.g [12])

The proof system of DC* is complete for sentences where iteration is allowed only for a restricted class of formulas called simple

Definition 1 Simple DC* formulas are defined inductively by the following BNF

≙= 0Sa a()()(◠)*

Definition 2 Given a simple DC* formula , we define a simple DC* formula PREF() as follows.

1 PREF (S)≙S*

2 PREF (a) ≙0

3 PREF (a) ≙a

4 PREF (’)≙PREF ()

PREF (’)

5 PREF (’)≙PREF ()PREF (’)

6 PREF(◠ ’) ≙ PREF ()  (

◠PREF(’))

7 PREF (*)≙*◠PREF ()

Intuitively, PREF() is a simple DC* formula that holds for all prefixes of an interval

that validates

A simple DC* formula denotes exactly a Timed Regular Expression and therefore

a time automaton Moreover, it has an interesting property that it is decidable [1]

2.2 S-graph

Definition 3 An s-graph G is a directed acyclic graph with one source and one sink Its vertex set V contains four types of vertices: BEGIN, END, TEST and ASSIGN.

The source has type BEGIN, the sink has type END All other vertices are of type

TEST or ASSIGN Each TEST vertex v has two children true(v) end false(v) Each BEGIN or ASSIGN vertex u has one child next(u) only Any non-source vertex can

have one or more parents An s-graph is associated with a set of m input and l out put variables z1, , z m+l , ranging over finite domains D(z1), , D(z m+l), respectively

Fig 1 A simple s-graph

The s-graph model resembles order binary decision diagrams (OBDD) [7], which based on a decomposition of Boolean function called the Shannon expansion A

function f can be decomposed in terms of a variable as follows.

f = x f x=1+x f x= 0

The manipulation of s-graph is also similar to that of OBDD It means that, one can operate logic operators on variables (AND, OR and NOT) Fig 1 illustrates a simple example of an s-graph

Each ASSIGN vertex v is labeled with an output variable z v , and a D(z v)-valued

function a v (z1, , z m+l) In the graphical representation of s-graphs, we label such a

vertex with z v := a v (z1, , z m+l) to indicate the meaning of ASSIGN.

Each TEST vertex v is labeled with a predicate p v (z1, , z m+l), whose truth value determines which child will be executed

The evaluation of the multioutput function computed by an s-graph with BEGIN

node v, m input variables and l output variables.

In an s-graph, we present the transition function as a composition of the following:

- Set T of tests on input and state variables.

- Set A of actions, which can be either output emissions or assignments to states

variables

- The reactive function mapping subsets of T to subsets of A, represented by its characteristic function F: {0, 1} |T| + |A| {0, 1}

For example, in the Figure, tests are present_c and a = ?c; actions are a’:= a, a’:=

0, a’:= a + 1 and emit_y; and the reactive function is:

present_c a=?c; a’:= a a’:= 0, a’:= a+1 emit_y

Conceptually, the transition function is executed in three phases:

- Tests are evaluated to determine the values of input variables of the reactive function

- The s-graph of the reactive function is evaluated to determine the values of its output variables

- Actions corresponding to output variables are executed

S-graph is built recursively starting from reactive function based on the Shannon decomposition ([16])

Theoretically, dynamic calculation of software performance can be done with realistic inputs Both the structure of the synthesized code and the architecture of the target system can be considered Static calculation, useful for example for worst case execution time analysis, can be done by using graph traversal algorithms Assume that

E is the number of edges in the s-graph and N the number of nodes The

minimum-cost path based on Dijkstra's shortest path algorithm from the BEGIN to END vertex

of the s-graph is O(ElogN)).

3 Combining the methods

3.1 The technique description

The combination process can be formalized by consecutive steps Firstly, a state variables model of the system should be defined The state variables model comprises continuous state variables and discrete state variables Secondly, the requirement of

the system is formalized as a DC formula Req over continuous state variables A

design decision must be established so that the requirement of the system will be met

and refined into a detailed design Des over continuous state variables such that A

⊦Des  Req, where A stands for some assumptions about the behavior of the

environment and the relationship between continuous state variables Finally, the discrete step follows We approximate continuous state variables by discrete ones and formalize the relationship between them based on the general behavior of the sensors and actuators The control requirement is derived from the detailed design and refined

into a simple DC* formula Cont over discrete state variables such that A c ⊦Cont  Des, where A cstands for some assumptions about the behavior of the environment and the relationship between continuous state variables, and relationship between discrete state variables and continuous ones The assumptions in the last two phases include ones about time latency of hardware and software, which were computed and

estimated exactly by the corresponding s-graph The discrete formula Cont is the

formal specification of the controller

3.2 A case study: designing a single lift control system

We will illustrate the technique in the remaining of this section with a simple case study The readers are referred to [2, 13] for more details on the designing steps, Discrete Interface, Refinement and Verification Rules

We now define three concepts for formalizing the relationship between continuous state variables and discrete ones

Definition 4 (Stability) Given a state variable s and a positive real number, we say

s is- stable iff the following formula is satisfied by any interval

-stable(s) ≙□( s◠ s◠ s s◠ ( s>)◠ s)

Definition 5 (Control state) Given two state variables r and s, and a non-negative

real number , we say r - controls s iff the following formula is satisfied by any interval

r⊲s≙□( r> ()◠ s)

Definition 6 (Observation state) Given two state variables r and s, and a

non-negative real number , we say r- observes s iff the following formula is satisfied by any interval

3.2.1 Problem domain description

The logical control of a lift system studied in this paper consists of a simple, single lift system It allows movement of a single lift cage between a finite numbers of floors

Components: a lift cage with send buttons, one for each floor; a motor; n + 1 floors,

each with a floor door, a call button and a close button; sensors and actuators; a controller

Attributes:

- The lift cage is either stopped at floor j for j lying between 0 and n inclusive, or is moving up (or down) between floors i and i +1 (i and i - 1), for i lying between 0 and n - 1 (n and 1).

- A floor door is either open or closed

- The motor is either running up (or down) or is stopped

- The motor, when running, runs at a constant speed - which causes the lift cage to

move between immediately neighboring floors in t mtime units

Events:

- A send button is pressed for floor k, for k = 0, , n.

- A call button on floor k is pressed, for k = 0, , n.

- A close button is pressed for the door at floor k, for k = 0, , n.

- The opening (and closing) of floor doors

- The starting and stopping of the motor - implying the same for the cage

- Servicing a floor k means that a send button is pressed for floor k, or a call button

on floor k is pressed or the lift cage is running upwardly or downwardly (towards floor k).

- There is a request on floor j, means that a call or a send button at floor j is pressed,

iff there does not exist any services of floors and the floor door is closed; or a close

button at floor j is pressed when the floor door is open This implies that the lift

system services floors successively This dogma makes our design simple

Invariants:

- There are at least two floors (a component invariant)

- The cage has exactly one send button for each floor (a component invariant)

- Pressing a call button at floor i or pressing a send button for floor i causes the lift

to service that floor within t stime units (a procedural, functional invariant)

- A floor door may only be open if the lift cage is at that floor (a component safety invariant)

- The floor door is open for at least t 0 time units and at most t maxtime units

The lift system presented in this paper shall be monitored and controlled by a controller that shall respect the components, handle the events, and satisfy the usual procedures and invariants enumerated above

3.2.2 Formalizing the requirements of the system

We introduce the following continuous state variables: variable c i holds if the call

button on floor i is pressed, variable s i holds if the send button for floor i is pressed, variable d i holds if the door at floor i is open, and variable f iholds if the lift is at floor

i, for i ranges over interval [0, , n]; variable motor holds if motor is on (and this makes the lift cage move); variable close i holds if the close button on floor i is

pressed

The requirements of the system are defined by Req ≙□(SafetyReq FunctReq)

The safety property for the lift control system is: for every floor, the door must only be opened if the lift is at that floor This is equivalent to stating that “if the lift is

not at floor i, then door i must be closed”.

SafetyReq ≙d i  f i

The function requirement is the following conjunction

FunctReq ≙F1F2F3

Pressing a send button causes the lift to service the corresponding floor within t s

time units

F1≙s i≙true  t s(t s ◠ d i◠ true)

This requirement states that for every observation interval for which s i holds

initially, i.e the send button for the i’th floor is pressed, either the interval is shorter than or equal to t sor it may be divided into three subintervals where the first lasts at

most t s , in the second the door at floor i is opened, and a final subinterval which is

unconstrained

A similar condition must hold when pressing a call button: pressing a call button

causes the lift to service the corresponding floor within t stime units

F2≙ c i◠ true  t s(t s ◠ d i◠ true)

The system must guarantee that when a floor is serviced, the door is open for at

least t0time units and at most t maxtime units

F3≙( d i◠ d i◠ d it0)( d it max)

We now present a design decision, which implements the requirements

3.2.3 Design decision

We define the design decision by the predicate Des

Des ≙□(D1D2D3D4D5D6D7)

The following formula is derived directly from the assumptions of the behavior of the system

D1≙((= a s i c i)◠(= b ( d i◠ d i))

 (= a)◠(b (s i c i s j c j))◠ true) (close i d i)

(c i d i)(ci s i)(si d i)(ci d j)(c i c j)

(c i s j)(si s j)(si d j)

If for every interval for which a send button for floor i is pressed initially, and the lift is at floor j, and j i, then the interval may be divided into three subintervals The

first lasts at most time units, in the second the motor is on, and an unconstrained

final subinterval; in the condition of i = j, then the door at floor i must be opened

within time units, where stands for a response time of the system A similar

condition must hold when pressing a call button at floor i.

D2≙(s i c i)f j◠ true  ()◠ motor◠ true

D3≙(s i c i)f i◠ true  ()◠ d i◠ true

If a send button for floor i is pressed while lift is at floor j, the lift may reach the

destination floor and then the motor is off and the door at the floor is opened within

time units A similar condition must hold when pressing a call button at floor i.

D4≙( (s i c i)f j◠ true 

()◠= |i - j|t m◠ (◠ d i ) f i◠ true)

( (s i c i)f j◠ true 

()◠= |i - j|t m◠ (◠ motor) f i◠ true)

If the close button at floor i is pressed it may make the door at the floor open

withintime units

D5 ≙close i◠ true  ()◠ d i◠ true

Two following formulas will help satisfy the requirement of the maximum and minimum time units for which a door is open

D6≙d i◠ d i◠ true  d i◠< t0◠ close i◠ true

D7≙( d i t max- 1t max)◠ true  d i◠ d i◠ true

Initially the lift is idle at the ground floor with the doors close, motor stops, and no requests for the lift

Init ≙motor f0d i s i c i close i◠ true 

The maximum time it may take to service a floor corresponds to the time it takes to

move across n + 1 floors and the response time it takes to open doors.

A1≙(t s (n +1) t m+ 2)

The following formula is derived directly from the attribute of the motor as described in Section 3.2.1

A2≙(s i c i)f j◠ true  ◠= |i - j|t m ◠ f i◠ true

We assume that the response timeis small enough in order to the lift, having reached the destination floor, can be at the floor within at leasttime units while the motor is still running

A3≙f i◠ f i motor ◠ true  f i◠f i◠ true

A4≙(t0++ 1t max)

Let A ≙Init A1A2A3A4

3.2.4 Discrete design

For any continuous state variable s, let s c be the discrete state variable used by the

controller to observe s via the sensors Then the relationships between continuous state variables and discrete state ones are formalised as following formulas: f ic f i,

c ic c i , d ic



 d i , s ic



 s i , and close ic



 close i, whereis the sampling step.

Let Dopen i , Dclose i , Mon, and Moff be discrete state variables, which hold when the controller requests the actuators to open the door at floor i, close the door at floor

i, start the motor, and stop the motor, respectively The relationship between them and the continuous state variables d i and motor are expressed by Dopen i⊲d i , Dclose i

⊲d i , Mon⊲motor, and Moff⊲motor, wherestands for the response time of the plant via the actuators Besides, we also introduce a symbolas one described above

Let 1≙( (c ic s ic)f jc Mon=)◠ (|i - j|t m+ |i - j|t m)◠ Moff

2 ≙ ( (c ic s ic)f jc Mon= )◠ (|i - j|t m+ |i - j|t m)◠

Dopen i

3≙(c ic s ic)f ic Dopen i(= )

1≙(t0-)◠ close ic Dclose i

2≙(t max-- 1t max-)◠ Dclose i

1≙( (c ic s ic)f ic◠(+ |i - j|t m)◠ c ic s ic c jc s jc)

2≙(c ic d jc)(cic c jc)(cic s jc)(sic s jc)

(s ic d jc)(closeic d ic)(cic d ic)(cic s ic)

(s ic d ic)

≙c ic s ic*◠ ((12)3◠12)*

≙c ic s ic*cicsic◠ ((12)3◠12)*

A discrete design for the controller is defined as following formula

Cont≙(*◠PREF (*)) 12

Let A c ≙A (f ic f i) (c ic



 c i) (d ic



 d i)(s ic





s i) (close ic





close i)

(Dopen i⊲d i)(Dclose i⊲d i)(Mon⊲motor) (Moff ⊲motor) 

(+)( Dopen i)( Dclose i)

The following Theorem establishes the correctness of the discrete design, under the assumption about the relationship between discrete state variables and continuous ones, and the behavior of the environment

Theorem 1 A c ⊦Cont  Des (Proof See [13]).

In the design process, we must chooseandsatisfying the hardware and software latencies, which were evaluated and estimated easily by using s-graph We have implemented s-graph in C language and tested it successfully Conceptually, the input for initial s-graph need not always be a function but could also be a relation In the paper, we consider that s-graph comes at the end of the technique design simply to fill

in the estimated values for parameters of DC* The readers are referred to [2] for details on how to write a real-time program for the controller and verify its correctness w.r.t the formula Cont using extended Hoare triples

4 Conclusion

We consider DC* as specification language to reason about the design of the system, which has been used successfully in many case studies, see e.g [1, 2, 13] However, these had not mentioned about how to choose assumptions about environment, especially about time latency We used s-graph associated with DC* to resolve the problem

Using the technique will make our system design move closer to real world compares to one given in [10], and it is useful for programmers to implement it in some programming languages Besides, it is not difficult to prove the correctness of the design of the system by using the technique In general, we just have considered the system with simple requirements and the dogmatic assumption

In the future, we will use the technique to design more complex and practical systems with optimized processes of s-graph combining with DC* Moreover, we are planning to integrate DC* formal language with Co-design Finite State Machine to build a better synthesizable and verifiable model

References