On-vehicle terminal, data synchronization system, data synchronization method, and program

Abstract

When a vehicle service is newly installed by an orchestrator, a synchronization unit generates component data to be used for describing information related to an added service, which is the vehicle service that was added by the installation. The synchronization unit also performs a setting for receiving a first change notification indicating that target component data in an on-vehicle database has been changed, and a second change notification indicating that the target component data in a cloud database has been changed, the target component data being the component data of the added service.

Description

In-vehicle terminal, data synchronization system, data synchronization method, and program Cross-reference to Related Applications

[0001] This international application claims the benefit of Japanese Patent Application No. 2025-055452 filed with the Japan Patent Office on March 28, 2025, the entire disclosure of which is incorporated herein by reference into this international application.

[0002] The present disclosure relates to technology for collecting and using vehicle data.

[0003] Patent Document 1 describes a technology for installing a vehicle service downloaded from a cloud into a vehicle and executing the vehicle service in the vehicle.

[0004] In recent years, there has been known a system that realizes a digital twin that reproduces a virtual space time-synchronized with real space on a computer such as a cloud by storing and updating data on current and past vehicle states collected from a vehicle in real time.

[0005] International Publication No. WO 2024 / 143007

[0006] However, as a result of detailed studies by the inventor, the following problems have been found in the conventional technology.

[0007] In a digital twin system, a mechanism for synchronizing data is statically set in advance, so it has been difficult to increase or decrease the amount of data to be synchronized. For example, when a new vehicle service is installed in a vehicle, in order to synchronize data obtained by the vehicle service to the cloud, it has been necessary to update the mechanism for synchronizing data. That is, it has been found that there is a problem that it is difficult to reflect and use data related to additionally installed vehicle services in a digital twin later.

[0008] One aspect of the present disclosure provides a technology that facilitates the use of dynamically installed vehicle services.

[0009] One aspect of this disclosure is an in-vehicle terminal configured to communicate with an external device having a cloud database that stores at least a request list, which is a list of vehicle services to be installed in the vehicle. The in-vehicle terminal is configured to communicate with the external device via a communication unit and further comprises an in-vehicle database, a synchronization unit, and an orchestrator. The in-vehicle database is configured to store multiple component data, each associated with any of the in-vehicle components. When the synchronization unit detects a change in component data stored in the in-vehicle database, it uploads the changed component data to the cloud database. When the synchronization unit detects a change in component data stored in the cloud database, it downloads the changed component data to the in-vehicle database. In other words, the synchronization unit is configured to synchronize the contents of the in-vehicle database with the contents of the cloud database. The orchestrator is configured to perform the installation of vehicle services. When a new vehicle service is installed by the orchestrator, the synchronization unit generates component data to be used to describe information about the additional service, which is a vehicle service added by the installation. Furthermore, the synchronization unit is configured to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed. The target component data is the component data for additional services.

[0010] With this configuration, when a vehicle service is installed on the in-vehicle terminal, component data used to describe information about the vehicle service added by the installation is automatically generated. Therefore, after the vehicle service is installed, it becomes possible to operate the vehicle service using the component data without requiring any special operations, thereby improving the convenience for users of the vehicle service.

[0011] One aspect of this disclosure is a data synchronization system. The data synchronization system comprises an external device and an in-vehicle terminal. The external device is located outside the vehicle. The in-vehicle terminal is mounted in the vehicle. The external device includes a cloud database that stores at least a request list, which is a list of vehicle services to be installed on the vehicle. The in-vehicle terminal is configured to communicate with the external device via a communication unit and further includes an in-vehicle database, a synchronization unit, and an orchestrator. The in-vehicle database is configured to store multiple component data, each associated with any of the in-vehicle components. When the synchronization unit detects a change in component data stored in the in-vehicle database, it uploads the changed component data to the cloud database. Also, when the synchronization unit detects a change in component data stored in the cloud database, it downloads the changed component data to the in-vehicle database. In other words, the synchronization unit is configured to synchronize the contents of the in-vehicle database with the contents of the cloud database. The orchestrator is configured to perform the installation of vehicle services. The synchronization unit generates component data used to describe information about additional services, which are vehicle services added by the installation, when a new vehicle service is installed by the orchestrator. The synchronization unit is also configured to receive a first change notification indicating that the target component data in the in-vehicle database has been changed, and a second change notification indicating that the target component data in the cloud database has been changed. The target component data is the component data for the additional service.

[0012] With this configuration, after installing the vehicle service, it becomes possible to operate the vehicle service using component data without requiring any special operations, thereby improving convenience for users of the vehicle service.

[0013] One aspect of this disclosure is a data synchronization method for a data synchronization system comprising a cloud database and an in-vehicle database, which synchronizes the contents of the cloud database with the contents of the in-vehicle database.

[0014] The cloud database is located on an external device outside the vehicle and stores at least a request list, which is a list of vehicle services to be installed on the vehicle. The in-vehicle database is located on an in-vehicle terminal mounted in the vehicle and communicating with the external device via a communication unit, and each terminal stores multiple component data associated with any of the in-vehicle components. In the data synchronization method, when a change in component data stored in the in-vehicle database is detected, the component data with the detected change is uploaded to the cloud database. Also, in the data synchronization method, when a change in component data stored in the cloud database is detected, the component data with the detected change is downloaded to the in-vehicle database. By uploading and downloading the component data with detected changes in this way, the contents of the in-vehicle database and the contents of the cloud database are synchronized.

[0015] Furthermore, in the data synchronization method, when a new vehicle service is installed on the vehicle, component data is generated to describe information about the additional service, which is a vehicle service added by the installation.The data synchronization method then configures the system to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed.The target component data is the component data of the additional service.Furthermore, the data synchronization method synchronizes the target component data on the in-vehicle database with the target component data on the cloud database in accordance with the first and second change notifications.

[0016] One aspect of this disclosure is a data synchronization method for an in-vehicle terminal equipped with an in-vehicle database, which is configured to communicate with an external device equipped with a cloud database, and synchronizes the contents of the in-vehicle database with the contents of the cloud database.

[0017] The specific method is similar to the data synchronization method used in a data synchronization system, which is one aspect of this disclosure, for synchronizing target component data on an in-vehicle database with target component data on a cloud database.

[0018] By implementing such a data synchronization method, the same effects as those of a data synchronization system and an in-vehicle terminal, which are embodiments of this disclosure, can be obtained.

[0019] One aspect of this disclosure is a program that causes a computer to function as an in-vehicle database, a synchronization unit, and an orchestrator, which are provided in an in-vehicle terminal, which is an aspect of this disclosure. The computer is provided in an in-vehicle terminal configured to communicate with an external device. The external device includes a cloud database that stores at least a request list, which is a list of vehicle services to be installed in the vehicle.

[0020] By running such a program, the computer can be made to function as an in-vehicle terminal, which is one aspect of this disclosure.

[0021] This is a block diagram showing the configuration of the digital twin system of the first embodiment. This is an explanatory diagram showing the structure related to shadows. This is a sequence diagram showing the procedure performed to receive change notifications indicating that data stored in the in-vehicle database and the cloud database has changed. This is a sequence diagram showing the procedure for synchronizing shadow changes that occur in the cloud database with the in-vehicle database. This is a sequence diagram showing the procedure for synchronizing shadow changes that occur in the in-vehicle database with the cloud database when the internet is not connected. This is a sequence diagram showing the procedure for synchronizing shadow changes that occur in the in-vehicle database with the cloud database, including not only the latest value but all history, when the internet is not connected. This is a sequence diagram showing the procedure for backing up persistent data and restoring shadow values ​​according to the backed-up content when the system is restarted. This is a block diagram showing the configuration of the digital twin system of the second embodiment. This is an explanatory diagram showing the configuration of RS objects and S objects possessed by a service thing that manages vehicle services. This is a sequence diagram showing the procedure for installing vehicle services. This is an explanatory diagram showing the procedure for using an operation thing. This is a sequence diagram showing the procedure for uninstalling vehicle services. This is an explanatory diagram showing the structure of a manifest. This is a sequence diagram showing the procedure for determining whether or not to generate an operation thing using the information in the manifest. This is an explanatory diagram illustrating an example of an RS object written to desire when issuing an installation instruction for a vehicle service. This is an explanatory diagram illustrating an example of an RS object and an S object written to report after the installation of a vehicle service. This is an explanatory diagram illustrating an example of an S object written to desire when issuing an uninstallation instruction for a vehicle service.

