Security function management device, security function management method, and security function management program

Abstract

This invention provides a security function management device method and program for managing the execution of security functions of an electronic control unit (ECU) mounted on a mobile device. [Solution] A security function management device 10 for managing the execution of a first function (security function) includes a resource requirement acquisition unit 102 that acquires the resource requirement amount for one or more second functions different from the first function that can be executed by the ECU, a usage acquisition unit 103 that acquires the usage level of the second function, a resource determination unit 106 that determines whether or not the ECU's resources are insufficient when executing the first function when the execution of the first function is required, and an instruction unit 108 that outputs an execution instruction for the first function and an execution instruction for the selected second function, which is an instruction to release the resources currently being consumed by the second function, based on the usage level and resource requirement amount of the second function when resources are insufficient.

Description

Technical Field

[0001] The present invention relates to a security function management device, a security function management method, and a security function management program for managing the execution of the security function of an electronic control device mounted on a moving body such as a vehicle.

Background Art

[0002] In recent years, vehicles have multiple electronic control units, which communicate and cooperate with each other via an in-vehicle network. Also, with the development of wireless communication technology and wireless communication network technology, communication technologies connecting vehicles to the outside, such as V2X and connected cars, have become widespread, so the cases where a network connecting an external network and an in-vehicle network is formed are increasing. Therefore, it has become possible to download software and programs that implement various functions according to the user's selection, etc. from an external provider or a central device into the vehicle by OTA (Over The Air) or the like, and further install or update them in each electronic control unit via the in-vehicle network. As such, while it has become easier to add functions and update functions to electronic control units, the possibility of various cyberattacks on the vehicle from outside the vehicle, such as unauthorized tampering of programs and stealing of confidential data, has increased. Against this background, cyber security countermeasures in vehicles are necessary.

[0003] Patent Document 1 discloses a monitoring device that monitors an abnormal state of a first monitoring target, comprising a receiving unit that receives an abnormal detection result by another monitoring device that monitors an abnormal state of a second monitoring target different from the first monitoring target, and a control unit that changes the processing executed by the monitoring device according to the abnormal detection result by the other monitoring device.

[0004] Thereby, by notifying each other of the states of the monitoring targets detected by the plurality of monitoring devices, each monitoring device can appropriately execute data processing related to the security of the vehicle, and can also appropriately adjust or change the mode of that data processing. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2019-047177 [Overview of the project] [Problems that the invention aims to solve]

[0006] Here, the inventors identified the following problem. To counter an attack on an electronic control unit, it is necessary to run a program equipped with security functions (hereinafter referred to as "security functions") on the electronic control unit to appropriately respond to the attack. However, if the electronic control unit is already running or has many functions installed, there may be insufficient resources on the electronic control unit to run a new program with security functions, in which case the security functions cannot be executed. Furthermore, if resources are freed up by indiscriminately stopping or deleting functions already running or installed on the electronic control unit in order to resolve resource shortages when executing security functions, it may result in users being unable to use functions they want or expect to use on the electronic control unit.

[0007] Therefore, the present invention aims to enable the electronic control unit to perform security functions against attacks by appropriately securing resources even when the electronic control unit's resources are insufficient. [Means for solving the problem]

[0008] A security function management device according to one aspect of this disclosure is a security function management device that manages the execution of a first function which is a security function of an electronic control device mounted on a mobile body, Resource requirement acquisition unit (102) acquires resource requirement amounts, which are the amounts of resources required for one or more second functions different from the first function that can be executed by the electronic control unit, A usage level acquisition unit (103) acquires a usage level indicating the degree to which each of the second functions described above has been used, If an attack is detected and the execution of the first function is required, a resource determination unit (106) determines whether the resources of the electronic control unit will be insufficient to execute the first function based on the resource requirements of the second function, If the electronic control unit determines that the resources are insufficient, it selects a second function to release the resources currently being consumed, based on the usage and resource requirements of each of the second functions, The electronic control unit has an instruction unit (108) that outputs an instruction to execute the first function and an instruction to release the resources currently being consumed by the second function selected by the selection unit.

[0009] The numbers in parentheses attached to the claims and the constituent elements of the invention described in this section indicate the correspondence between the present invention and the embodiments described later, and are not intended to limit the present invention. [Effects of the Invention]

[0010] With the above configuration, the security function management device of the present invention can secure resources for the electronic control unit to execute security functions while retaining functions that are likely to be used by the user. [Brief explanation of the drawing]

[0011] [Figure 1] This figure shows an example configuration of a security function management system common to embodiments of this disclosure. [Figure 2] A diagram showing a common main hardware configuration example of the embodiments of this disclosure. [Figure 3]Diagram for explaining the relationship between resources and functions of an electronic control device in an embodiment of the present disclosure [Figure 4] Diagram showing the configuration of a security function management device in an embodiment of the present disclosure [Figure 5] Diagram for explaining the resource requirements acquired by a resource requirement acquisition unit in an embodiment of the present disclosure [Figure 6] Diagram for explaining the usage and priority acquired by a usage acquisition unit in an embodiment of the present disclosure [Figure 7] Diagram for explaining a specific operation example of a resource determination unit and a release function selection unit in an embodiment of the present disclosure [Figure 8] Diagram showing the configuration of an electronic control device in an embodiment of the present disclosure [Figure 9] Flowchart showing the operation of a security function management device in an embodiment of the present disclosure [Figure 10] Flowchart showing the operation of a security function management device in an embodiment of the present disclosure [Figure 11] Flowchart showing the operation of an electronic control device in an embodiment of the present disclosure [Figure 12] Diagram showing usage and priority in Embodiment 2 of the present disclosure [Figure 13] Diagram showing usage and priority in Embodiment 3 of the present disclosure

Mode for Carrying Out the Invention

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

[0013] Note that the present invention means the invention described in the claims or the section of means for solving the problems, and is not limited to the following embodiments. Also, at least the words in parentheses mean the words described in the claims or the section of means for solving the problems, and are not limited to the following embodiments either.

[0014] The configurations and methods described in the dependent claims are optional configurations and methods in the invention described in the independent claims. The configurations and methods in embodiments corresponding to the configurations and methods described in the dependent claims, as well as configurations and methods described only in embodiments and not in the claims, are optional configurations and methods in the present invention. The configurations and methods described in embodiments when the claims are broader than the descriptions in embodiments are also optional configurations and methods in the present invention, in the sense that they are illustrative examples of the configurations and methods of the present invention. In any case, by describing them in the independent claims, they become essential configurations and methods of the present invention.

