Electronic control device and inter-core communication method

Abstract

To transfer a large amount of data at a high speed while guaranteeing reliability of data transfer.SOLUTION: An electronic control apparatus includes a first processor core, a second processor core, and a shared memory accessible from the first processor core and the second processor core. The first processor core includes a first SOME / IP conversion unit which converts data received in CAN communication to SOME / IP message, and stores the SOME / IP message converted by the first SOME / IP conversion unit in the shared memory. The second processor core includes a second SOME / IP conversion unit which converts SOME / IP message to a format available in an application, acquires the SOME / IP message stored in the shared memory and converts the SOME / IP message acquired by the second SOME / IP conversion unit to a format available in the application, to be provided to the application.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a data transfer method using SOME / IP, a communication standard for automobiles.

Background Art

[0002] In recent years, the concept of SOA (Service-oriented architecture) has been adopted in in-vehicle networks, and a protocol called SOME / IP has come to be used. Since this SOME / IP is a protocol created based on Ethernet (Ethernet is a registered trademark; the same applies hereinafter), data is usually transferred via Ethernet. When transferring SOME / IP, data errors are detected by each protocol via which Ethernet, IP, and TCP pass, ensuring the reliability of data transfer.

[0003] When transferring SOME / IP messages between different operating systems (OSs) operating on a multi-core, if sent using Ethernet, the processing time becomes long for large-capacity data. A method for transferring SOME / IP messages between cores via shared memory has not been established. Also, it is difficult to compensate for the reliability of data transfer guaranteed by passing through Ethernet.

[0004] In Ethernet, data error detection called CRC is adopted, and the reliability of data transfer is guaranteed by CRC. CRC is also adopted in CAN, and an area for CRC is prepared in the frame format. Therefore, these protocols have CRC implemented in the protocol itself. On the other hand, the SOME / IP message format does not implement a value for performing error detection such as CRC, and it is difficult to guarantee the reliability of data with just a SOME / IP message alone.

[0005] The following prior art forms serve as background technology for this field. Patent Document 1 (International Publication No. 2020 / 217202) describes a method for transmitting messages between a requesting entity and a providing entity of a service instance using the SOME / IP communication protocol in an onboard communication network of a vehicle. Mutual authentication is performed between the requesting and providing entities, taking into account communications associated with the service instance. This step includes verifying the existence and mutual validity of pre-assigned certificates of the requesting and providing entities that authorize access to the service instance, and verifying that the security level at which the service is provided by the providing entity is not lower than the minimum security level pre-assigned to the service by both the requesting and providing entities. If the certificate and security level verification is successful, at least one communications message associated with the service instance is transmitted from the providing entity to the requesting entity and vice versa. A method for transmitting messages or data using the SOME / IP communication protocol is described. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] International Publication No. 2020 / 217202 [Overview of the project] [Problems that the invention aims to solve]

[0007] In multi-core inter-core communication, there is a need for a method that can transfer large amounts of data at high speed, and guaranteeing the reliability of data transfer is also important. As mentioned above, SOME / IP messages are usually transferred via Ethernet, but using shared memory allows for faster transfer of large amounts of data.

[0008] However, by using shared memory and bypassing Ethernet, data error detection such as CRC in protocols like Ethernet, IP, and TCP is not performed, and therefore the reliability of data transfer cannot be guaranteed.

[0009] Patent Document 1 discloses improvements to the transmission of data or messages on vehicles using the SOME / IP communication protocol, and does not address the conversion of CAN data to SOME / IP messages or the use of SOME / IP messages to enable inter-core communication between different operating systems, nor does it improve the reliability of the SOME / IP protocol, which are the issues that the present invention seeks to solve.

[0010] Furthermore, when transferring received data via CAN between cores, the receiving core requires service conversion to make the data usable by the application. This type of processing, known as S2S (signal to service), suffers from slow processing speeds. Using the SOME / IP protocol eliminates the need for S2S.

[0011] The present invention aims to provide a method for transferring large amounts of data at high speed while ensuring the reliability of data transfer through inter-core communication using shared memory. [Means for solving the problem]

[0012] A typical example of the invention disclosed in this application is as follows: an electronic control device comprising a first processor core that receives data via CAN communication, a second processor core on which an application runs, and a shared memory accessible by the first and second processor cores, wherein the first processor core has a first SOME / IP conversion unit that converts data received via CAN communication into a SOME / IP message, and stores the SOME / IP message converted by the first SOME / IP conversion unit in the shared memory, and the second processor core has a second SOME / IP conversion unit that converts the SOME / IP message into a format usable by the application, retrieves the SOME / IP message stored in the shared memory, converts the retrieved SOME / IP message into a format usable by the application using the second SOME / IP conversion unit, and provides it to the application. [Effects of the Invention]