[0022] Embodiments of this disclosure will be described below with reference to the drawings.

[0023] [1. First Embodiment] [1-1. Configuration] The digital twin system 1 of the embodiment shown in Figure 1 comprises a cloud 2 and an in-vehicle system 3.

[0024] Cloud 2 includes a cloud-side unit 21, which is a platform for realizing a digital twin. Cloud 2 may also include one or more application programs (hereinafter referred to as "apps") 22 that perform information gathering and vehicle control using information from the digital twin.

[0025] The in-vehicle system 3 comprises an ECU group 4, a Mobicon 5, and a TCU 6. ECU stands for Electronic Control Unit. Mobicon stands for Mobility Computer.

[0026] The ECU group 4 consists of electronic control units mounted on the vehicle and is classified into zone ECUs 41 and terminal ECUs 42.

[0027] A zone ECU 41 is provided for each zone that divides the area within the vehicle. The zone ECU 41 is communicated with multiple terminal ECUs 42 located within the zone. The zone ECU 41 coordinates the multiple terminal ECUs 42 to achieve coordinated control within the zone.

[0028] The terminal ECU 42 executes processing to realize the function assigned to it, in accordance with instructions received via the zone ECU 41.

[0029] Mobicon 5 is an electronic control unit mounted in the vehicle and is communicated with multiple zone ECUs 41. Mobicon 5 manages the multiple zone ECUs 41 to achieve coordinated control of the entire vehicle.

[0030] MobiCon 5 comprises a vehicle-side unit 51, which is a platform for realizing a digital twin, and an in-vehicle communication processing unit 52. MobiCon 5 may also include one or more applications 53 that perform information gathering and vehicle control using information from the digital twin. In addition, MobiCon 5 may also include one or more applications 54 that do not utilize information from the digital twin.

[0031] The TCU 6 is a wireless communication unit that enables bidirectional information communication between the vehicle and external devices such as Cloud 2. TCU stands for Telematics Control Unit. The MobiCon 5 is connected to Cloud 2 via the TCU 6, enabling communication.

[0032] The communication network connecting the ECU group 4, MobiCon 5, and TCU 6 can use, for example, Ethernet, CAN, or CAN FD. Ethernet is a registered trademark. CAN is an abbreviation for Controller Area Network, and CAN FD is an abbreviation for CAN With Flexible Data Rate. The communication networks that can be used in the in-vehicle system 3 are not limited to the example communication networks. In addition, the in-vehicle system 3 may have a mixture of multiple types of communication networks.

[0033] The in-vehicle communication processing unit 52 has the function of collecting data from various devices mounted on the vehicle, such as the ECUs 41 and 42 and sensors, and converting the collected data into a standard format. In addition, the in-vehicle communication processing unit 52 has the function of converting instructions from the vehicle-side unit 51 to the ECUs 41 and 42 into a format that the ECUs 41 and 42 can accept.

[0034] [1-2. Overview of Digital Twin] The digital twin recreates a virtual space on a computer that is synchronized with the real world by storing and updating data on the current and past vehicle status collected from the ECU group 4 in real time.

[0035] The data used to create a digital twin is also called "shadow." Shadow refers to state data related to various components of a vehicle, such as "the engine is on" or "the air conditioning is on."

[0036] Shadows are managed in units called "things," as shown in Figure 2.

[0037] A "thing" is a collection of items similar to a folder, and is provided for each virtual group unit such as CarA, EcuB, AppX, etc. Hereafter, the in-vehicle components associated with a "thing" are referred to as "target components." A "thing" contains one or more shadows related to the target component. In-vehicle components include both hardware such as devices and software such as applications.

[0038] Each shadow is managed using two types of data: report and desire.

[0039] The `report` variable represents the current state (i.e., the latest state) of the target component and is written by a single application that manages the target component (hereinafter referred to as the "target application"). Furthermore, if the state of the target component changes, the changed state is overwritten and written to the `report` variable.

[0040] The `desire` parameter represents the desired state of the target component after a change, and is written from an external source (i.e., an application other than the target application).

[0041] For example, if you want to turn on the air conditioner, you write a value (e.g., True) indicating that you want it turned on to the `desire` field of the shadow (hereinafter referred to as the "focus shadow") which handles the on / off state of the air conditioner in the `thing` which treats the air conditioner as the target component. Then, the target application that manages the air conditioner reads the write to `desire` and outputs an instruction to the terminal ECU 42 that controls the air conditioner installed in the vehicle via the in-vehicle communication processing unit 52, thereby actually turning on the air conditioner. The target application also obtains the processing result from the terminal ECU 42 that controls the air conditioner via the in-vehicle communication processing unit 52 and writes the obtained processing result to the `report` field of the focus shadow.

[0042] Further, for example, when instructing data to be uploaded from the vehicle to the cloud 2 for a certain target application from the outside, the data desired to be uploaded may be written to the desire of the shadow that handles the update status of vehicle data in the thing that treats the vehicle as a target component. In this case, a plurality of pieces of data may be listed and written in desire as [GPS coordinates, vehicle speed], [steering angle, vehicle speed] or the like. Further, a data collection condition table listing data collection conditions may be written to the desire of the shadow that handles the update status of vehicle data.

[0043] As a method for causing the target application to execute processing related to the target component, a method using job is provided in addition to the method using desire. A job is basically downloaded from the cloud 2.

[0044] Desire may be used in simple cases where no failure or mediation is required, such as instructing a certain application to upload specified data from the outside, for example.

[0045] Job may be used in cases where not only a state is specified but also an action is instructed, such as "update application A", "open the trunk", "cause the system to execute a specified command", for example. The instruction content is described in arbitrary text, and a format that both the sender and receiver can understand is used. Note that similarly to desire, a job may list data desired to be uploaded, or may indicate a data collection condition table related to the data desired to be uploaded.

[0046] Note that the data collection condition table may be incorporated in the target application. In this case, the data collection condition table is installed together with the target application via OTA. In other words, when the target application is updated, the data collection condition table is also updated. OTA is an abbreviation for Over the Air, and indicates that the transmission is via wireless.

[0047] A job is issued for a thing. A thing can accept a plurality of jobs, and stores the accepted jobs in a job queue in the order of acceptance. The target application of the thing acquires one job at a time from the job queue in descending order of priority and executes processing. Parallel processing of jobs is basically not performed.

[0048] In a thing, the progress of a job is managed by the job status. The target application executes the instruction content described in the job while rewriting the job status.

[0049] When a job is created, the job status is initialized to QUEUED, which indicates that the job has not been started.

[0050] When the target application receives the job and starts work, the job status is rewritten to IN_PROGRESS, which indicates that work is in progress. Note that the job status may display a number from 0 to 100% representing the progress of the work instead of or together with IN_PROGRESS.

[0051] When the target application completes work based on the job, the job status is rewritten to SUCCEEDED, which indicates that the work has been completed.

[0052] Note that statuses such as CANCELED, FAILED, and REJECTED, which are used when an error or work failure occurs, may be used as the job status. Furthermore, any error message specified by a character string may be used.

[0053] [1-3. Cloud-side Unit / Vehicle-side Unit] Returning to Fig. 1, the cloud-side unit 21 that handles digital twins and the vehicle-side unit 51 will be described.

[0054] The cloud-side unit 21 includes a cloud database (hereinafter referred to as cloud DB) 211 and a cloud core unit 212.

[0055] The vehicle-side unit 51 includes an in-vehicle database (hereinafter referred to as in-vehicle DB) 511, an in-vehicle core unit 512, and a synchronization unit 513.

[0056] The cloud DB211 stores information necessary to realize a digital twin of multiple in-vehicle systems 3. The "things" used to classify and manage the shadows are assigned names that allow identification of which in-vehicle system 3 they belong to.

