Julien Dardenne

Sébastien Valette

Nicolas Siauve
email: nicolas.siauve@univ-lyon1.fr

Rémy Prost

Medial Axis Approximation with Constrained Centroidal Voronoi Diagrams On Discrete Data

Keywords: Medial Axis, Discrete Data, Constrained Centroidal Voronoi Diagrams

HAL is

Introduction

In the last forty years, the Medial Axis (MA) has been a constant research topic. The MA of a shape provides a compact representation of its features. The MA has been proposed as a tool for shape analysis, surface reconstruction, animation control, mesh generation and many other applications [START_REF] Bonnassie | Shape description of threedimensional images based on medial axis[END_REF][START_REF] Chazal | A sampling theory for compact sets in euclidean space[END_REF][START_REF] Dellas | Knowledge-based extraction of control skeletons for animation[END_REF][START_REF] Jia | Stratified helix information of medial-axispoints matching for 3d model retrieval[END_REF]. A concise definition of the MA or skeleton in the smooth case was given by Blum [START_REF] Blum | A transformation for extracting new descriptors of form[END_REF], who postulated the well-known prairie fire (or grassfire) analogy [START_REF] Attali | Géométrie discrète et images numériques, chap. Représentation par axe médian[END_REF]. The MA also can be defined as the set of centres of maximal balls which can fit inside a shape boundary. In figure 1 (a), we consider the MA of the shape in the smooth case. The fire front starts at the same time at every point on the boundary of a compact set B, moving with constant speed into B, locally perpendicular to the boundary and the place where two or more fronts collide defines the medial axis. In figure 1 (b), noise was added to the original shape and its skeleton was computed. One could see that the MA is very sensitive to noise and small pertubations on the boundary introduces large "spikes" in the MA. The above definitions were formulated in smooth space. However, many of the applications that need MA approximation have discrete 3D datasets, such as those acquired using medical scanners. In discrete space, the definitions are analogous to the smooth case. In figure 1 (c), we proceed to the discrete case in adding to noise on the boundary shape. In the discrete case, with our approach the MA extraction is robust to noise (d) and the correct topology of the MA is found.

Contribution and Outline

This paper presents a discrete approach for approximate MA. This method is of completely discrete nature: it is especially designed for pixel or voxel data. It is based on a discrete definition of Constrained Centroidal Voronoi Diagram Figure 2 shows a summary of our approach. (a) shows the original shape. In (b), the boundary of the shape is detected. In (c), we construct the CCVD of the whole image, with the constraint that all the Voronoi sites lay on the shape boundary. The medial axis (d) is extracted from the VG by eliminating Voronoi edges intersecting the shape boundary and by filtering edges according to angle criterion.

The outline of this paper is as follows : In the next section, we review related works. Section 4 gives the preliminaries and definitions for this approach. In Section 5, we provide the details of the proposed approximation of MA definition and computation. In Section 6, we present the results of the algorithm and we compare our approach to others in the literature. Section 7 gives an exemple of application to mesh sizing function and we conclude in Section 8.

Related Works

In the following, we give a brief survey of approaches for MA extraction in the discrete or smooth case. This state of the art is far from being exhaustive due to the huge amount of existing methods. There are many approaches to compute the MA, but they can be broadly organised into three classes : distance transforms, thinning or morphological erosions and Voronoi approaches.

The distance functions, are based on the fact that the locus of the points of MA are coincidental with the singularities of a distance function to the boundary. A distance transform or distance field (D) is defined for each point x of a shape S as the smallest distance from that point to the boundary B S of the shape:

D(x) = min x∈B S , y∈S (d(x, y)) ( 1
)
where d is some distance metric. An appropriate distance metric (such as Euclidean or cityblock distance) is first used to calculate the distance transform of the shape. The local maxima of this distance function or the corresponding discontinuities in its derivatives are then detected, each of which indicates a point of MA [START_REF] Ge | On the generation of skeletons from discrete euclidean distance maps[END_REF]. In [START_REF] Coeurjolly | Optimal separable algorithms to compute the reverse euclidean distance transformation and discrete medial axis in arbitrary dimension[END_REF], Coeurjolly et al. present time optimal algorithms to extract the MA with the squared distance transform and the reverse Euclidean distance transformation. They explain the links between Euclidean Distance Transform and the construction of a VD.

Thinning, or morphological erosion, has been proposed to mimick Blum's grassfire formulation and operate by successively eroding points from the boundary of the object, while retaining the end points of line segments, until no more thinning is possible [START_REF] Ju | Computing a family of skeletons of volumetric models for shape description[END_REF]. All thinning algorithms operate in the discrete space. They have been used on pixel and voxel image data in the areas of pattern recognition and image processing. Recently, an implementation of the fire front propagation in the discrete volume was proposed in [START_REF] Quadros | 3d discrete skeleton generation by wave propagation on pr-octree for finite element mesh sizing[END_REF].

There are also many approaches based on Voronoi Diagrams (VD) in the smooth setting [START_REF] Miklos | Medial axis approximation from inner voronoi balls: a demo of the mesecina tool[END_REF].

Definition 1

Given an open set Ω of R a , and n different sites (or seeds) z i;i=0,1,...,n-1 , the Voronoi Diagram (or Voronoi Tesselation) can be defined as n distinct cells (or regions) C i such that:

C i = {w ∈ Ω |d(w, z i ) < d(w, z j ) j = 1, 2, . . . , n, j = i} ( 2
)
where d is a distance measure.

A survey of approaches for the construction of the medial axis (and Voronoi diagrams) is given by Sherbrooke et al. [START_REF] Sherbrooke | Computation of the medial axis transform of 3-d polyhedra[END_REF]. The MA is represented as a subset of the boundary of Voronoi cells defined within a compact set B by points on the boundary. The elements of MA are sets of points equidistant from at least two points on the boundary and their union represents a local symmetry axis of the shape. More specifically, it has been shown (for the 2D case in [START_REF] Brandt | Continuous skeleton computation by voronoi diagram[END_REF][START_REF] Fabbri | On voronoi diagrams and medial axes[END_REF] and for the 3D case in [START_REF] Dey | Approximating the medial axis from the voronoi diagram with a convergence guarantee[END_REF][START_REF] Amenta | The power crust[END_REF]) that, under appropriately chosen smoothness conditions and as the sampling rate increases, the vertices of the VD of a set of boundary points will converge to the exact MA. In the smooth case, approximating the MA from the VD in 3D has been attempted in the past. The VD is deduced from the Delaunay Triangulation and then, a filtering is applied to the VD to approximate the MA. Dey and Zhao [START_REF] Dey | Approximating the medial axis from the voronoi diagram with a convergence guarantee[END_REF] compute the subset of the Voronoi facets or edges and vertices located inside the surface and then filter out some Voronoi vertices and their incident elements according to some angle and ratio criteria.

In medical image processing, real image data from computer tomography, magnetic resonance, with large amount of voxels and noise, cause MA to be very dense and computation time to be expensive because they generate too many nodes and lines. There are two challenges to compute this approximation of MA :

-The MA is highly unstable with respect to small details of the shape. -Only a discrete approximation of the MA is known and its sampling is dependent of the distribution of the input points.

Preliminaries and Definitions

Discrete shapes are defined to be a finite subset of the pixels or voxels of a space graph. The faces, edges, and vertices are collectively called boundary elements of the shape. For clarity reasons, we explain our approach in two dimensions. An image (or volume) is transformed into a graph such that, for each pixel (or each voxel) a vertex is associated, and pixels (or each voxel) that are neighbors in the sampling grid are joined by an edge [START_REF] Kovalevsky | Finite topology as applied to image analysis[END_REF]. This graph is denoted by G = (V, E) and is called primal graph or neighborhood graph. Where V and E denote, the set of vertices, the set of edges, i.e. the set of unordered vertex pairs, respectively. The dual of this graph is the graph representing inter-pixel edges and inter-pixel vertices. This graph is denoted by G and is simply called dual graph.

The Discrete Voronoi Graph (DVG) is a graph of vertices and edges which are a subset of the CCVD. The vertices are the locus of points that have at least 3 pixels of different labels while the edges are the locus of points containing at least 2 pixels of different labels. In the discrete case, we call elements of the VG the boundary sub-edges incident to the pixels from the CCVD. There are a wide variety of edge detection algorithms in the literature, generally driven by neighbouring relationships.

We also can build a triangulation by dualizing the constructed diagram. There are a wide variety of algorithms available to build a Delaunay triangulation for a set of points in the smooth case. In fig. 3, an example of the relationship between Voronoi regions and Delaunay triangulation in two dimensions is given. The Voronoi sites Z i are joined by a Delaunay edge if their Voronoi regions are adjacent. E i, j is an element of the DVG.

Our Approach

This section describes the algorithm for constructing a MA approximation. Figure 4 provides an overview of this approach, consisting of three stages : the original model (a) is processed by our Constrained Centroidal Voronoi Diagram approach (b). The clusters anisotropy is measured by means of principal axis analysis (c). The DVG (d) is extracted from the CCVD following the neighbouring relationship. Finally, an approximation of the MA is created (f) by filtering the Voronoi element sets of the DVG (e).

Clustering algorithm

Our proposal is to construct the VD by a constrained clustering, where each cluster boundary potentialy represents a subset of the MA. The performance of the MA approximation approaches is usually dramatically reduced if the input shape is noisy. To address this problem, we propose to filter by clustering and then subsample the boundary B of the shape, while constructing the VD in the image.

Centroidal Voronoi Diagram

In this subsection, we make an overview of Centroidal Voronoi Diagrams (CVDs). The work presented here is closely related to the work of Valette et al. [START_REF] Valette | Generic remeshing of 3d triangular meshes with metric-dependent discrete voronoi diagrams[END_REF].

A CVD is a Voronoi diagram where each Voronoi site z i is also the mass centroid of its Voronoi region :

z i = C i x.ρ(x)dx C i ρ(x)dx (3)
where ρ(x) is a density function. CVD minimize the energy given as:

E = n ∑ i=1 C i ρ(x) x -z i 2 dx (4)
Practically, a centroidal distribution of points is useful because the points are well-spaced. CVDs optimize the compactness of the created Voronoi regions and can be done, using algorithms such as k-means or Lloyd relaxations.

