[go: up one dir, main page]

WO2025069973A1 - 情報処理方法、情報処理装置、および、プログラム - Google Patents

情報処理方法、情報処理装置、および、プログラム Download PDF

Info

Publication number
WO2025069973A1
WO2025069973A1 PCT/JP2024/031795 JP2024031795W WO2025069973A1 WO 2025069973 A1 WO2025069973 A1 WO 2025069973A1 JP 2024031795 W JP2024031795 W JP 2024031795W WO 2025069973 A1 WO2025069973 A1 WO 2025069973A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
policy
service
information processing
ecu
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/031795
Other languages
English (en)
French (fr)
Inventor
剛 岸川
智之 芳賀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of WO2025069973A1 publication Critical patent/WO2025069973A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • This disclosure relates to an information processing method, an information processing device, and a program.
  • Zero trust architecture Conventionally, there has been a concept called zero trust architecture to reduce security risks (see, for example, Non-Patent Document 1).
  • zero trust architecture it is considered that a decision is made as to whether or not to permit access to a resource from an access source based on information about the access source.
  • zero trust architecture can also be applied to in-vehicle network systems to enhance safety.
  • examples of resources in in-vehicle network systems include functions, known as services, provided by the electronic control units (ECUs) that make up the in-vehicle network system.
  • ECUs electronice control units
  • control network systems such as in-vehicle network systems
  • services that require real-time and/or reliable communication
  • the inability to use the services may affect the safety of the object (e.g., a moving object) in which the system is installed.
  • This disclosure provides an information processing method and the like for realizing a secure control network system while maintaining the safety of the object on which the control network system is installed.
  • An information processing method is an information processing method executed by an information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing a service including execution of a predetermined process and capable of accessing each other for the service, and a plurality of edge access permission devices each determining whether or not to allow the access based on a predetermined access policy, the information processing method obtaining a policy verification result including a determination result of whether or not to allow the access from each of the plurality of edge access permission devices, and outputting verification information regarding a master policy verification result including a final determination result of whether or not to allow the access based on the policy verification result from each of the plurality of edge access permission devices.
  • An information processing device is an information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing a service including execution of a predetermined process and capable of mutually accessing the service, and a plurality of edge access permission devices each determining whether or not the access is permitted based on a predetermined access policy, the information processing device including an acquisition unit that acquires a policy verification result including a determination result of whether or not the access is permitted from each of the plurality of edge access permission devices, and an output unit that outputs verification information regarding a master policy verification result including a final determination result of whether or not the access is permitted based on the policy verification result from each of the plurality of edge access permission devices.
  • the program according to one aspect of the present disclosure is a program for causing a computer to execute an information processing method according to one aspect of the present disclosure.
  • the information processing method can realize a secure control network system while maintaining the safety of the object on which the control network system is installed.
  • FIG. 1 is a diagram showing a configuration of an in-vehicle network system according to an embodiment.
  • FIG. 2 is a block diagram showing a configuration of the central ECU according to the embodiment.
  • FIG. 3 is a block diagram showing a functional configuration of the zone ECU according to the embodiment.
  • FIG. 4 is a block diagram showing a functional configuration of the camera ECU according to the embodiment.
  • FIG. 5 is a diagram illustrating an example of an access policy according to the embodiment.
  • FIG. 6 is a diagram illustrating an example of a vehicle state according to the embodiment.
  • FIG. 7 is a diagram illustrating an example of user information according to the embodiment.
  • FIG. 8 is a sequence diagram showing an access permission process according to the embodiment.
  • FIG. 9 is a sequence diagram showing an access permission process according to the embodiment.
  • FIG. 1 is a diagram showing a configuration of an in-vehicle network system according to an embodiment.
  • FIG. 2 is a block diagram showing a configuration of the central ECU according
  • FIG. 10 is a flowchart showing the processing procedure of the master policy determination unit and the policy enforcement unit of the central ECU according to the embodiment.
  • FIG. 11 is a flowchart showing the processing procedure of the policy determination unit and the policy enforcement unit of the zone ECU according to the embodiment.
  • FIG. 12 is a flowchart showing a processing procedure for changing an important characteristic of a service depending on a vehicle state in a master policy determination unit of a central ECU according to the embodiment.
  • FIG. 13 is a flowchart showing a processing procedure when an ECU having a policy verification result different from the other ECUs is present, which is received by the central ECU according to the embodiment.
  • FIG. 14 is a diagram showing a configuration of an in-vehicle network system according to the first modification of the embodiment.
  • FIG. 14 is a diagram showing a configuration of an in-vehicle network system according to the first modification of the embodiment.
  • FIG. 15 is a block diagram showing a functional configuration of a central ECU according to the first modification of the embodiment.
  • FIG. 16 is a block diagram showing a functional configuration of a zone ECU according to the first modification of the embodiment.
  • FIG. 17 is a diagram illustrating an example of a vehicle state according to the first modification of the embodiment.
  • FIG. 18 is a flowchart showing a processing procedure for determining a threshold value in a master policy determination unit of a central ECU according to the first modification of the embodiment.
  • FIG. 19 is a flowchart showing a processing procedure when an ECU having a policy verification result different from the other ECUs is received by the central ECU according to the second modification of the embodiment.
  • FIG. 20 is a diagram showing an example of visualization of a state in which there is a zone ECU whose policy verification result is different from the others according to the second modification of the embodiment.
  • FIG. 1 shows the overall configuration of an in-vehicle network system according to this embodiment.
  • the in-vehicle network system includes a central ECU 100, zone ECUs 200a, 200b, 200c, and 200d (hereinafter also referred to as zone ECU 200a, etc.), a camera ECU 300a, a charger ECU 300b, a brake ECU 300c, and a motor ECU 300d.
  • the in-vehicle network system is a system in which electronic control devices in the vehicle 10 communicate with each other.
  • the camera ECU 300a and the zone ECU 200a communicate via the in-vehicle network.
  • the zone ECU 200a also communicates with the central ECU 100 or the zone ECU 200b via the in-vehicle network.
  • the in-vehicle network system is an example of a control network system.
  • the in-vehicle network is configured based on in-vehicle network communication standards called Controller Area Network (CAN), LIN, FlexRay, and Ethernet (registered trademark).
  • CAN Controller Area Network
  • LIN LIN
  • FlexRay FlexRay
  • Ethernet registered trademark
  • the vehicle 10 is used by a user.
  • the vehicle 10 is, for example, an automobile, but may also be a motorcycle or other mobility system such as a ship or an airplane.
  • the vehicle 10 may also be an autonomous vehicle or a manually driven vehicle.
  • the vehicle 10 is an example of an object in which a control network system is installed.
  • the central ECU 100 is an electronic control device that performs the central function of vehicle control.
  • the central ECU 100 has a connectivity function, and wirelessly notifies the vehicle status and downloads firmware via a server outside the vehicle 10 and a mobile phone network or Wi-Fi (registered trademark).
  • the central ECU 100 is also equipped with an autonomous driving application, and achieves autonomous driving functions by acquiring and controlling information from each ECU.
  • the central ECU 100 is an example of an information processing device or access permission device.
  • Zone ECUs 200a to 200d are placed in various locations in the in-vehicle network, function as gateways for the sub-network, and communicate with the central ECU 100 or other zone ECUs.
  • Zone ECUs 200a to 200d are an example of an edge access permission device.
  • the camera ECU 300a acquires camera information and transmits it to the in-vehicle network.
  • the charger ECU 300b controls charging of the battery installed in the vehicle 10.
  • the charger ECU 300b and the zone ECU 200a communicate with each other via an in-vehicle network.
  • the brake ECU 300c controls the brakes of the vehicle 10.
  • the brake ECU 300c and the zone ECU 200c communicate with each other via an in-vehicle network.
  • the motor ECU 300d controls the motor of the vehicle.
  • the motor ECU 300d and the zone ECU 200d communicate with each other via an in-vehicle network.
  • each ECU When communicating with other ECUs, each ECU transmits and receives various data and control instructions, for example, using Scalable Service Oriented Middleware over IP (SOME/IP protocol).
  • SOME/IP protocol Scalable Service Oriented Middleware over IP
  • the in-vehicle network system includes a plurality of ECUs (e.g., camera ECU 300a, charger ECU 300b, brake ECU 300c, motor ECU 300d) each capable of executing services including the execution of predetermined processes and capable of accessing each other for services, and a plurality of zone ECUs 200a, etc., each of which determines whether or not access is permitted based on a predetermined access policy.
  • ECUs e.g., camera ECU 300a, charger ECU 300b, brake ECU 300c, motor ECU 300d
  • FIG. 2 is a block diagram showing the functional configuration of the central ECU 100 according to this embodiment.
  • the central ECU 100 includes a center communication unit 101, a vehicle control application unit 102, a driver application unit 103, an autonomous driving application unit 104, an in-vehicle network communication unit 105, a master policy determination unit 106, a policy implementation unit 107, an access policy storage unit 108, a vehicle state storage unit 109, and a user information storage unit 110.
  • the central ECU 100 may be an ECU (integrated ECU) that integrates functions that were previously installed separately in multiple ECUs in order to resolve issues of increased development time or cost associated with the complexity of in-vehicle network systems.
  • the integrated ECU is an ECU that uses virtualization technology to operate multiple virtual computers (virtual machines: VMs) in one ECU.
  • the vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104 may be realized by virtual machines.
  • the vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104 are logically separated by virtualization technology.
  • different IP addresses are assigned to the vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104.
  • the center communication unit 101 is a communication interface that communicates with a server external to the vehicle 10.
  • the center communication unit 101 functions as an acquisition unit that acquires policy verification results including the result of a determination as to whether access is permitted.
  • the center communication unit 101 may also function as an output unit that outputs verification information related to the master policy verification results to an external server.
  • the vehicle control application unit 102 is an application that processes or controls data acquired from each ECU in order to realize the basic functions of the vehicle 10, such as running, turning, and stopping.
  • the driver application unit 103 is an application for improving the user experience of the vehicle 10, and controls the air conditioning and infotainment system inside the vehicle, etc.
  • the autonomous driving application unit 104 is an application for executing autonomous driving, and acquires sensing information outside the vehicle from ECUs other than the central ECU 100, and controls the vehicle 10.
  • the in-vehicle network communication unit 105 is a communication interface for the in-vehicle network, and transmits and receives messages with the zone ECUs 200a to 200d.
  • the in-vehicle network communication unit 105 also has the function of a network switch that controls the transfer of communications.
  • the in-vehicle network communication unit 105 may also function as an output unit that outputs verification information related to the master policy verification results to each zone ECU 200a, etc.
  • the master policy determination unit 106 determines whether to permit access to the function. Specifically, based on the access policy stored in the access policy holding unit 108, it determines whether the destination and source of the message content acquired by the in-vehicle network communication unit 105 match. If the destination and source of the acquired message content match, the in-vehicle network communication unit 105 notifies the policy enforcement unit 107 of access permission. If the destination and source of the acquired message content do not match, the in-vehicle network communication unit 105 notifies the policy enforcement unit 107 of access denial. The master policy determination unit 106 may also determine whether the service ID and the destination IP address match.
  • the master policy determination unit 106 may also comprehensively determine access permission based not only on the access policies stored in the access policy holding unit 108, but also on the policy verification results, which are the results of verifying the access policies, notified by the policy determination units 202 arranged in the zone ECUs 200a to 200d. The master policy determination unit 106 then notifies the policy enforcement units 203 of the zone ECUs 200a to 200d of the permission/denial of access.
  • the policy enforcement unit 107 allows/denies access to vehicle functions based on the access permission/denial notification received from the master policy decision unit 106. Specifically, the policy enforcement unit 107 controls the forwarding/discarding of messages acquired by the in-vehicle network communication unit 105.
  • the access policy holding unit 108 is a storage that stores information about policies for controlling access to vehicle functions. Details will be described later with reference to FIG. 5.
  • the access policy holding unit 108 is realized, for example, by a semiconductor memory or a HDD (Hard Disk Drive), but is not limited to this.
  • the vehicle state storage unit 109 is a storage that stores information on the current vehicle state. Details will be described later with reference to FIG. 6.
  • the vehicle state storage unit 109 is realized, for example, by a semiconductor memory or a HDD, but is not limited to these.
  • the user information storage unit 110 is a storage that stores user information. Details will be described later with reference to FIG. 7.
  • the user information storage unit 110 is realized, for example, by a semiconductor memory or a HDD, but is not limited to this.
  • FIG. 3 is a block diagram showing the functional configuration of the zone ECU 200a according to this embodiment. Note that the zone ECUs 200b, 200c, and 200d also have the same configuration, so a description of these will be omitted.
  • the zone ECU 200a includes an in-vehicle network communication unit 201, a policy determination unit 202, a policy enforcement unit 203, an access policy storage unit 204, and a vehicle state storage unit 205.
  • the in-vehicle network communication unit 201 is a communication interface for the in-vehicle network, and communicates with at least one of the central ECU 100 and the camera ECU 300a in the zone.
  • the in-vehicle network communication unit 201 also has the function of a network switch that controls the transfer of communication as necessary.
  • the policy determination unit 202 determines whether the destination and source of the message content acquired by the in-vehicle network communication unit 201 match, based on the access policy stored in the access policy holding unit 204. If the destination and source of the message content match, the policy determination unit 202 notifies the policy enforcement unit 203 of access permission. If the destination and source of the message content do not match, the policy determination unit 202 notifies the policy enforcement unit 203 of access denial. The policy determination unit 202 may also determine whether the service ID and the destination IP address match.
  • the determination result of the policy determination unit 202 is an example of a policy verification result, and includes a determination result of whether access is permitted.
  • the policy determination unit 202 may notify the master policy determination unit 106 of the central ECU 100, and the master policy determination unit 106 may notify the policy enforcement unit 203 of the final decision result of whether access permission is granted or denied.
  • Policy enforcement unit 203 has the same functions as policy enforcement unit 107, and permits/denies access to vehicle functions based on the notification of access permission/denial notified from policy decision unit 202 or master policy decision unit 106. Specifically, policy enforcement unit 203 controls the forwarding/discarding of messages acquired by in-vehicle network communication unit 201. For example, policy enforcement unit 203 forwards messages for which access is permitted, and discards messages for which access is denied.
  • the access policy holding unit 204 is a storage that stores information related to policies for controlling access to vehicle functions. Essentially, the access policy holding unit 204 holds the same information as the access policy holding unit 108 of the central ECU 100, and details will be described later with reference to FIG. 5.
  • the access policy holding unit 204 is realized, for example, by a semiconductor memory or a HDD, but is not limited to these.
  • the vehicle state storage unit 205 is a storage that stores information on the current vehicle state. Basically, the vehicle state storage unit 205 stores the same information as the vehicle state storage unit 109 provided in the central ECU 100, and details will be described later using FIG. 6.
  • the vehicle state storage unit 205 is realized, for example, by a semiconductor memory or a HDD, but is not limited to these.
  • FIG. 4 is a block diagram showing the functional configuration of the camera ECU 300a according to this embodiment. Note that the charger ECU 300b, brake ECU 300c, and motor ECU 300d have substantially the same configuration, so their explanations are omitted.
  • the camera ECU 300a includes an application unit 301 and a communication unit 302.
  • the app section 301 is equipped with applications that realize the functions of the ECUs.
  • the camera ECU 300a has started a service that acquires camera information and provides it to the necessary ECUs.
  • the charger ECU 300b has started a service for providing the charging status of the battery or a service for controlling the charging of the battery.
  • the brake ECU 300c has started a service for notifying the status of the brakes or a service for controlling the brakes.
  • the motor ECU 300d has started a service for notifying the status of the motor or a service for controlling the motor.
  • the communication unit 302 is a communication interface for the in-vehicle network and communicates with the zone ECU 200a.
  • FIG. 5 is a diagram showing an example of an access policy according to this embodiment.
  • the access policy is information stored in the access policy holding units 108 and 204.
  • the access policies stored in the access policy holding units 108 and 204 are the same information (synchronized information).
  • the access policy is information that indicates the destination IP address and source IP address for each function (service ID), and also defines important characteristics for each function.
  • the access policy also holds version information of the access policy.
  • At least the service ID and destination IP address are information included in the message (a request for access to a vehicle function, a search message described below).
  • the access policy version is 1.0
  • the functions of the vehicle 10 are camera information (service ID: 0x10), brake control (service ID: 0x20), charger control (service ID: 0x30), and user information acquisition (service ID: 0x40)
  • the IP addresses permitted as service destinations for each function are 192.168.0.20, 192.168.0.10, 192.168.0.30
  • the IP addresses permitted as service sources are 192.168.0.10, 192.168.0.5, 192.168.0.30, 192.168.0.10
  • the important characteristics are availability, security, availability, and confidentiality, respectively.
  • Communication in the in-vehicle network may be realized, for example, by SOME/IP, and the service ID corresponds to the Message ID or Service ID in SOME/IP.
  • the in-vehicle protocol of the in-vehicle network is not limited to SOME/IP.
  • the important characteristics are classified into availability, security, and confidentiality. Note that the important characteristics need to include at least two of availability, security, and confidentiality.
  • Availability is assigned to services where continuity of service is an important factor. For example, services such as camera information and vehicle 10 status notifications, where the interruption of information can affect vehicle control, fall under this category.
  • a service (first service) that requires availability is the exchange of sensor data acquired by a sensor such as a camera, but is not limited to this.
  • the master policy decision unit 106 or policy decision unit 202 makes the decision to block communication for that service more carefully than safety and confidentiality. In other words, rather than a single policy decision unit 202 deciding whether to deny access, the master policy decision unit 106 decides to deny access based on the results of multiple policy decision units 202. Also, because real-time performance is required, the master policy decision unit 106 performs access control to allow communication until it decides to deny access.
  • Safety is assigned to services that may have a direct impact on vehicle control. For example, this applies to services that receive brake or motor control instructions and control the brake or motor.
  • a service that requires safety (third service) is, but is not limited to, a service related to actuator control that requires real-time performance.
  • Confidentiality is assigned to services that do not want the information contained in the service to be read by any application other than authorized applications.
  • a service that provides information related to a user's personal information falls into this category.
  • a service (second service) that requires confidentiality includes, but is not limited to, the exchange of data related to personal information or confidential information.
  • the master policy decision unit 106 or the policy decision unit 202 decides whether to allow access for the communication of the service in question based on the results of multiple policy decision units 202. Furthermore, each zone ECU performs access control to suspend communication until the master policy decision unit 106 decides whether to allow access.
  • the access policy may include information regarding either or both of the ECUs among the multiple ECUs that are permitted to access the service and the ECUs among the multiple ECUs that are permitted to provide the service.
  • the information indicating the destination and source does not have to be an IP address.
  • the information indicating the destination and source may be, for example, a MAC address, or an identifier that identifies an ECU or an application.
  • the service ID may be anything that represents an identifier of the service.
  • the service ID may be included in the message.
  • the service ID may be a port number.
  • access permission/denial may be determined according to a default set standard (e.g., a determination by a single policy determination unit 202).
  • the access policy may also be encrypted and stored in the access policy storage units 108 and 204.
  • access control may be set in the access policy so that it cannot be referenced by anyone other than the master policy decision unit 106 and the policy decision unit 202.
  • the access policy may also be updated based on a regular procedure. For example, the access policy may be updated after verifying that the version of the access policy received from an external server has not been rolled back, that the digital signature of the access policy has been verified correctly, etc.
  • FIG. 6 is a diagram showing an example of a vehicle state according to this embodiment.
  • the vehicle state is information stored in the vehicle state storage units 109 and 205.
  • the vehicle state stores the current vehicle state based on information notified via the in-vehicle network.
  • the vehicle state storage units 109 and 205 store the vehicle state, including the driving state of the vehicle 10, whether the autonomous driving mode is ON/OFF, and the remaining battery power state.
  • Figure 6 shows an example in which the driving state is driving, autonomous driving is OFF, and the remaining battery power is 70%.
  • the master policy determination unit 106 and the policy determination unit 202 can change the important characteristics of each service in the access policy depending on the vehicle state. For example, when the vehicle 10 is stopped, the master policy determination unit 106 and the policy determination unit 202 use the vehicle state to respond to cases where the characteristics that a service considers important change depending on the current vehicle state, such as changing the important characteristic of the charging control service to safety.
  • vehicle state is not limited to the example shown in FIG. 6, and may include, for example, a diagnostic mode state or an update state.
  • the diagnostic mode state indicates, for example, the mode (e.g., ON/OFF) of the self-diagnosis function of each ECU.
  • the update state indicates the update state (e.g., version) of each application and access policy installed in the vehicle 10.
  • FIG. 7 is a diagram showing an example of user information according to this embodiment.
  • the user information is information stored in the user information storage unit 110.
  • the user information storage unit 110 specifically stores the vehicle user's name, address, telephone number, and credit card information as user information.
  • the vehicle user's name may be, for example, the name of the user currently using the vehicle 10.
  • FIG. 7 indicates that the user's name is Yamada Taro, the address is XXXX in Osaka Prefecture, the telephone number is 090XXXXXXXX, and the credit card information is YYYYY.
  • the user information stored in the user information storage unit 110 is not limited to the information shown in FIG. 7.
  • the user information storage unit 110 may store address book information, favorite location information, and the like obtained from an information terminal such as a user's smartphone.
  • the user information may be encrypted and stored in the user information storage unit 110.
  • FIG. 8 is a sequence diagram (information processing method, access permission method) showing the procedure for access permission processing according to this embodiment. Specifically, FIG. 8 is a sequence diagram when the autonomous driving application of the central ECU 100 accesses the camera information service of the camera ECU 300a.
  • the central ECU 100 transmits a camera information service search message to request the use of the camera information service, for example, when the autonomous driving function is turned on (S100).
  • a SOME/IP-SD (Service Discovery) message (Find message) is broadcast from the central ECU 100 to the zone ECUs 200a, 200b, 200c, and 200d as a camera information service search message.
  • each of zone ECUs 200a, 200b, 200c, and 200d receives a search message for the camera information service, it checks whether the message matches the access policy (S101). In other words, when each of zone ECUs 200a, 200b, 200c, and 200d receives a search message for the camera information service, it determines the access policy of the search message.
  • the search message for the camera information service contains the ID of the camera information as the service ID (0x10 in the example of FIG. 5) and the destination IP address (the IP address of the central ECU 100 or the application unit that sent the search message).
  • the policy determination unit 202 of each zone ECU checks whether there is a match between the ID of the camera information and the destination IP address included in the search message and the access policy shown in FIG. 5. For example, the policy determination unit 202 of each zone ECU determines whether the pair of the ID of the camera information and the destination IP address included in the search message is in the access policy shown in FIG. 5.
  • the zone ECUs 200a, 200b, 200c, and 200d first transfer a search message for the camera information service to their respective zones (S102). For example, if each zone ECU 200a, etc. does not know whether a camera ECU capable of providing the camera information service is connected to its own zone and the important characteristic is availability, it transfers the search message once regardless of the result of step S101. Note that if each zone ECU 200a, etc. knows (stores) information regarding the services that the ECU in its own zone can provide, the processing of step S102 may be omitted.
  • zone ECUs 200a, 200b, 200c, and 200d respond (transmit) to the central ECU 100 that the verification result of the access policy (policy verification result) is OK (S103).
  • policy verification result the verification result of the access policy
  • step S103 the result of the processing in step S101 (verification result) is transmitted to the central ECU 100, which is the ECU to which the access policy is to be provided.
  • Step S103 is executed independently of the processing in step S102.
  • the central ECU 100 permits access to the camera information service and also notifies the zone ECUs 200a, 200b, 200c, and 200d of the permission (S104).
  • step S104 the master policy determination unit 106 of the central ECU 100 outputs a master policy verification result (here, access permission), which is the final determination result of whether access is permitted for the camera information service search message sent in step S100, based on the policy verification results sent from the zone ECUs 200a, 200c, and 200d.
  • a master policy verification result here, access permission
  • the zone ECU 200a transfers the response (SOME/IP-SD message (Offer message)) received from the camera ECU 300a of its own zone to the central ECU 100 (S105). In other words, the zone ECU 200a transfers the response from the camera ECU 300a to the central ECU 100. This response indicates that the camera information is available in response to the transfer of the search message in step S102. This allows the central ECU 100 to obtain which zone ECU the camera ECU 300a is connected to.
  • SOME/IP-SD message Offer message
  • the central ECU 100 Based on the Offer message received from the camera ECU 300a, the central ECU 100 sends a message (a usage request) to the zone ECU 200a requesting the use of the camera information service (S106). After that, a session between the central ECU 100 and the camera ECU 300a is established, and the central ECU 100 can use the camera information service.
  • the usage request is an example of verification information related to the master policy verification result.
  • the timing of the response of the access policy verification result in step S103 is not particularly limited. Also, depending on the timing of the response of the access policy verification result in step S103, the decision on permission to access the camera information service in step S104 may be made later than in step S105, but since availability is an important characteristic of the camera information service, the response from the camera ECU 300a is transferred to the central ECU 100 in any case.
  • FIG. 9 is a sequence diagram (information processing method, access permission method) when a charger ECU 300b exhibiting unauthorized behavior in this embodiment accesses a camera information service for a camera ECU 300a.
  • the zone ECU 200b receives a search message for the camera information service sent from the charger ECU 300b, and after checking the access policy of the message, transfers the message to the other zone ECUs 200a, 200c, 200d and the central ECU 100 (S200).
  • the central ECU 100 and the zone ECUs 200a, 200c, and 200d to which the camera information service search message has been transferred check the access policy of the search message (received message) (S201).
  • the method of checking the access policy is the same as step S101 shown in FIG. 8.
  • Zone ECUs 200a, 200c, and 200d transfer a search message for the camera information service to their own zone (S202).
  • the camera ECU 300a sends an Offer message for the camera information service to the zone ECU 200a, and the zone ECU 200a transfers the message to the zone ECU 200b (S203). The message is then transferred to the charger ECU 300b. In other words, the zone ECU 200b transfers the response from the camera ECU 300a to the charger ECU 300b.
  • the charger ECU 300b sends a message requesting the use of the camera information service to the camera ECU 300a via the zone ECUs 200b and 200a (S204).
  • the zone ECUs 200c and 200d transmit a verification result (NG) to the central ECU 100 indicating that the use of the camera information service by the charger ECU 300b violates the access policy (S205).
  • NG verification result
  • zone ECU 200a also transmits to the central ECU 100 that the verification result is a violation of the access policy (NG) (S206).
  • NG access policy
  • the central ECU 100 comprehensively judges the verification results of the access policies received from the zone ECUs 200a, 200c, and 200d, and notifies (sends) a message (a request to shut off the camera information service) to the relevant zone ECUs, zone ECU 200a and zone ECU 200b, prohibiting the charger ECU 300b that has violated the access policy from accessing the camera information service (S207).
  • the central ECU 100 requests zone ECU 200a and zone ECU 200b to shut off the camera information service.
  • step S207 if the number of policy verification results including access NG (access denial) among the policy verification results is equal to or greater than a threshold value, the master policy determination unit 106 of the central ECU 100 transmits a master policy verification result indicating access denial (here, a cut-off request) to the zone ECU 200a connected to the camera ECU 300a and the zone ECU 200b connected to the charger ECU 300b among the multiple zone ECUs 200a, etc.
  • a master policy verification result indicating access denial here, a cut-off request
  • step S207 the master policy determination unit 106 of the central ECU 100 outputs a master policy verification result (here, a blocking request since access was denied) which is the final judgment result on whether or not access is permitted for the camera information service search message received in step S200 based on the verification result of the access policy sent from the zone ECUs 200a, 200c, and 200d.
  • the blocking request is an example of verification information related to the master policy verification result.
  • the charger ECU 300b is an example of one electronic control device
  • the camera ECU 300a is an example of another electronic control device
  • the transmission of the search message is an example of access from the charger ECU 300b to the service of the camera ECU 300a.
  • the shutdown request in step S207 may be notified (transmitted) to each of multiple zone ECUs 200a, etc., including zone ECUs 200c and 200d.
  • FIG. 10 is a flowchart (information processing method, access permission method) showing details of the processing of the master policy determination unit 106 and the policy enforcement unit 107 executed by the central ECU 100 according to this embodiment.
  • the central ECU 100 receives a SOME/IP-SD message (service Find message or service Offer message) from the in-vehicle network (S300).
  • the service Find message is a message that allows the destination (client side) to find the service provider (server side).
  • the service Find message is a message that includes which ECU is searching for which service.
  • the service Offer message is a message that notifies the server side (such as the camera ECU 300a) of the information it possesses (that it can provide).
  • the service Offer message is a message that includes which ECU can provide which service.
  • the central ECU 100 checks the provided or requested service ID contained in the received SOME/IP-SD message, and by referring to the access policy holding unit 108, determines whether the important characteristics of the service related to the received message are safe or not (S301).
  • the master policy determination unit 106 of the central ECU 100 determines whether the important characteristics of the service ID contained in the service Find message or service Offer message are safe or not based on the access policy shown in Figure 5. As shown in Figure 5, the access policy has a one-to-one correspondence between the service ID and the important characteristics.
  • the central ECU 100 may check all service IDs and determine whether or not there is a service that requires security.
  • the central ECU 100 may split the message into service IDs and transfer the SOME/IP-SD message. For example, for a SOME/IP-SD message that includes service IDs whose important characteristics are different, safety and availability, the central ECU 100 may create a SOME/IP-SD message that includes only the service ID whose important characteristic is availability, and transfer the created message first. Furthermore, the central ECU 100 may perform service policy checks on the SOME/IP message, rather than on the SOME/IP-SD message.
  • the central ECU 100 checks the access policy and determines whether the source and destination of the service match the access policy (S302).
  • step S303 only messages that pass through the central ECU 100 are allowed.
  • each zone ECU 200a etc. individually determines whether the access policy is OK or not.
  • the message in step S303 is a normal SOME/IP message, and may be, for example, a message sending camera information (image information). This message is a message received after a Service Find message, and is not a service discovery.
  • the central ECU 100 can also be said to allow each of the multiple zone ECUs 200a, etc. to individually determine whether or not to allow access to that service in that zone ECU based on the policy verification result of that zone ECU before the master policy verification result is output.
  • the central ECU 100 prohibits the transfer of the message (S304) and ends the process.
  • the central ECU 100 determines whether the important characteristic of the service related to the received message is confidentiality (S305).
  • the central ECU 100 receives the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d related to that message (S306).
  • the central ECU 100 judges whether the number of policy verification results OK received from the zone ECUs 200a, 200b, 200c, and 200d is less than a threshold (3 in this case) (S307).
  • a threshold 3 in this case
  • the central ECU 100 receives the judgment results of the other zone ECUs and makes a comprehensive judgment on whether or not to allow access since the data is important.
  • the threshold used in step S307 is larger than the threshold used in step S311, but is not limited to this.
  • the central ECU 100 prohibits the transfer of the message (S304).
  • the central ECU 100 permits the transfer of the message (S308) and ends the process.
  • the central ECU 100 allows the transfer of the message because the important characteristic of the service related to the message is availability (S309).
  • the central ECU 100 receives the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d relating to the message (S310).
  • the central ECU 100 determines whether the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is less than two (S311). For example, in steps S205 and S206 shown in FIG. 9, all are NG, so it is determined that the number of received results is 0, that is, less than two.
  • Step S312 corresponds to step S207 shown in FIG. 9.
  • central ECU 100 ends the process. In this case, the state permitted in step S309 continues. In this way, if the service requires availability as an important characteristic, the process is executed so that it is permitted once (S309), and if there is any problem (Yes in S311), it is later prohibited (S312).
  • the threshold value for the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d, which causes the processing contents of the central ECU 100 to branch, is not limited to the value shown in this embodiment.
  • the threshold value may be changed depending on the in-vehicle network configuration, the number of zone ECUs, and the contents of the message.
  • the number of received policy verification results that are OK may include not only the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d, but also the policy verification results of the master policy determination unit 106 of the central ECU 100.
  • this flowchart shows an example of determining the access policy for SOME/IP-SD, but the target of the access restriction is not limited to SOME/IP-SD messages.
  • it may be SOME/IP messages, Data Distribution Service (DDS) messages, etc.
  • DDS Data Distribution Service
  • step S304 the central ECU 100 prohibits the transfer of the message, i.e., prohibits the transfer of the SOME/IP-SD message, but it may also forward the SOME/IP-SD message and prohibit the transfer of subsequent messages related to the service, or it may notify other zone ECUs to prohibit communications outside the access policy.
  • FIG. 11 is a flowchart (information processing method, access permission method) showing the details of the access permission determination process executed by the zone ECU 200a according to this embodiment. Note that the zone ECUs 200b, 200c, and 200d also execute similar processes.
  • the zone ECU 200a receives a SOME/IP-SD message (service Find message or service Offer message) from the in-vehicle network (S400).
  • SOME/IP-SD message service Find message or service Offer message
  • the zone ECU 200a checks the provided or requested service ID contained in the received SOME/IP-SD message, and by referring to the access policy holding unit 204, determines whether the important characteristics of the service related to the received message are safe (S401).
  • the policy determination unit 202 of the zone ECU 200a determines whether the important characteristics of the service ID contained in the service Find message or service Offer message are safe based on the access policy shown in FIG. 5.
  • the zone ECU 200a may check all service IDs and determine whether or not there is a service that requires security.
  • zone ECU 200a may divide the message into service IDs and forward the SOME/IP-SD message. For example, for a SOME/IP-SD message that contains service IDs whose important characteristics are different, safety and availability, zone ECU 200a may create a SOME/IP-SD message that contains only service IDs whose important characteristic is availability, and forward the created message first. Furthermore, zone ECU 200a may perform service policy checks on the SOME/IP message, rather than on the SOME/IP-SD message.
  • the zone ECU 200a checks the access policy and determines whether the source and destination of the service match the access policy (S402).
  • the zone ECU 200a allows the message to be forwarded (S403) and ends the process. In step S403, only messages that pass through the zone ECU 200a are allowed.
  • the zone ECU 200a prohibits the transfer of the message (S404) and ends the process.
  • zone ECU 200a determines whether the important characteristic of the service related to the received message is not security (No in S401), it determines whether the important characteristic of the service related to the received message is confidentiality (S405).
  • the zone ECU 200a transmits the policy verification result for that message to the central ECU 100 (S406).
  • the zone ECU 200a further receives the final access permission/denial decision result (master policy verification result) from the central ECU 100, and determines whether the decision result is access denial (NG) (S407).
  • master policy verification result master policy verification result
  • NG access denial
  • zone ECU 200a receives an access denial (NG) as the final judgment result from the central ECU 100 (Yes in S407), it prohibits the transfer of the message (S404).
  • NG access denial
  • the zone ECU 200a receives an access permission (OK) as the final judgment result (No in S407), it allows the transfer of the message (S408) and ends the process.
  • the zone ECU 200a allows the transfer of the message since the important characteristic of the service related to the message is availability (S409).
  • the zone ECU 200a transmits the policy verification result of the zone ECU 200a regarding the message to the central ECU 100 (S410).
  • the zone ECU 200a receives the final access permission/denial decision result (master policy verification result) from the central ECU 100, and determines whether the decision result is access denial (NG) (S411).
  • zone ECU 200a determines that it has received an access denial as the final judgment result (Yes in S411), it prohibits communication that violates the access policy for that service (S412) and ends the process.
  • the zone ECU 200a determines that access is permitted as a final result (No in S411), it ends the process without doing anything. In this case, the state permitted in step S409 continues. In this way, if the service requires availability as an important characteristic, the process is executed so that the service is permitted once (S409), and if there is any problem (Yes in S411), it is later prohibited (S412).
  • zone ECU 200a prohibits the transfer of the message, i.e., prohibits the transfer of the SOME/IP-SD message, but it is also possible to transfer the SOME/IP-SD message and prohibit the transfer of subsequent messages related to the service.
  • FIG. 12 is a flowchart (information processing method, access permission method) showing the process in which the master policy decision unit 106 of the central ECU 100 according to this embodiment changes the important characteristics of each service stored in the access policy holding unit 108 in accordance with the vehicle state held in the vehicle state holding unit 109.
  • the policy decision units 202 of the zone ECUs 200a, 200b, 200c, and 200d also perform similar processes.
  • the central ECU 100 receives a message from the in-vehicle network and detects a change in the vehicle state from the communication content (S500). In step S500, the central ECU 100 determines whether the vehicle state has changed.
  • the central ECU 100 determines whether the vehicle's driving state has changed (or changed) while the vehicle is stopped (S501).
  • the central ECU 100 changes the important characteristic of the communication for the service related to charger control to safety (e.g., from availability to safety) (S502), and proceeds to step S507.
  • the central ECU 100 determines whether the vehicle's running state has changed (changed) while the vehicle is running (S503).
  • the central ECU 100 changes the important characteristic of the communication for the service related to brake control to safety (S504) and proceeds to step S507.
  • the central ECU 100 determines whether the autonomous driving mode of the vehicle state has changed to ON (S505). In other words, in step S505, it is determined whether the vehicle state has changed during autonomous driving.
  • the central ECU 100 changes the important characteristic of the communication for the service related to brake control to availability (e.g., from safety to availability) (S506), and proceeds to step S507.
  • the central ECU 100 transmits information including the changed important characteristics to each zone ECU 200a, etc. (S507).
  • the central ECU 100 may also transmit an access policy including the changed important characteristics to each zone ECU 200a, etc. Then, the central ECU 100 ends the processing.
  • the central ECU 100 ends the process.
  • the contents of the access policy holding unit 108 may be changed as shown in this flowchart, or the important characteristics may be changed by referring to the vehicle state in the vehicle state holding unit 109 at the timing of referring to the access policy holding unit 108 in Figure 10.
  • the central ECU 100 may increase or decrease the threshold value for denying access depending on the vehicle state of the vehicle 10 and the service.
  • the central ECU 100 may set the threshold value so that the threshold value increases in the following order when the vehicle state of the vehicle 10 is stopped, moving, and autonomously driving.
  • FIG. 13 is a flowchart (information processing method, access permission method) showing the processing performed when the master policy determination unit 106 of the central ECU 100 according to this embodiment collects the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d and there is a zone ECU that transmits a verification result different from the other zone ECUs.
  • the central ECU 100 determines whether there is a zone ECU that returns a different policy verification result (S600). In other words, the central ECU 100 determines whether it has received different policy verification results from each zone ECU.
  • the central ECU 100 requests the version of the access policy from the zone ECU that responded with the different policy verification result (S601).
  • the central ECU 100 requests the zone ECU to transmit the version of the access policy.
  • the version of the access policy is an example of information related to the access policy.
  • the information related to the access policy may be, for example, the date and time when the access policy was updated.
  • the central ECU 100 may request the access policy version from all zone ECUs, rather than requesting the access policy version from zone ECUs that have responded with different policy verification results.
  • the central ECU 100 determines whether the version information of the received access policy is different from the version information of the access policy held by the central ECU 100 itself (S602). In step S602, for example, it may be determined whether the access policies held in each zone ECU 200a, etc. are synchronized.
  • the central ECU 100 may compare the version of the access policy with the version information of the access policy held by itself, or may hold a list of version information of access policies that are expected to be used, and check whether the version information of the access policy of the zone ECU matches the version information of the access policy of the zone ECU listed in the list.
  • the central ECU 100 determines that the zone ECU is using an access policy different from that expected, updates the access policy of the zone ECU (S603), and ends the process. For example, the central ECU 100 may transmit the access policy held by itself to each zone ECU 200a, etc. (or to zone ECUs with different access policies).
  • the central ECU 100 determines that the corresponding zone ECU is behaving improperly, ignores (or reduces the weight of) the verification result (policy verification result) by the corresponding zone ECU from the next time onwards (S604), and terminates the process.
  • Ignoring may mean that even if a policy verification result is received from the corresponding zone ECU, no processing is performed on it. Ignoring may mean, for example, that even if the policy verification result is received, the policy verification result is not used to determine the master policy verification result.
  • the central ECU 100 may notify an external server of the presence of the zone ECU exhibiting improper behavior, or may record the abnormality as a log.
  • FIG. 14 is a diagram showing the overall configuration of an in-vehicle network system according to this modified example, in which the same components as those shown in Fig. 1 are denoted by the same reference numerals.
  • the in-vehicle network system installed in the vehicle 20 includes a central ECU 1000, zone ECUs 2000a, 2000b, 2000c, and 2000d, a camera ECU 300a, a charger ECU 300b, a brake ECU 300c, and a motor ECU 300d.
  • the central ECU 1000 and the zone ECUs 2000a, 2000b, 2000c, and 2000d are described below.
  • FIG. 15 is a block diagram showing the functional configuration of the central ECU 1000 according to this modified example.
  • the information stored in the vehicle state storage unit 1109 is different from that of the central ECU 100 in FIG. 2 according to the embodiment, and the master policy determination unit 1106 has additional functions compared to the master policy determination unit 106.
  • the information stored in the vehicle state storage unit 1109 will be described in detail later with reference to FIG. 17.
  • FIG. 16 is a block diagram showing the functional configuration of a zone ECU 2000a according to this modified example.
  • An integrity verification unit 206 and an in-vehicle network intrusion detection unit 207 have been added as components to the zone ECU 200a in FIG. 3 according to the embodiment.
  • the integrity verification unit 206 verifies that the functional configuration of the zone ECU 2000a has not been tampered with. Specifically, the integrity verification unit 206 verifies that the software or data of the zone ECU 2000a has not been tampered with by comparing a hash value calculated from the software or data constituting the zone ECU 2000a with a hash value stored in advance. The integrity verification unit 206 periodically or irregularly verifies the integrity of the software or data of the zone ECU 2000a (integrity verification) while the zone ECU 2000a is running. The integrity verification result is notified to the central ECU 1000 via the in-vehicle network communication unit 201.
  • the in-vehicle network intrusion detection unit 207 monitors the in-vehicle network communications received by the zone ECU 2000a and detects whether any abnormal communications are occurring. Specifically, the in-vehicle network intrusion detection unit 207 detects abnormal communications such as receiving a message to an unexpected source or destination, receiving messages at a higher than normal frequency, port scan communications, and diagnostic communications at improper times.
  • the in-vehicle network intrusion detection unit 207 detects abnormal communication, it notifies the central ECU 1000 of the occurrence of the abnormality.
  • zone ECUs 2000b, 2000c, and 2000d may also include an integrity verification unit 206 and an in-vehicle network intrusion detection unit 207, or may include only one of them. Furthermore, it is sufficient that at least one of zone ECUs 2000a, 2000b, 2000c, and 2000d includes at least one of the integrity verification unit 206 and the in-vehicle network intrusion detection unit 207.
  • FIG. 17 shows an example of a vehicle state stored in the vehicle state storage unit 1109 of the central ECU 1000 in this modified example.
  • FIG. 17 stores the integrity verification result and time and the in-vehicle network intrusion detection result (the result of the intrusion detection system) notified from zone ECUs 2000a, 2000b, 2000c, and 2000d.
  • the in-vehicle network intrusion detection result is the detection result of the in-vehicle network intrusion detection system.
  • the integrity verification result is stored for each zone ECU together with the time.
  • the integrity verification result for zone ECU 2000a is OK, indicating that the software or data has not been tampered with, and the last verification time is 13:05.
  • the integrity verification result for zone ECU 2000b is OK, indicating that the software or data has not been tampered with, and the last verification time is 13:05.
  • the integrity verification result for zone ECU 2000c is OK, indicating that the software or data has not been tampered with, and the last verification time is 13:10.
  • the integrity verification result for zone ECU 2000d is OK, indicating that the software or data has not been tampered with, and the last verification time is 12:30.
  • the results of the in-vehicle network intrusion detection system are also stored for each zone ECU.
  • the intrusion detection result of the in-vehicle network system of zone ECU 2000a is OK, indicating that no abnormalities have been detected.
  • the intrusion detection result of the in-vehicle network system of zone ECU 2000b is OK, indicating that no abnormalities have been detected.
  • the intrusion detection result of the in-vehicle network system of zone ECU 2000c is OK, indicating that no abnormalities have been detected.
  • the intrusion detection result of the in-vehicle network system of zone ECU 2000d is OK, indicating that no abnormalities have been detected.
  • FIG. 18 is a flowchart showing the process of determining the thresholds used in steps S307 and S311 in the flowchart of FIG. 10 in the master policy determination unit 1106 of the central ECU 1000 in this modified example.
  • the timing for determining the threshold is not particularly limited; for example, the threshold may be calculated each time it is referenced (i.e., this process may be executed immediately before step S307 or step S311), or a process for determining the threshold may be executed in advance.
  • the central ECU 1000 determines whether confidentiality is an important characteristic of the service for which the access policy is to be verified (S700).
  • the central ECU 1000 sets the numerical value of the threshold N for denying access to the service (second service) whose important characteristic is confidentiality to a value lower than a predetermined value.
  • the predetermined value here is, for example, but is not limited to, a numerical value obtained by subtracting a predetermined number from the number of zone ECUs.
  • the threshold N set in step S701 is the threshold used in step S307 in FIG. 10.
  • the central ECU 1000 sets the numerical value of the threshold N for denying access to a service (first service) whose important characteristic is not confidentiality (e.g., availability) higher than a predetermined value.
  • the predetermined value here is, for example, but is not limited to, a numerical value obtained by subtracting a predetermined number from the number of zone ECUs.
  • the threshold N set in step S702 is the threshold used in step S311 of FIG. 10.
  • threshold value N set in steps S701 and S702 is not limited to the value shown in FIG. 18.
  • the threshold value N set in step S701 may be set to a value relatively higher than the threshold value N set in step S702.
  • the central ECU 1000 checks the vehicle state, checks the integrity verification results of the zone ECUs 2000a, 2000b, 2000c, and 2000d, and determines whether there is a zone ECU whose integrity verification has been successful within the last five minutes (S703). Note that five minutes is an example and is not limiting.
  • the central ECU 1000 sets (changes) the weight of the policy verification result (access OK/NG) received from the corresponding zone ECU to 2 (e.g., from 1 to 2) (S704).
  • the policy judgment result of a zone ECU whose judgment in step S703 is Yes is more reliable than the policy judgment result of a zone ECU whose judgment in step S703 is No, so the weight is increased.
  • weight is not limited to being increased from 1 to 2, but can be any value greater than 1.
  • the central ECU 1000 does nothing in particular. Note that if the answer is No in step S703, the central ECU 1000 may lower the weight of the zone ECU.
  • the central ECU 1000 may increase or decrease the weight of the policy verification result received from a zone ECU based on the result of the integrity verification received from that zone ECU.
  • the central ECU 1000 then checks the vehicle state and determines whether any zone ECU has detected an abnormality in the in-vehicle network intrusion detection system (S705).
  • the central ECU 1000 sets the weight of the policy verification result by the corresponding zone ECU to 0 (zero), subtracts 1 from the current threshold value N (S706), and ends the process.
  • the weight of the policy verification result by the corresponding zone ECU is 0 (zero)
  • subtracts 1 from the current threshold value N is possible to set a threshold value appropriate for the case where there is a zone ECU with a weight of 0.
  • the central ECU 1000 is not limited to setting the weight of the policy verification result to 0, but may simply lower the weight from its current value.
  • step S706 at least the weight of the policy verification result needs to be lowered.
  • the central ECU 1000 ends the process. Note that if the answer is No in step S705, the central ECU 1000 may increase the weight of the zone ECU.
  • the central ECU 1000 when the central ECU 1000 receives a notification from a zone ECU that abnormal communication has been detected, it may reduce the weight of the policy verification result received from that zone ECU.
  • the weight of the policy verification result of that zone ECU may be set to zero.
  • the weight of the policy verification result of a zone ECU in which an abnormality has been detected by the in-vehicle network intrusion detection system is set to zero
  • the weight of the policy verification result of that zone ECU does not have to be set to zero in this case.
  • the threshold N may be increased for messages sent from an ECU present in the zone in which the abnormality has been detected. This allows for more careful judgment of communications sent from an ECU present in a network in which an abnormality has occurred, thereby improving the security of the in-vehicle network.
  • Figure 19 is a flowchart (information processing method, access permission method) showing the processing that is performed when a zone ECU that transmits a verification result different from the other zone ECUs is present when the master policy determination unit 106 of the central ECU 100 in this modified example collects the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d.
  • FIG. 19 shows a flowchart in which step S800 has been added to the flowchart shown in FIG. 13, and step S604 has been replaced with step S801.
  • Step S800 corresponds to, for example, step S306 or S310 shown in FIG. 10.
  • the central ECU 100 transmits to an external server a notice that an inconsistency has occurred in the policy verification results (S801).
  • Information indicating that an inconsistency has occurred in the policy verification results is an example of verification information related to the master policy verification results.
  • transmitting to an external server a notice that an inconsistency has occurred in the policy verification results is an example of outputting verification information.
  • the central ECU 100 may transmit at least one of the policy verification result and the version information of the access policy to an external server as verification information related to the master policy verification result.
  • the version information of the access policy is an example of information that identifies a specific access policy.
  • the verification information can be displayed on a display device connected to an external server.
  • the verification information can be displayed to a supervisor monitoring the in-vehicle network system.
  • FIG. 20 shows an example of an analysis screen when the central ECU 100 notifies an external server of the situation when there is a zone ECU with a different policy verification result, and the external server determines the situation.
  • FIG. 20 shows an example of the displayed verification information.
  • FIG. 20 shows the IP address information of the ECU that made the service request when an inconsistency occurred in the policy verification results, and the result of which service was attempted to be accessed (brake control function in the example of FIG. 20). Furthermore, a screen may be displayed that lists the verification results (policy verification results), software version (SW version), and access policy version (policy version) for the central ECU 100 and each of the zone ECUs 200a, 200b, 200c, and 200d. In FIG. 20, although all the ECUs use the same policy version, only zone ECU 200b has returned a verification result of NG, indicating that an inconsistency has occurred in the policy verification results.
  • FIG. 1 An information processing method executed by an information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing a service including execution of a predetermined process and capable of mutually accessing the services, and a plurality of edge access permission devices each determining whether or not to allow the access based on a predetermined access policy, the information processing method obtaining a policy verification result including a determination result of whether or not to allow the access from each of the plurality of edge access permission devices, and outputting verification information regarding a master policy verification result including a final determination result of whether or not to allow the access based on the policy verification result from each of the plurality of edge access permission devices.
  • the access permission device is the central ECU 100
  • the edge access permission devices are the zone ECUs 200a, 200b, 200c, and 200d.
  • an access permission device verifies distributed access policies at multiple verification points to make a final decision on whether or not access is permitted. This allows a highly reliable decision on whether or not access is permitted, and keeps the control network system safe.
  • an object e.g., a vehicle
  • a secure control network system can be realized while maintaining the safety of the object.
  • the administrator of the control network system can be informed of the master policy verification results.
  • the access includes access from one of the plurality of electronic control devices to a service of another of the plurality of electronic control devices
  • the information processing method is an information processing method according to any one of Technologies 1 to 4, in which, if the number of policy verification results from each of the plurality of edge access access devices that include an access denial is equal to or exceeds a threshold, the master policy verification result indicating the access denial is transmitted to an edge access access permission device connected to the one of the plurality of edge access access devices and to an edge access permission device connected to the other of the plurality of electronic control devices.
  • the access denial threshold is a threshold for the number of times that a policy verification result indicating a denial of access has been received.
  • the service can be accessed by the electronic control unit, for example, via SOME/IP communication.
  • the electronic control unit sends a message requesting an unauthorized service
  • the access policy is verified in multiple zone ECUs 200a, etc., and if the verification result is equal to or exceeds a threshold value, resulting in access denial, the message is discarded and access to the service is denied.
  • the master policy verification results are sent to each of the multiple edge access permission devices, so if there is a zone ECU that is not operating properly, that information can be provided.
  • an access policy that includes at least one of electronic control devices that are permitted to access the service and electronic control devices that are permitted to provide the service.
  • the service includes a first service that requires availability, and the information processing method is the information processing method described in Technology 5 or 6, in which the threshold value for denying access to the first service is increased to a predetermined value.
  • the first service is the information processing method described in Technology 8, which includes transmitting and receiving sensor data.
  • the first service includes the transmission and reception of sensor data, it is possible to ensure the availability of the network system while maintaining security.
  • the service includes a second service that requires confidentiality, and the information processing method is an information processing method described in any one of Techniques 5 to 9, in which the threshold value for denying access to the second service is set lower than a predetermined value.
  • the second service is the information processing method described in Technology 10, which includes the exchange of data related to personal information or confidential information.
  • the service includes a third service for which security is required, and the information processing method is an information processing method described in any one of Techniques 1 to 11, in which, before the master policy verification result is output for the third service, each of the multiple edge access permission devices is individually permitted to determine whether or not to allow access to the service based on the policy verification result of the edge access permission device.
  • access can be granted with minimal processing delays that occur by waiting for the results of distributed access policy verification, making it possible to maintain the security and real-time capabilities of the network system.
  • the third service is the information processing method described in Technology 12, which includes matters related to actuator control.
  • the control network system is an in-vehicle network system mounted in a vehicle, and the information processing method is the information processing method described in Technology 5, in which the threshold value for denying the access is increased or decreased depending on the vehicle state of the vehicle and the service.
  • At least one edge access permission device among the plurality of edge access permission devices is configured to be capable of performing integrity verification to verify that its own software or data has not been tampered with, and the information processing method is an information processing method described in any one of Techniques 1 to 15, in which a weight of the policy verification result received from the at least one edge access permission device is increased or decreased based on the result of the integrity verification received from the at least one edge access permission device.
  • At least one edge access permission device among the plurality of edge access permission devices is configured to be capable of detecting anomalous communication
  • the information processing method is an information processing method described in any one of Techniques 1 to 16, in which, upon receiving a notification from the at least one edge access permission device that the anomalous communication has been detected, the information processing method reduces the weight of the policy verification result received from the at least one edge access permission device.
  • the weight of the policy verification result received from the edge access permission device can be reduced to efficiently determine whether or not to allow access.
  • An information processing device in a control network system including a plurality of electronic control devices each capable of executing a service including execution of a predetermined process and capable of mutually accessing the service, and a plurality of edge access permission devices each determining whether or not the access is permitted based on a predetermined access policy, the information processing device including an acquisition unit that acquires a policy verification result including a determination result of whether or not the access is permitted from each of the plurality of edge access permission devices, and an output unit that outputs verification information regarding a master policy verification result including a final determination result of whether or not the access is permitted based on the policy verification result from each of the plurality of edge access permission devices.
  • Such an information processing device achieves the same effects as the information processing method according to one aspect of the present disclosure.
  • Such a program provides the same effects as the information processing method according to one aspect of the present disclosure.
  • the general or specific aspects of the present disclosure may be realized as a system, device, method, integrated circuit, computer program, or non-transitory recording medium such as a computer-readable CD-ROM. It may also be realized as any combination of a system, device, method, integrated circuit, computer program, and recording medium.
  • control network system of the present disclosure is not limited to being an in-vehicle network system, but may include other mobility network systems and/or control network systems.
  • communication standard for communications performed in such a system is not particularly limited.
  • architecture of the in-vehicle communication network system is not limited to the example shown in FIG. 1.
  • the object in which the control network system is installed is not limited to being a moving object such as a vehicle, but may be a non-moving object such as a facility.
  • a facility is, for example, an object in which a home network system, which is an example of a control network system, is installed.
  • a facility may be, for example, a house, a hospital, a building, a nursing home, a school, etc.
  • the policy decision unit and policy enforcement unit may be provided outside the zone ECU.
  • the policy decision unit and policy enforcement unit may be provided in an ECU, network switch, or network gateway.
  • the master policy decision unit does not have to be provided in the central ECU.
  • the master policy decision unit may be provided on an ECU that has an execution environment with a different security level than normal applications.
  • the target message may be forwarded to that ECU to request policy verification.
  • each of the zone ECUs that receives a search message such as a camera information service verifies the access policy
  • the present disclosure may also be realized as an access permission device mounted on an object, the object having an ECU in which the access permission device is provided, and one or more zone ECUs (e.g., multiple zone ECUs 200a, etc.) that are managed by the ECU and control equipment mounted on the object, the access permission device including: an acquisition unit (e.g., a center communication unit) that acquires, when an access request (e.g., an access request to a service) is made from an arbitrary source (or provider) in the object to an arbitrary destination (or provider) in the object, in each of the one or more zone ECUs, a policy verification result that is a judgment result of whether or not access is permitted for the access request, based on a predetermined access policy; and a master policy judgment unit that judges whether or not access is permitted for the access request, based on the policy verification result acquired from each of the one or more zone ECUs.
  • an acquisition unit e.g., a center communication unit
  • an access request e.g.,
  • the present disclosure may also be realized as an access permission method executed by an access permission device mounted on an object, the object having an ECU in which the access permission device is provided and one or more zone ECUs (e.g., multiple zone ECUs 200a, etc.) that are managed by the ECU and control equipment mounted on the object, the access permission method including, when there is an access request (e.g., an access request to a service) from any source (or provider) in the object to any destination (or provider) in the vehicle, acquiring a policy verification result in each of the one or more zone ECUs that is a judgment result on whether or not access is permitted for the access request based on a predetermined access policy, and determining whether or not access is ultimately permitted for the access request based on the policy verification result acquired from each of the one or more zone ECUs.
  • an access request e.g., an access request to a service
  • acquiring a policy verification result in each of the one or more zone ECUs that is a judgment result on whether or not access is permitted
  • control network system is installed on a moving object such as a vehicle, but the present invention is not limited to this, and the control network system may be installed on a stationary object that does not move.
  • the communication method and communication standard between the devices in the above embodiment are not particularly limited. Either wireless communication or wired communication may be performed between the devices. Furthermore, wireless communication and wired communication may be combined between the devices.
  • the division of functional blocks in a block diagram is one example, and multiple functional blocks may be realized as one functional block, one functional block may be divided into multiple blocks, or some functions may be transferred to other functional blocks. Furthermore, the functions of multiple functional blocks having similar functions may be processed in parallel or in a time-shared manner by a single piece of hardware or software.
  • processing performed by a specific processing unit may be executed by another processing unit.
  • the order of multiple processes may be changed, and multiple processes may be executed in parallel.
  • each component may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU (Central Processing Unit) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.
  • a program execution unit such as a CPU (Central Processing Unit) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.
  • each component may be realized by hardware.
  • Each component may be a circuit (or an integrated circuit). These circuits may form a single circuit as a whole, or each may be a separate circuit. Furthermore, each of these circuits may be a general-purpose circuit, or a dedicated circuit.
  • the general or specific aspects of the present disclosure may be realized in a system, an apparatus, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM.
  • the present disclosure may be realized in any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.
  • this disclosure also includes forms that can be obtained by applying various modifications to each embodiment that a person skilled in the art would conceive, or forms that can be realized by arbitrarily combining the components and functions of each embodiment without departing from the spirit of this disclosure.
  • This disclosure can be used in control devices that control vehicles.
  • Vehicle 100 1000 Central ECU (information processing device, access permission device) 101 Center communication unit (acquisition unit, output unit) 102 Vehicle control application unit 103 Driver application unit 104 Autonomous driving application unit 105, 201 In-vehicle network communication unit (output unit) 106, 1106 Master policy determination unit 107, 203 Policy enforcement unit 108, 204 Access policy storage unit 109, 205, 1109 Vehicle state storage unit 110 User information storage unit 200a, 200b, 200c, 200d, 2000a, 2000b, 2000c, 2000d Zone ECU (edge access permission device) 202 Policy determination unit 206 Integrity verification unit 207 In-vehicle network intrusion detection unit 300a Camera ECU 300b charger ECU 300c Brake ECU 300d Motor ECU 301 Application section 302 Communication section

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)