[0015] The effects described in the embodiments are those that occur when the configuration is that of an exemplary embodiment of the present invention, and are not necessarily effects that the present invention possesses.

[0016] When there are multiple embodiments, the components disclosed in each embodiment are not confined to that embodiment alone, but can be combined across embodiments. For example, the components disclosed in one embodiment may be combined with those in another embodiment. Alternatively, components disclosed in multiple embodiments may be collected and combined. The same applies to modifications and examples.

[0017] The problems described in the section on the problems that the invention aims to solve are not publicly known problems, but rather problems that the inventors have discovered independently, and together with the structure and method of the present invention, these facts affirm the inventive step of the invention.

[0018] 1. Configuration and functions common to each embodiment (1-1) Overall configuration of the security function management system Figure 1 illustrates an example of the arrangement of an electronic control unit (ECU) 20 and a security function management device 10 in an electronic control system S mounted on a vehicle.

[0019] In each embodiment, the electronic control system S and the ECU 20, which is an "electronic control unit" that constitutes it, are "mounted" on a vehicle, which is a "mobile body". Here, A "moving object" refers to any object that can move, regardless of its speed. It also includes objects that are stationary. Examples include, but are not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and items carried on them. "Mounted" includes not only cases where the item is directly fixed to the moving object, but also cases where it is not fixed to the moving object but moves along with it. Examples include cases where the item is carried by a person riding on the moving object, or where it is mounted on cargo placed on the moving object. The term "electronic control device" may refer to a physically independent electronic control device, or a virtualized electronic control device implemented using virtualization technology.

[0020] The electronic control system S consists of multiple ECUs 20 and an in-vehicle network connecting them. Figure 1 shows eight ECUs (ECU20a to ECU20h) as an example, but naturally, the electronic control system S can consist of any number of ECUs. In the following explanation, when describing the entire electronic control unit, one or more units are referred to as ECU20 or each ECU20, and when describing individual electronic control units, they are referred to as ECU20a, ECU20b, ECU20c, ...

[0021] In the case of Figure 1, each ECU 20 is connected via an in-vehicle communication network such as CAN (Controller Area Network), CAN_FD (CAN with Flexible Datarate), LIN (Local Interconnect Network), or FlexRay (registered trademark). Alternatively, they may be connected using any communication method, whether wired or wireless, such as MOST (Media Oriented System Transport) (registered trademark), Ethernet (registered trademark), Wi-Fi (registered trademark), or Bluetooth (registered trademark). Furthermore, "connection" refers to a state in which data can be exchanged, and includes not only cases where different hardware is connected via a wired or wireless communication network, but also cases where virtual ECUs (also called virtual machines) implemented on the same hardware are virtually connected to each other.

[0022] The electronic control system S shown in Figure 1 includes an integrated ECU 20a, an external communication ECU 20b, zone ECUs (20c, 20d), and individual ECUs (20e to 20h).

[0023] The integrated ECU 20a is an ECU that has the function of controlling the entire electronic control system S, as well as a gateway function that mediates communication between each ECU 20. The integrated ECU 20a is sometimes called a gateway ECU (G-ECU) or a mobility computer (MC). The integrated ECU 20a may also be a relay device or a gateway device.

[0024] The external communication ECU 20b is an ECU that has a communication unit for communicating with an external device 30 located outside the vehicle. The communication method used by the external communication ECU 20b is the wireless communication method or wired communication method described later. Furthermore, to implement multiple communication methods, multiple external communication ECUs 20b may be provided. Alternatively, instead of providing external communication ECUs 20b, the integrated ECU 20a may incorporate the functions of the external communication ECUs 20b. In addition, individual ECUs (20e to 20h) may have their own communication functions.

[0025] Zone ECUs (20c, 20d) are gateway-function ECUs appropriately positioned according to the location and function of the individual ECUs (20e~20h). For example, Zone ECU 20c is an ECU that has a gateway function to mediate communication between individual ECUs 20e and 20f located at the front of the vehicle and other ECUs 20, and Zone ECU 20d is an ECU that has a gateway function to mediate communication between individual ECUs 20g and 20h located at the rear of the vehicle and other ECUs 20.

[0026] Individual ECUs (20e~20h) can be composed of ECUs with any function. Examples include drivetrain electronic control units that control the engine, steering wheel, brakes, etc., vehicle system electronic control units that control meters, power windows, etc., information system electronic control units such as navigation systems, or safety control system electronic control units that perform control to prevent collisions with obstacles or pedestrians. In addition, the ECUs 20 may not be in parallel, but may be classified as master and slave units.

[0027] The security function management device 10 is a device that manages the execution of the security functions (corresponding to the "first function") of each ECU 20 of the electronic control system S. The security function management device 10 may be installed either inside or outside the electronic control system S.

[0028] For example, the security function management device 10 can be implemented in any ECU 20 mounted on the vehicle. For example, since the security function management device 10 is involved in the overall control of the electronic control system S, it is desirable to implement it in an integrated ECU 20a that manages each ECU 20, as shown in Figure 1. However, this does not prevent implementation in zone ECUs (20c, 20d) or individual ECUs (20e~h). Nor does it prevent implementation in multiple ECUs 20. In each embodiment, the case in which the security function management device 10 is implemented in an integrated ECU 20a will be described as an example.

[0029] Alternatively, the security function management device 10 can be implemented as a server device installed outside the vehicle, as shown in the external device 30 in Figure 1. The external device 30 and the external communication ECU 20b of the electronic control system S are connected using either a wired or wireless communication method. Examples of wired communication methods include the Internet, fixed telephone lines, and Ethernet®. Examples of wireless communication methods include IEEE 802.11 (Wi-Fi®), IEEE 802.16 (WiMAX®), W-CDMA (Wideband Code Division Multiple Access), HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution), LTE-A (Long Term Evolution Advanced), 4G, and 5G. Other methods such as DSRC (Dedicated Short Range Communication), BLE (Bluetooth Low Energy), or Bluetooth® may also be used. The choice of communication method should be based on factors such as the location where the external device 30 is installed and the distance between the external device 30 and the electronic control system S.

[0030] The electronic control units managed by the security function management device 10 are each ECU 20 capable of executing security functions (corresponding to the "first function"). In Figure 1, all of the integrated ECU 20a, external communication ECU 20b, zone ECUs (20c, 20d), and individual ECUs (20e to 20h) are included. Specific examples of security functions will be described in detail in Embodiment 1. Note that the security function management device 10 and the ECU 20 to be managed may be the same ECU. In other words, if the security function management device 10 is implemented as an integrated ECU 20a, then the ECU 20 to be managed will also include the integrated ECU 20a. The security function management device 10 and the electronic control device to be managed together are referred to as the security function management system.

