Combining an Iterative State-Based Timing Analysis with a Refinement Checking Technique

. The analysis of real-time properties is crucial in safety critical areas like in automotive applications. Systems have to work in a timely manner to o(cid:27)er correct services. Most of the applications in this domain are distributed over several computation units, inter-connected by bus systems. In previous works we have introduced a state-based analysis approach to validate end-to-end deadlines for distributed systems. The approach is based on the computation of the state spaces of all resources, such as processors and buses, in an iterative fashion. For this, abstraction and composition operations were de(cid:28)ned to adequately handle task and resource dependencies. During the design process of a system changes occur typically on both the speci(cid:28)cation and implementation level, such that already performed analyses of the system have to be repeated. In this work, we extend our timing analysis with a re(cid:28)ne-ment checking approach, detail when it is appropriate to be used, and compare the analysis times with the computation times to perform the re(cid:28)nement check.


Introduction
In recent years the co-operations and inter-connections between individual, geographically distributed systems heavily increased. Also in safety critical areas the signicance of these topics increased. As an example, much eort has been invested in the development of Car-to-Car communications with the aim to increase the safety in trac and optimize trac ows. Another example is the dynamic partitioning of the airspace with respect to time investigated in the SESAR (Single European Sky ATM Research) program. The recent partitioning of the airspace is performed in a static manner with respect to time, i.e. the trajectories are not changed during the whole landing approach and the takeo. The shift to a dynamic partitioning, which is called 4D-trajectories, involves a much more intensive co-operation between the tower and each airplane. For the correct functionality of safety-critical functions of such systems, timing constraints are one crucial aspect. The nal product has to satisfy those constraints, as the violation of a requirement could result in high costs or even threats to human life. Nissan for example had to recall the vehicles of its premium segment cars due to some delays in the emergency program of their new steerby-wire system. Such a problem could have been avoided, if an early analysis on timing constraints would have been performed. Unfortunately, many changes occur during the design process, such that already performed analyses have to be repeated. Our approach targets these problems.
In [1] we worked out a state-based approach for the analysis of timing properties. In analogy to model checking methods, we consider the full state space, where all task interleavings are preserved. In order to alleviate the problem of state space explosion due to state unfolding, the state space of an architecture is constructed in an iterative manner. Abstraction methods are applied to keep the interfaces between components as small as possible, while composition operations are used to combine a set of triggering sources of a component.
On top of this we worked out an impact analysis approach to minimize revalidation eorts of timing properties needed when the considered system is modied [2]. Adaptations of the architecture of an already existing and analyzed system could be for example the addition of new tasks that are allocated to the existing system. To minimize the eort of a re-validation, it is desirable to reuse the previous results of the analysis that did not change. With this, only the parts are re-validated, which were aected by the architectural changes.
This work is a consecutive extension of our previous work [2]. We illustrate the implementation of the impact analysis. We describe in which cases a renement check can be applied to reduce the re-verication times when changes occur. We evaluate our approach by a set of test systems demonstrating the computation times needed to perform a full timing analysis and the times needed to perform the impact analysis consisting of the loading and storing of state spaces, and the renement check between state spaces. Further, we discuss the benet of applying abstractions of resource interfaces for the renement relation.