[0057] The in-vehicle DB511 stores information necessary to realize a digital twin of the vehicle.

[0058] The in-vehicle DB511 comprises a volatile region and a non-volatile region. The volatile region consists of volatile memory whose contents are erased when the power to the in-vehicle system 3 is turned off. The non-volatile region consists of non-volatile memory whose contents are not erased even when the power is turned off.

[0059] Furthermore, the in-vehicle DB 511 includes a DS area A1, a VSS area A2, a cache area A3, and an application-dedicated area A4. The DS area A1 stores "thing". DS stands for Device Shadow. The VSS area A2 stores vehicle data collected from various devices installed in the vehicle by the in-vehicle communication processing unit 52 and converted into a standard format, and is updated periodically. In other words, only the latest values ​​of standardized vehicle data are stored in the VSS area A2. VSS stands for Volume Shadow Copy Service. The data stored in the VSS area A2 is data used by applications 53 and cloud 2, etc., via "thing", and is not basically data that is directly uploaded to the cloud DB 211. However, the state of individual data stored in the VSS area A2 may be represented by a shadow. Cache area A3 is a temporary storage area for data that needs to be uploaded to Cloud 2 while communication with Cloud 2 is unavailable. Application-specific area A4 is provided for each application and stores the data requested by the application, retrieved from VSS area A2.

[0060] The DS area A1, VSS area A2, cache area A3, and application-specific area A4 are generally set as volatile areas. However, if data that needs to be reproduced after the power is turned off and the device is restarted is stored, areas A1 to A4 may be set as non-volatile areas.

[0061] For example, if it's possible to configure whether or not to persist the report value on a per-thing basis, then things for which persistence is enabled will be stored in the non-volatile area. For things stored in the non-volatile area, when the system is restarted after a power off, the contents of the report will be maintained in the state it was in immediately before the power off. However, for things that are not configured for persistence and are stored in the volatile area, when the system is restarted after a power off, they will be newly created in the volatile area, and the contents of the report will start from an empty data state.

[0062] The cloud core unit 212 and the in-vehicle core unit 512 accept subscription activation requests from external sources. A subscription activation request is a request to be notified when a change in the state of a specified monitored item is detected for a specified item.

[0063] The cloud core unit 212 monitors the status of the "thing" stored in the cloud DB 211, and when it detects a change in the status indicated in the subscription request, it sends a change notification indicating the change to the source of the subscription request. Similarly, the in-vehicle core unit 512 monitors the status of the "thing" stored in the in-vehicle DB 511, and when it detects a change in the status indicated in the subscription request, it sends a change notification indicating the change to the source of the subscription request.

[0064] The sources requesting the start of a subscription are the synchronization unit 513, applications 22 and 53, and user terminal 7, etc. User terminal 7 is a terminal operated by a user who uses the digital twin via cloud 2.

[0065] The synchronization unit 513 has the function of synchronizing the cloud DB 211 and the in-vehicle DB 511. When the in-vehicle system 3 starts up, the synchronization unit 513 requests the cloud core unit 212 and the in-vehicle core unit 512 to start the subscription. The subscription start request is made for each thing, and the data to be monitored is all data that needs to be synchronized.

[0066] When the synchronization unit 513 receives a change notification from the cloud core unit 212, it updates the corresponding "thing" item in the in-vehicle DB 511 according to the content of the change notification. Similarly, when the synchronization unit 513 receives a change notification from the in-vehicle core unit 512, it updates the corresponding "thing" item in the cloud core unit 212 according to the content of the change notification. As a result, the updates in the cloud DB 211 are reflected in the in-vehicle DB 511, and the updates in the in-vehicle DB 511 are reflected in the cloud DB 211, so that both DBs 211 and 511 are maintained in a synchronized state.

[0067] [4. Sequence] The operation flow in the digital twin system 1 will be explained using a sequence diagram.

[0068] [4-1 Subscription Request] The operations related to the subscription start request made at startup will be explained using the sequence diagram in Figure 3.

[0069] In Figure 3, the client includes the synchronization unit 513, applications 22 and 53 that utilize the digital twin, and the user terminal 7, etc. The unit core is either the cloud core unit 212 or the in-vehicle core unit 512.

[0070] In S1, the client sends a subscription start request to the unit core. The subscription start request includes information specifying the thing and information specifying the items to be monitored within the thing. The items to be monitored may be specified individually, such as report, desire, job, etc., or all items may be specified together. If no items are specified, all items may be specified together.

[0071] Upon receiving a subscription start request, unit core monitors the status of the specified item in the specified thing specified in the subscription start request. When it detects a change in status, it sends a change notification to client in S2, indicating the changes. A change notification is sent each time a change in status is detected.

[0072] [1-4-2. Cloud DB Update] An example of the operation when a change occurs in Cloud DB211 will be explained using the sequence diagram in Figure 4.

[0073] When the in-vehicle system 3 starts up, in S11, application A (i.e., appA) 53 sends a request to the in-vehicle core unit 512 to start a subscription, specifying thing:appA which handles application A as the specified item and desire as the specified item. Hereinafter, specifying thing:appA which handles application A as the specified item and desire as the specified item will be referred to as thing:appA / desire. Also, in S12 and S13, the synchronization unit 513 sends a request to start a subscription to the in-vehicle core unit 512 and the cloud core unit 212, respectively, specifying thing:appA as the specified item and all items as specified items. Hereinafter, specifying thing:appA as the specified item and all items as specified items will be referred to as thing:appA.

[0074] The procedure to request the start of subscriptions S11-S13 is performed only once when the system starts up.

[0075] Subsequently, in S14, a user who wants to use application A writes `config=newValue` to `desire` (i.e., `thing:appA / desire`) of `thing:appA` stored in the cloud DB 211 from the user terminal 7. For example, this is the operation when a user wants to change the vehicle's air conditioning temperature setting (i.e., `config`) to 25°C (i.e., `newValue`) from the user terminal 7.

[0076] When the cloud core unit 212 detects a change in thing:appA / desire by monitoring the cloud DB 211, it sends a change notification indicating the changes to the synchronization unit 513, which is the source of the subscription request for thing:appA, in S15.

[0077] When the synchronization unit 513 receives a change notification from the cloud core unit 212, in S16 it writes config=newValue to thing:appA / desire stored in the in-vehicle DB 511 according to the contents of the change notification. As a result, the updated contents of the cloud DB 211 are downloaded and reflected in the in-vehicle DB 511.

[0078] When the in-vehicle core unit 512 detects a change in thing:appA / desire by monitoring the in-vehicle DB 511, it sends a change notification indicating the changes to application A, which is the source of the subscription request for thing:appA / desire, in S17.

[0079] When App A receives a change notification, it executes the process determined according to the content of the change notification. For example, App A executes the process of changing the air conditioner setting temperature, which is set to config, to 25°C, which is set to newValue.

[0080] [1-4-3. Updating the In-Vehicle Database] An example of the operation when the state of the in-vehicle database 511 changes will be explained using the sequence diagram in Figure 5.

[0081] When the in-vehicle system 3 starts up, in S21, the synchronization unit 513 sends a request to the in-vehicle core unit 512 to start a subscription, specifying thing:appA as the specified thing and all items as specified items.

[0082] The procedure to request the start of the S21 subscription is performed only once when the system starts up.

[0083] Subsequently, in S22, application A writes, for example, Error=“file is broken” to the report of thing:appA (hereinafter, thing:appA / report) stored in the in-vehicle DB511, indicating that an error occurred during processing.

[0084] When the in-vehicle core unit 512 detects a change in thing:appA / report by monitoring the in-vehicle DB 511, it sends a change notification indicating the changes to the synchronization unit 513, which is the source of the thing:appA subscription request, in S23.

[0085] When the synchronization unit 513 receives a change notification from the in-vehicle core unit 512, in S24, it writes Error=“file is broken” to thing:appA / desire stored in the cloud DB 211 according to the contents of the change notification. As a result, the changes in the in-vehicle DB 511 are uploaded and reflected in the cloud DB 211.

