Nicolas Navet
email: nicolas.navet@uni.lu

Françoise Simonot

Françoise Simonot-Lion

In-vehicle communication networks -a historical perspective and review

Keywords: Time-triggered, 1, 5, 3 Security issues, middleware, communication services

The use of networks for communications between the Electronic Control Units (ECU) of a vehicle in production cars dates from the beginning of the 90s. The specic requirements of the dierent car domains have led to the development of a large number of automotive networks such as LIN, CAN, CAN FD, FlexRay, MOST, automotive Ethernet AVB, etc.. This report rst introduces the context of in-vehicle embedded systems and, in particular, the requirements imposed on the communication systems. Then, a review of the most widely used, as well as the emerging automotive networks is given. Next, the current eorts of the automotive industry on middleware technologies which may be of great help in mastering the heterogeneity, are reviewed, with a special focus on the proposals of the AUTOSAR consortium. Finally, we highlight future trends in the development of automotive communication systems.

1

Automotive communication systems: characteristics and constraints 1.1 From point-to-point to multiplexed communications Since the 1970s, one observes an exponential increase in the number of electronic systems that have gradually replaced those that are purely mechanical or hydraulic. The growing performance and reliability of hardware components and the possibilities brought by software technologies enabled implementing complex functions that improve the comfort of the vehicle's occupants as well as their safety. In particular, one of the main purposes of electronic systems is to assist the driver to control the vehicle through functions related to the steering, traction (i.e., control of the driving torque) or braking such as the ABS (Anti-lock Braking System), ESP (Electronic Stability Program), EPS (Electric Power Steering), active suspensions or engine control. Another reason for using electronic systems is to control devices in the body of a vehicle such as lights, wipers, doors, windows as well as entertainment and communication equipments (e.g., radio, DVD, hand-free phones, navigation systems). More recently appeared a large set of Advanced Driver Assistance Systems (ADAS), often camera based, such as brake and park assistance, lane departure detection, night vision assistance with pedestrian recognition or suspension proactively scanning the road surface [START_REF]The new Mercedes-Benz S-Class[END_REF].

In the future, vehicles will become entities of large intelligent transportation systems [START_REF] Machan | Intelligent vehicles as an integral part of intelligent transport systems[END_REF], involving cooperation mechanisms [START_REF] Lokaj | Cooperative systems for car safety improvement[END_REF] through car-to-car and car-to-infrastructure communications.

In the early days of automotive electronics, each new function was implemented as a stand-alone Electronic Control Unit (ECU), which is a subsystem composed of a micro-controller and a set of sensors and actuators. This approach quickly proved to be insucient with the need for functions to be distributed over several ECUs and the need for information exchanges among functions. For example, the vehicle speed estimated by the engine controller or by wheel rotation sensors, has to be known in order to adapt the steering eort, to control the suspension or simply to choose the right wiping speed. In today's luxury cars, up to 2500 signals (i.e., elementary information such as the speed of the vehicle) are exchanged by up to 70 ECUs [START_REF] Albert | Comparison of event-triggered and time-triggered concepts with regards to distributed control systems[END_REF]. Until the beginning of the 90s, data was exchanged through point-to-point links between ECUs. However this strategy, which required an amount of communication channels of the order of n 2 where n is the number of ECUs (i.e., if each node is interconnected with all the others, the number of links grows in the square of n), was unable to cope with the increasing use of ECUs due to the problems of weight, cost, complexity and reliability induced by the wires and the connectors. These issues motivated the use of networks where the communications are multiplexed over a shared medium, which conse-quently required dening rules -protocols -for managing communications and, in particular, for granting bus access. It was mentioned in a 1998 press release (quoted in [START_REF] Leen | Expanding automotive electronic systems[END_REF]) that the replacement of a wiring harness with LANs in the four doors of a BMW reduced the weight by 15 kilograms. In the mid-1980s, the third part supplier Robert Bosch developed Controller Area Network (CAN) which was rst integrated in Mercedes production cars in the early 1990s. CAN has become today the most widely used network in automotive systems, and already in 2004 the number of CAN nodes sold per year was estimated [START_REF] Johansson | Handbook of Networked and Embedded Control Systems, chapter Vehicle Applications of Controller Area Network[END_REF] to be around 400 millions (all application elds).

Other communication networks, providing dierent services, are now being integrated in automotive applications. A description of the major networks is given in section 2.

Car domains and their evolution

As all the functions embedded in cars do not have the same performance or safety needs, dierent Quality of Services (e.g. response time, jitter, bandwidth, redundant communication channels for tolerating transmission errors, eciency of the error detection mechanisms, etc.) are expected from the communication systems. Typically, an in-car embedded system is divided into several functional domains that correspond to dierent features and constraints. Two of them are concerned specically with real-time control and safety of the vehicle's behavior: the powertrain (i.e. control of engine and transmission) and the chassis (i.e., control of suspension, steering and braking) domains. The third, the body, mostly implements comfort functions. The telematics (i.e. integration of wireless communications, vehicle monitoring systems and location devices), multimedia and Human Machine Interface (HMI) domains take advantage of the continuous progress in the eld of multimedia and mobile communications. Finally, an emerging domain is concerned with the safety of the occupant and with functions providing driver assistance.

The main function of the powertrain domain is controlling the engine. This domain is increasingly constrained by stringent regulations, such as EURO 5 in force at the time of writing in Europe, for the protection of environment (e.g., emissions of particulate matter) and energy eciency. The powertrain function is realized through several complex control laws with sampling periods of a magnitude of some milliseconds (due to the rotation speed of the engine) and implemented in micro-controllers with high computing power. In order to cope with the diversity of critical tasks to be treated, multi-tasking is required and stringent time constraints are imposed on the scheduling of the tasks (see [START_REF] Monot | Multisource software on multicore automotive ECUs -combining runnable sequencing with task scheduling[END_REF] for typical automotive scheduling solutions). Furthermore, frequent data exchanges with other car domains, such as the chassis (e.g. ESP, ABS) and the body (e.g. dashboard, climate control), are required.

The chassis domain gathers functions such as ABS, ESP, ASC (Automatic Stability Control), 4WD (4 Wheel Drive), which control the chassis components according to steering/braking solicitations and driving conditions (ground surface, wind, etc). Communication requirements for this domain are quite similar to those for the powertrain but, because they have a stronger impact on the vehicle's stability, agility and dynamics, the chassis functions are more critical from a safety standpoint. Furthermore, the X-by-Wire technology, currently used for avionic systems, is now slowly being introduced to execute steering or braking functions. X-by-Wire is a generic term referring to the replacement of mechanical or hydraulic systems by fully electrical/electronic ones, which led and still leads to new design methods for developing them safely [START_REF] Wilwert | The Industrial Communication Technology Handbook, chapter Design of Automotive X-by-Wire Systems[END_REF] and, in particular, for mastering the interferences between functions [START_REF] Ayoubi | X-by-Wire functionality, performance and infrastructure[END_REF]. Chassis and powertrain functions operate mainly as closed-loop control systems and their implementation is moving towards a time-triggered approach [START_REF] Rushby | A comparison of bus architectures for safety-critical embedded systems[END_REF][START_REF] Krug | New demands for in-vehicle networks[END_REF][START_REF] Poledna | Communication bus for automotive applications[END_REF][START_REF] Peteratzinger | Use of XCP on FlexRay at BMW[END_REF], which facilitates composability (i.e. ability to integrate individually developed components) and deterministic real-time behavior of the system. Dashboard, wipers, lights, doors, windows, seats, mirrors, climate control are increasingly controlled by software-based systems that make up the body domain. This domain is characterized by numerous functions that necessitate many exchanges of small pieces of information among themselves. Not all nodes require a large bandwidth, such as the one oered by CAN; this lead to the design of low-cost networks, such as LIN (see section 2), or more recently, PSI5 and SENT. On LIN, only one node, termed the master, possesses an accurate clock and drives the communication by polling the other nodes -the slaves -periodically. The mixture of dierent communication needs inside the body domain leads to a hierarchical network architecture where integrated mechatronic sub-systems based on low-cost networks are interconnected through a CAN backbone. The activation of body functions is mainly triggered by the driver and passengers' solicitations (e.g. opening a window, locking doors, etc).

Telematics functions are becoming more and more numerous: hand-free phones, car radio, CD, DVD, in-car navigation systems, rear seat entertainment, remote vehicle diagnostic, stolen vehicle tracking, etc. These functions require a lot of data to be exchanged within the vehicle but also with the external world through the use of wireless technology (see, for instance, [START_REF] Ramaswamy | Delivering multimedia content to automobiles using wireless networks[END_REF]).

Here, the emphasis shifts from messages and tasks subject to stringent deadline constraints to multimedia data streams, bandwidth sharing, multimedia quality of service where preserving the integrity (i.e., ensuring that information will not be accidentally or maliciously altered) and condentiality of information is crucial. HMI aims to provide Human Machine Interfaces that are easy to use and that limit the risk of driver inattention [START_REF] Motor | Ford to study in-vehicle electronic devices with advanced simulators[END_REF].

