JP2012128788A - Vehicle control device and data communication method - Google Patents

Abstract

To provide a vehicle control device or the like in which a plurality of ECUs are integrated by suppressing modification of software before integration.
A vehicle control device 100 in which a first app executed by a first core and a second app executed by a second core transmit data to the outside, respectively, The communication means 36 for communicating with the device, the internal communication means 37 for data communication between the first core and the second core, and the first transmission data of the second application to the internal communication means instead of the communication means The destination information of the first transmission data indicates whether to output the output destination changing means 34 (2) to be output and the first transmission data acquired from the internal communication means to the first application or the communication means. Data transmission destination control means 34 (1) for controlling according to the registered list table.
[Selection] Figure 2

Description

  The present invention relates to an ECU that controls an in-vehicle device, and more particularly to an integrated ECU in which a plurality of ECUs are integrated.

  By reducing the number of ECUs (electronic control units) mounted on the vehicle, the development cost of the ECUs can be reduced. In this case, an application previously installed in a separate ECU is installed in one ECU. Need arises.

  FIG. 1A is an example of a diagram for explaining inconvenience caused by integration of the ECU. The ECU α executes the application A on the microcomputer, and the ECU β executes the application B on the microcomputer. An RTE (Runtime Environment) below the application A and the application B is a layer that provides a common function used by the applications A and B and passes data and events between the applications.

  The layer below the RTE is a communication module corresponding to the communication content of CAN communication, and COM, NM, and DiaCAN are illustrated. COM is a module that communicates general data, NM is a module that manages the network management function, and DiagCAN is a request for diagnostic information from a service tool (diagnostic tool that is externally connected to the CAN bus at a dealer's factory, etc.) It is a module that acquires diagnostic information from the app. Note that MCAL (Microcontroller Abstraction Layer) is a set of various drivers and hides hardware from the software side.

  FIG. 1B shows a configuration example of an ECU γ in which the ECU α and the ECU β are integrated into one ECU. The MCAL on the application A side and the MCAL on the application B side output a frame to the CAN bus in response to any request of COM, NM, or DiagCAN. As shown in FIG. 1B, if two or more channels are provided in the ECU γ for ECU integration, each of the two MCALs can output a CAN frame to the CAN bus, but there are many restrictions in reality. For example, the NMs of the ECUs α and β have a function of periodically transmitting NM frames to other ECUs on the CAN bus as one of the functions. Thereby, other ECUs that have not received the NM frame from the ECU γ can detect that the ECU γ is out of order. For this reason, in standards and in-house regulations, it may be determined that only one NM message should be output from one ECU to the CAN bus.

  In order to avoid this inconvenience, it can be considered that, for example, the developer deletes only the NM of ECUβ during integration. However, the application A and the application B originally have a function of notifying the NM that it is possible to sleep, and conversely, the NM (receives an NM message from the NM of another ECU). It is necessary to request the apps A and B to get up. This means that the apps A and B cannot operate without an NM API (Application Programming Interface), which means that it is difficult to delete only the NM. Application A and B need to be modified).

  Here, a technique has been devised that improves the portability of software without modifying existing software or suppressing modification (see, for example, Patent Document 1). In Patent Document 1, when a plurality of programs for a single processor are distributed to a plurality of processors, a pseudo part of each program is provided in each processor, and the programs distributed to different processors communicate with each other via the pseudo part. A communication method is disclosed.

JP-A-5-324574

  However, when the inter-processor communication method disclosed in Patent Document 1 is adopted, the developer needs to create as many pseudo-parts as the number of programs executed by the original single processor, and the development increases as the number of programs increases. The problem of increased costs is not solved. In addition, it is not considered to integrate a new program, and when a new program is integrated, there is a possibility that the development cost for constructing a relationship with a pseudo part of an existing program may become large.

  In view of the above problems, an object of the present invention is to provide a vehicle control device or the like in which a plurality of ECUs are integrated by suppressing modification of software before integration.

  The present invention is a vehicle control device in which a first app executed by a first core and a second app executed by a second core transmit data to the outside, respectively, and an external device via a bus Communication means for communicating, internal communication means for data communication between the first core and the second core, and the first transmission data of the second application not the communication means but the internal communication means The destination information of the first transmission data indicating whether to output the first transmission data acquired from the internal communication means to the first application or the communication means. Data transmission destination control means for controlling according to the registered list table.

  It is possible to provide a vehicle control device or the like in which a plurality of ECUs are integrated while suppressing modification of software before integration.

