Surveillance system, surveillance method, surveillance device, and function restriction device

Abstract

This monitoring system for monitoring a vehicle (10) or a monitoring target operating in the vehicle (10) comprises: a reliability management unit (1186) for managing a reliability indicating a security protection status of the monitoring target, in accordance with a vehicle event of the vehicle (10); and a function restricting unit (1163) for restricting at least some functions of the monitoring target in accordance with the reliability.

Description

[Technical Field]

[0001] The present disclosure relates to a monitoring system, a monitoring method, a monitoring device, and a function restriction device. [Background technology]

[0002] In recent years, vehicle systems have become increasingly complex in order to provide users with advanced features such as autonomous driving. To address the growing development time and costs that accompany these complexities, there has been a trend toward integrating functions that were previously distributed across multiple Electronic Control Units (ECUs) into a single ECU. In ECU integration, virtualization technology is used to run multiple virtual computers on a single ECU. These virtual computers are called virtual machines, and the software that serves as the virtualization infrastructure for running multiple virtual machines is called a hypervisor. If vulnerabilities or specification defects in the virtualization software or device drivers within the hypervisor become apparent, there is a risk that the memory area allocated to the hypervisor or virtual machine may be tampered with.

[0003] As a countermeasure to these problems, Patent Document 1 discloses a device that periodically monitors for tampering with an operating system. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 4388292 Summary of the Invention [Problem to be solved by the invention]

[0005] However, it is desirable to improve security in vehicles.

[0006] Therefore, the present disclosure provides a monitoring system, a monitoring method, a monitoring device, and a function restriction device that improve security in a vehicle. [Means for solving the problem]

[0007] A monitoring system according to one embodiment of the present disclosure is a monitoring system for monitoring a vehicle or a first monitoring target operating within the vehicle, and includes a reliability management unit that manages a first reliability indicating a security protection status of the first monitoring target in accordance with a vehicle event of the vehicle, and a function restriction unit that restricts at least some of the functions of the first monitoring target in accordance with the first reliability.

[0008] A monitoring method according to one aspect of the present disclosure is a monitoring method for monitoring a vehicle or a monitoring target operating within a vehicle, and includes a reliability management step of managing a reliability indicating a security protection status of the monitoring target in accordance with a vehicle event of the monitoring target, and a function restriction step of restricting at least a portion of the functions of the monitoring target in accordance with the reliability.

[0009] A monitoring device according to one aspect of the present disclosure is included in a monitoring system that includes a monitoring device for monitoring a vehicle or a monitoring target operating within the vehicle, and a function restriction device for restricting the functions of the monitoring target, and includes a reliability management unit that manages a reliability indicating the security protection status of the monitoring target in accordance with a vehicle event of the vehicle.

[0010] A function restriction device according to one aspect of the present disclosure is a function restriction device included in a monitoring system that includes a monitoring device for monitoring a vehicle or a monitored object operating within the vehicle, and a function restriction device for restricting the functions of the monitored object, and includes a function restriction unit that restricts at least a portion of the functions of the monitored object depending on a reliability indicating the security protection status of the monitored object depending on a vehicle event of the vehicle. [Effects of the Invention]

[0011] According to a monitoring system according to one aspect of the present disclosure, security in a vehicle is improved. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of an overall configuration of a vehicle network system according to the first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of the configuration of the integrated ECU according to the first embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of a configuration of a monitoring target module according to the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of the monitoring module according to the first embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of a reliability management table according to the first embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a reliability adjustment table according to the first embodiment. [Figure 7] FIG. 7 is a diagram showing an example of a function restriction table according to the first embodiment. [Figure 8] FIG. 8 is a diagram illustrating an example of a reliability update sequence according to the first embodiment. [Figure 9] FIG. 9 is a diagram showing an example of a determination sequence using reliability according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a reliability restoration sequence according to the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of a configuration of a monitoring target module according to a modification of the first embodiment. [Figure 12] FIG. 12 is a diagram showing an example of a reliability management table according to a modification of the first embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of a configuration of a monitoring module according to a modification of the first embodiment. [Figure 14] FIG. 14 is a diagram showing an example of a reliability update sequence according to the modification of the first embodiment. [Figure 15]FIG. 15 is a diagram showing an example of a determination sequence using reliability according to a modification of the first embodiment. [Figure 16] FIG. 16 is a diagram illustrating an example of a reliability restoration sequence according to a modification of the first embodiment. [Figure 17] FIG. 17 is a diagram illustrating an example of the overall configuration of a network system according to the second embodiment. [Figure 18] FIG. 18 is a diagram illustrating an example of the configuration of the integrated ECU according to the second embodiment. [Figure 19] FIG. 19 is a diagram illustrating an example of a configuration of a monitoring module according to the second embodiment. [Figure 20] FIG. 20 is a diagram illustrating an example of a configuration of a server according to the second embodiment. [Figure 21] FIG. 21 is a diagram illustrating an example of a reliability management table according to the second embodiment. [Figure 22] FIG. 22 is a diagram illustrating an example of a reliability adjustment table according to the second embodiment. [Figure 23] FIG. 23 is a diagram illustrating an example of a function restriction table according to the second embodiment. [Figure 24] FIG. 24 is a diagram illustrating an example of a reliability update sequence according to the second embodiment. [Figure 25] FIG. 25 is a diagram illustrating an example of a determination sequence using reliability according to the second embodiment. [Figure 26] FIG. 26 is a diagram illustrating an example of a reliability restoration sequence according to the second embodiment. [Figure 27] FIG. 27 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 28] FIG. 28 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 29] FIG. 29 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 30] FIG. 30 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 31]FIG. 31 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 32] FIG. 32 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 33] FIG. 33 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 34] FIG. 34 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 35] FIG. 35 is a diagram illustrating an example of the configuration of an integrated ECU according to another embodiment. [Figure 36] FIG. 36 is a diagram showing an example of a display screen according to another embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] (Background to this disclosure) Before describing the present disclosure, the background to the present disclosure will be described.

[0014] When the device disclosed in Patent Document 1 is applied to an ECU configured to operate multiple virtual computers in a single ECU, the area to be verified becomes enormous, and the time required to complete verification of each verification target increases, resulting in large differences in the time at which verification is completed for each verification target. Furthermore, because verification is performed periodically, it is difficult to detect an attack during the time between verifications. Therefore, it is desirable to improve the security of vehicles equipped with ECUs.

[0015] Therefore, the inventors of the present application have conducted extensive research into monitoring systems and the like that can improve vehicle security, and have devised the monitoring system described below. For example, even if there is a large difference in the time at which each verification target is completed, the inventors have devised a monitoring system and the like that can achieve a safer ECU by setting a numerical value that serves as a basis for determining that the target is normal, and by restricting some of the functions of the target according to that numerical value. This makes it possible to appropriately determine and restrict usable functions according to the state of the monitored target, and to maintain a safe state for the entire system.

[0016] A monitoring system according to one embodiment of the present disclosure is a monitoring system for monitoring a vehicle or a first monitoring target operating within the vehicle, and includes a reliability management unit that manages a first reliability indicating a security protection status of the first monitoring target in accordance with a vehicle event of the vehicle, and a function restriction unit that restricts at least some of the functions of the first monitoring target in accordance with the first reliability.

[0017] This makes it possible to appropriately determine which functions can be used depending on the state of the monitored object, and to maintain a safe state for the entire system, thereby improving security in the vehicle.

[0018] Also, for example, the first reliability may be a value having at least two or more stages indicating the degree of security protection status of the first monitoring target, and the reliability management unit may change the stage each time the vehicle event occurs.

[0019] This allows for more detailed management of the status of the monitored object.

[0020] Also, for example, the vehicle event that causes the change of state may include verification of the integrity of the first monitored software.

[0021] This makes it possible to detect tampering with the software being monitored and reduce the impact on other monitored software.

[0022] Also, for example, the reliability management unit may change the stage by performing at least one of adding the first reliability if the integrity verification is completed successfully, and subtracting the first reliability if the integrity verification is not completed successfully.

[0023] This allows the reliability to be updated according to the result of the integrity verification.

[0024] Also, for example, the vehicle event that causes the change of state may include the passage of a predetermined amount of time.

[0025] This makes it possible to properly manage the status of monitored objects, whose risk of tampering increases over time, and by restricting functions according to the status, it is possible to reduce the impact on other monitored objects.

[0026] Furthermore, for example, the reliability management unit may subtract a value from the first reliability when the predetermined time has elapsed.

[0027] This allows the reliability to be updated after a predetermined time has elapsed.

[0028] Also, for example, the vehicle event that causes the change of state may include a restart of the first monitored object.

[0029] This allows for proper management of the restart status, the success or failure of which can change due to tampering, etc., and by restricting functions depending on the status, it becomes possible to reduce the impact on other monitored objects, etc.

[0030] Furthermore, for example, when the restart is completed normally, the reliability management unit may change the stage by incrementing the first reliability or by setting the first reliability to an initial value.

[0031] This allows the reliability to be updated depending on whether the restart is successful or not.

