Vehicle-mounted system, shared memory management device, and shared memory management method

Abstract

A shared area (522) that is set in a memory managed by at least one of a plurality of electronic control devices and that is shared by the plurality of electronic control devices, and a cloud area (922) that is a memory provided by a cloud server and permitted to be used by a vehicle-mounted system are virtually set as one shared memory. A memory map (6) associates storage location information, which indicates the storage location of data in the shared memory, with a data type serving as information for identifying data stored in the storage location indicated by the storage location information. Upon receiving an access request for access to the shared memory, a memory management unit (53) acquires, by using the memory map, the storage location information related to an access target indicated in the access request.

Description

In-Vehicle System, Shared Memory Management Device, and Shared Memory Management Method Cross-Reference to Related Applications

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

[0002] The present disclosure relates to a technique for sharing memory among a plurality of devices connected to an in-vehicle communication network.

[0003] Patent Document 1 below describes a technique in which, in an in-vehicle communication network, a part of the memory mounted on one electronic control unit (hereinafter, ECU) is used as a shared memory, and data shared among a plurality of ECUs is stored and used in the shared memory.

[0004] Japanese Unexamined Patent Application Publication No. 2022-57224

[0005] However, as a result of the inventors' detailed examination, the following problems have been found.

[0006] When the amount of shared data that needs to be stored in an ECU having a shared memory increases, the dedicated memory used for its own processing decreases, which may affect the original processing assigned to the ECU. Also, when trying to secure both the dedicated memory and the shared memory sufficiently, there is a problem that the memory capacity of the ECU having the shared memory, and thus the device scale, increases.

[0007] Further, due to the above constraints, when the capacity of the shared memory cannot be secured sufficiently, there are problems such as that data with a large capacity such as program update data cannot be stored in the shared memory, and that old data needs to be frequently deleted in order to secure an area for storing new data.

[0008] In one aspect of the present disclosure, a technique for improving the usability of a shared memory is provided.

[0009] One aspect of the present disclosure is an in-vehicle system comprising a plurality of electronic control units connected via an in-vehicle communication network. The memory managed by at least one of the plurality of electronic control units has a dedicated area and a shared area. The dedicated area is dedicated to the electronic control unit. The shared area is shared by the plurality of electronic control units. The in-vehicle system comprises a map storage unit and a memory management unit. The map storage unit is configured to store a memory map that associates storage location information indicating the storage location of data in the shared memory with data type information which identifies the data stored in the storage location indicated by the storage location information. Here, the shared area owned by the electronic control units and the cloud area, which is memory provided by a cloud server and permitted for use by the in-vehicle system, are treated virtually as a single shared memory. When the memory management unit receives an access request to the shared memory, it is configured to use the memory map to obtain storage location information relating to the access target indicated in the access request.

[0010] In this configuration, the shared area set in the electronic control unit and the cloud area provided by the cloud server are used as a single virtual shared memory. Therefore, the free space of each electronic control unit can be effectively utilized, and a large-capacity shared memory can be obtained without placing an excessive load on any single electronic control unit. As a result, the usability of the shared memory can be improved.

[0011] One aspect of this disclosure is a shared memory management device comprising a map storage unit and a memory management unit. The map storage unit is configured to store a memory map that associates storage location information indicating the storage location of data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information. Here, the shared area and the cloud area are treated as a single virtual shared memory. The shared area is an area set in memory managed by at least one of the multiple electronic control units in an in-vehicle system equipped with multiple electronic control units connected via an in-vehicle communication network, and is shared by the multiple electronic control units. The cloud area is memory provided by a cloud server and permitted for use by the in-vehicle system. When the memory management unit receives an access request to the shared memory, it is configured to use the memory map to obtain storage location information relating to the access target indicated in the access request.

[0012] A shared memory management device having such a configuration can be used when constructing the aforementioned in-vehicle system.

[0013] One aspect of this disclosure is a shared memory management method in which a shared area and a cloud area are treated as a single virtual shared memory. The shared area is an area set in memory managed by at least one of the multiple electronic control units in an in-vehicle system equipped with multiple electronic control units connected via an in-vehicle communication network, and is shared by the multiple electronic control units. The cloud area is memory provided by a cloud server and authorized for use by the in-vehicle system. When an access request to the shared memory is received, a memory map is used to obtain storage location information related to the access target indicated in the access request. The memory map has contents that associate storage location information indicating the storage location of shared data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information.

[0014] By implementing this method, the same effects as those of the aforementioned in-vehicle system can be obtained.

[0015] This is a block diagram showing the configuration of an in-vehicle system. This is an explanatory diagram showing the structure of a memory map. This is a sequence diagram showing the procedure for reading shared data from shared memory in the first embodiment. This is a sequence diagram showing the procedure for writing shared data to shared memory in the first embodiment. This is a sequence diagram showing the procedure for deleting shared data from shared memory in the first embodiment. This is a sequence diagram showing additional procedures for accessing shared data in the cloud area. This is a sequence diagram showing the procedure for reducing the shared area used for shared memory. This is a sequence diagram showing the procedure for expanding the shared area used for shared memory. This is a sequence diagram showing the procedure for reading shared data from shared memory in the second embodiment. This is a sequence diagram showing the procedure for writing shared data to shared memory in the second embodiment. This is a sequence diagram showing the procedure for deleting shared data from shared memory in the second embodiment. This is an explanatory diagram showing the structure of a memory map used in the third embodiment. This is an explanatory diagram showing the structure of a memory map used in the fourth embodiment. This is an explanatory diagram showing the structure of a read / write map used in the fourth embodiment. This is an explanatory diagram showing an overview of the operation when saving confidential data in the fifth embodiment. This is a block diagram showing other configuration examples of an in-vehicle system.

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

[0017] [1. First Embodiment] [1-1. Configuration] The in-vehicle system 1 shown in Figure 1 comprises a communication device 3 and a plurality of electronic control units (hereinafter referred to as ECUs) 5. The communication device 3 and the plurality of ECUs 5 are all connected to an in-vehicle communication network 7 and cooperate to perform various vehicle controls by sending and receiving data to each other. In addition, the ECUs 5 are configured to communicate with wireless equipment 8 and a cloud server 9 via the communication device 3. Hereinafter, the ECUs 5, wireless equipment 8 and cloud server 9 will be collectively referred to as connected equipment.

[0018] The communication device 3 comprises an external communication unit 31, an internal communication unit 32, and a proximity communication unit 33.

[0019] The external communication unit 31 is connected to a wide-area communication network via the antenna 311 and communicates with cloud servers 9, etc. The cloud servers 9 to which communication is performed may be one or more. The external communication unit 31 has the function of monitoring the connection status with the cloud servers 9 and notifying the ECU 5. If it is necessary to identify multiple cloud servers 9, they are denoted as Cloud A, Cloud B, ...

[0020] The in-vehicle communication unit 32 communicates with multiple ECUs 5 via the in-vehicle communication network 7.

[0021] The proximity communication unit 33 communicates with the wireless device 8 via the antenna 331 using short-range wireless communication such as Bluetooth or Wi-Fi. Bluetooth and Wi-Fi are both registered trademarks. The wireless device 8 includes, for example, a portable terminal carried by a vehicle occupant, and a device installed in the vehicle that has short-range wireless communication capabilities. The proximity communication unit 33 has the function of monitoring the connection status with the wireless device 8 and notifying the ECU 5. The wireless device 8 connected to the in-vehicle communication network 7 via the proximity communication unit 33 may be omitted, or there may be two or more. If it is necessary to identify multiple wireless devices 8, they are denoted as wireless device A, wireless device B, ...