[0013] According to one aspect of the present invention, inter-core communication using shared memory enables high-speed transfer of large amounts of data while guaranteeing the reliability of data transfer. Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0014] [Figure 1] This diagram shows the configuration of the multicore microcontroller in Example 1. [Figure 2] This diagram shows the configuration of the ECU in Example 1. [Figure 3] This block diagram shows the processes performed by each core in Example 1. [Figure 4] This figure shows the frame formats of CAN and CAN FD in Example 1. [Figure 5] This figure shows the message format of SOME / IP in Example 1. [Figure 6] This figure shows a SOME / IP message created using the CAN data from Example 1. [Figure 7] It is a diagram showing the CRC value added to the SOME / IP message of Example 2. [Figure 8] It is a diagram showing the arithmetic processing of the CRC of Example 2. [Figure 9] It is a flowchart of the process of notifying the application when a Payload CRC error in Example 2 is detected. [Figure 10] It is a flowchart of the process of requesting retransmission when a Payload CRC error in Example 2 is detected. [Figure 11] It is a diagram showing the configuration around the second SOME / IP conversion unit of Example 3. [Figure 12] It is a diagram showing a method for complementing missing values generated in continuous data of Example 4. [Figure 13] It is a flowchart of the data complementation process for complementing the missing data generated in the continuous data of Example 4. [Figure 14] It is a diagram showing a method for complementing missing values generated in discrete data of Example 4. [Figure 15] It is a flowchart of the data complementation process for complementing the missing data generated in the discrete data of Example 4. [Figure 16] It is a diagram showing the configuration around the second SOME / IP conversion unit of Example 5. [Figure 17] It is a diagram showing another configuration around the second SOME / IP conversion unit of Example 5.

Mode for Carrying Out the Invention

[0015] <Example 1> FIG. 1 is a diagram showing the configuration of the multi-core microcomputer 1. The multi-core microcomputer 1 of this embodiment includes a first core 2 that executes processing, a second core 3 that executes processing, a first core RAM 4, a second core RAM 5, a first core non-volatile memory 6, a second non-volatile memory 7, a communication controller 8 that transmits and receives data to and from the outside of the multi-core microcomputer, and a shared memory 9 that is a RAM that can be referred to by the first core 2 and the second core 3. Also, each component is connected through an internal bus 10.

[0016] A multi-core microcontroller 1 is a microcomputer equipped with two or more cores. A microcontroller with one core is called a single-core microcontroller. To improve the performance of a microcontroller, there are two methods: increasing the operating frequency of the cores within the microcontroller to increase processing speed, and simply increasing the number of cores within the microcontroller used for processing. Increasing the operating frequency increases power consumption, but with a multi-core microcontroller, performance can be improved and power consumption suppressed even at low operating frequencies. In this example, a 2-core microcontroller will be used for explanation.

[0017] The first core 2 and the second core 3 are the devices that actually perform processing, receiving data from various devices and performing various calculations. As mentioned earlier, increasing the operating frequency of the cores improves performance, but also increases power consumption.

[0018] The first core RAM4 is the main memory used by the first core2 when it performs processing. Similarly, the second core RAM5 is the main memory used by the second core3 when it performs processing. These are composed of volatile memory devices, and the data they were using is erased when the microcontroller's power is turned off.

[0019] The internal bus is a transmission path that connects the internal circuits of the multicore microcontroller 1.

[0020] The multi-core microcontroller 1 is implemented in the electronic control unit (ECU) mounted on the vehicle. The ECU controls vehicle-mounted equipment such as the engine, power steering system, and controlled braking system.

[0021] Figure 2 shows the configuration of ECU 10. In addition to the multicore microcontroller 1 described in Figure 1, ECU 10 has a CAN transceiver 11 that enables communication with CAN and a LAN port 12 that enables Ethernet connection (Ethernet is a registered trademark, the same applies hereinafter). The CAN transceiver 11 is connected to the CAN bus 15, which will be described later. Signals received by the CAN transceiver 11 from other ECUs 16 via the CAN bus 15 and signals received by the LAN port 12 from LAN 12 via Ethernet are sent to the communication controller 8 of the multicore microcontroller 1. The communication controller 8 has a CAN controller 13 that handles signals via CAN and an Ethernet switch 14 that handles signals via Ethernet.

[0022] CAN bus 15 is a transmission path that transfers data using the CAN protocol and consists of two communication lines called CAN High and CAN Low. CAN transmits CAN signals of 0 and 1 based on the voltage difference applied to these two communication lines. This format improves noise immunity. Details of the CAN protocol will be described later.