Constrained Centroidal Voronoi Diagram

We want to construct a CVD on a discrete input. Our approach is based on partitioning (clustering) the discrete input in a variational framework, which groups discrete cells into K clusters through the minimization of the total intracluster variance. Our algorithm is based on the construction of a partitioning which minimizes equation (4). It is possible to efficiently minimize with an iterative algorithm that updates the clustering according to tests on the boundaries between the different clusters. Here, we choose ρ(x) to be uniform. The shape boundary is used for initial clustering. Then, we define the digital shape as the set of all vertices labelled as boundary or not boundary. At each cluster C i is associated a site. The major difference with [START_REF] Valette | Generic remeshing of 3d triangular meshes with metric-dependent discrete voronoi diagrams[END_REF] is that the site is defined as the center of mass of only the boundary vertices contained in the cluster. We also add an additional constraint to our clustering algorithm : to ensure diagram conformity, a cluster must always contain at least one boundary vertex. We assume that the subsampling factor of this clustering is high, i.e the ratio between the number of original boundary vertices and the number of sites of the VD is high. We then have to evaluate of the optimal number of clusters. If we have few clusters, it is difficult to define the shape of the object. In the opposite case, using many clusters, "spikes" appears on the medial axis. Figure 4 shows an example of constrained clustering on a shape with 400 clusters.

We now define the various graphs extracted from the CVD. The motivation behind this dualisation is a good approximation of the boundary Voronoi cells for a better localization of the MA of the discrete shape. During the next step of the method, the constructed CCVD should be transformed into a DVG and the Delaunay Triangulation can be computed.

Filtering conditions

In this subsection, we describe the filtering algorithm. It is well-known that the MA is very sensitive to small perturbation of the shape boundary and many filtering methods have been proposed to remove bad components associated with noise or other artifacts. [START_REF] Chazal | The lambda medial-axis[END_REF][START_REF] Hulin | Chordal axis on weighted distance transforms[END_REF] and [START_REF] Attali | Stability and computation of medial axes: a state of the art report[END_REF] give a state of art of these approaches in the smooth case. Our aim is to approximate the MA with a subset of Voronoi edges or facets. i.e to decide if a given vertex set belongs or not to the MA. Our algorithm uses two criteria to select the Voronoi elements from the DVG.

Mesuring clusters anisotropy and principal axes

Following the general observation that the Voronoi cells are elongated along the normal direction at the boundary points [START_REF] Amenta | Surface reconstruction by voronoi filtering[END_REF], our algorithm measures the anisotropy of each cluster C i in order to have a confidence measure on the normal estimation. For each C i , we compute its covariance matrix M i and deduce the local cluster anisotropy from the eigenvalues of M i [START_REF] Alliez | Voronoi-based variational reconstruction of unoriented point sets[END_REF]. M i can be viewed as a 3 x 3 tensor. The eigenvalues and eigenvectors of this symmetric and positive definite matrix correspond to the axes lengths and directions of an ellipsoid, respectively. We can deduce the principal axis from the eigenvector associated to the highest eigenvalue of M i . The fractional anisotropy (FA i ) allows to compute the local anisotropy of each C i [START_REF] Basser | Microstructural and physiological features of tissues elucidated by quantitative-diffusion-tensor mri[END_REF] :

FA i = √ 3 √ 2 (Λ 1 i -Λ i ) 2 + (Λ 2 i -Λ i ) 2 + (Λ 3 i -Λ i ) 2 (Λ 1 i 2 + Λ 2 i 2 + Λ 3 i 2 ) (5)
with :

Λ i = (Λ 1 i + Λ 2 i + Λ 3 i ) 3 ( 6
)
where Λ j, j=1,2,3 i are the eigenvalues of M i , with

Λ 1 i > Λ 2 i > Λ 3 i . One note that : 0 ≤ FA i ≤ 1 (7)
The FA i index is zero in a perfect isotropic case (a sphere) and 1 in the anisotropic case (the hypothetical case of an infinite cylinder). Increasing FA i values indicate a higher tensor anisotropy. Figure 5 (left) shows a cut-view of the CCVD of an empty box (for wich the cube boundary defines the shape boundary). In figure 5 (right), each cluster is replaced by its equivalent ellipsoid. The ellipsoids elongation clearly depict the cluster anisotropy.

Sometimes, a cluster is mostly isotropic (i.e FA i is close to 0) and its first principal axis does not approximate the normal direction. We detect these cases with the following test :

d(C i , z i ) > α .Λ 1 i (8)
where Λ 1 i is the principal eigenvalue of C i , C i is its barycenter and α is a arbitrary constant (in our experiments, we set α = 0.6). Whenever this test is true for a cluster, we estimate its normal direction as :

-→ N i = --→ C i z i --→ C i z i (9)
In figure 6 (middle), the principal axis (encircled) gives a bad approximation of the normal direction. Then, we compute the normal direction as above and obtain a good approximation of the normal direction (right).

Pole condition

Amenta et al. were the first to propose the definition of poles [START_REF] Amenta | A new voronoi-based surface reconstruction algorithm[END_REF] and proposed the Powercrust algorithm [START_REF] Amenta | The power crust[END_REF] to construct manifold triangulations of three-dimensional points. When the boundary B is sufficiently dense, the Powercrust is guaranteed to produce a geometrically and topologically correct approximation. We recall that the set of poles is a subset of Voronoi vertices. In 2D, all Voronoi vertices converge to the medial axis. In 3D, some Voronoi vertices may be far from the medial axis but poles are guaranteed to converge to the medial axis. Each boundary-point is associated with two poles, denoted by p i+ and p i-, respectively. These two poles are the farthest Voronoi vertices of Voronoi cell. The boundary B also is divided in two sets of poles: inside and outside poles. The definition of poles plays an important role in normals approximation. When B is a sufficiently densely sampled, the Voronoi cells appear naturally anisotropic, and are approximately perpendicular to the boundary of the shape. Our approach is based on an estimate of the vertices position with respect to the shape boundary and the estimated normal direction. We define the discrete element E i, j as the set of vertices adjacent to the clusters C i and C j . The critical part consists in tagging each vertex of each element as positive or negative. For each element E i, j , we define an operator f (i, j) as follows:

f (i, j) =
i when FA i > FA j j when FA j > FA i [START_REF] Attali | Stability and computation of medial axes: a state of the art report[END_REF] We denote its site as z f (i, j) and its estimated principal axis N f (i, j) . This allows a good approximation of the normal direction N f (i, j) to the shape boundary.

In this regard, a vertex candidate v ∈ E i, j will be tagged as negative or positive depending on the sign of S f (i, j) (v) defined as :

S f (i, j) (v) = < ----→ z f (i, j) v, ---→ N f (i, j) > (11)
S f (i, j) (v) then provides an information on v with respect to the boundary shape. We then define the first filtering condition as follows :

E i, j ∈ MA i f S f (i, j) (v 1 ).S f (i, j) (v 2 ) ≥ 0, (12)
∀(v 1 , v 2 ) ∈ (E i, j ⊗ E i, j )
If an element E i, j contains vertices v for which S f (i, j) (v) is not always of the same sign, it can be deduced that this element crosses the shape boundary, and therefore is not considered as MA element. In the opposite case, all elements with the same sign belongs to the same side of the boundary. Howewer, we do not know if they are inside or outside of the shape. Figure 7 shows two examples where E 1,2 is rejected for inclusion in the MA, and E 1,3 is considered as a part of the MA.

Our objective is to extract a simplified MA. However, in some cases, we see some "spikes" appearing on the MA. Then we use an angle condition to filter out some spikes at the poles condition. Fig. 7 A candidate vertex v ∈ E 1,3 ; E 1,3 does not cross the shape boundary as its vertices are all tagged same way; E 1,2 crosses the shape boundary as its vertices are not always tagged wich the same sign. As a consequence E 1,3 ∈ MA and E 1,2 / ∈ MA;

Angle condition

An angle condition can be used to remove points from straight edges to eliminate spikes in the MA. Dey and Zhao [START_REF] Dey | Approximating the medial axis from the voronoi diagram with a convergence guarantee[END_REF] use a criteria on a angle condition to retain faces from the VD of a set of boudary points. They consider the angle between an approximate of the normal direction at the boundary points and a Delaunay edge (dual to a Voronoi face). If that angle is small, the Voronoi face is kept as a part of the MA.

Our method is based on the direct construction of the VG in the discrete space. Therefore, we consider the angle between the normal of an element of the VG (dual to a Delaunay edge) and the normal direction at the shape boundary wich is estimated by the principal axis associated with each surrounding cluster. For each boundary element candidate E i, j , we associate an angle Θ i, j . Θ i, j = N f (i, j) , N i, j [START_REF] Chazal | A sampling theory for compact sets in euclidean space[END_REF] The approximation of the angle Θ i, j for a MA element re- quires both the knowledge of the principal axis N f (i, j) of the neighbouring cluster having the greatest anisotropy and the estimated normal direction of E i, j , noted N i, j . The scalar product is useful when you need to calculate the angle between two vectors. Then, we define the angle filtering condition as :

E i, j ∈ MA i f A i, j > γ , Λ 1 f (i, j) > β . Λ 3 i, j (14)
with

A i, j = | < N f (i, j) , N i, j > | (15)
where Λ 1 f (i, j) and Λ 3 i, j are the largest eigenvalue of C f (i, j) and the minimal eigenvalue of E i, j , respectively, and γ and β are arbitrary. (in our experiments, we set γ = 0.8 and β = 0.7) Figure 8 shows an illustative example where A i, j is computed.

Results

The proposed algorithms has been tested with several discrete data. These algorithms were implemented in C++ using the VTK library.

Fig. 8 The angle condition : the angle between N f [START_REF] Bonnassie | Shape description of threedimensional images based on medial axis[END_REF][START_REF] Basser | Microstructural and physiological features of tissues elucidated by quantitative-diffusion-tensor mri[END_REF] and N 1,4 has to be within a given range, or the element E 1,4 will be filtered out from the MA. Fig. 9 Three slices of a volume representing a heart and their respective Medial Axis Fig. 10 Comparison between our approach and the RDMA approach [START_REF] Coeurjolly | Optimal separable algorithms to compute the reverse euclidean distance transformation and discrete medial axis in arbitrary dimension[END_REF]. Left : original shape. Middle : RDMA; Right : our approach Figure 9 shows the results obtained on three different slices of a volume representing a human heart.

