WO2020099298A1 - Steuergerätearchitektur für fahrzeuge - Google Patents

Steuergerätearchitektur für fahrzeuge Download PDF

Info

Publication number
WO2020099298A1
WO2020099298A1 PCT/EP2019/080819 EP2019080819W WO2020099298A1 WO 2020099298 A1 WO2020099298 A1 WO 2020099298A1 EP 2019080819 W EP2019080819 W EP 2019080819W WO 2020099298 A1 WO2020099298 A1 WO 2020099298A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
interface controller
data
control device
interface
Prior art date
Application number
PCT/EP2019/080819
Other languages
English (en)
French (fr)
Inventor
Helge - c/o Continental Automotive GmbH ZINNER
Original Assignee
Continental Automotive Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Gmbh filed Critical Continental Automotive Gmbh
Priority to US17/291,140 priority Critical patent/US11902048B2/en
Priority to EP19801860.8A priority patent/EP3881507A1/de
Priority to CN201980073954.6A priority patent/CN112997457B/zh
Publication of WO2020099298A1 publication Critical patent/WO2020099298A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40078—Bus configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/34—Circuit design for reconfigurable circuits, e.g. field programmable gate arrays [FPGA] or programmable logic devices [PLD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9042—Separate storage for different parts of the packet, e.g. header and payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9057—Arrangements for supporting packet reassembly or resequencing

Definitions

  • the invention relates to a control unit architecture in which a communication link between at least two
  • Control devices especially in a vehicle, takes place.
  • the invention further relates to a method for
  • Control devices in a vehicle have an increasing number
  • Transmission media e.g. Fieldbuses no longer have the bandwidth required for this and are therefore increasingly supplemented by other, sometimes faster, communication connections, transmission media and / or transmission protocols.
  • the existing ones e.g. Fieldbuses no longer have the bandwidth required for this and are therefore increasingly supplemented by other, sometimes faster, communication connections, transmission media and / or transmission protocols.
  • Transmission media continue to be used, e.g. for security reasons or for existing methods and / or devices, e.g. for testing and / or debugging.
  • One aspect of the invention relates to a method for
  • Delivery strategy includes at least one of the following actions:
  • the first and second interface controllers are arranged in a vehicle.
  • the vehicle is
  • a motor vehicle such as a car, bus or truck, or else a rail vehicle, a ship, an aircraft, such as a helicopter or plane.
  • the first interface controller can be connected, for example, to a communication link or to a transmission medium.
  • the communication link can be, for example, wireless and / or wired transmission protocols, for example Ethernet protocols, LTE protocols (long-term evolution and / or long-term evolution advanced) and / or so-called 5G protocols. With these protocols, the data to be transmitted are converted into data packets with fixed or
  • the first interface controller is set up to receive such a data packet
  • the data packet can be saved
  • ⁇ in particular can be stored temporarily, for example in a receive buffer.
  • the data packet is transmitted to at least one second interface controller. It may be the case that not every data packet is transmitted to exactly one second interface controller. Some of the data packets can e.g. be discarded. Some of the data packets can e.g. be transmitted to more than one second interface controller; this can also be called multicast or broadcast.
  • the second interface controller can use the same protocol as the first interface controller. It can also use the same protocol type as the first interface controller, but a different speed; so the first one
  • Interface controller e.g. use a 1000BASE-T1 protocol and the second interface controller 100BASE-T1.
  • the second interface controller can also be a "traditional"
  • Use vehicle bus such as CAN bus or one of its successors.
  • the use of a "traditional" vehicle bus can be particularly advantageous because it may also be possible to use components that have been developed and / or manufactured for these "traditional" vehicle buses, and these components to newer and / or connect faster communication connections.
  • the data packet is analyzed using a data analyzer. For example, the header, length and / or content of the data packet and / or the frequency of the data stream, ie the number of packets per time unit, can be analyzed. It can contain information from several protocol layers
  • MAC address e.g. a MAC address and / or the number of a virtual channel as used by certain protocols
  • the data packet can also be assigned to a certain type of data.
  • 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.
  • control information for the vehicle and / or an actuator 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 data flow on the communication link of the first interface controller can also be taken into account, e.g. the
  • the transmission strategy for the data packet is determined from the analysis of the data packet.
  • the delivery strategy can include one or more actions. The actions can be carried out as a single action, as a parallel action and / or as a serial action. The execution of a
  • Action can depend on the execution of another action.
  • the action can relate to the same data packet or also include other data packets, e.g.
  • One of the actions can be to discard the data packet.
  • the Discarding can also be done depending on the data type. For example, all data packets that come from a device with an unknown MAC address can be discarded. For example, a maximum number of packets per time unit can also be defined for a specific data type and all packets that exceed the maximum number can be discarded. The maximum number can also be defined depending on a specific sender.
  • DoS Denial of Service
  • One of the actions can be to send the data packet to at least one of the second interface controllers. This can e.g. then happen when the latency of the transfer
  • Sending can take place without further treatment of the data packet, for example. If e.g. it is necessary that the incoming data arrive with high security, then e.g. all filters are deactivated and fast forwarding is enabled. This state could be based on the configuration or also on the basis of the received data (e.g. special
  • Sending to at least one of the second interface controllers can depend, for example, on the data type of the data packet.
  • Other properties from the Data packet derived and / or assigned to the data packet can be a priority which the data packet has, for example in a part of the header, or which is assigned to the data packet, for example on the basis of its data type.
  • sensor data can be assigned a higher priority than, for example, music data.
  • Sending to at least one of the second interface controllers can include sending to a predefined set of second interface controllers or sending to all second interface controllers; this can also be called multicast or broadcast. This can emulate protocols of the first interface controller that support multicast or broadcast.
  • One of the actions can be to send the data packet to at least one of the buffer stores. This can e.g. happen in order to collect the data of several data packets - and first to send them to one of the second interface controllers - and thus to reduce the data traffic to the selected second interface controller.
  • One of the actions can be to fragment the data packet and send the fragmented data packet to at least one buffer memory.
  • Large data packets, for example, which exceed the protocol and / or the input buffers of the second interface controller can thus be sent to the corresponding devices without these devices having to make design changes. This enables devices to be used and / or reused in later generations of a vehicle without great adaptation effort have been extensively tested and / or are in favor of this
  • One of the actions can be to send the at least one buffer memory to at least one of the second interface controllers. This can take place, for example, after the fragmentation and / or the collection of data in this buffer memory. This can be a multicast or
  • the transmission strategy for the data packet is carried out.
  • decouple This can be used, for example, to reduce the number of interrupts and / or the protocol overhead for the second interface controller.
  • the numerous interrupts could have the effect, at least with some control units, that the CPU of the control units is informed about every incoming frame and thus ongoing tasks could be interrupted. This could sometimes lead to Ethernet frames being discarded and / or paused tasks not being processed in time. Avoiding this is particularly with regard to a
  • Another aspect of the invention relates to a method for transmitting a data packet from at least one second interface controller to a first interface controller, comprising the steps:
  • Delivery strategy includes at least one of the following actions:
  • Buffer memory (131, 132), and / or
  • Fragment the data packet (500) and send it to at least one of the buffer memories (131, 132), and / or
  • the transmission of a data packet from at least a second interface controller to a first interface controller can also be understood as an “inverse operation” for the transmission of a data packet from a first interface controller to at least a second interface controller.
  • These two operations can be combined with one another in such a way that they can be understood as supplementary and / or as bidirectional operations
  • the delivery strategy further comprises at least one of the following actions:
  • the characterization can include the determination of a data type.
  • Priority can be assigned depending on the type of data.
  • the priority of the data can influence actions
  • Priority can be emptied faster or data with higher priority can e.g. do not use buffers
  • the maximum load can be the load on the communication link of the first interface controller and / or the second
  • the maximum load can e.g. a maximum number of packets per time unit can also be defined for a specific data type and all packets which exceed the maximum number can be discarded.
  • the maximum number can also be defined depending on a specific sender.
  • the transmission strategy is at least partially shown in a table.
  • the table can include, for example: the characterization for the data packet, assignment to one of the buffer memories and / or to one of the second interface controllers, elements of a white list for the data packet, the priority for the data packet, the maximum load for the data packet.
  • the table is designed as an associative memory.
  • the characterization can be used as a key for the associative memory.
  • Other keys e.g. compound keys or only part of the characterization.
  • An associative memory can allow a faster determination of the delivery strategy.
  • the delivery strategy further includes the following action:
  • the delivery strategy further includes the following action:
  • Communication can be further increased. In particular, it can be used to identify at least certain types of attacks
  • 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.
  • a wide range of applications e.g. can be achieved on different communication connections, transmission media and / or transmission protocols.
  • the method also has a further first interface controller, the further first interface controller supporting the same protocol as the first interface controller.
  • This can be particularly the case with communication connections with bus topology, e.g. Ethernet, can be used to increase performance and / or reliability.
  • the further first interface controller is used as a redundant first interface controller.
  • the same data can be repeated several times - e.g.
  • twice - can be read using several first interface controllers. This can e.g. used to be a
  • the redundancy strategy can, for example, check each other of the read data, e.g. by comparing the data, including switching off faulty controllers and others
  • Another aspect of the invention relates to a control device 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 one
  • Interface controller comprising the control unit:
  • At least one second interface controller is at least one second interface controller.
  • the control unit is set up to carry out a method as explained above and / or in the examples.
  • the control unit has a number of advantages. So a change to new microcontrollers is due to one
  • Ethernet modules in the vehicle possible without major changes. At least some platform developments can be continued despite the lack of original protocol support, since only the control unit, as additional hardware, has to be connected upstream of the controller.
  • the upstream Ethernet hardware can adapt the communication data based on the data received from the microcontroller.
  • adapting means i.a. duplicate, eliminate, change addresses and / or check.
  • Ethernet-based communication a gain in performance, but also a gain in functionality, through the use of Ethernet-based communication can be used.
  • some Ethernet-based protocols can use one
  • the control unit can send uncompressed data
  • control unit and / or the one described Procedures can significantly lower hardware resources
  • Implementations are implemented. Furthermore, the security level can be increased significantly in some cases
  • Embodiments can do this without leading to higher manufacturing costs for the network or for devices connected to it.
  • Another advantage of this control unit is that an existing hardware does not have to be changed, but the existing hardware can continue to be used.
  • the control device and / or the method can be in one
  • the quality of execution of software-based applications can be increased, in particular with better protection in terms of safety and security.
  • the network system according to the invention is improved in terms of cost and reliability.
  • the integration of the Ethernet hardware in the ECU can further increase the system's reliability.
  • the security of a vehicle network can advantageously be increased significantly and very simply by the invention, in particular with reduced financial resources
  • the invention offers a transparent one
  • Another advantage of this invention is that the current hardware does not have to be changed, but the existing hardware can continue to be used. This can lead to largely platform-independent solutions. This means that at least partial compatibility with new protocols such as AVB (Audio Video Bridging) and TSN (Time Sensitive
  • Networking can be achieved.
  • the process can be integrated into an existing network without damaging existing devices.
  • the controller is implemented as an ASIC or as an FPGA. This enables the control unit to be e.g. with a
  • a further aspect of the invention relates to 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 :
  • control unit for this purpose
  • control unit for this purpose
  • Another aspect of the invention relates to the use of a method, a control device or a control system as described above and / or in the figures for transmitting a data packet between controller modules in a vehicle.
  • Another aspect of the invention relates to a vehicle with a control device or a control system as described above and / or in the figures.
  • the invention can be used outside of a vehicle e.g. be used in the area of embedded systems.
  • High security requirements, low computing power and slow platform cycles are examples of such areas of application.
  • the hardware can be defined for a function that provides filter functions.
  • the filters e.g. data parameters, time unit, validity period
  • the hardware is transferred to the hardware and actions are defined, which should take action when the filter is violated, such as Discard the data, discard all data from the problem, save the data, etc.
  • the invention has functions for merging or duplicating data.
  • the controller reports data stream patterns (IDs) to the system on the basis of which it is to be fused, eliminated or duplicated.
  • IDs data stream patterns
  • the messages can dynamically address the requirements / capacities of the controller should be adjusted. For example, the maximum
  • the packet size and the frequency of the data ultimately determine the interrupt load of the controller. Based on this knowledge, the package size in the unit is then adapted to the requirement. Meet, for example, very large ones
  • the hardware can be set so that it is only used from a predefined permissible latency.
  • the hardware can be activated automatically if, for example, security protocols are recognized or requirements are recognized (header analysis of the Ethernet hardware). In this case, the hardware can possibly act autonomously and work with filters predefined for these protocols. Feedback on activation can then be sent to the controller via the separate control channel. In one embodiment, the hardware can react to changes in the data load and also report this back via the control channel. If the load increases per unit of time, it can be reacted to slowly and preparatively and this can also be reported to the controller.
  • FIG. 2 shows a schematic representation of a control device according to a further embodiment of the present invention.
  • Fig. 4 a schematic representation of part of a
  • FIG. 5 shows a schematic illustration of a controller in a vehicle according to an embodiment of the present invention
  • FIG. 6 shows a schematic representation of a communication with many communication connections according to an embodiment of the present invention
  • Fig. 7 a schematic representation of a large
  • Fig. 8 a schematic representation of many data per
  • Fig. 9 a schematic representation of a first and
  • FIG. 11 shows a schematic illustration of an embodiment of the present invention
  • 16 shows a schematic illustration of an embodiment of the present invention.
  • the control device 100 has a first interface controller 110, which is connected to an Ethernet connection 420.
  • the ethernet connection 420 is with an ethernet line 400 connected.
  • Ethernet line 400 may be part of a vehicle communication system.
  • the first interface controller 110 is connected to a data analyzer 120, which is set up to determine a transmission strategy for a data packet 500 (see FIG. 3).
  • Transmission strategy can e.g. include that the data packet 500 is discarded. This can e.g. in the event of an overload on the Ethernet connection 400, 420, or if the data packet 500 is not permitted for the first interface controller 110, for example on the basis of a whitelist of the MAC addresses.
  • the data analyzer 120 is in this
  • Embodiment 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 e.g. include a simple "acknowledge" for the receipt of the data, but also data which the
  • the data analyzer 120 is still one
  • Logging module 250 connected, which records at least parts of the data packets 500. This can e.g. to
  • the data packet 500 can, for example, be sent directly to a vehicle controller 330. This is indicated by the dashed buffer memory 139; this buffer memory 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.
  • the data packet 500 can be sent to the buffer memory 131 and / or 132, for example. If the data packet 500 is sent to more than one buffer memory, this can be the case
  • the buffer memory (s) 131, 132 can, via one of the second interface controllers 301, 302, 303, be connected to one of the
  • Vehicle controllers 310, 320, 330 can be sent. 1 shows a direct assignment of the second interface controllers 301, 302, 303 to the vehicle controllers 310, 320, 330. In another embodiment, a different mapping can be implemented, e.g. The second interface controller 302 may send to both the vehicle controller 310 and the vehicle controller 320 (not shown). In another embodiment e.g. the vehicle controller 330 receives data from both second interface controllers 301 and 302 (not shown).
  • the connection between the second interface controllers 301, 302, 303 and the vehicle controller 310, 320, 330 each includes the data connections 311, 321, 331 and the interrupt connections 312, 322, 332. This depends on the Selection of the connection protocol between the second interface controllers and the vehicle controllers. With some protocols, the interrupt connections can be omitted.
  • FIG. 2 shows a schematic illustration of a control device 100 according to a further embodiment of the present invention.
  • Components with the same reference signs as in FIG. 1 have the same or an analog function.
  • the buffers 131, 132 send in Opposite direction as in FIG. 1.
  • This embodiment shown in FIG. 2 can be used, for example, to transfer data from one of the vehicle controllers 310, 320, 330 to the
  • the data analyzer 120 in this embodiment does not control and / or influence the first interface controller 110, but rather the second interface controller 301, 302, 303.
  • the data analyzer 120 can have several control the components of control unit 100, e.g. also the first interface controller 110.
  • FIG 3 shows a schematic illustration 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 recognizable.
  • 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.
  • Fig. 4 shows a schematic representation of part of a table 550 according to another embodiment of the vorlie invention.
  • the table has lines 551, 552, 553, 554.
  • Characterization 560 may include determining 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
  • the characterization 560 can also be used as a key for an associative memory, for example.
  • the assignment 561 can be an assignment to one of the buffers and / or to one of the second interface controllers. One, several or none of the buffer memories and / or one of the second interface controllers can be addressed.
  • the entry "0" can be provided if, for example, a data packet 500 with a predefined data type 560 is to be discarded in any case.
  • the assignment 561 can, for example, be used advantageously if video data and telephone data are quickly sorted and sorted, for example
  • the whitelist 562 may include certain allowable addresses, e.g. MAC addresses or features of higher protocol layers. Whitelist 562 may be empty.
  • the priority 563 can be assigned, for example, on the basis of a characterization 560 or can also be predetermined, for example by a definition in the configuration module 200 (see FIGS. 1 and 2). For example, sensor data can be assigned a higher priority than, for example, music data. Depending on this, predefined types of data can be treated preferentially.
  • the maximum load 564 can relate, for example, to the communication medium of the first interface controller 110. It can be defined, for example, from which maximum load a particular data packet 500 is rejected or rejected.
  • FIG. 5 shows a schematic illustration 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, which is directly connected to a second interface controller 301, 302, 303 and a vehicle controller 310, 320, 330.
  • Fig. 6 shows a schematic representation of a
  • Fig. 7 shows a schematic representation of a large one
  • Fig. 8 shows a schematic representation of many data packets 500 per unit time on one
  • Communication link 400 may exceed the maximum capacity for some of the interface controllers 110. This can be triggered, for example, by a so-called DoS attack.
  • 9 shows a schematic illustration 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 therefore interrupt ongoing tasks. Ethernet frames can possibly be discarded, and paused tasks cannot be processed on time.
  • Ethernet can send data via unicast as well as multicast and broadcast. This addressing is sometimes not fixed because switches can change the recipient address in the event of an error. For example, if a receiver is no longer reachable, the switch may be able to send a unicast-addressed data stream to all controllers
  • Multicast and broadcast communication cannot generally be avoided because otherwise protocols such as ARP (Address Resolution Protocol) or IEEE 802.1AS could no longer work.
  • ARP Address Resolution Protocol
  • IEEE 802.1AS IEEE 802.1AS
  • Ethernet and IP in the vehicle can be improved by the described methods and / or devices.
  • the type of communication (client / server) that Ethernet brings with it may be new for at least some vehicles.
  • Ethernet communication and / or specifications of newer vehicle controllers can lead to high bus utilization.
  • so-called network cards can be used, for example.
  • the controller and the transceiver are integrated on a separate system and thus decoupled from the main system.
  • 10 shows a schematic representation of an embodiment of the present invention.
  • a control device 100 is inserted between the connection, for example an Ethernet connection.
  • the vehicle controller 310, 320, 330 e.g. a microcontroller (yC) or microprocessor (mR) or a system on chip (SoC), a hardware with Ethernet interfaces is transparently connected upstream.
  • transparent means that there is no need to convert the protocol or that the hardware can also be displayed almost invisibly for the application.
  • the hardware can e.g. two
  • Embodiment offer the same speed as that of the yC.
  • the additional component offers a fast configuration interface 220, which is not routed via Ethernet.
  • the hardware can be connected to the yC (or the PHY) either on the board (onboard) or by a cable.
  • the hardware does not necessarily have to be placed on the same board. It may be useful to provide a separate configuration line 220.
  • the additional hardware can e.g. as a
  • the additional hardware can also be implemented as an ASIC, for example with memory and two Ethernet interfaces - in the ASIC or outside.
  • the hardware can, for example, as a such ASIC incl. Register and 2 Ethernet PHYs must be set up.
  • Fig. 11 shows a schematic representation of a
  • Embodiment of the present invention Addressing that is transparent in some respects (since neither ECU1 nor ECU2 see an address of this component, neither as recipient nor as sender) may be possible. This is shown schematically in FIG. 11 by a bidirectional arrow 115. This can become possible if the additional hardware is no longer addressed and / or should be addressed. This means that it does not work on Layer 2, but on the outside only on the physical layer.
  • Fig. 12 shows a schematic representation of a
  • Embodiment of the present invention This is an embodiment in which the hardware mediates between two different speeds.
  • Microcontrollers are compensated and this concept find more application.
  • the hardware can also be equipped with additional memory in order to
  • Embodiment of the present invention No priority 563 is assigned, so that data streams 116 and 117 have the same priority.
  • 14 shows a schematic representation of an embodiment of the present invention.
  • the data streams 116 and 117 and the software can be assigned new priorities 563.
  • data stream 117 has a higher priority than data stream 117. This can be used, for example, to prioritize control data of the vehicle that arrive as data stream 117 over an infotainment data stream 116.
  • the invention allows through the upstream hardware, regardless of
  • This hardware could then be dynamic, e.g. by means of the
  • the "Config" interface 220 can also be implemented as a bus or network.
  • Two interfaces 110, 112 are arranged on a conventional controller, via which data streams 116 and 117 are conducted. These data streams can be operated or configured redundantly, for example.
  • Embodiment of the present invention are on a conventional controller, two interfaces 110, 112 are arranged, via which data streams 116 and 117 are routed. These data streams can be operated or configured redundantly, for example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • General Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung betrifft eine Steuergerätearchitektur und ein Verfahren bei der eine Kommunikationsverbindung zwischen mindestens zwei Steuergeräten, insbesondere in einem Fahrzeug, stattfindet. Das Verfahren weist folgende Schritte auf: • - Empfangen des Datenpakets (500), mittels des ersten Interface- Controllers (110); • - Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst: • Verwerfen des Datenpakets (500), und/oder • Senden des Datenpakets (500) an mindestens einen der zweiten Interface-Controller (301, 302, 303), und/oder Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder • Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder Senden des Inhalts des mindestens eines Pufferspeichers (131, 132) an mindestens einen der zweiten Interface-Controller (301, 302, 303); • - Durchführen der Übermittlungsstrategie für das Datenpaket (500)

Description

Steuergerätearchitektur für Fahrzeuge
Die Erfindung betrifft eine Steuergerätearchitektur, bei der eine Kommunikationsverbindung zwischen mindestens zwei
Steuergeräten, insbesondere in einem Fahrzeug, stattfindet. Die Erfindung betrifft weiterhin ein Verfahren zur
Übermittlung von Datenpaketen und eine Verwendung.
Steuergeräte in einem Fahrzeug weisen einen zunehmenden
Kommunikationsbedarf auf. Dies ist unter anderem dadurch verursacht, dass sich die Anzahl der Steuergeräte in
Fahrzeugen kontinuierlich erhöht. Dies führt zumindest bei manchen Fahrzeugen dazu, dass existierende
Übertragungsmedien, wie z.B. Feldbusse, nicht mehr die dafür erforderliche Bandbreite aufweisen und daher zunehmend durch andere, zum Teil schnellere, Kommunikationsverbindungen, Übertragungsmedien und/oder Übertragungsprotokolle ergänzt werden. Vielfach sollen dabei die existierenden
Übertragungsmedien weiter genutzt werden, z.B. aus Gründen der Sicherheit oder um existierende Methoden und/oder Geräte, z.B. für Test und/oder Debugging, weiter nutzen zu können.
Es ist Aufgabe der Erfindung, ein Verfahren und/oder eine Steuergerätearchitektur zur Verfügung zu stellen, welche die Anbindung von Steuergeräten mit existierenden Übertragungs medien an andere Übertragungsmedien und Über
tragungsprotokolle ermöglicht.
Ein Aspekt der Erfindung betrifft ein Verfahren zur
Übermittlung eines Datenpakets von einem ersten Interface- Controller zu mindestens einem zweiten Interface-Controller, mit den Schritten:
- Empfangen des Datenpakets, mittels des ersten Interface- Controllers ;
- Bestimmen, mittels eines Daten-Analysators , einer
Übermittlungsstrategie für das Datenpaket, wobei die
Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst :
Verwerfen des Datenpakets, und/oder
Senden des Datenpakets an mindestens einen der zweiten
Interface-Controller, und/oder
Senden des Datenpakets an einen Pufferspeicher, und/oder Fragmentieren des Datenpakets und senden an mindestens einen Pufferspeicher, und/oder
Senden des mindestens einen Pufferspeichers, bzw. dessen Inhalts, an mindestens einen der zweiten Interface- Controller;
- Durchführen der Übermittlungsstrategie für das Datenpaket.
Der erste und der zweite Interface-Controller sind in einem Fahrzeug angeordnet. Bei dem Fahrzeug handelt es sich
beispielsweise um ein Kraftfahrzeug, wie Auto, Bus oder Lastkraftwagen, oder aber auch um ein Schienenfahrzeug, ein Schiff, ein Luftfahrzeug, wie Helikopter oder Flugzeug.
Der erste Interface-Controller kann beispielsweise mit einer Kommunikationsverbindung oder mit einem Übertragungsmedium verbunden sein. Die Kommunikationsverbindung kann z.B. draht lose und/oder drahtgebundene Übertragungsprotokolle, z.B. Ethernet-Protokolle, LTE-Protokolle (Long-Term-Evolution und/oder Long-Term-Evolution-Advanced) und/oder sogenannte 5G-Protokolle, verwenden. Bei diesen Protokollen werden die zu übertragenden Daten in Datenpakete mit fester oder
variabler Länge aufgeteilt. Der erste Interface-Controller ist dazu eingerichtet, ein derartiges Datenpaket zu
empfangen. Das Datenpaket kann gespeichert werden,
insbesondere temporär gespeichert werden, beispielsweise in einem Empfangspuffer.
Das Datenpaket wird zu mindestens einem zweiten Interface- Controller übermittelt. Dabei kann es sein, dass nicht jedes Datenpaket an genau einen zweiten Interface-Controller über mittelt wird. Manche der Datenpakete können z.B. verworfen werden. Manche der Datenpakete können z.B. an mehr als einen zweiten Interface-Controller übermittelt werden; dies kann auch als Multicast oder Broadcast bezeichnet werden. Der zweite Interface-Controller kann dasselbe Protokoll verwenden wie der erste Interface-Controller. Er kann auch denselben Protokoll-Typus verwenden wie der erste Interface-Controller, aber eine andere Geschwindigkeit; so kann der erste
Interface-Controller z.B. ein 1000BASE-T1 Protokoll verwenden und der zweite Interface-Controller 100BASE-T1. Der zweite Interface-Controller kann auch einen „traditionellen"
Fahrzeug-Bus verwenden, wie z.B. CAN-Bus oder einen seiner Nachfolger. Die Verwendung eines „traditionellen" Fahrzeug- Busses kann insbesondere vorteilhaft sein, weil es damit möglich sein kann, auch Komponenten zu verwenden, die für diese „traditionellen" Fahrzeug-Busse entwickelt und/oder hergestellt wurden, und diese Komponenten an neuere und/oder schnellere Kommunikationsverbindungen anzubinden. Das Datenpaket wird mittels eines Daten-Analysators analy siert. Dabei können z.B. Header, Länge und/oder Inhalt des Datenpakets und/oder die Frequenz des Datenstroms, d.h. die Anzahl der Pakete pro Zeiteinheit, analysiert werden. Es können Informationen aus mehreren Protokollschichten
verwendet werden, z.B. eine MAC-Adresse und/oder die Nummer eines virtuellen Kanals, wie sie bestimmte Protokolle
verwenden. Dabei kann das Datenpaket auch einem bestimmten Typus von Daten zugeordnet werden. Beispiele für einen Daten- Typus können sein: Steuerinformationen für das Fahrzeug und/oder einen Aktor, Steuerinformationen für ein Gerät wie z.B. ein Telefon, Sensor-Rohdaten, Infotainment-Daten, Audio- daten, Videodaten. Bei der Analyse des Datenpakets kann auch der Datenfluss auf der Kommunikationsverbindung des ersten Interface-Controllers berücksichtigt werden, z.B. die
Auslastung der Kommunikationsverbindung.
Aus der Analyse des Datenpakets wird die Übermittlungsstra tegie für das Datenpaket bestimmt. Die Übermittlungsstrategie kann eine oder mehrere Aktionen beinhalten. Die Aktionen können als Einzelaktion, als parallele Aktion und/oder als serielle Aktion ausgeführt werden. Die Ausführung einer
Aktion kann von der Ausführung einer anderen Aktion abhängig sein. Die Aktion kann sich auf dasselbe Datenpaket beziehen oder auch andere Datenpakete mit einbeziehen, z.B.
Datenpakete, die bereits gespeichert wurden, z.B. in einem Pufferspeicher .
Eine der Aktionen kann sein, das Datenpaket zu verwerfen.
Dies kann z.B. geschehen, wenn bei dem ersten Interface- Controller ein Pufferüberlauf vorliegt oder droht. Das Verwerfen kann auch abhängig von dem Daten-Typus durchgeführt werden. So können z.B. alle Datenpakete, die von einem Gerät mit unbekannter MAC-Adresse stammen, verworfen werden. Es kann z.B. auch eine Maximalanzahl von Paketen pro Zeiteinheit für einen bestimmten Daten-Typus definiert werden und alle Pakete, welche die Maximalanzahl überschreiten, verworfen werden. Die Maximalanzahl kann auch abhängig von einem bestimmten Absender definiert werden. Mit diesen Aktionen können vorteilhafterweise z.B. bestimmte Typen von DoS- Attacken (DoS: Denial of Service) abgewehrt werden. Dies ist bei Fahrzeugen insbesondere vorteilhaft, weil Steuergeräte im Bordnetz begrenzte, manche sogar stark begrenzte, Ressourcen - z.B. in Bezug auf Speicher und/oder Rechenleistung - haben können .
Eine der Aktionen kann sein, das Datenpaket an mindestens einen der zweiten Interface-Controller zu senden. Dies kann z.B. dann geschehen, wenn die Latenz der Übertragung
minimiert werden soll. Das Senden kann dabei beispielsweise ohne weitere Behandlung des Datenpakets geschehen. Wenn es z.B. erforderlich ist, dass die eintreffenden Daten mit hoher Sicherheit ankommen, dann können z.B. alle Filter deaktiviert werden und eine schnelle Weiterleitung ermöglicht werden. Dieser Zustand könnte auf Basis der Konfiguration oder auch auf Basis der empfangenen Daten (z.B. spezielle
Transportprotokolle, die Echtzeit verlangen) eingenommen werden .
Das Senden an mindestens einen der zweiten Interface- Controller kann z.B. von dem Daten-Typus des Datenpakets abhängig sein. Es können auch andere Eigenschaften aus dem Datenpaket abgeleitet und/oder dem Datenpaket zugeordnet werden. Ein Beispiel kann eine Priorität sein, welche das Datenpaket z.B. in einem Teil des Headers aufweist oder die dem Datenpaket, z.B. aufgrund seines Daten-Typus, zugeordnet wird. So können z.B. Sensordaten eine höhere Priorität zugeordnet bekommen als beispielsweise Musikdaten.
Das Senden an mindestens einen der zweiten Interface-Con troller kann das Senden an eine vordefinierte Menge von zweiten Interface-Controllern oder das Senden an alle zweiten Interface-Controller beinhalten; dies kann auch als Multicast bzw. als Broadcast bezeichnet werden. Dies kann Protokolle des ersten Interface-Controller emulieren, welche Multicast bzw. Broadcast unterstützen.
Eine der Aktionen kann sein, das Datenpaket an mindestens einen der Pufferspeicher zu senden. Dies kann z.B. geschehen, um die Daten mehrerer Datenpakete zu sammeln - und erst gesammelt an einen der zweiten Interface-Controller zu senden - und damit den Datenverkehr zum dem ausgewählten zweiten Interface-Controller zu reduzieren.
Eine der Aktionen kann sein, das Datenpaket zu fragmentieren und das fragmentierte Datenpaket an mindestens einen Puffer speicher zu senden. Damit können beispielsweise große Daten pakete, welche das Protokoll und/oder die Eingangspuffer der zweiten Interface-Controller übersteigen, an die entsprechen den Geräte gesandt werden, ohne dass diese Geräte Design änderungen vornehmen müssten. Dies ermöglicht, ohne großen Anpassungsaufwand Geräte zu verwenden und/oder in späteren Generationen eines Fahrzeugs weiterzuverwenden, die bereits umfangreich getestet sind und/oder die sich für dieses
Fahrzeug und/oder für andere Fahrzeuge bewährt haben.
Eine der Aktionen kann sein, des mindestens einen Puffer speichers an mindestens einen der zweiten Interface- Controller zu senden. Dies kann beispielsweise im Anschluss an das Fragmentieren und/oder das Sammeln von Daten in diesem Pufferspeicher geschehen. Dies kann einen Multicast bzw.
einen Broadcast an mehrere zweite Interface-Controller beinhalten. Damit kann z.B. eine Parallelverarbeitung von Daten realisiert werden. Dies ist insbesondere vorteilhaft, wenn stärkere Controller nicht verfügbar sind oder wenn stärkere Controller mehr Strom benötigen und/oder mehr Hitze abgeben würden als die parallelisierte Lösung. Auch ein Zusammenfassen mehrerer Datenströme ist möglich, d.h. wenn beispielsweise eine Überlast „vermutet" wird, dann kann ein Multicast-Strom erzeugt werden und/oder die Daten können - gewissermaßen „zur Sicherheit" - an den zweiten Controller weitergeleitet werden.
Nach dem Bestimmen der Übermittlungsstrategie wird die Über mittlungsstrategie für das Datenpaket durchgeführt.
Durch dieses Verfahren kann also eine Vorrichtung zum „Vor schalten" vor „übliche" Steuergeräte - z.B. von
Steuergeräten, die in der letzten Fahrzeuggeneration
verwendet wurden - realisiert werden. Dies ist auch
vorteilhaft, wenn die Schnittstellen der Mikrocontroller sich ändern. Dem zweiten Interface-Controller kann also eine weitere Hardware vorgeschaltet werden, die den Ethernet- Verkehr bearbeiten und/oder den Controller entlasten kann. Weiterhin ist es damit möglich, die zweiten Interface- Controller von den ersten Interface-Controllern zu
entkoppeln. Dies kann beispielsweise genutzt werden, um die Anzahl der Interrupts und/oder den Protokoll-Overhead für die zweiten Interface-Controller zu reduzieren. Die zahlreichen Interrupts konnten zumindest bei manchen Steuergeräten den Effekt haben, dass die CPU der Steuergeräte über jeden eintreffenden Frame informiert wird und dadurch laufende Tasks unterbrochen werden konnten. Dies konnte manchmal dazu führen, dass Ethernet-Frames verworfen wurden und/oder pausierte Task können nicht zeitgerecht bearbeitet wurden. Dies zu vermeiden ist insbesondere in Hinblick auf ein
Bordnetz zum Transport von sicherheitskritischen Daten vorteilhaft. Dadurch kann es auch möglich werden, die
Bordnetzkommunikation dynamisch zu konfigurieren, z.B. auch in solchen Netzen, bei denen die Bordnetzkommunikation aus Gründen der Sicherheit, d.h. der funktionalen Sicherheit (Safety) , bisher statisch konfiguriert worden war. Dies kann auch für Multicast- sowie Broadcast-Kommunikation gelten.
Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten Interface-Controller, mit den Schritten:
- Empfangen des Datenpakets, mittels des zweiten Interface- Controllers ;
- Bestimmen, mittels eines Daten-Analysators , einer
Übermittlungsstrategie für das Datenpaket, wobei die
Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst :
Verwerfen des Datenpakets (500), und/oder Senden des Datenpakets (500) an den ersten Interface- Controller (110), und/oder
Senden des Datenpakets (500) an mindestens einen der
Pufferspeicher (131, 132), und/oder
Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens einen Pufferspeichers (131, 132) an den ersten Interface-Controller (110);
- Durchführen der Übermittlungsstrategie für das Datenpaket.
Die Übermittlung eines Datenpakets von mindestens einem zwei ten Interface-Controller zu einem ersten Interface-Controller kann auch als eine „inverse Operation" zu der Übermittlung eines Datenpakets von einem ersten Interface-Controller zu mindestens einem zweiten Interface-Controller verstanden werden. Diese beiden Operationen können so miteinander kombiniert werden, dass diese als ergänzende und/oder als bidirektionale Operationen aufgefasst werden können. Damit gelten auch für das Bestimmen und/oder das Durchführen der Übermittlungsstrategie analoge Überlegungen wie oben
erläutert .
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin mindestens eine der folgenden Aktionen:
- Verwenden einer Charakterisierung für das Datenpaket. Die Charakterisierung kann dabei das Bestimmen eines Daten-Typus umfassen .
- Verwenden einer Zuordnung zu einem der Pufferspeicher und/oder zu einem der zweiten Interface-Controller für das Datenpaket. Dies kann z.B. vorteilhaft sein, wenn auf
schnelle Weise z.B. Videodaten und Telefondaten schnell sortiert und den entsprechenden Geräten zugeordnet werden sollen .
- Verwenden einer Whitelist für das Datenpaket. Eine
Whitelist führt z.B. MAC-Adressen von Geräten auf, die übermitteln werden sollen. Alle anderen Daten werden
verworfen und reduzieren damit, insbesondere in Hinblick auf die Sicherheit der Geräte, das Risiko des Eindringens von unbefugten Adressen.
- Verwenden einer Priorität für das Datenpaket. Das Vergeben der Priorität kann abhängig von Typus der Daten geschehen.
Die Priorität der Daten kann Aktionen beeinflussen;
beispielsweise kann der Puffer von Daten mit höherer
Priorität schneller geleert werden oder Daten mit höherer Priorität können z.B. keine Puffer verwenden
- Verwenden einer Maximallast für das Datenpaket. Die
Maximallast kann die Last auf der Kommunikationsverbindung des ersten Interface-Controllers und/oder des zweiten
Interface-Controllers sein. Die Maximallast kann z.B. auch eine Maximalanzahl von Paketen pro Zeiteinheit für einen bestimmten Daten-Typus definiert werden und alle Pakete, welche die Maximalanzahl überschreiten, können verworfen werden. Die Maximalanzahl kann auch abhängig von einem bestimmten Absender definiert werden.
In einer Ausführungsform ist die Übermittlungsstrategie zumindest teilweise in einer Tabelle dargestellt. Die Tabelle kann beispielsweise umfassen: die Charakterisierung für das Datenpaket, Zuordnung zu einem der Pufferspeicher und/oder zu einem der zweiten Interface-Controller, Elemente einer White list für das Datenpaket, die Priorität für das Datenpaket, die Maximallast für das Datenpaket. Durch die Verwendung der Tabelle kann das Verfahren weniger fehleranfällig werden. Außerdem ermöglicht die Tabelle eine dynamische
Konfiguration, entweder beim Einrichten des Fahrzeugs
und/oder bei einem Update und/oder durch eine
Konfigurationsdatei .
In einer Ausführungsform ist die Tabelle als ein Assoziativ speicher ausgestaltet. Dabei kann die Charakterisierung als ein Schlüssel für den Assoziativspeicher verwendet werden. Es können auch andere Schlüssel, z.B. zusammengesetzte Schlüssel oder auch nur ein Teil der Charakterisierung, verwendet werden. Ein Assoziativspeicher kann ein schnelleres Bestimmen der Übermittlungsstrategie ermöglichen.
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin folgende Aktion:
- Einlesen der Tabelle von einem Konfigurationsmodul.
Damit ist eine einfache und schnelle Änderung der Übermitt lungsstrategie, bzw. beim Einrichten oder bei einem Update des Fahrzeugs möglich.
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin folgende Aktion:
- Senden zumindest eines Teils des Datenpakets an ein
Protokollierungsmodul .
Damit kann vorteilhafterweise die Sicherheit der
Kommunikation weiter erhöht werden. Insbesondere können damit zumindest bestimmten Formen von Attacken festgestellt
und/oder nachvollzogen werden. In einer Ausführungsform unterstützt der erste Interface- Controller ein Ethernet-Protokoll und der zweite Interface- Controller unterstützt ein paralleles Busprotokoll, ein serielles Busprotokoll und/oder ein Ethernet-Protokoll.
Damit kann eine breite Anwendbarkeit, z.B. auf verschiedene Kommunikationsverbindungen, Übertragungsmedien und/oder Übertragungsprotokolle erzielt werden.
In einer Ausführungsform weist das Verfahren weiterhin einen weiteren ersten Interface-Controller auf, wobei der weitere erste Interface-Controller dasselbe Protokoll wie der erste Interface-Controller unterstützt. Dies kann insbesondere bei Kommunikationsverbindungen mit Bus-Topologie, z.B. Ethernet, für eine Erhöhung der Leistung und/oder der Zuverlässigkeit genutzt werden.
In einer Ausführungsform wird der weitere erste Interface- Controller als redundanter erster Interface-Controller verwendet. Insbesondere bei Kommunikationsverbindungen mit Bus-Topologie kann damit dasselbe Datum mehrfach - z.B.
zweimal - mittels mehrerer erster Interface-Controller gelesen werden. Dies kann z.B. genutzt werden, um eine
Redundanzstrategie aufzubauen. Die Redundanzstrategie kann beispielsweise das gegenseitige Überprüfen der eingelesenen Daten, z.B. durch Vergleichen der Daten, beinhalten, das Abschalten von fehlerhaften Controllern und weitere
Redundanzstrategien .
Ein weiterer Aspekt der Erfindung betrifft ein Steuergerät zur Übermittlung eines Datenpakets von einem ersten
Interface-Controller zu mindestens einem zweiten Interface- Controller und/oder zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten
Interface-Controller, das Steuergerät aufweisend:
einen ersten Interface-Controller,
einen Daten-Analysator,
mindestens einen Pufferspeicher, und
mindestens einen zweiten Interface-Controller.
Dabei ist das Steuergerät dazu eingerichtet, ein Verfahren wie oben und/oder in den Beispielen erläutert durchzuführen.
Das Steuergerät weist eine Reihe von Vorteilen auf. So ist ein Wechsel zu neuen Mikrocontrollern aufgrund einer
Einführung von Ethernet-Modulen in das Fahrzeug ohne große Änderungen möglich. Zumindest einige Plattformentwicklungen können trotz fehlender originären Protokollunterstützung weitergeführt werden, da derartigen Dem Controller nur das Steuergerät, als eine weitere Hardware, vorgeschaltet werden muss. Die vorgeschaltete Ethernet-Hardware kann auf Basis der vom Mikrocontroller erhaltenen Daten die Kommunikationsdaten anpassen. Anpassen heißt in diesem Kontext u.a. duplizieren, eliminieren, Adressen ändern und/oder prüfen.
Insbesondere ein Performancegewinn, aber auch ein Gewinn von Funktionalität, durch die Verwendung von Ethernet-basierter Kommunikation kann dabei genutzt werden. Beispielsweise können einige Ethernet-basierte Protokolle eine
Übertragungsrate von z.B. 100 Mbit/s realisieren, gegenüber beispielsweise einer Übertragungsrate von 0,5 Mbit des CAN- Busses. Auch wenn z.B. Sensoren wie Kamera und Radar
unkomprimierte Daten versenden, kann das Steuergerät
verwendet werden. Das Steuergerät und/oder das geschilderte Verfahren kann deutlich geringere Hardwareressourcen
benötigen und kann daher gegebenenfalls mit vorhandenen
Implementierungen umgesetzt werden. Weiterhin kann damit das Sicherheitsniveau deutlich erhöht werden, in manchen
Ausführungsformen kann dies geschehen, ohne dass dies zu höheren Herstellungskosten für das Netzwerk oder für daran angeschlossene Geräte führt. Ein weiterer Vorteil dieses Steuergeräts ist zudem, dass eine vorhandene Hardware nicht verändert werden muss, sondern die vorhandene Hardware weiterverwendet werden kann. Das Steuergerät und/oder das Verfahren kann bei einigen Ausführungsformen in ein
bestehendes Netzwerk integriert werden, ohne dass vorhandene Geräte zu Schaden kommen.
In vorteilhafter Weise kann durch die Erfindung die Güte der Ausführung von Software-basierenden Anwendungen, z.B. bei einem zumindest teilweise automatisiert fahrenden Fahrzeug, erhöht werden, insbesondere mit besserer Absicherung in Bezug auf Safety und Security. Das erfindungsgemäße Netzwerksystem ist im Hinblick auf Kosten und Zuverlässigkeit verbessert. Durch die Integration der Ethernet-HW in der ECU kann weiter hin die Ausfallsicherheit der Systeme erhöht sein. In
vorteilhafter Weise kann durch die Erfindung die Sicherheit eines Fahrzeugnetzwerks signifikant und sehr simpel erhöht werden, insbesondere mit reduziertem finanziellen
Mehraufwand. Durch frühzeitigere Erkennung von Angriffen und Fehlverhalten mittels der frühen Analyse lassen sich Lücken und Fehler vor der Auslieferung des Fahrzeugs erkennen. Zudem bietet die Erfindung eine transparente
Sicherheitsfunktionalität . Ein Vorteil dieser Erfindung ist zudem, dass die gängige Hardware nicht verändert werden muss, sondern die bestehende Hardware weiterverwendet werden kann. Dies kann zu weitgehend plattformunabhängigen Lösungen führen. Dadurch kann auch eine zumindest teilweise Kompatibilität zu neuen Protokollen wie z.B. AVB (Audio Video Bridging) und TSN (Time Sensitive
Networking) erreicht werden. Das Verfahren kann in ein bestehendes Netzwerk integriert werden, ohne dass vorhandene Geräte zu Schaden kommen.
In einer Ausführungsform ist das Steuergerät als ein ASIC oder als ein FPGA implementiert. Dies ermöglicht es, das Steuergerät ohne großen Platzbedarf z.B. mit einer
vorhandenen Hardware zu kombinieren und damit das
Anwendungsspektrum einfach und kostengünstig zu erweitern.
Ein weiterer Aspekt der Erfindung betrifft ein Steuerungs system zur Übermittlung eines Datenpakets von einem ersten Interface-Controller zu mindestens einem zweiten Interface- Controller und/oder zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten Interface-Controller, das Steuerungssystem aufweisend:
ein Steuergerät wie oben beschrieben,
ein Konfigurationsmodul, wobei das Steuergerät dazu
eingerichtet ist, eine Tabelle von dem Konfigurationsmodul einzulesen, und/oder
ein Protokollierungsmodul, wobei das Steuergerät dazu
eingerichtet ist, zumindest eines Teils des Datenpakets an das Protokollierungsmodul zu senden. Ein weiterer Aspekt der Erfindung betrifft eine Verwendung eines Verfahrens, eines Steuergeräts oder eines Steuerungs systems wie oben und/oder in den Figuren beschrieben zur Übermittlung eines Datenpakets zwischen Controller-Modulen in einem Fahrzeug.
Ein weiterer Aspekt der Erfindung betrifft ein Fahrzeug mit einem Steuergerät oder einem Steuerungssystem wie oben und/oder in den Figuren beschrieben.
Die Erfindung kann außerhalb eines Fahrzeugs z.B. im Bereich von eingebetteten System eingesetzt werden. Hohe Sicherheits anforderungen, geringe Rechenleistung und langsame Plattform- Zyklen sind Beispiele für derartige Einsatzgebiete.
In einer Ausführungsform kann die Hardware für eine Funktion definiert werden, welche Filterfunktionen zur Verfügung stellt. Dazu werden die Filter (z.B. Datenparameter, Zeit einheit, Gültigkeitsdauer) an die Hardware übertragen und Aktionen definiert, welche bei Verletzung des Filters in Aktion treten sollen, wie z.B. Verwerfen der Daten, Verwerfen aller Daten ab dem Problem, Abspeichern der Daten, usw.
In einer Ausführungsform weist die Erfindung Funktionen zum Zusammenfügen bzw. Duplizieren von Daten auf. Hierbei werden vom Controller Datenstrompattern (IDs) an das System gemeldet auf deren Basis fusioniert, eliminiert oder dupliziert werden soll .
In einer Ausführungsform können die Nachrichten (Pakete) dynamisch an die Anforderungen/Kapazitäten des Controllers angepasst werden sollen. Dabei kann z.B. die maximale
aktuelle Paketgröße vom Controller bestimmt werden. Die
Paketgröße und die Frequenz der Daten bestimmt letztendlich die entstehende Interrupt-Last des Controllers. Auf Basis dieser Erkenntnis wird dann in der Einheit die Paketgröße an die Anforderung angepasst. Treffen bspw. sehr große
Jumboframes von z.B. mehr als 1500 Byte ein, oder sehr kleine Frames von z.B. 64 Byte oder weniger, dann kann die Schaltung adaptiv neu zusammenstellen oder aufteilen. Dies kann
folgende Schritte umfassen:
- Prüfen der Ressourcenkapazität im Controller (in Bezug auf Security-Test, Verarbeitungsgeschwindigkeit, Speicher, etc.);
- Übermittlung der Parameter an die Zusatzhardware;
- Prüfen, ob einkommende Daten diesen Regeln entsprechen;
- Verarbeiten der Daten gemäß den Anforderungen;
- (optional) Rückmeldung über durchgeführte Aktionen an den Controller .
In einer Ausführungsform kann die Hardware so eingestellt werden, dass diese nur ab einer vordefinierten zulässigen Latenz verwendet wird.
In einer Ausführungsform weist kann die Hardware automatisch aktiviert werden, wenn z.B. Sicherheitsprotokolle erkannt werden bzw. Anforderungen erkannt werden (Headeranalyse der Ethernet-Hardware) . Hierbei kann die Hardware möglicherweise autark handeln und mit für diese Protokolle vordefinierten Filtern arbeiten. Eine Rückmeldung zur Aktivierung kann dann über den separaten Kontrollkanal an den Controller gegeben werden . In einer Ausführungsform kann die Hardware bei Veränderung der Datenlast reagieren und diese auch über den Kontrollkanal zurückmelden. Steigt die Last pro Zeiteinheit an, so kann langsam und vorbereitend darauf reagiert werden und dies zusätzlich dem Controller gemeldet werden.
Zur weiteren Verdeutlichung wird die Erfindung anhand von in den Figuren abgebildeten Ausführungsform beschrieben. Diese Ausführungsformen sind nur als Beispiel, nicht aber als Ein schränkung zu verstehen.
Dabei zeigen :
Fig. 1: eine schematische Darstellung eines Steuergeräts gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 2: eine schematische Darstellung eines Steuergeräts gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 3: eine schematische Darstellung eines Datenpakets
gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 4: eine schematische Darstellung eines Teils einer
Tabelle gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 5: eine schematische Darstellung eines Controllers in einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 6: eine schematische Darstellung einer Kommunikation mit vielen Kommunikationsverbindungen gemäß einer Ausführungsform der vorliegenden Erfindung; Fig. 7: eine schematische Darstellung eines großen
Datenpakets auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 8: eine schematische Darstellung von vielen Daten pro
Zeiteinheit auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 9: eine schematische Darstellung eines ersten und
eines zweiten Interface-Controller gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 10: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 11: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 12: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 13: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 14: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 15: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 16: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung.
Fig. 1 zeigt eine schematische Darstellung eines Steuergeräts 100 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Steuergerät 100 weist einen ersten Interface-Controller 110 auf, der mit einer Ethernet-Verbindung 420 verbunden ist. Die Ethernet-Verbindung 420 ist mit einer Ethernet-Leitung 400 verbunden. Die Ethernet-Leitung 400 kann Teil eines Fahrzeug-Kommunikationssystems sein. Der erste Interface- Controller 110 ist mit einem Daten-Analysator 120 verbunden, welcher dazu eingerichtet ist, eine Übermittlungsstrategie für ein Datenpaket 500 (siehe Fig. 3) zu bestimmen. Die
Übermittlungsstrategie kann z.B. umfassen, dass das Daten paket 500 verworfen wird. Dies kann z.B. bei Überlast auf der Ethernet-Verbindung 400, 420 der Fall sein oder wenn das Datenpaket 500 nicht für den ersten Interface-Controller 110 zugelassen ist, beispielsweise auf Basis einer Whitelist der MAC-Adressen . Der Daten-Analysator 120 ist in dieser
Ausführungsform mit einem Konfigurationsmodul 200 verbunden. Das Konfigurationsmodul 200 kann den Daten-Analysator 120, über das Interface 220, konfigurieren. Der Daten-Analysator 120 kann auch Daten an das Konfigurationsmodul 200 senden; dies kann z.B. ein einfaches „Acknowledge" für den Empfang der Daten umfassen, aber auch Daten, welche die
Umkonfiguration des Daten-Analysators 120 unterstützen. Der Daten-Analysator 120 ist weiterhin mit einem
Protokollierungsmodul 250 verbunden, welches zumindest Teile der Datenpakete 500 aufzeichnet. Dies kann z.B. zur
Entdeckung von sicherheitsrelevanten Szenarien verwendet werden .
Abhängig von Teilen des Datenpakets 500 kann das Datenpaket 500 z.B. direkt zu einem Fahrzeug-Controller 330 gesandt wer den. Dies ist durch den gestrichelt gezeichneten Puffer speicher 139 angedeutet; dieser Pufferspeicher 139 kann entweder sehr klein sein (z.B. nur einen Eintrag enthalten) oder kann auch entfallen, so dass eine direkte und damit schnelle Übertragung zu dem zweiten Interface-Controller 303 stattfinden kann. Abhängig von Teilen des Datenpakets 500 kann das Datenpaket 500 z.B. an den Pufferspeicher 131 und/oder 132 gesandt werden. Wenn das Datenpaket 500 an mehr als einen Pufferspeicher gesandt wird, so kann das die
Realisierung eines Multicast oder eines Broadcast sein. Der oder die Pufferspeicher 131, 132 können, über einen der zweiten Interface-Controller 301, 302, 303 an einen der
Fahrzeug-Controller 310, 320, 330 gesandt werden. In Fig. 1 ist dabei eine direkte Zuordnung der zweiten Interface- Controller 301, 302, 303 zu den Fahrzeug-Controller 310, 320, 330 dargestellt. In einer anderen Ausführungsform kann eine andere Zuordnung implementiert sein, z.B. kann der zweite Interface-Controller 302 sowohl an den Fahrzeug-Controller 310 als auch an den Fahrzeug-Controller 320 senden (nicht dargestellt). In einer anderen Ausführungsform kann z.B. der Fahrzeug-Controller 330 von beiden zweiten Interface- Controllern 301 und 302 Daten empfangen (nicht dargestellt) . Die Verbindung zwischen den zweiten Interface-Controllern 301, 302, 303 und den Fahrzeug-Controller 310, 320, 330 umfasst jeweils die Daten-Verbindungen 311, 321, 331 und die Interrupt-Verbindungen 312, 322, 332. Dies ist abhängig von der Wahl des Verbindungs-Protokolls zwischen den zweiten Interface-Controllern und den Fahrzeug-Controllern. Bei manchen Protokollen kann auf die Interrupt-Verbindungen verzichtet werden.
Fig. 2 zeigt eine schematische Darstellung eines Steuergeräts 100 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei weisen Komponenten mit den gleichen Bezugs zeichen wie bei Fig. 1 dieselbe oder eine analoge Funktion auf. Beispielsweise senden die Pufferspeicher 131, 132 in Gegenrichtung wie bei Fig. 1. Diese in Fig. 2 gezeigte Aus führungsform kann beispielsweise verwendet werden, um Daten von einem der Fahrzeug-Controller 310, 320, 330 an die
Ethernet-Verbindung 420 zu senden. Im Gegensatz zu Fig. 1 steuert und/oder beeinflusst der Daten-Analysator 120 in dieser Ausführungsform nicht den ersten Interface-Controller 110, sondern die zweiten Interface-Controller 301, 302, 303. In einer anderen Ausführungsform kann der Daten-Analysator 120 mehrere der Komponenten des Steuergeräts 100 steuern, z.B. auch den ersten Interface-Controller 110.
Fig. 3 zeigt eine schematische Darstellung eines Datenpakets 500 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei sind deutlich der Header 510 und der Daten teil 520 des Datenpakets 500 erkennbar. Das Datenpaket 500 weist eine Gesamtlänge 501 auf. Der Datenteil 520 weist eine Datenlänge 521 auf. Die Übermittlungsstrategie des Daten- Analysators 120 kann durch Einträge im Header 510 und/oder im Datenteil 520 und/oder durch die Längen 501 und/oder 521 beeinflusst werden.
Fig. 4 zeigt eine schematische Darstellung eines Teils einer Tabelle 550 gemäß einer weiteren Ausführungsform der vorlie genden Erfindung. Die Tabelle weist als Beispiel die Zeilen 551, 552, 553, 554 auf. Jede der Tabellenzeilen 551, 552,
553, 554 weist dabei die Einträge Charakterisierung 560, Zuordnung 561, Whitelist 562, Priorität 563 und Maximallast 564 auf. Eine Ausführungsform der vorliegenden Erfindung kann diese Einträge, nur einen Teil dieser Einträge oder auch noch zusätzliche Einträge umfassen. Die Charakterisierung 560 kann dabei das Bestimmen eines Daten-Typus umfassen. Beispiele für einen Daten-Typus können sein: Steuerinformationen für das Fahrzeug und/oder einen Aktor, Steuerinformationen für ein Gerät wie z.B. ein
Telefon, Sensor-Rohdaten, Infotainment-Daten, Audiodaten, Videodaten. Die Charakterisierung 560 kann beispielsweise auch als Schlüssel für einen Assoziativspeicher verwendet werden .
Die Zuordnung 561 kann eine Zuordnung zu einem der Puffer speicher und/oder zu einem der zweiten Interface-Controller sein. Es können einer, mehrere oder keiner der Pufferspeicher und/oder einer der zweiten Interface-Controller adressiert sein. Es kann der Eintrag „0" vorgesehen sein, wenn z.B. ein Datenpaket 500 mit einem vordefinierten Daten-Typus 560 in jedem Fall verworfen werden soll. Die Zuordnung 561 kann z.B. vorteilhaft verwendet werden, wenn auf schnelle Weise z.B. Videodaten und Telefondaten schnell sortiert und den
entsprechenden Geräten zugeordnet werden sollen.
Die Whitelist 562 kann bestimmte zulässige Adressen, z.B. MAC-Adressen oder Merkmale höherer Protokollschichten, auf weisen. Die Whitelist 562 kann leer sein.
Die Priorität 563 kann beispielsweise auf Basis einer Charak terisierung 560 vergeben werden oder auch, z.B. durch eine Definition in dem Konfigurationsmodul 200 (siehe Fig. 1 und 2) vorgegeben sein. So können z.B. Sensordaten eine höhere Priorität zugeordnet bekommen als beispielsweise Musikdaten. Abhängig davon können vordefinierte Typen von Daten bevorzugt behandelt werden. Die Maximallast 564 kann sich z.B. auf das Kommunikations medium des ersten Interface-Controllers 110 beziehen. Es kann z.B. definiert sein, ab welcher Maximallast ein bestimmtes Datenpaket 500 zurückgewiesen bzw. verworfen wird.
Fig. 5 zeigt eine schematische Darstellung eines Controllers 310, 320, 330 in einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung. Der Controller weist einen ersten Interface-Controller 110 auf, der direkt mit einem zweiten Interface-Controller 301, 302, 303 und einen Fahrzeug- Controller 310, 320, 330 verbunden ist.
Fig. 6 zeigt eine schematische Darstellung einer
Kommunikation mit vielen Kommunikationsverbindungen 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Damit können einige der Interface-Controller 110 überlastet werden.
Fig. 7 zeigt eine schematische Darstellung eines großen
Datenpakets 500 auf einer Kommunikationsverbindung 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Dies kann bei einigen der Interface-Controller 110 den maximalen
Eingangspuffer übersteigen.
Fig. 8 zeigt eine schematische Darstellung von vielen Daten paketen 500 pro Zeiteinheit auf einer
Kommunikationsverbindung 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Dies kann bei einigen der Interface- Controller 110 die maximale Kapazität übersteigen. Dies kann beispielsweise durch eine sog. DoS-Attacke ausgelöst werden. Fig. 9 zeigt eine schematische Darstellung eines ersten 110 und eines zweiten 301, 302, 303 Interface-Controllers gemäß einer Ausführungsform der vorliegenden Erfindung. Die CPU wird über jeden eintreffenden Frame informiert und kann dadurch laufende Tasks unterbrechen. Ethernet-Frames können möglicherweise verworfen werden, sowie pausierte Task können nicht zeitgerecht bearbeitet werden. Die vorliegende
Erfindung kann diese Effekte reduzieren. In manchen
Ausführungsformen kann die Bordnetzkommunikation zur
Reduktion dieser Effekte statisch konfiguriert sein. Ethernet kann Daten sowohl per Unicast als auch per Multicast und Broadcast versenden. Gelegentlich ist diese Adressierung nicht fix, weil Switches im Fehlerfall die Empfängeradresse ändern können. Wenn beispielsweise ein Empfänger nicht mehr erreichbar ist, kann der Switch möglicherweise einen mit Unicast adressierten Datenstrom an alle Controller
weiterleiten. Multicast- sowie Broadcast-Kommunikation kann nicht generell vermieden werden, weil sonst Protokolle wie ARP (Address Resolution Protocol) oder IEEE 802.1AS nicht mehr funktionieren könnten.
Die Verwendung von Ethernet und IP im Fahrzeug kann durch die geschilderten Verfahren und/oder Vorrichtungen verbessert werden. Die Art der Kommunikation (Client/Server) , welche Ethernet mit sich bringt, kann für zumindest einige Fahrzeuge neu sein. Die Ethernet-Kommunikation und/oder Spezifikationen neuerer Fahrzeug-Controller können schon zu hoher Busaus lastung führen. In einigen Ausführungsformen können z.B. sog. Netzwerk Cards verwendet werden. Bei derartigen Komponenten ist der Controller und der Transceiver auf einem separaten System integriert und damit vom Hauptsystem abgekoppelt. Fig. 10 zeigt eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung. Dabei ist ein Steuergerät 100 zwischen die Verbindung, z.B. eine Ethernet- Verbindung, eingefügt. Damit können - anstatt oder zusätzlich zu anderen Maßnahmen - die Problemstellungen, wie sie in Fig. 6 bis 8 dargestellt sind, zumindest teilweise gemildert werden .
Dem Fahrzeug-Controller 310, 320, 330, z.B. einem Micro- controller (yC) oder Mikroprozessor (mR) bzw. einem System on Chip (SoC) , wird dabei eine Hardware mit Ethernet-Schnitt- stellen transparent vorgeschaltet. Transparent meint in diesem Zusammenhang, dass keine Protokollumsetzung erfolgen muss bzw. die Hardware auch fast unsichtbar für die Anwendung dargestellt werden kann. Die Hardware kann z.B. zwei
Ethernet-Schnittstellen aufweisen, welche in einer
Ausführungsform die gleiche Geschwindigkeit wie die vom yC anbieten. Zusätzlich dazu bietet die zusätzliche Komponente eine schnelle Konfigurationsschnittstelle 220 an, welche nicht über Ethernet geführt wird. Die Hardware kann entweder auf der Platine (OnBoard) oder durch ein Kabel mit dem yC (resp. dem PHY) verbunden sein. Die HW muss nicht zwangsweise auf dieselbe Platine gesetzt werden. Es kann sinnvoll sein, eine separate Konfigurationsleitung 220 zur Verfügung zu stellen. Die zusätzliche Hardware kann z.B. als ein
intelligenter 2-Port Ethernet-Switch-Baustein realisiert sein. Die zusätzliche Hardware kann auch als ein ASIC, z.B. mit Speicher und zwei Ethernet-Schnittstellen - im ASIC oder außerhalb - realisiert sein. Die Hardware kann z.B. als ein solcher ASIC inkl . Register und 2 Ethernet-PHYs aufgebaut sein .
Fig. 11 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei kann eine unter einigen Aspekten transparente (da weder ECU1 noch ECU2 eine Adresse dieser Komponente sehen, weder als Empfänger noch als Absender) Adressierung möglich sein. Dies ist in Fig. 11 durch einen bidirektionalen Pfeil 115 schematisch dargestellt. Dies kann möglich werden, wenn die zusätzliche Hardware nicht mehr adressiert wird und/oder adressiert werden soll. Das bedeutet, dass sie nicht auf Layer 2, sondern nach außen nur auf der physikalischen Schicht arbeitet .
Fig. 12 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei handelt es sich um eine Ausführungsform, bei welcher die HW zwischen zwei unterschiedlichen Geschwindigkeiten vermittelt.
Hierdurch kann eine fehlende Schnittstelle des
Mikrocontrollers kompensiert werden und dieses Konzept mehr Anwendung finden. Hier kann zusätzlich die Hardware mit zusätzlichen Speicher ausgestattet werden, um die
hochfrequenten Pakete zwischenzuspeichern, bevor sie mit einer langsameren Verbindung weitergeleitet werden.
Fig. 13 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei wird keine Priorität 563 vergeben, so dass die Datenströme 116 und 117 dieselbe Priorität aufweisen. Fig. 14 zeigt eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung. Beispielsweise nach einem Softwareupdate können den Datenströmen 116 und 117 und der Software neue Prioritäten 563 zugeordnet werden. In der dargestellten Ausführungsform weist der Datenstrom 117 eine höhere Priorität auf als der Datenstrom 117. Dies kann z.B. genutzt werden, um Steuerungsdaten des Fahrzeugs, die als Datenstrom 117 ankommen, gegenüber einem Infotainment- Datenstrom 116 höher zu priorisieren . Die Erfindung erlaubt es, durch die vorgeschaltete Hardware, unabhängig vom
Fahrzeugnetzwerk, eine Entscheidung zu treffen und
ankommenden Sensordaten (in Datenstrom 117) höher bzw.
wichtiger zu priorisieren und beispielsweise gegenüber
Musikdaten vorzuziehen (und diese dann verzögert zu senden) . Diese Hardware könnte dann dynamisch, z.B. mittels des
Konfigurationsmoduls 200 (siehe Fig. 1 und/oder 2)
konfiguriert werden. Diese könnte sogar von einem anderen Teilnehmer des Netzwerks, also einen anderen ECU oder gar aus dem Backend, konfiguriert werden. D.h. die „Config" Schnitt stelle 220 kann auch als ein Bus oder Netzwerk ausgeführt sein .
Fig. 15 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei sind an einen herkömmlichen Controller zwei Schnittstellen 110, 112 angeordnet, über welche Datenströme 116 und 117 geführt werden. Diese Datenströme können beispielsweise redundant betrieben bzw. konfiguriert werden.
Fig. 16 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei sind an einen herkömmlichen Controller zwei Schnittstellen 110, 112 angeordnet, über welche Datenströme 116 und 117 geführt werden. Diese Datenströme können beispielsweise redundant betrieben bzw. konfiguriert werden.
Bezugszeichenliste :
100 Steuergerät
110 erster Interface-Controller
112 weiterer erster Interface-Controller
115 Pfeil
116, 117 Datenströme
120 Header-Analyse
120 Daten-Analysator
131, 132 Pufferspeicher
139 Zwischenpuffer für Datenpakete
190 Steuerungssystem
200 Konfigurationsmodul
250 Protokollierungsmodul
301, 302, 303 zweiter Interface-Controller
310, 320, 330 Fahrzeug-Controller
311, 321, 331 Daten-Verbindung
312, 322, 332 Interrupt-Verbindung
400 Ethernet-Verbindung
420 Ethernet-Verbindung
500 Datenpaket
550 Tabelle
551, 552, 553, 554 Tabellenzeilen
560 Charakterisierung
561 Zuordnung
562 Whitelist
563 Priorität
564 Maximallast

Claims

Patentansprüche
1. Verfahren zur Übermittlung eines Datenpakets (500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303), mit den Schritten:
- Empfangen des Datenpakets (500), mittels des ersten Interface-Controllers (110);
- Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst:
Verwenden einer Maximallast (564) für das Datenpaket (500), und/oder
Verwerfen des Datenpakets (500), und/oder Senden des Datenpakets (500) an mindestens einen der zweiten Interface-Controller (301, 302, 303), und/oder
Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens eines Pufferspeichers (131, 132) an mindestens einen der zweiten Interface-Controller (301, 302, 303);
- Durchführen der Übermittlungsstrategie für das
Datenpaket (500).
2. Verfahren zur Übermittlung eines Datenpakets (500) von mindestens einem zweiten Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), mit den Schritten :
- Empfangen des Datenpakets (500), mittels des zweiten Interface-Controllers (301, 302, 303);
- Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst:
Verwenden einer Maximallast (564) für das
Datenpaket (500), und/oder
Verwerfen des Datenpakets (500), und/oder
Senden des Datenpakets (500) an den ersten
Interface-Controller (110), und/oder
Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder
Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens einen
Pufferspeichers (131, 132) an den ersten Interface- Controller (110);
- Durchführen der Übermittlungsstrategie für das
Datenpaket (500).
3. Verfahren nach Anspruch 1 oder 2,
wobei die Übermittlungsstrategie weiterhin mindestens eine der folgenden Aktionen umfasst:
- Verwenden einer Charakterisierung (560) für das
Datenpaket (500); - Verwenden einer Zuordnung (561) zu einem der
Pufferspeicher (131, 132) und/oder zu einem der zweiten
Interface-Controller (301, 302, 303) für das Datenpaket (500) ;
- Verwenden einer Whitelist (562) für das Datenpaket (500) ;
- Verwenden einer Priorität (563) für das Datenpaket (500)
und/oder
wobei die Maximallast:
- eine Last auf einer Kommunikationsverbindung des ersten Interface-Controllers und/oder des zweiten
Interface-Controllers ist; oder,
- eine Maximalanzahl von Paketen pro Zeiteinheit für einen Daten-Typus ist, wobei alle Pakete, welche die Maximalanzahl überschreiten, verworfen werden; oder,
- abhängig von einem Absender definiert ist.
4. Verfahren nach einem der vorhergehenden Ansprüche,
wobei die Übermittlungsstrategie zumindest teilweise in einer Tabelle (550) dargestellt ist.
5. Verfahren nach Anspruch 4,
wobei die Tabelle (550) als ein Assoziativspeicher ausgestaltet ist, wobei die Charakterisierung (560) als ein Schlüssel für den Assoziativspeicher verwendet wird.
6. Verfahren nach Anspruch 4 oder 5, wobei die
Übermittlungsstrategie weiterhin folgende Aktion
umfasst : - Einlesen der Tabelle (550) von einem
Konfigurationsmodul (200).
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Übermittlungsstrategie weiterhin folgende Aktion umfasst :
- Senden zumindest eines Teils des Datenpakets (500) an ein Protokollierungsmodul (250).
8. Verfahren nach einem der vorhergehenden Ansprüche,
wobei der erste Interface-Controller (110) ein Ethernet- Protokoll unterstützt und
der zweite Interface-Controller (301, 302, 303) ein paralleles Busprotokoll, ein serielles Busprotokoll und/oder ein Ethernet-Protokoll unterstützt.
9. Verfahren nach einem der vorhergehenden Ansprüche,
weiterhin aufweisend einen weiteren ersten Interface- Controller (112),
wobei der weitere erste Interface-Controller (112) dasselbe Protokoll wie der erste Interface-Controller (110) unterstützt.
10. Verfahren nach einem der Ansprüche 8 oder 9,
wobei der weitere erste Interface-Controller (112) als redundanter erster Interface-Controller verwendet wird.
11. Steuergerät (100) zur Übermittlung eines Datenpakets
(500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303) und/oder zur Übermittlung eines Datenpakets (500) von mindestens einem zweiten Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), das Steuergerät (100) aufweisend:
einen ersten Interface-Controller (110),
einen Daten-Analysator (120),
mindestens einen Pufferspeicher (131, 132), und
mindestens einen zweiten Interface-Controller (301, 302, 303) ,
wobei das Steuergerät (100) dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 9
durchzuführen .
12. Steuergerät (100) gemäß Anspruch 11,
wobei das Steuergerät (100) als ein ASIC oder als ein FPGA implementiert ist.
13. Steuerungssystem (190) zur Übermittlung eines
Datenpakets (500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303) und/oder zur Übermittlung eines
Datenpakets (500) von mindestens einem zweiten
Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), das Steuerungssystem (190) aufweisend :
ein Steuergerät (100) gemäß Anspruch 11,
ein Konfigurationsmodul (200), wobei das Steuergerät (100) dazu eingerichtet ist, eine Tabelle (550) von dem Konfigurationsmodul (200) einzulesen, und/oder
ein Protokollierungsmodul (250), wobei das Steuergerät (100) dazu eingerichtet ist, zumindest eines Teils des Datenpakets (500) an das Protokollierungsmodul (250) zu senden .
14. Verwendung eines Verfahrens nach einem der Ansprüche 1 bis 10, eines Steuergeräts (100) gemäß Anspruch 10, 11 oder 12 oder eines Steuerungssystems (190) gemäß
Anspruch 13 zur Übermittlung eines Datenpakets (500) zwischen Controller-Modulen in einem Fahrzeug. 15. Fahrzeug mit einem Steuergerät (100) gemäß Anspruch 10,
11 oder 12 oder einem Steuerungssystem (190) gemäß Anspruch 13.
PCT/EP2019/080819 2018-11-12 2019-11-11 Steuergerätearchitektur für fahrzeuge WO2020099298A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/291,140 US11902048B2 (en) 2018-11-12 2019-11-11 Control unit architecture for vehicles
EP19801860.8A EP3881507A1 (de) 2018-11-12 2019-11-11 Steuergerätearchitektur für fahrzeuge
CN201980073954.6A CN112997457B (zh) 2018-11-12 2019-11-11 车辆的控制单元架构

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018219246.4 2018-11-12
DE102018219246.4A DE102018219246A1 (de) 2018-11-12 2018-11-12 Steuergerätearchitektur für Fahrzeuge

