Network block device protocol

Abstract

A network block device protocol. The invention relates to communication between electronic devices (ECUs, ECMs, central control units) in a vehicle. For example, an electronic device in a vehicle includes at least one processor and at least one memory containing program code. The program code, when executed with the at least one processor, causes the electronic device to: configure the interface to communicate with a controller in the vehicle over a transport protocol; configuring the electronic equipment as block equipment which can be accessed by the controller through the interface; upon receiving a request to access the block device from the controller through the transport protocol: reading data from the block device; and sending the data to the controller through the transport protocol.

Description

Technical Field

[0001] The present invention generally relates to electronic devices in a vehicle. More particularly, the present invention relates to an electronic device in a vehicle that communicates with another electronic device and a method for communicating in a vehicle. Background Art

[0002] In recent years, developments in the automotive sector have been progressing rapidly, in particular leading to an increasing number of electronic systems entering vehicles. Electronic systems are not only used to control and manage vehicle functions (e.g. the engine of a vehicle), but also increasingly support the driver in driving the vehicle, even for automatic or autonomous driving. Such advanced functions and technologies require a large number of different electronic systems to work together. For this purpose, the electronic systems are interconnected to each other via a vehicle bus. Examples of vehicle buses are CAN and LIN.

[0003] Electronic systems in vehicles also include low-cost components with limited capabilities and performance. Interconnection and networking are particular challenges for these components, as only simple protocols can be implemented or supported for communication via the vehicle bus. Therefore, maintenance and updating of such components may present technical challenges.

[0004] The present invention addresses these shortcomings and provides a solution to improve the manageability and updating of these electronic components in vehicles. Summary of the invention

[0005] The present invention aims to improve the management and operation of electronic devices such as electronic control units (ECUs) or electronic control modules (ECMs) in vehicles.

[0006] According to a first aspect of the present disclosure, an electronic device in a vehicle is provided. The electronic device includes at least one processor and at least one memory containing program code. When the program code is executed by the at least one processor, the electronic device: configures an interface to communicate with a controller in the vehicle through a transmission protocol; configures the electronic device that the controller can access through the interface as a block device; when a request to access the block device is received from the controller through the transmission protocol: reads data from the block device; and sends the data to the controller through the transmission protocol.

[0007] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device can: upon receiving a request to access the block device from the controller via the transmission protocol: receive data from the controller via the transmission protocol; and write the data to the block device.

[0008] In some examples of the first aspect, the data may include software code, and when the program code is executed by the at least one processor, the electronic device may be caused to: flash the block device with the software code.

[0009] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device can: upon receiving a request to access the block device from the controller through the transmission protocol: perform a handshake process to establish a session between the electronic device and the controller for accessing the block device.

[0010] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device can be caused to: perform a decryption / encryption process to decrypt / encrypt data using an encryption key shared by the electronic device and the controller. For example, when the program code is executed by the at least one processor, the electronic device can be caused to: perform a decryption process to decrypt data received from the controller via the transmission protocol using an encryption key shared by the electronic device and the controller. In another example, when the program code is executed by the at least one processor, the electronic device can be caused to: perform an encryption process to encrypt data to be sent to the controller via the transmission protocol using an encryption key shared by the electronic device and the controller.

[0011] In some examples of the first aspect, when executing the program code with the at least one processor, the electronic device can be caused to: use an encryption protocol such as a Transport Layer Security (TLS)-based protocol.

[0012] In some examples of the first aspect, the electronic device may further include: one or more physical or logical storage devices. In these examples, when the program code is executed by the at least one processor, the electronic device may be enabled to: configure the accessible one or more physical or logical storage devices as the block device.

[0013] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device may be caused to: configure the electronic device to use a network block protocol to enable access through the interface.

[0014] In some examples of the first aspect, the data may include one or more byte blocks of a fixed block size.

[0015] In some examples of the first aspect, the electronic device may include an electronic control module (ECM) for controlling one or more electrical systems in a vehicle, the ECM being embedded in the vehicle. In some examples of the first aspect, the controller may include a central vehicle controller.

[0016] In some examples of the first aspect, the transmission protocol may include one of: a transmission protocol other than the Transmission Control Protocol (TCP); and a transmission protocol according to ISO standard ISO 15765-2. In some examples of the first aspect, the vehicle bus may include a Controller Area Network (CAN) or a Local Interconnect Network (LIN).

[0017] In some examples of the first aspect, the interface may include one of: an interface incompatible with TCP; an interface compatible with a transport protocol according to ISO standard ISO 15765-2; and an interface compatible with CAN or LIN.

[0018] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device can be enabled to: receive a single-byte response having a byte value from the controller in response to sending the data; determine whether the byte value matches a byte value reserved according to the transmission protocol to confirm receipt of the transmitted data or to indicate valid transmission of the data; and in response to determining the match, send additional data via the transmission protocol.

[0019] In some examples of the first aspect, when the program code is executed by the at least one processor, the electronic device can also be enabled to: configure the electronic device to provide debugging information associated with a software component executed by the at least one processor of the electronic device through the interface; and when a request to provide the debugging information is received from the controller: send the debugging information to the controller through a transmission protocol.

[0020] According to a second aspect of the present disclosure, an electronic device in a vehicle is provided. The electronic device includes at least one processor and at least one memory containing program code. When the program code is executed by the at least one processor, the electronic device: configures an interface of the electronic device to communicate with a controller in the vehicle through a transmission protocol; configures the electronic device to provide debugging information associated with a software component executed by the at least one processor of the electronic device through the interface; and upon receiving a request to provide the debugging information from the controller: sends the debugging information to the controller through the transmission protocol.

[0021] In some examples of the second aspect, the electronic device may implement one or more examples of the first aspect.

[0022] According to a third aspect of the present disclosure, a computer-implemented method for communication in a vehicle is provided. The method comprises the following steps: configuring an interface of an electronic device to communicate with a controller in the vehicle via a transmission protocol; configuring the electronic device accessible by the controller via the interface as a block device; upon receiving a request to access the block device from the controller via the transmission protocol: reading data from the block device; and sending the data to the controller via the transmission protocol.

[0023] According to a fourth aspect of the present disclosure, a computer-implemented method for communication in a vehicle is provided. The method comprises the following steps: configuring an interface of an electronic device to communicate with a controller in the vehicle via a transmission protocol; configuring the electronic device to provide debugging information associated with a software component executed by the electronic device via the interface; and upon receiving a request from the controller to provide the debugging information: sending the debugging information to the controller via the transmission protocol.

[0024] According to a fifth aspect of the present disclosure, an electronic device in a vehicle is provided. The electronic device includes at least one processor and at least one memory containing program code. When the program code is executed by the at least one processor, the electronic device: generates one or more messages according to a network block protocol to be used as a network block device for a controller of a vehicle with respect to (or relative to) the vehicle; generates one or more frames according to a transmission protocol based on one or more messages according to the network block protocol; and sends the one or more frames to the controller via a vehicle bus.

[0025] In some examples of the fifth aspect, the electronic device may include an interface to couple the electronic device to a vehicle bus. The interface may be an interface incompatible with a transmission control protocol (TCP) / Internet protocol (IP).

[0026] In some examples of the fifth aspect, the electronic device may include one or more physical or logical storage devices. One or more messages according to the network block protocol will provide access to the one or more physical or logical storage devices. Therefore, the electronic device acting as a network block device can provide access to the one or more physical or logical storage devices.

[0027] In some examples of the fifth aspect, the program code, when executed with the at least one processor, causes the electronic device to: receive a request from the controller to access the electronic device. The one or more messages according to the network block protocol are generated in response to receiving the request. In some examples, the request to access the electronic device may include one or more of the following: a request to read one or more blocks from the electronic device; and a request to write one or more blocks to the electronic device, wherein the one or more blocks include byte blocks of a fixed block size.

[0028] In some examples of the fifth aspect, the program code, when executed by the at least one processor, causes the electronic device to: in response to receiving a connection request from the controller, perform a handshake process to establish a session between the electronic device and the controller. The one or more messages according to the network block protocol are associated with the session.

[0029] In some examples of the fifth aspect, the program code, when executed with the at least one processor, causes the electronic device to: encrypt one or more messages according to the network block protocol using an encryption key shared by the electronic device and the controller. The one or more frames are generated based on the encrypted messages. For example, an encryption protocol such as a protocol based on transport layer security (TLS) may be used to encrypt one or more messages.