Electronic-based systems for ensuring the safety of the occupants are in-creasingly embedded in vehicles. Examples of such systems are: impact and roll-over sensors, deployment of airbags and belt pretensioners, tyre pressure monitoring, Adaptive Cruise Control (or ACC -the car's speed is adjusted to maintain a safe distance with the car ahead), lane departure warning system, collision avoidance, driver intent and driver drowsiness detection, night vision assistance. These functions form an emerging domain usually referred to as active and passive safety.

Event-triggered versus Time-triggered

One of the main objectives of the design step of an in-vehicle embedded system is to ensure a proper execution of the vehicle functions, with a predened level of safety, in the normal functioning mode but also when some components fail (e.g., reboot of an ECU) or when the environment of the vehicle creates perturbations (e.g., EMI causing frames to be corrupted).

Networks play a central role in maintaining the embedded systems in a safe state since most critical functions are now distributed and need to communicate. Thus, the dierent communication systems have to be analysed in regard to this objective; in particular, messages transmitted on the bus must meet their real-time constraints, which mainly consist of bounded response times and bounded jitters.

There are two main paradigms for communications in automotive systems: time-triggered and event-triggered. Event-triggered means that messages are transmitted to signal the occurrence of signicant events (e.g., a door has been closed). In this case, the system possesses the ability to take into account, as quickly as possible, any asynchronous events such as an alarm.

The communication protocol must dene a policy to grant access to the bus in order to avoid collisions; for instance, the strategy used in CAN (see 2.1.1) is to assign a priority to each frame and to give the bus access to the highest priority frame. Event-triggered communication is very ecient in terms of bandwidth usage since only necessary messages are transmitted. Furthermore, the evolution of the system without redesigning existing nodes is generally possible which is important in the automotive industry where incremental design is a usual practice. However, verifying that temporal constraints are met is not obvious and the detection of node failures is problematic.

When communications are time-triggered, frames are transmitted at predetermined points in time, which is well-suited for the periodic transmission of messages as it it required in distributed control loops. Each frame is scheduled for transmission during one pre-dened interval of time, usually termed a slot, and the schedule repeats itself indenitely. This medium access strategy is referred to as TDMA (Time Division Multiple Access). As the frame scheduling is statically dened, the temporal behavior is fully predictable; thus, it is easy to check whether the timing constraints expressed on data exchanges are met. Another interesting property of time-triggered protocols is that missing messages are immediately identied; this can serve to detect, in a short and bounded amount of time, nodes that are presumably no longer operational. The rst downside is the ineciency in terms of network utilization and response times by comparison with the transmission of aperiodic messages (i.e. messages that are not transmitted in a periodic manner). A second drawback of time-triggered protocols is the lack of exibility even if dierent schedules (corresponding to dierent functioning modes of the application) can be dened and switching from one mode to another is possible at run-time. Finally, the unplanned addition of a new transmitting node on the network induces changes in the message schedule and, thus, may necessitate the update of all other nodes. TTP/C [START_REF]Time-Triggered Protocol TTP/C, High-Level Specication Document[END_REF] is a purely time-triggered network but there are networks, such as TTCAN [START_REF]International Standard Organization. 11898-4, Road Vehicles -Controller Area Network (CAN) -Part 4: Time-Triggered Communication[END_REF], FTT-CAN [START_REF] Ferreira | The FTT-CAN protocol for exibility in safety-critical systems[END_REF], FlexRay [START_REF]FlexRay communications system -protocol specication -version 3.0.1[END_REF] or TTEthernet [START_REF] Computertechnik | TTEthernet -a powerful network solution for multiple purpose[END_REF], that can support a combination of both time-triggered and event-triggered transmissions. This capability to convey both types of trac ts in well with the automotive context since data for control loops as well as alarms and events have to be transmitted.

Several comparisons have been done between event-triggered and time-triggered approaches, the reader can refer to [START_REF] Koopman | Critical embedded automotive networks[END_REF][START_REF] Albert | Comparison of event-triggered and time-triggered concepts with regards to distributed control systems[END_REF][START_REF] Ferreira | The FTT-CAN protocol for exibility in safety-critical systems[END_REF] for good starting points.

Dierent networks for dierent requirements

The steadily increasing need for bandwidth 1 and the diversication of per- formance, costs and dependability 2 requirements lead to a diversication of the networks used throughout the car. In 1994, the Society for Automotive Engineers (SAE) dened a classication for automotive communication protocols [START_REF]/2 survey of known protocols[END_REF]87,[START_REF]Introduction to in-vehicle networking[END_REF] based on data transmission speed and functions that are distributed over the network. Class A networks have a data rate lower than 10 Kbit/s and are used to transmit simple control data with low-cost technology. They are mainly integrated in the body domain (seat control, door lock, lighting, trunk release, rain sensor, etc.). Examples of class A networks are LIN [START_REF] Rajnák | The Industrial Communication Technology Handbook, chapter The LIN Standard[END_REF][START_REF]LIN Specication Package, revision 2.2A[END_REF] and TTP/A [START_REF] Kopetz | Specication of the TTP/A Protocol[END_REF]. Class B networks are dedicated to supporting data exchanges between ECUs in order to reduce the number of sensors by sharing information. They operate from 10 Kbit/s to 125 Kbit/s. The J1850 [89] and low-speed CAN [START_REF]2, Road Vehicles -Low Speed serial data communication -Part 2: Low Speed Controller Area Network[END_REF] are the main representatives of this class.

Applications that need high speed real-time communications require class C 1 For instance, in [START_REF] Ayoubi | X-by-Wire functionality, performance and infrastructure[END_REF], the average bandwidth needed for the engine and the chassis control was estimated to reach 1500kbit/s in 2008 while it was 765kbit/s in 2004 and 122kbit/s in 1994.

2 Dependability is usually dened as the ability to deliver a service that can justiably be trusted, see [START_REF] Avizienis | Fundamental concepts of dependability[END_REF] for more details. networks (speed of 125Kbit/s to 1Mbit/s) or class D networks 3 (speed over 1Mb/s). Class C networks, such as high-speed CAN [START_REF]Road Vehicles -Interchange of Digital Information -Controller Area Network for highspeed Communication[END_REF], are used for the powertrain and currently for the chassis domains, while class D networks are devoted to multimedia data (e.g., MOST [START_REF]MOST Specication Revision 3.0 E2[END_REF]) and safety critical applications that need predictability and fault-tolerance (e.g., TTP/C [START_REF]Time-Triggered Protocol TTP/C, High-Level Specication Document[END_REF] or FlexRay [START_REF]FlexRay communications system -protocol specication -version 3.0.1[END_REF] networks) or serve as gateways between sub-systems (see the use of FlexRay at BMW in [START_REF] Schedl | Goals and architecture of FlexRay at BMW[END_REF] and [START_REF] Kellermann | Electrical and electronic system architecture[END_REF]).

It is common, in today's vehicles, that the electronic architecture includes four, ve or more dierent types of networks interconnected by gateways.

For example, the rst-generation Volvo XC90 [START_REF] Johansson | Handbook of Networked and Embedded Control Systems, chapter Vehicle Applications of Controller Area Network[END_REF] embeds up to 40 ECUs interconnected by a LIN bus, a MOST bus, a low-speed CAN and a high-speed CAN. More recent high-end cars have much more complex architectures, such as the BMW 7 series launched in 2008 (see [START_REF] Kellermann | Electrical and electronic system architecture[END_REF]), which implements four CAN buses, a FlexRay bus, a MOST bus, several LIN buses, an Ethernet bus and wireless interfaces. The architecture is organized around a central gateway connecting most of the data buses, and providing external connections for diagnostic and large data transfer (code upload, navigational maps, etc).

New challenges for in-vehicle communication systems

We discuss here three main evolutions that will probably profoundly shape future automotive communication networks and architectures.

1.5.1

Real-time processing of large data quantities

The rst trend is the requirement for an increasing number of functions to process, at a high rate, large quantities of data, for instance produced by video and infrared cameras. A good example of such functions is a pedestrian detection system with auto-brake, which relies on image recognition and machine learning algorithms, and has to work at the highest possible vehicle speed. In the case of the pedestrian detection system introduced in 2010 in Volvo's S60, a collision with a pedestrian can be avoided at up to 35km/h [START_REF] Volvo | Volvo unveils innovative safety technology -pedestrian detection with full auto brake debuts on the all-new Volvo S60[END_REF]. This system has to analyse the ow of images and provide, on time, a deterministic verdict about whether there is a pedestrian in front of the car, and then possibly activate braking if the driver fails to respond in time. Such systems, often belonging to the active and passive safety car domain, require powerful computational resources. This is one of the rationale for the introduction of multicore architectures in automotive embedded systems [START_REF] Monot | Multisource software on multicore automotive ECUs -combining runnable sequencing with task scheduling[END_REF]. Furthermore, these functions are often implemented on a distributed architecture, and usually require sensor fusion, so that the 3 Class D is not formally dened but it is generally considered that networks over 1Mb/s belong to class D. This SAE classication is outdated today but was often refered to in the past.

underlying communication architecture has to provide a strong and guaranteed temporal quality of service. Another driver for increasing data streams are of course infotainment systems, consider for example a rear-set video system in HD quality.

Reducing electrical energy consumption

Energy eciency is now a major concern when designing new embedded electronic architectures, while it was for the last 10 years a concern for actuators mainly. A reason is that, by regulation, the average CO2 emission per passenger car sold in the EU must fall below the 95g/km threshold from 2020 onwards. Similar regulations will come into force in many countries outside EU, for instance in China or in the USA [START_REF] Zeltwanger | Partial networking reduces CO2 emissions[END_REF]. At the same time, it is estimated [START_REF] Butzkamm | Partial Networking for CAN bus systems: Any saved gram CO 2 /km is essential to meet stricter EU regulations[END_REF] that, between 2002 and 2012, the average power requirement for the automotive electronics was multiplied by 4 and reaches now 3kW.

This lead to the introduction of two main strategies to achieve better energy eciency: ECU degradation and partial networking. ECU degradation is the ability to switch o or reduce the execution rate of software modules, shutdown some I/O ports, or even put a complete CPU into idle mode. These low-power features are already supported in AUTOSAR. Partial networking means putting temporarily into sleep mode a group of nodes, or some entire network, when they do not need to be operational. For example, a parking assistance system that cannot be used above 20km/h can be deactivated at higher speeds. Many control modules in the body of the vehicle (seats, mirror, door, etc) can remain in sleep mode most of the time [START_REF] Butzkamm | Partial Networking for CAN bus systems: Any saved gram CO 2 /km is essential to meet stricter EU regulations[END_REF]. Then, the nodes are waken up when needed through specic messages. Audi estimates for instance that the potential savings of partial networking would be around 2.6g CO2/km [START_REF] Vollmer | Deutsche OEMs setzen standards. all-electronics[END_REF][START_REF] Butzkamm | Partial Networking for CAN bus systems: Any saved gram CO 2 /km is essential to meet stricter EU regulations[END_REF].

Partial networking has been an ongoing work in the automotive industry since 2008 [START_REF] Liebetrau | Energy saving in automotive E/E architectures[END_REF], already fully supported in AUTOSAR for CAN. A working group of carmakers and semiconductor manufacturers was set up in 2010 to develop a specication for CAN transceivers with wake-up capability [START_REF] Vollmer | Deutsche OEMs setzen standards. all-electronics[END_REF][START_REF] Butzkamm | Partial Networking for CAN bus systems: Any saved gram CO 2 /km is essential to meet stricter EU regulations[END_REF].

The outcomes of this working group have been submitted for standardisation as ISO 11898-6, an extension to the existing CAN standard (ISO 11898).

Several components supporting partial networking are commercially available [START_REF] Zeltwanger | Partial networking reduces CO2 emissions[END_REF] and a rst implementation in a car has been announced for 2013

or 2014 [START_REF] Liebetrau | Energy saving in automotive E/E architectures[END_REF].

Security issues

The last issue to be dealt with is the security of communication, and more generally security of the embedded systems. If safety has always been a matter of concern for automotive embedded systems, security issues have been in our view largely overlooked. The need for more security is driven by the ever increasing connectivity between the car and the external world, which includes not only telematics services and internet access, but also upcoming vehicle-to-vehicle or vehicle-to-infrastructure communication.

As demonstrated in [START_REF] Koscher | Experimental security analysis of a modern automobile[END_REF], some existing security mechanisms, for instance to control ECU reprogramming, are weak and many current automotive systems usually do not resist to attacks, sometimes even relatively unsophisticated ones according to [START_REF] Koscher | Experimental security analysis of a modern automobile[END_REF]. With a physical access to the vehicle, through a connection to the standard OBD-II port, the authors were for instance able to reash ECUs, even critical ones controlling the engine and the brakes.

The authors were also able to remotely compromise the security of the car, by injecting malicious code, and ultimately monitor and control the car remotely over the Internet [START_REF] Koscher | Experimental security analysis of a modern automobile[END_REF]. Obviously such security breaches could have catastrophic consequences, especially with ADAS systems and future intelligent transportation systems requiring cooperation between vehicles. One may even imagine a scenario where an infected vehicle would contaminate other vehicles.

The technical answer to this security challenge will probably encompass a spectrum of solutions [START_REF] Koscher | Experimental security analysis of a modern automobile[END_REF], ranging from cryptography (support for embedding a cryptographic module is available in AUTOSAR since release 4.0 [START_REF] Bunzel | Autosar architecture expands safety and security applications[END_REF]), message authentication mechanisms, security breach detection systems, etc.

These functionalities will require additional bandwidth, and, for instance, CAN FD (see 2.1.4) would probably be better suited than normal CAN to full these needs. The use of virtualization technologies [START_REF] Navet | Virtualization in automotive embedded systems: an outlook[END_REF] will also increase security because it enables to isolate functions or sub-systems running on the same ECUs having dierent security requirements, while enabling them to share information in a controlled manner. Typically, virtualization would help to prevent infotainment applications, that are connected to the external world through wireless connections, from accessing the internal communication buses.

2

In-car embedded networks

The dierent performance requirements throughout a vehicle, as well as the competition among companies, have led to the design of a large number of communication networks. The aim of this section is to give a description of the most representative networks for each main domain of utilization.

The CAN network

To ensure at run-time the freshness 4 of the exchanged data and the timely delivery of commands to actuators, it is crucial that the Medium Access Control (MAC) protocol is able to ensure bounded response times for frames. An ecient and conceptually simple MAC scheme that possesses this capability is the granting of bus access according to the priority of the messages (the reader can refer to [START_REF] Tindell | Calculating Controller Area Network (CAN) message response times[END_REF][START_REF] Navet | Validation of real-time in-vehicle applications[END_REF][START_REF] Davis | Controller Area Network (CAN) schedulability analysis: Refuted, revisited and revised[END_REF][START_REF] Meumeu-Yomsi | Controller Area Network (CAN): Response time analysis with osets[END_REF] for how to compute bound on response times for priority buses). To this end, each message is assigned an identier, unique to the whole system. This serves two purposes: giving priority for transmission (the lower the numerical value, the greater the priority) and allowing message ltering upon reception. Beside CAN two other representatives of such priority buses are VAN and J1850, they will be briey presented in 2.1.3. of wires has been reduced by 40%, from 635 to 370, in the Peugeot 307 that embeds two CAN buses with regard to the non-multiplexed Peugeot 306 [START_REF] Martin | L'argus de l'automobile[END_REF]).