Publications (1)

Publication Number Publication Date
WO2020099298A1 true WO2020099298A1 (de) 2020-05-22

Family

ID=68536863

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/080819 WO2020099298A1 (de) 2018-11-12 2019-11-11 Steuergerätearchitektur für fahrzeuge

Country Status (5)

Country Link
US (1) US11902048B2 (de)
EP (1) EP3881507A1 (de)
CN (1) CN112997457B (de)
DE (1) DE102018219246A1 (de)
WO (1) WO2020099298A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022210908A1 (de) 2022-10-14 2024-04-25 Elmos Semiconductor Se Gateway zur verbindung mit einem sensor eines kraftahrzeugs und verfahren zum betreiben des gateways

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020118640A1 (en) * 2001-01-04 2002-08-29 Oberman Stuart F. Dynamic selection of lowest latency path in a network switch
US20130201984A1 (en) * 2012-02-03 2013-08-08 Gigamon Llc Systems and methods for packet filtering and switching
WO2015028342A1 (de) * 2013-08-29 2015-03-05 Bayerische Motoren Werke Aktiengesellschaft Modusumschaltung eines steuergeräts zwischen diagnosebus und externer ethernetverbindung

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6791947B2 (en) * 1996-12-16 2004-09-14 Juniper Networks In-line packet processing
JP4591745B2 (ja) * 2003-12-02 2010-12-01 富士ゼロックス株式会社 画像形成装置、パターン形成方法及びそのプログラム
US7444445B2 (en) * 2006-07-30 2008-10-28 International Business Machines Corporation Selectively adjusting signal compensation parameters and data rate for transmission of data through a smart cable
GB2470675B (en) * 2008-06-09 2011-05-11 Gnodal Ltd Method of data delivery across a network
CN105120496B (zh) * 2009-11-06 2019-06-28 华为技术有限公司 负载控制方法和设备及通信系统
WO2014138765A1 (de) * 2013-03-14 2014-09-18 Fts Computertechnik Gmbh Vorrichtung und verfahren zur autonomen steuerung von kraftfahrzeugen
JP6983519B2 (ja) 2017-03-08 2021-12-17 株式会社東芝 パケット集約装置及び伝送処理プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020118640A1 (en) * 2001-01-04 2002-08-29 Oberman Stuart F. Dynamic selection of lowest latency path in a network switch
US20130201984A1 (en) * 2012-02-03 2013-08-08 Gigamon Llc Systems and methods for packet filtering and switching
WO2015028342A1 (de) * 2013-08-29 2015-03-05 Bayerische Motoren Werke Aktiengesellschaft Modusumschaltung eines steuergeräts zwischen diagnosebus und externer ethernetverbindung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "iptables(8) - Linux man page", 3 February 2018 (2018-02-03), XP055657344, Retrieved from the Internet <URL:https://web.archive.org/web/20180203003429/https://linux.die.net/man/8/iptables> [retrieved on 20200113] *