Figure 10 shows comparative results between our approach and the RDMA approach [START_REF] Coeurjolly | Optimal separable algorithms to compute the reverse euclidean distance transformation and discrete medial axis in arbitrary dimension[END_REF]. The first column is the original shape. The second column are the results obtained with RDMA. The third column was obtained with our approach. The first row shows a simple shape with sharp corners. The second row shows a slice of a human heart. The third row shows the same human heart but with noise on the shape boundaries. One can clearly see that in our approach the MA is smooth and connex for the three cases.

Application to sizing function for mesh generation

Mesh sizing is one important aspect of the mesh generation problem.The size of the elements may be either a consequence of the meshing algorithm when no sizing constraints are provided as input, or may be explicitly controlled by the user or by the physical simulation carried on over the mesh. Several techniques have been proposed for automatic generations of mesh size function. Quadros and al. [START_REF] Quadros | 3d discrete skeleton generation by wave propagation on pr-octree for finite element mesh sizing[END_REF] used medial axis generation over domain boundaries to construct mesh sizing functions. For our experimentations, we used the definition of Alliez et al. [START_REF] Alliez | Variational tetrahedral meshing[END_REF] who proposed a sizing function µ(x) which provides the element size at each point x. Figures 11 and12 show MA approximations of the letters "CGI" and a "bird" shape. One can see the influence of the MA then mesh sizing, as meshing density is higher in thin regions (the bird nozzle and tail regions).

Figure 13 shows a similar process for the 3D volume containing a human heart.

Our experiments support that both angle and dual conditions together produce a good approximation to the actual MA. Furthermore, the algorithm showed strong resistance against noise and boundary distorsion.

Conclusions

In this paper, we have presented an approach that approximates the medial axis for pixel or voxel objects. This approach is based on the Voronoi graph computed from a set of nodes distributed across the boundary. One of the key aspects is its completely discrete nature. Experimental results have shown that the method creates Medial Axis approximations which are robust to noise, and very suitable for mesh generation. Future work may include robust filtering of the MA elements, in order to increase the robustness of the approach.

Fig. 2

 2 Fig. 2 From left to right : the shape in the primal graph (a); the shape boundary in the dual graph (b); its Constrained Centroidal Voronoi diagram (c); approximation of Medial Axis after filtering (d)

Fig. 3

 3 Fig. 3 Left: Delaunay Triangulation and its dual Voronoi Diagram in the smooth case; Middle: similar configuration in the discrete setting; Right: the DVG

Fig. 4

 4 Fig. 4 The original model (a) is processed by our Constrained Centroidal Voronoi Diagram approach (b). The clusters anisotropy is measured by means of principal components analysis (c). The DVG (d) is extracted from the CCVD following the neighbouring relationship. Finally, an approximation of MA is created by filtering the Voronoi element sets of the DVG (e and f).

Fig. 5

 5 Fig. 5 Left: a cut of the Constrained Centroidal Voronoi Diagram of emty box with 1000 Voronoi cells. Right: each cluster is replaced by its equivalent ellipsoid. The FA i shows the local anisotropy of each cluster C i .

Fig. 6

 6 Fig. 6 Left: Centroidal Voronoi Diagram of the portion of the figure 4. Middle : estimation of principal axis for each cluster. Right: after correction, the encircled direction is now correctly estimated.

Fig. 11

 11 Fig. 11 On the top, approximation of the Medial Axis. On the bottom, 2D Delaunay triangulation with 2000 vertices.

Fig. 12

 12 Fig. 12 Top : a shape (left) and its medial axis (right). Bottom : On the left, sizing function on the MA in 3D. The colors represent the sizing values. On the right, mesh generated with respect to the sizing function.

Fig. 13

 13 Fig. 13 Left : a volume representing a human heart. Middle : its Medial Axis. Right: mesh generated with respect to the sizing function (10000 vertices).

Acknowledgements

The Human heart data are courtsey of Dr Patrick Clarysse from CREATIS at Lyon. This work was supported in part by the BioRFMod project (ANR-06-JCJC-0124-01) and the Région Rhône Alpes Cluster 2 ISLE, PP3, subproject I3M: Imagerie Médicale et Modélisation Multiéchelles : du petit animal à l'Homme.


Benjamin Fontan

Emmanuelle Rozet

Eric Jenn

Efficient Management of Requirements in Very Large Scale Development Projects in Avionics

Keywords: Requirement engineering, meta-modeling, certified embedded systems. I

Requirement engineering is a crucial part of development, in particular in terms of cost. This paper gives an overview of the problems we faced during the development of a very large avionics application, presents the solutions we have adopted, and the gains we observed.

INTRODUCTION

The problems related to the development of large scale software-intensive systems are definitely not new. Some efficient techniques have been -and are still being -proposed to cure the "software crisis" diagnosed in the late 60's. In the domain of airborne avionics systems, prevention used to be the primary means to avoid being contaminated: problems and solutions are kept as simple as possible, predictability is enforced, and partitioning and segregation of functions are common practices. However, if a small increase of functional complexity can still be worked out this way thanks to a proportional increase of resources, this approach does not scale. We faced this discontinuity during the development of our new Flight Management System: the problem is functionally very complex, the development teams are very large and distributed over multiple internal and external entities, the number of development artifacts is huge, etc. In simple terms: solutions that used to work smoothly for our previous developments simply don't work any more. Requirement management, or better, requirement engineering, is one particular practice that need to be adapted in this new context. In this paper, we show how we tackled this complexity and present some of the lessons learnt. The paper is organized as follows: Section II gives an overview of the context and identifies the main challenges regarding requirement management, Section III shows how we modeled the problem, Section IV gives some details about how the model has been exploited and implemented in tools, Section V gives an overview of the tool suite, and Section VI concludes the paper.

II. STATEMENT OF THE PROBLEM

A. The context Roughly speaking, a Flight Management System (FMS) provides the crew with means (in particular, interaction means) to define and manage flight plans, to predict the trajectory of the aircraft in the time, space and mass dimensions. It also pro-vides the Flight Guidance System (the autopilot) with data to guide the aircraft along the predicted trajectory. With respect to other airborne functions such as the Flight Warning function or the Braking and Steering function, the FMS is "unusual". It has to build and manage large, complex and dynamic data sets, it has to react to asynchronous events coming from the Man Machine Interface in a timely manner, and, finally, it has to perform some "low level" command and control functions such as guiding the aircraft. It is also unusual in terms of size. To give a rough idea, the baseline of our latest FMS contains around 15000 system requirements leading to more than 21000 high level software requirements (HLR), all this being implemented by more than 1000KLOC of Ada code. The organization is dimensioned adequately: it involves more than 300 system, software, and integration engineers located at multiple locations worldwide. The system is developed at DAL B according to [START_REF] Rtca/Eurocae | Software Considerations in Airborne Systems and Equipment Certification[END_REF].

B. The Challenges

In this context, several organizational and technical challenges have to be faced. From an organizational perspective, the main challenges are  To manage the fragmentation, distribution and concurrency of activities  To focus the work of engineers on their main tasks. From a technical perspective, the main challenges are  To reuse development artifacts from one version of a product to another, from one product to another in the same product line, or even from one product to another in another product line.  To automate activities using tools while masking the internals of those tools and make their usage as simple as possible. All these challenges concern the production, communication, maintenance of any development artifact. Here, we focus on requirement artifacts, i.e., the "identifiable element[s] of a function specification that can be validated and against which an implementation can be verified" [START_REF] Sae | Guidelines for Development of Civil Aircraft and Systems, Aerospace Recommended Practice[END_REF].

The set of requirements covers all levels and phases of a system development, from the user-level to the software and hardware levels, from inception to validation. It covers all aspects: technical, functional, and nonfunctional (performance, reliability, etc.). As any other artifact in a development process, requirements are engineered: they are elicited, documented, validated and negotiated, and managed. The quality of this engineering process is crucial: as illustrated on Fig. 1, a defect in a requirement propagates throughout the development process and its impact on the overall cost is roughly amplified by 10 from one stage to the next one! Fig. 1. Requirements versus cost in a typical development process

1) Manage fragmentation and distribution of activities

A large scale development usually means the "distribution" of people over multiple activities, teams, industrial sites, industrial organizations, countries, and possibly "cultures". One challenge is to ensure that these people understand each other, and all share and comply with a common process. Activities shall be performed homogeneously throughout time and space. In previous developments, it was not uncommon for people in the same development team to play multiple roles and perform multiple engineering activities (specification, architectural design, coding,…) as far as this ubiquity was deemed acceptable with respect to the development standards. On large developments, teams are more specialized and dedicated to some well-defined activity (definition of the logical architecture, definition of the physical architecture, coding, etc.). As the size of the development team gets larger (around 350 at peak for the FMS) and the duration of the development phase gets longer (more than 10 years for the FMS), turn-over increases dramatically. So, the transmission of information from individual to individual, from document to individual becomes crucial. All these new conditions benefit from a better formalization of information. Fragmentation and distribution of activities open the door to concurrency. Indeed, in order to comply with shorter development delays, the sequential organization of activities is now replaced by a highly concurrent set of processes where multiple versions of the same product, multiple components, etc. are developed in parallel. Activities are "pipelined" in order to optimize the usage of human resources. This "pipelining" imposes new constraints to all development activities, including requirement management.

2) Focus on developers tasks, mask complexity of tools

An engineer is usually supposed to achieve one main task making the best usage of his/her skills. However, in practice this task is often precedeed by or accompanied by some low added value but necessary activities of data extraction, impact "analysis", or coverage "analysis". Complexity of languages and tools is another problem that may divert engineers from this "main" task. Indeed, to manage a complex and large development, one has usually no choice but to use commercial means (e.g., configuration management tools) that are generic and powerful enough to deal with various problems but which complexity is often much too apparent to the end-user. Generally speaking, generic tools and notations have usually one big counterpart: if they are able to simplify the resolution of any complex problems, they may well make the resolution of a simple problem more complex. In practice, people need to be accompanied and left with actions and decisions that really take benefits from they skills. We will see later how this applies to requirement management.