[0086] For example, in a shadow that manages the status of data uploads, the report may be rewritten when an application that monitors the data stored in VSS area A2 detects that the data related to the shadow has changed. The application 53 associated with this shadow may, for example, move a portion of the data in VSS area A2 to an application-specific area A4 on the in-vehicle DB 511 provided for the application 53. Furthermore, a thing may be set that targets the application-specific area A4 as the target component, and it may be configured so that synchronization with the cloud DB 211 is performed when the contents of the application-specific area A4 change. In this way, by synchronizing only the data required by the application 53 with the cloud DB 211, the amount of data transmitted during uploads is reduced. Alternatively, when the contents of VSS area A2 change, the entire VSS area A2 may be uploaded by synchronizing with the cloud DB 211. The upload of the application-specific area A4 and the upload of VSS area A2 may be enabled or disabled by configuration.

[0087] [1-4-4. Recovery from Offline] In the situation described in Figure 5, an example of operation when the system is offline and not connected to the internet will be explained using the sequence diagram in Figure 6. Note that the data to be synchronized between the cloud DB 211 and the in-vehicle DB 511 is set to either latest update or history update for each data. Latest update is a setting that uploads only the latest update data from the update data stored in cache area A3 while offline. History update is a setting that uploads all update data stored in cache area A3 while offline. Here, we will explain the synchronization of data set to latest update.

[0088] The operations from S21 to S23 are the same as those explained using Figure 5, so their explanation is omitted here.

[0089] When the synchronization unit 513 receives a change notification from the in-vehicle core unit 512, it attempts to write to the cloud DB 211 based on the changes, as described in S24. If the writing fails a specified number of times consecutively, it determines that the system is offline. If the synchronization unit 513 determines that the system is offline, in S25 it stores the changes indicated in the change notification in the cache area A3 of the in-vehicle DB 511. Since the data stored in the cache area A3 needs to be reproducible after the power is turned off, it is desirable that the cache area A3 be set as a non-volatile area.

[0090] The synchronization unit 513 monitors the internet connection status. While the offline state persists, the contents of the change notification are stored in the cache area A3. Note that for data configured to be updated, the changes may be overwritten so that only the latest values ​​are stored in the cache area A3.

[0091] Subsequently, once the internet connection is restored and the system is confirmed to be online, the synchronization unit 513 writes to the cloud DB 211 in S26 based on the latest values ​​of the changes stored in the cache area A3.

[0092] The internet connection status can be checked by periodically attempting to write to the cloud DB211, or by checking the communication connection status information obtained from the TCU6.

[0093] [1-4-5. Synchronizing the entire change history] Figure 6 illustrates the case of a recent update, where only the most recent changes obtained while offline are used to update the database. Figure 7 illustrates the case of a history update, where all changes obtained while offline are used to update the database.

[0094] Here, we assume a scenario where, in a digital twin, not only the vehicle's current location information but also its driving history information is made available to the user. In other words, the data `arrivePoint`, which represents the vehicle's current location, is set to update the history.

[0095] In S31, application A writes `arrivePoint=1`, calculated based on information acquired from a GPS device, etc., to `thing:appA / report` stored in the in-vehicle DB 511. In other words, it writes information indicating that the vehicle's current location data is 1.

[0096] When the in-vehicle core unit 512 detects a change in thing:appA / report by monitoring the in-vehicle DB 511, it sends a change notification indicating the change to the synchronization unit 513 in S32.

[0097] When the synchronization unit 513 confirms that it is offline, in S33 it stores the changes indicated in the change notification in the cache area A3.

[0098] Thereafter, while the offline state continues, the same operations as in S31 to S33 are repeated in S34 to S36 and S37 to S39. However, in S34, arrivePoint=2 is written to thing:appA / report, and in S37, arrivePoint=3 is written to thing:appA / report.

[0099] Furthermore, since arrivePoint is configured to update its history, when it is stored in cache area A3, all changes received while offline are stored without being overwritten.

[0100] After returning to an online state, the synchronization unit 513 reads the changes stored in the cache area A3 in S41, starting with the oldest changes. The synchronization unit 513 also writes the read changes to the cloud DB 211's thing:appA / report. If the write is successful, the synchronization unit 513 deletes the successfully written changes in S42. The process from S41 to S42 is then repeated until all changes stored in the cache area A3 are deleted.

[0101] As a result, all data that is configured to update its history, generated while offline, and stored in cache area A3 can be reflected in cloud DB211.

[0102] Note that the storage capacity of cache area A3 is limited, and if the offline state persists for a long time, cache area A3 may overflow. Therefore, you may set a cache policy as shown in (1) to (3) below to sequentially delete data that exceeds the capacity of cache area A3. The cache policy may be set fixedly, or it may be embedded in the application 53 and dynamically updated each time the application 53 is downloaded. Alternatively, the cache policy may be dynamically updated using desire, similar to changing the air conditioner temperature setting as described above. Note that the cache policy may be set for each thing, or it may be set individually for each data.

[0103] (1) Cache with expiration date: The latest changed data is cached sequentially for the duration of the expiration date (e.g., 8 hours), and data that has exceeded the expiration date is deleted sequentially.

[0104] (2) Cache with size limit: The latest modified data is cached up to the size limit (for example, 16 MB), and if the size limit is exceeded, the oldest modified data is deleted first.

[0105] (3) Cache with quantity limit: The latest change data is cached up to the quantity limit (e.g., 16 generations), and if the quantity limit is exceeded, the oldest change data is deleted in order.

[0106] [1-5. Correspondence of Terms] In this embodiment, the digital twin system 1 corresponds to the data synchronization system of this disclosure, the cloud 2 corresponds to the external device of this disclosure, and the MobiCon 5 corresponds to the in-vehicle terminal of this disclosure. In this embodiment, the TCU 6 corresponds to the communication unit of this disclosure. In this embodiment, the shadow corresponds to the component data of this disclosure, the report corresponds to the state data of this disclosure, and the desire corresponds to the request data of this disclosure.

[0107] [1-6. Effects] The embodiments described in detail above produce the following effects.

[0108] (1a) In the digital twin system 1, digital twins (i.e., cloud DB 211 and in-vehicle DB 511 that store shadows) are placed in both the cloud 2 and the in-vehicle system 3. Furthermore, in the digital twin system 1, the contents of the cloud DB 211 and the in-vehicle DB 511 are smoothly synchronized by the operation of the synchronization unit 513 located in the in-vehicle system 3. Therefore, the application 53 installed in the vehicle or the application 22 installed in the cloud 2 can smoothly perform various controls using the information of the digital twin.

[0109] (1b) In the digital twin system 1, two methods are provided for manipulating the shadow: one using report / desire and the other using job. Therefore, simple operations and complex operations can be instructed using methods appropriate to each.

[0110] (1c) The in-vehicle system 3 temporarily stores the changes made to the digital twin when offline in the cache area A3 and synchronizes the changes when online. Therefore, it is possible to prevent the loss of changes that should be synchronized between the in-vehicle DB 511 and the cloud DB 211 due to the occurrence of an offline state. For this reason, the creator of the application 53 that uses the digital twin information can create the application 53 without having knowledge of offline retries or caching.

[0111] (1d) The in-vehicle system 3 stores data such as "thing" in a non-volatile area, which is necessary to restore the state immediately before power-off when restarting after power-off. Therefore, when restarting, it can respond to various requests from the application 53, such as wanting to resume processing from the state immediately before power-off.

[0112] [2. Second Embodiment] [2-1. Differences from the First Embodiment] The second embodiment has the same basic configuration as the first embodiment, so the differences will be explained below. Note that the same reference numerals as in the first embodiment indicate the same components, and refer to the preceding description.

[0113] As shown in Figure 9, the digital twin system 1a of the second embodiment comprises a cloud 2a, an in-vehicle system 3a, and a user terminal 7a.

[0114] Cloud 2a further includes a repository 23 in addition to the configuration of Cloud 2 in the first embodiment. The repository 23 is a storage area for organizing and saving source code, files, etc. It stores application programs (hereinafter referred to as containers) for realizing vehicle services provided to vehicles, and manifests that show settings related to vehicle services.

