In-vehicle device, data providing method, and program

Abstract

According to the present invention, a schedule management unit uses one or more pieces of management information to extract, as a command-to-be-transmitted, a command indicated by management information that satisfies an acquisition condition, and generate, at the same time, routing information that associates the command-to-be-transmitted with a request source application. The request source application is an application program that is a request source of vehicle data. The management information represents the type of a command used for acquiring the vehicle data, the request source application, and a vehicle data acquisition condition. The command-to-be-transmitted is a command for transmission in a transmission process. A routing unit provides the acquired vehicle data to the request source application by using the routing information.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2022-212065, filed with the Japan Patent Office on December 28, 2022, the entire contents of which are incorporated herein by reference. [Technical Field]

[0002] The present disclosure relates to a technique for providing vehicle data to an application program running on an in-vehicle device connected to an in-vehicle network. [Background technology]

[0003] The following Patent Document 1 describes a device that performs diagnostic communication to diagnose faults using data transmitted between ECUs via an in-vehicle network such as CAN. CAN is a registered trademark. In diagnostic communication, a diagnostic tester is connected to a dedicated connector such as an OBD port provided in the vehicle, and a request message is sent from the diagnostic tester to the ECU, which then returns a response message. OBD stands for on-board diagnostic. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-209964 Summary of the Invention

[0005] However, after detailed investigation by the inventors, the following problem was found: A vehicle typically has one port for diagnostic communication, to which one diagnostic tester is connected. Furthermore, the diagnostic tester only runs one application, and can only be used for a single purpose and independently.

[0006] One aspect of the present disclosure provides a technique that enables an in-vehicle device connected to an in-vehicle network to be used for multiple purposes simultaneously.

[0007] One aspect of the present disclosure is an in-vehicle device including a data acquisition unit, an application execution unit, a schedule management unit, and a routing unit. The data acquisition unit is configured to execute a transmission process to transmit a command used to acquire vehicle data to an in-vehicle network. The application execution unit is configured to execute one or more application programs that use the vehicle data acquired by the data acquisition unit. The schedule management unit is configured to use one or more pieces of management information to extract commands indicated by the management information that satisfy an acquisition condition as transmission target commands that are commands to be transmitted in the transmission process. The schedule management unit is also configured to generate routing information that associates the transmission target commands with request source applications. The management information indicates the type of command used to acquire the vehicle data, the request source application that is an application program that requests the vehicle data, and the acquisition conditions for the vehicle data. The routing unit is configured to provide the vehicle data acquired by the data acquisition unit executing the transmission process to the request source application using the routing information.

[0008] With this configuration, vehicle data acquired via the in-vehicle network can be provided to the requesting application. In other words, multiple applications that each independently use vehicle data can be simultaneously installed and run on an in-vehicle device connected to the in-vehicle network.

[0009] One aspect of the present disclosure is a data providing method for providing vehicle data to a requesting application, which is an application program that requests the vehicle data. The data providing method is applied to an on-board device that executes a transmission process for transmitting a command used to acquire the vehicle data to an on-board network, and provides the vehicle data acquired by the transmission process to one or more application programs.

[0010] In the data providing method, one or more pieces of management information are used to extract commands indicated by the management information that satisfy acquisition conditions as transmission target commands, which are commands to be transmitted in a transmission process. In the data providing method, routing information is generated that associates the transmission target commands with requesting applications. The management information indicates the type of command used to acquire the vehicle data, the requesting application, and acquisition conditions for the vehicle data. In the data providing method, the vehicle data acquired by executing the transmission process is provided to the requesting application using the routing information.

[0011] According to this method, the same effect as that of the above-mentioned vehicle-mounted device can be obtained.

[0012] One aspect of the present disclosure is a program. The program is executed in an onboard device that executes a transmission process to transmit a command used to acquire vehicle data to an onboard network and provides the vehicle data acquired by the transmission process to one or more application programs. The program is executed to provide the vehicle data to a requesting application, which is an application program that requests the vehicle data.

[0013] The program causes the in-vehicle device to execute a process of extracting a command to be sent and generating routing information using one or more pieces of management information. The management information indicates the type of command used to acquire vehicle data, the requesting application, and the acquisition conditions for the vehicle data. The command to be sent is a command to be sent in the transmission process and is indicated by the management information that satisfies the acquisition conditions. The routing information is information that associates the command to be sent with the requesting application.

[0014] The program causes the in-vehicle device to execute a process of providing the vehicle data acquired by executing the transmission process to the requesting application using the routing information.

[0015] By executing such a program, it is possible to obtain the same effects as the above-mentioned vehicle-mounted device. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 2 is a block diagram showing the functional configuration of the data providing system. [Figure 2] FIG. 2 is a block diagram showing the hardware configuration of a cloud server. [Figure 3] FIG. 2 is a block diagram showing a hardware configuration of an in-vehicle device. [Figure 4] FIG. 2 is an explanatory diagram illustrating the structure of a manifest. [Figure 5] FIG. 10 is an explanatory diagram illustrating the structure of a command management table. [Figure 6] FIG. 3 is a sequence diagram showing the operation of each part of the system when the power of the vehicle-mounted device is turned on. [Figure 7] FIG. 10 is a sequence diagram showing an operation when a diagnostic application is distributed. [Figure 8] FIG. 10 is a sequence diagram showing an operation when a diagnostic command is transmitted. [Figure 9] FIG. 10 is a sequence diagram showing an operation when a response to a diagnostic command is received. [Figure 10] 10 is a flowchart showing the contents of a schedule adjustment process. [Figure 11] FIG. 10 is an explanatory diagram illustrating an example of a diagnostic command request extracted at each tick. [Figure 12] FIG. 10 is an explanatory diagram showing the operation when diagnostic command requests overlap. [Figure 13] FIG. 10 is an explanatory diagram showing the operation when there is a possibility that the load on the CAN bus may exceed the limit. [Figure 14] FIG. 10 is an explanatory diagram of a command transmission method. [Figure 15] FIG. 10 is an explanatory diagram showing an example of setting a transmission schedule to prevent diagnostic commands from concentrating in the same tick. [Figure 16] FIG. 10 is a sequence diagram showing an operation when measuring a turnaround time. DETAILED DESCRIPTION OF THE INVENTION

[0017] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0018] [1. Configuration] The data providing system 1 shown in Fig. 1 includes a cloud server 10 and an on-board device 30. Although Fig. 1 exemplarily shows one cloud server 10 and one on-board device 30, the data providing system 1 may include a plurality of cloud servers 10 and a plurality of on-board devices 30.

[0019] [1-1. Cloud Server] The cloud server 10 is configured to be accessible via a wide area communication network NW. The cloud server 10 distributes various information required for the in-vehicle device 30 to execute a diagnostic application program (hereinafter referred to as a diagnostic app) to the in-vehicle device 30. The diagnostic app is an application that uses vehicle data collected using diagnostic communication. Diagnostic communication, written as Diagnostic Communication in English, is a communication method that uses an in-vehicle network to obtain vehicle data required for fault diagnosis from an electronic control unit (hereinafter referred to as an ECU) 63. In this embodiment, a CAN bus 62 is used as the in-vehicle network. CAN is an abbreviation for Controller Area Network. CAN is a registered trademark.

[0020] Vehicle data is classified into multiple data types, which may include "body control / powertrain system," "AD / ADAS system," "driver monitor system," "vehicle body system," "indoor / outdoor environmental control system," "fuel / exhaust system," "media system," and "diagnostic fault code (DTC)."

[0021] Vehicle data related to vehicle control and powertrain systems may include vehicle speed, vehicle acceleration, vehicle angular velocity, gear position, accelerator pedal position, brake pedal position, brake pressure, and the like.

[0022] AD / ADAS vehicle data may include vehicle distance, posted speed limit, stop sign detection, lane keeping warning, leading vehicle following, clearance sonar, and whether or not an obstacle is detected.

[0023] The driver monitor vehicle data may include an inattentiveness detection status, a decreased attention detection status, a driver abnormality detection status, and the like.

[0024] Vehicle data for the vehicle body system may include total mileage (i.e., odometer value), Global Positioning System (hereinafter referred to as GPS) location information, light status, door / window open / close status, door / window lock status, seat belt status, airbag status, tire pressure, air conditioner operation status, parking brake status, etc.