[0032] Also, for example, the reliability management unit may determine whether the first reliability of the first monitoring target is less than a threshold, and if the first reliability is less than the threshold, cause the first monitoring target to perform the restart.

[0033] This allows the device to automatically restart when the reliability is reduced, and update the reliability.

[0034] Furthermore, for example, restricting at least some of the functions of the first monitoring target in accordance with the first reliability may include suspending the first monitoring target's right to access a specific resource.

[0035] This makes it possible to appropriately manage access to resources depending on the state of the monitored object.

[0036] Furthermore, for example, restricting at least some of the functions of the first monitoring target in accordance with the first reliability may include stopping a communication function of the first monitoring target.

[0037] This makes it possible to restrict actions by a less trustworthy monitored target from spreading its influence to other monitored targets via communications.

[0038] Also, for example, when the first monitoring target communicates with a communication target, the function restriction unit may prohibit the first monitoring target from communicating with the communication target if the first reliability is less than a threshold value.

[0039] This makes it possible to restrict actions that could cause a less trustworthy monitored target to initiate communication and spread its influence to other monitored targets.

[0040] Furthermore, for example, the monitoring system may further monitor the vehicle or a second monitoring target operating within the vehicle, the reliability management unit may further manage a second reliability indicating a security protection status of the second monitoring target in accordance with a vehicle event of the vehicle, and the function restriction unit may prohibit communication between the first monitoring target and the second monitoring target when at least one of the first reliability and the second reliability is below a threshold value when the first monitoring target and the second monitoring target communicate with each other.

[0041] This makes it possible to more reliably restrict actions that could be taken by a less trustworthy monitored target to initiate communication and attempt to spread the influence to other monitored targets, etc.

[0042] Furthermore, for example, at least some of the function restrictions according to the first reliability of the first monitoring target may include stopping the operation of the first monitoring target.

[0043] This makes it possible to prevent unreliable monitoring targets from continuing to operate and adversely affecting the entire system.

[0044] Also, for example, the unit of the first monitoring target for calculating the first reliability may include any one of a software process, an operating system, a hypervisor, a virtual machine running on the hypervisor, an electronic control unit running within the vehicle, and the vehicle.

[0045] This allows for functional restrictions on each unit, enabling broad monitoring across the entire system.

[0046] Furthermore, for example, a display unit may be provided that displays the first monitoring target and the first reliability together.

[0047] This makes it possible to check the current status of the monitored object from outside, and maintain a safe state for the entire system.

[0048] Furthermore, for example, the reliability management unit and the function restriction unit may be mounted on the vehicle.

[0049] This allows for improved security within the vehicle without communicating with the outside of the vehicle.

[0050] Furthermore, for example, the monitoring system may include a server communicably connected to the vehicle, and at least one of the reliability management unit and the function restriction unit may be realized by the server.

[0051] This allows accurate determination of at least one of the reliability and functional limitations even if the software to be monitored has been tampered with.

[0052] Furthermore, a monitoring method according to one aspect of the present disclosure is a monitoring method for monitoring a vehicle or a monitoring target operating within a vehicle, and includes a reliability management step of managing a reliability indicating a security protection status of the monitoring target in accordance with a vehicle event of the monitoring target, and a function restriction step of restricting at least a portion of the functions of the monitoring target in accordance with the reliability.

[0053] This provides the same effects as the above-mentioned monitoring system. Specifically, it is possible to appropriately determine which functions are available depending on the state of the monitored object, and it is possible to maintain a safe state for the entire system.

[0054] In addition, a monitoring device according to one aspect of the present disclosure is a monitoring device included in a monitoring system that includes a monitoring device for monitoring a vehicle or a monitoring target operating within the vehicle, and a function restriction device for restricting the functions of the monitoring target, and includes a reliability management unit that manages a reliability indicating the security protection status of the monitoring target in accordance with a vehicle event of the vehicle.

[0055] This makes it possible to appropriately manage the status of the monitored object.

[0056] Furthermore, a function restriction device according to one aspect of the present disclosure is a function restriction device included in a monitoring system that includes a monitoring device for monitoring a vehicle or a monitored object operating within the vehicle, and a function restriction device for restricting the functions of the monitored object, and includes a function restriction unit that restricts at least a portion of the functions of the monitored object depending on a reliability indicating the security protection status of the monitored object depending on a vehicle event of the vehicle.

[0057] This makes it possible to appropriately determine the available functions depending on the state of the monitored object.

[0058] Hereinafter, a fraud prevention method according to an embodiment of the present disclosure will be described with reference to the drawings. Each of the embodiments described below represents a preferred specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, component arrangements and connection forms, steps, and step order shown in the following embodiments are examples of the present disclosure and are not intended to limit the present disclosure. The present disclosure is defined by the claims. Therefore, among the components in the following embodiments, components not recited in the independent claims that represent the highest concept of the present disclosure are not necessarily required to achieve the objectives of the present disclosure, but are described as components that constitute more preferred embodiments.

[0059] Furthermore, each figure is a schematic diagram and is not necessarily an exact illustration. Therefore, for example, the scales of the figures do not necessarily match. Furthermore, in each figure, substantially the same components are given the same reference numerals, and redundant explanations are omitted or simplified.

[0060] Furthermore, in this specification, terms indicating relationships between elements, such as coincidence, as well as numerical values ​​and numerical ranges, are not expressions that express only the strict meaning, but also expressions that include a substantially equivalent range, for example, a difference of about a few percent (e.g., about 10%).

[0061] (Embodiment 1) [1. System Configuration] Here, as an embodiment of the present disclosure, a vehicle network system will be described with reference to the drawings.

[0062] 1.1 Overall Configuration of Vehicle Network System 1000 FIG. 1 is a diagram showing an example of the overall configuration of a vehicle network system 1000 according to this embodiment.

[0063] 1, the vehicle network system 1000 is a network system inside the vehicle 10, and includes a brake 1011, an engine 1012, a display 1013, and an integrated ECU 1100 connected to all of them. Note that the integrated ECU 1100 may be connected to components other than the brake 1011, the engine 1012, and the display 1013. The vehicle network system 1000 is an example of a monitoring system.

[0064] The integrated ECU 1100 transmits processing commands to the brake 1011 and the engine 1012 in response to the driver's operation, and the results are fed back.

[0065] The display 1013 receives a display command in response to a driver's operation from the integrated ECU 1100 and displays the command. The display 1013 also receives a driver's operation on the display 1013 side and feeds back the command to the integrated ECU 1100.

[0066] The display 1013 may also display, for example, a monitoring target and the reliability of the monitoring target, which will be described later. The display 1013 may also display a determination result such as the result of integrity verification, the result of maintenance and inspection processing, etc., which will be described later.

[0067] [1.2 Integrated ECU 1100 configuration diagram] FIG. 2 is a diagram showing an example of the configuration of integrated ECU 1100 according to this embodiment.

[0068] As shown in Figure 2, the integrated ECU 1100 assumes an environment in which a Hypervisor 1120 and a Trusted Execution Environment (hereinafter, TEE) 1130 run on a hardware system called a System on Chip (hereinafter, SoC) 1110, and multiple Virtual Machines (hereinafter, VMs) (not shown) are started on the Hypervisor 1120, with different Operating Systems (hereinafter, OSs) running on each VM.

[0069] In this embodiment, a monitoring target module 1160 and a monitoring target module 1170, which are to be monitored, run on the OSs 1140 and 1150, respectively, and a monitoring module 1180 that monitors the monitoring target module 1160 and the monitoring target module 1170 runs on the TEE 1130. The TEE 1130 runs independently of the OSs 1140 and 1150. In this embodiment, an example will be described in which the monitoring targets of the monitoring module 1180 are the monitoring target modules 1160 and 1170, but the number of monitoring targets is not particularly limited as long as it is one or more.

[0070] [1.3 Configuration diagram of monitored module 1160] FIG. 3 is a diagram showing an example of the configuration of the monitoring target module 1160 according to this embodiment.

[0071] 3, the monitoring target module 1160 includes a communication unit 1161, a function processing unit 1162, and a function restriction unit 1163. Note that the monitoring target module 1170 has the same configuration as the monitoring target module 1160, and therefore a description thereof will be omitted. The monitoring target modules 1160 and 1170 will also be simply referred to as modules.

[0072] The communication unit 1161 is responsible for communication with the hypervisor 1120 and modules or processes running in OSs running on other VMs. The communication unit 1161 mainly queries the monitoring module 1180 about the reliability determination results and receives the determination results. The communication unit 1161 is configured to include a communication module (communication circuit).

[0073] The reliability is an index showing whether the monitoring target (here, the monitoring target module 1160) is secure or not, and is, for example, a degree of showing the security protection state of the monitoring target. The reliability indicates, for example, the likelihood that the monitoring target has not been tampered with (here, tampering with the memory area of ​​the monitoring target module 1160, etc.) or that the monitoring target has not been hacked.

