CONTROL UNIT ARCHITECTURE FOR VEHICLES

Abstract

A control unit architecture and a method in which a communication connection takes place between at least two control units, in particular in a vehicle. The method includes receiving the data packet by the first interface controller; determining, by a data analyzer, a transmission strategy for the data packet, the transmission strategy including at least one of the following actions: rejecting the data packet, and/or sending the data packet to at least one of the second interface controllers, and/or sending the data packet to at least one of the buffer stores, and/or fragmenting the data packet and sending it to at least one of the buffer stores, and/or sending the content of the at least one buffer store to at least one of the second interface controllers; implementing the transmission strategy for the data packet.

Claims

1. A method for transmitting a data packet from a first interface controller to at least one second interface controller, comprising: receiving the data packet by the first interface controller; determining, by a data analyzer, a transmission strategy for the data packet, the transmission strategy comprising at least one of the following actions: using a maximum load for the data packet, and/or rejecting the data packet, and/or sending the data packet to at least one of the second interface controllers, and/or sending the data packet to at least one of the buffer stores, and/or fragmenting the data packet and sending it to at least one of the buffer stores, and/or sending the content of the at least one buffer store to at least one of the second interface controllers; and implementing the transmission strategy for the data packet.

2. A method for transmitting a data packet from at least one second interface controller (301, 302, 303) to a first interface controller, comprising: receiving the data packet by the second interface controller; determining, by a data analyzer, a transmission strategy for the data packet, the transmission strategy comprising at least one of the following actions: using a maximum load for the data packet, and/or rejecting the data packet, and/or sending the data packet to the first interface controller, and/or sending the data packet (500) to at least one of the buffer stores, and/or fragmenting the data packet and sending it to at least one of the buffer stores, and/or sending the content of the at least one buffer store to the first interface controller; and implementing the transmission strategy for the data packet.

3. The method as claimed in claim 1, wherein the transmission strategy furthermore comprises at least one of the following actions: using a characterization for the data packet; using an assignment to one of the buffer stores and/or to one of the second interface controllers for the data packet; using a whitelist for the data packet; using a priority for the data packet and/or wherein the maximum load: is a load on a communication connection of the first interface controller and/or of the second interface controller; or is a maximum number of packets per unit time for a data type, all packets that exceed the maximum number being rejected; or is defined depending on a sender.

4. The method as claimed in claim 1, wherein at least part of the transmission strategy is presented in a table.

5. The method as claimed in claim 4, wherein the table is formed as an associative memory, the characterization being used as a key for the associative memory.

6. The method as claimed in claim 4, wherein the transmission strategy furthermore comprises the following action: reading in the table from a configuration module.

7. The method as claimed in claim 1, wherein the transmission strategy furthermore comprises the following action: sending at least part of the data packet to a logging module.

8. The method as claimed in claim 1, wherein the first interface controller supports an Ethernet protocol, and the second interface controller supports a parallel bus protocol, a serial bus protocol and/or an Ethernet protocol.

9. The method as claimed in claim 1, furthermore comprising a further first interface controller, wherein the further first interface controller supports the same protocol as the first interface controller.

10. The method as claimed in claim 8, wherein the further first interface controller is used as redundant first interface controller.

11. A control unit for transmitting a data packet from a first interface controller to at least one second interface controller and/or for transmitting a data packet from at least one second interface controller to a first interface controller, the control unit comprising: a first interface controller, a data analyzer, at least one buffer store, and at least one second interface controller, wherein the control unit is set up to carry out a method as claimed in claim 1.

12. The control unit as claimed in claim 11, wherein the control unit is implemented as an ASIC or as an FPGA.

13. A control system for transmitting a data packet from a first interface controller to at least one second interface controller and/or for transmitting a data packet from at least one second interface controller to a first interface controller, the control system having: a control unit as claimed in claim 11, a configuration module, wherein the control unit is set up to read in a table from the configuration module, and/or a logging module, wherein the control unit is set up to send at least part of the data packet to the logging module.

14. A method as claimed in claim 1 for transmitting a data packet between controller modules in a vehicle.

15. A vehicle having a control unit for transmitting a data packet from a first interface controller to at least one second interface controller and/or for transmitting a data packet from at least one second interface controller to a first interface controller, the control unit comprising: a first interface controller, a data analyzer, at least one buffer store, and at least one second interface controller, wherein the control unit is set up to carry out a method as claimed in claim 1.

