A static approach to estimation of execution time of components in AADL models

During development of modern avionics systems and other mission-critical systems modelling is vitally used. Models can be used for checking and validation of developed system, including early validation. Early validation is very important because the cost of errors is raising exponentially depending on the development stage. For modelling of such systems, Architecture Analysis and Design Language (AADL) is widely used. It allows to model both architecture of a developed system and some of behavioral characteristics of its components. In the paper, the task of automated model checking for consistency of some behavioral properties is considered. In particular, we focus on the problem of estimation of working time of model components and corresponding between this time and other properties in a model. This problem is close to the worst-case execution time problem (WCET) but it has its own specific in this application. We considered a static approach allowing to work with standard specification of components behaviour in AADL-models with specialized extended finite automata. In the paper, peculiarities of used behaviour model (specialized finite automata) were considered including work with time and external events. We considered the problem of working time estimation for such models connected with non-local characteristic of this property. We propose an algorithm for time estimation for such behaviour models. This algorithm was implemented in MASIW framework, a tool for development of AADL-models.


Introduction
Modern avionics is responsible for control of almost all aspects of aircraft operation.As a result, the complexity of such systems is really high.Thus making sure that developed system is correct is a challenging task.Nowadays problems and their solution bring additional complexity to avionics systems.To satisfy models requirements for weight and power consumption, 158 integrated modular avionics (IMA [1]) approach is used.It means that several resources (e.g.universal processor modules and network) are shared between several pieces of software.The approach leads to appearing of step of the integration of the whole system, i.e. deployment of software on different hardware, network configuration and etc.This approach solves weight and power consumption problems, but leads to potential problems of interfering of applications.It means that the whole system correctness must be checked and this problem is not solvable by checking of correctness of each part of the system.The model-driven approach of development allows to manage with the complexity of a system being developed.In particular, models are needed to perform different kinds of analysis of the modelled system though analysis of appropriate models.Such analyses are intended to be performed on different stages of development, in particular, to eliminate errors at early steps of development.One kind of checks that are needed to be performed is check of timing properties of software components.In particular, during design and deployment stages, each particular application is bound to a processor module.Appropriate timing properties are assigned to them, for example • dispatch protocol, i.e. whether an application is fired periodically, eventually (sporadically) or both; • period of execution for periodic applications; • compute deadline, i.e. time interval in which an application has to finish its work after it was given an ability to execute; • recover deadline, i.e. time interval in which an application has to recover from recoverable errors; • process time, i.e. the time between sending a processed output data after getting some input data; • output rate, i.e.rate at which an application has to produce its output, when it is periodic; • output jitter, i.e. maximum deviation of time for periodic output and etc. Being assigned to some particular application, these properties can be used in schedulability analysis, data flow timing analysis, worst case execution time (WCET) analysis and etc.Some desired or expected values can appear before implementation of particular software.During the system development, models of it are refined.In particular, for software some behaviour specifications can appear.Such behaviour specifications can be purely functional (i.e. containing only information about which outputs will be produced in particular inputs at the given state).
159 Also such specifications can contain how much time will be consumed in this or that situation.The addition of this information can lead to inconsistency in the model, because some assumptions about timing properties of software can already exist in the model and these assumptions can contradict with behavior specification.
To check the consistency of a model, it is important to estimate timing properties of particular behaviour specifications.

Compute deadline consistency example
Consider a periodic software component with some particular period set in the model.Consider also that this component has compute deadline property bounds set to a range from to ms.This property can be used in the schedule building: e.g. a time frame of ms can be reserved each period to ensure this software component has enough time to compute.This can be done on early stages of system development when no particular behavior is known yet.Consider the case when after development this software component is refined: now its behaviour is specified with automaton with transitions containing how much time is consumed by computations assigned to them.We can estimate general time consuming of an application each period as a range ℎfrom ℎ to ℎ ms.After getting estimations ℎwe can compare it with bounds from the model and there are several decisions we can take: • when ℎ = , behavior corresponds to property and the model is consistent; • when ℎ ⊄ , the model can be inconsistent because real execution time may miss the bounds; • when ℎ ⊂ , ≠ ℎ, the behaviour specification corresponds to the property; also, we can say that the property in the model can be refined to a more precise value; • when ∩ ℎ = ∅, the model is inconsistent.

