In-vehicle device, data provision system, data provision method, and program

Abstract

According to the present invention, a standard vehicle data storage unit (343) converts specific vehicle data acquired by a data acquisition unit (44, 45) into a form of standard vehicle data, and stores the converted data. An API group (42) is a set of application programming interfaces prepared for respective pieces of the standard vehicle data. The API group provides a function of acquiring standard vehicle data from the standard vehicle data storage unit, for an application program to be executed in an application execution unit (41).

Description

Cross-reference to Related Applications

[0001] This international application claims priority based on Japanese Patent Application No. 2022-212067 filed with the Japan Patent Office on December 28, 2022, and incorporates the entire contents of Japanese Patent Application No. 2022-212067 by reference into this international application.

Technical Field

[0002] This disclosure relates to a technology for providing vehicle data to an application program operating on an in-vehicle device connected to an in-vehicle network.

Background Art

[0003] Patent Document 1 below describes a device that performs diagnostic communication for fault diagnosis using data transmitted and received 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, a request message is transmitted from the diagnostic tester to the ECU, and the ECU returns a response message. OBD is an abbreviation for on-board diagnostic.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] However, as a result of the inventors' detailed examination, the following problems were found. That is, the number of ports for diagnostic communication mounted on a vehicle is usually one, and one diagnostic tester is connected. And it was found that the diagnostic tester can only execute one application and can only be used for a single purpose and independently.

[0006] One aspect of this disclosure is the provision of technology that enables simultaneous use of in-vehicle devices connected to an in-vehicle network for multiple purposes.

[0007] One aspect of this disclosure is an in-vehicle device comprising a data acquisition unit, a standard vehicle data storage unit, an application execution unit, and an API group. The data acquisition unit is configured to perform a transmission process according to instructions that specify one or more types of standard vehicle data, which are standardized vehicle data. The transmission process is the process of acquiring unique vehicle data, which is vehicle data expressed in a vehicle-specific format, from the in-vehicle network by sending a command to the in-vehicle network of the vehicle on which the in-vehicle device is installed. The standard vehicle data storage unit is configured to convert the unique vehicle data acquired by the data acquisition unit into the format of standard vehicle data and store it. The application execution unit is configured to execute one or more application programs that utilize the standard vehicle data. The API group is a set of application programming interfaces provided for each type of standard vehicle data in order to provide the application program executed by the application execution unit with the function to acquire standard vehicle data from the standard vehicle data storage unit.

[0008] With this configuration, vehicle data acquired via the in-vehicle network and stored in the standard vehicle data storage unit in the format of standard vehicle data is provided to application programs via a set of APIs. Therefore, the in-vehicle unit can simultaneously install and operate multiple applications, each with a different purpose.

[0009] One aspect of this disclosure is a data provision system. The data provision system comprises one or more in-vehicle devices and a server. The server is located outside the vehicle on which the in-vehicle devices are installed. The in-vehicle devices have the configuration described above. The server includes a digital twin database that stores at least one of the following: standard vehicle data transmitted from each of the in-vehicle devices, and digital twin data that emulates the vehicle on which the in-vehicle devices are installed, generated based on the standard vehicle data.

[0010] With this configuration, the same effects as those of the in-vehicle device described above can be obtained.

[0011] One aspect of this disclosure is a data provision method for providing vehicle data acquired via an in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs deployed on the in-vehicle device. In this method, a transmission process is performed according to instructions that specify one or more types of standardized vehicle data, which are standardized vehicle data. The transmission process is the process of acquiring unique vehicle data, which is vehicle data expressed in a format specific to the vehicle, from the in-vehicle network by sending a command to the in-vehicle network. In this method, the unique vehicle data acquired by executing the transmission process is converted into the format of standard vehicle data and stored in a standard vehicle data storage unit. In this method, in order to provide the function of acquiring standard vehicle data from the standard vehicle data storage unit, the standard vehicle data is provided to the application program by a set of APIs, which are a collection of application programming interfaces prepared for each of the standard vehicle data.

[0012] This method can achieve the same effects as the in-vehicle device described above.

[0013] One aspect of this disclosure is a program. The program is executed to provide vehicle data acquired via the in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs located in the in-vehicle device.

[0014] The program instructs the in-vehicle unit to perform a transmission process. The transmission process involves sending commands to the in-vehicle network according to instructions that specify one or more types of standardized vehicle data, which are standardized vehicle data. In doing so, the unit obtains unique vehicle data, which is vehicle data expressed in a format specific to the vehicle, from the in-vehicle network.

[0015] The program instructs the in-vehicle unit to convert the unique vehicle data acquired by performing the transmission process into the standard vehicle data format and store it in the standard vehicle data storage unit.

[0016] The program causes the in-vehicle unit to provide standard vehicle data to the application program via a set of APIs. The API set is a collection of application programming interfaces provided for each type of standard vehicle data, in order to provide the function of retrieving standard vehicle data from the standard vehicle data storage unit.

[0017] By running such a program, the same effects as those of the in-vehicle device described above can be obtained. [Brief explanation of the drawing]

[0018] [Figure 1] This is a block diagram showing the functional configuration of the data provision system. [Figure 2] This is a block diagram showing the hardware configuration of the cloud server. [Figure 3] This is a block diagram showing the hardware configuration of the in-vehicle unit. [Figure 4] This is an explanatory diagram showing the structure of a manifesto. [Figure 5] This is an explanatory diagram showing the structure of a standard vehicle data instruction sheet. [Figure 6] This is an explanatory diagram showing the structure of the data stored in the standard vehicle data database. [Figure 7] This is an explanatory diagram showing the structure of the command management table based on the manifest. [Figure 8] This is an explanatory diagram showing the structure of the command management table based on the standard vehicle data instruction manual. [Figure 9] This is a sequence diagram showing the operation of each part of the system when the in-vehicle unit is powered on. [Figure 10] This is a sequence diagram showing the operation during turnaround time measurement. [Figure 11]It is a sequence diagram showing the operation when updating the standard vehicle data instruction manual. [Figure 12] It is a sequence diagram showing the operation when distributing the diagnostic application. [Figure 13] It is a sequence diagram showing the operation when transmitting a diagnostic command. [Figure 14] It is a sequence diagram showing the operation when receiving a response to a diagnostic command. [Figure 15] It is a sequence diagram showing the operation when using the standard vehicle data DB. [Figure 16] It is a flowchart showing the content of the schedule adjustment process. [Figure 17] It is an explanatory diagram exemplifying the request of the diagnostic command extracted at each tick. [Figure 18] It is an explanatory diagram showing the operation when the requests of the diagnostic commands overlap. [Figure 19] It is an explanatory diagram showing the operation when the load on the CAN bus may exceed. [Figure 20] It is an explanatory diagram about the method of transmitting commands. [Figure 21] It is an explanatory diagram showing an example of setting the transmission schedule so that the diagnostic commands do not concentrate in the same tick.

Mode for Carrying Out the Invention

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

[0020] [1. Configuration] The data providing system 1 shown in FIG. 1 includes a cloud server 10 and an in-vehicle unit 30. In FIG. 1, for example, one cloud server 10 and one in-vehicle unit 30 are shown, but the data providing system 1 may include a plurality of cloud servers 10 and a plurality of in-vehicle units 30.

