In-vehicle terminal, data synchronization program, and data synchronization system

Abstract

This in-vehicle terminal (5) comprises an in-vehicle database (511), a synchronization unit (513), and an upload unit (514). The in-vehicle database stores a plurality of pieces of component data. The synchronization unit synchronizes the content of the in-vehicle database and the content of a cloud database. The upload unit receives an upload request, uploads upload request data, which is a subject of the upload request, to a cloud by using Wi-Fi when the in-vehicle terminal is connected to Wi-Fi, and controls a process for uploading the upload request data to the cloud via a mobile line on the basis of an upload policy when the in-vehicle terminal is not connected to Wi-Fi.

Description

In-vehicle terminal, data synchronization program, and data synchronization system Cross-reference to related applications

[0001] This international application claims the benefit of Japanese Patent Application No. 2024-232724, filed with the Japan Patent Office on December 27, 2024, the entire disclosure of which is incorporated herein by reference.

[0002] This disclosure relates to a technology for collecting and utilizing vehicle data.

[0003] Patent Document 1 describes a technology for uploading media content to a remote location through a wireless communication network.

[0004] Japanese Patent Publication No. 2010-505324

[0005] As a result of the inventors' detailed examination, it has been found that there is a problem that it is necessary to suppress uploading using a mobile line because communication costs are incurred when uploading data from an in-vehicle device mounted on a vehicle to the cloud using a mobile line.

[0006] This disclosure provides a technology for suppressing the use of a mobile line and uploading data.

[0007] One aspect of this disclosure is an in-vehicle terminal configured to perform data communication with an external device mounted on a vehicle and provided outside the vehicle and having a cloud database.

[0008] The in-vehicle terminal of this disclosure includes an in-vehicle database, a synchronization unit, and an upload unit.

[0009] The in-vehicle database is configured to store a plurality of component data each associated with a corresponding in-vehicle component.

[0010] When the synchronization unit detects a change in the component data stored in the in-vehicle database, it is configured to synchronize the content of the in-vehicle database with the content of the cloud database by uploading the detected changed component data to the cloud database.

[0011] The upload unit receives an upload request that requests data to be uploaded to the cloud. If the in-vehicle terminal is connected to Wi-Fi (registered trademark), it uploads the data subject to the upload request to the cloud using Wi-Fi. If the in-vehicle terminal is not connected to Wi-Fi, it controls the process of uploading the data to the cloud via a mobile network based on the upload policy set for the upload request.

[0012] The in-vehicle terminal of this disclosure, configured in this manner, determines whether or not to upload the requested data over the mobile network based on the upload policy. Therefore, the in-vehicle terminal of this disclosure does not immediately upload the requested data upon receiving it, but can postpone the upload until it is connected to Wi-Fi, thereby enabling data upload while minimizing the use of the mobile network.

[0013] Another aspect of this disclosure is a data synchronization program for causing a computer in an in-vehicle terminal, which is mounted in a vehicle and configured to communicate data with an external device located outside the vehicle and equipped with a cloud database, to function as a synchronization unit and an upload unit.

[0014] A computer controlled by the data synchronization program of this disclosure can constitute part of the in-vehicle terminal of this disclosure and can achieve the same effects as the in-vehicle terminal of this disclosure.

[0015] A further aspect of this disclosure is a data synchronization system comprising an external device located outside the vehicle and equipped with a cloud database, and an in-vehicle terminal mounted in the vehicle and configured to communicate data with the external device. The in-vehicle terminal comprises an in-vehicle database, a synchronization unit, and an upload unit.

[0016] The data synchronization system disclosed herein is a system equipped with the in-vehicle terminal disclosed herein and can achieve the same effects as the in-vehicle terminal disclosed herein.

[0017] This is a block diagram showing the configuration of the digital twin system 1 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 when the internet is not connected with the cloud database, including not only the latest value but all history. 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 1 of the second embodiment. This is a first sequence diagram showing the procedure for uploading data. This is a second sequence diagram showing the procedure for uploading data. This is a third sequence diagram showing the procedure for uploading data.

[0018] [First Embodiment] A first embodiment of the present disclosure will be described below with reference to the drawings.

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

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

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

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

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

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

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

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

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

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

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

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

[0031] The data used to create a digital twin is also called "shadow." Shadow refers to state data related to various devices in a vehicle, such as "the engine is on" or "the air conditioner is on."

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

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

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

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

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

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

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

