Jean-Pierre Gallois
email: jean-pierre.gallois@cea.fr

Jean-Yves Pierron
email: jean-yves.pierron@cea.fr

Qualitative simulation and validation of complex hybrid systems

Keywords: hybrid systems, formal methods, qualitative simulation, validation

Complex industrial systems need extensive validation and verification. Methods for this are well advanced in case of discrete systems. However, for hybrid systems that combine discrete and continuous aspects, they are not as well developed. To deal with this, qualitative simulation can be used, based on the principle of discretization by identifying domains of variation of continuous variables and tracking the evolution of these variables. A system can be discretized by representing its continuous parts, which are described by differential equations. When these are coupled with the discrete parts of the system, a fully discrete global model is obtained, on which formal techniques can be applied for the validation process. If the differential equations cannot be expressed clearly, it is necessary to establish a qualitative model describing the laws of evolution of continuous variables. We defined and tested a novel methodology that represents variations of continuous variables and the causal links between them to obtain mappings of system behaviors that are suitable for validation.

Introduction

Industrial systems are becoming increasingly more complex, requiring more powerful formal methods of verification and validation. Large models are usually difficult to solve analytically, so engineers use numerical simulations to study their behavior. But numerical simulation has limitations. It requires determining the values of parameters and initial conditions. In practice, these are often difficult to specify. Another difficulty is needlessly calculating the behavior of a system for parameter values that are of no practical interest in a lot of situations. More often it is of greatest interest to determine what class of behaviors is to be expected for a given constraint imposed on the initial conditions and parameters. That is why qualitative models and simulations have been used; they can cope with imprecise knowledge and with infinite numerical value domains by compacting them into abstractions, and using qualitative predictions to predict the significant qualitative classes of system behaviors. This type of qualitative reasoning is also suitable for process analyses and verifications.

In this paper we describe an approach proposed by CEA LIST, which uses formal techniques in order to automatically prove safety properties and to automatically generate a set of corresponding test scenarios. To that end, a methodology and a corresponding tool (named DIVERSITY) based on symbolic execution were developed at CEA LIST. This technique allows generating symbolic scenarios corresponding to classes of system behaviors, which are sequences of well-defined actions. Once the set of all possible symbolic scenarios is computed, it is possible to prove properties on this set and to generate concrete numerical tests from them (a single numerical test is sufficient to represent a given symbolic scenario). Symbolic execution is a proven way of overcoming both combinatorial explosion and computational redundancies. However, to analyze complex systems that include continuous components that are classically modeled by hybrid automata, it was necessary to extend the simulation method used in the DIVERSITY tool to support qualitative methods.

Qualitative reasoning has been applied in different domains as Artificial Intelligence, mathematics, economy, and much in bioinformatics this last decade [START_REF] Mateus | Symbolic modeling of genetic regulatory networks[END_REF]. Recent developments of formal tools and the increasing power of computers lead us to believe that these methods can be applied effectively to industrial-size hybrid systems.

State of the art

Hybrid systems can be described by a finite set of continuous processes and transitions, and a set of real and discrete variables on which they operate. The processes are generally defined by differential equations that give changes in the real variables. Transitions are discrete assignments and guarded with variables.

There are several classes of hybrid systems: if the differential equations, guards and assignments are linear, then the hybrid automaton is said to be polyhedral (polyhedral hybrid automaton). If the differential equations are equalities and inequalities that include constant parameters, then it is called rectangular (rectangular hybrid automaton). Finally, if the differential equations are equalities and inequalities that include the unit of time as a parameter, the system is said to be timed (timed automaton) and real variables are clocks (clocks). Timed automata are specially handled by the Uppaal [START_REF] Bengtsson | Automated verification of an audio-control protocol using UPPAAL[END_REF] and Kronos [START_REF] Bozga | Kronos: A modelchecking tool for real-time systems[END_REF] tools.

For other types of hybrid systems, we can mention the following tools and methods, which are used to calculate a set of accessible states approximated by a superset of those states: Hytech [START_REF] Henzinger | HYTECH: A model checker for hybrid systems[END_REF] for rectangular hybrid automata with transitions with linear guards; Checkmate [START_REF] Chutinan | Computational techniques for hybrid system verification[END_REF] for non-linear continuous evolutions but with linear guards, evolutions approximated by a polyhedral; the Tiwari & Khanna method [START_REF] Tiwari | Series of abstractions for hybrid automata[END_REF] for polynomial continuous evolutions, where the system is abstracted as a discrete system whose guards are polynomial. This latter approach [START_REF] Tiwari | Series of abstractions for hybrid automata[END_REF] was chosen in our work because it can manipulate polynomial constraints that are widely used in differential equations involved in embedded systems, especially in the mechanical domain. The QEPCAD tool was used to deal efficiently with constraints including polynomial expressions [START_REF] Brown | QEPCAD B: a program for computing with semi-algebraic sets using CADs[END_REF].

If the system is not clearly described by differential equations, a qualitative model must be established using specifications that describe the evolution of continuous variables. Many works have been published on this topic and a good survey of them has been presented in "Modèles et raisonnements qualitatifs" [START_REF] Louise | TraitéIC2, série Systèmes automatisés[END_REF], and, prior to that, in "A Survey of Techniques and Applications" [START_REF] Bourseau | Qualitative reasoning: A survey of techniques and applications[END_REF].

Technical context

A hybrid automaton [H96] is defined by a set of states and discrete and continuous variables. A transition between states has a guard that depends on the values of the variables and will assign new values to the variables corresponding to the new target state. For continuous variables, the laws of evolution can be described by more or less accurate differential equations in the context of the various possible formalisms and methods [START_REF] Louise | TraitéIC2, série Systèmes automatisés[END_REF]. Continuous variables change according to these laws, representing the different states of the system. System states are timed in the sense that they have a duration. In contrast, the transition time between states of the system is assumed to be zero, as the system performs instantaneous assignments to variables.

To simulate this type of model, qualitative simulation [K86] [TK02], which is an alternative to numerical simulation is used. It is based on the principle of discretization by partitioning domains of variation of the continuous variables, based on the evolution trends of these variables (increasing, decreasing, or constant) indicated by the signs of their first derivatives (positive, negative or null). In this way, one can get a tree of abstract behaviors [START_REF] Rapin | Behavioural Unfolding of Formal Specifications Based on Communicating extended automata ATVA[END_REF] that allows for coverage of the system states [START_REF] Gallois | INTERVAL, instanciation d'une plate-forme de validation pour les spécifications industrielles dans le cadre du projet CONNEXION[END_REF]. If these are coupled with the discrete part of the system, a fully discrete global model is obtained on which formal techniques can be applied.

If the differential equations are not available, it is necessary to establish a qualitative model that describes the laws of evolution of the continuous variables. One solution is to represent the velocity of variations for continuous variables and to establish causal links between them. This construction of automata modeling the evolution of continuous variables requires specific rules that we present here. These rules allow the definition of qualitative states and associated transitions where each qualitative state corresponds to a set of values for continuous variable with regards to its evolution law (corresponding to the sign of the derivative: positive, negative or null). Each transition defines a rule that allows the evolution to move from one set to another (e.g., move from a zero to a positive derivative).

