Electronic control device, vehicle information provision method, and vehicle information provision program

Abstract

To provide a device, a method, and a program that allow each of a plurality of applications to easily and appropriately utilize vehicle information based on data that conforms to a predetermined communication protocol.SOLUTION: A car data coder 12, which is a middleware layer of an electronic control device within a vehicle, includes: a data extraction unit 12a that extracts data from a data frame that conforms to a predetermined communication protocol; a vehicle information generation unit 12b that generates vehicle information based on the data extracted by the data extraction unit; a vehicle information storage unit 12c that stores vehicle information generated by the vehicle information generation unit; and a vehicle information provision unit 12g that provides the vehicle information stored in the vehicle information storage unit to a requesting application that has requested provision of the vehicle information.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an electronic control device, a vehicle information providing method, and a vehicle information providing program. [Background technology]

[0002] BACKGROUND ART In a vehicle control system, for example, a configuration is provided in which an electronic control unit (hereinafter referred to as an ECU (Electronic Control Unit)) is connected to a CAN (Controller Area Network) (registered trademark) bus (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2011-218974 Summary of the Invention [Problem to be solved by the invention]

[0004] When an ECU is connected to a CAN bus and a control unit installed in the ECU executes multiple applications, each of the applications extracts CAN data from the CAN frame and generates vehicle information based on the extracted CAN data. However, when multiple applications generate vehicle information separately, a program module for generating vehicle information must be prepared for each application, resulting in problems such as increased costs and a great deal of effort when developing the applications. Furthermore, storing the program modules for each application unnecessarily consumes memory capacity. Furthermore, if the logic for generating vehicle information based on CAN data differs between applications, there is a risk that different vehicle information will be generated from the same CAN data. Using this different vehicle information could result in malfunctions between the applications.

[0005] The present invention has been made in consideration of the above-mentioned circumstances, and its purpose is to provide an electronic control device, a vehicle information provision method, and a vehicle information provision program that allow each of multiple apps to easily and appropriately use vehicle information based on data that conforms to a specified communication protocol. [Means for solving the problem]

[0006] According to the invention described in claim 1, the vehicle information generating unit (12b) generates vehicle information based on the data extracted by the data extracting unit. The vehicle information storing unit (12c) stores the vehicle information generated by the vehicle information generating unit. The update presence / absence determining unit (12e) determines whether the vehicle information stored in the vehicle information storage unit has been updated. The vehicle information providing unit (12g) When the vehicle information stored by the vehicle information storage unit is determined to be updated by the update presence / absence determination unit, The vehicle information stored in the vehicle information storage unit is provided to the application that has requested the provision of the vehicle information.

[0007] Data is extracted from a data frame that conforms to a predetermined communication protocol, vehicle information is generated and saved based on the extracted data, and the saved vehicle information is provided to the requesting application that requested the provision of the vehicle information.

[0008] This eliminates the need to prepare a program module for generating vehicle information for each app, which reduces the cost and effort required to create apps and reduces storage memory consumption. Furthermore, it eliminates the risk of generating different vehicle information from the same data that conforms to a specific communication protocol, which can lead to problems with inter-app operation. This allows multiple apps to easily and appropriately use vehicle information based on data that conforms to a specific communication protocol.

[0009] In addition to the inventions set forth in the claims, the present disclosure includes the following inventions. [1] An electronic control device (1) having a control unit (6) that executes multiple applications, a data extraction unit (12a) for extracting data from a data frame conforming to a predetermined communication protocol; a vehicle information generating unit (12b) that generates vehicle information based on the data extracted by the data extracting unit; a vehicle information storage unit (12c) for storing the vehicle information generated by the vehicle information generation unit; and a vehicle information providing unit (12g) that provides the vehicle information stored in the vehicle information storage unit to an application that has requested the provision of the vehicle information.

[0010] [2] a registration request receiving unit (12d) that receives a registration request from each of the plurality of applications; The vehicle information providing unit provides the vehicle information stored in the vehicle information storage unit to the application for which the registration request has been accepted by the registration request accepting unit. [1]

[0011] [3] an update determination unit (12e) that determines whether the vehicle information stored by the vehicle information storage unit has been updated; The vehicle information providing unit is configured to provide the vehicle information stored in the vehicle information storage unit to the requesting application that requested the provision of the vehicle information when the vehicle information stored in the vehicle information storage unit is updated by the update determination unit. [1] or [2] An electronic control device as described in

[0012] [4] a provision request receiving unit (12f) that receives a provision request from each of the plurality of applications; An electronic control device as described in any one of [1] to [3], wherein the vehicle information providing unit, upon receipt of a provision request from an app by the provision request receiving unit, provides the vehicle information stored in the vehicle information storage unit to the requesting app that requested the provision of the vehicle information.

[0013] [5] The electronic control device according to any one of [1] to [4], wherein the data extraction unit, the vehicle information generation unit, the vehicle information storage unit, and the vehicle information provision unit are executed by the control unit.

[0014] [6] The electronic control device according to any one of claims [1] to [5], wherein the vehicle information providing unit provides vehicle information of different granularities to an application that has requested the provision of the vehicle information. [Brief explanation of the drawings]

[0015] [Figure 1] Functional block diagram illustrating one embodiment. [Figure 2] Diagram explaining protocol conversion [Figure 3] Diagram showing the flow when receiving a CAN frame [Figure 4] Car Data Code functional block diagram [Figure 5] A diagram showing the flow when generating vehicle information [Figure 6] CAN data and vehicle information diagram [Figure 7] Vehicle information list [Figure 8] Vehicle information list [Figure 9] Vehicle information list [Figure 10] A diagram showing the service offering list [Figure 11] Flowchart showing registration request acceptance processing [Figure 12] Flowchart showing vehicle information storage processing [Figure 13] Flowchart showing update processing [Figure 14] Flowchart showing provision request acceptance processing [Figure 15] Sequence diagram [Figure 16] Sequence diagram [Figure 17] Sequence diagram [Figure 18]Sequence diagram DETAILED DESCRIPTION OF THE INVENTION

[0016] An embodiment will be described below with reference to the drawings. As shown in Fig. 1, a master ECU 1 mounted on a vehicle controls the vehicle by acquiring information from, for example, a powertrain ECU, a body ECU, a cockpit ECU, a chassis ECU, and a safety ECU, or by issuing commands to each ECU. To achieve this, the master ECU 1 includes multiple applications and multiple middleware programs. The master ECU 1 functions as an update master that manages reprogramming for the purpose of, for example, improving functionality or repairing defects.

[0017] The master ECU 1 is connected to the plurality of ECUs 3 and 4 via a CAN bus 2 (Controller Area Network) (registered trademark) (corresponding to a communication bus) so as to be able to communicate data with the plurality of ECUs 3 and 4, and performs integrated management of the plurality of ECUs 3 and 4 by issuing operation instructions to the plurality of ECUs 3 and 4 and acquiring operation states from the plurality of ECUs 3 and 4. The number of ECUs connected to the master ECU 1 via the CAN bus 2 is not limited to two and can be any number. The plurality of ECUs 3 and 4 may be, for example, a powertrain ECU, a body ECU, a cockpit ECU, a chassis ECU, a safety ECU, etc.

[0018] The master ECU1 is connected to a DCM (Data Communication Module) that functions as a data communication device. The DCM can send and receive data by wirelessly connecting to the outside world via a communication network. The DCM can receive distribution packages sent from an OTA center by wirelessly connecting to the OTA center via a communication network. When the DCM receives a distribution package sent from the OTA center, it transfers the received distribution package to the master ECU1. The master ECU1 identifies a reprogramming target ECU from among multiple ECUs that functions as a reprogramming target, and when the distribution package is transferred from the DCM, it extracts an update program from the transferred distribution package and performs reprogramming by instructing the reprogramming target ECU to write the extracted update program.

[0019] The master ECU 1 includes a first control unit 5, a second control unit 6 (corresponding to a control unit), and a storage 7. The first control unit 5 and the second control unit 6 are each configured by a microcomputer having a CPU (Central Processing Unit). The master ECU 1 includes a ROM (Read Only Memory), a RAM (Random Access Memory), and an I / O (Input / Output). The first control unit 5 and the second control unit 6 each execute a control program stored in a non-transitory physical storage medium to perform processing corresponding to the control program, and cooperate to control the overall operation of the master ECU 1. The control program executed by the second control unit 6 includes a vehicle information provision program.

[0020] The first control unit 5 is connected to the ECUs 3 and 4 via the CAN bus 2, and performs data communication with the ECUs 3 and 4 in accordance with the CAN protocol (corresponding to a predetermined communication protocol). The first control unit 5 and the second control unit 6 are connected via Ethernet 8, and perform data communication between them in accordance with the Ethernet protocol. That is, the first control unit 5 is directly connected to the CAN bus 2. The second control unit 6 is not directly connected to the CAN bus 2, but is connected to the CAN bus 2 via the Ethernet 8. Data communication using the Ethernet protocol is faster and larger in capacity than data communication using the CAN protocol. The first control unit 5 and the second control unit 6 correspond to multiple CPUs.

[0021] In the hardware architecture of the master ECU 1, the first CPU is connected to the CAN bus 2 and is configured to directly access the CAN bus 2, while the second CPU is not connected to the CAN bus 2 and is configured not to directly access the CAN bus 2. Within the same board, the second CPU is connected to the first CPU via Ethernet so that data communication is possible. Note that instead of multiple CPUs, a virtual machine that realizes the same functions using software may be used.

[0022] The storage 7 is a non-volatile memory mainly made of, for example, a NOR flash memory or a NAND flash memory, and is shared by multiple applications executed by the first control unit 5 and the second control unit 6. That is, the multiple applications each access the storage 7 to write and read data. In this embodiment, a configuration in which the storage 7 is built into the master ECU 1 is exemplified, but the present invention can also be applied to a configuration in which the storage 7 is disposed outside the master ECU 1. Furthermore, while a configuration in which the storage 7 is shared by multiple applications executed by the first control unit 5 and the second control unit 6 is exemplified, the storage 7 may also be shared by applications executed by a control unit of another ECU connected to the master ECU 1 so as to be able to communicate data.

[0023] When each application 9a belonging to the application layer 9 requests information about a vehicle, it requests transmission of the information from one of the CAN service 11, car data code 12, and scene code 13 belonging to the middleware layer 10, depending on the granularity of the requested information. The CAN service 11, car data code 12, and scene code 13 each have an application programming interface (hereinafter referred to as API) set so that they can provide information.

[0024] As described above, the first control unit 5 is directly connected to the CAN bus 2, and therefore has the function of controlling the transmission and reception of CAN frames including CAN data, which is data conforming to the CAN protocol. The first control unit 5 also has the function of protocol-converting CAN frames into Ethernet frames. That is, as shown in Fig. 2, when the first control unit 5 receives a CAN frame from the CAN bus 2, it performs protocol-conversion of the received CAN frame into an Ethernet frame and transmits the protocol-converted Ethernet frame to the CAN service 11.

[0025] As shown in Fig. 3, when the CAN service 11 receives an Ethernet frame transmitted from the first control unit 5, it extracts a CAN protocol data unit (PDU) from the received Ethernet frame and transmits the extracted CAN PDU to the car data coder 12. A PDU is a unit of information to be transmitted and received, and includes a control information portion defined by the communication protocol and a payload, which is the data content. The ID, control field, and data field of the CAN frame correspond to the CAN ID, DLC, and CAN data of the Ethernet frame, respectively.

[0026] When the car data coder 12 receives a CAN PDU transmitted from the CAN service 11, the car data coder 12 generates vehicle information based on the received CAN PDU and provides the generated vehicle information to the application that requested the provision of the vehicle information. The configuration of the car data coder 12 will be described below with reference to FIGS. 4 and 5. The car data coder 12 includes a data extractor 12a, a vehicle information generator 12b, a vehicle information storage unit 12c, a registration request receiver 12d, an update presence / absence determination unit 12e, a provision request receiver 12f, and a vehicle information provider 12g. The units 12a to 12g that control the operation of the car data coder 12 are executed by the second controller 6.

[0027] When the data extraction unit 12a receives a CAN PDU transmitted from the CAN service 11, it extracts CAN data from the received CAN PDU. The CAN data is in a data format conforming to the CAN communication protocol. When the CAN data is extracted by the data extraction unit 12a, the vehicle information generation unit 12b interprets the extracted CAN data and generates vehicle information. As shown in FIG. 6, for example, if the CAN data when the vehicle speed is "60 km / h" is "01 23 45 67 ab...", the vehicle information generation unit 12b generates data indicating the vehicle speed "60 km / h" as vehicle information. The data generated as vehicle information is data that can be uniquely identified from the CAN data. For example, the data generated as vehicle information is data expressed in a smaller amount of data than the CAN data.

[0028] When vehicle information is generated by the vehicle information generation unit 12b, the vehicle information storage unit 12c can store the generated vehicle information in the vehicle information list shown in FIG. 7. In this case, if vehicle information has not yet been stored, the vehicle information storage unit 12c newly stores the generated vehicle information. If vehicle information has already been stored but the generated vehicle information does not match the already stored vehicle information, the vehicle information storage unit 12c overwrites and stores the generated vehicle information. On the other hand, if vehicle information has already been stored and the generated vehicle information matches the already stored vehicle information, the vehicle information storage unit 12c discards the generated vehicle information without storing it.

[0029] The vehicle information stored in the vehicle information list includes the vehicle speed mentioned above, as well as information on whether or not a smart key is installed, the hazard status, the driver's door status, fuel consumption, the IG relay status, the odometer reading, the vehicle location, and the date. The contents of each vehicle information are as follows:

[0030] "Smart key presence / absence": Information regarding the presence / absence of a smart key, which is "True" if the key is present in the vehicle, and "False" if the key is not present in the vehicle. "Hazard status": Information about the status of the hazard lamps, which is "on" when flashing and "off" when off. "Driver's door": Information about the driver's door. When the driver's door is open, it is "open." When the driver's door is closed and locked, it is "locked." When the driver's door is closed and unlocked, it is "unlocked." "Fuel consumption": Information about fuel consumption, which is a numerical value between "0 ml" and "32 ml". "IG relay state": Information about the driving state of the IG relay, which is "on" when the IG relay is in the on state, and "off" when the IG relay is in the off state. "Odometer reading" is information about the odometer reading, which is distance information displayed on the odometer. "Vehicle speed": Information relating to vehicle speed, which is an integrated value of the vehicle speed pulse signal and is specified by the number of pulses counted. "Vehicle position": Information about the vehicle position, which is the latitude and longitude specified by the navigation device. "Date": Information about a date, specified by year, month, day, hour, minute, and second.

[0031] The vehicle information storage unit 12c may also add a timestamp to the vehicle information when storing it. As shown in FIG. 8, the vehicle information storage unit 12c may add a timestamp each time the status of "whether or not a smart key is present" is updated, for example, regarding whether or not the key is present inside the vehicle. By adding a timestamp, it is possible to store a history regarding the presence or absence of a smart key, and it becomes possible to retroactively acquire past vehicle information regarding the presence or absence of the smart key. Furthermore, as shown in FIG. 9, the vehicle information storage unit 12c may add a timestamp each time the status of the hazard lamps flashing or being turned off is updated, for example, regarding the "hazard state." By adding a timestamp, it is possible to store a history regarding the hazard state, and it becomes possible to retroactively acquire past vehicle information regarding the hazard state. The same applies to vehicle information other than "whether or not a smart key is present" and "hazard state."

[0032] The registration request receiving unit 12d receives a registration request from each of the multiple apps 9a and registers the received registration request in the service provision list. The registration request is a request from the app 9a that wants to receive vehicle information to register an app ID identifying the app 9a and a desired vehicle information type in association with each other. As shown in FIG. 10 , when the registration request receiving unit 12d receives a registration request from app A for a vehicle information type of "presence or absence of smart key," the registration request receiving unit 12d registers the app ID of app A in association with "presence or absence of smart key." When the registration request receiving unit 12d receives a registration request from app B for a vehicle information type of "vehicle speed" and "vehicle location," the registration request receiving unit 12d registers the app ID of app B in association with "vehicle speed" and "vehicle location." Note that the registration request receiving unit 12d may receive registration requests from other middleware by treating the other middleware in the same way as app 9a and register the received registration request in the service provision list.

[0033] The update determination unit 12e determines whether the vehicle information stored by the vehicle information storage unit 12c has been updated. When the vehicle information generated this time is newly stored or overwritten by the vehicle information storage unit 12c, the update determination unit 12e determines whether the vehicle information stored by the vehicle information storage unit 12c has been updated. That is, the update determination unit 12e determines whether the vehicle information has been updated every time the vehicle information is newly stored or overwritten by the vehicle information storage unit 12c in response to an update of the CAN data. In other words, the vehicle information storage unit 12c always stores the latest vehicle information.

[0034] The provision request receiving unit 12f receives a request for providing vehicle information from each of the multiple apps 9a. The vehicle information providing unit 12g provides the vehicle information stored in the vehicle information storage unit 12c to the app 9a that has requested the provision of the vehicle information. In this case, the vehicle information providing unit 12g can provide vehicle information of different granularities to the app 9a that has requested the provision of the vehicle information. In other words, the app 9a can acquire vehicle information of any granularity. The vehicle information providing unit 12g provides the vehicle information in two ways: when the update presence / absence determining unit 12e determines whether the vehicle information has been updated, or when the provision request receiving unit 12f receives a request for providing vehicle information from the app 9a.

[0035] Next, the operation of the above-described configuration will be described with reference to Figures 11 to 18. In the master ECU 1, the registration request acceptance process, vehicle information storage process, update process, and provision request acceptance process performed by the car data code 12 will be described in order.

[0036] (1) Registration request acceptance process (see Figure 11) When the car data code 12 receives a registration request from the application 9a and the start condition for the registration request reception process is met, the car data code 12 starts the registration request reception process. When the car data code 12 starts the registration request reception process, it acquires the application ID and vehicle information type notified from the application 9a (S1). The car data code 12 associates the acquired application ID and vehicle information type and registers them in the service provision list (S2), and ends the registration request reception process.

[0037] (2) Vehicle information storage process (see Figure 12) When the car data coder 12 receives a CAN PDU from the CAN service 11 and the start condition for the vehicle information storage process is met, the car data coder 12 starts the vehicle information storage process. When the car data coder 12 starts the vehicle information storage process, it extracts CAN data from the received CAN PDU (S11, corresponding to the data extraction step). The car data coder 12 interprets the extracted CAN data and generates vehicle information (S12, corresponding to the vehicle information generation step). The car data coder 12 refers to the vehicle information list (S13) and determines whether or not the generated vehicle information should be saved (S14).

[0038] If the car data code 12 determines that the vehicle information has not yet been saved, or that the vehicle information already saved does not match the previously saved vehicle information, the car data code 12 determines that the currently generated vehicle information is to be saved (S14: YES), saves the currently generated vehicle information in the vehicle information list (S15, which corresponds to the vehicle information saving step), and ends the vehicle information saving process. For example, when the car data code 12 generates a vehicle speed of "60 km / h" as the current vehicle information, if the storage area for "vehicle speed" in the vehicle information list is empty, or if the vehicle information already saved in the storage area for "vehicle speed" in the vehicle information list is a vehicle speed other than "60 km / h" and the vehicle information has been updated since the previous time, the car data code 12 saves the generated vehicle speed of "60 km / h" as the current vehicle information in the vehicle information list.

[0039] On the other hand, if the car data code 12 has already stored vehicle information and determines that the newly generated vehicle information matches the already stored vehicle information, it determines that the newly generated vehicle information is not to be stored (S14: NO), discards the newly generated vehicle information without storing it in the vehicle information list (S16), and ends the vehicle information storage process. For example, when the car data code 12 generates a vehicle speed of "60 km / h" as the current vehicle information, if the vehicle information already stored in the "vehicle speed" storage area of ​​the vehicle information list is "60 km / h" and the vehicle information has not been updated since the previous time, it discards the newly generated vehicle information of "60 km / h" without storing it in the vehicle information list.

[0040] (3) Update process (see Figure 13) The car data code 12 starts the update process when the vehicle information is updated in the vehicle information saving process described above and the newly generated vehicle information is saved in the vehicle information list, thereby satisfying the start condition for the update process. When the update process starts, the car data code 12 refers to the service provision list (S21) and identifies the application 9a to which the vehicle information associated with the updated vehicle information is to be provided (S22). Once the car data code 12 identifies the application 9a to which the vehicle information is to be provided, the car data code 12 refers to the vehicle information list (S23) and provides the vehicle information saved in the vehicle information list to the application 9a identified as the recipient of the vehicle information (S24, which corresponds to the vehicle information provision step), thereby terminating the update process. That is, the car data code 12 provides the latest vehicle information to the application 9a identified as the recipient of the vehicle information.

[0041] 10, for example, if the vehicle information generated this time is "vehicle speed," the car data code 12 specifies application B associated with "vehicle speed" as the vehicle information provider, and provides the latest value of "vehicle speed" to application B. Similarly, if the vehicle information generated this time is "vehicle position" in the service provision list shown in FIG. 10, the car data code 12 specifies applications B and D associated with "vehicle position" as the vehicle information provider, and provides the latest value of "vehicle position" to applications B and D.

[0042] (4) Provision request acceptance process (see Figure 14) When the car data coder 12 receives a provision request from the application 9a and the start condition for the provision request reception process is met, the car data coder 12 starts the provision request reception process. When the car data coder 12 starts the provision request reception process, it acquires the application ID and specified vehicle information notified from the application 9a (S31). The car data coder 12 identifies the application 9a to which the vehicle information is to be provided based on the acquired application ID (S32), and identifies the type of vehicle information to be provided to the application 9a based on the acquired specified vehicle information (S33). The car data coder 12 refers to the vehicle information list (S34), and provides the vehicle information corresponding to the identified vehicle information type to the application 9a identified as the recipient of the vehicle information (S35, which corresponds to the vehicle information provision procedure), and ends the provision request reception process.

[0043] For example, when application X notifies a request for providing "whether or not a smart key is present," the car data code 12 identifies application X as a vehicle information provider and provides the latest value of "whether or not a smart key is present" to application X.

[0044] Next, the process performed by the CAN service 11 and the car data code 12 in cooperation with each other will be described with reference to Fig. 15 to Fig. 18. For example, when the master ECU 1 is started, the car data code 12 notifies the CAN service 11 of an open instruction (t1). When the CAN service 11 receives the open instruction from the car data code 12, it notifies the car data code 12 of a response to the notified open instruction (t2) and creates a temporary data storage area.

[0045] The car data code 12 notifies the CAN service 11 of the set ID filter instruction (t3). When the CAN service 11 receives the set ID filter instruction from the car data code 12, it notifies the car data code 12 of a response to the notified set ID filter instruction (t4) and holds the ID specified by the notified set ID filter instruction.

[0046] When the CAN service 11 receives an Ethernet frame from the first control unit 5 (t5), it compares the ID it holds with the CAN ID stored in the received Ethernet frame. When the CAN service 11 identifies an Ethernet frame containing a CAN ID that matches the ID it holds, it extracts a CAN PDU from the identified Ethernet frame and stores the extracted CAN PDU in a data storage area. When the CAN service 11 identifies an Ethernet frame containing a CAN ID that does not match the ID it holds, it discards the identified Ethernet frame without extracting the CAN PDU. Thereafter, the CAN service 11 repeats the above process each time it receives an Ethernet frame from the first control unit 5 (t10, t14, t17).

[0047] When the car data code 12 receives a registration request from the application 9a (t6), it executes the registration request acceptance process described above in Fig. 11. The car data code 12 acquires the application ID and vehicle information type specified in the notified registration request, and registers the acquired application ID and vehicle information type in the service provision list in association with each other.

[0048] The car data coder 12 sends a read instruction to the CAN service 11 at a predetermined interval (e.g., every few milliseconds) (t7). When the CAN service 11 receives the read instruction from the car data coder 12, it sends the CAN PDU stored in the data storage area to the car data coder 12 (t8). When the car data coder 12 acquires the CAN PDU from the CAN service 11, it performs the vehicle information storage process described above in FIG. 12. The car data coder 12 extracts CAN data from the acquired CAN PDU, interprets the extracted CAN data to generate vehicle information, and refers to the vehicle information list to determine whether the generated vehicle information should be stored. After this, the car data coder 12 and the CAN service 11 repeat the above process at the interval at which the car data coder 12 issues a read instruction (t11, t12, t15, t16, t18, t19).

[0049] If the car data code 12 determines that the vehicle information has not been updated, it discards the vehicle information generated this time without saving it in the vehicle information list. On the other hand, if the car data code 12 determines that the vehicle information has been updated, it saves the vehicle information generated this time in the vehicle information list and performs the update processing described above in Figure 13. The car data code 12 refers to the service provision list, identifies the application 9a to which the vehicle information will be provided, and refers to the vehicle information list, and notifies the application 9a identified as the recipient of the vehicle information of the vehicle information saved in the vehicle information list, i.e., the latest value of the vehicle information (t9, t13, t20).

[0050] 17 and 18 show a case where "vehicle speed" is specified as the vehicle information type in the registration request notified from the application 9a. In this case, the car data coder 12 notifies the application 9a of the vehicle information generated based on the CAN PDU first acquired from the CAN service 11 immediately after the registration request is notified from the application 9a (t9). After this, for example, if the vehicle information generated based on the CAN PDU acquired from the CAN service 11 at timing "t8" is a vehicle speed of "58 km / h" and the vehicle information generated based on the CAN PDU acquired from the CAN service 11 at timing "t12" is a vehicle speed of "60 km / h," the car data coder 12 notifies the application 9a of the vehicle speed of "60 km / h" as the vehicle information since the vehicle information has been updated since the previous time (t13).

[0051] If the vehicle information generated based on the CAN PDU acquired from the CAN service 11 at time "t16" indicates a vehicle speed of "60 km / h," the car data code 12 discards the vehicle information without notifying the application 9a, since the vehicle information has not been updated since the previous time. If the vehicle information generated based on the CAN PDU acquired from the CAN service 11 at time "t19" indicates a vehicle speed of "62 km / h," the car data code 12 notifies the application 9a of the vehicle speed of "62 km / h" as the vehicle information, since the vehicle information has been updated since the previous time (t20). The above describes the case where "vehicle speed" is specified as the vehicle information type, but the same applies to other vehicle information types.

[0052] As described above, according to this embodiment, the following advantageous effects can be obtained. The master ECU 1 extracts CAN data from the CAN frame, generates and saves vehicle information based on the extracted CAN data, and provides the saved vehicle information to the application 9a that requested the provision of the vehicle information. This eliminates the need to prepare a program module for generating vehicle information for each application, thereby reducing the cost and labor required to create the application 9a and reducing memory consumption in the storage 7. Furthermore, there is no risk of generating different vehicle information from the same CAN data, and there is no risk of malfunctions occurring between applications 9a. This allows multiple applications 9a to easily and appropriately use vehicle information based on CAN data.

[0053] When the stored vehicle information is updated in the master ECU 1, the stored vehicle information is provided to the application 9a that has requested the provision of the vehicle information. When the vehicle information is updated, the latest vehicle information can be provided to the application 9a. In other words, the latest vehicle information can be provided to the application 9a without the application 9a notifying the provision request.

[0054] When the master ECU 1 receives a request for provision from the application 9a, the master ECU 1 provides the stored vehicle information to the application 9a that has requested the provision of the vehicle information. Regardless of whether the vehicle information has been updated since the last time, the latest vehicle information can be provided to the application 9a at any timing when the application 9a notifies the provision request.

[0055] The master ECU 1 converts the protocol of the CAN frame received from the CAN bus 2 into an Ethernet frame, and extracts the CAN data from the protocol-converted Ethernet frame. This targets the application 9a executed by the second control unit 6 that is not directly connected to the CAN bus 2, and each of the multiple applications 9a can easily and appropriately use vehicle information based on the CAN data.

[0056] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0057] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. [Explanation of symbols]