[0022] The communication device 3 may have a function to upload various data to the cloud server 9 in response to requests from the ECU 5. The communication device 3 may also have a function to download application programs executed on the ECU 5 from the cloud server 9 and store them in the shared memory described later.

[0023] Each ECU 5 includes an in-vehicle communication unit 51, a storage unit 52, and a control unit 53.

[0024] The in-vehicle communication unit 51 communicates with other connected devices via the in-vehicle communication network 7.

[0025] The memory unit 52 is composed of rewritable volatile or non-volatile memory and includes a dedicated area 521 used exclusively for the ECU 5 and a shared area 522 shared with other connected devices. The size of each area, the dedicated area 521 and the shared area 522, may be fixed or variable according to instructions from the control unit 53 or other connected devices.

[0026] The control unit 53 includes a microcomputer having a CPU, ROM, RAM, etc.

[0027] Each wireless device 8 comprises a communication unit 81, a storage unit 82, and a control unit 83.

[0028] The communication unit 81 communicates with the ECU 5 via the communication device 3 using short-range wireless communication via the antenna 811. The communication unit 81 may also have a function to communicate with other connected devices via a high-range communication network.

[0029] The memory unit 82, like the memory unit 52, is composed of rewritable volatile or non-volatile memory and includes a dedicated area 821 used exclusively for the wireless device 8 and a shared area 822 shared with other connected devices. The size of each area, the dedicated area 821 and the shared area 822, may be fixed or variable according to instructions from the control unit 83 or other connected devices.

[0030] The control unit 83 includes a microcomputer having a CPU, ROM, RAM, etc.

[0031] The cloud server 9 comprises a communication unit 91, a storage unit 92, and a control unit 93.

[0032] The communication unit 91 communicates with other connected devices via a high-range communication network.

[0033] The storage unit 92 is composed of rewritable volatile or non-volatile memory and includes a cloud area 922 that is permitted for use by the in-vehicle system 1, and a stock area 921 that can be used as the cloud area 922. The cloud area 922 may be fixedly set by contract or the like, or it may be variably set in response to a request from the control unit 93 or a request from other connected devices. The cloud area 922 can be expanded by changing a part of the stock area 921 into the cloud area 922, and the cloud area 922 can be reduced by changing a part of the cloud area 922 into the stock area 921. The cloud area 922 that is permitted for use by the in-vehicle system 1 may be provided on multiple cloud servers 9.

[0034] The control unit 93 includes a microcomputer having a CPU, ROM, RAM, etc.

[0035] The various functions of the microcomputers in the control units 53, 83, and 93 are realized by the CPU executing a program stored in a non-transitional physical recording medium. In this example, the ROM corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program executes the method corresponding to the program. Some or all of the functions executed by the CPU may be configured in hardware using one or more ICs, etc. Also, the number of microcomputers constituting the control unit 53 may be one or more.

[0036] The shared areas 522 and 822 of the connected devices, and the cloud area 922 (hereinafter referred to as the shared areas of the connected devices, etc.) are used as a single virtual shared memory. Hereafter, the ECU 5 that manages the shared memory will be referred to as the host ECU. When it is necessary to distinguish between ECUs 5 other than the host ECU, they will be denoted as ECU_A, ECU_B, ECU_C, etc.

[0037] The host ECU has a memory map 6 in a dedicated area 521.

[0038] The memory map 6 is used to manage the memory space of the shared memory. As shown in Figure 2, the memory map 6 is information that associates data types with storage location information. The data type is information that identifies the shared data to be accessed. Data types may include, for example, "destination," "vehicle location," "image," "audio," "video," "battery capacity," "downloaded update data," etc. Storage location information includes the holding device and memory address. The holding device is information that indicates which connected device is the storage location of the shared data. The memory address is information that indicates the address in the shared area of ​​the holding device where the shared data is stored. In addition, the memory map 6 stores unused areas (hereinafter referred to as "free areas") in the shared area of ​​each holding device, associating them with the data type "free." The memory space of the shared memory managed by the memory map 6 may include the memory space of an external storage device such as a USB memory connected to a USB terminal of any of the ECUs 5. In this case, the memory space of the external storage device will be recognized as the memory space of the ECU 5 to which the external storage device is connected.

[0039] Figure 2 shows, for example, that shared data of type "destination" is stored in the addresses "0x001A to 0x00FA" of the shared area 522 of ECU_A. It also shows that shared data of type "video A" is stored in the addresses "0x042D to 0x04FB" of the cloud area 922 of Cloud_A. Furthermore, it shows that the free space in the shared area 522 of the host ECU is at addresses "0x110C to 0x1FFF", and the free space in the cloud area 922 of Cloud_A is at addresses "0x0800 to 0x0FFF".

[0040] The control unit 53 of the ECU 5 may include functions realized by executing a program, such as a function to access shared data and a function to set variable area sizes for the dedicated area 521 and the shared area 522.

[0041] The function of accessing shared data is a function that transmits an access request to the host ECU when it is necessary to access the shared data. The access request may include a write request, a read request, and a deletion request for the shared data.

[0042] The area setting function is a function that arbitrarily changes the size of each of the dedicated area 521 and the shared area 522 in the storage unit 52 of the own ECU 5. For example, after the ECU 5 is attached to the vehicle, when a situation where the dedicated area 521 of the ECU 5 is insufficient is detected due to, for example, a program update, the area setting function may be used to reduce the shared area 522 and expand the dedicated area 521. Also, when a situation where the number of shared data increases and the shared memory becomes insufficient is detected due to, for example, an application program being added, the area setting function may be used to reduce the dedicated area 521 and expand the shared area 522.

[0043] The control unit 53 of the host ECU may further include a data sharing function, a backup function, etc. as functions realized by executing a program.

[0044] The data sharing function is a function that shares the "data type" of the shared data registered in the memory map 6 with all the connected devices that use the shared data. For example, when new shared data is added or deleted in the memory map 6 due to a new application program being installed or updated, the "data type" of the added or deleted shared data is notified to each connected device.

[0045] The backup function is a function that backs up the shared data stored in the shared memory to a predetermined backup destination. The backup destination may be a cloud server 9 that can communicate via the vehicle exterior communication unit 31, an external storage device such as a USB memory connected to a USB terminal provided in any of the ECUs 5, or a wireless device 8 that can communicate via the proximity communication unit 33.

[0046] Backups may be performed by an event by the vehicle user or a dealer operator who performs vehicle inspections or repairs, or may be performed automatically on a regular basis.

[0047] Backups may also be made by copying the shared areas, etc. in each connected device as a whole. However, in this case, it is also necessary to back up the memory map 6 indicating what information is stored where. When restoring data based on the backup data, the copied data in the shared area, etc. is restored by writing it to the same storage location as before the backup according to the backed-up memory map 6.

[0048] Backups may also be performed by reading out each "data type". In this case, since the storage location information is lost, when restoring data based on the backup data, it may be restored by acquiring the storage location again and writing it to the acquired storage location.