[0074] The function processing unit 1162 is a processing unit for realizing the original function of the monitoring target module 1160. For example, drawing processing for the display 1013, instructions for driving control for the brake 1011 or the engine 1012, etc. are examples of processing for realizing the original function.

[0075] The function restriction unit 1163 restricts at least a part of the functions of each monitoring target according to the reliability. For example, the function restriction unit 1163 receives the reliability determination result from the monitoring module 1180, and restricts the operation of the function processing unit 1162 according to the reliability.

[0076] Hereinafter, the monitored module 1160 will also be referred to as a monitored module A, and the monitored module 1170 will also be referred to as a monitored module B. The monitored modules 1160 and 1170 are mounted on the vehicle 10.

[0077] [1.4 Configuration diagram of monitoring module 1180] FIG. 4 is a diagram showing an example of the configuration of the monitoring module 1180 according to this embodiment.

[0078] 4, the monitoring module 1180 includes a communication unit 1181, a vehicle state acquisition unit 1182, a monitoring unit 1183, a monitoring information storage unit 1184, a monitoring log storage unit 1185, a reliability management unit 1186, and a table storage unit 1187. In this embodiment, the monitoring module 1180 is an example of a monitoring device for monitoring the vehicle 10 or a monitoring target operating within the vehicle 10.

[0079] In this embodiment, an example will be described in which the monitoring target of the monitoring module 1180 is a monitored module, but the unit of the monitoring target may be any one of a software process, an operating system, a hypervisor, a virtual machine running on a hypervisor, an electronic control unit (ECU) running within the vehicle 10, and the vehicle 10.

[0080] The communication unit 1181 is responsible for communication with the Hypervisor 1120, OSs running on other VMs, and modules or processes running within the OSs. The communication unit 1181 mainly receives inquiries from other modules and returns determination results. The communication unit 1181 is configured to include a communication module (communication circuit).

[0081] The vehicle state acquisition unit 1182 acquires, as vehicle state information, the running state of the vehicle 10, specific events occurring within the vehicle 10, etc. The vehicle state acquisition unit 1182 notifies the reliability management unit 1186 of the received vehicle state information.

[0082] The monitoring unit 1183 verifies the integrity of the file or memory area of ​​the module or VM to be monitored using a hash value or the like required for integrity verification, which is stored in the monitoring information storage unit 1184. The monitoring unit 1183 stores the verification result in the monitoring log storage unit 1185 and notifies the reliability management unit 1186 of the verification result.

[0083] The reliability management unit 1186 manages the reliability of the monitoring target module (monitoring target) in response to a vehicle event for each monitoring target module (monitoring target) using the vehicle state information received from the vehicle state acquisition unit 1182, the verification results received from the monitoring unit 1183, and a reliability management table (described later with reference to FIG. 5). The reliability management unit 1186 stores the reliability management table, which describes the reliability value for each monitoring target module, in the table storage unit 1187. FIG. 5 is a diagram showing an example of the reliability management table according to this embodiment.

[0084] As shown in FIG. 5, the reliability management table is a table in which monitoring targets are associated with the reliability of the monitoring targets. In the example of FIG. 5, the reliability of monitoring target module A (monitoring target module 1160) is 8, and the reliability of monitoring target module B (monitoring target module 1170) is 7. The reliability may be changed by a vehicle event. In other words, the reliability may change dynamically. Note that the reliability is expressed as a numerical value with an upper limit of 10 and a lower limit of 0, but it may be a value having at least two or more stages that indicate the degree of the status of each monitoring target module. Furthermore, the reliability may be ranked, for example, as "high," "medium," or "low."

[0085] Referring again to Fig. 4, the reliability management unit 1186 changes the reliability recorded in the reliability management table in accordance with the reliability adjustment rule. For example, the reliability management unit 1186 changes the reliability (for example, by a level of 2 or more) every time a vehicle event occurs. The reliability adjustment rule is stored in advance in, for example, the table storage unit 1187. Fig. 6 is a diagram showing an example of a reliability adjustment table according to this embodiment.

[0086] As shown in FIG. 6, the reliability adjustment rule is a table in which actions, targets, and results are associated with each other.

[0087] An action is a vehicle event that changes the reliability and is an example of a vehicle event that causes a change in the reliability level. Actions include, but are not limited to, completion of integrity verification, passage of a certain time, travel of a certain distance, occurrence of a specific vehicle event (positive), occurrence of a specific vehicle event (negative), a change in vehicle state (positive), a change in vehicle state (negative), and reset, as long as they include at least one of these.

[0088] "Integrity verification completed" indicates that integrity verification of the software to be monitored has been completed successfully, "a certain amount of time has passed" indicates that a certain amount of time has passed since a reference time or the time the previous integrity verification was performed, and "a certain distance traveled" indicates that a certain distance has been traveled from a reference location or the location where the previous integrity verification was performed. "Specific vehicle event occurrence" (positive) indicates that a vehicle event has occurred that increases the security of the monitored object, and "specific vehicle event occurrence" (negative) indicates that an event has occurred that decreases the security of the monitored object. "Specific vehicle events" are, for example, events based on actions taken by workers or the like on the vehicle 10, such as, but not limited to, vehicle maintenance, inspection, and repair.

[0089] A vehicle state change (positive) indicates that a change in the vehicle state has occurred that increases the security of the monitored object, and a vehicle state change (negative) indicates that a change in the vehicle state has occurred that decreases the security of the monitored object. A reset indicates that the monitored object has restarted (or been successfully restarted).

[0090] For example, for any monitored object that has been fully verified, the reliability of that monitored object is increased by +5. Also, after a certain distance has been traveled, the reliability of only monitored object module A among multiple monitored objects is decreased by -1.

[0091] As described above, a vehicle event that causes a change of stage may include an integrity verification of the software being monitored, the passage of a predetermined time, or a reset (restart) of the monitored software.

[0092] 6, if the integrity verification fails, the result may be set to a negative value. Also, the reset result is "+10", which indicates that the reliability of the monitoring target is increased by +10 after the reset. Also, the reliability may be changed to a reference value (for example, an initial value) after the reset.

[0093] 4, the reliability management unit 1186 also uses the function restriction table to restrict the functions of the monitoring target module 1160. The function restriction table is stored in advance in the table storage unit 1187, for example.

[0094] FIG. 7 is a diagram showing an example of a function restriction table according to the present embodiment.

[0095] As shown in FIG. 7, the function restriction table is a table in which restriction contents and threshold values ​​are associated with each other.

[0096] The restriction content indicates the content of the function restriction to be imposed on a monitoring target whose reliability falls below a threshold, and is an example of the content of at least some of the function restriction according to the reliability of each monitoring target. The threshold indicates the reliability value at which the restriction is implemented. In the example of FIG. 7, for example, when the threshold falls below 5, a communication restriction is implemented to the monitoring target module 1160 of other VMs, and when the threshold falls below 1, operation is stopped. In this way, the restriction content may be gradually strengthened as the reliability decreases.

[0097] As described above, restricting at least some of the functions according to the reliability of each monitored object may include restricting the communication function of the monitored object (e.g., stopping the communication function) or stopping the operation of the monitored object.

[0098] Note that restricting the communication functions of a monitored target is an example of terminating the monitored target's access rights to specific resources. Access to specific resources includes access to communication functions (communication modules), access to (specific) files, access to some OS functions, etc.

[0099] In this embodiment, each component of the monitoring module 1180 is mounted on the vehicle 10. That is, in this embodiment, the reliability management unit 1186 and the function restriction unit 1163 are mounted on the vehicle 10. Furthermore, it is sufficient that the vehicle network system 1000 includes at least the reliability management unit 1186 and the function restriction unit 1163.

[0100] [1.5 Example of a reliability update sequence] Fig. 8 is a diagram showing an example of a reliability update sequence (reliability management steps included in the monitoring method) according to this embodiment. It is assumed that steps S1101 to S1105 in Fig. 8 are each scheduled to be performed periodically. Also, Fig. 8 shows only the process of adding reliability, but subtraction process may also be performed.

[0101] (S1101) The monitoring module 1180 periodically performs an integrity verification process on the monitoring target module 1160. The integrity verification process here involves reading the memory area, calculating a hash value, and comparing it with a hash value previously stored as correct data to determine whether or not it matches, in order to detect tampering with the memory area of ​​the module that is the target of integrity verification.

[0102] (S1102) The monitoring unit 1183 determines whether the integrity verification process of step S1101 has ended normally. If the monitoring unit 1183 determines that the integrity verification process of step S1101 has ended normally, for example, if it determines that the calculated hash value matches the correct data ("Y" in S1102), the reliability management unit 1186 determines that no tampering or the like has been detected, and increases the reliability of the monitoring target module A (monitoring target module 1160) that is the target of verification. Note that if the monitoring unit 1183 determines that the calculated hash value matches the correct data, the reliability management unit 1186 may change (e.g., reset) the reliability to the maximum possible value.