Abstract

情報処理方法は、制御ネットワークシステムにおける情報処理装置が実行する情報処理方法であって、制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、アクセスの可否を判断する複数のエッジアクセス許可装置とを含む。情報処理方法は、複数のエッジアクセス許可装置のそれぞれからアクセスの可否の判断結果を含むポリシー検証結果を取得し（Ｓ８００）、複数のエッジアクセス許可装置それぞれからのポリシー検証結果に基づいて、アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する（Ｓ８０１）。

Description

情報処理方法、情報処理装置、および、プログラム
　本開示は、情報処理方法、情報処理装置、および、プログラムに関する。
　従来、セキュリティのリスクを低減するために、ゼロトラストアーキテクチャという考え方がある（例えば、非特許文献１参照）。従来のゼロトラストアーキテクチャでは、アクセス元の情報に基づいて、アクセス元のリソースへのアクセスを許可するか否かを判断することが考えられている。
Ｓｃｏｔｔ　Ｒｏｓｅ，Ｏｌｉｖｅｒ　Ｂｏｒｃｈｅｒｔ，Ｓｔｕ　Ｍｉｔｃｈｅｌｌ，Ｓｅａｎ　Ｃｏｎｎｅｌｌｙ，"Ｚｅｒｏ　Ｔｒｕｓｔ　Ａｒｃｈｉｔｅｃｔｕｒｅ"，ＮＩＳＴ　Ｓｐｅｃｉａｌ　Ｐｕｂｌｉｃａｔｉｏｎ　８００－２０７，Ａｕｇｕｓｔ　２０２０，（ｈｔｔｐｓ：／／ｄｏｉ．ｏｒｇ／１０．６０２８／ＮＩＳＴ．ＳＰ．８００－２０７）
　車載ネットワークシステムに対してもゼロトラストアーキテクチャを適用し、安全性を高めることが考えられる。車載ネットワークシステムにおけるリソースの一例として、ユーザの個人情報の他にも、サービスと呼ばれるような、車載ネットワークシステムを構成する電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）が提供する機能がある。
　しかしながら車載ネットワークシステムなどの制御ネットワークシステムにおいては、通信のリアルタイム性および／または信頼性が求められるサービスも存在し、サービスを利用できないことが、当該システムが搭載される対象物（例えば、移動体）の安全性に影響を及ぼす可能性がある。
　本開示は、制御ネットワークシステムが搭載される対象物の安全性を保ちつつ、セキュアな制御ネットワークシステムを実現するための情報処理方法などを提供する。
　本開示の一態様に係る情報処理方法は、制御ネットワークシステムにおける情報処理装置が実行する情報処理方法であって、前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、前記情報処理方法は、前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得し、前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する。
　本開示の一態様に係る情報処理装置は、制御ネットワークシステムにおける情報処理装置であって、前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、前記情報処理装置は、前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得する取得部と、前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する出力部とを備える。
　本開示の一態様に係るプログラムは、本開示の一態様に係る情報処理方法をコンピュータが実行するための、プログラムである。
　本開示の一態様に係る情報処理方法などによれば、制御ネットワークシステムが搭載される対象物の安全性を保ちつつ、セキュアな制御ネットワークシステムを実現することができる。
図１は、実施の形態に係る車載ネットワークシステムの構成を示す図である。 図２は、実施の形態に係るセントラルＥＣＵの構成を示すブロック図である。 図３は、実施の形態に係るゾーンＥＣＵの機能構成を示すブロック図である。 図４は、実施の形態に係るカメラＥＣＵの機能構成を示すブロック図である。 図５は、実施の形態に係るアクセスポリシーの一例を示す図である。 図６は、実施の形態に係る車両状態の一例を示す図である。 図７は、実施の形態に係るユーザ情報の一例を示す図である。 図８は、実施の形態に係るアクセス許可の処理手順を示すシーケンス図である。 図９は、実施の形態に係るアクセス許可の処理手順を示すシーケンス図である。 図１０は、実施の形態に係るセントラルＥＣＵのマスターポリシー判断部およびポリシー実施部の処理手順を示すフローチャートである。 図１１は、実施の形態に係るゾーンＥＣＵのポリシー判断部およびポリシー実施部の処理手順を示すフローチャートである。 図１２は、実施の形態に係るセントラルＥＣＵのマスターポリシー判断部の車両状態に応じてサービスの重要特性を変化させる処理手順を示すフローチャートである。 図１３は、実施の形態に係るセントラルＥＣＵが受信するポリシー検証結果が他と異なるＥＣＵが存在したときの処理手順を示すフローチャートである。 図１４は、実施の形態の変形例１に係る車載ネットワークシステムの構成を示す図である。 図１５は、実施の形態の変形例１に係るセントラルＥＣＵの機能構成を示すブロック図である。 図１６は、実施の形態の変形例１に係るゾーンＥＣＵの機能構成を示すブロック図である。 図１７は、実施の形態の変形例１に係る車両状態の一例を示す図である。 図１８は、実施の形態の変形例１に係るセントラルＥＣＵのマスターポリシー判断部における閾値を決定する処理手順を示すフローチャートである。 図１９は、実施の形態の変形例２に係るセントラルＥＣＵが受信するポリシー検証結果が他と異なるＥＣＵが存在したときの処理手順を示すフローチャートである。 図２０は、実施の形態の変形例２に係るポリシー検証結果が他と異なるゾーンＥＣＵが存在したときの状態を可視化した一例を示す図である。
　以下、本開示の実施の形態について、図面を参照しながら説明する。
　なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すためのものである。以下の実施の形態で示される数値、形状、構成要素、ステップ、ステップの順序等は、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また、全ての実施の形態において、各々の内容を組み合わせることもできる。さらに、本開示の主旨を逸脱しない限り、本開示の各実施の形態に対して当業者が想到する範囲内の変更を施した各種変形例も本開示に含まれる。
　また、本明細書において、同じなどの要素間の関係性を示す用語、並びに、数値、および、数値範囲は、厳格な意味のみを表す表現ではなく、実質的に同等な範囲、例えば数％程度（あるいは、１０％程度）の差異をも含むことを意味する表現である。
　（実施の形態）
　［構成］
　まず、実施の形態に係る車載ネットワークシステムの構成について説明する。
　図１は、本実施の形態に係る車載ネットワークシステムの全体構成を示す図である。
　車載ネットワークシステムは、セントラルＥＣＵ１００と、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄ（以降において、ゾーンＥＣＵ２００ａ等とも記載する）と、カメラＥＣＵ３００ａと、充電器ＥＣＵ３００ｂと、ブレーキＥＣＵ３００ｃと、モータＥＣＵ３００ｄと、を備える。
　車載ネットワークシステムは、車両１０における電子制御装置が互いに通信するシステムである。例えば、カメラＥＣＵ３００ａとゾーンＥＣＵ２００ａとは、車載ネットワークを介して通信する。また、ゾーンＥＣＵ２００ａは、セントラルＥＣＵ１００またはゾーンＥＣＵ２００ｂと車載ネットワークを介して通信する。車載ネットワークシステムは、制御ネットワークシステムの一例である。
　車載ネットワークは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）、ＬＩＮ、ＦｌｅｘＲａｙ、Ｅｔｈｅｒｎｅｔ（登録商標）と呼ばれる車載ネットワーク通信規格に基づいてネットワークが構成されている。
　車両１０は、ユーザが利用する。車両１０は、例えば、自動車であるが、オートバイなどであってもよいし、船舶または飛行機といったその他のモビリティシステムであってもよい。また、車両１０は、自動運転車両であってもよいし、手動運転車両であってもよい。車両１０は、制御ネットワークシステムが搭載される対象物の一例である。
　セントラルＥＣＵ１００は、車両制御の中心的な機能を果たす電子制御装置である。セントラルＥＣＵ１００は、コネクティビティ機能を保有しており、車両１０の外部にあるサーバと携帯電話網あるいはＷｉ－Ｆｉ（登録商標）などを通じて、無線経由で車両の状態の通知、ファームウェアのダウンロードなどを実施する。またセントラルＥＣＵ１００は、自動運転アプリケーションが搭載されており、各ＥＣＵの情報を取得し、制御することで自動運転機能を実現する。セントラルＥＣＵ１００は、情報処理装置またはアクセス許可装置の一例である。
　ゾーンＥＣＵ２００ａ～２００ｄは、車載ネットワークの各所に配置され、サブネットワークのゲートウェイの役割を果たし、セントラルＥＣＵ１００または他のゾーンＥＣＵと通信を行う。ゾーンＥＣＵ２００ａ～２００ｄは、エッジアクセス許可装置の一例である。
　カメラＥＣＵ３００ａは、カメラ情報を取得し、車載ネットワークへ送信する。
　充電器ＥＣＵ３００ｂは、車両１０に搭載されるバッテリーの充電制御を行う。充電器ＥＣＵ３００ｂと、ゾーンＥＣＵ２００ａとは、車載ネットワークを介して通信する。
　ブレーキＥＣＵ３００ｃは、車両１０のブレーキ制御を行う。ブレーキＥＣＵ３００ｃと、ゾーンＥＣＵ２００ｃとは、車載ネットワークを介して通信する。
　モータＥＣＵ３００ｄは、自動車のモータの制御を行う。モータＥＣＵ３００ｄと、ゾーンＥＣＵ２００ｄとは、車載ネットワークを介して通信する。
　各ＥＣＵは、他のＥＣＵと通信を行う際に、例えばＳｃａｌａｂｌｅ　Ｓｅｒｖｉｃｅ　Ｏｒｉｅｎｔｅｄ　Ｍｉｄｄｌｅｗａｒｅ　ｏｖｅｒ　ＩＰ（ＳＯＭＥ／ＩＰプロトコル）によって、各種データの授受、制御指示の授受などを行う。本実施の形態では、ゾーンＥＣＵ２００ａ～２００ｄのそれぞれに１つずつＥＣＵが接続されている例を示しているが、接続されるＥＣＵの数は特にこれに限定されない。
　上記のように、本実施の形態に係る車載ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数のＥＣＵ（例えば、カメラＥＣＵ３００ａ、充電器ＥＣＵ３００ｂ、ブレーキＥＣＵ３００ｃ、モータＥＣＵ３００ｄ）と、それぞれが所定のアクセスポリシーに基づいて、アクセスの可否を判断する複数のゾーンＥＣＵ２００ａ等とを含む。
　図２は、本実施の形態に係るセントラルＥＣＵ１００の機能構成を示すブロック図である。
　セントラルＥＣＵ１００は、センター通信部１０１と、車両制御アプリ部１０２と、ドライバアプリ部１０３と、自動運転アプリ部１０４と、車載ネットワーク通信部１０５と、マスターポリシー判断部１０６と、ポリシー実施部１０７と、アクセスポリシー保持部１０８と、車両状態保持部１０９と、ユーザ情報保持部１１０と、を備える。また、セントラルＥＣＵ１００は、車載ネットワークシステムの複雑化に伴って増大する開発期間又はコストの課題を解消するため、従来複数のＥＣＵに分かれて搭載されていた機能が統合されたＥＣＵ（統合ＥＣＵ）であってもよい。統合ＥＣＵは、１つのＥＣＵに複数の仮想的なコンピュータ（仮想マシン：ＶＭ）を動作させるために仮想化技術が利用されているＥＣＵである。例えば、車両制御アプリ部１０２と、ドライバアプリ部１０３と、自動運転アプリ部１０４とは、仮想マシンにより実現されてもよい。また、車両制御アプリ部１０２と、ドライバアプリ部１０３と、自動運転アプリ部１０４とは、仮想化技術により論理的には分離されている。また、車両制御アプリ部１０２と、ドライバアプリ部１０３と、自動運転アプリ部１０４とには、互いに異なるＩＰアドレスが割り当てられている。
　センター通信部１０１は、車両１０の外部のサーバと通信を行う通信インターフェースである。センター通信部１０１は、アクセスの可否の判断結果を含むポリシー検証結果を取得する取得部として機能する。また、センター通信部１０１は、さらに、マスターポリシー検証結果に関する検証情報を外部のサーバに出力する出力部として機能してもよい。
　車両制御アプリ部１０２は、走る・曲がる・止まるといった車両１０の基本的な機能を実現するために、各ＥＣＵから取得したデータの処理または制御を実施するアプリケーションである。
　ドライバアプリ部１０３は、車両１０のユーザエクスペリエンス向上のためのアプリケーションであり、車内の空調制御またはインフォテインメントシステムの制御などを行う。
　自動運転アプリ部１０４は、自動運転を実行するためのアプリケーションであり、セントラルＥＣＵ１００以外の他のＥＣＵから車外のセンシング情報を取得し、車両１０の制御を行う。
　車載ネットワーク通信部１０５は、車載ネットワークの通信インターフェースであり、ゾーンＥＣＵ２００ａ～２００ｄとメッセージの授受を行う。また車載ネットワーク通信部１０５は、通信の転送制御を行うネットワークスイッチの機能を備える。車載ネットワーク通信部１０５は、マスターポリシー検証結果に関する検証情報を各ゾーンＥＣＵ２００ａ等に出力する出力部として機能してもよい。
　マスターポリシー判断部１０６は、車両機能へのアクセス要求があった場合に、当該機能へのアクセスを許可するか否かを判断する。具体的にはアクセスポリシー保持部１０８に格納されるアクセスポリシーに基づいて、車載ネットワーク通信部１０５で取得したメッセージの内容に関して送信先と送信元とが合致しているか否かを判断する。取得したメッセージの内容に関して送信先と送信元とが合致している場合、車載ネットワーク通信部１０５は、アクセス許可をポリシー実施部１０７に通知する。取得したメッセージの内容に関して送信先と送信元とが合致していない場合、車載ネットワーク通信部１０５は、アクセス拒否をポリシー実施部１０７に通知する。なお、マスターポリシー判断部１０６は、サービスＩＤと提供先ＩＰアドレスとが一致するか否かを判断してもよい。
　また、マスターポリシー判断部１０６は、アクセスポリシー保持部１０８に格納されるアクセスポリシーだけでなく、ゾーンＥＣＵ２００ａ～２００ｄに配置されるポリシー判断部２０２から通知される、アクセスポリシーの検証結果であるポリシー検証結果に基づいて総合的にアクセス許可を判断してもよい。その後、マスターポリシー判断部１０６は、アクセス許可／拒否の通知をゾーンＥＣＵ２００ａ～２００ｄのポリシー実施部２０３へ通知する。
　ポリシー実施部１０７は、マスターポリシー判断部１０６から通知されるアクセス許可／拒否の通知に基づいて、車両機能へのアクセスを許可／拒否する。具体的にはポリシー実施部１０７は、車載ネットワーク通信部１０５で取得したメッセージの転送／破棄の制御を行う。
　アクセスポリシー保持部１０８は、車両機能へのアクセス制御を行うためのポリシーに関する情報を記憶するストレージである。詳細は図５を用いて後述する。アクセスポリシー保持部１０８は、例えば、半導体メモリまたはＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などにより実現されるがこれに限定されない。
　車両状態保持部１０９は、現在の車両状態の情報を記憶するストレージである。詳細は図６を用いて後述する。車両状態保持部１０９は、例えば、半導体メモリまたはＨＤＤなどにより実現されるがこれに限定されない。
　ユーザ情報保持部１１０は、ユーザ情報を記憶するストレージである。詳細は図７を用いて後述する。ユーザ情報保持部１１０は、例えば、半導体メモリまたはＨＤＤなどにより実現されるがこれに限定されない。
　図３は、本実施の形態に係るゾーンＥＣＵ２００ａの機能構成を示すブロック図である。なおゾーンＥＣＵ２００ｂ、２００ｃ、２００ｄも同様の構成のため、これらの説明を省略する。
　ゾーンＥＣＵ２００ａは、車載ネットワーク通信部２０１と、ポリシー判断部２０２と、ポリシー実施部２０３と、アクセスポリシー保持部２０４と、車両状態保持部２０５と、を備える。
　車載ネットワーク通信部２０１は、車載ネットワークの通信インターフェースであり、セントラルＥＣＵ１００およびゾーン内のカメラＥＣＵ３００ａの少なくとも一方と通信を行う。また車載ネットワーク通信部２０１は、必要に応じて通信の転送制御を行うネットワークスイッチの機能を備える。
　ポリシー判断部２０２は、アクセスポリシー保持部２０４に格納されるアクセスポリシーに基づいて、車載ネットワーク通信部２０１で取得したメッセージの内容に関して、送信先と送信元とが合致しているか否かを判断する。メッセージの内容に関して、送信先と送信元とが合致している場合、ポリシー判断部２０２は、アクセス許可をポリシー実施部２０３に通知する。メッセージの内容に関して、送信先と送信元とが合致していない場合、ポリシー判断部２０２は、アクセス拒否をポリシー実施部２０３に通知する。なお、ポリシー判断部２０２は、サービスＩＤと提供先ＩＰアドレスとが一致するか否かを判断してもよい。ポリシー判断部２０２の判断結果は、ポリシー検証結果の一例であり、アクセスの可否の判断結果を含む。
　また、メッセージの内容に応じて、アクセス許可の検証結果をポリシー実施部２０３に通知するのではなく、ポリシー判断部２０２は、セントラルＥＣＵ１００のマスターポリシー判断部１０６へ通知し、マスターポリシー判断部１０６から、アクセス許可／拒否の最終判断結果をポリシー実施部２０３に通知する場合もある。
　ポリシー実施部２０３は、ポリシー実施部１０７と同様の機能を有し、ポリシー判断部２０２または、マスターポリシー判断部１０６から通知されるアクセス許可／拒否の通知に基づいて、車両機能へのアクセスを許可／拒否する。具体的にはポリシー実施部２０３は、車載ネットワーク通信部２０１で取得したメッセージの転送／破棄の制御を行う。例えば、ポリシー実施部２０３は、アクセス許可されたメッセージを転送し、アクセス拒否されたメッセージを破棄する。
　アクセスポリシー保持部２０４は、車両機能へのアクセス制御を行うためのポリシーに関する情報を記憶するストレージである。基本的にはアクセスポリシー保持部２０４は、セントラルＥＣＵ１００の備えるアクセスポリシー保持部１０８と同様の情報を保持しており、詳細は図５を用いて後述する。アクセスポリシー保持部２０４は、例えば、半導体メモリまたはＨＤＤなどにより実現されるがこれに限定されない。
　車両状態保持部２０５は、現在の車両状態の情報を記憶するストレージである。基本的には車両状態保持部２０５は、セントラルＥＣＵ１００の備える車両状態保持部１０９と同様の情報を保持しており、詳細は図６を用いて後述する。車両状態保持部２０５は、例えば、半導体メモリまたはＨＤＤなどにより実現されるがこれに限定されない。
　図４は、本実施の形態に係るカメラＥＣＵ３００ａの機能構成を示すブロック図である。なお、充電器ＥＣＵ３００ｂ、ブレーキＥＣＵ３００ｃ、モータＥＣＵ３００ｄについても、実質的な構成は同様のため説明を省略する。
　カメラＥＣＵ３００ａは、アプリ部３０１と、通信部３０２と、を備える。
　アプリ部３０１は、ＥＣＵの機能を実現するアプリケーションが搭載されている。カメラＥＣＵ３００ａは、カメラ情報を取得し、必要なＥＣＵに対してカメラ情報を提供するサービスが起動している。充電器ＥＣＵ３００ｂは、バッテリーの充電状態を提供するためのサービスまたはバッテリーの充電制御を行うためのサービスが起動している。ブレーキＥＣＵ３００ｃは、ブレーキの状態を通知するためのサービスまたはブレーキの制御を行うためのサービスが起動している。モータＥＣＵ３００ｄは、モータの状態を通知するためのサービスまたはモータの制御を行うためのサービスが起動している。
　通信部３０２は、車載ネットワークの通信インターフェースであり、ゾーンＥＣＵ２００ａと通信を行う。
　［各種情報の具体例］
　続いて、実施の形態に係る車載ネットワークシステムで用いられる各種情報について説明する。
　図５は、本実施の形態に係るアクセスポリシーの一例を示す図である。アクセスポリシーは、アクセスポリシー保持部１０８および２０４に記憶されている情報である。例えば、アクセスポリシー保持部１０８および２０４に記憶されているアクセスポリシーは、同一の情報（同期がとれている情報）である。
　アクセスポリシーは、機能（サービスＩＤ）ごとに、提供先ＩＰアドレスと提供元ＩＰアドレスとを示す情報であり、さらに機能ごとに重要特性が定められている。またアクセスポリシーには、アクセスポリシーのバージョン情報が併せて保持されている。少なくともサービスＩＤおよび提供先ＩＰアドレスは、メッセージ（車両機能へのアクセス要求であり、後述する探索メッセージ）に含まれる情報である。
　図５において、アクセスポリシーのバージョンは１．０であり、車両１０の機能として、カメラ情報（サービスＩＤ：０ｘ１０）、ブレーキ制御（サービスＩＤ：０ｘ２０）、充電器制御（サービスＩＤ：０ｘ３０）、ユーザ情報取得（サービスＩＤ：０ｘ４０）があり、それぞれの機能のサービスの提供先として許可されたＩＰアドレスが順に、１９２．１６８．０．２０、１９２．１６８，０．１０、１９２．１６８．０．１０、１９２．１６８．０．３０であり、サービスの提供元として許可されたＩＰアドレスが順に、１９２．１６８．０．１０、１９２．１６８，０．５、１９２．１６８．０．３０、１９２．１６８．０．１０であり、重要特性が順に、可用性、安全性、可用性、機密性である。
　車載ネットワークの通信は例えば、ＳＯＭＥ／ＩＰによって実現されていてもよく、サービスＩＤはＳＯＭＥ／ＩＰにおけるＭｅｓｓａｇｅ　ＩＤやＳｅｒｖｉｃｅ　ＩＤと対応している。なお、車載ネットワークの車載プロトコルは、ＳＯＭＥ／ＩＰであることに限定されない。
　重要特性は、可用性、安全性、および、機密性に分類される。なお、重要特性は、可用性、安全性、および、機密性のうち少なくとも２つを含んでいればよい。
　可用性は、サービスの継続性が重要な要素となるようなサービスに対して割り当てられる。例えばカメラ情報、車両１０の状態通知など情報が遮断されることによって車両制御に影響が及ぶようなサービスが該当する。例えば、可用性が求められるサービス（第１サービス）として、カメラなどのセンサにより取得されたセンサデータの授受が例示されるがこれに限定されない。
　可用性が重要なサービスに対しては、リアルタイム性またはサービスの継続性が求められるため、マスターポリシー判断部１０６または、ポリシー判断部２０２は、当該サービスの通信の遮断の判断を安全性および機密性に比べて慎重に行う。つまり単一のポリシー判断部２０２によってアクセス拒否を判断するのではなく、複数のポリシー判断部２０２の結果に基づいてマスターポリシー判断部１０６がアクセスの拒否を判断する。またリアルタイム性が求められるため、マスターポリシー判断部１０６は、アクセス拒否の判断までの通信を許可するようにアクセス制御を行う。
　安全性は、車両制御に直接的な影響を及ぼしうるサービスに対して割り当てられる。例えば、ブレーキまたはモータ制御指示を受け付け、ブレーキまたはモータの制御を行うようなサービスが該当する。例えば、安全性が求められるサービス（第３サービス）として、リアルタイム性の求められるアクチュエータの制御に関するサービスが例示されるがこれに限定されない。
　安全性が重要なサービスに対しては、不正なサービスへのアクセスを即時に遮断することが求められ、さらに車両１０の制御に関わるためリアルタイム性も求められる。そのため単一のポリシー判断部２０２の決定に基づいてサービスのアクセスの許可／拒否が判断される。例えば、各ゾーンＥＣＵ２００ａ等が自装置のポリシー判断部２０２のポリシー検証結果に基づいて、自装置におけるサービスのアクセスの許可／拒否を判断する。
　機密性は、サービスに含まれる情報が、許可されたアプリケーション以外に読み取られたくないサービスに対して割り当てられる。例えばユーザの個人情報に関わる情報を提供するサービスが該当する。例えば、機密性が求められるサービス（第２サービス）として、個人情報または機密情報に関するデータの授受が例示されるがこれに限定されない。
　機密性が重要なサービスに対しては、リアルタイム性は求められないが、アクセスの許可を慎重に判断することが求められる。そのため、マスターポリシー判断部１０６、またはポリシー判断部２０２は、当該サービスの通信に関して、複数のポリシー判断部２０２の結果に基づいて、マスターポリシー判断部１０６がアクセスの許可を判断する。また各ゾーンＥＣＵは、マスターポリシー判断部１０６によるアクセス許可の判断までは、通信を保留させておくようにアクセス制御を行う。
　なお、機能は、図５に示す例に限るものではなく、ほかにもあってもよい。
　また、提供先ＩＰアドレスと提供元ＩＰアドレスとの両方に値が設定されている必要はなく、どちらか片方のＩＰアドレスだけが設定されていてもよい。また設定されるＩＰアドレスが複数あってもよい。例えば、アクセスポリシーは、複数のＥＣＵのうちサービスへのアクセスを許可されたＥＣＵ、および、複数のＥＣＵのうちサービスの提供を許可されたＥＣＵのいずれか、または両方に関する情報を含んでいてもよい。
　また、提供先と提供元とを示す情報はＩＰアドレスでなくても構わない。提供先と提供元とを示す情報としては、例えばＭＡＣアドレス、または、ＥＣＵもしくはアプリケーションを識別する識別子であってもよい。
　また、サービスＩＤは、サービスの識別子を表すものであればなんでもよい。サービスＩＤは、メッセージに含まれていてもよい。また、サービスＩＤは、ポート番号であってもよい。
　また、重要特性は、設定されていないサービスが存在しても構わない。重要特性が設定されていないサービスに対しては、デフォルトで設定された基準（例えば単一のポリシー判断部２０２による判断）に従ってアクセス許可／拒否が判断されてもよい。
　また、アクセスポリシーは、暗号化されてアクセスポリシー保持部１０８および２０４に保持されていてもよい。
　また、アクセスポリシーには、マスターポリシー判断部１０６、および、ポリシー判断部２０２以外が参照できないように、アクセス制御が設定されていてもよい。
　また、アクセスポリシーは、正規の手順に基づいて更新されてもよい。正規の手順とは例えば、外部のサーバから受信したアクセスポリシーのバージョンがロールバックしていないこと、アクセスポリシーのデジタル署名の検証が正しいことなどを検証した後に、アクセスポリシーが更新されてもよい。
　図６は、本実施の形態に係る車両状態の一例を示す図である。車両状態は、車両状態保持部１０９、および２０５に記憶されている情報である。
　車両状態には、車載ネットワークを介して通知される情報に基づいた現在の車両状態が記憶されている。具体的には、車両状態保持部１０９、および２０５は、車両状態として、車両１０の走行状態、自動運転モードのＯＮ／ＯＦＦ、バッテリーの残電力の状態を保持している。図６において、走行状態が走行中、自動運転がＯＦＦ、バッテリーの残電力が７０％である状態を一例として示している。
　マスターポリシー判断部１０６、およびポリシー判断部２０２は、車両状態に応じて、アクセスポリシーの各サービスの重要特性を変更しうる。例えば、車両１０が停車している場合に、マスターポリシー判断部１０６、およびポリシー判断部２０２は、充電制御サービスの重要特性を安全性に変更するなど、現在の車両状態に応じてサービスが重要とする特性が変化する場合に対応するために車両状態を用いる。
　なお、車両状態は図６に示す例に限らず、例えば診断モード状態またはアップデート状態を含んでいてもよい。診断モード状態は、例えば各ＥＣＵの自己診断機能のモード（例えば、ＯＮ／ＯＦＦ）を示す。アップデート状態は、車両１０に搭載されている各アプリケーション、アクセスポリシーのアップデートの状態（例えば、バージョン）を示す。
　図７は、本実施の形態に係るユーザ情報の一例を示す図である。ユーザ情報は、ユーザ情報保持部１１０に記憶されている情報である。
　ユーザ情報保持部１１０は、ユーザ情報として具体的には車両ユーザの氏名、住所、電話番号、およびクレジットカード情報を保持する。車両ユーザの氏名は、例えば、車両１０を現在使用しているユーザの氏名であってもよい。
　図７に示す例では、ユーザの氏名は山田太郎であり、住所は大阪府ＸＸＸＸであり、電話番号は０９０ＸＸＸＸＸＸＸＸであり、クレジットカード情報はＹＹＹＹＹＹであることを示している。
　なお、ユーザ情報保持部１１０が保持するユーザ情報は、図７に示す情報に限らない。ユーザ情報保持部１１０は、例えば、ユーザ情報として、ユーザのスマートフォンなどの情報端末から取得したアドレス帳情報、お気に入りの場所情報などを保持していてもよい。
　また、ユーザ情報は暗号化されてユーザ情報保持部１１０に保持されていてもよい。
　［処理手順］
　続いて、本実施の形態に係る車載ネットワークシステムの処理手順について説明する。
　図８は、本実施の形態に係るアクセスの許可の処理手順を示すシーケンス図（情報処理方法、アクセス許可方法）である。具体的には、図８は、セントラルＥＣＵ１００の自動運転アプリが、カメラＥＣＵ３００ａに対してカメラ情報サービスにアクセスする際のシーケンス図である。
　まず、セントラルＥＣＵ１００は、例えば自動運転機能がＯＮとなったタイミングに、カメラ情報サービスの利用を要求するためのカメラ情報サービスの探索メッセージを送信する（Ｓ１００）。カメラ情報サービスの探索メッセージとしてＳＯＭＥ／ＩＰ‐ＳＤ（Ｓｅｒｖｉｃｅ　Ｄｉｃｏｖｅｒｙ）メッセージ（Ｆｉｎｄメッセージ）がセントラルＥＣＵ１００からゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄにブロードキャストされる。
　ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのそれぞれは、カメラ情報サービスの探索メッセージを取得すると、当該メッセージに対してアクセスポリシーに合致しているか否かを確認する（Ｓ１０１）。つまり、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのそれぞれは、カメラ情報サービスの探索メッセージを取得すると、探索メッセージのアクセスポリシーを判断する。
　カメラ情報サービスの探索メッセージには、サービスＩＤとしてカメラ情報のＩＤ（図５の例では、０×１０）と、提供先ＩＰアドレス（セントラルＥＣＵ１００または探索メッセージを送信したアプリ部のＩＰアドレス）とが含まれる。ステップＳ１０１では、各ゾーンＥＣＵのポリシー判断部２０２は、探索メッセージに含まれるカメラ情報のＩＤおよび提供先ＩＰアドレスと、図５に示すアクセスポリシーとに基づいて、合致しているか否かを確認する。例えば、各ゾーンＥＣＵのポリシー判断部２０２は、探索メッセージに含まれるカメラ情報のＩＤおよび提供先ＩＰアドレスの組が、図５に示すアクセスポリシーにあるか否かを判断する。
　その後、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄは、カメラ情報サービスの重要特性が可用性であるため、まずカメラ情報サービスの探索メッセージを各自のゾーンに転送する（Ｓ１０２）。各ゾーンＥＣＵ２００ａ等は、例えば、自ゾーンにカメラ情報サービスを提供可能なカメラＥＣＵが接続されているか否かを把握しておらず、かつ、重要特性が可用性である場合、ステップＳ１０１の結果に関わらず探索メッセージを一旦転送する。なお、各ゾーンＥＣＵ２００ａ等が自ゾーンのＥＣＵが提供可能なサービスに関する情報を把握している（記憶している）場合、ステップＳ１０２の処理は省略されてもよい。
　さらに、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄは、アクセスポリシーの検証結果（ポリシー検証結果）が問題なし（ＯＫ）であったことをセントラルＥＣＵ１００に返答する（送信する）（Ｓ１０３）。ステップＳ１０３では、ステップＳ１０１の処理の結果（検証結果）を提供先のＥＣＵであるセントラルＥＣＵ１００に送信する。ステップＳ１０３は、ステップＳ１０２の処理とは無関係に実行される。
　ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄからのポリシー検証結果が全てＯＫであったため、セントラルＥＣＵ１００が、カメラ情報サービスにアクセスすることを許可し、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄに対しても許可の通知を行う（Ｓ１０４）。
　ステップＳ１０４において、セントラルＥＣＵ１００のマスターポリシー判断部１０６は、ゾーンＥＣＵ２００ａ、２００ｃ、２００ｄから送信されるポリシー検証結果に基づいて、ステップＳ１００で送信したカメラ情報サービスの探索メッセージに対する最終的なアクセスの可否の判断結果であるマスターポリシー検証結果（ここでは、アクセス許可）を出力する。
　ゾーンＥＣＵ２００ａは自ゾーンのカメラＥＣＵ３００ａから受信した返答（ＳＯＭＥ／ＩＰ‐ＳＤメッセージ（Ｏｆｆｅｒメッセージ））をセントラルＥＣＵ１００に転送する（Ｓ１０５）。つまり、ゾーンＥＣＵ２００ａは、カメラＥＣＵ３００ａからの返答をセントラルＥＣＵ１００に転送する。当該返答は、ステップＳ１０２において探索メッセージを転送したことに対して、カメラ情報を有していることを示す返答である。これにより、セントラルＥＣＵ１００は、カメラＥＣＵ３００ａがどのゾーンＥＣＵに接続されているかを取得することができる。
　セントラルＥＣＵ１００は、カメラＥＣＵ３００ａから受信したＯｆｆｅｒメッセージに基づいて、カメラ情報サービスの利用を要求するメッセージ（利用要求）をゾーンＥＣＵ２００ａへ送信する（Ｓ１０６）。その後、セントラルＥＣＵ１００とカメラＥＣＵ３００ａとのセッションが確立して、セントラルＥＣＵ１００はカメラ情報サービスを利用することができる。利用要求は、マスターポリシー検証結果に関する検証情報の一例である。
　なお、ステップＳ１０３のアクセスポリシーの検証結果の返答タイミングは、特に限定されない。また、ステップＳ１０３のアクセスポリシーの検証結果の返答タイミングに応じてステップＳ１０４のカメラ情報サービスへのアクセス許可の判断がステップＳ１０５より遅くなる可能性もあるが、カメラ情報サービスの重要特性が可用性であるため、いずれにせよ、カメラＥＣＵ３００ａからの返答は、セントラルＥＣＵ１００に転送される。
　図９は、本実施の形態に係る不正な挙動を示す充電器ＥＣＵ３００ｂが、カメラＥＣＵ３００ａに対してカメラ情報サービスにアクセスする際のシーケンス図（情報処理方法、アクセス許可方法）である。
　まず、充電器ＥＣＵ３００ｂから送信されたカメラ情報サービスの探索メッセージをゾーンＥＣＵ２００ｂが受信し、当該メッセージのアクセスポリシーを確認後、当該メッセージを他のゾーンＥＣＵ２００ａ、２００ｃ、２００ｄおよびセントラルＥＣＵ１００に転送する（Ｓ２００）。
　カメラ情報サービスの探索メッセージを転送されたセントラルＥＣＵ１００と、ゾーンＥＣＵ２００ａ、２００ｃ、２００ｄとは、当該探索メッセージ（受信メッセージ）のアクセスポリシーを確認する（Ｓ２０１）。アクセスポリシーの確認方法は、図８に示すステップＳ１０１と同様である。
　ゾーンＥＣＵ２００ａ、２００ｃ、２００ｄは、自ゾーンにカメラ情報サービスの探索メッセージを転送する（Ｓ２０２）。
　カメラＥＣＵ３００ａはゾーンＥＣＵ２００ａに、カメラ情報サービスのＯｆｆｅｒメッセージを送信し、ゾーンＥＣＵ２００ａは、当該メッセージをゾーンＥＣＵ２００ｂに転送する（Ｓ２０３）。その後メッセージは充電器ＥＣＵ３００ｂに転送される。つまり、ゾーンＥＣＵ２００ｂにおいて、カメラＥＣＵ３００ａからの返答が充電器ＥＣＵ３００ｂに転送される。
　次に、充電器ＥＣＵ３００ｂは、カメラ情報サービス利用を要求するメッセージをゾーンＥＣＵ２００ｂ、２００ａ経由でカメラＥＣＵ３００ａに送信する（Ｓ２０４）。
　その後、ゾーンＥＣＵ２００ｃ、２００ｄは、充電器ＥＣＵ３００ｂが、カメラ情報サービスを利用するのはアクセスポリシーに違反する検証結果（ＮＧ）をセントラルＥＣＵ１００に送信する（Ｓ２０５）。
　同様にゾーンＥＣＵ２００ａも、検証結果がアクセスポリシーに違反する検証結果（ＮＧ）であることをセントラルＥＣＵ１００に送信する（Ｓ２０６）。
　セントラルＥＣＵ１００は、ゾーンＥＣＵ２００ａ、２００ｃ、２００ｄから受信したアクセスポリシーの検証結果を総合的に判断して、アクセスポリシー違反となった充電器ＥＣＵ３００ｂがカメラ情報サービスにアクセスすることを禁止するメッセージ（カメラ情報サービスの遮断要求）を、該当するゾーンＥＣＵであるゾーンＥＣＵ２００ａと、ゾーンＥＣＵ２００ｂとに通知（送信）する（Ｓ２０７）。つまり、セントラルＥＣＵ１００は、カメラ情報サービスの遮断をゾーンＥＣＵ２００ａと、ゾーンＥＣＵ２００ｂとに要求する。ステップＳ２０７において、セントラルＥＣＵ１００のマスターポリシー判断部１０６は、例えば、ポリシーの検証結果のうちアクセスＮＧ（アクセス拒否）であることを含むポリシー検証結果の数が閾値以上ある場合、アクセス拒否であることを示すマスターポリシー検証結果（ここでは、遮断要求）を、複数のゾーンＥＣＵ２００ａ等のうちカメラＥＣＵ３００ａに接続されたゾーンＥＣＵ２００ａと、充電器ＥＣＵ３００ｂに接続されたゾーンＥＣＵ２００ｂとを送信する。
　ステップＳ２０７において、セントラルＥＣＵ１００のマスターポリシー判断部１０６は、ゾーンＥＣＵ２００ａ、２００ｃ、２００ｄから送信されるアクセスポリシーの検証結果に基づいて、ステップＳ２００で受信したカメラ情報サービスの探索メッセージに対する最終的なアクセスの可否の判断結果であるマスターポリシー検証結果（ここでは、アクセス拒否と判定されたので、遮断要求）を出力する。遮断要求は、マスターポリシー検証結果に関する検証情報の一例である。
　その後、充電器ＥＣＵ３００ｂとカメラＥＣＵ３００ａとにおけるカメラ情報サービスに関する通信は、ゾーンＥＣＵ２００ａまたは、ゾーンＥＣＵ２００ｂにおいて遮断され、充電器ＥＣＵ３００ｂは不正にカメラ情報サービスを利用することができなくなる。
　この場合、充電器ＥＣＵ３００ｂは一の電子制御装置の一例であり、カメラＥＣＵ３００ａは他の一の電子制御装置の一例である。また、探索メッセージの送信は、充電器ＥＣＵ３００ｂからカメラＥＣＵ３００ａのサービスへのアクセスの一例である。
　なお、ステップＳ２０７の遮断要求は、さらにゾーンＥＣＵ２００ｃおよび２００ｄを含む複数のゾーンＥＣＵ２００ａ等のそれぞれに通知（送信）されてもよい。
　図１０は、本実施の形態に係るセントラルＥＣＵ１００が実行する、マスターポリシー判断部１０６とポリシー実施部１０７との処理の詳細を示すフローチャート（情報処理方法、アクセス許可方法）である。
　まず、セントラルＥＣＵ１００は、車載ネットワークからＳＯＭＥ／ＩＰ―ＳＤメッセージ（サービスＦｉｎｄメッセージまたはサービスＯｆｆｅｒメッセージ）を受信する（Ｓ３００）。サービスＦｉｎｄメッセージは、提供先（クライアント側）がサービスを提供する提供元（サーバ側）を見つけるためのメッセージである。サービスＦｉｎｄメッセージは、どのＥＣＵがどのサービスを探しているかを含むメッセージである。また、サービスＯｆｆｅｒメッセージは、サーバ側（カメラＥＣＵ３００ａとか）から所有する（提供可能な）情報を通知するメッセージである。サービスＯｆｆｅｒメッセージは、どのＥＣＵがどのサービスを提供可能であるかを含むメッセージである。
　セントラルＥＣＵ１００は、受信したＳＯＭＥ／ＩＰ―ＳＤメッセージに含まれる提供または要求するサービスＩＤを確認し、アクセスポリシー保持部１０８を参照することで、受信したメッセージに関わるサービスの重要特性が安全性であるか否かを判断する（Ｓ３０１）。セントラルＥＣＵ１００のマスターポリシー判断部１０６は、サービスＦｉｎｄメッセージまたはサービスＯｆｆｅｒメッセージに含まれるサービスＩＤの重要特性が安全性であるかを、図５に示すアクセスポリシーに基づいて判断する。図５に示すように、アクセスポリシーでは、サービスＩＤと重要特性とが一対一に対応付けられている。
　なお、受信したＳＯＭＥ／ＩＰ―ＳＤメッセージに複数のサービスＩＤが存在する場合があるが、その場合、セントラルＥＣＵ１００はすべてのサービスＩＤを確認し、安全性が求められるサービスが存在するか否かを判断してもよい。
　また、異なる重要特性が含まれるＳＯＭＥ／ＩＰ―ＳＤメッセージに対しては、セントラルＥＣＵ１００は、各サービスＩＤに分割して、ＳＯＭＥ／ＩＰ―ＳＤメッセージを転送してもよい。例えば重要特性が安全性と可用性との異なるサービスＩＤを含むＳＯＭＥ／ＩＰ―ＳＤメッセージに対しては、セントラルＥＣＵ１００は、重要特性が可用性であるサービスＩＤのみを含むＳＯＭＥ／ＩＰ－ＳＤメッセージを作成し、作成したメッセージを先に転送してもよい。またセントラルＥＣＵ１００は、サービスのポリシー確認をＳＯＭＥ／ＩＰ―ＳＤメッセージに対して実施するのではなく、ＳＯＭＥ／ＩＰメッセージに対して実施するとしてもよい。
　受信したメッセージに関わるサービスの重要特性が安全性であると判断された場合（Ｓ３０１でＹｅｓ）、セントラルＥＣＵ１００は、アクセスポリシーを確認し、サービスの提供元と提供先とがアクセスポリシーに合致しているか否かを判断する（Ｓ３０２）。
　次に受信したメッセージがアクセスポリシーに合致していると判断された場合（Ｓ３０２でＹｅｓ）、セントラルＥＣＵ１００は、当該メッセージの転送を許可し（Ｓ３０３）、処理を終了する。ステップＳ３０３では、セントラルＥＣＵ１００を通るメッセージのみ許可されることとなる。なお、図１１を用いて後述するが、この場合、各ゾーンＥＣＵ２００ａ等は、個々にアクセスポリシーがＯＫか否かを判断する。また、ステップＳ３０３における当該メッセージは、ＳＯＭＥ／ＩＰの通常のメッセージのことであり、例えばカメラ情報（画像情報）を送るメッセージであってもよい。当該メッセージは、サービスＦｉｎｄメッセージの後に受信したメッセージであり、サービスディスカバリーではない。
　セントラルＥＣＵ１００は、重要特性が安全性であるサービス（第３サービス）に対しては、マスターポリシー検証結果が出力される前に、複数のゾーンＥＣＵ２００ａ等のそれぞれが個別に、当該ゾーンＥＣＵのポリシー検証結果に基づいて、当該ゾーンＥＣＵにおける当該サービスに対するアクセス可否を判断することを許可するとも言える。
　アクセスポリシーに合致していないと判断された場合（Ｓ３０２でＮｏ）、セントラルＥＣＵ１００は、当該メッセージの転送を禁止して（Ｓ３０４）、処理を終了する。
　受信したメッセージに関わるサービスの重要特性が安全性でないと判断された場合（Ｓ３０１でＮｏ）、セントラルＥＣＵ１００は、受信したメッセージに関わるサービスの重要特性が機密性であるか否かを判断する（Ｓ３０５）。
　次に受信したメッセージに関わるサービスの重要特性が機密性であると判断された場合（Ｓ３０５でＹｅｓ）、セントラルＥＣＵ１００は、当該メッセージに関する、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果を受信する（Ｓ３０６）。
　さらにセントラルＥＣＵ１００は、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が閾値（ここでは、３）未満か否かを判断する（Ｓ３０７）。セントラルＥＣＵ１００は、機密性が求められる場合、重要なデータであるので他のゾーンＥＣＵの判断結果をもらって総合的にアクセス可否を判断する。また、ステップＳ３０７で用いられる閾値は、ステップＳ３１１で用いられる閾値よりも値が大きいがこれに限定されない。
　ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が３未満であると判断された場合（Ｓ３０７でＹｅｓ）、セントラルＥＣＵ１００は、当該メッセージの転送を禁止する（Ｓ３０４）。
　一方で、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が３以上であると判断された場合（Ｓ３０７でＮｏ）、セントラルＥＣＵ１００は、当該メッセージの転送を許可して（Ｓ３０８）、処理を終了する。
　受信したメッセージに関わるサービスの重要特性が機密性でないと判断された場合（Ｓ３０５でＮｏ）、セントラルＥＣＵ１００は、当該メッセージに関わるサービスの重要特性が可用性であるので、当該メッセージの転送を許可する（Ｓ３０９）。
　次にセントラルＥＣＵ１００は、当該メッセージに関するゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果を受信する（Ｓ３１０）。
　その後セントラルＥＣＵ１００は、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が２未満であるか否かを判断する（Ｓ３１１）。例えば、図９に示すステップＳ２０５、Ｓ２０６では、全部ＮＧなので受信数が０、つまり２未満であると判定される。
　ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が２未満であると判断された場合（Ｓ３１１でＹｅｓ）、セントラルＥＣＵ１００は、当該サービスに関してアクセスポリシーを違反する通信を禁止するようにゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄに通知して（Ｓ３１２）、処理を終了する。ステップＳ３１２は、図９に示すステップＳ２０７に相当する。
　一方で、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数が２以上であると判断された場合（Ｓ３１１でＮｏ）、セントラルＥＣＵ１００は、処理を終了する。この場合、ステップＳ３０９で許可された状態が継続する。このように、重要特性として可用性が求められるサービスである場合は、一旦許可して（Ｓ３０９）、おかしかったら（Ｓ３１１でＹｅｓ）後から禁止する（Ｓ３１２）ように処理が実行される。
　なお、セントラルＥＣＵ１００の処理内容を分岐させるゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果ＯＫの受信数の閾値は、本実施の形態で示した値に限らない。車載ネットワーク構成、ゾーンＥＣＵの配置数、および、メッセージの内容に応じて閾値が変更されてもよい。
　また、ポリシー検証結果ＯＫの受信数は、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果だけでなく、セントラルＥＣＵ１００のマスターポリシー判断部１０６のポリシー検証結果を含めてもよい。
　また、本フローチャートでは、ＳＯＭＥ／ＩＰ－ＳＤに関してアクセスポリシーを判断する例を示したが、アクセス制限の対象はＳＯＭＥ／ＩＰ－ＳＤメッセージに限らない。例えば、ＳＯＭＥ／ＩＰメッセージ、Ｄａｔａ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｓｅｒｖｉｃｅ（ＤＤＳ）メッセージなどであってもよい。
　また、本フローチャートでは、ステップＳ３０４において、セントラルＥＣＵ１００は、当該メッセージの転送を禁止、つまりＳＯＭＥ／ＩＰ－ＳＤメッセージの転送を禁止しているが、ＳＯＭＥ／ＩＰ－ＳＤメッセージは転送し、その後の該当サービスに関するメッセージについて転送を禁止するとしてもよいし、他のゾーンＥＣＵに対して、アクセスポリシー外の通信を禁止するように通知してもよい。
　図１１は、本実施の形態に係るゾーンＥＣＵ２００ａが実行する、アクセスの許可の判断処理の詳細を示すフローチャート（情報処理方法、アクセス許可方法）である。なお、ゾーンＥＣＵ２００ｂ、２００ｃ、２００ｄも同様の処理を実行する。
　まず、ゾーンＥＣＵ２００ａは、車載ネットワークからＳＯＭＥ／ＩＰ―ＳＤメッセージ（サービスＦｉｎｄメッセージまたはサービスＯｆｆｅｒメッセージ）を受信する（Ｓ４００）。
　ゾーンＥＣＵ２００ａは、受信したＳＯＭＥ／ＩＰ―ＳＤメッセージに含まれる提供または要求するサービスＩＤを確認し、アクセスポリシー保持部２０４を参照することで、受信したメッセージに関わるサービスの重要特性が安全性であるか否かを判断する（Ｓ４０１）。ゾーンＥＣＵ２００ａのポリシー判断部２０２は、サービスＦｉｎｄメッセージまたはサービスＯｆｆｅｒメッセージに含まれるサービスＩＤの重要特性が安全性であるかを、図５に示すアクセスポリシーに基づいて判断する。
　なお、受信したＳＯＭＥ／ＩＰ―ＳＤメッセージに複数のサービスＩＤが存在する場合があるが、その場合、ゾーンＥＣＵ２００ａはすべてのサービスＩＤを確認し、安全性が求められるサービスが存在するか否かを判断してもよい。
　また、異なる重要特性が含まれるＳＯＭＥ／ＩＰ―ＳＤメッセージに対して、ゾーンＥＣＵ２００ａは、各サービスＩＤに分割して、ＳＯＭＥ／ＩＰ―ＳＤメッセージを転送してもよい。例えば重要特性が安全性と可用性との異なるサービスＩＤを含むＳＯＭＥ／ＩＰ―ＳＤメッセージに対して、ゾーンＥＣＵ２００ａは、重要特性が可用性であるサービスＩＤのみを含むＳＯＭＥ／ＩＰ－ＳＤメッセージを作成し、作成したメッセージを先に転送してもよい。またゾーンＥＣＵ２００ａは、サービスのポリシー確認をＳＯＭＥ／ＩＰ―ＳＤメッセージに対して実施するのではなく、ＳＯＭＥ／ＩＰメッセージに対して実施するとしてもよい。
　受信したメッセージに関わるサービスの重要特性が安全性であると判断された場合（Ｓ４０１でＹｅｓ）、ゾーンＥＣＵ２００ａは、アクセスポリシーを確認し、サービスの提供元と提供先とがアクセスポリシーに合致しているか否かを判断する（Ｓ４０２）。
　次に受信したメッセージがアクセスポリシーに合致していると判断された場合（Ｓ４０２でＹｅｓ）、ゾーンＥＣＵ２００ａは、当該メッセージの転送を許可し（Ｓ４０３）、処理を終了する。ステップＳ４０３では、ゾーンＥＣＵ２００ａを通るメッセージのみ許可されることとなる。
　受信したメッセージがアクセスポリシーに合致していないと判断された場合（Ｓ４０２でＮｏ）、ゾーンＥＣＵ２００ａは、当該メッセージの転送を禁止して（Ｓ４０４）、処理を終了する。
　ゾーンＥＣＵ２００ａは、受信したメッセージに関わるサービスの重要特性が安全性でないと判断された場合（Ｓ４０１でＮｏ）、受信したメッセージに関わるサービスの重要特性が機密性であるか否かを判断する（Ｓ４０５）。
　次に受信したメッセージに関わるサービスの重要特性が機密性であると判断された場合（Ｓ４０５でＹｅｓ）、ゾーンＥＣＵ２００ａは当該メッセージに関する、ポリシー検証結果をセントラルＥＣＵ１００に送信する（Ｓ４０６）。
　さらにゾーンＥＣＵ２００ａはセントラルＥＣＵ１００から、最終的なアクセス許可／拒否の判断結果（マスターポリシー検証結果）を受信し、判断結果がアクセス拒否（ＮＧ）であるか否かを判断する（Ｓ４０７）。
　ゾーンＥＣＵ２００ａは、セントラルＥＣＵ１００から受信した最終判断結果として、アクセス拒否（ＮＧ）を受信した場合（Ｓ４０７でＹｅｓ）、当該メッセージの転送を禁止する（Ｓ４０４）。
　一方でゾーンＥＣＵ２００ａは、最終判断結果として、アクセス許可（ＯＫ）を受信した場合（Ｓ４０７でＮｏ）、当該メッセージの転送を許可して（Ｓ４０８）、処理を終了する。
　受信したメッセージに関わるサービスの重要特性が機密性でないと判断された場合（Ｓ４０５でＮｏ）、ゾーンＥＣＵ２００ａは、当該メッセージに関わるサービスの重要特性が可用性であるので、当該メッセージの転送を許可する（Ｓ４０９）。
　次にゾーンＥＣＵ２００ａは、当該メッセージに関するゾーンＥＣＵ２００ａのポリシー検証結果をセントラルＥＣＵ１００に送信する（Ｓ４１０）。
　その後、ゾーンＥＣＵ２００ａは、セントラルＥＣＵ１００から、最終的なアクセス許可／拒否の判断結果（マスターポリシー検証結果）を受信し、判断結果がアクセス拒否（ＮＧ）であるか否かを判断する（Ｓ４１１）。
　ゾーンＥＣＵ２００ａは、最終判断結果としてアクセス拒否を受信したと判断された場合（Ｓ４１１でＹｅｓ）、当該サービスに関してアクセスポリシーを違反する通信を禁止して（Ｓ４１２）、処理を終了する。
　一方で、ゾーンＥＣＵ２００ａは、最終判断結果としてアクセス許可であると判断された場合（Ｓ４１１でＮｏ）、何もせずに処理を終了する。この場合、ステップＳ４０９で許可された状態が継続する。このように、重要特性として可用性が求められるサービスである場合は、一旦許可して（Ｓ４０９）、おかしかったら（Ｓ４１１でＹｅｓ）後から禁止する（Ｓ４１２）ように処理が実行される。
　なお、本フローチャートでは、ＳＯＭＥ／ＩＰ－ＳＤに関してアクセスポリシーを判断する例を示したが、アクセス制限の対象はＳＯＭＥ／ＩＰ－ＳＤメッセージに限らない。ＳＯＭＥ／ＩＰメッセージ、Ｄａｔａ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｓｅｒｖｉｃｅ（ＤＤＳ）メッセージであってもよい。また、本フローチャートでは、ステップＳ４０４において、ゾーンＥＣＵ２００ａは、当該メッセージの転送を禁止、つまりＳＯＭＥ／ＩＰ－ＳＤメッセージの転送を禁止しているが、ＳＯＭＥ／ＩＰ－ＳＤメッセージは転送し、その後の該当サービスに関するメッセージについて転送を禁止するとしてもよい。
　図１２は、本実施の形態に係るセントラルＥＣＵ１００のマスターポリシー判断部１０６が車両状態保持部１０９に保持されている車両状態に応じて、アクセスポリシー保持部１０８に格納されている各サービスの重要特性を変更する処理を示すフローチャート（情報処理方法、アクセス許可方法）である。なお、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー判断部２０２も同様の処理を行う。
　まず、セントラルＥＣＵ１００は、車載ネットワークの通信からメッセージを受信し、通信内容から車両状態の変更を検出する（Ｓ５００）。ステップＳ５００において、セントラルＥＣＵ１００は、車両状態が変化したか否かを判断する。
　セントラルＥＣＵ１００は、車両状態の走行状態が停車中に変更されたか（変化したか）否かを判断する（Ｓ５０１）。
　車両状態の走行状態が停車中に変化したと判断された場合（Ｓ５０１でＹｅｓ）、セントラルＥＣＵ１００は、充電器制御に関わるサービスの通信の重要特性を安全性に変更（例えば、可用性から安全性に変更）して（Ｓ５０２）、ステップＳ５０７に進む。
　車両状態の走行状態が停車中に変化していないと判断された場合（Ｓ５０１でＮｏ）、セントラルＥＣＵ１００は、車両状態の走行状態が走行中に変更されたか（変化したか）否かを判断する（Ｓ５０３）。
　車両状態の走行状態が走行中に変化したと判断された場合（Ｓ５０３でＹｅｓ）、セントラルＥＣＵ１００は、ブレーキ制御に関わるサービスの通信の重要特性を安全性に変更して（Ｓ５０４）、ステップＳ５０７に進む。
　また、車両状態の走行状態が走行中に変化していないと判断された場合（Ｓ５０３でＮｏ）、セントラルＥＣＵ１００は、車両状態の自動運転モードがＯＮに変化したか否かを判断する（Ｓ５０５）。つまり、ステップＳ５０５では、車両状態が自動運転中に変化したか否かが判断される。
　車両状態の自動運転モードがＯＮに変化したと判断された場合（Ｓ５０５でＹｅｓ）、セントラルＥＣＵ１００は、ブレーキ制御に関わるサービスの通信の重要特性を可用性に変更（例えば、安全性から可用性に変更）して（Ｓ５０６）、ステップＳ５０７に進む。
　次に、セントラルＥＣＵ１００は、変更した重要特性を含む情報を各ゾーンＥＣＵ２００ａ等に送信する（Ｓ５０７）。セントラルＥＣＵ１００は、変更した重要特性を含むアクセスポリシーを各ゾーンＥＣＵ２００ａ等に送信してもよい。そして、セントラルＥＣＵ１００は、処理を終了する。
　一方、車両状態の自動運転モードがＯＮに変化していないと判断された場合（Ｓ５０５でＮｏ）、セントラルＥＣＵ１００は、処理を終了する。
　なお、重要特性の変更については、本フローチャートのようにアクセスポリシー保持部１０８の内容を変更してもよいし、図１０のアクセスポリシー保持部１０８の参照タイミングで、車両状態保持部１０９の車両状態を参照することで、重要特性を変更してもよい。
　これにより、同じサービスＩＤであっても車両状態に応じて重要特性が変化するので、アクセス可否の判断結果を車両状態に応じて異ならせることができる。よって、その時点での車両状態に応じたアクセス可否の判断結果を行うことができる。
　なお、セントラルＥＣＵ１００は、車両１０の車両状態とサービスとに応じて、アクセスを拒否する閾値の数値を増減させてもよい。例えば、セントラルＥＣＵ１００は、車両１０の車両状態が停車中、走行中、自動運転中の順に高くなるように、閾値の数値を設定してもよい。
　図１３は、本実施の形態に係るセントラルＥＣＵ１００のマスターポリシー判断部１０６がゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果を収集したときに、他のゾーンＥＣＵと異なる検証結果を送信するゾーンＥＣＵが存在した場合の処理を示すフローチャート（情報処理方法、アクセス許可方法）である。
　まず、セントラルＥＣＵ１００は、図１０のフローチャートのステップＳ３０６、またはステップＳ３１０において、各ゾーンＥＣＵ２００ａ等のポリシー検証結果を受信したときに、異なるポリシー検証結果を返答するゾーンＥＣＵが存在するか否かを判断する（Ｓ６００）。つまり、セントラルＥＣＵ１００は、各ゾーンＥＣＵから異なるポリシー検証結果を受信したか否かを判断する。
　セントラルＥＣＵ１００は、異なるポリシー検証結果を返答するゾーンＥＣＵが存在した場合（Ｓ６００でＹｅｓ）、異なるポリシー検証結果を返答したゾーンＥＣＵに対して、アクセスポリシーのバージョンを要求する（Ｓ６０１）。セントラルＥＣＵ１００は、当該ゾーンＥＣＵに対して、アクセスポリシーのバージョンの送信を要求する。アクセスポリシーのバージョンは、アクセスポリシーに関する情報の一例である。アクセスポリシーに関する情報は、例えば、アクセスポリシーを更新した日時などであってもよい。
　なお、セントラルＥＣＵ１００は、異なるポリシー検証結果を返答したゾーンＥＣＵに対して、アクセスポリシーのバージョンを要求するのではなく、すべてのゾーンＥＣＵに対して、アクセスポリシーのバージョンを要求してもよい。
　次に、異なるポリシー検証結果を返答したゾーンＥＣＵからアクセスポリシーのバージョンを受信すると、セントラルＥＣＵ１００は、受信したアクセスポリシーのバージョン情報が、セントラルＥＣＵ１００自身の保持するアクセスポリシーのバージョン情報と異なるか否かを判断する（Ｓ６０２）。ステップＳ６０２では、例えば、各ゾーンＥＣＵ２００ａ等において、保持するアクセスポリシーが同期しているかが判断されてもよい。
　なお、セントラルＥＣＵ１００は、アクセスポリシーのバージョンを自身の保持するアクセスポリシーのバージョン情報と比較するのではなく、他のゾーンＥＣＵのアクセスポリシーのバージョンと比較してもよいし、あらかじめ利用が想定されるアクセスポリシーのバージョン情報のリストをセントラルＥＣＵ１００が保持しており、当該リストに記載されている当該ゾーンＥＣＵのアクセスポリシーのバージョン情報との一致を確認してもよい。
　受信したアクセスポリシーのバージョン情報が、セントラルＥＣＵ１００自身の保持するアクセスポリシーのバージョン情報と異なると判断された場合（Ｓ６０２でＹｅｓ）、セントラルＥＣＵ１００は、当該ゾーンＥＣＵが想定と異なるアクセスポリシーを利用しているとして、当該ゾーンＥＣＵのアクセスポリシーのアップデートを実施して（Ｓ６０３）、処理を終了する。例えば、セントラルＥＣＵ１００は、自身が保持するアクセスポリシーを各ゾーンＥＣＵ２００ａ等（又はアクセスポリシーが異なるゾーンＥＣＵ）に送信してもよい。
　一方で、受信したアクセスポリシーのバージョン情報が、セントラルＥＣＵ１００自身の保持するアクセスポリシーのバージョン情報と同じであると判断された場合（Ｓ６０２でＮｏ）、セントラルＥＣＵ１００は、該当ゾーンＥＣＵが不正な挙動を示しているとして、次回以降の当該ゾーンＥＣＵによる検証結果（ポリシー検証結果）を無視する（または、重みを下げる）ようにして（Ｓ６０４）、処理を終了する。無視するとは、該当ゾーンＥＣＵからのポリシー検証結果を受信しても、それに対する処理を行わないことであってもよい。無視するとは、例えば、当該ポリシー検証結果を受信しても、マスターポリシー検証結果の決定に当該ポリシー検証結果を用いないことであってもよい。
　異なる検証結果を返答するゾーンＥＣＵが存在しないと判断された場合（Ｓ６００でＮｏ）、セントラルＥＣＵ１００は、処理を終了する。
　なお、不正な挙動を示すゾーンＥＣＵが存在した場合に、セントラルＥＣＵ１００は、外部のサーバに不正な挙動を示すゾーンＥＣＵが存在することを通知してもよいし、異常をログとして残してもよい。
　［その他の変形例］
　続いて、本実施の形態に係る車載ネットワークシステムで用いられる上記以外の変形例、および、不正なゾーンＥＣＵが存在するときの分析のために用いられる画像の具体例などについて説明する。
　［変形例１］
　図１４は、本変形例に係る車載ネットワークシステムの全体構成を示す図である。図１４では、図１に示される同じ構成については同じ符号を付している。
　車両２０に搭載される車載ネットワークシステムは、セントラルＥＣＵ１０００と、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄと、カメラＥＣＵ３００ａと、充電器ＥＣＵ３００ｂと、ブレーキＥＣＵ３００ｃと、モータＥＣＵ３００ｄと、を備える。
　以下、セントラルＥＣＵ１０００、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄについて説明する。
　図１５は、本変形例に係るセントラルＥＣＵ１０００の機能構成を示すブロック図である。実施の形態の図２のセントラルＥＣＵ１００に対して、車両状態保持部１１０９に記憶される情報が異なり、マスターポリシー判断部１１０６は、マスターポリシー判断部１０６に対して、機能が追加されている。車両状態保持部１１０９に記憶される情報については、図１７で詳細を後述する。
　図１６は、本変形例に係るゾーンＥＣＵ２０００ａの機能構成を示すブロック図である。実施の形態の図３のゾーンＥＣＵ２００ａから、インテグリティ検証部２０６と、車載ネットワーク侵入検知部２０７とが、構成要素として追加されている。
　インテグリティ検証部２０６は、ゾーンＥＣＵ２０００ａの機能構成が改ざんされていないことを検証する。具体的には、インテグリティ検証部２０６は、ゾーンＥＣＵ２０００ａを構成するソフトウェアまたはデータから算出されるハッシュ値と、あらかじめ保持されているハッシュ値とを比較することで、ゾーンＥＣＵ２０００ａのソフトウェアまたはデータが改ざんされていないことを検証する。インテグリティ検証部２０６は、ゾーンＥＣＵ２０００ａが起動中に定期的または不定期的に、ゾーンＥＣＵ２０００ａのソフトウェアまたはデータのインテグリティの検証（インテグリティ検証）を行う。インテグリティ検証結果は、車載ネットワーク通信部２０１を介して、セントラルＥＣＵ１０００へ通知される。
　車載ネットワーク侵入検知部２０７は、ゾーンＥＣＵ２０００ａが受信した車載ネットワーク通信を監視し、異常な通信が発生していないかを検知する。具体的には、車載ネットワーク侵入検知部２０７は、想定していない送信元または送信先へのメッセージを受信する、通常より高い頻度でメッセージを受信している、ポートスキャン通信、不正なタイミングでの診断通信、などを異常な通信として検知する。
　車載ネットワーク侵入検知部２０７は、異常な通信を検知した場合に、セントラルＥＣＵ１０００に、異常の発生を通知する。
　なお、ゾーンＥＣＵ２０００ｂ、２０００ｃ、２０００ｄも同様に、インテグリティ検証部２０６と車載ネットワーク侵入検知部２０７と、を備えていてもよいし、いずれか一方のみを備えていてもよい。また、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄのうち少なくとも１つが、インテグリティ検証部２０６および車載ネットワーク侵入検知部２０７の少なくとも１つを備えていればよい。
　図１７は、本変形例に係るセントラルＥＣＵ１０００の車両状態保持部１１０９に保持される車両状態の一例を示す図である。
　図１７は、図６の車両状態で保持される情報に加えて、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄから通知される、インテグリティ検証結果・時刻および、車載ネットワーク侵入検知結果（侵入検知システムの結果）が保持されている。車載ネットワーク侵入検知結果は、車載ネットワーク侵入検知システムの検知結果である。
　インテグリティ検証結果は、ゾーンＥＣＵごとに、時刻と併せて保持されている。図１７では、ゾーンＥＣＵ２０００ａのインテグリティ検証結果はＯＫで、ソフトウェアまたはデータの改ざんがされていないことを示しており、最終検証時刻は１３時５分であることを示している。ゾーンＥＣＵ２０００ｂのインテグリティ検証結果はＯＫで、ソフトウェアまたはデータの改ざんがされていないことを示しており、最終検証時刻は１３時５分であることを示している。ゾーンＥＣＵ２０００ｃのインテグリティ検証結果はＯＫで、ソフトウェアまたはデータの改ざんがされていないことを示しており、最終検証時刻は１３時１０分であることを示している。ゾーンＥＣＵ２０００ｄのインテグリティ検証結果は、ＯＫで、ソフトウェアまたはデータの改ざんがされていないことを示しており、最終検証時刻は１２時３０分であることを示している。
　また車載ネットワーク侵入検知システムの結果についてもゾーンＥＣＵごとに、結果が保持されている。ゾーンＥＣＵ２０００ａの車載ネットワークシステムの侵入検知結果はＯＫ、つまり異常が検知されていないことを示している。ゾーンＥＣＵ２０００ｂの車載ネットワークシステムの侵入検知結果はＯＫ、つまり異常が検知されていないことを示している。ゾーンＥＣＵ２０００ｃの車載ネットワークシステムの侵入検知結果はＯＫ、つまり異常が検知されていないことを示している。ゾーンＥＣＵ２０００ｄの車載ネットワークシステムの侵入検知結果はＯＫ、つまり異常が検知されていないことを示している。
　図１８は、本変形例に係るセントラルＥＣＵ１０００のマスターポリシー判断部１１０６における図１０のフローチャートにおけるステップＳ３０７およびステップＳ３１１で用いられる閾値を決定する処理を示すフローチャートである。
　なお、閾値の決定タイミングは特に限定されず、例えば、閾値の参照タイミングで都度計算されてもよいし（つまりステップＳ３０７またはステップＳ３１１の直前で、本処理が実行されてもよいし）、あらかじめ閾値を決定する処理を実施してもよい。
　セントラルＥＣＵ１０００は、アクセスポリシーを検証する対象のサービスの重要特性が機密性であるか否かを判断する（Ｓ７００）。
　アクセスポリシーを検証する対象のサービスの重要特性が機密性であると判断された場合（Ｓ７００でＹｅｓ）、セントラルＥＣＵ１０００は、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄから受信するポリシー検証結果ＯＫである受信数の閾値Ｎを、「車載ネットワークシステムに配置されるゾーンＥＣＵの数－１」、本変形例においては４－１＝３、に設定する（Ｓ７０１）。セントラルＥＣＵ１０００は、重要特性が機密性であるサービス（第２サービス）に対してアクセスを拒否する閾値Ｎの数値を所定値より低く設定する。ここでの所定値は、例えば、ゾーンＥＣＵの数から所定数を減算した数値であるがこれに限定されない。ステップＳ７０１で設定される閾値Ｎは、図１０のステップＳ３０７で用いられる閾値である。
　一方で、アクセスポリシーを検証する対象のサービスの重要特性が機密性でないと判断された場合（Ｓ７００でＮｏ）、セントラルＥＣＵ１０００は、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄから受信するポリシー検証結果ＯＫである受信数の閾値Ｎを「車載ネットワークシステムに配置されるゾーンＥＣＵの数－２」、本変形例においては４－２＝２、に設定する（Ｓ７０２）。セントラルＥＣＵ１０００は、重要特性が機密性ではない（例えば、可用性である）サービス（第１サービス）に対してアクセスを拒否する閾値Ｎの数値を所定値より高く設定する。ここでの所定値は、例えば、ゾーンＥＣＵの数から所定数を減算した数値であるがこれに限定されない。ステップＳ７０２で設定される閾値Ｎは、図１０のステップＳ３１１で用いられる閾値である。
　なお、ステップＳ７０１およびＳ７０２で設定される閾値Ｎは、図１８に示す値に限定されない。ステップＳ７０１で設定される閾値Ｎは、ステップＳ７０２で設定される閾値Ｎより相対的に高い値に設定されればよい。
　次にセントラルＥＣＵ１０００は、車両状態を確認し、ゾーンＥＣＵ２０００ａ、２０００ｂ、２０００ｃ、２０００ｄのインテグリティ検証結果を確認し、直近５分以内にインテグリティ検証がＯＫであったゾーンＥＣＵが存在するか否かを判断する（Ｓ７０３）。なお、５分は例示であり、これに限定されない。
　直近５分以内にインテグリティ検証がＯＫであったゾーンＥＣＵが存在すると判断された場合（Ｓ７０３でＹｅｓ）、セントラルＥＣＵ１０００は、該当するゾーンＥＣＵから受信するポリシー検証結果（アクセスＯＫ／ＮＧ）の重みを２（例えば、１から２）に設定（変更）する（Ｓ７０４）。ステップＳ７０３でＹｅｓと判断されたゾーンＥＣＵのポリシー判断結果はステップＳ７０３でＮｏと判断されたゾーンＥＣＵのポリシー判断結果より信用できるので、重みが上げられる。このように、通常時の１つのゾーンＥＣＵの重みを１とし、インテグリティ検証がＯＫであったゾーンＥＣＵから受信したポリシー検証結果ＯＫのゾーンＥＣＵの重みを２に設定することで、インテグリティ検証がＯＫであったゾーンＥＣＵからのポリシー検証結果ＯＫの受信を２つのポリシー検証結果ＯＫの受信があったものと同一と見なすように、マスターポリシー判断部１１０６においてポリシー検証結果ＯＫの受信数がカウントされる。
　なお、重みは１から２に上げられることに限定されず、１より大きな値であればよい。
　直近５分以内にインテグリティ検証がＯＫであったゾーンＥＣＵが存在しないと判断された場合（Ｓ７０３でＮｏ）、セントラルＥＣＵ１０００は、特になにもしない。なお、ステップＳ７０３でＮｏである場合、セントラルＥＣＵ１０００は、当該ゾーンＥＣＵの重みを下げてもよい。
　このように、セントラルＥＣＵ１０００は、ゾーンＥＣＵから受信するインテグリティ検証の結果に基づいて、当該ゾーンＥＣＵから受信するポリシー検証結果の重みを増減させてもよい。
　次にセントラルＥＣＵ１０００は、車両状態を確認し、車載ネットワーク侵入検知システムで異常を検知したゾーンＥＣＵが存在するか否かを判断する（Ｓ７０５）。
　車載ネットワーク侵入検知システムで異常を検知したゾーンＥＣＵが存在すると判断された場合（Ｓ７０５でＹｅｓ）、セントラルＥＣＵ１０００は、該当するゾーンＥＣＵによるポリシー検証結果の重みを０（ゼロ）に設定して、現状の閾値Ｎから１を引き（Ｓ７０６）、処理を終了する。現状の閾値Ｎから１を引くことで、重みが０であるゾーンＥＣＵが存在する場合に応じた閾値を設定することができる。
　なお、セントラルＥＣＵ１０００は、ステップＳ７０５でＹｅｓの場合、ポリシー検証結果の重みを０に設定することに限定されず、重みを現時点の値より下げればよい。
　なお、ステップＳ７０６では、少なくともポリシー検証結果の重みを下げることが実行されればよい。
　一方、車載ネットワーク侵入検知システムで異常を検知したゾーンＥＣＵが存在しないと判断された場合（Ｓ７０５でＮｏ）、セントラルＥＣＵ１０００は、処理を終了する。なお、ステップＳ７０５でＮｏである場合、セントラルＥＣＵ１０００は、当該ゾーンＥＣＵの重みを上げてもよい。
　このように、セントラルＥＣＵ１０００は、ゾーンＥＣＵから異常な通信が検知されたことを受信すると、当該ゾーンＥＣＵから受信するポリシー検証結果の重みを減少させてもよい。
　これにより、次にサービスＦｉｎｄメッセージを受信した場合、図１８に示す処理により更新された閾値、重みを使って図１０に示す処理等が実行される。
　なお、インテグリティ検証結果がＮＧであるゾーンＥＣＵが存在する場合に、当該ゾーンＥＣＵのポリシー検証結果の重みをゼロとしてもよい。
　また、車載ネットワーク侵入検知システムで異常を検知したゾーンＥＣＵのポリシー検証結果の重みをゼロとする例を示したが、この時の当該ゾーンＥＣＵのポリシー検証結果の重みをゼロとしなくてもよい。例えば、異常を検知したゾーンに存在するＥＣＵから送信されるメッセージに対して、閾値Ｎを上昇させるとしてもよい。これにより、異常が発生しているネットワークに存在するＥＣＵから送信される通信を、より慎重に判断することができ、車載ネットワークの安全性を高めることができる。
　［変形例２］
　図１９は、本変形例に係るセントラルＥＣＵ１００のマスターポリシー判断部１０６がゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのポリシー検証結果を収集したときに、他のゾーンＥＣＵと異なる検証結果を送信するゾーンＥＣＵが存在した場合の処理を示すフローチャート（情報処理方法、アクセス許可方法）である。
　なお、図１９は、図１３に示すフローチャートにステップＳ８００を追加し、ステップＳ６０４をステップＳ８０１に置き換えたフローチャートを示す。
　まず、セントラルＥＣＵ１００は、各ゾーンＥＣＵ２００ａ等からポリシー検証結果を取得する（Ｓ８００）。ステップＳ８００は、例えば、図１０に示すステップＳ３０６またはＳ３１０に相当する。
　受信したアクセスポリシーのバージョン情報が、セントラルＥＣＵ１００自身の保持するアクセスポリシーのバージョン情報と同じであると判断された場合（Ｓ６０２でＮｏ）、セントラルＥＣＵ１００は、ポリシー検証結果に不整合が発生したことを外部のサーバに送信する（Ｓ８０１）。ポリシー検証結果に不整合が発生したことを示す情報は、マスターポリシー検証結果に関する検証情報の一例である。また、ポリシー検証結果に不整合が発生したことを外部のサーバに送信することは、検証情報を出力することの一例である。
　なお、ステップＳ６０２でＹｅｓと判断された場合、セントラルＥＣＵ１００は、ポリシー検証結果、および、アクセスポリシーのバージョン情報の少なくとも一方を、マスターポリシー検証結果に関する検証情報として、外部のサーバに送信してもよい。アクセスポリシーのバージョン情報は、所定のアクセスポリシーを識別する情報の一例である。
　これにより、外部のサーバに接続された表示装置に、検証情報を表示させることができる。例えば、車載ネットワークシステムを監視する監視者に、検証情報を表示することができる。
　図２０は、セントラルＥＣＵ１００が、ポリシー検証結果が異なるゾーンＥＣＵが存在した場合に、外部のサーバにその状況を通知し、外部のサーバ側で状況を判断する時の分析画面の一例を示した図である。図２０では、表示された検証情報の一例を示す。
　図２０では、ポリシー検証結果に不整合が生じたときのサービス要求を行ったＥＣＵのＩＰアドレス情報と、どのサービス（図２０の例では、ブレーキ制御機能）に対してアクセスを試みたのかの結果とが示されている。さらに、セントラルＥＣＵ１００と、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄのそれぞれとに対して、検証結果（ポリシー検証結果）と、ソフトウェアのバージョン（ＳＷバージョン）と、アクセスポリシーのバージョン（ポリシーバージョン）とが一覧できるような画面が表示されてもよい。図２０では、全てのＥＣＵが同様のポリシーバージョンを利用しているものの、ゾーンＥＣＵ２００ｂのみが、検証結果ＮＧを返答しており、ポリシー検証結果に不整合が生じたことがわかる。
　［効果など］
　以下、本開示内容から得られる技術を例示し、当該技術から得られる効果等について説明する。
　（技術１）制御ネットワークシステムにおける情報処理装置が実行する情報処理方法であって、前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、前記情報処理方法は、前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得し、前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する、情報処理方法である。
　上記実施の形態では、アクセス許可装置はセントラルＥＣＵ１００であり、エッジアクセス許可装置は、ゾーンＥＣＵ２００ａ、２００ｂ、２００ｃ、２００ｄである。
　従来、この種のアクセス許可装置では、単一のアクセスポリシーの検証ポイントにおいて、アクセス許可の可否が判断されていたが、攻撃者によりアクセスポリシーの改ざんやプログラムの改ざんがされることで、アクセスポリシーの検証を回避されてしまう可能性がある。そこで本開示の一態様に係るアクセス許可装置は、分散されたアクセスポリシーを複数の検証ポイントで検証することで、最終的なアクセス可否の判断を行う。これにより信頼性の高いアクセス可否の判断を行うことができ制御ネットワークシステムを安全に保てる。つまり、アクセス許可装置によれば、制御ネットワークシステムが搭載される対象物（例えば、車両）にアクセス許可装置が適用された場合、当該対象物の安全性を保ちつつ、セキュアな制御ネットワークシステムを実現することができる。
　（技術２）前記検証情報を表示装置に出力することで、前記検証情報を表示装置に表示させる、技術１に記載の情報処理方法である。
　これによれば、検証情報を表示装置に表示させることで、マスターポリシー検証結果を制御ネットワークシステムの管理者に知らせることができる。
　（技術３）前記検証情報は、前記複数のエッジアクセス許可装置それぞれが有する前記所定のアクセスポリシーを識別する情報、および、前記複数のエッジアクセス許可装置それぞれの前記ポリシー検証結果を含む、技術２に記載の情報処理方法である。
　これによれば、エッジアクセス許可装置に異常が発生しているかなどを、所定のアクセスポリシーを識別する情報、および、ポリシー検証結果を用いて、制御ネットワークシステムの管理者がこのことを知らせることができる。
　（技術４）前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に不整合が発生した場合、前記表示装置に前記検証情報を表示させる、技術３に記載の情報処理方法である。
　これによれば、ポリシー検証結果に不整合が発生した場合に制御ネットワークシステムの管理者にそのことを知らせることができる。
　（技術５）前記アクセスは、前記複数の電子制御装置のうちの一の電子制御装置から他の一の電子制御装置のサービスへのアクセスを含み、前記情報処理方法は、前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果のうち、アクセス拒否であることを含むポリシー検証結果の数が閾値以上ある場合、アクセス拒否であることを示す前記マスターポリシー検証結果を、前記複数のエッジアクセス許可装置のうち、前記一の電子制御装置に接続されたエッジアクセス許可装置と、前記他の一の電子制御装置に接続されたエッジアクセス許可装置とに送信する、技術１～４のいずれかに記載の情報処理方法である。なお、アクセス拒否閾値とは、アクセス否を示すポリシー検証結果を受信した回数に対する閾値である。
　サービスは例えばＳＯＭＥ／ＩＰ通信を介して、電子制御装置がアクセスできる。電子制御装置が、許可されていないサービスを要求するメッセージを送信した場合に、複数のゾーンＥＣＵ２００ａ等でアクセスポリシーが検証され、結果としてアクセス拒否となる検証結果が閾値以上となり、当該メッセージは破棄され、サービスへのアクセスが拒否される。
　これによれば、複数のアクセスポリシーの検証結果に基づいて判断された最終的な判断結果に基づいてゾーンＥＣＵで、サービスへのアクセス制御を実現することができ、制御ネットワークシステムを安全に保つことができる。
　（技術６）アクセス拒否であることを含むポリシー検証結果の数が閾値以上ある場合、前記複数のエッジアクセス許可装置のそれぞれに前記マスターポリシー検証結果を送信する、技術５に記載の情報処理方法である。
　これによれば、複数のエッジアクセス許可装置のそれぞれにマスターポリシー検証結果が送信されるので、動作がおかしいゾーンＥＣＵがある場合にその情報を供給することができる。
　（技術７）前記アクセスポリシーは、前記複数の電子制御装置のうち前記サービスへのアクセスを許可された電子制御装置、および、前記複数の電子制御装置のうち前記サービスの提供を許可された電子制御装置のいずれか、または両方に関する情報を含む、技術１～４のいずれかに記載の情報処理方法である。
　これによれば、サービスへのアクセスを許可された電子制御装置、および、サービスの提供を許可された電子制御装置の少なくとも一方を含むアクセスポリシーを用いることで、アクセスを許可するか否かが判断可能である。
　（技術８）前記サービスは、可用性が求められる第１サービスを含み、前記情報処理方法は、前記第１サービスに対して前記アクセスを拒否する前記閾値の数値を所定値により高くする、技術５又は６に記載の情報処理方法である。
　これによれば、データ通信の可用性が求められるサービスについて、誤ったアクセス拒否による可用性の侵害の影響を抑えることができ、セキュリティを保ちつつ、ネットワークシステムの可用性を確保することができる。
　（技術９）前記第１サービスは、センサデータを授受することを含む、技術８に記載の情報処理方法である。
　これによれば、第１サービスがセンサデータを授受することを含む場合に、セキュリティを保ちつつ、ネットワークシステムの可用性を確保することができる。
　（技術１０）前記サービスは、機密性が求められる第２サービスを含み、前記情報処理方法は、前記第２サービスに対して前記アクセスを拒否する前記閾値の数値を所定値より低くする、技術５～９のいずれかに記載の情報処理方法である。
　これによれば、データの開示先を厳密に管理する必要性のあるサービスについて、慎重なアクセス可否の判断を行うことができ、セキュリティを保つことができる。
　（技術１１）前記第２サービスは、個人情報または機密情報に関するデータを授受することを含む、技術１０に記載の情報処理方法である。
　これによれば、第２サービスがデータを授受することを含む場合に、制御ネットワークシステムのセキュリティを保つことができる。
　（技術１２）前記サービスは、安全性が求められる第３サービスを含み、前記情報処理方法は、前記第３サービスに対して、前記マスターポリシー検証結果が出力される前に、前記複数のエッジアクセス許可装置のそれぞれが個別に、当該エッジアクセス許可装置の前記ポリシー検証結果に基づいて、前記サービスに対するアクセス可否を判断することを許可する、技術１～１１のいずれかに記載の情報処理方法である。
　これによれば、リアルタイム制御が求められるサービスについては、分散したアクセスポリシーの検証結果を待機することで発生する処理遅延を最小限に抑えたアクセス許可が可能となり、ネットワークシステムのセキュリティとリアルタイム性とを維持することが可能となる。
　（技術１３）前記第３サービスは、アクチュエータの制御に関することを含む、技術１２に記載の情報処理方法である。
　これによれば、第３サービスがアクチュエータの制御に関することである場合に、ネットワークシステムのセキュリティとリアルタイム性とを維持することが可能となる。
　（技術１４）前記制御ネットワークシステムは、車両に搭載される車載ネットワークシステムであり、前記情報処理方法は、前記車両の車両状態と前記サービスとに応じて、前記アクセスを拒否する前記閾値の数値を増減させる、技術５に記載の情報処理方法である。
　これによれば、車両の走行状態に応じて、優先される特性が変化するサービスに対して、適切にアクセス可否の判断方法を変化させることが可能となり、ネットワークシステムのセキュリティを向上させることができる。
　（技術１５）前記車両状態は、走行状態、充電状態、アップデート状態、診断モード状態、および、自動運転モードのいずれか１つ以上を含む、技術１４に記載の情報処理方法である。
　これによれば、走行状態、充電状態、アップデート状態、診断モード状態、および、自動運転モードのいずれか１つに応じた閾値を設定することができる。
　（技術１６）前記複数のエッジアクセス許可装置のうち少なくとも１つのエッジアクセス許可装置は、自身のソフトウェアまたはデータが改ざんされていないことを検証するインテグリティ検証を実行可能に構成され、前記情報処理方法は、前記少なくとも１つのエッジアクセス許可装置から受信する前記インテグリティ検証の結果に基づいて、前記少なくとも１つのエッジアクセス許可装置から受信する前記ポリシー検証結果の重みを増減させる、技術１～１５のいずれかに記載の情報処理方法である。
　これによれば、安全性が検証されたエッジアクセス許可装置によるアクセスポリシー検証結果を重みづけて評価することで、効率的にアクセス可否の判断を行うことができる。
　（技術１７）前記複数のエッジアクセス許可装置のうち少なくとも１つのエッジアクセス許可装置は、異常な通信を検知可能に構成され、前記情報処理方法は、前記少なくとも１つのエッジアクセス許可装置から前記異常な通信が検知されたことを受信すると、前記少なくとも１つのエッジアクセス許可装置から受信する前記ポリシー検証結果の重みを減少させる、技術１～１６のいずれかに記載の情報処理方法である。
　これによれば、異常な通信が検知された場合、エッジアクセス許可装置から受信するポリシー検証結果の重みを減少させることで、効率的にアクセス可否の判断を行うことができる。
　（技術１８）前記複数のエッジアクセス許可装置のうち他のエッジアクセス許可装置と異なる前記ポリシー検証結果を送信するエッジアクセス許可装置が存在する場合に、当該エッジアクセス許可装置が保持する前記アクセスポリシーに関する情報の送信を要求する、技術１～１７のいずれかに記載の情報処理方法である。
　これによれば、本来ポリシー検証結果は、全てのエッジアクセス許可装置で同一となることが期待されているため、期待と異なる動作をしているエッジアクセス許可装置を検出し、さらにその原因を調査することが可能となり、ネットワークシステムのセキュリティを向上できる。
　（技術１９）制御ネットワークシステムにおける情報処理装置であって、前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、前記情報処理装置は、前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得する取得部と、前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する出力部とを備える。
　このような情報処理装置によれば、本開示の一態様に係る情報処理方法と同様の効果を奏する。
　（技術２０）技術１～１８のいずれかに記載の情報処理方法をコンピュータに実行させるための、プログラムである。
　このようなプログラムによれば、本開示の一態様に係る情報処理方法と同様の効果を奏する。
　なお、本開示の全般的又は具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭなどの非一時的な記録媒体で実現されてもよい。また、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　（その他の実施の形態）
　以上、本開示について実施の形態に基づいて説明したが、本開示は、上記実施の形態に限定されるものではない。
　例えば、本開示の制御ネットワークシステムは、車載ネットワークシステムであることに限定されず、その他のモビリティネットワークシステム、および／または、制御ネットワークシステムを含んでもよい。また、このようなシステムで行われる通信の通信規格は、特に限定されない。また、車載通信ネットワークシステムのアーキテクチャは、図１に示す例に限定されるものではない。
　また、制御ネットワークシステムが搭載される対象物は、車両などの移動体であることに限定されず、例えば、施設などの非移動体であってもよい。施設は、例えば、制御ネットワークシステムの一例である宅内ネットワークシステムが設けられる対象物である。施設は、例えば、住宅、病院、ビル、介護施設、学校などであってもよい。
　また、ゾーンＥＣＵにポリシー判断部およびポリシー実施部が備えられる例を示したが、ゾーンＥＣＵ以外にポリシー判断部およびポリシー実施部が備えられていてもよい。例えばＥＣＵ、ネットワークスイッチ、ネットワークゲートウェイにポリシー判断部およびポリシー実施部が備えられていてもよい。また、マスターポリシー判断部はセントラルＥＣＵに備えられていなくてもよい。例えば通常のアプリケーションとはセキュリティレベルの異なる実行環境を備えるＥＣＵ上にマスターポリシー判断部が備えられていてもよい。
　また、上記実施の形態におけるカメラ情報サービス探索メッセージなどのポリシー検証対象メッセージがブロードキャストされないなど、受信できないアクセスポリシー保持部とポリシー判断部とを保持するＥＣＵが存在する場合は、当該ＥＣＵに対してポリシーの検証を依頼するように対象メッセージを転送してもよい。
　また、上記実施の形態におけるカメラ情報サービスなどの探索メッセージを受信したゾーンＥＣＵのそれぞれがアクセスポリシーの検証を行う例について説明したがこれに限定されず、探索メッセージを受信した複数のゾーンＥＣＵのうち少なくとも２つ以上のゾーンＥＣＵがアクセスポリシーの検証を行えばよい。
　また、本開示は、対象物に搭載されたアクセス許可装置であって、前記対象物は、前記アクセス許可装置が設けられるＥＣＵと、前記ＥＣＵにより統括され、前記対象物に搭載された機器を制御する１以上のゾーンＥＣＵ（例えば、複数のゾーンＥＣＵ２００ａ等）とを有し、前記アクセス許可装置は、前記対象物における任意の送信元（又は提供元）から前記対象物における任意の送信先（又は提供先）へのアクセス要求（例えば、サービスへのアクセス要求）があった場合、前記１以上のゾーンＥＣＵそれぞれにおいて、所定のアクセスポリシーに基づいて判断された前記アクセス要求に対するアクセス可否の判断結果であるポリシー検証結果を取得する取得部（例えば、センター通信部）と、前記１以上のゾーンＥＣＵそれぞれから取得された前記ポリシー検証結果に基づいて、前記アクセス要求に対する最終的なアクセスの可否を判断するマスターポリシー判断部とを備える、アクセス許可装置として実現されてもよい。
　また、本開示は、対象物に搭載されたアクセス許可装置が実行するアクセス許可方法であって、前記対象物は、前記アクセス許可装置が設けられるＥＣＵと、前記ＥＣＵにより統括され、前記対象物に搭載された機器を制御する１以上のゾーンＥＣＵ（例えば、複数のゾーンＥＣＵ２００ａ等）とを有し、前記アクセス許可方法は、前記対象物における任意の送信元（又は提供元）から前記車両における任意の送信先（又は提供先）へのアクセス要求（例えば、サービスへのアクセス要求）があった場合、前記１以上のゾーンＥＣＵそれぞれにおいて、所定のアクセスポリシーに基づいて判断された前記アクセス要求に対するアクセス可否の判断結果であるポリシー検証結果を取得する取得し、前記１以上のゾーンＥＣＵそれぞれから取得された前記ポリシー検証結果に基づいて、前記アクセス要求に対する最終的なアクセスの可否を判断する、アクセス許可方法として実現されてもよい。
　また、上記実施の形態では、制御ネットワークシステムが搭載される対象物が車両等の移動体である例について説明したが、これに限定されず、移動しない据え置き型の対象物に搭載されてもよい。
　また、上記実施の形態における各装置間の通信方法および通信規格については特に限定されるものではない。装置間では、無線通信が行われてもよいし、有線通信が行われてもよい。また、装置間では、無線通信および有線通信が組み合わされてもよい。
　また、例えば、上記で用いた数字は、全て本開示を具体的に説明するために例示するものであり、本開示の実施の形態は例示された数字に制限されない。
　また、例えば、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェアまたはソフトウェアが並列または時分割に処理してもよい。
　また、例えば、フローチャートにおける各ステップが実行される順序は、本開示を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。
　また、例えば、上記実施の形態で説明された各装置が備える構成要素は、本開示の趣旨を逸脱しない範囲で複数の装置にどのように振り分けられてもよい。
　また、上記実施の形態において、特定の処理部が実行する処理を別の処理部が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。
　また、上記実施の形態において、各構成要素（各処理部）は、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）またはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
　また、各構成要素は、ハードウェアによって実現されてもよい。各構成要素は、回路（または集積回路）でもよい。これらの回路は、全体として１つの回路を構成してもよいし、それぞれ別々の回路でもよい。また、これらの回路は、それぞれ、汎用的な回路でもよいし、専用の回路でもよい。
　また、本開示の全般的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの非一時的な記録媒体で実現されてもよい。また、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　その他、各実施の形態に対して当業者が思いつく各種変形を施して得られる形態、または、本開示の趣旨を逸脱しない範囲で各実施の形態における構成要素および機能を任意に組み合わせることで実現される形態も本開示に含まれる。
　本開示は、車両を制御する制御装置に利用可能である。
　１０、２０　車両
　１００、１０００　セントラルＥＣＵ（情報処理装置、アクセス許可装置）
　１０１　センター通信部（取得部、出力部）
　１０２　車両制御アプリ部
　１０３　ドライバアプリ部
　１０４　自動運転アプリ部
　１０５、２０１　車載ネットワーク通信部（出力部）
　１０６、１１０６　マスターポリシー判断部
　１０７、２０３　ポリシー実施部
　１０８、２０４　アクセスポリシー保持部
　１０９、２０５、１１０９　車両状態保持部
　１１０　ユーザ情報保持部
　２００ａ、２００ｂ、２００ｃ、２００ｄ、２０００ａ、２０００ｂ、２０００ｃ、２０００ｄ　ゾーンＥＣＵ（エッジアクセス許可装置）
　２０２　ポリシー判断部
　２０６　インテグリティ検証部
　２０７　車載ネットワーク侵入検知部
　３００ａ　カメラＥＣＵ
　３００ｂ　充電器ＥＣＵ
　３００ｃ　ブレーキＥＣＵ
　３００ｄ　モータＥＣＵ
　３０１　アプリ部
　３０２　通信部