It is an example of the figure explaining the inconvenience which arises by integration of ECU. It is an example of the figure explaining the communication method of the application integrated in integrated ECU. It is an example of the hardware block diagram of integrated ECU. It is an example of a functional block diagram of one integrated ECU in which two ECUs α and β are integrated. It is an example of a driver table in which a relationship between a driver called by a PDU router and a data destination is registered. It is an example of the flowchart figure which shows the procedure in which the PDU router 1 and the PDU router 2 transmit or receive data. It is an example of the figure which shows the structural example of ECU in case the application AC communicates via RTE. (Example 2) which is an example of the functional block diagram of one integrated ECU with which two ECU (alpha), (beta) was integrated. It is an example of the figure which shows typically the procedure which an IPC-IF / IPC driver communicates. FIG. 10 is an example of a flowchart illustrating a procedure in which PDU router 1 and PDU router 2 transmit or receive data (second embodiment). It is an example of the figure explaining a data flow. It is an example of a functional block diagram of a multi-microcomputer. It is an example of a functional block diagram of a multi-microcomputer. FIG. 10 is an example of a flowchart illustrating a procedure in which PDU router 1 and PDU router 2 transmit or receive data (third embodiment).

Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.
FIG. 2 is an example of a diagram illustrating a communication method between cores integrated in the integrated ECU 100. In the integrated ECU (electronic control unit) 100 of FIG. 2, a PDU router is provided between the COM, NM, and DiaCAN (sometimes referred to as the communication module 33) layer and the MCAL35 (referred to as MCAL1, 2). (Protocol Data Unit Router) 34 is provided. The PDU router (referred to as PDU routers 1 and 2 when distinguished) is a layer for routing communication data.

  In addition, the MCAL 35 is provided with a DMA driver 38 (referred to as DMA drivers 1 and 2 for distinction) that requests communication from the DMA controller 37. The DMA driver 38 is also provided in the conventional MCAL, but the DMA driver 38 in FIG. 2 is designed so that the integrated ECU 100 can perform data communication between the applications 31 (referred to as applications A and B when distinguished). Yes.

  For example, when the communication module 33 requests the PDU router 2 to transmit communication data, the PDU router 2 calls the DMA driver 2 because the transmission destination is the application A. That is, by calling the DMA driver 2 instead of the CAN driver, the DMA controller 37 transfers data, and the core 36 (referred to as cores 1 and 2 when distinguished) can communicate with the other core 36. When viewed from the core 2, communication data is output to a virtual CAN bus 40 that does not actually exist instead of the CAN bus 39.

  The DMA driver 1 on the application A side detects that the data has been received by an interruption or the like of the DMA controller 37 and transmits the data to the PDU router 1. Since the transmission destination is the application A, the PDU router 1 transmits data to the application A via the RTE 32 (referred to as RTE 1 and 2 when distinguished).

  Further, for example, when the data destination of the application B is another ECU, when the DMA driver 1 on the application A side transmits the data to the PDU router 1, the PDU router 1 has the CAN driver because the destination is the other ECU. Call. By calling the CAN driver, the CAN controller 29 can output data to the CAN bus 39.

  In this way, by providing the PDU routers 1 and 2 and the DMA drivers 1 and 2 on the two integrated applications, respectively, and using the DMA controller 37, the applications A and B and the communication module 33 are not corrected. , B can communicate with each other. Further, for example, since the NM message output from the NM2 on the application B side is not output from the CAN bus 39, it is possible to output only one NM message from one ECU.