[0025] The vehicle data of the vehicle interior / exterior environment control system may include the interior / exterior temperatures of the vehicle, the operating status of the air conditioner, and the like.

[0026] Fuel and exhaust vehicle data may include battery state of charge, fuel tank capacity, amount of fuel remaining, average fuel consumption, and the like.

[0027] The media-related vehicle data may include the media status, volume, whether or not a Bluetooth (hereinafter referred to as BT) connection is present, whether or not a Data Communication Module (hereinafter referred to as DCM) is present, etc. Bluetooth is a registered trademark.

[0028] The DTC vehicle data may include a DTC list and the like.

[0029] Priorities may be set for the vehicle data according to the data type. The priorities may be set, for example, as follows. However, the setting of priorities according to the data type is not limited to the following order, and can be set arbitrarily.

[0030] Vehicle Control & Powertrain Systems > AD & ADAS Systems > Driver Monitoring Systems > Vehicle Body Systems > Interior & Exterior Environmental Control Systems > Fuel & Exhaust Systems > Media Systems > DTC As shown in FIG. 2, the cloud server 10 includes a control unit 11, a communication unit 12, and a storage unit 13.

[0031] The control unit 11 includes a CPU 111, a ROM 112, and a RAM 113. Various functions of the control unit 11 are realized by the CPU 111 executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 112 corresponds to the non-transitory tangible recording medium storing the program. Furthermore, by executing this program, a method corresponding to the program is performed.

[0032] The communication unit 12 performs data communication with the vehicle-mounted device 30 by wireless communication via the wide area communication network NW.

[0033] The storage unit 13 includes an application database (hereinafter referred to as application DB) 131 and a master database (hereinafter referred to as master DB) 132. The application DB 131 stores information about one or more diagnostic applications. The master DB 132 stores information about the CAN bus 62 of the vehicle 60 to which the on-board device 30 is connected.

[0034] [1-2.In-vehicle device] 1, the vehicle-mounted device 30 is used by connecting to a diagnostic port 61 provided in a vehicle 60. The vehicle-mounted device 30 downloads one or more diagnostic applications 411 from the cloud server 10 and executes them.

[0035] As shown in FIG. 3, the vehicle-mounted device 30 includes a control unit 31, a vehicle interface (hereinafter referred to as vehicle I / F) 32, a communication unit 33, and a storage unit .

[0036] The control unit 31 includes a CPU 311, a ROM 312, and a RAM 313. Various functions of the control unit 31 are realized by the CPU 311 executing a program stored in a non-transitory physical recording medium. In this embodiment, the ROM 312 corresponds to the non-transitory physical recording medium storing the program. Furthermore, by executing this program, a method corresponding to the program is performed.

[0037] The vehicle I / F 32 includes a diagnostic connector 321 and an expansion connector 322 .

[0038] 1, the diagnostic connector 321 is connected to a diagnostic port 61 (for example, an OBD port) provided in the vehicle 60. That is, the on-board device 30 is connected to a CAN bus 62 of the vehicle 60 via the diagnostic port 61 to which the diagnostic connector 321 is connected, and acquires various vehicle data held by the ECU 63 via the CAN bus 62 using diagnostic communication.

[0039] The expansion connector 322 receives signals from an external device group 70 that is retrofitted to the vehicle 60. The external device group 70 may include a communication chip (e.g., BLE, LTE, NFC, etc.), a camera, a microphone, a speaker, an acceleration sensor, a gyro sensor, etc. BLE stands for Bluetooth Low Energy, LTE stands for Long Term Evolution, and NFC stands for Near Field Communication.

[0040] Returning to FIG. 3, the communication unit 33 performs data communication with the cloud server 10 connected to the wide area communication network NW via wireless communication.

[0041] The storage unit 34 includes a diagnostic command database (hereinafter referred to as a diagnostic command DB 341) and a frame interpretation database (hereinafter referred to as a frame interpretation DB) 342.

[0042] The diagnostic command DB 341 stores diagnostic command information acquired from the cloud server 10 via the communication unit 33. The frame interpretation DB 342 stores frame interpretation information acquired from the cloud server 10 via the communication unit 33. The diagnostic command information and the frame interpretation information will be described later.

[0043] [2. Functional configuration] Next, the functional configurations of the cloud server 10 and the vehicle-mounted device 30 will be described.

[0044] [2-1. Cloud Server] 1, the cloud server 10 includes an application DB 131 and a master DB 132. The application DB 131 and the master DB 132 are configured on the storage unit 13.

[0045] The application DB 131 stores one or more types of diagnostic applications to be distributed to the vehicle-mounted device 30 and manifests associated with each of the diagnostic applications.

[0046] A manifest is an instruction document that describes one or more vehicle data items used in a diagnostic application, by associating each type of vehicle data with the conditions for acquiring the vehicle data. The manifest is created by the application developer. The manifest is written in a format that application developers can understand without specialized knowledge of vehicles. Specifically, as shown in Figure 4, the manifest includes "request information" and "mode attributes." Depending on the content of the "mode attributes," the manifest may also include "mode sub-attributes" and "application metadata."

[0047] "Request information" is information that specifies the type of vehicle data. When specifying the type of vehicle data, name specification and command specification can be used. Name specification is a method of specifying vehicle data using a standardized name that allows the meaning of the vehicle data to be intuitively understood, and is commonly defined regardless of vehicle model. Command specification is a method of specifying the data in a format (i.e., a bit pattern) that is actually sent and received in vehicle diagnostic communication, and is uniquely defined for each vehicle model.

[0048] The "mode attribute" is information that specifies how to acquire the vehicle data indicated in the "request information." The "mode attribute" includes application-driven, periodic-driven, and event-driven modes. Application-driven is a mode used when specified vehicle data is acquired a limited number of times within a limited time period in accordance with instructions from a diagnostic application. Of the application-driven modes, immediate acquisition only once is called immediate acquisition. In this embodiment, immediate acquisition will be described as an example of application-driven mode. Periodic acquisition is a mode used when specified vehicle data is repeatedly acquired at a specified fixed interval. Event-driven is a mode used when specified vehicle data is acquired using a change in a signal detected when a specified event occurs as a trigger.

[0049] The "mode sub-attribute" is information that differs depending on the type of "mode attribute," and the information is set as needed. Note that if the "mode attribute" is immediate drive, there is no need to set information as the "mode sub-attribute." If the "mode attribute" is periodic drive, a period value indicating the vehicle data acquisition period and a period value indicating the vehicle data acquisition period may be set as the "mode sub-attribute." If the "mode attribute" is event drive, a trigger condition may be set as the "mode sub-attribute." The trigger condition is information that defines which signal and what state will trigger the event. The trigger condition may utilize information obtained via the CAN bus 62, signals obtained from the external device group 70, and information obtained by processing (e.g., differentiating, integrating, smoothing) the signals obtained from the external device group 70.

[0050] The "application metadata" may be set with a priority value that indicates the priority of the vehicle data. The priority of the vehicle data is information used to determine which vehicle data should be prioritized when multiple vehicle data are requested to be acquired at the same time and it is difficult to process all of the requests.

[0051] The master DB 132 stores diagnostic command information and frame interpretation information.

[0052] The frame interpretation information is information that defines the format of the communication frame used in the CAN bus 62, the bit assignment in each area of ​​the frame, the unit of the value shown in the assigned area, etc. The frame interpretation information is prepared for each vehicle model and is information required when interpreting the communication frame used in diagnostic communication.

[0053] The diagnostic command information is information that includes a list of diagnostic commands that can be used on the CAN bus 62, and as explained in the "request information" of the manifest, there is information regarding name specification and information regarding command specification. Like the frame interpretation information, the diagnostic command information is prepared for each vehicle model.

[0054] Cloud server 10 includes a cloud-side application management unit 21 and a cloud-side DB management unit 22 as functions realized by the processing executed by control unit 11.

[0055] The cloud-side application management unit 21 distributes and deletes diagnostic applications and the like to the in-vehicle device 30, and also monitors the operation of the distributed diagnostic applications. The cloud-side application management unit 21 assigns application IDs to the diagnostic applications stored in the application DB 131 and to manifests associated with the diagnostic applications, and manages them. The cloud-side application management unit 21 may manage the diagnostic applications by associating them with the businesses that developed the diagnostic applications.

