JP7204443B2 - VEHICLE CONTROL DEVICE AND PROGRAM EXECUTION METHOD - Google Patents

Description

The present invention relates to a vehicle control device equipped with a multi-core microprocessor and a program execution method in such a vehicle control device.

In the in-vehicle ECU (Electronic Control Unit) software, standardization of commonly required functions, such as in-vehicle self-diagnosis requirements stipulated by laws and regulations, is being promoted, and the functions are provided as platform software components. For example, AUTOSAR (AUTomotive Open System ARchitecture), which is a platform for vehicle standard software, provides a software component called DEM (Diagnosis Event Manager) as a diagnostic information management section.

However, in order to realize various performance improvements such as safety, fuel efficiency, and exhaust emissions required for in-vehicle ECUs, software components are becoming larger and more complex. As one of the countermeasures, a multi-core microprocessor having a plurality of processors (hereinafter referred to as a multi-core microcomputer) can be adopted to improve the total arithmetic performance.

In order to use a multi-core microcomputer, it is necessary to manage core allocation of functions, which functions are operated by which cores. In multi-core microcomputers with many cores, there is a limit to the management of core allocation, and techniques for automatically allocating cores using a parallelizing compiler have begun to be applied.

JP 2005-071109 A JP 2018-049406 A

Application software that uses software components of the platform normally uses functions via APIs (Application Programming Interfaces) provided by the software components. When this API is used simultaneously from each core of a multi-core microcomputer, data contention occurs, so a mechanism for avoiding API call contention is required. Problems associated with avoiding API call conflicts or data conflicts will be described by taking as an example a case where a diagnostic module of application software uses a diagnostic information manager, which is a software component of the platform, using APIs.

FIG. 1 is an example of implementation of a vehicle control device for avoiding contention due to API calls from a plurality of cores 1-1 to n. In this configuration, all diagnostic modules 11 in application software using the diagnostic information management unit 12 of the platform are allocated to cores so that they can be accessed from one core (core 1-1 in this example), and diagnostic information management is performed. The configuration is such that the processing of the unit 12 is completed by a single core. With this configuration, the API is not called from cores other than the core 1-1, and data contention can be suppressed. However, even if development progresses and there is a need to add a new diagnostic module, there will be a constraint that it must be assigned to the core 1-1 to which the diagnostic module 11 has already been assigned.

FIG. 2 shows another example of implementation, in which one diagnostic information manager 12-i is assigned to one core 1-i (i=any number from 1 to n). In this configuration, it is possible to call a common API in each core. Only Memory) usage increases. Further, when the diagnostic information management unit 12-i of each core writes to the core-shared RAM 3, it is necessary to perform data barrier synchronization as described in Patent Document 1, for example, in order to suppress data competition. Yes, and this can delay processing.

FIG. 3 is yet another example of implementation, in which software components 12 under one core (here, core 1-1) described in Patent Document 2 are connected to the core 1-1 and another core 1-j. This is a configuration example in which direct operation is performed from (j=any number from 2 to n). In this configuration, it is possible to reduce the amount of ROM used, but to prevent simultaneous execution when calling APIs under other cores, arbitration between cores, for example, priority is given to processing that is being executed first. Since it is necessary for the side to execute later to wait until the completion of the processing, a delay in processing is unavoidable as in the case of the configuration in FIG.

A vehicle control device is required to guarantee that the processing of a scheduled task of each core of a multi-core microcomputer is completed within a predetermined period (cycle period). For example, if the cycle period is defined as 10 ms, the processing of the scheduled task in one cycle executed by each core must be completed within 10 ms, and the task in the next cycle must be ready to start. . If it takes 10 ms or more to process a scheduled task that is executed every 10 ms, the scheduled task cannot be executed correctly in the next cycle, resulting in system failure. Therefore, it is necessary to design tasks so that the time required for scheduled tasks is shorter than the cycle period. For example, if the cycle period is 10 ms and the time to complete the task is 7 ms, the remaining 3 ms can be used as idle time until the next 10 ms task is started. can be managed as an indicator of

However, if API call competition or data competition occurs, there is a possibility that a large overhead will occur due to arbitration, and the effect of increasing the total computational performance by parallelization cannot be fully utilized.