Furthermore, it allows to share sensors among ECUs.

CAN on a twisted pair of copper wires became an ISO standard in 1994 [START_REF]2, Road Vehicles -Low Speed serial data communication -Part 2: Low Speed Controller Area Network[END_REF][START_REF]Road Vehicles -Interchange of Digital Information -Controller Area Network for highspeed Communication[END_REF] and is now a de-facto standard in Europe for data transmission in automotive applications, due to its low cost, its robustness and the bounded communication delays (see [START_REF] Johansson | Handbook of Networked and Embedded Control Systems, chapter Vehicle Applications of Controller Area Network[END_REF]). In today's car, CAN is used as an SAE class C network for real-time control in the powertrain and chassis domains (at 250 or 500KBit/s), but it also serves as an SAE class B network for the electronics in the body domain, usually at a data rate of 125Kbit/s.

On CAN, data, possibly segmented in several frames, may be transmitted periodically, aperiodically or on-demand (i.e. client-server paradigm). A CAN frame is labeled by an identier, transmitted within the frame (see CAN uses Non-Return-to-Zero (NRZ) bit representation with a bit stung of length 5. In order not to lose the bit time (i.e., the time between the emission of two successive bits of the same frame), stations need to resynchronize periodically and this procedure requires edges on the signal. Bit stung is an encoding method that enables resynchronization when using Non-Return-to-Zero (NRZ) bit representation where the signal level on the bus can remain constant over a longer period of time (e.g. transmission of '000000..'). Edges are inserted into the outgoing bit stream in such a way to avoid the transmission of more than a maximum number of consecutive equal-level bits (5 for CAN). The receiver will apply the inverse procedure and de-stu the frame. CAN requires the physical layer to implement the logical and operator: if at least one node is transmitting the 0 bit level on the bus, then the bus is in that state regardless if other nodes have transmitted the 1 bit level. For this reason, 0 is termed the dominant bit value while 1 is the recessive bit value.

The standard CAN data frame (CAN 2.0A, see Figure 1) can contain up to 8 bytes of data for an overall size of, at most, 135bits, including all the protocol overheads such as the stu bits. The sections of the frames are:

the header eld (see Figure 2), which contains the identier of the frame, the Remote Transmission Request bit that distinguishes between data frame (RTR set to 0) and data request frame (RTR set to 1) and the Data Length Code (DLC) used to inform of the number of bytes of the data eld, the data eld having a maximum length of 8 bytes, the 15 bit Cyclic Redundancy Check (CRC) eld which ensures the integrity of the data transmitted, the Acknowledgment eld (Ack). On CAN, the acknowledgment scheme solely enables the sender to know that at least one station, but not necessarily the intended recipient, has received the frame correctly, the End-of-Frame (EOF) eld and the intermission frame space which is the minimum number of bits separating consecutive messages.

Any CAN node may start a transmission when the bus is idle. Possible conicts are resolved by a priority-based arbitration process, which is said non-destructive in the sense that, in case of simultaneous transmissions, the highest priority frame will be sent despite the contention with lower priority frames. The arbitration is determined by the arbitration elds (identier plus another transmits a dominant bit, the resulting bus level is dominant due to the and operator realized by the physical layer. Therefore, the node transmitting a recessive bit will observe a dominant bit on the bus and then will immediately stop transmitting. Since the identier is transmitted most signicant bit rst, the node with the numerically lowest identier eld will gain access to the bus. A node that has lost the arbitration will wait until the bus becomes free again before trying to retransmit its frame.

CAN arbitration procedure relies on the fact that a sending node monitors the bus while transmitting. The signal must be able to propagate to the most remote node and return back before the bit value is decided. This requires the bit time to be at least twice as long as the propagation delay which limits the data rate: for instance, 1Mbit/s is feasible on a 40 meter bus at maximum while 250Kbit/s can be achieved over 250 meters. To alleviate the data rate limit, and extend the lifespan of CAN further, car manufacturers are starting to optimize the bandwidth usage by implementing trac shaping strategies that are very benecial in terms of response times (see, for instance, [START_REF] Grenier | The Automotive Embedded Systems Handbook, chapter Scheduling frames with osets in automo-tive systems: a major performance boost[END_REF]).

CAN has several mechanisms for error detection. For instance, it is checked that the CRC transmitted in the frame is identical to the CRC computed at the receiver end, that the structure of the frame is valid and that no bitstung error occurred. Each station which detects an error sends an "error ag" which is a particular type of frame composed of 6 consecutive dominant bits that allows all the stations on the bus to be aware of the transmission error. The corrupted frame automatically re-enters into the next arbitration to hardware dysfunctioning at the level of the micro-controller, communication controller or physical layer. The scheme is based on error counters that are increased and decreased according to particular events (e.g., successful reception of a frame, reception of a corrupted frame, etc.). The relevance of the algorithms involved is questionable (see [START_REF] Gaujal | Fault connement mechanisms on CAN: Analysis and improvements[END_REF]) but the main limitation is that a node has to diagnose itself, which can lead to the non-detection of some critical errors. For instance, a faulty oscillator can cause a node to transmit continuously a dominant bit, which is one manifestation of the babbling idiot fault, see [START_REF] Pimentel | The Automotive Embedded Systems Handbook, chapter Dependable Automotive CAN Networks[END_REF]. Furthermore, other faults such as the partitioning of the network into several sub-networks may prevent all nodes from communicating due to bad signal reection at the extremities. Without additional fault-tolerance facilities, CAN is not well suited for safety-critical applications. For instance, a single node can perturb the functioning of the whole network by sending messages outside their specication (i.e. length and period of the frames). Many mechanisms were proposed for increasing the dependability of CAN-based networks (see [START_REF] Pimentel | The Automotive Embedded Systems Handbook, chapter Dependable Automotive CAN Networks[END_REF] for an excellent survey), but if each proposal solves a particular problem, they have not necessarily been conceived to be combined. Furthermore, the fault-hypotheses used in the design of theses mechanisms are not necessarily the same and the interactions between them remain to be studied in a formal way.

The CAN standard only denes the physical layer and Data Link layer (DLL). Several higher level protocols have been proposed, for instance, for standardizing startup procedures, implementing data segmentation or sending periodic messages (see OSEK/VDX and AUTOSAR in 3). Other higherlevel protocols standardize the content of messages in order to ease the interoperability between ECUs. This is the case for J1939 which is widely used, for instance, in Scania's trucks and buses [START_REF] Waern | Evaluation of protocols for automotive systems[END_REF]. COTS toolsets available on the market to help them with the optimization and verication using simulation (possibly with fault-injection), schedulability analysis and trace analysis (see [START_REF] Navet | CAN in automotive applications: a look forward[END_REF] for the use of RealTime-at-Work's tools).

Optimizing CAN networks.

When CAN was introduced, the bus load levels were limited, typically much less than 30% (see [START_REF] Navet | Worst-case deadline failure probability in real-time applications distributed over CAN (Controller Area Network)[END_REF] for a typical set of messages of the years 1995-2000). Optimizing CAN networks, which includes reaching higher load levels, has now become an industrial requirement for The rst obvious way to optimize a CAN network is to keep the amount of data transmitted to a minimum, specically limit the transmission frequency of the frames. This requires a rigorous identication and traceability of the temporal constraints. Given a set of signals or frames, and their associated temporal constraints (freshness, jitters, etc), they are in addition a few conguration strategies than can be used:

1. Desynchronize the stream of frames by using osets. The reader may refer to [START_REF] Grenier | Pushing the limits of CANscheduling frames with osets provides a major performance boost[END_REF] for comprehensive experiments on the large gains achieved using osets, 2. Reassign the priorities of the frames, so that the priority order better reects the timing constraints, 3. Re-consider the frame-packing, that is the allocation of the signals to the frames and choice of the frame periods, so as to minimize the bandwidth usage while meeting timing constraints (see [START_REF] Saket | Frame packing algorithms for automotive applications[END_REF]), 4. Optimize the ECU communication stacks so as to remove all implementation choices that cause a departure from the ideal CAN behavior (see [START_REF] Navet | CAN in automotive applications: a look forward[END_REF]).

However, because there is less margin for error, using complex CAN-based architectures at high load levels involves more detailed supplier specications on the one hand, and, on the other hand, to spend more time and eort in the integration/validation phase. For quite a long time, the trend in new designs seems to be the replacement of J1850 by CAN or a low-cost network such as LIN (see 2.3.1).

In the 90s, another competing technology was the French Vehicle Area Network (VAN, see [START_REF]3, Road Vehicles -Low Speed serial data communication -Part 3: Vehicle area network (VAN)[END_REF]) which is very similar to CAN (e.g., frame format, data rate) but possesses some additional or dierent features that are advantageous from a technical point of view (e.g., no need for bit-stung, in-frame response: a node being asked for data answers in the same frame that contained the request). VAN was used for years in production cars by the French carmaker PSA Peugeot-Citroën in the body domain (e.g, for the 206 model) but, as it was not adopted by the market, it was abandoned in favor of CAN. , and a higher one used immediately after the arbitration for the transfer of the data payload and related elds (e.g., DLC, CRC). The bit rate for this data part of the frame transmission can be freely chosen (e.g., 10MBit/s are mentioned in [START_REF] Hartwich | CAN with Flexible Data-Rate[END_REF]) but in practice it will depend much on the topology of the network and the eciency of the transceivers.

It is not clear at the time of writing what is the kind of data rate, and thus the speedup with regard to standard CAN, that can be achieved in typical automotive applications and this will largely determine the acceptance of CAN FD. The target mentioned in [START_REF] Hartwich | CAN with Flexible Data-Rate[END_REF] is an average data rate of 2.5MBit/s with existing CAN transceivers.

Four main use-cases are identied for CAN FD in [START_REF] Lindenkreuz | CAN FD -CAN with exible data rate[END_REF]: faster software download (end-of-production line or maintenance), avoiding segmentation of long messages (and possibly securing normal CAN messages with message authentication information), oering higher-bandwidth to car domains requiring it (e.g., powertrain [START_REF] Lindenkreuz | CAN FD -CAN with exible data rate[END_REF]), and enabling faster communication on long CAN buses (e.g., in trucks and buses). An important advantage of CAN FD is that there is an easy migration path from CAN systems to CAN FD systems since existing CAN application software can basically remains unchanged, the changes taking place in the communication layers and their conguration. Following FPGA's implementations, microcontrollers with CAN FD are already available (e.g., [START_REF]New Freescale microcontrollers help streamline automotive body electronics networks and reduce vehicle weight[END_REF]) and the protocol has been submitted as ISO 11898-7 for international standardization.

Time-Triggered networks

Among communication networks, as discussed before, one distinguishes timetriggered networks where activities are driven by the progress of time and event-triggered once where activities are driven by the occurrence of events.

Both types of communication have advantages but one considers that, in general, dependability is much easier to ensure using a time-triggered bus (refer, for instance, to [START_REF] Rushby | A comparison of bus architectures for safety-critical embedded systems[END_REF] for a discussion on this topic). This explains that mainly time-triggered communication systems are being considered for use in the most critical applications such as X-by-Wire systems. In this category, multi-access protocols based on TDMA (Time Division Multiple Access) are particularly well suited; they provide deterministic access to the medium (the order of the transmissions is dened statically at the design time), and thus bounded response times. Moreover, their regular message transmissions can be used as "heartbeats" for detecting station failures. The three TDMA based networks that could serve as gateways or for supporting safety critical applications are TTP/C (see [START_REF]Time-Triggered Protocol TTP/C, High-Level Specication Document[END_REF]), FlexRay (see 2.2.1) and TTEthernet (see 2.5.4). FlexRay, which was backed by the world's automotive industry, is becoming a standard technology in the industry, though without gaining broad acceptance, and is already in use in production cars since 2006 (see [START_REF] Schedl | Goals and architecture of FlexRay at BMW[END_REF][START_REF] Hammerschmidt | Beyond FlexRay: BMW airs Ethernet plan[END_REF]). TTCAN (see 2.2.2) was, before the advent of FlexRay, considered for use and is briey discussed in this section. In the following, we choose not to discuss further TTP/C which, to the best of our knowledge, is no more considered for vehicles but is used in aircrafts. However, the important experience and know-how gained over the years with TTP/C, in particular regarding its fault-tolerance features (see [START_REF] Gaujal | Maximizing the robustness of TDMA networks with applications to TTP/C[END_REF]) and their formal validation (see [START_REF] Pfeifer | The Automotive Embedded Systems Handbook, chapter Formal Methods in the Automotive Domain: The Case of TTA[END_REF]), is certainly benecial to FlexRay and any Ethernet-based protocols such as TTEthernet (see 2.5.4) or even AVB (see 2.5.3).

2.2.1

The FlexRay Protocol A consortium of major companies from the automotive eld developed the The FlexRay frame consists of 3 parts : the header, the payload segment containing up to 254 bytes of data and the CRC of 24 bits. The header of 5 bytes includes the identier of the frame and the length of the data payload. The use of identiers allows to move a software component, which sends a frame X, from one ECU to another ECU without changing anything in the nodes that consume frame X. It has to be noted that this is no more possible when signals produced by distinct components are packed into the same frame for the purpose of saving bandwidth (i.e., which is refer to as frame-packing or PDU-multiplexing -see [START_REF] Saket | Frame packing algorithms for automotive applications[END_REF] for this problem addressed on CAN).

From the dependability point of view, the FlexRay standard solely species a bus guardian (optional), passive and active star coupler (optional) and the clock synchronization algorithms. Other features, such as mode management facilities or a membership service, will have to be implemented in software or hardware layers on top of FlexRay (see, for instance, [START_REF] Barbosa | Formal specication and verication of a protocol for consistent diagnosis in real-time embedded systems[END_REF] for a membership service protocol that could be used along with FlexRay). This will allow to conceive and implement exactly the services that are needed with the drawback that correct and ecient implementations might be more dicult to achieve in a layer above the communication controller.

In the FlexRay specication, it is argued that the protocol provides scalable dependability i.e., the ability to operate in congurations that provide various degrees of fault tolerance. Indeed, the protocol allows for mixing links with single and dual transmission supports on the same network, subnetworks of nodes without bus-guardians or with dierent fault-tolerance capability with regards to clock synchronization, etc. In the automotive context where critical and non-critical functions co-exist and interoperate, this exibility can prove to be ecient in terms of cost and re-use of existing components. The reader interested in more information about FlexRay can refer to [START_REF] Schätz | The Automotive Embedded Systems Handbook, chapter The FlexRay Protocol[END_REF][START_REF]FlexRay communications system -protocol specication -version 3.0.1[END_REF], and to [START_REF] Pop | Bus access optimisation for FlexRay-based distributed embedded systems[END_REF][START_REF] Grenier | Conguring the communication on FlexRay: the case of the static segment[END_REF][START_REF] Zeng | Schedule optimization of time-triggered systems communicating over the FlexRay static segment[END_REF] for how to congure the communication cycle.

2.2.2

The TTCAN protocol TTCAN (Time Triggered Controller Area Network -see [START_REF]International Standard Organization. 11898-4, Road Vehicles -Controller Area Network (CAN) -Part 4: Time-Triggered Communication[END_REF]) is a communication protocol developed by Robert Bosch GmbH on top of the CAN physical and data-link layers. TTCAN uses the CAN standard but, in addition, requires that the controllers have the possibility to disable automatic retransmission of frames upon transmission errors and to provide the upper layers with the point in time at which the rst bit of a frame was sent or received. The bus topology of the network, the characteristics of the transmission support, the frame format, as well as the maximum data rate -1Mbits/s -are imposed by the CAN protocol. Channel redundancy is possible (see [START_REF] Müller | Fault tolerant TTCAN networks[END_REF] for a proposal), but not standardized and no bus guardian is implemented in the node. The key idea was to propose, as with FlexRay, a exible time-triggered/event-triggered protocol. As illustrated in Figure 6, TTCAN denes a basic cycle (the equivalent of the FlexRay communication cycle) as the concatenation of one or several time-triggered (or "exclusive") windows and one event-triggered (or "arbitrating") window. Exclusive windows are devoted to time triggered transmissions (i.e., periodic messages) while the arbitrating window is ruled by the standard CAN protocol: transmissions are dynamic and bus access is granted according to the priority of the frames. Several basic cycles, that dier by their organization in exclusive and arbitrating windows and by the messages sent inside exclusive windows, can be dened. The list of successive basic cycles is called the system matrix, which is executed in loops. Interestingly, the protocol enables the master node (i.e. the node that initiates the basic cycle through the transmission of the "reference message") to stop functioning in TTCAN mode and to resume in standard CAN mode. Later, the master node can switch back to TTCAN mode by sending a reference message.

TTCAN is built on a well-mastered and low-cost technology, CAN, but, as dened by the standard, does not provide important dependability services such as the bus guardian, membership service and reliable acknowledgment (see [START_REF] Pimentel | The Automotive Embedded Systems Handbook, chapter Dependable Automotive CAN Networks[END_REF]). It is, of course, possible to implement some of these mechanisms at the application or middleware level but with reduced eciency.

About 10 years ago, it was thought that carmakers could be interested in

Exclusive Window

Time windows for messages

... Exclusive Window

Exclusive Window

Arbitration Window

Reference Message

Exclusive Window

Reference Message master node transmission

TDMA CAN standard arbitration

Free Window

Basic Cycle

Figure 6: Example of a TTCAN Basic Cycle using TTCAN during a transition period until FlexRay technology is fully mature but this was not really the case and TTCAN has not been used in production cars to the best of our knowledge.

Low-cost automotive networks

Several eldbus networks have been developed to fulll the need for low-speed / low-cost communication inside mechatronic based sub-systems generally made of an ECU and its set of sensors and actuators. Two representatives of such networks are LIN and TTP/A. The low-cost objective is achieved not only because of the simplicity of the communication controllers but also because the requirements set on the micro-controllers driving the communication are reduced (i.e., low computational power, small amount of memory, low-cost oscillator). Typical applications involving these networks include controlling doors (e.g., door locks, opening/closing windows) or controlling seats (e.g., seat position motors, occupancy control). Besides cost considerations, a hierarchical communication architecture, including a backbone such as CAN and several sub-networks such as LIN, enables reducing the total trac load on the backbone.

Both LIN and TTP/A are master/slave networks where a single master node, the only node that has to possess a precise and stable time base, coordinates the communication on the bus: a slave is only allowed to send a message when it is polled. More precisely, the dialogue begins with the transmission by the master of a command frame that contains the identier of the message whose transmission is requested. The command frame is then followed by a data frame that contains the requested message sent by one of the slaves or by the master itself (i.e., the message can be produced by the master). This paragraph also presents the SENT and PSI5 networks which are other more recent low-cost alternatives to CAN. The LIN specication package (LIN version 2.2A [START_REF]LIN Specication Package, revision 2.2A[END_REF]) includes not only the specication of the transmission protocol (physical and data link layers) for master-slave communications but also the specication of a diagnostic protocol on top of the data link layer. A language for describing the capability of a node (e.g., bit-rates that can be used, characteristics of the frames published and subscribed by the node, etc.) and for describing the whole network is provided (e.g., nodes on the network, table of the transmissions' schedule, etc.). These description language facilitates the automatic generation of the network conguration by software tools.

Break

A LIN cluster consists of one master node and several slave nodes connected to a common bus. For achieving a low-cost implementation, the physical layer is dened as a single wire with a data rate limited to 20Kbit/s due to EMI limitations. The master node decides when and which frame shall be transmitted according to the schedule table. The schedule table is a key element in LIN; it contains the list of frames that are to be sent and their associated frame-slots thus ensuring determinism in the transmission order. At the moment a frame is scheduled for transmission, the master sends a header (a kind of transmission request or command frame) inviting a slave node to send its data in response. Any node interested can read a data frame transmitted on the bus. As in CAN, each message has to be identied: 64 distinct message identiers are available. Figure 7 depicts the LIN frame format and the time period, termed a frame slot, during which a frame is transmitted.

The header of the frame that contains an identier is broadcast by the master node and the slave node that possesses this identier inserts the data in the response eld. The break symbol is used to signal the beginning of a frame.

It contains at least 13 dominant bits (logical value 0) followed by one recessive bit (logical value 1) as a break delimiter. The rest of the frame is made of byte elds delimited by one start bit (value 0) and one stop bit (value 1), thus resulting in a 10-bit stream per byte. The sync byte has a xed value (which corresponds to a bit stream of alternatively 0 and 1), it allows slave nodes to detect the beginning of a new frame and be synchronized at the start of the identier eld. The so-called protected identier is composed of two sub-elds: the rst 6 bits are used to encode the identier and the last two bits, the identier parity. The data eld can contain up to 8 bytes of data. A checksum is calculated over the protected identier and the data eld. Parity bits and checksum enable the receiver of a frame to detect bits that have been inverted during transmission.

LIN denes ve dierent frame types: unconditional, event-triggered, sporadic, diagnostic and user-dened. Frames of the latter type are assigned a specic identier value and are intended to be used in an applicationspecic way that is not described in the specication. The rst three types A typical example of the use of the event-triggered transfer given in [START_REF]LIN Specication Package, revision 2.2A[END_REF] is the doors' knob monitoring in a central locking system. As it is rare that multiple passengers simultaneously press a knob, instead of polling each of the four doors, a single event-triggered frame can be used. Of course, in the rare event when more than one slave responds, a collision will occur. The It is also worth noting that LIN oers services to send nodes into a sleep mode (through a special diagnostic frame termed go-to-sleep-command) and to wake them up, which is convenient since optimizing energy consumption, especially when the engine is not running, is a real matter of concern in the automotive context. MOST supports end-user applications like radios, GPS navigation, video displays and entertainment systems. MOST's physical layer has been so far a Polymer Optical Fiber (POF) transmission support which provides a better resilience to EMI and higher transmission rates than classical cooper wires, but a new coaxial standard has been introduced recently [START_REF] Klos | MOST in future automotive connectivity[END_REF]. It was estimated in 2008 [START_REF] Mayer | Serial bus systems in the automobile -part 5: MOST for transmission of multimedia data. Summary of Networking Competence[END_REF] that around 50 model series, for example from BMW and Daimler, implement a MOST network (e.g., MOST25 at 25Mbit/s at Daimler, see [START_REF] Leonhardi | MOST150's new features in a series project[END_REF]). MOST has now become a de-facto standard for transporting audio and video streams within vehicles (see [START_REF] Muyshondt | Consumer and automotive electronics converge: Part 1 -Ethernet, USB, and MOST[END_REF][START_REF] Muyshondt | Consumer and automotive electronics converge: Part 2 -a MOST implementation[END_REF]).

The third revision of MOST [START_REF]MOST Specication Revision 3.0 E2[END_REF] has introduced the support of a channel that can transport standard Ethernet frames and is thus well suited to transmit IP trac. These features, along with the higher bandwidth provided by MOST150 introduced in 2007, are already taken advantage of in some new vehicle projects [START_REF] Leonhardi | MOST150's new features in a series project[END_REF] to provide access to internet services and web browsing, and independent access to audio and video sources from all seats with a single bus. In [START_REF] Klos | MOST in future automotive connectivity[END_REF], the MOST consortium announces its intention to develop a next generation of the protocol, with a target bandwidth of 5Gbit/s, that would be suited as well for ADAS requiring the transmission of uncompressed video streams, competing thus with automotive Ethernet solutions. Automotive was at some time considered a serious competitor for MOST technology but, despite a few early implementations at Renault and Nissan, as far as we know the protocol did not reach wide acceptance in the automotive market.

Automotive Ethernet

At the time of writing, the question is not if, but when Ethernet will become a standard technology in cars [START_REF] Yoshida | NXP: 3 phases of Automotive Ethernet[END_REF][START_REF] Hammerschmidt | Beyond FlexRay: BMW airs Ethernet plan[END_REF][START_REF] Tuohy | Next generation wired intra-vehicle networks, a review[END_REF]. For instance, Continental expects to start series production of Ethernet-capable control units as soon as in 2015 [START_REF] Continental | Continental shows Ethernet test setup[END_REF]. The introduction of Ethernet will however be gradual, and

Ethernet is probably going to full dierent use-cases over time. This paragraph discusses these use-cases and the main Ethernet technologies that are considered for use.

Motivation and use-cases for Ethernet

The rst motivation for Ethernet is that it is a low-cost and mature technology that oers much more bandwidth that what is available today, which is of interest for infotainment and active safety especially [START_REF] Hank | Automotive Ethernet, a holistic approach for a next generation in-vehicle networking standard[END_REF]. From the user perspective, as well as from an economic point of view, the re-use of non automotive-specic networking technologies such as Ethernet can be benecial. However, automotive specic requirements must be taken into account: e.g., the need for partial networking and power over Ethernet to reduce the wiring, provision of specic QoS, robustness to severe environmental conditions (e.g., EMI, heat, etc).

In [START_REF] Hank | Automotive Ethernet, a holistic approach for a next generation in-vehicle networking standard[END_REF], the authors describe a plausible roadmap for the use of Ethernet.

First generation Ethernet network, based on 100BASE-TX physical layer, will be for diagnostics (using ISO 13400 standard) and code upload (as already done since 2008, see [START_REF] Kellermann | Electrical and electronic system architecture[END_REF]). The second generation Ethernet network, from 2015 onwards, will support infotainment and camera-based ADAS using Ethernet AVB (see 2.5.3) and BroadR-Reach physical layer (see 2.5.2).

At the third stage, from 2020 onwards, gigabit Ethernet should become the backbone interconnecting most other networks, and replacing thus today's gateways (see section 4). This communication architecture will benet from the ability of Ethernet switches to handle ports having dierent speeds. The backbone will have to support various kinds of trac with dierent QoS requirements, and thus require QoS policies that may be oered, according to the authors of [START_REF] Hank | Automotive Ethernet, a holistic approach for a next generation in-vehicle networking standard[END_REF], by a second generation of AVB protocols. A new physical layer derived from today's 100Mbit/s BroadR-Reach will be needed, and Time-Triggered transmissions would be available.

BroadR-Reach physical layer

BroadR-Reach is a 100MBit/s physical layer over low-cost unshielded copper wires that is being developed by the OPEN Alliance SIG consortium (see http://www.opensig.org/). This consortium, that already counts 140 member companies with many of the carmakers along with Robert Bosch and Continental, aims at establishing BroadR-Reach as the standard for the automotive Ethernet physical layer, with Gb/s speed in its roadmap [START_REF] Humig | Next generation automotive network architecture based on Ethernet[END_REF].

For that purpose, BroadR-Reach was designed to meet the automotive requirements in terms of cost, power saving modes, robustness to environmental conditions, etc. One clear advantage of BroadR-Reach over standard 100BASE-TX Fast Ethernet is that it only requires a single pair of copper cables. At the time of writing, the Broad-R-Reach specication is close to being nal [START_REF] Yoshida | NXP: 3 phases of Automotive Ethernet[END_REF]. Experiments in [START_REF] Steinbach | Tomorrow's in-car interconnect? A competitive evaluation of IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802)[END_REF] suggest that AVB would be an excellent option for incar multimedia streams, with the advantage that it enables to dynamically register data ows and can be used with higher level protocols for handling audio/video streams such as IEEE 1733. To the best of our knowledge, there is not clear cut answer yet about the suitability of the current AVB standard for the transmission of critical control data. In October 2012, AVnu Alliance has announced the formation of the AVB Gen2 Council with the aims to improve AVB functionality in areas such as time-sensitive transmission and fault tolerance. This new specication is currently in development within the IEEE (Audio/Video Bridging Task Group). TTEthernet is designed to be operational in cross-domain critical applications, up to highest criticality level such as DO178 DAL-A in aeronautics, and thus possesses a wide range of fault-tolerant mechanisms. Besides, the time-triggered trac oers a temporal QoS that cannot be matched by the current version of AVB. These features could be needed for some future automotive applications. Another idea currently investigated [START_REF] Yoshida | NXP: 3 phases of Automotive Ethernet[END_REF][START_REF] Steinbach | Tomorrow's in-car interconnect? A competitive evaluation of IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802)[END_REF] is the integration of AVB and TTEthernet, which the aim to come up with an ecient solution for all common automotive Ethernet use-cases.

3 Automotive middleware

Objectives of an embedded middleware

The design of automotive electronic systems has to take into account several constraints. First, nowadays, the performance, quality and safety of a vehicle depend on functions that are mainly implemented in software (for example, the engine control, body electronics, ADAS, etc.) and moreover depend on a tight cooperation between these functions. For example, the control of the engine is done according to requests from the driver (speeding up, slowing down as transmitted by the throttle position sensor or the brake pedal) and requirements from other embedded functions such as climate control, ESP or brake assist. Second, in-vehicle embedded systems are produced through a complex cooperative multi-partner development process shared between OEMs and suppliers. Therefore, in order to increase the eciency of the production of components and their integration, two important problems have to be solved: 1) the portability of components from one Electronic

Control Unit to another one enabling some exibility in the architecture design, and 2) the reuse of components between platforms which is a keypoint for car manufacturers. Thus the cooperative development process raises the problem of interoperability of components. A classic approach for easing the integration of software components is to implement a middleware layer that provides application programs with common services and a common interface. In particular, the common interface allows the design of an application disregarding the hardware platform and the distribution, and therefore enables the designer focusing on the development and the validation of the software components and the software architecture that realize a function. plicate of CAN (see [START_REF] Pinho | Reliable real-time communication in CAN networks[END_REF]), the provision of a reliable acknowledgment service or message authentication mechanism on CAN, the status information on the data consumed by the application components (e.g., data was refreshed since last reading, its freshness constraint was not respected, etc.) or ltering mechanisms (e.g., notify the application for each k reception or when the data value has changed in a signicant way).

Note that a more advanced features would be to come up with adaptive communication services, thanks to algorithms that would modify at run-time the parameters of the communication protocols (e.g., priorities, transmission frequencies, etc.) according to the current requirements of the application (e.g., inner-city driving or highway driving) or changing environmental conditions (e.g., EMI level). For the time being, to the best of our knowledge, such features exist in series automotive embedded systems only for low-power modes (see 1.5, see also [START_REF] Ziermann | DynOAA -dynamic oset adaptation algorithm for improving response times of CAN systems[END_REF] for a research work in the direction of more adaptive communication systems). In fact, this point requires a coordinated approach for the design of function (as the denition of control law parameters, the identication of the parameters acting on the robustness of the function, etc.) and the deployment of the software architecture that implements the function (specically the communication parameters). By increasing the efciency and the robustness of the application, such an adaptive strategy would certainly ease the re-usability. and ensure a predictable and deterministic real time communication system thanks to schedulability analysis techniques (see [START_REF] Tindell | Calculating Controller Area Network (CAN) message response times[END_REF][START_REF] Casparsson | Volcanoa revolution in on-board communications[END_REF]). To the best of our knowledge, there are no publicly available technically precise descriptions of both TITUS and Volcano.

A rst step to dene a standard for in-car embedded middleware was started by the OSEK/VDX consortium (http://www.osek-vdx.org). In particular, two specications are of particular interest in the context of this chapter: the OSEK/VDX Communication layer [START_REF]OSEK/VDX Communication[END_REF] and the Fault-Tolerant Communication layer [START_REF]OSEK/VDX Fault-Tolerant Communication[END_REF]. The rst one species a communication layer [START_REF]OSEK/VDX Communication[END_REF] OSEK/VDX Communication runs on top of a transport layer (e.g., [START_REF]International Standard Organization. 15765-2, Road Vehicles -Diagnostics on CAN -Part 2[END_REF]) that takes care mainly of possible segmentation of frames and it can operate on any OS compliant with OSEK/VDX OS services for tasks, events and interrupt management (see [START_REF]OSEK/VDX Operating System[END_REF]).

OSEK/VDX Communication is not intended to be used on top of a Time-Triggered (TT) network, as for example TTP/C or FlexRay. For this purpose, there is OSEK/VDX FTCom specication (Fault-Tolerant Communication, see [START_REF]OSEK/VDX Fault-Tolerant Communication[END_REF]) whose main role is to manage the redundancy of data needed to achieve fault-tolerance (i.e., the same information can be produced by a set of replicated nodes) by presenting only one copy of data to the receiving application according to the strategy specied by the designer. Two other important services of OSEK/VDX FTCom, already oered by OSEK/VDX Communication, are to manage the packing/unpacking of messages [START_REF] Saket | Frame packing algorithms for automotive applications[END_REF], and to provide message ltering mechanisms for passing only signicant data to the application. OSEK/VDX FTCom was developed to run on top of a timetriggered operating system (OS) such as OSEK Time [START_REF]OSEK/VDX time triggered operating system[END_REF]. OSEK/VDX is no more under active development and has been superseded by AUTOSAR. eases the mastering of the complexity, allows the portability of application software components and therefore the exibility for product modication, upgrade and update, as well as the scalability of solutions within and across product lines. Besides, AUTOSAR ensures a smooth integration process of components provided by dierent companies while protecting the industrial properties of each actor involved. The AUTOSAR reference architecture is schematically illustrated in gure 8. An important issue is the automatic generation of an AUTOSAR middleware that has to be done from the basic software components, generally provided by suppliers, and the specication of the application itself (description of applicative-level tasks, signals sent or received, events, alarms, etc.). The challenge is to realize such a generation so that the deployment of the middleware layer can be optimized for each ECU.

AUTOSAR -a standard for the automotive industry

The communication services

One of the main objectives of the AUTOSAR middleware is to hide the characteristic of the hardware platform as well as the distribution of the application software components. Thus the inter-or intra-ECU communication Conceptually a signal is exchanged between application software components through ports disregarding the distribution of this component.

The application needs to precise a Transfer Property parameter that will impact the behavior of the transmission and whose value can be triggered (each time the signal is provided to the middleware by the application, it has to be transmitted on the network) or pending (the actual transmission of a signal on the network depends only on the emission rule of the frame that contains the signal). Furthermore, when specifying a signal, the designer has to indicate if it is a data, an event or a mode. For data transmission, incoming data are not queued on the receiver side while for event exchanges, signals are queued on the receiver side and therefore, for each transmission of the signal, a new value will be made available to the application. The handling of buers or queues is done by the RTE. or none (for I-PDUs whose emission rules depend on the underlying network protocol, as e.g., FlexRay; no transmission is initiated by AUTOSAR COM in this mode).

an N-PDU is built by the basic components CAN TP (Transport Protocol) or FlexRay TP. It consists of the data payload of the frame that will be transmitted on the network and protocol control information.

Note that the use of a transport layer is not mandatory and I-PDUs can be transmitted directly to the lower layers (see gure 9).

The RTE (Run Time Environment) implements the AUTOSAR middleware interface and the corresponding services.

In particular, when using the sender/receiver model, the RTE handles the implicit/explicit communication modes and the fact that the communication involves events (queued) or data (unqueued). The AUTOSAR COM component is responsible for several functions: on the sender side, it ensures the transmission and noties the The E2E library is implemented as a set of functions that can be invoked Each prole oers all or a subset of the following data protection mechanisms:

checking the integrity of an exchanged data. This is done by an additional CRC computed by a function belonging to the E2E library, checking the systematic transmission of a data thanks to a Sequence Counter. The Sequence Counter is incremented upon each transmission of the data, allowing thus the receiver to verify that no instance of the data has been lost, checking, from the receiver side, if a sender is transmitting a data as expected. For this purpose, an Alive Counter is used, it is incremented upon each transmission of the data and the receiver can verify that the counter has been incremented, to check if the received data is the one that is expected. This mechanism is based on the denition of a data ID that is not transmitted with the data but that is used in the computation of the CRC, nally, to verify that the data is sent and/or received on time. Two mechanisms are provided for this purpose: receiver communication timeout and sender acknowledgment timeout.

The CRC and the counters are integrated into a E2E header, which is an additional control eld transmitted along with the data payload. When a faulty transmission is detected, the error is then reported to the calling component.

Conclusions and discussion

In our view, the development of in-vehicle embedded communications can be schematically subdivided into 4 main successive periods: One may imagine that the next stage will be when the car will become an IP node in the world wide web ( [START_REF] Hammerschmidt | Beyond FlexRay: BMW airs Ethernet plan[END_REF], see also [START_REF] Hoschka | W3C launched work on Web and automotive[END_REF]), integrated into global data infrastructures enabling a more ecient type of collaborative mobility [START_REF] Radusch | Collaborative mobility -beyond communicating vehicles[END_REF] relying on interactions between users and infrastructure operators.

Over the years, the technologies needed for the interoperability between applications located on dierent ECUs and sub-networks have been improved.

With AUTOSAR, we are now close to the desirable characteristics listed in section 3. However, if the traditional partitioning of automotive applications into several distinct functional domains with their own characteristics and requirements has proven useful in mastering the complexity, it lead to the development of several independent sub-systems with their specic architectures, networks and software technologies. Some diculties arise from this partitioning since more and more cross-domain data exchanges are needed.

The current practice is to transfer data between dierent domains through a central gateway (see, for example, [START_REF] Kellermann | Electrical and electronic system architecture[END_REF]). This subsystem is recognized as being critical in the vehicle: it constitutes a single point of failure, its design is overly complex and ensuring a guaranteed QoS through gateways is dicult and require a careful design (see, for instance, [START_REF] Sommer | Optimized resource dimensioning in an embedded CAN-CAN gateway[END_REF] and [START_REF] Davis | Trac shaping to reduce jitter in Controller Area Network (CAN)[END_REF]). In the future, the interconnection between vehicle subdomains could be more eciently ensured by an Ethernet backbone [START_REF] Hank | Automotive Ethernet, a holistic approach for a next generation in-vehicle networking standard[END_REF], instead of a gateway. This backbone will have to support various trac with dierent QoS requirements on the same network, which will require to implement QoS policies such as bandwidth reservation.

A perhaps more dicult challenge ahead of us is security: automotive systems must be designed to be more resilient to security attacks. This entails nding the technical solutions, but also the new cooperation schemes between all the automotive stakeholders, that will permit to achieve the right trade-o for the automotive domain, between costs/overhead and security level.

These

  Area Network) is without a doubt the most widely used in-vehicle network. It was designed by Bosch in the mid 80's for multiplexing communication between ECUs in vehicles and thus for decreasing the overall wire harness: length of wires and number of dedicated wires (e.g. the number

Figures 1 and 2 )

 2 Figures 1 and 2), whose numerical value determines the frame priority. There are two versions of the CAN protocol diering in the size of the identier: CAN 2.0A (or standard CAN) with an 11 bit identier and CAN 2.0B (or extended CAN) with a 29 bit identier. For in-vehicle communications,