[0056] The cloud-side DB management unit 22 updates the master DB 132 and distributes the diagnostic command information and frame interpretation information stored in the master DB 132 in response to a request from the vehicle-mounted device 30. The cloud-side DB management unit 22 may be configured to be able to identify the vehicle model from the vehicle identification number (hereinafter, referred to as VIN).

[0057] [2-2.In-vehicle device] The vehicle-mounted device 30 includes a diagnostic command DB 341 and a frame interpretation DB 342. The diagnostic command DB 341 and the frame interpretation DB 342 are configured on the storage unit .

[0058] The diagnostic command DB 341 stores diagnostic command information that is applied to the vehicle model of the vehicle 60 in which the on-board device 30 is installed (hereinafter referred to as the on-board vehicle).

[0059] The frame interpretation DB 342 stores frame interpretation information that is applied to the vehicle type of the vehicle 60 on which the vehicle is mounted.

[0060] The in-vehicle device 30 has, as functions realized by processing executed by the control unit 31, an application execution environment 41, an API group 42, a routing unit 43, a CAN transmitter 44, a CAN receiver 45, a vehicle-side application management unit 46, a manifest management unit 47, a schedule management unit 48, a vehicle-side DB management unit 49, and an external device management unit 50.

[0061] The external device management unit 50 manages the external device group 70 connected to the expansion connector 322 of the in-vehicle device 30. The external device management unit 50 monitors signals input from each external device belonging to the external device group 70. If the signal being monitored satisfies a trigger condition notified by the schedule management unit 48, the external device management unit 50 has a function of notifying the schedule management unit 48 of the occurrence of an event. If the external device management unit 50 detects, when the in-vehicle device 30 is started, that the external device group 70 connected to the expansion connector 322 has changed since the previous startup, the external device management unit 50 may also have a function of notifying the schedule management unit 48 of a change in hardware configuration.

[0062] When the vehicle-mounted device 30 connects to the vehicle 60 for the first time, the vehicle-side DB management unit 49 obtains diagnostic command information and frame interpretation information suitable for the vehicle 60 from the cloud server 10 and stores them in the diagnostic command DB 341 and frame interpretation DB 342.

[0063] The application execution environment 41 includes an OS, middleware, etc., and provides an execution environment for diagnostic applications distributed from the cloud server 10.

[0064] The vehicle-side application management unit 46 acquires the diagnostic applications 411 from the cloud server 10 via the wide area communication network NW, and deploys (i.e., arranges and expands) the acquired diagnostic applications 411 so that they can be executed in the application execution environment 41. The vehicle-side application management unit 46 also monitors the operation of the deployed diagnostic applications 411 and deletes the deployed diagnostic applications 411. Furthermore, the vehicle-side application management unit 46 provides the manifest distributed from the cloud server 10 together with the diagnostic applications 411 to the manifest management unit 47. The vehicle-side application management unit 46 may have a function of notifying the schedule management unit 48 of a change in the software configuration every time a diagnostic application is deployed or deleted.

[0065] The API group 42 is a collection of application programming interfaces (hereinafter, APIs) that provide various functions to the diagnostic application 411 executed in the application execution environment 41. The API group 42 includes at least an API that provides a function to acquire vehicle data via the CAN bus 62 of the vehicle 60 on which the API group 42 is installed.

[0066] The routing unit 43 has routing information notified by the schedule management unit 48. The routing information is information that associates a diagnostic application 411 (hereinafter, a requesting application) that requests vehicle data with a diagnostic command that is transmitted to the CAN bus 62 in response to the request. The routing unit 43 distributes the vehicle data received by the CAN receiving unit 45 as a result of the CAN transmitting unit 44 transmitting the diagnostic command to the requesting application by referring to the routing information.

[0067] In other words, since CAN is a communication method that does not perform session management to identify the communication partner, when there are multiple requesting applications, it is not possible to determine which diagnostic application 411 has made a request for a received frame. Therefore, the routing unit 43 refers to routing information that associates requesting applications with command IDs, so that the vehicle data acquired from the CAN bus 62 via the CAN receiving unit 45 is delivered correctly to each requesting application.

[0068] Manifest management unit 47 includes storage unit 471 and interpretation unit 472.

[0069] The storage unit 471 stores the manifest provided by the vehicle-side application management unit 46.

[0070] Interpretation unit 472 interprets the contents of the manifest stored in storage unit 471 to extract and generate information necessary for setting the command management table, and provides the information to schedule management unit 48. Specifically, interpretation unit 472 identifies vehicle data from the "request information" of the manifest, and extracts the command ID of the command used to acquire the identified vehicle data from the diagnosis command information. Interpretation unit 472 extracts the contents of the "mode attribute" and "mode sub-attribute" of the manifest as vehicle data acquisition conditions. Interpretation unit 472 extracts the contents of the "application metadata" of the manifest as a priority value representing the transmission priority. Instead of using the priority value set in the "application metadata," interpretation unit 472 may automatically set the priority value from the "mode attribute" and "mode sub-attribute" of the manifest (i.e., vehicle data acquisition conditions) as follows, for example:

[0071] "Immediate or event driven" < "Periodic driven: long cycle" < "Periodic driven: short cycle" In other words, among periodic drive commands, immediate drive commands and event drive commands may have higher priorities, and among periodic drive commands, commands with shorter periods may have higher priorities. However, the order of priority is not limited to the above and can be set arbitrarily.

[0072] Furthermore, instead of using the priority value set in the "application metadata," the interpretation unit 472 may use a priority value set according to the data type of the vehicle data identified from the "request information" of the manifest. Furthermore, the interpretation unit 472 may use a combination of a priority value set based on the vehicle data acquisition conditions and a priority value set according to the data type.

[0073] The schedule management unit 48 includes a setting unit 481 , an adjustment unit 482 , and a load calculation unit 483 .

[0074] The setting unit 481 adds management information indicating vehicle data acquisition conditions to the command management table based on the interpretation result of the manifest by the interpretation unit 472. The command management table is a table indicating information used to manage the transmission timing of diagnostic commands.

[0075] 5, the management information set in the command management table includes "application ID," "command ID," "transmission waiting status," "supplementary information," and "transmission priority." A command management table is generated for each type of "mode attribute," and the content of the "supplementary information" differs for each "mode attribute."

[0076] The "application ID" is information that identifies the requesting application, and is assigned by the vehicle-side application management unit 46 when the diagnostic application is deployed.

[0077] The "command ID" is information that identifies the diagnostic command used when obtaining the vehicle data indicated in the "request information" of the manifest.

[0078] "Transmission waiting status" indicates the number of ticks remaining until transmission. A tick is the execution cycle of the diagnostic command transmission process, and is set to, for example, 100 ms. The number of remaining ticks is decremented with each tick, and management information whose remaining ticks reaches 0 will be processed in the next tick.

[0079] However, if the "mode attribute" is set to periodic drive, the "transmission waiting status" is preset to the number of ticks corresponding to the period value set in the "mode sub-attribute" each time a command is sent. As a result, in the case of periodic drive, command transmission is repeated at a period corresponding to the period value.

[0080] When the "mode attribute" is event-driven, the "send waiting status" is normally set to an invalid value indicating that there is no request, is set to 0 when the specified trigger condition is met, and is set to the invalid value again after the command is sent. The invalid value may be, for example, a value in which all bits are padded with 1.

[0081] When the "mode attribute" is immediate drive, the "transmission waiting status" is normally set to an invalid value, is set to 0 when a request is made from the diagnostic application 411, and is set to an invalid value again after the command is sent. When the "transmission waiting status" is set to an invalid value, it is not decremented for each tick and the invalid value is maintained.

[0082] If the "mode attribute" is cyclically driven, "remaining transmission count" may be set as "supplementary information." If the "mode sub-attribute" of the manifest includes information about the validity period, the "remaining transmission count" is set to a value indicating the remaining validity period in ticks. If the validity period is unlimited, the "remaining transmission count" is set to an invalid value. The remaining tick count of the "remaining transmission count" is decremented with each tick. However, if it is set to an invalid value, it is not decremented with each tick and the invalid value is maintained. Management information in which the number of ticks in the "remaining transmission count" reaches 0 is deleted from the command management table.