[0031] The ECUs 20 managed by the security function management device 10 are devices on which users of mobile vehicles can install software, as described later. For example, information-based electronic control devices such as IVI (In-Vehicle-Information) fall into this category.

[0032] (1-2) Main Hardware Configuration Figure 2 shows the main hardware configuration of the ECU20. The ECU20 consists of a processor 21, ROM 22, RAM 23, storage 24, communication circuit 25, and other hardware 26.

[0033] The processor 21 is a processing and calculation device that executes programs to realize the various functions of the ECU 20. It may be a CPU (Central Processing Unit), a DSP (Digital Signal Processor), a GPU (Graphics Processing Unit), or an LSI with a built-in AI core. It may also be an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array) that includes the functions of a processor such as a CPU.

[0034] ROM22 (Read Only Memory) is a read-only memory device, but the one used as a resource in the present invention, as described later, is a memory that can be erased and read / written, such as FlashROM (corresponding to a "non-volatile storage medium"). ROM22 mainly stores programs, authentication information, etc.

[0035] RAM23 (Random Access Memory) is a memory device that can be erased and read / written (equivalent to a "volatile storage medium"). RAM23 stores parts of the program code, working data used by the program, or other temporary data during program execution. RAM23 can be either DRAM (Dynamic Random Access Memory) or SRAM (Static Random Access Memory).

[0036] Storage 24 refers to memory devices with large storage capacity (equivalent to "non-volatile storage media"). This includes easily removable and portable memory devices, such as SSDs (Solid State Drives), USB (Universal Serial Bus) memory, and HDDs (Hard Disk Drives).

[0037] The communication circuit 25 communicates with the security function management device 10 and other ECUs 20 via the in-vehicle communication bus.

[0038] Other hardware 26 includes digital and analog circuits around the processor, as well as hardware necessary for the functions implemented by the ECU 20. For example, it may include HMIs such as displays and touch panels, GNSS (Global Navigation Satellite System) such as GPS, sensors such as cameras, or their control circuits, or communication devices with external devices such as wireless communication.

[0039] In the actual hardware of the ECU20, it may be a System on a Chip (SOC) in which all or part of the processor 21, ROM 22, RAM 23, etc., are integrated onto a single semiconductor chip.

[0040] The above describes the main hardware configuration of the ECU20, but the hardware configuration of the security function management device 10 can be the same.

[0041] (1-3) Resources and functions of electronic control devices Next, we will describe the resources and functions of the ECU20.

[0042] The resources of the ECU20 refer to the computer resources necessary for the ECU20 to realize various functions, and may include both physical and virtual resources. Examples include resources that perform calculations and data processing according to program code, and resources that temporarily or long-term store program code and data. Specifically, in the case of the ECU20 in Figure 2, the processor 21, ROM 22, RAM 23, and storage 24 are considered resources.

[0043] On the other hand, the function of the ECU20 is a specific role or capability that is realized by consuming the resources of the ECU20 through the execution of programs included in the software. Functions are not necessarily limited to those executed by the entire program; some functions may be realized by the execution of at least a part of the program. For example, car navigation is a function that is realized by the execution of the entire car navigation system program, while generating a guidance route to the destination is a function that is realized by the execution of a part of the program of that navigation system.

[0044] The functions of the ECU20 can be broadly categorized into two types, depending on the role of the ECU. One essential function is a required function. Essential functions are those that are necessary for the ECU20 to fulfill its intended purpose and role. For example, for an information-related ECU20, car navigation, car audio, and security functions may be considered essential functions. Another type is additional functionality. Additional functionality refers to features that are added according to the user's preferences, and can be features that the ECU20 offers as selectable options or features that the user installs themselves via the internet, etc. In the latter case, third-party applications would be considered additional functionality. For example, in the case of an information-based ECU20, this could include a browser, SNS (Social Networking Service), games, streaming service platforms for movies, a scheduler, etc.

[0045] Figure 3 shows the relationship between the resources and functions of ECU20. In Figure 3, the resource shown is the processor 21 (A), the resource in (B) is the ROM 22, and the resource in (C) is the RAM 23. In each case, the diagram illustrates the percentage of resources consumed by each function when the maximum processing capacity or capacity is set to 100%.

[0046] For example, suppose additional functions A1, A2, and A3, and essential functions I1 and I2 are installed. In this case, the ROM22 consumes resources because the software for each of these functions is stored in ROM22.

[0047] When additional functions A1 and A2, and essential functions I1 and I2 are being executed, the programs with their respective functions are deployed and executed in RAM 23 and processor 21. In this case, the resources of RAM 23 and processor 21 are not consumed for additional function A3, which is installed but not being executed. Note that for processor 21 and RAM 23, resource consumption fluctuates depending on the software execution state, but Figure 3 shows the maximum consumption.

[0048] Thus, if the types of functions installed in ECU20 and their execution status are known, the resource requirements for each resource in ECU20 are known. Therefore, by notifying the security function management device 10 of the resource requirements for each resource, ECU20 can determine how much of each resource in ECU20 is being consumed by the security function management device 10.

[0049] Regarding resource consumption, both essential and optional functions consume resources equally. However, as will be explained later, when ECU20 needs to release resources from other functions in order to execute a new security function, optional functions take precedence over essential functions as candidates for resource release.

[0050] 2. Embodiment 1 (2-1) Configuration of the security function management device of Embodiment 1 The configuration of the security function management device 10 of Embodiment 1 will be described using Figure 4.

[0051] The security function management device 10 consists of a communication unit 101, a resource requirement acquisition unit 102, a usage acquisition unit 103, an attack detection unit 104, a security function execution necessity determination unit 105, a resource determination unit 106, an open function selection unit 107, and an instruction unit 108.

[0052] The communication unit 101 communicates with each ECU 20 of the electronic control system S. It also communicates with external devices 30, etc., via the communication ECU 20b.

[0053] The resource requirement acquisition unit 102 acquires the resource requirement, which is the amount of resources required by the functions that can be executed by the ECU 20. In particular, in this embodiment, it acquires from the managed ECU 20 the amount of resources required by each of the one or more second functions that are different from the first function, which is a security function executed by the ECU 20. The resource requirement is acquired separately for each type of resource.

[0054] Figure 5 shows an example of a resource requirement table that records the resource requirements for each function acquired by the resource requirement acquisition unit 102. In this example, the resource type is RAM 23, and it shows the size of the software stored in the RAM of the ECU 20. The resource requirements shown in Figure 5 are normalized with the maximum memory capacity set to 100%. For example, if the maximum memory capacity of RAM23 is 10GB and the resource requirement for function A2 is 1GB, the resource requirement will be 10%. Although Figure 5 shows only RAM 23 as a resource, the resource requirements for other types of resources, such as the processor 21 and ROM 22, may also be obtained at the same time.