16. The method as claimed in claim 2, wherein the transmission strategy furthermore comprises at least one of the following actions: using a characterization for the data packet; using an assignment to one of the buffer stores and/or to one of the second interface controllers for the data packet; using a whitelist for the data packet; using a priority for the data packet; and/or wherein the maximum load: is a load on a communication connection of the first interface controller and/or of the second interface controller; or is a maximum number of packets per unit time for a data type, all packets that exceed the maximum number being rejected; or is defined depending on a sender.

17. A control unit as claimed in claim 10, for transmitting a data packet between controller modules in a vehicle.

18. A control system as claimed in claim 13 for transmitting a data packet between controller modules in a vehicle.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0085] For further clarification, aspects of the invention will now be described on the basis of embodiments shown in the figures. These embodiments are intended to be understood merely as examples and not as limitations.

[0086] In the figures:

[0087] FIG. 1: shows a schematic depiction of a control unit according to an embodiment of the present invention;

[0088] FIG. 2: shows a schematic depiction of a control unit according to a further embodiment of the present invention;

[0089] FIG. 3: shows a schematic depiction of a data packet according to a further embodiment of the present invention;

[0090] FIG. 4: shows a schematic depiction of part of a table according to a further embodiment of the present invention;

[0091] FIG. 5: shows a schematic depiction of a controller in a vehicle according to an embodiment of the present invention;

[0092] FIG. 6: shows a schematic depiction of a communication with many communication connections according to an embodiment of the present invention;

[0093] FIG. 7: shows a schematic depiction of a large data packet on a communication connection according to an embodiment of the present invention;

[0094] FIG. 8: shows a schematic depiction of a large amount of data per unit time on a communication connection according to an embodiment of the present invention;

[0095] FIG. 9: shows a schematic depiction of a first and a second interface controller according to an embodiment of the present invention;

[0096] FIG. 10: shows a schematic depiction of an embodiment of the present invention;

[0097] FIG. 11: shows a schematic depiction of an embodiment of the present invention;

[0098] FIG. 12: shows a schematic depiction of an embodiment of the present invention;

[0099] FIG. 13: shows a schematic depiction of an embodiment of the present invention;

[0100] FIG. 14: shows a schematic depiction of an embodiment of the present invention;

[0101] FIG. 15: shows a schematic depiction of an embodiment of the present invention;

[0102] FIG. 16: shows a schematic depiction of an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0103] FIG. 1 shows a schematic depiction of a control unit 100 according to an embodiment of the present invention. The control unit 100 has a first interface controller 110 that is connected to an Ethernet connection 420. The Ethernet connection 420 is connected to an Ethernet line 400. The Ethernet line 400 can be part of a vehicle communication system. The first interface controller 110 is connected to a data analyzer 120 that is set up to determine a transmission strategy for a data packet 500 (see FIG. 3). The transmission strategy can comprise, for example, the data packet 500 being rejected. This can be the case, for example, in the event of overload on the Ethernet connection 400, 420 or if the data packet 500 is not approved for the first interface controller 110, for example on the basis of a whitelist of the MAC addresses. In this embodiment, the data analyzer 120 is connected to a configuration module 200. The configuration module 200 can configure the data analyzer 120 via the interface 220. The data analyzer 120 can also send data to the configuration module 200; this can comprise, for example, a simple “acknowledge” for reception of the data, but also data that support the reconfiguration of the data analyzer 120. The data analyzer 120 is furthermore connected to a logging module 250 that records at least parts of the data packets 500. This can be used, for example, to discover security-relevant scenarios.

[0104] Depending on parts of the data packet 500, the data packet 500 can be sent directly to a vehicle controller 330, for example. This is indicated by the buffer store 139 shown in dashed lines; this buffer store 139 can either be very small (for example contain only one entry) or can also be omitted, so that a direct and thus fast transmission to the second interface controller 303 can take place. Depending on parts of the data packet 500, the data packet 500 can be sent to the buffer store 131 and/or 132, for example. If the data packet 500 is sent to more than one buffer store, this can be the realization of a multicast or a broadcast. The buffer store(s) 131, 132 can be sent to one of the vehicle controllers 310, 320, 330 via one of the second interface controllers 301, 302, 303. FIG. 1 depicts a direct assignment of the second interface controllers 301, 302, 303 to the vehicle controllers 310, 320, 330. In another embodiment, a different assignment can be implemented, for example the second interface controller 302 can send both to the vehicle controller 310 and to the vehicle controller 320 (not depicted). In another embodiment, for example, the vehicle controller 330 can receive data from the two second interface controllers 301 and 302 (not depicted). The connection between the second interface controllers 301, 302, 303 and the vehicle controllers 310, 320, 330 comprises the data connections 311, 321, 331 and the interrupt connections 312, 322, 332, respectively. This depends on the choice of connection protocol between the second interface controllers and the vehicle controllers. With some protocols, the interrupt connections can be dispensed with.