[0083] If the "mode attribute" is event-driven, a "trigger type" may be set as "supplemental information." The "trigger type" sets a trigger condition, which is a condition for notifying the occurrence of an event. The setting unit 481 notifies the external device management unit 50 and the CAN receiver 45 of the trigger condition according to the content of the "trigger type."

[0084] When the "mode attribute" is immediate drive, the "payload" may be set as the "supplementary information." The "payload" is set to the command itself, which is written in bit format to the payload of the CAN frame.

[0085] A priority value is set in "transmission priority." The priority value is information used to determine which diagnostic command should be prioritized when transmission candidate commands are extracted according to the command management table and it is difficult to process all of the transmission candidates in the next tick due to reasons such as excessive load. Here, the higher the priority value, the higher the priority. If a priority value is set as "application metadata" in the manifest, this priority value may be used. If no priority value is set, it may be considered the lowest priority.

[0086] The adjustment unit 482 refers to the command management table, determines the management information to be processed in the next tick, i.e., the diagnostic command to be transmitted, and notifies the CAN transmission unit 44. Note that the determination of the diagnostic command to be transmitted takes into consideration the turnaround time of each diagnostic command, the traffic on the CAN bus 62, and the transmission priority of the diagnostic command.

[0087] In diagnostic communication, if parallel command transmission is prohibited and alternate command transmission is used, the number of commands that can be transmitted per tick can be estimated from the turnaround time. Alternate communication is a method in which, after transmitting a command, the next command is transmitted after receiving its response, as shown in the upper part of Figure 14. Parallel transmission is a method in which, after transmitting a command, the next command is transmitted without waiting for the response, as shown in the lower part of Figure 14.

[0088] Traffic is the rate at which the CAN bus 62 is in use. Higher traffic means longer turnaround times, and therefore fewer commands can be sent per tick. The upper limit of traffic allowed on the CAN bus 62 (hereinafter referred to as the "allowable limit") may be set for each vehicle model.

[0089] After the initialization process at the start of the in-vehicle device 30, the load calculation unit 483 measures the turnaround time used for processing by the adjustment unit 482. The turnaround time is measured by having the CAN transmitter 44 transmit a command to the CAN bus 62 and measuring the time until the CAN receiver 45 receives a response. This measurement is performed repeatedly for multiple commands. The load calculation unit 483 may calculate the average value of the measured turnaround times. The load calculation unit 438 stores either or both of the turnaround time measured for each command and the average turnaround time in the diagnostic command DB 341. Note that instead of the average turnaround time, a value obtained by adding a safety margin to the average turnaround time may be used.

[0090] The load calculation unit 483 may measure the turnaround time every time the in-vehicle device 30 is started. Furthermore, as indicated by the dotted line in Fig. 16 , the load calculation unit 483 may measure the turnaround time when a notification indicating a change in the hardware configuration is received from the external device management unit 50. The load calculation unit 483 may measure the turnaround time when a notification indicating a change in the software configuration is received from the vehicle-side application management unit 46.

[0091] The CAN transmitter 44 includes a command generator 441. The command generator 441 generates a diagnostic command by referring to the diagnostic command DB 341 in accordance with an instruction from the adjustment unit 482 of the schedule manager 48. The command generator 441 further generates a CAN frame with the diagnostic command stored in the payload and stores the CAN frame in the transmission buffer. The CAN transmitter 44 transmits the CAN frame stored in the transmission buffer to the CAN bus 62 via the diagnostic connector 321.

[0092] The CAN receiver 45 includes a frame interpretation unit 451. The CAN receiver 45 stores a CAN frame (i.e., a response to a diagnostic command) received from the CAN bus 62 via the diagnostic connector 321 in a receive buffer. The frame interpretation unit 451 interprets the contents of the received CAN frame (hereinafter, "received frame") by referring to frame interpretation information stored in the frame interpretation DB 342. The frame interpretation unit 451 converts vehicle data, which is indicated in the payload of the received frame and is written in a format specific to the vehicle 60, into a format understandable by the requesting application. The frame interpretation unit 451 then provides the interpreted and converted vehicle data to the routing unit 43 together with the command ID of the transmitted diagnostic command.

[0093] The CAN receiver 45 has a function of monitoring vehicle data that is periodically received. The CAN receiver 45 has a function of notifying the schedule manager 48 of the occurrence of an event when the monitored signal satisfies the trigger condition notified by the schedule manager 48. The CAN receiver 45 has a function of measuring a turnaround time, which is the time from when a command is transmitted by the CAN transmitter 44 to when a response to the command is received by the CAN receiver 45, and notifying the load calculator 483 of the turnaround time.

[0094] The routing unit 43 provides the vehicle data provided from the CAN receiving unit 45 to the requesting application in accordance with routing information notified from the adjusting unit 482 of the schedule management unit 48.

[0095] [3. Operation] [3-1. Operation when the in-vehicle device is turned on] The operation of each part of the system when the vehicle-mounted device 30 is powered on will be described with reference to the sequence diagram shown in FIG.

[0096] 6, when the power supply to the on-vehicle device 30 is turned on, the on-vehicle device 30 executes a process S1 (hereinafter referred to as on-vehicle device initialization process) to initialize the on-vehicle device 30. By this on-vehicle device initialization process S1, the on-vehicle device 30 becomes ready for diagnostic communication using standard commands.

[0097] The vehicle-side DB management unit 49 transmits a VIN acquisition command, which is one of the standard commands, to the CAN bus 62 via the CAN transmitter 44, and receives the response via the CAN receiver 45, thereby acquiring VIN information from the vehicle 60.

[0098] The vehicle-side DB management unit 49 uses the acquired VIN information to determine whether the diagnostic command DB 341 and the frame interpretation DB 342 need to be updated. Specifically, if the diagnostic command DB 341 and the frame interpretation DB 342 do not store VIN-related information, it determines that they need to be updated. The VIN-related information is diagnostic command information and frame interpretation information linked to the acquired VIN information. If the diagnostic command DB 341 and the frame interpretation DB 342 already store VIN-related information, it determines that they do not need to be updated.

[0099] For example, when the on-board device 30 is attached to a vehicle for the first time, it is determined that an update is necessary. Also, when the on-board device 30 is removed from a first vehicle 60, and the VIN-related information of the first vehicle 60 remains in the diagnostic command DB 341 and the frame interpretation DB 342, and then attached to a second vehicle 60 and the VIN information of the second vehicle 60 is newly acquired, it is determined that an update is necessary.

[0100] If the vehicle-side DB management unit 49 determines that updating is not necessary, it ends the operation.

[0101] If the vehicle-side DB management unit 49 determines that an update is required, it transmits a data acquisition request together with the acquired VIN information to the cloud server 10, thereby acquiring VIN-related information corresponding to the vehicle model of the mounted vehicle 60 from the cloud server 10. At this time, the cloud-side DB management unit 22 of the cloud server 10 identifies the vehicle model from the VIN information indicated in the data acquisition request, reads out the VIN-related information corresponding to the identified vehicle model from the master DB 132, and returns it to the vehicle-mounted device 30.

[0102] The vehicle-side DB management unit 49 updates the diagnostic command DB 341 and the frame interpretation DB 342 with the VIN-related information received from the cloud server 10. The updated VIN-related information is stored in association with the VIN information.

[0103] In the following, among the processes described with reference to FIG. 6, a series of processes executed after the vehicle-mounted device initialization process S1 is also referred to as database update process S2.

[0104] [3-2. Turnaround time measurement] The operation of each part of the system when measuring the turnaround time of the diagnostic command used by the vehicle-mounted device 30 will be described with reference to the sequence diagram shown in FIG.

[0105] 16, after the on-board device initialization process S1 and the database update process S2 described above with reference to Fig. 6 are completed, the load calculation unit 483 reads out a plurality of pre-specified commands for measuring the turnaround time from the diagnostic command DB 341. It selects one of the read out commands as a measurement target command and notifies the CAN transmission unit 44 to measure the turnaround time using the selected measurement target command.

[0106] The CAN transmitter 44 transmits a measurement target command to the CAN bus 62. At this time, the CAN receiver 45 starts measuring the turnaround time. When the CAN receiver 45 receives a response from the CAN bus 62, it stops measuring the turnaround time and transmits the measurement result to the load calculator 483.