A vehicle control device according to one embodiment of the present invention has a microprocessor having a plurality of cores including a first core and a memory readable and writable from the plurality of cores, and provided by the microprocessor from a software platform. A vehicle control device in which application software using software components is executed, wherein the plurality of cores includes application software modules and a request receiving unit that receives API calls for software components from the modules; , a software component, and a request processing unit that performs a first API call to cause the software component to execute a first process of writing the processing result of the application software to a predetermined area of a memory, and the request receiving units of the plurality of cores: , receives the first API call from the module, writes the processing result of the module together with the storage time information into the buffer area of the memory allocated to each core, and the request processing unit of the first core receives the first API call. Then , based on the storage time information, the processing results of the modules written in the buffer area of the memory assigned to each core are written in a predetermined area of the memory in chronological order .

When application software modules installed on multiple cores use platform APIs from multiple cores, it is possible to perform processing with a balance of trade-offs in terms of ROM usage, calculation load, responsiveness, etc. .

Other problems and novel features will become apparent from the description of the specification and the accompanying drawings.

It is a figure for demonstrating the subject of this invention. It is a figure for demonstrating the subject of this invention. It is a figure for demonstrating the subject of this invention. 1 is an example of a system configuration in Example 1; It is an example of the data structure of information. 6 is a flow chart showing the flow of processing executed by a request receiving unit; 4 is a flow chart showing the flow of processing executed by a write request processing unit; 4 is a flowchart showing processing of a diagnostic information management unit; It is a figure for demonstrating the effect of a present Example. It is a figure for demonstrating the effect of a present Example. It is a system configuration example in the second embodiment.

Embodiments for carrying out the present invention will be described below with reference to the attached drawings. Here, a case where the diagnostic module of the application software uses the API of the diagnostic information management section of the platform will be described as an example. Specifically, the diagnostic information processing unit of the platform is assumed to be DEM, which is a software component of AUTOSAR.

FIG. 4 is a system configuration example of a vehicle control device to which the multi-core microcomputer according to the first embodiment is applied. A vehicle control device 5 of this embodiment includes a plurality of cores 1-1 to n, a core-shared random access memory (RAM) 3 accessible from each of the cores 1-1 to n, and a non-volatile memory 4. FIG. Each core has a computing unit, a timer management unit, and the like for executing instructions stored in a memory (not shown), and each of them executes processing related to a specific function.

Each core contains functional blocks that function by executing instructions. In this example, a core 1-i (where i is any number from 1 to n) includes a diagnostic module 11-i for detecting failures in general-purpose input circuits and output circuits, and a request reception unit 13-i. The request receiving unit 13-i receives a reference request for the diagnostic result stored in the common diagnostic information area 31 of the core shared RAM 3 from the diagnostic module 11-i of the relevant core 1-i, or receives a diagnostic result performed by the diagnostic module 11-i. Accepts a write request to write the result to the core shared RAM 3 . In addition to these, the core 1-1 includes a write request processing unit 14 for requesting writing of diagnostic results to the common diagnostic information area 31, and a diagnostic information management unit 12 corresponding to DEM of AUTOSAR. In this system configuration, only the core 1-1 has the write request processing unit 14 and the diagnostic information management unit 12. FIG.

The core shared RAM 3 is readable and writable by the cores 1-1 to n. The core-shared RAM 3 has a buffer area 32-i for temporarily storing diagnostic results for which write requests are made from the request receiving units 13-i for each core, and a common diagnostic for storing diagnostic results of the diagnostic modules 11-i to 11-n. and an information area 31 . The common diagnostic information area 31 is an area of the core-shared RAM 3 in which the diagnostic results of the diagnostic modules 11-1 to 11-n written in the buffer areas 32-1 to 32-n are finally written, as will be described later. However, part of the data in the common diagnostic information area 31 is also stored in the nonvolatile memory 4 according to its importance.

The diagnosis result of the diagnosis module 11-i of each core is passed to the request receiving unit 13-i of the same core using the DEM API name. Two kinds of DEM APIs, a read API and a write API, are prepared, and the request receiving unit 13-i performs predetermined processing according to the received API.

FIG. 6 is a flow chart showing the flow of request reception processing executed by the request reception unit 13-i of each core. As described above, this flow is executed in the relevant core by an API call from the diagnostic module 11-i of the relevant core.

