WO2023210128A1 - Electronic control device - Google Patents

Abstract

This electronic control device comprises: a calculation processing unit that has an application processing unit which performs application processing; a data storage unit that stores data which is processed by the calculation processing unit; and a peripheral that transmits, to another electronic control device, data which has been read from the data storage unit, or that receives data from another electronic control device. Fixed in advance are a first timing at which the calculation processing unit inputs/outputs data to/from the data storage unit for the application processing, and a second timing at which the calculation processing unit provides, to the peripheral, data that has been read from the data storage unit, and at which the peripheral transmits the data to the other electronic control device.

Description

electronic control unit

The present invention relates to an electronic control device.

As vehicles are now equipped with multiple electronic control units (ECUs), there is a need to reduce the development cost of electronic control units. Therefore, techniques described in Patent Documents 1 and 2 are known to reduce the development cost of electronic control devices. Patent Document 1 states, ``The driver has a plurality of interface sections corresponding to a plurality of application programs and a common processing section that executes instructions from the plurality of application programs, and communication between the plurality of application programs is , under the control of the driver."

Furthermore, Patent Document 2 states that ``data sent in a communication frame from an external bus connected to an external device is regarded as received data, and a message box in which at least the received data is stored; and an internal memory having a plurality of storage areas in which received data transferred via a bus can be written and read.''

Japanese Patent Application Publication No. 2013-062734 Japanese Patent Application Publication No. 2011-250110

In the technology disclosed in Patent Document 1, for an electronic control device loaded with a plurality of application programs, a buffer used by each of the application programs is installed as a component of a driver. This buffer allows each application program to share one peripheral without having to prepare multiple peripherals (for example, CAN (Controller Area Network) controllers and CAN transceivers).

However, when comparing the case where multiple application programs share a peripheral with the case where a plurality of application programs do not share a peripheral, the timing from when each application program generates data until the data reaches the peripheral is different. Therefore, the behavior of the electronic control device (for example, the timing and order of transmission of CAN messages) changes depending on whether a plurality of application programs share a peripheral or not. As a result, costs are required to verify the changed operation of the electronic control device and to redesign the data input/output timing.

In the technology disclosed in Patent Document 2, in a situation where a CPU (Central Processing Unit) performs processing to control a controlled device, a DMA (Direct Memory Access) controller replaces part of the communication processing. It is something. However, generally the processing speed of a CPU and a DMA controller is different. For this reason, when processing conventionally executed by a CPU is replaced with a DMA controller, the scheduling of the CPU, including application processing and communication processing, changes before and after the replacement. As a result, in the technique disclosed in Patent Document 2, similar to the technique disclosed in Patent Document 1, costs are required for verifying the operation of the electronic control device and redesigning the data timing.

The present invention was made in view of this situation, and aims to reduce the cost of developing software programs.

An electronic control device according to the present invention includes an arithmetic processing section having an application processing section that performs application processing, a data storage section that stores data processed by the arithmetic processing section, and a data storage section that stores data read from the data storage section. a peripheral that transmits data to the control device or receives data from another electronic control device; a first timing at which the arithmetic processing unit inputs and outputs data to the data storage unit for application processing; A second timing at which the data read from the data storage unit is passed to the peripheral and the peripheral transmits the data to another electronic control device is fixed in advance.

According to the present invention, since the first and second timings are fixed in advance, it is possible to reduce the cost of developing a software program.
Problems, configurations, and effects other than those described above will be made clear by the following description of the embodiments.

1 is a diagram showing a schematic configuration example of an electronic control device according to a first embodiment of the present invention. FIG. 2 is a block diagram showing an example of the internal configuration of each part of the electronic control device according to the first embodiment of the present invention. FIG. 1 is a block diagram showing an example of the internal configuration of a vehicle control device equipped with an electronic control device according to a first embodiment of the present invention. FIG. 3 is a diagram illustrating a configuration example of camera object detection data according to the first embodiment of the present invention. It is a figure showing pattern 1 of time synchronization of a first electronic control unit (camera ECU) and a second electronic control unit (automatic driving ECU). It is a figure showing pattern 2 of time synchronization of a first electronic control unit (camera ECU) and a second electronic control unit (automatic driving ECU). 3 is a diagram illustrating an example of a change in data flow between electronic control devices time-synchronized in pattern 1. FIG. 7 is a diagram illustrating an example of a change in data flow between electronic control devices time-synchronized in pattern 3. FIG. FIG. 2 is a diagram showing definitions of LET and LCT proposed in Non-Patent Document 1. FIG. 3 is a diagram showing an example of processing time of each electronic control device and communication time of an in-vehicle network. FIG. 2 is a diagram showing an example in which a conventional software architecture is applied to a first electronic control unit (camera ECU). It is a figure which shows the example to which the conventional software architecture is applied in the second electronic control unit (automatic driving|operation ECU). FIG. 9 is a diagram showing an example of mapping the LET and LCT proposed in Non-Patent Document 1 to the modules and tasks shown in FIGS. 8 and 9. FIG. It is a timing chart of communication middleware and an in-vehicle network when transmitting a large amount of data in the first electronic control unit (camera ECU). FIG. 2 is a diagram illustrating an overview of processing by a communication preparation processing unit and a peripheral access unit according to the first embodiment of the present invention, using AUTOSAR as an example. It is a diagram showing software architecture according to the present embodiment in a first electronic control unit (camera ECU). It is a diagram showing the software architecture according to the present embodiment in a second electronic control unit (automatic driving ECU). FIG. 3 is a diagram showing an example in which the LET and LCT according to the first embodiment of the present invention are applied to each module and task according to the present embodiment. 1 is a timing chart comparing the technology according to the first embodiment of the present invention and the technology disclosed in Non-Patent Document 1. It is a diagram showing software architecture in a first electronic control unit (camera ECU) according to a second embodiment of the present invention. It is a diagram showing software architecture in a second electronic control unit (automatic driving ECU) according to a second embodiment of the present invention. FIG. 7 is a diagram showing an example of mapping LET and LCT according to the second embodiment of the present invention to each module and task according to the present embodiment. FIG. 7 is a diagram illustrating a configuration example of a vehicle control device equipped with a third electronic control device (central ECU) according to a third embodiment of the present invention. It is a diagram showing software architecture in a third electronic control unit (central ECU) according to a third embodiment of the present invention.

Hereinafter, embodiments for carrying out the present invention will be described with reference to the accompanying drawings. In this specification and the drawings, components having substantially the same functions or configurations are designated by the same reference numerals and redundant explanations will be omitted.

[First embodiment]
A first embodiment of the present invention, which will be described below, applies the present invention to an electronic control device and a vehicle control device. ). In the first embodiment, a vehicle control device installed in an automatic driving vehicle that controls steering, accelerator, and brakes using image data acquired from a camera is taken as an example, and the electronic control device and vehicle control device are A configuration example and an operation example will be explained. However, the present invention is applicable not only to automatic driving vehicles but also to vehicles that do not perform automatic driving. The present invention is also applicable to a real-time system connected to a network and configured to communicate with other electronic control units (ECUs) inside and outside the vehicle. For example, the electronic control device and vehicle control device according to the first embodiment can be applied to products such as robots, construction machines, autonomous forklifts, etc., in which the CPU is configured with multi-cores and software programs run in real time.

<Example of configuration of electronic control device>
FIG. 1 is a diagram showing a schematic configuration example of an electronic control device according to a first embodiment.
The electronic control device 100 includes a CPU 1, a RAM 2, and peripherals 3.
The CPU 1 is equipped with multiple cores. For the sake of explanation, in this embodiment, it is assumed that there are two cores, and the first core 11 and the second core 12 are included, but the present invention also applies when the CPU 1 is equipped with three or more cores. is applicable.

The peripheral 3 is hardware used to communicate with the outside of the electronic control device 100 (for example, another electronic control device 100), and includes a register 31 therein. The peripheral 3 is specifically hardware such as a CAN controller or a physical layer of Ethernet (registered trademark), and is connected to the in-vehicle network 4. A plurality of electronic control devices (a first electronic control device (camera ECU) 6, a second electronic control device (autonomous driving ECU) 7) shown in FIG. ) allows data communication. The peripheral (peripheral 3) transmits data read from the data storage unit (data storage unit 2A) (see FIG. 2) to another electronic control device, or receives data from another electronic control device.

Communication data is transmitted to the in-vehicle network 4 by the first core 11 or second core 12 of the CPU 1 writing a value to the hardware-specific transmission register 31. Conversely, when the peripheral 3 receives communication data transmitted by another electronic control device 100 from the in-vehicle network 4, the value is written to the hardware-specific reception register 31. This communication data is converted into a format usable by the first core 11 and the second core 12 and stored in the RAM 2. The first core 11 and the second core 12 can read data from the RAM 2 and use it for application processing by an application module (an example of an application program) provided in each core.

<Example of internal configuration of each part of electronic control unit>
FIG. 2 is a block diagram showing an example of the internal configuration of each part of the electronic control device 100 according to the first embodiment.
In the block diagram shown in FIG. 2, a calculation processing section 1A is provided as a functional section corresponding to the first core 11 of the CPU 1 shown in FIG. 1, and a calculation processing section 1B is provided as a functional section corresponding to the second core 12. provided. Further, a data storage section 2A is provided as a functional section corresponding to the RAM 2 shown in FIG. This arithmetic processing section ( arithmetic processing sections 1A, 1B, first core 11, second core 12) has an application processing section (application processing section 22) that performs application processing. In addition, the arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12) prepare for communication of application data generated by application processing with the application processing unit (application processing unit 22). It has a communication preparation processing unit (communication preparation processing unit 201) that performs the communication preparation processing.

The arithmetic processing unit 1A includes an application processing unit 22, a communication preparation processing unit 201, a peripheral access unit 202, and a task activation time management unit 26. Here, at least one arithmetic processing unit (arithmetic processing unit 1A, first core 11) includes a communication data storage unit (communication data storage unit 28) and a peripheral access unit (peripheral access unit) that accesses a peripheral (peripheral 3). 202) and a startup time management section (task startup time management section 26) that manages the startup time for starting up the peripheral access section (peripheral access section 202).

The application processing unit 22 of the arithmetic processing unit 1A performs application processing to realize the functions handled by the arithmetic processing unit 1A. Application data generated by application processing is stored in the application data storage unit 23.