[0107] The load calculation unit 483 performs the same process for all commands read from the diagnostic command DB 341 to obtain the turnaround time for each command. After the load calculation unit 483 has finished transmitting all specified commands, it calculates the average value of the turnaround times. Furthermore, the load calculation unit 483 stores the measurement results of the turnaround times for each command and the calculation results of the average turnaround time in the diagnostic command DB 341 so that they can be used in the processing of the adjustment unit 482.

[0108] The load calculation unit 483 may measure the turnaround time every time the in-vehicle device 30 is started. Furthermore, the load calculation unit 483 may measure the turnaround time when a notification indicating a change in the hardware configuration is received from the external device management unit 50 or a notification indicating a change in the software configuration is received from the vehicle-side application management unit 46.

[0109] [3-3. Application distribution / command management table settings] The operation of each part of the system when the cloud server 10 distributes a diagnostic application to the in-vehicle device 30 will be described with reference to the sequence diagram shown in FIG.

[0110] As shown in FIG. 7, when a diagnostic application waiting to be distributed is stored in the application DB 131, the cloud-side application management unit 21 of the cloud server 10 transmits a distribution request to the in-vehicle device 30 to request that the in-vehicle device 30 accept the distribution of the diagnostic application.

[0111] When the vehicle-side application management unit 46 of the in-vehicle device 30 receives the distribution request, it determines whether to accept the distribution according to the information indicated in the distribution request, and if it accepts, it sends an acceptance notice to the cloud server 10. The information used to determine whether to accept the distribution may include the memory capacity required to store the program, the CPU processing power and memory capacity required to execute the application, etc.

[0112] The cloud-side application management unit 21 distributes and transmits the diagnostic applications and manifests stored in the application DB 131 to the in-vehicle device 30 that has returned the permission notification. At this time, the cloud-side application management unit 21 may register, in the application DB 131, information about the in-vehicle device 30 to which the applications are to be distributed (for example, VIN information of the vehicle in which the in-vehicle device 30 is installed).

[0113] When the vehicle-side application management unit 46 receives the diagnostic application from the cloud server 10, it deploys the received diagnostic application 411 so that it can be executed in the application execution environment 41. In addition, the vehicle-side application management unit 46 provides the manifest attached to the diagnostic application 411 to the manifest management unit 47. An application ID is assigned to the deployed diagnostic application 411, and this application ID is associated with the manifest provided to the manifest management unit 47.

[0114] Manifest management unit 47 stores the manifest provided from vehicle-side application management unit 46 in storage unit 471, and also interprets the contents of the manifest in interpretation unit 472 to extract information necessary for registration in the command management table. Specifically, interpretation unit 472 extracts the application ID, command ID, vehicle data acquisition condition (i.e., "mode attribute" and "mode sub-attribute"), and transmission priority associated with the manifest, and provides them to schedule management unit 48.

[0115] If the "mode attribute" of the manifest is periodic and the period value indicated in the "mode sub-attribute" is shorter than "tick", the vehicle-side application management unit 46 may be notified that vehicle data cannot be acquired at the requested timing. Upon receiving the notification, the vehicle-side application management unit 46 may delete the corresponding diagnostic application and notify the cloud server 10, which is the distributor, that the application has been deleted along with the reason.

[0116] Setting unit 481 of schedule management unit 48 updates the command management table using information provided by interpretation unit 472 of manifest management unit 47 (hereinafter, "update information").

[0117] As shown in Fig. 5, a command management table is prepared for each type of "mode attribute." The command management table is updated by adding new management information (i.e., application ID, command ID, transmission waiting status, auxiliary information, and transmission priority).

[0118] [3-4. Update waiting status] The operation of the adjustment unit 482 of the schedule management unit 48 to update the "transmission waiting status" in the command management table will be described.

[0119] For management information registered in the periodically driven command management table, the adjustment unit 482 subtracts 1 from the remaining number of ticks shown in the "transmission waiting status" and "auxiliary information (i.e., number of remaining transmissions)" each time the schedule adjustment process described below is completed. However, for management information in which the remaining number of ticks in the "transmission waiting status" before the subtraction is 0, the adjustment unit 482 presets the remaining number of ticks to a value corresponding to the periodic value instead of subtracting the remaining number of ticks.

[0120] If the number of remaining ticks of the "auxiliary information" becomes 0 as a result of subtracting the number of remaining ticks of the "auxiliary information," the adjustment unit 482 deletes the management information from the command management table.

[0121] When the adjustment unit 482 receives a trigger signal from the external device management unit 50 or the CAN receiving unit 45, it sets the "waiting for transmission status" of the management information corresponding to the received trigger signal to 0 in the event-driven command management table.

[0122] When the adjustment unit 482 receives a request for immediate acquisition of vehicle data from a diagnostic application via the API group 42, it sets the "waiting for transmission status" of the management information corresponding to the received immediate acquisition request to 0 in the command management table for immediate driving.

[0123] [3-5. Schedule Adjustment] The schedule adjustment process in which the adjustment unit 482 of the schedule management unit 48 uses the command management table to determine the diagnostic command to be transmitted in the next tick will be described with reference to the sequence diagram of FIG. 8 and the flowchart of FIG.

[0124] The adjustment unit 482 executes the schedule adjustment process for each tick.

[0125] When the schedule adjustment process starts, first, in S110, the adjustment unit 482 acquires the traffic conditions of the CAN bus 62. The traffic conditions may be information acquired from the ECU 63, which measures traffic on the CAN bus 62, or information acquired by separate measurement by the in-vehicle device 30. Alternatively, the traffic conditions may be static information (hereinafter, static traffic information) pre-registered in the system. The static traffic information may be, for example, an average value measured for each vehicle model, or a value obtained by adding a safety margin to the average value. The static traffic information may be included in information stored in the diagnostic command DB 341, for example. Furthermore, the static traffic information may be used when, for example, dynamic traffic information, which represents dynamic traffic conditions measured at each time, cannot be acquired from the ECU 63 or the in-vehicle device 30.

[0126] In the next step S120, the adjustment unit 482 references the "transmission waiting status" in the command management table and extracts, as transmission candidate commands, all management information for which the number of remaining ticks is set to 0, i.e., all management information to be processed in the next tick. FIG. 11 shows an example of transmission candidate commands (i.e., diagnostic command transmission requests) extracted for each tick based on the command management table. FIG. 11 shows a case in which three periodic commands C1 to C3 exist, with one event-driven command and two immediate-driven commands. Note that periodic command C1 is processed every 0.5 seconds (i.e., 5 ticks), periodic command C2 is processed every 0.2 seconds (i.e., 2 ticks), and periodic command C3 is processed every 0.1 seconds (i.e., 1 tick). FIG. 11 shows a diagnostic command transmission schedule before load adjustment.

[0127] In the next step S130, if there is duplicate management information having the same command ID among the management information extracted as transmission candidate commands, the adjustment unit 482 leaves one piece of management information and removes the other duplicate management information from the transmission candidate commands. The adjustment unit 482 also generates routing information to be provided to the routing unit 43. The routing information is information that associates the command ID indicated by the transmission candidate command with the application ID of the application that requested the transmission candidate command, based on information indicated in the command management table. In the routing information, each command ID is associated with one or more application IDs.

[0128] For example, as shown in Fig. 12, when multiple diagnostic applications 411 are configured to transmit periodic commands C4 and C5 for acquiring the same vehicle data at different intervals, requests from both applications may overlap in the same tick. In such a case, instead of transmitting both of the overlapping periodic commands C4 and C5, adjustments are made to transmit only one of them (for example, command C5 in Fig. 12). However, since the correspondence between the acquired vehicle data and the requesting application is unclear based on information from the CAN alone, which does not perform session management, routing information is used to ensure that the acquired vehicle data is correctly provided to the requesting application.

[0129] In the next S140, the adjustment unit 482 acquires the turnaround times of all the transmission candidate commands. As described above, the turnaround time for each command may be measured when the in-vehicle device 30 is started and may be a measured value stored in the diagnostic command DB 341, or may be an average value of the turnaround times calculated from the measured values, or may be a design value.

[0130] In the next step S150, the adjustment unit 482 calculates the required time Tneed that would be required if all transmission candidate commands were transmitted by alternating communication. The required time Tneed is the total value of the turnaround times for all transmission candidate commands. However, the turnaround time may be corrected to be longer the more congested the traffic situation obtained in S110.

