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

A virtual memory management system for vehicles optimizes shared memory use among ECUs by dynamically allocating storage and ensuring efficient data handling and security through a memory map, addressing memory capacity and efficiency issues in shared systems.

WO2026004977A1PCT designated stage Publication Date: 2026-01-02DENSO CORP
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/JP2025/023087
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-06-28
Filing Date
2025-06-26
Publication Date
2026-01-02

AI Technical Summary

Technical Problem

In vehicles with shared memory systems, increasing shared data storage demands reduce dedicated memory for processing, leading to inefficiencies and potential memory capacity constraints, necessitating frequent data deletion to accommodate new data.

Method used

A system where multiple electronic control units (ECUs) share a virtual memory space through a memory map that associates data types with storage locations, allowing flexible allocation and management of dedicated and shared memory areas, enabling efficient use of free memory without overburdening individual ECUs.

Benefits of technology

This approach provides a large-capacity shared memory without overloading any single ECU, allows dynamic adjustment of memory areas, supports data backup, and enhances security by managing data confidentiality levels.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure JP2025023087_02012026_PF_FP_ABST
    Figure JP2025023087_02012026_PF_FP_ABST
Patent Text Reader

Abstract

According to the present invention, each of a plurality of electronic control devices (5) has a dedicated area (521), which is a memory dedicated to the electronic control device, and a shared area (522), which is a memory shared by the plurality of electronic control devices. In this vehicle-mounted system, the shared area of the plurality of electronic control devices is virtually handled as a single shared memory. A memory map (6) associates storage location information, indicating the storage location of data in the shared memory, with a data type that is 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) uses the memory map to acquire the storage location information about an access target indicated in the access request.
Need to check novelty before this filing date? Find Prior Art

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-105630, filed with the Japan Patent Office on June 28, 2024, the entire disclosure of which is incorporated herein by reference.

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

[0003] The following Patent Document 1 describes a technology in which part of the memory installed in one electronic control unit (hereinafter referred to as ECU) in an in-vehicle communication network is used as a shared memory, and data shared between multiple ECUs is stored in the shared memory and used.

[0004] Japanese Patent Application Laid-Open No. 2022-57224

[0005] However, as a result of detailed investigation by the inventors, the following problems were found.

[0006] In an ECU equipped with a shared memory, if the amount of shared data that needs to be stored increases, the dedicated memory available for its own processing will decrease, which may affect the processing originally assigned to the ECU. Furthermore, if an attempt is made to secure sufficient dedicated memory and shared memory, the memory capacity of the ECU equipped with the shared memory, and therefore the size of the device, will increase.

[0007] The inventors also discovered the problem that if the above constraints prevent sufficient shared memory capacity from being secured, large amounts of data such as program update data cannot be stored in the shared memory, and that old data must be frequently deleted in order to secure space to store new data.

[0008] One aspect of the present disclosure provides a technique for improving the usability of a shared memory.

[0009] One aspect of the present disclosure is an in-vehicle system including a plurality of electronic control units connected via an in-vehicle communication network. The electronic control units have a dedicated area and a shared area. The dedicated area is memory dedicated to the electronic control units. The shared area is memory shared by the plurality of electronic control units. The in-vehicle system includes a map storage unit and a memory management unit. In the in-vehicle system, the shared areas owned by the plurality of electronic control units are virtually treated as a single shared memory. The map storage unit stores a memory map. The memory map is information that associates storage location information indicating the storage location of data in the shared memory with a data type, which is information that identifies the data stored in the storage location indicated by the storage location information. When the memory management unit receives an access request for the shared memory, it uses the memory map to obtain storage location information for the access target indicated in the access request.

[0010] With this configuration, the shared memory areas of multiple electronic control units are used as a single virtual shared memory. This allows the free memory areas of each electronic control unit to be used effectively, and a large-capacity shared memory can be provided without placing an excessive load on any one specific electronic control unit. As a result, the usability of the shared memory can be improved.

[0011] One aspect of the present disclosure is a shared memory management device including a map storage unit and a memory management unit. A shared area set in each of the memories of a plurality of electronic control units connected via an in-vehicle communication network is treated as a single virtual shared memory. The map storage unit stores a memory map that associates storage location information indicating a storage location of data in the shared memory with a data type, which is information identifying the shared data stored in the storage location indicated by the storage location information. Upon receiving an access request for the shared memory, the memory management unit uses the memory map to obtain storage location information for the access target indicated in the access request.

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

[0013] One aspect of the present disclosure is a shared memory management method, in which a shared area set in each memory of a plurality of electronic control devices connected via an in-vehicle communication network is treated as a single virtual shared memory. A memory map is used that associates storage location information indicating a storage location of shared data in the shared memory with a data type that identifies the shared data stored in the storage location indicated by the storage location information. When an access request for the shared memory is received, the memory map is used to obtain storage location information for the access target indicated in the access request.

[0014] By implementing this method, it is possible to obtain the same effects as the above-mentioned in-vehicle system.