The communication preparation processing unit 201 of the arithmetic processing unit 1A performs communication preparation processing for the electronic control device 100 to communicate with another electronic control device, and stores communication data in the communication data storage unit 28. Further, the communication preparation processing unit 201 reads communication data received from another electronic control device 100 from the communication data storage unit 28, converts it into a format that can be used by the application processing unit 22, and then converts the communication data received from the other electronic control device 100 into a format that can be used by the application processing unit 22. can also be stored in the application data storage section 23.

The peripheral access unit 202 communicates with the communication data storage unit 28 and accesses the peripheral 3 and the communication data storage unit 28 according to the activation instruction input from the task activation time management unit 26.

The task activation time management unit 26 manages the activation time of the peripheral access unit 202 when the activation of the peripheral access unit 202 is set as a task. Then, the startup time management section (task startup time management section 26) operates the application processing section (application processing section 22) at a first timing based on a predetermined internal time, and operates the peripheral access section at a second timing. (Peripheral access unit 202) is operated. As described later, the first timing according to the first embodiment is fixed as the timing at which the application processing unit (application processing unit 22) inputs and outputs data to and from the application data storage unit (application data storage unit 23). Ru. Further, the second timing is fixed as the timing at which the peripheral access unit (peripheral access unit 202) transfers the communication data stored in the communication data storage unit (communication data storage unit 28) to the peripheral (peripheral 3). Further, the internal time is corrected by a time synchronization signal that the electronic control device 100 receives from the outside. Therefore, the internal times of the plurality of electronic control devices 100 are synchronized.

The arithmetic processing unit 1B includes an application processing unit 22 and a communication preparation processing unit 201.
The application processing unit 22 of the arithmetic processing unit 1B performs application processing to realize the functions that the arithmetic processing unit 1B is responsible for. Application data generated by application processing is stored in the application data storage unit 23.
The communication preparation processing section 201 of the arithmetic processing section 1B performs communication preparation processing for the electronic control device 100 to communicate with another electronic control device, and stores communication data in the communication data storage section 28. The processing of the communication preparation processing section 201 of the calculation processing section 1B is similar to the processing of the communication preparation processing section 201 of the calculation processing section 1A.

The data storage unit (data storage unit 2A) stores data processed by the calculation processing units ( calculation processing units 1A, 1B, first core 11, second core 12). This data storage unit (data storage unit 2A) stores communication data generated by an application data storage unit (application data storage unit 23) that stores application data and a communication preparation processing unit (communication preparation processing unit 201). It has a communication data storage section (communication data storage section 28).

The application data storage unit 23 stores application data processed by the application processing units 22 of the calculation processing units 1A and 1B. The application data storage unit (application data storage unit 23) serves as an area where each application processing unit (application processing unit 22) temporarily stores data during application processing. It has a local area (local area 23a) that is used only by the application processing unit 22). The local area 23a is an area provided inside the RAM 2 shown in FIG. The data stored in the local area 23a can be accessed individually only by each application processing section 22, and therefore is not changed by other application processing sections 22.

Further, the application data storage unit (application data storage unit 23) stores data resulting from completion of processing by the application processing unit (application processing unit 22), and transmits the data to other application processing units (application processing unit 22). It has a global area (global area 23b) that is made available for use by the public. The global area 23b is an area provided in the RAM2. The data stored in the global area 23b can be mutually accessed and used by each application processing unit 22. Therefore, the application processing unit (application processing unit 22) accesses the global area (global area 23b) at the first timing. Further, the application data stored in the global area 23b of the application data storage section 23 can be read by the communication preparation processing section 201 of the arithmetic processing section 1A, 1B.

It is possible for the data acquisition task 24 shown in FIGS. 8, 9, 13, and 14, which will be described later, to read data from the local area 23a or the global area 23b. Further, the data publishing task 25 can write data to the global area 23b. Local variables and global variables are distinguished by the compiler, and within the RAM 2, local variables are placed in the local area 23a and global variables are placed in the global area 23b. Which area of the RAM 2 is the local area 23a and which area is the global area 23b depends on the electronic control device 100.

The communication data storage unit 28 stores communication data processed by the communication preparation processing unit 201 of the arithmetic processing units 1A and 1B. The communication data stored in the communication data storage section 28 can be read by the peripheral access section 202.

The peripheral 3 transmits data output from the peripheral access unit 202 at the timing activated by the task activation time management unit 26 to other electronic control devices via the in-vehicle network 4 (hereinafter also referred to as a bus). Further, the peripheral 3 outputs data received from another electronic control device via the in-vehicle network 4 to the peripheral access unit 202. The communication data that the peripheral access unit 202 acquires from the peripheral 3 at the timing of activation by the task activation time management unit 26 is stored in the communication data storage unit 28. After that, the communication preparation processing section 201 of the arithmetic processing section 1A, 1B acquires the communication data from the communication data storage section 28, converts it into data that can be processed by the application processing section 22, and stores it in the global area 23b of the application data storage section 23. save. The application processing units 22 of the arithmetic processing units 1A and 1B read data from the application data storage unit 23 and use it for processing each application.

In the electronic control device 100 according to the first embodiment, the arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12) are stored in a data storage unit (data storage unit) for application processing. The first timing of inputting and outputting data to the storage unit 2A) and the first timing when the calculation processing unit ( processing units 1A, 1B, first core 11, second core 12) read from the data storage unit (data storage unit 2A) The second timing at which the peripheral (peripheral 3) transmits the data to the peripheral (peripheral 3) and the peripheral (peripheral 3) transmits the data to another electronic control device is fixed in advance. The pre-fixed processing timing according to this embodiment will be described below in comparison with the conventional technology.

<Example of internal configuration of vehicle control device>
FIG. 3 is a block diagram showing an example of the internal configuration of a vehicle control device equipped with an electronic control device according to the first embodiment. Here, as electronic control devices installed in the vehicle control device 5, a first electronic control device (camera ECU) 6 and a second electronic control device (automatic driving ECU) 7 are shown as examples.

The vehicle control device 5 includes a first electronic control device (camera ECU) 6, a second electronic control device (automatic driving ECU) 7, a camera 8, a steering wheel 16, an accelerator 17, and a brake 18. A first electronic control unit (camera ECU) 6 and a second electronic control unit (automatic driving ECU) 7 are connected to each other via an in-vehicle network 4. The internal hardware configurations of the first electronic control unit (camera ECU) 6 and the second electronic control unit (automatic driving ECU) 7 are the same as the electronic control unit 100 shown in FIG. 1, respectively.

The camera 8 captures an image in front of the vehicle at a cycle of, for example, 100 milliseconds, and generates camera image data 9 using a known method such as JPEG (Joint Photographic Experts Group). Camera image data 9 generated by the camera 8 is input to a first electronic control unit (camera ECU) 6.

A first electronic control unit (camera ECU) 6 receives camera image data 9 from a camera 8 and generates camera object detection data 10. Here, a configuration example of the camera object detection data 10 will be explained.
FIG. 4 is a diagram showing an example of the configuration of camera object detection data 10.

The camera object detection data 10 includes items such as an object number (identifier), object type, and coordinates.
The number (identifier) item specifies each object detected from the camera image data 9 by the image recognition application modules 221 and 222 (see FIG. 8 described later) included in the first electronic control unit (camera ECU) 6. number will be assigned.
In the object type field, the object type, such as a car or a pedestrian, is stored for each detected object.
Coordinate information in the camera image data 9 of objects detected by the image recognition application modules 221 and 222 is stored in the coordinate item.

The camera image data 9 input to the first electronic control unit (camera ECU) 6 is image data compressed using a known compression format such as JPEG or PNG (Portable Network Graphics), or image data detected by the imaging sensor of the camera 8. It is a numerical string itself, and is generally called raw data. On the other hand, the camera object detection data 10 output from the first electronic control unit (camera ECU) 6 is composed of items such as the number (identifier), object type, and coordinates of the object detected from the camera image data 9. . Therefore, the camera image data 9 is larger in size than the camera object detection data 10, which is about several megabytes.

As shown in FIG. 3, the first electronic control unit (camera ECU) 6 transmits camera object detection data 10 to the second electronic control unit (automatic driving ECU) 7 via the in-vehicle network 4. Since the data size of the camera object detection data 10 is smaller than the camera image data 9, it does not need to occupy the band of the in-vehicle network 4. Note that the internal logic of the first electronic control unit (camera ECU) 6 is not directly related to the present invention, and therefore will not be illustrated.

The second electronic control unit (automatic driving ECU) 7 receives the camera object detection data 10 from the first electronic control unit (camera ECU) 6 at a cycle of, for example, 100 milliseconds. Then, the second electronic control unit (automatic driving ECU) 7 plans the traveling direction (trajectory) of the vehicle based on the camera object detection data 10, and provides a steering control command 13 and an accelerator control command to realize the plan. 14 and a brake control command 15. The steering control command 13 is command data for controlling the operation of the steering wheel 16. The accelerator control command 14 is command data for controlling the operation of the accelerator 17. The brake control command 15 is command data for controlling the operation of the brake 18.

The steering 16 is controlled by the steering control command 13 and changes the direction of travel of the vehicle. The accelerator 17 is controlled by the accelerator control command 14 to accelerate the vehicle. Brake 18 is controlled by brake control command 15 to decelerate the vehicle. Controlling the traveling direction and acceleration/deceleration of the vehicle in this manner is called "vehicle control." Note that the logic for analyzing the camera object detection data 10 in the second electronic control unit (autonomous driving ECU) 7, the logic for generating each control command, and the data format of each control command are not directly related to the present invention. Therefore, an example will be omitted.

<Time synchronization>
Next, time synchronization between the first electronic control unit (camera ECU) 6 and the second electronic control unit (automatic driving ECU) 7 will be explained.
5A and 5B are diagrams showing the necessity of time synchronization between the first electronic control unit (camera ECU) 6 and the second electronic control unit (automatic driving ECU) 7. FIG. 5A is a diagram showing a time synchronization pattern 1, and FIG. 5B is a diagram showing a time synchronization pattern 2.

In the first electronic control unit (camera ECU) 6, periodic processing is performed every 100 milliseconds to generate camera object detection data 10 from camera image data 9. In the second electronic control unit (automatic driving ECU) 7, periodic processing is performed every 100 milliseconds to generate each control command from the camera object detection data 10. Normally, these periodic processes are implemented using timeout processing of hardware counters installed inside the electronic control units 6 and 7. However, if the operating clocks of the hardware counters are different, there will be a time lag between the electronic control units 6 and 7, which may not maintain consistency in data flow and may affect vehicle control.

