Outline F eria AADL behavior 1/ 78

Outline AADL behavior Annex Jean-Paul Bodeveix 2 Pierre Dissaux 3 Mamoun Filali 2 Pierre Gaufillet 1 François Vernadat 2 1 AIRBUS-FRANCE 2 FéRIA 3 ELLIDIS SAE AS2C Detroit Michigan April 2006 FéRIA AADL behavior 1/ 78

Outline Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 2/ 78

Outline Subprogram behavior Message exchanges Thread behavior 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 3/ 78

Subprograms Subprogram behavior Message exchanges Thread behavior Behavior attached to subprogram implementations Access to subprogram parameters Access to visible data declared in AADL FéRIA AADL behavior 4/ 78

Annex for subprogram behavior Subprogram behavior Message exchanges Thread behavior Specified by an automaton Reuse of mode automata syntax Action part associated to a transition Guard added to event return state declaration: when reached: output parameters are transmitted to the caller, control returns to the caller. FéRIA AADL behavior 5/ 78

Example (specification) Subprogram behavior Message exchanges Thread behavior subprogram addition features x: in parameter Behavior::integer; y: in parameter Behavior::integer; r: out parameter Behavior::integer; ovf: out parameter Behavior::boolean; end addition; FéRIA AADL behavior 7/ 78

Example (implementation) Subprogram behavior Message exchanges Thread behavior subprogram implementation a d d i t i o n. d e f a u l t annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l s t a t e ; s1 : return s t a t e ; transitions normal : s0 [ ] s1 { r := x + y ; ovf := false ; } ; overflow : s0 [ ] s1 { r := 0; ovf := true ; } ; }; end a d d i t i o n. d e f a u l t ; FéRIA AADL behavior 9/ 78

Subprogram call Subprogram behavior Message exchanges Thread behavior AADL control flow: specification of unconditional call sequences proposed annex: data dependent control flows subprogram calls send of events FéRIA AADL behavior 10/ 78

Example (2): AADL specification Subprogram behavior Message exchanges Thread behavior subprogram s t a r t r e a d features debug : i n parameter Behavior : : boolean ; end s t a r t r e a d ; subprogram implementation s t a r t r e a d. i c a l l s { p1 : subprogram std : : p r i n t ; } ; FéRIA AADL behavior 12/ 78

Subprogram behavior Message exchanges Thread behavior Example (3): behavior specification subprogram implementation s t a r t r e a d. i c a l l s { p1 : subprogram std : : p r i n t ; } ; annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l s t a t e ; s1 : return s t a t e ; transitions s0 [ on debug ] s1 { std : : p r i n t! } ; s0 [ on not debug ] s1 { } ; }; end s t a r t r e a d ; FéRIA AADL behavior 14/ 78

Sending an event Subprogram behavior Message exchanges Thread behavior subprogram addition features x: in parameter Behavior::integer; y: in parameter Behavior::integer; r: out parameter Behavior::integer; ovf: out parameter Behavior::boolean; end addition; FéRIA AADL behavior 15/ 78

Subprogram behavior Message exchanges Thread behavior subprogram implementation a d d i t i o n. d e f a u l t annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l s t a t e ; s1 : return s t a t e ; transitions s0 [ ] s1 { r := x + y ; } s0 [ ] s1 { ovf! } }; end a d d i t i o n. d e f a u l t ; FéRIA AADL behavior 16/ 78

Subprogram behavior Message exchanges Thread behavior The action part can contain subprogram parameterized calls annex b e h a v i o r s p e c i f i c a t i o n { s t a t e v a r i a b l e s r e s u l t : Behavior : : i n t e g e r ; states s0 : i n i t i a l s t a t e ; s1 : return s t a t e ; transitions s0 [ ] s1 { a d d i t i o n!(1 >x,2 >y, r >r e s u l t ) ; } ; }; FéRIA AADL behavior 17/ 78