[0021] [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 necessary for the in-vehicle unit 30 to execute a diagnostic application program (hereinafter referred to as a diagnostic application) on the in-vehicle unit 30. The diagnostic application is an application that utilizes vehicle data collected using diagnostic communication. Diagnostic communication is a communication method that uses an in-vehicle network to acquire vehicle data necessary 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 stands for Controller Area Network. CAN is a registered trademark.

[0022] Vehicle data is classified into multiple data types. These data types may include "vehicle control / powertrain systems," "AD / ADAS systems," "driver monitoring systems," "vehicle body systems," "in-cabin / out-of-vehicle environment control systems," "fuel / exhaust systems," "media systems," and "diagnostic codes (DTCs)."

[0023] Vehicle data for body control and powertrain systems may include vehicle speed, vehicle acceleration, vehicle angular velocity, gear position, accelerator pedal position, brake pedal position, brake pressure, etc.

[0024] AD / ADAS vehicle data may include following distance, speed limit signs, stop sign detection, lane keeping warning, following the preceding vehicle, clearance sonar, and whether or not obstacles are detected.

[0025] Driver monitoring system vehicle data may include statuses such as distraction detection status, decreased attention detection status, and driver abnormality detection status.

[0026] Vehicle body data may include total mileage (i.e., odometer reading), Global Positioning System (GPS) location information, light status, door / window open / closed status, door / window locked status, seat belt status, airbag status, tire pressure, air conditioning operation status, parking brake status, etc.

[0027] Vehicle data from the in-vehicle and out-of-vehicle environment control system may include in-vehicle and out-of-vehicle temperatures, air conditioning operation status, etc.

[0028] Vehicle data for the fuel and exhaust systems may include battery charge status, fuel tank capacity, remaining fuel level, average fuel consumption, etc.

[0029] Media-related vehicle data may include media usage status, volume, Bluetooth (BT) connection status, Data Communication Module (DCM) connection status, etc. Bluetooth is a registered trademark.

[0030] Vehicle data for DTC may include DTC lists, etc.

[0031] Vehicle data may be assigned priorities according to its data type. Priorities may be set, for example, as follows. However, the priority setting by data type is not limited to the order below and can be set arbitrarily.

[0032] Vehicle control / powertrain systems > AD / ADAS systems > Driver monitoring systems > Vehicle body systems > In-cabin / out-of-vehicle environment control systems > Fuel / exhaust systems > Media systems > DTC As shown in Figure 2, the cloud server 10 comprises a control unit 11, a communication unit 12, and a storage unit 13.

[0033] The control unit 11 comprises a CPU 111, a ROM 112, and a RAM 113. The various functions of the control unit 11 are realized by the CPU 111 executing a program stored in a non-transitional physical recording medium. In this example, the ROM 112 corresponds to the non-transitional physical recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program.

[0034] The communication unit 12 communicates data with the in-vehicle unit 30 via wireless communication over a wide-area communication network NW.

[0035] The memory unit 13 includes an application database (hereinafter referred to as App DB) 131, a master database (hereinafter referred to as Master DB) 132, and a digital twin database (hereinafter referred to as Digital Twin DB) 133. The App 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 in-vehicle unit 30 is connected. The Digital Twin DB 133 stores information necessary for generating a digital twin, a technology that reproduces the state and movement of an actual vehicle in a virtual space.

[0036] [1-2.In-vehicle device] As shown in Figure 1, the in-vehicle unit 30 is used by connecting to a diagnostic port 61 provided in the vehicle 60. The in-vehicle unit 30 downloads and runs one or more diagnostic applications 411 from the cloud server 10.

[0037] As shown in Figure 3, the in-vehicle unit 30 comprises a control unit 31, a vehicle interface (hereinafter referred to as vehicle I / F) 32, a communication unit 33, and a storage unit 34.

[0038] The control unit 31 comprises a CPU 311, a ROM 312, and a RAM 313. The various functions of the control unit 31 are realized by the CPU 311 executing a program stored in a non-transitional physical recording medium. In this embodiment, the ROM 312 corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program executes a method corresponding to the program.

[0039] The vehicle interface 32 includes a diagnostic connector 321 and an expansion connector 322.

[0040] As shown in Figure 1, the diagnostic connector 321 is connected to a diagnostic port 61 (for example, an OBD port) provided by the vehicle 60. In other words, the in-vehicle unit 30 is connected to the 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.

[0041] The expansion connector 322 receives signals from a group of exterior devices 70 that are retrofitted to the vehicle. The group of exterior devices 70 may include a communication chip (e.g., BLE, LTE, NFC, etc.), a camera, a microphone, a speaker, an accelerometer, a gyroscope, etc. BLE stands for Bluetooth Low Energy, LTE stands for Long Term Evolution, and NFC stands for Near Field Communication.

[0042] Returning to Figure 3, the communication unit 33 communicates data with the cloud server 10 connected to the wide-area communication network NW via wireless communication.

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

[0044] The diagnostic command DB 341 stores diagnostic command information obtained from the cloud server 10 via the communication unit 33. The frame interpretation DB 342 stores frame interpretation information and normalization rules obtained from the cloud server 10 via the communication unit 33. The diagnostic command information, frame interpretation information, and normalization rules will be described later.

[0045] [2. Functional Configuration] Next, we will describe the functional configuration of the cloud server 10 and the in-vehicle device 30.

[0046] [2-1. Cloud Server] As shown in Figure 1, the cloud server 10 includes an application DB 131, a master DB 132, and a digital twin DB 133. The application DB 131, master DB 132, and digital twin DB 133 are configured on the storage unit 13.

[0047] The application DB131 stores one or more diagnostic applications to be distributed to the in-vehicle device 30, and manifests associated with each of the diagnostic applications.

[0048] A manifest is a set of instructions that describes the type of vehicle data and the conditions for acquiring each vehicle data for one or more vehicle data used in a diagnostic application. The manifest is created by the application developer. The manifest is written in a format that can be understood by the application developer even without specialized vehicle knowledge. Specifically, as shown in Figure 4, the manifest includes "request information" and "mode attributes." Furthermore, depending on the content of the "mode attributes," the manifest may also include "mode sub-attributes" and "application metadata."

[0049] "Request information" is information that specifies the type of vehicle data. When specifying the type of vehicle data, you can use either name specification or command specification. Name specification is a method of specifying vehicle data using a standardized name that allows for an intuitive understanding of its meaning, and is defined commonly regardless of the vehicle type. Vehicle data that can be specified by name specification is also called standard vehicle data. Command specification is a method of specifying vehicle data in the format (i.e., bit pattern) that is actually transmitted and received in the vehicle's diagnostic communication, and is defined uniquely for each vehicle type. The same vehicle data may be configured to be specified by either name specification or command specification.

[0050] The "mode attribute" specifies how to acquire the vehicle data indicated in the "request information". There are three types of "mode attributes": application-driven, periodic-driven, and event-driven. Application-driven is the mode used when acquiring specified vehicle data a limited number of times within a limited time, in accordance with instructions from a diagnostic application. Among the application-driven modes, acquiring the data immediately once is called immediate-driven. In this embodiment, immediate-driven will be described as an example of application-driven mode. Periodic-driven is the mode used when acquiring specified vehicle data repeatedly at a specified fixed interval. Event-driven is the mode used when acquiring specified vehicle data triggered by a change in a signal detected when a specified event occurs.

[0051] "Mode sub-attributes" are different types of information depending on the type of "mode attribute," and the information is set as needed. Note that if the "mode attribute" is immediate drive, there does not need to be any information to set as "mode sub-attributes." If the "mode attribute" is periodic drive, the "mode sub-attributes" may include a period value representing the vehicle data acquisition cycle and a period value representing the vehicle data acquisition period. If the "mode attribute" is event drive, the "mode sub-attributes" may include trigger conditions. Trigger conditions define which signal, in what state, will trigger an event. Trigger conditions may utilize information obtained via the CAN bus 62, signals obtained from the external device group 70, and information obtained by processing (e.g., differentiation, integration, smoothing, etc.) the signals obtained from the external device group 70.

[0052] "App metadata" may include, for example, a priority value representing the priority of vehicle data. The priority of vehicle data is used to determine which vehicle data to prioritize when it is required to retrieve multiple vehicle data at the same time and it is difficult to process all requests.

[0053] The master DB132 stores diagnostic command information, frame interpretation information, normalization rules, and standard vehicle data instructions.

[0054] Frame interpretation information defines the format of communication frames used in CAN bus 62, the bit assignments in each area of ​​the frame, and the units of values ​​indicated in the assigned areas. Frame interpretation information is prepared for each vehicle model and is necessary for interpreting communication frames used in diagnostic communication.

[0055] The normalization rules are information that describes the normalization rules used when converting vehicle-specific vehicle data, which is extracted from the communication frame and represented in a format specific to the vehicle 60, into the format of standard vehicle data. Similar to frame interpretation information, normalization rules are provided for each vehicle type.

[0056] Diagnostic command information includes a list of diagnostic commands available on CAN bus 62, and as explained in the "Requirements" section of the manifest, it contains both naming information and command-specific information. Like frame interpretation information and normalization rules, diagnostic command information is prepared for each vehicle model.

[0057] A standard vehicle data instruction document is a document that describes the types of standard vehicle data, which are standardized vehicle data used in common across all vehicle types, and the conditions for acquiring each type of standard vehicle data. Standard vehicle data instruction documents are created, for example, by providers of digital twin infrastructure. As shown in Figure 5, a standard vehicle data instruction document basically has the same content as a manifest. Specifically, a standard vehicle data instruction document includes "request information" and "mode attributes." In addition, a standard vehicle data instruction document may include "mode sub-attributes" depending on the content of the "mode attributes."

[0058] "Request information" is specified by the name of the standard vehicle data, i.e., a standardized name. In other words, it is the same as the naming specification in the manifest. "Mode attributes" include periodic drive and event drive. In other words, immediate drive is omitted compared to the manifest. The content of "mode sub-attributes" is the same as in the manifest.

[0059] The digital twin DB133 stores standard vehicle data repeatedly provided from multiple vehicles. As shown in Figure 6, the standard vehicle data is stored in association with vehicle ID, time, latitude, longitude, system, and control label.

[0060] The vehicle ID is information that identifies the vehicle that provided the standard vehicle data (hereinafter referred to as the "providing vehicle"). The vehicle ID may be, for example, the VIN, or a number uniquely defined by the system and associated with the VIN.

[0061] The time indicates the date and time when the vehicle information was acquired from the providing vehicle.

[0062] The latitude and longitude represent the location of the providing vehicle at the time the vehicle information was acquired.

[0063] The system identifies the CAN that provided the vehicle information in the source vehicle. In other words, if the in-vehicle network is divided into multiple CANs based on function, such as powertrain CANs and body CANs, this system identifies which CAN was used to obtain the information.

[0064] The control label is a label that indicates the name of the vehicle data identified from the CANID shown in the CAN frame.

[0065] Vehicle data is information obtained by converting the vehicle data shown in the CAN data into the standard vehicle data format.

[0066] Furthermore, the digital twin DB133 stores standard vehicle data transmitted from multiple in-vehicle units 30, as well as digital twin data that emulates the vehicle 60 equipped with the in-vehicle unit 30, which is generated by processing the standard vehicle data.

[0067] The cloud server 10 includes a cloud-side application management unit 21 and a cloud-side database management unit 22, which are functions realized by processing performed by the control unit 11.

[0068] The cloud-side application management unit 21 distributes and deletes diagnostic applications and other related applications 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 the manifests associated with the diagnostic applications, and manages them accordingly. The cloud-side application management unit 21 may also manage the diagnostic applications in association with the business operator that developed the diagnostic applications.

[0069] The cloud-side DB management unit 22 distributes diagnostic command information, frame interpretation information, normalization rules, and standard vehicle data instructions stored in the master DB 132 in response to requests from the in-vehicle devices 30. The cloud-side DB management unit 22 may also autonomously distribute update information to each in-vehicle device 30 when the contents of the master DB 132 are updated. The cloud-side DB management unit 22 stores acquired data transmitted from multiple in-vehicle devices 30 in the digital twin DB 133 and performs data retrieval and other processing as requested. The cloud-side DB management unit 22 may be configured to identify vehicle types from vehicle identification numbers (VINs).

[0070] [2-2.In-vehicle device] The in-vehicle unit 30 includes a diagnostic command DB341, a frame interpretation DB342, and a standard vehicle data DB343. The diagnostic command DB341, frame interpretation DB342, and standard vehicle data DB343 are configured on the storage unit 34.

[0071] The diagnostic command DB341 stores diagnostic command information applicable to the vehicle type of the vehicle 60 to which the onboard unit 30 is installed (hereinafter referred to as the mounted vehicle).

[0072] The frame interpretation DB342 stores frame interpretation information applicable to 60 vehicle types.

[0073] The standard vehicle data DB343 stores standard vehicle data acquired from the installed vehicle 60. The standard vehicle data is stored in the standard vehicle data DB343 in a format in which the vehicle ID is omitted from the stored data accumulated in the digital twin DB133 shown in Figure 6.

[0074] The in-vehicle unit 30 includes, as functions realized by processing performed by the control unit 31, an application execution environment 41, an API group 42, a routing unit 43, a CAN transmission unit 44, a CAN reception unit 45, a vehicle-side application management unit 46, a manifest management unit 47, an instruction management unit 51, a schedule management unit 48, a vehicle-side DB management unit 49, and an exterior device management unit 50.

[0075] The external device management unit 50 manages the external device group 70 connected to the expansion connector 322 of the in-vehicle unit 30. The external device management unit 50 monitors signals input from each external device belonging to the external device group 70. The external device management unit 50 has a function to notify the schedule management unit 48 of the occurrence of an event when the monitored signal satisfies the trigger conditions notified by the schedule management unit 48. The external device management unit 50 may also have a function to notify the schedule management unit 48 of a change in hardware configuration when the external device group 70 connected to the expansion connector 322 has been detected to have changed compared to the previous startup when the in-vehicle unit 30 is started up.

[0076] The vehicle-side DB management unit 49 acquires diagnostic command information, frame interpretation information, and normalization rules suitable for the vehicle 60 from the cloud server 10 when the in-vehicle unit 30 makes its initial connection to the vehicle 60. The vehicle-side DB management unit 49 stores the acquired diagnostic command information in the diagnostic command DB 341 and the frame interpretation information and normalization rules in the frame interpretation DB 342. The vehicle-side DB management unit 49 has the function of acquiring standard vehicle data instructions simultaneously with the diagnostic command information, claim interpretation information, and normalization rules, or in response to instructions from the cloud server 10. The vehicle-side DB management unit 49 provides the acquired standard vehicle data instructions to the instruction management unit 51. The vehicle-side DB management unit 49 has the function of periodically and autonomously, or in response to instructions from the cloud server 10, uploading the standard vehicle data stored in the standard vehicle data DB 343, along with the vehicle ID assigned to the vehicle 60, to the digital twin DB 133 of the cloud server 10.

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

[0078] The vehicle-side application management unit 46 obtains diagnostic applications 411 from the cloud server 10 via the wide-area communication network NW, and deploys (i.e., places and deploys) the obtained 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 deployed diagnostic applications 411. Furthermore, the vehicle-side application management unit 46 provides the manifest distributed from the cloud server 10 along with the diagnostic applications 411 to the manifest management unit 47. The vehicle-side application management unit 46 may also have a function to notify the schedule management unit 48 of changes in the software configuration each time a diagnostic application is deployed or deleted.

[0079] API group 42 is a collection of application programming interfaces (hereinafter referred to as APIs) that provide various functions to diagnostic applications 411 executed in the application execution environment 41. API group 42 includes at least an API that provides the function of acquiring vehicle data via the CAN bus 62 of the vehicle 60. In addition, API group 42 includes at least an API (hereinafter referred to as a standard data API) that provides the function of acquiring standard vehicle data from the standard vehicle data DB 343. A standard data API is provided individually for each type of standard vehicle data.

[0080] In other words, diagnostic applications 411 can use two methods to access vehicle data. One method is to automatically receive vehicle data according to the acquisition conditions described in the manifest, by describing them in the manifest. The other method is to autonomously acquire standard vehicle data using the standard data API. Developers of diagnostic applications 411 can adopt either method.

[0081] The routing unit 43 has routing information notified by the schedule management unit 48. The routing information is information that associates the diagnostic application 411 (hereinafter referred to as the requesting application) that requests vehicle data with the diagnostic commands that are sent to the CAN bus 62 in accordance with the request. The routing unit 43 distributes the vehicle data received by the CAN receiving unit 45 when the CAN transmission unit 44 sends a diagnostic command, by referring to the routing information.

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

[0083] The manifest management unit 47 comprises a storage unit 471 and an interpretation unit 472.

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

[0085] The interpretation unit 472 interprets the contents of the manifest stored in the storage unit 471, extracts and generates the information necessary for setting the command management table, and provides it to the schedule management unit 48. Specifically, the 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 diagnostic command information. The interpretation unit 472 extracts the contents of the "mode attribute" and "mode sub-attribute" of the manifest as conditions for acquiring vehicle data. The 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," the interpretation unit 472 may automatically set the priority value from the "mode attribute" and "mode sub-attribute" (i.e., conditions for acquiring vehicle data) of the manifest, for example, as follows.

[0086] "Immediate drive or event drive" < "Periodic drive: long period" < "Periodic drive: short period" In other words, the priority of periodic-driven commands may be set higher than that of immediate-driven and event-driven commands, and among periodic-driven commands, shorter-period commands may be given higher priority. However, the priority order is not limited to what is described above and can be set arbitrarily.

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

[0088] The instruction management unit 51 comprises a storage unit 511 and an interpretation unit 512.

[0089] The memory unit 511 stores the standard vehicle data instruction sheet provided by the vehicle-side DB management unit 49.

[0090] The interpretation unit 512 interprets the contents of the standard vehicle data instruction sheet stored in the storage unit 511, extracts and generates the information necessary for setting the command management table, and provides it to the schedule management unit 48. The specific processing in the interpretation unit 512 is the same as the processing in the interpretation unit 472 that interprets the manifest, except that the processing related to "application metadata" is omitted.

[0091] The schedule management unit 48 comprises a setting unit 481, an adjustment unit 482, a load calculation unit 483, and an API monitoring unit 484.

[0092] Based on the interpretation results of the manifest by the interpretation unit 472 and the interpretation results of the standard vehicle data instruction sheet by the interpretation unit 512, the setting unit 481 adds management information indicating the conditions for acquiring vehicle data to the command management table. The command management table is a table that shows information used to manage the timing of sending diagnostic commands.

[0093] As shown in Figure 7, the management information set in the command management table according to the interpretation of the manifest includes "App ID," "Command ID," "Send Waiting Status," "Supplementary Information," and "Send 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."

[0094] The "App ID" is information that identifies the requesting app and is assigned when a diagnostic app is deployed by the vehicle-side app management unit 46.

[0095] The "Command ID" is information that identifies the diagnostic command used to retrieve the vehicle data specified in the "Request Information" section of the manifest.

[0096] The "Send 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, 100ms. The remaining tick count is decremented with each tick, and the management information that reaches 0 ticks is processed in the next tick.

[0097] 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 indicated in the "mode sub-attribute" each time a command is sent. As a result, in the case of periodic drive, the command is sent repeatedly at a period corresponding to the period value.

[0098] If the "Mode Attribute" is event-driven, the "Send Waiting Status" is normally set to an invalid value indicating no request, set to 0 when the specified trigger condition is met, and set back to an invalid value after the command is sent. The invalid value may be, for example, a value padded with all bits being 1.

[0099] When the "Mode Attribute" is set to immediate drive, the "Send Waiting Status" is normally set to an invalid value, set to 0 when a request is made from the diagnostic application 411, and then set to an invalid value again after the command is sent. When the "Send Waiting Status" is set to an invalid value, no decrement is performed with each tick, and the invalid value is maintained.

[0100] If the "Mode attribute" is periodic, "Remaining transmissions" may be set as "Supplementary information". If the "Mode sub-attribute" of the manifest includes information about the validity period, the "Remaining transmissions" will be set to a value that represents the validity period as the number of remaining ticks. If the validity period is unlimited, the "Remaining transmissions" will be set to an invalid value. The remaining ticks of the "Remaining transmissions" will be decremented with each tick. However, if it is set to an invalid value, the decrement will not be performed with each tick and the invalid value will be maintained. Management information for which the tick count of the "Remaining transmissions" has reached 0 will be deleted from the command management table.

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

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

[0103] A priority value is set for "Transmission Priority". The priority value is information used to determine which diagnostic command to prioritize when it is difficult to process all transmission candidates in the next tick due to load overload or other reasons, after extracting command candidates according to the command management table. Here, a higher priority value indicates a higher priority. The priority value used is the value extracted or set in the interpretation unit 472,512. If no priority value is extracted or set, it may be considered to have the lowest priority.

[0104] As shown in Figure 8, the management information set in the command management table according to the interpretation of the standard vehicle data instruction sheet includes "command ID," "transmission waiting status," "supplementary information," and "transmission priority." In other words, the management information based on the standard vehicle data instruction sheet (hereinafter referred to as "management information based on the instruction sheet") is the same as the management information based on the manifest, except that the "application ID" is omitted. However, the priority value representing "transmission priority" may be set according to the monitoring results of the API monitoring unit 484.

[0105] The API monitoring unit 484 monitors the usage status of each standard data API included in the API group 42. The API monitoring unit 484 calculates the usage frequency of each standard data API by counting the number of accesses from the diagnostic application 411 for each standard data API. The usage frequency may be, for example, the number of accesses per hour over the entire counting period, or the number of accesses within a certain period in the past. The API monitoring unit 484 sets and updates the priority value of the management information based on the instruction sheet according to the usage frequency of the standard data API corresponding to the management information. Specifically, the priority value of the management information is set to a higher value the higher the usage frequency of the corresponding standard data API.

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

[0107] In diagnostic communication, if parallel transmission of commands is prohibited and alternating command transmission is enabled, the number of commands that can be transmitted per tick can be estimated from the turnaround time. Alternating transmission, as shown in the upper part of Figure 20, is a method of sending the next command only after receiving a response to the previous command. Parallel transmission, as shown in the lower part of Figure 20, is a method of sending the next command without waiting for a response to the previous command.

[0108] Traffic refers to the percentage of time that CAN bus 62 is being used. Higher traffic results in longer turnaround times, and therefore fewer commands can be sent per tick. Furthermore, the upper limit of traffic allowed on CAN bus 62 (hereinafter referred to as the "allowable value") may be set for each vehicle model.

[0109] The load calculation unit 483 measures the turnaround time used for processing in the adjustment unit 482 after the initialization process at startup of the in-vehicle unit 30. The turnaround time is measured by having the CAN transmission unit 44 send a command to the CAN bus 62 and measuring the time until the CAN reception unit 45 receives a response. This measurement is repeated for multiple commands. The load calculation unit 483 may also calculate the average value of the measured turnaround times. The load calculation unit 483 stores either or both of the turnaround time measured for each command and the average value of the turnaround times in the diagnostic command DB 341.

[0110] The CAN transmission unit 44 includes a command generation unit 441. The command generation unit 441 generates diagnostic commands by referring to the diagnostic command DB 341 in accordance with instructions from the adjustment unit 482 of the schedule management unit 48. The command generation unit 441 further generates a CAN frame containing the diagnostic commands in the payload and stores it in the transmission buffer. The CAN transmission unit 44 transmits the CAN frame stored in the transmission buffer to the CAN bus 62 via the diagnostic connector 321.

[0111] The CAN receiver 45 includes a frame interpretation unit 451. The CAN receiver 45 stores CAN frames (i.e., responses to diagnostic commands) 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 referred to as the received frame) by referring to frame interpretation information and normalization rules stored in the frame interpretation DB 342. The frame interpretation unit 451 converts the vehicle data shown in the payload of the received frame and written in a format specific to the vehicle 60 into a standard vehicle data format that can be understood by the requesting application. In addition to converting the CAN data into "vehicle data", the frame interpretation unit 451 also converts the CANID into a "control label" representing the data type of the vehicle data represented by the CAN data, and a "system" representing the system to which the device that generated the CAN data belongs.