[0030] In some examples of the fifth aspect, the vehicle bus may include a low-cost bus used in an automotive environment, such as a Controller Area Network (CAN), CAN Flexible Data-rate (CAN-FD), CAN Extra Long (CAN-XL), or a Local Interconnect Network (LIN).

[0031] In some examples of the fifth aspect, the electronic device may include an electronic control unit (ECU) or an electronic control module (ECM) for controlling one or more electrical systems in a vehicle. The ECU or ECM is embedded in the vehicle. In some examples of the fifth aspect, the controller may include a central vehicle controller.

[0032] In some examples of the fifth aspect, the transmission protocol comprises a transport layer protocol and is used to send one or more messages on a vehicle bus. Examples of the transmission protocol include a transmission protocol according to or based on ISO standard ISO 15765-2 or a derivative thereof.

[0033] In some examples of the fifth aspect, the program code, when executed with the at least one processor, causes the electronic device to: in response to sending one of the one or more frames, receive a single-byte response having a byte value from the controller; determine whether the byte value matches a byte value reserved according to the transmission protocol for confirming receipt of the transmitted data or indicating valid transmission of the data; and in response to determining the match, send another frame of the one or more frames.

[0034] In some examples of the fifth aspect, the program code, when executed by the at least one processor, causes the electronic device to: generate one or more messages according to a remote debugging protocol to provide debugging information associated with a software component executed by the at least one processor of the electronic device to the controller; and generate one or more frames to be sent to the controller based on the one or more messages according to the remote debugging protocol.

[0035] In some examples of the fifth aspect, the program code, when executed by the at least one processor, also causes the electronic device to: implement a protocol stack including an application layer, a transport layer, and a physical layer; provide a network block protocol with a first service at the application layer, and generate one or more messages according to the network block protocol; provide a transport protocol with a second service at the transport layer to generate the one or more frames; and provide a vehicle bus protocol with a third service at the physical layer to send the one or more frames via a vehicle bus.

[0036] According to a sixth aspect of the present disclosure, an electronic device in a vehicle is provided. The electronic device includes at least one processor and at least one memory containing program code. When the program code is executed by the at least one processor, the electronic device: generates one or more messages according to a remote debugging protocol to provide debugging information associated with a software component executed by the at least one processor of the electronic device to a controller of the vehicle; based on the one or more messages according to the remote debugging protocol, generates one or more frames according to a transmission protocol; and sends the one or more frames to the controller via a vehicle bus.

[0037] In some examples of the sixth aspect, the electronic device can implement one or more examples of the fifth aspect.

[0038] According to the seventh aspect of the present disclosure, an electronic device in a vehicle is provided. The electronic device includes at least one processor and at least one memory containing program code. When the program code is executed by the at least one processor, the electronic device: implements a protocol stack including an application layer, a transport layer and a physical layer; provides a network block protocol with a first service at the application layer to generate one or more messages according to the network block protocol, with respect to the controller of the vehicle as a network block device; provides a transport protocol with a second service at the transport layer to generate one or more frames according to the transport protocol based on one or more messages according to the network block protocol; and provides a vehicle bus protocol with a third service at the physical layer to send one or more frames to the controller via the vehicle bus.

[0039] In some examples of the seventh aspect, the electronic device can implement one or more examples of the fifth aspect.

[0040] According to an eighth aspect of the present disclosure, a computer-implemented method for communication in a vehicle is provided. The method comprises the following steps: generating one or more messages according to a network block protocol at an electronic device of the vehicle to act as a network block device for a controller of the vehicle; generating one or more frames according to a transport protocol at the electronic device based on the one or more messages according to the network block protocol; and sending the one or more frames from the electronic device to the controller via a vehicle bus.

[0041] According to a ninth aspect of the present disclosure, a computer-implemented method for communication in a vehicle is provided. The method comprises the following steps: generating one or more messages according to a remote debugging protocol at an electronic device of the vehicle to provide debugging information associated with a software component of the electronic device to a controller of the vehicle; generating one or more frames according to a transmission protocol at the electronic device based on the one or more messages according to the remote debugging protocol; and sending the one or more frames from the electronic device to the controller via a vehicle bus.

[0042] According to a tenth aspect of the present disclosure, a computer-implemented method for communication in a vehicle is provided. The method comprises the following steps: implementing a protocol stack including an application layer, a transport layer, and a physical layer; providing a network block protocol with a first service at the application layer to generate one or more messages according to the network block protocol to act as a network block device; providing a transport protocol with a second service at the transport layer to generate one or more frames according to the transport protocol based on one or more messages according to the network block protocol; and providing a vehicle bus protocol with a third service at the physical layer to send one or more frames through a vehicle bus.

[0043] According to an eleventh aspect, a computer program product is provided, wherein the computer program product comprises instructions, which when executed by a computer, cause the computer to perform one or more methods according to the third, fourth and eighth to tenth aspects and their embodiments.

[0044] According to a twelfth aspect, there is provided a computer readable data carrier having stored thereon the computer program product of the eleventh aspect.

[0045] This summary is intended to provide a brief overview of some aspects and features of the present disclosure. Therefore, it should be understood that the above features are only examples and should not be interpreted as narrowing the scope of the present disclosure in any way. Other features, aspects and advantages of the present disclosure will become apparent through the following detailed description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] A better understanding of the present invention may be obtained when the following detailed description of various exemplary embodiments is considered in conjunction with the accompanying drawings, in which:

[0047] Figure 1 A vehicle having various electronic components according to one embodiment of the present disclosure is shown.

[0048] Figure 2 Shows Figure 1 FIG. 1 is a block diagram of various electronic components of a vehicle according to one embodiment of the present disclosure.

[0049] Figure 3 Shows Figure 1 Electronic components of a vehicle are shown interconnected via a communication bus according to one embodiment of the present disclosure.

[0050] Figure 4 An electronic device for communication in a vehicle according to one embodiment of the present disclosure is shown.

[0051] Figure 5A method for in-vehicle communication according to one embodiment of the present disclosure is shown.

[0052] Figure 6 Another method for in-vehicle communications according to one embodiment of the present disclosure is shown.

[0053] Figure 7 Another method for in-vehicle communications according to one embodiment of the present disclosure is shown.

[0054] Figure 8 is a diagram of the internal components of a computing system that implements the functionality described herein. DETAILED DESCRIPTION

[0055] Before explaining exemplary embodiments of the present disclosure in more detail, certain general principles related to the present disclosure are briefly explained to help understand the technology underlying the examples.

[0056] Figure 1 A vehicle 100 with various electronic components according to one embodiment of the present disclosure is shown. For example, a passenger car is shown. However, any other vehicle may also be considered a vehicle. Examples of other vehicles include buses, commercial vehicles (especially trucks, agricultural machinery, construction machinery), motorcycles, rail vehicles, other mobile systems such as storage lifts, etc. The present disclosure is generally applicable to land vehicles, rail vehicles, water vehicles and aircraft. This use is mainly used in the field of vehicles. However, use in the field of field buses, i.e. in automation technology, processing technology, etc., can also be considered.

[0057] In the vehicle 100 , a plurality of electronic control units (ECUs) are used to control various functions of the vehicle 100 . Figure 1 The interconnection of some exemplary electronic control units and sensors is shown. Basically, a distinction is made between three different categories of electronic control units, each of which is typically interconnected individually. The individual communication buses (also called networks) are connected to each other via a central gateway control unit 140 (e.g., central gateway, central control unit, etc.).

[0058] Electronic control units such as driver assistance control units are interconnected via bus 110, for example. Coupled to bus 110 are, for example, driver assistance control unit 112, radio detection and ranging (RADAR) control unit 114, and ultrasonic sensor control unit 116. RADAR control unit 114 is connected to one or more RADAR sensors and is used, for example, to implement one or more of a radar-based cruise control system, a radar-based distance warning system, and a radar-based collision warning system. Additionally or alternatively, a light detection and ranging (LIDAR) control unit (connected to one or more LIDAR sensors) may also be used.

[0059] Electronic control units such as powertrain control units are interconnected via bus 120, for example. Coupled to bus 120 are, for example, engine control unit 122, electronic stability program (ESP) control unit 124, and transmission control unit 126. In addition, one or more wheel speed sensors 128a to 128d may also be coupled to bus 120.

