AUTomotive Open System ARchitecture (AUTOSAR) is an international network of OEMs and automotive suppliers with the aim of establishing an open standard for automotive software architectures.

Members of this consortium include Daimler and BMW on the OEM side, and Bosch and Continental on the automotive supplier side. In total, AUTOSAR comprises ten Core Partners, 51 Premium Members, 44 Associate Members and three Development Members.

The architecture of the AUTOSAR-based software is composed of functional modules that have been independently developed by different manufacturers and merged into a project in a largely automated configuration process.

AUTOSAR sees itself only as a standardisation committee that develops specifications, but does not prescribe binding rules for implementation. This is left to individual providers in open competition.

CAN is the most widely used bus system in the automotive sector and is also used in automation technology. The CAN bus supports data rates of up to 1 MBit/s, but common usage rates only reach around 500 KBit/s.

Development began in the early 1980s at Bosch in order to reduce the cabling work involved in the networking of various control units and sensors. At that time, all devices were wired directly, resulting in huge harnesses. The CAN bus is specially tailored to requirements of the automotive industry (very secure data transmission, low costs). Since 1994, CAN has been standardised by ISO standards 11898-1 to -3. These describe two different physical layers, CAN high-speed and CAN low-speed. CAN high-speed supports data transfer rates of up to 1 Mbit/s and is designed for applications in the drive train and chassis sector. CAN low-speed reaches a maximum of 125 kbps and is used more for comfort electronics in the interior.

Communications via CAN is event-driven, meaning messages are sent when they occur. In general, each node has the same access rights to the bus and is allowed to send at any time. The prioritisation is in the message. Important messages receive low IDs, less important messages receive higher IDs. If there are collisions, the message with the lower ID and therefore higher priority is preferred (the node with the higher ID withdraws). If the bus load is very high, low-priority messages may be sent with great delay.

Transmission technology

CAN signal transmission is subdivided into two types of transmission: CAN high-speed and CAN low-speed. Both types of transmission are based on a differential signal consisting of two levels, the high and the low CAN data line.

With high-speed CAN, the logical one is differential at about 0V, logical zero is differential at 2V. CAN low-speed uses approximately 5 V differential for the logical one and 2 V differential for the logical zero as well. Communication between CAN high-speed and CAN low-speed is not possible due to the different voltage levels.

FIBEX (FIeld Bus Exchange Format) is an XML database format defined by ASAM (association for standardisation of automation and measuring systems) for describing message-oriented communication systems in automobiles.

FIBEX enables the exchange of data between software tools that work with message-oriented bus communication systems. It contains all information for the description of complete on-board electrical systems of a vehicle. It is standardised by ASAM and freely available. With the help of FIBEX, complex automotive communication systems can be described in an XML file. It supports the description of the following bus systems:

• CAN
• TTCAN
• LIN
• FlexRay
• MOST

FIBEX' versatility facilitates communication and data exchange between all project participants.

When developing a control unit, the proper functioning tests are of enormous importance. However, the complete system is not available for testing the control unit in most cases. Therefore, one must simulate the missing control unit data by means of a so-called restbus simulation (RBS).

There are many application possibilities and deployment times of a restbus simulation in vehicle development. It can be used at an early stage for rudimentary ECU testing right through to partial integration testing of automotive networks. A restbus simulation is ideal whenever only parts of a network are present and the rest must be simulated. Missing functionalities of any control unit can be simulated in the RBS.

Usually the OEM provides the global design and description of the system up to the partitioning of the ECUs. Because such a system consists of a variety of signals with all kinds of properties and values, it is important to reduce the complexity involved. One must therefore identify the relevant signals that affect the ECU application. In addition, the configuration must provide adequate timing behaviour to enable real-time behaviour of the selected system.

FLEXRAY-RESTBUS SIMULATION

Compared to previous bus systems, FlexRay has higher transmission rates and it is also capable of real-time operation thanks to Time Division Multiple Access. However, this places significantly higher demands on the development and structure of a FlexRay network, which also affects the FlexRay restbus simulation (RBS). In an RBS with FlexRay, messages must be sent at fixed times. This requires real-time scheduling.

For a FlexRay controller to even send data, various boundary conditions must be met. Among others, these include the presence of at least two start-up nodes, correctly calculated CRC algorithms, accurately transmitted network management messages, and Message (Alive) counters. All this must be taken into account by a FlexRay RBS in real time. Unlike with CAN, it makes more sense to run a RBS on dedicated hardware with FlexRay. A real-time hardware platform ensures that FlexRay messages are sent in their designated slots. An example of such a kind of hardware is the FlexDevice-L. Due to the variety of connection options (CAN, FlexRay, LIN, RS232, SPI, CAN-FD, Ethernet, BroadR-Reach), this hardware can be used in many application areas.