[0112] The CAN receiver 45 provides the routing unit 43 with the "vehicle data," "control label," and "system" interpreted and converted by the frame interpretation unit 451, along with the "command ID" and "additional information" of the transmitted diagnostic command. The additional information includes "time," "latitude," and "longitude," which are information separately acquired by the CAN receiver 45 via the exterior device management unit 50, etc.

[0113] The CAN receiver 45 has a function to monitor vehicle data received periodically. The CAN receiver 45 has a function to notify the schedule management unit 48 of the occurrence of an event when the monitored signal satisfies the trigger conditions notified by the schedule management unit 48. The CAN receiver 45 has a function to measure the turnaround time, which is the time from when a command is transmitted by the CAN transmitter 44 until the response to that command is received by the CAN receiver 45, and notify the load calculation unit 483 of this time. The CAN receiver 45 has a function to provide the received vehicle data to the routing unit 43. If the received vehicle data is standard vehicle data, the CAN receiver 45 has a function to store the vehicle data, along with the control label, system, and additional information, in the standard vehicle data DB 343.

[0114] The routing unit 43 provides the vehicle data received from the CAN receiving unit 45 to the requesting application according to the routing information notified by the adjustment unit 482 of the schedule management unit 48.

[0115] [3. Operation] [3-1. Operation when the in-vehicle unit is powered on] The operation of each part of the system when the in-vehicle unit 30 is powered on will be explained using the sequence diagram shown in Figure 9.