〔Constitution〕
FIG. 3 shows an example of a hardware configuration diagram of the integrated ECU 100. The integrated ECU 100 includes a processor 11, a DMA controller 37, an SDRAM 12, a CAN controller 29, an I / O 16, and a ROM 13 connected via the multilayer bus 14. The processor 11 includes two CPUs 15 (hereinafter referred to as CPUs 1 and 2 when distinguished), but the number of CPUs 15 may be four or more as long as it is two or more. Each CPU 1, 2 has a core 36, an inter-core communication unit 21, and a local RAM 36. In order to distinguish the functions of the CPUs 1 and 2, the same numbers as the CPUs 1 and 2 are assigned to the functions in the CPU.

  Cores 1 and 2 are PC (program counter), instruction buffer, IFU (Instruction Fetch Unit), DEC (DECoder), RF (Register Fetch), REG (REGister), SH (Shifter), ALU, MUL, FPU, etc. An arithmetic circuit, a general-purpose register, a load / store unit, and the like are included. By executing each stage of the instruction execution stage every clock, so-called pipeline control is realized.

  The ROM 13 stores applications A to C and a PF (Plat Form) 24. The apps A and B are apps installed in one ECU α before the two ECUs α and β are integrated, and the app C is an app installed in the other ECU β. The PF 24 provides an execution environment for the cores 1 and 2 to execute the applications A to C by absorbing differences in hardware. In this embodiment, the basic software standardized by AUTOSAR (AUTomotive Open System Architecture) will be described as an example. However, a simple OS can be used as long as the difference in hardware can be concealed.

  The PF 24 is composed of layers such as an RTE, a service layer, an ECU abstraction layer, and a MCAL (microcontroller abstraction layer) from the upper layer. The service layer is a layer that provides various services independent of hardware, such as OS (for example, OSEK (Open system together with interfaces for automotive electronics), other embedded OS, real-time OS, etc.), system service ( Diagnostic software, memory management software, etc.), memory service, and communication service (network management software (CAN, FlexRay, LIN, etc.) for in-vehicle LAN communication). The COM, NM, and DiaCAN communication modules 33 are included in the service layer.

  The ECU abstraction layer abstracts all basic components of the ECU, such as onboard equipment, memory hardware, communication hardware, and I / O hardware. The lowermost MCAL is a layer that abstracts all the functions and peripheral devices of the microcomputer of the ECU. The layer above MCAL is independent of the hardware of the microcomputer. In addition to the DMA driver 38 described above, the MCAL includes, for example, a memory driver, a communication driver, and an I / O driver.

  Although the number of PFs 24 is one in the figure, when the types of cores and microcomputers before integration are different, the PFs 24 before integration may also be different. In this case, each PF 24 is stored in the ROM 13.

  The core 1 executes the PF 24 and applications A and B stored in the ROM 13, and the core 2 executes the PF 24 and application C stored in the ROM 13. The local RAM 1 is a memory (primary cache) dedicated to the core 1, and the local RAM 2 is a memory dedicated to the core 2. The SDRAM 12 is a memory (secondary cache) for providing programs or data to the cores 1 and 2. At least a part of the SDRAM 12 is shared by the cores 1 and 2.

  The inter-core communication units 1 and 2 enable the cores 1 and 2 to interrupt and communicate with each other via the core communication bus 16. The cores 1 and 2 can monitor the presence / absence of other cores by the inter-core communication units 1 and 2 and can communicate data with each other via the local RAMs 1 and 2. The cores 1 to 3 can also communicate with each other via the multilayer bus 14.

  The multi-layer bus 14 includes a total of four layers for the CPU 1, the CPU 2, and the DMA controller 37 for reading and writing. The DMA controller 37 arbitrates access requests to the SDRAM 12 from each block connected to the multi-layer bus 14, and from the SDRAM 12 to the local RAMs 1 and 2 (or from the local RAMs 1 and 2 to SDRAM), and from the I / O 16 to the SDRAM 12 The data is transferred without going through the cores 1 and 2 (or from SDRAM to I / O). The DMA controller 37 can appropriately interrupt the cores 1 and 2 upon completion of the transfer.

  The CAN controller 29 is a communication controller that performs communication processing in accordance with the CAN protocol, and may have a communication controller for FlexRay or LIN. The I / O 16 is an interface for connecting a microcomputer and an external device, to which various sensors, actuators, and the like are connected.

  FIG. 4 is an example of a functional block diagram of one integrated ECU 100 in which two ECUs α and β are integrated.

  The app A and the app B may be an app in which one uses the calculation result of the other, and the app B may be weakly linked to the app A and B like a simple idle task. In the former case, the application A or B notifies the event or data via the RTE 32 and is called and executed. The application C is an application specific to the ECU β. However, if the applications A and B are body systems, the application C may be an application that has a strong connection like the body system, or may be an unrelated application.

  The communication module 33 has COM, NM, and DiagCAN. As described with reference to FIG. 1, COM is general data, NM is data for network management functions, and DiaCAN is data necessary for service tools. It is a module to do. These communication modules perform communication processing according to a protocol (for example, CAN, FlexRay, Lin). Further, the communication module creates a CAN frame or the like in a format determined by the communication module, such as COM, NM, and DiaCAN. At the time of reception, data to be received is selectively received based on CANID. Which communication module of COM, NM, and DiaG should be processed is determined from CANID.

  Note that NM is a module that performs communication based on OSEK / VDX-NM (Network Management) regulations. In OSEK-NM, each ECU connected to one in-vehicle LAN is determined to determine whether or not it can sleep and periodically transmit an NM (Network Management) message indicating whether or not to sleep to the network bus. ing. Note that the NM message is merely an expression of a CAN message, and the format and transmission procedure conforms to the CAN protocol. However, the NM message has a feature such that it is periodically transmitted. Therefore, a message based on OSEK-NM is called an NM message.

  The NMs 1 and 2 determine whether or not the apps A, B, or C can sleep at every predetermined cycle, and transmit NM messages indicating whether sleep is possible or not to other ECUs in a predetermined order. When each ECU receives the NM message, the other ECUs store whether or not sleep is possible, and when all ECUs connected to the in-vehicle LAN are allowed to sleep, the process of shifting to the sleep mode is started. Therefore, it is possible to detect that there is an abnormality in the other ECU by not receiving the NM message from the other ECU that should be received even though it is not in the sleep mode.

  The NM may transmit an NS (Network Status) message in addition to the NM message, but it can be handled in the same manner as the NM message, and is omitted here.

  The PDU router 34 controls the data transmission destination. The functions differ between the PDU router 1 of the core 1 that can control the CAN controller 29 and the PDU router 2 of the core 2 that cannot directly control the CAN controller 29.

  Since the PDU router 2 cannot call the CAN driver 38 at the time of data transmission, it is necessary to mechanically transfer all CAN frames to the PDU router 1. The PDU router 2 calls the DMA driver 2 when communication is requested from any of the COM, NM, and DiaCAN communication modules.

  When the PDU router 2 receives data from the DMA driver 2, the destination is one of the communication modules 33, so the data is transferred to the communication module 33.

  Even when the core 2 executes the fourth application D, since the core 2 cannot control the CAN controller 37, the function of the PDU router 2 is the same.