In pattern 1 shown in FIG. 5A, data generated in the first cycle by the first electronic control unit (camera ECU) 6 is transmitted to the second electronic control unit (automatic driving ECU) 7 in two cycles via the in-vehicle network 4. Arrive before the start of the eye. Therefore, the second electronic control unit (autonomous driving ECU) 7 can perform calculation processing in the second cycle using the data that the first electronic control unit (camera ECU) 6 generated in the first cycle. be.

On the other hand, in pattern 2 shown in FIG. 5B, the data generated by the first electronic control unit (camera ECU) 6 in the first cycle is transmitted to the second electronic control unit (autonomous driving ECU) 7 via the in-vehicle network 4. Arrived after the start of the second cycle. Therefore, the second electronic control unit (autonomous driving ECU) 7 uses the data generated by the first electronic control unit (camera ECU) 6 in the first cycle, not in the second cycle but in the next third cycle. It becomes possible to perform calculation processing. In this way, when a difference occurs between the internal times of the electronic control units 6 and 7, the behavior of the system fluctuates.

Here, the system developer needs to verify that fluctuations in the behavior of the system including all of the multiple electronic control units due to differences in the internal time of the multiple electronic control units do not affect vehicle control. This verification work was one of the causes of increased software development costs. Therefore, in the first embodiment, control is performed to synchronize the first electronic control unit (camera ECU) 6 and the second electronic control unit (automatic driving ECU) 7 so that the times do not deviate. The method of time synchronization between electronic control devices is specified in AUTOSAR (AUTomotive Open System Architecture), which is a standard for in-vehicle software. However, since the method of time synchronization between electronic control units is not directly related to the present invention, detailed illustration of AUTOSAR will be omitted.

<Changes in data flow between time-synchronized electronic control units>
FIGS. 6A and 6B are diagrams showing examples of changes in data flow between time-synchronized electronic control units. FIG. 6A is a diagram showing the same time synchronization pattern 1 as in FIG. 5A, and FIG. 6B is a diagram showing a changed data flow pattern 3. In FIGS. 6A and 6B, unlike in FIGS. 5A and 5B, in both patterns 1 and 3, the first electronic control unit (camera ECU) 6 and the second electronic control unit (automatic operation ECU) 7 are synchronized in time. has been done.

In FIG. 6A, the start timings of periodic tasks every 100 milliseconds are the same between the two electronic control devices. However, even if the start timing (phase) of the periodic task is shifted every 100 milliseconds, if this shift is constant, it can be considered that the times are synchronized. However, as shown in pattern 3, if the processing time of the first electronic control unit (camera ECU) 6 in the first cycle becomes long, the communication time of the camera object detection data 10 transmitted over the in-vehicle network 4 is 2 It depends on the cycle. In this case, since the camera object detection data 10 does not arrive by the start of the second period of the second electronic control unit (automatic driving ECU) 7, Processing omissions occur and data flow becomes inconsistent.

Such fluctuations in processing time in the electronic control unit on the data transmitting side are obtained from the surrounding environment of the vehicle, such as when driving straight on a highway with little traffic and when turning right at an intersection in a busy downtown area. This occurs due to a difference in the amount of information and has a significant impact on vehicle control. Therefore, the system developer must verify that data flow consistency does not break down as shown in pattern 3 in FIG. 6B, regardless of the amount of traffic. Additionally, system developers are required to redesign timing and CPU scheduling as necessary, so changes in the amount of data transmitted over the in-vehicle network 4 are one of the factors that increases software development costs. It was a factor.

<LET and LCT>
Here, an overview of LET (Logical Execution Time) and LCT (Logical Communication Time) disclosed in Non-Patent Document 1 will be explained.
7A and 7B are diagrams showing an overview of LET and LCT proposed in Non-Patent Document 1. Non-patent document 1 is the following document.
”Kai-Bjorn Gemlau, Leonie KOHLER, Rolf Ernst, and Sophie Quinton. 2021. “System-level Logical Execution Time: Augmenting the Logical Execution Time Paradigm for Distributed Real-time Automotive Software.” ACM Trans. Cyber-Phys. Syst. 5, 2, Article 14 (January 2021), 27 pages. DOI:https://doi.org/10.1145/3381847”
This non-patent document 1 describes a method of extending a scheduling method called LET between ECUs.

FIG. 7A is a diagram showing the definitions of LET and LCT. As shown in FIG. 7A, the period of each cycle of the first electronic control device, the in-vehicle network, and the second electronic control device is constant at 100 milliseconds.

The first process, second process, third process, and fourth process are assigned to the LETs in the first, second, third, and fourth cycles in the first electronic control device, respectively. . Data is read at the read timing at the beginning of each process, and processed data is written at the write timing at the end of each process. Different devices and in-vehicle networks can read data written to the RAM 2, peripheral 3, etc. at the end of one cycle at the beginning of the next cycle.

In the in-vehicle network, communication processing of data processed by the first electronic control device is shown. For example, the LCT in the second cycle in the in-vehicle network is assigned the first process of communicating data that is the result of the first process in the first cycle by the first electronic control unit to the second electronic control unit. . Similarly, in the LCT of the third and fourth cycles in the in-vehicle network, data that is the result of the first processing of the second and third cycles by the first electronic control unit is sent to the second electronic control unit. A second process and a third process to communicate are assigned.

Then, in the third and fourth cycles of LET in the second electronic control device, the first processing and the second processing of the second electronic control device are performed, respectively, using data received via the in-vehicle network. Assigned.

FIG. 7B is a diagram showing an example of the processing time of each electronic control device and the communication time of the in-vehicle network. Since the period of each cycle of the first electronic control device, the in-vehicle network, and the second electronic control device is fixed, the processing performed by the first electronic control device and the second electronic control device is performed within the LET. Run it somewhere. Furthermore, communication processing performed on the in-vehicle network is executed somewhere within the LCT. For example, the first electronic control unit executes processing somewhere within the LET at a certain period. In the next cycle, the in-vehicle network communicates data to the second electronic control unit somewhere within the LET. In the next cycle, the second electronic control unit obtains data from the in-vehicle network and executes processing somewhere within the LET.

The method proposed in Non-Patent Document 1 is to fix the start time and end time of each of the application processing installed in the electronic control device and the communication processing of the in-vehicle network in advance and do not change them. be. Here, the start time is the time at which data necessary for processing of an application installed in the electronic control device and communication processing of the in-vehicle network is acquired. Furthermore, the end time is the time at which data generated by the processing of the application installed in the electronic control device and the communication processing of the in-vehicle network is released to the electronic control device or the in-vehicle network in the next cycle. By using the method proposed in Non-Patent Document 1, each application process and each The order of communication processing does not change, and data flow consistency is maintained. Therefore, it was expected that software development costs related to verification and timing redesign would be reduced.

However, it has been found that when the start and end times of application processing and communication processing are fixed according to the method disclosed in Non-Patent Document 1, the following problem occurs. This problem occurs when the processing time required for communication processing of each message (data) is long, and the amount of messages that can be communicated in the time from the start to the end of communication processing is due to the CPU processing time required to process each message. (in other words, the amount of data) was limited.

Therefore, the method disclosed in Non-Patent Document 1 could not be applied as is to applications that require large amounts of data communication, such as high-quality in-vehicle cameras, zone ECUs, and central ECUs. Note that if you lengthen the time from the start time to the end time of communication processing, it is possible to increase the amount of data communication, but the time required to exchange data between applications will increase, resulting in latency (communication delay). The problem was that it was getting worse.

As explained with reference to FIG. 6, the time required for the CPU 1 of each ECU to process each application varies depending on the surrounding environment of the vehicle or the internal state of the vehicle. Therefore, in the technology according to Non-Patent Document 1, the processing of each application executed by each application processing unit 22 shown in FIG. 2 is performed using local variables that do not share data with other application processing units 22. We will do so. Further, at the start and end of processing in each application processing section 22, global variables shared among the plurality of application processing sections 22 are read and written. Furthermore, the timing at which each application processing unit 22 reads and writes global variables is fixed. As a result, the time required for each application processing unit 22 to process an application is defined as the time from the timing of reading a fixed global variable to the timing of writing a fixed global variable, and this time is called LET. By defining the LET in this way, the processing time required by each application processing unit 22 can be regarded as always constant, and it is thought that the above-mentioned breakdown in data flow consistency will not occur.

Similarly, regarding data communication, the timing of reading a global variable from the RAM 2 of the electronic control device of the transmission source and the timing of writing the value of the global variable to the RAM 2 of the electronic control device of the receiving destination are fixed. Then, the time from the timing of reading the global variable to the timing of writing the value of the global variable is regarded as LCT.

Transmission processing by the BSW (Basic Software) on the transmission source electronic control unit (first electronic control unit (camera ECU) 6) and physical data transfer on the in-vehicle network 4 at any timing during the LCT and reception processing by the BSW on the receiving destination electronic control device (second electronic control device (automatic operation ECU) 7).

In this embodiment, it is assumed that the communication load (also referred to as bus load) on the in-vehicle network 4 is sufficiently small. Therefore, a high priority is set for communication messages (communication data) with short communication cycles. With this setting, for any communication message with a different communication cycle, the register of the peripheral 3 of the destination electronic control unit (second electronic control unit (autonomous driving ECU) 7) is 31 (see FIG. 1), the data always arrives. Here, in the case of CAN, it is known that it is sufficient if the bus load is 25% or less. Therefore, since the processing cycle of the first electronic control unit (camera ECU) 6 and the second electronic control unit (autonomous driving ECU) 7 shown in FIG. 1 is 100 milliseconds, the LCT should also be set to 100 milliseconds. Bye.

<Implementation of LET and LCT>
Next, a conventional software architecture for implementing LET and LCT proposed in Non-Patent Document 1 will be described with reference to FIGS. 8 to 11.
FIG. 8 is a diagram showing an example in which a conventional software architecture is applied to the first electronic control unit (camera ECU) 6. As shown in FIG.

The first core 11 in the first electronic control unit (camera ECU) 6 is dedicated to communication, and the second core 12 is dedicated to applications. That is, an OS (Operating System) 19, communication middleware 20, and communication driver 21 are allocated to the first core 11. Furthermore, an OS 19, an image recognition application module (vehicle front) 221, an image recognition application module (vehicle rear) 222, a data acquisition task 24, and a data disclosure task 25 are assigned to the second core 12.