[0115] Furthermore, the cloud DB 211 provides a "thing" (hereinafter referred to as "service thing") for managing the vehicle services provided for each MobiCon (hereinafter also referred to as "device") 5a installed in each vehicle. The service thing is used to operate the orchestrator 514, which will be described later. As shown in Figure 10, the service thing includes a requested service object (hereinafter referred to as "RS object") and a service object (hereinafter referred to as "S object"). RS stands for Required Services, and S stands for Services. Both the RS object and the S object correspond to shadow data. In the following, the device associated with the service thing of interest will be referred to as the target device.

[0116] The RS object is a list of information about vehicle services to be installed on the target device (hereinafter referred to as vehicle service information). The vehicle service information includes information such as the vehicle service name, version, path, and last modified time. The vehicle service name is information that identifies the vehicle service. The version is the version of the vehicle service. The path represents the storage location in the repository 23 of the container that implements the vehicle service. The last modified time is the time when the container was stored in the repository 23.

[0117] An S object is a list of information regarding the status of vehicle services on the target device (hereinafter referred to as status information).

[0118] Status information includes information such as vehicle service name, version, startup status, startup conditions, startup error messages, installation status, installation error messages, and last modified time. The vehicle service name, version, and last modified time are the same information as those found in the RS object. The startup status indicates the startup status (e.g., standby, starting, etc.) of the container (i.e., vehicle service) installed on the device. The startup conditions indicate the startup conditions for the vehicle service (e.g., when the ignition is turned on, etc.). The startup error message is an error message indicating the nature of the error that occurred when an error occurred during the startup of the vehicle service. The installation status indicates the installation status of the vehicle service (e.g., not installed, installing, installed, etc.). The installation error message is an error message indicating the nature of the error that occurred when an error occurred during the installation of the vehicle service.

[0119] The `desire` parameter is used to manipulate vehicle service information and status information for individual vehicle services listed in the RS and S objects.

[0120] Cloud 2a manages vehicle services to be installed on MobiCon 5a (i.e., devices) for each device group. Device groups may be set up, for example, by vehicle grade, by vehicle sales region, by dealership, etc. In this case, the same RS object is applied to devices belonging to the same device group. In other words, users who want to install or uninstall vehicle services on a device need to specify the device group and vehicle services on Cloud 2.

[0121] The user terminal 7a is equipped with a dashboard 71. The dashboard 71 is a GUI application that communicates with the cloud 2 to perform device registration, device group registration, and vehicle service installation-related instructions. GUI stands for Graphical User Interface. Installation-related instructions include installation instructions, uninstallation instructions, and update instructions. When a screen operation is performed on the dashboard 71, it retrieves the corresponding information from the cloud DB 211 and displays it on the screen or writes the corresponding information to the cloud DB 211.

[0122] The in-vehicle system 3a differs in some respects from the vehicle-side unit 51 of the first embodiment in the configuration of the vehicle-side unit 51a of the Mobicon 5a device. Specifically, in addition to the configuration of the vehicle-side unit 51, the vehicle-side unit 51a further includes an orchestrator 514.

[0123] The orchestrator 514 executes installation-related processes according to the contents of the target device's service thing, which is synchronized between the cloud DB 211 and the target device's in-vehicle DB 511. Installation-related processes include the installation, updating, and uninstallation of vehicle services.

[0124] [2-2. Operation] [2-2-1. Vehicle Service Installation] The operation when an installation instruction is received on the dashboard 71 will be explained according to the sequence diagram shown in Figure 11.

[0125] In the in-vehicle system 3, when the synchronization unit 513 detects that the vehicle's ignition is turned on, in S61 it requests the in-vehicle core unit 512 to start subscribing to (i.e., listening to) the service thing. Thereafter, the synchronization unit 513 will receive update notifications from the in-vehicle core unit 512 whenever there is a change in the service thing on the in-vehicle DB 511.

[0126] Furthermore, in S62, the synchronization unit 513 requests the cloud core unit 212 of cloud 2 to start subscribing to a service thing that targets the vehicle's Mobicon 5 as the target device. Thereafter, the synchronization unit 513 will receive update notifications from the cloud core unit 212 whenever there is a change in the service thing on the cloud DB 211.

[0127] When the orchestrator 514 starts up in conjunction with the ignition of its own vehicle, it requests the onboard core unit 512 to start subscribing to the service thing in S63. Thereafter, the orchestrator 514 will receive update notifications from the onboard core unit 512 whenever there is a change in the service thing on the onboard DB 511.

[0128] When the dashboard 71 receives an installation instruction for a vehicle service specifying a device in S64, it writes the installation instruction to the desire of the service thing of the specified device via the cloud core unit 212 in S65. The installation instruction is made by writing an RS object with the vehicle service information to be installed to desire. For example, if the RS object is in a state where no vehicle service information is written, as shown in the upper part of Figure 16, and then the writing shown in the lower part of Figure 16 is made, it means that the installation of the vehicle service identified as service1 has been instructed.

[0129] In S66, when the cloud core unit 212 detects a change in the service thing on the cloud DB 211 due to the writing of an installation instruction by the dashboard 71, it sends a change notification to the synchronization unit 513 of the target device. Note that the change notification may only send the changed part of the RS object.

[0130] In S67, the synchronization unit 513 updates the RS object of service thing on the in-vehicle DB 511 via the in-vehicle core unit 512 according to the content of the change notification received from the cloud core unit 212, and in S68, it sends the change notification to the orchestrator 514.

[0131] Upon receiving the change notification, the orchestrator 514 performs the installation of the vehicle services in S69 according to the installation instructions provided in the change notification. The process in S69 includes determining whether installation is necessary by comparing the RS object with the S object. The process in S69 also includes downloading the container and manifest of the vehicle services to be installed from the repository 23 in Cloud 2. Furthermore, the process in S69 includes writing the installation status, any errors during download or installation, etc., to the S object. A detailed explanation of the process in S69 is omitted.

[0132] In S70, the orchestrator 514 writes RS objects and S objects to the service thing on the in-vehicle DB 511 using report, as shown in Figure 17. The RS objects and S objects written reflect the vehicle service information and status information of the vehicle service installed in S69. Part of the contents of the S object are copied from the vehicle service information shown in the RS object and the information shown in the manifest.

[0133] In S71, when the in-vehicle core unit 512 detects a change in the service thing on the in-vehicle DB 511 due to a write from the orchestrator 514, it sends a change notification to the synchronization unit 513.

[0134] In step S72, the synchronization unit 513 sends a change notification to the cloud core unit 212. The cloud core unit 212 updates the contents of the service thing on the cloud DB 211 according to the change notification received from the synchronization unit 513.

[0135] If the synchronization unit 513 determines from the changes indicated in the change notification that a new vehicle service has been installed, it requests the in-vehicle core unit 512 to generate an operation thing in S73. The operation thing is used to operate the vehicle service added by the installation (hereinafter referred to as the additional service), and contains information about the vehicle service. In addition, in S74, the synchronization unit 513 requests the cloud core unit 212 to generate an operation thing for operating the additional service.

[0136] The in-vehicle core unit 512 generates operation things on the in-vehicle DB 511 in response to requests from the synchronization unit 513. The cloud core unit 212 generates operation things on the cloud DB 211 in response to requests from the synchronization unit 513. As a result, memory areas are secured in both the in-vehicle DB 511 and the cloud DB 211 for writing desires, reports, jobs, etc., for the added vehicle services.

[0137] In S75, the synchronization unit 513 requests the in-vehicle core unit 512 to start subscribing to a newly generated operation thing on the in-vehicle DB 511, and in S76, it requests the cloud core unit 212 to start subscribing to a newly generated operation thing on the cloud DB 211.

[0138] Thereafter, if there is a change in the content of the operation thing on the cloud DB 211 or the operation thing on the in-vehicle DB 511, a change notification is sent to the synchronization unit 513. Then, the synchronization unit 513's response to the change notification keeps the content of the operation thing on the cloud DB 211 and the operation thing on the in-vehicle DB 511 in a synchronized state.