Also Published As

Publication number Publication date
DE102018219246A1 (de) 2020-05-14
CN112997457B (zh) 2024-07-19
CN112997457A (zh) 2021-06-18
US11902048B2 (en) 2024-02-13
EP3881507A1 (de) 2021-09-22
US20210392012A1 (en) 2021-12-16

Similar Documents

Publication Publication Date Title
DE102005021820B4 (de) Kommunikationsmitteilungs-Konvertierungseinrichtung, Kommunikationsverfahren und Kommunikationssystem
DE102017211860B3 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
EP1566029B1 (de) Gateway-einheit zur verbindung von subnetzen in fahrzeugen
DE69830491T2 (de) Cut-through -durchschaltung und paketfilterung in einem rechnersystem
EP3248362B1 (de) Datenübertragung in einem kommunikationsnetzwerk
WO2015028342A1 (de) Modusumschaltung eines steuergeräts zwischen diagnosebus und externer ethernetverbindung
DE102017120505A1 (de) System zur Verifikation einer unregistrierten Vorrichtung basierend auf Informationen eines Ethernet-Switchs und Verfahren für dasselbige
EP3228036B1 (de) Verfahren und steuergerät zur übertragung sicherheitsrelevanter daten in einem kraftfahrzeug mittels eines ethernet-standards
EP3542510A1 (de) Verfahren für ein kommunikationsnetzwerk und elektronische kontrolleinheit
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
WO2018099736A9 (de) Verfahren für ein kommunikationsnetzwerk und elektronische kontrolleinheit
EP2090031A2 (de) Verfahren und anordnung zur kommunikation auf einem lin-bus
WO2019030388A1 (de) Verfahren, vorrichtung und computerprogramm zur dynamischen ressourcenzuweisung in einem mehrprozessor-computersystem
DE102018215945A1 (de) Verfahren und Vorrichtung zur Anomalie-Erkennung in einem Fahrzeug
DE102014202826A1 (de) Teilnehmerstation für ein Bussystem und Verfahren zur Erhöhung der Datenrate eines Bussystems
WO2020120550A1 (de) Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
EP4062591B1 (de) Verfahren zur überwachung der kommunikation auf einem kommunikationsbus, elektronische vorrichtung zum anschluss an einen kommunikationsbus, sowie zentrale überwachungsvorrichtung zum anschluss an einen kommunikationsbus
WO2020099298A1 (de) Steuergerätearchitektur für fahrzeuge
EP3152872B1 (de) Übertragungseinheit mit prüffunktion
DE102017012214B4 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
DE102019210224A1 (de) Vorrichtung und Verfahren für Angriffserkennung in einem Rechnernetzwerk
DE102019213322A1 (de) Ethernet Physical Layer Transceiver für Zweidraht-Bustopologie
DE102007049044A1 (de) Vorrichtung und Verfahren zum Datenaustausch zwischen mindestens zwei Funktionsmodulen einer integrierten Schaltung
WO2020088999A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zum senden einer nachricht in einem seriellen bussystem
EP1430647B1 (de) Verfahren zum Betrieb eines Koppelknotens in einem Datennetz

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19801860

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019801860

Country of ref document: EP

Effective date: 20210614