The image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 are both modules that execute application processing.
The data acquisition task 24 acquires data necessary for each application processing section 22 from the RAM 2 (see FIG. 1) at the start of processing of each application module. The data acquisition task 24 can acquire data from the local area 23a or global area 23b of the application data storage unit 23 (see FIG. 2).

The data publishing task 25 stores the results of each application process in the application data storage unit 23 included in the RAM 2 when the process of each application module ends. The data publication task 25 sets an area (global area 23b) accessible from both the first core 11 and the second core 12 in the application data storage unit 23, and stores the results of each application process in this global area 23b. save. Therefore, data generated by the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 and used by other application modules is saved in the global area 23b by the data publication task 25.

The communication middleware 20 has a function of adding data necessary for communication, including header generation, to the data stored in the global area 23b, and generating communication data. This communication data is, for example, a frame used in Ethernet.
The communication driver 21 writes communication data to the register 31 of the peripheral 3 shown in FIG.

The timing for starting the data acquisition task 24 and the data publication task 25 is fixed. Further, the processing of the data acquisition task 24 and the data publication task 25 is only access to the RAM 2. Therefore, the CPU processing time of the data acquisition task 24 and the data publication task 25 can be considered constant. As a result, even if the CPU processing time (application processing time) of the image recognition application module (front of the vehicle) 221 and the image recognition application module (rear of the vehicle) 222 changes, the timing at which the data acquisition task 24 is started and the data release task The timing at which 25 is completed does not change.

From the viewpoint of data flow, the execution time of the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 is calculated from the timing when the data acquisition task 24 is started and when the data publishing task 25 is started. The time until completion is constant. This certain period of time is implemented as a LET regarding the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222.

Note that the operation of starting each application module and each task included in the electronic control device 100 at a predetermined timing is managed and executed by the task starting time management unit 26. The task start time management unit 26 is a functional unit that implements a task scheduling function provided by the OS 19.

FIG. 9 is a diagram showing an example in which the conventional software architecture is applied to the second electronic control unit (automatic driving ECU) 7.

The first core 11 in the second electronic control unit (automatic driving ECU) 7 is dedicated to communication, and the second core 12 is dedicated to applications. That is, an OS (Operating System) 19, communication middleware 20, and communication driver 21 are allocated to the first core 11. Furthermore, the OS 19, trajectory generation application module 223, control command generation application module 224, data acquisition task 24, and data publication task 25 are assigned to the second core 12.

The trajectory generation application module 223 generates a trajectory on which the vehicle travels.
The control command generation application module 224 generates control commands (steering control command 13, accelerator control command 14, and brake control command 15) for the steering 16, accelerator 17, and brake 18 shown in FIG. 3 according to the generated trajectory.

The execution time of the trajectory generation application module 223 and the control command generation application module 224 is constant as the time from the timing when the data acquisition task 24 is started until the timing when the data publication task 25 is completed. The time is implemented as a LET for the trajectory generation application module 223 and the control command generation application module 224.
The data acquisition task 24, the data publication task 25, and the task start time management unit 26 are the same as those described with reference to FIG. 8, so detailed explanations will be omitted.

Next, in order to consider the implementation of LCT, the processing of the communication middleware 20 will be explained.
The communication middleware 20 shown in FIGS. 8 and 9 is activated periodically and performs a process of transmitting communication data to other electronic control devices. Therefore, the communication middleware 20 uses the data publishing task 25 to read the data stored in the global area 23b of the application data storage unit 23 shown in FIG. Thereafter, the communication middleware 20 adds data necessary for communication (such as a communication header) to the read data, and writes the communication data to the register 31 of the peripheral 3 shown in FIG. 1 by calling the communication driver 21.

The communication middleware 20 is also activated by a data reception interrupt from the peripheral 3, and can also perform reception processing of communication data transmitted from other electronic control devices. The communication middleware 20 reads communication data stored in the register 31 of the peripheral 3 using the communication driver 21 during data reception processing. The communication middleware 20 then executes necessary predetermined processing regarding data reception defined by the communication protocol, such as communication header removal and CRC (Cyclic Redundancy Check). Thereafter, the communication middleware 20 stores the received data in the application data storage unit 23, particularly in the local area 23a of the RAM 2 that is accessible from the first core 11 and not accessible from the second core 12. save.

Furthermore, the communication middleware 20 can also be activated periodically and store the received data stored in the local area 23a of the RAM2 in the global area 23b of the RAM2. Therefore, both the first core 11 and the second core 12 can access the global area 23b.

LCT is defined by the following process.
That is, starting from the time when the communication middleware 20 installed in the first electronic control unit (camera ECU) 6 is activated for transmission processing, the communication middleware installed in the second electronic control unit (autonomous driving ECU) 7 is started. The communication middleware 20 that has been updated is also activated. The communication middleware 20 installed in the second electronic control unit (autonomous driving ECU) 7 is accessible especially from the first core 11 of the application data storage section 23 shown in FIG. Data stored in the local area 23a that is not accessible from the core 12 is retrieved. The communication middleware 20 then stores the data in the global area 23b that is accessible from both the first core 11 and the second core 12 in the application data storage unit 23. In this way, the time calculated from the time when the communication middleware 20 is activated for transmission processing until data is stored in the global area 23b is defined as the LCT.

The time required for communication from the first electronic control unit (camera ECU) 6 to the second electronic control unit (automatic driving ECU) 7 may vary depending on the status of the in-vehicle network 4. However, from the viewpoint of data flow, even the fluctuating time can be regarded as constant as LCT.

Here, an example will be described in which application processing and communication processing are performed using the technology proposed in Non-Patent Document 1.
FIG. 10 is a diagram showing an example of mapping the LET and LCT proposed in Non-Patent Document 1 to the modules and tasks shown in FIGS. 8 and 9.

The processing performed in the timing chart of the first electronic control unit (camera ECU) 6 represents the processing performed in the application-dedicated second core 12 of the first electronic control unit (camera ECU) 6. In addition, the first half of the processing performed in the timing chart of the in-vehicle network 4 (including the read timing on the left side of the diagram) is the processing performed in the first core 11 dedicated to communication of the first electronic control unit (camera ECU) 6. represents. On the other hand, the latter half of the processing performed in the timing chart of the in-vehicle network 4 (including the write timing on the right side of the diagram) is performed in the first core 11 dedicated to communication of the second electronic control unit (autonomous driving ECU) 7. Represents processing. The processing performed in the timing chart of the second electronic control unit (automatic driving ECU) 7 represents the processing performed in the second core 12 dedicated to the application of the second electronic control unit (automatic driving ECU) 7. ing.

(1st cycle)
In the first electronic control unit (camera ECU) 6, a data acquisition task 24 acquires data necessary for application processing at the beginning of the first cycle. Then, an image recognition application module (vehicle front) 221 and an image recognition application module (vehicle rear) 222 (abbreviated as "image recognition (vehicle front) 221 and image recognition (vehicle rear) 222" in the figure) perform processing. Execute. The processed data is written to the peripheral 3 by the data publishing task 25 at the end of the first cycle. The area described as "processing" in the figure represents the time during which the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 execute the process.

(2nd cycle)
Next, in the in-vehicle network 4, at the beginning of the second cycle, the communication middleware 20 in the first electronic control unit (camera ECU) 6 reads the data and sends it to the second electronic control unit (autonomous driving ECU) 7. Executes communication processing. The area labeled "communication" in the figure represents the time during which data is flowing through the bus (in-vehicle network 4). Thereafter, at the end of the second cycle, the communication middleware 20 in the second electronic control unit (automatic driving ECU) 7 writes the received data into the RAM 2.

(3rd cycle)
Next, in the second electronic control unit (automatic driving ECU) 7, the data acquisition task 24 acquires data from the peripheral 3 at the beginning of the third cycle. Then, the trajectory generation application module 223 and the control command generation application module 224 (abbreviated as "trajectory generation 223 and control command generation 224" in the figure) execute the process. The processed data is written to the peripheral 3 by the data publishing task 25 at the end of the third cycle. The area labeled "Processing" in the figure represents the time during which the trajectory generation application module 223 and the control command generation application module 224 execute the process.

<Restrictions on data communication amount>
FIG. 11 is a timing chart of the communication middleware 20 and the in-vehicle network 4 when the first electronic control unit (camera ECU) 6 transmits a large amount of data. Restrictions on data communication amount will be explained with reference to FIG. 11. The timing chart on the upper side of FIG. 11 is similar to the timing chart shown in FIG.

The data publication task 25 in the communication middleware 20 reads data stored in the application data storage unit 23 in an area (global area 23b) that is accessible from both the first core 11 and the second core 12, and writes communication headers, etc. There is a process of adding data necessary for communication and writing the data into the register 31 of the peripheral 3. In this process, for example, in the case of Ethernet communication in the in-vehicle software standard AUTOSAR, as shown on the left side of FIG. This is done via a module called . Furthermore, in this process, it is necessary to call the Driver after going through modules called Interface and Transceiver that belong to Communication Hardware abstraction. Since this processing is all executed by the CPU, the CPU processing time is on the order of 100 microseconds to 1 millisecond. In this embodiment, the CPU processing time is 150 microseconds.

On the other hand, regarding Ethernet, which allows a communication speed of 1 gigabit per second, the size of a frame, which is a communication unit, is 1 kilobyte. In this case, since 1 Kbyte is 8000 bits, the time that the frame flows as a physical signal on the in-vehicle network 4 is 8000/10^9=80*10^(-6), that is, about 80 microseconds. Here, the CPU processing time of the communication middleware 20 (150 microseconds) is longer than the time the frame flows through the in-vehicle network 4 (80 microseconds), so the time is 150 microseconds - 80 microseconds = 70 microseconds. There will be a waiting time of several minutes.

The timing chart shown in the lower part of FIG. 11 shows the relationship between the processing times of the camera object detection data 10 generated by the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222, respectively. As described above, the CPU processing time of the communication middleware 20 for the camera object detection data 10 generated by the image recognition application module (vehicle front) 221 is 150 microseconds, and then the camera object detection data processed by the communication middleware 20 is It is shown that the time it takes for 10 frames to flow through the in-vehicle network 4 is 80 microseconds. As shown in FIG. 10, also in the in-vehicle network 4, the CPU 1 of the first electronic control unit (camera ECU) 6 performs communication processing for transmitting frames (data).

