Data synchronization system, in-vehicle terminal, and program

Abstract

In the present invention, an external device includes a cloud database that stores at least a request list that is a list of vehicle services to be installed in the vehicle. The in-vehicle terminal comprises an in-vehicle database, a synchronization unit, and an orchestrator. The synchronization unit synchronizes stored contents of the in-vehicle database or the cloud database. The orchestrator executes installation, update, and uninstallation of the vehicle service according to the request list downloaded from the cloud database to the in-vehicle database by the synchronization unit.

Description

Data synchronization system, in-vehicle terminal, and program Cross-Reference to Related Applications

[0001] This international application claims the benefit of Japanese Patent Application No. 2025-040573 filed with the Japan Patent Office on March 13, 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] International Publication No. 2024 / 143007

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

[0006] Since the cloud directly requests a device to install a vehicle service, if the request execution fails due to a communication failure, an error during request processing, or the like, there is a problem that the cloud needs to repeatedly transmit the same instruction.

[0007] One aspect of the present disclosure provides a technology that enables efficient processing of instructions from a cloud on the vehicle side.

[0008] One aspect of this disclosure is a data synchronization system. It 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. 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 installation, updating, and uninstallation of vehicle services according to the request list. The request list is written to a cloud database, and then downloaded as component data from the cloud database to the in-vehicle database by the synchronization unit.

[0009] With this configuration, the cloud side can, regardless of the status of the in-vehicle terminal, simply update the request list in the cloud database, causing the orchestrator on the in-vehicle terminal to perform installation, updates, and uninstallation of vehicle services.

[0010] 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 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 install, update, and uninstall vehicle services according to the request list. The request list is written to the cloud database and downloaded from the cloud database to the in-vehicle database as component data by the synchronization unit.

[0011] With this configuration, it can be used as an in-vehicle terminal constituting a data synchronization system, which is one aspect of this disclosure.

[0012] One aspect of this disclosure is a program that causes a computer in an in-vehicle terminal to function as an in-vehicle database, a synchronization unit, and an orchestrator. The in-vehicle terminal is 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 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 install, update, and uninstall vehicle services according to the request list. The request list is written to the cloud database and downloaded from the cloud database to the in-vehicle database as component data by the synchronization unit.

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

[0014] 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 the RS module and S module of the device thing that manages vehicle services. This is an explanatory diagram illustrating the screen displayed by the dashboard. This is an explanatory diagram illustrating the screen displayed by the dashboard. This is a sequence diagram showing the procedure for installing vehicle services. This is an explanatory diagram illustrating the contents written to desire and report. This is a sequence diagram showing the procedure for uninstalling vehicle services. This is a sequence diagram showing the procedure for installing vehicle services when a device is added to a device group, and when a device is removed from a device group. This is a sequence diagram showing the procedure when vehicle service installation fails. This is an explanatory diagram showing the procedure for retrying vehicle service installation using job. This is an explanatory diagram showing the procedure for updating installed vehicle services.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0028] 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."

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

[0030] A "thing" is a collection of items similar to a folder, and is provided for each virtual group unit such as CarA, EcuA, AppA, etc. In the following, 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.

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

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

[0033] 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).

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

[0035] Furthermore, for example, if an external system instructs a target application to upload data from a vehicle to Cloud 2, the data to be uploaded can be written to the `desire` field of the shadow that handles the update status of vehicle data within the `thing` that treats the vehicle as a target component. In this case, multiple data items such as `[GPS coordinates, vehicle speed]` or `[steering angle, vehicle speed]` can be listed and written to `desire`. Alternatively, a data collection condition table listing the data collection conditions can be written to the `desire` field of the shadow that handles the update status of vehicle data.

[0036] In addition to using `desire`, another method is available for having the target application execute processes related to the target component. Jobs are generally downloaded from Cloud 2.

[0037] Desire is primarily used in simple, error-free, and mediation-free cases, such as when an external party instructs an application to upload specific data.