Next, the PDU router 1 will be described.
-When transmitting from the PDU router 1 When the PDU router 1 is requested to transmit data from any one of the communication modules 33 of COM, NM, and DiaCAN, the data received by the ECU β is simply output to the CAN bus 39. Core 2 cannot receive. Therefore, the PDU router 1 calls both the CAN driver 1 and the DMA driver 1 when transmitting data. Whether or not to receive data may be determined by the communication module 33 of the core 2.

Alternatively, the CANID received by the ECU β before integration may be listed, and the DMA driver 1 may be called when the PDU router 1 accepts the transmission of data of the CANID.
At the time of reception by the PDU router 1 The PDU router 1 may receive data via the CAN driver or the DMA driver 1 in some cases. When data is received via the CAN driver, the CAN frame is stored in the reception buffer or the like as before the integration, and the communication module 33 such as COM, NM, and DiaCAN determines whether or not the data should be received. Therefore, the PDU router 1 outputs all data received via the CAN driver to the communication module 33.

  Moreover, the core 2 cannot receive the data that the ECU β received from the ECU α before the integration only by outputting it to the communication module 33. Therefore, the PDU router 1 outputs data to the DMA driver 1 when receiving data via the CAN driver. Whether or not to receive data may be determined by the communication module 33 of the core 2. Also in this case, the CANID received by the ECU β before the integration may be listed, and the DMA driver 1 may be called only when the PDU router 1 accepts the transmission of the data of the CANID.

  When data is received via the DMA driver 1, the PDU router 1 prohibits at least outputting the NM message to the CAN bus. For this reason, a CAN frame (or a CAN frame that should not be transferred) that a developer or the like may transfer to the CAN bus is registered in advance in the transfer list table.

  FIG. 5 shows an example of the transfer list table. In the transfer list table, CANIDs that should not be transferred are registered. This CANID includes the CANID of the NM message. When the PDU router 1 receives data via the DMA driver 1, the PDU router 1 calls the CAN driver and transfers only the data whose transfer is not prohibited by the transfer list table to the CAN bus 39.

  Moreover, the core 1 cannot receive the data that the ECU α has received from the ECU β before the integration only by outputting to the CAN bus 39. Therefore, the PDU router 1 outputs data to the communication module 33 when receiving data via the DMA driver 1. The communication module 33 of the core 1 may determine whether to receive data.

  The CAN driver is the same as before integration. The CAN driver is an interface independent from the CAN controller 29 that is hardware, and provides basic functions such as initialization of the CAN controller 29 and transmission / reception of CAN messages.

  The DMA drivers 1 and 2 are interfaces that are independent of the DMA controller 37 that is hardware, and cause the DMA controller 37 to transmit data and receive the data transferred by the DMA controller 37.

  The DMA driver 1 stores data acquired from the communication module in the local RAM 1. Therefore, if this data is transmitted to the local RAM 2, the data is transferred from the core 1 to the core 2. The reverse is true for the DMA driver 2. In both the local RAMs 1 and 2, addresses of a transmission buffer and a reception buffer for transmitting a CAN frame are determined in advance. Both the transmission buffer and the reception buffer are FIFO type buffers.

  The DMA driver 38 is modified so that data can be transferred from the local RAM 1 to the local RAM 2 via the SDRAM 12 (or vice versa) when called from the PDU router 34.

  The DMA driver 1 sets the start address of the transmission buffer of the local RAM 1 in the transfer source address register of the DMA controller 37, and the transfer count required from the data length or the like in the transfer count register of the DMA controller 37 (or in the transfer end address register). The last address of the frame may be set), and the start address of the shared area of the SDRAM 12 is set in the transfer destination address register of the DMA controller 37 and transmitted to the DMA controller 37.

  When the transfer is completed, the DMA controller 37 interrupts and notifies the core 2 so that the DMA driver 2 of the core 2 can read the CAN frame from the shared area of the SDRAM 12.

  The same applies to the DMA driver 2. The DMA driver 2 stores the CAN frame acquired from the PDU router 2 in the local RAM 2. The DMA driver 2 sets the start address of the transmission buffer of the local RAM 2 in the transfer source address register of the DMA controller 37, the transfer count required from the data length and the like in the transfer count register of the DMA controller 37, and the start address of the shared area of the SDRAM 12 Are set in the transfer destination address register of the DMA controller 37 and transmitted.

  When the transfer is completed, the DMA controller 37 interrupts and notifies the core 2 so that the DMA driver 2 of the core 2 can read the CAN frame from the shared area of the SDRAM 12.

  Note that data may be transferred between the local RAMs 1 and 2 without going through the SDRAM 12. In this case, a driver necessary for inter-core communication may be used instead of the DMA driver 38, such as using a driver of the inter-core communication unit 21.

  As described above, it is possible to integrate the two ECUs α and β by only modifying the PDU routers 1 and 2 and the DMA driver 38 without losing the portability of the apps A and B.