[0103] Furthermore, if the monitoring unit 1183 determines that the integrity verification process of step S1101 has not been completed successfully, for example, if it determines that the hash value calculated by the monitoring unit 1183 does not match the correct data ("N" shown in S1102), the reliability management unit 1186 determines that this is an error and skips the process of changing the reliability of the monitored module A (monitored module 1160).

[0104] If it is determined that the hash value calculated by the monitoring unit 1183 does not match the correct data, the reliability management unit 1186 may subtract the reliability of the monitoring target module A that is the verification target. In step S1102, the reliability management unit 1186 may change (update) the reliability by performing at least one of adding the reliability if the integrity verification is completed successfully and subtracting the reliability if the integrity verification is not completed successfully.

[0105] (S1103) The monitored module 1170 receives maintenance and inspection processing from an external tool (not shown) and notifies the monitoring module 1180 that it has been completed successfully.

[0106] (S1104) The monitoring unit 1183 of the monitoring module 1180 determines whether the notified vehicle event corresponds to a specific vehicle event. For example, the monitoring unit 1183 checks (determines) whether the notified vehicle event is recorded in the reliability adjustment table. If the monitoring unit 1183 determines that the event is recorded ("Y" in S1104), the reliability management unit 1186 changes the reliability of the monitored module B (monitored module 1170) that is the target. Since the successful completion of the maintenance and inspection process corresponds to the occurrence (positive) of a specific vehicle event shown in FIG. 6, the reliability management unit 1186 adds "1" to the reliability of the monitored module 1170. Furthermore, if the reliability management unit 1186 determines that the event is not recorded ("N" in S1104), it skips the process of changing the reliability of the monitored module B (monitored module 1170).

[0107] In addition, in step S1104, the reliability management unit 1186 determines whether the vehicle event is a specific vehicle event occurrence (negative), and if it is a specific vehicle event occurrence (negative), it may subtract the reliability of the monitored module B to be verified, and if it is not a specific vehicle event occurrence (negative), it may skip the process of changing the reliability of the monitored module B.

[0108] (S1105) The reliability management unit 1186 determines whether a certain time (an example of a predetermined time) has elapsed, and if the certain time has elapsed ("Y" in S1105), it subtracts the reliability of all the modules to be monitored, and if the certain time has not elapsed ("N" in S1105), it skips the process of changing the reliability of all the modules to be monitored. The reliability management unit 1186 may subtract a predetermined number from the reliability of all the modules to be monitored each time a predetermined certain time has elapsed. Note that, when a certain time has elapsed, it is not limited to subtracting the reliability of all the modules to be monitored, and it may also be possible to subtract the reliability of only a specific module to be monitored.

[0109] [1.6 Example of a decision sequence using reliability] 9 is a diagram showing an example of a determination sequence (a function restriction step included in a monitoring method) using reliability according to this embodiment. Fig. 9 shows an example of a determination sequence using reliability when the monitoring target module 1160 requests a connection to the monitoring target module 1170. The monitoring target module 1170 is an example of a communication target of the monitoring target module 1160.

[0110] (S1201) The monitoring target module 1160 requests the monitoring target module 1170 to connect.

[0111] (S1202) The monitored module 1170 inquires of the monitoring module 1180 whether or not connection with the monitored module 1160 is possible.

[0112] (S1203) The monitoring module 1180 compares the current reliability of the monitored module 1160 with a threshold value, determines whether the monitored module 1160 is capable of communicating with other modules, and transmits the determination result to the monitored module 1170.

[0113] (S1204) The monitored module 1170 responds to the connection request from the monitored module 1160 based on the determination result received from the monitoring module 1180. If the monitored module 1160 is able to communicate with other modules ("Y" in S1204), the monitored module 1170 sends a connection response to the monitored module 1160 permitting the connection, and if the monitored module 1160 is not able to communicate with other modules ("N" in S1204), the monitored module 1170 sends an error notification to the monitored module 1160 and terminates the connection process with the monitored module 1160. Note that a display corresponding to the error notification may be displayed on the display 1013.

[0114] When the function restriction unit 1163 of the monitoring target module 1160 receives a connection response, it does not restrict communication with the monitoring target module 1170, and when it receives an error notification, it restricts communication with the monitoring target module 1170 (prohibits communication).

[0115] In this way, when the monitoring target module 1160 communicates with the monitoring target module 1170, if the reliability of the monitoring target module 1160 is less than a threshold, the function restriction unit 1163 prohibits the monitoring target module 1160 from communicating with the monitoring target module 1170. This makes it possible to prevent the monitoring target module 1160 with low reliability from communicating with the monitoring target module 1170. By the function restriction unit 1163 restricting communication, for example, if the monitoring target module 1160 is hacked, it is possible to prevent the effects of this hacking from spreading to the monitoring target module 1170.

[0116] The processing of steps S1201 to S1204 shown in FIG. 9 is executed, for example, before the monitoring target module 1160 starts communication with the monitoring target module 1170.

[0117] [1.7 Example of reliability restoration sequence] Fig. 10 is a diagram showing an example of a reliability restoration sequence (reliability management steps included in the monitoring method) according to this embodiment. Fig. 10 shows an example of a sequence in which the monitoring module 1180 restores the monitoring target module 1160 in response to a decrease in the reliability of the monitoring target module 1160. It is assumed that steps S1301 to S1303 in Fig. 10 are each scheduled to be performed periodically.

[0118] (S1301) The reliability management unit 1186 determines whether the current reliability of the monitoring target module A (monitoring target module 1160) is less than a threshold value. The threshold value here is a threshold value for determining whether to execute a restart. The reliability management unit 1186 checks the current reliability of the monitoring target module 1160, and if it is equal to or greater than the threshold value ("N" in S1301), ends the processing. Furthermore, if the current reliability of the monitoring target module 1160 is less than the threshold value ("Y" in S1301), the reliability management unit 1186 commands the monitoring target module 1160 to restart.

[0119] (S1302) The monitoring target module 1160 restarts and notifies the monitoring module 1180 of the completion of the restart. The completion of the restart here means that the restart has been completed normally.

[0120] (S1303) The reliability management unit 1186 increments the reliability of the monitoring target module A (monitoring target module 1160). Note that in step S1303, the reliability management unit 1186 may perform at least one of the following if the restart is completed successfully: incrementing the reliability or resetting the reliability to an initial value; and if the restart is not completed successfully, decrementing the reliability.

[0121] [1.8 Effects of the First Embodiment] The vehicle network system 1000 (monitoring system) shown in embodiment 1 restricts the functionality of the monitored module depending on the time elapsed since the last verification date and time of the monitored module, thereby reducing the possibility that a monitored module with reduced reliability will be tampered with and pose a threat to other modules, and making it possible to ensure the safety of the integrated ECU 1100 as a whole.

[0122] The present disclosure may be realized as a configuration in which the monitoring module 1180 included in the vehicle network system 1000 includes a monitoring module 1180 (an example of a monitoring device) for monitoring the vehicle 10 or a monitoring target operating within the vehicle 10, and a function restriction unit 1163 (an example of a function restriction device) for restricting the functions of the vehicle 10 or a monitoring target operating within the vehicle 10, and the monitoring module 1180 includes a reliability management unit 1186 for managing the reliability of each monitoring target according to a vehicle event. The present disclosure may also be realized as a function restriction device included in the vehicle network system 1000, and the function restriction unit 1163 for restricting at least a portion of the functions of each monitoring target according to the reliability of the monitoring target according to a vehicle event. In other words, the reliability management unit 1186 and the function restriction unit 1163 may each be realized as a separate device.

[0123] (Modification of the first embodiment) In the first embodiment, a method in which the monitoring module 1180 manages reliability was described, but in this modification, an example of a method in which a monitored module manages its own reliability will be described with reference to the drawings. Note that descriptions of drawings similar to those in the first embodiment will be omitted. Furthermore, components and processing steps similar to those in the first embodiment will be assigned the same numbers, and descriptions thereof will be omitted.

[0124] [1.1.1 Configuration diagram of monitored module 11160] FIG. 11 is a diagram showing an example of the configuration of a monitoring target module 11160 according to this modification.

[0125] 11, the monitored module 11160 includes a communication unit 1161, a function processing unit 1162, a function restriction unit 1163, a vehicle state acquisition unit 11164, a reliability management unit 11165, and a table storage unit 11166. Note that the monitored module 11170 (see FIG. 14) has a similar configuration, and therefore description thereof will be omitted.

[0126] The vehicle state acquisition unit 11164 acquires the running state of the vehicle 10, specific vehicle events occurring within the vehicle 10, and the like as vehicle state information. The vehicle state acquisition unit 11164 may acquire the vehicle state information from, for example, each main sensor mounted on the vehicle 10. The vehicle state acquisition unit 11164 notifies the reliability management unit 11165 of the acquired vehicle state information.

[0127] The reliability management unit 11165 manages the reliability of itself (here, the monitoring target module 11160) using a reliability management table. The reliability management unit 11165 stores the reliability management table, in which the reliability values ​​of its own are recorded, in the table storage unit 11166. Fig. 12 is a diagram showing an example of the reliability management table according to this modification.