Related Work
Timing analysis on distributed systems is a very large research area. Thus, we cover only the most relevant works for our approach. The classical approach is a holistic one, as it was worked out in e. g. [3,4]. Local analysis is performed evaluating xed-point equations. These approaches are very fast and able to handle large systems. Unfortunately, the analytical approaches deliver pessimistic results if inter-ECU task dependencies exist. In [5] activation patterns for tasks are described by upper and lower arrival curves realizing a compositional analysis method. Based on this work a compositional scheduling analysis tool, called SymTA/S, was created by SymtaVision [6]. The concept has been developed by Richter et al. The main idea behind SymTa/S is to transform event streams whenever needed and to exploit classical scheduling algorithms for local analysis. Another related approach is the modular performance analysis (MPA) [7] which is based on a formalism with many similarities to event streams named Real-Time Calculus. Arrival functions are used to model the computation that is requested by a process, and service functions are used to model the amount of computation that can be delivered by a resource. In [8], the MPA approach has been combined with timed automata while oering methods that allow to transform the model of one formalism to another. CARTS is another tool for compositional real-time scheduling analysis [9]. Schedulability is checked for tasks whose resource usage is bounded by periodic resource models developed by Lee et al. Composition is done on the resource model level resulting again in periodic resource models by using abstractions.
Another approach is based on model-checking: In [10] non-preemptive schedulers are modeled in terms of timed automata. The advantage of this approach is that one gets exact solutions with respect to the modeled scheduling problem. Since the state space of the analyzed system is preserved, checking complex properties like safety is possible. Unfortunately, state-based approaches do not scale well. The authors of [11] also use timed automata to model preemptive scheduling and verify timing properties by using Uppaal. As a front-end they employ sequence diagrams, from which timed automata are derived. In [12] these automaton models were reused and the results were compared to other techniques such as MPA or SymTA/S. In [13] timed automata are extended by clocks which may be subtracted by a natural number to handle preemption in a more natural way. The authors derive a sub-class of this formalism, where the reachability is preserved.
Outline First, we illustrate the considered problem domain. In Section 3 we will detail our general analysis approach in a condensed form. In Section 4 we introduce our implemented impact analysis methodology. Section 5 evaluates our concept and compares plain verication times and renement checking times. Finally, we conclude the work and give an outlook for future work. 2 Problem Domain We are interested in safety-critical real-time systems which are typically used in the automotive domain. Typically, the design of the overall system is performed by the original equipment manufacturer (OEM). The OEM designs the software components in form of logical architectures by using, e.g., Autosar software components (SWC), inter-connected by a high level virtual function bus (VFB) like illustrated in the left part of Figure 1. The components and parts of this system are then realized by the suppliers. In order to get adequate realizations from each supplier, the OEM has to specify the extra-functional properties and interfaces unambiguously. This is realized by the usage of so called contracts [14]. used. Contracts follow the principle of separation of concerns, i.e., a contract does not just specify a guarantee about the behavior of a component, but also an assumption about the behavior of the environment in which the component will be integrated. If all suppliers deliver the implementations of the SWCs, the OEM has to verify whether all SWCs t together, i.e., he has to perform the consistency check in a black box manner, and whether some higher level requirements ranging over several SWCs are realized by the decomposition structure.
After the implementation of all SWCs the logical architecture has to be allocated to the hardware architecture, consisting of electronic control units (ECUs) which are inter-connected by bus systems. At this design stage technical details such as resource consumptions and timing latencies have to be veried. To perform such analyses, typically the architecture is abstracted in an appropriate manner. The abstraction we perform for our analysis is illustrated in the right part of Figure 1: ECUs and bus systems are treated logically equivalent in the sense that both represent computation units on which a set of tasks are allocated. The order of executions of the tasks is determined by the corresponding scheduling policy like xed priority scheduling. Dependent tasks are directly connected, tasks with no input edges are considered to work independent from other tasks. A task is characterized by a tuple τ = (bcet, wcet, pr), where bcet, wcet ∈ N ≥0 , bcet ≤ wcet, are the best and worst case execution times with respect to the resource the task is allocated to, and pr ∈ N ≥0 is the xed priority of the task. We will refer to the elements of a task by indexing, e.g. bcet τ for task τ . The set of all tasks is called T . Independent tasks are triggered by events of a corresponding event stream (ES). An event stream ES = (p, j) is characterized by a period p and a jitter j with p, j ∈ N ≥ . Such streams can be characterized by upper and lower occurrence curves as introduced in the real-time calculus [15]. In this work we restrict to event streams where j τ < p τ for all τ ∈ T. Like stated above we will further assume that dependent tasks are directly connected.  timing information for tasks allocated to the corresponding resource, and endto-end latencies between a set of tasks. In contrast to standard model-checking, our approach does work in an iterative fashion. The interfaces between resources are tried to be kept as minimal as possible. Note that we assume cyclic free systems. Parts of systems with cycles have to be handled in a holistic fashion.
To build the state space of a computation resource, we have to determine its input behavior, which denes the activation times of all allocated tasks. State spaces are represented by symbolic transition systems (STS): the states determine a range of valuations of clock variables, and include the information, which task is currently running, is interrupted, or in the ready queue. A resource can have multiple sources for its inputs: the independent tasks are triggered by event streams, while dependent tasks are triggered when the tasks on which they depend, terminate. Thus, we get multiple input state spaces. To determine a single input state space for each resource, we have to combine all these inputs.
When the input is determined, the next step is to build the state space of the resource itself. For this, the input STS, the behavior of the scheduling policy, and the execution times and priorities of the allocated tasks are taken into account. The approach to compute the state space is illustrated in Fig. 3, where two tasks hp, lp are allocated to a single resource with a xed priority scheduling policy. For each task a clock c p which traces the periodic activation is needed. Further, we need a clock c c to determine when a task is nished. If we are interested in the exact response times of a task instance, we need multiple clocks c r , one for each instance of a task.
The computed state space of a resource is then used as an input for dependent resources, i. e. for resources on which dependent tasks are allocated. To keep the interface between the resources as small as possible, parts of the state space that are not relevant for the input behavior of the dependent resources are abstracted.
Consider the example in Fig. 2, which consists of three resources where on each resource two tasks are allocated. The tasks task5 and task6 on resource Resource3 depend on task2 on resource Resource1 and task3 on resource Resource2 respectively. Tasks task1,...,task4 are activated by event streams, thus the inputs for both Resource1 and Resource2 are directly given and their state spaces can be computed (illustrated in the left part of the gure). Next, the input of Resource3 has to be determined, which depends on both the state space of Resource1 and Resource2. As timing information for the tasks task1 and task4 is not relevant for Resource3, the corresponding STSs can be reduced by abstracting from states encapsulating information about these tasks. After this minimization, the product of both STSs is computed (indicated by the right part of the gure).
The details of our timing analysis including the composition operation, the minimization, and the resource construction can be found in [1]. 4 Impact Analysis Methodology During the design process changes aecting the architecture of a system occur, such as adding a new task on an existing resource, the merge of two tasks in a single one, or even the change of the complete implementation. If such changes occur, already performed analyses have to be repeated, increasing the time needed to verify the functionality and properties of the design, and thus increasing the time to market. To minimize the eort of a re-validation, it is desirable to reuse the previous results of the analysis that did not change. With this, only the parts are revalidated, which were aected by the architectural changes. It is required to perform an impact analysis, when changing or maintaining software because it allows to judge the amount of work required to implement a change, proposes software artifacts which should be changed, and helps to identify test cases which should be re-executed to ensure that the change was implemented correctly [16].
As our timing analysis approach works in an iterative manner (and not holistically), we are able to determine whether the interface of dependent resources is aected through the concept of our renement analysis: we are able to check if the new interface between dependent resources renes the old interface. In such a case a re-validation of dependent resources can be omitted. The denition of an appropriate renement relation was the topic of our previous work [2].
In the next section, we illustrate our implementation approach of the impact analysis. We demonstrate in which cases a complete re-verication of a component is necessary, in which cases a renement check is performed, and when verication steps can be omitted. Thereafter we discuss the advantages of our approach when using further abstraction techniques on the interfaces of resources.