<Operation procedure>
FIG. 6 is an example of a flowchart illustrating a procedure in which the PDU router 1 and the PDU router 2 transmit or receive data. The procedure of FIG. 6 starts when the PDU router 1 or the PDU router 2 acquires data.

  The PDU router 1 will be described. First, the PDU router 1 acquires data (S10). When acquiring data, there are a case where data for transmission is acquired from the application A or the application B, and a case where data for reception is acquired from the CAN driver 1 or the DMA driver 1. Whether data is transmitted or received is determined based on whether the PDU router 1 has acquired data from the application side or the driver side.

  When receiving data (Yes in S20), the PDU router 1 determines whether or not the data has been acquired from the DMA driver 1 (S30).

  When the data is acquired from the DMA driver 1 (Yes in S30), the PDU router 1 refers to the transfer list table to refer to the transfer list table to prohibit the transfer of the NM message and calls the CAN driver to the CAN bus except for the transmission prohibited data. Transfer (S40).

  Subsequently, the PDU router 1 outputs data to the communication module 33 regardless of whether the data is acquired from the DMA driver 1 or the CAN driver (S50). The communication module 33 determines whether or not reception is necessary based on the CANID, and outputs to the application A or the application B via the RTE 32 if necessary.

  Further, since the data acquired from the CAN driver by the PDU router 1 may be addressed to the application C, the PDU router 1 calls the DMA driver 1 (S60). As a result, the DMA driver 1 transmits data to the DMA driver 2 using the DMA controller 37.

  At the time of data transmission (No in S20), the PDU router 1 calls the CAN driver (S70). As a result, the CAN driver 1 transmits data to the CAN bus 39 using the CAN controller 29.

  Further, since there is a possibility that the transmission data acquired by the PDU router 1 is addressed to the application C, the PDU router 1 calls the DMA driver 1 (S80). As a result, the DMA driver 1 transmits data to the DMA driver 2 using the DMA controller 37.

  Next, the PDU router 2 will be described. First, the PDU router 2 acquires data (S110). When the PDU router 2 acquires data, there are a case where data for transmission is acquired from the application C and a case where data for reception is acquired from the DMA driver 2. Whether data is transmitted or received is determined by whether the PDU router 2 has acquired data from the application side or the driver side.

  When receiving data (Yes in S110), the PDU router 2 outputs the data to the communication module 33 (S120). The communication module 33 determines whether reception is necessary based on CANID.

  At the time of data transmission (No in S110), the PDU router 2 calls the DMA driver 2 (S130). As a result, the DMA driver 2 transmits data to the DMA driver 1 using the DMA controller 37.

<Effect>
According to the integrated ECU 100 as described above, even if the NM message transmitted by the application C is transmitted to the application A or B, it is not output to the CAN bus 39. Therefore, one NM message output from one ECU is provided. Can be.

  Further, it is not necessary to modify the applications A to C, and the modification target can be limited to the DMA drivers 1 and 2 and the PDU routers 1 and 2. Therefore, the portability of the apps A to C can be maintained.