First, if the request for which the acceptance process (S101) is performed is a read request (NO in S102), the core shared RAM 3 is directly accessed, the desired diagnostic result is obtained from the common diagnostic information area 31, and a response is sent to the diagnostic module 11-i. (S103). As for reading, since arbitration between cores is not required, the requested diagnostic result is returned to the diagnostic module 11-i and the flow ends. The exchange of information between the request reception unit 13-i of each core and the core-shared RAM 3 at this time is indicated by the one-dot chain line in FIG.

On the other hand, if the request subjected to the reception process (S101) is a write request (YES in S102), the request reception unit 13-i needs to specify the buffer area 32-i in the core shared RAM 3 for storing the processing status. In addition, it acquires information (S104) on the core that executed the call (that is, its own core) and storage time information (S105) when called by the diagnostic module 11-i. S105 is required by law to store diagnostic results in chronological order, and S105 is performed to comply with this requirement. Acquisition of the storage time information can be performed by, for example, capturing the free-running timer value provided by the timer manager.

Then, the diagnostic result requested by the diagnostic module 11-i is written in the buffer area 32-i in the core-shared RAM 3 (S106), and the flow ends (S107). The exchange of information between the request receiving unit 13-i of each core and the core-shared RAM 3 at this time is indicated by broken lines in FIG.

FIG. 5 shows an example of a data structure written to the buffer area 32-i of the core shared RAM 3 from the request receiving unit 13-i. A diagnostic result 70 is one unit for which the diagnostic module 11-i issues a write request, and the diagnostic result 70 includes the determination result and additional information when the determination result is generated for failure analysis or the like. there is The diagnosis ID 71 is identification information assigned to the diagnosis executed by the diagnosis module 11 in order to uniquely identify the contents of the diagnosis. The determination result 72 is the result of executing the diagnosis, and includes both failure determination and normal determination. The environment information 73 is environment data when the diagnosis is executed. The environmental data includes, for example, vehicle data, such as vehicle speed, and ambient environment data, such as outside temperature, at the time of diagnosis. The storage time information 74 is a time stamp indicating when the diagnosis is executed. For example, it is the free-run timer value acquired in S105 in the flowchart of FIG.

Also, in the same cycle, a request to write a plurality of diagnostic results 70 may be issued from the request receiving unit 13-i. The number of write requests 75 in one cycle from the request receiving unit 13-i is recorded in the buffer area 32-i. That is, when the scheduled task of each core ends, diagnostic results 70 corresponding to the number of write requests 75 are stored in the buffer area 32-i.

In the system configuration of this embodiment, the diagnostic result stored in the buffer area 32-i of the core shared RAM 3 by the request receiving unit 13-i is sent to the diagnostic information managing unit 12 by the write request processing unit 14 of the core 1-1. be handed over. FIG. 7 is a flow chart showing the flow of write request processing notified to the diagnostic information management unit 12 by the write request processing unit 14 . This process is periodically executed as a regular task of the write request processing unit 14 in each cycle, but it can also be executed by interrupt processing triggered by the end of processing of the core.

The write request processing unit 14 first monitors the end of processing of the cores 1-1 to n (S202). If the processing of all cores has not ended (NO in S202), the flow ends without performing the write request processing (S211). For example, a flag storage area indicating the end of diagnostic processing for each core is provided in the core-shared RAM 3, and an end flag is stored in the flag storage area when the diagnosis module 11-i of each core finishes the scheduled task. The write request processing unit 14 can monitor the end of the scheduled task of the diagnosis module 11-i of each core by reading the end flag of each core 1-1 to n.

When it is confirmed that the scheduled tasks of all the cores 1-1 to n have been completed, write request processing is started (YES in S202). First, the number of write requests from each core (see FIG. 5) is acquired, and the total number of writes is confirmed (S203). After that, in order to determine the order of writing to the common diagnostic information area 31, the information of the storage time information 74 of each diagnostic result 70 stored in the buffer areas 32-1 to 32-n is obtained (S204), The diagnostic results 70 are sorted (S205). After sorting is completed (YES in S206), the diagnostic results 70 are read from the buffer areas 32-1 to 32-n in that order (S207), and a write request is sent to the diagnostic information management unit 12 using the write API (S208). .

After confirming the number of write processing requests for the total number of requests (S209) and completing the write processing for the total number of requests (YES in S209), the diagnostic results in the buffer areas 32-1 to 32-n are deleted (S210), and the flow is resumed. End (S211).