[0131] In the next step S160, the adjustment unit 482 determines whether the processing in the next tick will result in an overload. An overload occurs when the required time Tneed calculated in step S150 is greater than the tick, or when the estimated traffic on the CAN bus 62 will exceed the allowable value if the transmission candidate command is transmitted. If the adjustment unit 482 determines in step S160 that an overload will not occur, it proceeds to step S200, and if it determines that an overload will occur, it proceeds to step S170.

[0132] In S170, the adjustment unit 482 determines whether or not there is an exclusion-allowed command among the transmission candidate commands. For example, a transmission candidate command whose priority value is equal to or less than the exclusion-allowed threshold value may be determined to be an exclusion-allowed command.

[0133] If there is an exclusion-allowed command among the transmission candidate commands, the adjustment unit 482 shifts the process to S180, and if there is no exclusion-allowed command, the adjustment unit 482 shifts the process to S190.

[0134] In S180, the adjustment unit 482 excludes at least one of the exclusion-possible commands included in the transmission candidate commands from the transmission candidate commands, and also excludes information about the excluded transmission candidate command from the routing information, and returns the process to S150. Note that the adjustment unit 482 may notify the requesting application of the excluded transmission candidate command that the request was not processed.

[0135] In S190, the adjustment unit 482 excludes at least one of the commands with the lowest priority value among the transmission candidate commands or the command with a period value equal to or greater than a predetermined value (e.g., 10 ticks) from the transmission candidate commands and sets the selected command as a transmission pending command. The adjustment unit 482 also excludes information related to the transmission pending command from the routing information. Furthermore, the adjustment unit 482 increments the number of remaining ticks in the "transmission waiting status" of the transmission pending command by 1 in the command management table so that the transmission pending command will be extracted as a transmission candidate command again in the next tick, and returns the process to S150. Note that the number by which the remaining ticks are incremented is not limited to 1, and may be, for example, a number randomly selected within a certain range. The certain range may also be set to be larger as the traffic on the CAN bus 62 becomes more congested.

[0136] In S200, the adjustment unit 482 notifies the CAN transmission unit 44 of the transmission candidate command as a transmission target command, and also notifies the routing unit 43 of the routing information, and then ends the process.

[0137] 13, when an excess load occurs, if the transmission candidate commands include an exclusion-enabled command CR, the exclusion-enabled command CR is excluded to adjust the load on the CAN bus 62. If the transmission candidate commands do not include an exclusion-enabled command CR, the load on the CAN bus 62 is adjusted by transmitting a low-priority command CL with a low priority among the transmission candidate commands, or a command with a period value equal to or greater than a predetermined value, in the next or subsequent ticks.

[0138] 8, when the CAN transmitter 44 receives notification of a command to be transmitted, it acquires a bit pattern representing the diagnostic command from the diagnostic command DB 341 according to the command ID indicated in the management information of the command to be transmitted. The CAN transmitter 44 generates a transmission frame (i.e., a CAN frame) with the acquired bit pattern set in the payload, and transfers the frame to the transmission buffer.

[0139] The CAN frame transferred to the transmission buffer is transmitted and received in accordance with the transmission and reception process of diagnostic communication on the CAN bus 62.

[0140] [3-6. Response Reception] The operation when the vehicle-mounted device 30 transmits a CAN frame carrying a diagnostic command and receives a CAN frame carrying a response to the diagnostic command (i.e., vehicle data) from the vehicle 60 will be described using the sequence diagram shown in FIG.

[0141] As shown in FIG. 9, when the CAN receiver 45 receives a CAN frame indicating a response to the diagnostic command, the frame interpreter 451 performs bit analysis on the payload of the received CAN frame. For the bit analysis, frame interpretation information stored in the frame interpretation DB 342 is used. The vehicle data obtained by the bit analysis may be a value representing some state (for example, on / off status of a switch) or may be a sampled value of an analog signal (i.e., a physical quantity). When the vehicle data represents a physical quantity, the frame interpreter 451 may convert the acquired physical quantity into a predetermined unit (for example, a unit used by the requesting application) or may perform time-series processing on the acquired physical quantity. The time-series processing is a process of performing differentiation, integration, smoothing, etc. on the acquired vehicle data.

[0142] The CAN receiver 45 notifies the routing unit 43 of the vehicle data processed by the frame interpreter 451 together with a command ID that indicates the diagnostic command sent to acquire the vehicle data.

[0143] The routing unit 43 identifies the application ID corresponding to the command ID by referring to the routing information notified by the schedule management unit 48, based on the command ID and vehicle data notified by the CAN receiving unit 45. Furthermore, the routing unit 43 notifies the requesting application indicated by the application ID of the vehicle data via the application execution environment 41.

[0144] [4. Terminology] In this embodiment, the CAN transmitter 44 and the CAN receiver 45 correspond to a data acquisition unit in this disclosure, the application execution environment 41 corresponds to an application execution unit in this disclosure, the vehicle-side DB manager 49 corresponds to a peripheral information acquisition unit in this disclosure, and the diagnostic command information and frame interpretation information correspond to peripheral information in this disclosure.

[0145] [5. Effects] According to the embodiment described above in detail, the following effects are achieved.

[0146] (5a) In the data providing system 1, the in-vehicle device 30 generates management information to be registered in the command management table in accordance with a manifest distributed from the cloud server 10 together with the diagnostic applications 411. Then, the in-vehicle device 30 adjusts the timing of processing vehicle data acquisition requests from multiple diagnostic applications by using the management information registered in the command management table.

[0147] Therefore, the on-board device 30 can simultaneously operate a plurality of diagnostic applications that utilize diagnostic communication. That is, the diagnostic port 61 of the vehicle 60 can be simultaneously used for a plurality of different purposes.

[0148] (5b) The on-board device 30 manages the vehicle data acquisition schedule according to a manifest that indicates the vehicle data acquisition conditions. The on-board device 30 also generates diagnostic commands suitable for the on-board vehicle 60 and interprets responses from the on-board vehicle 60 according to the diagnostic command information and frame interpretation information. Therefore, an application developer can develop the diagnostic application 411 even if they lack knowledge about diagnostic communication for the target vehicle 60.

[0149] (5c) The in-vehicle device 30 creates routing information to associate the diagnostic command to be sent with the requesting application. Therefore, even if the request to send the same command is duplicated at the same tick timing and the duplicate command is deleted, the in-vehicle device 30 can refer to the routing information and correctly provide the acquired vehicle data to all requesting applications.

[0150] (5d) In the onboard device 30, if there is a possibility of excessive load if all transmission candidate commands extracted from the command management table are transmitted, load adjustment is performed. In the load adjustment, some of the transmission candidate commands are excluded from transmission targets or adjusted so that they are processed in the next or subsequent ticks. Therefore, traffic on the CAN bus 62 can be kept within an acceptable range, and effects such as delays in transmission and reception of regular commands (e.g., vehicle control commands) transmitted and received between ECUs 63 can be suppressed. Furthermore, an application developer can develop a diagnostic application 411 that operates safely even without knowledge of traffic restrictions on the CAN bus 62 in each vehicle 60.

[0151] (5e) In the case of a periodically driven request, the in-vehicle device 30 sets a lower priority as the periodic value increases. In other words, the impact of a deviation (i.e., delay) in the transmission period of a low-priority command caused by processing being suspended due to an excessive load becomes relatively smaller as the periodic value of the suspended command increases, thereby minimizing the impact on the function realized by the requesting application.

[0152] 6. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0153] (6a) In the above embodiment, when there is an excessive load and there are no commands that can be excluded, the processing of low-priority commands is delayed. However, the processing of commands related to immediate drive or event drive may also be delayed.

[0154] (6b) In the above embodiment, the diagnostic communication on the CAN bus 62 is based on alternate transmission, in which commands are completed one by one after waiting for a response from the vehicle, as shown in the upper part of Figure 14. The present disclosure is not limited to alternate transmission, and transmission operations may be performed in parallel (hereinafter referred to as parallel transmission) without waiting for a response from the vehicle, as shown in the lower part of Figure 14. In this case, it is necessary to adjust the number of commands that can be transmitted in parallel so that traffic does not exceed the allowable range.