[0015] FIG. 1 is a block diagram showing the configuration of an in-vehicle system. FIG. 2 is an explanatory diagram showing the structure of a memory map. FIG. 3 is a sequence diagram showing the procedure when shared data is read from a shared memory in the first embodiment. FIG. 4 is a sequence diagram showing the procedure when shared data is written to a shared memory in the first embodiment. FIG. 5 is a sequence diagram showing the procedure when shared data is deleted from a shared memory in the first embodiment. FIG. 6 is a sequence diagram showing the procedure when a shared area used in the shared memory is reduced. FIG. 7 is a sequence diagram showing the procedure when a shared area used in the shared memory is expanded. FIG. 8 is a sequence diagram showing the procedure when shared data is read from a shared memory in the second embodiment. FIG. 9 is a sequence diagram showing the procedure when shared data is written to a shared memory in the second embodiment. FIG. 10 is a block diagram showing another configuration example of an in-vehicle system.

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

[0017] 1. First Embodiment 1-1. Configuration An in-vehicle system 1 shown in FIG. 1 includes a communication device 3 and a plurality of electronic control units (hereinafter referred to as ECUs) 5.

[0018] The communication device 3 and the plurality of ECUs 5 are all connected to an in-vehicle communication network 7, and transmit and receive data to and from each other to cooperate with each other to execute various vehicle controls.

[0019] The communication device 3 includes an exterior communication unit 31 and an interior communication unit 32 .

[0020] The external vehicle communication unit 31 is connected to a wide area communication network via an antenna 33 and communicates with the cloud server 9 and the like.

[0021] The in-vehicle communication unit 32 communicates with a plurality of ECUs 5 via the in-vehicle communication network 7 .

[0022] The communication device 3 may have a function of uploading various data to the cloud server 9 in response to a request from the ECU 5. The communication device 3 may have a function of downloading an application program to be executed by the ECU 5 from the cloud server 9 and storing the application program in a shared memory, which will be 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 ECUs 5 and the communication device 3 via the in-vehicle communication network 7 .

[0025] The storage unit 52 is configured by a rewritable volatile or non-volatile memory, and includes a dedicated area 521 that is used exclusively for the ECU 5 itself, and a shared area 522 that is shared with other ECUs 5. The size of each of the dedicated area 521 and the shared area 522 may be set to a fixed size or may be set to a variable size according to an instruction from the control unit 53.

[0026] The shared area 522 of each ECU 5 is used as a single virtual shared memory. Hereinafter, the ECU 5 that manages the shared memory will be referred to as the host ECU. When it is necessary to distinguish the ECUs 5 other than the host ECU, they will be referred to as ECU_A, ECU_B, ECU_C, etc.

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

[0028] The memory map 6 is used to manage the memory space of the shared memory. As shown in FIG. 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. Examples of data types include "destination," "vehicle location," "image," "driving status," "remaining battery capacity," and "downloaded update data." The storage location information includes a storage ECU and a memory address. The storage ECU is information that indicates which ECU 5's shared area 522 stores the shared data. The memory address is information that indicates the address where the shared data is stored in the shared area 522 of the storage ECU. The memory map 6 also stores unused areas (hereinafter referred to as "free areas") in the shared area 522 of each ECU 5, associated with the data type "free."

[0029] 2, for example, shared data whose data type is "destination" is stored at addresses "0x001A to 0x00FA" in the shared area 522 of ECU_A. Also, it is shown that the free area in the shared area 522 of the host ECU is at addresses "0x110C to 0x1FFF."

[0030] The control unit 53 includes a microcomputer having a CPU, ROM, RAM, etc. The various functions of the microcomputer are realized by the CPU executing a program stored in a non-transitory tangible recording medium. In this example, the ROM corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 53 may be one or more.

[0031] The control unit 53 of each ECU 5 may have functions realized by executing a program, such as an access function to shared data and an area setting function for variably setting the area sizes of the dedicated area 521 and the shared area 522.

[0032] The shared data access function is a function that sends 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 delete request for the shared data.

[0033] The area setting function is a function for arbitrarily changing the size of each of the dedicated area 521 and the shared area 522 in the storage unit 52 of the ECU 5. For example, if a situation in which the dedicated area 521 is insufficient is detected after the ECU 5 is installed in a vehicle due to a program update or the like, the area setting function may be used to reduce the shared area 522 and expand the dedicated area 521. Furthermore, if a situation in which the shared memory is insufficient is detected due to an increase in the amount of shared data due to the addition of an application program or the like, the area setting function may be used to reduce the dedicated area 521 and expand the shared area 522.

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

[0035] The data sharing function is a function for sharing the "data type" of the shared data registered in the memory map 6 with all ECUs 5 that use the shared data. For example, when new shared data is added to or deleted from the memory map 6 as a result of a new installation or update of an application program, the "data type" of the added or deleted shared data is notified to each ECU 5.

[0036] The backup function is a function for backing 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 be communicated with via the communication device 3, or an external storage device such as a USB memory connected to a USB terminal provided in the in-vehicle system 1.