[0023] The CAN controller 13 is a module that has functions such as receiving necessary data by generating an interrupt and ignoring unnecessary data among the data transferred on the CAN bus 15.

[0024] The Ethernet switch 14 is an abbreviation for Ethernet Switch and is a module that controls the destination of Ethernet data received from the LAN port 12. The Ethernet switch 14 controls the destination of data based on information such as the source and destination contained in the data being transmitted over Ethernet.

[0025] Figure 3 is a block diagram showing the processing performed by each core. The multicore microcontroller 1 has a first core 2 having a receiving unit 101 that receives CAN data (described later), a second core 3 that utilizes the data received by the first core 2, and a shared memory 9 that enables the movement of data between the two cores 2 and 3. In this embodiment, the receiving unit 101 mounted on the first core 2 receives CAN data from another ECU 16, the first SOME / IP conversion unit 102 extracts the actual CAN data (described later), creates a SOME / IP message according to the SOME / IP message format, and transfers it to the second core 3 via the shared memory 9. In the second core 3, the second SOME / IP conversion unit 103 performs service conversion, enabling data transfer to the application.

[0026] Shared memory 9 is a RAM area that can be accessed from any of the multiple cores. By using shared memory 9, data can be transferred to different cores without going through an external communication path.

[0027] CAN stands for Controller Area Network, and it is currently the most widely used in-vehicle network protocol.

[0028] Data transmitted via CAN is defined in frames, and each frame of CAN data contains various information, such as an ID to identify the frame being transmitted via CAN. Of the data contained in a frame, the data actually used for control by applications is stored in an area called the data field and is transmitted in the range of 0-8 bytes. The CAN frame format will be described later. In addition, there is a protocol called CAN FD, which is an extension of CAN. CAN FD is a communication protocol developed in response to the increasing functionality of automobiles, and it can transmit more data faster than CAN. The data field of a frame transmitted by the CAN FD protocol stores data in the range of 0-64 bytes. The CAN FD frame format will be described later.

[0029] A protocol is a set of established communication formats and procedures for exchanging data on a computer. By following these established protocols, components from different manufacturers can communicate with each other.

[0030] SOME / IP is a protocol created based on Ethernet to implement the concept of SOA (Service-Oriented Architecture), which will be described later, in an in-vehicle network, and is classified as an upper layer in the OSI reference model, which will also be described later. In SOME / IP, the functions and processing of in-vehicle applications are defined in units of services, and when using these services, the service is searched for on the in-vehicle network. If the ECU that searches for a service is called the client, and the ECU that provides the service is called the server, the server that provides the searched service notifies the client that the service is available. Once the client confirms the service through the notification, it requests the server to send data. If there are no problems, the server approves the request and sends the data to the client periodically or at times when the value changes.

[0031] SOA stands for Service-Oriented Architecture, and it is a concept for building computer systems. In SOA, application functions are modularized into service units, making these services accessible from outside the application. Systems can then be built and implemented by combining these modularized services.

[0032] The OSI reference model is a concept for unifying different network architectures. The OSI reference model is classified into seven layers. Layer 7: Application Layer 6 layers: Presentation layer Layer 5: Session Layer 4th layer: Transport layer Layer 3: Network Layer Layer 2: Data Link Layer Layer 1: Physical layer

[0033] Higher layers require software configuration, while lower layers require hardware configuration. For example, in Ethernet, the physical layer is the connection port where LAN cables are plugged in. The data link layer is the layer that receives Ethernet frames. The network layer and transport layer are TCP and IP, which are carried over Ethernet. Although it is classified in this way, SOME / IP is a protocol that encompasses the session layer to the application layer. There are also protocols that span multiple layers, such as CAN, which is a protocol that spans the physical layer and the data link layer.

[0034] Figure 4 shows the frame formats for CAN and CAN FD. CAN data received from other ECUs is transmitted in the format of the CAN protocol (including CAN FD), and this data includes CAN protocol-specific information such as ID, control field, data fields 201 and 202, and CRC.

[0035] The actual CAN data used after being converted to the SOME / IP message format consists of data 201a, 211a, 211b, etc., stored in the data field of the CAN data. Both CAN and CAN FD can transfer multiple data points, but they differ in their maximum data size and communication speed.

[0036] The SOME / IP message format defines a SOME / IP message as a collection of data created according to the SOME / IP message format, which is the data format usable with the SOME / IP protocol. The SOME / IP message format is described below.

[0037] Figure 5 shows the SOME / IP message format. The first SOME / IP conversion unit 113 executes the process of creating a SOME / IP message based on the actual CAN data. The SOME / IP message format requires the following information. Service ID Method ID Length Client ID Session ID Version License Privacy Version Message Type Return Code Payload

[0038] Let's explain each area.