[0128] As shown in Fig. 12, the reliability management table includes its own reliability. In the example of Fig. 12, the reliability of itself (for example, the monitoring target module 11160) is 8. Note that the reliability table does not include the reliability of monitoring targets other than itself.

[0129] 11 again, the reliability management unit 11165 changes the reliability written in the reliability management table in accordance with the reliability adjustment rules. The reliability adjustment rules are stored in advance in the table storage unit 11166. An example of the reliability adjustment table is the same as that in the first embodiment (see FIG. 6), so a description thereof will be omitted.

[0130] Furthermore, the reliability management unit 11165 restricts the functions of the monitoring target module (i.e., itself) using a function restriction table. The function restriction table is stored in advance in, for example, the table storage unit 11166. An example of the function restriction table is the same as that in the first embodiment (see FIG. 7), and therefore a description thereof will be omitted.

[0131] [1.1.2 Configuration diagram of monitoring module 11180] FIG. 13 is a diagram showing an example of the configuration of the monitoring module 11180 according to this embodiment.

[0132] As shown in FIG. 13, the monitoring module 11180 includes a communication unit 11181, a monitoring unit 11183, a monitoring information storage unit 1184, and a monitoring log storage unit 1185.

[0133] The communication unit 11181 is responsible for communication with the hypervisor 1120, OSs running on other VMs, modules and processes running within the OSs, etc. The communication unit 11181 mainly transmits the verification results of the monitoring unit 11183 to other modules. The communication unit 11181 is configured to include a communication circuit.

[0134] The monitoring unit 11183 verifies the integrity of the file or memory area of ​​the module or VM to be monitored by using a hash value (correct answer data) or the like required for integrity verification from the monitoring information storage unit 1184. The monitoring unit 11183 stores the verification result in the monitoring log storage unit 1185 and transmits it to other modules via the communication unit 11181.

[0135] [1.1.3 Example of a reliability update sequence] 14 is a diagram showing an example of a reliability update sequence (reliability management steps included in the monitoring method) according to this modification. Note that steps S1101 and S11001 to S11005 in FIG. 14 are each scheduled to be performed periodically.

[0136] (S11001) The monitoring unit 11183 of the monitoring module 11180 determines whether the integrity verification process of step S1101 has ended normally. If the integrity verification process of step S1101 has ended normally ("Y" in S11001), the monitoring unit 11183 determines that no tampering or the like has been detected, and notifies the monitored module 11160 of the verification result to that effect. Furthermore, if the integrity verification process of step S1101 has not ended normally ("N" in S11001), the monitoring unit 11183 determines that an error has occurred, and skips notifying the monitored module 11160.

[0137] The monitoring unit 11183 performs, for example, the processes of steps S1101 and S11001 for each of a plurality of monitoring targets. If the integrity verification process of step S1101 does not end normally, the monitoring unit 11183 may notify the monitoring target module 11160 of the verification result indicating this fact.

[0138] (S11002) The reliability management unit 11165 of the monitoring target module 11160 that has received the notification updates (here, adds) the reliability that it manages. Note that when the reliability management unit 11165 acquires a verification result notification indicating that the integrity verification process has ended successfully, it may change its own (monitoring target module 11160) reliability to the maximum possible value.

[0139] (S11003) When the monitored module 11170 receives a maintenance and inspection process from an external tool (not shown), it executes the maintenance and inspection process.

[0140] (S11004) The reliability management unit of the monitored module 11170 determines whether the vehicle event that has occurred corresponds to a specific vehicle event. For example, the reliability management unit checks (determines) whether the vehicle event that has occurred is recorded in the reliability adjustment table. If the reliability management unit determines that there is a record ("Y" in S11004), it changes the reliability of its own (monitored module B). Since the successful completion of the maintenance and inspection process corresponds to the occurrence of a specific vehicle event (positive) as shown in Figure 6, the reliability management unit increments its own reliability by +1. Furthermore, if there is no record ("N" in S11004), the reliability management unit skips the process of changing its own reliability.

[0141] (S11005) The reliability management unit 11165 of the monitored module 11160 and the reliability management unit of the monitored module 11170 each determine whether a certain amount of time has passed. If the certain amount of time has passed ("Y" in S11005), the reliability management unit 11165 updates (here, subtracts) its own reliability (monitored module A), and if the certain amount of time has not passed ("N" in S11005), skips the process of changing its own reliability. Furthermore, the reliability management unit of the monitored module 11170 updates (here, subtracts) its own reliability (monitored module B) if a certain amount of time has passed ("Y" in S11005), and skips the process of changing its own reliability if the certain amount of time has not passed ("N" in S11005).

[0142] In this way, in step S11005, the monitoring target module 11160 and the monitoring target module 11170 subtract a preset number from their own reliability, which they manage themselves, every time a preset period of time elapses, for example.

[0143] [1.1.4 Example of a judgment sequence using reliability] Fig. 15 is a diagram showing an example of a determination sequence (a function restriction step included in a monitoring method) using reliability according to this modification. Fig. 15 shows an example of a determination sequence using reliability when a monitoring target module 11160 requests a connection to a monitoring target module 11170.

[0144] (S11201) The monitored module 11160 determines whether its own reliability is equal to or greater than a threshold. The monitored module 11160 compares its current reliability with the threshold, and can be said to determine whether it is capable of communicating with other modules. If the monitored module 11160 determines that communication is not possible ("N" in S11201), that is, if it is determined that the reliability is less than the threshold, it terminates the process as an error. If the determination results in communication possible ("Y" in S11201), that is, if it is determined that the reliability is equal to or greater than the threshold, the monitored module 11160 requests a connection from the monitored module 11170.

[0145] If the result of the determination is that communication is not possible, the monitoring target module 11160 may notify the monitoring module 11180 that communication is not possible. The threshold value may be set in advance and may be stored in the table storage unit 11166, for example.

[0146] (S11202) When the monitored module 11170 receives a connection request from the monitored module 11160, it determines whether its current reliability is equal to or greater than a threshold. The monitored module 11170 compares its current reliability with the threshold and determines whether it can communicate with other modules. The monitored module 11170 responds to the connection request from the monitored module 11160 based on the determination result. For example, if the determination result shows that communication is not possible ("N" in S11202), that is, if the reliability is determined to be less than the threshold, the monitored module 11170 sends an error notification to the monitored module 11160 and terminates the connection process with the monitored module 11160. Furthermore, for example, if the determination result shows that communication is possible ("Y" in S11202), that is, if the reliability is determined to be equal to or greater than the threshold, the monitored module 11170 sends a connection response to the monitored module 11160 indicating that the connection is permitted.

[0147] In this manner, in this modification, the monitoring target module 11160 and the monitoring target module 11170 each determine their own reliability. Then, the monitoring target module 11160 and the monitoring target module 11170 communicate only if the reliability of each of the monitoring target module 11160 and the monitoring target module 11170 is equal to or greater than a threshold. In other words, in this modification, the monitoring module 11180 is not involved in determining whether communication is possible. Note that the threshold used in the determination in step S11201 and the threshold used in the determination in step S11202 may be the same value, or may be different values.

[0148] The function restriction unit (here, the function restriction unit 1163 and the function restriction unit provided in the monitored module 11170) provided in the vehicle network system of this modified example can also be said to prohibit communication between the monitored module 11160 and the monitored module 11170 when at least one of the reliability of the monitored module 11160 and the reliability of the monitored module 11170 is below a threshold value when the monitored module 11160 and the monitored module 11170 communicate with each other.

[0149] [1.1.5 Example of reliability restoration sequence] Fig. 16 is a diagram showing an example of a reliability restoration sequence according to this modification. Fig. 16 shows an example of a sequence for the monitoring target module 11160 to restore its own module reliability following a decrease in its own module reliability. It is assumed that steps S11301 to S11303 in Fig. 16 are each scheduled to be performed periodically.

[0150] (S11301) The monitored module 11160 determines whether the current reliability of its own module is below the threshold. If the reliability is equal to or greater than the threshold ("N" in S11301), the monitored module 11160 terminates processing. If the reliability of its own module is below the threshold ("Y" in S11301), the monitored module 11160 issues a command to restart.

[0151] (S11302) If the result of step S11301 is that the reliability of the own module is less than the threshold, the monitoring target module 11160 restarts.

[0152] (S11303) If the restart is successful, the monitored module 11160 increments the reliability of its own module. If the memory area of ​​the module has been tampered with, the restart may not be performed normally, so the monitored module 11160 increments the reliability of its own module if the restart is successful. Note that if the restart is successful, the monitored module 11160 may set the reliability of its own module to an initial value.

[0153] The processing shown in FIG. 16 may be executed by, for example, the reliability management unit 11165 of the monitoring target module 11160.

[0154] [1.1.6 Effects of the Modification of the First Embodiment] In the vehicle network system shown in the modification of the first embodiment, the reliability of each module is managed by the module itself, thereby reducing the code size of the monitoring module 11180 and enabling it to easily operate on a Trusted OS. This is expected to have a cost-cutting effect, and it is possible to reduce the possibility that a monitored module with a lowered reliability will be tampered with and pose a threat to other modules in a wider range of systems, thereby ensuring the safety of the integrated ECU 1100 as a whole.