3) Enhance re-usability, automate activities

A large scale development usually means a large set of artifacts that have to be managed. On the FMS, for instance, this set contains more than 1 500 000 artifacts for which we have  To guarantee the integrity and the consistency of issues, review statuses and allocations  To perform changes impact analysis  To generate progress and quality metrics with a high level of reproducibility and reliability.

Traceability is a means to ensure consistency and to support change impact analysis. It is defined as "the evidence of an association between items, such as between process outputs, between an output and its originating process, or between a requirement and its implementation." or a "discernible association between two or more logical entities such as requirement, system elements, verification or tasks" [START_REF]System Engineering Handbook[END_REF]. Traceability ensures and demonstrates the complete control over the transformation process. It ensures that no user requirement "disappears" and, conversely, that no artifact "appears" in the process without reason. Ensuring traceability is mandatory for certification. Furthermore, we also need to improve the precision and accuracy of quotations and reduce bidding delays. This requires a capability to identify all key requirements (so-called "critical requirement" for the design). All these activities shall be performed continuously, quickly with as less human interventions as possible, throughout the development process, with short delays. Finally, in the context of certification, we must:  Identify each version of each artifact/document  Prove that orphan requirements (so-called derived requirements) are justified and have been taken into account in safety analysis  Prove that all requirements have been verified (analyzed, tested, etc.)  Prove that all requirements in a delivered baseline have been reviewed and comply with the development standards.

In the agile context, project stakeholders need to manage systematically/daily requirement impact analysis process in a large scale project to enable:  The earliest detection and correction of defects  The generation of metrics on a daily basis (requirement stability, reviews, …)  The automatic triggering on issue of requirements and automatic review rules update (compliance rules, changes justification rules, etc)  The efficient validation/negotiation process of requirements with several stakeholders (system designer, system integrator, hardware designer, software designer …). These activities improve reactivity with daily requirement integration, and competitiveness by cost reduction of review with incremental baseline and reviews.

III. FROM THE CHALLENGES TO THE REQUIREMENT

METAMODEL

All previous challenges share one common need: to be able to define precisely and document the structure and the semantics of the development artifacts, and their relations. The objective is (i) to enhance the overall communication process of development artifacts, (ii) to facilitate their automatic processing including production, transformation, navigation, verification. A well-defined structure is a prerequisite for the mechanized processing of artifacts and it ensures that any developer will find the expected information where he/she expects it to be, in the format in which he/she expects it to be. Finally, a welldefined semantics prevents misinterpretations, and facilitate maintenance. In modern parlance, formalization of structural and semantic definition is expressed via a metamodel. For requirement engineering and management, the metamodel usually carry the following concepts:  Artifact, i.e., an element that is identified throughout the development cycle.  Semantics links between artifacts (e.g., "verifies", "satisfies" relations)  Issue and Review status  Baseline, i.e., a well-defined set of formal objects at the same level of specification (usually merged in formal documents such as Software Requirement Specifications, Software Design Documents, etc.). Once instantiated in a Tooled Up Process, one shall ensure and maintain the consistency of the model, including the correctness of semantic links with respect to the artifacts issues included in a baseline.

A. Basic concepts used in this metamodel

The set of formal artifact contains:

 Requirements (REQ) possibly specialized into a functional requirements, capability requirements, etc.  Integration Verification/Validation Procedures (IVVP) including inspections, analysis, demonstrations, or tests [START_REF]System Engineering Handbook[END_REF] with their status (i.e, "written", "to be run", "OK", "KO", etc.).  Configuration Items (CI) which corresponds to the logical and physical [START_REF] Rtca/Eurocae | Software Considerations in Airborne Systems and Equipment Certification[END_REF]components of the project. Traceability between REQs and CIs enables to map requirement and architectural models.

Semantics relations are defined over the set of artifacts [START_REF] Rtca/Eurocae | Software Considerations in Airborne Systems and Equipment Certification[END_REF]:  The allocated by relation between configuration items and requirements in order to build allocation matrices.  The satisfies relation (covering refinement and factorization) between requirement across the successive development phases in order to build traceability matrices  The verifies relation between test items and requirement (e.g., a IVVP "verifies" a REQ) in order to build coverage matrices

B. Enhance the Requirement Engineering metamodel

In the FMS project, two formal artifacts have been added to the usual requirements metamodel in order to complete the traceability process:  Methods, which represent all code included in the embedded software. A Method artifact implements a Software Design Requirement (Low Level Requirement collected in the Software Design Document (SDD)  Flows, which represents all internal and external control and data flows. Requirement artifacts (System, Software and Hardware) consume or produce a Flow artifact. Fig. 2 presents the relationships between several formal artifacts. The metamodel also distinguishes two kinds of Issue and Review attributes:  Internal Issue/review Status (those depicted in Fig. 3)  Compliance Issue/Review Status They will be described in more details the final version of the paper.

IV. FROM THE REQUIREMENT METAMODEL THE TOOL UP PROCES

The metamodel and the exploiting tools have been implemented using proprietary and off-the-shelf tools. IBM DOORS [START_REF][END_REF] and IBM RMF [START_REF]Requirement Management Framework[END_REF] have been used to manage traceability, artifact (Requirements, Configuration Items, IVV Procedures), and baselines.

Proprietary tools have been developed to manage  Additional artifacts (Flows, Methods, IVV Results)  Automatic Issue and Review mechanisms (VACRM and IVVCRM)

A. Instanciation of Requirement Engineering metamodel in the DOORS FMS project.

Fig. 4 depicts the instantiation of the metamodel in the DO178-B DAL B context. Fig. 5 illustrates the benefits of this metamodel instantiation. It shows one example of traceability and coverage views from system requirements and test to software methods and units test. This view is deployed for each SRS of the FMS system Configuration Items, over more than 127 documents.

B. Instanciation of the Issue and Review metamodel

The automatic triggering of issues and reviews relies on the metamodel instantiation depicted in Fig. 3. A preview of the FMS process tool suite is shown in the Fig. 6 and7.

Fig. 6 shows how the tool in charge of internal modification detection manages the evolution of internal issue and review attributes in the nominal case and in the derogation case. The following figures illustrate some parts of our tool-up process including the management of concurrent development activities (Fig. 8), the analysis of baselines (Fig. 9), the review triggering mechanism (Fig. 10), and the automatic generation of a project progress overview (Fig. 11).

Fig. 8 describes how change requests are managed: whenever the software needs to be modified to take into account a problem report or an evolution request, a parallel development stream is created. Once the modifications are complete and validated, it is possible to rebase from the original reference stream, resolve potential conflicts, and then deliver those modifications. Attributes management is entirely based on the data model introduced in the previous section. The reference module is then versioned and baselined in order to be delivered. With respect to most existing descriptions of requirement management processes (e.g., [START_REF] Hoffman | Requirement for Requirement Management Tool[END_REF]), our paper depicts something that has been actually applied on a very large development. With respect to other requirement metamodels such as ReqIf [START_REF] Omg | Requirement Interchange Format (ReqIF), Object Management Group[END_REF] for instance, which is focused on the structure of requirements and on the way they are exchanged, our metamodel also covers the relation between the requirements and the other development artifacts. Furthermore, ReqIf or Eclipse RMF [START_REF]Eclipse RMF[END_REF] is still to be applied on a large scale project. Our metamodel and associated tools and processes have been used by more than 300 people for more than 2 years. Finally, the two major improvements are worth being mentioned:  The automation of some crucial part of the requirement management process has strongly reduced the time that the users spend interacting with tools, and the set of intermediate pre/post check or reviews have been drastically reduced.  The automation of the reviews has facilitated the implementation of a continuous integration process (a 30% gain of time during reviews activities), and it is now possible to monitor in real time reviews activities.

Fig. 2 .

 2 Fig. 2. Formal artifacts interaction metamodelC. Define issue consistency to improve impact analysis and automated reviews mechanismsAs depicted on Fig.3, a formal artifact is composed of several attributes:  Description attributes that describe the artifact itself (i.e., Text, equation, UML diagram, allocated item descrip-

Fig. 3 .

 3 Fig. 3. Internal Issue and Review interaction metamodel

Fig. 4 .Fig. 5 .

 45 Fig. 4. Metamodel instantiation in the DO 178 C context

Fig. 7 Fig. 6 .Fig. 7 .

 767 Fig. 7 describes how the tool in charge of compliance change checks the compliance issue and update compliance reviews attributes in nominal case.

Fig. 9 Fig. 10 (Fig. 10 .

 91010 Fig. 9 describes one way to analyze a new input baseline. The tool enables to launch a comparison between two baselines, given a subset of the official data model attributes list.A synthesis of created/modified/deleted items is provided, and a detailed difference is given in rich text format for all items. The possibility to choose a subset of attributes enables to


Christoph Roth
email: christoph.roth@kit.edu

Harald Bucher
email: harald.bucher@kit.edu

Alisson Brito+

Oliver Sander

Juergen Becker

A Simulation Tool Chain for Investigating Future V2X-based Automotive E/E Architectures

Keywords: Co-Simulation, Vehicle-to-X, E/E-Architecture

I. INTRODUCTION

Today, the electric/electronic (E/E) architecture of modern cars is a distributed network of embedded systems, consisting of several bus systems, dozens of electronic control units (ECUs) and hundreds of sensors and actuators. To this system, high requirements regarding determinism are imposed which form the basis for safe operation in any conceivable driving situation. Because of that, the timing behavior of single components as well as communication within the vehicle is widely statically determined a priori and the E/E architecture is realized as a nearly fully closed system.

Due to the evermore rising number of functions, current E/E architectures are more and more a vulnerable source for faults and a barrier to innovation [START_REF] Buckl | The software car: Building ict architectures for future electric vehicles[END_REF]. This situation is aggravated by the integration of new technologies like Vehicle-to-X Communication (V2XC) which form the basis for a large number of future services and applications. For these, it is no longer sufficient to only consider data that is available locally. The majority of applications rather will rely on information that originates from most diverse data sources. E/E architectures in the first approximation need to be "opened" by means of an additional radio interface located e.g. at an ECU, which enables communication with other vehicles or infrastructure. This not least increases potential for non-deterministic disturbance of safety-critical functions or malicious attacks of the internal communication network [START_REF] Glas | Car-to-car communication security on reconfigurable hardware[END_REF].

In order to overcome the limitations of current E/E architectures, application of new design principles like more encapsulation, standardization and centralization as well as a fundamental reconsideration of the fragmented development process is necessary [START_REF] Buckl | The software car: Building ict architectures for future electric vehicles[END_REF]. Up to the present day, both, function and architecture development are most often separately running tasks. As a result, errors are often only discovered in the integration phase. This fact can become an extremely time consuming and expensive endavor. Principles of platformbased design (PBD) are a promising solution in order to cope with this problem [START_REF] Sangiovanni-Vincentelli | Embedded system design for automotive applications[END_REF] since function and architecture are separated. This enables a flexible mapping of function to architecture and its validation already in early phases of development. The result is an increase of reliability and a reduction of development cost by avoiding additional design cycles [START_REF] Sangiovanni-Vincentelli | Embedded system design for automotive applications[END_REF].

Within this context, we propose a novel extensible tool chain that targets facilitation of exploration, validation and verification of future V2X-based automotive E/E architectures. Such systems are heterogeneous by nature. Hence, a design framework is necessary that supports managing heterogeneous model composition for representing data as well as control flow between models. The proposed tool chain is made up of a heterogeneous design tool called Ptolemy II (PtII) [START_REF] Eker | Taming heterogeneity -the Ptolemy approach[END_REF] and a simulation middleware based on the High Level Architecture (HLA) [START_REF]IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)[END_REF]. A possible framework architecture that can be developed by means of the tool chain is illustrated in Fig. 1. The HLA enables distributed co-simulation with domainspecific simulators like (parallel) SystemC [START_REF]IEEE Standard for Standard SystemC Language Reference Manual[END_REF] [START_REF] Roth | Improving parallel mpsoc simulation performance by exploiting dynamic routing delay prediction[END_REF] (hardware/software), OMNET++ [START_REF] Varga | An overview of the omnet++ simulation environment[END_REF] (network), Veins/SUMO [START_REF] Sommer | Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis[END_REF], Microsim [START_REF] Treiber | Microsimulation of road traffic flow[END_REF] (traffic) or co-emulation with real hardware/software components [START_REF] Roth | Efficient execution of networked mpsoc models by exploiting multiple platform levels[END_REF]. PtII is the starting point of the design process. Its task within the tool chain is twofold: I) The capabilities for explicit meta-modeling using an abstract syntax of clustered graphs [START_REF] Liu | The ptolemy ii framework for visual languages[END_REF] serve as user interface for support of tool integration and configuration of control and data flow interaction via HLA, II) due to its inherent heterogeneity and model composition properties PtII serves as central design tool for performing architectural exploration and validation and verification.

