JP2024070053A - Electronic control apparatus and core-to-core communication method - Google Patents

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

The present invention relates to a data transfer method using the SOME/IP automotive communication standard.

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 into use. Since SOME/IP is a protocol created based on Ethernet (Ethernet is a registered trademark, the same applies below), data is usually transferred via Ethernet. When transferring SOME/IP, data errors are detected in each of the protocols it passes through, Ethernet, IP, and TCP, ensuring the reliability of data transfer.

When transferring SOME/IP messages between different OSs running on multiple cores, sending them over Ethernet results in long processing times for large volumes of data. There is no established method for transferring SOME/IP messages between cores via shared memory. In addition, it is difficult to guarantee the reliability of data transfer that was guaranteed by going via Ethernet.

Ethernet uses a data error detection method called CRC, which ensures the reliability of data transfer. CRC is also used in CAN, and an area for CRC is provided in the frame format. For this reason, these protocols implement CRC in the protocol itself. On the other hand, the SOME/IP message format does not implement values for error detection such as CRC, making it difficult to ensure the reliability of data with SOME/IP messages alone.

The following prior art is included as background art in this technical field. In Patent Document 1 (WO 2020/217202), a message is transmitted between a requesting entity and a providing entity of a service instance using the SOME/IP communication protocol in an on-board communication network of a vehicle. Mutual authentication of the requesting entity and the providing entity is performed taking into account the communication associated with the service instance. This step includes verifying the existence and mutual validity of pre-assigned certificates of the requesting entity and the providing entity 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 at the requesting entity and the providing entity. If the verification of the certificate and the security level is successful, at least one communication 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.

International Publication No. 2020/217202

Multi-core inter-core communication requires a method for transferring large volumes of data at high speed, and it is also important to guarantee the reliability of data transfer. As mentioned above, SOME/IP messages are usually transferred via Ethernet, but using shared memory allows for the transfer of large volumes of data at high speed.

However, by using shared memory and not going through Ethernet, data error detection such as CRC in protocols such as Ethernet, IP, and TCP is not performed, so the reliability of data transfer cannot be guaranteed.

Patent document 1 discloses an improvement to the transmission of data or messages on a vehicle using the SOME/IP communication protocol, but does not address the problems that the present invention aims to solve, such as converting CAN data into SOME/IP messages or using SOME/IP messages to realize communication between cores of different OSs, nor does it improve the reliability of the SOME/IP protocol.

In addition, when receiving data transferred via CAN and transferring it between cores, the receiving core needs to perform service conversion to make the data usable by the application. S2S (signal to service), which performs this type of processing, has the problem of being slow. When using the SOME/IP protocol, there is no need to use S2S.

The present invention aims to provide a method for transferring large volumes of data at high speeds while ensuring the reliability of data transfer in inter-core communication using shared memory.

A representative example of the invention disclosed in the present application is as follows. That is, an electronic control device includes a first processor core that receives data via CAN communication, a second processor core on which an application runs, and a shared memory accessible to the first processor core and the second processor core, 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, the second processor core has a second SOME/IP conversion unit that converts the SOME/IP message into a format usable by the application, and acquires the SOME/IP message stored in the shared memory, converts the acquired SOME/IP message into a format usable by the application in the second SOME/IP conversion unit, and provides the message to the application.

According to one aspect of the present invention, large volumes of data can be transferred at high speeds while ensuring the reliability of data transfers in inter-core communication using shared memory. Problems, configurations, and effects other than those described above will become clear from the description of the following embodiment.