Concept
The concept of the implementation of our impact analysis is illustrated in Figure  8 in terms of an UML activity diagram.
Each resource has a status ag for its resource state space called outputIs-Consistent, initially set to false. The idea of this ag is to inform dependent resources whether some non-renement changes concerning the resource state space occurred (and thus the resource state space has to be recomputed).
First, it is checked whether some inputs of the resource has changed (check-InputStatus). If changes occurred, the check evaluates to false and the input STS (computeInputSTS ) followed by the computation of the resource state space itself (computeResourceSTS )is performed as usual. As the resource STS is newly computed, the ag outputIsConsistent is set to false to signalize dependent resources that this input has changed. Last, the resource STS is stored appropriately. If on the other hand the output STSs of all resources, from which the current resource depends on, did not change, checkInputStatus evaluates to true. Then it is checked whether an already computed resource STS of this resource exists (from previous verication steps, where the resource STS was saved). If not, it has to be computed as described above. Else, it is checked whether structural changes have occurred, i.e. changes concerning the scheduling policy of the resource, the number of allocated tasks and their properties like priorities and execution times. If these properties did not change, the resource STS will also be not aected. Thus, the existing STS can be restored (loaded from le system).
The ag outputIsConsistent is set to true indicating that nothing changed on the output.
If else some changes on the resource occurred checkInputStatus will evaluate to false. In this case, we have to re-compute the resource STS, load the previously computed resource STS and do a renement check between both STSs.
If the renement check evaluates to true, outputIsConsistent is also set to true indicating that the resource STS changed in a good manner. Else it is set to false. Note that before the re-computation of the resource STS the input STS of the resource has also to be re-computed because if properties of independent tasks change the input STS is also aected.