[0116] As shown in Figure 9, when power is supplied to the in-vehicle unit 30, the in-vehicle unit 30 executes an initialization process (hereinafter referred to as the in-vehicle unit initialization process) S1. This in-vehicle unit initialization process S1 enables the in-vehicle unit 30 to perform diagnostic communication using standard commands.

[0117] The vehicle-side DB management unit 49 obtains VIN information from the vehicle 60 by sending a VIN acquisition command, one of the standard commands, to the CAN bus 62 via the CAN transmission unit 44, and receiving the response via the CAN reception unit 45.

[0118] The vehicle-side DB management unit 49 uses the acquired VIN information to determine whether or not the diagnostic command DB 341 and frame interpretation DB 342 need to be updated. Specifically, if VIN-related information is not stored in the diagnostic command DB 341 and frame interpretation DB 342, it is determined that an update is necessary. VIN-related information includes diagnostic command information, frame interpretation information, and normalization rules linked to the acquired VIN information. If VIN-related information is already stored in the diagnostic command DB 341 and frame interpretation DB 342, it is determined that an update is not necessary.

[0119] For example, if the in-vehicle unit 30 is installed in a vehicle for the first time, it will be determined that an update is required. Also, if the in-vehicle unit 30 is removed from the first vehicle 60, and the VIN-related information of the first vehicle 60 remains in the diagnostic command DB341 and frame interpretation DB342, and then installed in the second vehicle 60, and the VIN information of the second vehicle 60 is acquired again, it will be determined that an update is required.

[0120] The vehicle-side DB management unit 49 terminates its operation if it determines that no update is necessary.

[0121] If the vehicle-side DB management unit 49 determines that an update is necessary, it sends a data acquisition request to the cloud server 10 along with the acquired VIN information, thereby obtaining VIN-related information corresponding to the vehicle type of the installed 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 type from the VIN information indicated in the data acquisition request, reads the VIN-related information corresponding to the identified vehicle type from the master DB 132, and sends it back to the in-vehicle device 30.

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

[0123] In the following, the series of processes executed after the in-vehicle device initialization process S1, as explained using Figure 9, will also be referred to as the database update process S2.

[0124] [3-2. Measuring Turnaround Time] The operation of each part of the system when measuring the turnaround time of diagnostic commands used by the in-vehicle unit 30 will be explained using the sequence diagram shown in Figure 10.

[0125] As shown in Figure 10, once the in-vehicle unit initialization process S1 and the database update process S2, which were previously described using Figure 9, are completed, the load calculation unit 483 reads a number of pre-specified commands from the diagnostic command DB341 for turnaround time measurement. It selects one of the read commands as the command to be measured and notifies the CAN transmission unit 44 to measure the turnaround time using the selected command.

[0126] The CAN transmitter 44 sends 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 sends the measurement result to the load calculation unit 483.

[0127] The load calculation unit 483 obtains the turnaround time for each command by performing the same process for all commands read from the diagnostic command DB 341. Once the transmission of all specified commands is complete, the load calculation unit 483 calculates the average turnaround time. Furthermore, the load calculation unit 483 stores the measurement results of the turnaround time for each command, as well as the calculation result 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. Note that instead of the average turnaround time, a value obtained by adding a safety margin to the average turnaround time may be used.

[0128] The load calculation unit 483 may measure the turnaround time each time the in-vehicle unit 30 starts up. Also, as shown by the dotted line in Figure 10, the load calculation unit 483 may measure the turnaround time when it receives a notification from the exterior device management unit 50 indicating a change in the hardware configuration. The load calculation unit 483 may also measure the turnaround time when it receives a notification from the vehicle-side application management unit 46 indicating a change in the software configuration.

[0129] [3-3. Standard Vehicle Data Instruction Sheet Update / Command Management Table Settings] The operation of each part of the system during the distribution of standard vehicle data instructions from the cloud server 10 to the in-vehicle unit 30 will be explained using the sequence diagram shown in Figure 11.

[0130] As shown in Figure 11, the cloud-side DB management unit 22 of the cloud server 10 distributes standard vehicle data instructions or update information for standard vehicle data instructions (hereinafter referred to as standard data instructions, etc.) to each in-vehicle unit 30 at any time. The cloud server 10 may also distribute standard data instructions, etc. in response to requests from the in-vehicle units 30, or distribute them together with the VIN-related information described earlier.

[0131] After the in-vehicle unit initialization process S1 and the database update process S2, the vehicle-side DB management unit 49 of the in-vehicle unit 30 receives standard data instructions, etc., from the cloud server 10, and then forwards the received standard data instructions, etc., to the instruction management unit 51.

[0132] The instruction management unit 51 stores standard data instruction sheets, etc., transferred from the vehicle-side DB management unit 40 in the storage unit 511, and interprets the contents of the standard data instruction sheets, etc., in the interpretation unit 512 to extract the information necessary for registration in the command management table. Specifically, the interpretation unit 512 extracts the command ID and the conditions for acquiring vehicle data (i.e., "mode attributes" and "mode sub-attributes") and provides them to the schedule management unit 48.

[0133] The setting unit 481 of the schedule management unit 48 uses the information provided by the interpretation unit 512 of the instruction management unit 51 (hereinafter referred to as update information) to add and update the management information based on the instruction included in the command management table shown in Figure 8.

[0134] The command management table update based on the instructions is performed as follows: If there is no management information with the same command ID as the command ID shown in the update information, new management information is added to the command management table. Even if management information with the same command ID as the update information already exists in the command management table, new management information is added if the data acquisition conditions, etc., do not match. If the content of the update information is a perfect match to the existing management information, the update information may be discarded, or the content of the existing management information may be updated with the update information.

[0135] The "Send Pending Status" in the management information is set to the number of remaining ticks when the management information is registered in the command management table, according to the acquisition conditions for the vehicle data included in the update information.

[0136] The "transmission priority" of the management information based on the instruction sheet is set to an arbitrary initial value when the management information is registered in the command management table, and thereafter is updated periodically according to the monitoring results of the API monitoring unit 484.