Heterogeneous Modeling Tool (Ptolemy II)

II. FUNDAMENTALS

In PtII, the basic building block of a system description is an actor. Actors are concurrent components that communicate through ports and relations. They can be atomic or composite. An atomic actor is at the bottom of the hierarchy. A composite actor allows hierarchical nesting of actors. Both, atomic and composite actors are executable following specific execution semantics, also known as models of computation (MoC) [START_REF] Eker | Taming heterogeneity -the Ptolemy approach[END_REF].

The MoC within a composite actor is determined by a director. In the discrete event (DE) MoC, interaction between actors is modeled by events, representing some instantaneous action during simulation time. DE simulations are particularly suitable for modeling discrete systems like e.g. digital hardware or communication networks. SystemC, OMNET++, SUMO or Microsim are examples of DE simulators. Beside DE there exist various other MoCs like continuous time (CT) which is suitable for modeling analogue components like sensors, or process networks (PN) which are often used for modeling data flow applications.

The HLA is an IEEE standard [START_REF]IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)[END_REF] since 2000. It was originally defined by the Defense Modeling and Simulation Office (DMSO) for the U.S. Department of Defense. Its original field of application are military training simulations. The HLA is a generic software architecture combining all the components necessary for Parallel Discrete Event Simulation (PDES). In HLA terminology the logical representation of an interconnection of different simulators is called a federation and includes multiple simulators called federates. Federates connect via ambassadors to a runtime infrastructure (RTI). The RTI implements services defined by the HLA standard like time management or data distribution management. A RTI can possibly run several independent logical federations in parallel. Also part of the HLA standard is the so called Object Model Template (OMT) which defines the format and syntax of HLA object models including object/interaction classes attributes, parameters and datatypes but not their content. The OMT allows to define Federation Object Models (FOM) and Simulation Object Models (SOM). The FOM contains properties of a whole federation. The SOM contains properties of a single federate.The HLA implementation used in this work is [START_REF] Noulard | CERTI, an Open Source RTI, why and how[END_REF].

III. SIMULATION PLATFORM LIBRARY

The so called Simulation Platform Library (SPLib) forms the basis for contruction kit like composition of distributed simulation tools. The SPLib applied within this work is an extended version of the one described in [START_REF] Roth | Efficient execution of networked mpsoc models by exploiting multiple platform levels[END_REF]. It provides a set of classes that abstract from the lower level HLA ambassador interface classes. Its task is to provide a contract between HLA and the simulation tool that is to be integrated in terms of data flow and interaction behavior between both. Fig. 2 The Federate class aggregates all other core classes. The ToolAdaptor class establishes a link from a simulation tool to the data model and the behavioral metamodels of the SPLib. These are given by the ObjectModel (OM) and the BehavioralInterfaceModel (BIM) classes. The ToolAdaptor provides high-level control flow related methods that are to be called by the simulation tool. Beside that, it encapsulates instances of IOSocket which are used for establishing data flow connections to the simulation tool. IOSockets are equipped with a queue that allows buffering incoming HLA reflections. On the reverse side, the Ambassador class provides access to the RTI ambassador interfaces and implements the federate ambassador callback methods. Hence, it is the access point for data as well as control flow interaction with the RTI. The HLA specific interfaces given by the Ambassador class are encapsulated by the HLAAdaptor class.

A. Object Model

The ObjectModel allows to store the SOM of a specific simulator. It provides capabilities for dynamic object model representation resulting in a high amount of flexibility. An excerpt of the overall class structure is illustrated in Fig. 3. The classes form an object-oriented meta-representation of a SOM. The structure has been developed according to the OMT. In the OMT specification, components are structured in tables. Object/interaction classes within the OMT can be hierarchically nested, representing inheritance. Components within one table can reference components within other tables. For instance, an attribute entry in the attribute table must reference a specific object class it belongs to. In addition, an attribute must be assigned a datatype of one of the datatype tables. Each datatype table contains types that share common characteristics. The OMT standard differntiates e.g. between basic data representations, simple datatypes or the array datatype table. More complex datatypes like arrays may reference to simple datatypes as element types. The nesting and referencing relationships between components in the OMT tables are mapped to object-oriented aggregation and/or inheritance relationships within the structure of Fig. 3. Generally, the ObjectModel class consists of ObjectClass and InteractionClass members. The hierarchical nesting between object and interaction classes is modelled using self-aggregation. Also, attribute and parameter ownership is modelled using aggregation between Object/InteractionClass types and Attribute/Parameter types. The latter two are owner of any of the defined datatypes. For datatype representation inheritance has been applied in order to exploit polymorphism in case of compound datatypes like arrays. In the current implementation SOM tables can be specified in a easy readable form by means of (nested) C++ method calls as shown in Listing 1. Therefore, the ObjectModel class needs to be inherited for implementation of the generateObjectModel() method. Methods applied within generateObjectModel() are implemented in the base class. An alternative is to provide the SOM as XML representation.

B. Behavioral Interface Model

By inheriting from the BIM class (see Fig. 4) it is possible to define a finite state machine (FSM) by which data and control flow interactions between simulator and HLA and vice versa can be controlled. The FSM defines a valid calling sequence of simulator interface and ambassador methods. This allows to realize/verify different general interaction behaviors and/or synchronization schemes on top of the HLA services. The latter can be advantageous for accelerating DE co-simulation/emulation [START_REF] Roth | Efficient execution of networked mpsoc models by exploiting multiple platform levels[END_REF]. Also, for MoCs different from DE other synchronization schemes may be more suitable. BIM descriptions can be annotated to respective actors as C++ code. When neglecting hierarchical states and abstract arguments, BIM FSMs can mathematically be described as a tuple (S, Σ, Ω, δ, s 0 , s e , S int ), with S being the set of states, Σ the input alphabet, Ω the output alphabet, δ : S × Σ → S × Ω the transition function, s 0 the start state, s e the end state and S int the set of the so called interaction states. States are realized by the State class. During execution, the input within a certain state s is given by the topmost Event within the EventQueue. Events are either generated by actions or incoming method calls from the Ambassador or the simulation tool respectively IOSocket. In the latter case, method calls are converted by the respective adaptor into events. The transition function relates inputs and source states to outputs and target states. In the BehavioralInterfaceModel class it is realized by a transition table which holds elements of type Transition. The traversal of transitions must be protected by Guards. Outputs are generated by Action(s) which can be annotated to transitions. An output corresponds to the generation of a new event into the event queue, the call of a ToolAdaptor/H-LAAdaptor method or the write access to elements of type AbstractArgument which are part of a FSM description.

Event

The notion of interaction state become more clear when considering the execution semantics of a BIM FSM in more detail. These are based on iterative execution of the two methods exec() and post() which are inspired by the fire() and postfire() methods of Ptolemy II actors (since the FSM is always ready to fire, an equivalent to prefire() is not necessary). An iteration consists of a single call to exec() and a subsequent single call to post(). Therewith, the following happpens:

• The exec() method takes the front event from the EventQueue and selects the transition for which the guard evaluates to true. This transition is called active transition. Thereby, a runtime check is performed in order to ensure that there exists only one active transition.