[0037] The backup may be performed in an event initiated by the vehicle user or a dealer technician inspecting or repairing the vehicle, or may be performed automatically on a regular basis.

[0038] The backup may be performed by copying the shared area 522 in the memory unit 52 of each ECU 5 as is. In this case, however, it is necessary to also back up the memory map 6, which indicates what information is stored where. In this case, when restoring data based on the backup data, the data in the copied shared area 522 is restored by writing it to the same storage location as before the backup, according to the backed up memory map 6.

[0039] Backups may also be performed by reading each "data type." In this case, the storage location information is lost, so when restoring data based on backup data, the storage location may be acquired again and the data may be written to the acquired storage location for restoration.

[0040] [1-2. Sequence] The procedure for accessing shared data will be described below. In the following, the ECU 5 that requests access to shared data will be referred to as a client ECU, and the ECU 5 in which the shared data to be accessed is stored will be referred to as a target ECU.

[0041] First, the sequence for reading shared data from the shared memory will be described with reference to FIG.

[0042] In step S10, the client ECU transmits a read request to the host ECU, which indicates the type of shared data to be read.

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

[0044] In S12, the host ECU transmits a storage location notification indicating the storage location information acquired from the memory map 6 to the client ECU.

[0045] In step S13, the client ECU transmits a read request including a specified address to the target ECU in accordance with the storage location information notified by the host ECU. The target ECU is the holding ECU indicated in the storage location information, and the specified address is the memory address indicated in the storage location information.

[0046] In S14, the target ECU reads the shared data stored at the specified address from the shared area 522 of the target ECU in accordance with the received read request.

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

[0048] The read result notification is a notification indicating the execution result of accessing the shared memory. If the reading of data from the shared memory fails, the read result notification may also indicate the content of the error.

[0049] Here, a specific operation will be described with reference to the memory map 6 in FIG. 3 . For example, consider a case where "XX data" is registered in the memory map 6, and its storage location information is set to "ECU_A" as the holding ECU and "0x511 to 0x05FA" as the memory address. When the host ECU receives a read request for the "XX data," it retrieves the storage location information for the "XX data," i.e., the holding ECU "ECU_A" and the memory address "0x511 to 0x05FA," from the memory map 6 through a storage location search. The host ECU also notifies the client ECU of the retrieved storage location information. The client ECU transmits a read request to the target ECU (i.e., "ECU_A"), indicating the specified address (i.e., "0x511 to 0x05FA"). The target ECU reads the shared data in accordance with the read request, and the read shared data is transmitted to the client ECU via a read result notification. As a result of the above procedure, the client ECU can acquire the shared data identified by the data type "XX data."

[0050] Next, the sequence for writing shared data to the shared memory will be described with reference to FIG.

[0051] In S20, the client ECU transmits a write request to the host ECU, which indicates the type of shared data to be written and the size of the shared data.

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

[0053] If the shared data to be written is not registered in the memory map 6 and the host ECU is unable to obtain the storage location of the shared data, the host ECU executes S22 and then executes S23 and subsequent steps. If the shared data to be written is registered in the memory map 6 and the host ECU is able to obtain the storage location of the shared data, the host ECU executes S23 and subsequent steps without executing S22.

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

[0055] In S23, the host ECU transmits a storage location notification indicating the storage location information acquired from the memory map 6 to the client ECU.

[0056] In step S24, the client ECU transmits a write request to the target ECU, which indicates the designated address and the write data, which is the shared data to be stored at the designated address, in accordance with the storage location information notified by the host ECU. The target ECU is the holding ECU indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0057] In S25, the target ECU writes the write data to the specified address in the shared area 522 of the target ECU in accordance with the received write request.

[0058] In S26, the target ECU transmits a write result notification indicating the result of the process in S25 to the client ECU, and the series of processes ends when the client ECU receives the write result notification.

[0059] The write result notification may notify the completion of writing if the writing is successful, or may notify the content of the error if the writing is unsuccessful.

[0060] That is, 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 ECU. If the target data is not yet registered in the memory map 6, a location for storing 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 ECU.

[0061] Here, a specific operation will be described with reference to memory map 6 in FIG. 4 . For example, consider a case where "YY data" is not registered in memory map 6 and the memory addresses of the free area of ​​"ECU_A" are set to "0x0600 to 0x0FFF." Then, assume that 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 ECU in which the shared data will be stored. The host ECU reserves an area "0x0600 to 0x06FA" for "YY data" from the free area "0x0600 to 0x0FFF" of "ECU_A" shown in memory map 6, which is equivalent to the data size "FAH." The host ECU then adds an item to memory map 6 indicating that the storage location of "YY data" is the memory addresses "0x0600 to 0x06FA" of the holding ECU "ECU_A." Furthermore, the host ECU rewrites the memory addresses of the free areas of "ECU_A" to "0x06FB to 0x0FFF".

[0062] Here, the logic for determining which free area in the shared area 522 of which ECU 5 to use when registering new shared data in the memory map 6 will be described in the following (1) to (3).

