Reusing TestCases on Different Levels of Abstraction in a Model Based Development Tool
Abstract
Seamless model based development aims to use models during all phases of the development process of a system. During the development process in a componentbased approach, components of a system are described at qualitatively differing abstraction levels: during requirements engineering component models are rather abstract highlevel and underspecified, while during implementation the component models are rather concrete and fully specified in order to enable code generation. An important issue that arises is assuring that the concrete models correspond to abstract models. In this paper, we propose a method to assure that concrete models for system components refine more abstract models for the same components. In particular we advocate a framework for reusing testcases at different abstraction levels. Our approach, even if it cannot completely prove the refinement, can be used to ensure confidence in the development process. In particular we are targeting the refinement of requirements which are represented as very abstract models. Besides a formal model of our approach, we discuss our experiences with the development of an Adaptive Cruise Control (ACC) system in a model driven development process. This uses extensions which we implemented for our modelbased development tool and which are briefly presented in this paper.
A. Petrenko, H. Schlingloff (Eds.): Workshop on ModelBased Testing 2012 (MBT 2012) EPTCS 80, 2012, pp. Reusing TestCases on Different Levels of Abstraction in a Model Based Development Tool–LABEL:LastPage, doi:10.4204/EPTCS.80.2 © Blech, Mou, Ratiu This work is licensed under the Creative Commons Attribution License.
Reusing TestCases on Different Levels of Abstraction in a Model Based Development Tool
Jan Olaf Blech Dongyue Mou Daniel Ratiu  
{blech,mou,ratiu}@fortiss.org \IfArrayPackageLoaded  



1 Introduction
Formally defining relations between different models used in the development process of an entire system or a component is an important prerequisite to apply techniques that give confidence in the refinement process. Lifting properties – in our case single testcases – to work on more refined models is one technique towards gaining this confidence. It is in general much easier and scalable to perform than, e.g., using formal verification techniques, and thus more convenient to use for a wider range of applications and developers that are not trained in the usage of formal methods.
Abstract models during an early phase in the software development process can be used to capture single requirements directly. Such models of single requirements concentrate on distinct aspects of a system and thereby are rather small. These models may represent functional requirements and are relatively easy to validate using testcases and a simulation environment. At a later stage in the development process we can have a model that is more refined and may describe the entire system functionality with the interplay of several finegrained requirements. A challenge is to use the existing testcases to get confidence that the concrete implementation models refine the abstract requirement models.
In this work, we regard the relation between abstract models that may correspond to single requirements, and more concrete models that can already contain enough information to automatically generate an implementation. We regard the transformation of existing testcases for the abstract models into testcases for the concrete ones.
The initial motivation for this work – that we faced in a project – is a situation where manufacturers of larger systems (e.g., a car) give an abstract specification with abstract testcases to subcontractors that are responsible for developing a distinct component (e.g., a control system used in the car). Here, at least the provided testcases for the abstract specification must be respected by the implementation that the subcontractor provides.
We present a formal framework for relating testcases, report on our implementation experiences and regard a casestudy on Adaptive Cruise Control (ACC) systems. Requirements ACC on systems are standardized in the ISO 15622 standard [8]. In this paper, we present some requirements and a model that captures the implementation and evaluate our testcase transformation using this casestudy. The featured implementation and case study is integrated into our AutoFocus 3 [2] modelbased development environment and its modeling language.
Our paper features the following contributions:

A formal framework for relating models of components for different abstraction levels which aims especially at concretizing testcases for AutoFocus 3.

An implementation of the framework in AutoFocus 3.