[0055] Resource requirements can be acquired either when an event occurs or periodically. Examples of the former include when an attack is detected, or when the IG is turned ON or OFF. An example of the latter is acquiring the requirements at predetermined intervals, such as every 10 minutes. Furthermore, the acquisition timing may differ depending on the type of resource. For example, the processor 21 may be acquired every 10 minutes, the RAM 23 when the program for each function is started, and the ROM 22 when software is downloaded, depending on when each resource is consumed or when the state of each resource changes.

[0056] As shown by the dotted line in Figure 5, the resource requirement acquisition unit 102 may acquire, in addition to the resource requirement for the second function, the resource requirement for the first function, whose execution necessity is determined by the security function execution necessity determination unit 105 described later. For example, if there have been instances in the past where function I3, which is the first function, consumed resources in the ECU 20, the amount of resources consumed may be acquired as the resource requirement. Alternatively, the resource requirements for function I3 may be obtained via communication from an external server or other provider of the first function.

[0057] The usage acquisition unit 103 "acquires" a "usage level" that indicates the degree to which each of the second functions has been used. Here, "Usage level" simply means that the degree to which something has been used can be quantitatively evaluated, for example, usage time, number of uses (including number of activations), usage percentage, etc. In addition to numerical values, symbols or other classifications may also be used. "To acquire" includes not only acquiring data by receiving it from another device, but also acquiring data by generating it oneself.

[0058] Figure 6 shows specific examples of the usage level of each function. For example, the ECU 20 may pre-measure the usage of each of the second functions, create a usage table as shown in Figure 6, and send it to the security function management device 10, which then receives it. Alternatively, the ECU 20 may send a startup flag to the security function management device 10 each time each of the second functions is activated, and the security function management device 10 may receive and aggregate these flags to create a usage table as shown in Figure 6.

[0059] Any method can be used to calculate the usage rate. For example, the usage rate shown in Figure 6 is a normalized value obtained by dividing the usage time of each function within a predetermined time in the ECU20 by the total usage time of all functions. The usage time can be determined from the time the user started and ended the function.

[0060] Furthermore, in the example in Figure 6, a priority is assigned to release resources based on their usage. In this example, the lower the usage, the higher the priority.

[0061] Furthermore, since the usage rate is obtained to determine the priority when selecting a function to release resources, as will be explained later, it is sufficient to obtain it only for the additional functions among the second functions. In other words, it is not usually considered necessary to release resources for the essential functions of ECU20. In the example in Figure 6, the usage rate is not obtained for essential functions I1 and I2.

[0062] The attack detection unit 104 detects cyberattacks against its own vehicle or other vehicles. Examples of attacks include attacks that exploit vulnerabilities in the in-vehicle communication bus protocol to infiltrate the network and generate malicious data packets, and attacks that illegally tamper with software or firmware.

[0063] A known method can be used to detect an attack on the vehicle. For example, one method is to analyze logs generated by the security sensors of each ECU 20 to detect anomalies, or to detect anomalies from the contents and transmission intervals of CAN frames transmitted by each ECU 20. Alternatively, the attack may be detected by analysis performed by a center device installed outside the vehicle, rather than within the electronic control system S. In this case, the attack detection unit 104 detects the attack by receiving an attack occurrence notification from the center device. Furthermore, when the attack detection unit 104 detects an attack on the vehicle itself, it may be installed on the vehicle as shown in Figure 6, or it may be installed on the outside of the vehicle.

[0064] The method for detecting attacks on other vehicles is the same as the method for detecting attacks on one's own vehicle, when the focus is on other vehicles. The attack detection unit 104 of the own vehicle detects cyberattacks on other vehicles by receiving attack notification from a central device or the like.

[0065] The security function execution necessity determination unit 105 determines whether the ECU 20 should execute a first security function in response to an attack detected by the attack detection unit 104. In other words, when the attack detection unit 104 detects an attack on the vehicle itself or another vehicle, the security function execution necessity determination unit 105 determines which of the first security functions should be executed on which ECU 20. Once the attack detection unit 104 detects an attack, the type, characteristics, and target of the attack become clear, allowing the security function execution necessity determination unit 105 to determine whether or not to execute the first function on the target or affected ECU 20. In addition, the security function execution necessity determination unit 105 may be installed on the vehicle itself, as shown in Figure 6, or it may be installed on the outside of the vehicle.

[0066] The first function is a security function, but since it is a security function that is performed when an attack is detected by the attack detection unit 104, it is desirable that the first function be responsible for countermeasures and responses to attacks. In other words, the first function is a security function that becomes necessary as a result of attack detection. Examples of the first function include EPP (Endpoint Protection Platform), which prevents attacks by malicious programs and malware from infiltrating the ECU20 and records detailed logs for analysis; NGAV (Next Generation AntiVirus), which is an antivirus that uses AI and machine learning for behavioral detection; DPI (Deep Packet Inspection), which inspects not only the header but also the data body of data packets; and firewall settings for specific attacks.

[0067] Furthermore, if the attack detection unit 104 detects an attack on another vehicle by receiving a notification from the central device, and the notification specifies that the execution of the first function should be performed, the security function execution necessity determination unit 105 decides to execute the first function in accordance with the notification. In this case, the determination of whether or not the security function should be executed is made by a central device outside the vehicle or by a person outside the vehicle.

[0068] Furthermore, either the attack detection unit 104 or the security function necessity assessment unit 105 may be located outside the vehicle. The processing procedures in each case are as follows. (i) When the attack detection unit 104 is located outside the vehicle and the security function execution necessity determination unit 105 is located inside the vehicle. The security sensor transmits logs and CAN frames generated by the vehicle to an external source, and the attack detection unit 104 detects the attack upon receiving them. The attack detection unit 104 then transmits the attack detection result back to the vehicle. (ii) When the attack detection unit 104 is located inside the vehicle and the security function execution necessity determination unit 105 is located outside the vehicle. The attack detection unit 104 transmits the detected attack result from the vehicle to the outside of the vehicle. The security function execution necessity determination unit 105, upon receiving this result, determines whether or not to execute the first function, the type of first function to be executed, and the location where it will be executed. The security function execution necessity determination unit 105 then transmits the determined result to the vehicle. (iii) When the attack detection unit 104 and the security function execution necessity determination unit 105 are located outside the vehicle. Logs and CAN frames generated by the security sensor are transmitted from the vehicle to the outside, and the attack detection unit 104 that receives them detects an attack. The attack detection unit 104 transmits the attack detection result to the security function execution necessity determination unit 105, which receives the result and determines whether or not to execute the first function, the type of first function to be executed, and where to execute it. The security function execution necessity determination unit 105 then transmits the determined result to the vehicle.

