Fabienne Nouvel
email: fabienne.nouvel@insa-rennes.fr

Philippe Tanguy
email: philippe.tanguy1@insa-rennes.fr

What is about future high speed power line communication systems for in-vehicles networks ?

Keywords: vehicles, power line, X-by-wire, embedded networks. I

This paper deals with alternative automotive networks involved by the X-by-wire and X-tainment applications. New market demands like navigation, multimedia, security, safety and individualized options introduce more and more electronic control units. Furthermore, the automotive industry has to face a great challenge in its transition from mechanical engineering towards mechatronical products. In the last decades, the power line technology has received an increasing attention and spans several applications both in indoor, outdoor and invehicle data communications. To fulfil theses demands of intracar communications, techniques based on power line communication (PLC) seem to be a good candidate. These techniques offer both high data rate and good adequacy with power line properties. This paper revisits the work carried out in using PLC within the automotive domain. Different solutions are discussed and results are given for different applications.

INTRODUCTION

Nowadays, several fieldbus technologies, usually very specialized, were developed by car manufacturers to fulfil the different communications between electronic control units (ECU) according to their task. The ECU can assist the driver to control for example the vehicle through functions related to the steering, traction, braking system (ABS), Electronic Stability Program (ESP), Electric Power Steering (EPS), . . . . The different used networks (i.e CAN, LIN, FlexRay, MOST) [1,chapter II and IV] provide different services. They required specific MAC and PHY layers for managing communications and, in particular, for granting bus access. Each of these networks use it own data lines and thereby is responsible for an increase of wiring harness. To reduce this complexity, without reducing safety, it is desirable to commit to a limited set of networks. However, it is not in the near future that the number of networks can be reduced to only one or two as such technology would provide the properties supporting the most demanding automotive systems. It would probably make it too expensive. Hence, it is more likely that a few network technologies will be used while providing timeliness and fault tolerance.

Among all the available technologies, it seems to be interesting to look at the evolution of the local are networks (LAN) for domestic uses. Since few years, power line communications (PLC) has received a great interest. PLC solution has numerous advantages, notably in terms of reliability, because it would reduce the amount of splicing that is necessary, as well as simplify and lighten the cable bundles The HomePlug Powerline Alliance [START_REF]HomePlug Powerline Alliance[END_REF] has been formed in 2000 by a group of industry leading companies to enable standards based powerline networking products. In 2005, the IEEE P1901 [START_REF]Medium Access Control and Physical Layer Specifications[END_REF] has been created. The objectives of the IEEE P1901 working group are to standardize the PLC context. However, their efforts are limited to the physical layer (PHY) and medium access layer (MAC). Today PLC advantages have been demonstrated, it is the reason why the PLC solution is studied by car manufacturers. A first application of PLC could be redundant path for X-by-wire systems. Furthermore, PLC could be used for the diagnosis of ECUs and finally high data rate communications. In [START_REF] Benzi | Towards the powerline alternative in automotive applications[END_REF], the authors focus on PLC for automotive. The main issues proposed by the authors are the cost reduction, the bus segmentation and replacement of the common vehicle networks and especially the widespread CAN.

The remaining paper is organized as follows. In next section, we give an overview of previously work on high data rates PLC solutions. In section III, we discuss about automotive constraints. We briefly present the features of today PLC technologies used in indoor applications, namely the HomePlug AV and HD-PLC standards in section IV. In section V, we present some results we obtain in our study. Finally, Section VI concludes the paper.

II. BACK GROUND

A.

Back ground: previous PLC studies in vehicle PLC is nowadays adopted in a multitude of application domains, both for broadband connectivity, indoor automation and data exchanges. A number of widely adopted communication protocols have been developed, starting from low speed X10 technology up to recent implementations like HomePlug or HD-PLC, which is also targeted to high speed communication, to support for example High Definition TV and VoIP. It is obvious that the power line in indoor has very few common with the automotive ones. However, the power line channels present numerous similarities: impulse noise, multipaths, attenuation [START_REF] Lienard | Modeling and Analysis on In-vehicle power line communication channels[END_REF] [START_REF] Degardin | Comparison of in-house and in-vehicle noise characteristics in PLC systems[END_REF].

In [START_REF] Nouvel | Code division multiple access for an automotive area network over power-lines[END_REF], PLC feasibility for cars has been demonstrated. The proposed solution was based on spread spectrum technology. It ICICS 2009 allowed multi-user access by using code division multiple accesses. However, it achieved only a 50 Kbps data rate per function. In [START_REF] Beikirch | Can-transceiver for field bus powerline communications[END_REF], a CAN PLC transceiver has been studied. It supported both single carrier modulation and base band ASK modulation. It achieved bit rate up to 250Kbps. Further investigations have been carried out in [START_REF] Taub | Real-time capabilities with digital powerline communications interfaces in csma/ca-networks[END_REF] in order to develop a CAN-based powerline multi-carrier transceiver instead of single carrier modulation. Today, the Yamar [START_REF]Official web site of Yamar[END_REF] Company proposed solution based on transmission over DC lines and CAN protocol. Two devices namely DCAN250 and DCB500 are already available. The DCAN250 allows communications up to 250 Kbps as DCB500 allows various applications up to 500Kbps. These PLC solutions have the advantages of being CAN compliant. However the main draw back is the low data rate and they do not answer X-by-wire and/or multi-media requirements.

B.

Recent PLC applications and investigations In more recent years, car manufacturers focus on PLC as an alternative for embedded networks due to its benefits related to the reduction of cabling and costs. In [11], authors investigate the properties of on board power lines and introduce a tutorial about the realization of high speed PLC. They propose a reorganization of the wiring harnesses based on a star structure. This solution can avoid reflection and makes impedance matching easier by using ferrite materials. Similar modifications of DC networks are proposed in [12] in order to fulfil high data rate requirements and safety. Recently, the PREDIT Project has focus on new embedded PLC solutions. In [START_REF] Lienard | Modeling and Analysis on In-vehicle power line communication channels[END_REF] the authors have studied high PLC data rate communication based on the well known OFDM technique (orthogonal frequency division multiple access). OFDM has the advantage to cope with the frequency selectivity of the power line channel caused by multiple reflections and by the coupling to cables. In the vehicle demonstration [12], a video transmission between a camera at the rear of the vehicle and a screen placed on the dashboard has been carried out up to 30 frames per second. Nowadays, one can affirm that the feasibility of indoor PLC over in-vehicle powerline channels is demonstrated and we need to go deeper into the study.

The workshop held in Italy [13] is aimed at presenting the state of the art in communication systems in a modern car, in order to optimize and reduce the cabling on board. Some useful results expected from the workshop are: a general layout of a useful benchmark; the specifications expected from a PLC based protocol to meet the automotive requirements; a list of significant experiments aimed at defining the viability of a PLC solution.

Recently, the author in [14] has proposed a vehicular communication system which can switch over a communication method between the orthogonal frequency division multiplex (OFDM) method and the spread spectrum (SS) method. A PLC master set includes a LAN communication unit for performing data communications with control units such as an engine control ECU via an in-vehicle LAN. In the PLC master set, a microcomputer acquires the operating states of parts of the vehicle from various control units through the LAN communication unit, and uses the acquired operating states and control information stored previously to enable data communications without being affected by noises. The demonstrator includes a camera that is mounted in a vehicle such as a car to photograph its periphery, and a receiving device that receives a video signal from the camera to perform image processing and the like are connected to enable data communications with each other through an electric power line wired in the vehicle and transmit the video signal from the camera to the receiving device through the power line. Furthermore in this system, the modulation per subcarrier can change from 64 QAM down to BPSK according to the channel state. However, no results in term of throughput are given nor bit error rates.

Among the different possible technologies that can be adopted in vehicle, a description of some of them is given in section IV.

III. AUTOMOTIVE POWER LINE AND CONSTRAINTS

Before considering the PHY and MAC layers of PLC system, the capacity of the channel through the wires must be determined through channel measurements. Furthermore, the PLC solution must meet the EMC requirements.

A.