[0137] [3-4. App Distribution / Command Management Table Settings] The operation of each part of the system during the distribution of diagnostic applications from the cloud server 10 to the in-vehicle device 30 will be explained using the sequence diagram shown in Figure 12.

[0138] As shown in Figure 12, if diagnostic applications awaiting distribution are stored in the application DB 131, the cloud-side application management unit 21 of the cloud server 10 sends a distribution request to the in-vehicle device 30 requesting it to accept the distribution of the diagnostic applications.

[0139] When the in-vehicle device 30's in-vehicle application management unit 46 receives a distribution request, it determines whether to accept the distribution according to the information indicated in the distribution request, and if it accepts, it sends a permission notification to the cloud server 10. The information used to determine whether to accept or reject the distribution may include the memory capacity required to save the program, the CPU processing power and memory capacity required to run the application, etc.

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

[0141] When the vehicle-side application management unit 46 receives a 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. The vehicle-side application management unit 46 also provides the manifest attached to the diagnostic application 411 to the manifest management unit 47. The deployed diagnostic application 411 is assigned an application ID, and this application ID is associated with the manifest provided to the manifest management unit 47.

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

[0143] Furthermore, if the "mode attribute" of the manifest is periodic drive 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 this notification, the vehicle-side application management unit 46 may delete the corresponding diagnostic application and notify the distribution source cloud server 10 that the application has been deleted, along with the reason.

[0144] The setting unit 481 of the schedule management unit 48 uses the information provided by the interpretation unit 472 of the manifest management unit 47 (hereinafter referred to as update information) to add and update the manifest-based management information included in the command management table shown in Figure 7.

[0145] Updating the command management table based on a manifest is basically done in the same way as updating the command management table based on an instruction manual.

[0146] The "transmission priority" of management information based on the manifest may be the priority value included in the update information, the priority value set according to the vehicle data acquisition conditions, or the priority value set according to the data type of the vehicle data.

[0147] [3-5. Update Sending Status] This section describes the operation by which the adjustment unit 482 of the schedule management unit 48 updates the "send waiting status" in the command management table.

[0148] The adjustment unit 482, for management information registered in the command management table for periodic drive, decrements the remaining tick counts shown in "Transmission Waiting Status" and "Auxiliary Information (i.e., remaining transmissions)" by 1 each time the schedule adjustment process described later is completed. However, for management information where the remaining tick count in "Transmission Waiting Status" before decrementing is 0, the adjustment unit 482 presets the remaining tick count to a value corresponding to the periodic value instead of decrementing it.

[0149] The adjustment unit 482 removes management information from the command management table if, as a result of reducing the remaining tick count of the "auxiliary information," the remaining tick count of the "auxiliary information" becomes 0.

[0150] 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 "transmission waiting status" of the management information corresponding to the received trigger signal to 0 in the command management table for event driving.

[0151] 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 "send waiting status" of the management information corresponding to the received immediate acquisition request to 0 in the command management table for immediate drive.

[0152] [3-6. Schedule Adjustment] The scheduling adjustment process performed by the adjustment unit 482 of the scheduling management unit 48, which determines the diagnostic command to be sent in the next tick using the command management table, will be explained using the sequence diagram in Figure 13 and the flowchart in Figure 16.

[0153] The adjustment unit 482 executes the schedule adjustment process every tick.

[0154] When the schedule adjustment process begins, the adjustment unit 482 first acquires the traffic status of the CAN bus 62 in S110. The traffic status may be information acquired from the ECU 63, which measures the traffic of the CAN bus 62, or information acquired by measuring separately by the in-vehicle unit 30. Alternatively, the traffic status may be static information (hereinafter referred to as static traffic information) that has been registered in the system in advance. Static traffic information may be, for example, an average value measured for each vehicle model, or an average value with a safety margin added. Static traffic information may also be included in the information stored in the diagnostic command DB341, for example. Furthermore, static traffic information may be used, for example, when dynamic traffic information, which represents the dynamic traffic status measured at any given time, cannot be acquired from the ECU 63 or the in-vehicle unit 30.

[0155] In the subsequent S120, the adjustment unit 482 refers to the "Send Waiting Status" in the command management table and extracts all management information with a remaining tick count of 0, that is, all management information to be processed in the next tick, as candidate commands to send. Figure 17 illustrates the candidate commands to send (i.e., requests to send diagnostic commands) extracted at each tick based on the command management table. Figure 17 shows a case where there are three periodic drive commands C1 to C3, with one event drive command and two immediate drive commands. Note that periodic drive command C1 is processed at a 0.5s (i.e., 5 tick) cycle, periodic drive command C2 is processed at a 0.2s (i.e., 2 tick) cycle, and periodic drive command C3 is processed at a 0.1s (i.e., 1 tick) cycle. Figure 17 shows the transmission schedule of diagnostic commands before load adjustment.

[0156] In the subsequent S130, the adjustment unit 482, if there are duplicate management information entries with the same command ID among the management information extracted as candidate commands to send, keeps one management information entry and excludes the other duplicate management information from the candidate commands to send. However, if management information based on a manifest and management information based on an instruction document are duplicated, the management information based on the manifest is kept, and the management information based on the instruction document is excluded from the candidate commands to send. The adjustment unit 482 also generates routing information to provide to the routing unit 43. The routing information is information that associates the command ID indicated by the candidate command to send with the application ID of the application that requested the candidate command to send, based on the information shown in the command management table. In the routing information, each command ID is associated with one or more application IDs. In other words, if the candidate command to send is management information based on a manifest, routing information is generated, but if the candidate command to send is management information based on an instruction document, routing information is not generated.

[0157] For example, as shown in Figure 18, if multiple diagnostic applications 411 are configured to send periodic drive commands C4 and C5 at different intervals to acquire the same vehicle data, requests from both applications may overlap at the same tick. In such cases, instead of sending both of the overlapping periodic drive commands C4 and C5, adjustments are made to send only one of them (for example, command C5 in Figure 18). However, since the correspondence between the acquired vehicle data and the requesting application is unclear based solely on CAN information without session management, routing information is used to ensure that the acquired vehicle data is correctly provided to the requesting application.

[0158] In the subsequent S140, the adjustment unit 482 obtains the turnaround time for all candidate transmission commands. The turnaround time for each command may be the measured value stored in the diagnostic command DB341, as explained earlier, when the in-vehicle unit 30 is started up, or the average value of the turnaround times calculated from the measured values ​​may be used, or a design value may be used.

[0159] In the subsequent S150, the adjustment unit 482 calculates the required time Tneed, which is the time required if all candidate transmission commands are transmitted via alternating communication. The required time Tneed is the sum of the turnaround times for all candidate transmission commands. However, the turnaround time may be adjusted according to the traffic conditions obtained in S110, so that it becomes longer the more congested the network is.

[0160] In the following S160, the adjustment unit 482 determines whether processing in the next tick will result in an overload. An overload occurs when the required time Tneed calculated in S150 is greater than the tick, or when sending a candidate command will cause the estimated traffic on the CAN bus 62 to exceed the allowable value. If the adjustment unit 482 determines in S160 that there will be no overload, it moves the processing to S200; if it determines that there will be an overload, it moves the processing to S170.

[0161] In S170, the adjustment unit 482 determines whether or not there are any commands that can be excluded among the candidate commands to be transmitted. For example, candidate commands to be transmitted whose priority value is less than or equal to the exclusion threshold may be treated as commands that can be excluded.

[0162] The adjustment unit 482 proceeds to S180 if there is an exclusionable command among the candidate transmission commands, and proceeds to S190 if there is no exclusionable command.

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

[0164] In S190, the adjustment unit 482 excludes at least one of the transmission candidate commands that has the lowest priority value or a period value of 10 ticks or more from the transmission candidate commands, making it a transmission pending command. The adjustment unit 482 also excludes information about the transmission pending command from the routing information. Furthermore, the adjustment unit 482 increases the remaining tick count of the transmission pending command's "transmission waiting status" by 1 in the command management table so that the transmission pending command is extracted as a transmission candidate command again in the next tick, and returns the process to S150. Note that the number to increase the remaining tick count is not limited to 1; for example, a number randomly selected within a certain range may be used. The certain range may also be set to be larger during times of congestion, depending on the traffic conditions of the CAN bus 62.

[0165] In S200, the adjustment unit 482 notifies the CAN transmission unit 44 of the candidate transmission command as the command to be transmitted, and also notifies the routing unit 43 of the routing information, and then terminates the process.

[0166] In other words, as shown in Figure 19, if an overload occurs, and the candidate transmission command includes an exclusionable command CR, the load on the CAN bus 62 is adjusted by excluding that exclusionable command CR. If the exclusionable command CR is not included, the load on the CAN bus 62 is adjusted by ensuring that a lower-priority candidate transmission command CL, or a command with a period value equal to or greater than a predetermined value, is transmitted in subsequent ticks.

[0167] As shown in Figure 13, when the CAN transmitter 44 receives notification of a command to be transmitted, it obtains a bit pattern representing the diagnostic command from the diagnostic command DB341 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 obtained bit pattern set as the payload and transfers it to the transmission buffer.

[0168] The CAN frame transferred to the transmit buffer is transmitted and received according to the transmit / receive process of diagnostic communication on the CAN bus 62.

[0169] [3-7. Response Received] The operation when the in-vehicle unit 30 transmits a CAN frame containing diagnostic commands and receives a CAN frame containing the response to the diagnostic commands (i.e., vehicle data) from the vehicle 60 will be explained using the sequence diagram shown in Figure 14.