Here, when the CPU processing of the camera object detection data 10 of the image recognition application module (vehicle front) 221 is finished, the CPU processing of the camera object detection data 10 of the image recognition application module (vehicle rear) 222 is next performed. In this way, conventionally, CPU processing using the communication middleware 20 is performed in the second core 12 dedicated to applications, in the order of the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222. Ta.

Here, immediately after the process of transmitting the camera object detection data 10 processed by the CPU of the image recognition application module (front of the vehicle) 221 to the in-vehicle network 4, the camera object detection data 10 processed by the CPU of the image recognition application module (rear of the vehicle) 222 is completed. It is desirable to start the process of transmitting the object detection data 10 to the in-vehicle network 4. However, the image recognition application module (vehicle rear) 222 does not operate until the CPU processing of the image recognition application module (vehicle front) 221 is completed. As a result, the CPU processing wait time is 70 microseconds from the end of frame transmission by the image recognition application module (front of the vehicle) 221 until the end of the frame generation process of the image recognition application module (rear of the vehicle) 222. will occur.

The period of 70 microseconds from when the image recognition application module (vehicle front) 221 finishes transmitting the camera object detection data 10 until the image recognition application module (vehicle rear) 222 starts transmitting the camera object detection data 10 is One electronic control unit (camera ECU) 6 cannot use the band of the in-vehicle network 4. For this reason, the amount of data that can be communicated over the in-vehicle network 4 is restricted during the 70 microseconds that is the waiting time for CPU processing.

<Communication preparation processing unit and peripheral access unit>
FIG. 12 is a diagram illustrating an overview of the processing of the communication preparation processing unit 201 and peripheral access unit 202 shown in FIG. 2, using AUTOSAR as an example.

On the left side of FIG. 12, a configuration example of conventional communication middleware 20 and communication driver 21 is shown. Normally, in AUTOSAR, the communication middleware 20 reads data generated by each application module and stored in the global area 23b of the application data storage section 23 using RTE_read(). Thereafter, the communication middleware 20 accesses the peripheral 3 by sequentially calling COM, PduR, Tp (Transport Protocol), If (Interface), and Driver (communication driver 21), and stores the transmission data in the register 31. In AUTOSAR, COM, PduR, and Tp belong to the service layer, and If belongs to the HW (hardware) abstraction layer.

The communication middleware 20 is responsible for processing from Rte_read() to If. As described above, it takes approximately 150 microseconds from the time the process starts from RTE_read( ) until the driver completes the process.

Therefore, in this embodiment, the processing of the communication middleware 20 and the communication driver 21 shown in FIGS. 8 and 9 is divided into the communication preparation processing section 201 and the peripheral access section 202 shown in FIG. 2.
On the right side of FIG. 12, a configuration example of the communication preparation processing section 201 and the peripheral access section 202 according to this embodiment is shown. As shown in FIG. 2, the communication preparation processing section 201 and the peripheral access section 202 are provided in the arithmetic processing section 1A. Note that the arithmetic processing unit 1B is provided with a communication preparation processing unit 201, but is not provided with a peripheral access unit 202. Furthermore, in this embodiment, a communication data storage unit 28 is installed as a buffer between If and Driver. As shown in FIG. 2, the communication data storage section 28 is provided in the data storage section 2A.

Here, by modifying If in the communication preparation processing unit 201, the first core 11 and the second core 12 ( arithmetic processing units 1A, 1B) do not call the Driver directly, but instead call the Driver. The communication data storage unit 28 is configured to store the arguments to be passed when doing so. The communication preparation processing section 201 is comprised from RTE_read() to the modified If. As shown in FIG. 2, the communication preparation processing section 201 receives data stored in the global area 23b of the application data storage section 23 as input, and performs processing from RTE_read() to the modified If shown on the right side of FIG. After doing so, the data is output to the communication data storage section 28.

Further, in this embodiment, the peripheral access unit 202 is a functional unit that can execute a process of extracting data from the communication data storage unit 28 and calling a Driver using the extracted data as an argument. The communication preparation processing unit (communication preparation processing unit 201) is a service layer and hardware abstraction layer defined by AUTOSAR (registered trademark), and the peripheral access unit (peripheral access unit 202) is defined by AUTOSAR (registered trademark). This is a driver. The communication data storage unit (communication data storage unit 28) is provided between the hardware abstraction layer and the driver.

As shown in FIG. 2, the actual communication data storage unit 28 is secured in an area of the RAM 2 that can be accessed from both the first core 11 and the second core 12, and the application data storage unit 23 is Separate area. Most of the CPU processing from Rte_read() until the Driver completes the process is performed by the communication preparation processing unit 201, and the CPU processing time required by the communication preparation processing unit 201 is about 130 microseconds. On the other hand, since the peripheral access unit 202 only retrieves data from the communication data storage unit 28 and calls the Driver (communication driver 21), the CPU processing time required by the peripheral access unit 202 is about 20 microseconds. Furthermore, since the communication preparation processing unit 201 is provided in both the first core 11 and the second core 12 (the arithmetic processing units 1A and 1B shown in FIG. 2), the communication preparation processing unit 201 12 can each execute the communication preparation processing unit 201 in parallel.

As shown on the right side of FIG. 12, the arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12) operate the communication preparation processing unit ( Data is transmitted to other electronic control devices 100 by activating the communication preparation processing section 201) and the peripheral access section (peripheral access section 202) in this order. Then, the communication preparation processing unit (communication preparation processing unit 201) stores communication data in the communication data storage unit (communication data storage unit 28), and the peripheral access unit (peripheral access unit 202) performs processing to store communication data in the communication data storage unit (communication data storage unit 28). The communication data read from the data storage unit 28), which the peripheral (peripheral 3) transmits to another electronic control device, is stored in the peripheral (peripheral 3).

On the contrary, the arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12) perform communication preparation on the peripheral access unit (peripheral access unit 202) based on a predetermined internal time. Data is received from other electronic control devices 100 by activating the processing units (communication preparation processing unit 201) in this order. Then, the peripheral access unit (peripheral access unit 202) acquires the data received by the peripheral (peripheral 3) from another electronic control device, and writes it into the communication data storage unit (communication data storage unit 28), and the communication preparation process. The communication preparation section (communication preparation processing section 201) writes communication data read from the communication data storage section (communication data storage section 28) into the application data storage section (application data storage section 23).

<Software architecture according to this embodiment>
Next, the software architecture according to this embodiment will be explained with reference to FIGS. 13 and 14.
In the software architecture according to this embodiment, the first core 11 is dedicated to communication, and the second core 12 is dedicated to applications, as in the example in which the method in Non-Patent Document 1 described with reference to FIGS. 8 and 9 is applied. Instead, the first core 11 and second core 12 are used for both applications and communication.

FIG. 13 is a diagram showing the software architecture of the first electronic control unit (camera ECU) 6 according to this embodiment.

One of the plurality of electronic control units (first electronic control unit (camera ECU) 6) according to the first embodiment detects an object from camera image data (camera image data 9) captured by the camera. The camera object detection data (camera object detection data 10) is transmitted to the in-vehicle network (in-vehicle network 4). This first electronic control unit (camera ECU) 6 has an OS 19, an image recognition application module (vehicle front) 221, a data acquisition task 24, a data disclosure task 25, and a communication preparation processing unit 201 for the first core 11. is assigned. Further, an OS 19, an image recognition application module (rear of the vehicle) 222, a data acquisition task 24, a data disclosure task 25, and a communication preparation processing unit 201 are assigned to the second core 12.

In the OS 19, the task activation time management unit 26 can be executed from both the first core 11 and the second core 12.
The peripheral access unit 202 of the first electronic control unit (camera ECU) 6 can be executed by either the first core 11 or the second core 12. In FIG. 2, the peripheral access unit 202 is executed by the arithmetic processing unit 1A corresponding to the first core 11, but it may also be executed by the arithmetic processing unit 1B corresponding to the second core 12. .

FIG. 14 is a diagram showing the software architecture according to this embodiment in the second electronic control unit (automatic driving ECU) 7.

One of the plurality of electronic control devices (second electronic control device (autonomous driving ECU) 7) according to the first embodiment determines the control target of the vehicle based on camera object detection data (camera object detection data 10). At least one of a control command value for the target angle of the steering (steering 16), a control command value for the target acceleration force of the accelerator (accelerator 17), and a control command value for the target damping force of the brake (brake 18). Generate and send control command values to the controlled object. In this second electronic control unit (automatic driving ECU) 7, an OS 19, a trajectory generation application module 223, a data acquisition task 24, a data disclosure task 25, and a communication preparation processing unit 201 are assigned to the first core 11. . Furthermore, the OS 19, the control command generation application module 224, the data acquisition task 24, the data publication task 25, and the communication preparation processing unit 201 are assigned to the second core 12.

In the OS 19, the task activation time management unit 26 can be executed from both the first core 11 and the second core 12.
Further, the peripheral access unit 202 of the second electronic control unit (automatic driving ECU) 7 can be executed by either the first core 11 or the second core 12. In FIG. 2, the peripheral access unit 202 is executed by the arithmetic processing unit 1A corresponding to the first core 11, but it may also be executed by the arithmetic processing unit 1B corresponding to the second core 12. .

As shown in FIGS. 13 and 14, the first core 11 and the second core 12 both execute application processing and communication processing (particularly the communication preparation processing unit 201), and the first core 11 performs communication processing. Also executes a peripheral access unit 202 for accessing the peripheral 3 that executes.

The data acquisition task 24 installed in the first core 11 is activated at a predetermined time. Furthermore, the data acquisition task 24 installed in the first core 11 has a role of acquiring data necessary for processing of the image recognition application module (vehicle front) 221, which is an application module also installed in the first core 11. have. The data acquired by the data acquisition task 24 may be generated by an image recognition application module (vehicle rear) 222 installed in the same electronic control unit. In this case, the data acquisition task 24 acquires data stored in the global area 23b of the application data storage unit 23.

If the data acquired by the data acquisition task 24 is generated by an application module installed in a different electronic control device and received by the peripheral 3, the first core 11 activates the peripheral access unit 202. The application modules installed in different electronic control devices are, for example, the application modules shown in FIG. These are the trajectory generation application module 223 or the control command generation application module 224. The peripheral access unit 202 activated by the first core 11 acquires the data stored in the register 31 shown in FIG. 1 using the communication driver 21 shown in FIG. The data is stored in the storage unit 28.

Similar to the processing of the data acquisition task 24 installed in the first core 11, the data acquisition task 24 installed in the second core 12 performs image recognition, which is an application module installed in the same second core 12. It has the role of acquiring data necessary for execution of the application module (vehicle rear) 222.