[0155] (Embodiment 2) The monitoring module 1180 (an example of a monitoring device) shown in the first embodiment (1) exists on an ECU, (2) module units operating on a specific ECU in the vehicle 10 are monitored for reliability, and (3) reliability is expressed numerically, but (1') it may exist outside the vehicle 10, (2') the reliability monitoring unit is not limited to a module but may be, for example, a VM, an ECU, or the vehicle 10, and (3') reliability may be expressed as a status such as OK or NG instead of a number. An example of the above is shown in the second embodiment.

[0156] [2. System Configuration] Here, as an embodiment of the present disclosure, a network system 2000 will be described with reference to the drawings. Note that descriptions of the same drawings as in embodiment 1 will be omitted. Furthermore, components and processing steps similar to those in embodiment 1 will be assigned the same numbers, and descriptions thereof will be omitted.

[0157] [2.1 Overall Configuration of Network System 2000] 17 is a diagram showing an example of the overall configuration of a network system 2000 according to this embodiment. The network system 2000 is an example of a monitoring system.

[0158] 17, the network system 2000 includes a vehicle 11 and a server 20 communicatively connected to the vehicle 11. The vehicle 11 includes, as a vehicle network system inside the vehicle 11, a brake 1011, an engine 1012, a display 1013, and an integrated ECU 2100 connected to all of them. Here, the integrated ECU 2100 has both a communication unit inside the vehicle 10 and a communication unit to the outside of the vehicle 10.

[0159] [2.2 Integrated ECU2100 configuration diagram] FIG. 18 is a diagram showing an example of the configuration of an integrated ECU 2100 according to this embodiment.

[0160] As shown in Figure 18, the integrated ECU 2100 is assumed to have an environment in which a Hypervisor 1120 and a Trusted Execution Environment (hereinafter referred to as TEE) 1130 run on a hardware SoC 1110, multiple Virtual Machines (hereinafter referred to as VMs) (not shown) are started on the Hypervisor 1120, and an Operating System (hereinafter referred to as OS) runs on each VM.

[0161] In this embodiment, a monitoring target OS 2140 and a monitoring target OS 2150 are the monitoring targets, and a monitoring module 2180 that monitors the monitoring target OS 2140 and the monitoring target OS 2150 runs on the TEE 1130. Furthermore, a function restriction module 2160 runs on the monitoring target OS 2140, and a function restriction module 2170 runs on the monitoring target OS 2150. The function restriction modules 2160 and 2170 have the same functions as the function restriction unit 1163 shown in Fig. 3. The function restriction modules 2160 and 2170 are examples of a function restriction unit.

[0162] In the following description, the monitoring target OS 2140 will also be referred to as the monitoring target OS-A, and the monitoring target OS 2150 will also be referred to as the monitoring target OS-B.

[0163] [2.3 Configuration diagram of monitoring module 2180] FIG. 19 is a diagram showing an example of the configuration of the monitoring module 2180 according to this embodiment.

[0164] As shown in FIG. 19, the monitoring module 2180 includes a communication unit 2181, a vehicle state acquisition unit 2182, a monitoring unit 2183, a monitoring information storage unit 1184, and a monitoring log storage unit 1185.

[0165] The communication unit 2181 is responsible for communication with the Hypervisor 1120, OSs running on other VMs, modules or processes running within the OSs, and the like, as well as communication with the server 20 outside the vehicle 10. The communication unit 2181 mainly notifies the server 20 of the verification results of the monitoring unit 2183, the vehicle state received by the vehicle state acquisition unit 2182, and the like, and notifies the determination results of the server 20 to other modules. The communication unit 2181 has a communication circuit (communication module).

[0166] The vehicle state acquisition unit 2182 acquires the vehicle's running state, specific events occurring inside the vehicle, and the like as vehicle state information. The vehicle state acquisition unit 2182 notifies the server 20 of the received vehicle state information via the communication unit 2181. Note that the vehicle state information can be acquired from the vehicle and various sensors mounted thereon.

[0167] The monitoring unit 2183 verifies the integrity of the file or memory area of ​​the VM to be monitored by using a hash value (correct data) or the like required for integrity verification in the monitoring information storage unit 1184. The monitoring unit 2183 stores the verification result in the monitoring log storage unit 1185 and notifies the server 20 of the verification result via the communication unit 2181.

[0168] [2.4 Server 20 Configuration Diagram] FIG. 20 is a diagram showing an example of the configuration of the server 20 according to the present embodiment.

[0169] As shown in FIG. 20, the server 20 includes a communication unit 21, a display unit 22, a reliability management unit 23, and a table storage unit 24.

[0170] The communication unit 21 is responsible for communication with the vehicle 11 .

[0171] The display unit 22 is a display device that displays information indicating a monitoring target (for example, a monitoring target module) together with the reliability of the monitoring target. The display unit 22 is realized by, for example, a liquid crystal display.

[0172] The reliability management unit 23 manages the reliability of the monitored modules using the vehicle status information, verification results, and a reliability management table received from the vehicle 11. The reliability management table describes the reliability value for each monitored module, and is stored in the table storage unit 24.

[0173] FIG. 21 is a diagram showing an example of a reliability management table according to the present embodiment.

[0174] As shown in Fig. 21, the reliability management table is a table in which monitoring targets are associated with the reliability of the monitoring targets. In the example of Fig. 21, the reliability of monitoring target OS-A (monitoring target OS 2140) is OK, and the reliability of monitoring target OS-B (monitoring target OS 2150) is NG. In this way, the reliability may be expressed in two stages (for example, as a determination result).

[0175] Referring again to Fig. 20, the reliability management unit 23 changes the reliability recorded in the reliability management table in accordance with the reliability adjustment rule. For example, the reliability management unit 23 changes the reliability every time a vehicle event occurs. The reliability adjustment rule is stored in advance in, for example, the table storage unit 24. Fig. 22 is a diagram showing an example of a reliability adjustment table according to this embodiment.

[0176] 22, the reliability adjustment rule is a table in which actions, targets, and results are associated with each other. Actions include whether an error occurs and resetting. Alternatively, an action may be that an error occurs a predetermined number of times (for example, five or more times).

[0177] 20 again, the reliability management unit 23 uses the function restriction table to restrict the functions of the monitoring target module. The function restriction table is stored in the table storage unit 24 in advance, for example.

[0178] FIG. 23 is a diagram showing an example of a function restriction table according to the present embodiment.

[0179] 23, the function restriction table is a table in which restriction contents and target states are associated with each other. The restriction contents include restricting communication with other vehicles and stopping operation.

[0180] 18 and 20 have described an example in which the server 20 includes the reliability management unit 23 and the integrated ECU 2100 includes a function restriction unit (function restriction module), but the server 20 may include a function restriction unit instead of or in addition to the reliability management unit 23. That is, the server 20 may include at least one of the reliability management unit 23 and the function restriction unit.

[0181] [2.5 Example of a reliability update sequence] 24 is a diagram showing an example of a reliability update sequence (reliability management steps included in the monitoring method) according to this embodiment. Note that steps S1101 and S2103 to S2105 in FIG. 24 are each scheduled to be performed periodically.

[0182] (S2103) The monitoring module 2180 determines whether an error has occurred, for example, whether the integrity verification process in step S1101 has ended normally.

[0183] (S2104) If the monitoring module 2180 determines that an error has occurred ("Y" in S2103), that is, if the integrity verification process of step S1101 has not ended normally, it refers to the reliability adjustment table and changes the reliability of the OS-A to be monitored (OS 2140 to be monitored). For example, the monitoring module 2180 sets the status to OK if the complete verification is successful or the number of successful integrity verification attempts exceeds a specified number, and sets the status to NG if the complete verification is unsuccessful or the number of errors exceeds a specified number.

[0184] (S2105) The monitoring module 2180 stores the result of the reliability changed in step S2104 in a log, and uploads the same content to the server 20.

[0185] [2.6 Example of a decision sequence using reliability] Fig. 25 is a diagram showing an example of a determination sequence (a function restriction step included in a monitoring method) using reliability according to this embodiment. Fig. 25 shows an example of a determination sequence using reliability when the OS 2140 to be monitored requests an external communication connection. The device to which the external communication is connected is an example of a communication target of the OS 2140 to be monitored.

[0186] (S2201) The OS 2140 to be monitored requests the monitoring module 2180 for connection.

[0187] (S2202) The monitoring module 2180 inquires of the server 20 whether or not connection with the OS 2140 to be monitored is possible.

[0188] (S2203) The server 20 determines whether or not an external connection is possible based on the reliability of the monitoring target OS-A (monitoring target OS 2140). For example, the server 20 checks the reliability of the monitoring target OS 2140 and the function restriction table, determines whether or not the monitoring target OS 2140 is able to communicate with the outside, and transmits the determination result to the monitoring module 2180.

[0189] (S2204) The monitoring module 2180 responds to the connection request from the OS 2140 to be monitored based on the determination result received from the server 20. If the OS 2140 to be monitored is capable of communicating with the outside ("Y" in S2204), the monitoring module 2180 transmits a connection permission response to the OS 2140 to be monitored that permits the connection, and if the OS 2140 to be monitored is not capable of communicating with the outside ("N" in S2204), the monitoring module 2180 transmits an error notification to the OS 2140 to terminate the external connection processing in the OS 2140 to be monitored.

[0190] When the function restriction module 2160 (an example of a function restriction section) of the monitored OS 2140 receives a connection permission response, it does not restrict communication with a device external to the vehicle 10 (an example of a communication target), and when it receives an error notification, it restricts (prohibits) communication with a device external to the vehicle 10.

[0191] In this way, when the OS 2140 to be monitored communicates with a device external to the vehicle 10, if the reliability of the OS 2140 to be monitored is less than the threshold, the function restriction module 2160 prohibits the OS 2140 to be monitored from communicating with a device external to the vehicle 10. This makes it possible to prevent the OS 2140 to be monitored that has a low reliability from communicating with a device external to the vehicle 10.

[0192] The processing of steps S2201 to S2204 shown in FIG. 25 is executed, for example, before the OS 2140 to be monitored starts communication with a communication target.

[0193] [2.7 Example of reliability restoration sequence] Fig. 26 is a diagram showing an example of a reliability restoration sequence according to the present embodiment. Fig. 26 shows an example of a sequence in which the server 20 restores the monitoring target OS 2140 via the monitoring module 2180 in response to a change in the reliability of the monitoring target OS 2140. It is assumed that steps S2301 to S2305 in Fig. 26 are each scheduled to be performed periodically.

[0194] (S2301) The server 20 determines whether the current reliability of the monitoring target OS-A (monitoring target OS 2140) is less than the threshold. If the reliability is not less than the threshold (the reliability is equal to or greater than the threshold) ("N" in S2301), that is, if the reliability is in an OK state, the server 20 ends the processing. Also, if the reliability of the monitoring target OS 2140 is less than the threshold ("Y" in S2301), that is, if the reliability is in an NG state, the server 20 commands the monitoring module 2180 to restart the monitoring target OS 2140.

[0195] (S2302) When the monitoring module 2180 receives from the server 20 a command to reboot the OS 2140 to be monitored, the monitoring module 2180 commands the OS 2140 to be monitored to reboot (transmits a reboot command).

[0196] (S2303) When the reboot is successful, the monitored OS 2140 notifies the monitoring module 2180 of the reboot completion (transmits a reboot completion notification).

[0197] (S2304) Upon receiving the reboot completion notification, the monitoring module 2180 notifies the server 20 that the reboot of the monitoring target OS 2140 has been completed (transmits the reboot completion notification).

[0198] (S2305) The server 20 changes the reliability of the monitoring target OS 2140. Here, the server 20 adds the reliability of the monitoring target OS 2140.

[0199] [2.8 Effects of the Second Embodiment] The monitoring device shown in embodiment 2 restricts functions according to the verification results of the OS to be monitored, thereby reducing the possibility that a monitored OS with reduced reliability will be tampered with and pose a threat to other modules, and making it possible to ensure the safety of the integrated ECU 2100 as a whole.

[0200] (Other embodiments) [3. Other variations] Although the present disclosure has been described based on the above-described embodiments, it goes without saying that the present disclosure is not limited to the above-described embodiments. The following cases are also included in the present disclosure. Note that Figures 27 to 35 shown below are diagrams illustrating examples of the configuration of the integrated ECU.

[0201] (1) In the above embodiment, software integrity verification is described as an example of reliability addition, and the passage of a certain period of time is described as an example of reliability subtraction. However, vehicle events are not limited to this. For example, as shown in FIG. 6, the vehicle events to be added and subtracted may be determined for each vehicle event, or for each vehicle driving state. For example, examples of driving states include the start or end of driving, the start or end of stopping, the start or end of parking, the start or end of connecting to an external charger, and the start or end of charging. Examples of specific vehicle events occurring within the vehicle include the start or completion of maintenance and inspection processing, the start or end of communication with an external device, the occurrence of a security error or failure, an ECU update, and an ECU function check by an external maintenance tool. Furthermore, while the above embodiment allows reliability adjustment items to be set for each module, they may also be set uniformly for all monitored objects.

[0202] (2) In the above modification of the first embodiment, the monitoring module verifies the integrity of the software of the monitored module and notifies the result directly. However, the result may be notified to all modules in the vehicle as a vehicle event. The monitored module can receive the vehicle event and reflect it in its own reliability.

[0203] (3) In the above embodiment, a monitoring device for an integrated ECU in an environment where a hypervisor is installed has been described, but the present disclosure is not limited to the presence or absence of a hypervisor. For example, as shown in FIGS. 27, 28, and 29, the present disclosure may be realized in an environment where a hypervisor is not installed. FIGS. 27 to 29 are diagrams illustrating examples of the configuration of an integrated ECU according to other embodiments. FIG. 27 illustrates an example in which a monitoring module monitors monitoring target modules A and B in the same monitoring target OS. FIG. 28 illustrates an example in which a monitoring module monitors the monitoring target OS. FIG. 29 illustrates an example in which a monitoring module monitors monitoring target modules in the monitoring target OS. In this case, the monitoring module may run on the TEE 1130 or may run on the same OS as the modules to be monitored.

[0204] (4) In the above embodiment, the unit of the monitoring target to which reliability is assigned is an OS or a module running on the OS. However, this is not limiting. As shown in FIG. 30, a hypervisor may also be a monitoring target. Furthermore, the monitoring target may be, for example, an ECU itself, a function implemented by multiple ECUs (e.g., an ADAS system), or even a vehicle itself. Furthermore, the reliability management unit may add up the reliability of each module to calculate the reliability of the OS, add up the reliability of each OS to calculate the reliability of the integrated ECU, or add up the reliability of each ECU to calculate the reliability of the vehicle.

[0205] (5) In the above embodiment, the monitoring module running on the TEE monitors all monitoring targets, but this is not limiting. For example, as shown in Figures 31 and 32, the monitoring module may run on a hypervisor, or may run as hardware on an SoC. Furthermore, as shown in Figure 33, a separate monitoring module may be installed for each monitoring target.

[0206] (6) In the above embodiment, an example of restoring reliability is given in which a module or the OS itself is rebooted, but a dedicated module for restoring reliability may be placed in an area other than the target area. For example, as shown in Fig. 34, to restore the monitored OS, the hypervisor may reboot the VM, or the SoC may reboot.

[0207] (7) In the above embodiment, an example of function restriction is given as an example of restriction by a module or the OS itself, but a dedicated module for implementing this function restriction may be placed in an area other than the target area. For example, as shown in Fig. 35, a new function restriction module may be placed in a hypervisor, and when this function restriction module relays communication between the monitoring target modules A and B and the monitoring module, it may inquire about the content of the function restriction to the monitoring module and implement the function restriction on the monitoring target modules A and B.

[0208] (8) In the above embodiment, reliability was used to determine internal processing. However, a screen showing the reliability of each monitoring target may be prepared in order to manage reliability in a server or vehicle. FIG. 36 is a diagram showing an example of the display screen 22a in another embodiment. FIG. 36 shows an example of a screen in which reliability is mapped to each monitoring target. Each monitoring target is mapped along with its location, and the current reliability is displayed superimposed on it. These locations are merely examples, and the present invention is not limited to these. For example, a screen that displays a list in a table may also be used. Furthermore, rather than simply displaying the status, an operation screen (e.g., operation icons) may be provided so that each monitoring target can be selected and instructions such as resetting or stopping operation can be given from the screen.

[0209] (9) Each device in the above embodiments is specifically a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device achieves its function when the microprocessor operates in accordance with the computer program. Here, a computer program is composed of a combination of multiple instruction codes that indicate commands to a computer to achieve a predetermined function.

[0210] (10) In each of the above embodiments, some or all of the constituent elements may be configured from a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured to include a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.

[0211] (11) Furthermore, each of the components constituting each of the above devices may be individually integrated into a single chip, or some or all of them may be integrated into a single chip.

[0212] Although we refer to it as a system LSI here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the level of integration. Furthermore, the method of integration is not limited to LSI; it can also be realized using dedicated circuits or general-purpose processors. It is also possible to use FPGAs (Field Programmable Gate Arrays), which can be programmed after LSI manufacturing, or reconfigurable processors, which allow the connections and settings of circuit cells within LSI to be reconfigured.

[0213] Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or other derivative technologies, it is natural that such technology could be used to integrate functional blocks. The application of biotechnology is also a possibility.

[0214] (12) Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates according to a computer program. This IC card or module may be tamper-resistant.

[0215] (13) The present disclosure may be embodied as the methods described above. Furthermore, the present disclosure may be embodied as a computer program for implementing these methods on a computer, or as a digital signal comprising the computer program. The computer program may be, for example, a computer program for causing a computer to execute each of the characteristic steps included in the monitoring method shown in any of Figures 8 to 10, 14 to 16, and 24 to 26.

[0216] The present disclosure may also be a computer program or a digital signal recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. Alternatively, the present disclosure may be a digital signal recorded on such a recording medium.

[0217] The present disclosure may also be applied to transmitting a computer program or digital signal via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0218] The present disclosure may also be a computer system having a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating in accordance with the computer program.