Another effect is that the utilization efficiency of the CPU 15 is not easily lowered.
FIG. 7A is an example of a diagram illustrating a configuration example of the integrated ECU when the applications A to C communicate via the RTE 32. Since the RTE 32 has a function of transmitting and receiving events and data between applications, it is possible to integrate two ECUs without using the DMA drivers 1 and 2 as shown in the figure.

  App A can communicate with app B, and app A can communicate with app C via RTE. Further, the data received by the communication module (COM) from the CAN bus 39 can be transmitted to the application C by the communication module via the RTE 32. However, when the method of absorbing all the effects of integration in RTE 32 is adopted, it means that apps A and B access local RAM 2 of core 2 and app C accesses local RAM 1 of core 1. This means that exclusive control is required for .about.C. Since the exclusive application is not executed (the process cannot proceed), the utilization efficiency of the CPU 15 decreases. In contrast, the integrated ECU 100 of the present embodiment does not cause such inconvenience.

Further, there is an effect that the power consumption of the integrated ECU 100 can be reduced.
FIG. 7B is an example of a diagram schematically illustrating the relationship between the four cores 1 to 4 and the applications A to H. The core 1 executes the apps A and B, the core 2 executes the apps C and D, the core 3 executes the apps E and F, and the core 4 executes the apps G and H. For example, when the app D communicates only with the apps E and F and the app C communicates only with the app F (not communicating with the outside), the communication is completed in the core 2 and the core 3. For this reason, when the sleep conditions are established in the applications C, D, E, and F, the cores 2 and 3 can be stopped, and low power consumption can be easily achieved. More specifically, as shown in FIG. 7A, when the RTE 32 is responsible for communication between the applications C, D, E, and F, even if the applications C, D, E, and F satisfy the sleep condition, Since the RTE 32 needs to be activated, the cores 2 and 3 cannot be stopped, and the power consumption cannot be reduced. In the present embodiment, since the RTE 32 can also be stopped in units of cores, it becomes easy to reduce the power consumption of the integrated ECU 100.

  In the first embodiment, the integrated ECU 100 is configured by performing inter-core communication using the DMA drivers 1 and 2. In this embodiment, the inter-core communication by the IPC-IF 41 / IPC driver 42 will be described for the integrated ECU 100.

  FIG. 8 is an example of a functional block diagram of one integrated ECU 100 obtained by integrating two ECUs α and β. In FIG. 8, the description of the same part as in FIG. 4 is omitted. In FIG. 8, an IPC-IF (InterProcess Communication Interface) 1 / IPC (InterProcess Communication) driver 1 is arranged instead of the DMA driver 1, and an IPC-IF2 / IPC driver 2 is arranged instead of the DMA driver 2.

  A local RAM 1 is arranged instead of the DMA controller 37. In the configuration of FIG. 8, the core 1 and the core 2 communicate via the FIFO-type transmission queue, the reception queue, and the local RAM 1.

The IPC-IF 41 outputs a reception completion notification to the application side when data arrives in the reception queue and the function of registering data in the transmission queue 43.
The IPC driver 42
Register the data stocked in the transmission queue in the local RAM 1.
Write the data stored in the shared RAM to the reception queue.

  FIG. 9 is an example of a diagram schematically illustrating a procedure in which the IPC-IF1 / IPC driver 1 and the IPC-IF2 / IPC driver 2 communicate with each other. FIG. 9 shows an example of NM periodic communication. FIG. 9A shows a transmission procedure from the core 1 to the core 2, and FIG. 9B shows a transmission procedure from the core 2 to the core 1.

This will be described with reference to FIG.
(1) First, when transmission registration is performed from the NM1 to the PDU router 1, data is registered on the IPC-IF1 side based on the routing information of the CANID statically set in the PDU router.
(2) The PDU router 1 of the core 1 wakes up the IPC driver 1.
(3) The IPC driver 1 reads the data in the transmission queue 43 and stores it in the local RAM 1.
(4) The PDU router 2 of the core 2 wakes up the IPC driver 2.
(5) The IPC driver 2 reads the data in the local RAM 1 and registers the data in the PDU router 2. On the PDU router side, registration is made in the reception queue 44 of the IPC-IF 2 based on the routing information of the CANID set statically.
(6) The PDU router 2 notifies the NM 2 of a reception completion notification.

  Since FIG. 9B only reverses the procedure, the description is omitted. 9A and 9B both use the local RAM 1 as a shared RAM, some kind of exclusive control is required. In the present embodiment, for example, the semaphore is used, and the one that acquires the semaphore among the IPC drivers 1 and 2 obtains the right to use the local RAM 1.

  FIG. 10 is an example of a flowchart illustrating a procedure in which the PDU router 1 and the PDU router 2 transmit or receive data. The procedure shown in FIG. 10 is almost the same as the procedure shown in FIG. 6 except that the PDU router 34 calls the DMA driver 38 or the IPC-IF 41 / IPC driver 42.

  As described above, if the driver enables communication between applications (between processes), the DMA controller 37 does not need to be used, and the integrated ECU 100 capable of communication between applications as in the first embodiment can be realized. it can.