Example of consistent case
Consider an example when the model has bounds for compute deadline property set to be from 3 to 10 ms.Consider also that this application has behavior specification 160 with automaton shown on the fig. 1.Each period this application begins in state and finishes in .
In this example we can estimate execution time of the application to be between 5 and 10 ms.This value is consistent with property set in the model.There is another case when such estimations are useful.Consider a situation when some software component in the model did not have any timing properties set.Consider then, that later it was refined and some behavior specification has appeared for it.The model still needs to be checked for schedulability and other timing-aware properties.So, we need to derive these timing properties for a component with some behaviour specification.Again, we run into an issue of estimation of timing properties having a particular behavior specification.So, generally we can resume that there is an important issue of estimation of timing properties in responsible systems' models with behavior specifications.

AADL and BA
We use AADL (Architecture Analysis and Design Language, [2]) as a modelling language.It allows to describe both physical and logical parts of the modelled system, connections between components and bindings between layers of the system.AADL has a mechanism of the language extending though special language annexes and it has a number of standard annexes.
One of such extensions is called Behavior Model Annex [3] (BA).It allows to specify behavior of AADL-components using extended time-aware finite-state machine.
Behaviors are set to components of a modelled system.The basic elements used in BA behavior specifications are • automaton states change; • internal computations; • accessing and assigning to internal or external variables (data components); • interaction with the outer world using input/output ports; depending of behavior, input ports can be managed both by pulling data and by waiting for data to come; • handling dispatch events, i.e. a situation when software component is allowed to perform its execution (e.g., an operating system signals a thread to start).Behavior Annex automaton must contain a single initial state.When the automaton goes out from the initial state, its internal variables are being initialized.The automaton can contain several final states, in these states automaton can stop its execution.Each state of the automaton belongs to one of the classes of complete states or execution states.

161
Transitions from execution states occur immediately after automaton comes to such state.In complete states automaton waits for external events (data for input ports or dispatch event).Transitions going out of complete states are fired as soon as corresponding event happens.In BA each state transition is assigned with a list of actions which is run when automaton performs this transition.There are actions that appear in the list of actions in BA behavior specification: • actions with ports: reading, writing, getting of messages count in ports; • actions with local and accessible external variables: reading and assignment; • locking on resources: getting and releasing; • action for modelling of time consumption ( . .); • stop action for automaton interruption; • composite actions (loops, conditionals); • computation of arithmetical expressions.

Problem
We focus on AADL models with behavior specifications set using Behavior Model Annex language.We consider a BA behavior specification of a single component in a model.Also, we consider two states and !" of the automaton are given.We want to estimate the maximum and minimum model time the BA automaton will consume to go out from state and to come to ! " .

Solution
Automaton can reach a given state starting from another given state in several ways depending on variables state, external events and nondeterminism.We will call an interleaving sequence of states and transitions as a path in automaton.
Thus we divide the original problem to considering a single path in automaton and then considering the automaton itself as a source of paths.

Estimation for a path
First, let us look at a finite path starting and ending at given states and !" , and going through states , , . . ., , which could be equal to each other and to states and !" .We would designate it as → → →. . .→ → !" .The question is how long does it take to go along this path out from to ! " .Some of states in the path may be complete.An automaton is waiting for external events in these states while going through them.It is a hard task to estimate how much 162 time would it take because it is not a local property, i.e. it depends on other components in the model.Execution states do not consume any time by definition, thus there is no such problem for them.Also, in BA actions assigned to transitions can take some time (e.g.computation action takes time, which is specified with its argument; input/output operations may take time too).Time taken by composite actions (loops and conditionals) depend on very actions inside them and external conditions (state of variables and ports).Having dependency on external conditions, estimation of time consumption by conditionals it a tricky task (undecidable in the general case).Thus, task of estimation of time, taking by execution of a finite path, can be split into two tasks: time estimation for each complete state in the path and for each list of actions assigned to a transition in the path.