[0038] A "job" is primarily used in cases where you want to instruct an action rather than just a state, such as "update app A," "open the trunk," or "the system execute the specified command." The instructions can be written in any text format, and should be understandable to both the sender and receiver. Similar to a "desire," a "job" may also include a list of data to be uploaded or a data collection condition table for the data to be uploaded.

[0039] The data collection conditions table may also be embedded in the target application. In this case, the data collection conditions table is installed via OTA along with the target application. In other words, when the target application is updated, the data collection conditions table is also updated. OTA stands for Over the Air, indicating that the installation is done wirelessly.

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

[0041] In a thing, the progress of a job is managed by the job state. The target application executes the instruction content written in the job while rewriting the job state.

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

[0043] When the target application receives the job and starts work, the job state is rewritten to IN_PROGRESS, which indicates that work is in progress. Note that the job state may display a numerical value of 0-100% representing the progress of work instead of or together with IN_PROGRESS.

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

[0045] Note that as the job state, CANCELED, FAILED, REJECTED, etc., which are states used when an error or work failure occurs, may be used. Furthermore, any error message specified by a character string may be used.

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

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

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

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

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

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

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

[0053] The DS area A1, VSS area A2, cache area A3, and application-specific area A4 are generally set as volatile areas. However, if they contain data that needs to be reproduced after the power is turned off and the system is restarted, some or all of areas A1 to A4 may be set as non-volatile areas.

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

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

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

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

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

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

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

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

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

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

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

[0065] [1-3-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.

[0066] 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, thing:appA / desire). Also, in S12 and S13, the synchronization unit 513 sends a request to start a subscription, specifying thing:appA as the specified item and all items as specified items (hereinafter, thing:appA), to the in-vehicle core unit 512 and the cloud core unit 212, respectively.

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