[0170] As shown in Figure 14, when the CAN receiver 45 receives a CAN frame indicating a response to a diagnostic command, the frame interpretation unit 451 performs bit analysis on the payload of the received CAN frame. Frame interpretation information stored in the frame interpretation DB 342 is used for bit analysis. The vehicle data obtained by bit analysis may be a value representing some state (e.g., on / off status of a switch) or a sampled value of an analog signal (i.e., a physical quantity). If the vehicle data represents a physical quantity, the frame interpretation unit 451 may convert the acquired physical quantity to a predetermined unit (e.g., a unit used by the requesting application) or perform time-series processing on the acquired physical quantity. Time-series processing is a process that applies differentiation, integration, smoothing, etc., to the acquired vehicle data. The vehicle data obtained by bit analysis is unique vehicle data and may be converted to standard vehicle data according to normalization rules stored in the frame interpretation DB 342.

[0171] The CAN receiver 45 notifies the routing unit 43 of the vehicle data processed by the frame interpretation unit 451, along with the command ID representing the diagnostic command sent to acquire that vehicle data.

[0172] If the vehicle data processed by the frame interpretation unit 451 is standard vehicle data, the CAN receiver 45 adds separately acquired peripheral information such as "time," "latitude," and "longitude" to the "system," "control label," and "vehicle data" information extracted from the CANID and CAN data of the received frame, and stores it in the standard vehicle data DB 343. The standard vehicle data DB 343 may store not only standard vehicle data acquired based on instructions, but also standard vehicle data acquired based on manifests.

[0173] 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.

[0174] In other words, since all vehicle data acquired based on the instruction sheet is standard vehicle data, all vehicle data is stored in the standard vehicle data DB343. Vehicle data acquired based on the manifest is provided to the requesting application via the routing unit 43. However, if the vehicle data is standard vehicle data, it is not only provided to the requesting application but also stored in the standard vehicle data DB343.

[0175] [3-8. Obtaining Standard Vehicle Data] The system operation when the diagnostic application 411 acquires standard vehicle data using the standard data API belonging to API group 42 will be explained using the sequence diagram shown in Figure 15.

[0176] As shown in Figure 15, the diagnostic application 411 can obtain various standard vehicle data by accessing the standard vehicle data DB 343 using the standard data API. In addition to the latest data, it is also possible to obtain historical data by specifying the data acquisition time and location.

[0177] [4. Correspondence of Terms] In this embodiment, the CAN transmission unit 44 and the CAN reception unit 45 correspond to the data acquisition unit in this disclosure. The standard vehicle data DB 343 corresponds to the standard vehicle data storage unit in this disclosure. The application execution environment 41 corresponds to the application execution unit in this disclosure. The vehicle-side DB management unit 49 corresponds to the peripheral information acquisition unit and the standard vehicle data transmission unit in this disclosure, and the diagnostic command information, frame interpretation information, and normalization rules correspond to the peripheral information in this disclosure.

[0178] [5. Effects] The embodiments described in detail above produce the following effects.

[0179] (5a) In the data provision system 1, the in-vehicle unit 30 generates management information to be registered in the command management table in accordance with the standard vehicle data instruction sheet. The in-vehicle unit 30 then uses the management information registered in the command management table to acquire standard vehicle data via the diagnostic port 61 of the vehicle 60 and stores it in the standard vehicle data DB 343. Multiple diagnostic applications 411 deployed on the in-vehicle unit 30 are each configured to acquire arbitrary standard vehicle data from the standard vehicle data DB 343 using standard data APIs belonging to the API group 42.

[0180] Therefore, the in-vehicle device 30 can simultaneously operate multiple diagnostic applications 411 that utilize standard vehicle data acquired through diagnostic communication. In other words, the diagnostic port 61 of the vehicle 60 can be used simultaneously for multiple different purposes.

[0181] (5b) In the data provision system 1, the in-vehicle device 30 is configured to upload the standard vehicle data stored in the standard vehicle data DB 343 to the digital twin DB 133 of the cloud server 10.

[0182] Therefore, in the data provision system 1, the system can be easily constructed by utilizing the configuration provided in the in-vehicle unit 30 for building the digital twin DB 133.

[0183] (5c) In the data provision system 1, the in-vehicle unit 30 generates management information to be registered in the command management table according to the manifest distributed from the cloud server 10 along with the diagnostic application 411. The in-vehicle unit 30 then uses the management information registered in the command management table to adjust the timing for processing multiple vehicle data acquisition requests specified in the manifest.

[0184] Therefore, the in-vehicle device 30 is not limited to the standard vehicle data shown in the standard vehicle data instruction sheet, but can also provide any vehicle data shown in the manifest to the diagnostic application 411.

[0185] (5d) The in-vehicle unit 30 manages the vehicle data acquisition schedule in accordance with the standard vehicle data instruction sheet and manifest. The in-vehicle unit 30 also generates diagnostic commands that are suitable for the vehicle 60 and interprets the responses from the vehicle 60 in accordance with the VIN-related information. Therefore, even if the application developer lacks knowledge of the diagnostic communication of the target vehicle 60, they can still develop the diagnostic application 411.

[0186] (5e) The in-vehicle unit 30 creates routing information to associate the diagnostic commands to be sent with the requesting applications. Therefore, even if duplicate requests for sending the same command occur at the same tick timing and the duplicate command is deleted, the system can refer to the routing information to correctly provide the acquired vehicle data to all requesting applications.

[0187] (5f) In the in-vehicle unit 30, if sending all candidate commands extracted from the command management table could result in an overload, load balancing is performed. Load balancing involves excluding some candidate commands from transmission or adjusting them to be processed in subsequent ticks. As a result, the traffic on the CAN bus 62 can be kept within an acceptable range, and delays or other effects on the transmission and reception of regular commands (e.g., vehicle control commands) between the ECUs 63 can be suppressed. Furthermore, application developers can develop diagnostic applications 411 that operate safely even without knowledge of the traffic limitations of the CAN bus 62 in each vehicle 60.

[0188] In the (5g) in-vehicle unit 30, for periodic drive requests, the larger the period value, the lower the priority is set. In other words, the impact of the shift in the transmission period (i.e., delay) of low-priority commands due to processing being held in abeyance due to excessive load becomes relatively smaller the larger the period value of the held command, thus minimizing the impact on the functionality implemented by the requesting application.

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

[0190] (6a) In the above embodiment, when the load exceeds capacity and there are no commands that can be excluded, the processing of low-priority commands or commands with a long data acquisition cycle is delayed. However, the processing of commands related to immediate drive or event drive may be delayed instead.

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

[0192] (6c) In the above embodiment, the standard vehicle data to be stored in the standard vehicle data DB343 is configured to be acquired by sending diagnostic commands, but the method of acquiring standard vehicle data is not limited to the method of sending diagnostic commands. For example, if the vehicle 60 is configured to receive all frames flowing on the CAN bus 62 via the diagnostic port 61, the CAN receiver 45 may acquire standard vehicle data flowing on the CAN bus 62 independently of the transmission of diagnostic commands. In this case, the CAN receiver 45 corresponds to the passive data acquisition unit in this disclosure.

[0193] (6d) In the above embodiment, when adding management information to the command management table in accordance with the manifest, the initial value of "Send Waiting Status" is set to a value corresponding to the period value. The initial value of "Send Waiting Status" may be adjusted so that candidate commands for transmission do not concentrate on the same tick. For example, as shown in Figure 21, if there are three periodic drive commands C6 to C8 with an acquisition period of 3 ticks, the initial value of "Send Waiting Status" when registering the management information may be adjusted so that each of the periodic drive commands C6 to C8 is processed at a different tick.

[0194] (6e) In the above embodiment, the transmission priority of duplicated commands that were not deleted is not specifically described, but the transmission priority of such commands may be temporarily set higher only for processing in that tick. In other words, even if the transmission priority is low, the system may be adjusted so that transmission is performed as much as possible for commands that have multiple requesters.

[0195] (6f) In the above embodiment, there is no specified priority for transmission between the management information based on the manifest and the management information based on the instruction sheet. However, the management information based on the manifest may be given higher priority, or conversely, the management information based on the instruction sheet may be given higher priority.

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

[0197] When this scheduling process is adopted, the "Send Waiting Status" for "Mode Attribute" that is immediately driven may be set to one or more predetermined numbers when a request is made from the diagnostic application 411. Similarly, the "Send Waiting Status" for "Mode Attribute" that is event driven may be set to one or more predetermined numbers when the specified trigger condition is met.

[0198] Furthermore, in the schedule adjustment process S120, the adjustment unit 482 may refer to the "Send Waiting Status" in the command management table and extract all management information set to a predetermined number of ticks greater than 1 as candidate commands to send. In S200, the adjustment unit 482 may refer to the "Send Waiting Status" in the command management table and process candidate commands to send that have a remaining tick count of 0 as commands to be sent. In this case, the "Send Waiting Status" for an immediate-driven "Mode Attribute" may be set to a number greater than or equal to the predetermined number of ticks when a request is made from the diagnostic application 411. Similarly, the "Send Waiting Status" for an event-driven "Mode Attribute" may be set to a number greater than or equal to the predetermined number of ticks when the specified trigger condition is met.

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

[0200] (6e) In the above embodiment, immediate drive was a mode used when the specified vehicle data is acquired "immediately" only once in accordance with instructions from a diagnostic application. However, as explained in the modified example of the schedule adjustment process, the "transmission waiting status" of the "mode attribute" for 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 one or more predetermined ticks. In other words, instead of acquiring the vehicle data "immediately," it may be acquired within a limited time. In this case, the "mode attribute" can be understood as application drive, which is a higher-level concept than immediate drive. Application drive is a mode in which vehicle data is acquired in response to a request from an application program.

[0201] (6f) In the above embodiment, when the "mode attribute" is immediate drive or event drive, the number of ticks set as the "send waiting status" indicates the timing for executing the process, but it may also represent the latest timing that is permissible for executing the process. In this case, in the schedule adjustment process, if there is sufficient processing load, candidate commands for transmission with a remaining tick count other than 0 may be processed in addition to the commands to be sent.