If the runtime check is passed, the associated action(s) is/are executed. If the exist more than one or no active transitions, an exception is thrown. • The post() method changes the current state to the target state of the chosen transition. The method either returns 0 oder +1. If the target state is the toplevel end state or an interaction state the method returns 0 in order to signal termination or that control should temporally be passed to the environment. For all other states the method returns +1 in order to signal that a further iteration of exec() and post() should be performed.

Therewith, an interaction state forms a kind of label at which the execution of the BIM FSM is suspended and control is given to the surrounding execution environment (i.e. the simulator to be connected). The state in which the FSM has been suspended last, corresponds to the entry point for further execution. Instantiation of a BIM FSM works similar to the instantiation of the object model, namely by using (nested) C++ function calls within the generateBIM() method. Applied methods within generateBIM() like STATE() or TRANSITION() are again part of the BehavioralInterfaceModel base class. Listing 2 illustrates an example. At the top instantiation of an abstract argument, specifically a synchronization point named "'READY TO RUN"' is exemplarily shown. Afterwards, four states S_INIT, S_GRANT, S_ADVANCE and S_END are instantiated within the state table. S_INIT and S_END are marked as start respectively end states. In order to avoid state explosion, BIM FSMs can be defined hierarchically: S_INIT is a hierarchical state that is refined with a complete state machine called Init_FSM. Thereby, refinements are always executed first. Only if a refinement cannot execute, then outer transitions are evaluated. The S_GRANT state is marked as interaction state. Both, S_GRANT and S_ADVANCE are referenced by the subsequent transition definition, where S_GRANT is the source state and S_ADVANCE the destination state of the transition. Traversal of the transition is protected by an event guard (a derived type of the Guard class) which limits passage of the transition to the occurence of the Sim Event SetNextBarrier event. The passage of the transition is coupled with the execution of an action called HLA13 A5 11 Action NextEventReq.

Listing 2. BIM FSM Instantiation Code

v i r t u a l v o i d g e n e

IV. TOOL INTEGRATION

Tool integration means, making simulation models or tool capable of communicating with the rest of the overall simulation. The process of tool integration can be separated into the three steps Federation Model Definition, Interface Generation and Interface Integration. The proposed overall supporting process is illustrated in Fig. 5. In the first step one or several federation models (FMs) are defined in PtII. A single PtII model can contain several FMs, each representing a separate federation. In the second step, interfaces for each tool are generated automatically based on the FM definition(s). Finally, interfaces are integrated into simulation tools. Depending on the tool, this step can occur automatically or must occur manually.

A. Federation Model Definition

An FM specified in PtII syntax includes all the necessary information for generating interfaces and configuration files. This information is extracted by parsing the FM. Generally, a FM is specified within a PtII HlaComposite actor. Step 1) Federation Model Definition

Step 2) Interface Generation

Step 3) Interface Integration HLADEDirector HLAGenDirector

Fig. 5. Interface Generation and Tool Integration

This includes datatypes, object/interaction classes and publish/subscribe relationships. II) control flow between simulators by means of annotating behavioral descriptions to actors.

1) Definition of Data Flows and Datatypes: Data flows between the mentioned HLA entities (i.e. the newly introduced actors) are modelled by PtII relations. Thereby, the names of the actors correspond to the names of the respective entities within an HLA object model. HLAFederate actors are only allowed to connect to HLAObjectClass actors and communicate with each other via these. Beside that, federation models can but need not include PtII as federate. PtII can solely be used for FM definition and interface generation. In turn, a HLAFederate actor can represent any type of simulator, including another PtII instance. In order to allow a PtII instance to take part in a federation, ports need to be added to the composite actor that allow connecting to the residual PtII simulation model to HLAObjectClass actors. The structure of HLA object classes and the datatypes of attributes and parameters are determined by the PtII datatypes of the actor ports. The direction of communication between federate actors and object class actors through ports and relations determines the publish/subscribe relationships. In the example of Fig. 5, a single external simulator represented by a federate actor named "'RemoteSimulator"' is co-simulated with a local PtII model. Connection to a local PtII model is achieved by introducing PtII input and output ports (large arrows in corners of the composite) that connect the FM to the HLA composite. The local PtII model and the remote simulator solely communicate via the ObjectClassX and InteractionClassY actors.

2) Definition of Control Flow: The kind of interaction and control flow between simulators that are part of a federation is specified by their BIM FSMs. The BIM FSMs limit the number of interaction patterns between simulators that interact via HLA to a subset of all interaction patterns that are allowed by HLA. In the current version of the PtII extension, BIM FSM descriptions must be annotated to actors as C++ code. In case PtII taking part as federate, the BIM FSM must be annotated to the HLAComposite in case of any other simulator it needs to be annotated to the respective HLAFederate actor.

B. Interface Generation

Tool interfaces can be generated automatically. A generated interface serves as a separate layer between a simulator and HLA. From the overall FM four types of artifacts are generated:

• FOM related artifacts: Currently it is possible to automatically generate the .fed file which is necessary for configuring the RTI. For interface generation there exists a special director called HLAGenDirector. This director must be added to the HLAComposite. The HLAGenDirector has access to different ModelInterpreter classes as shown in Fig. 6. These provide concrete (language specific) interpretations of the syntactical artifacts provided by the FM. Each of the TypeInterpreter classes contains tables with which PtII datatypes are mapped to language specific types like C++, Java or HLA datatypes. Hence, the PtII type system serves as reference type system from which language specific types are derived. The SOMInterpreter is used to fill the datatype tables of the type interpreters with SOM specific content. Both, SOMInterpreter and FOMInterpreter classes provide the capabilities for generating the above mentioned FOM and SOM related artifacts. Finally, the JavaInterfaceInterpreter and CPPInterfaceInterpreter classes inherit from SOMInterpreter and provide additional capabilities for deriving the signature of the data flow related Java and C++ interface functions by which the interface wrapper is accessed from outside. CPPInterfaceInterpreter is capable of generating the high level interface classes, the JavaInterfaceInterpreter is capable for generating the Java specific SWIG interface file.

The resulting artifacts are compiled with the SPLib classes into a shared C++ library. If the target simulator is written in C++ (like e.g. the open source SystemC or OMNET++ simulators) the shared library can directly be integrated and linked to the simulator/model. If the target simulator is written in another language like Java, C# or a scripting language like Python, SWIG must be called for target language wrapper generation.

TypeInterpreter

C. Interface Integration

The interface wrapper appears to a simulator as a single class that provides a fixed number of control flow and a variable number of data flow related high level methods. The control flow related methods are provided by the ToolAdaptor class, the data flow related ones by the IOSocket classes (see also section III). They have a fixed signature. In the current implementation, control flow related methods are Generally, interface integration can be viewed as a mapping of BIM FSM states into the execution phases of the target simulator. Exemplarily transferred to a PtII director these phases are preinitialize(), initialize(), prefire(), fire(), postfire() and wrapup(). For PtII integration, a special HLADEDirector has been developed which derives from the original DEDirector and which integrates an interface wrapper following the described approach (a prestudy has been done in [START_REF] Brito | Development and evaluation of distributed simulation of embedded systems using ptolemy and hla[END_REF]). Since PtII is written in Java, a SWIG based wrapper is used and loaded dynamically. The mentioned control flow related calls can theoretically occur in any of the execution phases of the HLADEDirector. The applied BIM FSM (the same has been used for SystemC and Veins) is illustrated in Fig. 7. It consists of a toplevel FSM with four hierarchical refined states. In S_INIT HLA initialization like federation creation, publication and subscription as well as instance registration is performed (for the latter, S_INIT internally contains an interaction state). The S_SYNC_READY_TO_RUN and S_SYNC_SHUTDOWN states are refined by FSMs that implement synchronization procedures by means of HLA synchronization points which ensure that simulators start and stop execution (the latter includes instance deletion and the shutdown procedure) at the same time. The S_EXECUTE state is responsible for time advancement (federates are time regulating and time constrained). It is an interaction state and a refined state at the same time. Interaction with the environment simulator is only performed if there does not exist an event in the event queue (symbolized by Event_Absent). Otherwise, the refinement states ensure that only valid events can occur during the time advancement procedure. Finally, if the toplevel end state becomes the next state, the FSM terminates. The current implementation matches the S_INIT state to the initialize() phase, the S_EXECUTE state to the fire() phase and the S_END state to the wrapup() phase of the PtII HLADEDirector. If the fire() method of the HLADEDirector is called and the timestamp of the next event in the event queue is larger than the previously granted time the director proposes an advance, iterates and sets the next fire time via fireContainerAt() to the granted time. Afterwards reflections are served. Due to the microstep semantics zero lookahead was chosen. In order to be able to achieve deterministic distributed execution by means of the NER service a priority field method similar to the one described in [START_REF] Fujimoto | Zero lookahead and repeatability in the high level architecture[END_REF] is applied. The HLADEDirector manages data flow between a local PtII model and the interface wrapper with support of the HLAObjectClass. The HLADEDirector is equipped with a reflectDir() and updateDir(token) method. The reflectDir() method is called by the HLADEDirector itself at any point in simulation time when a new time barrier has been read by calling getNextBarrier(). The method checks IOSocket buffers for available reflections by calling getSocketQueueSize(). If a reflection is available the full signature of the read method is dynamically derived from the object class structure of the SOM using the JavaInterfaceInterpreter class. The reflection is then converted into a PtII token. Afterwards, the token is transferred to the HLAObjectClass actor that belongs to the IOSocket which provided the reflection. For that reason, each HLAObjectClass actor is equipped with a reflectAct(token,time) method. In turn, the updateDir(token) method is called by HLAObjectClass actors. The method converts the passed token by the help of the JavaInterfaceInterpreter class into a write method call on the interface wrapper. The timestamp of the generated update event corresponds to the current local simulation time. The semi-automatic integration by dynamic signature derivation makes sense since PtII plays a central role within the overall tool chain and is probably applied in many different and extensible co-simulation scenarios.