[0069] Furthermore, if the attack detection unit 104 and / or the security function execution necessity determination unit 105 are located outside the vehicle, the externally located parts can be operated by a device or by a person.

[0070] If the attack detection unit 104 detects an attack and the security function execution necessity consideration unit 105 determines that the execution of the first function is necessary, the resource determination unit 106 determines whether the resources of the ECU 20 will be insufficient to execute the first function, based on the resource requirements for the second function obtained by the resource requirement acquisition unit 102. In this embodiment, the resource determination unit 106 calculates the total resource requirement by adding the resource requirement of the first function to the resource requirement of all the functions to which resources have been allocated by the ECU 20 among the second functions, and determines whether the ECU 20 has insufficient resources based on whether the total resource requirement exceeds the maximum value of the resources that the ECU 20 has.

[0071] More specifically, the appropriate decision-making method should be determined based on the type of resource. For example, if the resource is a volatile storage medium or processor that can be erased and read / written, the decision can be made based on the resource requirements of the second function that is currently running. Alternatively, if the resource is a non-volatile storage medium that can be erased and read / written, the decision can be made based on the resource requirements of the second function currently stored on the non-volatile storage medium.

[0072] If the resource determination unit 106 determines that the ECU 20 is running low on resources, the release function selection unit 107 selects a second function that "releases" the resources currently being consumed, based on the usage level and resource requirements of each of the second functions. In this embodiment, as shown in the example in Figure 6, the usage acquisition unit 103 acquires a priority table from the ECU 20 that prioritizes the functions of the second function that are currently consuming resources, in order of increasing usage. Then, the release function selection unit 107 selects one function at a time from the second function to release resources, based on the priority table, until the resource determination unit 106 determines that there is no shortage of resources. Here, "to release" means to make the resources currently being consumed available for use.

[0073] The second function selected by the release function selection unit 107 is preferably an additional function that is software installed by the vehicle's user. Here, The term "user" refers to anyone who uses the mobile device; this could be an operator who controls the device, such as a vehicle driver, or a passenger in the mobile device other than the operator. Furthermore, the user may be someone who uses the mobile device remotely via communication, such as a person who remotely controls an electronic control device. "Software" includes middleware such as operating systems.

[0074] Similarly, it is desirable that the second function selected by the release function selection unit 107 does not include any functions related to the "driving" of the vehicle. Here, "driving" includes stopping.

[0075] Using Figure 7, we will explain specific examples of the operation of the resource determination unit 106 and the release function selection unit 107. First, as a premise, we assume that the resource requirement acquisition unit 102 acquires the resource requirement table shown in Figure 5, and the usage acquisition unit 103 acquires the usage table shown in Figure 6.

[0076] The first example is illustrated in Figures 7(A) and (B). In the first example, it is assumed that the software for the second function, functions A1, A2, I1, and I2, is stored in RAM23. In this state, if we were to allocate resources to the first function, function I3, the sum of the resource requirements of the four functions already allocated (67%) plus the resource requirement of function I3 (22%) would still not reach the maximum resource value (100%). Therefore, as shown in Figure 7(B), resources can be allocated to all five of these functions. In other words, in the case of Figure 7(B), the first function I3 can be executed without stopping any of the second functions.

[0077] Figures 7(C) and (D) illustrate the second example. In the second example, it is assumed that the software for the second function, functions A1, A2, A3, A4, I1, and I2, is stored in RAM23. In this state, if we were to allocate resources to the first function, function I3, the sum of the resource requirements of the six functions already allocated (90%) plus the resource requirement of function I3 (22%) would exceed the maximum resource limit (100%). Therefore, under these circumstances, it would not be possible to allocate resources to the first function, I3. Therefore, from the six second functions already allocated, we select the second functions to release resources in order of least usage, i.e., in the example of Figure 6, in order of highest priority. In the example of Figure 6, function A1, which has the highest priority, is selected first, but since function A1 alone is not enough, function A2, which has the next highest priority, is also selected. Then, the sum of the resource requirements of the four functions excluding functions A1 and A2 (71%) plus the resource requirement of function I3 (22%) does not exceed the maximum resource value (100%), so resources can be allocated to function I3 as shown in Figure 7(D).

[0078] Note that while Figure 7 uses RAM23 as an example resource type, the same principles apply to other resource types. Furthermore, if there are multiple resource types, the same adjustments as in Figure 7 should be applied to each resource, ensuring that none of the resources exceed 100%.

[0079] Returning to Figure 4, the instruction unit 108 outputs an "execution instruction" for the first function and a "release instruction" to the ECU 20, which is an instruction to release the resources currently being consumed by the second function selected by the release function selection unit 107. Here, An "execution instruction" includes not only instructing the execution of a first function that is already installed, but also instructing the installation and execution of a first function that is not yet installed. A "release instruction" includes not only cases where a resource is directly instructed to be released, but also cases where a resource is released as a result of a predetermined instruction. Examples of the former include erase instructions for ROM and hard disks (i.e., instructions that release ROM and storage resources), and examples of the latter include program termination instructions (i.e., instructions that release processor and RAM resources).

[0080] Regarding release instructions, you should specify the appropriate instruction depending on the type of resource. For example, if the resource is a volatile storage medium or processor that can be erased and read / written, the release instruction outputs a termination command for the second function selected by the release function selection unit 107. Alternatively, if the resource is a non-volatile storage medium that can be erased and read / written, the erase command of the second function selected by the release function selection unit 107 is output as a release instruction.

[0081] If the first function has not yet been installed in the ECU20, the software that implements the first function may be sent in addition to the execution instruction. In that case, it is desirable for the resource determination unit 106 to determine in advance whether or not the resources in the ROM22 are insufficient.

[0082] (2-2) Configuration of the electronic control unit of Embodiment 1 The configuration of the ECU20 in Embodiment 1 will be described using Figure 8. The ECU20 has a function management unit 201 and a communication unit 202. The function management unit 201 has a resource requirement measurement unit 203, a usage measurement unit 204, and a function control unit 205.

[0083] The communication unit 202 communicates with the security function management device 10. Specifically, it transmits information regarding resource requirements and usage to the security function management device 10. It also receives execution and release instructions from the security function management device 10.