[0105] FIG. 2 shows a schematic depiction of a control unit 100 according to a further embodiment of the present invention. Components having the same reference signs as in FIG. 1 have the same or an analogous function. For example, the buffer stores 131, 132 send in the opposite direction to in FIG. 1. This embodiment shown in FIG. 2 can be used, for example, to send data from one of the vehicle controllers 310, 320, 330 to the Ethernet connection 420. In contrast to FIG. 1, the data analyzer 120 in this embodiment controls and/or influences not the first interface controller 110 but rather the second interface controllers 301, 302, 303. In another embodiment, the data analyzer 120 can control multiple instances of the components of the control unit 100, for example also the first interface controller 110.

[0106] FIG. 3 shows a schematic depiction of a data packet 500 according to a further embodiment of the present invention. The header 510 and the data part 520 of the data packet 500 are clearly discernible. The data packet 500 has an overall length 501. The data part 520 has a data length 521. The transmission strategy of the data analyzer 120 can be influenced by entries in the header 510 and/or in the data part 520 and/or by the lengths 501 and/or 521.

[0107] FIG. 4 shows a schematic depiction of part of a table 550 according to a further embodiment of the present invention. The table has rows 551, 552, 553, 554 as an example. Each of the table rows 551, 552, 553, 554 has the entries characterization 560, assignment 561, whitelist 562, priority 563 and maximum load 564. An embodiment of the present invention can comprise these entries, only part of these entries or also additional entries.

[0108] The characterization 560 can comprise the determination of a data type. Examples of a data type can be: control information for the vehicle and/or an actuator, control information for a device such as a telephone, raw sensor data, infotainment data, audio data, video data. The characterization 560 can also be used, for example, as a key for an associative memory.

[0109] The assignment 561 can be an assignment to one of the buffer stores and/or to one of the second interface controllers. One, multiple instances or none of the buffer stores and/or one of the second interface controllers can be addressed. The entry “0” can be provided if, for example, a data packet 500 having a predefined data type 560 is supposed to be rejected in any case. The assignment 561 can, for example, be used advantageously when video data and telephone data, for example, are supposed to be quickly sorted and assigned to the applicable devices.

[0110] The whitelist 562 can have specific permissible addresses, for example MAC addresses or features of higher protocol layers. The whitelist 562 can be empty.

[0111] The priority 563 can be allocated, for example, on the basis of a characterization 560 or also, for example, stipulated by a definition in the configuration module 200 (see FIGS. 1 and 2). For example, sensor data can be assigned a higher priority than music data, for example. Depending on this, predefined types of data can be treated preferentially.

[0112] The maximum load 564 can relate to the communication medium of the first interface controller 110, for example. For example, the maximum load from which a specific data packet 500 is refused or rejected can be defined.

[0113] FIG. 5 shows a schematic depiction of a controller 310, 320, 330 in a vehicle according to an embodiment of the present invention. The controller has a first interface controller 110 that is directly connected to a second interface controller 301, 302, 303 and a vehicle controller 310, 320, 330.

[0114] FIG. 6 shows a schematic depiction of a communication with many communication connections 400 according to an embodiment of the present invention. This can overload some of the interface controllers 110.

[0115] FIG. 7 shows a schematic depiction of a large data packet 500 on a communication connection 400 according to an embodiment of the present invention. For some of the interface controllers 110, this can exceed the maximum input buffer.

[0116] FIG. 8 shows a schematic depiction of a large number of data packets 500 per unit time on a communication connection 400 according to an embodiment of the present invention. For some of the interface controllers 110, this can exceed the maximum capacity. This can be triggered, for example, by a so-called DoS attack.

[0117] FIG. 9 shows a schematic depiction of a first 110 and a second 301, 302, 303 interface controller according to an embodiment of the present invention. The CPU is informed of every incoming frame and can thus interrupt tasks in progress. Ethernet frames can possibly be rejected, and paused tasks cannot be processed in a timely manner. The present invention can reduce these effects. In some embodiments, the vehicle electrical system communication can be configured statically to reduce these effects. Ethernet can send data both by unicast and by multicast and broadcast. Occasionally this addressing is not fixed because switches can change the recipient address in the event of an error. For example, if a recipient can no longer be reached, the switch may be able to forward a data stream addressed with unicast to all controllers. Multicast and broadcast communication cannot be avoided in general, because otherwise protocols such as ARP (Address Resolution Protocol) or IEEE 802.1AS could no longer work.