[0039] The Service ID indicates the type of service, which will be explained later. The Method ID indicates the type of method. The Service ID and Method ID are sometimes collectively referred to as the Message ID.

[0040] Length is the message length from the Client ID to the Payload.

[0041] The Client ID is identification information used to identify the caller within the ECU. The Session ID is identification information used to distinguish messages forwarded from the same sender. The Client ID and Session ID are sometimes collectively referred to as the Request ID.

[0042] The Protocol Version indicates the protocol version of SOME / IP.

[0043] Interface Version indicates the major version of the service interface, which will be described later. Message Type indicates the type of message in SOME / IP.

[0044] The Return Code is a return value indicating whether the request was processed successfully. The Payload is the data.

[0045] Here, a service is an application provided by each ECU, and a Method is a function contained within that application.

[0046] A Method is one way of thinking when using SOME / IP, and it refers to a function included within a service. Specifically, as explained in the SOME / IP protocol above, the application that requests the service is the client, and the application that provides the service is the server. A service consists of a combination of one or more functions, and functions are managed in units called Methods, with each Method being assigned a Method ID. In SOME / IP, the header information describes which service and which Method (function) the data was obtained from.

[0047] A service interface is an interface for accessing a function that provides a service. When using a service with SOME / IP, data is retrieved through the service interface.

[0048] Of the SOME / IP message format mentioned above, the information 301 other than the Payload is called the Header, and the Payload portion 302 where the actual CAN data is stored is simply called the Payload.

[0049] Figure 6 shows a SOME / IP message created using CAN data. Since serialization for the application is not performed at the SOME / IP creation stage, the actual data can be stored directly as variables. In the first SOME / IP conversion unit, a header is created based on the ID contained in the CAN data, and the actual CAN data 201a, 211a, and 211b shown in Figure 4 are stored in the Payload portion of the SOME / IP message format. In this embodiment, the SOME / IP header is created by the CAN data ID, and actual CAN data with different IDs cannot be combined into the same SOME / IP packet. The CAN data ID allows the application to determine the type of CAN data it receives through the SOME / IP message.

[0050] SOME / IP is typically a higher-level protocol for data transmitted over Ethernet. In this embodiment, by transmitting SOME / IP messages via shared memory 9, high-speed communication is possible between cores for large amounts of data compared to Ethernet communication. Furthermore, by converting to SOME / IP on the first core side, data can be used by two cores even if they have different language environments, improving the convenience of data utilization.

[0051] <Example 2> In this embodiment, the CRC is calculated and stored in shared memory 9 along with the created SOME / IP message. CRC, also known as cyclic redundancy check, is one of the error detection codes for data. CRC is also used in CAN frames and Ethernet frames, and CAN and Ethernet frames contain CRC values. The CRC value is calculated based on the information contained in the frame, and the added CRC value is checked upon reception. However, since the CRC field is not defined in the SOME / IP message format, error detection is impossible with SOME / IP alone. As mentioned above, SOME / IP is a protocol created on the premise that it will normally be sent over Ethernet, and error detection is performed in each protocol such as Ethernet, IP, and TCP that SOME / IP passes through before reaching the application. Therefore, when the created SOME / IP message is transferred via shared memory 9, the reliability of the data can be guaranteed by performing similar error detection. Therefore, in this embodiment, since the CRC value is not included in the SOME / IP message (if the CRC value were included, it would be unreceivable because it would differ from the SOME / IP message format), the CRC value calculated separately from the created SOME / IP message is stored in shared memory 9.

[0052] Figure 7 shows the CRC values ​​attached to the SOME / IP message. In this embodiment, two CRCs are attached to the SOME / IP message: a Header CRC calculated based on Header 301 and a Payload CRC calculated based on Payload 302. For example, the CRC is associated with the SOME / IP message by storing the CRC in the address following the created SOME / IP message, thereby attaching the CRC to the SOME / IP message. In this embodiment, 4 bytes are used for each of the two CRCs. This makes it possible to determine whether there is an error in the transmitted data and to distinguish whether the error is in the Header or the Payload.

[0053] Referring to Figure 8, the calculation process for CRC in this embodiment will be explained.

[0054] Step 401: After the first core 2 receives CAN data, it converts the data to match the SOME / IP message format based on the ID contained in the CAN frame, creates information such as a header, and creates a SOME / IP message.

[0055] Step 402: Calculate the CRC based on the information in the first 16 bytes of the header of the SOME / IP message created in Step 401. In this embodiment, the header CRC is a fixed length of 4 bytes.

[0056] Step 403: Calculate the CRC based on the Payload information from the first 16 bytes of the SOME / IP message created in Step 401. In this example, the Payload CRC is a fixed length of 4 bytes and does not change depending on the length of the Payload data.