FIG. 1 is a diagram illustrating a configuration of a multi-core microcomputer according to a first embodiment. FIG. 2 is a diagram showing a configuration of an ECU according to the first embodiment. FIG. 2 is a block diagram showing a process executed by each core in the first embodiment. FIG. 2 is a diagram showing frame formats of CAN and CAN FD in the first embodiment. FIG. 2 is a diagram showing a message format of SOME/IP in the first embodiment. FIG. 13 is a diagram showing a SOME/IP message created using the CAN data of the first embodiment. FIG. 11 is a diagram showing a CRC value added to a SOME/IP message in the second embodiment. FIG. 11 is a diagram illustrating a CRC calculation process according to the second embodiment. 13 is a flowchart of a process of notifying an application when a payload CRC error is detected according to the second embodiment. 13 is a flowchart of a process for requesting retransmission when a Payload CRC error is detected in the second embodiment. FIG. 13 is a diagram illustrating the peripheral configuration of a second SOME/IP conversion unit according to the third embodiment. FIG. 13 is a diagram showing a method for complementing missing values occurring in continuous data in Example 4. 13 is a flowchart of a data complementation process for complementing a loss occurring in continuous data according to a fourth embodiment. FIG. 13 is a diagram showing a method for complementing missing values occurring in discrete data in Example 4. 13 is a flowchart of a data complementation process for complementing a loss occurring in discrete data according to the fourth embodiment. FIG. 13 is a diagram showing the peripheral configuration of a second SOME/IP conversion unit according to a fifth embodiment. FIG. 13 is a diagram showing another configuration of the periphery of the second SOME/IP conversion unit of the fifth embodiment.

Example 1
1 is a diagram showing the configuration of a multi-core microcomputer 1. The multi-core microcomputer 1 of this embodiment has 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 referenced by the first core 2 and the second core 3. In addition, each component is connected via an internal bus 10.

The multi-core microcomputer 1 is a microcomputer equipped with two or more cores. A microcomputer with one core is called a single-core microcomputer. There are two ways to improve the performance of a microcomputer: increasing the operating frequency of the cores in the microcomputer to increase processing speed, or simply increasing the number of cores in the microcomputer used for processing. Increasing the operating frequency increases power consumption, but with a multi-core microcomputer, performance can be improved and power consumption can be reduced even at a low operating frequency. In this embodiment, a two-core microcomputer will be used for explanation.

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

The first core RAM 4 is a working main memory used by the first core 2 when executing processes. The second core RAM 5 is a working main memory used by the second core 3 when executing processes. It is made up of a volatile memory device, and the data being used is erased when the microcomputer is turned off.

The internal bus is a transmission path that connects the internal circuits of the multi-core microcontroller 1.

The multi-core microcomputer 1 is implemented in an electronic control unit (ECU) installed in a vehicle. The ECU controls the engine, power steering device, controlled brake device, and other on-board equipment.

Figure 2 is a diagram showing the configuration of the ECU 10. In addition to the multi-core microcomputer 1 described in Figure 1, the ECU 10 has a CAN transceiver 11 that enables communication with the CAN and a LAN port 12 that enables Ethernet connection (Ethernet is a registered trademark, the same applies below). The CAN transceiver 11 is connected to a 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 the LAN 12 via Ethernet are sent to the communication controller 8 of the multi-core microcomputer 1. The communication controller 8 has a CAN controller 13 that handles signals via the CAN and an Ethernet switch 14 that handles signals via the Ethernet.

The CAN bus 15 is a transmission path that transfers data using the CAN protocol, and is composed of two communication lines called CAN High and CAN Low. In CAN, CAN signals of 0 and 1 are transmitted by the difference in voltage applied to these two communication lines. This format can improve noise resistance. Details of the CAN protocol will be described later.

The CAN controller 13 is a module that has the function of receiving necessary data by generating an interrupt and ignoring unnecessary data among the data transferred via the CAN bus 15.

The Ethernet switch 14 is an abbreviation for Ethernet Switch, and is a module that controls the transfer destination of Ethernet data received from the LAN port 12. The Ethernet switch 14 controls the transfer destination of data based on information such as the sender and destination contained in the data transferred via Ethernet.

Figure 3 is a block diagram showing the processing executed by each core. The multi-core microcomputer 1 has a first core 2 having a receiver 101 for receiving CAN data (described later), a second core 3 for using the data received by the first core 2, and a shared memory 9 for enabling data transfer between the two cores 2, 3. In this embodiment, the receiver 101 mounted on the first core 2 receives CAN data from another ECU 16, and a first SOME/IP converter 102 extracts 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, a second SOME/IP converter 103 performs service conversion to enable data transfer to an application.

The shared memory 9 is a RAM area that can be referenced by any of the multiple cores. By using the shared memory 9, data can be transferred to different cores without going through an external communication path.

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