[0139] In S77, the orchestrator 514 starts the added vehicle service according to the activation conditions indicated in the S object.

[0140] [2-2-2. Operation using the control thing] The operation using the added vehicle service control thing will be explained according to the sequence diagram shown in Figure 12.

[0141] This section describes the procedure for when the activated vehicle service provides any kind of information.

[0142] In S81, the vehicle service writes the status of the vehicle service to the report of the operation thing on the in-vehicle DB511.

[0143] When the in-vehicle core unit 512 detects a change in the operation item on the in-vehicle DB 511 due to writing a vehicle service, it sends a change notification to the synchronization unit 513 in S82.

[0144] In S83, the synchronization unit 513 updates the contents of the operation thing on the cloud DB 211 via the cloud core unit 212 in accordance with the change notification received from the in-vehicle core unit 512. As a result, the operation thing on the cloud DB 211 becomes synchronized with the operation thing on the in-vehicle DB 511.

[0145] A user utilizing the data from the digital twin system 1 inputs an instruction on the dashboard 71 screen to display the vehicle service status on the screen. Then, in S84, the dashboard 71 retrieves a vehicle service report from the cloud DB 211 via the cloud core unit 212 and displays the contents of the retrieved report on the screen.

[0146] Next, we will explain the procedure for making a request to the vehicle service from Cloud 2 using "desire".

[0147] The user enters a request for a specified vehicle service on the dashboard 71 screen. Then, in S85, the dashboard 71 writes the entered request to the desire of the specified vehicle service operation thing on the cloud DB 211 via the cloud core unit 212.

[0148] In S86, when the cloud core unit 212 detects a change in the operation thing on the cloud DB 211, it sends a change notification indicating the change to the synchronization unit 513 of the Mobicon 5 on which the specified vehicle service is installed.

[0149] In S87, the synchronization unit 513 updates the operation thing for the target vehicle service on the in-vehicle DB 511 via the in-vehicle core unit 512 according to the content of the change notification received from the cloud core unit 212. As a result, the operation thing on the in-vehicle DB 511 becomes synchronized with the operation thing on the cloud DB 211. In other words, the desire of the operation thing on the in-vehicle DB 511 indicates a request for the vehicle service.

[0150] In S88, the vehicle service obtains the desire for the operation thing on the in-vehicle DB511. The vehicle service may obtain the desire periodically, for example. In S89, the vehicle service executes the requested processing according to the content of the obtained desire.

[0151] Next, we will explain the procedure for making a request to the vehicle service from Cloud 2 using a job.

[0152] The user enters a job-format request for a specified vehicle service on the dashboard 71 screen. Then, in S90, the dashboard 71 writes the entered request as a job to the operation thing for the specified vehicle service on the cloud DB 211.

[0153] The processing in S92 and S93 is the same as the processing in S86 and S87. Therefore, as a result of the processing in S92 and S93, the operation thing on the in-vehicle DB 511 becomes synchronized with the operation thing on the cloud DB 211. In other words, the job of the operation thing on the in-vehicle DB 511 will have a request for vehicle services.

[0154] In S93, the vehicle service obtains a job for an operation thing on the in-vehicle DB 511. The vehicle service may obtain jobs periodically, for example, in the same way as obtaining desires. In S94, the vehicle service executes the requested processing according to the contents of the obtained job.

[0155] Furthermore, information such as the results of processes requested using desire and job and executed by the vehicle service is notified to the user via the dashboard 71 according to the procedures S81 to S84 described above.

[0156] [2-2-3. Uninstall Instructions] The procedure when an uninstall instruction is received on the dashboard 71 will be explained according to the sequence diagram shown in Figure 13. However, for S61-S63, S66-S68, S71-S72, and S74-S75, there are some differences in the information transmitted, but basically it is the same as the operation when an installation instruction is received as explained in Figure 11. Below, the explanation will focus on S64A, S65A, S69A, S70A, S73A, S76A, and S77A, which are executed instead of S64, S65, S69, S70, S73, S76, and S77.

[0157] When the dashboard 71 receives an uninstallation instruction for a vehicle service specifying a device in S64A, it writes the uninstallation instruction to the desire of the service thing for the specified device via the cloud core unit 212 in S65A. For example, as shown in the upper part of Figure 18, the status information of vehicle services identified as vehicle-service-B and vehicle-service-C is listed in the S object, and as shown in the lower part of Figure 18, the status information of the vehicle service identified as vehicle-service-B is rewritten to null in the S object and written to desire. In this case, it means that the uninstallation of the vehicle service identified as vehicle-service-B has been instructed.

[0158] In steps S66-S68, a change notification indicating an uninstallation instruction is sent to the orchestrator 514.

[0159] In S69A, the orchestrator 514 uninstalls the vehicle service in accordance with the uninstallation instructions provided in the change notification. Details of the uninstallation process are omitted.

[0160] In S70A, the orchestrator 514 deletes information related to the uninstalled vehicle service from the service thing on the in-vehicle DB 511 via the in-vehicle core unit 512. Specifically, it writes the S object, service thing, from which the uninstalled vehicle service item (i.e., "vehicle-service-B" : null shown in the lower part of Figure 18) has been deleted, to the report.

[0161] Steps S71 to S72 synchronize the contents of the uninstalled S-objects written to the in-vehicle DB 511 with the cloud DB 211.

[0162] If the synchronization unit 513 determines from the changes indicated in the change notification that the vehicle service has been uninstalled, it requests the in-vehicle core unit 512 to delete the operation thing in S73A. The operation thing to be deleted is the operation thing that was prepared on the in-vehicle DB 511 to operate the vehicle service that was deleted by uninstallation. Also, in S74A, the synchronization unit 513 requests the cloud core unit 212 to delete the operation thing that was prepared on the cloud DB 211 to operate the deleted vehicle service.

[0163] In S75A, the synchronization unit 513 requests the in-vehicle core unit 512 to unsubscribe from the operation thing that has been deleted from the in-vehicle DB 511, and in S76A, it requests the cloud core unit 212 to unsubscribe from the operation thing that has been deleted from the cloud DB 211.

[0164] [2-3. Correspondence of Terms] In this embodiment, the operation thing corresponds to component data used to describe information about additional services of the present disclosure. In this embodiment, a change notification from the in-vehicle core unit 512 to the synchronization unit 513 corresponds to the first change notification of the present disclosure, and a change notification from the cloud core unit 212 to the synchronization unit 513 corresponds to the second change notification of the present disclosure. In this embodiment, sending a subscription request for the operation thing to the in-vehicle core unit 512 and the cloud core unit 212 corresponds to setting up to receive the first and second change notifications of the present disclosure. In this embodiment, the S object corresponds to the service list of the present disclosure.

[0165] [2-4. Effects] The second embodiment described in detail above provides the effects (1a) to (1d) of the first embodiment described above, and further provides the following effects.

[0166] (2a) In the digital twin system 1a, when a vehicle service is installed on the Mobicon 5, an operating thing is automatically generated to operate the vehicle service added by the installation. Therefore, after the installation of the vehicle service, it becomes possible to operate the vehicle service using the operating thing without requiring any special operation, thereby improving the convenience for users of the vehicle service.

[0167] [3. Third Embodiment] [3-1. Differences from the Second Embodiment] The third embodiment has the same basic configuration as the second embodiment, so the differences will be explained below. Note that the same reference numerals as in the first and second embodiments indicate the same components, and refer to the preceding description.

[0168] In the second embodiment, when a vehicle service is installed, an operation thing is automatically generated. The third embodiment differs from the second embodiment in that whether or not to generate an operation thing for the installed vehicle service is determined from the information in the manifest.

[0169] As shown in Figure 14, the manifest includes an ID, version, activation conditions, and synchronization requirements. The ID is identification information to indicate the vehicle service to which the manifest contents apply. The version indicates the version of the manifest. The activation conditions are the activation conditions for the vehicle service to which it applies. The synchronization disabling information indicates whether or not synchronization with cloud 2a is disabled for the vehicle service to which it applies. Specifically, if the synchronization disabling information is True, it indicates that synchronization with the cloud is disabled, i.e., the generation of an operation thing is unnecessary. If the synchronization disabling information is false, it indicates that synchronization with the cloud is enabled, i.e., the generation of an operation thing is necessary.