The image recognition application module (vehicle front) 221 installed in the first core 11 executes the image recognition application module (vehicle front) after the completion of the data acquisition task 24 and before the start time of the data publication task 25, similar to the technology disclosed in Non-Patent Document 1. executed at any time between. However, among the data acquired by the image recognition application module (vehicle front) 221, there may be data acquired from an application module installed in a different electronic control device, that is, data received from the outside. In this case, the image recognition application module (vehicle front) 221 calls the communication preparation processing unit 201 installed in the same first core 11 before executing the process.

The called communication preparation processing unit 201 retrieves data from the communication data storage unit 28 shown in FIG. Note that the process described here is a data reception process, so in the flow shown in FIG. 12, it is Rte_write() instead of Rte_read(). As a result, the data retrieved from the communication data storage section 28 can be accessed from the image recognition application module (front of the vehicle) 221.

In addition, when the data generated by the image recognition application module (vehicle front) 221 is released to an application module installed in a different electronic control unit after the processing of the image recognition application module (vehicle front) 221 is completed. There is. Data disclosed to the outside (for example, to a different electronic control device) in this way needs to be transmitted to the outside. Therefore, the first core 11 immediately calls the communication preparation processing unit 201 with the data that needs to be transmitted to the outside as an argument. Then, the communication preparation processing unit 201 processes Rte_read(), COM, PduR, and Tp in order as shown in FIG. 12, and stores the data in the communication data storage unit 28 at If.

Similar to the image recognition application module (vehicle front) 221 installed in the first core 11, processing is performed by the image recognition application module (vehicle rear) 222 installed in the second core 12. The processing by the image recognition application module (vehicle rear) 222 is executed at any time between after the task processing of the data acquisition task 24 is completed and before the start time of the data publication task 25.

However, among the data acquired by the image recognition application module (vehicle rear) 222, there may be data acquired from an application module installed in a different electronic control device, that is, data received from the outside. In this case, the image recognition application module (vehicle rear) 222 calls the communication preparation processing section 201 before executing the process. At this time, the communication preparation processing unit 201 retrieves data from the communication data storage unit 28 and processes Tp, PduR, COM, and Rte_write() in the reverse order of the processing shown in FIG. Through such processing, the data retrieved from the communication data storage section 28 can be accessed from the image recognition application module (vehicle rear) 222.

In addition, after the processing of the image recognition application module (rear of the vehicle) 222 is completed, the data generated by the image recognition application module (rear of the vehicle) 222 is released to application modules installed in different electronic control units. There are cases where Regarding data that needs to be sent to the outside (for example, a different electronic control device), the second core 12 immediately calls the communication preparation processing unit 201 with the data that needs to be sent to the outside as an argument. Then, the communication preparation processing unit 201 processes Rte_write(), COM, PduR, and Tp in order, and stores the data in the communication data storage unit 28 at If.

Here, in the technology disclosed in Non-Patent Document 1, since the first core 11 is dedicated for communication, all communication processing is executed by the same core. On the other hand, in the data transmission and reception processing, the communication preparation processing unit 201 according to the present embodiment performs the first Note that this is executed by the second core 11 and the second core 12, respectively.

The data publication task 25 installed in the first core 11 is activated at a predetermined time. The data publication task 25 installed in the first core 11 has the role of publishing the execution results (application data) of the image recognition application module (vehicle front) 221, which is an application module installed in the same first core 11. have Then, the application data storage unit 23 stores data to be published to application modules within the same electronic control device in the global area 23b.

Furthermore, the data publication task 25 installed in the first core 11 activates the peripheral access unit 202 immediately after the processing is completed. The peripheral access unit 202 acquires the data stored in the communication data storage unit 28, calls the communication driver 21 shown in FIG. 12, and writes the data to the register 31 of the peripheral 3. Similarly, the data publication task 25 installed in the second core 12 is activated at a predetermined time.

On the other hand, the data publication task 25 installed in the second core 12 has the role of publishing the execution results of the image recognition application module (vehicle rear) 222, which is an application module installed in the same second core 12. Therefore, the application data storage unit 23 stores data to be made public to application modules within the same electronic control device in the global area 23b.

Note that the image recognition application module (vehicle rear) 222 has already completed the communication preparation processing section 201 regarding external transmission data. Furthermore, all accesses to the peripherals 3 are executed by the peripheral access unit 202 mounted on the first core 11. Therefore, the data publication task 25 installed in the second core 12 does not particularly process data to be published to application modules in different electronic control devices.

<Differences between the technology disclosed in Non-Patent Document 1 and the technology according to this embodiment>
Next, the difference between the technology disclosed in Non-Patent Document 1 and the technology according to this embodiment will be explained with reference to FIGS. 15 and 16.
FIG. 15 is a diagram showing an example in which the LET and LCT according to the present embodiment are applied to each module and task according to the present embodiment. Here, each module and task to which LET and LCT are applied are shown in FIGS. 13 and 14. When the communication preparation processing unit 201 and the peripheral access unit 202, which will be described below, perform data reception processing, they are referred to as (receiving side), and when they perform data transmission processing, they are referred to as (transmission side).

Then, the electronic control unit (first electronic control unit (camera ECU) 6) on the sending side completes the process of transmitting data to the in-vehicle network (in-vehicle network 4), and the electronic control unit (second electronic control unit) on the receiving side A start time of a process at which the electronic control unit (automatic driving ECU) 7) receives data from the in-vehicle network (in-vehicle network 4) is defined. In addition, the startup time management unit (task startup time management unit 26) of each of the plurality of electronic control units (first electronic control unit (camera ECU) 6, second electronic control unit (automatic driving ECU) 7) is , starts the peripheral access unit (peripheral access unit 202) included in each of the plurality of electronic control devices based on the specified completion time and start time. As shown in FIG. 15, the completion time of the process in which the first electronic control unit (camera ECU) 6 transmits data, and the start time of the process in which the second electronic control unit (automatic driving ECU) 7 receives the data. The interval is fixed at 100 milliseconds. Therefore, the period of each process in the first electronic control unit (camera ECU) 6 and the second electronic control unit (autonomous driving ECU) 7 can be matched with the period of transmitting data to the in-vehicle network 4. .

(1st cycle)
<First processing by data acquisition task and data publication task>
In the first electronic control unit (camera ECU) 6, the data acquisition task 24 is performed at the read timing when the first cycle starts, and the data acquisition task 24 is performed to perform the data acquisition task 24 necessary for the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222. Obtain data (for example, camera image data 9). Next, the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 perform application processing to generate application data (for example, camera object detection data 10). In this way, the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 are assigned to the first core 11 and the second core 12, respectively, so that image recognition The application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 can simultaneously execute their respective application processes. Then, the data publication task 25 stores the application data in the global area 23b of the application data storage unit 23 and publishes the application data.

<Second processing by peripheral access unit and communication preparation processing unit>
In the first cycle, processing based on communication data received from other electronic control devices is also performed.
The peripheral access unit 202 (receiving side) whose activation is managed by the task activation time management unit 26 accesses the peripheral 3 at the read timing, reads communication data, and stores it in the communication data storage unit 28 . The communication preparation processing unit 201 (receiving side) converts the communication data read from the communication data storage unit 28 into application data that can be processed by each application module, and sends the converted application data to the application data storage unit 23. save. The image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 execute application processing using the application data read from the application data storage section 23.

When the first and second processes described above are completed, the processed application data is stored in the application data storage unit 23. The communication preparation processing unit 201 performs communication preparation processing on the application data read from the application data storage unit 23 and stores the communication data in the communication data storage unit 28. Thereafter, the peripheral access unit 202 reads the communication data from the communication data storage unit 28 and writes the communication data to the register 31 of the peripheral 3 at the write timing. Here, the time from read timing to write timing in the first electronic control unit (camera ECU) 6 is fixed at 100 milliseconds.

(2nd cycle)
On the bus of the in-vehicle network 4, communication processing of communication data is performed, and data is transmitted from the peripheral 3 of the first electronic control unit (camera ECU) 6 to the peripheral 3 of the second electronic control unit (autonomous driving ECU) 7. Communication data is sent.

(3rd cycle)
Similarly to the first cycle processing, in the third cycle, the first process by the data acquisition task 24 and the data release task 25, or the second process by the peripheral access unit 202 and the communication preparation processing unit 201 is performed. Note that the processing in the third cycle is performed by the second electronic control unit (automatic operation ECU) 7, so the point in which the trajectory generation application module 223 and the control command generation application module 224 execute the application processing is different from the first cycle. different.

The technology according to the present embodiment differs from the technology disclosed in Non-Patent Document 1 in that the timing to be fixed is not the start time and end time of the application module, but the start of processing that combines the application module and the communication preparation processing unit 201. Time and end time. Further, the communication preparation processing unit 201 is executed by both the first core 11 and the second core 12. Therefore, of the communication processing that required 150 microseconds of CPU processing time shown in FIG.

FIG. 16 is a timing chart comparing the technology according to the first embodiment and the technology disclosed in Non-Patent Document 1.

The upper part of FIG. 16 shows an example of the timing of each process according to the first embodiment. The processes of the first core 11 and the second core 12 can be started simultaneously. The first core 11 and the second core 12 separate communication processing by the CPU into a communication preparation processing section (130 microseconds) and a peripheral access section (20 microseconds).

The peripheral access unit 202 (reception side) of the first core 11 performs reception processing in 20 microseconds. After that, the first core 11 and the second core 12 perform parallel processing on the communication preparation processing unit 201 (receiving side) and the communication preparation processing unit 201 (transmission side), and perform application processing (image recognition application (front) and image recognition application (front)). The recognition application (backwards) is also executed in parallel. The first core 11 executes the peripheral access unit 202 (transmission side) using one core. Therefore, the communication processing performed on the in-vehicle network 4 does not have to wait for processing by the CPU 1, and the band limitation of the in-vehicle network 4 is eliminated.

The lower part of FIG. 16 shows an example of the timing of each process related to the technology disclosed in Non-Patent Document 1. In the technology disclosed in Non-Patent Document 1, as shown in FIGS. 8 and 9, the core is separated into a first core 11 dedicated to communication and a second core 12 dedicated to applications. Therefore, after the application-dedicated second core 12 sequentially processes the image recognition application (vehicle front) and the image recognition application (vehicle rear), the first core 11 performs communication processing. The first core 11 dedicated to communication sequentially transmits the processing data of the image recognition application (front of the vehicle) and the processing data of the image recognition application (rear of the vehicle) to the second electronic control unit (automatic control unit) via the in-vehicle network 4. Performs communication processing for sending data to the driving ECU) 7.