Claims (20)

  1. 　制御ネットワークシステムにおける情報処理装置が実行する情報処理方法であって、
    　前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、
    　前記情報処理方法は、
    　前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得し、
    　前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する、
    　情報処理方法。
  2. 　前記検証情報を表示装置に出力することで、前記検証情報を表示装置に表示させる、
    　請求項１に記載の情報処理方法。
  3. 　前記検証情報は、前記複数のエッジアクセス許可装置それぞれが有する前記所定のアクセスポリシーを識別する情報、および、前記複数のエッジアクセス許可装置それぞれの前記ポリシー検証結果を含む、
    　請求項２に記載の情報処理方法。
  4. 　前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に不整合が発生した場合、前記表示装置に前記検証情報を表示させる、
    　請求項３に記載の情報処理方法。
  5. 　前記アクセスは、前記複数の電子制御装置のうちの一の電子制御装置から他の一の電子制御装置のサービスへのアクセスを含み、
    　前記情報処理方法は、
    　前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果のうち、アクセス拒否であることを含むポリシー検証結果の数が閾値以上ある場合、アクセス拒否であることを示す前記マスターポリシー検証結果を、前記複数のエッジアクセス許可装置のうち、前記一の電子制御装置に接続されたエッジアクセス許可装置と、前記他の一の電子制御装置に接続されたエッジアクセス許可装置とに送信する、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  6. 　アクセス拒否であることを含むポリシー検証結果の数が閾値以上ある場合、前記複数のエッジアクセス許可装置のそれぞれに前記マスターポリシー検証結果を送信する、
    　請求項５に記載の情報処理方法。
  7. 　前記アクセスポリシーは、前記複数の電子制御装置のうち前記サービスへのアクセスを許可された電子制御装置、および、前記複数の電子制御装置のうち前記サービスの提供を許可された電子制御装置のいずれか、または両方に関する情報を含む、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  8. 　前記サービスは、可用性が求められる第１サービスを含み、
    　前記情報処理方法は、前記第１サービスに対して前記アクセスを拒否する前記閾値の数値を所定値により高くする、
    　請求項５に記載の情報処理方法。
  9. 　前記第１サービスは、センサデータを授受することを含む、
    　請求項８に記載の情報処理方法。
  10. 　前記サービスは、機密性が求められる第２サービスを含み、
    　前記情報処理方法は、前記第２サービスに対して前記アクセスを拒否する前記閾値の数値を所定値より低くする、
    　請求項５に記載の情報処理方法。
  11. 　前記第２サービスは、個人情報または機密情報に関するデータを授受することを含む、
    　請求項１０に記載の情報処理方法。
  12. 　前記サービスは、安全性が求められる第３サービスを含み、
    　前記情報処理方法は、前記第３サービスに対して、前記マスターポリシー検証結果が出力される前に、前記複数のエッジアクセス許可装置のそれぞれが個別に、当該エッジアクセス許可装置の前記ポリシー検証結果に基づいて、前記サービスに対するアクセス可否を判断することを許可する、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  13. 　前記第３サービスは、アクチュエータの制御に関することを含む、
    　請求項１２に記載の情報処理方法。
  14. 　前記制御ネットワークシステムは、車両に搭載される車載ネットワークシステムであり、
    　前記情報処理方法は、前記車両の車両状態と前記サービスとに応じて、前記アクセスを拒否する前記閾値の数値を増減させる、
    　請求項５に記載の情報処理方法。
  15. 　前記車両状態は、走行状態、充電状態、アップデート状態、診断モード状態、および、自動運転モードのいずれか１つ以上を含む、
    　請求項１４に記載の情報処理方法。
  16. 　前記複数のエッジアクセス許可装置のうち少なくとも１つのエッジアクセス許可装置は、自身のソフトウェアまたはデータが改ざんされていないことを検証するインテグリティ検証を実行可能に構成され、
    　前記情報処理方法は、前記少なくとも１つのエッジアクセス許可装置から受信する前記インテグリティ検証の結果に基づいて、前記少なくとも１つのエッジアクセス許可装置から受信する前記ポリシー検証結果の重みを増減させる、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  17. 　前記複数のエッジアクセス許可装置のうち少なくとも１つのエッジアクセス許可装置は、異常な通信を検知可能に構成され、
    　前記情報処理方法は、前記少なくとも１つのエッジアクセス許可装置から前記異常な通信が検知されたことを受信すると、前記少なくとも１つのエッジアクセス許可装置から受信する前記ポリシー検証結果の重みを減少させる、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  18. 　前記複数のエッジアクセス許可装置のうち他のエッジアクセス許可装置と異なる前記ポリシー検証結果を送信するエッジアクセス許可装置が存在する場合に、当該エッジアクセス許可装置が保持する前記アクセスポリシーに関する情報の送信を要求する、
    　請求項１～４のいずれか１項に記載の情報処理方法。
  19. 　制御ネットワークシステムにおける情報処理装置であって、
    　前記制御ネットワークシステムは、それぞれが所定の処理の実行を含むサービスを実行可能であり、互いにサービスに関するアクセスが可能な複数の電子制御装置と、それぞれが所定のアクセスポリシーに基づいて、前記アクセスの可否を判断する複数のエッジアクセス許可装置とを含み、
    　前記情報処理装置は、
    　前記複数のエッジアクセス許可装置のそれぞれから前記アクセスの可否の判断結果を含むポリシー検証結果を取得する取得部と、
    　前記複数のエッジアクセス許可装置それぞれからの前記ポリシー検証結果に基づいて、前記アクセスの可否の最終的な判断結果を含むマスターポリシー検証結果に関する検証情報を出力する出力部とを備える、
    　情報処理装置。
  20. 　請求項１～４のいずれか１項に記載の情報処理方法をコンピュータに実行させるための、プログラム。