[0049] As functions realized by the control unit 83 of the wireless device 8 by executing a program, it may be provided with an access function to shared data, a region setting function for variably setting the region sizes of the dedicated area 821 and the shared area 822, etc. The details of the access function to shared data and the region setting function are the same as those executed by the control unit 53 of the aforementioned ECU 5.

[0050] As functions realized by the control unit 93 of the cloud server 9 by executing a program, it may be provided with an access function to shared data, a region setting function for variably setting the region size of the cloud region 922, etc. The access function to shared data is the same as that executed by the control unit 53 of the aforementioned ECU 5. The region setting function is a function for arbitrarily changing the region size of the cloud region 922 in the storage unit 92 possessed by the self-cloud server 9. The region setting function is used, for example, when the region size available by a contract, etc. is changed, or when there is a temporary region expansion request from the host ECU. Specifically, when expanding the cloud region 922, a part of the stock region 921 is changed to the cloud region 922, and when shrinking the cloud region 922, a part of the cloud region 922 is changed to the stock region 921.

[0051] [1-2. Sequence] This section describes the procedure for accessing shared data. In the following, the connected device requesting access to the shared data is referred to as the client device, and the connected device where the shared data to be accessed is stored is referred to as the target device.

[0052] First, the sequence for reading shared data from shared memory will be explained using Figure 3.

[0053] In S10, the client device sends a read request to the host ECU. The read request specifies the type of shared data to be read.

[0054] In S11, the host ECU searches the memory map 6 according to the data type indicated in the read request received from the client device and obtains the storage location information of the shared data (i.e., the holding device and memory address) identified from the data type.

[0055] In S12, the host ECU sends a storage location notification to the client device, which contains the storage location information obtained from the memory map 6.

[0056] In S13, the client device sends a read request to the target device, specifying the designated address, according to the storage location information notified by the host ECU. The target device is the holding device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0057] In S14, the target device reads the shared data stored at the specified address from the shared area or other location owned by the target device, in accordance with the received read request.

[0058] In S15, the target device sends a read result notification to the client device indicating the shared data (hereinafter referred to as read data) read in S14, and the series of processes ends when the client device receives the read result notification.

[0059] The read result notification informs the user of the result of accessing shared memory. If the read operation fails, the read result notification may also include details of the error.

[0060] Here, we will explain the specific operation with reference to memory map 6 in Figure 3. For example, consider a case where "XX data" is registered in memory map 6, and its storage location information is set to the holding device "ECU_A" and the memory address "0x511 to 0x05FA". When the host ECU receives a read request for "XX data" from the client device, it retrieves the storage location information for "XX data," i.e., the holding device "ECU_A" and the memory address "0x511 to 0x05FA," from memory map 6 by a storage location search and notifies the client device. The client device sends a read request to the target device (i.e., "ECU_A") indicating the specified address (i.e., "0x511 to 0x05FA"). The target device reads the shared data according to the read request, and the read shared data is sent to the client device by read result notification. As a result of the above procedure, the client device can obtain the shared data identified by the data type "XX data".

[0061] Next, the sequence for writing shared data to shared memory will be explained using Figure 4.

[0062] In S20, the client device sends a write request to the host ECU. The write request specifies the type of shared data to be written and the size of the shared data.

[0063] In S21, the host ECU searches the memory map 6 according to the data type indicated in the write request received from the client device and obtains the storage location information of the shared data (i.e., the holding device and memory address) identified from the data type.

[0064] Here, if the host ECU finds that the shared data to be written is not registered in memory map 6 and cannot obtain the storage location of the shared data, it executes S22 and then executes S23 and subsequent steps. If the host ECU finds that the shared data to be written is registered in memory map 6 and can obtain the storage location of the shared data, it executes S23 and subsequent steps without executing S22.

[0065] In S22, the host ECU registers the data type indicated in the write request in the memory map 6. Specifically, the host ECU selects a storage device for the shared data to be registered from the shared areas of each connected device that are registered in the memory map 6 with the data type "free," according to a predetermined logic. Furthermore, the host ECU allocates an area equal to the data size from the free area of ​​the selected storage device as the storage location for the shared data to be written, and updates the memory map 6 according to the allocation. The memory address indicating the selected storage device and the allocated area equal to the data size becomes the storage location information for the shared data identified by the data type.

[0066] In S23, the host ECU sends a storage location notification to the client device, which contains the storage location information obtained from the memory map 6.

[0067] In S24, the client device sends a write request to the target device, specifying the designated address and the shared data to be stored at that address, in accordance with the storage location information notified by the host ECU. The target device is the storage device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0068] In S25, the target device writes the data to a specified address, such as a shared area, on the target device, in accordance with the received write request.

[0069] In S26, the target device sends a write result notification to the client device indicating the result of the processing in S25, and the series of processes ends when the client device receives the write result notification.

[0070] Furthermore, the write result notification may simply notify the user that the write operation was successful, or it may notify the user of the error details if the write operation failed.

[0071] In other words, if the shared data to be written (hereinafter referred to as "target data") is already registered in the memory map 6, the storage location information is read from the memory map 6 and notified to the client device. If the target data is not registered in the memory map 6, a storage location for the target data is secured from the free area of ​​the shared memory, and storage location information indicating this secured location is notified to the client device.

[0072] Here, we will explain the specific operation by referring to memory map 6 in Figure 4. For example, consider the case where "YY data" is not registered in memory map 6, and the memory address of the free area of ​​"ECU_A" is set to "0x0600 to 0x0FFF". Suppose the host ECU receives a write request indicating the data type "YY data" and the data size "FAH", and selects "ECU_A" as the holding device to store the shared data. The host ECU reserves the area "0x0600 to 0x06FA" of the free area "0x0600 to 0x0FFF" of "ECU_A" shown in memory map 6 for the data size "FAH" for "YY data". Then, an item is added to memory map 6 indicating that the storage location for "YY data" is the memory address "0x0600 to 0x06FA" of the holding device "ECU_A", and the memory address of the free area of ​​"ECU_A" is rewritten to "0x06FB to 0x0FFF".

[0073] Here, the logic for determining which connected device's free space to use when registering new shared data in memory map 6 is explained in (1) to (3) below.

[0074] (1) The host ECU may search for free areas registered in the memory map 6 and select the smallest free area as the storage location among the free areas that have contiguous memory addresses and can store data of the "data size" indicated in the write request. In this case, a free area with contiguous memory addresses and a large data size can be left, so that when it becomes necessary to store large data, it can be stored without being divided across multiple connected devices. Note that having contiguous memory addresses means that the free area does not span across at least multiple connected devices.

[0075] (2) The host ECU searches for free areas registered in the memory map 6, and if it does not find a free area that has a contiguous memory address and can store data of the "data size" indicated in the write request, it may select multiple free areas belonging to the same connected device as storage locations. In this case, since the storage locations for shared data are not distributed across multiple connected devices, access to shared data can be made simple and quick.

[0076] (3) The host ECU may compare the free space registered in the memory map 6 for each connected device and select the connected device with the largest free space as the host ECU. In this case, since the free space of each connected device will remain roughly equal, it is possible to prepare for requests from connected devices to reduce the shared area, etc., or requests from connected devices to expand the dedicated areas 521, 821.