Models with differential equations

As part of our study we retain the framework of models with differential equations of the first order (i.e., with first derivatives only), with polynomial integer coefficients, but to any degree and with any number of variables (this is the framework chosen by Tiwari [START_REF] Tiwari | Series of abstractions for hybrid automata[END_REF] for qualitative simulation). Higher-order differential equations can be reduced to first-order differential equations by changing variables.

In summary, continuous variables change continuously with time and they can be calculated by the differential equations applied to the control states which define the laws of change. When a guard of a transition whose source state is the current state of control becomes true, this transition is fired, resulting in new values being assigned to certain variables. In the new state of control, which is the target state of the transition, the new differential equations applying to that state provide the corresponding laws for the further evolution of the continuous variables.

Qualitative simulation with differential equations

In this section, the context is assumed to be a continuous system described solely by differential equations.

Qualitative simulation, whose core principles were well defined in the 80s and which was refined in the 2000s, is based on the principle of discretization by partitioning areas of variation of the continuous variables of the system, based on their evolution trends (increasing, decreasing or constant) based on the signs of their first derivatives (positive, negative or zero). When all the discrete states corresponding to this qualitative partitioning are created, we can apply a simple algorithm based on the possible evolution of each variable. That is, a derivative may change its sign only when vanishing, because the process is continuous (for example a positive derivative must first be zero before becoming negative). This limits possible evolutions and thus reduces the size of the corresponding graph. Finally, the differential equation system allows generation of a transition system whose states are based on partitioning continuous variables into change in areas as described above and whose transitions are possible evolutions of these states. It has been shown that the result of such a qualitative simulation is an abstraction of the original differential equation system.

Symbolic execution

In the following, we describe the classical technique of symbolic execution used in the DIVERSITY tool as it is a based on the method presented in this paper, with an adaptation to hybrid automata context.

Starting from a transition system whose transitions are labeled by conditions and assignments to variables, it is possible to produce its corresponding symbolic execution tree, in which variables are described by expressions with parameters.

Given the current state S of the transition system, and a condition which is associated with the current state, the path condition PC, a symbolic execution constructs the tree of sequences of symbolic states, based on the following rules:

The root of the tree is the initial state (the current state at the beginning of the process); For each possible successor of the current state S, a path can be constructed, if and only if the condition C on the parameters that makes a state S' a successor of the current state can be true; in that case, an edge is constructed from S to S' and the new symbolic values of variables are evaluated, applying the assignments, their symbolic values having been updated by substitution and simplified by a simplification procedure (for instance, if x + y is assigned to x, with a and b as initial values of x and y, then the final value of x will be a + b); S' is associated with a new constraint PC', which is the conjunction of PC and C (if the PC is evaluated to false by a constraint solver then the path is cut);

The process is repeated with the successors of S';

If a new symbolic state has already been reached along the same path (or in a previously calculated path if a more compact tree is required), then the execution of this path stops: this can be determining by comparing the appropriate sets of variables, by the criteria of inclusion (or equality if more precise calculus is required), for instance if the PC is x>0 in the previous state, and PC' is x >1 in the final state, then the set of possible values of x in the final state is included in the previous state and the path can be cut;

The symbolic execution is over when all the possible paths have been assessed.

The discretization process

The discretization process requires creating a state machine for each variable representing an abstraction of its evolution. A variable x can be increasing, decreasing or constant, which is equivalent to the differential equations dx/dt > 0, dx/dt < 0, dx/dt = 0. This will be represented by a state machine with 3 states and the possible transitions between them corresponding to possible evolutions of the system. Each transition is defined by an initial state, a guard, a final state, and a constraint expressed by a formula that must be evaluated a posteriori and whose evaluation will be based on each variable value after having been updated by its own state machine. The update of the variable depends on its direction of change (e.g., the new value of x > old value of x if dx/dt > 0 ...). As the constraints represent the differential equations according to the direction of evolution of the synchronized variables, the conjunction of these constraints represents the overall constraint that must be satisfied if the overall step of simulation is possible. To evaluate this overall formula the tool QEPCAD was used, which handles polynomial constraints. If the formula evaluates to false, the corresponding branch in the execution tree is cut. This process is repeated until the entire execution tree has been computed. As control states correspond to the direction of variation of each variable, we obtain for 3 states for 1 variable, and 3n states for n variables. As the set of states is finite, the process will necessarily terminate. This number of states (3n) gives a good idea of the potential complexity of the resulting models. It is clear that, in the worst case, the number of paths may be excessive. However, we assume that, if the method is applied to models of real-world systems, the number of classes of behaviors represented in this way will generally not be too large.

Complete system

In the case of a "traditional" hybrid system, the differential equation system which describes the continuous part of the system is combined with a discrete system in which there are discrete variables and transitions that affect these variables. For the qualitative simulation the discrete part of the system is unaffected by the discretization method described above. Control statements are for discrete variables "simple" states, while for continuous variables they are continuous process. The latter can be discretized with the qualitative simulation mechanism described above. Consequently, the entire resulting system is discrete, which means that it can be treated using traditional mechanisms (verification, test generation) that are applicable to discrete systems.

Nevertheless, there is a case which can be problematic: it occurs when the discrete part of the system contains variables whose domains of definition are infinite. Indeed, the number of states of the system in that case is potentially infinite, limiting the ability to fully analyze the system. In practice, if one is faced with such systems, several techniques are possible. We have chosen symbolic execution, which provides a representation that is either equivalent to the real system or a valid abstraction of it. It has been shown that when symbolic execution is applied, if the cut-off criterion is the equality of domains, then the execution tree is bi-similar to the digital implementation of the numerical tree. On the other hand, if the cut-off criterion is the inclusion of domains, then the symbolic execution tree is an abstraction of the numerical implementation of the system tree.

Working with Booleans or integers in the scope of Presburger arithmetic ensures the decidability of the process of the equality or inclusion. In this context, applying the symbolic execution to the discrete part of the system produces at least an abstraction of the execution tree of the system. As qualitative simulation also produces an abstraction of differential equations that it processes, the product of qualitative simulation and symbolic execution gives an abstraction of the execution tree of the system.

If we place ourselves in a less constrained framework, for example in the context of handling complex calculations of real numbers, we cannot apply the preceding cut-off criteria for the calculation of the symbolic execution tree (equal criterion or inclusion). In that case, the cut-off criterion chosen is generally a criterion of depth in the execution tree. In this case, we know that to this depth the symbolic execution tree is bi-similar to the numerical execution tree. It is thus necessarily an abstraction, and, therefore, for a chosen depth, we have as in the previous case of Presburger arithmetic, the ability to produce an abstraction of the numerical tree of the system.