[0060] For example, electronic control units such as a chassis control unit are interconnected via the bus 130. Coupled to the bus 130 are, for example, a chassis control unit 132 and a steering assist control unit 134.

[0061] Figure 2 Shows Figure 1 FIG. 1 is a block diagram of various electronic components of a vehicle according to an embodiment of the present disclosure. More specifically, Figure 2 The block diagram shows electronic control units such as powertrain, chassis and driver assistance control units. Figure 2 The same reference numerals in the figure denote Figure 1 The same parts in.

[0062] Figure 2 The three communication buses 110, 120, 130 shown are linear or serial buses. Such buses typically include low-cost buses. Examples include controller area network (CAN) buses, local interconnect network (LIN) buses, flexible buses, etc. The bus protocols used for the communication buses 110, 120, and 130 can be designed to meet the functional and communication requirements of the electronic control devices interconnected therewith. For example, the communication bus 130 for chassis control units can be designed to have a higher data rate than the two communication buses 110 and 120, so as to enable the chassis to adapt to changing road conditions extremely quickly when necessary.

[0063] In order to exchange data between electronic control units and sensors interconnected with different communication buses 110, 120, 130, a gateway 140 is provided. The gateway 140 is connected to all three communication bus systems 110, 120 and 130. The gateway 140 is designed to convert the data packets (or general communications) received by the gateway 140 via one of the communication buses into the transmission format of another communication bus, and forward the converted data packets via the other communication bus. As shown in the figure, the gateway 140 can be connected to the communication bus 110, the communication bus 120 and the communication bus 130 as a central device. The gateway 140 therefore handles the format conversion for sending data packets between different communication buses.

[0064] As described above, the bus protocols used for the communication buses 110, 120 and 130 are designed to meet the needs of interconnecting electronic control units. For example, the use of the protocol may depend on the communication bus (such as the buses 110, 120, 130) used in the vehicle 100. For example, in the case of CAN or LIN, a transmission protocol (or transport layer protocol) such as one standardized according to ISO standard ISO 15765-2 or a derivative thereof (also referred to as ISO-TP) may be used. In addition, for diagnostic services (i.e., services for managing ECUs and sensors), the UDS protocol (Unified Diagnostic Services) standardized according to ISO standard 14229, the KWP2000 protocol (Keyword Protocol 2000) standardized according to ISO standard ISO 14230-3 and / or an OBD / OBD2-based protocol (on-board diagnostics-based protocol) standardized according to SAE J1979 or ISO 15031 may be used as a diagnostic communication protocol.

[0065] Protocols are usually separated from each other and compatible with each other according to the layers of the ISO / OSI reference model. Typically, according to the ISO model (International Organization for Standardization model) or the OSI model (Open System Interconnection model), protocols divide different tasks into different layers for secure communication. For this reason, according to the layers of the ISO / OSI model, protocols are separated from each other but compatible with each other.

[0066] The ISO / OSI model includes seven layers: the first layer is the physical layer, the second layer is the data link layer, the third layer is the network layer, the fourth layer is the transport layer, the fifth layer is the session layer, the sixth layer is the presentation layer, and the seventh layer is the application layer.

[0067] Typically, these layers are used in the vehicle field to send commands (especially diagnostic commands) and status updates, and to perform the method described below for performing software updates of ECUs (called ECU flashing). Vehicle buses such as CAN and LIN typically implement the lower layers of the ISO / OSI reference model, such as the physical layer and the data link layer. Parts of the data link layer and higher layers (such as the network layer and the transport layer) are then typically implemented by network protocols and protocol stacks (such as Ethernet / IP / TCP) on top of the vehicle bus.

[0068] In conjunction with the use of the UDS protocol to manage electronic components (i.e., ECUs and sensors) in vehicles, a problem that may arise is that additional software at the application layer is used to perform software updates (e.g., ECU flashing). The communication with the additional software, e.g., sending software updates to electronic components and initiating an update process on the electronic components, is done using the UDS protocol via a communication bus (e.g., a CAN bus). This process results in a time delay (i.e., hysteresis) and is only suitable to a limited extent for, e.g., manual updates.

[0069] Therefore, the present invention provides access to electronic components (e.g., ECU) in a vehicle by means of protocols and protocol stacks that allow another electronic component or central control component to access the electronic component as a block device (also referred to as a network block device). The network block device used herein is a network device configured to use a network block protocol. This enables other electronic components or central control components to access the electronic component in a manner similar to a local storage device (e.g., a hard disk) or a partition thereof. In addition, the use of such a protocol at the application layer of the ISO / OSI model enables simplified and reliable communication using a transport protocol (e.g., ISO-TP) on a vehicle bus (e.g., a CAN or LIN bus), especially for lightweight electronic components such as embedded systems with a small operating system (e.g., a microkernel with only a few hundred lines of code) or even no operating system at all. In addition, the present invention reduces the number of protocols and avoids the need to use a TCP / IP compatible interface or a TCP / IP-based implementation, thereby providing performance improvements and benefits in terms of hardware requirements.

[0070] Additionally or alternatively, the electronic component may provide a protocol or protocol stack that allows other electronic components or a central control component to access information (e.g., debug information) of a software component running on the electronic component. This allows information of a running software component to be provided to other electronic components or a central control component, similar to the information of a software component running locally thereon. The protocol may also allow other electronic components or a central control component to modify data (e.g., input data of the software component) and control the execution of the software component (e.g., set breakpoints, restart execution, stop execution, etc.).

[0071] The present invention is based on the above-mentioned Figure 3 The principle of interconnecting electronic components (such as electronic control units and sensors in vehicles) of the communication bus (or vehicle bus) shown. In this example, a communication bus 110 for a driver assistance control unit class is shown. All electronic components (i.e., control units 112, 114, 116) are connected to the communication bus 110. A gateway 140 (not shown) is also connected to the communication bus 110. The bus structure of the communication bus 110 is linear or serial. For example, a twisted unshielded two-wire line (e.g., unshielded twisted pair UTP) can be used as a physical transmission medium (i.e., bus line), and a symmetrical differential voltage is applied to the physical transmission medium for data transmission. The voltage represents the symbol generated (encoded) by the transmitter according to the desired bit stream. The receiver uses the resulting symbol stream to recover (decode) the bits contained in the bit stream.

[0072] Each electronic component (i.e., electronic control device 112, 114, 116) generally includes at least one processor 310 (e.g., a microcontroller) and at least one memory 320. The memory 320 stores program code representing application software executed by the processor 310. The memory 320 may also store data (e.g., input / output data of the application software, data required or generated by the electronic component). In addition, each electronic component has a communication interface (not shown) to the communication bus 110.

[0073] The communication interface is typically an interface to a vehicle bus (typically a low-cost bus such as CAN or LIN). Therefore, the interface is represented as a CAN or LIN bus interface. Such an interface and the electronic components therefor are typically incompatible with TCP / IP. In other words, the electronic components cannot establish a TCP / IP compatible connection to other electronic components (e.g., Ethernet, WiFi, etc.). The communication interface includes or implements a physical layer block (physical layer, PHY) and a media access controller layer block (media access controller, MAC). The PHY block is responsible for converting the digital packets originating from the MAC block into digital signals, and then sending the digital signals via a physical transmission medium (e.g., a twisted unshielded two-wire line). The PHY block and the MAC block can each be implemented as a separate circuit of the communication interface. In addition, the PHY block controls access to the transmission medium by ensuring that no two electronic components attempt to write to the transmission medium at the same time.

[0074] exist Figure 3In the example of , each electronic control unit 112, 114, 116 has a PHY circuit 330 connected to a circuit 335 for connecting to a bus. The electronic control unit 112, 114, 116 also has a MAC circuit 340. In the above example, the communication bus is a CAN bus, and the PHY circuit 330 and the MAC circuit 340 perform the functions and tasks of the CAN protocol or a CAN-based protocol such as CAN-FD or CAN-XL. The processor 310 that executes the application typically also executes protocols of other layers of the ISO / OSI model, such as ISO-TP as a transport protocol at the network layer and the transport layer, and other session layer and presentation layer protocols as appropriate. In some examples, the electronic control devices 112, 114, 116 may also include one or more additional circuits, each of which implements one of the layers between the MAC layer and the application layer, and the application layer includes the application executed by the processor 310.