[0170] [3-2. Post-Installation Procedures] The post-installation procedures for the vehicle service will be explained in accordance with the sequence diagram shown in Figure 15.

[0171] Furthermore, when installing the vehicle service in S69, the orchestrator 514 retrieves the manifest along with the vehicle service container from the repository 23 in cloud 2 and saves the retrieved manifest.

[0172] In S70B, the orchestrator 514 uses desire to write an S object to the service thing on the in-vehicle DB 511, which contains the status information of the vehicle service installed in S69 and the synchronization failure information indicated in the manifest.

[0173] Steps S71 to S72 synchronize the contents of the S object written to the in-vehicle DB 511 with the cloud DB 211.

[0174] If the synchronization information written to the S object is true, the synchronization unit 513 determines in S101 that it is unnecessary to generate an operation thing.

[0175] The synchronization unit 513 determines that it is necessary to generate an operation thing if the non-synchronization information written to the S object is false, and in steps S73 to S76, it starts generating the operation thing and subscribing to the generated operation thing.

[0176] [3-3. Effects] The third embodiment described in detail above provides the effects (1a) to (1d) of the first embodiment described above, and further provides the following effects.

[0177] (3a) In the digital twin system 1a of this embodiment, when a vehicle service is installed on the Mobicon 5a, the necessity of generating an operation thing to be used for the installed vehicle service is determined according to the non-synchronization information described in the manifest. Therefore, after the installation of the vehicle service, it is possible to operate the vehicle service using the operation thing without requiring any special operation, and it is also possible to suppress the unnecessary generation of operation things for vehicle services that do not require an operation thing.