Channel measurement Different channel measurements have been carried out in [15] and [16] on different cars. The variations of the transfer function are observed in different configurations: electronic unit ON or OFF, ignition ON/OFF, car moving or not, battery connected or not. Additional complex paths (front, trunk, cockpit, point to point, multi-point …) have been studied on an other car [17]. The throughput and channel measurement results show that it is not easy to confirm the separation into direct and indirect links as it has proposed in [18]. In [START_REF] Mohammadi | Measurement Study and Transmission for In vehicle[END_REF], similar measurements have been performed in a small sports car. Experimentations show the effects of electronic states on the channel (drops of about 10 dB), which are consistent with all the previous works. In addition, they do not confirm the direct and indirect path classification. Furthermore, the results emphasize that impedance adaptation for modem must be studied carefully as the interfaces will modify the power line channel. These different studies show that the channel characterization is not easy and linked to the vehicle. Fig. 1 and Fig. 2 present two examples of variations of the transfer function between nodes in the vehicle. In these measurements, the motor is off. In Fig. 1, D1D3 is considered as direct, as D1D2 and D2D3 are indirect as classified in [18]. All these points are in the Front area. We have done the measures in Fig. 2 on a French Peugeot 407 SW. In most of the experimentations, the measurements are carried out up to 80-90 MHz, as the upper bound for domestic channel is 100 MHz. These results can be compared with indoor PLC profiles obtained in [START_REF] Degardin | Power Line Communication: Application to Indoor and In-Vehicle Data Transmission[END_REF], represented in Fig. 3. We can observe that this channel is not flat and is linked with the loads. In Fig. 1 and Fig. 2, we can observe the short length paths less suffer from reflection, cable attenuation and junction. The differences between are on the order of 10 up to 15 dB in the [0-30] MHz band. However, the D2D3 link presents deep fading due to the low battery impedance connected on this link. In the upper band, we can observe that for short links, the channels do not present high attenuation and could be an interesting transmission band. For the Front-Rear links (Fig. 2), we observe a linear decrease. Results in [START_REF] Mohammadi | Measurement Study and Transmission for In vehicle[END_REF] exhibit more reflections and variable insertion loss in the [30-100] MHz. However, those figures make it is clear that a narrow band and single carrier transmission is not able to provide efficient connectivity.

B. EMC requirements

The selected PHY will have to fulfil the PLC requirements defined in the Ray_CISPR25 [START_REF]Limits and methods of measurement of radio disturbance characteristics for the protection of receivers used on board vehicles[END_REF] which allow transmission in the [0.15-30] MHz bandwidth under 45dBµV (-61dBm) and 35dBµV (-72dBm) for class 4 and class 5 respectively. Fig. 4 represents HomePLug AV power spectru measured on automotive power lines (the same car than Fig. 2) compared with the EMC constraints. Letters correspond to different point in the vehicle, both Front Left/Right/Middle and Rear Left/Right/Middle. The access impedance has not been yet optimized. We can observe the PLC signal is CISPR compliant up to class 2. If we compare the CISPR vehicle requirements with PLC indoor's one, the indoor PLC emission mask may not exceed -50dBm/Hz (57 dBµV) in North America. We notice this level is higher than the vehicular emission limit.

IV. PLC STANDARDS DESCRIPTION

Considering these results, the PLC PHY layer will require frequency diversity which can be achieved by using orthogonal frequency division multiplex (OFDM). OFDM has been adopted for many wireless wide area or personal area networks (like in IEEE 802.11a/g) or over copper wires (ADSL). Actually, two standards are promoted by the IEEE

AF AH AD

1901 group, the HomePlug AV and the HD-PLC standard. The actual barrier to the adoption of PLC in indoor ( and then in car) is the lack of technical standard. We will rapidly described the two solutions proposed to standardization. However, additionnal systems have been proposed like the Spidcom technology. .

A. HomePLug 1.0 and HomePlug AV The HomePlug process is based on an OFDM technique whose major advantage for the embedded PLC application is to cope with the frequency selectivity of the power line channel. The HomePlug V1.0 [START_REF] Lee | HomPlug 1.0 PowerLine Communication LANs-Protocol[END_REF] was based on 128(84 used) sub-carriers equally spaced from 4.3 MHz to 25MHz, (intercarrier space is about 195 KHz) with a 50 MHz sampling rate. The OFDM symbol duration is 8.4 µs with 5.12µs for the raw OFDM symbol and 3.28µs for the guard interval (GI). The differential encoding allows simplifying the receiver part by suppressing the channel equalization. DBPSK, DQPSK or ROBO modulation on each subcarrier are applied according to the signal to noise ratio (SNR). Concerning the MAC layer, HomePlug V1.0 uses only the CSMA/CA protocol to access to the ad-hoc network. The enhanced HomePlug V1.0 is the HomePlug AV (HPAV) standard of which features are summarized in Table I. The OFDM modulation is realized thanks to a 3072 points IFFT/FFT with a frequency sampling of 75 MHz. In this case the OFDM symbol duration is 40.96 µs and the space between each carrier is 24.414 kHz. The HPAV uses higher modulation order from BPSK (Binary phase-shift keying) up to 1024 QAM than HomePlug V1.0. Moreover, several GI can be used depending on the channel and so the data rates can be improved. A frequency mask is used to avoid interferences mainly with amateur radio bands. Thanks to this specific window, the out of band noise is reduced and the notches are deeper. Those enhancements will improve many features: the throughput, the equalization, and the interferences. Results obtained in [18] show that the median values of coherence bandwidth (Bc) are 1.3 MHz and 700 kHz for direct and indirect connections. If we consider the delay spread (DS) and the GI, the authors report that the Ds remains under 380 µs for all the direct and indirect configurations. This delay is longer thanthe [START_REF]HomePlug Powerline Alliance[END_REF][START_REF]Medium Access Control and Physical Layer Specifications[END_REF][START_REF] Benzi | Towards the powerline alternative in automotive applications[END_REF][START_REF] Lienard | Modeling and Analysis on In-vehicle power line communication channels[END_REF]µs Ds obtained in indoor (it can also be on the order of some microseconds as in the cars). Generally, the GI duration should be about two to four times the DS.

If we compare the HPAV parameters with the Bc and Ds constraints, we can observe that they fulfil them. Furthermore, we can observe that the HPAV parameters are closer to the in vehicle channel parameters than the HomePlug V1.0 ones. These results are confirmed by the study presented in [15]. An enhanced OFDM system has been simulated using up to 2048 sub-carriers in the [0-20] MHz bandwidth. As the HomePLug V1.0 is not optimum to obtain a bit error rate (BER) of 10 -3 , this BER can be obtained by using a 1024 OFDM modulation with a SNR of 21 dB. Similar study will be carried out in the actual study in order to improve the HPAV parameters for in vehicle PLC.

As the number of subcarriers increases, the throughput will be better and is given by:

( ) ∑ + = = pu N 0 k k g s R m T T 1 D ( 1 )
where m k is the bits number per sub-carrier symbol defined according to the SNR, R the coding ratio, N pu the number of used subcarriers per OFDM symbol (N p is the FFT size) and (Ts + T g ) the OFDM symbol duration. T s is related to the sampling frequency F s = N p /T s, Tg is the guard interval. The ratio (T s / (T s + T g )) represents the loss due to the guard interval insertion. The increase of the GI will induce a decrease of the data rate and the spectral efficiency. On the contrary, we notice the HD-PLC does not use GI.

B.

HD-PLC The HD-PLC alliance [START_REF]Official website of the High Definition Power Line Communication Alliance (HDPLCA)[END_REF] (HDPLCA) is an additional group which promotes the PLC networks based on its HD-PLC technology. It is based on a specific OFDM modulation called Wavelet-OFDM which exploits the Wavelet transform. It appears with this modulation that the notches are deeper than OFDM realized with IFFT/FFT. Moreover, Wavelet-OFDM does not use guard interval and so it has a better spectral efficiency than OFDM modulation. Pulse-Amplitude Modulation (PAM) with a order from 2 to 32 is used for modulation. The MAC layer uses the hybrid TDMA and CSMA/CA protocols synchronized with the AC line cycle. This solution seems to be very promising for vehicle PLC and may fulfil the vehicle channel requirements (coherence bandwidth for example). These two standards are tested in the next Section and discussed.

C.

Spidcom Spidcom has built modems using OFDM and studied for car in [15]. The frequency range is [2 -30] MHz with an original division in 7 independent sub-bands of 128 carriers each. A tone ordering is applied on each sub-carrier. Moreover, the FEC is a convolutional coder combined with a Reed Solomon coder. Such system can provide up to 10 Mbps throughput (Front-Front path) taking into account the EMC requirements. However, they do not have been selected for standardization by the P1901 group.

V. PLC OVER VEHICLE DC CHANNELS

In this section, we will give some comparison between the two main standards, namely HPAV and HD-PLC. We will focus on some perspectives.

A. HomePlug AV and HD-PLC spectrum

We have measured the two spectrums over the DC channels according to the configuration presented in [START_REF] Tanguy | Implementation of vehicular high speed power line communication system[END_REF]. Fig. 5 illustrates these two spectrums. The input impedance has not been yet modified and the transmitted OFDM waveform is not EMC compliant. We can observe that HD-PLC presents deeper notches than HPAV with a less emission power. The measurements have been performed with the same configuration (e.g. similar path, equipments OFF, motor ON); however the impedance of the modems may be different. It is not possible to use the two protocols at the same time as they have non-interoperable PHY layers.

B. HomePlug AV and HD-PLC throughput