Here, when the communication processing of the processing data of the image recognition application (vehicle front) is completed in the first core 11 dedicated for communication, the processing data of the image recognition application (vehicle front) is communicated over the in-vehicle network 4. However, when the in-vehicle network 4 uses high-speed, large-capacity communication such as 1 Gigabit Ethernet, the CPU processing (150 microseconds) required for communication by the first core 11 is This is longer than the time it takes to flow on the bus (80 microseconds). Therefore, in the in-vehicle network 4, a processing wait occurs until the first core 11 dedicated to communication finishes communication processing of processing data of the image recognition application (vehicle rear). When the communication processing in the first core 11 dedicated to communication is completed, the in-vehicle network 4 can send the frame data of the image recognition application (vehicle rear) to the in-vehicle network 4 bus. In this way, the communication band of the in-vehicle network 4 is limited.

In the electronic control device 100 according to the first embodiment described above, the timing to be fixed as LET is determined from the start time of application processing in each application processing unit, not from the start time and end time of application processing in each application processing unit. This is the end time of communication preparation processing. Each core was provided with a communication preparation processing section 201, respectively. By fixing the LET in this way, it is possible to simultaneously execute communication preparation processing in a plurality of cores. For this reason, conventionally, one core performed communication preparation processing and then sent a frame to the bus, so if one application module did not finish communication preparation processing, another application module would start communication preparation processing. This resulted in a wait time before sending the frame onto the bus. A trade-off has occurred in that the shorter the control period, the more waiting time occurs and the amount of data that can be transmitted to the bus decreases. On the other hand, in the electronic control device according to the present embodiment, even if the control period becomes shorter, the amount of data that can be transmitted to the bus does not need to be reduced. Further, even when a large amount of data communication is required between a plurality of electronic control devices, it is possible to introduce LET (fixed timing), which has the effect of reducing software development costs.

Furthermore, as described above, in the electronic control device 100 according to the first embodiment, the units for fixing the start time and end time of LET are not application processing and communication processing, but application processing and communication preparation. processing and peripheral access processing. Therefore, most of the communication processing can be executed in parallel in each core (arithmetic processing unit) while keeping the start time and end time of the processing fixed. Further, even when a large amount of data communication is required, there is no need to extend the time from the start time to the end time of communication-related processing, so it is possible to improve latency (communication delay).

Note that, regarding the electronic control device 100 according to the first embodiment, an example of the configuration and processing of the electronic control device has been described using standard AUTOSAR as an example. However, the communication middleware 20 is not a standard basic software module, but may be a complex device driver. A complex device driver is software that can be installed by users with their own specifications.

The present invention is also applicable to electronic control devices equipped with general real-time operating systems other than AUTOSAR.

In addition, in order to verify that the data flow shown in FIG. 15 is maintained, the communication preparation processing unit 201 (sending side) adds a timestamp indicating the transmission time to the frame data and performs frame transmission processing. . On the other hand, the communication preparation processing unit 201 (receiving side) may perform a process of checking the time stamp added to the received frame when receiving the frame.

[Second embodiment]
Next, a configuration example and a processing method of an electronic control device according to a second embodiment of the present invention will be described. The electronic control device according to the second embodiment differs from the first embodiment in that the communication middleware 20 is a lightweight communication driver. Note that the same configurations as those in the first embodiment are given the same reference numerals and the description thereof will be omitted.

<Lightweight communication driver>
A configuration example of a first electronic control unit (camera ECU) 6A and a second electronic control unit (automatic driving ECU) 7A that can execute a lightweight communication driver will be described with reference to FIGS. 17 and 18.
FIG. 17 is a diagram showing the software architecture of the first electronic control unit (camera ECU) 6A according to the second embodiment.

One or more arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12) are provided; 12) may each have an application processing section (application processing section 22). In FIG. 17, the first electronic control unit (camera ECU) 6A will be described as having only the first core 11 that is used for both communication processing and application processing.

An OS 19, an image recognition application module (vehicle front) 221, an image recognition application module (vehicle rear) 222, a data acquisition task 24, a data disclosure task 25, and a lightweight communication driver 29 are assigned to the first core 11. A task start time management unit 26 is assigned to the OS 19.

FIG. 18 is a diagram showing the software architecture of the second electronic control unit (automatic driving ECU) 7A according to the second embodiment.

The second electronic control unit (automatic driving ECU) 7A has only a first core 11 that is used for both communication processing and application processing.
The OS 19, trajectory generation application module 223, control command generation application module 224, data acquisition task 24, data publication task 25, and lightweight communication driver 29 are assigned to the first core 11. A task start time management unit 26 is assigned to the OS 19.