FIG. 11 is an example illustrating a data flow. FIG. 11 illustrates an example of a procedure in which the COM of the communication module 33 communicates.
・ App B → App A
(A1) Since the data data_a to be transmitted by the application C is generated, it is transmitted to the COM via the RTE 32. The “common CS (Communication Stack)” is a function (software) that performs communication processing using the COM, the IPC-IF 41, and the IPC driver 42 that is common to each core.
(A2) The COM generates a message and transmits it to the PDU router 2.
(A3) The PDU router 2 registers the message in the transmission queue 43 of the IPC-IF2.
(A4) The IPC driver 2 reads a message from the transmission queue 43 and writes it in the local RAM 1.
(A5) The IPC driver 1 reads a message from the local RAM 1 and registers it in the reception queue 44 of the IPC-IF 1.
(A6) The IPC-IF 1 notifies the PDU router 1 of a reception completion notification and a message. The PDU router can sort the data, but in the figure, the data is output to the COM side of the communication module 33.
(A7) COM1 outputs data to application A.
Application A → CAN bus (B1) When data data_b to be transmitted by application A is generated, it is transmitted to COM1 via RTE1.
(B2) COM1 generates a message and outputs it to the PDU router 1.
(B3) The PDU router 1 outputs the message B to the CAN I / F 45 and IPC-IF1. In the figure, output to the IPC-IF1 side is omitted. CAN
The I / F 45 outputs a reception completion notification to the PDU router 1 when the data arrives in the transmission queue and the reception queue (B4). The CAN I / F 45 outputs a message B to the CAN driver. .
(B5) The CAN driver outputs the frame B to the CAN bus 39 using the CAN controller 29.

  As described above, by using the IPC-IF 41 / IPC driver 42 without using the DMA controller 37, it is possible to make one NM message output from one ECU as in the first embodiment. The portability of the apps A to C can be maintained. Further, the utilization efficiency of the CPU 15 is not lowered, and the power consumption is easily reduced.

  In the first and second embodiments, a single integrated ECU 100 is realized by integrating a plurality of ECUs into a single microcomputer including a multi-core type processor. In this embodiment, an integrated ECU 100 in which a plurality of microcomputers are integrated into one ECU will be described. There are two configurations of the integrated ECU 100 that leaves the framework of the microcomputer.

  FIG. 12 is an example of a functional block diagram of the multi-microcomputer. In FIG. 12, the description of the same part as in FIG. 4 is omitted. In FIG. 12, since the microcomputer 51 (referred to as microcomputers 1 and 2 when distinguished) is mounted on the integrated ECU 100, the microcomputers 1 and 2 are arranged in the lowest layer. The microcomputers 1 and 2 communicate with each other by the DMA controller 37. However, if the microcomputers 1 and 2 can communicate with each other, they can communicate with each other via a shared memory (IPC-IF41 / IPC driver 42) or a dedicated communication line. Good. Since the communication procedure in the case of a multi-microcomputer as shown in FIG.

  FIG. 13 is an example of a functional block diagram of the multi-microcomputer. In FIG. 13, the description of the same parts as in FIG. 4 is omitted. Since one microcomputer 51 normally has a plurality of channels, even if one of the channels on the microcomputer 2 side is assigned to the DMA controller 37, a channel remains. Moreover, there is no problem even if a single ECU outputs a plurality of messages other than NM messages. Therefore, another channel of the microcomputer 2 is assigned to the CAN controller 29. By doing so, the microcomputers 1 and 2 need only process the NM message in the integrated ECU 100.

  That is, the PDU router 2 calls the DMA driver 2 when it is determined as an NM message from the CANID, or when data is received from the communication module 33, and calls the CAN driver 2 in other cases. The DMA driver 1 of the PDU router 1 receives data and outputs it to the PDU router 1 as in the first embodiment. Since the PDU router 1 is an NM message, the data is output only to the communication module 33 without being output to the CAN bus 39. By doing so, the integrated ECU 100 having the two microcomputers 1 and 2 can prevent a plurality of NM messages from being output to the CAN bus 39.

  Since both the microcomputers 1 and 2 have the CAN controller 29, the PDU router 1 can communicate with the microcomputer 2 internally by the DMA driver 1 or with the microcomputer 2 via the CAN bus 39. . If communication with the microcomputer 2 is designed to use the CAN bus 39 in the same manner as before integration, the distribution of CAN frames required by the PDU routers 1 and 2 can be further reduced.

  FIG. 14 is an example of a flowchart illustrating a procedure in which the PDU router 1 and the PDU router 2 transmit or receive data. Steps different from the procedure of FIG. 6 in the procedure of FIG. 14 will be described.

  First, as in the first embodiment, when receiving data, when the PDU router 1 acquires data from the DMA driver 1 (Yes in S30), the PDU router 1 prohibits the transfer of the NM message. The CAN driver is called up and transferred to the CAN bus 39 except for the data prohibited for transmission (S40).

  Further, the PDU router 1 outputs data to the communication module 33 regardless of whether the data is acquired from the DMA driver 1 or the CAN driver (S50). Thereafter, unlike the first embodiment, since the microcomputer 2 has the CAN controller 2, the data addressed to the application C is directly received by the microcomputer 2. For this reason, it is not necessary for the PDU router 1 to call the DMA driver 1.

  When data is transmitted (No in S20), the PDU router 1 calls the CAN driver (S80), but the data addressed to the application C may be transmitted to the microcomputer 2 via the CAN bus. There is no need to call driver 1.

  In the case of the PDU router 2, when data is received (Yes in S120), the PDU router 2 outputs data to the communication module 33 (S130), so there is no change at the time of reception.

  At the time of data transmission (No in S120), the PDU router 2 determines whether the data is an NM message in order to distribute the MN data to the DMA driver 2 (S125). The PDU router 2 calls the DMA driver 2 only for the MN message (S140). The PDU router 2 calls the CAN driver 2 for data other than the MN message (S150). Thereby, the microcomputer 2 can transmit only the NM message to the microcomputer 1 internally.

  As described above, in the case of the multi-microcomputer, the integrated application can communicate similarly to the first and second embodiments, and the communication of the application can be realized more easily than the first and second embodiments.