The FlexRay protocol consists of a static and dynamic segment, which combines the advantages of both communication variants TDMA and FTDMA. The FlexRay bus uses three different differential signals here: Idle, high and low.

Bus systems distinguish between time-controlled and event-controlled communication. Time-controlled communication operates on the principle of Time Division Multiple Access (TDMA), in which each participant is granted a specific time slot on the bus that repeats in fixed intervals. This guarantees a deterministic transmission of the messages, but has the disadvantage that the bandwidth is not used efficiently: Each time slot is reserved for a particular participant, even if it does not transmit data. Event-driven communication has advantages, in which participants only send when an event occurs, for example, when new data is available for transmission.

A variation of time-controlled communication in the direction of event control is the Flexible Time Division Multiple Access (FTDMA) method, in which short slots with consecutive numbering are assigned to the participants. If a participant wants to send in his slot, he increases the size of this slot, which moves subsequent slots back in time. This achieves a more efficient use of bandwidth.

The FlexRay bus uses both time-controlled communication variants TDMA and FTDMA and thus combines the advantages of both concepts: deterministic data transmission in a static bandwidth, as well as use of the available bandwidth in a dynamic segment.

Data transmission on a FlexRay bus takes place on two physically separated channels with a data transmission rate of 10 Mbit/s each. If both channels are operated redundantly, meaning they send identical data, communication is maintained if one channel fails. Alternatively, it is possible to transmit different data on both channels in order to theoretically realize data rates of up to 20 Mbit/s.

Transmission technology

The FlexRay bus uses a differential signal with three levels: Idle, high and low. The voltage is 0 V differential in idle state. Idle means that there are no messages on the bus. The logical one is differential at about 2V, the logical zero is differential at -2V. FlexRay is terminated at the ends of the bus line between bus plus and bus minus each with the line impedance, meaning about 90 Ω. A FlexRay bus has two channels in which transmission between channels A and B is not possible due to the different checksum (CRC) in the message header.

The Extensible Mark-up Language, abbreviated XML, is a standard for creating documents in the form of a tree structure readable by machines and humans. XML defines the rules for the structure of these documents.

For a specific XML application, the details of each document must be specified. In particular, this relates to the definition of the structural elements and their arrangement within the document tree.

XML is thus a standard for the definition of arbitrary mark-up languages that are however strongly related in their basic structure. An XML element can thus describe very different data, such as texts, graphics or even abstract knowledge.

A basic idea behind XML is to separate data and its representation, for example, to output weather data once as a table and once as a graphic, but to use the same database in XML format for both applications.

FlexRay is a fast, deterministic and fault-tolerant bus system for automotive use. Since 2000, the core partners of the FlexRay consortium, BMW, DaimlerChrysler, Motorola (Freescale), Philips Semiconductors (NXP), Bosch, General Motors and Volkswagen have been pushing the FlexRay specification. This is currently being converted into an ISO standard.

Data exchange between the installed control units in the vehicle is now mainly carried out via a CAN network. However, the introduction of new technologies as well as ever-increasing data volumes are leading to increasing demands, particularly with regard to fault tolerance and time control for message transmission. FlexRay fulfils these increased demands by transmitting messages in fixed time slots and by a fault-tolerant and redundant transmission on two channels.

FlexRay operates on the TDMA principle in which the nodes or messages are allocated fixed slots, in which they have exclusive bus access. These time slots are repeated in a certain cycle. This way, the time at which a message is on the bus can be predicted exactly.

Figure 1: Possible FlexRay topology with 2 channels

Fixed allocation of the nodes or messages to fixed time slots has the disadvantage, however, that the bandwidth is not used to its full capacity. For this reason, FlexRay divides the cycle into static and dynamic sections. The static segment, in which each message is assigned a fixed time slot in which a node must always send, is located at the beginning of a communication cycle. If there are no data, an empty message (so-called “null frame”) is sent in this time slot.

In the subsequent dynamic section, the time slots are allocated dynamically. An exclusive bus access is only possible for a short time (so-called “minislots”). This time slot is then extended by the time required to send a message. Subsequent messages are shifted back. Messages that are not sent therefore do not block the subsequent data exchange because no time slot is reserved for it and the other messages advance accordingly.