[0058] In the drawing, 1 is a master ECU (electronic control unit), 5 is a first control unit, 6 is a second control unit (control unit), 12 is a car data code, 12a is a data extraction unit, 12b is a vehicle information generation unit, 12c is a vehicle information storage unit, 12d is a registration request reception unit, 12e is an update presence / absence determination unit, 12f is a provision request reception unit, and 12g is a vehicle information provision unit.

Claims

1. An electronic control device (1) having a control unit (6) that executes a plurality of apps, a data extraction unit (12a) for extracting data from a data frame conforming to a predetermined communication protocol; a vehicle information generating unit (12b) that generates vehicle information based on the data extracted by the data extracting unit; a vehicle information storage unit (12c) for storing the vehicle information generated by the vehicle information generation unit; an update presence / absence determination unit (12e) that determines whether the vehicle information stored by the vehicle information storage unit has been updated; a vehicle information providing unit (12g) that provides the vehicle information stored in the vehicle information storage unit to an application that has requested the provision of the vehicle information, The vehicle information providing unit is an electronic control device that, when the update determination unit determines that the vehicle information stored in the vehicle information storage unit has been updated, provides the vehicle information stored in the vehicle information storage unit to the requesting app that requested the provision of the vehicle information.

2. a registration request receiving unit (12d) for receiving a registration request from each of the plurality of applications; 2. The electronic control device according to claim 1, wherein the vehicle information providing unit provides the vehicle information stored in the vehicle information storage unit to an app whose registration request has been accepted by the registration request accepting unit as the requesting app that requested the provision of the vehicle information.