[0155] (6c) In the above embodiment, when management information is added to the command management table in accordance with the manifest, the initial value of the "send waiting status" is set to a value corresponding to the periodic value. The initial value of the "send waiting status" may be adjusted so that transmission candidate commands are not concentrated in the same tick. For example, as shown in FIG. 15, if there are three periodic commands C6 to C8 with an acquisition period of 3 ticks, the initial value of the "send waiting status" when registering the management information may be adjusted so that each of the periodic commands C6 to C8 is processed in a different tick.

[0156] (6d) In the above embodiment, in S120 of the schedule adjustment process, the adjustment unit 482 references the "transmission status" in the command management table and extracts, as transmission candidate commands, all management information for which the number of remaining ticks is set to 0, i.e., all management information to be processed in the next tick. However, the method of extracting transmission candidate commands is not limited to this. For example, in S120, the adjustment unit 482 may reference the "transmission status" in the command management table and extract, as transmission candidate commands, all management information for which the number of remaining ticks is set to 1, i.e., all management information to be processed in the tick after next. In this case, in S130 to S190, the transmission candidate commands to be processed in the tick after next, which were extracted in S120 of the current schedule adjustment process, are narrowed down. Then, in S200, processing may be performed using the transmission candidate commands for which the number of remaining ticks is set to 0, i.e., the transmission candidate commands extracted and narrowed down in the previous schedule adjustment process, as transmission target commands.

[0157] When this schedule adjustment process is employed, the "transmission waiting status" whose "mode attribute" is immediate drive may be set to a predetermined number greater than or equal to 1 when a request is made from the diagnostic application 411. Similarly, the "transmission waiting status" whose "mode attribute" is event drive may be set to a predetermined number greater than or equal to 1 when a specified trigger condition is satisfied.

[0158] Furthermore, in S120 of the schedule adjustment process, the adjustment unit 482 may refer to the "send waiting status" in the command management table and extract all management information for which the number of remaining ticks is set to a predetermined number of ticks greater than 1 as transmission candidate commands. In S200, the adjustment unit 482 may refer to the "send waiting status" in the command management table and process transmission candidate commands for which the number of remaining ticks is set to 0 as commands to be transmitted. In this case, the "send waiting status" for which the "mode attribute" is immediate drive may be set to a number equal to or greater than the predetermined number of ticks when a request is made from the diagnostic application 411. Similarly, the "send waiting status" for which the "mode attribute" is event drive may be set to a number equal to or greater than the predetermined number of ticks when a specified trigger condition is satisfied.

[0159] Furthermore, in the above embodiment, steps S120 to S190 of the schedule adjustment process are executed every transmission cycle, i.e., every tick, but they may also be executed every multiple transmission cycles, for example, every two ticks. In this case, in S120, the adjustment unit 482 may refer to the "transmission waiting status" in the command management table and extract, for example, all management information in which the number of remaining ticks is set to 0 or 1 as transmission candidate commands. In this case, in steps S130 to S190, the transmission candidate commands extracted in S120 are narrowed down. In S200, the process may be executed with all transmission candidate commands that remain without being excluded by the narrowing down as commands to be transmitted.

[0160] (6e) In the above embodiment, immediate drive was a mode used when specified vehicle data was acquired "immediately" only once in accordance with an instruction from a diagnostic application. However, as described in the modified example of the schedule adjustment process, the "transmission waiting status" of the "mode attribute" of immediate drive is not limited to being set to 0 when a request is made from the diagnostic application 411, but may be set to a predetermined number of ticks greater than or equal to 1. In other words, instead of acquiring vehicle data "immediately," the vehicle data may be acquired within a limited time period. In this case, the "mode attribute" can be understood as app drive, which is a higher-level concept than immediate drive. App drive is a mode in which vehicle data is acquired in response to a request from an application program.

[0161] (6f) In the above embodiment, when the "mode attribute" is immediate drive or event drive, the number of ticks set as the "transmission waiting status" indicates the timing to execute the process, but it may also indicate the latest allowable timing for executing the process. In this case, in the schedule adjustment process, if there is room in the processing load, transmission candidate commands with a remaining number of ticks other than 0 may be added to the transmission target commands and processed.

[0162] (6g) The control unit 31 and its method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit 31 and its 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 31 and its method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer. The method for implementing the functions of each unit included in the control unit 31 does not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

[0163] (6h) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0164] (6i) In addition to the above-described vehicle-mounted device 30, the present disclosure can also be realized in various forms, such as a system including the vehicle-mounted device 30 as a component, a program for causing a computer to function as the vehicle-mounted device 30, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a data provision method.

[0165] [7. Technical Ideas Disclosed in the Present Specification] [Item 1] a data acquisition unit (44, 45) configured to repeatedly execute a transmission process of transmitting a command used to acquire vehicle data to an in-vehicle network; an application execution unit (41) configured to execute one or more application programs that utilize the vehicle data acquired by the data acquisition unit; a schedule management unit (48) configured to use one or more pieces of management information indicating the type of the command used to acquire the vehicle data, the request source application that is the application program that requests the vehicle data, and acquisition conditions for the vehicle data, to extract the command indicated by the management information that satisfies the acquisition conditions as a transmission target command that is the command to be transmitted in the transmission process, and to generate routing information that associates the transmission target command with the request source application; a routing unit (43) configured to provide the vehicle data acquired by the data acquisition unit executing the transmission process to the request source application using the routing information; An in-vehicle device comprising:

[0166] [Item 2] The vehicle-mounted device according to item 1, the data acquisition unit is configured to repeatedly execute the transmission process at a preset execution cycle; The schedule management unit is configured to extract the command indicated by the management information that satisfies the acquisition condition as the transmission target command, which is the command to be transmitted in the next or subsequent execution cycles. Onboard machine.

[0167] [Item 3] The vehicle-mounted device according to item 1 or 2, the schedule management unit is configured to acquire, from a distributor of the application program, a manifest that is linked to the application program and describes the type of vehicle data required by the application program and conditions for acquiring the vehicle data, and to generate the management information in accordance with the manifest. Onboard machine.

[0168] [Item 4] The vehicle-mounted device according to item 3, The manifest includes, as a method for specifying the acquisition conditions of the vehicle data, a periodic drive for repeatedly acquiring the vehicle data at a fixed period, an application drive for acquiring the vehicle data in response to a request from the application program, and an event drive for acquiring the vehicle data when a specified event occurs. Onboard machine.

[0169] [Item 5] The vehicle-mounted device according to item 3 or 4, The manifest includes, as a method for specifying the type of vehicle data, a name specification that specifies the type of vehicle data using a standardized name that indicates the meaning of the vehicle data, and a command specification that specifies the type of vehicle data in a format that is transmitted and received over the in-vehicle network. Onboard machine.

[0170] [Item 6] The vehicle-mounted device according to any one of items 3 to 5, a peripheral information acquisition unit (49) that acquires peripheral information including information for interpreting a frame received from the in-vehicle network of the vehicle to which the in-vehicle device is connected and information indicating a list of the commands that can be used in the vehicle, by wireless communication with a server provided outside the vehicle; The data acquisition unit is configured to convert the management information based on the manifest into a format that can be transmitted over the in-vehicle network using the peripheral information, and to interpret a response from the in-vehicle network using the peripheral information. Onboard machine.

[0171] [Item 7] The vehicle-mounted device according to any one of items 1 to 6, the schedule management unit is configured to, when there is a possibility that the in-vehicle network will be overloaded if all of the transmission target commands extracted from the one or more pieces of management information are transmitted in the transmission process, exclude some of the transmission target commands from being processed in the transmission process so as to prevent the overload from occurring. Onboard machine.

[0172] [Item 8] Item 7: The vehicle-mounted device according to item 7, the schedule management unit is configured to determine that the load is excessive when the traffic of the in-vehicle network exceeds a tolerance value; Onboard machine.

[0173] [Item 9] The vehicle-mounted device according to item 7, which cites item 2, the schedule management unit is configured to determine that the load is excessive when a total value of turnaround times of the commands to be transmitted exceeds a cycle of the execution cycle. Onboard machine.

[0174] [Item 10] Item 9: The vehicle-mounted device according to item 9, The turnaround time is measured when the in-vehicle device is started. Onboard machine.

[0175] [Item 11] The vehicle-mounted device according to item 9 or 10, When there is a change in the configuration of the hardware connected to the in-vehicle device or the configuration of the application program executed by the application execution unit, the turnaround time is measured. Onboard machine.