[0039] As a method of causing the target application to execute processing related to the target component, in addition to using desire, a method using job is prepared. Jobs are basically downloaded from the cloud 2.

[0040] Desire is mainly used in cases that are simple and do not require failure handling or mediation, such as instructing an external application to upload specified data.

[0041] Jobs are mainly used in cases where not only the state is specified but also actions are mainly instructed, such as "update application A", "open the trunk", and "the system execute the specified command". The instruction content is described in arbitrary text and a format that can be understood by both the sender and the receiver is used. Note that, similar to desire, jobs may also list data to be uploaded or show a data collection condition table related to the data to be uploaded.

[0042] Note that the data collection condition table may be incorporated into the target application. In this case, the data collection condition table is installed by OTA together with the target application. In other words, when the target application is updated, the data collection condition table is also updated. OTA is the abbreviation of Over the Air, indicating that it is via wireless.

[0043] Jobs are issued to the thing. The thing can receive multiple jobs and stores the received jobs in the job queue in the order of reception. The target application of the thing retrieves one job at a time from the job queue in order of high priority and executes the processing. Basically, parallel processing of jobs is not performed.

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

[0045] The job state is initialized to QUEUED, which indicates not started, at the time of job creation.

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

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

[0048] Note that for the job status, states such as CANCELED, FAILED, REJECTED, etc., which are used when an error or the work fails, may be used. Furthermore, any error message specified as a string may be used.

[0049] [3. Cloud-side Unit / Vehicle-side Unit] Returning to FIG. 1, the cloud-side unit 21 and the vehicle-side unit 51 that handle the digital twin will be described.

[0050] The cloud-side unit 21 includes a cloud database (hereinafter, cloud DB) 211 and a cloud core unit 212.

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

[0052] The cloud DB 211 stores information for realizing digital twins of a plurality of in-vehicle systems 3. The thing that classifies and manages the shadows is given a name so that it can identify which in-vehicle system 3 it belongs to.

[0053] The in-vehicle DB 511 stores information for realizing the digital twin of the vehicle itself.

[0054] The in-vehicle DB 511 includes a volatile area and a non-volatile area. The volatile area is composed of a volatile memory whose stored content disappears when the power of the in-vehicle system 3 is turned off. The non-volatile area is composed of a non-volatile memory whose stored content does not disappear even when the power is turned off.

[0055] The in-vehicle DB 511 also 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 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.

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

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

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

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

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

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

[0062] 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, updates in the cloud DB 211 are reflected in the in-vehicle DB 511, and updates in the in-vehicle DB 511 are reflected in the cloud DB 211, thus maintaining DBs 211 and 511 in a synchronized state.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0096] After returning to an online state, the synchronization unit 513 reads the changes stored in the cache area A3 in order from the oldest stored change in S41, and writes them to the cloud DB 211's thing:appA / report according to the read changes. If the write is successful, the synchronization unit 513 deletes the successfully written changes in S42. Then, the process from S41 to S42 is repeated until all changes stored in the cache area A3 are deleted.

[0097] This enables the system to be configured to update its history, allowing all data that occurred while the system was offline and stored in cache area A3 to be reflected in cloud DB211.

[0098] Note that the storage capacity of cache area A3 is limited, and if the offline state persists for a long period, 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.

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

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

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

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

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

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

[0105] (5c) 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.

[0106] (5d) 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.

[0107] [Second Embodiment] A second embodiment of the present disclosure will be described below with reference to the drawings. In the second embodiment, the parts that differ from the first embodiment will be described. Common components will be denoted by the same reference numerals.

[0108] The digital twin system 1 of the second embodiment differs from the first embodiment in that the vehicle-side unit 51 further includes an uploader 514, and the cloud 2 further includes an upload server 8 and a departure management system 9, as shown in Figure 9.

[0109] The uploader 514 uploads the data requested by applications 53 and 54 to the upload server 8 in the cloud 2, based on requests from applications 53 and 54. The uploader 514 includes a storage unit 515 for temporarily storing the data to be uploaded to the upload server 8. In this embodiment, the storage unit 515 is composed of a non-volatile memory that allows data to be rewritten.

[0110] The upload server 8 is configured to communicate with the uploader 514 and stores the data that the uploader 514 uploads to the upload server 8.