[0057] Step 404: Store the created SOME / IP message in shared memory, and then store 4 bytes each of Header CRC and Payload CRC in that order after the SOME / IP message.

[0058] The Header CRC allows for the detection of invalid data before it is read by the SOME / IP conversion unit 103. Additionally, the Payload CRC determines whether the data is valid and usable by the application.

[0059] If the Payload CRC determines that there is an error in the data, two actions are possible (Figures 9 and 10). This section explains how to handle errors detected by the Payload CRC.

[0060] Figure 9 is a flowchart of the process for notifying the app when a Payload CRC error is detected.

[0061] Step 501: First, detect the completion of processing on the first core side. The microcontroller used in this embodiment has an interrupt handling function that notifies when the processing result has been stored in the shared memory 9 and storage is complete, so the completion of processing is detected by this interrupt. Various methods can be used to implement the detection of processing completion.

[0062] Step 502: Once the completion of processing on the first core side is detected in step 501, the SOME / IP data and CRC data are retrieved from shared memory 9. The data consists of a SOME / IP header with 16 bytes from the starting address. Since the Payload is variable-length data, the length of the Payload is calculated based on the data recorded in Length included in the Header. In this embodiment, the CRC consists of a fixed-length 4-byte Header CRC and a fixed-length 4-byte Payload CRC stored immediately after the Payload. Therefore, the 8 bytes immediately following the Payload are retrieved as the CRC and separated into a 4-byte Header CRC and a 4-byte Payload CRC.

[0063] Step 503: Perform a CRC check using the SOME / IP and Header CRC retrieved in Step 502. The header of the SOME / IP message has a fixed length of 16 bytes at the beginning, and the CRC is calculated based on this 16-byte data. After calculating the CRC, compare its value with the Header CRC retrieved simultaneously with the SOME / IP message from shared memory. Store a flag to determine the result, such as "1" if the two values ​​match, and "0" if they do not match.

[0064] Step 504: If the result of Step 503 is "1", indicating a match, proceed to Step 506. If the result of Step 503 is "0", indicating a mismatch, proceed to Step 505.

[0065] Step 505: Since an abnormality was determined in the SOME / IP header in Step 504, the SOME / IP data cannot be read correctly, and the received SOME / IP message is discarded. After discarding, the process ends without any further processing.

[0066] Step 506: Since it was determined in Step 504 that there were no abnormalities in the SOME / IP Header, a CRC check is performed on the SOME / IP Payload. The Payload portion of the SOME / IP message is read based on the data recorded in the Length included in the Header information, and the CRC is calculated based on the read Payload. After calculating the CRC, it is compared with the Payload CRC retrieved from shared memory along with the SOME / IP message, and a flag is stored to determine the result, such as "1" if the two values ​​match, and "0" if they do not match.

[0067] Step 507: If the result of Step 506 is "1", indicating a match, proceed to Step 509. If the result of Step 506 is "0", indicating a mismatch, proceed to Step 508.

[0068] Step 508: If an abnormality is determined in Step 507, the status of "unavailable" is overwritten on the Payload portion of SOME / IP. Since the length of the Payload is determined at this point, a numerical value indicating the error is written to the data length of the Payload as the "unavailable" status. Note that the numerical value indicating the error may be written to a part of the Payload (for example, a predetermined length from the beginning).

[0069] Step 509: The SOME / IP Header extracted in Step 502 and the Payload read in Step 506 based on the determination result in Step 507, or the Payload overwritten with the numerical value indicating an error in Step 508, are transferred to the application. The data transferred to the application consists only of the SOME / IP message, which is a combination of the SOME / IP Header and Payload; the CRC is discarded as it does not need to be transferred.

[0070] This embodiment allows the application to be notified that the data is unavailable if there is an anomaly in the Payload data.

[0071] Additionally, if there is an error in the CRC of the payload, you may request a retransmission.

[0072] Figure 10 is a flowchart of the process for requesting retransmission when a Payload CRC error is detected.

[0073] In the process shown in Figure 10, steps 501 to 507 and step 509 are the same as the process shown in Figure 9.

[0074] Step 601: If an abnormality is detected in the Payload in Step 507, a retransmission request is sent to the first core. Various methods can be used to implement the retransmission request. After the retransmission request, the process terminates without transferring data to the application.

[0075] In the process shown in Figure 10, if there is an abnormality in the payload, a request can be made to the first core to resend the data.

[0076] Furthermore, by adding two CRCs, one for the header and one for the payload, the reliability of SOME / IP messages is enhanced. In addition, if an anomaly occurs, it becomes possible to detect which part of the SOME / IP message is incorrect, and to perform appropriate actions for the cause of the anomaly, such as discarding the frame, notifying the application of its unavailability, or requesting retransmission.