[0077] Next, the sequence for deleting shared data from shared memory will be explained using Figure 5.

[0078] In S30, the client device sends a deletion request to the host ECU. The deletion request specifies the data type and confidentiality level of the shared data to be deleted (hereinafter referred to as the data to be deleted).

[0079] If the confidentiality level indicated in the deletion request indicates that the data to be deleted is of low confidentiality, steps S31 to S35 are omitted and steps S36 onwards are executed. If the confidentiality level is high, steps S31 to S35 are executed first, followed by steps S36 onwards. Shared data with a high confidentiality level includes, for example, personal information of drivers.

[0080] In S31, the host ECU searches the memory map 6 according to the data type indicated in the deletion request received from the client device and obtains information about the storage location of the data to be deleted (i.e., the holding device and memory address).

[0081] In S32, the host ECU sends a storage location notification to the client device, which contains the storage location information obtained from the memory map 6.

[0082] In S33, the client device sends an initialization request to the target device, specifying the designated address, according to the storage location information notified by the host ECU. The target device is the holding device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0083] In S34, the target device is initialized by overwriting the memory address indicated in the initialization request with initialization data in the shared area or other area owned by the target device. The initialization data may be, for example, "00H", "FFH", or any value other than "00H" or "FFH".

[0084] In S35, the target device sends an initialization result notification, indicating the processing result in S34, to the client device and the host ECU.

[0085] In S36, the host ECU unregisters the data to be deleted in the memory map 6. More specifically, it changes the data type of the data to be deleted to "free". If there are multiple free areas in the memory map 6 that belong to the same connected device and have consecutive memory addresses, the memory map 6 may be rewritten so that the multiple free areas become a single free area.

[0086] In S37, the host ECU sends a deletion result notification to the client device indicating the processing result of the deletion request. The series of processes ends when the client device receives this deletion result notification.

[0087] Furthermore, the deletion result notification may simply notify the user that the deletion was successful, or it may notify the user of the error if an error occurred during the deletion process.

[0088] In other words, when deleting shared data with a low level of confidentiality, only the data to be deleted is removed from memory map 6. When deleting highly confidential shared data, in addition to removing the data to be deleted from memory map 6, the data in the storage location is initialized.

[0089] Here, we will explain the specific operation with reference to memory map 6 in Figure 5. For example, consider a case where "ZZ data" is registered in memory map 6, and its storage location information is set to the holding device "ECU_A" and the memory address "0x511 to 0x05FA". When the host ECU receives a deletion request for data type "ZZ data", if the confidentiality level indicated in the deletion request is low, it will unregister the data to be deleted by rewriting the data type in memory map 6 in Figure 5 from "ZZ data" to "free". Also, when the host ECU receives a deletion request for data type "ZZ data", if the confidentiality level indicated in the deletion request is high, it will obtain the storage location information for "ZZ data" from memory map 6 and notify the client device. The storage location information for "ZZ data" is the holding device "ECU_A" and the memory address "0x511 to 0x05FA". The client device sends an initialization request to the target device (i.e., "ECU_A") according to the notified storage location information. The initialization request specifies a range of addresses (i.e., "0x0511 to 0x05FA"). In accordance with this initialization request, the target device initializes the data at the specified addresses in the target device's shared area, etc. After that, the registration of "ZZ data" is unregistered in memory map 6.

[0090] Next, using Figure 6, we will explain the additional procedure for accessing the shared memory of the cloud area 922 when the client device is the ECU 5 or wireless device 8 and the target device is the cloud server 9.

[0091] In S90, the external communication unit 31 notifies the host ECU of the communication status with the cloud server 9. The notification of the communication status from the external communication unit 31 to the host ECU may be done periodically or when the communication status changes.

[0092] In S91, the client device outputs an access request to the host ECU for the shared data stored in the cloud area 922. The access request may be a read request, a write request, or a delete request.

[0093] In S92, when the host ECU receives an access request to the cloud area 922, it checks the communication status with the cloud server 9. If communication is possible, it executes the process in S93; otherwise, it executes the process in S94.

[0094] In S93, the host ECU performs normal processing according to the procedure described using Figures 3 to 5, depending on the content of the access request.

[0095] In S94, the host ECU notifies the client device of an error indicating that it cannot perform processing in response to the access request because it is unable to communicate with the cloud server 9.

[0096] Next, the procedure for a client device to request the host ECU to release a portion of the shared area used as shared memory will be explained using Figure 7. This procedure is performed, for example, when the ECU 5 or wireless device 8 needs to expand the dedicated areas 521 and 821, or when the cloud server 9 needs to reduce the size of the cloud area 922 due to contractual reasons, etc.

[0097] In S40, the client device sends a region change request to the host ECU requesting a reduction in the shared area of ​​the client device. The region change request includes information indicating the client device that made the request (hereinafter referred to as the requesting device) and the size of the shared area to be reduced from the shared memory (hereinafter referred to as the requested size).

[0098] In S41, the host ECU searches the memory map 6 according to the area change request received from the client device and checks the size of the free area, such as the shared area of ​​the requesting device. Specifically, the host ECU obtains the area size (i.e., the free area size) identified from the memory address of an item in the memory map 6 whose data type is "free" and whose holding device is the requesting device. Furthermore, the host ECU determines whether the obtained free area size is equal to or greater than the requested size indicated in the area change request. If the free area size is less than the requested size, the host ECU executes S42 followed by S43; if the free area size is equal to or greater than the requested size, it executes S43 without executing S42.

[0099] In S42, the host ECU moves the shared data stored in the requesting device's shared area to the shared area of ​​other connected devices, thereby securing a free area size in the requesting device's shared area that is larger than the requested size. Note that Figure 7 omits the illustration of the sequence showing the movement of shared data stored in the requesting device's shared area to the shared area of ​​other connected devices.

[0100] In S43, the host ECU updates the memory map 6 by rewriting the memory address of the free area of ​​the requesting device so that an area equal to the requested size is released from the free area of ​​the requesting device.

[0101] In S44, the host ECU sends a region change result notification to the client device, and the series of processes ends when the client device receives the region change result notification. If the change is successful, the region change result notification will show the address of the region that has been released from the shared region, etc. (hereinafter referred to as the released address). If the client device is ECU 5, ECU 5 will change its settings so that the region indicated by the released address shown in the region change result notification can be used as dedicated regions 521 and 821. If the client device is cloud server 9, cloud server 9 will change its settings from cloud region 922 to stock region 921 so that the region indicated by the released address shown in the region change result notification can be provided to other systems.

[0102] Here, we will explain the specific operation by referring to memory map 6 in Figure 7. For example, consider a case where the requesting device for a memory area change request is "ECU_A", and memory addresses "0x0D00 to 0x0FFF" (i.e., a free area size of "300H") are registered in memory map 6 as free areas for "ECU_A".

[0103] When the host ECU receives a memory area change request with a requested size of "200H" from a client device (i.e., the requesting device), since the free memory area size of the requesting device is greater than or equal to the requested size, it frees up an area of ​​"200H" (for example, "0x0D00 to 0x0DFF") from the current free memory area "0x0D00 to 0x0FFF". Specifically, the host ECU updates the memory address of the freed free area of ​​the requesting device in the memory map 6 to "0x0F00 to 0x0FFF". The host ECU also notifies the client device of the memory address of the freed area (i.e., the freed address).