Combination with Abstractions
Generally an impact analysis is useful in combination with analysis techniques that involve abstractions. This is also a typical scenario for analytic techniques such as in [17]. These techniques are based on the assumption that every interface  behavior can be characterized by event streams. To obtain event streams for the outputs of a resource, the actual task behavior is generally over-approximated.
Hence changes in the behavior of a particular resource might indeed have an impact on the already computed exact state-space representing its output behavior, but might not have an impact on the over-approximated output behavior of the resource. This can be exploited by our impact analysis. We consider event streams as the maximal abstraction of the timing behavior of a task, as these only contain information about best-and worst-case responsetimes, without any information, in which cases the corresponding response times occurs. For example a task could have a large response time when it is interrupted by an high priority task which is allocated on the same resource, and an small response time, when no interrupts occur.
Though our analysis approach is an exact analysis in general, it can be combined with abstraction techniques in order to reduce the state space of the interface transition systems. Such abstractions were the topic of our previous works [18].
An abstraction indeed might aect the schedulability of a depending resource, and hence may cause false negative results. On the other hand, suitable abstraction techniques may pave the way to omit re-validations. 5 Evaluation In this chapter we will evaluate our methodology by the usage of the three test systems illustrated in Figure 4. Tasks with no input edge are considered as to be independent, i.e. triggered by event streams. The scheduling policies of each ECU is xed priority with interruption, and the policy of the CAN bus is also xed priority but (of course) without interruption. The parameters of the tasks are detailed in the table of Figure 5, where p is the period of a task, ecec. is the execution time which may be a single value or an interval, if bcet = wcet, and pr is the priority of a task. In our evaluation we compare the time needed for an analysis of each resource and the times needed to store and load a corresponding state space, and check the renement of the state spaces of the resources. The idea is to demonstrate that the analyses times of the resources is always much larger than the times needed to store and to load the state spaces, and to check whether if a change occurred the old state space is a renement of the new one.
Note that all times were measured on the same machine to preserve comparability. Each check has been performed ve times. The times illustrated here are the average times of all measurements.
The measured times are illustrated in the table of Figure 6. As an example: To analyze the timings of ECU 2 of System2 we need 6, 75 seconds. In contrast to this, the renement check of the of state spaces (new and old) of ECU 2 only takes 0, 015 seconds. The cell Sum is the sum of the cells Renement, Load and Store and is used to compare the times needed to perform these three steps against the plain verication time.
As an example we illustrated some cases graphically in Figure 7. The result of our evaluation is that the larger the state space of a resource is (and therefore the verication time of that resource), the larger the dierence between the verication time and the computation times needed to load, save, and check the renement of the old and new state spaces is. Thus, for larger systems our renement methodology is a real gain for our analysis approach. Note that of course, if the renement check fails, i.e. the new state space of a resource is not a renement, than we have extra analysis times which we would not have if we always perform the plain verication directly. But fortunately these renement checking times are not that large. Actually the complexity of the renement check is n(n − 1) where n is the number of states. 6 Conclusion and Outlook We illustrated the implementation of our impact analysis approach which is applied when architectural changes occur during the design state of a system. We evaluated our approach by measuring the computation times needed to perform  the full verication, the storage and load of state spaces, and the computation of the renement check, and compared these times. The result is that for larger systems our renement methodology is a real gain for our analysis approach. Currently, we investigate new abstraction techniques which will yield more accurate results than the classical analysis techniques and will boost the scalability of our approach.