FIGS. 8 and 9 show an example of communication middleware 20 and communication driver 21 for transmitting and receiving data, which are allocated to the first core 11 dedicated to communication. Here, the total processing time required for execution of the communication preparation processing unit (communication preparation processing unit 201) and the peripheral access unit (peripheral access unit 202) is the communication time of data communicated with other electronic control devices. It may be shorter than For example, the total CPU processing time of the communication middleware 20 and the communication driver 21 may be shorter than the time during which a data frame flows through the bus of the in-vehicle network 4. In this case, the arithmetic processing unit (arithmetic processing unit 1A, first core 11) is a lightweight communication driver (lightweight The lightweight communication driver (lightweight communication driver 29) performs transmission and reception processing of communication data. Therefore, the communication middleware 20 and communication driver 21 are collectively referred to as a "lightweight communication driver." The lightweight communication driver 29 shown in FIGS. 17 and 18 does not cause the CPU to wait for processing as shown in FIG. 16 even if one core (first core 11) continuously executes transmission/reception processing. .

However, in the second embodiment, the communication preparation processing section 201 and the peripheral access section 202 do not need to be separated. Furthermore, the data acquisition task 24 acquires data necessary for the processing of the application module from other application modules within the same electronic control device by accessing the global area 23b.

FIG. 19 is a diagram showing an example of mapping the LET and LCT according to the present embodiment to each module and task according to the present embodiment. Here, each module and task for mapping LET and LCT are shown in FIGS. 17 and 18. Among the modules and tasks described below, the modules and tasks labeled (receiving side) are responsible for data reception processing, and the modules and tasks labeled (transmission side) are responsible for data transmission processing. do.

(1st cycle)
In the first electronic control unit (camera ECU) 6A, the data acquisition task 24 mapped to the read timing at which the first cycle starts acquires data. Next, the lightweight communication driver 29 (reception side) performs a reception process on the received data. Next, the image recognition application module (vehicle front) 221 and the image recognition application module (vehicle rear) 222 execute processing. Then, at the write timing when the first cycle ends, the data disclosure task 25 writes the processed data to the register 31 of the peripheral 3, and the lightweight communication driver 29 (transmission side) performs a transmission process to transmit the data to the in-vehicle network 4. conduct.

(2nd cycle)
On the bus of the in-vehicle network 4, data is communicated from the first electronic control unit (camera ECU) 6A to the second electronic control unit (automatic driving ECU) 7A.

(3rd cycle)
In the second electronic control unit (automatic driving ECU) 7A, the data acquisition task 24 mapped to the read timing at which the third cycle starts acquires data. Next, the lightweight communication driver 29 (reception side) performs data reception processing. Next, the trajectory generation application module 223 and the control command generation application module 224 execute processing. Then, at the write timing when the third cycle ends, the data disclosure task 25 writes the processed data to the register 31 of the peripheral 3, and the lightweight communication driver 29 (transmission side) performs data transmission processing.

As shown in FIG. 19, after the processing by the data acquisition task 24 is completed, the task activation time management unit 26 immediately calls the lightweight communication driver 29 to perform data reception processing. Then, the data publishing task 25 publishes the data to other application modules within the same electronic control device by writing the processing results of the application module into the global area 23b. Further, after the processing of the data disclosure task 25 is completed, the task activation time management unit 26 immediately calls the lightweight communication driver 29 to perform data transmission processing.

In the electronic control device 100 according to the second embodiment described above, even when there is only one core, it is possible to reduce software development costs by fixing the timing. Further, even when the electronic control device 100 is configured with multiple cores, unlike the technology disclosed in Non-Patent Document 1, there is no need to install a dedicated communication core. Therefore, the number of CPU cores used in the electronic control device 100 can be reduced. In this way, in the electronic control device 100 according to the second embodiment, the timing can be adjusted without modifying the communication middleware 20 and the communication driver 21 shown in FIG. This has the effect of reducing software development costs due to fixed costs.

[Third embodiment]
Next, a configuration example and a processing method of an electronic control device according to a third embodiment of the present invention will be described with reference to FIGS. 20 and 21.
The electronic control device according to the third embodiment differs from the electronic control device according to the first embodiment in that the application module installed in the first electronic control device is installed in the second electronic control device. The following changes were made. Note that the same configurations as those in the first embodiment are given the same reference numerals and the description thereof will be omitted.
FIG. 20 is a diagram showing a configuration example of a vehicle control device 5A equipped with a third electronic control device (central ECU) 71 according to the third embodiment.

<Vehicle control device 5A>
The vehicle control device 5A includes a third electronic control device (central ECU) 71 instead of the second electronic control device (automatic driving ECU) 7.
The third electronic control device 71 is a central computer and is responsible for heavy-load calculations such as AI (Artificial Intelligence) and image processing, so an electronic control device with emphasis on calculation performance is used. A zone ECU (not shown) is provided for the third electronic control unit (central ECU) 71. The zone ECU is responsible for light-load calculations such as sensor control and actuator control for each zone into which the vehicle is divided, and uses an electronic control unit with an emphasis on safety.

Unlike the first embodiment, a first electronic control unit (camera ECU) 6B included in the vehicle control device 5A transmits camera image data 9 acquired from the camera 8 to the in-vehicle network 4 at a predetermined time. It only has a role. The camera image data 9 transmitted to the in-vehicle network 4 by the first electronic control unit (camera ECU) 6B is received by the third electronic control unit (central ECU) 71.

A third electronic control unit (central ECU) 71 generates a steering control command 13, an accelerator control command 14, and a brake control command 15 based on the camera image data 9. The third electronic control unit (central ECU) 71 controls the operations of the steering wheel 16, accelerator 17, and brake 18 by outputting each command.

Furthermore, the third electronic control unit (central ECU) 71 can update the software that operates on the third electronic control unit (central ECU) 71 using a known OTA (Over the Air) technology.

FIG. 21 is a diagram showing the software architecture of the third electronic control unit (central ECU) 71 according to the present embodiment.

One of the plurality of electronic control devices (third electronic control device (central ECU) 71) according to the third embodiment includes a plurality of arithmetic processing units ( arithmetic processing units 1A, 1B, three cores (first It has a core 11, a second core 12 and a third core 72)). The first core 11, second core 12, and third core 72 are all used for applications and communication. One or more application processing units (application processing unit 22) are provided in each of the plurality of arithmetic processing units ( arithmetic processing units 1A, 1B, first core 11, second core 12, and third core 72). . One of the plurality of arithmetic processing units (first core 11) includes an update unit (software update unit 73) that updates the function of the application processing unit (application processing unit 22).

The first core 11 includes a trajectory generation application module 223, an OS 19, a data acquisition task 24, which was installed in the second electronic control unit (automatic driving ECU) 7 according to the first embodiment shown in FIG. A data publication task 25, a communication preparation processing section 201, and a peripheral access section 202 are assigned. The OS 19 of the first core 11 can execute the task start time management section 26. Furthermore, a software update section 73 is newly allocated to the first core 11.

The second core 12 includes a control command generation application module 224, an OS 19, and a data acquisition task 24 installed in the second electronic control unit (automatic driving ECU) 7 according to the first embodiment shown in FIG. , a data disclosure task 25, and a communication preparation processing unit 201 are assigned. The OS 19 of the second core 12 can execute the task start time management unit 26.

The third core 72 includes an image recognition application module (vehicle front) 221 and an image recognition application module installed in the first electronic control unit (camera ECU) 6 according to the first embodiment shown in FIG. (vehicle rear) 222, OS 19, data acquisition task 24, data disclosure task 25, and communication preparation processing section 201 are assigned.

The software update unit 73 installed in the first core 11 can update the application module installed in the third electronic control unit (central ECU) 71 using OTA (Over the Air) technology. That is, the software update unit 73 has a role of updating the image recognition application module (vehicle front) 221, the image recognition application module (vehicle rear) 222, the trajectory generation application module 223, and the control command generation application module 224.

The software update performed by the software update unit 73 is normally carried out when each application module is started or after it is finished. In many computers, a master core and a slave core are designated, and the master core updates software including the slave cores. The core number of the master core is often "0". Therefore, if the first core 11 is the master core, the software update unit 73 is executed by the first core 11. This software update unit 73 can also update the trajectory generation application module 223 and the control command generation application module 224.

The software update unit 73 can update the functions of the trajectory generation application module 223 and the control command generation application module 224 in automatic driving at any time. In addition, the software update unit 73 also updates the image processing functions of the image recognition application modules 221 and 222 that are performed on the camera image data 9, thereby making it possible to improve the image recognition performance of each module. Become.

In the first embodiment, the data transmitted from the first electronic control unit (camera ECU) 6 to the second electronic control unit (automatic driving ECU) 7 is camera object detection data 10. On the other hand, in the third embodiment, the data transmitted from the first electronic control unit (camera ECU) 6B to the third electronic control unit (central ECU) 71 is camera image data 9. In the third embodiment, camera object detection data 10 is sent from the first electronic control unit (camera ECU) 6 to the second electronic control unit (autonomous driving ECU) 7 via the in-vehicle network 4 as in the first embodiment. There is no need to send the data. Therefore, the process in which the third electronic control unit (central ECU) 71 performs image recognition and generates a trajectory and a control command for automatic driving is shortened, and the vehicle can be quickly controlled.

Furthermore, as explained with reference to FIG. 4, since the data size of the camera image data 9 is approximately several megabytes, the technology disclosed in Non-Patent Document 1 has limitations on the communication band. It was impossible to send or receive. On the other hand, with the technology according to the third embodiment, since there is no restriction on the communication band, it is possible to arrange such application modules.

In the vehicle control device 5A according to the third embodiment described above, in the vehicle control device 5 according to the first embodiment, the first electronic control device (camera ECU) 6 and the second electronic control device (automatic driving ECU ) 7 are integrated into one third electronic control unit (central ECU) 71. Then, the software update unit 73 updates the functions of the application module at an arbitrary timing. Therefore, the accuracy of image recognition and vehicle driving control can be improved by using an application module with improved functionality.

Furthermore, the present invention aims to reduce software development costs by fixing timing. Then, by updating the application modules, the possibility that the input and output timing of each application module changes before and after the update is eliminated. Therefore, software updating by OTA is particularly useful for the third electronic control unit (central ECU) 71 according to the third embodiment.

Therefore, in the vehicle control device 5A according to the third embodiment, the arrangement of application modules within the vehicle can be changed flexibly. Further, it has the effect of integrating a plurality of electronic control devices and making it possible to easily update a plurality of application modules.

It should be noted that the present invention is not limited to the embodiments described above, and it goes without saying that various other applications and modifications may be made without departing from the gist of the present invention as set forth in the claims.
For example, in each of the embodiments described above, the configurations of devices and systems are explained in detail and specifically in order to explain the present invention in an easy-to-understand manner, and the embodiments are not necessarily limited to having all the configurations described. Further, it is possible to replace a part of the configuration of the embodiment described here with the configuration of another embodiment, and furthermore, it is also possible to add the configuration of another embodiment to the configuration of a certain embodiment. Furthermore, it is also possible to add, delete, or replace some of the configurations of each embodiment with other configurations.
Further, the control lines and information lines are shown to be necessary for explanation purposes, and not all control lines and information lines are necessarily shown in the product. In reality, almost all components may be considered to be interconnected.

1... CPU, 1A, 1B... Arithmetic processing unit, 2... RAM, 2A... Data storage unit, 3... Peripheral, 4... In-vehicle network, 5... Vehicle control device, 6... First electronic control device (camera ECU), 7... Second electronic control unit (automatic driving ECU), 11... First core, 12... Second core, 19... OS, 22... Application processing section, 23... Application data storage section, 24... Data acquisition task , 25...Data disclosure task, 26...Task start time management section, 28...Communication data storage section, 100...Electronic control unit, 201...Communication preparation processing section, 202...Peripheral access section, 221-224...Application module

Claims (11)

1. an arithmetic processing unit having an application processing unit that performs application processing;
   a data storage unit that stores data processed by the arithmetic processing unit;
   a peripheral that transmits the data read from the data storage unit to another electronic control device or receives data from another electronic control device,
   A first timing at which the arithmetic processing unit inputs and outputs the data to the data storage unit for the application processing, and a first timing at which the arithmetic processing unit passes the data read from the data storage unit to the peripheral, and and a second timing for transmitting the data to another electronic control device are fixed in advance.
2. The arithmetic processing unit includes the application processing unit and a communication preparation processing unit that prepares for communication of application data generated by the application processing,
   The data storage unit includes an application data storage unit that stores the application data, and a communication data storage unit that stores communication data generated by the communication preparation processing unit,
   At least one of the arithmetic processing units includes a peripheral access unit that accesses the communication data storage unit and the peripheral, and a startup time management unit that manages a startup time for starting the peripheral access unit,
   The electronic control according to claim 1, wherein the startup time management unit operates the application processing unit at the first timing and operates the peripheral access unit at the second timing, based on a predetermined internal time. Device.
3. The first timing is fixed as a timing at which the application processing unit inputs and outputs the data to the application data storage unit,
   The electronic control device according to claim 2, wherein the second timing is fixed as a timing at which the peripheral access unit transfers the communication data stored in the communication data storage unit to the peripheral.
4. The electronic control device according to claim 3, wherein the internal time is corrected by a time synchronization signal received from the outside.
5. The application data storage section includes a local area used only by the application processing section executing processing, and a local area where each application processing section temporarily stores data during the application processing. a global area that stores data resulting from completion of processing by the processing unit and makes the data usable to other application processing units;
   The electronic control device according to claim 4, wherein the application processing unit accesses the global area at the first timing.
6. The arithmetic processing section activates the communication preparation processing section and the peripheral access section in this order based on a predetermined internal time, and the communication preparation processing section stores the communication data in the communication data storage section. processing, and processing of storing in the peripheral the communication data read by the peripheral access unit from the communication data storage unit and transmitted by the peripheral to another of the electronic control devices,
   Based on a predetermined internal time, the peripheral access unit and the communication preparation processing unit are activated in this order, and the peripheral access unit acquires the data that the peripheral has received from the other electronic control device, and the communication The electronic control device according to claim 5, wherein the electronic control device performs a process of writing into a data storage unit, and a process of writing the communication data read from the communication data storage unit by the communication preparation processing unit into the application data storage unit.
7. The communication preparation processing unit is a service layer and a hardware abstraction layer defined in AUTOSAR (registered trademark),
   The peripheral access unit is a driver defined by AUTOSAR,
   The electronic control device according to claim 3, wherein the communication data storage unit is provided between the hardware abstraction layer and the driver.
8. When the total processing time required for execution of the communication preparation processing section and the peripheral access section is shorter than the communication time of the data communicated with other electronic control devices, the arithmetic processing section: The electronic control device according to claim 3, wherein the communication preparation processing unit and the peripheral access unit are integrated into a lightweight communication driver, and the lightweight communication driver performs transmission and reception processing of the communication data.
9. The electronic control device according to claim 3, wherein one of the plurality of arithmetic processing units includes an updating unit that updates a function of the application processing unit.
10. The plurality of electronic control devices communicate the data with each other through the in-vehicle network through the peripheral,
    A completion time of a process in which the electronic control unit on a transmitting side transmits the data to the in-vehicle network, and a start time in a process in which the electronic control unit on a receiving side receives the data from the in-vehicle network are defined,
    According to claim 3, the activation time management unit included in each of the plurality of electronic control units activates the peripheral access unit included in each of the plurality of electronic control units based on the specified completion time and the start time. The electronic control device described.
11. One of the plurality of electronic control devices transmits camera object detection data, which is a result of object detection from camera image data captured by the camera, to the in-vehicle network;
    One of the plurality of electronic control devices is configured to determine, based on the camera object detection data, a control command value for a target angle of a steering wheel, which is a control target of the vehicle, a control command value for a target acceleration force of an accelerator, and a target attenuation of a brake. The electronic control device according to claim 10, wherein the electronic control device generates at least one of force control command values and transmits the control command value to the controlled object.

Images