[0084] The resource requirement measurement unit 203 measures the resource requirements for each function performed by the ECU 20. A specific example is shown in Figure 5. The resource requirement can be the average or maximum value of the measured values ​​of the consumed resources. By measuring the resource requirement, the resource requirement measurement unit 203 can acquire resource requirement information at the necessary time.

[0085] Furthermore, the resource requirements may be provided as an estimated value in advance when the ECU 20 is manufactured or when the function is provided from an external source such as a center device. For example, in Figure 5, if the first function, function I3, is not initially executed in the ECU 20, the resource requirement measurement unit 203 cannot measure the resource requirements, so an estimated value provided from an external source can be used.

[0086] The usage measurement unit 204 measures the usage level, which indicates the degree to which each of the second functions has been used. A specific example is shown in Figure 6.

[0087] The function control unit 205 controls the installation, execution, termination, and deletion of the software that implements the functions of the ECU 20. As a result, the respective resources of the ECU 20 are allocated or released. In this embodiment, the software that implements each function is installed, executed, terminated, or deleted according to the execution instructions and release instructions sent from the security function management device 10.

[0088] (2-3) Operation of the security function management device of Embodiment 1 The operation of the security function management device 10 of this embodiment will be explained using the flowcharts in Figures 9 to 10. Furthermore, the following operations not only demonstrate how to perform them on the security function management device 10, but also illustrate the processing procedures for programs that can be executed on these devices.

[0089] Figure 9 shows the main routine when an attack on a vehicle is detected. The attack detection unit 104 detects an attack on its own vehicle or another vehicle (S101). If an attack is detected in S101, the security function execution necessity determination unit 105 determines the first function to be executed and the ECU 20 that will execute the first function (S102). There may be multiple first functions and multiple ECU 20s. In other words, if there are multiple ECU 20s, one or more first functions should be determined for each ECU 20. The resource requirement acquisition unit 102 acquires the resource requirements for one or more second functions from the ECU 20 (S103). The usage acquisition unit 103 acquires the usage status of each of the second functions from the ECU 20 (S104). The resource determination unit 106 determines whether the resources of the ECU 20 will be insufficient to execute the first function based on the resource requirements obtained in S103 (S105, S106). Specifically, it calculates the resource requirements for all functions of the second function that are currently consuming resources, and adds the resource requirements for the first function determined in S102 to the sum of these requirements to obtain the total resource requirement Rs (S105). Then, it compares the total resource requirement Rs with the maximum resource value Rmax, which is the maximum amount of resources that can be consumed (S106). If the total resource requirement Rs is less than or equal to Rmax (S106:y), the process ends. If it is greater than Rmax (S106:n), the process moves to S107. The release function selection unit 107 selects a function from the second set of functions to release resources based on the required resource amount obtained in S103 and the usage amount obtained in S104 (S107). The instruction unit 109 outputs an instruction to the ECU 20 to execute the first function and an instruction to release the resources of the second function selected in S107 (S108).

[0090] Figure 10 shows the subroutine that executes step S107. Based on the usage of the second function obtained in S104, a priority is assigned to each second function, which is the order in which resources should be released (S201). Let the priority be p, and set p to 1 (S202). Select the second function with priority p (S203). The total resource requirement Rs(p), obtained by subtracting the resource requirement of the second function selected in S203 from the total resource requirement Rs, is compared with the maximum value Rmax (S204). If the total resource requirement Rs(p) is less than or equal to Rmax (S204:y), the subroutine terminates, assuming the resource shortage is resolved. If it is greater than Rmax (S204:n), the resource shortage is not yet resolved, so p is incremented (S205), and the process returns to S203. In other words, the selection range is expanded from high-priority to low-priority functions until the resource shortage is resolved. For example, if the resource shortage is resolved when p=3, it means that functions with priorities p of 1, 2, and 3 have been selected.

[0091] In Figure 9, resource requirements are obtained in S103 and usage in S104 after detecting an attack in S101. However, resource requirements and usage may be obtained in advance before detecting an attack. In this case, the processing is performed in the order of S103, S104, S101, and S102. In this case, since the ECU20 that will execute the first function has not yet been determined, it is desirable to periodically obtain the resource requirements and usage of all ECU20s. Alternatively, the priority assigned in S201 may be pre-assigned in step S104. Or, the ECU20 may measure usage and obtain the pre-assigned priority. In these cases, processing in S201 is unnecessary. If multiple first functions are selected in S102, the resource requirement for the first function in S105 will be the sum of the resource requirements of the selected first functions. Also, if multiple ECU20s are selected in S102, the flows shown in Figures 9 and 10 should be executed for each ECU20.

[0092] (2-4) Operation of the electronic control unit of Embodiment 1 Next, the operation of the ECU20 in this embodiment will be explained using the flowchart in Figure 11.

[0093] The resource requirement measurement unit 203 of the ECU 20 measures the resource requirements for each of the second functions (S301). The communication unit 202 of the ECU 20 transmits the resource requirement measured in S301 to the security function management device 10 (S302). As a result, the resource requirement acquisition unit 102 of the security function management device 10 acquires the resource requirement (S103). The usage measurement unit 204 of the ECU20 measures the usage of each of the second functions in the ECU20 (S303). The communication unit 202 of the ECU 20 transmits the usage level measured in S303 to the security function management device 10 (S304). As a result, the usage level acquisition unit 103 of the security function management device 10 acquires the usage level (S104). The instruction unit 108 of the security function management device 10 outputs an instruction to execute the first function and an instruction to release the resources of the selected second function (S108), and the communication unit 202 of the ECU 20 receives the output (S305). The function control unit 205 of the ECU 20 allocates resources to the first function and executes the first function, and then releases the resources for the specified function among the second functions (S306).

[0094] (2-5) Summary As described above, the security function management device 10 of this embodiment selects a function to release resources based on usage and instructs it to release those resources. Therefore, even if the ECU 20 does not have sufficient resources to execute security functions, it is possible to secure resources for executing security functions while leaving functions with high usage (i.e., functions that are likely to be used by the user) available to the ECU 20. The security function management device 10 of this embodiment selects a second function to be released in order of decreasing usage, so that functions that are less likely to be used by the user can be terminated or deleted in order. In this embodiment, the security function management device 10 uses software installed by the vehicle user as the second function for releasing resources. Therefore, it does not require selecting essential functions of the ECU 20, and resources for functions indispensable to the ECU 20 can be preserved. In this embodiment, the security function management device 10 does not include functions related to vehicle operation in its second function of releasing resources. Therefore, it does not select essential functions of the ECU 20, and resources for functions indispensable to the ECU 20 can be preserved.