Reception Subprogram behavior Message exchanges Thread behavior Messages are received through event, data or event data ports. Event and event data ports have associated queues. On dispatch, delivery depends on the Dequeue Protocol. p can be used as a data value and: contains the data stored in the port variable if p is a data port, contains the delivered data if p is an event data port with the OneItem Dequeue Protocol, contains the first item of the queue associated to the event data port if p is an event data port with the AllItems Dequeue Protocol. FéRIA AADL behavior 18/ 78

Reception (2) Subprogram behavior Message exchanges Thread behavior p.count returns the number of internally queued messages p.fresh return true if the port variable has been refreshed at the previous dispatch. p? dequeues an event on an event port. p.count must be non zero and is decremented. p? (x) dequeues in the variable x a data on an event data port with the AllItems protocol. p.count must be non zero and is decremented. FéRIA AADL behavior 19/ 78

Emission Subprogram behavior Message exchanges Thread behavior p!d writes data d to the event data port p and calls Raise Event. The data is immediately sent to the destination. p! calls Raise Event on an event or event data port. The event is immediately sent to the destination with the stored data if any. p := d writes data d on a data or event data port. Data is transferred to the destination port at the next p! call or after completion. FéRIA AADL behavior 20/ 78

Example of thread specification Subprogram behavior Message exchanges Thread behavior thread t e s t features p i n : i n event data port Behavior : : i n t e g e r ; p out : out event data port Behavior : : i n t e g e r ; end t e s t ; FéRIA AADL behavior 21/ 78

Example of thread specification Subprogram behavior Message exchanges Thread behavior thread implementation t e s t. d e f a u l t subcomponents x : data Behavior : : i n t e g e r ; annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l f i n a l s t a t e ; transitions s0 [p i n? ( x ) ] s0 { p out! ( x + 1 ) ; } ; }; end t e s t. d e f a u l t ; FéRIA AADL behavior 22/ 78

Subprogram behavior Message exchanges Thread behavior (56) The subset of enabled event or event data ports that are concerned by data transfer and that can trigger a dispatch (if the Dispatch port is not connected) is specified as follows: a port is in the enabled subset if a transition starting from the current state and the guard of which evaluates to true contains a reception from that port. (57) At initialization, the current state is an initial state. When, reaching a final state, the thread is completed. The next dispatch starts from this completion state, which is used to determine the enabled ports. The thread is supposed to retain its data between a completion and the following dispatch. Reaching a final state can be interpreted as calling the Await Dispatch service. FéRIA AADL behavior 23/ 78

thread behavior Subprogram behavior Message exchanges Thread behavior thread merger features p1 : i n event data port Behavior : : i n t e g e r ; p2 : i n event data port Behavior : : i n t e g e r ; m : out event data port Behavior : : i n t e g e r ; end merger ; FéRIA AADL behavior 24/ 78

Remark Subprogram behavior Message exchanges Thread behavior A reception p? can appear either in the transition : between [ ] or in the action associated to the transition: between {}. Then: in the transition, it is a concurrent offer with other transitions starting at the same state. in the action associated to the transition, execution must perform (wait for) the transmission FéRIA AADL behavior 25/ 78

Subprogram behavior Message exchanges Thread behavior thread implementation merger. i annex b e h a v i o r s p e c i f i c a t i o n { s t a t e v a r i a b l e s x1, x2 : Behavior : : i n t e g e r ; states s0 : i n i t i a l s t a t e ; comp : s t a t e ; next1, next2 : f i n a l s t a t e ; transitions s0 [ p1?( x1 ) ] next2 { } ; s0 [ p2?( x2 ) ] next1 { } ; next1 [ p1?( x1 ) ] comp { } ; only one enabled p o r next2 [ p2?( x2 ) ] comp { } ; only one enabled p o r comp [ on x1 < x2 ] next1 { m! ( x1 ) ; } ; comp [ on x2 <= x1 ] next2 { m! ( x2 ) ; } ; }; end merger. i ; FéRIA AADL behavior 26/ 78

Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 27/ 78