The throughput has been measured using UDP traffic. For Front-Rear paths, we obtain about 15 Mbps/s for both systems. For Front-Front paths, the mean data rate is about 15 up to 25 Mbps. The highest one is 40 Mbps using the shortest Fron-Front path. We have noticed very low variations when the electronic units are in active use and the engine is driven. These results are better than the previous ones obtained in [15] [16]. In fact, the enhanced OFDM HPAV loads each tone according to the SNR for each connection between transmitter and receiver (e.g., modulation per tone and cyclic prefix length). Furthermore, the coding schemes (Turbo or LDPC) have better performances than RS or convolutional codes used in HomePlug V1.0. However, even these results present great challenges for PLC in automotive, we need to focus on different technical requirements and next steps.

C.

Discussion about PLC solutions. 1) Static notches : We have seen that notches are required to avoid interferences with amateur bands. Such notches are not necessary in vehicle environment. On the contrar, we have to take care with the upper FM band (80-100 MHz) and EMC constraints. Notches may be created dynamically through configuration according to the channel environment (detection of narrow radio band for example).

2) EMC requirements: The level of the transmitted signal need to be reduced and will induce a loss of throughput. Howver, the transmission bandwidth can be extended up to 50 MHz as no overall drops occurs.

Figure 1 .Figure 2 .

 12 Figure 1. Channel measurement, short length Front -Front Area ( D1D3 : direct, D2-D1/D3 indirect), from [16]

Figure 3 .

 3 Figure 3. Indoor Channel measurement, from [20]-COST 2005, slide Number 14, bandwidth 0-30 MHz

Figure 4 .

 4 Figure 4. Automotive Power Spectrum HomePLug and CISPR requirements ( dBµV) Those results can be compared with the previous ones obtained with other wide band PLC modems tested in cars [1, Chapter IV]. In this study, the access impedance has been optimized in order to both fulfil EMC constraints while achieving up to 15 Mbps data rate for different paths.

Figure 5 .

 5 Figure 5. HD-PLC versus HPAV over vehicular power lines

ACKNOWLEDGMENT

This work is carried out in the CIFAER project, initiated and supported by the ANR and the French Premium Cars Competitiveness Cluster. [17] Nouvel, F., Maziéro P., "X-by-wire and Intra-car communications: power line and/or wireless solutions". IEEE International ITST Conference, ITST 2008, pp 1-4, 2008 [18] M. Lienard, M. Carrion, V. Degardin, and V. Degauque, "Modeling and analysis of in-vehicle power line communication channels," IEEE Trans. Veh. Technol., vol. 57, no. 2, pp. 670-679, Mar. 2008.

4) Mac layer:

The two networks use a master-slave architecture. This master (chosen or fixe) authenticates the nodes and may assignes dynamic or static slots. For vehicle application, it seems to be better to identify a static master, always in active use.

Additionnal PLC nodes will be considered as slaves.

[11] T. Huck, J. Schirmer, T. Hogenmuller, and K. Dostert, "Tutorial about the implementation of a vehicular high


Fabienne Nouvel
email: fabienne.nouvel@insa-rennes.fr

Philippe Tanguy

Future high speed in-vehicle PLC networks

Keywords: HomePLUG AV, HDPLC, in-vehicle, EMC

This paper deals with power line communication in vehicle (PLC). PLC is a very promising communication solution in order to offer future in-vehicle applications without increasing wiring harnesses. We join recent additional measurements which have been carried out using modified indoor PLC modems. These PLC modems are based on the two main technologies, HomePLUG AV and HDPLC.

I. INTRODUCTION

HE in-vehicle PLC solution has numerous advantages, notably in terms of reliability, because it would reduce the amount of splicing that is necessary, as well as simplify and lighten the cable bundles. Today, indoor PLC is a common way of communication in local area networks and a lot of modems based on HomePlug are on the market. A theoretical bit rate of about 200 Mbps can be achieved. This is the reason why for automotive applications, a PLC solution may be studied by car manufacturers. Indeed, the ever growing development of safety and comfort equipments needs high bit rate and this also leads to an increase of the communication wires with a negative impact on reliability. The possible applications of automotive PLC are very wide, extending from high-speed multimedia buses for entertainment systems to low-speed data buses for activating. actuators. Mock-ups are being developed in the automobile industry to demonstrate the feasibility of the PLC approach. The studies carry out in [START_REF] Gouret | High data rate network using automotive powerline communication[END_REF] have lead to a demonstrator based on a video transmission between a camera at the back of the car and a screen placed on the dashboard. However, to our knowledge, there are no cars that are currently available in the market that use PLC data exchanges instead of dedicated buses. Many studies are carried out today as presented during the conference ISPLC 2009 [START_REF] Mohammadi | Measurement Study and Transmission for In-vehicle Power Line Communication[END_REF]. Previous work [START_REF] Nouvel | X-by-wire and intra-car communications: power line and/or wireless solutions[END_REF] has demonstrated the feasibility of PLC in vehicle. The recent workshop held in Italy [START_REF]WORKSHOP Fieldbuses for automotive and the powerline alternative[END_REF] is aimed at presenting the state of the art in communication systems in a modern car, in order to optimize and reduce the cabling on board. Some useful results expected from the workshop are: a general layout of a useful benchmark; the specifications expected from a PLC based protocol to meet the automotive requirements; a list of significant experiments aimed at defining the viability of a PLC solution. In this paper, we focus on the comparison between two PLC technologies, namely HomePlug AV (HPAV) and HDPLC; T I. EXISITING POWER COMMUNICATION SYSTEMS: IN-VEHICLE COMPATIBILITY?

The enhanced HomePlug V1.0 is the HomePlug AV (HPAV) standard with an OFDM modulation realized thanks to a 3072 points IFFT/FFT with a frequency sampling of 75 MHz. In this case the OFDM symbol duration is 40.96 μs and the space between each carrier is 24.414 kHz. The HPAV uses higher modulation order from BPSK (Binary phase-shift keying) up to 1024 QAM than HomePlug V1.0. Moreover, several guard interval (GI) can be used depending on the channel and so the data rates can be improved. Previous results [START_REF] Lienard | Modeling and analysis of in-vehicle power line communication channels[END_REF] obtained show that the median values of coherence bandwidth (Bc) are 1.3 MHz and 700 kHz for in-vehicle direct and indirect connections. If we consider the delay spread (DS) and the GI, the authors report that the Ds remains under 380 µs for all the cases. This delay is longer than the [START_REF] Mohammadi | Measurement Study and Transmission for In-vehicle Power Line Communication[END_REF][START_REF] Nouvel | X-by-wire and intra-car communications: power line and/or wireless solutions[END_REF][START_REF]WORKSHOP Fieldbuses for automotive and the powerline alternative[END_REF][START_REF] Lienard | Modeling and analysis of in-vehicle power line communication channels[END_REF]µs Ds obtained in indoor (it can also be on the order of some microseconds as in the cars). Generally, the GI duration should be about two to four times the DS. If we compare the HPAV parameters with the Bc and Ds constraints, we can observe that they fulfil them The HD-PLC alliance [START_REF]Official website of the High Definition Power Line Communication Alliance (HDPLCA)[END_REF] (HDPLCA) is an additional group which promotes the PLC networks based on its HDPLC technology. It is based on a specific OFDM modulation called Wavelet-OFDM which exploits the Wavelet transform. It appears with this modulation that the notches are deeper than OFDM realized with IFFT/FFT. Moreover, Wavelet-OFDM does not use guard interval and so it has a better spectral efficiency than OFDM modulation. Pulse-Amplitude Modulation (PAM) with an order from 2 to 32 is used for modulation. The MAC layer uses the hybrid TDMA and CSMA/CA protocols synchronized with the AC line cycle. These two standards have been tested in vehicle according to many configurations and discussed in the next section.

II. RESULTS :HPAV VERSUS HDPLC

We have measured the two spectrums over the DC channels according to the configuration presented in [START_REF] Nouvel | X-by-wire and intra-car communications: power line and/or wireless solutions[END_REF]: ignition OFF, ignition ON, ignition ON and equipments, paths Rear-Rear, Front-Rear, Front-Front. Other configurations have been considered and will be presented in the final paper. Fig. 1 illustrates these two spectrums.

HPAV HDPLC

The input impedance has not been yet modified and the transmitted OFDM waveform is not EMC compliant. We can observe that HD-PLC presents deeper notches than HPAV with a less emission power. We can notice that it is not possible to use the two protocols at the same time as they have non-interoperable PHY layers. The throughput has been measured using UDP traffic. For Front-Rear paths, we obtain about 15 Mbps/s for both HPAV and HDPLC. For Front-Front paths, the mean data rate is about 15 up to 25 Mbps. The highest one is 40 Mbps using the shortest Fron-Front path. However, we have noticed a little throughput decrease on the long paths when the electronic units are in active use and the engine is driven with HDPLC, not observed with HPAV. This decrease can be explained by the lack of GI in HDPLC. However, these results are better than the previous ones obtained in our previous study on HomePlug V1.0 and Spidcom modems.

III. CONCLUSION