[0219] The program or digital signal may also be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, so that the program or digital signal can be implemented by another independent computer system.

[0220] (14) Furthermore, the vehicle network system according to the above-described embodiments may be realized as a single device or may be realized by multiple devices. When the vehicle network system is realized by multiple devices, the components of the vehicle network system may be distributed among the multiple devices in any manner. When the vehicle network system is realized by multiple devices, the communication method between the multiple devices is not particularly limited and may be wireless communication or wired communication. Furthermore, wireless communication and wired communication may be combined between the devices.

[0221] (15) The order in which each step is executed in each sequence diagram is merely an example for specifically explaining the present disclosure, and an order other than the above may be used. Also, some of the steps may be executed simultaneously (in parallel) with other steps, or some of the steps may not be executed.

[0222] (16) Furthermore, at least one of the reliability management table, reliability adjustment table, and function restriction table in the above embodiments may be a different table for each monitoring target, or may be a common table for each monitoring target.

[0223] (17) In the above embodiment, an example has been described in which the function of a monitored object is restricted using a reliability level to which a value is added when the safety of the monitored object is confirmed, for example, when the integrity verification is completed normally. However, the function of a monitored object may also be restricted using a risk level to which a value is added when the safety of the monitored object is not confirmed, for example, when the integrity verification is not completed normally. The reliability level and risk level are examples of indicators that indicate the security protection status of a vehicle.