[0202] (6g) The control unit 31 and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the control unit 31 and its method described herein may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the control unit 31 and its method described herein may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium. The method for implementing the functions of each part included in the control unit 31 does not necessarily have to include software, and all of its functions may be implemented using one or more hardware components.

[0203] (6h) Multiple functions of one component in the above embodiment may be realized by multiple components, or one function of one component may be realized by multiple components. Also, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Furthermore, some of the configuration of the above embodiment may be omitted. Furthermore, at least some of the configuration of the above embodiment may be added to or replaced with the configuration of other above embodiments.

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

[0205] [7. The technical concepts disclosed herein] [Item 1] It is an in-vehicle device, A data acquisition unit (44, 45) is configured to perform a transmission process to acquire unique vehicle data, which is the vehicle data expressed in a format specific to the vehicle, from the vehicle network by sending a command to the vehicle network of the vehicle on which the in-vehicle device is installed, in accordance with an instruction sheet that shows one or more types of standard vehicle data, which are standardized vehicle data. A standard vehicle data storage unit (343) is configured to convert the unique vehicle data acquired by the data acquisition unit into the format of the standard vehicle data and store it there, An application execution unit (41) configured to execute one or more application programs that utilize the standard vehicle data, In order to provide the application program executed by the application execution unit with the function to acquire the standard vehicle data from the standard vehicle data storage unit, a set of APIs (42) is provided, which is a collection of application programming interfaces prepared for each standard vehicle data. An in-vehicle device equipped with the following features.

[0206] [Item 2] The in-vehicle device described in item 1, The in-vehicle unit is connected to the in-vehicle network via a diagnostic port (61) provided in the vehicle. The data acquisition unit is configured to use diagnostic commands used in diagnostic communication as the command. Onboard machine.

[0207] [Item 3] An in-vehicle device as described in item 1 or item 2, The system further includes a schedule management unit (48) configured to extract commands indicated by management information that satisfy the acquisition conditions, using one or more pieces of management information that specify the type of command used to acquire the specific vehicle data corresponding to the standard vehicle data, and the acquisition conditions for the standard vehicle data, as commands to be transmitted in the transmission process. Onboard machine.

[0208] [Item 4] The in-vehicle device according to claim 3, The data acquisition unit is configured to repeatedly execute the transmission process at a predetermined execution cycle. The schedule management unit is configured to extract the command indicated by the management information that satisfies the acquisition conditions as the command to be transmitted in the next execution cycle. Onboard machine.

[0209] [Item 5] An in-vehicle device as described in item 3 or item 4, The methods for specifying the acquisition conditions include periodic drive, which acquires data repeatedly at regular intervals, and event drive, which acquires data when a specified event occurs. Onboard machine.

[0210] [Item 6] An in-vehicle device described in any one of items 3 through 5, The schedule management unit is configured to exclude some of the commands to be transmitted from the transmission process if processing all of the commands to be transmitted extracted from the one or more pieces of management information in the transmission process could cause the in-vehicle network to become overloaded, in order to prevent such overload from occurring. Onboard machine.

[0211] [Item 7] The in-vehicle device described in item 6, The schedule management unit is configured to determine that a load overload occurs when the traffic of the in-vehicle network exceeds an acceptable value. Onboard machine.

[0212] [Item 8] An in-vehicle device described in item 6 or item 7 that references item 4, The schedule management unit is configured to determine that a load is exceeded if the total turnaround time of the commands to be transmitted exceeds the execution cycle of the transmission process. Onboard machine.

[0213] [Item 9] The in-vehicle device described in item 8, The data acquisition unit is configured to measure the turnaround time when the in-vehicle unit is started up. Onboard machine.

[0214] [Item 10] An in-vehicle device as described in item 8 or item 9, The data acquisition unit is configured to measure the turnaround time when there is a change in the configuration of the hardware connected to the in-vehicle device or the configuration of the software executed by the application execution unit. Onboard machine.

[0215] [Item 11] An in-vehicle device described in any one of items 6 through 10 that references item 4, The management information includes the priority for sending the command, The schedule management unit is configured to exclude at least one of the following from the commands to be transmitted when it determines that the load has been exceeded: the management information with the lowest priority, the management information with a priority below the exclusion threshold, and the management information with an acquisition cycle of 10 times or more the execution cycle. Onboard machine.

[0216] [Item 12] The in-vehicle device described in item 11, The schedule management unit is configured to adjust the management information so that the management information excluded from the commands to be transmitted is extracted as a command to be transmitted in an execution cycle later than the execution cycle in which the command to be transmitted was excluded. Onboard machine.

[0217] [Item 13] An in-vehicle device as described in item 11 or item 12, Each of the application programming interfaces belonging to the aforementioned API group is further provided with an API monitoring unit (461) configured to monitor the usage status of the application programming interface, The aforementioned priority is set to a higher value the more frequently the application programming interface used to acquire the vehicle data associated with that priority is used, based on the monitoring results of the API monitoring unit. Onboard machine.

[0218] [Item 14] An in-vehicle device described in any one of items 11 to 13, The priority is set according to the data type of the vehicle data associated with that priority. Onboard machine.

[0219] [Item 15] An in-vehicle device described in any one of items 11 through 14, The priority is set according to the acquisition conditions of the vehicle data associated with that priority. Onboard machine.

[0220] [Item 16] An in-vehicle device according to any one of claims 1 to 15, The system further includes a peripheral information acquisition unit (49) configured to acquire peripheral information, including the aforementioned instruction sheet, information for interpreting frames received from the in-vehicle network, information for converting the unique vehicle data obtained by interpreting the frames into the standard vehicle data, and a list of the commands usable in the vehicle, via wireless communication with a server (10) located outside the vehicle. Onboard machine.

[0221] [Item 17] An in-vehicle device described in any one of items 1 through 16, The vehicle data acquired by the data acquisition unit includes at least one of the following: 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, light status, interior and exterior temperature, air conditioning operation status, door and window open / closed status, door and window locked 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.

[0222] [Item 18] An in-vehicle device as described in item 3 or any one of items 4 through 17 that references item 3, The schedule management unit obtains a manifest from the distribution source of the application program, which is linked to the application program and describes the type of vehicle data requested by the application program and the conditions for acquiring the vehicle data, and generates the management information in accordance with the manifest. The management information includes, in addition to the type of vehicle data and the conditions for acquiring the vehicle data, information that identifies the requesting application, which is the application program that requests the vehicle data. The schedule management unit generates routing information that associates the transmitted command with the requesting application for the vehicle data obtained by the command, The system further includes a routing unit (43) configured to provide the vehicle data acquired by the data acquisition unit executing the transmission process to the requesting application using the routing information. Onboard machine.

[0223] [Item 19] An in-vehicle device described in any one of items 1 through 18, The system further includes a passive data acquisition unit (45) configured to extract the unique vehicle data from frames flowing through the in-vehicle network independently of the transmission of the aforementioned command, convert the extracted unique vehicle data into standard vehicle data, and store it in the standard vehicle data storage unit. Onboard machine.

[0224] [Item 20] An in-vehicle device described in any one of items 1 through 19, The vehicle further comprises a standard vehicle data transmission unit (49) configured to wirelessly transmit the standard vehicle data stored in the standard vehicle data storage unit to a server (10) located outside the vehicle. Onboard machine.

[0225] [Claim 21] The system comprises one or more in-vehicle devices (30) and a server (10) located outside the vehicle on which the in-vehicle devices are mounted. The in-vehicle device comprises the configuration described in any one of items 1 to 20, The server includes a digital twin database (133) that stores at least one of the standard vehicle data transmitted from each of the in-vehicle units, and digital twin data that emulates a vehicle equipped with the in-vehicle unit, which is generated based on the standard vehicle data. Data provision system.

Claims

1. It is an in-vehicle device, A data acquisition unit (44, 45) is configured to perform a transmission process to acquire unique vehicle data, which is the vehicle data expressed in a format specific to the vehicle, from the vehicle network by sending a command to the vehicle network of the vehicle on which the in-vehicle unit is installed, in accordance with an instruction sheet that shows one or more types of standard vehicle data, which are standardized vehicle data. A standard vehicle data storage unit (343) is configured to convert the unique vehicle data acquired by the data acquisition unit into the format of the standard vehicle data and store it there. An application execution unit (41) configured to execute one or more application programs that utilize the standard vehicle data, In order to provide the application program executed by the application execution unit with the function to acquire the standard vehicle data from the standard vehicle data storage unit, a set of APIs (42) is provided, which is a collection of application programming interfaces prepared for each of the standard vehicle data. A schedule management unit (48) is configured to extract commands indicated by management information that satisfy the acquisition conditions, using one or more pieces of management information that indicate the type of command used to acquire the specific vehicle data corresponding to the standard vehicle data, and the acquisition conditions for the standard vehicle data, as commands to be transmitted in the transmission process. An in-vehicle device equipped with the following features.

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

3. The in-vehicle device according to Claim 1, The data acquisition unit is configured to repeatedly execute the transmission process at a predetermined execution cycle. The schedule management unit is configured to extract the command indicated by the management information that satisfies the acquisition conditions as the command to be transmitted in the next execution cycle. Onboard machine.

4. The in-vehicle device according to Claim 1, The methods for specifying the acquisition conditions include periodic drive, which acquires data repeatedly at regular intervals, and event drive, which acquires data when a specified event occurs. Onboard machine.

5. An in-vehicle device according to any one of claims 1 to 4, The schedule management unit is configured to exclude some of the commands to be transmitted from the transmission process if transmitting all of the commands to be transmitted extracted from one or more pieces of management information in the transmission process could cause the in-vehicle network to become overloaded, in order to prevent such overload from occurring. Onboard machine.

6. The in-vehicle device according to claim 5, The schedule management unit is configured to determine that a load overload occurs when the traffic of the in-vehicle network exceeds an acceptable value. Onboard machine.