PCT/JP2024/031795 2023-09-29 2024-09-05 情報処理方法、情報処理装置、および、プログラム Pending WO2025069973A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPPCT/JP2023/035708 2023-09-29
PCT/JP2023/035708 WO2025069401A1 (ja) 2023-09-29 2023-09-29 アクセス許可装置、アクセス許可方法、および、プログラム

Publications (1)

Publication Number Publication Date
WO2025069973A1 true WO2025069973A1 (ja) 2025-04-03

Family

ID=95202700

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2023/035708 Pending WO2025069401A1 (ja) 2023-09-29 2023-09-29 アクセス許可装置、アクセス許可方法、および、プログラム
PCT/JP2024/031795 Pending WO2025069973A1 (ja) 2023-09-29 2024-09-05 情報処理方法、情報処理装置、および、プログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/035708 Pending WO2025069401A1 (ja) 2023-09-29 2023-09-29 アクセス許可装置、アクセス許可方法、および、プログラム

Country Status (1)

Country Link
WO (2) WO2025069401A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009147734A1 (ja) * 2008-06-04 2009-12-10 株式会社ルネサステクノロジ 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2017135626A (ja) * 2016-01-29 2017-08-03 トヨタ自動車株式会社 電子制御装置の検証方法
JP2021167985A (ja) * 2018-07-06 2021-10-21 日立Astemo株式会社 車載セキュリティシステムおよび攻撃対処方法
WO2023136111A1 (ja) * 2022-01-14 2023-07-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置及び異常検知方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009147734A1 (ja) * 2008-06-04 2009-12-10 株式会社ルネサステクノロジ 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2017135626A (ja) * 2016-01-29 2017-08-03 トヨタ自動車株式会社 電子制御装置の検証方法
JP2021167985A (ja) * 2018-07-06 2021-10-21 日立Astemo株式会社 車載セキュリティシステムおよび攻撃対処方法
WO2023136111A1 (ja) * 2022-01-14 2023-07-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置及び異常検知方法