[0104] When the host ECU receives a memory area change request from a client device (i.e., the requesting device) with a requested size of "400H", since the free area size is less than the requested size, it moves shared data to secure free area in the requesting device's (i.e., ECU_A) shared area 522 that is larger than the requested size. Here, to be on the safe side, it secures a new free area 0x0B00 to 0x0CFF so that the free area size becomes 500H, and updates the memory address of the requesting device's free area in memory map 6 to "0x0B00 to 0X0FF". After that, it releases an area of ​​the requested size "400H" (for example, "0x0B00 to 0x0EFF") from the updated free area "0x0B00 to 0x0FFF" of the requesting device. Specifically, the host ECU updates the memory address of the released free area of ​​the requesting device in memory map 6 to "0x0F00 to 0x0FFF". Furthermore, the host ECU notifies the client device of the memory address of the freed area (i.e., the freed address).

[0105] Next, using Figure 8, we will explain the procedure by which the host ECU requests a connected device, selected according to predetermined logic, to expand the size of the shared area, etc., in order to expand the shared memory.

[0106] Each ECU 5 maintains information regarding its usage, including the size of its dedicated area 521 and shared area 522, as well as the size of the available area in the dedicated area 521. Here, the connected device selected according to the logic is referred to as the target device.

[0107] In S50, the host ECU sends a domain expansion request to the target device, requesting an expansion of the target device's shared area, etc. The domain expansion request includes information identifying the target device, and the size of the area to be expanded (hereinafter referred to as the requested size).

[0108] In S51, the target device checks whether it can provide memory of the requested size. If the target device is the ECU 5 or the wireless device 8, it checks whether the free space size of the dedicated areas 521 and 821 is equal to or greater than the requested size indicated in the area change request. If the target device is the cloud server 9, it checks whether the area size of the stock area 921 is equal to or greater than the requested size indicated in the area change request. If the target device cannot provide memory of the requested size, it executes S52; if it can provide memory of the requested size, it executes S53 to S54.

[0109] In S52, the target device sends a result notification to the host ECU indicating that there are no dedicated areas 521, 821 or stock area 921 available for use as shared memory, and the host ECU terminates the series of processes upon receiving the result notification.

[0110] In S53, the target device secures free space (hereinafter referred to as the "extended area") of the requested size that can be used as shared memory from the dedicated areas 521, 821 or the stored areas. The target device then updates the information indicating the size of the shared area and other areas on the target device according to the secured extended area. Furthermore, the target device sends a result notification to the host ECU indicating the memory address (hereinafter referred to as the "extended address") that identifies the extended area.

[0111] In S54, the host ECU updates the memory map 6 so that the extended area of ​​the target device is added to the shared memory, in accordance with the result notification, and then terminates the series of processes. Specifically, it registers the extended address indicated in the result notification as free space for the target device in the memory map 6.

[0112] [1-3. Correspondence of Terms] In this embodiment, the storage unit 52 of the host ECU corresponds to the map storage unit in this disclosure, and the processes S11, S21, S31, S61, S71, and S81 executed by the control unit 53 of the host ECU correspond to the memory management unit in this disclosure. In this embodiment, the host ECU corresponds to the host device in this disclosure, and the client device corresponds to the client device in this disclosure. In this embodiment, the external communication unit 31 corresponds to the communication monitoring unit in this disclosure.

[0113] [1-4. Effects] The first embodiment described in detail above produces the following effects.

[0114] (1a) In the in-vehicle system 1, the shared areas 522, 822 and the cloud area 922 provided for multiple connected devices are used as a single virtual shared memory. Therefore, the free space of each connected device can be effectively utilized, and a large-capacity shared memory can be obtained without placing an excessive load on a specific connected device.

[0115] (1b) In the in-vehicle system 1, the size of the shared area and other areas can be arbitrarily changed in each connected device by using area change requests and area expansion requests. Therefore, if the dedicated areas 521 and 821 become insufficient due to functional upgrades of connected devices, a portion of the shared areas 522 and 822 used as shared memory can be changed to the dedicated areas 521 and 821. Also, to resolve a shortage of shared memory, a portion of the dedicated areas 521 and 821 can be changed to the shared areas 522 and 822. In other words, when a memory shortage occurs, it is possible to respond flexibly by changing the area sizes of the dedicated area 521 and the shared area 522, and the area size of the cloud area 922, without adding memory in hardware.

[0116] (1c) The in-vehicle system 1 is configured to back up shared data stored in the shared memory to a cloud server 9, a wireless device 8, or an external storage device that can be attached to or removed from the in-vehicle system 1. Therefore, even if the ECU fails and is replaced, the state before the failure can be restored using the backed-up historical data.

[0117] (1d) In the in-vehicle system 1, when deleting shared data stored in the shared memory, if the confidentiality level of the data to be deleted is low, only the memory map 6 is updated. If the confidentiality level is high, in addition to updating the memory map 6, the data of the storage location of the data to be deleted is initialized. Therefore, highly confidential information such as personal information that is no longer needed will not remain in the storage unit 52, and the security of the in-vehicle system 1 can be improved. Furthermore, for information with a low confidentiality level, processing can be simplified as only the memory map 6 needs to be manipulated.

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

[0119] In the first embodiment described above, when accessing shared memory, the client device obtains storage location information from the host ECU and uses the obtained storage location information to access the target device's shared area, etc. The second embodiment differs from the first embodiment in that the host ECU performs the access to the target device's shared area, etc.

[0120] [2-2. Sequence] This section describes the procedure for client devices to access shared data.

[0121] First, the sequence for reading shared data from shared memory will be explained using Figure 9.

[0122] Steps S60 to S61 are the same as steps S10 to S11, which were explained using Figure 3.

[0123] In S62, the host ECU sends a read request to the target device, specifying the designated address, according to the storage location information obtained from the memory map 6. The target device is the holding device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0124] In S63, the target device reads the shared data stored at the specified address from the shared area or other location owned by the target device, in accordance with the received read request.

[0125] In S64, the target device sends a read result notification to the host ECU indicating the shared data (hereinafter referred to as read data) read in S63.

[0126] In step S65, the host ECU forwards the read result notification received from the target device to the client device, and the client device terminates the series of processes upon receiving the read result notification.

[0127] Next, the sequence for writing shared data to shared memory will be explained using Figure 10.

[0128] Steps S70 to S72 are the same as steps S20 to S22 as explained using Figure 4. However, the write request transmitted in S70 includes the write data to be stored in the shared memory.

[0129] In S73, the host ECU sends a write request to the target device, specifying the designated address and the shared data to be stored at that address, according to the storage location information obtained from the memory map 6. The target device is the holding device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0130] In S74, the target device writes the data to a specified address, such as a shared area, on the target device, in accordance with the received write request.

[0131] In S75, the target device sends a write result notification to the host ECU indicating the result of the processing in S74.

[0132] In S76, the host ECU forwards the write result notification received from the target device to the client device, and the process is completed when the client device receives the write result notification.

[0133] Next, the sequence for deleting specified shared data from shared memory will be explained using Figure 11.

[0134] Steps S80 to S81 are the same as steps S30 to S31, which were explained using Figure 5.