Direct translation to AADL data declarations package stack public subprogram push features v : i n parameter Behavior : : i n t e g e r ; t h i s : requires data access stack { Required Access => access Read Write ; } ; overflow : out event port ; end push ; subprogram pop... end pop ; subprogram c l e a r... end c l e a r ; subprogram is empty... end is empty ;... FéRIA AADL behavior 28/ 78

data specification package stack public... data stack features put : subprogram push ; get : subprogram pop ; c l e a r : subprogram c l e a r ; is empty : subprogram is empty ; end stack ; end stack ; FéRIA AADL behavior 29/ 78

(45) The internal state of a data component is specified by the subcomponents of the data implementation. It is accessed through the this data reference by the behavioral annex associated to the implementation of each subprogram. Dereferencing this is implicit. FéRIA AADL behavior 30/ 78

supported by AADL data with property Concurrency Control Protocol Access control left unspecified by AADL property Supported Concurrency Control Protocols to be defined FéRIA AADL behavior 31/ 78

Protected object example data stack features put: subprogram put; get: subprogram get; empty: subprogram empty; full: subprogram full; properties Concurrency_Control_Protocol => protected end stack; FéRIA AADL behavior 32/ 78

(I) are accessed through protocols. Three protocols are considered (HRT-HOOD): asynchronous (ASER), synchronous (HSER) and semi-synchronous (LSER). Server Call Protocol: type enumeration (ASER,HSER,LSER) => HSER applies to (server subprogram); ASER, there is no synchronization LSER, the caller waits for the acceptation of the request. HSER, the caller waits for the completion of the request and gets results if any. FéRIA AADL behavior 34/ 78

(II) Entry points are AADL ports Asynchronous message sending Thread associated to the server Bounded message queue (AADL attribute Queue Size) Acceptance conditions specified by the server thread FéRIA AADL behavior 35/ 78

(54) an active object exports a set of so called entry points. These can be seen as an extension of AADL server subprograms. In fact, a protocol is associated to an entry through a property. The parameters and the results of subprograms are handled automatically: the actual call to the subprogram is implicit. (55) The transitions of the server thread specify when requests are accepted and when the client is resumed. FéRIA AADL behavior 36/ 78

(59 ) Server subprograms can be guarded. The guard should only depend on the internal state of the thread. It cannot depend on the parameters of the subprogram. (60) Subprograms can be attached to event or event data input ports of non periodic threads. AADL defines the property Compute Entrypoint to associate source text specified by a string to a port. We introduce a new property which specifies the subprogram to be called: property set Behavior is Entrypoint: classifier (subprogram) applies to (event data port,event port) end Behavior; FéRIA AADL behavior 37/ 78

(61) The subprogram attached to a port is automatically executed by the thread if an event is received on that port. (62) We use AADL call sequences and associated connections to link the port with its corresponding subprogram. The subprogram associated to an event data port takes one input parameter of the same type as the port. The subprogram associated to an event port takes no parameters. Output ports of the thread must be declared within the subprogram. They are linked together by the connection clause. FéRIA AADL behavior 38/ 78

thread t e s t features p i n : i n event data port Behavior : : i n t e g e r { Behavior : : E n t r y p o i n t => subprogram get ; } ; p out : out event data port Behavior : : i n t e g e r ; end t e s t ; subprogram get features v : i n parameter Behavior : : i n t e g e r ; p out : out event data port Behavior : : i n t e g e r ; end get ; FéRIA AADL behavior 39/ 78

thread implementation t e s t. d e f a u l t c a l l s { g : subprogram get ; } ; connections parameter p i n > g. v ; event data port g. p out > p out ; end t e s t. d e f a u l t ; FéRIA AADL behavior 40/ 78