[0224] (18) The above-described embodiments and modifications may be combined. Furthermore, the technology of the present disclosure is not limited to these, and may be applied to embodiments in which modifications, substitutions, additions, omissions, etc. are made as appropriate. For example, as long as they do not deviate from the spirit of the present disclosure, various modifications conceivable by a person skilled in the art may be made to the present embodiments, and embodiments constructed by combining components of different embodiments may also be included in the present disclosure. [Industrial Applicability]

[0225] This disclosure makes it possible to clarify the reliability of each element that makes up a system, thereby minimizing damage in the event of an abnormality and maintaining a safe state. [Explanation of symbols]

[0226] Cars 10 and 11 20 servers 21, 1161, 1181, 2181, 11181 Communications Department 22 Display section 22a display screen 23, 1186, 11165 Reliability Management Department 24, 1187, 11166 Table storage section 1000 Vehicle Network System (Monitoring System) 1011 Brake 1012 Engine 1013 Display 1100, 2100 Integrated ECU 1110 SoC 1120 Hypervisor 1130 TEE 1140, 1150 OS 1160, 1170, 11160, 11170 Monitored modules 1162 Functional Processing Unit 1163 Functionality Restriction Section 1180, 2180, 11180 Monitoring Module 1182, 2182, 11164 Vehicle status acquisition unit 1183, 2183, 11183 Monitoring Department 1184 Monitoring information storage unit 1185 Monitoring log storage unit 2000 Network System (Monitoring System) 2140, 2150 Monitored OS 2160, 2170 Limited Function Module

Claims

1. A monitoring system for monitoring an integrated ECU (Electronic Control Unit) that integrates functions of a plurality of ECUs and operates in a vehicle or the vehicle, comprising: The integrated ECU is configured to be able to operate a plurality of virtual machines, each of the plurality of virtual machines includes a function of at least one ECU among the functions of the plurality of ECUs; The monitoring system includes: one of the plurality of virtual machines as a first monitoring target in order to monitor functions of the plurality of ECUs; a reliability management unit that manages a first reliability indicating a security protection state of the first monitoring target, the first reliability is a value having at least two or more stages indicating the degree of the security protection state of the first monitoring target, The monitoring system includes: Verifying the integrity of the first monitored software; performing at least one of changing the level of the security protection state of the first degree of reliability to a higher level when the integrity verification is completed successfully, or changing the level of the security protection state of the first degree of reliability to a lower level when the integrity verification is not completed successfully; changing the level of the security protection state of the first reliability to a lower level after a certain period of time has elapsed since the time when the integrity verification was performed; Surveillance system.

2. The integrated ECU further operates a TEE (Trusted Execution Environment), The integrity verification is performed in the TEE. The monitoring system of claim 1 .

3. the plurality of virtual machines operating on the integrated ECU operate on a hypervisor; The monitoring system further monitors the hypervisor. The monitoring system of claim 1 .

4. Further, a function limiting unit that limits at least a part of the functions of the first monitoring target in accordance with the first reliability. The monitoring system of claim 1 .

5. (delete)

6. (delete)

7. the monitoring system restarts the first monitoring target; The monitoring system of claim 1 .

8. When the reboot is successfully completed, the monitoring system changes the level of the security protection state of the first reliability to a higher level or changes the first reliability to an initial value. The monitoring system of claim 7.

9. the monitoring system determines whether the first reliability of the first monitoring target is less than a threshold, and if the first reliability is less than the threshold, causes the first monitoring target to execute the restart; The monitoring system of claim 7.

10. At least a part of the function restriction of the first monitoring target according to the first reliability level includes terminating the first monitoring target's access right to a specific resource. The monitoring system according to any one of claims 4 and 7 to 9.

11. The restriction of at least some of the functions of the first monitoring target according to the first reliability includes stopping a communication function of the first monitoring target. The monitoring system of claim 10.

12. restricting at least a portion of the functions of the first monitoring target in accordance with the first reliability includes stopping a communication function of the first monitoring target; the function restriction unit prohibits the first monitoring target from communicating with the communication target when the first reliability is less than a threshold value when the first monitoring target communicates with the communication target; The monitoring system of claim 4.

13. the monitoring system further designates one of the plurality of virtual machines other than the first monitoring target as a second monitoring target; the reliability management unit further manages a second reliability indicating a security protection state of the second monitoring target, the function restriction unit prohibits communication between the first monitoring target and the second monitoring target when at least one of the first reliability and the second reliability is less than a threshold value when the first monitoring target and the second monitoring target communicate with each other; The monitoring system of claim 11.

14. The restriction of at least some of the functions of the first monitoring target according to the first reliability level includes stopping the operation of the first monitoring target. The monitoring system according to any one of claims 4 and 7 to 9.

15. (delete)

16. a display unit that displays the first monitoring target and the first reliability together; The monitoring system according to any one of claims 1 to 4 and 7 to 9.

17. the reliability management unit and the function restriction unit are mounted on the vehicle; The monitoring system of claim 4.

18. the monitoring system includes a server communicatively connected to the vehicle; At least one of the reliability management unit and the function restriction unit is realized by the server. The monitoring system of claim 4.

19. A monitoring method for monitoring an integrated ECU (Electronic Control Unit) that integrates functions of a plurality of ECUs (Electronic Control Units) and operates in a vehicle or within the vehicle, comprising: The integrated ECU is configured to be able to operate a plurality of virtual machines, each of the plurality of virtual machines includes a function of at least one ECU among the functions of the plurality of ECUs; The monitoring method includes: In order to monitor functions of the plurality of ECUs, one of the plurality of virtual machines is set as a monitoring target; a reliability management step of managing reliability indicating a security protection state of the monitoring target, the reliability is a value having at least two or more stages indicating the degree of the security protection state of the monitoring target, The monitoring method includes: Verifying the integrity of the software to be monitored; performing at least one of: if the integrity verification is completed successfully, changing the level of the security protection state of the degree of trust to a higher level; or, if the integrity verification is not completed successfully, changing the level of the security protection state of the degree of trust to a lower level; changing the level of the security protection state of the trust level to a lower level after a certain period of time has elapsed since the time when the integrity verification was performed; Monitoring method.

20. A monitoring device for monitoring an integrated ECU (Electronic Control Unit) that integrates functions of a plurality of ECUs (Electronic Control Units) and operates in a vehicle or the vehicle, comprising: The integrated ECU is configured to be able to operate a plurality of virtual machines, each of the plurality of virtual machines includes a function of at least one ECU among the functions of the plurality of ECUs; The monitoring device In order to monitor functions of the plurality of ECUs, one of the plurality of virtual machines is set as a monitoring target; a reliability management unit that manages reliability indicating the security protection state of the monitoring target, the reliability is a value having at least two or more stages indicating the degree of the security protection state of the monitoring target, The monitoring device Verifying the integrity of the software to be monitored; performing at least one of: if the integrity verification is completed successfully, changing the level of the security protection state of the degree of trust to a higher level; or, if the integrity verification is not completed successfully, changing the level of the security protection state of the degree of trust to a lower level; changing the level of the security protection state of the trust level to a lower level after a certain period of time has elapsed since the time when the integrity verification was performed; monitoring equipment.

Images