[0111] The departure management system 9 uses data stored on the upload server 8 to manage the departure of multiple vehicles used by delivery personnel to deliver food and other items in a food delivery service, for example.

[0112] Next, the operation flow of the digital twin system 1 of the second embodiment will be explained using the sequence diagrams in Figures 10, 11, and 12.

[0113] In S61 of Figure 10, the vehicle user (i.e., the delivery person or the administrator of the departure management system 9) sets the upper limit of the available storage capacity (hereinafter referred to as the upper limit storage capacity) in the storage unit 515 of the uploader 514 by performing an input operation on the HMI device installed in the vehicle. HMI stands for Human Machine Interface. The operation to set the upper limit storage capacity is performed only once as an initial setup.

[0114] When the upper limit of storage capacity is set, the uploader 514 periodically performs a benchmark of the upload speed and measures the upload speed when it is connected to the upload server 8 using an IEEE 802.11 standard wireless LAN (hereinafter referred to as Wi-Fi) in S62. The uploader 514 stores the information indicating the measured upload speed, along with information indicating the time and place of measurement, in the storage unit 515. Wi-Fi is an abbreviation for Wireless Fidelity. Wi-Fi is a registered trademark.

[0115] When the vehicle is away from a location where it is connected to the upload server 8 via Wi-Fi (hereinafter referred to as the Wi-Fi connection location), the application 53 sends an upload request to the uploader 514 in S63. Specifically, the application 53 writes, for example, the data to be uploaded (hereinafter referred to as the upload request data), the priority of the upload request data, and an upload policy that defines the conditions for uploading to the desire of the thing of the uploader 514.

[0116] The upload policy stipulates that if there is sufficient storage capacity in the storage unit 515 (i.e., if the storage capacity used to store the upload request data is less than the upper limit storage capacity), the upload request data corresponding to the upload request received by the uploader 514 will be stored in the storage unit 515.

[0117] The upload policy specifies one of the following options: "prioritize new data," "prioritize old data," "retain data as much as possible," and "prioritize mobile connection," in the event that there is insufficient storage capacity in the storage unit 515 (i.e., when the storage capacity used to store the upload request data reaches the upper limit of storage capacity). The mobile connection is a connection that uses a mobile phone network to connect to the internet wirelessly.

[0118] Therefore, if there is sufficient storage capacity in the storage unit 515 when the application 53 makes an upload request, the uploader 514 stores the upload request data in the storage unit 515 at S64 in Figure 11.

[0119] If the storage capacity of the storage unit 515 is insufficient when application 53 makes an upload request, and the upload policy is "prioritize newer data", then in S65, the uploader 514 deletes the oldest upload request data stored in the storage unit 515 from past upload requests made by application 53 (hereinafter referred to as the requesting application) in S63, and stores the new upload request data in the storage area freed up by the deletion.

[0120] If the storage unit 515 does not have sufficient storage capacity when application 53 makes an upload request, and the upload policy is "prioritize older data", the uploader 514 discards the new upload request data in S66 without storing it in the storage unit 515.

[0121] If, when application 53 makes an upload request, there is insufficient storage capacity in the storage unit 515, and the upload policy is "retain data as much as possible," and the vehicle cannot use a mobile network, then in S67, the uploader 514 deletes upload request data stored in the storage unit 515 from applications 53 (hereinafter referred to as "other applications") that have made upload requests in the past and have a lower priority than the upload request data of the requesting application, and stores the new upload request data in the storage area freed up by the deletion.

[0122] If the storage capacity of the storage unit 515 is insufficient when the application 53 makes an upload request, and the upload policy is "retain data as much as possible", and the vehicle can use a mobile network, the uploader 514 uploads the requesting application's upload request data to the upload server 8 via the mobile network in S68.

[0123] If the storage capacity of the storage unit 515 is insufficient when the application 53 makes an upload request, and the upload policy is "prioritize mobile network," the uploader 514 uploads the requesting application's upload request data to the upload server 8 via the mobile network in S69.

[0124] The uploader 514 periodically calculates the estimated upload time in S70 and notifies the departure management system 9 of the calculated estimated upload time.

[0125] The estimated upload time is the time when all upload request data stored in the memory unit 515 can be uploaded after the vehicle returns to the Wi-Fi connection location.