Figure 1 :Figure 2 :

 12 Figure 1: Format of the CAN 2.0A data frame

Figure 3 :

 3 Figure3: CAN arbitration phase with two nodes starting transmitting simultaneously. Node 2 detects that a frame with a higher priority than its own is being transmitted when it monitors a level 0 (i.e. dominant level) on the bus while it has sent a bit with a level 1 (i.e. recessive level). Afterwards, Node 2 immediately stops transmitting.

  several reasons: It helps to master the complexity of the architectures, It reduces the hardware costs, weight, space, consumption, etc, It facilitates an incremental design process, It may avoid the industrial risk, the costs and the time to master new technologies such as FlexRay, It leads to better communication performances and helps to match the bandwidth needs. Sometimes, a 60%-loaded CAN network can be more ecient that two 40% CAN networks interconnected by a gateway causing delays and high jitters.

FlexRayFigure 4 :Figure 5 :

 45 Figure 4: Example of a FlexRay communication cycle with 4 nodes A, B, C and D

  of frames are used to convey signals. Unconditional frames are the usual type of frames used in the master-slave dialog and are always sent in their frame-slots. Sporadic frames are frames sent by the master, only if at least one signal composing the frame has been updated. Usually, multiple sporadic frames are assigned to the same frame-slot and the higher priority frame that has an updated signal is transmitted. An event-triggered frame is used by the master willing to obtain a list of several signals from dierent nodes. A slave will only answer the master if the signals it produces have been updated, thus resulting in bandwidth savings if updates do not take place very often. If more than one slave answers, a collision will occur. The master resolves the collision by requesting all signals in the list one by one.

  master will then resolve the collision by sending one by one the individual identiers of the list during the successive frame slots reserved for polling the list. Finally, diagnostic frames have a xed size of 8 bytes, xed value identiers for both the master's request and the slave answers and always contain diagnostic or conguration data whose interpretation is dened in the specication.