As a result, we have an original method and an associated tool -based on symbolic execution for discrete parts of models and qualitative simulation for continuous parts -which can provide a usable abstraction of models of complex systems in every case. This approach reduces path redundancies to a minimum and, thereby, provides efficient support for analysis and verification of system properties.

Implementation

Qualitative simulation produces a discrete graph that is an abstraction of the system of the represented differential equations. The discrete graph is implemented by a transition system expressed in XLIA, which is the internal language of DIVERSITY.

Similarly, the discrete parts of the system can be translated from a model expressed in an industry-standard language like UML, SDL, or Matlab/Simulink, into XLIA, to be processed by the DIVERSITY tool.

Therefore, it is planned to jointly run the two systems (discretized differential equations and discrete system) translated into XLIA in a model by creating a model that includes these two XLIA models along with the connections between them. In the preceding discussion, it was assumed that the system has just a single differential part; but one can generalize this reasoning to a system with multiple differential parts, each of which can be discretized using the same process and then translated to XLIA.

An example: The Brusselator

The Brusselator is an example of an oscillating autocatalytic chemical reaction [START_REF] Ault | Dynamics of the Brusselator[END_REF]. Its mechanism is given by the four following chemical equations:

1. X A → 2. X Y X 3 2 → + 3. C Y X B + → + 4.

D X →

The dynamics of this system are described using differential equations and are typically resolved by a Jacobian.

Our goal is to provide a discrete description of the dynamics of the Brusselator. For this we divide the plane (X, Y) in areas according to increase/decrease X and Y, wherein these domains are synthesized by abstract states.

We thus obtain the graph of abstract states of X and Y, and therefore the behavior of the Brusselator system.

Equations

Dynamic analysis

Calculating all the possibilities of movement is equivalent to firing all transitions from each abstract state of the abstract space listed above. The simulation then yields the tree of all possible paths, which captures all possible dynamic behaviors.

Qualitative simulation shows strictly and explicitly the loop operation, which is characteristic of the Brusselator, without having to unfold the standard calculations of numerical analysis (by the Jacobian). On the other hand, the resulting abstract model provides an excellent support for the proof (e.g., it can show a loop clearly, or evaluate the intersection of the set of qualitative states with a forbidden region), especially for temporal logic properties. Finally, the abstract model can also help in the definition of test sequence (in this case, it demonstrates a characteristic sequence of the main loop by an experiment).

Models without differential equations

The method can be applied to a system including the physical data subsystem that is continuous. For this type of model the evolution of continuous variables laws can be described by differential equations or by abstract equivalents based on the tables of variation. In this section, we focus on the second case. The objective is to realize a hybrid automata representation of the system, and to apply to this model the technique of qualitative simulation that provides classes of behavior. The value of having such classes is to gain generality when validating the simulated model. Thus, if a loop is detected, it can be deduced that this loop exists for all the corresponding numerical paths. A major application of the qualitative method is getting a "mapping" of the behavior of the system. This mapping is intended to serve as a support for other purposes, such as co-simulation, HMI validation, etc.

Modeling the hybrid system

The inputs to the tool are specifications (which may be textual) and known data of the system, including engineering experiences. The model can then be encoded directly into XLIA, the internal language of DIVERSITY, in the form of concurrent state machines. It may be encoded using an industry-standard such as SysML (an objective for our future work), but it is necessary to translate this to XLIA to use the DIVERSITY tool.

When the differential equations of a system are not available to describe the behaviors of the continuous variables, their laws must be expressed by hybrid automata, which must conform to specific methodological construction rules. These rules are summed up by the following diagram, which represents the possible sequences of qualitative states. Indeed, they may be to the Nul state, their values are constant. They can begin to grow, which corresponds to the Pos Start state, or begin to decline, which corresponds to the Neg Start state. They may continue to decline, which corresponds to the Neg state, or continue to grow, that is to say the Pos state, eventually reaching either the Max or the Min state.

From the XLIA model DIVERSITY generates a tree of behaviors that can be represented in a graphical format for easier comprehension. For example, system cycles can be highlighted in this way.

Thus execution traces resulting from DIVERSITY simulations of the model can be analyzed and compared with potential scenarios configured by the operator in the simulator. In addition, one can compare the execution traces produced by the numerical simulator to what is expected by the qualitative model, to establish compliance of the numerical simulation to the qualitative simulation. DIVERSITY includes a feature that can automatically generate a compliance verdict.

Outputs

DIVERSITY calculates a symbolic execution tree in which each execution path corresponds to a potential system behavior. If test is provided for each such path, a satisfactory coverage of behaviors can result.

The classical system properties that can be identified with this technique include detecting cycles (e.g., oscillations) and reachability (or not) of specific states (critical, non-critical, etc.).

Case study