[0118] The use of Ethernet and IP in the vehicle can be improved by the methods and/or apparatuses described. The type of communication (client/server) that accompanies Ethernet may be novel for at least some vehicles. The Ethernet communication and/or specifications of newer vehicle controllers can already lead to high bus utilization. In some embodiments, so-called network cards can be used, for example. With such components, the controller and the transceiver are integrated on a separate system and thus decoupled from the main system.

[0119] FIG. 10 shows a schematic depiction of an embodiment of the present invention. A control unit 100 is inserted between the connection, for example an Ethernet connection. In this way, instead of or in addition to other measures, the problems as depicted in FIGS. 6 to 8 can be alleviated at least in part.

[0120] The vehicle controller 310, 320, 330, for example a microcontroller (μC) or microprocessor (μP) or a system on chip (SoC), has hardware having Ethernet interfaces transparently connected upstream of it. In this context, transparent means that no protocol conversion has to take place and that the hardware can also be presented almost invisibly to the application. The hardware can have two Ethernet interfaces, for example, which in one embodiment provide the same speed as that of the μC. In addition to this, the additional component provides a fast configuration interface 220 that is not routed via Ethernet. The hardware can be connected either to the circuit board (OnBoard) or via a cable to the μC (or the PHY). The HW does not necessarily have to be placed on the same circuit board. It can be useful to provide a separate configuration line 220. The additional hardware can be realized as an intelligent 2-port Ethernet switch module, for example. The additional hardware can also be realized as an ASIC, for example with memory and two Ethernet interfaces—in the ASIC or outside. The hardware can be designed, for example, as such an ASIC including registers and 2 Ethernet PHYs.

[0121] FIG. 11 shows a schematic depiction of an embodiment of the present invention. Addressing that is transparent in some respects (since neither ECU1 nor ECU2 sees an address of this component, either as recipient or as sender) may be possible in this case. This is depicted schematically in FIG. 11 by a bidirectional arrow 115. This can become possible if the additional hardware is no longer addressed and/or supposed to be addressed. This means that it does not work on layer 2, but rather externally only on the physical layer.

[0122] FIG. 12 shows a schematic depiction of an embodiment of the present invention. This is an embodiment in which the HW mediates between two different speeds. This allows a missing interface of the microcontroller to be compensated for and this idea to be used more widely. Here, the hardware can additionally be equipped with additional memory in order to temporarily store the high-frequency packets before they are forwarded using a slower connection.

[0123] FIG. 13 shows a schematic depiction of an embodiment of the present invention. In this case, no priority 563 is allocated, which means that the data streams 116 and 117 have the same priority.

[0124] FIG. 14 shows a schematic depiction of an embodiment of the present invention. For example, after a software update, the data streams 116 and 117 and the software can be assigned new priorities 563. In the embodiment depicted, the data stream 117 has a higher priority than the data stream 117. This can be used, for example, to provide control data of the vehicle that arrive as a data stream 117 with higher priority than an infotainment data stream 116. The invention makes it possible to use the upstream hardware, independently of the vehicle network, to make a decision and to provide arriving sensor data (in data stream 117) with higher or more important priority and, for example, to give them preference over music data (and then to send the latter with a delay). This hardware could then be configured dynamically, for example by means of the configuration module 200 (see FIG. 1 and/or 2). It could even be configured by another subscriber in the network, i.e. another ECU or even from the backend. That is to say that the “Config” interface 220 can also be embodied as a bus or network.

[0125] FIG. 15 shows a schematic depiction of an embodiment of the present invention. In this case, two interfaces 110, 112, via which data streams 116 and 117 are routed, are arranged on a conventional controller. These data streams can be operated or configured redundantly, for example.

[0126] FIG. 16 shows a schematic depiction of an embodiment of the present invention. In this case, two interfaces 110, 112, via which data streams 116 and 117 are routed, are arranged on a conventional controller. These data streams can be operated or configured redundantly, for example.

LIST OF REFERENCE SIGNS

[0127] 100 control unit [0128] 110 first interface controller [0129] 112 further first interface controller [0130] 115 arrow [0131] 116, 117 data streams [0132] 120 header analysis [0133] 120 data analyzer [0134] 131, 132 buffer store [0135] 139 intermediate buffer for data packets [0136] 190 control system [0137] 200 configuration module [0138] 250 logging module [0139] 301, 302, 303 second interface controller [0140] 310, 320, 330 vehicle controller [0141] 311, 321, 331 data connection [0142] 312, 322, 332 interrupt connection [0143] 400 Ethernet connection [0144] 420 Ethernet connection [0145] 500 data packet [0146] 550 table [0147] 551, 552, 553, 554 table rows [0148] 560 characterization [0149] 561 assignment [0150] 562 whitelist [0151] 563 priority [0152] 564 maximum load