During execution, only HLAObjectClass actors that connect to the HLAComposite ports play an active role. They represent the HLA object classes (to) which the residual probably heterogeneous PtII model subscribes/publishes. They are necessary for transferring data between the residual PtII model and the federation and vice versa. All other HLAObjectClass and HLAFederate actors remain passive and will never fire during execution. The reflectAct(token,time) method of a HLAObjectClass actor stores the passed token in an internal timed queue. The method internally calls fireAt(time). This makes sure, that the actor is fired at the point in time, when a reflected token should be forwarded to the residual PtII model through the corresponding output port. Therefore, the time parameter must correspond to the time of the grant. The opposite direction works as follows: As soon as an HLAObjectClass actor is fired it checks its input ports for available tokens. if a token is found it is passed to the HLADEDirector by calling updateDir(token).

Overall, by means of the combination of PtII and HLA in the described manner, the following types of execution are conceivable: V. CASE STUDIES Applicability of the previously described tool chain is now demonstrated by means of a framework that has been developed with the tool chain. Thereby, validation of a V2X based ACC application running on a future automotive E/E architecture has been chosen as example. By means of the presented case studies three goals are pursued I) demonstration of the basic capability of heterogeneous distributed co-simulation II) demonstration of the applicability of PBD within the tool chain III) demonstration of applicability for verification using several federations in parallel.

A. Simulation Setup

The overall framework is shown in Fig. 8. It allows investigating interdependency between inter/intra vehicle communication as well as computation overhead when executing ACC functions. The framework consists of a PtII federate, a Veins federate and a SystemC federate. In case of the latter two the interface wrapper has been integrated manually. The structure has been designed according to the PtII managed mode described in section IV-C, i.e. single simulators are cosimulated with PtII within seperate logical federations. Within the PtII federate the E/E architecture of the vehicles of interest is modelled. These intra-vehicle models are combined with an inter vehicle model that is provided by a Veins federate. Veins is an open source vehicular network simulator that integrates the OMNET++ network simulator with the SUMO traffic simulator bidirectionally using a TCP/IP proxy. Veins allows simulating IEEE 802.11p wireless networks including node mobility. Within the framework Veins simulates surrounding vehicles and the inter vehicle communication via V2X messages. Finally, by means of a SystemC federate selected ECUs within the E/E architecture model can be refined down to fully cycle accurate descriptions. All federates are integrated by means of the interface wrapper described above.

Concerning Veins we've modified the application and mobility modules of Veins by the introduction of additional parameters that allow indicating which vehicles are remotely controlled by PtII or if WiFi messages are received/sent remotely from/to PtII. This is a prerequisite for validation of the ACC functionality. Regarding synchronization a parameter can be set for each vehicle representing the time interval for updating messages exchanged with PtII. Analogueous, there is a parameter which specifies the update time interval between SUMO and OMNET++ via TCP/IP. In the different considered scenarios these are set to a value of 0.01s.

Considering SystemC, a detailed model of a multi-core architecure called HeMPS [START_REF] Carara | HeMPS -a framework for NoC-based MPSoC generation[END_REF] which represents a refined V2X ECU has been integrated. The model consists of a configurable number of processing elements (PEs) which are interconnected by a Network-on-Chip (NoC) called HERMES [START_REF] Moraes | HERMES: an infrastructure for low area overhead packet-switching networks on chip[END_REF]. In addition, the model is equipped with a virtual internal/external network interface that connects the model to the interface wrapper.

B. Adaptive Cruise Control Application

Current ACC systems monitor the distance to the vehicle in front using radar sensors. Based on the monitored values speed and distance are automatically adjusted by motor and brake intervention. However, conventional ACC monitoring is limited to the line of sight. This can be a safety critical factor e.g. in case of a sudden traffic congestion within a curve. By extending the ACC with V2XC capabilities, an automatic reaction to such situations is possible.

The PtII model of the considered scenario is shown in Fig. 9. On the top level, the overall simulation model is instantiated, containing Veins and separate composite actors for selected vehicles. Vehicles can be refined to E/E architectures. Here, we orient ourselves by design principles suggested for future E/E architectures [START_REF] Buckl | The software car: Building ict architectures for future electric vehicles[END_REF] like a centralized computer architecture and interconnection by a standardized communication backbone. We assume, that the basic structure of the target E/E architecture is predefined while implementation of components like ECUs may vary. Inside the E/E architecture data is routed through a network model represented by an Internal Network composite. V2X and Central ECUs are assumed to be multicore architectures which execute the ACC application. Radar ECU and GPS ECU are responsible for data acquisition and preprocessing of radar sensor and GPS data where the Radar ECU provides position and velocity of the vehicle ahead and the GPS ECU the own position. The four Wheel ECUs take the acceleration calculated by the ACC as an input and drive the corresponding wheels to the desired velocity. The determined velocity value is fed back to the top level model and forwarded to Veins where the velocity of the corresponding remotely controlled SUMO vehicle is adjusted. The Wheel ECU composites, representing the control path of the ACC application, are directed by a ContinuousDirector. The velocity provided by the Wheel ECUs is discretized in order to be reused for transmission to connected ECUs. The sampling rate is set to 0.01s In Fig. 10 the velocity measurements of radar only controlled ACC is shown. The red and blue curves belong to the ahead and refined vehicle respectively. As we can see, the refined vehicle whose velocity is calculated in PtII follows the leading vehicle controlled by SUMO with a certain distance that depends on ACC parameters such as a safety time gap (set to 1.7s). The calculated acceleration is plotted in Fig. 10. On the right hand side in Fig. 10 we can see the position of the leading and the following vehicle. The difference between both curves represents the distance between both vehicles and is also reflected by the distance plot in Fig. 10.

To analyse the influence of the V2X based ACC, several simulations with different V2X message beacon rates of 0.1s, 1.0s and 10.0s have been conducted. With a beacon rate of 0.1s the curves are identical to the radar ACC. When increasing the beacon rate to 1.0s and 10.0s (low beacon rates could arise e.g. in lossy or jammed channels) the progress of the velocity of the following vehicle gets less comfortable in terms of maneuver with high deceleration rates or higher velocities. This gets more obvious the lower the beacon rates get since the ACC algorithm gets updates about the actual position and velocity of the leading vehicle less frequently. This can be observed in Fig. 11 but even with a beacon rate of 10.0s the scenario still remains crash free. However, if the beacon rate gets too low, the ACC cannot react properly anymore and crashes into the leading vehicle. This has been observed with a very low beacon rate of 50.0s where a crash occured after around 49s.

D. Application of Platform-based Design Principles

As has been shown, the framework allows modelling of functional and architectural artifacts as well as environmental components, that are necessary for a holistic analysis and system validation. In the following it is shown that by replacing abstract artifacts through more detailed entities, an iterative refinement of an abstract specification towards the final implementation is possible. Moreover, if the process of refinement is based on quantity managers (QM) [START_REF] Davare | A next-generation design framework for platformbased design[END_REF] a mapping of functions to co-simulated architecture models is possible. PtII provides capabilities for computation and communication refinement using so called aspects which are a synonym for QMs [START_REF] Ptolemaeus | System Design, Modeling, and Simulation using Ptolemy II. Ptolemy.org[END_REF].

As mentioned above, messages exchanged within an E/E architecture model are routed through an Internal Network composite. For communication refinement, the ports at that composite can e.g. be annotated with a so called bus communication aspect allowing investigation of bus delay influences. Furthermore, the vehicle composites can be refined towards functional and architectural models which is the basis for computation refinement. The function (ACC application) is specified by means of a task graph consisting of Tasks T1-T7. A task is represented by a (composite) actor which models a specific sub-functionality of the overall V2X-ACC application. Hereby, the single tasks fulfill the following sub-functionality:

1) V2X data transmission 2) V2X data reception 3) V2X data security measures 4) radar sensor and GPS data processing 5) data aggregration 6) V2X-ACC algorithm based on the Intelligent Driver Model (IDM) 7) actuator control.

Within this case study, Central ECU and V2X ECU are responsible for the tasks T1-T7. The latter can be mapped on the former by means of a newly developed quantity manager actor called QMMapper. The mapping and routing are specified by routing entries in a mapping/routing table used by the QMMapper. This is the basis for a later automization of design space exploration. For investigating task mapping influences, the following methodology is applied:

1) Tasks are clustered into task groups consolidated in further composite actors. These composites follow the PTIDES MoC [START_REF] Zhao | A programming model for timesynchronized distributed real-time systems[END_REF] time-synchronized distributed realtime applications. A PTIDES composite is also called PTIDES platform. 2) PTIDES platforms are mapped onto V2X ECU resp.

Central ECU which is accomplished by means of the QMMapper.

3) The specification of each of the ECUs can be refined from an abstract model down to an individual RTL SystemC implementation. Each PTIDES platform is then mapped onto a specific PE within the abstract composite/cosimulated SystemC model.

In the following measurements a V2X ACC has been configured with a beacon interval of 1.0s. Two task groups, i.e. PTIDES platforms called ACC containing T4-T7 and V2X containing T1-T3 have been created. The Central ECU and V2X ECU are modelled abstractly. Each is made up of four PEs interconnected by an abstract NoC. Scheduling issues are not considered in this use case but can be incorporated by annotating different kinds of so called execution aspects [START_REF] Ptolemaeus | System Design, Modeling, and Simulation using Ptolemy II. Ptolemy.org[END_REF].

Table I summarizes the mapping variations of the platforms. In both cases the ACC platform is mapped onto the Central ECU and the V2X platform onto the V2X ECU but on different inside the ECU. Thereby PE 0 is a computational core with additional access to the network interface, i.e. every message to be received/sent is processed in PE 0 first. It is obvious that in Mapping 1 no additional communication delay through the NoC emerges whereas in Mapping 2 all messages need to be received/sent from/to PE 3. Furthermore, in both mappings the received V2X messages have to pass the internal network since the ACC and V2X platforms are mapped onto Central and V2X ECU respectively. To see the influence of communication delay caused by the E/E internal network and the NoCs of the Central ECU and V2X, we generated synthetic congestion resulting in bus service times of the internal network of 2ms and in NoC delays per hop of 500ms. Such high delays per hop can arise in simple NoCs in case of congestion when there are no quality of service countermeasures. Thus in Mapping 2 there are three hops necessary in the V2X ECU to forward received velocity and position values of the vehicle ahead to PE 0 before the packet can be sent out via the internal E/E bus to the Central ECU. In the Central ECU again all incoming messages have to be forwarded from PE 0 to PE 3 before the ACC can calculate new acceleration values. This results in a communication delay of about 6 * 500ms = 3s where the internal bus delay is neglected. This can be obeserved in Fig. 12 where the braking maneveur of Mapping 2 is delayed by calculated value compared to Mapping 1 where only the internal bus delay has an influence.