Estimations for an automaton
The whole automaton containing both execution and complete states is a challenging object.Let us at first consider simpler kind of automata containing only execution states and then to consider the general case.

Automata with execution states only
In this case, automaton is not waiting for external events and goes through states right away.We can represent such automaton as a weighted graph.Vertexes of the graph are states of the automaton, and edges of the graph are transitions of the automaton.Weight of each edge is time estimation for the actions of corresponding transition.We can use all known algorithms for finding minimum and maximum times (e.g. for finding minimum time we can use Dijkstra's algorithm [4]).However, when the graph is cyclic these estimations can be inaccurate.For example, we have a loop of the automaton, which is executed exactly 50 times.If this fact is not used, estimation of the time consumption of this loop may be too imprecise, up to +∞ for the higher bound and to 0 for the lower bound.Considering information of the number of loop iterations, we can estimate the time to be 50 )*"+ where )*"+ is an estimation of the time consuming by the loop body, or even more precise if )*"+ depends on the loop iteration number in a known way.Despite inaccuracy in some cases, time estimation for this kind of automaton is a pretty studied problem.

Automata with complete states too
Approaches with simple weighted graphs with weights only on edges do not model the fact that automaton can wait some time in a complete state during its execution.But we work with automata having complete states.Thus, we need to manage with it somehow while estimating automata execution time.
It seems that this problem can be reduced to the previous one, e.g.though replacing a single complete state with two connected execution states with a transition consuming the same time as automaton waits in this complete state.But what we realized trying to implement such approach is that time of waiting in a complete state is not local and cannot be represented by some constant.This time actually depends both on the way this state was reached and on how regular external events occur.So, automata with complete states need special treatment, one variant of which will be discussed below.

Solution structure
So, to solve the original task we have divided the original problem to the following subtasks: • estimation of time consumption of paths in automaton: • estimation of execution time for transitions; • estimation of time of waiting in complete states; • estimation of time consumption by automaton itself: • in a particular case, when the automaton contains only execution states; • in the general case, when automata with both complete and execution states are considered.The rest of the paper follows this division.

Estimation of time for transitions
Let us estimate how much time can take different Behavior Annex actions.At first, look at simple actions.The action computation has a time as an argument, which is the execution time of this action.Also, the action get resource can take some time, because at the moment when this action is executed, needed resource can be used by some other component.And so it will be necessary to wait for some time until the resource can be used.We will estimate this time from 0 to +∞.If action stop occurs at some point, then the execution of automaton became interrupted and it does not go to the next state.The action does not take time.However, since we are interested in the time between the states of the automaton, it is convenient to assume that the time of this action is +∞.Indeed, if the transition from to , with action stop exists, it means that automaton will not ever be in state ,after this transition.Now let us consider composite actions.Loops which contains the actions occupying some time, we will estimate with time from 0 to +∞.Making this estimation to be 164 more accurate is possible but it is not considered in this paper.Other loops do not take any time.We will estimate conditional constructs in the following way.Time of actions in ifblock is from to , time of actions in else-block is fromto -(if there is no else-block -= -= 0).Then the estimation is the time range from min( , -) to max( , -).
In this way, estimations for transitions of the automaton can be performed.Now let us estimate time, that automaton is waiting in complete states.

Estimation of time for complete states
Behavior Annex allows to handle two types of external events: receiving a message to input port and a dispatch signal.At first, look at the first type of events.Since the expectation of the receiving message can take arbitrarily much time, we will estimate this time with 0 to +∞.So, this is the estimations of time of waiting in the complete states for the external event of the first type.Estimations of time waiting for events of the second type can be performed in same way.But the estimations can be more accurate when the component is a thread.This is due to the fact, that AADL allows to set properties for the thread, which determined how often dispatch signal arrives to the thread (such properties are Dispatch Protocol and Period).These properties determine the time between neighboring complete states in automaton.Consider any path in an automaton, which starts and ends in complete states, all other states are execution states, and the transition from the first complete state is the transition of the second type.Above AADL-properties can determine the execution time of this path from going out from the first complete state to going out from the second complete state.This time is determined by time range with possibly infinite bounds.In this way, when automaton comes to complete state, the waiting time in this state is determined by the time elapsed from going out from the previous complete state and by AADL-properties.The task is to find the maximal and minimal weight of paths from to ! " , where weight of a path is a sum of weights of path's → ⋯ → !" transitions counted with multiplicity.For example, we will consider the graph on the fig. 2 and vertices and D as and !" respectively.

Algorithm
1) We find strongly connected components (SCC) in graph 4 with Tarjan's algorithm [5].Strongly connected components of the graph 4 are highlighted by a dotted line on fig. 2. 2) We build acyclic graph 7 from strongly connected components of the graph 4 (fig.3).
3) Let vertices and !" belong to strongly connected components с and !" respectively.Then we find all paths in acyclic graph 7 (we

Fig. 3. Graph E
Troitskiy A.M., Buzdalov D.V..A static approach to estimation of execution time of components in AADL models.
Trudy ISP RAN /Proc.ISP RAS, 2016, vol. 28, no 2, pp. 157-172.166 call them SCC-paths) from с to ! " .In the example, all paths from с to с F are с → с → с F and с → с → с F .Case 2: is cyclic, then upper bound of weight of the transition ⇒ *I is positive infinity, and the lower bound is calculated using Dijkstra's algorithm [4].6) For possibly infinite set of paths between and !" we have considered finite set of W XY!" paths.We calculated weight of each W XY!" path, got a finite set of weights.Thus, we can pick maximal and minimal ones.6.2.General case, both execution and complete states