Figure 2: Typical FlexRay communication cycle

FlexRay can communicate over two physically separate channels (A + B) at a data rate of 10 Mbit/s each. Today, however, only channel A is used in practice. Both channels are mainly planned for redundant and therefore fault-tolerant message transmission. But they can also transfer different message content. In this case, the data throughput doubles.

To implement the bus access method, the nodes distributed in the communication network need a common time base. Synchronisation messages are transmitted in the static part of the communication cycle in order to match the local clocks of the individual nodes, and thus to obtain a global time base.

A FlexRay node consists of a host processor, the FlexRay Communication Controller (CC), the Bus Guardian (BG) and one bus driver (BD) per channel. The FlexRay Communication Controller is responsible for synchronising the node with the rest of the network

The topology of the FlexRay network is largely open. However, only the daisy-chain connection and the active star are used in the vehicle.

The active star is an active node that receives messages on a branch and transmits them to the other branches in a broadcast similar to a hub.

A daisy-chain connection is simply the looping of a FlexRay line from one node to another.

A wakeup can either be done via the FlexRay network or locally by turning on a node, which initializes it.

Unlike the CAN network, the communication of the FlexRay network does not start immediately after the wakeup. To start a FlexRay network, a start-up process must first be run through so-called cold start nodes (these are nodes that are allowed to initiate a FlexRay network boot) with start-up messages.

The CAN network usually uses a *dbc file as the communication matrix. The FlexRay network with all its nodes including their communication is described in either FIBEX or AUTOSAR.

The FIBEX format is an XML file describing complete vehicle networks, a free standard defined by ASAM e.V. The FIBEX format allows the complete description of FlexRay, CAN, MOST and LIN networks, including all Gateway connections in the vehicle with each other, in a file.

AUTOSAR also describes the communication similar to the FIBEX standard, but adds further information on the functions and behaviour of the control units. Thus a conversion from AUTOSAR to FIBEX is also possible.

A new trend in the networking of control units in motor vehicles is the use of Ethernet. Classic bus systems in the automotive environment, such as MOST, FlexRay and CAN are replaced by Ethernet. The new bus system presents some challenges for developers of automotive networking solutions. This begins with the physical layer of transmission, which is different from traditional Ethernet, and ends with the introduction of new transmission protocols on higher layers.

Transition to Ethernet in vehicle networking has several advantages. On the one hand costs are reduced. This is related to, among other things, expenditures for components in the vehicle. Thus, the wiring for an Ethernet connection is cheaper than an optical cable for using MOST. On the other hand, existing, inexpensive tools from the existing PC and industrial Ethernet world can be used. Another advantage is the higher data transfer rate, which allows some new application fields.

There are various applications for Ethernet in the automotive environment. One of the first deployment options is the transmission of vehicle camera data. The advantage of Ethernet is that network cameras (IP cameras) are not only connected to one control unit, but that several control units can access the data streams of the vehicle cameras. This makes the network very flexible and well-equipped for the future. Thus, an application can be developed that provides a top-view image of the vehicle environment via several cameras.

For later extensions, additional control units can also access the existing camera data. Regarding IP cameras, tool manufacturers in the field of bus analysis are facing new challenges. In the past, a database had to be integrated for classic bus systems such as CAN in order to decode the raw data on the bus and make it readable for humans.

For Ethernet data coming from vehicle IP cameras, the data stream must be analysed to display the associated image (Figure 1).

This means: From the beginning of an image, all Ethernet messages must be cached until the end of the image. Subsequently, the image of the automotive environment can be generated from all cached Ethernet messages.

Picture 1: Caromee bus analysis software with the representation of images coming from IP cameras. In addition, additional buses such as CAN and FlexRay can be analysed.

Another important application is the fast flashing of control units. Flashing over Ethernet significantly reduces flash times. A CAN bus can only transfer data with a maximum length of 8 bytes per message. Ethernet messages have a length of more than 1500 bytes. This increases the user data rate, meaning: Significantly larger message packets can be transmitted in a shorter period of time.

Further applications such as control unit communication, the networking of vehicles with the environment and diagnostic inserts will further increase the importance of Ethernet. Overall, it can be predicted that the complexity and size of messages will continue to increase in the future. Ethernet as a very high-performance, cost-effective technology is therefore the best solution to respond to these requirements.