Data transferred via CAN is defined in frame units, and one frame of CAN data contains various information such as an ID for identifying the frame transferred via CAN. Of the data contained in the frame, the data actually used for control by applications, etc. is stored in an area called the data field, and is transferred in the range of 0-8 bytes. The CAN frame format will be described later. There is also a protocol called CAN FD, which is an extension of CAN. CAN FD is a communications protocol developed in response to the increase in automotive functionality, and can transfer larger amounts of data at higher speeds than CAN. The data field of a frame transferred using the CAN FD protocol stores data in the range of 0-64 bytes. The CAN FD frame format will be described later.

A protocol is a communication format or procedure agreed upon for exchanging data on a computer, and by following the agreed upon protocol, parts from different manufacturers can communicate with each other.

SOME/IP is a protocol created based on Ethernet to realize the concept of SOA (described later) on an in-vehicle network, and is classified as a higher layer in the OSI reference model (described later). In SOME/IP, the functions and processing of in-vehicle applications are defined on a service-by-service basis, and when using these services, the services are searched for on the in-vehicle network. If the ECU searching for a service is considered the client and the ECU providing the service is considered the server, the server that provides the searched service notifies the client that the service is available. After 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 when the value is changed.

SOA stands for Service Oriented Architecture, and is a concept used when building computer systems. In SOA, application functions are modularized into service units, allowing services to be used from outside the application. Systems can be built and implemented by combining modularized services.

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 Layer 6: Presentation layer Layer 5: Session layer Layer 4: Transport layer Layer 3: Network layer Layer 2: Data link layer Layer 1: Physical layer

The higher the layer, the more software configuration is required, and the lower the layer, the more hardware configuration is required. For example, in Ethernet, the physical layer is the connection port where a LAN cable is inserted. The data link layer is the layer that receives Ethernet frames. The network layer and transport layer are TCP and IP that are carried on Ethernet. Although they are classified in this way, SOME/IP is a protocol that encompasses everything from the session layer to the application layer. In this way, there are also protocols that span multiple layers; for example, CAN is a protocol that spans the physical layer and data link layer.

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

The actual CAN data that is converted into the SOME/IP message format and used is data 201a, 211a, 211b, etc. stored in the data field of the CAN data. Both CAN and CAN FD can transfer multiple data, but the maximum data value and communication speed are different between the two.

The SOME/IP message format is a data format that can be used with the SOME/IP protocol. A SOME/IP message is defined as a collection of data created according to the SOME/IP message format. The SOME/IP message format is explained below.

5 is a diagram showing the SOME/IP message format. The first SOME/IP converter 113 executes a process of creating a SOME/IP message based on actual data of the CAN. The SOME/IP message format requires the following information:
Service ID
Method ID
Length
Client ID
Session ID
Protocol Version
Interface Version
Message Type
Return Code
Payload

Explain each area.

The Service ID indicates the type of service, which will be described later. The Method ID indicates the type of Method. The Service ID and Method ID are sometimes collectively called the Message ID.

Length is the message length from the Client ID to the Payload.

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.

Protocol Version indicates the protocol version of SOME/IP.

Interface Version indicates the major version of the service interface described below. Message Type indicates the type of SOME/IP message.

Return Code is the return value that indicates whether the request was processed successfully. Payload is the data.

Here, a service is an application provided by each ECU, and a function contained within the application is a method.

A method is one way of thinking when using SOME/IP, and refers to a function contained within a service. Specifically, as explained in the SOME/IP protocol above, an application that requests a service is the client, and an application that provides the service is the server. A service is made up 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 indicates which Method (function) of which service the data was obtained from.

A service interface is an interface for accessing the functionality that provides the service. When using a service in SOME/IP, data is obtained through the service interface.

In the SOME/IP message format described above, the information other than the payload 301 is called the Header, and the payload portion 302 in which the actual CAN data is stored is simply called the Payload.

Figure 6 shows a SOME/IP message created using CAN data. At the SOME/IP creation stage, serialization to the application is not performed, so the actual data can be stored as is as a variable. The first SOME/IP conversion unit creates a header based on the ID included 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 using the CAN data ID, and actual CAN data with different IDs cannot be bundled together in the same SOME/IP packet. The CAN data ID allows the type of CAN data received by the application side to be determined through the SOME/IP message.

SOME/IP is normally a higher-level protocol for data transferred via Ethernet. In this embodiment, by transferring SOME/IP messages via shared memory 9, large volumes of data can be communicated between cores at higher speeds than via Ethernet. In addition, by converting to SOME/IP on the first core side, data can be used by two cores even between cores with different language environments, improving the convenience of data usage.