Problem
The Behavior Annex automaton and two states of the automaton are given.The problem is to find estimation of the execution time of the automaton between leaving the state and entering the state !" .We designate the set of states of the automaton as ^.The set of execution states of the automaton is 7_` ⊂ ^, the set of complete states of the automaton is a ⊂ ^.For example, let us consider the automaton on fig. 5. Complete states are marked by white color, execute states are gray.The goal is to find time between state e2 and state c2.

Solution idea
Two different states types are determined in Behavior Annex.So we consider two different graphs.We consider graph of the complete states and the graph of the execution states separately.Then if we need to find time between exit from one complete state to exit from other complete state, we use graph of complete states.In other cases we use the graph of execution states.

General scheme
We have two states , ! " ∈ ^.The aim is to find the minimum and the maximum possible time between leaving the state and entering the state !" .We will do this by estimation of time for each path → ⋯ → !" .The problem is that execution time of the path depends on complete states before state , if is execution state.We will consider two cases: when is complete state, and when is execution state.When k klmnl is complete state, each path → ⋯ → !" can be divided into smaller paths: → ⋯ → and ⇢ !" , where ∈ bc76( !" ).For each ∈ bc76( !" ) time of the path → ⋯ → ⇢ !" is j( → ) + ( ⇢ !" ), where j( → ⋯ → ) is time between leaving and leaving , and time ( ⇢ !" ) is time between leaving and entering !" .Notice that times j and can be different for the same path, when the last state of the path is complete state.The ways of estimation of time jQ ⇢ R T were described in section 5.2.When k klmnl is execution state, each path → !" is a part of path like

Calculation of j
Let us focus on the function j.Value of j is described in section 5.2 for paths ⇢ R , where , R ∈ a .To find time j for arbitrary paths ( → ⋯ → R ) we build weighted oriented graph 4 X .The vertices of the graph 4 X are complete states of the automaton.We build edge ( , R ), if a path ⇢ R exists in the automaton.Weights of edges are determined with AADL-properties of the component as described in section 5.2, i.e. weight of an edge Q , R T equals to jQ ⇢ R T. Graph 4 X for the considered example is presented on fig.6.To find time j( → … → R ) we execute the algorithm described in section 6.1 on graph 4 X .

Calculation of
To find time ( ⇢ ) we build weighted oriented graph 4 ! .The vertices of the graph 4 !are all execution states of the automaton.For each transition ` → ` of the Troitskiy A.M., Buzdalov D.V..A static approach to estimation of execution time of components in AADL models.Trudy ISP RAN /Proc.ISP RAS, 2016, vol. 28, no 2, pp. 157-172.170 automaton we build edge (` , ` ) in graph 4 ! .The weight of this edge is time estimation for transition's actions (see section 5.1).Graph 4 !can be not connected.Graph 4 ! is presented on the top of fig. 6.With graph 4 !we can estimate time ( ⇢ ).To do this we build new graph 4 !q ( , ).Vertices set of graph 4 !q ( , ) is union of states set of 4 !and { , }.It contains all edges from 4 ! .Additionally, it contains all edges, which are corresponding to outgoing transitions of automaton from state to vertices from 4 !q ( , ) and incoming transitions from vertices of 4 !q ( , ) to .To find ( ⇢ ) we execute the algorithm from section 6.1 on graph 4 !q ( , ).
On the second line of fig.7 the graph 4 !for calculating the time between exit from complete state to enter to complete state F is presented.

Calculation of the result
For each path → … → !" we calculate time estimation.The result of the algorithm is the smallest time range, that contains all these time ranges.

Related works
One close problem to the problems, considered in this paper, is WCET problem.This problem is well-known, and a lot of algorithms solving WCET exist.But these algorithms cannot be applied to our problem directly, due to considered specific object class, defined by Behavior Annex language.As Behavior Annex describes behavior based on timed automata, consider WCET algorithms working on timed automata.The WCET problem for timed automata was considered in the paper [6].This paper has a description of the algorithm using the difference-bound matrix data structure to represent zones (heuristic).This algorithm can be applied in the particular case, which was described in section 6.1.The main specific construct in Behavior Annex is complete states.In the particular case we consider automata with only execution states.These automata are very similar to timed automata from the paper [6].It means that algorithms from the paper can be applied to the particular case.We are thinking about applying it, but currently we have chosen simpler algorithm.But to use it in the general case from 6.2, it should be adapted.We have decided that the adaptation of the algorithm would be harder, than to develop the new algorithm applied to a needed object class.

Conclusion
In this paper, the development of mission-critical systems is considered.In this context, we have considered the task of correct integration of the whole system.System modelling with language AADL and analysis of models are using to solve the task.

4 )
For each SCC-path → →. . .→ G → !" we pick vertices from each SCC and consider the following path through them: ( ⇒ *I ) → (s KL ⇒ *I ) → ⋯ → (s RS T ∈ 7, U = 1, 2, … , n V 1.We will designate such paths as W XY!" .Designation ⇒ R *I represents an automaton path from state to state R inside a single SCC-component.Vertices and *I can be the same.On the fig. 4 all paths are presented.Notice that number of such paths is finite because each SCC-path is finite.5) Let us find the weight of each path W XY!" .Weight of each transition s K Z[\ → s ] KL is equal to weight of edge (s K Z[\ , s ] KL ) of graph 4. To estimate weight of transitions ⇒ *I , = 1. .V 1, we consider two cases.Case 1: is acyclic (thus containing a single vertex), then weight of the transition ⇒ *I is 0.

Fig. 5 .
Fig. 5. Graph with complete states and execution states