[0135] However, if the confidentiality level indicated in the deletion request sent in S80 indicates that the confidentiality level of the data to be deleted is low, steps S81 to S84 are omitted and steps S85 onwards are executed. If the confidentiality level is high, steps S81 to S84 are executed first, followed by steps S85 onwards.

[0136] In S82, the host ECU sends an initialization request to the target device, specifying the designated address, according to the storage location information obtained from the memory map 6. The target device is the holding device indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0137] In S83, the target device performs initialization by overwriting the specified address, such as a shared area, owned by the target device with initialization data, in accordance with the received initialization request.

[0138] In S84, the target device sends an initialization result notification to the host ECU, indicating the processing result in S83.

[0139] Steps S85 to S86 are the same as steps S36 to S37, which were explained using Figure 5.

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

[0141] (2a) In the in-vehicle system 1 of the second embodiment, the host ECU performs access to the target device based on the storage location information obtained from the memory map 6. Therefore, compared to the case where access to the target device is performed by a client device that has obtained the storage location information from the host ECU, the procedure is simplified and the amount of communication within the system can be reduced.

[0142] [3. Third Embodiment] [3-1. Differences from the First Embodiment] The third 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.

[0143] In the first embodiment described above, when the host ECU registers new shared data in the memory map 6, it uses logic (1) to (3) that considers the size of the free space in the connected device when deciding which free space to use. The third embodiment differs from the first embodiment in that it further uses logic that considers the flag CF assigned to each data type.

[0144] [3-2. Memory Map] In this embodiment, the host ECU uses the memory map 6a shown in Figure 12 instead of the memory map 6 shown in Figure 2.

[0145] As shown in Figure 12, the memory map 6a is information that associates data types with storage location information, similar to the first embodiment. However, in the memory map 6a, the data type includes a flag CF in addition to the name information. The flag CF indicates whether or not to allow the corresponding data to be stored on the cloud server 9, and whether or not to allow it to be stored on the ECU 5 and wireless device 8 (hereinafter referred to as ECU, etc.).

[0146] Specifically, if flag CF = 0, it indicates that saving to cloud server 9 is not possible, but saving to ECU etc. is possible. If flag CF = 1, it indicates that saving to cloud server 9 is possible, but saving to ECU etc. is not possible. If flag CF = 2, it indicates that saving to both cloud server 9 and ECU etc. is possible.

[0147] The value of flag CF may be predetermined for each data item, or it may be specified by the connected device requesting the registration of the shared data.

[0148] Here, the ECU 5 and the wireless device 8 are treated together as an ECU, etc., and are associated with flag CF. However, the ECU and the wireless device 8 may also be treated separately and associated with flag CF.

[0149] [3-3. Operation] When the host ECU registers new shared data in the memory map 6, it first checks which connected devices can store the data to be registered by referring to the flag CF associated with the data to be registered. Next, it searches for available space in the memory map 6 for the connected devices that have been confirmed to be able to store the data, and determines which connected device will be the destination for registration by applying one of the logics (1) to (3) described in the first embodiment to the found available space. The following operation is the same as in the first embodiment.

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

[0151] (3a) In this embodiment, the reliability and usability of the system can be improved by setting the value of flag CF according to the characteristics of the data. For example, it is conceivable that data that is frequently used during operation (e.g., data used for operation control) may not be saved to the cloud. On the other hand, it is conceivable that data that is unlikely to be used during operation (e.g., log data) may be saved to the cloud. Furthermore, it is conceivable that data that is unlikely to be used and is also long (e.g., image data) may not be saved to the ECU, etc. By making these settings, it is possible to suppress situations in which necessary data cannot be obtained when communication with the cloud server 9 is impossible, and to reduce the time required to read and write shared data as a whole.

[0152] [4. Fourth Embodiment] [4-1. Differences from the First Embodiment] The fourth 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.

[0153] In the first embodiment described above, when the host ECU registers new shared data in the memory map 6, it uses logic (1) to (3) that considers the size of the free space in the connected device when deciding which free space to use. The fourth embodiment differs from the first embodiment in that it further uses logic that considers the flag SF assigned to each data type.

[0154] [4-2. Memory Map] In this embodiment, the host ECU uses the memory map 6b shown in Figure 13 instead of the memory map 6 shown in Figure 2.

[0155] As shown in Figure 13, the memory map 6b, as in the first embodiment, is information that associates data types with storage location information. However, in the memory map 6b, the data type includes a flag SF in addition to the name information. The flag SF indicates the security level for the corresponding data.

[0156] Specifically, a flag SF=1 indicates a low security level, a flag SF=2 indicates a medium security level, and a flag SF=3 indicates a high security level. For example, data containing personal information may be assigned a high security level (i.e., flag SF=3). Data used for vehicle control and frequently updated may be assigned a medium security level (i.e., flag SF=2). Data other than high or medium security levels may be assigned a low security level (i.e., flag SF=1).

[0157] The value of flag SF may be predetermined for each data item, similar to the case of flag CF, or it may be specified by the connected device requesting the registration of the shared data.

[0158] The host ECU has a read / write map in addition to the memory map 6b. As shown in Figure 14, the read / write map contains information that associates connected devices with read levels and write levels. Connected devices are information that identifies connected devices and include all ECUs 5 connected to the in-vehicle communication network 7, all wireless devices 8 connected to the in-vehicle communication network 7 via the communication device 3, and all cloud servers 9. The read level is information that indicates the security level of data that a corresponding connected device can read from the shared memory of other connected devices. The write level is information that indicates the security level of data that can be written to the shared memory of a corresponding connected device.

[0159] For example, the read / write mapping in Figure 14 shows that ECU_A can read any data set with flags SF=1 to SF=3 from the shared memory of other connected devices, and can write any data set with flags SF=1 to SF=3 to ECU_A's shared memory. It also shows that ECU_C can read data set with flag SF=1 from the shared memory of other connected devices, but cannot read data set with flags SF=2 or SF=3. It also shows that ECU_C's shared memory can write data set with flag SF=1, but cannot write data set with flags SF=2 or SF=3.

[0160] [4-3. Operation] When the host ECU registers new shared data in the memory map 6b, it first checks the security level of the data to be registered by referring to the flag SF associated with the data to be registered. Next, it refers to the read / write map and extracts all connected devices whose write level matches the confirmed security level. Then, for the extracted connected devices, it searches for free space registered in the memory map 6 and determines the connected device to which the data will be registered by applying one of the logics (1) to (3) described in the first embodiment to the found free space. The following operation is the same as in the first embodiment.

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

[0162] (4a) In this embodiment, data reading and writing at each connected device can be controlled according to the data security level, thereby further improving the reliability and usability of the system.

[0163] [5. Fifth Embodiment] [5-1. Differences from the First Embodiment] The fifth 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.

[0164] In the first embodiment described above, when the host ECU registers new shared data in the memory map 6, it uses logic (1) to (3) that considers the size of the free space in the connected device when deciding which connected device's free space to use. Also, in the first embodiment, the data to be registered is stored in a single connected device as much as possible. In the fifth embodiment, data that needs to be kept confidential (hereinafter referred to as confidential data) is deliberately divided and stored in multiple connected devices, and moreover, one of the connected devices is always a cloud server 9, which is different from the first embodiment.