[0063] (1) The host ECU may search for free areas registered in the memory map 6 and select the smallest free area that has contiguous memory addresses and is capable of storing data of the "data size" specified in the write request as the storage location. In this case, free areas with contiguous memory addresses and large data sizes can be left, so that when large data needs to be stored, the data can be stored without being divided among multiple ECUs. Note that having contiguous memory addresses means that the free area does not span at least multiple ECUs 5.

[0064] (2) When the host ECU searches for free areas registered in the memory map 6 and does not find any free areas that have consecutive memory addresses and can store data of the "data size" specified in the write request, the host ECU may select multiple free areas belonging to the same ECU 5 as storage locations. In this case, the storage locations for the shared data are not distributed among multiple ECUs 5, so that the shared data can be read easily and quickly.

[0065] (3) The host ECU may compare the free space registered in the memory map 6 for each ECU 5 and select the ECU 5 with the largest free space as the retaining ECU. In this case, the free space of each ECU 5 remains approximately equal, so that it is possible to prepare for a request from the ECU 5 to expand the dedicated area 521.

[0066] Next, the sequence for deleting shared data from the shared memory will be described with reference to FIG.

[0067] In step S30, the client ECU transmits a deletion request to the host ECU, which indicates the type and confidentiality level of the shared data to be deleted (hereinafter, "data to be deleted").

[0068] If the confidentiality level indicated in the deletion request indicates that the confidentiality level of the data to be deleted is low, steps S31 to S35 are omitted and step S36 and subsequent steps are executed, whereas if the confidentiality level indicates that the data is high, steps S31 to S35 are executed and then step S36 and subsequent steps are executed. Shared data with a high confidentiality level includes, for example, the driver's personal information.

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

[0070] In S32, the host ECU transmits a storage location notification indicating the storage location information acquired from the memory map 6 to the client ECU.

[0071] In step S33, the client ECU transmits an initialization request including a specified address to the target ECU in accordance with the storage location information notified by the host ECU. The target ECU is the holding ECU indicated in the storage location information, and the specified address is the memory address indicated in the storage location information.

[0072] In S34, the target ECU performs initialization by overwriting the memory address indicated in the initialization request with initialization data in the shared area 522 of the target ECU. The initialization data may be, for example, "00H" or "FFH."

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

[0074] In S36, the host ECU cancels the registration of the data to be deleted in the memory map 6. More specifically, the data type of the data to be deleted is rewritten to "free." If there are multiple free areas in the memory map 6 that belong to the same ECU 5 and have consecutive memory addresses, the memory map 6 may be rewritten so that these multiple free areas become a single free area.

[0075] In S37, the host ECU transmits a deletion result notification indicating the processing result for the deletion request to the client ECU, and when the client ECU receives this deletion result notification, the series of processes ends.

[0076] The deletion result notification may notify the completion of deletion if the deletion is successful, or may notify the content of the error if an error occurs during the deletion.

[0077] In other words, when deleting shared data with a low confidentiality level, only the data to be deleted is deregistered from the memory map 6, and when deleting shared data with a high confidentiality level, in addition to deregistering the data to be deleted from the memory map 6, the data in the storage location is also initialized.

[0078] Here, a specific operation will be described with reference to the memory map 6 in FIG. 5 . For example, consider a case where "ZZ data" is registered in the memory map 6, and its storage location information is set to "ECU_A" as the holding ECU and "0x511 to 0x05FA" as the memory address. The host ECU receives a deletion request for the data type "ZZ data." If the confidentiality level indicated in the received deletion request is low, the host ECU rewrites the data type in the memory map 6 from "ZZ data" to "free" to cancel the registration of the data to be deleted. Furthermore, if the host ECU receives a deletion request for the data type "ZZ data" and the confidentiality level indicated in the received deletion request is high, the host ECU performs the following process. The host ECU obtains the storage location information for the "ZZ data" from the memory map 6, i.e., the holding ECU "ECU_A" and the memory address "0x511 to 0x05FA," and notifies the client ECU. The client ECU then transmits an initialization request to the target ECU (i.e., "ECU_A") according to the notified storage location information. The initialization request indicates a specified address (i.e., "0x0511 to 0x05FA"). In response to this initialization request, the target ECU initializes the data at the specified address in the shared area 522 of the target ECU. Then, the "ZZ data" is unregistered in the memory map 6.

[0079] Next, the procedure when a client ECU requests the host ECU to release a portion of the shared area 522 used as shared memory in order to expand the dedicated area 521 in the memory unit 52 of the client ECU will be explained using Figure 6.

[0080] In S40, the client ECU transmits to the host ECU an area change request requesting reduction of the client ECU's shared area 522. The area change request indicates information indicating the client ECU that has made the request (hereinafter, the requesting ECU) and the size of the shared area 522 to be reduced from the shared memory (hereinafter, the requested size).