This technique was applied to the SRI temperature control model (Intermediate Cooling System [NDB14]), which was coded directly into the internal language of DIVERSITY. The SRI is a basic system found in French nuclear power plants, which is used to provide cooling of auxiliary secondary circuits connected to the turbine process. This is a device for cooling several hot sources through an interface with a cold source, controlled by exchangers. It is of reasonable size and is sufficiently independent without being too simple, permitting it to be used in "Cluster Connexion" (a French BGLE2 project, COntrôle commande Nucléaire Numérique pour l'EXport et la rénovatION)) with available project resources. It contains logical and analog parts, and is, therefore, a good candidate for our study, which was coded directly into the internal language of DIVERSITY using the modeling methodology described above.

Three state variables in the SRI model were the primary subject of the simulation process study: the hot temperature of the circuit (input to exchangers), the cold temperature (output from exchangers) and the flow in the exchangers (given by the rate of the flow within an exchanger). All other parameters were assumed to be constant.

From the qualitative SRI model DIVERSITY generated a behaviors tree that could be represented in a graphical format for readability. This set of paths can highlight any potential oscillation in the control cycle, which can occur when the set temperature is exceeded, giving rise to several control cycles before stabilizing.

Another useful input to the DIVERSITY tool is a set of traces based on numerical simulation scenarios of the system. These traces capture observable variables in the numerical simulations. They can be used to demonstrate compliance of the numerical model with the XLIA model. Namely, the execution traces of the simulator can be compared to those of the qualitative model so that compliance of the numerical simulation with the qualitative simulation modulo these traces could be established. This was done by considering changes in temperature measurements in the circuit (by observing the oscillatory phenomenon of the regulation). For this global case study we obtained a behaviors tree containing 49 states and 18 paths. Each path is a behavior cycle of the system. The longest path contains 19 states.

The complexity of the approach without using differential equation is similar to the complexity encountered with differential equations, in terms of numbers of states and potential paths of the produced tree. Based on that so we anticipate that, for reasonable case studies we will not have to model systems with very large numbers of distinct classes of paths, and that the method will remain practical. This will have to be evaluated more in the future with larger experiments.

Conclusion

The technique of qualitative simulation with differential equations has been evaluated using the CEA LIST DIVERSITY tool on several different models, including a model of chemical equations (the Brusselator), which is completely nonlinear. The main result of this was that a mapping of the behaviors of such systems can be calculated very quickly and presented in an abstract form, using qualitative states and transitions. For instance, in the chemical model example we obtained a single path which synthesized many concrete numerical paths.

Applying the method to the case when differential equations cannot be expressed clearly was also evaluated. A model of the cooling system in the French BGLE2 project "Cluster CONNEXION" was used. It provided interesting results, allowing the comparison of qualitative paths against the numerical paths obtained by numerical simulation, which are difficult to classify for validation activities. Since the qualitative paths are an abstraction of the numerical ones, they are more usable for formal activities and provide a more human-friendly and more suitable representations of behaviors (e.g., detecting oscillations or proving essential properties of the system).

Prospect

A tree produced by DIVERSITY can be used in co-simulation to validate other systems that interact with the hybrid system represented in this way. Indeed, co-simulation generally involves numerical simulators which often involve long computation times and which are necessarily configured only for specific scenarios, thus reducing the scope of exploration. In contrast, qualitative simulation provides a good abstraction of all system behaviors, which requires less computation time and thereby enables more exhaustive exploration.

We plan to construct a component FMU (Functional Mockup Unit) from the execution tree generated by DIVERSITY, which can play the role of observer and actuator, and which can be interfaced with a simulated system. This component can then be used to automatically drive a pre-computed execution scenario replacing the need for a human operator of the simulator.

Vx = 1

 1 -(b + 1) X + a X 2 Y (the growth rate of the concentration of X) Vy = b X -X 2 Y (the growth rate of the concentration of Y) Note 1: variables X, Y, and parameters a and b are positive. Note 2: If the speed Vx is positive [resp. negative], the concentration of X increases [resp. decreases]. Abstract space Division of space: -3 possible states for Vx (Vx = 0, Vx> 0 or Vx <0); -3 possible states for Vy (Vy = 0, Vy > 0 or Vy <0). This makes a total of nine states (3x3): State S1: Vx < 0 and Vy > 0 State S2: Vx = 0 and Vy > 0 State S3: Vx > 0 and Vy > 0 State S4: Vx > 0 and Vy = 0 State S5: Vx > 0 and Vy < 0 State S6: Vx = 0 and Vy < 0 State S7: Vx < 0 and Vy < 0 State S8: Vx < 0 and Vy = 0 State S9: Vx = 0 and Vy = 0 The diagram represents the qualitative simulation of the Brusselator.

  The following are graphical representations of the three main automata of the model that was realized in DIVERSITY and the graphical representation of the results of the qualitative simulation calculated by the tool:Cold Temperature: TCold. Variation of TCold: dTCold Hot Temperature: THot. Variation of THot: dTHot Exchange rate: Rate. Variation of Rate: dRate Note: ∆HeatSource>0 (resp. < 0) means an increasing (resp. decreasing) of heat source. Thus we finally obtain a set of paths containing all potential behaviors. The following picture describes one of them.


Sébastien Dubé
email: sebastien.dube@hella.com

Mesut Özhan
email: oezhan@inchron.com

Achim Rettberg
email: achim.rettberg@hella.com

A Practical Approach to the Simulation of Safety-critical Automotive Control Systems considering Complex Data Flows

Keywords: Automotive Control Applications, Electronic Power Steering, Fault Tolerant Time Interval, Response Time Analysis, Real-Time Simulation, AUTOSAR III. MOTIVATION

Embedded systems highly contribute to the efficiency, safety, and usability of our present-day means of transport like cars and airplanes. Due to the possible hazards and risks involved with their operation, safety standards like DO-178C for avionics and ISO 26262 for automotive commend the application of methods and tools according to the state of the art. Functional safety requirements imposed on hardware and software imply the detection of malfunctions and taking corrective actions, before hazards actually occur. As described in [5] one of the key challenges thereby is the prediction and verification of the system's timing behavior. In this paper we describe a model-based approach for real-time simulation focusing on complex end-to-end data flows typically encountered in safety-critical automotive control applications. Based on first-hand experiences gained during the development of an electrical power steering control system, we illustrate how real-time simulation models can be utilized to guide design decisions, and help to achieve safety goals defined at system level. Furthermore, we discuss the issues of response time analysis for dynamic state-dependent data flows considering different semantics for communication in the context of the AUTOSAR standard. II.

Safety mechanisms built into a system are liable to hard real-time requirements. Hence, the transition into a safe state must be achieved under all possible conditions with respect to a limited time span, the so called fault tolerant time interval (FTTI) as defined in [START_REF] Simonot-Lion | Automotive Embedded Systems -The Emergence of Standards[END_REF]. However, if one considers the many different factors that influence a system's timing behavior, e.g. the number of possible faults and failure states, the complexity of the data and control flow, or the scheduling properties of different hardware and software variants, it turns out, that finding a robust and reliable dynamic architecture design is a very challenging task. The problem of verifying the schedulability of processes and messages in a distributed system is NP-hard [START_REF] Burns | Scheduling hard real-time systems: a review[END_REF], and besides hard real-time requirements, for safety-critical systems additional requirements must be considered in order to guarantee dependability.

During the past decades, since Liu and Layland in [START_REF] Liu | Scheduling algorithms for multiprogramming in a hard-real-time environment[END_REF] presented their work about rate-monotonic scheduling (RMS), research in scheduling theory has developed a large number of concepts and mathematical proofs in order to take on the challenges presented by the analysis and optimization of embedded control applications. But, despite the many advances in extending their scope and applicability as described by Sha et al. in [START_REF] Sha | Real time scheduling theory: A historical perspective[END_REF], most theoretical approaches remain limited to specific use cases as typically some of their constraints are violated in real industrial systems. Examples for those limitations and constraints are given by Cooling in [START_REF] Cooling | Rate monotonic analysis[END_REF] and Davis et al. in [START_REF] Davis | A survey of hard real-time scheduling for multiprocessor systems[END_REF]. A more recent study taking into account precedence relations between tasks is provided by Kermia in [START_REF] Kermia | Optimizing distributed real-time embedded system handling dependence and several strict periodicity constraints[END_REF].

The software standards developed by the Automotive Open System Architecture (AUTOSAR) partnership [START_REF]AUTOSAR Development Partnership[END_REF] have dramatically changed the way automotive systems are built today, and the transformation of processes, methods, and tools is not yet finished. Since AUTOSAR release 4.0 there is also a dedicated specification [START_REF]Specification of Timing Extensions, Final Version[END_REF] for the formalized description of timing properties and constraints available. And although, this helps to identify and exchange timing-related information in a complex automotive supply chain, AUTOSAR does not address the issue of how this information can be obtained, or a timing analysis can be performed.

In order to evaluate a system's performance, interoperability, robustness, and eventually its safety, the specific characteristics of the AUTOSAR operating system and run-time en-vironment (RTE) must be considered on implementation level. These comprise concepts like OS applications, IOC, shared (multi-core) resources, schedule tables, and extended tasks. For AUTOSAR compliant real-time systems, Anssi et al. in [START_REF] Anssi | Enabling scheduling analysis for AUTOSAR systems[END_REF] presented a study, where the applicability of schedulability analysis is evaluated using an open source implementation [START_REF]Software engineering and Universidad de Cantabria real-time group. Modeling and analysis suite for real-time applications (MAST)[END_REF] of Palencia's and Harbour's algorithm [START_REF] Palencia | Schedulability analysis for tasks with static and dynamic offsets[END_REF]. Additional evaluations are provided by Hladik et al. in [START_REF] Hladik | Adequacy between autosar os specification and real-time scheduling theory[END_REF]. Viewed from the system engineering perspective eventually one key issue remains: Even if state of the art scheduling analysis methods can be applied, they can only provide true or false statements on the feasibility of a given system configuration. However, in order to perform design modifications efficiently, engineers need more fine-grained information about their system's dynamic behavior, e.g. obtained by statistical analysis of trace data coming from target measurements or real-time simulation.

IV. CASE STUDY: ELECTRONIC POWER STEERING

The research results presented in the following are based on the observations and experiences made by the authors during the development of an electronic power steering (EPS) system at Hella Engineering in Toulouse, France. Due to the safety and hard real-time requirements for this system, a modelbased approach using SysML at logical architecture level, and AUTOSAR methodology at technical architecture level was implemented. For the simulation, visualization, and exploration of various design alternatives methods and tools [START_REF]INCHRON Tool-Suite[END_REF] provided by INCHRON were also used from the very beginning of this project.

A. System overview

The electronic power steering system in our case study as depicted in figure 1 uses a brushless motor to assist the driver in steering his vehicle. Position and torque of the steering column are permanently measured by sensors and processed by the steering control module (SCM), which calculates an assistive torque that is applied depending on different driving conditions. Advantages of an electronic power steering system over a comparable hydraulic solution are improved fuel efficiency and greatly simplified manufacturing and maintenance processes. Also, in combination with an electronic stability control it vastly contributes to improved driving safety.

B. Objectives

A major challenge during the development of embedded systems such as the electronic power steering is the verification of end-to-end latency requirements. The difficulty lays in the fact that these systems feature many different functional and dysfunctional modes of operation with corresponding hard real-time requirements for monitoring, error detection, and error handling. Depending on the required safety level, the implementation of these safety mechanisms in addition to the actual control functionality, drastically increases the complexity of the data and control flow. As a consequence for the EPS system development, following a classical integration and test approach solely based on measurements on the target hardware, seemed not feasible. In order to reduce the time and effort, that it takes to find resource bottlenecks, timing Figure 1. Electro-mechanical components of the electronic power steering system errors, and eventually to verify the real-time requirements, it was one of our main objectives in this case study to apply stateof-the-art methods and tools, aiming at a virtual integration of the system in earlier development phases. Furthermore, the verification of an embedded system requires that timing properties and constraints are specified in a formal, unambiguous way, matching with the semantics of the formalism which is used for the analysis. Thus, another objective was to check if all the system information, needed by either formal schedulability analysis or model-based scheduling simulation, is available in a real project environment. Finally, we wanted to achieve a seamless integration of all methods and tools avoiding redundant modeling of the same information as much as possible.

C. Design of the dynamic architecture

An important part of the dynamic architecture design for the SCM was planning the execution of tasks and interrupt service routines (ISR) on the main microcontroller. The initial design was created according to the strategy of deadlinemonotonic scheduling (DMS) [START_REF] Leung | On the complexity of fixed-priority scheduling of periodic, real-time tasks[END_REF] where tasks are assigned priorities depending on their deadline with priorities being inversely proportional to the length of the deadline. Compared to RMS, deadline-monotonic priority assignment is an optimal strategy for tasks that can have a deadline equal or smaller than their activation period. Furthermore, Audsley and Burns [START_REF] Neil | Deadline monotonic scheduling[END_REF] [START_REF] Burns | Scheduling hard real-time systems: a review[END_REF] showed that with additional schedulability tests, the deadlines of sporadic tasks can be guaranteed within the deadline-monotonic theory.

Table I shows the initial scheduling configuration for the SCM according to the deadline-monotonic priority assignment strategy. 1 In order to preserve most of the scheduling characteristics guaranteed by DMS, the SCM design was restricted to only use time-triggered, basic tasks with no priorities shared between two different tasks.

For the model-based simulation with the INCHRON Tool-Suite a project file (.ipr) of this configuration needed to be created. As suggested by the TIMMO-2-USE project in [START_REF] Ekelin | TIMMO-2-USE Methodology Description V2[END_REF], there are basically two different possibilities to create a model for the simulation: either top-down based on requirements and design specifications in an early project phase, or bottom-up by reverse-engineering the necessary information based on an existing (prototype) implementation of the system. In this case study the initial simulation model was generated by importing the AUTOSAR ECU configuration data of a prototype sample into the INCHRON Tool-Suite.

Another very important input parameter required for the schedulability analysis and simulation is the core execution time (CET) of the scheduled processes. Obtaining actual and reliable execution time information in reality is not an easy task. Even if sophisticated measurement capabilities are available, it can be very difficult or nearly impossible to do measurements for all possible operation states and (error) conditions in many different variants. An alternative to measurements on the target hardware is to predict worst case execution times by using static code analysis, e.g. as suggested by Ferdinand in [START_REF] Ferdinand | Worst case execution time prediction by static program analysis[END_REF]. However, this approach also has its limitations: for example increasingly complex caching and pipelining solutions found in modern microcontrollers, make it very difficult to predict the time consumption of machine code instructions.

In the case study, the model-based simulation of different scheduling scenarios was performed by using execution time information which was measured on the target hardware. Measurements were taken for various operation states, whereas focus was laid on those configurations that covered the most complex execution paths (in case of the control functions). In order to further increase the confidence into the results, we applied scaling factors to some of the measured values for those functions where behavioral details were unknown. However, it should also be noted, that for the verification and optimization of end-to-end latencies in a distributed system, time delays caused by asynchronous process executions can be more important, than the deviation of individual execution times.

D. Event chains with hard real-time latency requirements

A temporally ordered sequence of correlated events, that can be observed or measured in a system, is referred to as a chain of events, or event chain. Applied to embedded real-time systems, the concept of an event chain can be used to specify a sequence of function executions and (communication) data flows between them, which are subject to safety and real-time requirements. Figure 2 shows an example for such an event chain in the SCM, starting with the sampling of the torque sensor and ending with the control of the motor realizing the steering assistance. The event chain concept is a very useful abstraction in order to describe the scope of an end-to-end latency requirement from the perspective of a control or system engineer, considering the influence of both the hardware and the software. In the automotive industry it is a widely used concept, but only since its formalization by the AUTOSAR standard, the semantical pitfalls of ambiguous textual and visual descriptions could be mitigated.

A key issue in the formal semantics of an event chain concerns the definition of data flow properties: the data flow in a system results from the production, transmission, and consumption of data by different hardware and software functions. In a distributed system the deployment (location) of a function mostly determines the means by which this function is able to communicate with other local or remote functions, e.g. via messaging over a network, shared variables etc. As the interpretation of an event chain depends on the behavior of the functions in its scope, and again their behavior depends on the value, state, order, and age of the processed data, a formal semantics of the data flow needs to take the different communication means and their characteristics into account. At the same time, the mathematical model which is used by the analysis or simulation, must be able to handle that formalism.

Initially, at the beginning of the case study, the data flow between hardware and software components at system level was modeled by using the flow port concept of SysML [START_REF] Omg | SysML Standard v1.2[END_REF] as depicted in the figure 3. This modeling view helps to understand the relationships between architectural blocks, differentiated between hardware and software. However, some essential data flow characteristics as described above, were not supported by that concept. Furthermore, we also tried to derive a communication model from the AUTOSAR meta-model, but that approach turned out to be too complex, as the specification of the communication and the dependencies between basic software modules is significantly different from the concepts used for the application software. A further restriction was the difficulty to adequately describe the behavior and influence of hardware functions. Eventually, in the case study a rather simple but sufficiently powerful formalism, derived from the co-design methodology for embedded systems (MCSE) [START_REF] Paul Calvez | Uninterpreted co-simulation for performance evaluation of hw/sw systems[END_REF], was used for the specification of data flows as follows:

• Shared variable (or permanent data): Data which can be read / written at any time. In order to avoid data inconsistencies, the access to shared variables must be protected against simultaneous read and write operations by asynchronous processes.

• Event: An (activation) event that triggers the execution of a process.

• Queued: Data is buffered in a queue with FIFO mechanism where the oldest data in the queue is read first. In control theory the queue size usually directly depends on the execution periods (frequency) of the producing and consuming processes.

Figure 4 shows the application of the co-design methodology for the modeling of the SCM system architecture. This model describes the main hardware and software functions, and also the data and control flow connections according to the MCSE semantics. Compared to the basic SysML semantics (see figure 3), the most important differences are as follows:

• Rich data flow semantics: MCSE supports different types (shared variable, event, queued) for data flows, which allows abstract modeling of the most common communication mechanisms encountered in real systems.

• Activation flow: Event-triggered activation of processes is explicitly supported by MCSE, but not the basic SysML model.

• Timing properties: Task periods, interrupt interarrival times, and other timing parameters can be specified as properties of a (software) block.

• Closer to AUTOSAR model: MCSE is closer to the AUTOSAR meta-model (the SCM is based on AUTOSAR), and offers better support for the concepts used in the specification of the software architecture.

In the case study, this model was used as a starting point for the definition of the data and control flow in the INCHRON Tool-Suite. Basically, the MCSE concepts could be mapped one-to-one to semantically equivalent communication concepts in the tool. A further advantage of this approach is that event chain definitions for the functional and dysfunctional operation states of the system can be described in a common model, using the same data and control flow concepts. For this paper, we have selected two (dysfunctional) event chains, in order to demonstrate the application of our approach for the verification of end-to-end FTTI requirements. Figure 5 shows the sequence of process executions for each event chain similar to the definition in the simulation tool. They start with the detection of a failure at different signal sources, but then follow the same sequence of function executions until they end with the transition into a safe state (here disabling the application of the motor torque to the motor power stage). Arrows between the processes represent a (typed) data flow connection in the model, which are then traced and highlighted in the simulation (see figures [START_REF] Davis | A survey of hard real-time scheduling for multiprocessor systems[END_REF][START_REF] Ekelin | TIMMO-2-USE Methodology Description V2[END_REF][START_REF] Ferdinand | Worst case execution time prediction by static program analysis[END_REF][START_REF]INCHRON Tool-Suite[END_REF].

In general, a failure of the system can have different underlying causes originating from either the environment (e.g. the system operating under conditions different from its specification) or the system itself (e.g. a malfunction of an electrical, electronic, or mechanical component). However, at software level for the verification of FTTI requirements, this difference can be neglected. For example, if the system needs to shutdown when sensors indicate a too high temperature, we do not need to care, if this indication is caused by a sensor malfunction, or the system temperature being actually too high. Regardless of the failure source, the dynamic architecture design must ensure, that monitoring, error detection and error handling processes are executed in a deterministic way, and meet the FTTI requirements. In a real system the malfunction causing the system failure can occur at any time, and in order to verify the compliance of the dynamic software architecture with the FTTI requirements, it is necessary to recreate the different scheduling situations in the simulation. Therefore, it is not sufficient to induce an error just once, but it must be done repeatedly over the time of the simulation. For the SCM the stimulation generator of chron-SIM was used to define an environment model (scenario), that would randomly induce an error with respect to the activation period of the concerned monitoring or error detection process. For example, if the error detection is executed every 10ms, then a uniform random variation between 0 and 10ms was chosen for the error induction. Figure 6 shows the stimulation scenario defined for the different errors induced during the simulation. The main benefit of this approach is, that it allows to reach a high coverage of the various, relevant preemption situations in a very short time -much shorter than in a hardware-in-theloop (HIL) or prototype test environment.

V. SIMULATION AND OPTIMIZATION

Using the INCHRON Tool-Suite we performed several simulation runs in order to compare alternative scheduling configurations for the SCM. The traces generated by the simulation were evaluated according to the following quality criteria:

• Deadline violations • Response time distribution • CPU peak load in certain averaging intervals • Start-to-start jitter
• End-to-end latencies of dedicated event chains According timing requirements were specified directly in the simulation tool, and evaluation statistics were automatically generated after each iteration. After analyzing these results, the (scheduling) configuration was modified manually, and a new iteration was started. The most important observations and conclusions made during the case study, are presented in the following.

A. Adjustment of start offsets

Figure 7 shows an excerpt from the simulation trace of the initial system configuration as specified further above in table I: process executions (indicated by green areas within the rectangular process box) and preemptions (white areas) by higher priority processes are depicted as a Gantt diagram. One observation made during the analysis of simulation results for the initial scheduling configuration was, that CPU load peaks can occur when processes with relatively large execution times are activated at the same time. For example the timetriggered processes ASIC_Manager and Analog_Manager both with a period of 1ms were affected. Furthermore, Com_Tx and Com_Rx with a period of 5ms also had this issue. An obvious solution to smooth the peak load, would be to introduce a time delay (offset) between the activations of the processes in question. For example for the ASIC_Manager task, an activation offset of 500µs against the Analog_Manager task seemed feasible. 2 However, the granularity of the underlying OS counter tick was just 1ms, and thus shifts between the activations were only possible in steps of 1ms. For this reason, the OS configuration was modified, and the granularity of the OS counter tick was reduced to 500µs.

B. Deadline violations

In the case study deadline requirements were defined for all processes. These were monitored and checked during the simulation of the different scheduling configurations. The simulation tool shows the evaluation of all (response time and other) requirements in a dedicated requirements evaluation view, where the number of successful, critical, and failed checks for each requirement is summarized (see figure 8). A concrete response time check is considered critical, if a certain predefined margin relative to the actual deadline is exceeded. For example, we can see that the response time of Com_Rx is considered critical, as it exceeds the safety margin. Overall, we observed no hard deadline requirement violations in the case study.

C. Execution jitter

In order to monitor the efficiency of a specific scheduling configuration, it may be necessary to monitor additional process statistics. A very useful indicator is the execution jitter. Figure 9 for example shows the time distribution of the startto-start (purple bars) and terminate-to-terminate jitter (green bars) for the Com_Rx task. In the histogram, we can see that the start time of Com_Rx fluctuates between 4.98 and 5.03ms due to preemptions caused by interrupts and higher priority tasks.

D. Evaluation of event chain 'Temperature Error'

A Temperature Error is indicated by the task Temp_Manager when the temperature value measured by the temperature sensor exceeds a predefined threshold. If this is the case, the Mode_Manager task shall switch into a corresponding failure mode, and send an error notification PWM_Stop to the power stage which is driving the motor. According to the system specification, the end-to-end latency requirement goal for this event chain was 12ms.

The simulation of the SCM with chronSIM predicted, that violations of the end-to-end latency requirement are possible, although no activation violations occur and all processes meet their deadline requirements. An example from the simulation which shows such a requirement violation is given in figure 10. In this particular case, we can observe that the endto-end latency mainly arises from the 10ms period of the Temp_Manager task, and from the additional delay (almost 3ms) between the execution of the Temp_Manager and the Mode_Manager task. One possible solution would be to increase the execution frequency of the Temp_Manager task, in order to reduce the time delay which occurs after the provision of new sensor values by the Analog_Manager task. However, this would also increase the CPU load.

Alternatively, a solution would be to reduce the time delay between the activation of the Temp_Manager and Mode_Manager task, by adjusting the start offsets. Furthermore, it is also necessary, that Temp_Manager gets a higher priority than Mode_Manager, so it is scheduled first. Although, this priority change contradicts the DMS strategy -Temp_Manager has a bigger deadline than Mode_Managerit seems to be the most feasible solution to reduce the event chain latency. After the adjustment of the scheduling as defined in table III, a rerun of the simulation shows, that the end-to-end latency of the event chain now remains under the deadline of 12ms. An example for a successful evaluation of the requirement is shown in figure 11. The distribution of the end-to-end latency for the event chain Temperature Error predicted by the simulation is shown in figure 12. According to these results, the latency of the event chain ranges from 0.3ms up to 10.4ms.

E. Evaluation of event chain 'Analog Input Error'

In addition to the main temperature sensor, the SCM processes temperature information from two additional temperature sensors in different locations. These are connected to the SCM via two multiplexed (switched) analog inputs. The multiplexing is controlled by an ASIC using synchronous SPI bus communication. Depending on the SPI pin selection controlled by the ASIC_Manager, the ADC reads the sensor signal from either Analog_Input 1 or Analog_Input 2.

As shown in figure 13, the switching between the analog inputs every 6ms can lead to a delay for the recognition of a potential Analog Input Error. In this situation, we can see that an input error propagating from Analog_Input 1 is not processed immediately by the Analog_Manager task, but only after an additional switching cycle, when Analog_Input 1 is selected again after Analog_Input 2 was read. Considering the simulation results we can see that the switching frequency is highly relevant for the optimization of the end-to-end event chain latency. If we increase the frequency (decrease the period) switching inputs every 1ms, thus accepting a slight increase of the CPU load, we can reduce the time delay for the error indication to propagate and reach the power stage in less than 12ms as depicted in figure 14. Figure 15 shows the CPU load for the initial configuration of the SCM before the optimization, and figure 16 shows the CPU load for the final configuration. In both cases the CPU load curve was calculated for a smoothing interval of 1ms with a granularity of 10us. We can observe that the CPU load peaks in the initial configuration reach up to 64%, and are slightly higher than those observed in the optimized configuration. The decrease from 64% to 58% was achieved mainly by the re-adjustment of the start offset for the ASIC_Manager task.

VII. GENERIC DESIGN RULES LEARNED FROM THE CASE

STUDY

A key question for the optimization of the scheduling in the SCM was to know which configuration parameters can be changed, and which changes are the most effective in order to fulfill the timing requirements. The theory for preemptive fixed-priority scheduling usually focuses on the optimization of process priorities and relative activation offsets. As we have shown in this paper, the optimization of offsets -even when it is done manually -is very effective to minimize the number of context switches3 and to smooth the CPU load in time intervals which show high CPU load peaks. At this, it is important to follow the precedence relations imposed by the data flow in the system, as otherwise the end-to-end latencies of event chains will be unnecessarily prolonged. However, we have also shown that for the optimization of event chains, it can be very useful to consider changing also other aspects of the system configuration, like activation periods, or the number and decomposition of processes:

• Periods of time-triggered processes: Usually, the activation period of a time-triggered processes is deduced from the system requirements of the functions allocated to this process. Nevertheless, in some cases the activation period can be relaxed without violating any constraints. For example in many control systems, processes concerned with the sampling and (pre-)processing of sensor data are usually scheduled with a higher frequency than necessary, in order to compensate for unpredicted scheduling effects.

• Number and decomposition of processes: The number of processes and their decomposition, as a matter of fact the allocation of basic and application software functions (or runnables) to processes, is guided by both functional and safety requirements. As the endto-end latency of an event chain results from a predefined, sequential chain of function executions and data flows, and thus depends on the timely interaction of the involved processes, it can only be optimized under consideration of the underlying process architecture.

In a complex control system, consisting of many event chains with different criticality, designers must find a trade-off between the separation of concerns driven by safety requirements, and the compliance with real-time requirements imposed by the functional domain.

• Execution order: In general, the execution order of functions within one process should follow the data flow between the functions. In some cases, additional design techniques must be employed to break up feedback loops in the data flow.

• Core affinity: On multi-core processors, the core affinity of a process defines on which core(s) this process is allowed to execute. In order to avoid expensive crosscore communication between processes, functions of the same event chain should not be allocated to processes which execute on different cores.

VIII. EXTENDED TIMING-AWARE CO-DESIGN

METHODOLOGY

Based on the experiences made in the case study, we have enhanced our development process for the verification of (safety-critical) event chains with hard real-time requirements. A seamless workflow as depicted in figure 17 combining timing measurements on the target hardware with modelbased timing simulation was defined, and feasibility of the approach was tested using the commercial tools chronVIEW and chronSIM developed by INCHRON. The following work tasks shall be performed iteratively:

• Specify the structural system architecture comprising the basic hardware and software elements using the MCSE modeling concepts.

• Identify the interactions between application and basic software (e.g. required services), and basic software and hardware peripherals (e.g. sensor data acquisition).

• Specify the dynamic system architecture comprising the basic execution and communication blocks (tasks, interrupts, messages) and their associated timing properties (BCET, WCET, period, offset, deadline, priority etc.).

• Specify the functional data and control flow considering all relevant modes of operation.

• Perform safety analysis and deduce the dysfunctional data and control flow for all relevant fault conditions.

• Create (using chronSIM's model editor directly) or generate (using the INCHRON python API) a timing simulation for the chronSIM tool out of the various architecture models.

• Define simulation scenarios in chronSIM for the various modes and fault conditions and perform simulation runs.

• If available perform measurements of the integrated target and import and analyze the measured trace with the chronVIEW tool.

• Extract timing properties and update simulation parameters with measured values. This is already done automatically by the tool.

• Iteratively perform simulations and target measurements until all functional and safety requirements can be fulfilled by the current set of timing properties.

IX. CONCLUSION AND FUTURE WORK

Following the practical approach described in this paper, we have shown how state-of-the-art model-based simulation techniques can be used to support the dynamic architecture design of complex automotive control systems. Although, it may appear that adjusting the scheduling configuration in the presented examples is not too complicated, and the proposed solutions may seem obvious, one should consider the number and complexity of the entire event chains in the SCM. In reality, system engineers and software architects responsible for integration and testing, have to achieve many different competing, and sometimes contradicting design goals, especially concerning the dynamic behavior of the system. Model-based simulation and statistical analysis tools as provided by INCHRON greatly help to detect possible realtime requirement violations, and furthermore offer guidance in order to adjust and optimize an existing system configuration. Eventually, they help to document and prove 4 the feasibility of the dynamic architecture design or subsequently proposed design modifications.

Another goal of the case study was to explore possible options for the integration of the different tools used in this project, e.g. for modeling the system architecture, compiling the AUTOSAR configuration, performing the timing simulation, and debugging and tracing on the target microcontroller. Although, some tool-integrations already exist, for example the INCHRON Tool-Suite can generate a model out of an AUTOSAR configuration in .arxml format, not all the relevant information is represented adequately in each model. In some case, we used the Python programing language and the model API of the INCHRON Tool-Suite to automatically generate the simulation model, and to extract execution times from a measured trace in order to update the parameters of the simulation model. In other cases, e.g. for the modeling of event chains or real-time requirements, the transformation from the system architecture model into the simulation model was done manually, mainly due to issues with the interpretation of the data flow semantics discussed in section IV-D of this paper.

In the future, we intend to increase the efficiency of the integration between the simulation and system modeling tools by extending the UML/SysML meta-model profile with the semantics defined in the MCSE methodology. This will make it possible, to automatically generate the event chain and requirement definitions used by the simulation, directly from the system architecture model, and thus eliminate the need to re-model them manually. This solution would also use the existing model API of the simulation tool, and can be maintained without high effort.

After that, we also want to evaluate, if formal verification methods as described in [START_REF] Berthomieu | Fiacre: an intermediate language for model verification in the topcased environment[END_REF] can be applied in a real project environment, in order to find possible inconsistencies concerning the data and control flow already in the structural architecture model, and thus reducing the number of required simulation iterations for the optimization of the system. Finally, we plan to migrate the case study to a multi-core platform, in order to analyze and verify our assumptions for multi-core architectures.

Figure 2 .

 2 Figure 2. Event chain with end-to-end latency requirement

Figure 3 .

 3 Figure 3. Simplified SCM model as SysML internal block diagram

Figure 4 .

 4 Figure 4. Technical architecture of SCM with functional and dysfunctional data flows

Figure 5 .

 5 Figure 5. Event chain definition for Temperature Error and Analog Input Error

Figure 6 .

 6 Figure 6. Stimulation scenario defined with the INCHRON Tool-Suite

Figure 7 .

 7 Figure 7. Gantt chart view of processes inside the SCM

Figure 8 .

 8 Figure 8. Evaluation of response time requirements

Figure 9 .

 9 Figure 9. Distribution of execution jitter (start and terminate) for task Com_Rx

Figure 10 .

 10 Figure 10. Violation of end-to-end latency requirement (Temperature Error) detected in the simulation

Figure 11 .

 11 Figure 11. Successful evaluation of end-to-end latency requirement (Temperature Error)

Figure 12 .

 12 Figure 12. End-to-end latency distribution for event chain (Temperature Error)

Figure 13 .

 13 Figure 13. Violation of end-to-end latency requirement (Analog Input Error)

Figure 14 .

 14 Figure 14. Successful evaluation of end-to-end latency requirement (Switched Analog Input Error)

Figure 15 .

 15 Figure 15. Simulated CPU load average for initial configuration

Figure 16 .

 16 Figure 16. Simulated CPU load average for final configuration after optimization

Figure 17 .

 17 Figure 17. Model-based timing simulation of AUTOSAR compliant systems

Table I .

 I SCHEDULING WITH OS COUNTER TICK OF 1MS

	Name	Type	Period	Deadline	Offset	Priority
			(µs)	(µs)	(µs)
	Torque_Manager	Task	1000	100	async	200
	Analog_Manager	Task	1000	500	0	102
	ASIC_Manager	Task	1000	1000	0	95
	Mode_Manager	Task	5000	5000	2000	70
	Com_Rx	Task	5000	5000	2000	50
	Com_Tx	Task	5000	5000	2000	45
	Temp_Manager	Task	10000	10000	4000	20
	Memory_Manager Task	10000	10000	9000	5
	Diagnosis	Task	10000	10000	8000	2

Table II .

 II ADJUSTED START OFFSETS FOR ASIC_Manager AND Com_Tx

	Name	Type	Period	Deadline	Offset	Priority
			(µs)	(µs)	(µs)
			. . .
	ASIC_Manager	Task	1000	1000	500	95
			. . .
	Com_Tx	Task	5000	5000	3500	45
			. . .
	The activation offsets for ASIC_Manager and Com_Tx
	were adjusted as shown in table II.

Table III .

 III ADJUSTED SCHEDULING WITH OS COUNTER TICK OF 500US

	Name	Type	Period	Deadline	Offset	Priority
			(µs)	(µs)	(µs)
	Torque_Manager	Task	1000	100	-	200
	Analog_Manager	Task	1000	500	0	102
	ASIC_Manager	Task	1000	1000	500	95
	Temp_Manager	Task	10000	10000	2000	71
	Mode_Manager	Task	5000	5000	2000	70
	Com_Rx	Task	5000	5000	2000	50
	Com_Tx	Task	5000	5000	3500	45
	Memory_Manager Task	10000	10000	9000	5
	Diagnosis	Task	10000	10000	8000	2

Note, that due to intellectual property rights of the companies involved in the development of the SCM, only anonymized and simplified versions of the original system information can be documented.

The worst-case response time determined for the ASIC_Manager task was lower than 500µs.

A context switch in an AUTOSAR OS with memory protection may consume several microseconds.

Depending on the safety and integrity level (SIL) standards like IEC 61508 or ISO 26262 for automotive require or at least recommend the usage of analysis and simulation tools for the verification of the dynamic architecture.