3. a provision request receiving unit (12f) for receiving a provision request from each of the plurality of applications; 2. The electronic control device according to claim 1, wherein the vehicle information providing unit provides the vehicle information stored in the vehicle information storage unit to the requesting app that requested the provision of the vehicle information when a provision request from the app is accepted by the provision request accepting unit.

4. The electronic control device according to claim 1 , wherein the data extraction unit, the vehicle information generation unit, the vehicle information storage unit, and the vehicle information provision unit are executed by the control unit.

5. The electronic control device according to claim 1 , wherein the vehicle information providing unit provides vehicle information of different granularities to an application that has requested the provision of the vehicle information.

6. An electronic control device (1) having a control unit (6) that executes multiple apps, a data extraction procedure for extracting data from a data frame conforming to a predetermined communication protocol; a vehicle information generating step of generating vehicle information based on the data extracted by the data extracting step; a vehicle information storage step for storing the vehicle information generated by the vehicle information generation step; an update determination step for determining whether the vehicle information stored by the vehicle information storage step has been updated; a vehicle information providing procedure that, when the vehicle information stored by the vehicle information storing procedure is determined to have been updated by the update presence / absence determining procedure, provides the vehicle information stored by the vehicle information storing procedure to an application that requested the provision of the vehicle information.

7. An electronic control device (1) having a control unit (6) that executes multiple apps, a data extraction procedure for extracting data from a data frame conforming to a predetermined communication protocol; a vehicle information generating step of generating vehicle information based on the data extracted by the data extracting step; a vehicle information storage step for storing the vehicle information generated by the vehicle information generation step; an update determination step for determining whether the vehicle information stored by the vehicle information storage step has been updated; A vehicle information providing program that executes a vehicle information providing procedure that, when the vehicle information stored by the vehicle information storing procedure is determined to have been updated by the update presence / absence determining procedure, provides the vehicle information stored by the vehicle information storing procedure to an application that requested the provision of the vehicle information.

Images