11 Processor 22 Local RAM 29 CAN Controller 31 Application 32 RTE 33 Communication Module 34 PDU Router 35 MCAL 36 Core 37 DMA Controller 38 DMA Driver 39 CAN Bus 40 Virtual CAN Bus 51 Microcomputer 100 Integrated ECU

Claims (9)

The first application executed by the first core and the second application executed by the second core are vehicle control devices that transmit data to the outside, respectively.
A communication means for communicating with an external device via a bus;
Internal communication means for communicating between the first core and the second core;
Output destination changing means for outputting the first transmission data of the second application to the internal communication means instead of the communication means;
Controls whether to output the first transmission data acquired from the internal communication means to the first application or the communication means according to a list table in which transmission destination information of the first transmission data is registered. Data transmission destination control means;
A vehicle control device. The data transmission destination control means outputs the second transmission data acquired from the first application to the communication means and the internal communication means,
The communication means transmits the second transmission data to the outside, and the internal communication means transmits the second transmission data to the second core;
The vehicle control device according to claim 1. When the communication means receives received data from the outside,
The data transmission destination control means outputs the received data to the first application and outputs to the internal communication means,
The internal communication means transmits the received data to the second core;
The vehicle control apparatus according to claim 1 or 2, wherein The internal communication means uses a DMA controller and a shared memory, or uses a driver for internal communication and a local RAM of the first or second core, and uses the first core and the second core. Communicate between cores,
The vehicle control device according to any one of claims 1 to 3, wherein In the list table, an NM message based on the specification of OSEK / VDX-NM (Network Management) is registered as the first transmission data to be prohibited from being output to the communication means,
The data transmission destination control means does not output the NM message to the communication means, but outputs only to the first application.
The vehicle control device according to any one of claims 1 to 4, wherein The vehicle control device is an electronic control unit in which a processor having a plurality of cores is arranged in one microcomputer.
The vehicle control device according to any one of claims 1 to 5, wherein The vehicle control device is an electronic control unit including a plurality of microcomputers in which a processor having one or more cores is arranged in the microcomputer.
The first microcomputer and the second microcomputer are respectively connected to different communication means;
The output destination changing unit outputs the first transmission data to the internal communication unit only when the first transmission data is predetermined predetermined transmission data, and the first transmission data other than the predetermined transmission data is output to the first transmission data. Output to the communication means connected to the microcomputer of 2,
The vehicle control device according to claim 1. The data transmission destination control means outputs the second transmission data acquired from the first application only to the communication means connected to the first microcomputer,
The second application receives the second data via the communication means connected to the second microcomputer;
The vehicle control device according to claim 7. A data communication method in which a first application executed by one core of an electronic control device and a second application executed by a second core respectively communicate data with the outside,
The second application generating first transmission data;
An output destination changing unit outputting the first transmission data to the internal communication unit instead of the communication unit;
The internal communication means transmitting the first transmission data to the first core;
The data transmission destination control unit controls whether the first transmission data is output to the first application or the communication unit according to a list table in which transmission destination information of the first transmission data is registered. Steps,
A data communication method comprising:

Images