[0081] In S41, the host ECU searches the memory map 6 in accordance with the area change request received from the client ECU to check the free area size of the shared area 522 of the requesting ECU. Specifically, the host ECU obtains the area size (i.e., the free area size) specified by the memory address of an item in the memory map 6 whose data type is "free" and whose holding ECU is the requesting ECU. The host ECU then 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 and then executes S43. If the free area size is equal to or greater than the requested size, the host ECU executes S43 without executing S42.

[0082] In S42, the host ECU moves the shared data stored in the shared area 522 of the requesting ECU to the shared area 522 of another ECU 5 other than the requesting ECU, thereby securing a free area size equal to or larger than the requested size in the shared area 522 of the requesting ECU. Note that in Fig. 6, the sequence showing the movement of the shared data stored in the shared area 522 of the requesting ECU to the shared area 522 of another ECU 5 is not shown.

[0083] In S43, the host ECU updates the memory map 6 by rewriting the memory addresses of the free areas of the requesting ECU so that an area of ​​the requested size is released from the free areas of the requesting ECU.

[0084] In S44, the host ECU transmits an area change result notification to the client ECU, and the series of processes ends when the client ECU receives the area change result notification. If the change is successful, the area change result notification indicates the address of the area released from the shared area 522 (hereinafter referred to as the released address). The client ECU changes its settings so that the area indicated by the released address in the area change result notification can be used as the dedicated area 521.

[0085] Here, a specific operation will be described with reference to memory map 6 in Fig. 6. For example, consider a case where the ECU that has made the area change request is "ECU_A" and memory address "0x0D00 to 0x0FFF" (i.e., the free area size is "300H") is registered in memory map 6 as the free area for "ECU_A."

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

[0087] When the host ECU receives an area change request with a requested size of 400H from a client ECU, the free area size is smaller than the requested size. Therefore, the host ECU allocates free area equal to or larger than the requested size in the shared area 522 of the client ECU by moving the shared data. To allow for some leeway, the host ECU allocates a new free area 0x0B00 to 0x0CFF so that the free area size becomes 500H, and updates the memory address of the free area of ​​the requesting ECU in memory map 6 to 0x0B00 to 0x0FF. Then, the host ECU releases an area (e.g., 0x0B00 to 0x0EFF) equivalent to the requested size of 400H from the updated free area 0x0B00 to 0x0FFF. Specifically, the host ECU updates the memory address of the released free area of ​​the requesting ECU in memory map 6 to 0x0F00 to 0x0FFF. The host ECU also notifies the client ECU of the memory address of the released area (i.e., the released address).

[0088] Next, the procedure when the host ECU requests the ECU 5 selected according to a predetermined logic to change part of the dedicated area 521 to the shared area 522 in order to expand the shared memory will be described with reference to FIG. 7.

[0089] Each ECU 5 holds information about its usage status, including the area sizes of its dedicated area 521 and shared area 522, and the size of the free area in the dedicated area 521. Here, the ECU 5 selected according to the logic is called a target ECU.

[0090] In S50, the host ECU transmits to the target ECU an area expansion request requesting expansion of the target ECU's shared area 522. The area expansion request indicates the target ECU, which is information indicating the target ECU, and the size of the area to be changed from the dedicated area 521 to the shared area 522 (hereinafter referred to as the requested size).

[0091] In S51, the target ECU checks whether the free space size of the dedicated area 521 of the target ECU is equal to or larger than the requested size indicated in the area change request. If the free space size of the dedicated area 521 is smaller than the requested size, the target ECU executes S52. If the free space size of the dedicated area 521 is equal to or larger than the requested size, the target ECU executes S53 to S54.

[0092] In S52, the target ECU transmits a result notification to the host ECU indicating that there is no dedicated area 521 available for use as shared memory, and the host ECU ends the series of processes upon receiving the result notification.

[0093] In S53, the target ECU reserves a free area (hereinafter referred to as the extension area) of the requested size that can be used as shared memory from the dedicated area 521. The target ECU then updates information indicating the area sizes of the dedicated area 521 and the shared area 522 in the target ECU according to the reserved extension area. Furthermore, the target ECU transmits a result notification indicating a memory address (hereinafter referred to as the extension address) that specifies the extension area to the host ECU.

[0094] In step S54, the host ECU updates the memory map 6 in accordance with the result notification so that the extension area of ​​the target ECU is added to the shared memory, and then ends the series of processes. Specifically, the host ECU registers the extension address indicated in the result notification in the memory map 6 as an available area of ​​the target ECU.

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

[0096] [1-4. Effects] According to the first embodiment described above in detail, the following effects are achieved.

[0097] (1a) In the in-vehicle system 1, the shared area 522 provided in the multiple ECUs 5 is used as a single virtual shared memory. Therefore, by effectively utilizing the free area of ​​each ECU 5, it is possible to have a large-capacity shared memory without placing an excessive load on any one specific ECU 5.

[0098] (1b) In the in-vehicle system 1, by using an area change request and an area expansion request, the allocation of area sizes between the dedicated area 521 and the shared area 522 can be changed in each ECU 5. Therefore, if the dedicated area 521 becomes insufficient due to a function upgrade or the like in each ECU 5, a part of the shared area 522 used as shared memory can be changed to the dedicated area 521. Furthermore, to resolve the shortage of shared memory, a part of the dedicated area 521 can be changed to the shared area 522. In other words, if a memory shortage occurs, it can be flexibly addressed by changing the area sizes of the dedicated area 521 and the shared area 522 without adding memory in hardware.