Also Published As

Publication number Publication date
WO2025069401A1 (ja) 2025-04-03

Similar Documents

Publication Publication Date Title
US8650620B2 (en) Methods and apparatus to control privileges of mobile device applications
US11792194B2 (en) Microsegmentation for serverless computing
JP4327630B2 (ja) インターネット・プロトコルを用いたストレージエリア・ネットワーク・システム、セキュリティ・システム、セキュリティ管理プログラム、ストレージ装置
CA2849763C (en) Managing mobile device applications
CN103959857B (zh) 管理无线网络中的移动设备应用
CA2849769C (en) Managing mobile device applications on a mobile device
CA2849757C (en) Managing mobile device applications on a mobile device
CN114553540B (zh) 基于零信任的物联网系统、数据访问方法、装置及介质
WO2017175154A1 (en) Automated security policy generation for controllers
EP3042487B1 (en) Secured mobile communications device
US11811817B2 (en) SSL proxy whitelisting
CN112311769A (zh) 安全认证的方法、系统、电子设备及介质
US20070294699A1 (en) Conditionally reserving resources in an operating system
WO2025069973A1 (ja) 情報処理方法、情報処理装置、および、プログラム
CN119696842B (zh) 一种关联控制方法及相关装置
WO2024127841A1 (ja) アクセス許可装置、および、アクセス許可方法
CN119945752A (zh) 服务访问控制方法、装置、电子设备及存储介质
HK40030628B (en) Managing mobile device applications in a wireless network
HK40030628A (en) Managing mobile device applications in a wireless network
Vieweg A Concept for a Trustworthy Integration of Smartphones in Business Environments

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24871772

Country of ref document: EP

Kind code of ref document: A1