[0126] Specifically, the uploader 514 first obtains Wi-Fi connection prediction time information from the departure management system 9, which indicates the predicted time when the vehicle equipped with the uploader 514 will return to the Wi-Fi connection location (hereinafter referred to as the Wi-Fi connection prediction time).

[0127] The uploader 514 calculates the amount of data stored in the storage unit 515 per unit time (hereinafter referred to as the data storage rate) based on several recent timings in which the upload request data was stored in the storage unit 515.

[0128] The uploader 514 calculates the amount of data to be stored in the storage unit 515 by the predicted Wi-Fi connection time (hereinafter referred to as the upload data amount) based on the predicted Wi-Fi connection time and the data storage speed.

[0129] The uploader 514 calculates the estimated upload time based on the time calculated by dividing the amount of uploaded data by the data storage rate and the predicted Wi-Fi connection time.

[0130] The uploader 514 transmits the estimated upload time information, which indicates the calculated estimated upload time, to the departure management system 9 via the mobile network.

[0131] When the vehicle returns to the Wi-Fi connection location, the uploader 514 uploads all upload request data stored in the storage unit 515 to the upload server 8 via the mobile network at S71 in Figure 12. The uploader 514 generally uploads data in order of priority, starting with the highest priority. The uploader 514 then deletes completed upload request data from the storage unit 515. However, if the upload policy is "prioritize new data," the uploader 514 uploads data in order of newest first. If the upload policy is "prioritize old data," the uploader 514 uploads data in order of oldest first.

[0132] During the upload process, the uploader 514 periodically calculates the estimated time of upload completion in S72 and notifies the departure management system 9 of the calculated estimated time of upload completion.

[0133] Specifically, the uploader 514 first calculates the amount of data to be uploaded per unit time (hereinafter referred to as the upload speed) and the amount of upload request data currently stored in the storage unit 515 (hereinafter referred to as the amount of stored data).

[0134] The uploader 514 calculates the time when the upload will be completed based on the calculated upload speed and the amount of data to be stored, and sets this time as the estimated upload completion time.

[0135] The uploader 514 uploads the calculated estimated upload completion time information to the upload server 8 using Wi-Fi.

[0136] If the vehicle departs before the upload to the upload server 8 is complete, and the upload policy is "retain data as much as possible", and the vehicle has access to a mobile network, and it is unlikely that the upload request data stored in the storage unit 515 that was not uploaded due to the vehicle's departure will be retained until the next predicted Wi-Fi connection time, then in S73, the uploader 514 uploads the upload request data stored in the storage unit 515 to the upload server 8 via the mobile network.

[0137] Furthermore, the uploader 514 determines whether it can retain the upload request data stored in the storage unit 515 until the next predicted Wi-Fi connection time, based on the most recently calculated data storage speed, the amount of upload request data currently stored in the storage unit 515, and the next predicted Wi-Fi connection time.

[0138] The MobiCon 5, configured in this way, is mounted on the vehicle and is configured to communicate data with a cloud-side unit 21 located outside the vehicle and equipped with a cloud DB 211.

[0139] Mobicon 5 comprises an in-vehicle DB 511, a synchronization unit 513, and an uploader 514.

[0140] The in-vehicle DB511 is configured to store multiple shadows, each associated with one of the in-vehicle components.

[0141] The synchronization unit 513 is configured to synchronize the contents of the in-vehicle DB 511 and the cloud DB 211 by uploading the shadow with the detected change to the cloud DB 211 when it detects a change in the shadow stored in the in-vehicle DB 511.

[0142] The uploader 514 receives an upload request that requests the uploading of data to Cloud 2. If MobiCon 5 is connected to Wi-Fi, it uploads the data subject to the upload request to Cloud 2 using Wi-Fi. If MobiCon 5 is not connected to Wi-Fi, it controls the process of uploading the data to Cloud 2 via the mobile network based on the upload policy set for the upload request.

[0143] This type of MobiCon 5 determines whether or not to upload the requested data over the mobile network based on its upload policy. Therefore, instead of immediately uploading the requested data upon receiving it, MobiCon 5 can postpone the upload until a Wi-Fi connection is established, thus limiting the use of the mobile network while uploading the data. Immediate uploading refers to starting the upload without any delay.