On a physical level, automotive Ethernet does not rely on Ethernet from the PC world. The aim of the development was a physical transmission of the data streams over unshielded, two-core cables. This was achieved by the Ethernet standard “BroadR-Reach®”. It is also designed for the demanding requirements (keyword interference resistance) in the automotive environment. Transfer rates of 100 MBit are easily achieved. The disadvantage is that this Ethernet canniot be accessed with classic tooling. This means it is not possible to read data from the vehicle's automotive Ethernet via PC with built-in Ethernet controllers. This application requires a converter from automotive Ethernet to standard Ethernet. These are either one-to-one converters, called media switches or switches that have a standard Ethernet port.

In classical control unit development (with CAN and FlexRay, etc.) it was possible to easily access data via a measuring hardware. This is not so easy with automotive Ethernet. The usual option of disconnecting the transmission cable in order to connect a measuring hardware is not feasible. One must focus on other solutions in order to tap data. However, they also have disadvantages because they change the runtime behaviour of messages.

The easiest way to pick up Ethernet traffic from a vehicle is through switches. Since the messages in the switch are processed for some time and then forwarded, the switch influences the runtime behaviour. This latency is not constant, but depends on the processing algorithms in the switch.

Another way to access data from an Ethernet line is through a TAP (Test Access Point). A TAP accesses the data directly on the physical layer and forwards it with a low constant latency.

Figure 2: Measurement set-up for the analysis of CAN and Ethernet with the bus analysis software Caromee, the FlexCard USB as CAN hardware interface and the standard PC interface for Ethernet.

A developer of an application always raises the question as to what time frame the tooling has to fulfil for an analysis. For simple applications in which the jitter between Ethernet and another bus system plays only a minor role, a structure for the bus analysis as shown in Figure 2 would be sufficient. In this case, the time stamp varies in a range of up to 20ms. However, this would be sufficient to analyse images, for example from the vehicle environment, in a temporal context with a CAN message that comes only once per image. At an image data rate of 25 frames per second, a transmission of an image would theoretically take 40ms. Measurement accuracy would therefore be sufficiently high.

Figure 3: Measurement set-up for the analysis of CAN and Ethernet with the bus analysis software Caromee and the FlexCard PMCII for high-precision time requirements.

If a very accurate temporal correlation between an Ethernet bus and a classic bus is to be met, the measurement set-up for the analysis would have to look like Figure 3. In this case, Eberspächer Electronics' FlexCard PMC II is used as the Ethernet and CAN sensor. The FlexCard PMC II ensures a time-synchronised time stamp for individual messages. The accuracy of the time stamp lies in the microsecond range. Both measurement set-ups are not only suitable for recording a vehicle test drive. With the Caromee analysis software, it is even possible to play the data again synchronously. This allows to repeatedly test algorithms of control units with a particular recording.

Figure 4: ISO/OSI layer model

In the ISO/OSI layer model (Figure 4) layer one, the so-called automotive Ethernet, is currently covered by BroadR-Reach® in many applications. Layer two in the model is provided by the standard Ethernet MAC and VLAN. With VLAN, however, double VLAN is already implemented. Several standards apply at the network layer (layer three). For example, video applications are often set to IEEE 1722. In the diagnostic area, IP (DoIP) is used on the network layer and TCP on the transport layer (layer four). For the communication of control units with each other, the network layer is covered by IP. At transport level, the protocols use TCP or UDP. At a higher level, such as control unit communication, there are protocol standards such as Some-IP and Service Discovery.

The protocol Some-IP is used for the communication of control units with each other. This protocol is a change from the typical cyclical communication in the automotive environment. Some-IP is an RPC method. Basically, Some-IP is a client-server model. At the beginning of a communication, the client sends a request to a server. This request describes what the server should do and what the answer should look like. The server processes the request and sends back a result. Various methods for error handling and message structure are saved in the client-server communication.

There are some challenges when integrating Ethernet into classic automotive networking. Since the transition to Ethernet is smooth and without a hard cut, the communication of traditional automotive bus systems with Ethernet controllers must be ensured. This can usually be realised via gateways. Gateway functionality is then provided by a larger, centralised controller. To lessen the Ethernet load, multiple CAN messages can be packed into one Ethernet message. As a result, the larger message length of Ethernet messages can be ideally exploited. In this case it is possible to increase from 8 bytes data length for CAN to more than 1500 bytes for Ethernet. One can assume that the complexity of message building in automotive vehicle networks is increasing. There will be standards that distribute data content across multiple Ethernet messages. But there will also be standards that package several classic data content into an Ethernet message.

Further challenges for the future result from the effort to extend the transmission to an unshielded Gigabit Ethernet as a physical layer, but without all questions about hard real-time requirements having been answered until now.