[0099] (1c) In the in-vehicle system 1, the shared data stored in the shared memory can be backed up to the cloud server 9 or an external storage device that is detachable from the in-vehicle system 1. Therefore, even if an ECU fails and is replaced, the backed-up past data can be used to restore the state before the failure.

[0100] (1d) When the in-vehicle system 1 deletes 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 unnecessary personal information is not left in the storage unit 52, thereby improving the security of the in-vehicle system 1. Furthermore, for information with a low confidentiality level, it is only necessary to operate the memory map 6, thereby simplifying the process.

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

[0102] In the first embodiment described above, when accessing the shared memory, the client ECU acquires storage location information from the host ECU and uses the acquired storage location information to access the shared area 522 of the target ECU. The second embodiment differs from the first embodiment in that the host ECU accesses the shared area 522 of the target ECU.

[0103] [2-2. Sequence] The procedure when a client ECU accesses shared data will be described.

[0104] First, the sequence for reading shared data from the shared memory will be described with reference to FIG.

[0105] S60 to S61 are the same as S10 to S11 described with reference to FIG.

[0106] In S62, the host ECU transmits a read request indicating the specified address to the target ECU in accordance with the storage location information obtained from the memory map 6. The target ECU is the holding ECU indicated in the storage location information, and the specified address is the memory address indicated in the storage location information.

[0107] In S63, the target ECU reads the shared data stored at the specified address from the shared area 522 of the target ECU in accordance with the received read request.

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

[0109] In S65, the host ECU transfers the read result notification received from the target ECU to the client ECU, and the client ECU receives the read result notification, thereby completing the series of processes.

[0110] Next, the sequence for writing shared data to the shared memory will be described with reference to FIG.

[0111] S70 to S72 are the same as S20 to S22 described with reference to Fig. 4. However, the write request sent in S70 includes write data to be stored in the shared memory.

[0112] In S73, the host ECU transmits a write request indicating the designated address and the write data, which is the shared data to be stored at the designated address, to the target ECU in accordance with the storage location information acquired from the memory map 6. The target ECU is the holding ECU indicated in the storage location information, and the designated address is the memory address indicated in the storage location information.

[0113] In S74, the target ECU writes the write data to the specified address in the shared area 522 of the target ECU in accordance with the received write request.

[0114] In S75, the target ECU transmits a write result notification indicating the result of the process in S74 to the host ECU.

[0115] In S76, the host ECU transfers the write result notification received from the target ECU to the client ECU, and the client ECU receives the write result notification, thereby completing the series of processes.

[0116] Next, the sequence for deleting designated shared data from the shared memory will be described with reference to FIG.

[0117] S80 to S81 are the same as S30 to S31 described with reference to FIG.

[0118] 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, S81 to S84 are omitted and S85 and subsequent steps are executed, and if the confidentiality level is high, S81 to S84 are executed and then S85 and subsequent steps are executed.

[0119] In S82, the host ECU transmits an initialization request with a specified address to the target ECU in accordance with the storage location information acquired from the memory map 6. The target ECU is the holding ECU indicated in the storage location information, and the specified address is the memory address indicated in the storage location information.

[0120] In S83, the target ECU performs initialization by overwriting the initialization data at a specified address in the shared area 522 of the target ECU in accordance with the received initialization request.

[0121] In S84, the target ECU transmits an initialization result notification indicating the processing result in S83 to the host ECU.

[0122] S85 and S86 are the same as S36 and S37 described with reference to FIG.

[0123] [2-3. Effects] According to the second embodiment described above in detail, in addition to the effects (1a) to (1d) of the first embodiment described above, the following effects are also achieved.

[0124] (2a) In the in-vehicle system 1 of the second embodiment, the host ECU accesses the target ECU based on the storage location information acquired from the memory map 6. Therefore, compared to when the client ECU acquires the storage location information from the host ECU and accesses the target ECU, the procedure is simplified and the amount of communication within the system can be reduced.

[0125] 3. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modifications.

[0126] (3a) Although the in-vehicle system 1 described in the above embodiment has one host ECU, two or more host ECUs may be present. For example, as shown in FIG. 11 , in-vehicle system 1a, multiple domain ECUs 5a are connected to a main network 7a, and each of the multiple domain ECUs 5a is connected to multiple controlled ECUs 5b via a sub-network 7b. In other words, the multiple ECUs 5a, 5b are classified into multiple domains, each of which forms a sub-network. In this case, each domain ECU 5a may be set as a host ECU, and shared data may be managed for each domain. In addition to the in-vehicle communication unit 51, storage unit 52, and control unit 53 of the ECU 5 of the in-vehicle system 1, the domain ECU 5a may also include an intra-domain communication unit 54. The controlled ECU 5b may also include an intra-domain communication unit 54 instead of the in-vehicle communication unit 51 of the ECU 5 of the in-vehicle system 1. The intra-domain communication unit 54 performs communication via the sub-network 7b.