Example 2
In this embodiment, a CRC is calculated and stored in the shared memory 9 together with the created SOME/IP message. The CRC is also called a cyclic redundancy check, and is one of the data error detection codes. The CRC is also used in CAN frames and Ethernet frames, and the CAN and Ethernet frames contain a CRC value. The CRC value is calculated based on the information contained in the frame, and the added CRC value is checked when the frame is received. However, since the CRC field is not defined in the SOME/IP message format, error detection is not possible in the SOME/IP alone. As described above, the SOME/IP is a protocol created on the assumption that it is usually sent via the Ethernet, and error detection is performed in each protocol, such as Ethernet, IP, and TCP, through which the SOME/IP passes before reaching the application. Therefore, when the created SOME/IP message is transferred via the shared memory 9, the reliability of the data can be guaranteed by performing a similar error detection. Therefore, in this embodiment, since the SOME/IP message does not include a CRC value (if a CRC value were included, it would differ from the SOME/IP message format and would therefore be unreceivable), a CRC value calculated separately from the created SOME/IP message is stored in shared memory 9.

Figure 7 shows the CRC value added to the SOME/IP message. In this embodiment, two CRCs are added 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 stored in a subsequent address of the created SOME/IP message, and the CRC is added to the SOME/IP message by associating the CRC with 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 transferred data, and to distinguish whether the error is in the Header or the Payload.

The CRC calculation process in this embodiment will be explained with reference to Figure 8.

Step 401: After the first core 2 receives the 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.

Step 402: Calculate the CRC based on the first 16 bytes of the Header information of the SOME/IP message created in step 401. In this embodiment, the Header CRC has a fixed length of 4 bytes.

Step 403: Calculate the CRC based on the payload information after the first 16 bytes of the SOME/IP message created in step 401. In this embodiment, the payload CRC has a fixed length of 4 bytes and does not change depending on the data length of the payload.

Step 404: The created SOME/IP message is stored in shared memory, and the Header CRC and Payload CRC are stored 4 bytes after the SOME/IP message, in that order.

The Header CRC makes it possible to detect invalid data before it is read by the SOME/IP conversion unit 103. In addition, the Payload CRC makes it possible to determine whether the data is valid and can be used by the application.

If the payload CRC determines that there is an error in the data, two processing options (Figures 9 and 10) are available. We will explain how to handle an error detected by the payload CRC.

Figure 9 is a flowchart of the process for notifying the app when a payload CRC error is detected.

Step 501: First, detect the completion of processing on the first core side. The microcomputer used in this embodiment has an interrupt processing function that notifies the completion of storage after the processing result is stored in the shared memory 9, so the completion of processing is detected by this interrupt. Various methods can be adopted as a method for implementing the detection of the completion of processing.

Step 502: When completion of processing on the first core side is detected in step 501, the SOME/IP data and CRC data are extracted from the shared memory 9. The data consists of 16 bytes from the first address that constitute the SOME/IP Header. Since the Payload is variable length data, the length of the Payload is calculated based on the data recorded in the Length included in the Header. Also, in this embodiment, the CRC consists of a 4-byte fixed-length Header CRC and a 4-byte fixed-length Payload CRC that are stored immediately after the Payload, so the 8 bytes immediately after the Payload are extracted as the CRC and separated into a 4-byte Header CRC and a 4-byte Payload CRC.

Step 503: A CRC check is performed using the SOME/IP and Header CRC extracted in step 502. The Header of the SOME/IP message has a fixed length of the first 16 bytes, and the CRC is calculated based on these 16 bytes of data. Once the CRC has been calculated, the value is compared with the Header CRC extracted from the shared memory at the same time as the SOME/IP message, and a flag is stored to determine the result, such as "1" if the two values match, or "0" if they do not match.

Step 504: If the result of step 503 is "1" indicating a match, transition to step 506. If the result of step 503 is "0" indicating a mismatch, transition to step 505.

Step 505: Since it was determined in step 504 that there is an abnormality in the SOME/IP header, the SOME/IP data cannot be read correctly, so the received SOME/IP message is discarded. After discarding, the process ends without performing any special processing.