[0077] <Example 3> Figure 11 shows the surrounding configuration of the second SOME / IP conversion unit 103 included in the second core 3 of Example 3.

[0078] In Examples 1 and 2, the second SOME / IP conversion unit 103 of the second core 3 can be configured using pre-implemented SOME / IP processing functions and does not need to be newly created for these embodiments. The implementation method of the second SOME / IP conversion unit 103 varies depending on the core specifications, but the input and output conform to the SOME / IP standard. Therefore, SOME / IP messages transferred from the shared memory 9 through the CRC calculation unit 701 and SOME / IP messages transferred via the normal Ethernet receiver 702 require the same interface and can be processed by the same second SOME / IP conversion unit 103.

[0079] SOME / IP messages transmitted via Ethernet are SOME / IP messages included in the payload portion of an Ethernet frame, and when received by the second SOME / IP conversion unit 103, the header information used by protocols such as Ethernet, IP, and TCP is removed. Furthermore, "identical interface" means that SOME / IP messages received from shared memory 9 and SOME / IP messages received from Ethernet are handled in the same way, and the arguments and output methods used by the second SOME / IP conversion unit 103 are identical.

[0080] This configuration helps to suppress complexity. By suppressing complexity, the maintainability of the software is improved, and when problems occur, debugging becomes easier.

[0081] <Example 4> In this embodiment, the CAN data received by the first core 2 is not always guaranteed to be correct. Missing values ​​may occur if there is an anomaly at the data source. The CAN standard does not include a process for retransmitting data when missing values ​​occur. Therefore, if missing values ​​occur, the application may not be able to process them correctly. To address this, the first SOME / IP conversion unit 102 is equipped with a function to interpolate data. Missing values ​​can be detected based on the data transmitted in the CAN frame. While the application can handle the detection of missing values, in this embodiment, processing for missing values ​​is performed before the application does.

[0082] Figure 12 shows a method for imputing missing values ​​in continuous data.

[0083] If, in the actually received consecutive values ​​801a, 801b, 801c, and 801d, a missing value occurs in the third position between value 801b and value 801c, the missing value is imputed with data 802 that conforms to the application's specifications (for example, a value 802 calculated from the preceding and succeeding values ​​so as not to affect the application's operation).

[0084] Figure 13 is a flowchart of the data imputation process that fills in missing data in continuous data.

[0085] Step 901: Receive CAN data. Register the CAN ID of the ECU that receives CAN data, and when a CAN signal with the specified ID arrives, receive the CAN data.

[0086] Step 902: Check the ID and data fields of the received CAN data to determine the data type and whether there are any missing values. A CAN frame's data field may contain multiple data points, and the delimiters for each data point are statically defined by byte positions, etc. A byte position indicates the starting position of the data contained in the data field within the CAN frame, and the contents of a frame transmitted via CAN are statically defined.

[0087] Step 903: If the received CAN data indicates missing values, proceed to step 904. If the received CAN data indicates no missing values, proceed to step 905.

[0088] Step 904: If data is missing, determine whether the received CAN data is continuous or discrete based on its ID. If it is continuous, overwrite the value in the CAN data field with a value calculated from the preceding and succeeding values ​​(for example, the average of the previous and next values, or a value calculated from the previous and next values ​​using an approximation function), and proceed to Step 905.

[0089] Step 905: Create a SOME / IP message based on the data received from Step 903 or Step 904. Create a header based on the ID from the received CAN data and store the values ​​of the data fields in the Payload. The processing does not change depending on the data received.

[0090] By implementing it in this way, when the received data is continuous data such as physical values, it becomes possible to add data to fill in any missing data.

[0091] Furthermore, the case where the data being transferred is discrete must also be considered.

[0092] Figure 14 shows a method for imputing missing values ​​in discrete data.

[0093] If, in the actually received discrete values ​​1001a, 1001b, 1001c, and 1001d, a missing value occurs in the third position between values ​​1001b and 1001c, the missing value is imputed with data 1002 that conforms to the application's specifications (for example, data 1002 that replicates the previous value so as not to affect the application's operation).

[0094] Figure 15 is a flowchart of the data imputation process that fills in missing data in discrete data.

[0095] In the process shown in Figure 15, steps 901 to 903 and step 905 are the same as the process shown in Figure 13.

[0096] Step 1101: If data is missing, determine whether it is a continuous or discrete value based on the ID of the received CAN data. If it is a discrete value, overwrite the value in the CAN data field with the data duplicated from the previous value, and proceed to Step 905.

[0097] Since the aforementioned completion methods are implemented in a way that does not affect the application, effective completion is not always guaranteed. However, this allows the data to be processed as normal data without requiring any special processing on the application side.