[0068] Subsequently, in S14, a user who wants to use application A writes `config=newValue` to `desire` (hereinafter referred to as `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.

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

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

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

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

[0073] [1-3-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.

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

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

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

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

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

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

[0080] [1-3-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.

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

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

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

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

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

[0086] [1-3-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.

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

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

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

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

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

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

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

[0094] In other words, history updates are performed, and all data that occurred while the system was offline and stored in cache area A3 can be reflected in cloud DB211.

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

[0096] (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.

[0097] (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.

[0098] (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.

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

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

[0101] (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, and the contents of both 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.

[0102] (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.

[0103] (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.

[0104] (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.

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

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

[0107] 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 and files. Application programs and the like (hereinafter referred to as containers) for realizing vehicle services provided to vehicles are stored here.

[0108] Furthermore, the cloud DB 211 provides a thing (hereinafter referred to as a device thing) for managing the vehicle services provided for each MobiCon (hereinafter also referred to as a device) 5a installed in each vehicle. The device thing is used to operate the orchestrator 514, which will be described later. As shown in Figure 10, the device thing includes a requested service object (hereinafter referred to as an RS object) and a service object (hereinafter referred to as an 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 device thing of interest will be referred to as the target device.

[0109] The RS object contains 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 is the path that 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.

[0110] The S object contains a list of information regarding the status of vehicle services on the target device (hereinafter referred to as "status information").

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

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

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

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

[0115] As shown in the upper part of Figure 11, the dashboard 71 displays a first screen SC1 showing a list of device groups DG1, DG2, ... and provides a function to select the device group DG to be worked on. The display of the first screen SC1 may include comments related to the device group DG.

[0116] When device group DG is selected, the dashboard 71 displays a second screen SC2. As shown in the lower part of Figure 11, the second screen SC2 displays a list of vehicle services SV1, SV2, ... that can be installed on devices belonging to the selected device group. The dashboard 71 provides a function to select the vehicle service SV to be worked on using the second screen SC2. The list of vehicle services may display information such as the service name of the vehicle service, the version of the vehicle service, comments related to the vehicle service, the number of devices to be installed on, and the number of devices on which it has already been installed.

[0117] When a vehicle service SV is selected, the dashboard 71 displays a third screen SC3. As shown in the upper part of Figure 12, the third screen SC3 displays icons for entering installation or uninstallation instructions, and a list of vehicle service versions to be installed. The dashboard 71 provides a function to select the vehicle service version to be worked on and to instruct the work to be performed using the third screen SC3.

[0118] Furthermore, when the user inputs a command to obtain the installation status by specifying the device group DG and vehicle service SV on the dashboard 71, the fourth screen SC4 is displayed. As shown in the lower part of Figure 12, the fourth screen SC4 displays a list of information (hereinafter referred to as "installation information") such as the installation status of the specified vehicle service (hereinafter referred to as "target vehicle service") for each device belonging to the specified device group. The installation information includes information that identifies the device, the version of the target vehicle service, and the installation status of the target vehicle service.

[0119] On the fourth screen, SC4, if information about a vehicle service that failed to be installed or uninstalled is displayed, a message prompting the user to retry the failed operation will be shown on the screen. On this screen, the retry operation button will be enabled, and when the button is pressed, an instruction prompting the user to retry the specified operation will be sent via Cloud 2 to the device to be retried.

[0120] Returning to Figure 9, 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.

[0121] The orchestrator 514 executes installation-related processes according to the contents of the device thing of the target device, which are synchronized between the cloud DB 211 and the in-vehicle DB 511 of the target device.

[0122] [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 13. However, in the following, the in-vehicle DB 511, the in-vehicle core unit 512, and the synchronization unit 513 are collectively referred to as the device core unit DU. In Figure 13, for the sake of clarity, the operation within the device core unit DU and the cloud-side unit 21 will be omitted from the explanation.

[0123] In S61, the dashboard 71 receives installation instructions for a specified vehicle service SV in a specified device group DG via the first to third screens SC1 to SC3.

[0124] In S62, the dashboard 71 identifies the devices belonging to the specified device group and executes the processes described in S63 to S78 below for each of the identified devices (hereinafter referred to as target devices).

[0125] In S63, when the device core unit DU detects that the vehicle's ignition is turned on, in S64 it requests the cloud-side unit 21 to start subscribing to the desire of the target device thing (i.e., to listen to the desire). Thereafter, whenever there is a change in the desire of the device thing on the cloud DB 211, the device core unit DU will receive an update notification from the cloud-side unit 21.

[0126] When the orchestrator 514 starts up in conjunction with the vehicle's ignition being turned on, in S65 it requests the device core unit DU to start subscribing to the desire of device thing. Thereafter, the orchestrator 514 will receive update notifications from the device core unit DU whenever there is a change in the desire of device thing on the in-vehicle DB 511.

[0127] In S66, the dashboard 71 writes an installation instruction to the desire of the RS object belonging to the device thing of the target device. The installation instruction is written by writing information about the vehicle service to be installed. In the example shown in Figure 14, the installation of the vehicle service identified as Service1 is instructed.

[0128] Returning to Figure 13, at S67, when the cloud-side unit 21 detects a change in desire, it sends a change notification to the device core unit DU of the target device that is requesting a listen for desire. This change in desire occurs, for example, when the dashboard 71 writes an installation instruction to the RS object on the cloud DB 211. Note that the change notification only sends the changed part of the RS object.

[0129] In S68, the device core unit DU updates the desire RS object on the in-vehicle DB 511 according to the contents of the change notification received from the cloud-side unit 21, and sends the change notification to the orchestrator 514 that is requesting a listen for desire.

[0130] Upon receiving the change notification, the orchestrator 514 retrieves the entire RS object and the entire S object from the device core unit DU in S69.

[0131] In S70, the orchestrator 514 compares the acquired RS object with the S object to determine whether installation is necessary. For example, if a vehicle service listed in the RS object is indicated as not being installed in the S object, the orchestrator 514 determines that installation is necessary. If the orchestrator 514 determines that installation is necessary, the following processes S71 to S78 are executed.

[0132] In S71, the orchestrator 514 sends an instruction to the device core unit DU to write the installation status of the vehicle service to be installed (hereinafter referred to as the target vehicle service) to the report of the S object on the in-vehicle DB 511. Here, "Installing" is written as the installation status. If the information of the vehicle service to be installed does not exist in the S object, an area is created to write the information of the corresponding target vehicle service, and the installation status is written there.

[0133] In S72, when the device core unit DU detects a write to an S object, it notifies the cloud-side unit 21. Upon receiving the notification, the cloud-side unit 21 updates the contents of the S object on the cloud DB 211 with the information received. As a result, the contents of the S object on the cloud DB 211 and the contents of the S object on the in-vehicle DB 511 become synchronized.

[0134] In S73, the orchestrator 514 downloads the container for the target vehicle service from the repository 23 in Cloud 2.

[0135] In S74, the orchestrator 514 performs the installation of the downloaded container.

[0136] In S75, the orchestrator 514 writes the same content to the RS object's report as the desire shown in the change notification received in S68. In other words, the report indicates that the state of the device (i.e., Mobicon 5a) has changed to match the request from the cloud 2a as shown in the desire.

[0137] In S76, the orchestrator 514 sends an instruction to the device core unit DU to write "Installing" as the installation status of the target vehicle service to the report of the S object on the in-vehicle DB 511. The writes in S75 and S76 will be, for example, the content shown in " / / Report" in Figure 14.

[0138] In S77, when the device core unit DU detects a write to an S object, it notifies the cloud-side unit 21. Upon receiving the notification, the cloud-side unit 21 updates the contents of the S object on the cloud DB 211 with the information received. As a result, the contents of the S object on the cloud DB 211 and the contents of the S object on the in-vehicle DB 511 become synchronized.

[0139] In S78, the orchestrator 514 starts the vehicle service according to the startup conditions indicated in the S object.

[0140] When the dashboard 71 receives a command to obtain the installation status of vehicle services on the target device, it obtains information from the cloud DB via the cloud-side unit 21 at S79. The information to be obtained is the installation status of vehicle services on the target device, as indicated in the S object.

[0141] In S80, the dashboard 71 displays the acquired installation status using the fourth screen SC4 shown in Figure 12.

[0142] [2-2-2. Uninstall Instruction] The operation when an uninstall instruction is received by the dashboard 71 will be explained according to the sequence diagram shown in Figure 15. However, for S61 to S70, the operation is basically the same as when an installation instruction is received as explained in Figure 13. However, in S66, the dashboard 71 writes an uninstall instruction, not an installation instruction, to the desire RS object belonging to the device thing of the target device. An uninstall instruction is performed, for example, by writing a list of vehicle service information related to the vehicle service to be uninstalled to desire.

[0143] If the orchestrator 514 determines in S70 that uninstallation is necessary, the following processes S81 to S86 are executed. The orchestrator 514 determines that uninstallation is necessary, for example, if a vehicle service that is indicated as installed in the S object is not listed in the RS object.

[0144] In S81, the orchestrator 514 sends an instruction to the device core unit DU to write the installation status of the vehicle service to be uninstalled (hereinafter referred to as the target vehicle service) to the report of the S object on the in-vehicle DB 511. Here, "Uninstalling" is written as the installation status.

[0145] In step S82, when the device core unit DU detects a write operation to an S object on the in-vehicle DB 511, it notifies the cloud-side unit 21. Upon receiving the notification, the cloud-side unit 21 updates the contents of the S object on the cloud DB 211 according to the information received.

[0146] In S83, the orchestrator 514 performs the uninstallation of the target vehicle service.

[0147] In S84, the orchestrator 514 writes the same content as "desire" to the repot of the RS object.

[0148] In S85, the orchestrator 514 requests the device core unit DU to delete the information regarding the target vehicle service from the S object. For example, the deletion request is made by writing a list of installation information from which the information regarding the target vehicle service has been deleted to the report of the S object on the in-vehicle DB 511.

[0149] In S86, when the device core unit DU detects a change in the content of an S object, it notifies the cloud-side unit 21. Upon receiving the notification, the cloud-side unit 21 updates the content of the S object on the cloud DB 211 according to the notification, thereby synchronizing the content of the S object between the in-vehicle DB 511 and the cloud DB 211.

[0150] [2-2-3. Adding / Removing Devices] The actions taken when a new device is added to device group DG and when a device is removed from device group DG on dashboard 71 will be explained according to the sequence diagram shown in Figure 16.

[0151] When Dashboard 71 accepts the addition of a device to device group DG in S91, it generates a device thing for the added device on Cloud DB 211 in S92. The RS object used in device group DG to which the added device belongs is applied to this device thing.

[0152] The following describes how the device `thing` on the cloud DB 211 synchronizes with the in-vehicle DB 511 of the added device, resulting in the same operation as when the vehicle service installation instructions described in Figure 13 are written. As a result, the vehicle service indicated in the RS object is installed on the added device.

[0153] When Dashboard 71 receives a request to remove a device from device group DG in S93, it deletes the RS object from the device thing of the target device in Cloud DB 211 in S94.

[0154] The following operation occurs when the device "thing" on the cloud DB211 is synchronized with the vehicle DB511 of the device to be deleted, resulting in the same behavior as when the vehicle service uninstallation instruction described in Figure 15 is written. As a result, the vehicle service indicated in the deleted RS object is uninstalled on the target device.

[0155] [2-2-4. Errors during installation] The operation that occurs when an error occurs during the installation of vehicle services on the device will be explained according to the sequence diagram shown in Figure 17.

[0156] Figure 17 is executed instead of the processes S71-S78 that are performed in Figure 13 if installation is required.

[0157] Steps S71 to S73 are the same as in the case shown in Figure 13.

[0158] In S95, the orchestrator 514 determines that if the download of the target vehicle service fails, and there is a possibility of success with a retry, a download retry is necessary, and in S96, it attempts to download the target vehicle service again. The number of retries can be set arbitrarily. If there is no possibility of success even after retrying, the process proceeds to S97 without retrying in S96.

[0159] In S97, the orchestrator 514 determines that an error has been detected if the download retry also fails.

[0160] In S98, the orchestrator 514 sends an instruction to the device core unit DU to write "Installation Failed" as the installation status of the target vehicle service to the report of the S object on the in-vehicle DB 511.

[0161] In S99, when the device core unit DU detects a write to an S object, it notifies the cloud-side unit 21. Upon receiving the notification, the cloud-side unit 21 updates the contents of the S object on the cloud DB 211 with the information received. As a result, the contents of the S object on the cloud DB 211 and the contents of the S object on the in-vehicle DB 511 become synchronized.

[0162] When the installation of the vehicle service fails, the dashboard 71 retrieves the installation status, similar to S79 ​​and S80 as described in Figure 13, and displays the retrieved installation status. In this case, an error will be displayed on the fourth screen SC4.

[0163] [2-2-5. Retrying using job] The operation of retrying the installation of vehicle services by sending a message from the dashboard 71 to the orchestrator 514 using the job function will be explained according to the sequence diagram shown in Figure 18.

[0164] To enable the functionality of the job, the device core unit DU requests the cloud-side unit 21 at S101 to start subscribing to the job for the device thing of the target device (i.e., to listen to the job). Thereafter, the device core unit DU will receive update notifications from the cloud-side unit 21 whenever there is a change in the job for the device thing on the cloud DB 211.

[0165] Similarly, in S102, the orchestrator 514 requests the device core unit DU to start subscribing to the job for device thing. Thereafter, the orchestrator 514 will receive update notifications from the device core unit DU whenever there is a change in the job for device thing on the in-vehicle DB 511.

[0166] When the dashboard 71 receives a retry request for vehicle service installation in S103, it sends an instruction to the cloud-side unit 21 in S104 to write a retry instruction to the job of the device thing of the target device on the cloud DB 211. When the job is changed by the cloud-side unit 21 writing to the cloud DB 211, the cloud-side unit 21 sends a change notification to the device core unit DU of the target device that is requesting to listen for the job.

[0167] In S106, the device core unit DU updates the job on the in-vehicle DB 511 according to the contents of the change notification received from the cloud-side unit 21, and sends the change notification to the orchestrator 514 that is requesting the job to listen.

[0168] Upon receiving the change notification, the orchestrator 514 retryes the vehicle service installation in S107 according to the contents indicated in job. That is, it executes the processes from S71 onwards as shown in Figures 15 and 17.

[0169] [2-2-6. Update] A minor bug is found in the vehicle service installed on the device, and the operation to replace the vehicle service without changing the version (hereinafter referred to as "update") will be explained according to the sequence diagram shown in Figure 19. Here, the update is performed using the storage time information contained in the vehicle service information of the RS object.

[0170] When the dashboard 71 receives an upload request for a vehicle service to be replaced in S111, it uploads the vehicle service to be replaced to the repository 23 in S112.

[0171] When the dashboard 71 receives a vehicle service update instruction in S113, in S114 it identifies the devices belonging to the device group on which the target vehicle service will be installed. Furthermore, the dashboard 71 executes the processes S63 to S78 described in Figure 13 for each of the identified devices (hereinafter referred to as target devices).

[0172] However, in S66, the content of the installation instruction that the dashboard 71 writes to the RS object "desire" belonging to the device thing of the target device differs from the case described in Figure 13. In this case, the installation instruction changes only the last update time information of the vehicle service to be installed, and writes the changed vehicle service information to "desire". Specifically, a time later than the last update time included in the installation information of the target vehicle service in the S module of the vehicle DB 511 of the target device is written.

[0173] Changes to the 'desire' are synchronized with the RS module in the vehicle DB 511. The orchestrator 514, notified of this change, performs the same process as when installing a vehicle service. As a result, the target vehicle service is updated without changing its version.

[0174] [2-2-7. Writing to RS Objects When MobiCon Stops] In Cloud 2a, if a user terminal 7 or the like writes to an RS object on Cloud DB 211 while the vehicle-side unit 51 (i.e., MobiCon 5a) is stopped, the changes to the RS object due to the write are saved in Cloud DB 211. The saving method is to save all the history of writes, or to save only the most recent write.

[0175] Then, the changes to the RS objects stored in the cloud DB 211 are synchronized with the in-vehicle DB 511 by the synchronization unit 513 when the vehicle-side unit 51 is started. In addition, the orchestrator 514 performs installation, update, or uninstallation according to the synchronized changes to the RS objects.

[0176] [2-3. Correspondence of Terms] In this embodiment, the RS object corresponds to the request list in this disclosure, the S object corresponds to the service list in this disclosure, and the RS object and S object correspond to the component data in this disclosure. In this embodiment, the dashboard 71 corresponds to the operation unit in this disclosure.

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

[0178] (2a) In the digital twin system 1a, an RS object showing a list of vehicle services to be installed on a device and an S object showing a list of the installation status of vehicle services on each device are prepared in both the cloud DB 211 and the in-vehicle DB 511, and their contents are synchronized. The orchestrator 514 in the in-vehicle system 3 then compares the RS object and the S object to determine whether or not vehicle service installation-related processing is necessary, and executes processing according to the determination result.

[0179] Therefore, in the digital twin system 1a, the cloud 2a can cause the orchestrator 514 of the in-vehicle system 3a to execute installation-related processing simply by updating the RS object on the cloud DB 211, regardless of the status of the in-vehicle system 3a. In other words, if the device Mobicon 5a fails to install vehicle services, etc., Mobicon 5a can retry the installation according to the contents of the RS object and S object without the cloud 2 having to actively and repeatedly issue instructions.

[0180] Furthermore, if the RS object is repeatedly updated by desire, regardless of whether or not it is synchronized with the in-vehicle system 3a, if it is configured to be sequentially overwritten and only the latest list is retained, the following effects can be obtained. For example, consider a conventional device that is configured to execute instructions issued from cloud 2a in order when the vehicle starts up, such as when the vehicle is stopped and synchronization is not possible. In the conventional device, for example, if an uninstallation instruction comes after an installment instruction, the installation and uninstallation are performed unnecessarily, even though ultimately uninstallation is sufficient. In the digital twin system 1a, even if multiple conflicting instructions are issued from cloud 2a when the vehicle is stopped, only the last instruction is synchronized when the vehicle starts up, thus preventing the canceled instructions from being executed unnecessarily by Mobicon 5a.

[0181] (2b) In the digital twin system 1a, an RS object is prepared for each device group, so there is no need to deal with each MobiCon 5a belonging to the same device group individually, and vehicle service installation and other operations can be performed efficiently.

[0182] (2c) In the digital twin system 1a, writes to RS objects on the cloud DB 211 made while the vehicle-side unit 51 (i.e., Mobicon 5a) is stopped are saved in the cloud DB 211 and synchronized with the on-board DB 511 when the vehicle-side unit 51 is started. Therefore, the cloud 2a can issue installation-related instructions using RS objects, i.e., OTA execution instructions, regardless of the startup status of the vehicle-side unit 51. Furthermore, since it is not necessary to forcibly start the vehicle-side unit 51 when issuing installation-related instructions while the vehicle-side unit 51 is stopped, control can be simplified.

[0183] [3. 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.

[0184] (3a) In the above embodiment, the vehicle-side unit 51 is mounted on the Mobicon 5, but the mounting location of the Mobicon 5 is not limited to the vehicle-side unit 5. For example, the vehicle-side unit 51 may be mounted on a separate aftermarket in-vehicle device from the Mobicon 5.

[0185] (3b) 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.

[0186] (3c) In the above embodiment, in order to restore the persistence setting related thing to the 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 thing may be stored in a volatile area, operations may be performed on the volatile area, and for the persistence setting related thing, backup data may be written to the non-volatile area each time a write is made to the thing, as shown in S52 and S53 of Figure 8. In this case, as shown in S51 of Figure 8, at startup, all thing 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.

[0187] (3d) The cloud-side unit 21 and the vehicle-side unit 51 (hereinafter referred to as units 21 and 51) described herein, and the methods implemented by units 21 and 51, 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 units 21 and 51 described herein, and the methods implemented by units 21 and 51, may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the units 21 and 51 described herein, and the methods implemented by units 21 and 51, 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 methods for realizing the functions of each part included in units 21 and 51 do not necessarily need to include software, and all of the functions may be realized using one or more hardware components.

[0188] (3e) 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 configurations of the above embodiment may be omitted. Furthermore, at least some of the configurations of the above embodiment may be added to or replaced with the configurations of other above embodiments.

[0189] (3f) The present disclosure can be implemented in various forms, including the digital twin system 1 described above, the cloud 2 and in-vehicle system 3 which are components of the digital twin system 1, a program for causing computers to function as the cloud-side unit 21 and the vehicle-side unit 51, a non-transitional physical recording medium such as semiconductor memory on which this program is recorded, and a method for synchronizing the digital twin.

[0190] [4. Technical Concept Disclosed in This Specification] [Item 1] An external device (2) provided outside the vehicle, and an in-vehicle terminal (5) 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, and 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 changed component data to the cloud database, and detecting a change in the component data stored in the cloud database, downloading the changed component data to the in-vehicle database, A data synchronization system comprising: an orchestrator (514) configured to perform installation, updating, and uninstallation of vehicle services according to the 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; and

[0191] [Item 2] A data synchronization system as described in Item 1, wherein the component data is written to the in-vehicle database and includes a service list indicating the installation status of the vehicle services in the vehicle, and the orchestrator determines whether installation, updating, or uninstallation of the vehicle services is necessary by comparing the request list with the service list.

[0192] [Item 3] A data synchronization system according to Item 1 or Item 2, wherein the component data includes request data indicating requirements related to the in-vehicle component, and the change in the request list is performed using the request data.

[0193] [Item 4] A data synchronization system according to Item 2 or Item 3 referring to Item 2, wherein the component data includes status data indicating the state of the in-vehicle component, and the writing of the installation status of the vehicle service to the service list is performed using the status data.

[0194] [Item 5] A data synchronization system according to any one of Items 1 to 4, wherein the synchronization unit is configured to synchronize writes to the request list stored in the cloud database while the in-vehicle terminal is stopped with the in-vehicle database when the in-vehicle terminal is started.

[0195] [Item 6] A data synchronization system according to any one of Items 1 to 5, wherein the in-vehicle terminal is used as a device, the device is managed for each device group, the same request list is applied to each device group, and when a new device is added to the device group, the external device causes the orchestrator of the added device to install the vehicle services according to the request list.

[0196] [Item 7] A data synchronization system according to Item 2 or any one of Items 3 to 6 referring to Item 2, comprising an operation unit (71) for operating the cloud database, wherein the operation unit is configured to use the functions of the synchronization unit to send a message to the failed orchestrator requesting a retry of the vehicle service installation when the failure of the vehicle service installation is confirmed by the service list synchronized on the cloud database by the synchronization unit.

[0197] [Item 8] A data synchronization system according to any one of items 1 to 7, wherein the request list includes information indicating the last update time of each of the vehicle services, and the orchestrator updates the vehicle services when it detects a change in the last update time information.

[0198] [Item 9] 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, 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 changed component data to the cloud database, and detecting a change in the component data stored in the cloud database, downloading the changed component data to the in-vehicle database; and an orchestrator (514) configured to perform installation, updating, and uninstallation of the vehicle services according to the 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.

[0199] [Item 10] A program to make 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, function as an orchestrator (514) configured to perform installation, updating, and uninstallation of vehicle services according to the request list, which is written to the cloud database and downloaded from the cloud database to the in-vehicle database by the synchronization unit. The orchestrator (514) configured to perform installation, updating, and uninstallation of vehicle services according to the request list, which is written to the cloud database and downloaded from the cloud database to the in-vehicle database as component data by the synchronization unit.

Claims

1. The vehicle comprises an external device (2) provided outside the vehicle and an in-vehicle terminal (5) 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, and 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 changed component data to the cloud database, and detecting a change in the component data stored in the cloud database, downloading the changed component data to the in-vehicle database. A data synchronization system comprising: an orchestrator (514) configured to perform installation, updating, and uninstallation of vehicle services according to the 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; and 2. A data synchronization system according to claim 1, wherein the component data includes a service list written to the in-vehicle database and indicating the installation status of the vehicle services in the vehicle, and the orchestrator determines whether installation, updating, or uninstallation of the vehicle services is necessary by comparing the request list with the service list.

3. A data synchronization system according to claim 1, wherein the component data includes request data indicating requirements related to the in-vehicle component, and the change in the request list is performed using the request data.

4. A data synchronization system according to claim 2, wherein the component data includes status data indicating the state of the in-vehicle component, and the writing of the installation status of the vehicle service to the service list is performed using the status data.

5. A data synchronization system according to claim 1, wherein the synchronization unit is configured to synchronize writes to the request list stored in the cloud database while the in-vehicle terminal is stopped with the in-vehicle database when the in-vehicle terminal is started.

6. A data synchronization system according to claim 1, wherein the in-vehicle terminal is a device, the device is managed for each device group, the same request list is applied to each device group, and when a new device is added to the device group, the external device causes the orchestrator of the added device to install the vehicle services according to the request list.

7. A data synchronization system according to claim 2, comprising an operation unit (71) for operating the cloud database, wherein the operation unit is configured to use the functions of the synchronization unit to send a message to the failed orchestrator requesting a retry of the vehicle service installation when the failure of the vehicle service installation is confirmed by the service list synchronized on the cloud database by the synchronization unit.

8. A data synchronization system according to claim 1, wherein the request list includes information indicating the last update time of each of the vehicle services, and the orchestrator performs an update of the vehicle services when it detects a change in the last update time information.

9. 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 on the vehicle, the in-vehicle terminal 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 changed component data to the cloud database, and detecting a change in the component data stored in the cloud database, downloading the changed component data to the in-vehicle database; and an orchestrator (514) configured to perform installation, updating, and uninstallation of the vehicle services according to the 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.

10. A program to enable 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 orchestrator (514) configured to perform installation, updating, and uninstallation of vehicle services according to the request list, which is written to the cloud database and downloaded from the cloud database to the in-vehicle database by the synchronization unit.

Images