[0144] Furthermore, the uploader 514 determines, based on the upload policy, whether the conditions for uploading the requested data are met. If the conditions are met, it immediately uploads the requested data via the mobile network. In this embodiment, the conditions for uploading are met when the upload policy is "retain data as much as possible" and the vehicle can use the mobile network, or when the upload policy is "prioritize mobile network".

[0145] Furthermore, when uploading multiple upload request data, the uploader 514 prioritizes uploading data with higher priority. This prevents situations where the MobiCon 5 is unable to upload high-priority upload request data to Cloud 2 due to the loss of connection to Wi-Fi or mobile network during the upload process.

[0146] Furthermore, if the MobiCon 5 is in the process of uploading the requested data to the cloud 2 using Wi-Fi, and the MobiCon 5 is in a state where it is not connected to Wi-Fi but connected to a mobile network, the uploader 514 will determine, based on the upload policy, whether the conditions for uploading the requested data are met. If the conditions for uploading are met, the uploader 514 will upload the requested data using the mobile network. The conditions for uploading in this embodiment are that the upload policy is "retain data as much as possible", the vehicle can use a mobile network, and it is not expected that the requested data stored in the storage unit 515 will be retained until the next predicted Wi-Fi connection time. Such a MobiCon 5 can suppress the occurrence of situations where the requested data is lost without being uploaded to the cloud 2 due to the disconnection from Wi-Fi during the upload.

[0147] Furthermore, the upload policy stipulates that if there is sufficient storage capacity in the storage unit 515, the upload request data corresponding to the received upload request will be stored in the storage unit 515, and if there is insufficient storage capacity in the storage unit 515, the upload request data corresponding to the received upload request will be uploaded via the mobile network. This makes it possible for MobiCon 5 to prevent situations in which upload request data is lost without being uploaded to Cloud 2.

[0148] Furthermore, the upload policy stipulates that if there is sufficient storage capacity in the storage unit 515, the upload request data corresponding to the received upload request will be stored in the storage unit 515, and if there is insufficient storage capacity in the storage unit 515, the old upload request data will be deleted from the storage unit 515 and the upload request data corresponding to the received upload request will be stored in the storage unit 515. This makes it possible for MobiCon 5 to prevent situations in which new upload request data is lost without being uploaded to Cloud 2.

[0149] Furthermore, the upload policy stipulates that if there is sufficient storage capacity in the storage unit 515, the upload request data corresponding to the received upload request will be stored in the storage unit 515, and if there is insufficient storage capacity in the storage unit 515, the upload request data stored in the storage unit 515 will be retained and the upload request data corresponding to the received upload request will be discarded. This makes it possible for MobiCon 5 to prevent situations in which old upload request data is lost without being uploaded to Cloud 2.

[0150] Furthermore, the upload policy stipulates that if there is sufficient storage capacity in the storage unit 515, the upload request data corresponding to the received upload request will be stored in the storage unit 515. If there is insufficient storage capacity in the storage unit 515, upload request data with a lower priority than the upload request data corresponding to the received upload request will be deleted from the upload request data stored in the storage unit 515, and the upload request data corresponding to the received upload request will be stored in the storage unit 515. This makes it possible for MobiCon 5 to prevent situations in which high-priority upload request data is lost without being uploaded to Cloud 2.

[0151] In the embodiments described above, the digital twin system 1 corresponds to a data synchronization system, the Mobicon 5 corresponds to an in-vehicle terminal, the cloud-side unit 21 corresponds to an external device, the shadow corresponds to component data, and the uploader 514 corresponds to an upload unit.

[0152] Although one embodiment of the present disclosure has been described above, the present disclosure is not limited to the above embodiment and can be implemented in various modified forms.

[0153] [Modification 1] In the above embodiment, the vehicle-side unit 51 is mounted on the Mobicon 5, but it is not limited to this. For example, the vehicle-side unit 51 may be mounted on a separate aftermarket in-vehicle device from the Mobicon 5.

[0154] [Modification 2] In the above embodiment, the ECU group 4 includes a zone ECU 41 provided for each zone, but instead of the zone ECU 41, a domain ECU provided for each domain may be included.

[0155] [Modification 3] 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. However, this is not limited to this, 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.

[0156] [Modification 4] In the above embodiment, the uploader 514 calculates the estimated upload time by obtaining Wi-Fi connection prediction time information from the departure management system 9.