Step 506: Since it was determined in step 504 that there was no abnormality 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. Once the CRC is calculated, it is compared with the payload CRC retrieved from the shared memory at the same time as the SOME/IP message, and a flag is stored to determine the result, such as "1" if the two values match, or "0" if they do not match.

Step 507: If the result of step 506 is "1" indicating a match, transition to step 509. If the result of step 506 is "0" indicating a mismatch, transition to step 508.

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

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

With this embodiment, if there is an abnormality in the payload data, the application can be notified that the data is unavailable.

If there is an error in the CRC of the payload, a retransmission may be requested.

Figure 10 is a flowchart of the process for requesting retransmission when a payload CRC error is detected.

In the process shown in FIG. 10, steps 501 to 507 and step 509 are the same as the process shown in FIG. 9.

Step 601: If it is determined in step 507 that there is an abnormality in the payload, a retransmission is requested to the first core. Various methods can be used to implement the retransmission request. After the retransmission request, the process ends without transferring the data to the application.

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.

Adding two CRCs, one for the header and one for the payload, increases the reliability of the SOME/IP message and, if an abnormality occurs, makes it possible to detect which part of the SOME/IP message is in error, allowing appropriate processing to be performed depending on the cause of the abnormality, such as discarding the frame, notifying the application that it is unavailable, or requesting a resend.

Example 3
FIG. 11 is a diagram showing a configuration around the second SOME/IP conversion unit 103 included in the second core 3 of the third embodiment.

In the first and second embodiments, 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 this embodiment. The implementation method of the second SOME/IP conversion unit 103 varies depending on the core specifications, but the input and output comply with the SOME/IP standards. Therefore, the SOME/IP message transferred from the shared memory 9 through the CRC calculation unit 701 and the SOME/IP message transferred via the normal Ethernet receiving unit 702 require the same interface and can be processed by the same second SOME/IP conversion unit 103.

A SOME/IP message transferred via Ethernet is a SOME/IP message included in the payload portion of an Ethernet frame, and has header information used in protocols such as Ethernet, IP, and TCP deleted when it is received by the second SOME/IP conversion unit 103. In addition, the same interface means that the SOME/IP message received from the shared memory 9 and the SOME/IP message received from the Ethernet are handled in the same way, and the arguments and output method used by the second SOME/IP conversion unit 103 are the same.

By configuring in this way, we can prevent the configuration from becoming too complicated. By preventing the configuration from becoming too complicated, we can improve the maintainability of the software and make it easier to debug when a problem occurs.

Example 4
In this embodiment, the CAN data received by the first core 2 is not necessarily a correct value. Missing values may occur when an abnormality occurs at the data transmission source. The CAN standard does not provide for a process to resend a missing value. Therefore, when a missing value occurs, there is a possibility that the application cannot process it correctly. Therefore, in order to deal with such cases, the first SOME/IP conversion unit 102 is provided with a function to complement data. Missing values can be detected based on data transferred in CAN frames. When a missing value is detected, it can be handled by the application, but in this embodiment, processing for the missing value is performed before the application.

Figure 12 shows how to complement missing values in continuous data.

When a missing value occurs at the third value between values 801b and 801c among the consecutive values 801a, 801b, 801c, and 801d actually received, the missing value is complemented with data 802 that matches the application specifications (for example, value 802 calculated from the previous and next values so as not to affect the operation of the application).

Figure 13 is a flowchart of the data completion process that complements missing data in continuous data.

Step 901: Receive CAN data. The CAN ID of the ECU that will receive the CAN data is registered, and when a CAN signal with the specified ID arrives, the CAN data is received.

Step 902: Check the ID and data field of the received CAN data to determine the type of data and whether or not there are missing values. The data field of a CAN frame may contain multiple pieces of data, and the delimiters for each piece of data are statically defined by byte positions, etc. The byte position indicates the starting position of the data contained in the data field in the CAN frame, and the contents of the frames transferred by CAN are statically defined.

Step 903: If the received CAN data indicates a missing value, proceed to step 904. If the received CAN data indicates no missing value, proceed to step 905.