[0165] [5-2. Operation] As shown in Figure 15, when the host ECU registers new shared data in the memory map 6 for secret data, it divides it into, for example, three partial data. Then, it selects physically different storage locations for two of the partial data from the ECU 5 or the wireless device 8, and sets the cloud server 9 as the storage location for one of the partial data. Then, it updates the memory map 6 so that an item is added for each of the three partial data.

[0166] Furthermore, the number of divisions of the confidential data is not limited to three; it can be two, four or more, or any number of divisions. The number of divisions may also be set variably depending on the length of the confidential data.

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

[0168] (5a) In this embodiment, since the confidential data is distributed and stored on multiple physically different connected devices, the confidentiality of the confidential data can be improved.

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

[0170] (6a) The above embodiment of the in-vehicle system 1 has been described in the case where there is one host ECU, but there may be two or more host ECUs. For example, as in the in-vehicle system 1a shown in Figure 16, multiple domain ECUs 5a are connected to the main network 7a, and each of the multiple domain ECUs 5a is connected to multiple controlled ECUs 5b via a subnetwork 7b. In other words, multiple ECUs 5a and 5b are classified into multiple domains, and a subnetwork 7b is formed for each domain. In this case, each domain ECU 5a may be set as a host ECU, and shared data may be managed for each domain. In the in-vehicle system 1a, the domain ECU 5a is equipped with an intra-domain communication unit 54 in addition to the in-vehicle communication unit 51, storage unit 52, and control unit 53 that the ECU 5 of the in-vehicle system 1 has. Also, the controlled ECU 5b is equipped with an intra-domain communication unit 54 instead of the in-vehicle communication unit 51 that the ECU 5 of the in-vehicle system 1 has. The intra-domain communication unit 54 performs communication via the subnetwork 7b. In the in-vehicle system 1a shown in Figure 16, the proximity communication unit 33 and the wireless device 8 of the communication unit 3 are omitted compared to the in-vehicle system 1 shown in Figure 1. However, the in-vehicle system 1a may also be equipped with the proximity communication unit 33 and the wireless device 8.

[0171] (6b) In the in-vehicle system 1a, when the entire system manages a single shared memory, the host ECU may use the following logic when selecting a holding ECU to store newly registered shared data that is not yet registered in the memory map 6. That is, when an access request is received from a client device, the host ECU may select an ECU belonging to the same domain as the client device as the holding ECU. In this case, since access to the shared data can be achieved without going through a complex communication path, errors related to accessing the shared data can be suppressed and the reliability of the system can be improved.

[0172] (6c) In the above embodiment, when deleting shared data from shared memory, it is determined whether or not to initialize the data in the storage location according to the confidentiality level. However, instead of the confidentiality level, information that directly indicates whether or not initialization is necessary may be used.

[0173] (6d) The control units 53, 83, 93 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 control units 53, 83, 93 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 control units 53, 83, 93 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. The computer program may also be stored as instructions to be executed by the computer on a computer-readable non-transitional tangible recording medium. The methods for implementing the functions of each part included in the control units 53, 83, 93 do not necessarily need to include software, and all of their functions may be implemented using one or more hardware components.

[0174] (6e) 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.

[0175] (6f) In addition to the host ECU as a shared memory management device as described above, the present disclosure may be implemented in various forms, such as a system comprising the shared memory management device, a program for causing a computer to function as the shared memory management device, a non-transitional physical recording medium such as semiconductor memory on which this program is recorded, and a shared memory management method.

[0176] [7. Technical Concept Disclosed in This Specification] [Item 1] An in-vehicle system comprising a plurality of electronic control devices (5, 5a, 5b) connected via an in-vehicle communication network (7, 7a, 7b), wherein the memory managed by at least one of the plurality of electronic control devices comprises a dedicated area (521) used exclusively by the electronic control device and a shared area (522) shared by the plurality of electronic control devices, and the shared area owned by the electronic control device and the cloud area (922), which is a memory provided by a cloud server and permitted for use by the in-vehicle system, are virtually treated as a single shared memory, and a map storage unit (52) is configured to store a memory map (6) that associates storage location information indicating the storage location of data in the shared memory with data type information which identifies the data stored in the storage location indicated by the storage location information, An in-vehicle system comprising: a memory management unit (53: S11, S21, S31, S61, S71, S81) configured to receive an access request to the shared memory and, using the memory map, acquire the storage location information relating to the access target indicated in the access request;

[0177] [Item 2] An in-vehicle system as described in Item 1, wherein the electronic control device comprising the map storage unit and the memory management unit is configured as the host device, the electronic control device that is the source of the access request is configured as the client device, and the host device is configured to perform access to the shared memory based on the storage location information acquired by the memory management unit and to notify the client device of the execution result.

[0178] [Item 3] An in-vehicle system as described in Item 1, wherein the electronic control device comprising the map storage unit and the memory management unit is a host device, the electronic control device that is the source of the access request is a client device, the host device notifies the client device of the storage location information acquired by the memory management unit, and the client device uses the storage location information notified by the host device to access the shared memory.

[0179] [Item 4] An in-vehicle system as described in Item 2 or Item 3, wherein the host device is configured to perform a backup that transfers the contents of the shared memory to a specified backup destination.

[0180] [Item 5] An in-vehicle system as described in Item 4, wherein the backup destination is an external storage device detachably provided to the in-vehicle system, or the cloud server.

[0181] [Item 6] An in-vehicle system according to any one of items 2 to 5, wherein when the area size of the dedicated area and the shared area in the electronic control unit is changed, and when the area size of the cloud area in the cloud server is changed, the electronic control unit and the cloud server are configured to send an area change request indicating the content of the area size change to the host device (S40), and the host device is configured to update the contents of the memory map according to the content of the change indicated in the area change request (S43).

[0182] [Item 7] An in-vehicle system according to any one of items 2 to 6, wherein the host device transmits a space expansion request to the electronic control unit and the cloud server when it is necessary to expand the shared memory (S50), the electronic control unit, upon receiving the space expansion request, transmits a space change result notification to the host device indicating that it will change the space size so that a portion of the free space becomes the shared area if there is free space in the dedicated area, the cloud server transmits a space change result notification to the host device indicating that it will change the space size of the cloud area if it allows the space expansion request (S53), and the host device updates the contents of the memory map in accordance with the space change result notification (S54).

[0183] [Item 8] An in-vehicle system according to any one of items 2 to 7, wherein when deleting data from the shared memory, the system is configured such that, depending on the confidentiality level of the data to be deleted, if the confidentiality level is low, the registration to the memory map is unregistered, and if the confidentiality level is high, the registration to the memory map is unregistered and the data of the storage location of the data to be deleted is initialized.

[0184] [Item 9] An in-vehicle system according to any one of items 2 to 8, further comprising a communication monitoring unit (31) configured to monitor the communication status with the cloud server, wherein if the communication status indicates that access to the cloud server is impossible, the host device notifies the client device that requested to read data from the cloud area of ​​the communication status.

[0185] [Item 10] An in-vehicle system according to any one of items 2 to 9, wherein the electronic control unit includes a portable terminal connected to the in-vehicle system by short-range wireless communication.

[0186] [Item 11] An in-vehicle system according to any one of items 2 to 10, wherein the memory managed by the electronic control unit includes an external storage device that can be attached to and detached from the electronic control unit.

[0187] [Item 12] An in-vehicle system according to any one of items 2 to 11, wherein there are multiple cloud servers that provide the cloud area.