The adaptation of PLC to vehicles holds great promises. It is possible to achieve high throughput as well as existing vehicle networks (FLEXRAY) suited for different applications (multi-media, safety). Different adaptations of indoor PLC will be proposed in order to fulfil vehicle constraints (EMC, synchronization). They cope both with the MAC and PHY layers.

ACKNOWLEDGMENT

This work has been carried out in the CIFAER project, initiated and supported by the ANR and the French Premium Cars Competitiveness Cluster.


Romain Delamare
email: romain.delamare@irisa.fr

Benoit Baudry
email: benoit.baudry@irisa.fr

Yves Le Traon
email: yves.letraon@enst-bretagne.fr

Regression Test Selection when Evolving Software with Aspects

Aspect-oriented software evolution introduces new challenges for regression test selection. When a program, that has been thoroughly tested, evolves by addition of an aspect, it is important for regression test selection to know which test cases are impacted by the new aspects and which are not. The work presented here proposes a classification for regression test cases and introduces an algorithm for impact analysis of aspects on a set of test cases. A major benefit of this analysis is that it saves the execution of test cases that are not impacted.

INTRODUCTION

When software evolves, it is necessary to perform regression testing in order to check that no unexpected change has been introduced. A major challenge for regression test selection techniques is to identify the subset of test cases for one version of the system that must be re executed to validate an evolution of the system. It is very important to precisely identify this subset since executing the whole test suite is very time consuming in the case of large software systems. Also, a selection technique must distinguish between the test cases that can be kept unchanged (that can be re executed as they are for regression testing) and the ones that must evolve (to take changes into account). Several techniques have been proposed for regression test selection in the context of object-oriented programs [START_REF] Leung | Insights into regression testing[END_REF][START_REF] Orso | Scaling regression testing to large software systems[END_REF][START_REF] Rothermel | Analyzing regression test selection techniques[END_REF][START_REF] Vokolos | Pythia: a regression test selection tool based on textual differencing[END_REF]. Here we are interested in regression testing in the context of aspect-oriented software evolution.

In this paper, we propose an impact analysis of aspects on test cases, as well as a classification of regression test cases. The analysis identifies the test cases that can cover a part of the system where an aspect is woven. These test cases are called impacted test cases. The test cases that are not concerned by the aspect weaving are called non-impacted test cases. This impact analysis provides the necessary informa-tion for regression test selection.

The impact analysis is performed statically, which avoids executing all the non-impacted test cases. In the first step of the analysis, the aspect and the base program are analyzed in order to identify which base methods are impacted by the aspect's weaving. Second, the static call graph is built for each test case. The graph is then analyzed to check whether it contains an impacted method.

Once the impacted test cases have been identified, we run them in order to get a verdict for each of them. The test cases that are impacted by the change but that still pass are of particular interest for us. This verdict can be interpreted in several ways. Either the aspect has no effect on the behaviour that is evaluated by the test case; or the aspect adds behaviour without modifying the previous one. When this happens, the test case still passes but its oracle function does not evaluate the behaviour added by the aspect. The test case should then be modified and re-executed in order to validate the evolution introduced by the aspect. The test cases that are impacted and that still pass can be automatically identified, but the analysis to know if they must change has to be performed manually.

The paper is organized as follows. Section 2 describes the general principles for the impact analysis we want to perform for regression testing selection. Section 3 presents the classification of test cases and discusses the meaning of each class of test case for regression testing. Section 4 goes into the detail of our solution for regression test selection. Section 5 discusses related works and section 6 concludes.

Relevance to LATE topics

The approach presented in this paper is related to aspect evolution and software evolution with aspects. Our technique leads to better evolvable aspects because it eases the validation of the evolutions thanks to a safe regression test selection. Regression testing has two purposes in this situation: it is a necessary step for validating the evolutions; it helps getting confidence that the introduced evolutions do not disturb existing behaviour. Thus, this approach can also be used to validate the preservation of certain behaviours after the addition of a new aspect or the evolution of an aspect already woven: it selects the test cases that must be executed to validate this behaviour preservation. and we introduce the global objectives of an impact analysis in case of aspect oriented evolution.

IMPACT ANALYSIS

Test cases

The starting point for the impact analysis proposed in this paper is a base program with its associated unit and system test cases. Our goal is then to analyze which test cases are impacted by the introduction of an aspect in the base program. Before we define what we mean by an impacted test case, we briefly present the structure of the test cases that we consider. It is important to understand this structure in order to understand the different ways an aspect can impact a test case. The analysis we propose is dedicated to Java programs, thus the base program is implemented in Java and the test cases are implemented with JUnit. All test cases conform to the same structure defined in the following.

Test cases.

A test case is composed of three parts.

• The first part of the test case is the preamble, which puts the system in a certain state required by the test scenario.

• The second part actually executes the method under test with the test data.

• The third part is the oracle, composed of a set of assertions. The test case fails if any of the assertion of the oracle fails.

The following test case example is a unit test for the pop method of the class Stack:

1 @Test public void testPop2() { It is important to note that in most cases the oracle (the set of assertions) cannot be exhaustive and is only partial: it is too expensive to check that the expected behavior occurred and nothing else occurred. For instance, in the previous example the oracle just checks if the result of pop is correct but it does not check if the stack is empty as it should be after the call of pop.

Objective of the impact analysis

The main objective of this work is to determine what test cases should be kept unchanged, what test cases should be modified, and what test cases should be removed in case of aspect oriented evolution. This analysis starts by detecting the methods in the base code that are impacted by an aspect. Then, a test case is detected as impacted if it can reach an impacted method.

Impacted method.

An impacted method is a method where an aspect is woven. Thus, a method is impacted if it includes a joinpoint shadow where an advice is woven. For instance if a pointcut matches every call to a method m, then the methods that call m are impacted. If a pointcut matches every execution of m, then m is impacted. Figure 1 shows an example that implements an integer Stack in Java (adapted from Xie et al. [START_REF] Xie | A framework and tool supports for generating test inputs of AspectJ programs[END_REF]) and Figure 3 displays an aspect called NonNegativeArg. In this example, the NonNegativeArg aspect impacts the push method because its pointcut expression matches every execution of push, so its advice is woven within push.

Impacted test case.

An impacted test case is a test case that can possibly execute at least one impacted method according to the previous definition. Let M (tc) be the set of all the methods statically reachable by a test case tc and I(a) the set of all the methods impacted by an aspect a. A test case tc is impacted if and only if ∃a, M (tc) ∩ I(a) = ∅.

Figure 2 shows three JUnit test cases for the Stack class. The push method is impacted by the NonNegativeArg aspect, so the testPush and testPushArray test cases are impacted:

• testPush calls an impacted method

• testPushArray calls the pushArray method which calls push which is impacted A test case can be impacted by an aspect in several different ways. The preamble may not achieve to put the system in the correct state. For instance in the example of section 2.1, if an aspect only allows pushing an integer in a stack under certain conditions, the integer might not be pushed as expected. The aspect might modify the behavior of the method under test and the result is not the same, so the oracle is not correct, or a behavior has been added, and the oracle must be extended. The input domain of the method under test may also change, so the input data may not be correct anymore.

Next section introduces the different classes of test cases that our analysis can identify and section 4 details the static analysis that we perform in order to determine the set of impacted test cases.

CLASSIFICATION OF TEST CASES

Depending on whether they are impacted or not and whether they pass or not we classify the test cases as presented in the following.

Classification definition

We define a first level for the classification: Not Impacted(NI) and Impacted(I) test cases. The NI class is the class of test cases that are not impacted by the aspect. On the contrary, the I class is the class of the test cases that are impacted according to the previous definition. Those two classes are exclusive and can be computed statically. At a second level of classification, the I class is divided into two subclasses:

Impacted Passing(IP) and Impacted Failing(IF) test cases.

The IP class contains the test cases that are impacted and that still pass, i.e. the assertions for the oracles are all satisfied. The IF contains the test cases that are impacted and fails.

This classification has two benefits. First, test cases classified as NI do not need to be executed for regression testing after the aspect weaving. As we discuss it in section 4, the classification of NI and I test cases is performed statically, thus the test cases that are not impacted by the aspect are never executed. Second, the distinction between IP and IF also offers valuable information for regression testing. In particular, a test case that is impacted and that still passes (IP) must be carefully studied. It is important to check if the test case still passes because the aspect has not changed the behavior it evaluates or if it passes because its oracle is too weak and does not consider the new behavior inserted by the aspect.

Classification exploitation

Once the test cases have been classified we can determine whether they should be modified, removed or kept unchanged. This section describes how to consider the test cases according to their class.

It is not necessary to execute the test cases of class NI. As we are sure that they are not impacted, if they passed before the weaving of the aspects, they should still pass. It is a major contribution as it may save a lot of time in large systems.

The test cases in class IP can evolve in three different ways, depending on the oracle. It is important to check the oracle because it might have become too weak. As discussed before the oracle is usually partial and some properties added by the aspect might not be checked. When it is the case, the test case can evolve to fail -assertions are added to the oracle and at least one of them fails -or it can evolve to pass -assertions are added and they all pass. When evolving, a test case checks new properties added by an aspect. If the test case fails there is probably an error in the aspect. The oracle may also not need any change and the test case is kept unchanged.

For the test cases of class IF the tester must focus on the input data. If the input data of a IF test case is still in the input domain of the method under test then the expected result must have change and the test case can evolve by correcting the oracle. If the input data is no more in the input domain, then it should be removed.

Table 1 shows a summary of the test case classification with the different possible evolutions.

In the Stack example, Figure 2 shows three test cases. Test case testPush is impacted as it calls an impacted method, push. When executed this test case fails as it calls push with a negative argument so it is in class IF. This test case should be removed as its input data is no more in the input domain of the method under test. Test case testPushArray is impacted too but still passes so it is in class IP. There is nothing new to check so the oracle is still good and this test case should be kept unchanged. Finally test case testPop is not impacted so it is kept unchanged

STATIC REGRESSION TEST SELECTION

To distinguish between NI and I test cases, we statically analyze the Java base program, the aspects and the test cases.

Thanks to the pointcut expression we can statically know in which methods the aspect is woven. The analysis thus consists of two steps. First, we build a model that captures the relationships between aspects and the base code. Then we analyze the static call graph of each test case in order to determine if they are impacted.

Impacted methods model

When a Java program and an aspect are compiled with the AspectJ compiler, the joinpoints where the aspect has to be woven are statically identified. To evaluate the impact of the aspects on the test cases we build a model that represents the relationships between the aspects and the base code.

Figure 4 shows the metamodel we have designed to capture impacted methods. A system is composed of a set of methods and a set of aspects, and there is a relation between the aspects and the methods that represents the fact that an aspect is woven within the code of a method.

We have extended the AspectJ compiler in order to build an instance of this metamodel. The AspectJ compiler compiles the Java classes and weaves the aspects, directly generating woven byte code. The compiler offers an interface to add a build listener (which is called after each compilation). The compiler then provides a list of weaving relations between the aspects and the different parts of the Java code where the aspects are woven. We use those information to build the impacted methods model.

As an example, figure 5 shows the model corresponding to the stack example, in the form of an object diagram. This model contains an instance of class Method for each method of Stack and an instance of Aspect for the aspect NonNegativeArg. As seen before, the advice of NonNegativeArg is woven within Stack.push, so there is a relationship between the two instances.

Static call graph

The second step consists in checking if a test case can reach an impacted method or not. This requires knowing the methods that are reachable by the test case. The adopted solution relies on a static call graph that allows us to know which methods are reachable by a test case.

Static call graph.

A static call graph is a pair (N, A) where:

• N is a set of nodes that model methods in the system, each method being represented by only one node.

• A ⊂ N × N is a set of edges that represent potential calls. If n1, n2 ∈ N respectively represents the methods m1 and m2, then n1 × n2 ∈ A means that m1 potentially calls m2..

The notion of potential call is related to polymorphism. Figure 6 shows a class diagram where C1 is a class defining a method m and C2 and C3 are two classes inheriting from C1 and overriding m. The testing class TestC has a test that calls m on an object declared with class C1, but in the general case we cannot know statically know which is the actual type of the object at runtime and which method is actually executed. That is why testM can potentially call C1.m, C2.m and C3.m. Figure 7 shows the static call graph of testM.

To determine if a test case is impacted we then traverse its static call graph. For each encountered method we check refer to the impacted methods model to know if it is impacted by an aspect. For instance in the static call graph of Figure 8, which shows the static call graph of the testPushArray test case, the Stack.push method is called, and the impacted methods model from Figure 5 shows that there is an aspect woven within Stack.push, so the testPushArray is impacted.

In the example of Figure 6, if we consider that only C2.m is impacted, as it is reachable by testM (Figure 7), we consider testM as impacted. This is an overapproximation as we cannot be sure that C2.m is actually executed by testM.

This overapproximation of the methods reachable by a test case allows us to guarantee that the test cases detected as non-impacted are actually not impacted. This overapproximation is also the only way to perform a static impact analysis that allows us to never execute the non-impacted test cases. This overapproximation also ensures that all impacted test cases will be detected. Thus, this static analysis allows us to perform a safe regression testing selection as defined by Rothermel et al. [START_REF] Rothermel | A safe, efficient regression test selection technique[END_REF]. All test cases that have to be executed for regression testing are identified in the set of I test cases.

RELATED WORKS

AOSD introduces a number of challenges for testing. For instance it is difficult to unit test an advice as it should be woven within a base program to be executed. For this reason the testing techniques for object-oriented programs cannot be directly applied on AOSD programs.

Xu et al. [START_REF] Xu | Regression test selection for AspectJ software[END_REF] have extended a regression test selection technique for Java introduced by Harrold et al. [START_REF] Harrold | Regression test selection for Java software[END_REF] to take aspects into account. Their approach is based on a specialized control-flow graph, called AJIG that extends the JIG introduced by Harrold et al.. This approach requires the construction and traversal of two CFGs, one for each version of the program.The impacted edge are identified during the traversal, and if a test case exercise an impacted edge it is rerun. The contribution of this work is the identification of the test cases that do not need to be executed, which our approach allows too, but on the contrary to our work they do not consider the evolution of the impacted test cases.

Xie et al. [START_REF] Xie | Detecting redundant unit tests for AspectJ programs[END_REF] have introduced a framework for detecting redundant unit tests in AspectJ programs. Aspects are usually unit tested in the context of the impacted classes as it not possible to execute them alone. So it is possible to use automated test generators for Java to test AspectJ aspects, but they produced a lot of redundant test cases. The framework proposed by Xie et al. removes the test cases that do not exercise a new behavior. This approach could be applied to regression testing as the introduction of an aspect can introduce redundancy in the test cases.

CONCLUSION

In this paper we have presented a classification for regression test cases in case of aspect-oriented evolution. This classification distinguishes the test cases that are not impacted by the aspects (class NI) from the test cases that are impacted by the aspects (class I). We have also pro-posed a static analysis to automate the impact analysis of aspect weaving on a set of test cases. This analysis takes advantage of the pointcut expression to evaluate the impact of aspects on the test cases.

In future work, we will completely implement the impact analysis in order to experiment with our test regression selection technique on aspect-oriented programs. We also plan to investigate a refinement of the test cases classification using the aspect classification of Rinard et al. [START_REF] Rinard | A classification system and analysis for aspect-oriented programs[END_REF]. This would improve the evolution of the test cases and the fault localization. For instance the test cases impacted by an augmentation aspect should be executed but they must pass, otherwise we are sure that the fault is localized in the aspect. Also, a a better understanding of the impacts of an aspect will probably help the evolution of the test cases.

Figure 2 :Figure 3 :

 23 Figure 2: JUnit tests for the Stack class

Figure 6 :

 6 Figure 6: Class diagram illustrating the overapproximation with polymorphism.

Figure 7 :

 7 Figure 7: The static call graph of testM.

Figure 8 :

 8 Figure 8: Example of static call graph, corresponding to the testPushArray test case.

  The preamble is on lines 3 and 4: a new stack is created and an integer (3) is pushed. Line 5 exercise the method under test: pop is called on s and its result is stored in the local

	public class StackTest {
	Stack stack;
	@Before
	public void setUp() throws Exception {
	stack = new Stack();
	}
	@Test
	public void testPush() {
	stack.push(-3);
	assertEquals(-3,stack.pop());
	}
	@Test
	public void testPushArray() {
	int[] t = {1,2,3};
	stack.pushArray(t);
	assertEquals(3,stack.pop());
	assertEquals(2,stack.pop());
	assertEquals(1,stack.pop());
	}
	@Test
	public void testPop() {
	try {
	stack.pop();
	fail();
	} catch(EmptyStackError e)
	{assertTrue(true);}
	}
	}

3 Stack s = new Stack(); s.add(3); 5 int i = s.pop(); assertEquals(3,i); 7 }

Table 1 :

 1 Summary of the test case classification

	Impact Analysis	Execution Result	Effect
	NI	No need to be executed
			-evolve to pass
		IP	-evolve to fail
	I		-no change
		IF	-evolve to pass -remove


M Monperrus

F Jaozafy

G Marchalot

J Champeau

B Hoeltzener

J M Jézéquel

Model-driven Simulation of a Maritime Surveillance System

This paper reports an industrial experiment made at Thales to use Model Driven Architecture (MDA) for system engineering. System engineering processes are currently mainly document-centric. The main experiment goal was to study the applicability of MDA at the system engineering level. The experiment consisted of setting up a model-driven simulation environment for a maritime surveillance system. The simulation is achieved thanks to 3 models conform to 3 metamodels. The implementation uses the Eclipse Modeling Framework and is written in the Java Programming language. This pilot project met the deadline, the budget and the threshold of desired functionalities. We report the main advances given by the MDA approach in the context of simulation for system engineering.