[0127] (3b) In the in-vehicle system 1a, when a single shared memory is managed by the entire system, the host ECU may use the following logic when selecting a holding ECU to serve as a storage location for newly registering unregistered shared data in the memory map 6. That is, when an access request is received from a client ECU, an ECU belonging to the same domain as the client ECU may be selected as the holding ECU. In this case, access to the shared data can be achieved without going through a complex communication path, thereby reducing errors related to accessing the shared data and improving system reliability.

[0128] (3c) In the above embodiment, when shared data is deleted from shared memory, whether or not to initialize the data in the storage location is determined based on the confidentiality level. However, instead of the confidentiality level, information that directly indicates whether or not initialization is required may be used.

[0129] (3d) The control unit 53 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit 53 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit 53 and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium. The method for implementing the functions of each unit included in the control unit 53 does not necessarily need to include software; all of the functions may be implemented using one or more hardware.

[0130] (3e) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0131] (3f) The present disclosure may be realized in various forms, including a host ECU as the shared memory management device described above, a system including the shared memory management device as a component, a program for causing a computer to function as the shared memory management device, a non-transient physical recording medium such as a semiconductor memory on which the program is recorded, and a shared memory management method.

[0132] [4. Technical Ideas Disclosed in the Present Specification] [Item 1] An in-vehicle system comprising: a plurality of electronic control units (5, 5a, 5b) connected via an in-vehicle communication network (7, 7a, 7b), each of the electronic control units having a dedicated area (521) that is a memory dedicated to the electronic control unit and a shared area (522) that is a memory shared by the plurality of electronic control units; a map storage unit (52) configured to virtually treat the shared area owned by the plurality of electronic control units as a single shared memory and to store a memory map (6) that associates storage location information that indicates a storage location of data in the shared memory with a data type that is information that identifies data stored in the storage location indicated by the storage location information; and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured, upon receiving an access request for the shared memory, to use the memory map to obtain the storage location information related to an access target indicated in the access request.

[0133] [Item 2] The in-vehicle system according to item 1, wherein the electronic control unit including the map storage unit and the memory management unit is a host device, and the electronic control unit that is the source of the access request is a client device, and the host device is configured to access the shared memory based on the storage location information acquired by the memory management unit and notify the client device of the execution result.

[0134] [Item 3] The in-vehicle system according to item 1, wherein the electronic control unit including the map storage unit and the memory management unit is a host device, the electronic control unit 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 executes access to the shared memory using the storage location information notified by the host device.

[0135] [Item 4] The in-vehicle system according to item 2 or 3, wherein the host device is configured to execute a backup of transferring the contents of the shared memory to a specified backup destination.

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

[0137] [Item 6] The in-vehicle system according to any one of items 2 to 5, wherein the electronic control device is configured to, when changing the area sizes of the dedicated area and the shared area, send an area change request indicating the changes to the area sizes to the host device (S40), and the host device is configured to update the contents of the memory map in accordance with the changes indicated in the area change request (S43).

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

[0139] [Item 8] The in-vehicle system according to any one of items 2 to 7, wherein when deleting data from the shared memory, the in-vehicle system is configured to, depending on the confidentiality level of the data to be deleted, cancel the registration of the data to be deleted from the memory map if the confidentiality level is low, and to cancel the registration of the data to be deleted from the memory map and initialize data of a storage location of the data to be deleted if the confidentiality level is high.

[0140] [Item 9] The in-vehicle system according to any one of items 2 to 8, wherein the host device is configured to, when registering data in the memory map, allocate the storage locations of the data to be registered, which is the data to be registered, so that the storage locations do not span multiple electronic control devices.

[0141] [Item 10] The in-vehicle system according to Item 9, wherein when registering data in the memory map, the host device is configured to allocate, as a storage location for the data to be registered, the free area in the shared memory that has consecutive addresses and that has the smallest area size among the free areas that can store the data to be registered.

[0142] [Item 11] An in-vehicle system according to any one of items 2 to 10, wherein the plurality of electronic control units are classified into a plurality of domains, the in-vehicle communication network has a sub-network formed for each of the domains, and when registering data in the memory map, the host device is configured to assign the shared area of ​​the electronic control unit that belongs to the same domain as the client device, which is the electronic control unit that requested the registration, as a storage location for the data to be registered.

[0143] [Item 12] The in-vehicle system according to any one of items 2 to 10, wherein the electronic control units are classified into a plurality of domains, the in-vehicle communication network has a sub-network formed for each of the domains, and the host device is provided for each of the domains and configured to manage the shared memory for each of the domains.

[0144] [Item 13] The in-vehicle system according to any one of items 1 to 12, wherein the access request includes any one of a data write request, a data read request, and a data deletion request.

