In the sub systems, we will discuss the most important day in the vehicle bus systems CAN, LIN, FlexRay and MOST in the infotainment area, the bus system. At the end of this chapter, we will very briefly look back at the now outdated but still frequently find systems K-Line and give SAE 1850th

Let's start with a section of basics that are important for the further understanding of the following chapter.

• All­ge­mein
• Bus systems Anforderungen an
• Task fields
• Anwendungsbereiche und Anforderungen
• Classification of bit rate
• Development of bus systems in the vehicle
• Protocol stack (protocol stack)

All­ge­mein

If we are talking about bus systems, we believe, in the ISO / OSI reference model, which we already know from the introduction, levels 1 and 2 (Physical and Data Link Layer), so the layers of the general communication model, as illustrated. They deal with the questions used, which signal lines and levels and how the bits are encoded on the lines. How to put together from bits messages and how these messages are addressed. Moreover, as regulated, is who can communicate via the communication bus, such as who can send messages and how errors are detected and corrected if necessary.

ISO / OSI layer model for bus systems

If we analyze the electronic architecture of a modern vehicle, we can find various applications, the so-called domains. In each domain a separate bus system is used. The various bus systems are coupled together via a central gateway, as illustrated. First, we have in the area of ​​powertrain and chassis electronics called Powertrain. This classic CAN increasingly and in a high-speed variant, FlexRay is used.

Communication in the vehicle

Second, we have the area of ​​comfort and body electronics. Here also dominated CAN, however, added in a version with a lower bus speed and by a multitude of sub-bus systems on the basis of LIN.

In the area of ​​infotainment we have today - in the MOST use - at least in luxury vehicles. In medium-sized vehicles can be found on this occasion also CAN.

For the diagnosis of CAN is required by law today standard. A few years ago it was the K-Line and J1850 in the U.S.. In addition, we find in some luxury cars are increasingly at this point, an Ethernet port (DoIP = Diagnostics over Internet Protocol) to accelerate the download / update of software within the production and in the workshop.

Bus systems Anforderungen an

If such an electronic architecture is set for a vehicle, in addition to the features you want, of course, a number of other requirements are met.

Since we have access to the subject of cost, which is the number of control devices, but certainly not least by the number of line connections and the need to plug and plug contacts.

Since vehicles are now increasingly equipped with individually combined special equipment that is on the other hand, the desire to minimize changes in production costs. Thus, when different devices are combined with various functions in the control devices no hardware or software changes are necessary.

The topic of reliability of electronic systems is also one of the "hot potato" in the overall development. It is therefore particularly important that these devices are insensitive to external influences, such as the operation of a mobile phone and, if it comes to disturbances, that erroneous data transfers identified and limited in their impact.

Furthermore, the available data rate to be of sufficient size to be able to accommodate future expansion even in the same system.

Task fields

Why do we now have different bus systems in the vehicle? Simply because we cover different tasks and the requirements of this task can be achieved with a single field bus system is not inexpensive. We have to take in the on-board communications - between the control units in normal operation - a communication to operate the control and regulation tasks has. There we have high to very high real-time requirements and the security of these communication plays a major role. The amount of data transmitted in this communication control device to control device is rather low. The repetition, however - and especially the requirement of temporal accuracy of the repetition rate is high. These are the domains for CAN, LIN and FlexRay.

The second on-board communication level is the infotainment (entertainment level), a communication that takes place between the controller and the passenger, ie typically radio, audio or navigation system. There we do have - especially when one thinks of navigation data - very high data rates. The safety aspects still play a subordinate role. This is a domain of the MOST system.

Task fields

For the off-board communications - communication between vehicle and external testers - go read it on the subject of memory error, change parameters which control actuators, flash programming, etc. This interface is used in the workshop, production and development.

For the workshop have legal requirements (eg, OBD) are met. The vehicle access should be restricted and protected. In production, every second is expensive. Therefore, here plays an important role in data throughput. In the development would be contrary to the workshop exposed very easily and have access to every part of the electronics of the vehicle. That is, restrictions or access control, relevant to the workshop diagnosis very important to play no role here. Therefore, many other protocols are used on the same bus system, see CAN Calibration CCP and XCP.

Anwendungsbereiche und Anforderungen

have in the following table attempts to detail the different requirements for each application area a little further. We evaluate the applications with respect to the typically required message length - ie the amount of data that must be transmitted in a single message, using the repetition of the messages - which is essentially the bit rate determines the bus system and ultimately in terms of safety requirements for data transmission and the respective costs.

Anwendungsbereiche und Anforderungen