[0098] <Example 5> Normally, SOME / IP searches for and uses services on the in-vehicle network, and requires an initial reception request, making one-way data transmission impossible. In this embodiment, a receiving mechanism is needed to send a SOME / IP message created from the received CAN data to the second core 3, regardless of whether a reception request has been made. Two methods described later are proposed in this embodiment.

[0099] Figure 16 shows the configuration around the second SOME / IP conversion unit 103 included in the second core 3 of Example 5.

[0100] First, the CRC calculation unit 701 reads the SOME / IP message and CRC data from the shared memory 9. Based on the retrieved data, it performs error checking using the Header CRC and Payload CRC described in the above embodiment. After confirming that there are no abnormalities in the data using CRC, the SOME / IP message is stored in the buffer 1201.

[0101] Next, when the second SOME / IP conversion unit 103 receives a reception request 1203 from the application 1202, it determines whether data is stored in the buffer 1201. If it determines that data is stored, the second SOME / IP conversion unit 103 deserializes the data stored in the buffer 1201 and transfers it to the application 1202.

[0102] In this embodiment, since the SOME / IP message read from the shared memory 9 cannot be immediately transferred to the application 1201, a SOME / IP message receiving mechanism is provided to temporarily store it in a buffer 1201.

[0103] Buffer 1201 is an area for temporarily storing data, absorbing the difference in processing speed between preceding and succeeding processing units. Buffer 1201 has a defined size. To define the size, it is necessary to know the length of data that buffer 1201 will handle. When defined statically, the buffer size should be greater than or equal to the maximum size of a single SOME / IP message. In this embodiment, the maximum size of a SOME / IP message should be 1460 bytes, which is the maximum amount of data that can be transferred over Ethernet minus the amount of data required for Ethernet, IP, and TCP headers.

[0104] In this embodiment, the SOME / IP message stored in buffer 1201 is variable-length data, so memory for the buffer may be allocated dynamically. This has the advantage of saving memory usage for storing variable-length data.

[0105] The allocation of memory for buffer 1201 can be implemented in various ways.

[0106] Furthermore, buffer 1201 can take various forms, such as queues and ring buffers. A queue, also known as a FIFO, is a buffer structure where data registered first is retrieved first. Because data is stored in an orderly manner, data entered later is not processed first. A ring buffer, also known as a circular buffer, has a circular structure. When reading from the beginning, the buffer is structured so that the data immediately following the end becomes the first data to be accessed next time. In a ring buffer, the oldest content is updated first.

[0107] Deserialization is the process of converting data, which is serialized as a sequence of bytes, into parallel data in a format that can be used by an application. Conversely, serialization can convert parallel data received from an application back into serial data arranged as a sequence of bytes.

[0108] A byte sequence is a sequence of data that does not have a specific format, and as such, it cannot be used by applications. Deserialization creates a data structure from the byte sequence and converts it into a data format that is easy for applications to handle.

[0109] By providing buffer 1201 in this way, the application can retrieve data at any time it chooses.

[0110] Figure 17 shows another configuration around the second SOME / IP conversion unit 103 included in the second core 3 of Embodiment 5. In the embodiment shown in Figure 17, an application buffer 1301 is provided within the application 1202.

[0111] First, the CRC calculation unit 701 reads the SOME / IP message and CRC data from the shared memory 9. Based on the retrieved data, it performs error checking using the Header CRC and Payload CRC described in the above embodiment. After confirming that there are no abnormalities in the data using the CRC, it sends the SOME / IP message to the second SOME / IP conversion unit 103.

[0112] Next, the second SOME / IP conversion unit 103 converts the data into a format usable by the application and then stores the data in the application buffer 1301 within the application 1202. The application 1202 determines at predetermined timings (for example, at predetermined time intervals) whether data has been stored in the application buffer 1301. If it is determined that data has been stored, the data reception function puts the application 1202 into a reception waiting state and receives the data from the application buffer 1301.

[0113] By configuring the system to include an application buffer 1301, which is a memory area managed by application 1202, data can be transferred without the need for extra buffers, thus saving resources.

[0114] As described above, according to the embodiment of the present invention, the CRC calculated when communicating between cores using SOME / IP messages is transferred simultaneously with SOME / IP via shared memory, thereby ensuring the reliability of data transfer while enabling high-speed transfer of large amounts of data.

[0115] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail to make the present invention easier to understand, and the present invention is not necessarily limited to having all of the described configurations. Furthermore, some of the configurations of one embodiment may be replaced with those of another embodiment. Furthermore, configurations of other embodiments may be added to the configuration of one embodiment. Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with those of other embodiments.