2. 5 . 4 TTEthernetTTEthernet [ 94 ]

 5494 is a time-triggered switched Ethernet protocol, promoted by the TTA-Group (see http://www.ttagroup.org/), that was standardized as SAE AS6802 in 2011. TTEthernet natively supports mixed-criticality temporal requirements as it denes 3 types of trac streams: time-triggered (with oine congurated transmission schedule), rate constrained (i.e., the maximum workload is bounded) and best eort. Upper bounds on the jitters and latencies can be derived for both the time-triggered and rate constrained trac. The temporal QoS in terms of jitters is better for the time-triggered trac but sending and receiving must be done at pre-dened points in time.Conceptually, the Rate-constrained trac model is similar to Virtual links in AFDX, and SR-Class A and B in AVB.

  Among the set of common services usually provided by a middleware, those that related to the communication between several application components are crucial. They have to meet several objectives: Hide the distribution through the availability of services and interfaces that are the same for intra-ECU, inter-ECU, inter-domain communications whatever the underlying protocols, Hide the heterogeneity of the platform by providing an interface independent of the underlying protocols, of the CPU architecture (e.g., 8/16/32 bits, endianness), of the Operating Systems, etc.Provide high-level services in order to shorten the development time and increase quality through the re-use of validated services (e.g., periodic transmission, working mode management such as partial networking, etc.). A good example of such a function is the frame-packing (sometimes also called signal multiplexing) that enables application components to exchange signals (e.g. the number of revolutions per minute, the speed of the vehicle, the state of a light, etc.) while, at runtime, frames are transmitted over the network; so, the frame-packing service of a middleware consists in packing the signals into frames and sending the frames at the right points in time for ensuring the deadline constraint on each signal it contains, Ensure QoS properties required by the application, in particular, it can be necessary to improve the QoS provided by the lower-level protocols as, for example, by furnishing an additional CRC (Cyclic Redundancy Code), transparent to the application, if the Hamming distance of the CRC specied by the network protocol is not sucient in regard to the dependability objectives (cf. the end-to-end communication protection library of AUTOSAR in3.3.3). Other examples are the correction of bugs in lower level protocols such as the inconsistent message du-

3. 2

 2 Former propositions of middleware Some proprietary middleware (MW) were developed by several carmakers in order to support the integration of ECUs and software modules provided by their third-party suppliers. For instance, the TITUS/DBKOM communication stack, was a proprietary middleware (MW) of Daimler that standardizes the cooperation between components according to a client/server model. Volcano[START_REF] Casparsson | Volcanoa revolution in on-board communications[END_REF][START_REF] Rajnák | The Volcano communication concept[END_REF] is a commercial product of Mentor Graphics, initially developed in tight cooperation with Volvo. The Volcano Target Package (VTP) consists of a communication layer and a set of o-line conguration tools for application distributed on CAN and LIN. It is aimed at providing the mapping of signals into frames under network bandwidth optimization

  that denes common software interfaces and common behavior for internal and external communications between application components. How signals are packed into a frame is statically dened o-line and the OSEK/VDX Communication layer automatically realizes the packing / unpacking at run-time as well as the handling of queued or unqueued messages at the receiver side.

From

  2001 to 2004, the ITEA European project EAST-EEA aimed at the specication of an automotive MW for the automotive industry. To the best of our knowledge, this was the rst important initiative targeting the specication of both the services to be ensured by the middleware and the architecture of the middleware itself in terms of components and architecture of components. Similar objectives are guiding the work done in the AUTOSAR consortium, see http://www.autosar.org and[START_REF] Fennel | Achievements and exploitation of the AUTOSAR development partnership[END_REF][START_REF] Fürst | AUTOSAR for Safety-Related Systems: Objectives, Approach and Status[END_REF][START_REF] Kirschke-Biller | A worldwide standard current developments roll out and outlook[END_REF], that gathers most the key players in the automotive industry. The specications produced by the consortium become quickly de-facto standards for the cooperative development of in-vehicle embedded systems (see, for instance, the migration to AUTOSAR at PSA Peugeot-Citröen[START_REF] Dezaux | Migration strategy of in-house automotive real-time applicative software in AUTOSAR standard[END_REF]).

3. 3 . 1

 31 The reference model AUTOSAR species the software architecture embedded in an ECU. More precisely, it provides a reference model which is comprised of three main parts: the application layer, the basic software (middleware software components), and the Run Time Environment (RTE) that provides standardized software interfaces to the application software.

Figure 8 :

 8 Figure 8: AUTOSAR reference architecture

Figure 9 :

 9 Figure 9: Communication software components and architecture

I

  -PDU are built by the AUTOSAR COM component. Each I-PDU is made of one or several signals and is passed via the PDU Router to the communication interfaces. The maximum length of an I-PDU depends on the maximum length of the L-PDU (i.e., Data Link Layer PDU) of the underlying communication interface: for CAN and LIN the maximum L-PDU length is 8 bytes while for FlexRay the maximum L-PDU length is 254 bytes. AUTOSAR COM ensures a local transmission when both components are located on the same ECU, or by building suited objects and triggering the appropriate services of the lower layers when the components are remote. This scheme enables the portability of components and hide their distribution. The transformation from signals to I-PDU and from I-PDU to signals is done according to an o-line generated conguration. Each I-PDU is characterized by a behavioral parameter, termed Transmission Mode whose possible value is direct indicates (the sending of the I-PDU is done as soon as a triggered signal contained in this I-PDU is sent at application layer), periodic means (the sending of the I-PDU is done only periodically), mixed (the rules imposed by the triggered signals contained in the I-PDU are taken into account, and additionally the I-PDU is sent periodically if it contains at least one pending signal)

  at two levels: by application software components (thanks to a wrapping technique) or from the COM component. These functions are stateless and have to report synchronously a verdict (i.e., the success of the exchange or the detected errors) to their calling component. The end-to-end communication protection is based on a standardization of mechanisms under the concept of E2E prole. Each prole can have several variants. So the instantiation of one prole for a specic information exchange consists in the choice of a variant and therefore the setting of the corresponding conguration options.

  communication through point-to-point links -until the beginning of the 90s, CAN-based architectures as de-facto standard -until 2006, the advent of AUTOSAR and FlexRay -until 2010, the emergence of automotive Ethernet and security concerns since then.

  The data eld length can be up to 64 bytes long: from 0 to 8 bytes, then above 8 bytes, the possible values are 12, 16, 20, 24, 32, 48 and 64 bytes. Technically, two bit rates are used successively in the transmission of a CAN FD frame: one lower for the arbitration phase, as required by the CAN bitwise arbitration (see 2.2.2)

2.1.4

CAN FD: a high speed CAN network CAN FD is a new protocol that was presented for the rst time by Robert Bosch GmbH at the International CAN Conference in 2012

[START_REF] Hartwich | CAN with Flexible Data-Rate[END_REF]

that combines CAN's core features with a higher data rate and larger data payloads.

  issues will certainly require more research and development work but the current state of technological maturity in security, network hardware components, communication protocols and middleware engineering is such that in our view everything is at hand to succeed in building safe, secure and cost-optimized embedded communication architectures for the next car generations.

	Index
	100BASE-TX, 28	middleware, 29, 3133
	1394 Automotive, 25, 26	MOST, 8, 25, 26
	Advanced Driver Assistance Systems	Nissan, 26
	(ADAS), 3, 10, 26, 27	Non-Return-to-Zero (NRZ), 11
	AFDX, 29 AUTOSAR, 9, 10, 15, 32, 33, 35, 37, 38	OPEN Alliance SIG, 27 OSEK/VDX, 15, 31
	AVB, 18, 25, 2729	partial networking, 9, 27, 30
	AVB Gen2 Council, 28	point-to-point communication, 3, 38
	AVnu Alliance, 28	powertrain domain, 4
		PSA, 17, 32
	BMW, 4, 8, 19, 26	PSI5, 5, 25
	BroadR-Reach, 27
		QoS, 25, 27, 29, 39
	CAN, 49, 11, 15, 3638
	CAN 2.0A, 11	Renault, 26
	CAN 2.0B, 11	Robert Bosch, 4, 17, 21, 27
	CAN FD, 10, 17
	chassis domain, 5	SAE AS6802, 28
	collaborative mobility, 39	SAE classication, 7
	COTS toolsets, 15	SAE J2716, 25
		schedulability analysis, 16, 31
	Daimler, 26, 31	scheduling frames with osets, 16
		security, 9, 10, 38
	ECU degradation, 9	SENT, 5, 25
	end-to-end communication protection	simulation, 16
	library, 30, 37	SPC protocol, 25
	Ethernet, 8, 2628, 38, 39
		TDMA, 6, 18, 19
	FlexRay, 8, 15, 18, 31, 36, 38	time-triggered, 6, 18, 19, 21, 25, 28,
	frame-packing, 16, 20	32
	FTT-CAN, 7	trace analysis, 16
	functional domains, 4	TTCAN, 7, 18, 21, 22
		TTEthernet, 7, 18, 28
	gateway, 8, 15, 16, 18, 39	TTP/A, 7, 22, 25
		TTP/C, 7, 18, 19, 31
	ISO 11898-6, 9
		VAN, 11, 17
	J1850, 7, 11, 17	virtualization, 10
	J1939, 15	Volvo, 8, 31
	LIN, 5, 7, 8, 17, 22, 36, 37

X-by-Wire, 5, 18

The freshness property is veried if data has been produced recently enough to be safely consumed: the dierence between the time when the data is used and its production time must be always smaller than a specied value. The delay experienced by a data is made up of the network latency, plus the latencies on the sending and receiving ends which can be large especially if the application tasks are not synchronized with the transmissions on the network (see[START_REF] Grenier | Conguring the communication on FlexRay: the case of the static segment[END_REF]).

Dierent nodes can send frames in the same slot but in dierent cycles, this is called slot multiplexing and it is only possible only in the dynamic segment.

application about its outcome (success or error). In particular, AUTOSAR COM can inform the application if the transmission of an I-PDU did not take place before a specied deadline (i.e., deadline monitoring). On the receiver side, it also noties the application (success or error of a reception) and supports the ltering mechanism for signals (dispatching each signal of a received I-PDU to the application or to a gateway). Both at the sending and receiving end, the endianness conversion is taken in charge. An important role of the COM component is to pack/unpack signals into/from I-PDU s.

Note that, as the maximal length of an I-PDU depends on the underlying networks, the design of a COM component has to take into account the networks and therefore it is not fully independent of the hardware architecture.

The COM component has also to determine the points in time where to send the I-PDUs. This is based on the attributes Transmission Mode of an I-PDU and on the attribute Transfer Property of each signal that it contains.

3.3.3

The end-to-end communication protection library

In order to support safer communications between application software components, the AUTOSAR standard species the End-to-End Communication Protection Library [START_REF] Autosar | Specication of SW-C end-to-end communication protection library[END_REF]. The specied End-to-End mechanisms aim to ensure that safety-critical data exchanges (up to ASIL D safety level) can be protected against faults that may occur at runtime during the transmission of the data: faults aecting the hardware (e.g., bit-ipping due to EMI in the sending communication stack) or software faults due to the incorrect development of a component of the communication stack. In particular, the E2E protection mechanisms allow:

to attach, on the sender side, specic control data to data that are to be sent to the RTE, to verify, on the receiver side, through the control data, the correction of the data received from the RTE, to report, when it occurs, that received data are faulty. In this case, the fault has to be handled by the receiver software components.