FIG. 8 is a flow chart showing the flow of diagnostic information management processing executed by the diagnostic information management section 12 called by the write API from the write request processing section 14 . The diagnostic result passed as an argument of the write API is accepted (S302), and the common diagnostic information area 31 in the core shared RAM 3 is updated (S303). Further, updating of the nonvolatile memory 4 is required depending on the type of diagnosis. If it is to be updated, the data (diagnosis result) in the nonvolatile memory 4 is updated (S304, S305), and the flow ends.

As described above, in the present embodiment, the processing related to writing to the common diagnostic information area 31 of the core-shared RAM 3 and accessing to the nonvolatile memory 4 are integrated into the core 1-1. Interference caused by accessing the common diagnostic information area 31 can be reliably avoided.

The effects of the system of this embodiment will be described with reference to FIGS. 9 and 10. FIG. FIG. 9 is a time chart for the system configuration shown in FIG. 2 as a comparative example, and FIG. 10 is a time chart for the system configuration shown in FIG. 4 of this embodiment. In either case, each core performs multiple diagnostic processes as scheduled tasks. In this example, core 1 executes diagnosis 1-1 to 3, core 2 executes diagnosis 2-1 to 3, and core n executes diagnosis n-1 to 2 in one cycle time. Each diagnostic process does not always reach the judgment every cycle, and a write request to the core-shared RAM 3 is made only when the judgment is reached. In this example, diagnosis 1-1 and diagnosis 2-2 in task N and diagnosis 1-3, diagnosis 2-3 and diagnosis n-2 in task (N+1) reach the judgment, and the diagnosis results are stored in the core shared RAM 3. I need to write to Thus, it is impossible to foresee in advance the timing at which a write request is generated in a scheduled task.

In the case of the comparative example (FIG. 9), task N succeeds in writing to the common diagnostic information area 31 of the core-shared RAM 3 without delay at the timing of the write request generated from each core. , the timings of write requests generated from each core interfere with each other, and it is necessary to arbitrate between write requests from each core. Therefore, the system will fail unless the task cycle time is set in consideration of the overhead for arbitration. On the other hand, in the case of the present embodiment (FIG. 10), the writing to the common diagnostic information area 31 of the core shared RAM 3 is collectively updated after the diagnostic processing of all the cores is completed, so the arbitration processing becomes unnecessary. there is Therefore, the task cycle time can be set so that the time required for writing to the common diagnostic information area 31 can be taken, and the cycle time can be set to a shorter time.

Embodiment 2 is a form suitable for developing software for a diagnostic module to be installed in a vehicle control device. In the first embodiment, the diagnosis module 11 and the request reception unit 13 are implemented in each core of the multi-core microcomputer applied to the vehicle control device. (Personal Computer)). Among the constituent elements of the present embodiment, the same reference numerals are given to the common parts with the first embodiment, and redundant explanations will be omitted.

FIG. 11 is a configuration example in which a vehicle control device 5 to which the multi-core microcomputer according to the second embodiment is applied and an environment in which part of the processing in the core 1 operates on the external environment 6 are combined. The configuration of the vehicle control device 5 is the same as that of the first embodiment. In this example, the core 1-1 is equipped with a test module 15 that triggers and executes a diagnostic module 61 under development in the external environment 6. FIG. On the other hand, the external environment 6 includes a diagnostic module 61 as a functional block functioning by executing a command, and a diagnostic result stored in the common diagnostic information area 31 of the core shared RAM 3 of the vehicle control device 5 from the diagnostic module 61. A request receiving unit 63 for receiving a reference request and a write request for writing the diagnostic result performed by the diagnostic module 61 to the core shared RAM 3 is provided. The request reception unit 63 has the same function as the request reception unit 13-i of each core 1-i. The core-shared RAM 3 is also provided with an external environment buffer area 33 for temporarily storing the diagnostic result executed by the diagnostic module 61 .

Thereby, the external environment 6 can be handled in the same manner as each core of the multi-core microcomputer of the vehicle control device 5 . A flow chart showing the flow of request acceptance processing executed by the request acceptance unit 63 is as shown in FIG. However, in the case of a write request, the buffer area 32 in the core shared RAM 3 storing the processing status becomes the buffer area of the core on which the test module 15 is mounted. Therefore, in this case, the data is written to the buffer area 32-1. Therefore, core information (in this case, information on the core 1-1) is delivered to the external environment 6 in advance from the test module 15, and is managed by the external environment 6. FIG. Acquisition of the storage time information (S105) is performed by capturing a free-run timer value provided by a timer manager in the vehicle control device, for example.