[0157] However, if the upload execution conditions are not met when the Mobicon 5 is not connected to Wi-Fi, the uploader 514 may not immediately upload the upload request data over the mobile network, but instead set a predicted Wi-Fi connection time for when the Mobicon 5 will next connect to Wi-Fi. The predicted Wi-Fi connection time may be obtained by the uploader 514 from the departure management system 9, or it may be calculated by the uploader 514 based on the vehicle's operating schedule. The predicted Wi-Fi connection time corresponds to the next connection timing.

[0158] The uploader 514 may also set a cache policy for storing upload request data in the storage unit 515 based on the predicted Wi-Fi connection time and the upper limit storage capacity set in advance for the storage unit 515. As an example of a cache policy, one could set a priority for storing data in the storage unit 515 according to the data type. For example, the priority could be set to prioritize the storage of sensor information such as GPS, and postpone the storage of video data. This allows the MobiCon 5 to suppress the occurrence of situations where high-priority upload request data is lost without being uploaded to the cloud 2.

[0159] [Modification 5] In the above embodiment, the upload request data is stored in a storage unit 515 which is composed of a data-rewritable non-volatile memory.

[0160] However, normally, upload request data is stored in volatile memory, and if, while uploading the data stored in volatile memory to cloud 2 using Wi-Fi, the MobiCon 5 transitions to a state where it is not connected to Wi-Fi but connected to a mobile network, the upload request data that was not uploaded to cloud 2 may be stored in non-volatile memory. This eliminates the need for the MobiCon 5 to have non-volatile memory with a large storage capacity to store the upload request data.

[0161] [Modification 6] In the above embodiment, an upload request is written to thing, but an upload request may be made to the uploader 514 by a method other than writing the upload request to thing.

[0162] The cloud-side unit 21 and vehicle-side unit 51 and their methods described in this disclosure 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 vehicle-side unit 51 and their methods described in this disclosure 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 vehicle-side unit 51 and their methods described in this disclosure 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 the cloud-side unit 21 and vehicle-side unit 51 do not necessarily need to include software, and all of their functions may be realized using one or more hardware components.

[0163] 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. Furthermore, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, some parts of the configuration of the above embodiment may be omitted. Furthermore, at least some parts of the configuration of the above embodiment may be added to or replaced with the configuration of other above embodiments.

[0164] In addition to the MobiCon 5 described above, this disclosure can also be realized in various forms, such as a system that uses the MobiCon 5 as a component, a program for causing the computer to function as the MobiCon 5, a non-transitional physical recording medium such as semiconductor memory that stores this program, and an upload method. [Technical Concept Disclosed in This Specification] [Item 1] An in-vehicle terminal (5) mounted in a vehicle and configured to communicate data with an external device (21) located outside the vehicle and equipped with a cloud database (211), comprising: an in-vehicle database (511) configured to store a plurality of component data, each associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database with the contents of the cloud database by uploading the component data in which a change has been detected to the cloud database when a change in the component data stored in the in-vehicle database is detected; and an upload unit (514) configured to receive an upload request requesting the upload of data to a cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi (registered trademark), to upload the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi, and if the in-vehicle terminal is not connected to Wi-Fi, to control the process of uploading the upload request data to the cloud via a mobile line based on an upload policy set for the upload request.

[0165] [Item 2] An in-vehicle terminal as described in Item 1, wherein the upload unit determines whether the upload execution conditions for uploading the upload request data are met based on the upload policy, and if the upload execution conditions are met, the in-vehicle terminal immediately uploads the upload request data via the mobile network.

[0166] [Item 3] An in-vehicle terminal as described in Item 1 or Item 2, wherein the upload unit uploads multiple upload request data, and uploads the upload request data with higher priority earlier.

[0167] [Item 4] An in-vehicle terminal as described in any one of Items 1 to 3, wherein the upload unit, while the in-vehicle terminal is uploading the upload request data to the cloud using the Wi-Fi, transitions to a state where the in-vehicle terminal is not connected to the Wi-Fi but is connected to the mobile network, and determines whether the upload execution conditions for uploading the upload request data are met based on the upload policy, and if the upload execution conditions are met, the in-vehicle terminal uploads the upload request data using the mobile network.