Step 904: If data is missing, determine whether the value is continuous or discrete based on the ID of the received CAN data. If it is continuous, rewrite the value in the CAN data field with a value calculated from the previous and next values (e.g., the average value 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.

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 value of the data field in Payload. The process does not change depending on the data received.

By implementing it in this way, when the received data is continuous data such as physical values, it becomes possible to add data to complement missing data.

It is also necessary to consider the case where the data being transferred is a discrete value.

Figure 14 shows how to complement missing values in discrete data.

When a missing value occurs at the third position between values 1001b and 1001c among the actually received discrete values 1001a, 1001b, 1001c, the missing value is complemented with data 1002 that matches the application specifications (for example, data 1002 that is a copy of the previous value so as not to affect the operation of the application).

Figure 15 is a flowchart of the data completion process that complements missing data.

In the process shown in FIG. 15, steps 901 to 903 and step 905 are the same as the process shown in FIG. 13.

Step 1101: If data is missing, determine whether the value is continuous or discrete based on the ID of the received CAN data. If it is discrete, rewrite the value in the CAN data field with data that is a duplicate of the previous value, and proceed to step 905.

All of the above mentioned completion methods are implemented to the extent that they do not affect the app, so they may not always provide effective completion. However, this allows the data to be processed as normal data without the application having to perform any special processing.

Example 5
Normally, SOME/IP searches for and uses services on the in-vehicle network, and since a receive request must be made first, one-way data transmission is not possible. In this embodiment, a receiving mechanism is required to send a SOME/IP message created from the received CAN data to the second core 3 side, regardless of the receive request. In this embodiment, two methods are proposed, which will be described later.

Figure 16 is a diagram showing the peripheral configuration of the second SOME/IP conversion unit 103 included in the second core 3 of the fifth embodiment.

First, the CRC calculation unit 701 reads the SOME/IP message and CRC data from the shared memory 9. Based on the extracted data, an error check is performed using the Header CRC and Payload CRC described in the previous embodiment. After confirming that there are no abnormalities in the data using the CRC, the SOME/IP message is stored in the buffer 1201.

Next, when the second SOME/IP conversion unit 103 receives a receive 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.

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 that temporarily stores the message in the buffer 1201.

Buffer 1201 is an area that temporarily stores data, and absorbs differences in the processing speed of the preceding and following processing units. A size is defined for buffer 1201. In order to define the size, it is necessary to know the data length that buffer 1201 handles. When defining the size statically, the buffer size should be set to be equal to or greater than the maximum size of one SOME/IP message. In this embodiment, the maximum size of a SOME/IP message should be set to 1,460 bytes, which is the maximum amount of data that can be transferred over Ethernet minus the amount of data required for the Ethernet, IP, and TCP headers.

In this embodiment, the SOME/IP messages stored in the buffer 1201 are variable-length data, so memory for the buffer may be dynamically allocated. This has the advantage of saving on the amount of memory used to store variable-length data.

Allocating memory space for buffer 1201 can be implemented in a variety of ways.

Buffer 1201 also comes in various forms, such as a queue or a ring buffer. A queue, also known as a FIFO, is a buffer with a structure in which data that is registered first is retrieved first. Data is stored in an orderly manner, so data input later is not processed first. A ring buffer, also known as a circular buffer, has a cyclic structure. When data is read from the top in order, the data next to the end becomes the top for the next access. In a ring buffer, the oldest contents are updated first.

Deserialization is the process of converting data arranged serially in a byte sequence into parallel data in a format that can be used by an application. Conversely, serialization can convert parallel data received from an application into serial data arranged in a byte sequence.

A byte sequence is a sequence of data without a specific format, and applications cannot use it in this state. Deserialization creates a data structure from the byte sequence and converts it into a data format that is easy for applications to handle.

By providing buffer 1201 in this way, the application can obtain data at any time.

Figure 17 is a diagram showing another configuration of the periphery of the second SOME/IP conversion unit 103 included in the second core 3 of the fifth embodiment. In the aspect shown in Figure 17, an application buffer 1301 is provided in the application 1202.

First, the CRC calculation unit 701 reads the SOME/IP message and CRC data from the shared memory 9. Based on the extracted data, an error check is performed using the Header CRC and Payload CRC described in the previous embodiment. After confirming that there are no abnormalities in the data using the CRC, the SOME/IP message is sent to the second SOME/IP conversion unit 103.

Next, the second SOME/IP conversion unit 103 converts the data into a format that can be used by the application, and then stores the data in the application buffer 1301 in the application 1202. The application 1202 determines whether data is stored in the application buffer 1301 at a predetermined timing (e.g., a predetermined time interval). If it is determined that data is stored, the data reception function puts the application 1202 into a reception standby state, and receives the data from the application buffer 1301.

By providing an application buffer 1301, which is a storage area managed by the application 1202, data can be transferred without providing an unnecessary buffer, thereby saving resources.

As described above, according to an embodiment of the present invention, when communicating between cores using a SOME/IP message, the CRC calculated is transferred via shared memory simultaneously with the SOME/IP, so that large volumes of data can be transferred at high speed while ensuring the reliability of the data transfer.

The present invention is not limited to the above-described embodiments, but includes various modified examples and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to having all of the configurations described. Furthermore, a portion of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, other configurations may be added, deleted, or replaced with part of the configuration of each embodiment.

Furthermore, each of the configurations, functions, processing units, processing means, etc. described above may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, hard disk, or SSD (Solid State Drive), or in a recording medium such as an IC card, SD card, or DVD.

In addition, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily represent all control lines and information lines necessary for implementation. In reality, it is safe to assume that almost all components are interconnected.

1 Multi-core microcomputer 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 switch 15 CAN bus 16 Other ECU
101 Receiving section 102 First SOME/IP conversion section 103 Second SOME/IP conversion section 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 unit 702 Ethernet reception unit 1201 Buffer 1202 Application 1203 Reception request 1301 Application buffer

Claims (14)

An electronic control device,
a first processor core that receives data through CAN communication;
a second processor core on which an application runs;
a shared memory accessible to the first processor core and the second processor core;
The first processor core is
A first SOME/IP conversion unit converts data received through CAN communication into a SOME/IP message;
storing the SOME/IP message converted by the first SOME/IP conversion unit in the shared memory;
The second processor core is
a second SOME/IP converter for converting a SOME/IP message into a format usable by said application;
Obtaining a SOME/IP message stored in the shared memory;
The electronic control device according to claim 1, wherein the second SOME/IP conversion unit converts the acquired SOME/IP message into a format usable by the application and provides the converted message 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;
The electronic control device further comprises: an electronic control unit that stores the calculated error detection code in the shared memory in association with the SOME/IP message. 3. The electronic control device according to claim 2,
The electronic control device according to claim 1, wherein the first processor core calculates an error detection code from a header of the SOME/IP message and stores the calculated error detection code in the shared memory. 3. The electronic control device according to claim 2,
The electronic control device, wherein the first processor core calculates an error detection code from a 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 into the SOME/IP message. 5. The electronic control device according to claim 4,
An electronic control device 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 resend the SOME/IP message. 2. The electronic control device according to claim 1,
The second SOME/IP conversion unit is capable of converting both SOME/IP messages obtained from the shared memory and SOME/IP messages transferred from other ECUs via Ethernet and providing them to the application. 2. The electronic control device according to claim 1,
The electronic control device, wherein the first SOME/IP conversion unit collects a plurality of CAN data received through CAN communication and converts them into one SOME/IP message. 2. The electronic control device according to claim 1,
The electronic control device, wherein when data received via CAN communication is missing, the first SOME/IP conversion unit complements the missing value with a value calculated from previous and following data. 2. The electronic control device according to claim 1,
The electronic control device, wherein the first SOME/IP conversion unit, when data received through CAN communication is missing, replicates a previous value to complement the missing value. 2. The electronic control device according to claim 1,
The electronic control device according to claim 1, wherein the second processor core has a mechanism for receiving a SOME/IP message stored in the shared memory. 12. The electronic control device according to claim 11,
The electronic control device according to claim 1, wherein the second processor core has a buffer for storing a SOME/IP message obtained from the shared memory. The electronic control device according to claim 11,
The electronic control device according to claim 1, wherein the application running on the second processor core has a buffer for storing a SOME/IP message obtained from the shared memory. An inter-core communication method executed by an electronic control device, comprising:
The electronic control device includes a first processor core that receives data according to a CAN protocol, a second processor core on which an application runs, and a shared memory accessible by the first processor core and the second processor core;
The inter-core communication method includes:
The first processor core converts data received through CAN communication into a SOME/IP message and stores the converted SOME/IP message in the shared memory;
An inter-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