7. An in-vehicle device according to claim 5, referencing claim 3, The schedule management unit is configured to determine that a load is exceeded if the total turnaround time of the commands to be transmitted exceeds the execution cycle of the transmission process. Onboard machine.

8. The in-vehicle device according to claim 7, The data acquisition unit is configured to measure the turnaround time when the in-vehicle unit is started up. Onboard machine.

9. The in-vehicle device according to claim 7, The data acquisition unit is configured to measure the turnaround time when there is a change in the configuration of the hardware connected to the in-vehicle device or the configuration of the software executed by the application execution unit. Onboard machine.

10. An in-vehicle device according to claim 5, relating to claim 3, The management information includes the priority for sending the command, The schedule management unit is configured to exclude at least one of the following from the commands to be transmitted when it determines that the load has been exceeded: the management information with the lowest priority, the management information with a priority below the exclusion threshold, and the management information with an acquisition cycle of 10 times or more the execution cycle. Onboard machine.

11. The in-vehicle device according to claim 10, The schedule management unit is configured to adjust the management information so that the management information excluded from the commands to be transmitted is extracted as a command to be transmitted in an execution cycle later than the execution cycle in which the command was excluded. Onboard machine.

12. The in-vehicle device according to claim 10, Each of the application programming interfaces belonging to the API group further comprises an API monitoring unit (461) configured to monitor the usage status of the application programming interface, The aforementioned priority is set to a higher value the more frequently the application programming interface used to acquire the vehicle data associated with that priority is used, based on the monitoring results of the API monitoring unit. Onboard machine.

13. The in-vehicle device according to claim 10, The priority is set according to the data type of the vehicle data associated with that priority. Onboard machine.

14. The in-vehicle device according to claim 10, The priority is set according to the acquisition conditions of the vehicle data associated with that priority. Onboard machine.

15. The in-vehicle device according to claim 1, The system further includes a peripheral information acquisition unit (49) configured to acquire peripheral information, including the aforementioned instruction sheet, information for interpreting frames received from the in-vehicle network, information for converting the unique vehicle data obtained by interpreting the frames into the standard vehicle data, and a list of the commands usable in the vehicle, via wireless communication with a server (10) located outside the vehicle. Onboard machine.

16. The in-vehicle device according to claim 1, The vehicle data acquired by the data acquisition unit includes at least one of the following: 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, light status, interior and exterior temperature, air conditioning operation status, door and window open / closed status, door and window locked 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.

17. The in-vehicle device according to Claim 1, The schedule management unit obtains a manifest from the distribution source of the application program, which is linked to the application program and describes the type of vehicle data requested by the application program and the conditions for acquiring the vehicle data, and generates the management information in accordance with the manifest. The management information includes, in addition to the type of vehicle data and the conditions for acquiring the vehicle data, information that identifies the requesting application, which is the application program that requests the vehicle data. The schedule management unit generates routing information that associates the transmitted command with the requesting application for the vehicle data obtained by the command, The system further includes a routing unit (43) configured to provide the vehicle data acquired by the data acquisition unit performing the transmission process to the requesting application using the routing information. Onboard machine.

18. The in-vehicle device according to claim 1, The system further includes a passive data acquisition unit (45) configured to extract the unique vehicle data from frames flowing through the in-vehicle network independently of the transmission of the aforementioned command, convert the extracted unique vehicle data into standard vehicle data, and store it in the standard vehicle data storage unit. Onboard machine.

19. The in-vehicle device according to claim 1, The vehicle further comprises a standard vehicle data transmission unit (49) configured to wirelessly transmit the standard vehicle data stored in the standard vehicle data storage unit to a server (10) located outside the vehicle. Onboard machine.

20. An in-vehicle device, A data acquisition unit (44, 45) is configured to perform a transmission process to acquire unique vehicle data, which is the vehicle data expressed in a format specific to the vehicle, from the vehicle network by sending a command to the vehicle network of the vehicle on which the in-vehicle unit is installed, in accordance with an instruction sheet that shows one or more types of standard vehicle data, which are standardized vehicle data. A standard vehicle data storage unit (343) is configured to convert the unique vehicle data acquired by the data acquisition unit into the format of the standard vehicle data and store it there. An application execution unit (41) configured to execute one or more application programs that utilize the standard vehicle data, In order to provide the application program executed by the application execution unit with the function to acquire the standard vehicle data from the standard vehicle data storage unit, a set of APIs (42) is provided, which is a collection of application programming interfaces prepared for each of the standard vehicle data. Equipped with, The data acquisition unit is configured to repeatedly execute the transmission process at a predetermined execution cycle. On-vehicle device

21. An in-vehicle device, A data acquisition unit (44, 45) is configured to perform a transmission process to acquire unique vehicle data, which is the vehicle data expressed in a format specific to the vehicle, from the vehicle network by sending a command to the vehicle network of the vehicle on which the in-vehicle unit is installed, in accordance with an instruction sheet that shows one or more types of standard vehicle data, which are standardized vehicle data. A standard vehicle data storage unit (343) is configured to convert the unique vehicle data acquired by the data acquisition unit into the format of the standard vehicle data and store it there. An application execution unit (41) configured to execute one or more application programs that utilize the standard vehicle data, In order to provide the application program executed by the application execution unit with the function to acquire the standard vehicle data from the standard vehicle data storage unit, a set of APIs (42) is provided, which is a collection of application programming interfaces prepared for each of the standard vehicle data. The system further includes a routing unit (43) configured to provide the vehicle data acquired by the data acquisition unit through the transmission process to the requesting application, which is the application program that requests the vehicle data acquired by the command, using routing information that associates the transmitted command with the requesting application. Onboard machine.

22. The system comprises one or more in-vehicle devices (30) and a server (10) located outside the vehicle on which the in-vehicle devices are mounted. The in-vehicle device has the configuration described in claim 1, The server includes a digital twin database (133) that stores at least one of the standard vehicle data transmitted from each of the in-vehicle units, and digital twin data that emulates a vehicle equipped with the in-vehicle unit, which is generated based on the standard vehicle data. Data provision system.

23. A method for providing an application execution environment that provides vehicle data acquired via the in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs installed on the in-vehicle device, A transmission process is performed to obtain unique vehicle data, which is vehicle data expressed in a format specific to the vehicle, from the in-vehicle network by sending a command to the in-vehicle network in accordance with an instruction sheet that shows one or more types of standard vehicle data, which are standardized vehicle data. The unique vehicle data obtained by executing the transmission process is converted into the format of the standard vehicle data and stored in the standard vehicle data storage unit. In order to provide a function for acquiring the standard vehicle data from the standard vehicle data storage unit, the application program is provided with the standard vehicle data by a set of APIs, which are application programming interfaces prepared for each of the standard vehicle data. Using one or more pieces of management information that indicate the type of command used to acquire the specific vehicle data corresponding to the standard vehicle data, and the acquisition conditions for the standard vehicle data, the command indicated by the management information that satisfies the acquisition conditions is extracted as a command to be transmitted in the transmission process. Data provision method.

24. A program for providing vehicle data acquired via the in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs installed on the in-vehicle device, The aforementioned in-vehicle device, The process involves sending a command to the in-vehicle network in accordance with an instruction sheet that specifies one or more types of standardized vehicle data, which are standardized vehicle data, thereby performing a transmission process to obtain unique vehicle data, which are vehicle data expressed in a format specific to the vehicle, from the in-vehicle network. The unique vehicle data obtained by executing the transmission process is converted into the format of the standard vehicle data and stored in the standard vehicle data storage unit. In order to provide a function to acquire the standard vehicle data from the standard vehicle data storage unit, the application program is provided with the standard vehicle data by a set of APIs, which are application programming interfaces prepared for each of the standard vehicle data. Using one or more pieces of management information that indicate the type of command used to acquire the specific vehicle data corresponding to the standard vehicle data, and the acquisition conditions for the standard vehicle data, the command indicated by the management information that satisfies the acquisition conditions is extracted as a command to be transmitted in the transmission process, which is the command to be transmitted. A program that performs the following action.

25. A program for providing vehicle data acquired via an in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs located on the in-vehicle device, The aforementioned in-vehicle device, The process involves sending a command to the in-vehicle network in accordance with an instruction sheet that specifies one or more types of standardized vehicle data, which are standardized vehicle data, thereby performing a transmission process to obtain unique vehicle data, which are vehicle data expressed in a format specific to the vehicle, from the in-vehicle network. The unique vehicle data obtained by executing the transmission process is converted into the format of the standard vehicle data and stored in the standard vehicle data storage unit. In order to provide a function for acquiring the standard vehicle data from the standard vehicle data storage unit, the application program is provided with the standard vehicle data by a set of APIs, which are a collection of application programming interfaces prepared for each of the standard vehicle data. The aforementioned transmission process is to be repeatedly executed at a predetermined execution cycle, A program that performs the following action.

26. A program for providing vehicle data acquired via an in-vehicle network of a vehicle equipped with an in-vehicle device to one or more application programs located on the in-vehicle device, The aforementioned in-vehicle device, The process involves sending a command to the in-vehicle network in accordance with an instruction sheet that specifies one or more types of standardized vehicle data, which are standardized vehicle data, thereby performing a transmission process to obtain unique vehicle data, which are vehicle data expressed in a format specific to the vehicle, from the in-vehicle network. The unique vehicle data obtained by executing the transmission process is converted into the format of the standard vehicle data and stored in the standard vehicle data storage unit. In order to provide a function for acquiring the standard vehicle data from the standard vehicle data storage unit, the application program is provided with the standard vehicle data by a set of APIs, which are a collection of application programming interfaces prepared for each of the standard vehicle data. The vehicle data obtained by executing the transmission process is provided to the requesting application, which is the application program that requests the vehicle data obtained by the command, using routing information that associates the transmitted command with the requesting application. A program that performs the following action.

Images