Introduction

Simulation is a key step in the development of a maritime surveillance system [START_REF] Ince | Principles of Integrated Maritime Surveillance Systems[END_REF]. At the very beginning of the life cycle of the system i.e.; at the system engineering level, simulation is a way to communicate with the customer in order to elicit the needs. Therefore, simulation eases the consistency between the customer requirements and the delivered product. From an engineering point of view, simulation is a way to validate parts of the architecture, as well as the behavior of the product. Last but not least, this permits a better cost estimation and a better planning of technical and human resources.

A maritime surveillance system (MSS) is a multi-mission system. As depicted in figure 1 as a UML use case diagram, it is intended to supervise the maritime traffic, to prevent pollution at sea, to control the fishing activities, to control borders. It is usually composed of an aircraft, a set of sensors, a crew and a large number of software artifacts. The number of functionalities, the relationships between hardware and software components and the communication between the system and others entities (base, other MSSs) indicate the complexity of the system.

Maritime surveillance system designers have been developing simulators for several decades. Current simulation methods, sometimes processed at early stage of design through technico-operational simulations, do not fully warranty the Fig. 1. Use cases of a maritime surveillance system design quality. Because there is no link between the system model checked by simulation and the system design. Moreover, the techniques used did not meet the required openness for reuse and modifiability. One of the key point of a simulator is to let the end-user, the customer, to test as many versions of the product as needed, and to let the engineers to add easily new features wanted by the customer.

In this paper, we report an industrial experiment we made to develop a new simulator for maritime surveillance systems following a Model Driven Architecture (MDA) approach [START_REF] Soley | Model driven architecture[END_REF]. The innovation did not reside in 1) new functionalities since the new simulator does not have more functionalities than the legacy ones 2) neither in the modeling activities since simulation has always been based on simulation models. The explored innovation consisted in the use of MDA.

The main goal of this experiment was to study the applicability and the advantages of MDA for system engineering activities. The experiment was a success. We mainly found that the MDA principles enable:

to keep a complete independence between different concerns that are system architecture, simulation scenarios, and simulation-based analysis. -to align the system engineering model and the simulation model which can be both explicitly specified.

The paper is organized as follows. In section 2, we present the design of the model-driven simulator. We then present the lessons learned in section 3 and conclude.

The design of the model-driven simulator

Our model-driven simulator was built following the process as follows: 1) identify the domain objects to be modeled; 2) elaborate the corresponding metamodels; 3) design the simulator; 4) develop the simulator.

The remainder of this section does not follow this chronological process. For sake of understandability, we will first present the architecture of the simulator, the metamodels and models used, and we conclude by exploring more in depth how we leverage model orientation in a simulation point of view. In figure 2 is depicted the architecture of the model-driven simulation process. The backbone of the simulator is the Y pattern depicted as bold lines. The simulator takes as input two models: a model of maritime surveillance system and a model of the tactical situation, called a scenario model. It outputs a model of simulation traces. The three models are specified by three metamodels respectively. The contents of these metamodels are presented in the next sections.

The model-driven simulation process

This architecture is built on two model-driven principles: 1) all data are exchanged as models specified by a metamodel 2) the domain concepts are kept independent of implementation concerns. This is slightly different from the Platform Independent Model (PIM) / Platform Model (PM) / Platform Specific Model (PSM) of the seminal MDA paper [START_REF] Soley | Model driven architecture[END_REF]. However, the architecture follows exactly the same principles. To a certain extent, the MSS model corresponds to a PIM, the scenario model to a PM and the simulation trace model to the PSM.

This architecture has several desirable properties. All the variability of the simulator is encoded into models. For instance, adding a given radar, or changing a feature of the radar to the maritime surveillance system is made by modifying the input MSS model.

The MSS model and the scenario model are not coupled at all. Therefore, we can create several MSS models, several scenario models and study the comportment of each system in each scenario.

The graphical output of the simulator is absolutely not coupled with the simulation rules. This property enables to easily have many tools that analyze the simulation output. That is to say, we have one and only one interface for plugging modules to the simulator. In such a model-driven architecture, the interface is a model, and is fully, consistently specified by a metamodel, the simulation trace metamodel. This point is further explored in section 2.3.

The metamodels and models used

Maritime surveillance system metamodel The maritime surveilllance system metamodel is divided in five packages. The criterion used to create the packages is a functional decomposition. The navigation system package contains classes whose roles are to represent routing and positioning components (hardware, software and composite). For instance, there is a GPS 1 class. The attributes of this class are the main characteristics of a GPS.

The detection package contains classes representing detection components of a MSS. For instance, the MSS model can be simulated with a classical radar, a IFF (Identification Friend and Foe), a FLIR (Forward Looking Infra Red). The attributes of a model of the radar include the antenna angle, the rotation speed, the impulse period.

The communication system package explicit the communication type and systems that will be simulated with the model. It ranges from internal communication between the crew members and external communications. The classes covers the communication support (e.g. VHF, IHF, satellite) and communication properties (encryption, protocols).

Finally, the crew package contains classes to specify the number of crew members, their respective skills and their functions. The database package acts like a schema of the embedded database of tactical information (e.g.; radar signatures).

The model mainly used for testing purpose represents a maritime surveillance system composed of an airplane Falcon, embedding a radar and an inertial system.

Scenario metamodel

The scenario metamodels contains all the needed classes to represent a tactictal situation. A model, instance of this metamodel, specifies the surveillance zone, the number and types of objects that are in the zone. For each object is specified a trajectory including the speed of the object. Furthermore, at the system engineering level, and for simulation purposes, we had to specify the concept of surface equivalent radar (SER) per object and the concept of weather for a given zone. During the simulation, the weather is used to compute the quality of the information given by the embedded sensors.

Simulation trace metamodel

The simulator takes two models as inputs: a MSS model and a scenario model. Then according to the semantics of the simulation, it outputs a simulation trace. Following a model-driven approach, this simulation trace is a model too, specified by a simulation metamodel.

The simulation traces contain all the events that have a semantic with respect to the simulation at the system engineering level. They are :

the position of the MSS system; -the position of every objects of the zone; -the internal attributes of the MSS: fuel, detection field of the radar; -the semantic events, for instance the detection and identification of the objects achieved by the system core.

In the next section, we show how we use this information to leverage as much as possible of the information given by the simulation. The core of a model-driven simulator is to specify all inputs and outputs with metamodels. To a certain extent, each of these metamodels specify an interface. This enables to introduce a kind of composition between the simulator functions. The MDA architecture of the simulator presented in figure 2 illustrates this point.

Leveraging model driven orientation

However the architecture goes far beyond. The simulation part of figure 2 contains only the simulation rules that represent the interactions between the model and the scenario. The architecture enforces that no analysis is done during this phase.

Our idea is to consider that any treatment on the simulation output could be absolutely decoupled of the rest of the application. The treatments are mainly visualization and measurement. However, there are several possible visualization as well as several measurements. We encapsulate each of them into a simulation analysis component, that takes as input a simulation trace model specified by the simulation trace metamodel. This is depicted in figure 3. We apply this design principle to several simulation analysis components.

The first component is a video player of the simulation events contained in the simulation trace model. It outputs the tactical view of the zone of surveillance. A screenshot of this player is given figure 4. The main screen is a 2D representation of the zone, with a geographic map, the maritime surveillance system (the yellow dot), the objects of the zone (several boats represented as orange dots), and the detection field of the radar, which is not visibe due to the size of the figure. In the upper bar, there are the indicators of the simulation characteristics (time, position and fuel consumption of the MSS). In the left bar is a list of the tactical events that occur, for instance ship detections. The remaining items are widgets to control the simulation (play/pause/stop buttons). The scale that controls the speed of the video player lets to play the scene at a speed different of the simulated time. This simulation component is a demonstrator to communicate with customers as well as to illustrate the impact of a certain system design choice. Since we already have human training processes using simulators, we developed an another simulation analysis component to represent the view of a radar operator. The last simulation analysis component computes several domain met-ric values such as the ratio of detected objects or the ratio of identified objects. This component is generated from an abstract specification of domain metrics, thanks to a dedicated framework developed in another project [START_REF] Monperrus | Measuring models[END_REF].

Finally, since the simulation analysis components are decoupled from the simulation itself, we plan to reuse these components to analyze some traces of real missions. This will enable to elaborate powerful processes for training and debriefing, as well as analyzing real missions in order to improve future versions of the simulator.

Lessons learned

First of all, this project to apply MDA at the system engineering level was a success. The project met the deadline, the budget and the threshold of desired functionalities. This validates the MDA as an architectural principle for a maritime surveillance system simulator.