[0116] Furthermore, each of the aforementioned configurations, functions, processing units, and processing means may be implemented in hardware, for example, by designing them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each function.

[0117] Information such as programs, tables, and files that implement each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other storage media such as IC cards, SD cards, and DVDs.

[0118] Furthermore, the control lines and information lines shown are those deemed necessary for explanation purposes and do not necessarily represent all control lines and information lines required for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0119] 1 Multicore microcontroller 2. First Core 3. Second Core 4. First Core RAM 5. Second Core RAM 6. First Core Non-Volatile Memory 7. Second Core Non-Volatile Memory 8. Communication Controller 9. Shared memory 10 Internal bus 11 CAN transceiver 12 LAN 13 CAN controller 14 Ethernet switches 15 CAN bus 16 other ECUs 101 Receiving Unit 102 First SOME / IP Conversion Unit 103 Second SOME / IP Conversion Unit 201 CAN data field 201a CAN actual data 211 CAN FD data field 211a-b CAN FD actual data 301 SOME / IP Header Information 302 SOME / IP Payload 701 CRC calculation section 702 Ethernet Receiver 1201 buffer 1202 Application 1203 Reception request 1301 Application Buffer

Claims

1. An electronic control device, A first processor core that receives data via CAN communication, The second processor core on which the application runs, The system comprises a shared memory accessible by the first processor core and the second processor core, The first processor core is It has a first SOME / IP conversion unit that converts data received via CAN communication into SOME / IP messages, The SOME / IP message converted by the first SOME / IP conversion unit is stored in the shared memory. The second processor core is It has a second SOME / IP conversion unit that converts SOME / IP messages into a format usable by the application, The SOME / IP message stored in the shared memory is retrieved. An electronic control device characterized in that the second SOME / IP conversion unit converts the acquired SOME / IP message into a format usable by the application and provides it to the application.

2. The electronic control device according to claim 1, The first processor core calculates an error detection code based on the SOME / IP message converted by the first SOME / IP conversion unit. An electronic control device characterized by associating the calculated error detection code with a SOME / IP message and storing it in the shared memory.

3. The electronic control device according to claim 2, The electronic control device is characterized in that the first processor core calculates an error detection code from the header of the SOME / IP message and stores the calculated error detection code in the shared memory.

4. The electronic control device according to claim 2, The electronic control device is characterized in that the first processor core calculates an error detection code from the payload of the SOME / IP message and stores the calculated error detection code in the shared memory.

5. The electronic control device according to claim 4, The electronic control device is characterized in that, when the second processor core detects an abnormality in the SOME / IP message using an error detection code obtained from the shared memory, it writes data indicating that the SOME / IP message is unavailable to the SOME / IP message.

6. The electronic control device according to claim 4, The electronic control device is characterized in that, when the second processor core detects an abnormality in the SOME / IP message using an error detection code obtained from the shared memory, it requests the first processor core to retransmit the SOME / IP message.

7. The electronic control device according to claim 1, The electronic control device is characterized in that the second SOME / IP conversion unit can convert both SOME / IP messages acquired from the shared memory and SOME / IP messages transferred from other ECUs via Ethernet and provide them to the application.

8. The electronic control device according to claim 1, The first SOME / IP conversion unit is an electronic control device characterized by combining multiple CAN data received via CAN communication and converting them into a single SOME / IP message.

9. The electronic control device according to claim 1, The first SOME / IP conversion unit is an electronic control device characterized by filling in missing values ​​with values ​​calculated from preceding and succeeding data when data received via CAN communication is missing.

10. The electronic control device according to claim 1, The first SOME / IP conversion unit is an electronic control device characterized by duplicating the previous value and filling in the missing value when data received via CAN communication is missing.

11. The electronic control device according to claim 1, The electronic control device is characterized in that the second processor core has a mechanism for receiving SOME / IP messages stored in the shared memory.

12. An electronic control device according to claim 11, The electronic control device is characterized in that the second processor core has a buffer for storing SOME / IP messages acquired from the shared memory.

13. An electronic control device according to claim 11, The electronic control device is characterized in that the application running on the second processor core has a buffer for storing SOME / IP messages acquired from the shared memory.

14. A method for inter-core communication performed by an electronic control unit, The electronic control unit includes a first processor core that receives data according to the CAN protocol, a second processor core on which an application runs, and a shared memory accessible by the first and second processor cores. The aforementioned inter-core communication method is: The first processor core converts the data received via CAN communication into a SOME / IP message, and stores the converted SOME / IP message in the shared memory. A core-to-core communication method characterized in that the second processor core acquires a SOME / IP message stored in the shared memory, converts the acquired SOME / IP message into a format usable by the application, and provides it to the application.

Images