Let's start with the on-board communications in the Very-low-speed range. As an example of a typical body electronics applications is listed here the windows. There you have to transfer a few bits and the transfer takes place only when necessary and scarce. It is sufficient for this purpose a low-cost bus system such as LIN with a data rate of only 20 kbit / s.

For applications in car bodies that provide little more demanding, it the low-speed CAN is a data rate of 125 kbit / s. An application example of this would be an air conditioner, even when data are exchanged, which must take into account some real-time aspect. The typical motor control application, however, or ABS or ESP application come with such low data rates not find anything. There is a high-speed CAN bus arrives at about 500 kbit / s used.

In chassis control even extends this data rate is no longer and so have the latest vehicles, especially the vehicles that use a very sophisticated chassis control, already the relatively new FlexRay bus system in use.

Even higher data rates and volumes, but lower security requirements, we find in the infotainment area. There, MOST has established itself as the bus system. It has data rates of 25, 50 and also latest 150 Mbit / s.

In the off-board communication, however, the data rate at least in the workshop area of ​​minor importance. The costs are, at least for the part that is not in the vehicle, not as critical. There we find today, in places, CAN and the aforementioned old bus K-line and J1850. In the next few years, here Ethernet play an increasing role as more and more data must be transferred immediately to the vehicle.

Classification of bit rate

If you deal with bus systems in the vehicle, you often hear names such as Class A or Class C-bus system. This classification is from the SAE and was introduced to bus lane after its bit rate. The boundaries between the different classes but are fluent. A typical Class-A bus system is in the range of less than 25 kbit / s. LIN is a typical representative of these buses, ranging from today's perspective, only for simple tasks in the body electronics.

Classification of bit rate

A Class B-bus system for more demanding tasks in the body electronics - the domain of low-speed CAN - even last up to 125 kbit / s. The Class C buses, as they are in the powertrain and chassis applications today and for the diagnosis of usual range, to about 1 Mbit / s. In these areas the high-speed CAN, usually with 500 kbit / s is used.

Above are the Class-C + bus systems - a term that is not officially approved by the SAE. This area is classified with FlexRay now 10 Mbps. The last are the infotainment systems. The main representative of these systems, MOST has a data rate of up to 150 Mbit / s.

Development of bus systems in the vehicle

The following figure shows the historical development of bus systems. The horizontal axis is the year of publication, to see where a particular bus for the first time in the series was used. On the vertical axis you see the bit rate as a benchmark for technical capability of a bus system. The circular areas represent a rough estimate of the cost of a bus node.

Development of bus systems in the vehicle

On the one hand, you see a number of bus systems, which are now either already out of date, or even never really been in production use, such as the A bus. On the other hand, you see now in use buses, and where they are arranged in this landscape: CAN in the high-and low-speed version, LIN, released only a few years and somewhat less expensive than low-speed CAN and FlexRay of course more expensive but also much more powerful than CAN. Further up located, unfortunately, the costs, the MOST bus system.

Protocol stack (protocol stack)

At the end of the introductory chapter we want to dwell on the development of the protocol stack. Suppose an application wants to send a range of information, including information on the current engine speed, engine temperature, the condition of the ignition, etc. Then the application passes these signals or information to the application layer of the protocol stack. This is handy some software in the ECU, which is responsible for sending and receiving messages. This application layer of the protocol stack packaged those signals as useful data in a message and provides them with a range of other information, such as that it is engine speed, ignition status, etc.. Eventually, he adds at the end even adds a checksum that is used for error control. He then passes this overall message (PDU - Protocol Data Unit) to the transport layer.

Protocol stack (protocol stack)

Suppose the message is too long for one frame, then it is up to the transport layer this great message into smaller messages to segment. These smaller messages receive from the transport layer, an additional header and possibly an additional trailer. This will indicate if it is the first, second, third, etc. is part of a larger message. In this way the receiver is able to select from the many small messages, compose the greater message again. The transport layer then passes these messages to the Data Link Layer.

The data link layer adds itself a header and a trailer, for example, address information or control bits and sends the message to the physical layer. This in turn then serializes the data, usually within the communication controller that encodes the bits and inserts may also contain additional bits to the beginning and end.

Only now data is actually sent as a message on the bus. Here we have the actual user data from the application and before and after a series of control information from the various protocol layers.

For the question of the real data rate is not only the bit rate is interesting, but to control data, the ratio of useful data. This shows that the data rate is always significantly less than the bit rate. For CAN and FlexRay can be used as rough estimates only 50% of the bit rate for user data!