[0095] 3. Embodiment 2 In Embodiment 1, the security function management device 10 obtained the usage rate of each function from the ECU 20 and selected a function to release resources based on this. However, the information received from the ECU 20, which may have been under attack, may not be reliable. Therefore, in this embodiment, we will describe a security function management device 10 that can select a function to release resources using trusted information. Below, we will describe a configuration that differs from Embodiment 1, and configurations common to Embodiment 1 will be referenced from the description of Embodiment 1.

[0096] (3-1) Example 1 (from the perspective of the timing of information acquisition) The usage acquisition unit 103 acquires usage data from the ECU 20 periodically or when an event other than an attack occurs, regardless of whether an attack has been detected. The release function selection unit 107 selects a second function to release resources based on the usage level acquired by the usage level acquisition unit 103 before the attack was detected.

[0097] Figure 12 shows an example of usage data acquired by the usage data acquisition unit 103 in this embodiment. In Figure 12, the usage data acquisition unit 103 acquires usage data once a day, for example at 6:00 AM. For example, if an attack on a vehicle is detected at 5:00 AM on June 3rd, the release function selection unit 107 considers the possibility that the usage and priority on June 3rd may be different from their original values ​​due to the attack, and selects a second function that releases resources using the usage and priority on June 2nd instead of the usage and priority on June 3rd.

[0098] However, considering that it may take some time for an attack to manifest, the usage and priority levels obtained before a predetermined time has passed since the attack was detected may be used. For example, if the usage and priority levels obtained more than 24 hours before the attack was detected are used, Figure 12 uses the usage and priority levels from June 1st.

[0099] Alternatively, the average usage before the attack can be calculated, and the priority can be determined based on this. For example, in the example in Figure 12, using the average usage for June 1st and June 2nd, the average usage and priority for each function are as follows. The numbers in parentheses represent the priority. A1: 7.5% (1) A2: 17.5% (2) A3: 32.5% (3) A4: 42.5% (4)

[0100] Similarly, regarding the resource requirements obtained from the ECU 20, the resource requirement acquisition unit 102 may acquire the resource requirements from the ECU 20 periodically or when an event other than an attack occurs, regardless of whether an attack has been detected. The release function selection unit 107 may then select a second function to release resources based on the resource requirements acquired by the resource requirement acquisition unit 102 before the attack was detected.

[0101] As described above, the security function management device 10 of this embodiment selects a second function that releases resources based on information acquired before detecting an attack, so it can select a second function that releases resources using information that has not been affected by the attack.

[0102] (3-2) Example 2 (from the perspective of information storage location) In the security function management device 10 of Embodiment 1, a second function was selected that frees up resources using the usage and resource requirements stored in the security function management device 10. However, if an attack on the vehicle is detected, not only the ECU 20 but also the ECU implementing the security function management device 10 and the connected storage device may be affected by the attack. Therefore, in this embodiment, the information is stored outside the vehicle.

[0103] The resource requirement acquisition unit 102 stores the acquired resource requirements in an external device installed outside the mobile body. For example, the resource requirement table shown in Figure 5 is stored in the external device. The usage acquisition unit 103 stores the acquired usage data in an external device installed outside the mobile unit. For example, the usage table shown in Figure 6 is stored in the external device. The open function selection unit 107 selects a second function based on the usage and resource requirements obtained from an external device.

[0104] Note that it is sufficient to store either usage data or resource requirements on an external device. Furthermore, a combination of Example 1 and Example 2 may be used. That is, the open function selection unit 107 may select a second function based on information acquired before detecting an attack from the information stored externally.

[0105] As described above, the security function management device 10 of this embodiment selects a second function that releases resources based on information stored externally, so it can select a second function that releases resources using information that has not been affected by the attack.

[0106] 4. Embodiment 3 In Embodiment 1, the usage rate was obtained without distinguishing between vehicle users, but in this embodiment, the users are distinguished when there are multiple vehicle users. The following describes the configurations that differ from Embodiment 1, and configurations common to Embodiment 1 are referenced from the description of Embodiment 1.

[0107] The usage acquisition unit 103 acquires the usage level for each user when the vehicle or ECU 20 is used by multiple users. The release function selection unit 107 selects a second function to release resources based on the usage of the vehicle or the user currently using the ECU 20, as determined or selected by the security function execution necessity determination unit 105, the resource determination unit 106, or the release function selection unit 107.

[0108] Figure 13 shows an example of usage data acquired by the usage data acquisition unit 103 in this embodiment. In Figure 13, the usage data acquisition unit 103 acquires usage data measured for each user, namely users X, Y, and Z. User identification can be carried out using any method. For example, users can be identified using their username and password or credit card information when logging in, or they can be identified using image recognition technology from images captured by cameras installed in the vehicle.

[0109] For example, suppose that at the time an attack on the vehicle is detected and it is determined that security functions should be executed in response to that attack, the user using the vehicle or ECU 20 was User X. In this case, the release function selection unit 107 generates a priority based on User X's usage in the usage table in Figure 13, and selects a second function to release resources based on the generated priority.

[0110] In the example above, we selected a function based on the usage of a single user. However, if multiple users were using the function at the same time, you could use the average usage rate (the average of the usage rates of those multiple users) or the average priority calculated from the average usage rate. For example, if users X, Y, and Z were all using the software at the same time, the average priority is calculated from their average usage, as shown in Figure 13. The average can be either a geometric mean or an arithmetic mean. The average priority in Figure 13 is an example of the geometric mean of the priorities of users X, Y, and Z.

[0111] Alternatively, the average value could be calculated using a weighted value based on the usage rate of the current users.

[0112] As described above, in cases where the vehicle or ECU 20 is used by multiple different users, the security function management device 10 of this embodiment can, when it is necessary to release the resources of one of the second functions in order to execute the security function, retain the function that is most likely to be used by the user currently using the vehicle or ECU 20, thereby increasing user satisfaction.

[0113] 5. Summary The security function management device 10 in the embodiment of the present invention has been described above.

[0114] The terms used in each embodiment are illustrative and may be replaced with synonymous terms or terms that include synonymous functions.

[0115] The block diagram used in describing the embodiment classifies and organizes the device configuration by function. Each block representing a function can be realized by any combination of hardware or software. Furthermore, since it represents a function, such a block diagram can also be understood as a disclosure of a method invention and a program invention that realizes said method.

[0116] The functional blocks that can be understood as processes, flows, and methods described in each embodiment may be reordered, unless there are constraints such as a relationship where one step utilizes the results of other preceding steps.