E. Verification based on Multiple Federations

The last case study serves as demonstration of the feasibility of PtII managed mode and mixed mode. In the case of discrete-event models a distinct execution order of actors is the basis for achieving causally correct and deterministic simulation results. For that case, PtII assigns priorities to events by sorting them according to model time, microstep and level [START_REF] Ptolemaeus | System Design, Modeling, and Simulation using Ptolemy II. Ptolemy.org[END_REF]. The microstep specifies a zero delay at a certain point in time whereas the level is determined by a topological sort of a directed acyclic graph (DAG) of the actors. Therewith an ordering is assigned such that an upstream actor in the DAG executes earlier than a downstream actor. In order to be able to build a DAG, loops between actors must contain at least a microstep delay. The synchronization algorithm that has been presented above relies on the NER service of the HLA. An HLADEDirector proposes to advance to a certain point in time that is specified by the setNextBarrier() call. It always passes the next event that is currently available within the event queue. In order to guarantee causal correct execution the time delta from the current point in time to the proposed time must not be larger than the minimum possible delay until the HLAComposite may possibly receive a new token. This requirement is always fulfilled for a single HLA composite and for multiple HLA composites without loops between them (due to the execution ordering). However, in case of the existence of loops between HLA composites the next event in the event queue cannot unconditionally be taken for proposition via setNextBarrier(), even in the case of delays that are inserted. The reason is, that after the grant of a HLADEDirector A within an upstream HLAComposite to time t A a HLADEDirector B within an adjacent downstream HLAComposite that requests at the same time and microstep could be granted to a time t B < t A and violate causal correctness by inserting a token that will be sent to federation A at an already passed point in time. A simple solution is to derive a minimum lookahead within the PtII model and regularly generate events with the derived minimum lookahead. This solution has been chosen here. The path from Veins to HeMPS contains no delay. The path from HeMPS to Veins via the Wheel ECU hence must contain at least a microstep delay to create the DAG. Concerning lookahead, since the Wheel ECU generates events with the same frequency as Veins (i.e. 1/0.01s), there will always be a event in the event queue in due time which avoids that Veins requests too far into the future. Hence, Veins will never receive events in the past and causal correctness is preserved. Fig. 13 illustrates the measured results for a simulated time interval of 10s when executing the radar ACC application as Kahn Process Network (KPN) on the cycle accurate HeMPS model. The model has been simulated with clock frequencies of 100 kHz respectively 50 kHz. As can be seen 100 kHz version reacts slightly faster which results in the velocity to start increasing again already at 19s whereas the 50 kHz version still remains at 0 m/s. The execution for 10s of simulation time was 25min at 50kHz and 52min at 100kHz on a core i5 dual-core at 2.5GHz. In [START_REF] Topc ¸u | A metamodel for federation architectures[END_REF] a metamodel for federation architectures is presented. However, no solution for managing heterogeneity is provided. In recent model-based approaches for investigating V2X communication like [START_REF] Queck | Realistic simulation of v2x communication scenarios[END_REF], [START_REF] Sommer | Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis[END_REF] the emphasis lies on application analysis on a more coarse grained level like traffic management and efficiency. Because of that, in these works vehicles can be considered as a focused processing point. However, for validation of E/E architecture components, such a point-of-view is insufficient. There is rather the need for a comprehensive description of a complete V2X processing chain starting from the sensor of the source vehicle and ending up at the actor of the destination vehicle. The concept presented in [START_REF] Roth | Car-to-X Simulation Environment for Comprehensive Design Space Exploration Verification and Test[END_REF] targets such a view but it is not mentioned, how heterogeneity could be managed or PBD principles could be integrated. In the area of hardware/software co-simulation [START_REF]Synopsis Platform Architect[END_REF] or [START_REF] Davare | A next-generation design framework for platformbased design[END_REF] are prominent tools. However, they do not provide capabilities for structured integration of simulators.

Fig. 1 .

 1 Fig. 1. Possible Framework Architecture

Fig. 2 .

 2 Fig. 2. SPLib Class Diagram

Fig. 3 .

 3 Fig. 3. Object Model Class Diagram

Fig. 4 .

 4 Fig. 4. Behavioral Interface Model Class Diagram

Fig. 6 .

 6 Fig. 6. Model Interpreters used within the HLAGenDirector

Fig. 7 .

 7 Fig. 7. Behavioral Interface Model FSM In contrast to the control flow methods, data flow related methods do not necessarily have a fixed signature. Methods for reading and writing start with read or write followed by the name of the object class that is accessed. The instance name is a method parameter. Number and types of other parameters depend on number and types of attributes that are stored within the respective object class. Data flow related methods are • readX(): Read topmost reflection of IOSocket/object class "'X"'. • writeX(): Write an update into IOSocket/object class "'X"'. This effectively generates a Sim_Event_Update event for the BIM FSM. In addition, a timestamp must be passed to the write call. • addRemInst(): Generate event for adding/removing object class instances. • getSocketQueueSize(): Return the fill level of a specified IOSocket. • popSocket(): Pop the topmost reflection from a specified IOSocket.

Fig. 9 .

 9 Fig. 9. V2X-based ACC Validation Scenario

Fig. 10 .

 10 Fig. 10. Velocities (top left), Own Acceleration (bottom left), Distance (top right) and Position (bottom right) of radar controlled ACC

Fig. 12 .

 12 Fig. 12. Velocities depending on Mapping, Left: ACC=CentralECU PE0, V2X=V2XECU PE0, Right: ACC=CentralECU PE3, V2X=V2XECU PE3

Fig. 13 .

 13 Fig. 13. Radar ACC as KPN Application on HeMPS (100 kHz left, 50 kHz right), red = ahead vehicle, blue = follower vehicle VI. DISTINCTION TO RELATED WORKS

  HLAObjectClass orHLAInteractionClass actors represent HLA object respectively interaction classes (in the following only HLAObjectClass actors are mentioned for simplicity reasons). By means of these basic elements the user can define I) data flows and data representations within a distributed co-simulation using actors, ports and relations.

		ObjectClassX
		RemoteSimulator
		InteractionClassY
		HLAComposite
	FOM	High Level
	(XML/FED)	Interface	SOMs	BIM FSMs
		Classes	(C++)	(C++)
		(C++)
	Beside the HLAComposite actor, further different novel types of PtII actors like HLAComposite, HLAFederate, HLAObjectClass or HLAInteractionClass are introduced. HLAFederate actors represent simulators to be co-simulated, SWIG Wrapper Generator Target Language C++ Compiler & Linker Compilers, Interpreters, Classloaders, ... wrap Federates RTI Shared Federate Libraries Target Language Wrappers	SPLib Sources Target Language Models HLA Ambass. Interfaces

  • SOM: The SOM is exported as C++ code. SOM specifications follow the syntax as it has been defined in section III-A (i.e. an inherited class of the ObjectModel class with respective OM instantiation code). • Behavioral Interface Model FSM: As already mentioned above, BIM FSMs currently need to be annotated as PtII parameter to federate actors and/or the HLA composite actor. BIM FSMs follow the syntax defined in section III-B. From the annotated FSM description an inherited class of the BehavioralInterfaceModel class is generated for each federate. • High level interface classes: These are generated for each federate and set on top of the SPLib classes.

They include derived types of IOSocket and a C++ wrapper class. The latter provides a function-based interface to the Adaptor and IOSocket classes. This greatly simplifies usage. Beside that, SWIG

[START_REF] Beazley | Automated scientific software scripting with swig[END_REF]

interface files (.i files) can be generated. SWIG is incorporated in order to wrap the C++ wrapper class once again for integration into simulators that are based other languages than C++. Interface files are used to configure SWIG with special type mappings between C++ and a target language. The resulting component is called interface wrapper in the following.

  • getState(): Return the current state of the BIM FSM. • setExpState(s exp ): The expected s exp state value may be used by the FSM to verify that it matches the actual next interaction state.

	• setNextBarrier(): Set the next time barrier that the
	simulator wishes to advance.
	• getNextBarrier(): Get the last time barrier that has
	been granted.

• iterate(): Iterate the BIM FSM. Executes sequences of exec() and post() until post() returns 0. This method must regularly be called by the environment simulator in order to advance the BIM FSM state.

• end(): Generate a Sim_Event_End event for the BIM FSM.

  and modification of data and control flows between them. Single simulators are co-simulated with PtII within seperate federations using appropriate SOMs and BIM FSMs. PtII serves as federation gateway and mediates between these federations. A possible drawback is decreased performance.• Mixed Mode: In this mode, the previously described modes are executed together, i.e. not only PtII and single simulators form separate federations but a co-simulation federation can contain more simulators. It combines advantages of both modes, namely better execution performance and flexibility in model composition.

	• Standard Mode: All simulators are part of a single feder-
	ation. This mode is best applied if all simulators follow
	related execution semantics. E.g. integrating several iden-
	tical DE simulators into a single federation is a straight
	forward issue since both, RTI and the simulators are
	basically event-based. A typical application is parallel
	simulation for improving performance.

• PtII Managed Mode: Generally, a "brute-force" composition of heterogeneous simulators following different MoCs may result in so called emergent behavior

[START_REF] Eker | Taming heterogeneity -the Ptolemy approach[END_REF]

. Hence, in this mode, the RTI is assisted by PtII for managing heterogeneity. This enables structured composition of federations

TABLE I

 I

	.	PTIDES PLATFORM MAPPINGS
		Mapping 1
	Platform	Tasks	ECU	PE
	ACC	T4-T7	Central ECU	0
	V2X	T1-T3	V2X ECU	0
		Mapping 2
	Platform	Tasks	ECU	PE
	ACC	T4-T7	Central ECU	3
	V2X	T1-T3	V2X ECU	3

ACKNOWLEDGMENT

This work was supported by the Sino-German Network on Electromobility.