We exemplify our approach using a simplified variant of an ACC system.
Thus, we are addressing the issue of transforming existing testcases and relating abstract and concrete models with each other. Derivation of new testcases and evaluation of testcase quality is not subject to this paper.
1.1 Related Work
Relations between properties on abstract and concrete system representations have been studied comprehensively for temporal logics formula, e.g., in [9]. Our testcases (test + expected result) may be regarded as properties if classified in the terms of this paper.
Abstractions in the context of modelbased testing has been studied in [11]. Here, in contrast to our work, different abstraction levels of models are studied regarding suitability for deriving testcases for a final implementation.
An early formal framework for relating testcases, interactive systems and abstractions is described in [1]. Here, testcases are regarded as contracts, which is similar to our view.
The usage of program analysis techniques on abstract system representation has been studied in the context of abstract testing [6], a kind of method for handling testing in an abstract interpretation framework.
The work presented in [13] presents a combination of abstract interpretation and model checking for testing. Here, somehow opposite to our work, concrete testcases are abstracted for abstract system representations.
In addition to testcase abstraction and concretization, a large body of research has been done on other aspects of modelbased testing. For a comprehensive overview and classification we refer to [12].
1.2 Overview
2 Our Model Based Development Environment
In this section we present the model based development tool: AutoFocus 3 that we use in the context of this work. In particular we present the semantics of the modeling language.
2.1 AutoFocus Semantics
Here we present a formal definition of our modeling language AutoFocus a dialect of FOCUS [5]. We follow the description given in [7]
In AutoFocus a system and its components are described by a stream processing function, which defines its syntactic interface as well as its behavior. Furthermore, the AutoFocus approach offers composition operators which allow to derive a larger system (the composed system) out of modularly defined functions.
2.1.1 Streams
Basically, the AutoFocus theory is based on the idea of timed data streams which are used to model the asynchronous interaction between a function and its environment. Streams represent histories of communication of data messages in a given time frame. Intuitively, a timed (data) stream can be thought of as a chronologically ordered sequence of data messages.
Definition 1 (Timed Stream).
Given a set of data messages, we denote a timed stream of elements from by a mapping
For each time , denotes the message communicated at time in a stream and the prefix of the first messages in the timed stream , i.e., the messages communicated until (and including) time .^{1}^{1}1The theory is originally defined for stream processing functions , which assign a sequence of messages to each time interval. In order to keep the paper at hand as understandable as possible, we decided for the simplification that only one message can be communicated within each time interval. A proper description of the original theory can be found in [5, 4]
We have chosen socalled timed data streams that allow us to flexibly include the timing issues of functions whenever required. We base our approach on a simple notion of discrete time: we assume a model of time consisting of an infinite sequence of time intervals of equal length. Thus, time can be simply represented by the natural numbers . In each time interval a message can be transmitted.
An exemplary timed stream over the data set is defined by the function . This means that in each time interval the stream contains the value , i.e.,
2.1.2 Input/Output Channels and Channel Histories
Every stream processing function is connected to its environment by channels. The channels of a stream processing function are divided into disjoint sets of input channels and output channels . Channels are used as identifiers for streams.
With every channel , we associate a data type indicating the set of messages sent along this channel. To that end, we define the channel type by the following function:
which maps each channel to a data type from the set of all possible data types .
To describe the function’s communication with its environment, each channel is associated with a stream which represents the messages communicated over this channel (cf. Figure 1). A mapping that associates a stream to any channel from a set of channel is called (channel) history of .
Definition 2 (Channel History).
Let be a set of typed channels. A channel history is a mapping
such that is a stream of the type for each .
The set of all histories over the set of channels is denoted by .
2.1.3 Specification of Stream Processing Functions
The blackbox specification of a stream processing function consists of a syntactic interface and its semantics.
A stream processing function is connected to its environment exclusively by its syntactic interface consisting of input/output channels. This interface indicates which types of messages can be exchanged.
Definition 3 (Syntactic Interface).
The syntactic interface of a function is denoted by
where and denote the sets of typed input and output channels, respectively.
For a function with syntactic interface , the set of all syntactically correct history pairs is denoted by
However, the syntactic interface tells nothing about the interface behavior of the function.
The behavior (semantics) of the stream processing function is given by the mapping of histories of the input channels to histories of the output channels. Thereby, we distinguish between total and partial functions. While the behavior of a total function is defined for all syntactically correct inputs, the behavior of a partial functions is defined for a subset of the inputs.
Definition 4 (Semantics Relation).
The semantics of a total stream processing function with syntactic interface is given by a relation
that fulfills the following timing property for all its input histories.
Let be , and . The timing property is specified as follows:
By mapping into the powerset of , Definition 4 allows to specify nondeterministic behavior. For an input history, there is a set of output histories that represent all possible reactions of the function to the input history. If a function defines exactly one output history for every input history, the function is called deterministic; if the set of output histories has several members for some input history, then the function is called nondeterministic.
The timing property expresses that the set of possible output histories for for the first intervals only depends on the inputs of the first time intervals. In other words, the processing of messages within a function takes at least one time interval. Functions that fulfill this timing property are called timeguarded or strictly causal. Strict causality is a crucial prerequisite for the composability of functions.
If we replace the expression by in Definition 4 above (i.e., the outputs in the first intervals depend on the inputs in the first intervals), messages are processed by the function without time delay. Such functions are called weakly causal.
Stream processing functions are used to represent components in our terminology. They can contain other stream processing functions thereby forming composed components.
Moreover, it is important to notice that stream processing functions in the AutoFocus realization of FOCUS are defined as finite automata comprising internal states and not in a functional way working on entire streams. The definition is rather element wise, thus, consuming one element for each input channel at a time and generating an output element for each channel.
2.2 Tool Integration and Proposed Usages
The AutoFocus modeling language has been implemented in a model based development tool: AutoFocus 3 [2]. AutoFocus 3 supports structuring textual requirements and expressing them through models. It allows the graphical modeling of system components, their functionality and deployment aspects. It comprises code generation and integrates formal verification and validation tools. AutoFocus 3 is based on Eclipse RCP framework and comes with a plugin mechanism for new functionality.
AutoFocus 3 aims at the development of embedded systems, e.g., in the automotive industry. It can be used for the entire development process. In a typical workflow with AutoFocus 3, project partners specify requirements in a textual way using AutoFocus, create corresponding models and establish testcases based on these requirements. In the course of the project, partners provide more detailed models and an implementation. It is important, that the testcases for the models representing higher abstraction levels of a system component can be transformed into testcases for the more refined models.
3 An Abstraction Framework for Models and Testcases
In this work, we want to relate abstract and concrete models and lift testcases from more abstract models to more concrete ones. Characteristic for our framework are the facts that both abstract and concrete models are given in the same modeling language. In AutoFocus, a model does typically represent a (potentially composed) component. In AutoFocus a component’s only means of interaction with its environment is via its channels. Thus, we do not have to deal with the possibility of additional side effects which facilitates a formal relation.
An important issue is the correctness of the lifting and if the refinement between models has been done correctly. Here we present basic definitions for testcases and two formalisms for relating abstract and concrete models which we have applied and evaluated in our modelbased development environment:

A formalism for relating inputs of testcases of their expected results using mathematical relations.

A formalism for relating the stream domains of abstract and concrete components using Galois connections.
3.1 Formal Definition of Testcases
Here we present some basic definitions for testcases. Test cases comprise testinput and expected results.
Definition 5 (Testinput).
A testinput for an AutoFocus Component with syntactic interface is a function with and a correctly typed stream (cf. Section 2.1).
Definition 6 (Test expectedresults).
An expectedresult of a testcase for an AutoFocus component with syntactic interface is a set of tuples with and a correctly typed stream.
For the deterministic systems that we regard in this paper expected results can also be written as functions from output channels to streams.
Definition 7 (Testcase).
A testcase for an AutoFocus component is a tuple of testinput and expectedresult .
3.2 Relating Testinputs and Expectedresults
Figure 2 shows our first formalism for relating models and testcases: As a prerequisite, we establish two abstraction relations RI and RO which capture the relation between abstract and concrete component and compare the inputs of the two components and their results with each other. These can be stated in a formal way. Then we create an AutoFocus component which transforms abstract testcases into concrete ones.
When such an existing test input for an abstract model is transformed into a concrete one we compare these test inputs and the expectedresults using the relations thereby validating the correctness of testcase transformation.
Formally, we regard an abstract component with semantics function and syntactic interface featuring typed input channels and output channels . The concrete model has a semantics functions and syntactic interface featuring input channels , and output channels . The relation RI has the type , RO : . These two relations have to be created for every pair of abstract and concrete models.
The formal definition of correctness of a testcase transformation is stated in the following definition.
Definition 8 (Corresponding testinputs).
Two testinputs , are corresponding with respect to input and output correctness relations RI, RO for abstract and concrete AutoFocus components with semantic functions , typed accordingly iff
Here, we assume that it is relatively easy to ensure that these the relations have been stated correctly. Checking that the relations have been done correctly can be done either manually or by implementing an AutoFocus component which performs the check and emits a boolean stream of check values.
3.3 Relating the Domains of Components Using Galois Connections
A second way to relate abstract and concrete components with each other is to formalize a relationship between their domains.
Both abstract component (syntactic interface ) and concrete component (syntactic interface ) operate on domains of streams. When regarding the abstract input and output domains together as a single abstract domain and the concrete input and output domains as a single concrete domain and in case the abstract component is refined by the concrete one it is reasonable to relate abstract and concrete domain with each other via a Galois connection. Galois connection are used to represent refinements between different domains and capture their relation in a formal way (cf., e.g., [6]).
This implies the existence of two functions and . Intuitively lifts sets of concrete input and output streams to abstract ones and does it the other way round. Furthermore, in order to illustrate the refinement between the two domains the functions have to fulfill the following conditions:
iff
The functions and capture the nature of the refinement. We formalize them in order to gain a precise description of the concretization allowing a transformation of testcases.
In our proposed scenario we regard the transformation of abstract testcases to concrete ones. The process of concretizing a testcase in general allows for multiple concrete testcases for a given abstract one. Once we have established the function , we formalize a parameterized family (parameter ) of functions to perform this task for the testinput data. At least the part of is implemented as an AutoFocus component that covers the testinput. Its semantics function is denoted . In case of a restriction to the input streams all instantiations of the component have the syntactic interface .
In accordance with the Galois connection is in general too restrictive for comparing the expectedresults of testcases, thus, we use or for this purpose.
3.4 Implementing Testcase Transformation and Checking
For a practical implementation in our tool the concretization is implemented using an AutoFocus component which corresponds to the relation RI. Checking the results of testinputs is done using the relations RO. Both RI and RO and the related testcase concretization can be constructed based on the functions and and their inverses.
More concretely, for checking the output relation RO we realize an AutoFocus component and take a semantic function based on or (if exists). The realization is shown in Figure 3.
For convenience reasons, we embed it into a component which just checks that the output streams are in relation. Thus, this component has the syntactic interface that checks whether the output streams are compatible and emits a boolean value accordingly. The bool stream must be interpreted in a way, such that a single false occurring in the streams turns the entire comparison into false.
3.5 An Example
Consider the abstract component in Figure 4 and a concretization in Figure 5. The concrete component shall encode and abstract a 64 bit floating point value – e.g., an input from a sensor – into an 8 bit integer representation and the fact whether it is a positive or a negative number shall be preserved. One basic requirement specified by the abstract component could be that positive input values (including ) are encoded into positive output values (including ) and negative input values are encoded as negative output values.
Establishing the relation based approach
For using the first approach, we can establish the two relations defined on sets of streams for the channels , , , :
RI
and
RO
A test case with as input stream for the i channel will deliver the output for the abstract component. A correct concretization may be and might generate the (correct) output on the concrete component.
Using the Galois connection approach
For the second approach we relate the two models by using the functions and .
For example can be defined as:
is a function that works on streams and abstracts the floating point and integer values to bools, in a way corresponding to the example above. While
the opposite way allows in general multiple concretizations,
e.g. for a concrete implementation ,
In this case can be realized in the following way
e.g.,
Note that in general holds. The transformation of testinputs and checking the correspondence of the results can be done using AutoFocus components build from and functions.
Complexity of testcase comparison and limitations
The proposed method uses entire abstract and concretized streams. Thus, components, that realize the abstraction and concretization functions may contain internal states if they are defined in an elementwise way on the streams.
Another characteristic is that input and output streams are regarded independently. This is justified by the fact that the relation between input and output streams is covered by the abstract model and correctness of testcases and the concrete model is always regarded with respect to this abstract model.
4 ACC Case Study
We have chosen a simplified variant of an Adaptive Cruise Control System(ACC) as the case study. The ACC system controls the speed of the car and takes a desired default speed, a distance to the car in front and inputs like pressing the gas or brake pedal into account. The entire development process is carried out using AutoFocus 3. In particular, textual requirements are structured and specified, models are build from these requirements and testcases are generated for these models. Several refined models for components are created in the development process using AutoFocus 3 until finally an implementation is created. Here, we start with requirements of an ACC systems which are taken from the ISO 15622 standard [8] “Intelligent transport systems – Adaptive Cruise Control systems – Performance requirements and test procedures”.
Figure 6 shows the toplevel component structure including input and output streams of the ACC that is regarded in this paper as realized in AutoFocus.
This model works on several input streams: SensSpeed representing current speed values, SensDist representing the distance to the next car in front of the car with the ACC. Furthermore, streams that represent user input to set an acceleration mode (AccMode), a desired speed value (SetSpeed), a desired distance to the next car (SetDist), and pressing the brake or gas pedal (BrakeCmd and GasCmd) are included. Output streams comprise values for showing the current Mode (AccModeOutput) and an acceleration command which can be negative when braking (CmdAcc) or positive when an acceleration is considered favorable by the ACC.
The ACC model consists of 5 components. The SpeedPlausibilisation component (left top) and DistancePlausibilisation component (left bottom) measure takes the input speed and distance and delivers the calibrated values to the speed control component (middle top) and distance control component (middle bottom). Both components compute the suitable acceleration values according to the given speed and distance and send the results to the acceleration control component (right). When the acceleration control component is turned on and thus in active mode, it decides whose value should be respected. When it is switched to standby mode, both values will be discarded and only user’s inputs are being processed. For safety consideration, drivers can provide their inputs any time (accelerate or brake) and this forces the acceleration control component to switch itself to standby mode.
Remember that components are stream processing functions and are composed from subcomponents. A simplified version of the ACC system can be downloaded with the standard AutoFocus 3 distribution [2].
One highlevel behavioral specification of the acceleration control component is shown in Figure 7 and also modeled in AutoFocus 3. It consists of two states. The left state represents the StandbyMode and the right state is for ActiveMode. The 3 transitions between the states represent the possible state switch of the component. The driver can turn on the ACC (ActiveMode) via a switch, which is represented by the AccOn transition, or turn off the ACC (StandbyMode) any time by explicitly using the switch, which is the AccOff transition, or implicitly giving a manual brake command, which is the Brake transition. If the component is in the ActiveMode, the ACC system will control the car to follow the given speed and distance rules, if this is for some reason not desirable it does the acceleration according to the driver’s command. If it is in the StandbyMode, it only reacts on the driver’s commands.
4.1 ACC Example Requirements
In the ISO 15622 standard requirements are explicitly given in the informal text format.
Here, we present two example requirements which we discuss in more details:

To ensure the driver can override the ACC, a requirement about the reaction of the ACC on the brake event is specified:
Braking by the driver shall deactivate the ACC function at least if the driver initiated brake force demand is higher than the ACC initiated brake force. 
Requirements can also imply constraints on relations between components:
When the ACC is active, the vehicle speed shall be controlled automatically either to maintain a time gap to a forward vehicle, or to maintain the set speed, whichever speed is lower. The change between these two control modes is made automatically by the ACC system.
Other requirements posses a similar level of complexity.
In our approach, the requirement must first be formalized as a model. Figure 8 shows our first ACC requirement as an AutoFocus 3 component.
In the upper part, the abstract component is shown, the lower part defines a simple automaton. The abstract model has less input streams: DriverBrake indicating whether the brake padel is down and to what degree, AccBrake indicating the braking value currently calculated by some other ACC Components and AccState indicating whether the ACC shall currently actively control the car’s speed. The first transition on the top left represents that the ACC system must be automatically set to StandbyMode, whenever the driver gives brake command and the value is larger than the value computed by the ACC system. If the driver’s brake value is smaller than the value computed by the ACC system or the driver gives no brake command, the system state is not concerned.
The second example requirement can be modeled with an AutoFocus component with two input ports , and one output port. The two input ports represent suitable acceleration values for maintaining a time gap () and for maintaining speed set by the driver (). The output port represents the selected acceleration value according to the inputs. The internal behavior of the component can be described with just one formula: .
4.2 Concretization of a Testcase
An example testcase about the requirement from Figure 8 comprises streams for
DriverBrake , AccBrake
and the corresponding stream for AccState
.
Output of the stream processing function is delayed by one time step.
Relating abstract and concrete models
Our formalizations of the and (for different parameters) functions and the RI and RO relations realize the following constraints:

Per time tick, the values of AccBrake are either equal to ReqDistAcc or ReqSpeedAcc (if we take the second requirement at this stage into account, we already know that it is advisable to chose the least of the two values per time tick),

AccMode does not have a correspondence in the abstract domain an thus does correspond to a parameter values,

BrakeCmd in the concrete domain does correspond to the AccState stream in the abstract domain: the ACC must be switched to standby mode if a certain brake force is applied,

GasCmd corresponds to a parameter value.
The function is less restrictive than , e.g., most parameterized values may correspond to any possible parameter.
Comparing abstract and concrete testresults
In our case study we created an AutoFocus component that abstracts the results of concrete case study output streams element wise. These are compared to the results of the abstract case study and a corresponding boolean value is emitted. Thus, we are computing and in some cases .
4.3 Implementation and Evaluation
We have implemented a testcase generation and an abstraction framework for AutoFocus and evaluated it using the ACC casestudy described in Section 4. AutoFocus 3 allows assigning models to textual requirements. A screenshot of handling the first example requirement in our tool is shown in Figure 9.
Figure 10 shows a screenshot of our plugin to specify and handle abstract testcases and their concretization. Once one has specified components that realize and or test cases can be handled in a userfriendly way: on the left side, one can select a testcase, which comprises values for different time steps, thus each column specifies an input stream.
Our implementation works together with an existing testcase generation tool for AutoFocus 3 described in [10]. This testcase generator uses Eclipse based constraint logic programming to derive testcases. The testcase generator can be used to generate testcases for the abstract model. Furthermore, the implementation can also be used to derive a family of different concrete test cases for a single abstract testcase.
Regarding our framework described in Section 3, for a requirement, we are stating the RI, RO relations from Section 3.2 or the Galois connection from Section 3.3 formally using a mathematical definition first. In case of using the Galois connection approach, we are implementing the (parameterized) and functions for testcase abstraction by writing AutoFocus components that realize these functions or the required parts. It is important to notice that we can not simple replace by or vice versa since holds in general. The implemented components realizing and in the regarded cases are relatively simple. In particular it is possible to derive from . It is thus possible to verify the Galois connection property, thereby, guaranteeing that the concrete model is a refinement of the abstract model.
However, we do not have a formal framework for carrying out correctness proofs yet. Such a framework could be established using the semantics of AutoFocus and its formalization in a higherorder theorem prover and remains subject to future work.
5 Conclusion
In this paper we presented a framework for relating components at different abstraction levels with each other. We regarded transforming existing testcases for abstract models to more concrete models and applying them to these concrete models in the context of our modelbased development environment and tool AutoFocus 3. We described an evaluation of the approach using an ACC based case study. Our experiences indicate that reusing testcases for different abstraction levels in a seemless modelbased development process is feasible for software development in embedded systems.
Different directions are interesting for future work. As next steps, we are interested to take more benefit from our work on relating abstract and concrete models using Galois connections. The investigation of compositionality aspects of tests for different components in a system is a goal. We are also interested in transforming other properties like, e.g., invariants from an abstract model to a concrete one (cf. [3] for a similar approach that we investigated).
As a more challenging long term goal, we are interested in automatically generating the AutoFocus components that relate abstract and concrete models with each other. Although this is an undecidable problem, some heuristics for relatively simple models would be a great benefit. An additional goal is a further improvement of the quality of testcase generation in AutoFocus.
References
 [1] B. K. Aichernig. Testdesign through abstraction – a systematic approach based on the refinement calculus. Journal of Universal Computer Science, / (8):710735, August 2001, doi:10.3217/jucs007080710.
 [2] The AutoFocus 3 Development Team, http://af3.fortiss.org.
 [3] J. O. Blech, A. Hattendorf, J. Huang. An Invariant Preserving Transformation for PLC Models. IEEE International Workshop on ModelBased Engineering for Real Time Embedded Systems Design, 2011, doi:10.1109/ISORCW.2011.46.
 [4] M. Broy, I. H. Krüger, and M. Meisinger. A formal model of services. ACM Transactions on Software Engineering and Methodology, ACM 2007 (TOSEM), doi:10.1145/1189748.1189753.
 [5] M. Broy, K. Stølen. Specification and development of interactive systems: FOCUS on streams, interfaces, and refinement. SpringerVerlag, 2001.
 [6] P. Cousot and R. Cousot. Abstract Interpretation Based Program Testing. In Proceedings of the SSGRR 2000 Computer & eBusiness International Conference, Compact disk paper 248 and electronic proceedings http://www.ssgrr.it/en/ssgrr2000/proceedings.htm, L’Aquila, Italy, July 31 – August 6 2000. Scuola Superiore G. Reiss Romoli.
 [7] A. Harhurin, J. Hartmann and D. Ratiu Motivation and Formal Foundations of a Comprehensive Modeling Theory for Embedded Systems. Technical Report, TUMI0924, Technische Universität München, 2009.
 [8] International Organization for Standardization (ISO). ISO 15622 standard: Intelligent transport systems – Adaptive Cruise Control systems – Performance requirements and test procedures.
 [9] C. Loiseaux and S. Graf and J. Sifakis and A. Bouajjani and S. Bensalem. Property Preserving Abstractions for the Verification of Concurrent Systems. Formal Methods in System Design, 1995, doi:10.1007/BF01384313.
 [10] C. Pfaller. Anforderungsorientierter modellbasierter Softwaretest reaktiver Systeme (RequirementsOriented ModelBased Software Test of Reactive Systems) Phd thesis, Technische Universität München, 2010.
 [11] W. Prenninger, A. Pretschner. Abstractions for ModelBased Testing. Proc. 2nd Intl. Workshop on Test and Analysis of Component Based Systems (TACoS’04), Barcelona, March 2004. Electronic Notes in Theoretical Computer Science 116:59–71, 2005, doi:10.1016/j.entcs.2004.02.086.
 [12] M. Utting, A. Pretschner, and B. Legeard. A Taxonomy of modelbased testing. Working paper series. University of Waikato, Department of Computer Science. No. 04/2006. Hamilton, New Zealand: University of Waikato. 2006.
 [13] G. Yorsh, Th. Ball and M. Sagiv. Testing, abstraction, theorem proving: better together! Proceedings of the 2006 international symposium on Software testing and analysis. ACM, 2006 (ISSTA’06), doi:10.1145/1146238.1146255.