[0075] In particular, the processor 310 implements an application layer network block protocol and therefore acts as a network block device relative to another electronic component, particularly a central control component. Other electronic components such as a central vehicle controller also implement an application layer network block protocol and access the network block protocol by exchanging messages (e.g., packets), where access occurs block by block. By using the network block protocol, another electronic component accesses the electronic component as if the electronic component were a local storage device or a portion thereof (e.g., a partition of a local storage device) of another electronic component. Therefore, utilizing the network block protocol enables, for example, a central vehicle controller to access, read, write, and otherwise manipulate the storage of an electronic component through the existing low-level network infrastructure of the vehicle. In addition, the processor 310 may also implement an application layer protocol by which the electronic component provides information (e.g., debugging information) of a software component running on the electronic component to another electronic component or a central control component.

[0076] Based on the foregoing principles of the present invention, some embodiments of the present invention are described below.

[0077] Reference Figure 4 According to an embodiment of the present disclosure, an electronic device 400 includes at least one processor 410 and at least one memory 420. The electronic device 400 may correspond to Figure 3 The electronic device 400 is designed to control functions in a vehicle (not shown) and is connected to a vehicle bus (e.g., Figure 34. In order to be connected to the vehicle bus, the electronic device 400 may have an interface 430. Examples of vehicle buses include serial buses and field buses, including but not limited to CAN buses, CAN-FD buses, CAN-XL buses, LIN buses, etc. As described above, the interface 430 is typically a low-cost interface without TCP / IP functionality. Therefore, the electronic device 400 is not configured to communicate with other electronic devices connected to the vehicle bus via a TCP / IP-based connection on the vehicle bus.

[0078] For the purpose of description, a vehicle is typically a vehicle used for land transportation, such as a bus or truck that participates in public road traffic and uses roads. However, it should be understood that the present disclosure is not limited thereto, but rather relates, for example, to other vehicles used for transportation on land (such as motorcycles) and vehicles used for water and air transportation. The latter may include, for example, using the exemplary embodiment in an aircraft.

[0079] The memory 420 of the electronic device 400 stores the program code 425, and when the processor 410 executes the program code 425, the electronic device 400 implements the protocol stack. The protocol stack can be a protocol stack according to the ISO / OSI reference model, including an application layer, a transport layer, and a physical layer. Of course, for those skilled in the art, one or more of these layers can be implemented with hardware or a combination of hardware and software (i.e., program code). Specifically, the physical layer can be implemented by a circuit associated with the interface 430.

[0080] By the execution of the program code 425 by the processor 410, the electronic device 400 provides a network block protocol at the application layer. An example of a network block protocol is a network block device (NBD) protocol developed for a UNIX-like operating system. The network block protocol provides a service based on data input or data transmission, generating messages according to the network block protocol. By implementing the network block protocol, the electronic device 400 acts as a server and makes itself or a local storage device (e.g., a hard disk, a partition, a memory card, a flash memory, etc.) available to the client (e.g., other electronic devices or a central control component) via a vehicle bus. As a result of, for example, access by a client (e.g., a control device) using the network block protocol, the electronic device 400 generates a message according to the network block protocol. The message includes a control message, such as a message for disassembling / installing the electronic device 400 or its local storage device as a network block device, and a message for writing or reading (at a given absolute address / from a given absolute address) and a payload message containing content read from the electronic device 400 or a local storage device or content to be written to the electronic device 400 or a local storage device. For example, the message may include a payload representing new or updated firmware to be transmitted from the client to the electronic device 400 or a local storage device to update the electronic device 400 .

[0081] The exemplary NBD protocol is a binary protocol in which all multi-byte values ​​are sent in network byte order, eg, corresponding to the memory organization of electronic device 400 .

[0082] The NBD protocol is usually divided into two phases: the negotiation / initialization phase (also called the handshake phase) and the data phase.

[0083] During the initialization phase, data is exchanged between the NBD server (i.e., electronic device 400) and the NBD client (i.e., other electronic devices or central control components). The NBD protocol handshake can support one block device per port or multiple block devices on a port, and in the case of multiple block devices, the NBD client can use the name of the block device to select the block device. The handshake is initiated by sending a server initialization packet with a magic number of the Network Block Protocol (NBD) from the NBD server to the NBD client. The NBD client responds to this with a reply that is typically composed of zero bits. The NBD server then sends a client initialization packet to the NBD client, and the NBD client responds to it with an option packet. The option packet typically defines one of several options, including: (1) the NBD client selects a block device name, (2) the NBD client wants to terminate the connection, or (3) a list of block device names that the NBD client wants to export. The NBD server can accept or reject the requested option by sending a reply packet to the NBD client. The reply packet may include: the NBD server accepts the requested option (ACK); the NBD server provides a description of the block device; the requested option is unknown to the NBD server; the requested option is known but not allowed; the requested option is syntactically invalid; or the NBD server does not support the requested option. Once the NBD server affirmatively confirms the name of the block device selected by the NBD client, the handshake ends, and the NBD server sends a device initialization packet with identification data of the block device to the NBD client.

[0084] After the handshake is completed, the data phase begins, during which the NBD client forwards information about the size of the block device, any flags, and open sockets to the network block protocol (i.e., the program code of the electronic device 400) via a special system call, and then terminates itself. The network block protocol then handles further communications on the socket. The NBD client can now use NBD requests to issue read and write requests to the NBD server. The NBD request defines the desired access type (e.g., read access, write access, controlled end of connection, refresh cache, etc.), the byte offset to read or write, and the length of the data block. For write access, the data to be written follows. The NBD server responds to each request with a reply (NBD Reply). In the case of a response to a read request, the requested data follows.

[0085] In addition, the execution of the program code 425 by the processor 410 provides a transport protocol (i.e., a transport layer protocol) at the transport layer and a vehicle bus protocol (i.e., a physical layer protocol) at the physical layer. Exemplary implementations include, but are not limited to, the ISO 15765-2 protocol (ISO-TP) as a transport protocol on a vehicle bus such as a CAN bus and CAN bus protocols (CAN, CAN-FD, CAN, XL) and a LIN bus protocol. The transport protocol at the transport layer provides the following services: receiving messages from the application layer; generating frames according to the transport protocol based on the messages from the application layer; and passing the generated frames to the physical layer. For example, a frame is generated at the transport layer according to ISO-TP, which includes a message according to the network block protocol as a payload. The transport protocol also ensures that the network block protocol messages are appropriately converted (e.g., segmented or combined) so that their size corresponds to the size that can be sent as a payload in the frame of the transport protocol.

[0086] Accordingly, at the physical layer, the vehicle bus protocol also provides the following services: receiving frames from the transport layer; generating symbols or signals according to the vehicle bus protocol based on the frames from the transport layer; and sending the generated symbols or signals to a receiver (i.e., other electronic devices or central control components) via the vehicle bus. For example, symbols or signals are generated according to the CAN bus protocol at the physical layer, which include frames according to the transport protocol as payload. The vehicle bus protocol also ensures that the frames of the transport protocol are appropriately converted (e.g., segmented or combined) so that their size corresponds to the size that can be sent in a time slot according to the vehicle bus protocol.

[0087] In the case of ISO-TP as an exemplary transport protocol, not only a maximum of 8 bytes according to the CAN bus protocol as an exemplary physical protocol but also 4095 bytes of user data can be sent. According to ISO-TP, the message to be sent (e.g., a message according to the network block protocol) is segmented into several frames and supplemented with metadata so that the message can be interpreted and reassembled by the receiver. For ISO-TP, the protocol control information (protocol control information, PCI) requires one byte per frame to send the corresponding ISO-TP frame type as well as counter and status information. Other exemplary transport protocols include protocols based on ISO-TP, such as ISO-FD and ISO-XL, which are not limited to 4095 bytes and / or 8 bytes per message.

[0088] ISO-TP generally uses the following four frame types:

[0089] - Single Frame (SF): No segmented transmission is necessary because only 6 or 7 bytes of user data need to be sent.

[0090] - First frame (FF): If more than 6 or 7 bytes have to be sent, the segmented transmission starts with the first frame. No user data is sent here yet, but the length of the entire telegram to be sent.

[0091] - Continuation Frame (CF): After the first frame, all segmented payload data are transmitted one by one via a continuation frame.

[0092] - Flow Control Frame (FC): allows the receiver to specify the transmission method.

[0093] The transmission according to ISO-TP then proceeds according to the following scheme: The sender (e.g., electronic device 400) starts sending with the first frame. The receiver (e.g., other electronic device or central control component) confirms with a flow control frame, in which the receiver defines the maximum possible number of consecutive CFs that the receiver can receive and the time interval in which the CFs must be sent. The sender sends a CF block (based on the details defined by the receiver in its first FC), which is again confirmed by the receiver with a FC. The sending and confirmation of CF blocks is repeated until all user data has been sent.

[0094] The frames generated according to ISO-TP are transmitted via the vehicle bus according to the CAN bus protocol (or a general vehicle bus protocol). That is, the frames according to ISO-TP are converted into symbols or signals according to the CAN bus protocol and then transmitted to the receiver via the CAN bus.

[0095] The combined use of NBD at the application layer and ISO-TP at the transport layer running on top of a vehicle bus such as CAN or LIN allows unified and simplified control of lightweight electronic components in the vehicle (without the need to implement more complex lower layer protocols such as Ethernet, IP and / or TCP, which would cause excessive overhead and load on such smaller electronic components).

[0096] Reference Figures 5 to 7 , a method for communication in a vehicle according to an embodiment of the present disclosure will now be described.

[0097] Figure 5 A method for in-vehicle communication according to one embodiment of the present disclosure is shown.

[0098] Method 500 can be referred to above Figure 4 The electronic device 400 described above is executed by at least one interface 430, at least one processor 410 and at least one memory 420. The electronic device 400 is installed to control functions in a vehicle and is connected to a vehicle bus via at least one interface 430. In addition, the memory 420 includes stored program codes, and the execution of the program codes by the processor 410 results in the execution of the method described below.

[0099] As described above, the electronic device 400 is connected to and communicates with other electronic devices or central control components via the vehicle bus. Examples of other electronic devices or central control components include an electronic control unit (ECU) or electronic control module (ECM) for controlling one or more electrical systems of a vehicle embedded in the vehicle, and / or a vehicle controller such as a central vehicle controller.

[0100] Examples of vehicle buses include serial buses and field buses, including but not limited to CAN buses, CAN-FD buses, CAN-XL buses, LIN buses, etc. Interface 430 is typically a low-cost interface that is incompatible with TCP (i.e., does not have TCP / IP functionality). In other examples, interface 430 is compatible with a transport protocol (e.g., a protocol different from TCP or a protocol according to ISO standard ISO15765-2 or a variant thereof). In other examples, interface 430 is compatible with CAN or LIN and / or can support communications on CAN or LIN.

[0101] Method 500 begins by configuring interface 430 (or electronic device 400) to communicate with a controller in a vehicle via a transmission protocol (block 510). Examples of transmission protocols include a transmission protocol other than TCP, a transmission protocol according to ISO standard ISO 15765-2, or one of the transmission protocols according to a variant of ISO standard ISO 15765-2.

[0102] More specifically, at block 510, the interface 430 may be configured to implement at least a portion of a protocol stack according to the ISO / OSI reference model. The interface 430 may be configured to implement a transport protocol at the transport layer of the protocol stack. In addition, the interface 430 may be configured to implement one or more protocols for communicating via a vehicle bus (e.g., CAN, LIN, etc.) at the physical layer of the protocol stack. Therefore, as will be described in more detail below, the interface 430 may be configured to transmit a transmission unit (e.g., frame, packet, symbol, signal, etc.) according to a transmission protocol and / or transmit a transmission unit (e.g., frame, packet, symbol, signal, etc.) according to a protocol for communicating via a vehicle bus.

[0103] Configuring the interface 430 or the electronic device 400 to communicate with the controller in the vehicle via the transmission protocol (i.e., box 510) can be performed during the initialization or startup of the electronic device 400. That is, once the electronic device 400 is powered on, the electronic device 400 begins to load and execute initial firmware such as a basic input and output system (BIOS) or a unified extensible firmware interface (UEFI) to provide runtime services to the operating system and programs and perform hardware initialization. The initial firmware initializes and tests the hardware components of the electronic device 400 (power-on self-test) and loads a boot loader from a memory or storage device such as a boot ROM of the electronic device 400. The boot loader can then initialize the kernel of the operating system (e.g., a Unix-like operating system such as Linux, FreeBSD, etc.). The kernel (e.g., a single kernel or a microkernel) may include a program code (i.e., the program code is compiled into the kernel) or a loader code (i.e., the program code is included in a module loaded by the kernel using a reference) that is executed to configure the transmission protocol and initialize the interface 430. For example, the program code can implement a protocol stack including a transmission protocol. In another example, the interface 430 may be configured at block 510 by loading and executing interface firmware using processing resources associated with the interface 430 (e.g., a processor coupled to the interface 430). In this example, the interface 430 may be configured to power up independently of the firmware (i.e., BIOS or UEFI) or operating system of the electronic device 400.

[0104] In addition, the method 500 includes configuring the electronic device 400 that can be accessed by the controller through the interface as a block device (block 520). For example, the electronic device 400 or the interface 430 can be configured at block 520 to implement a network block protocol such as the above-mentioned NBD protocol. More specifically, the electronic device 400 or the interface 430 can be configured to implement the network block protocol at the application layer of the protocol stack, so that the electronic device 400 or the interface 430 can transmit a transmission unit (e.g., a frame, a packet, a symbol, a signal, etc.) according to the network block protocol.

[0105] Configuring the electronic device 400 accessible by the controller through the interface as a block device (i.e., block 520) may also be performed during initialization or startup of the electronic device 400. For example, the kernel of the operating system may also include or load program code executed by the electronic device 400 to initialize the electronic device 400 to implement a network block protocol and start a service for accessing the block device. A service (e.g., a server) may be configured to listen on a port of the interface 430 for a request to access a block device and to initialize access and communication to itself or to one or more physical or logical storage devices of the electronic device 400.

[0106] As a result of configuring the electronic device 400 at block 520, the electronic device 400 may act as a server relative to the controller, which acts as a client. The electronic device 400 may provide read and / or write access to the controller. For example, the electronic device 400 may provide access to itself or to one or more physical or logical storage devices of the electronic device 400 (e.g., a storage device connected to the electronic device 400 or a portion thereof, such as a partition of the storage device). In this case, configuring the electronic device 400 at block 520 may include configuring the one or more physical or logical storage devices that can be accessed as block devices.

[0107] Here, accessing the electronic device 400 as a block device and / or one or more physical or logical storage devices of the electronic device 400 should be understood as accessing in a block-by-block manner. For example, the access involves reading and / or writing one or more byte blocks. Typically, one or more blocks have a fixed block size, such as 512, 1024, 2048, 4096 bytes. Other examples of block sizes may include other granularities such as 1 byte or up to 4 gigabytes.

[0108] At block 530, the electronic device 400 receives a request to access a block device from the controller via a transmission protocol. In the above example, the request may include a request according to a network block protocol received via a transmission protocol. For example, the electronic device 400 may receive a transmission unit according to a protocol for communicating via a vehicle bus at a physical layer. At the physical layer, the electronic device 400 may demodulate a transmission unit according to a protocol for communicating via a vehicle bus to obtain a transmission unit according to the transmission protocol. The electronic device 400 may provide the transmission unit according to the transmission protocol to the transmission layer. At the transmission layer, the electronic device 400 may demodulate the transmission unit according to the transmission protocol to obtain a transmission unit according to the network block protocol. The electronic device 400 may provide the transmission unit according to the network block protocol to the application layer. At the application layer, the electronic device 400 may demodulate the transmission unit according to the network block protocol to obtain a request to access a block device.

[0109] Upon receiving the request to access the block device at block 530 , the electronic device 400 accesses the block device according to the request.

[0110] For example, if the access request is a request to read data (ie, one or more byte blocks) from a block device, the electronic device 400 reads the data from the block device (block 540) and sends the data to the controller via a transfer protocol (block 550).

[0111] In some examples, the electronic device 400 may read data from the block device (block 540) and use the data to modulate a transmission unit according to a network block protocol. For example, the electronic device 400 may generate a transmission unit according to a network block protocol, the transmission unit including data or at least a portion of the data as a payload (e.g., generating one or more messages according to the network block protocol). Modulating the transmission unit according to the network block protocol may be performed at the application layer. The electronic device 400 may then provide the transmission unit according to the network block protocol to the transport layer, wherein the transmission unit according to the transmission protocol is modulated (e.g., generating one or more frames according to the transmission protocol). The transmission unit according to the transmission protocol may include the transmission unit according to the network block protocol or at least a portion thereof as a payload. The electronic device 400 may then provide the transmission unit according to the transmission protocol to the physical layer, wherein the transmission unit according to the transmission protocol for communicating through the vehicle bus is modulated (e.g., generating a transmission unit for transmitting through the vehicle bus). The transmission unit according to the protocol for communicating through the vehicle bus may include the transmission unit according to the transmission protocol or at least a portion thereof as a payload. Then, the electronic device 400 may transmit a transmission unit according to a protocol for communicating over the vehicle bus to the controller over the vehicle bus.

[0112] In another example, the access request may be a request to write data (ie, one or more byte blocks) to a block device. In this example, the electronic device 400 receives data to be written to the block device from the controller via a transmission protocol, and writes the received data to the block device.

[0113] For example, the electronic device 400 may receive a transmission unit according to a protocol for communicating through a vehicle bus at a physical layer, the transmission unit being used to transmit data to be written. At the physical layer, the electronic device 400 may demodulate the transmission unit according to the protocol for communicating through the vehicle bus to obtain a transmission unit according to the transmission protocol. The electronic device 400 may provide the transmission unit according to the transmission protocol to the transport layer. At the transport layer, the electronic device 400 may demodulate the transmission unit according to the transmission protocol to obtain a transmission unit according to a network block protocol. The electronic device 400 may provide the transmission unit according to the network block protocol to the application layer. At the application layer, the electronic device 400 may demodulate the transmission unit according to the network block protocol to obtain data to be written to the block device. In response to obtaining the data, the data is written to the block device.

[0114] In some examples, the data may include software code (e.g., firmware for operating an electronic device, software for implementing a function on an electronic device, etc.). The access request may be a request to flash a block device. The electronic device 400 may flash a block device using software code. For example, the electronic device 400 may write software code to a block device to overwrite or update existing software code on the block device. In response to the flashing of the block device, the electronic device 400 may initiate a restart / restart process to use the software code written to the block device.

[0115] The access request may also include a request to establish a session for accessing the block device. In this example, the electronic device 400 may perform a handshake process to establish a session for accessing the block device between the electronic device 400 and the controller. As part of the handshake process, the electronic device 400 and the controller may exchange and / or negotiate session parameters, keys, etc. used by the decryption / encryption process. In addition, the handshake process may include authenticating / authorizing the controller at the electronic device 400.

[0116] In some examples, the electronic device 400 can perform a decryption / encryption process to decrypt / encrypt data using an encryption key shared by the electronic device 400 and the controller. For example, the electronic device 400 can perform an encryption process to encrypt data read from a block device before sending the data to the controller via a transport protocol. Similarly, the electronic device 400 can perform a decryption process to decrypt data to be written to the block device when the data is received from the controller via a transport protocol. In some examples, the electronic device 400 can perform a decryption / encryption process using a cryptographic protocol such as a protocol based on transport layer security (TLS). For example, the electronic device 400 can implement a TLS-based protocol between a network block protocol and a transport protocol at the application layer.

[0117] As will be described in more detail below, method 500 may also include receiving a single byte response having a byte value from the controller. At block 550, the controller sends a single byte response in response to sending data read from the block device. Upon receiving the single byte response, electronic device 400 may determine whether the byte value matches a byte value reserved according to the transport protocol for confirming receipt of the sent data or for indicating valid transmission of the data. In response to determining a match, additional data may be sent via the transport protocol (i.e., block 550). Otherwise, the previously sent data may be sent again.

[0118] Figure 6 Another method for in-vehicle communication according to one embodiment of the present invention is shown. Figure 6 The method shown may alternatively or additionally be performed Figure 5 The method shown.

[0119] Method 600 can be referred to above Figure 4 The electronic device 400 described above is executed by at least one interface 430, at least one processor 410 and at least one memory 420. The electronic device 400 is installed to control functions in a vehicle and is connected to a vehicle bus via at least one interface 430. In addition, the memory 420 includes stored program codes, and the execution of the program codes by the processor 410 results in the execution of the method described below.

[0120] The method 600 begins by configuring the interface 430 (or the electronic device 400) to communicate with a controller in the vehicle via a transmission protocol (block 610). Examples of transmission protocols include a transmission protocol other than TCP, a transmission protocol according to ISO standard ISO 15765-2, or one of the transmission protocols according to a variant of ISO standard ISO 15765-2.

[0121] More specifically, at block 610, the interface 430 may be configured to implement at least a portion of a protocol stack according to the ISO / OSI reference model. The interface 430 may be configured to implement a transport protocol at the transport layer of the protocol stack. In addition, the interface 430 may be configured to implement one or more protocols for communicating via a vehicle bus (e.g., CAN, LIN, etc.) at the physical layer of the protocol stack. Therefore, as will be described in more detail below, the interface 430 may be configured to transmit a transmission unit (e.g., frame, packet, symbol, signal, etc.) according to a transmission protocol and / or transmit a transmission unit (e.g., frame, packet, symbol, signal, etc.) according to a protocol for communicating via a vehicle bus through a vehicle bus.

[0122] In addition, the method 600 includes configuring the electronic device 400 to provide debugging information associated with the software component executed by at least one processor 410 of the electronic device 400 through the interface (block 620). For example, the electronic device 400 or the interface 430 may be configured to implement a remote debugging protocol at block 620. More specifically, the electronic device 400 or the interface 430 may be configured to implement the remote debugging protocol at an application layer of the protocol stack, so that the electronic device 400 or the interface 430 can transmit a transmission unit (e.g., a frame, a packet, a symbol, a signal, etc.) according to the remote debugging protocol.

[0123] At block 630, the electronic device 400 receives a request to provide debugging information. For example, the electronic device 400 may receive a transmission unit according to a protocol for communicating through a vehicle bus at a physical layer. At the physical layer, the electronic device 400 may demodulate the transmission unit according to the protocol for communicating through the vehicle bus to obtain a transmission unit according to the transmission protocol. The electronic device 400 may provide the transmission unit according to the transmission protocol to the transport layer. At the transport layer, the electronic device 400 may demodulate the transmission unit according to the transmission protocol to obtain a transmission unit according to the remote debugging protocol. The electronic device 400 may provide the transmission unit according to the remote debugging protocol to the application layer. At the application layer, the electronic device 400 may demodulate the transmission unit according to the remote debugging protocol to obtain a request to provide debugging information. The request may include information about the software component for which debugging information is to be provided.

[0124] When a request to provide debugging information is received at block 630, the electronic device 400 obtains debugging information generated during execution of the software component and sends the debugging information to the controller via a transmission protocol (block 640). For example, the electronic device 400 may obtain debugging information when executing the software component, or the electronic device 400 may access debugging information stored during execution of the software component.

[0125] In some examples, the electronic device 400 may access the debugging information and use the debugging information to modulate a transmission unit according to the network block protocol. For example, the electronic device 400 may generate a transmission unit according to the remote debugging protocol, including the debugging information or at least a portion of the debugging information as a payload (e.g., generating one or more messages according to the remote debugging protocol). Debugging the transmission unit according to the remote protocol can be performed at the application layer. Then, the electronic device 400 may provide the transmission unit according to the remote debugging protocol to the transport layer, wherein the transmission unit according to the transmission protocol is modulated (e.g., generating one or more frames according to the transmission protocol). The transmission unit according to the transmission protocol may include the transmission unit according to the network block protocol or at least a portion thereof as a payload. The electronic device 400 may then provide the transmission unit according to the transmission protocol to the physical layer, wherein the transmission unit according to the protocol for communicating through the vehicle bus is modulated (e.g., generating a transmission unit for sending through the vehicle bus). The transmission unit according to the protocol for communicating through the vehicle bus may include the transmission unit according to the transmission protocol or at least a portion thereof as a payload. The electronic device 400 may then send the transmission unit according to the protocol for communicating through the vehicle bus to the controller via the vehicle bus.

[0126] Method 600 may also include one or more operations described above with reference to method 500 .

[0127] Figure 7 Another method for in-vehicle communications according to one embodiment of the present disclosure is shown.

[0128] Method 700 can be referred to above Figure 4 The electronic device 400 described herein is executed by at least one processor 410 and at least one memory 420. The electronic device 400 is installed to control functions in a vehicle and is connected to a vehicle bus. In addition, the memory 420 includes stored program code, and the execution of the program code by the processor 410 causes the execution of the method described below. As described above, the electronic device is connected to other electronic devices or a central control component via the vehicle bus and communicates with it. Examples of other electronic devices or central control components include an electronic control unit (ECU) or an electronic control module (ECM) for controlling one or more electrical systems of a vehicle embedded in a vehicle, and / or a vehicle controller such as a central vehicle controller.

[0129] Method 700 begins by generating one or more messages of a network block protocol at an electronic device (block 710). In one example, the network block protocol may include the above-mentioned NBD protocol. Through the messages, the electronic device acts as a network block device relative to other electronic devices or a central control component (e.g., a controller of a vehicle). More specifically, the electronic device acts as a server relative to other electronic devices or central control components that act as clients. The electronic device provides access (read / write access) to the electronic device (i.e., to itself) or a storage device connected to the electronic device or a portion thereof (e.g., a partition of a storage device) to the client through the generated messages.

[0130] Based on the message, the electronic device then generates one or more frames according to the transport protocol (box 720). Examples of transport protocols include protocols at the transport layer (i.e., transport layer protocols), such as ISO-TP (e.g., ISO 15765-2) described above. Those skilled in the art will appreciate that ISO-TP is only an example, and there may be other transport protocols in addition to the TCP / IP protocol, which is generally not supported by electronic devices. Possible examples include transport protocols based on ISO 15765-2 or derived therefrom. Generating one or more frames according to the transport protocol includes segmenting the message according to the network block protocol and packaging the segments as payloads into frames of a size suitable for transmission on the vehicle bus. In addition, generating one or more frames may also include adding metadata to the frame so that the payload can be correctly reassembled by the receiver (i.e., other electronic devices or central control components).

[0131] Thereafter, the generated frame is sent from the electronic device to another electronic device or a central control component via the vehicle bus (block 730). The transmission here may include converting the frame according to the vehicle bus protocol into a symbol, signal, or frame, and then sending the symbol, signal, or frame via the vehicle bus. Examples of vehicle buses include the above-mentioned CAN bus or LIN bus. Therefore, the symbol or signal to be sent may correspond to the CAN bus protocol or the LIN bus protocol (i.e., the protocol at the physical layer).

[0132] To simplify the description, the exemplary method 700 described above is only for sending from an electronic device (acting as a server) to other electronic devices or a central control component (acting as a client). However, it is obvious to those skilled in the art that receiving communications from other electronic devices or central control components (clients) at an electronic device (server) is performed in the opposite direction. Specifically, reception from a client includes receiving one or more frames according to a transmission protocol via a vehicle bus, extracting a payload (i.e., a message according to a network block protocol) from the one or more frames, and if necessary, correctly reassembling the message, and forwarding the message to the network block protocol (i.e., the application layer) for processing. In addition, it is also obvious to those skilled in the art that the above method 700 for sending and receiving is also performed by other electronic devices or a central control component (client) to generate, receive and process messages according to a network block protocol (e.g., providing a request to a server as described above).

[0133] Another embodiment of the above method 700 or the electronic device 400 implementing the above method 700 includes the electronic device acting as a server of a network block device relative to another electronic device or a central control component, and providing a logical or physical storage device connected to the electronic device as a network block device. For example, the electronic device may provide a local storage device or a portion of a local storage device (e.g., an area, a partition, etc.) as a network block device. Other examples of such storage devices include any type of storage device, such as flash memory, random access memory (RAM), solid state disk (SSD), etc. Therefore, generating a message according to the network block protocol involves access (read / write access) to these physical or logical storage devices, which are therefore provided as network block devices for access by other electronic devices or a central control component through the electronic device acting as a server.

[0134] Accessing a network block device according to a network block protocol or generating a message according to a network block protocol can be a response to a corresponding request from another electronic device or a central control component. To this end, before box 710, an electronic device (i.e., a server) receives a request to access a network block device from another electronic device or a central control component (i.e., a client). As described above in conjunction with the NBD protocol as an exemplary network block protocol, a client can send an NBD request to a server to, for example, read a data block starting from a predetermined offset, or write data to a location defined by an offset from a network block device. Thus, an exemplary request of a client may include a request to read one or more blocks of a network block device (e.g., from a given absolute address of a network block device), and a request to write one or more blocks to a network block device (e.g., to a given absolute address of a network block device). In this case, the message generated by the server according to the network block protocol (i.e., block 710) includes a corresponding response, such as the above-mentioned NBD response.

[0135] In addition, as described above in conjunction with the NBD protocol, a corresponding handshake process or handshake phase may be performed prior to the process according to method 700 to establish a session between an electronic device acting as a server and other electronic devices or a central control component acting as a client. The handshake process or handshake phase may correspond to the above-mentioned NBD handshake and may be initiated by receiving a connection request by other electronic devices or a central control component. For those skilled in the art, packets for request / response exchanged during the handshake process or handshake phase are also messages according to the network block protocol, which undergo the sequence described according to method 700 for transmission via the vehicle bus, i.e., are sent via the vehicle bus as a payload in a frame according to the transmission protocol.

[0136] Furthermore, the message may be subjected to encryption before it is used as a basis for generating a frame according to a transport protocol. For example, the encryption may be before the transport layer and therefore before the transport protocol. An example of suitable encryption includes the TLS protocol.

[0137] TLS consists of two main components: TLS handshake and TLS record. In the TLS handshake, secure key exchange and authentication occur. Then, the TLS record uses the symmetric key negotiated in the TLS handshake for secure data transmission (i.e., the message according to the network block protocol is encrypted and sent together with the message authentication code (MAC) to prevent modification, i.e., forwarded to the transport protocol). In other words, before the message encrypted in this way is used as the basis for generating a frame according to the transport protocol, the message is encrypted by a symmetric encryption process using a shared encryption key. For encryption (e.g., according to an encryption protocol), other electronic devices or central control components (as clients) can first establish a connection with an electronic device (as a server). The electronic device (server) authenticates itself to another electronic device or central control component (client) using a certificate, which is checked for credibility and consistency with the name of (for example) the electronic device. Similarly, other electronic devices or central control components can authenticate themselves to the electronic device using their own certificates. After successful verification, a secret random number encrypted with the public key of the electronic device is sent. In other embodiments, a Diffie-Hellman key exchange calculation is performed by two communication partners to obtain a shared secret, from which an encryption key can then be derived. This key is then used to encrypt all messages in that connection using symmetric encryption methods and is protected by a MAC to protect message integrity and authenticity.

[0138] In another embodiment, method 700 may include causing the electronic device to receive confirmation due to the transmission of one or more frames on the vehicle bus. In this regard, the confirmation of receiving a frame in a plurality of frames may include a single byte with a predetermined byte value. After receiving such a byte, the electronic device checks whether the byte value corresponds to a byte value, which corresponds to a confirmation of the reception of the sent frame or an indication of the transmission of a valid frame according to the transmission protocol. If the verification is successful, the electronic device sends another frame according to the transmission protocol to another electronic device or a central control component via the vehicle bus. Otherwise, the electronic device may retransmit the sent frame or perform error handling, possibly terminating the session or disconnecting.

[0139] Although the above embodiments have been described with reference to the network block protocol, it should be understood that the present invention is also applicable to the remote debugging protocol. Therefore, the above message generated at box 710 can also correspond to a message according to the remote debugging protocol for providing debugging information to other electronic devices or central control components. In this case, the debugging information generally relates to one or more software or software components executed by the electronic device using at least one processor. In this case as well, based on the message according to the remote debugging protocol, a frame is generated according to the transmission protocol (i.e., box 720), and then the frame is sent to other electronic devices or central control components via the vehicle bus. This makes it possible to provide GDB (i.e., GNU debugger) known from a UNIX-like operating system or a remote executable variant of GDB and / or DAP (debug adapter protocol) in a vehicle, for example, via a vehicle bus (such as CAN or LIN).

[0140] For example, in the case of a remote debugging protocol, other electronic components or a central control component may need to respond to a frame received according to a transport protocol via a vehicle bus with a response including a single ACK / NACK packet. For this purpose, it may be sufficient to send a response consisting of a single byte, the value of which is 0x41 for ACK and 0x40 for NACK. These merely exemplary values ​​are reserved for ACK / NACK in (for example) ISO-TP. Alternatively, other reserved byte values ​​such as 0x33 0x01 and 0x33 0x00 or other single byte values ​​or sequences thereof such as 0x33 / 0x34 may be used. For example, it would also be advantageous to reinterpret byte values ​​that have been reserved but are not required for the corresponding situation (i.e., the network block protocol or the remote debugging protocol), such as 0x30 0x000x00 for a continue sending message according to ISO-TP as an ACK, or 0x32 0x00 0x00 for a stop message according to ISO-TP as a NACK.

[0141] Figure 8 is a diagram of the internal components of a computing system 600 that implements the functionality described herein.

[0142] The computing system 800 may be in a vehicle and include at least one processor 810, a user interface 820, a network interface 830, and a main memory 860 that communicate with each other via a bus 850. Optionally, the computing system 800 may also include a static memory 870 and a disk drive unit (not shown), which also communicate with each other via the bus 850. A video display, an alphanumeric input device, and a cursor control device may be provided as examples of the user interface 820.

[0143] In addition, the computing system 800 may also include a sensor interface 840 for communicating with a sensor of a vehicle. Alternatively, the computing system 600 may communicate with the sensor via a network interface 830. The sensor acquires the image. The sensor may be a radar sensor, a laser scanner, a light detection and ranging (LIDAR) sensor, etc. The computing system 800 may also be connected to a database system (not shown) via the network interface 830, wherein the database system stores additional data required to provide the functions described herein. The network interface 830 also connects the computing system 800 to a vehicle bus (e.g., CAN or LIN), and the computing system 800 communicates with other computing systems connected to the vehicle bus via the vehicle bus.

[0144] The main memory 860 can be a random access memory (RAM) and / or any other volatile memory. The main memory 860 can store program code 880 for performing the exemplary methods described herein. The memory 860 can also store additional program data 882 required to provide the functions described herein. A portion of the program data 882 and / or program code 880 can also be stored in a separate, for example, cloud storage and at least partially executed remotely. In such an exemplary embodiment, the memory 860 can store the segment encoding modules and related encoding modules described herein in the cache 890.

[0145] Computer-readable storage media, which are non-transitory in nature, may include volatile and nonvolatile, as well as removable and non-removable tangible media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media may also include random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state memory technology, portable compact disk read-only memory (CD-ROM) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be read by a computer.

[0146] The computer-readable storage medium itself should not be interpreted as a transient signal (e.g., a radio wave or other propagating electromagnetic wave, an electromagnetic wave propagating through a transmission medium such as a waveguide, or an electrical signal transmitted through a wire). Computer-readable program instructions can be downloaded from the computer-readable storage medium to a computer, another type of programmable data processing device, or another device, or downloaded to an external computer or external storage device via a network.

[0147] It should be understood that although specific embodiments and variations are described herein, further modifications and substitutions are obvious to those skilled in the art. Specifically, examples are provided by illustrating principles, and various specific methods and arrangements for implementing various aspects of the present disclosure are provided.

[0148] In some embodiments, the functions and / or actions specified in the flow chart, sequence diagram and / or block diagram are reordered, processed in series and / or processed concurrently without departing from the scope of the present invention. In addition, any flow chart, sequence diagram and / or block diagram may include more or less blocks than those shown in accordance with embodiments of the present invention.

[0149] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the embodiments of the present disclosure. It should also be understood that when used in this specification, the terms "include" and / or "comprise" specify the presence of the features, wholes, activities, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, activities, operations, elements, components and / or combinations thereof. In addition, to the extent that the terms "include", "have", "have", "with", "consist of", or variations thereof are used in the detailed description or claims, these terms are intended to be included in a manner similar to the term "comprise".

[0150] Although the description of various embodiments has illustrated all of the subject disclosure, and although these embodiments have been described in considerable detail, it is not intended to limit or in any way restrict the scope of the appended claims to such details. Additional advantages and modifications will be apparent to those skilled in the art. Therefore, the present disclosure in its broader aspects is not limited to the specific details, representative devices and methods, and illustrative examples shown and described. Therefore, the described embodiments should be understood as provided as examples for the purpose of teaching general features and principles, and should not be understood as limiting the scope as defined in the appended claims.

Claims

1. An electronic device in a vehicle, the electronic device comprising: at least one interface to a vehicle bus; at least one processor; as well as at least one memory containing program code, wherein when the program code is executed by the at least one processor, the program code causes the electronic device to: configuring the interface to communicate with a controller in the vehicle via a transmission protocol; configuring the electronic device accessible by the controller through the interface as a block device; Upon receiving a request to access the block device from the controller through the transmission protocol: Reading data from the block device; and The data is sent to the controller via the transmission protocol.

2. The electronic device according to claim 1, wherein: When the program code is executed by the at least one processor, the program code further causes the electronic device to: Upon receiving a request to access the block device from the controller through the transmission protocol: receiving data from the controller via the transmission protocol; and The data is written to the block device.

3. The electronic device according to claim 1, wherein: The data includes software code, and when the program code is executed by the at least one processor, the program code further causes the electronic device to: The block device is flashed with the software code.

4. The electronic device according to any one of claims 1 to 3, wherein: When the program code is executed by the at least one processor, the program code further causes the electronic device to: Upon receiving a request to access the block device from the controller through the transmission protocol: A handshake process is performed to establish a session between the electronic device and the controller for accessing the block device.

5. The electronic device according to any one of claims 1 to 4, wherein: When the program code is executed by the at least one processor, the program code causes the electronic device to: Using an encryption key shared by the electronic device and the controller, a decryption / encryption process is performed to decrypt / encrypt the data.

6. The electronic device according to any one of claims 1 to 5, further comprising: one or more physical or logical storage devices, wherein when the program code is executed by the at least one processor, the program code causes the electronic device to: The one or more accessible physical or logical storage devices are configured as the block devices.

7. The electronic device according to any one of claims 1 to 6, wherein: When the program code is executed by the at least one processor, the program code causes the electronic device to: The electronic device is configured to use a network block protocol to enable access through the interface.

8. The electronic device according to any one of claims 1 to 7, wherein: The data comprises one or more byte blocks of a fixed block size; and / or wherein, The electronic device comprises an electronic control module (ECM) for controlling one or more electrical systems in the vehicle, the ECM being embedded in the vehicle; and / or wherein the controller comprises a central vehicle controller.

9. The electronic device according to any one of claims 1 to 8, wherein: The transport protocol comprises one of: a transport protocol different from the Transmission Control Protocol TCP; and a transport protocol according to ISO standard ISO 15765-2; and / or The vehicle bus includes a controller area network CAN or a local interconnect network LIN.

10. The electronic device according to claim 9, wherein: The interface comprises one of: an interface incompatible with TCP; an interface compatible with a transmission protocol according to ISO standard ISO 15765-2; and an interface compatible with CAN or LIN.

11. The electronic device according to any one of claims 1 to 10, wherein: When the program code is executed by the at least one processor, the program code further causes the electronic device to: receiving a single byte response having a byte value from the controller in response to sending the data; determining whether the byte value matches a byte value reserved for acknowledging receipt of transmitted data or for indicating valid transmission of the data in accordance with the transmission protocol; and In response to determining a match, additional data is sent via the transport protocol.

12. The electronic device according to any one of claims 1 to 11, wherein: When the program code is executed by the at least one processor, the program code further causes the electronic device to: configuring the electronic device to provide, via the interface, debug information associated with a software component executed with the at least one processor of the electronic device; Upon receiving a request from the controller to provide the debugging information: The debugging information is sent to the controller through the transmission protocol.

13. A computer-implemented method for in-vehicle communication, the computer-implemented method comprising the steps of: configuring an interface of the electronic device to communicate with a controller in the vehicle via a transmission protocol; configuring the electronic device accessible by the controller through the interface as a block device; Upon receiving a request to access the block device from the controller through the transmission protocol: Reading data from the block device; and The data is sent to the controller via the transmission protocol.

14. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to claim 13.

15. A computer-readable data carrier having stored thereon a computer program product according to claim 14.

Images