[0176] [Item 12] An in-vehicle device according to any one of items 7 to 11, which cites item 2, the schedule management unit is configured to adjust the management information so that the management information excluded from the command to be sent is extracted as the command to be sent in an execution period later than the execution period in which the management information was excluded from the command to be sent, Onboard machine.

[0177] [Item 13] The vehicle-mounted device according to any one of items 7 to 12, the management information includes a priority for transmitting the command; the schedule management unit is configured to, when determining that the load is excessive, exclude the management information whose priority is the lowest or whose priority is equal to or less than an exclusion threshold value from among the commands to be transmitted; Onboard machine.

[0178] [Item 14] Item 13: The vehicle-mounted device according to item 13, The priority is set according to the data type of the vehicle data acquired by the command. Onboard machine.

[0179] [Item 15] The vehicle-mounted device according to item 13 or 14, The priority is set according to the acquisition conditions of the vehicle data acquired by the command. Onboard machine.

[0180] [Item 16] The vehicle-mounted device according to any one of items 1 to 15, The vehicle data acquired by the data acquisition unit includes at least one of vehicle speed, total mileage, vehicle acceleration, vehicle angular velocity, GPS location information, gear position, battery charge status, fuel tank capacity, remaining fuel amount, average fuel consumption, headlight status, interior and exterior temperatures, air conditioner operation status, door and window open / close status, door and window lock status, seat belt status, airbag status, tire pressure, parking brake status, accelerator pedal position, brake pedal position, brake pressure, and fault diagnosis code list. Onboard machine.

[0181] [Item 17] The vehicle-mounted device according to any one of items 1 to 16, The vehicle-mounted device is connected to the vehicle-mounted network via a diagnostic port (61) provided in the vehicle, The data acquisition unit is configured to use a diagnostic command used in diagnostic communication as the command. Onboard machine.

Claims

1. a data acquisition unit (44, 45) configured to execute a transmission process for transmitting a command used to acquire vehicle data to an in-vehicle network; an application execution unit (41) configured to execute one or more application programs that utilize the vehicle data acquired by the data acquisition unit; a schedule management unit (48) configured to use one or more pieces of management information indicating the type of the command used to acquire the vehicle data, the request source application that is the application program that requests the vehicle data, and acquisition conditions for the vehicle data, to extract the command indicated by the management information that satisfies the acquisition conditions as a transmission target command that is the command to be transmitted in the transmission process, and to generate routing information that associates the transmission target command with the request source application; a routing unit (43) configured to provide the vehicle data acquired by the data acquisition unit executing the transmission process to the request source application using the routing information; An in-vehicle device comprising:

2. 2. The vehicle-mounted device according to claim 1, the data acquisition unit is configured to repeatedly execute the transmission process at a preset execution cycle; The schedule management unit is configured to extract the command indicated by the management information that satisfies the acquisition condition as the transmission target command, which is the command to be transmitted in the next or subsequent execution cycles. Onboard machine.

3. 3. The vehicle-mounted device according to claim 1 or 2, the schedule management unit is configured to acquire, from a distributor of the application program, a manifest that is linked to the application program and describes the type of vehicle data required by the application program and conditions for acquiring the vehicle data, and to generate the management information in accordance with the manifest. Onboard machine.

4. The vehicle-mounted device according to claim 3, The manifest includes, as a method for specifying the acquisition conditions of the vehicle data, a periodic drive for repeatedly acquiring the vehicle data at a fixed period, an application drive for acquiring the vehicle data in response to a request from the application program, and an event drive for acquiring the vehicle data when a specified event occurs. Onboard machine.

5. The vehicle-mounted device according to claim 3, The manifest includes, as a method for specifying the type of vehicle data, a name specification that specifies the type of vehicle data using a standardized name that indicates the meaning of the vehicle data, and a command specification that specifies the type of vehicle data in a format that is transmitted and received over the in-vehicle network. Onboard machine.

6. The vehicle-mounted device according to claim 3, a peripheral information acquisition unit (49) that acquires peripheral information including information for interpreting a frame received from the in-vehicle network of the vehicle to which the in-vehicle device is connected and information indicating a list of the commands that can be used in the vehicle, by wireless communication with a server provided outside the vehicle; The data acquisition unit is configured to convert the management information based on the manifest into a format that can be transmitted over the in-vehicle network using the peripheral information, and to interpret a response from the in-vehicle network using the peripheral information. Onboard machine.

7. 3. The vehicle-mounted device according to claim 1 or 2, the schedule management unit is configured to, when there is a possibility that the in-vehicle network will be overloaded if all of the transmission target commands extracted from the one or more pieces of management information are transmitted in the transmission process, exclude some of the transmission target commands from being processed in the transmission process so as to prevent the overload from occurring. Onboard machine.

8. The vehicle-mounted device according to claim 7, the schedule management unit is configured to determine that the load is excessive when the traffic of the in-vehicle network exceeds a tolerance value; Onboard machine.

9. The vehicle-mounted device according to claim 7, which relies on claim 2, the schedule management unit is configured to determine that the load is excessive when a total value of turnaround times of the commands to be transmitted exceeds the execution period; Onboard machine.

10. The vehicle-mounted device according to claim 9, The turnaround time is measured when the in-vehicle device is started. Onboard machine.

11. The vehicle-mounted device according to claim 9, When there is a change in the configuration of the hardware connected to the in-vehicle device or the software configuration of the application program executed by the application execution unit, the turnaround time is measured. Onboard machine.

12. The vehicle-mounted device according to claim 7, which relies on claim 2, the schedule management unit is configured to adjust the management information so that the management information excluded from the command to be sent is extracted as the command to be sent in an execution period later than the execution period in which the management information was excluded from the command to be sent, Onboard machine.

13. The vehicle-mounted device according to claim 7, the management information includes a priority for transmitting the command; the schedule management unit is configured to, when determining that the load is excessive, exclude the management information whose priority is the lowest or whose priority is equal to or less than an exclusion threshold value from among the commands to be transmitted; Onboard machine.

14. The vehicle-mounted device according to claim 13, The priority is set according to the data type of the vehicle data acquired by the command. Onboard machine.

15. The vehicle-mounted device according to claim 13, The priority is set according to the acquisition condition of the vehicle data acquired by the command. Onboard machine.

16. 2. The vehicle-mounted device according to claim 1, The vehicle data acquired by the data acquisition unit includes at least one of vehicle speed, total mileage, vehicle acceleration, vehicle angular velocity, GPS position information, gear position, battery charge state, fuel tank capacity, remaining fuel amount, average fuel consumption, headlight status, interior and exterior temperatures, air conditioner operation status, door and window open / close status, door and window lock status, seat belt status, airbag status, tire pressure, parking brake status, accelerator pedal position, brake pedal position, brake pressure, and a fault diagnosis code list. Onboard machine.

17. 2. The vehicle-mounted device according to claim 1, The vehicle-mounted device is connected to the vehicle-mounted network via a diagnostic port (61) provided in the vehicle, The data acquisition unit is configured to use a diagnostic command used in diagnostic communication as the command. Onboard machine.

18. 1. A data providing method for an on-board device that executes a transmission process of transmitting a command used to acquire vehicle data to an on-board network, and provides the vehicle data acquired by the transmission process to one or more application programs, the data providing method comprising: extracting the command indicated by the management information that satisfies the acquisition conditions as a transmission target command, which is the command to be transmitted in the transmission process, using one or more pieces of management information indicating the type of the command used to acquire the vehicle data, the request source application, and an acquisition condition for the vehicle data, and generating routing information that associates the transmission target command with the request source application; providing the vehicle data acquired by executing the transmission process to the request source application using the routing information; How data is provided.

19. a program executed in an on-board device that executes a transmission process for transmitting a command used to acquire vehicle data to an on-board network, and provides the vehicle data acquired by the transmission process to one or more application programs, the program providing the vehicle data to a request source application that is the application program that requests the vehicle data, The vehicle-mounted device, a process of extracting the command indicated by the management information that satisfies the acquisition conditions as a transmission target command, which is the command to be transmitted in the transmission process, using one or more pieces of management information indicating the type of the command used to acquire the vehicle data, the request source application, and an acquisition condition of the vehicle data, and generating routing information that associates the transmission target command with the request source application; and providing the vehicle data acquired by executing the transmission process to the request source application using the routing information.

Images