Asynchronous protocol (59) In the asynchronous protocol several clients can invoke the services of a server object. The invocation is non-blocking. The processing of an accepted request is carried out in parallel with the client. The entry points are represented by event ports which may support data. These events are stored in queues that can be bound via the Queue Size attribute. FéRIA AADL behavior 41/ 78

Asynchronous communication example (1) thread RW monitor features s t a r t r e a d : server subprogram s t a r t r e a d { Behavior : : S e r v e r C a l l P r o t o c o l => ASER; end read : server subprogram end read { Behavior : : S e r v e r C a l l P r o t o c o l => ASER; s t a r t w r i t e : server subprogram s t a r t w r i t e { Behavior : : S e r v e r C a l l P r o t o c o l => ASER; e n d w r i t e : server subprogram e n d w r i t e { Behavior : : S e r v e r C a l l P r o t o c o l => ASER; access error : out event port ; end RW monitor ; FéRIA AADL behavior 42/ 78

Asynchronous communication example (2) thread implementation RW monitor. i subcomponents r e a d i n g c p t : data Behavior : : i n t e g e r ; w r i t i n g f l g : data Behavior : : boolean ; c a l l s { sr : subprogram s t a r t r e a d ; } ; c a l l i f thread dispatched on s t a r t r e a d { er : subprogram end read ; } ; c a l l i f thread dispatched on end read connections data access r e a d i n g c p t > sr. rd ; data access w r i t i n g f l g > sr. wr ; event data port sr. e r r > access error ;... FéRIA AADL behavior 43/ 78

Highly synchronous mode The called service can return a result to the client. Already implemented by AADL client/server subprogram. New: specification of activation conditions. FéRIA AADL behavior 44/ 78

Proposed solution Use of the server thread to express conditions The server thread waits for allowed input events. and implicitly calls the corresponding subprogram. The client waits for the return of the called subprogram. FéRIA AADL behavior 45/ 78

Highly synchronous communication example (buffer) put is allowed if buffer is not full get is allowed if buffer is not empty subprogram put f e a t u r e s v : i n data Behavior : : i n t e g e r ; t h i s : r e q u i r e s data access b u f f e r ; end put ;... data b u f f e r f e a t u r e s put : subprogram put ; get : subprogram get ; end b u f f e r ; FéRIA AADL behavior 47/ 78

Buffer behavior (I) thread BufferServer f e a t u r e s put : server subprogram b u f f e r. put ; get : server subprogram b u f f e r. get ; end BufferServer ; FéRIA AADL behavior 48/ 78

Buffer behavior (II) thread implementation BufferServer. d e f a u l t subcomponents buf : data b u f f e r ; annex b e h a v i o r s p e c i f i c a t i o n { s t a t e s empty : i n i t i a l r e t u r n s t a t e ; f u l l : s t a t e ; t r a n s i t i o n s empty [ put? ] > f u l l { } ; f u l l [ get? ] > empty { } ; }; end BufferServer. d e f a u l t ; FéRIA AADL behavior 49/ 78

Semi-synchronous protocol (75) In the semi-synchronous protocol, the client is unblocked when the message is accepted. In this mode, only the input parameters are transmitted. The thread is dispatched when it receives a call on an enabled entry. At that moment, the client is resumed and the server thread implicitly calls the entry point. (76) The semi-synchronous and synchronous protocols are distinguished by the client wake-up time (which occurs when the request is accepted for the semi-synchronous mode and at the end of processing for the synchronous mode). This protocol is specified by attaching the LSER property to the subprogram declaration. FéRIA AADL behavior 50/ 78

thread BufferServer features put : server subprogram b u f f e r. put { Behavior : : S e r v e r C a l l P r o t o c o l => LSER ; } ; end BufferServer ; thread implementation BufferServer. d e f a u l t annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l s t a t e ; transitions s0 [ put? ] s0 { } ; } end BufferServer. d e f a u l t ; FéRIA AADL behavior 51/ 78

Elapse of time defined as new actions Computation(min,max): non deterministic CPU usage Delay(min,max): non deterministic wait FéRIA AADL behavior 52/ 78

Periodic threads Reuse of AADL properties attached to threads: Dispatch Protocol=>Periodic Period=>... The behavior defined by the behavioral annex starts from an initial state and must reach all final states before the Compute Deadline. FéRIA AADL behavior 53/ 78

Example of periodic thread thread T r a n s m i t t e r features l p u t : subprogram put ; end T r a n s m i t t e r ; thread implementation T r a n s m i t t e r. d e f a u l t properties D i s p a t c h P r o t o c o l => p e r i o d i c ; Period => 10 ms; annex b e h a v i o r s p e c i f i c a t i o n { states s0 : i n i t i a l s t a t e ; s1 : f i n a l s t a t e ; transitions s0 [ l p u t! ] s1 { } ; }; FéRIA AADL behavior 54/ 78

Interaction in bounded time (93) The solution we have chosen to express bounded wait involves adding a timeout T predicate which becomes true when the system has been waiting for T units of time since the last transition has been completed. Using such a guard on an alternative transition limits the time the response of a server subprogram can be called. FéRIA AADL behavior 55/ 78

Interaction in bounded time: example s0 [ on g > p! ] s1 { } ; s0 [ on g and timeout T ] s2 { } ; The synchronization on p! is then expected for T units of time at the most. This declaration is meaningful if the communication is time consuming. This is the case for calls to server subprograms using the HSER or LSER protocols. FéRIA AADL behavior 56/ 78

Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 57/ 78

property set behavior i s S e r v e r C a l l P r o t o c o l : type enumeration (ASER,LSER applies to ( server subprogram ) ; M u l t i p l i c i t y : aadlinteger applies to ( data ) ; M u l t i p l i c i t i e s : l i s t of aadlinteger applies to ( Constructor : aadlboolean applies to ( subprogram ) A b stract : aadlboolean applies to ( data ) ; E n t r y p o i n t : c l a s s i f i e r ( subprogram ) applies to ( e With Dispatch : aadlboolean applies to ( thread ) ; end behavior ; FéRIA AADL behavior 58/ 78

Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 59/ 78

Thread dispatch Extension to the basic dispatch protocol (1) Definition of a new runtime service: Enable ports: subprogram; if the Dispatch port is connected and receives an event, event/data available on the subset of the ports are transferred and the entry point associated to the Dispatch port is called to process transferred data. FéRIA AADL behavior 60/ 78

Thread dispatch Extension to the basic dispatch protocol (2) If the Dispatch port is not connected and an event arrives to a port of the subset, queued event/data of that port is transferred and the corresponding entry point is called. The choice is non deterministic among the most urgent ports of the subset that have received an event. The subset of enabled ports is defined at initialization and at completion. It controls the next dispatch. The subset can be specified using the new predeclared runtime service Enable ports. FéRIA AADL behavior 61/ 78

Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 62/ 78

(21) The goal of the proposed properties is to support the specification of enumerated data types. An enumerated type is defined as a data classifier. The constants of that type are declared as subprograms having one output parameter of that type. We also consider that enumerated constants can be parameterized. FéRIA AADL behavior 63/ 78

(22) are specified by a set of injective constructors so that a default implementation can be automatically provided. They extend and generalize the notion of enumerated type by allowing parameters. To each constructor is associated an observer indicating if its parameter has been build using the constructor, and a set of accessors which return the value of the effective arguments passed to the constructor. FéRIA AADL behavior 64/ 78

22 (cont) The following conventions are used to enforce this semantics: The boolean property Behavior::Abstract is defined to be true in the data component. The boolean property Behavior::Constructor is defined to be true for each subprogram acting as a constructor. A constructor has a unique out parameter. Its type must be the data it is associated with. FéRIA AADL behavior 65/ 78

package message subprogram Success features r e s u l t : out parameter Message ; end Success ; subprogram F a i l u r e features reason : i n parameter Behavior : : i n t e g e r ; r e s u l t : out parameter Message ; end F a i l u r e ; data Message features Success : subprogram Success { Behavior : : Constructor => true ; } ; F a i l u r e : subprogram F a i l u r e { Behavior : : Constructor => true ; } ; properties Behavior : : A b s t r a c FéRIA t => true AADL behavior ; 66/ 78

package message... data Message features Success : subprogram Success { Behavior : : Constructor => true ; } ; F a i l u r e : subprogram F a i l u r e { Behavior : : Constructor => true ; } ; properties Behavior : : A b s t r a c t => true ; end Message ; end message ; FéRIA AADL behavior 67/ 78

(24)Implicitly declared observers and accessors are specified as follows. By convention, we use the identifier this to denote the reference to the data to be accessed. observers are named by adding the p r e f i x is to the c o n s t r u c t o r name subprogram issuccess features r e s u l t : out parameter Behavior : : boolean ; t h i s : requires data access Message { Required Access => read only ; } ; end issuccess ; subprogram i s F a i l u r e... end i s F a i l u r e ; FéRIA AADL behavior 68/ 78

an accessor i s defined f o r each parameter of each c o n s t r u c t o r the name of the accessed parameter i s appended to the c o n s t r u c t o r name t h i s subprogram must only be c a l l e d on a F a i l u r e subprogram FailureReason features reason : out parameter Behavior : : i n t e g e r ; t h i s : requires data access Message { Required Access => read only ; } ; e r r o r : out event port ; r a i s e d i f data i s not a end FailureReason ; FéRIA AADL behavior 69/ 78

(25) Automatically generated subprograms can be called in the behavioral annex. As abstract data instances play the role of values, a functional notation is used for subprogram calls. To each such subprograms is associated a function with the same name and input parameters. For example, the term isfailure(failure(10)) is a legal boolean expression. In the same way, a term can be assigned to a variable as in err := Failure(10), or sent to a data port of the corresponding type. FéRIA AADL behavior 70/ 78

Outline 1 Behavior basics Subprogram behavior Message exchanges Thread behavior 2 3 4 5 6 Specific properties FéRIA Basic temporal operators AADL behavior 71/ 78

Environment of a component Verification needs a closed system Compositional verification needs environment hypothesis attach an environment component to each component one to one correspondence between declared features Environment can be specified hierarchically Environment has a behavior Verification of the product (closed system) FéRIA AADL behavior 72/ 78

Specification of system properties branching time logic. state-based domain specific properties. event-based domain specific properties. FéRIA AADL behavior 74/ 78

Re-initializable resettable pot ( AG EF initial) The component may return to its initial state (from any state). resettable inev ( AG AF initial) The component must return to its initial state (from any state). FéRIA AADL behavior 75/ 78

Component liveness Let C be the subset of events of the component. is alive ( AG EF C true) Always some action of the component must be possible in the future remark: When used in the root component, this property implies absence of deadlock. no livelock ( AG AF C true) A component may not be indefinitely idle (without performing some action) FéRIA AADL behavior 76/ 78

n order to specify more specific properties, we propose also a invariant p ( AG p) Property p always holds FéRIA AADL behavior 77/ 78

Leadsto e 1 leadsto e 2 [within d] AG (e 1 AF d e 2 ) When expression e 1 holds then expression e 2 eventually holds in the future [at most in d unit time]. Reachable from reachable e 1 [from e 2 ][within d] AG(e 1 EF d e 2 ) When expression e 1 holds then expression e 2 potentially holds in the future [at most in d unit time]. After e 1 after e 2 A[ e 2 Weak Until e 1 ] When expression e 1 holds then expression e 2 has been necessarily satisfied in the past Remark: Taking benefit of presence of labels of transitions it is also possible to envisage the use of behavioral equivalences (bisimulation, testing equivalence,... ) to specify directly by means of an abstract automaton FéRIA the AADLdesired behavior behavior of the 78/ 78