[0168] [Item 5] An in-vehicle terminal as described in Item 2, wherein the upload unit does not immediately upload the upload request data over the mobile network if the upload execution conditions are not met when the in-vehicle terminal is not connected to the Wi-Fi, and sets the next connection timing, which is the timing when the in-vehicle terminal will next connect to the Wi-Fi.

[0169] [Item 6] An in-vehicle terminal as described in Item 5, further comprising a storage unit (515) that stores the upload request data subject to the upload request when it receives the upload request, wherein the upload unit sets a cache policy for storing the upload request data in the storage unit based on the next connection timing and a preset upper limit storage capacity for the storage unit.

[0170] [Item 7] An in-vehicle terminal according to any one of Items 1 to 6, further comprising a storage unit (515) that stores the upload request data subject to the upload request when the upload request is received, wherein the upload policy specifies that, if there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit, and if there is insufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is uploaded via the mobile network.

[0171] [Item 8] An in-vehicle terminal according to any one of Items 1 to 6, further comprising a storage unit (515) that stores the upload request data subject to the upload request when the upload request is received, wherein the upload policy is defined as follows: If there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, the old upload request data is deleted from the storage unit and the upload request data corresponding to the received upload request is stored in the storage unit.

[0172] [Item 9] An in-vehicle terminal according to any one of Items 1 to 6, further comprising a storage unit (515) that stores the upload request data subject to the upload request when the upload request is received, wherein the upload policy is defined as follows: if there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, the upload request data stored in the storage unit is retained and the upload request data corresponding to the received upload request is discarded.

[0173] [Item 10] An in-vehicle terminal according to any one of Items 1 to 6, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload policy is defined as follows: If there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, upload request data with a lower priority than the upload request data corresponding to the received upload request is deleted from the storage unit, and the upload request data corresponding to the received upload request is stored in the storage unit.

[0174] [Item 11] An in-vehicle terminal according to any one of Items 1 to 9, wherein the upload unit stores in non-volatile memory the upload request data that was not uploaded to the cloud when the in-vehicle terminal is in the process of uploading the upload request data to the cloud using the Wi-Fi and the in-vehicle terminal is in a state where it is not connected to the Wi-Fi and is connected to the mobile network.

[0175] [Item 12] A data synchronization program for a computer in an in-vehicle terminal (5) that is mounted in a vehicle and configured to communicate data with an external device (21) located outside the vehicle and equipped with a cloud database (211), wherein the computer is configured to synchronize the contents of the in-vehicle database and the cloud database by detecting changes in component data stored in an in-vehicle database (511), each configured to store a plurality of component data associated with any one of the in-vehicle components, and uploading the component data for which changes have been detected to the cloud database; and an upload unit (514) that receives an upload request requesting to upload data to the cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi, uploads the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi, and if the in-vehicle terminal is not connected to Wi-Fi, controls the process of uploading the upload request data to the cloud via a mobile line based on the upload policy set for the upload request.

[0176] [Item 13] A data synchronization system (1) comprising: an external device (21) provided outside the vehicle and equipped with a cloud database (211); an in-vehicle terminal (5) mounted on the vehicle and configured to perform data communication with the external device, wherein the in-vehicle terminal comprises: an in-vehicle database (511) configured to store a plurality of component data each associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database with the contents of the cloud database by uploading the component data in which a change has been detected to the cloud database when a change in the component data stored in the in-vehicle database is detected; and an upload unit (514) configured to receive an upload request requesting the upload of data to the cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi (registered trademark), upload the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi; and if the in-vehicle terminal is not connected to Wi-Fi, control the process of uploading the upload request data to the cloud via a mobile line based on the upload policy set for the upload request.

Claims

1. An in-vehicle terminal (5) mounted in a vehicle and configured to communicate data with an external device (21) located outside the vehicle and equipped with a cloud database (211), comprising: an in-vehicle database (511) configured to store a plurality of component data, each associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database with the contents of the cloud database by uploading the component data in which a change has been detected to the cloud database when a change in the component data stored in the in-vehicle database is detected; and an upload unit (514) configured to receive an upload request requesting the upload of data to a cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi (registered trademark), to upload the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi, and if the in-vehicle terminal is not connected to Wi-Fi, to control the process of uploading the upload request data to the cloud via a mobile line based on the upload policy set for the upload request.