[0188] [Item 13] An in-vehicle system according to any one of items 2 to 12, wherein the host device is configured to distribute the storage location of the data to either the shared area of ​​the electronic control unit or the cloud area of ​​the cloud server, according to a flag associated with the data.

[0189] [Item 14] An in-vehicle system according to any one of items 2 to 13, wherein the host device is configured to restrict the electronic control unit and the cloud server that can access the data according to a flag associated with the data.

[0190] [Item 15] An in-vehicle system according to any one of items 2 to 14, wherein the host device is configured to divide and store the specified data in a plurality of physically separated shared areas or cloud areas.

[0191] [Item 16] A shared memory management device comprising: a map storage unit (52) configured to store a memory map (6) that associates storage location information indicating the storage location of data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information, in an in-vehicle system comprising a plurality of electronic control devices connected via an in-vehicle communication network, wherein the shared area (522) set in the memory managed by at least one of the plurality of electronic control devices and shared by the plurality of electronic control devices, and the cloud area (922) which is memory provided by a cloud server and permitted to be used by the in-vehicle system, as a single virtual shared memory; and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured to receive an access request to the shared memory and use the memory map to acquire the storage location information relating to the access target indicated in the access request.

[0192] [Item 17] A shared memory management method in an in-vehicle system comprising a plurality of electronic control devices connected via an in-vehicle communication network, wherein a shared area set in a memory managed by at least one of the plurality of electronic control devices and shared by the plurality of electronic control devices, and a cloud area which is memory provided by a cloud server and permitted for use by the in-vehicle system are treated as a single virtual shared memory, and a memory map is used which associates storage location information indicating the storage location of shared data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information, and when an access request to the shared memory is received, the storage location information relating to the access target indicated in the access request is obtained using the memory map.

Claims

1. An in-vehicle system comprising a plurality of electronic control devices (5, 5a, 5b) connected via an in-vehicle communication network (7, 7a, 7b), wherein the memory managed by at least one of the plurality of electronic control devices comprises a dedicated area (521) used exclusively by the electronic control device and a shared area (522) shared by the plurality of electronic control devices, and the shared area owned by the electronic control device and the cloud area (922), which is a memory provided by a cloud server and permitted for use by the in-vehicle system, are virtually treated as a single shared memory, and a map storage unit (52) is configured to store a memory map (6) that associates storage location information indicating the storage location of data in the shared memory with data type information that identifies the data stored in the storage location indicated by the storage location information, and a memory management unit (53: S11, S21, S31, S61, S71, S81) is configured to receive an access request to the shared memory and use the memory map to acquire the storage location information relating to the access target indicated in the access request, An in-vehicle system equipped with the following features.

2. An in-vehicle system according to claim 1, wherein the electronic control device comprising the map storage unit and the memory management unit is configured as a host device, the electronic control device that is the source of the access request is configured as a client device, and the host device is configured to perform access to the shared memory based on the storage location information acquired by the memory management unit and to notify the client device of the execution result.

3. An in-vehicle system according to claim 1, wherein the electronic control device comprising the map storage unit and the memory management unit is a host device, the electronic control device that is the source of the access request is a client device, the host device notifies the client device of the storage location information acquired by the memory management unit, and the client device uses the storage location information notified by the host device to access the shared memory.

4. An in-vehicle system according to claim 2 or claim 3, wherein the host device is configured to perform a backup that transfers the contents of the shared memory to a specified backup destination.

5. The in-vehicle system according to claim 4, wherein the backup destination is an external storage device detachably provided to the in-vehicle system, or the cloud server.

6. An in-vehicle system according to claim 2 or claim 3, wherein when the area size of the dedicated area and the shared area in the electronic control unit is changed, and when the area size of the cloud area in the cloud server is changed, the electronic control unit and the cloud server are configured to transmit an area change request indicating the content of the area size change to the host device (S40), and the host device is configured to update the contents of the memory map according to the content of the change indicated in the area change request (S43).

7. An in-vehicle system according to claim 2 or claim 3, wherein the host device transmits a space expansion request to the electronic control unit and the cloud server when it is necessary to expand the shared memory (S50); when the electronic control unit receives the space expansion request, transmits a space change result notification to the host device indicating that it will change the space size so that a portion of the free space becomes the shared area if there is free space in the dedicated area; when the cloud server allows the space expansion request, transmits a space change result notification to the host device indicating that it will change the space size of the cloud area (S53); and the host device updates the contents of the memory map in accordance with the space change result notification (S54).

8. An in-vehicle system according to claim 2 or claim 3, wherein when data is deleted from the shared memory, the system is configured such that, depending on the confidentiality level of the data to be deleted, if the confidentiality level is low, the registration to the memory map is unregistered, and if the confidentiality level is high, the registration to the memory map is unregistered and the data of the storage location of the data to be deleted is initialized.

9. An in-vehicle system according to claim 2 or claim 3, further comprising a communication monitoring unit (31) configured to monitor the communication status with the cloud server, wherein if the communication status indicates that access to the cloud server is unavailable, the host device notifies the client device that requested to read data from the cloud area of ​​the communication status.

10. An in-vehicle system according to claim 2 or claim 3, wherein the electronic control unit includes a portable terminal connected to the in-vehicle system by short-range wireless communication.

11. An in-vehicle system according to claim 2 or claim 3, wherein the memory managed by the electronic control unit includes an external storage device that can be attached to and detached from the electronic control unit.

12. An in-vehicle system according to claim 2 or claim 3, wherein there are multiple cloud servers providing the cloud area.

13. An in-vehicle system according to claim 2 or claim 3, wherein the host device is configured to distribute the storage location of the data to either the shared area of ​​the electronic control unit or the cloud area of ​​the cloud server, according to a flag associated with the data.

14. An in-vehicle system according to claim 2 or claim 3, wherein the host device is configured to restrict the electronic control unit and the cloud server that can access the data according to a flag associated with the data.

15. An in-vehicle system according to claim 2 or claim 3, wherein the host device is configured to divide and store the specified data in a plurality of physically separated shared areas or cloud areas.

16. A shared memory management device comprising: a map storage unit (52) configured to store a memory map (6) that associates storage location information indicating the storage location of data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information, in an in-vehicle system comprising a plurality of electronic control devices connected via an in-vehicle communication network, wherein the shared area (522) set in the memory managed by at least one of the plurality of electronic control devices and shared by the plurality of electronic control devices, and the cloud area (922) which is memory provided by a cloud server and permitted to be used by the in-vehicle system, as a single virtual shared memory; and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured to receive an access request to the shared memory and use the memory map to acquire the storage location information relating to the access target indicated in the access request.

17. A shared memory management method for an in-vehicle system comprising a plurality of electronic control devices connected via an in-vehicle communication network, wherein a shared area set in a memory managed by at least one of the plurality of electronic control devices and shared by the plurality of electronic control devices, and a cloud area which is memory provided by a cloud server and permitted for use by the in-vehicle system are treated as a single virtual shared memory, and a memory map is used which associates storage location information indicating the storage location of shared data in the shared memory with data type information which identifies the shared data stored in the storage location indicated by the storage location information, and when an access request to the shared memory is received, the storage location information relating to the access target indicated in the access request is obtained using the memory map.

Images