[0117] The terms "first," "second," through "nth" (where N is an integer) used in each embodiment and in the claims are used to distinguish between two or more configurations or methods of the same kind, and do not imply any order or hierarchy.

[0118] While each embodiment is based on a device mounted on a vehicle, the present invention also includes dedicated or general-purpose devices other than those for vehicles, unless otherwise specifically limited by the claims.

[0119] Furthermore, the following are examples of the configuration of the apparatus of the present invention. Examples of component forms include semiconductor elements, semiconductor circuits, electronic circuits, modules, and microcomputers. Examples of semi-finished products include electronic control units (ECUs), electronic control units, and system boards. Examples of finished products include mobile phones, smartphones, mobile routers, tablets, personal computers (PCs), workstations, and servers.

[0120] Furthermore, necessary functions such as antennas and communication interfaces may be added to the device.

[0121] The apparatus of the present invention is intended to be used for the purpose of providing various services. In connection with the provision of such services, the apparatus of the present invention will be used, the method of the present invention will be used, and / or the program of the present invention will be executed.

[0122] In addition, the present invention can be realized not only with dedicated hardware having the configuration and functions described in each embodiment, but also as a combination of a program for realizing the present invention recorded on a recording medium such as memory or a hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory capable of executing this program.

[0123] A program for the apparatus of the present invention, which is stored on a non-transitional physical recording medium of dedicated or general-purpose hardware (e.g., an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, ROM, etc.)), can also be provided to the dedicated or general-purpose hardware via the recording medium, or without the recording medium, via a communication line from a server. This allows the latest functions to always be provided through program upgrades. [Industrial applicability]

[0124] The security function management device of the present invention can be widely applied to security function management in motorcycles, electric bicycles, ships, aircraft, and the like. [Explanation of Symbols]

[0125] 10 Security function management device, 20 ECU, 21 Processor, 22 ROM, 23 RAM, 24 Storage, 25 Communication circuit, 26 Other hardware, 30 External device, 101 Communication unit, 102 Resource requirement acquisition unit, 103 Usage acquisition unit, 104 Attack detection unit, 105 Security function execution necessity determination unit, 106 Resource determination unit, 107 Open function selection unit, 108 Instruction unit, 201 Function management unit, 202 Communication unit, 203 Resource requirement measurement unit, 204 Usage measurement unit, 205 Function control unit

Claims

1. A security function management device that manages the execution of a first function, which is a security function of an electronic control device mounted on a mobile body, Resource requirement acquisition unit (102) acquires resource requirement amounts, which are the amounts of resources required for one or more second functions different from the first function that can be executed by the electronic control unit, A usage level acquisition unit (103) acquires a usage level indicating the degree to which each of the second functions described above has been used, If an attack is detected and the execution of the first function is required, a resource determination unit (106) determines whether the resources of the electronic control unit will be insufficient to execute the first function based on the resource requirements of the second function, When the electronic control unit determines that the resources are insufficient, it selects a second function to release the resources currently being consumed, based on the usage level and resource requirements of each of the second functions, The electronic control unit has an instruction unit (108) that outputs an instruction to execute the first function and an instruction to release the resources currently being consumed by the second function selected by the release function selection unit. Security function management device.

2. The release function selection unit selects the second function to be released in order of decreasing usage frequency. The security function management device according to claim 1.

3. The resource determination unit determines, if the resource is a volatile storage medium or processor that can be erased and read / written, based on the resource requirements of the second function currently running. The instruction unit outputs a termination command for the second function selected by the release function selection unit as the release instruction. The security function management device according to claim 1.

4. The resource determination unit, if the resource is a non-volatile storage medium that can be erased and read / written, determines based on the resource requirements of the second function currently stored on the non-volatile recording medium, The instruction unit outputs an erase command for the second function selected by the release function selection unit as the release instruction. The security function management device according to claim 1.

5. The first function described above is a security function required as a result of detecting the attack. The security function management device according to claim 1.

6. The second function selected by the release function selection unit is software installed by the user of the mobile device. The security function management device according to claim 1.

7. The second function described above does not include any functions related to the movement of the vehicle, which is the moving body. The security function management device according to claim 6.

8. The opening function selection unit selects the second function based on the usage level acquired by the usage level acquisition unit before the attack is detected. The security function management device according to claim 1.

9. The usage acquisition unit stores the acquired usage data in an external device installed outside the mobile body. The opening function selection unit selects the second function based on the usage level obtained from the external device. The security function management device according to claim 1.

10. The usage acquisition unit acquires the usage level for each user when the mobile body is used by multiple users. The opening function selection unit selects the second function based on the usage level of the user currently using the mobile body. The security function management device according to claim 1.

11. The usage acquisition unit acquires the usage level for each user when the mobile body is used by multiple users. The opening function selection unit selects the second function based on the average usage rate, which is the average value of the usage rate. The security function management device according to claim 1.

12. The security function management device is an electronic control unit mounted on the mobile body. A security function management device according to any one of claims 1 to 11.

13. The security function management device is a server device installed outside the mobile body. A security function management device according to any one of claims 1 to 11.

14. A security function management method executed by a security function management device that manages the execution of a first function which is a security function of an electronic control device mounted on a mobile body, The electronic control unit can perform the following: The required resource amount is obtained, which is the amount of resources required for one or more second functions different from the first function (S103), A usage level indicating the degree to which each of the second functions has been used is obtained (S104), If an attack is detected and it is necessary to execute the first function, the electronic control unit determines whether it will have insufficient resources to execute the first function based on the resource requirements for the second function (S105, S106). If the electronic control unit determines that the resources are insufficient, it selects a second function that releases the resources currently being consumed, based on the usage level and resource requirements of each of the second functions (S107), The electronic control unit is given an instruction to execute the first function and an instruction to release the resources currently being consumed by the selected second function (S108). Security function management methods.

15. A security function management program executable by a security function management device that manages the execution of a first function, which is a security function of an electronic control device mounted on a mobile body, The security function management program provides the security function management device with the following instructions: The electronic control unit can perform the following: The required resource amount is obtained, which is the amount of resources required for one or more second functions different from the first function (S103), A usage level indicating the degree to which each of the second functions has been used is obtained (S104), If an attack is detected and it is necessary to execute the first function, the electronic control unit determines whether it will have insufficient resources to execute the first function based on the resource requirements for the second function (S105, S106). If the electronic control unit determines that the resources are insufficient, it selects a second function that releases the resources currently being consumed, based on the usage level and resource requirements of each of the second functions (S107), The electronic control unit is given an instruction to execute the first function and an instruction to release the resources currently being consumed by the selected second function (S108). To execute the process Security function management program.

Images