2. An in-vehicle terminal according to claim 1, wherein the upload unit determines whether the upload execution conditions for uploading the upload request data are met based on the upload policy, and if the upload execution conditions are met, the in-vehicle terminal immediately uploads the upload request data via the mobile network.

3. An in-vehicle terminal according to claim 1 or claim 2, wherein the upload unit uploads a plurality of upload request data, and uploads the upload request data with higher priority earlier.

4. An in-vehicle terminal according to claim 1 or claim 2, wherein the upload unit, while the in-vehicle terminal is uploading the upload request data to the cloud using the Wi-Fi, transitions to a state where the in-vehicle terminal is not connected to the Wi-Fi but is connected to the mobile network, determines whether the upload execution conditions for uploading the upload request data are met based on the upload policy, and if the upload execution conditions are met, the in-vehicle terminal uploads the upload request data using the mobile network.

5. An in-vehicle terminal according to claim 2, wherein the upload unit, when the in-vehicle terminal is not connected to the Wi-Fi and the upload execution conditions are not met, does not immediately upload the upload request data over the mobile line, and sets the next connection timing, which is the timing when the in-vehicle terminal will next connect to the Wi-Fi.

6. An in-vehicle terminal according to claim 5, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload unit sets a cache policy for storing the upload request data in the storage unit based on the next connection timing and a preset upper limit storage capacity for the storage unit.

7. An in-vehicle terminal according to claim 1 or claim 2, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload policy is defined as follows: if there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is uploaded via the mobile network.

8. An in-vehicle terminal according to claim 1 or claim 2, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload policy is defined as follows: if there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, older upload request data is deleted from the storage unit and the upload request data corresponding to the received upload request is stored in the storage unit.

9. An in-vehicle terminal according to claim 1 or claim 2, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload policy is defined as follows: if there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, the upload request data stored in the storage unit is retained and the upload request data corresponding to the received upload request is discarded.

10. An in-vehicle terminal according to claim 1 or claim 2, further comprising a storage unit (515) that stores the upload request data subject to the upload request when an upload request is received, wherein the upload policy is defined as follows: If there is sufficient storage capacity in the storage unit, the upload request data corresponding to the received upload request is stored in the storage unit; if there is insufficient storage capacity in the storage unit, upload request data with a lower priority than the upload request data corresponding to the received upload request is deleted from the storage unit, and the upload request data corresponding to the received upload request is stored in the storage unit.

11. An in-vehicle terminal according to claim 1 or claim 2, wherein the upload unit stores the upload request data that was not uploaded to the cloud in a non-volatile memory when the in-vehicle terminal is in the process of uploading the upload request data to the cloud using the Wi-Fi and the in-vehicle terminal is in a state where it is not connected to the Wi-Fi and is connected to the mobile network.

12. A data synchronization program for a computer in an in-vehicle terminal (5) that is mounted in a vehicle and configured to communicate data with an external device (21) located outside the vehicle and equipped with a cloud database (211), wherein the computer is configured to synchronize the contents of the in-vehicle database and the cloud database by detecting changes in component data stored in an in-vehicle database (511), each configured to store a plurality of component data associated with any of the in-vehicle components, and uploading the changed component data to the cloud database; and an upload unit (514) that receives an upload request requesting to upload data to the cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi, uploads the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi, and if the in-vehicle terminal is not connected to Wi-Fi, controls the process of uploading the upload request data to the cloud via a mobile line based on the upload policy set for the upload request.

13. A data synchronization system (1) comprising: an external device (21) provided outside the vehicle and equipped with a cloud database (211); an in-vehicle terminal (5) mounted on the vehicle and configured to perform data communication with the external device, wherein the in-vehicle terminal comprises: an in-vehicle database (511) configured to store a plurality of component data each associated with any of the in-vehicle components; a synchronization unit (513) configured to synchronize the contents of the in-vehicle database with the contents of the cloud database by uploading the component data in which a change has been detected to the cloud database when a change in the component data stored in the in-vehicle database is detected; and an upload unit (514) configured to receive an upload request requesting the upload of data to the cloud (2), and, if the in-vehicle terminal is connected to Wi-Fi (registered trademark), upload the upload request data, which is the data subject to the upload request, to the cloud using Wi-Fi; and if the in-vehicle terminal is not connected to Wi-Fi, control the process of uploading the upload request data to the cloud via a mobile line based on the upload policy set for the upload request.

Images