[0178] [4. 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.

[0179] (4a) In the above embodiment, the vehicle-side unit 51 is mounted on the Mobicon 5, but for example, it may be mounted on an aftermarket in-vehicle device separate from the Mobicon 5.

[0180] (4b) In the above embodiment, the ECU group 4 includes a zone ECU 41 provided for each zone, but instead of the zone ECU 41, it may include a domain ECU provided for each domain.

[0181] (4c) In the above embodiment, in order to restore the persistence setting-related thing to its state immediately before power off when the power is turned off and the system is restarted, the persistence setting-related thing is stored in a non-volatile area. For example, all things may be stored in a volatile area and operations may be performed on the volatile area. In this case, for the persistence setting-related thing, as shown in S52 and S53 of Figure 8, backup data may be written to the non-volatile area each time a write is made to the thing. In this case, as shown in S51 of Figure 8, at startup, all things may be generated in an initialized state in the volatile area, and then the values ​​of the persistence setting-related thing may be restored using the backup data stored in the non-volatile area.

[0182] (4d) In the second embodiment described above, the orchestrator 514 is configured to execute installation-related processing using RS objects synchronized between the cloud DB 211 and the in-vehicle DB 511 using the functions of the synchronization unit 513. Instructions for installation-related processing to the orchestrator 514 may be given, for example, using the job or desire functions of the service thing, or by another mechanism without using the functions of the synchronization unit 513.

[0183] (4e) The cloud-side unit 21 and the vehicle-side unit 51 described in this disclosure, and the methods implemented therein, 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 cloud-side unit 21 and the vehicle-side unit 51 described in this disclosure, and the methods implemented therein, may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the cloud-side unit 21 and the vehicle-side unit 51 described in this disclosure, and the methods implemented therein, 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 on a computer-readable non-transitional tangible recording medium as instructions to be executed by the computer. The methods for realizing the functions of each part included in the cloud-side unit 21 and the vehicle-side unit 51 do not necessarily need to include software, and all of the functions may be realized using one or more hardware components.

[0184] (4f) 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. Also, at least some of the configuration of the above embodiment may be added to or replaced with the configuration of other above embodiments.

[0185] (4g) In addition to the digital twin systems 1, 1a and the clouds 2, 2a and in-vehicle systems 3, 3a which are components of the digital twin systems 1, 1a described above, the disclosure can also be implemented in various forms, such as a program for causing a computer to function as the cloud-side unit 21 and the in-vehicle-side unit 51, a non-transitional physical recording medium such as a semiconductor memory on which this program is recorded, and a data synchronization method.

[0186] [5. Technical Concept Disclosed in This Specification] [Item 1] An in-vehicle terminal configured to communicate with an external device having a cloud database (211) that stores at least a request list which is a list of vehicle services to be installed in the vehicle, the terminal being configured to communicate with the external device via a communication unit (6), and further comprising: an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by detecting a change in the component data stored in the in-vehicle database, uploading the component data whose change has been detected to the cloud database, and detecting a change in the component data stored in the cloud database, downloading the component data whose change has been detected to the in-vehicle database; and an orchestrator (514) configured to execute the installation of the vehicle services. An in-vehicle terminal comprising the synchronization unit, wherein when the orchestrator newly installs the vehicle service, the synchronization unit generates component data used to describe information about the additional service, which is the vehicle service added by the installation, and is configured to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed, using the component data of the additional service as the target component data.

[0187] [Item 2] An in-vehicle terminal as described in Item 1, wherein the orchestrator is configured to write status information representing the status of the additional service to a service list, which is a list of vehicle services installed on the in-vehicle terminal and stored in the in-vehicle database, after the installation of the additional service is complete but before the additional service is started.

[0188] [Item 3] An in-vehicle terminal as described in Item 2, wherein the status information includes identification information, version, startup conditions, and installation status for the corresponding vehicle service.

[0189] [Item 4] An in-vehicle terminal as described in Item 3, wherein the synchronization unit refers to the identification information of the status information described in the service list to determine whether or not there is an additional service that requires the generation of the component data.

[0190] [Item 5] An in-vehicle terminal as described in any one of Items 2 to 4, wherein the orchestrator, when the vehicle service installed on the in-vehicle terminal is uninstalled, makes a change to the service list to indicate the deleted service which is the uninstalled vehicle service, and the synchronization unit is configured to identify the deleted service from the change in the service list, delete the component data associated with the deleted service, and to cancel the settings for receiving the first change notification and the second change notification for the deleted component data.

[0191] [Item 6] An in-vehicle terminal according to any one of Items 1 to 5, wherein the orchestrator is configured to obtain a manifest containing synchronization information indicating whether or not synchronization of information regarding the vehicle service using the component data is necessary with the external device, along with the program for the vehicle service, and to notify the synchronization unit of the synchronization information for the installed vehicle service, and the synchronization unit is configured to determine whether or not it is necessary to generate the target component data according to the synchronization information.

[0192] [Item 7] An in-vehicle terminal according to any one of items 1 to 6, wherein the orchestrator is configured to perform the installation of the vehicle service according to a request list that is written to the cloud database and downloaded as component data from the cloud database to the in-vehicle database by the synchronization unit.

[0193] [Item 8] The vehicle comprises an external device (2a) provided outside the vehicle, and an in-vehicle terminal (5a) mounted on the vehicle, wherein the external device includes a cloud database (211) that stores at least a request list which is a list of vehicle services to be installed on the vehicle, the in-vehicle terminal is configured to communicate with the external device via a communication unit (6), and further includes an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components, a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by detecting a change in the component data stored in the in-vehicle database and uploading the changed component data to the cloud database, and detecting a change in the component data stored in the cloud database and downloading the changed component data to the in-vehicle database, and an orchestrator (514) configured to execute the installation of the vehicle services. A data synchronization system comprising the synchronization unit, wherein when the orchestrator newly installs the vehicle service, the synchronization unit generates component data used to describe information about the additional service, which is the vehicle service added by the installation, and sets up the system to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed, using the component data of the additional service as the target component data.

[0194] [Item 9] A synchronization system comprising: a cloud database (211) provided on an external device (2a) located outside the vehicle and storing at least a request list which is a list of vehicle services to be installed on the vehicle; and an in-vehicle database (511) provided on an in-vehicle terminal (5a) mounted on the vehicle and communicating with the external device via a communication unit (6), each configured to store a plurality of component data associated with any of the in-vehicle components, wherein the contents of the cloud database and the contents of the in-vehicle database are synchronized by: when a change in the component data stored in the in-vehicle database is detected, uploading the component data whose change has been detected to the cloud database; when a change in the component data stored in the cloud database is detected, downloading the component data whose change has been detected to the in-vehicle database, thereby synchronizing the contents of the in-vehicle database and the contents of the cloud database; and when a new vehicle service is installed on the vehicle, generating the component data used to describe information about the additional service which is the vehicle service added by the installation on the in-vehicle database and the cloud database. A data synchronization method comprising setting up the system to receive a first change notification indicating that the target component data in the in-vehicle database has been changed, and a second change notification indicating that the target component data in the cloud database has been changed, using the component data of the additional service as target component data, and synchronizing the target component data in the in-vehicle database and the target component data in the cloud database in accordance with the first change notification and the second change notification.

[0195] [Item 10] A program that causes a computer in an in-vehicle terminal configured to communicate with an external device having a cloud database (211) that stores at least a request list which is a list of vehicle services to be installed in the vehicle, to function as: an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by uploading the component data that has been changed to the cloud database when it detects a change in the component data stored in the in-vehicle database, and downloading the component data that has been changed to the in-vehicle database when it detects a change in the component data stored in the cloud database; and an orchestrator (514) configured to execute the installation of the vehicle services, The synchronization unit is configured to generate component data used to describe information about the additional service, which is the vehicle service added by the installation, when the orchestrator newly installs the vehicle service, and to configure the system to receive a first change notification indicating that the target component data in the in-vehicle database has been changed, and a second change notification indicating that the target component data in the cloud database has been changed, using the component data of the additional service as the target component data.

Claims

1. An in-vehicle terminal configured to communicate with an external device having a cloud database (211) that stores at least a request list which is a list of vehicle services to be installed in the vehicle, the terminal being configured to communicate with the external device via a communication unit (6), and further comprising: an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by uploading the component data that has been changed to the cloud database when a change in the component data stored in the in-vehicle database is detected, and downloading the component data that has been changed to the in-vehicle database when a change in the component data stored in the cloud database is detected; and an orchestrator (514) configured to execute the installation of the vehicle services. An in-vehicle terminal comprising the synchronization unit, wherein when the orchestrator newly installs the vehicle service, the synchronization unit generates component data used to describe information about the additional service, which is the vehicle service added by the installation, and is configured to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed, using the component data of the additional service as the target component data.

2. An in-vehicle terminal according to claim 1, wherein the orchestrator is configured to write status information representing the status of the additional service to a service list, which is a list of vehicle services installed on the in-vehicle terminal and stored in the in-vehicle database, after the installation of the additional service is complete but before the additional service is started.

3. An in-vehicle terminal according to claim 2, wherein the status information includes identification information, version, startup conditions, and installation status for the corresponding vehicle service.

4. An in-vehicle terminal according to claim 3, wherein the synchronization unit refers to the identification information of the status information described in the service list to determine whether or not there is an additional service that requires the generation of the component data.

5. An in-vehicle terminal according to claim 2, wherein the orchestrator, when the vehicle service installed on the in-vehicle terminal is uninstalled, makes a change to the service list to indicate the deleted service which is the uninstalled vehicle service, and the synchronization unit is configured to identify the deleted service from the change in the service list, delete the component data associated with the deleted service, and cancel the settings for receiving the first change notification and the second change notification for the deleted component data.

6. An in-vehicle terminal according to claim 1, wherein the orchestrator is configured to obtain a manifest containing synchronization information indicating whether or not synchronization of information regarding the vehicle service using the component data is necessary with the external device, along with the program for the vehicle service, and to notify the synchronization unit of the synchronization information for the installed vehicle service, and the synchronization unit is configured to determine whether or not it is necessary to generate the target component data according to the synchronization information.

7. An in-vehicle terminal according to claim 1, wherein the orchestrator is configured to perform the installation of the vehicle service according to a request list which is written to the cloud database and downloaded as component data from the cloud database to the in-vehicle database by the synchronization unit.

8. The vehicle comprises an external device (2a) provided outside the vehicle, and an in-vehicle terminal (5a) mounted on the vehicle, wherein the external device includes a cloud database (211) that stores at least a request list which is a list of vehicle services to be installed on the vehicle, the in-vehicle terminal is configured to communicate with the external device via a communication unit (6), and further includes an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components, a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by detecting a change in the component data stored in the in-vehicle database and uploading the changed component data to the cloud database, and detecting a change in the component data stored in the cloud database and downloading the changed component data to the in-vehicle database, and an orchestrator (514) configured to execute the installation of the vehicle services. A data synchronization system comprising the synchronization unit, wherein when the orchestrator newly installs the vehicle service, the synchronization unit generates component data used to describe information about the additional service, which is the vehicle service added by the installation, and sets up the system to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed, using the component data of the additional service as the target component data.

9. A synchronization system comprising: a cloud database (211) provided on an external device (2a) located outside the vehicle and storing at least a request list which is a list of vehicle services to be installed on the vehicle; and an in-vehicle database (511) provided on an in-vehicle terminal (5a) mounted on the vehicle and communicating with the external device via a communication unit (6), each configured to store a plurality of component data associated with any of the in-vehicle components, wherein the contents of the cloud database and the contents of the in-vehicle database are synchronized by: when a change in the component data stored in the in-vehicle database is detected, uploading the component data whose change has been detected to the cloud database; when a change in the component data stored in the cloud database is detected, downloading the component data whose change has been detected to the in-vehicle database; and when a new vehicle service is installed on the vehicle, generating component data to be used to describe information about the additional service which is the vehicle service added by the installation. A data synchronization method comprising setting up the system to receive a first change notification indicating that the target component data in the in-vehicle database has been changed, and a second change notification indicating that the target component data in the cloud database has been changed, using the component data of the additional service as target component data, and synchronizing the target component data in the in-vehicle database and the target component data in the cloud database in accordance with the first change notification and the second change notification.

10. A data synchronization method for an in-vehicle terminal configured to communicate with an external device having a cloud database (211) that stores at least a request list, which is a list of vehicle services to be installed in the vehicle, wherein the contents of an in-vehicle database (511), each configured to store a plurality of component data associated with any of the in-vehicle components, are synchronized with the contents of the cloud database, wherein when a change in the component data stored in the in-vehicle database is detected, the component data whose change has been detected is uploaded to the cloud database, and when a change in the component data stored in the cloud database is detected, the component data whose change has been detected is downloaded to the in-vehicle database, thereby synchronizing the contents of the in-vehicle database and the contents of the cloud database, wherein when a new vehicle service is installed in the vehicle, component data is generated to be used to describe information about the additional service, which is the vehicle service added by the installation, and the component data of the additional service is set as the target component data, and settings are made to receive a first change notification indicating that the target component data on the in-vehicle database has been changed, and a second change notification indicating that the target component data on the cloud database has been changed. A data synchronization method for synchronizing the target component data on the in-vehicle database with the target component data on the cloud database in accordance with the first change notification and the second change notification.

11. A program that causes a computer in an in-vehicle terminal configured to communicate with an external device having a cloud database (211) that stores at least a request list, which is a list of vehicle services to be installed in the vehicle, to function as: an in-vehicle database (511) each configured to store a plurality of component data associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database and the contents of the cloud database by uploading the component data that has been changed to the cloud database when it detects a change in the component data stored in the in-vehicle database, and downloading the component data that has been changed to the in-vehicle database when it detects a change in the component data stored in the cloud database; and an orchestrator (514) configured to execute the installation of the vehicle services, The synchronization unit is configured to generate component data used to describe information about the additional service, which is the vehicle service added by the installation, when the orchestrator newly installs the vehicle service, and to configure the system to receive a first change notification indicating that the target component data in the in-vehicle database has been changed, and a second change notification indicating that the target component data in the cloud database has been changed, using the component data of the additional service as the target component data.

Images