The processing status stored in the request receiving section is transferred to the diagnostic information managing section via the write request processing section. The write request processor monitors the end of each core process (S202). If the processing of all cores has not finished, the write request processing is terminated. The end of processing of the external environment can be determined by the end of processing of the core in which the test module is arranged.

The processing of the write request processing unit 14 and the processing of the diagnostic information management unit 12 are the same as in the first embodiment, and the diagnostic results from the diagnostic module 11 of each core 1 and the diagnostic results from the diagnostic module 61 of the external environment 6 are not distinguished. treated. Although this example shows an example in which the test module 15 is mounted on the core 1-1, it may be mounted on any core. In this case, the diagnostic result from the diagnostic module 61 of the external environment 6 is temporarily written in the buffer area assigned to the core on which the test module 15 is mounted.

In this way, API call conflicts or data conflicts can be avoided even when the vehicle control device is combined with the external environment.

1: core, 3: core shared RAM, 4: non-volatile memory, 5: vehicle control device, 6: external environment, 11, 61: diagnostic module, 12: diagnostic information management section, 13, 63: request reception section, 14: Write request processing unit 15: test module 31: common diagnostic information area 32: buffer area 70: diagnostic result 71: diagnostic ID 72: judgment result 73: environment information 74: storage time information 75 : Number of write requests.

Claims (9)

A microprocessor having a plurality of cores including a first core and memories readable and writable from the plurality of cores, wherein the microprocessor executes application software that utilizes software components provided by a software platform A vehicle control device,
the plurality of cores includes a module of the application software and a request reception unit that receives an API call of the software component from the module;
The first core includes the software component and a request processing unit that calls a first API to cause the software component to execute a first process of writing a processing result of the application software to a predetermined area of the memory. prepared,
The request reception units of the plurality of cores receive the first API call from the module and write the processing result of the module together with storage time information into a buffer area of the memory allocated for each core;
The request processing unit of the first core performs the first API call, writes the processing result of the module written in the buffer area of the memory allocated to each core based on the storage time information, A vehicle control device that writes to the predetermined area of the memory in chronological order . In claim 1,
The request receiving units of the plurality of cores receive, from the module, a second API call that causes the software component to execute a second process of reading a processing result of the application software from the predetermined area of the memory. , a vehicle control device for reading a processing result of the application software from the predetermined area of the memory; In claim 1,
The application software is software that executes a scheduled task that is executed within a predetermined cycle time,
The vehicle control device, wherein the request processing unit of the first core calls the first API after the processing of the plurality of cores in which the application software module is installed is completed for each cycle time. In claim 3,
The vehicle control device, wherein the request processing unit of the first core completes the first processing within the cycle time. In claim 1,
has a non-volatile memory,
The vehicle control device writes at least part of the processing result of the application software in the nonvolatile memory in the first processing. A vehicle control device having a microprocessor having a plurality of cores including a first core and memories readable and writable from the plurality of cores, wherein the microprocessor executes application software using software components provided from a software platform. A program execution method for executing,
The application software modules mounted on the plurality of cores make a first API call to cause the software component to execute a first process of writing a processing result of the application software to a predetermined area of the memory;
the request receiving unit mounted on the core that has made the first API call writes the processing result of the module together with storage time information into a buffer area of the memory allocated for each core;
The request processing unit mounted on the first core performs the first API call, and stores the processing result of the module written in the buffer area of the memory allocated for each core as the storage time information. a program execution method for writing to the predetermined area of the memory in time series based on the In claim 6 ,
The application software is software that executes a scheduled task that is executed within a predetermined cycle time,
The program execution method, wherein the request processing unit of the first core calls the first API after the processing of the plurality of cores on which the application software module is installed is completed for each cycle time. In claim 7 ,
The program execution method, wherein the request processing unit of the first core completes the first process within the cycle time. In claim 6 ,
The plurality of cores of the microprocessor includes a second core on which a test module is mounted,
the test module of the second core triggers an external environment to execute the application software module installed in the external environment;
A program execution method, wherein a processing result of a module of the application software installed in the external environment is written in a buffer area of the memory allocated to the second core.

Images