Productivity gain Our experiment gives some clues about a potential MDAspecific productivity gain. First of all, we obtained the prototype within six months of work of a junior engineer. The technologies used were the Eclipse Modeling Framework [START_REF] Budinsky | Eclipse Modeling Framework[END_REF] coupled to Java to implement the simulator. Thanks to the totally generated EMF model editor, we could right away, and for free, give the system engineers, who are not necessarily computer scientists, a tool to express the models. This is to be compared with the legacy simulators where a specific graphical user interface had to be developed to specify the models involved in the simulation.

An agility problem

The main disadvantage of EMF is the code generation step. Code generation is not a problem when one does not have to modify or enrich the generated source code (e.g.; a classical mature compiler). But in the EMF case, some methods and method bodies have to be added into the generated code. Our metamodels were very volatile during the prototyping phase, hence required many code re-generation and the associated method modifications. On the one hand, this hampers the agility of the development process. On the other hand, some re-generations were destructive, i.e; destroyed manually added code, due to the number, the complexity and the sensitivity of the generation parameters. This problem was partially addressed with a source revisioning system.

Separation of concerns

The MDA achitecture of the simulation process enables a real separation of concerns. The variability of a MSS simulator lies in the system architecture, the simulation scenarios, the kinds of post-simulation analysis. All the variability of the models is explicitely concentrated into different metamodels. There is no dependency links between the metamodels hence we obtained a total independence between concerns. This architecture is totally open w.r.t. system models, scenarios and analysis; e.g.; we are able to test different scenarios with a same model or perform different analysis from a same simulation.

Early model alignment The real innovation of our experiment was the metamodeling of the domain of maritime surveillance systems. Thanks to this step, the creation of a model involves only domain concepts and is not polluted by implementation concerns. This was perceived as highly valuable: the system engineering model facilitates the communication between the different stakeholders (a kind of mental alignment); it can be linked to a design model; and it is totally aligned with the simulation model by construction.

Conclusion and perspectives

In this paper, we presented our experiment to apply Model Driven Architecture at the system engineering level. The experiment consisted in developing a model-driven simulator for maritime surveillance systems. This experiment was a success and raises new issues, which will be explored in further R&D projects.

First of all, the domain metamodel can be seen as the specification of a domain specific modeling language (DSML). We will explore the ways to leverage the metamodel with a dedicated human-machine interface that supports an intuitive concrete syntax for the models. Thus, we would have a intuitive and usable modeling backbone to support the system engineering process.

The core of the simulator is an interpreter of a domain model, achieved by dedicated transformation of two models (MSS and scenario) into a simulation trace model. For prototyping and efficiency reasons, it was implemented in Java. We would like to evaluate the relevance of transformation languages in our case, with respect to the requirements specific to simulation.

The product line of maritime surveillance systems is highly driven by the need for composability. We are exploring how to express this composability within the MDA architecture of the simulator. Studies will be made to explore various solutions, e.g.; expressing the composability directly into the maritime surveillance system metamodel, or building a set of composable models of maritime surveillance systems.

Finally, the great promises of MDA for system engineering would have to be compared to other approaches within a controlled comparative experiment, which was not the goal of ours.

Fig. 2 .

 2 Fig. 2. The MDA architecture of the simulation process

Fig. 3 .

 3 Fig. 3. Usages of the simulaton traces

Fig. 4 .

 4 Fig. 4. Screenshot of the model-driven video player


M Monperrus

J-M Jézéquel

J Champeau

B Hoeltzener

In: Proceedings of the 4th European Congress on Embedded Real Time Software

As with other software development processes, model-driven engineering of real time software systems include quality assurance and measurement. Model-driven engineering (MDE) supports the development of real-time software systems by means of a set of languages, processes, methods and tools. To measure the models, a dedicated measurement software has to be developed, which is costly. In this paper, we propose a framework to concisely define and automatically implement an open-ended family of metrics for real time software systems. The overall contribution of this approach is to give an instant, reliable and low cost implementation of model metrics seamlessly integrated into modeling tools.

Introduction

As with other software development processes, model-driven engineering of real time software systems include quality assurance [START_REF] Kan | Metrics and Models in Software Quality Engineering[END_REF]. Assessing the quality of a product built from a set of models, involves the measurement of the resulting target. However, to be able to drive the development process all along the life cycle, it is needed to measure the models themselves as well.

Model-driven engineering (MDE) supports the development of real-time software systems by means of a set of languages, processes, methods and tools [START_REF] Schmidt | Model-driven engineering[END_REF]. Domain specific modeling languages (DSML) are specified and built so as to raise the level of abstraction and increase the productivity.

To measure the models, a dedicated measurement software has to be developed, which is costly. Timeto-market and cost constraints do not allow to build an ad hoc metric software. Indeed, the NASA recommends that the cost of measurement should not add more than 2 percent to the software development or maintenance effort [START_REF] Program | Software measurement guidebook[END_REF].

In this paper, we propose a framework to concisely define and automatically implement an openended family of metrics for real time software systems. This framework generates the whole implementation and environment, both integrated into a modeling tool. This framework enables to concentrate only on the conceptual level of the development of metrics. The overall contribution of this approach is to give an instant, reliable and low cost implementation of metrics seamlessly integrated into modeling tools.

The remainder of this paper is organized as follows. In section 2, we explore the research question. We then present our proposal (section 3), applied to the measurement of a large scale AADL model (section 4). We finish with a related work (section 5) and conclude.

Research Question

In table 1, we list the high level requirements of a real time model measurement software. Despite the small number of requirements, each of them hides an intrinsic complexity. For instance, requirement #2 implies to have an open modeling environment, to know its internals and to master the programming languages used to implement it. Indeed, a paper relating industrial experiences of software measurement points out five lessons [START_REF] Van Solingen | Integrating goal-oriented measurement in industrial software engineering: industrial experiences with and additions to the goal/question/metric method (gqm)[END_REF]. The second lesson states that software measurement should focus on a particular area to limit the cost of measurement [...]. Measurement is part of software economics.

Model driven engineering involves models as inputs, and other models or source code as outputs. This generative approach seeks to cut off the development costs. An analysis of the requirements presented in table 1 concludes that they are all addressable by code generation. This is emphasized in the last column of the table. To sum up, our research question is how to reduce the cost of development of real time model measurement software. Our intuition is to leverage model-driven engineering to generate the measurement software from an high level description of what to measure. Yes.

Table 1: Main requirements for a measurement tool.

3 Solution

Architecture

In this section, we present the architecture of model driven measurement software (first introduced in [START_REF] Monperrus | Counts count[END_REF]).

The design of a DSML environment starts with the metamodeling activity. DSMLs are specified by the domain expert with a metamodel which identifies the concepts of the domain and their relationships. The domain expert also knows what needs to be measured. Hence, we propose to give him a way of defining the domain metrics. This is achieved by a metric metamodel that identifies the good concepts for the metric specification. Compared to an ad hoc measurement software development, the domain expert defines the metrics at a higher level of abstraction than code. These two functions are depicted in figure 1.

Figure 1: The domain expert function Tools have to be implemented to create, edit and browse models as well as to check the conformity to the metamodel. However, there exists toolchains that generate this modeling environment conform to a metamodel (e.g. EMF1 / Topcased2 ). We propose to add a module to such a toolchain that compiles the declarative description of metrics directly in the DSML modeling environment to augment it with metrics capabilities. This is depicted in figure 2. • metrics are defined at a higher level of abstraction without caring about how this can be implemented in a DSML modeling environment;

• the implementation of the enhanced editor is generated;

• DSML engineers can edit and measure models in the same environment. To sum up, the whole process is sketched on figure 4. This architecture generates the whole measurement software integrated into a modeling tool. This eventually gives an enhanced modeling environment with metric capabilities.

Metric Metamodel

In this section, we present the metric metamodel. This metamodel comes from the fact that a lot of metrics in the literature are a kind of count metrics, i.e. the number of a given kind of elements. The difficulty is to precisely define the elements that needs We first present the general mechanisms to specify metrics, then the specification of predicates [START_REF] Monperrus | Measuring models[END_REF] in two distinct paragraphs.

In figure 5 is shown the backbone of the metric metamodel. The domain expert defines a Metric-SpecificationSet, composed of MetricSpecification. Since the term "metric" is polymorphic, we use the term metric specification to be opposed to metric values. A MetricSpecification is either a Predicate-MetricSpecification, a ConstantMetricSpecification, that simply handles constant values in metric expressions, and a DerivedSpecification that handle arithmetic operators and more complex ones, e.g. the exponential function (hidden in the figure ).

A PredicateMetricSpecification contains a Predicate. A predicate is a function that takes an object as input and makes tests on it to determine if it has to be counted. Predicates refer to the concepts expressed in the metamodel. The tests are made on types, attribute values and/or referenced objects. A predicate can be as long and complex as needed. The metric value of a PredicateMetricSpecification is the number of elements of a given model that satisfy the predicate. • StringValuePredicate enables to test the value of a slot (e.g. a boolean equals to "false" or an integer equals to "13");