[0145] [Item 14] A shared memory management device comprising: a map storage unit (52) configured to store a memory map (6) that associates storage location information indicating a storage location of data in the shared memory with a data type that is information identifying the shared data stored in the storage location indicated by the storage location information, using a shared area (522) set in a memory of each of a plurality of electronic control devices connected via an in-vehicle communication network as a single virtual shared memory; and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured, upon receiving an access request for the shared memory, to use the memory map to obtain the storage location information related to the access target indicated in the access request.

[0146] [Item 15] A shared memory management method comprising: treating a shared area set in a memory possessed by each of a plurality of electronic control devices connected via an in-vehicle communication network as a single virtual shared memory; using a memory map that associates storage location information indicating a storage location of shared data in the shared memory with a data type that is information identifying the shared data stored in the storage location indicated by the storage location information; and, upon receiving an access request for the shared memory, using the memory map to obtain the storage location information related to the access target indicated in the access request.

Claims

1. An in-vehicle system comprising a plurality of electronic control units (5, 5a, 5b) connected via an in-vehicle communication network (7, 7a, 7b), each of which has a dedicated area (521) that is a memory dedicated to that electronic control unit and a shared area (522) that is a memory shared by the plurality of electronic control units, a map storage unit (52) configured to virtually treat the shared area owned by the plurality of electronic control units as a single shared memory and to store a memory map (6) that associates storage location information indicating a storage location of data in the shared memory with a data type that is information identifying data stored in the storage location indicated by the storage location information, and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured to, upon receiving an access request for the shared memory, use the memory map to obtain the storage location information related to the access target indicated in the access request.

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

3. An in-vehicle system as claimed in claim 1, wherein the electronic control unit comprising the map storage unit and the memory management unit is a host device, the electronic control unit 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 executes access to the shared memory using the storage location information notified by the host device.

4. An in-vehicle system according to claim 2 or 3, wherein the host device is configured to execute a backup to transfer the contents of the shared memory to a designated backup destination.

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

6. An in-vehicle system according to claim 2 or claim 3, wherein the electronic control device is configured to, when changing the area sizes of the dedicated area and the shared area, send an area change request indicating the changes to the area sizes to the host device (S40), and the host device is configured to update the contents of the memory map in accordance with the changes indicated in the area change request (S43).

7. An in-vehicle system as claimed in claim 2 or claim 3, wherein the host device, when it is necessary to expand the shared memory, sends an area expansion request to each of the electronic control devices (S50); when the electronic control device receives the area expansion request, if there is free space in the dedicated area, it sends an area change result notification to the host device indicating that the area size will be changed so that part of the free space becomes the shared area (S53); and the host device updates the contents of the memory map in accordance with the area change result notification (S54).

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

9. An in-vehicle system according to claim 2 or claim 3, wherein the host device is configured to allocate storage locations for the data to be registered, that is, the data to be registered, so that the storage locations do not span multiple electronic control devices when registering data in the memory map.

10. An in-vehicle system according to claim 9, wherein the host device is configured to, when registering data in the memory map, allocate the smallest free area of ​​the free areas in the shared memory that have consecutive addresses and are capable of storing the data to be registered as the storage location for the data to be registered.

11. An in-vehicle system as claimed in claim 2 or claim 3, wherein the plurality of electronic control units are classified into a plurality of domains, the in-vehicle communication network has a sub-network formed for each of the domains, and the host device is configured, when registering data in the memory map, to assign the shared area of ​​the electronic control unit belonging to the same domain as the client device, which is the electronic control unit that requested the registration, as a storage location for the data to be registered.

12. An in-vehicle system according to claim 2 or claim 3, wherein the plurality of electronic control units are classified into a plurality of domains, the in-vehicle communication network has a sub-network formed for each of the domains, and the host device is provided for each of the domains and configured to manage the shared memory for each of the domains.

13. An in-vehicle system according to any one of claims 1 to 3, wherein the access request includes any one of a data write request, a data read request, and a data deletion request.

14. A shared memory management device comprising: a map storage unit (52) configured to store a memory map (6) that associates storage location information indicating a storage location of data in a shared memory with a data type that is information identifying the shared data stored in the storage location indicated by the storage location information, with the shared memory area (522) set in the memory of each of a plurality of electronic control devices connected via an in-vehicle communication network being treated as a single virtual shared memory; and a memory management unit (53: S11, S21, S31, S61, S71, S81) configured to, upon receiving an access request for the shared memory, use the memory map to obtain the storage location information related to the access target indicated in the access request.

15. A shared memory management method that treats a shared area set in the memory of each of multiple electronic control devices connected via an in-vehicle communication network as a single virtual shared memory, uses a memory map that associates storage location information indicating the storage location of shared data in the shared memory with a data type that is information that identifies the shared data stored in the storage location indicated by the storage location information, and, when an access request for the shared memory is received, uses the memory map to obtain the storage location information for the access target indicated in the access request.

Citation Information

Patent Citations

  • Memory utilizing system

    JP1993265844A

  • Electronic control device

    JP2019067236A

  • Network load reducing method and node structure for multiprocessor system with distributed memory

    US20110153958A1