• ContainsPredicate enables to test if a collection contains a model element referred by a variable;

• MultiplicityPredicate enables to test the actual size of a collection (not the multiplicity of the reference in the metamodel);

• LambdaPredicate enables to apply a predicate to all elements of a collection. It is subclassed in Exists and ForAll to express first-order logic quantifiers.

Given that a predicate can be as long and complex as needed and that predicate metrics can be composed together, this metamodel let the domain expert define an open-ended family of metrics. We show in the next sections our implementation choices and apply this framework to an AADL model.

Implementation

Our prototype relies on the following technologies: the metric metamodel is expressed in EMF/Ecore; the metric specification can be expressed as an EMF model, or using Kermeta3 . For each metric specification, a Kermeta program is generated. This Kermeta program is built on top of a metric library, implemented as an aspect on the metric metamodel.

Since, EMF and Kermeta work inside Eclipse, we use the Eclipse API to listen to changes on models files in order to automate the computation of metric values. This prototype is a proof that our approach solves the requirements of table 1 by means of model-driven engineering.

Case study

Our case study consists of the generation of a measurement software for AADL models. We then compute and present the metric values for an open source industrial AADL model. The Architecture Analysis & Design Language (AADL) is a component based modeling language that supports early analysis of a system's architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics [START_REF] Feiler | The architecture analysis and design language (aadl): An introduction[END_REF]. An excerpt of the AADL metamodel is given figure 8. D1 The mean number of processes per device is P 2/P 1;

D2 The mean number of threads per process is P 3/P 2;

D3 The schedulability difficulty indicator is D1 * D2. This is the number of tasks that the scheduler has to manage. Real-time systems architects recommend a strong risk warning to be raised if this metric is evaluated to more than 30;

D4 The load predictability is P 4/P 3. If all threads are periodic i.e., D4 → 0 and if they are well defined in terms of CPU consumption, the load of the device is easily predictable. On the contrary, if they are mainly sporadic or aperiodic i.e., D4 → 1, it is extremely hard to predict the load. In this case, real time systems architects augment their security margins.

For sake of brevity we present only two formalized metric specifications below (in this case study the predicates are written in Kermeta). Note that, the complexity of the predicate depends on the metric and the metamodel architecture. The framework compiles the specification of metrics into a Kermeta program built on top of a Kermeta library. With the proposed framework the declarative specification of metrics is about 40 lines of code, mainly to expressed the predicates in Kermeta. The whole implementation of the generated measurement software is about 1000 lines. Given that Kermeta is more concise than Java, and that the library is the result of our measurement knowhow, the added value of our generative approach to measurement software is significant. The workload of the metric definition by the domain expert is reduced to its formalization in textual or graphical syntax of the metric metamodel. The implementation is entirely automated. This generated measurement software takes the large scale AADL model mentionned above and produce the needed metric values, as shown in table 2. According to architects, the most important metrics are P5, P3, P4. They all indicate that the model considered is manageable in regard to their knowhow. For instance, we note that the schedulability difficulty indicator D3 is less than the empirical upper bound (30). According to project managers, P1, P2 and P3 are important. They need to be saved in a database, in order to ground future development process analysis, cost and risk estimation. This case study illustrated the applicability of our model-driven approach to the measurement of realtime models. The framework is intended to obtain low cost measurement software, not only for AADL, but also for any real time systems metamodel.

Related Works

Metamodels and metrics Misic et al. [START_REF] Misic | From formal metamodels to metrics: An object-oriented approach[END_REF] express a generic object-oriented metamodel using Z. With this metamodel, they express a function point metric using the number of instances of a given type. They also express a previously introduced metric called the system meter. Along the same line, [START_REF] Reissing | Towards a model for objectoriented design measurement[END_REF] extends the UML metamodel to provide a basis for metrics expression and then use this model to express known metrics suite with set theory and first order logic. Our approach also uses object models, set theory and logic. However, our approach is fully executable.

In [START_REF] Tang | Measuring OO design metrics from UML[END_REF], the authors address the issue of model metrics early in the life cycle. Hence, they present a method to compute object-oriented design metrics from UML models. UML models from Rose are parsed in order to feed their own tool in which metrics are hard-coded. We also believe that metrics are needed in early life cycle and the genericity of the predicate based metrics makes it usable for design metrics. But it is also usable at any moment of a product life-cycle, since a step of a design process can be considered as a domain per se.

On the implementation issue, [START_REF] Harmer | An extensible metrics extraction environment for objectoriented programming languages[END_REF] exposes a concrete design to compute semantic metrics on source code. The authors create a relational database for storing source code. This database is fed using a modified compiler. Metrics are expressed in SQL for simple ones, and with a mix of Java and SQL for the others. We also believe that it is needed to access the semantic elements of source code to express metrics. But the implementation presented in [START_REF] Harmer | An extensible metrics extraction environment for objectoriented programming languages[END_REF] is complex and tightly coupled with the source code and the metamodel unlike the predicate based metric and our associated prototype which are metamodel-independent. In [START_REF] Wakil | A novel approach to formalize and collect object-oriented design-metrics[END_REF], the authors use XQuery to express metrics. Metrics are then computed on XMI files. Our implementation relies also on XML. But thanks to the Eclipse Modeling Framework, it has a direct and complete access to the metamodel whereas when considering syntactic XML and XQuery, one has no direct access to the metamodel.

Baroni et al. [START_REF] Baroni | Using OCL to formalize object-oriented design metrics definitions[END_REF] propose to use OCL to express metrics. They use their own metamodel exposed in a previous paper. Likewise, in [START_REF] Mcquillan | Experiences of using the dagstuhl middle metamodel for defining software metrics[END_REF], the authors use Java bytecode to instantiate the Dagstuhl metamodel and express known cohesion metrics in OCL. Our implementation relies on Kermeta which permits OCL-like queries.

Note that the scope of all these works are object oriented metrics. In this paper, the considered metrics are real time model metrics.

Abstraction level for expressing metrics On the genericity of metrics, Alikacem et al. [START_REF] Alikacem | Generic metric extraction framework[END_REF] em-phasize on the need not to hard-code metrics and to express metrics in a generic manner and refer to the proposition made in [START_REF] Mens | A graph-based metamodel for object-oriented software metrics[END_REF]. In this paper, Mens et al. define a generic object-oriented metamodel and generic metrics. They then show that known software metrics are an application of these generic metrics. The predicate-based metric is close to the NodeCount of [START_REF] Mens | A graph-based metamodel for object-oriented software metrics[END_REF]. Since NodeCount aims primarily at computing classical OO metrics such as the number of methods per class, NodeCount has a local view and considers a root node. On the contrary the predicate-based metric is at the model level and considers the model as a whole.

Marinescu et al. [START_REF] Marinescu | Towards a simplified implementation of object-oriented design metrics[END_REF] propose a simplified implementation of object-oriented design metrics with a metric language called SAIL. Logically, some of the key mechanisms of SAIL, namely navigation, selection, set arithmetic are present in the predicates presented in this paper. Compared to them, we leverage generative techniques to integrate the domain-specific metrics into a DSML environment.

Conclusion

The current state of the art of real time systems development is moving toward more high level descriptions of systems. The Architecture Analysis & Design Language (AADL) is one of them. However for AADL, as for any metamodel of real time systems, the developement cost of the modeling environment, as well as its measurement features, has to be controlled.

To address this issue, we presented a way to generate a measurement software for measuring real time models. From a set of metric specifications made by the domain expert, the whole tool is generated and is able to compute metric values right out of the box. To address industrial scale and quality, the proof-of-concept research prototype has to be redeveloped in an future project or partnership in order to generate a whole Java/EMF Eclipse plugin for the model measurement. Moreover, further research is currently made to enrich the metric metamodel and thus widen the space of possible metric definitions.

# Description Generatable 1

 1 The model measurement tool is accessible via a command-line interface. Yes 2 The model measurement tool integrates into a modeling environment. Yes 3 The code includes an API to implement estimation models on top of metrics. Yes 4 The model measurement tool is extensible and gives a way to add new model metrics.

Figure 2 :

 2 Figure 2: The toolchain function

Figure 3 :

 3 Figure 3: The engineer function

Figure 4 :

 4 Figure 4: Model-driven engineering of metrics

Figure 6 :

 6 Figure 6: Main part of the predicate metamodel

Figure 7 :

 7 Figure 7: Features management in the metric metamodel The figure 7 shows what are the possible tests on a given feature, which are: • EqualityPredicate enables to test whether a reference points to a model element referred by a variable;

Figure 5 :

 5 Figure 5: General mechanisms of the metric metamodel

Figure 8 :

 8 Figure 8: Excerpt of the AADL metamodel

Eclipse Modeling Framework, see www.eclipse.org/emf

Topcased is an open source CASE environment, see www.topcased.org

a model-driven language and workbench, see www.kermeta.org and[START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF]