Computer program, mobile object control device, and mobile object control method

Abstract

This computer program causes a computer controlling a mobile object to perform a process for determining, on the basis of characteristics regarding the security of resources of the mobile object, whether or not to permit an API call for manipulating the resources, said API call originating from the execution entity of an application program.

Description

Computer Program, Moving Object Control Apparatus, and Moving Object Control Method

[0001] The technology disclosed in the present specification relates to a computer program, apparatus and method for controlling a moving object.

[0002] Vehicles such as automobiles are equipped with a computer called, for example, an Electronic Control Unit (hereinafter referred to as "ECU"). Various resources of the vehicle (e.g., displays, windows, seats, etc.) are controlled by the ECU. A technology called OTA (Over The Air), which adds and updates computer programs operating on an ECU via wireless communication, is known (see, for example, Patent Document 1).

[0003] Japanese Unexamined Patent Application Publication No. 2025-025452

[0004] It is conceivable that vehicle manufacturers (OEMs) and third parties use the above-described OTA to provide application programs that operate vehicle resources. However, since vehicles are moving objects, if the execution subject of an application program can freely operate vehicle resources, there is a risk that the safety of the vehicle will decrease. Such a problem is not limited to vehicles, but is common to moving objects in general.

[0005] The present specification discloses a technology capable of solving the above-described problems.

[0006] The technology disclosed in the present specification can be implemented, for example, in the following forms.

[0007] (1) The computer programs disclosed herein cause a computer controlling a mobile body to execute a process that determines whether or not an API call for manipulating the resources of the mobile body can be made from the execution entity of an application program, based on the safety characteristics of the resources of the mobile body. The risk of a decrease in the safety of the mobile body caused by an API call for manipulating the resources of the mobile body by the execution entity of an application program may vary depending on the safety characteristics of the resource being called. With this computer program, since the determination of whether or not an API call can be made is based on the safety characteristics of the resource, it is possible to suppress a decrease in the safety of the mobile body caused by such calls without excessively restricting API calls by the execution entity of an application program.

[0008] (2) In the above computer program, the processing may be performed based on access control information that specifies whether or not the execution entity can make the call for each of the safety characteristics of the resource. With this configuration, by referring to the access control information, the determination of whether or not to make an API call can be performed efficiently and accurately.

[0009] (3) In the above computer program, the characteristics relating to the safety of the resource may include a safety class that classifies the safety of each type of resource into multiple classes. With this configuration, the determination of whether or not to call the API can be performed efficiently and accurately according to the safety class, without being affected by the differences in resources for each mobile device.

[0010] (4) In the above computer program, the moving object may be a vehicle. With this configuration, it is possible to suppress a decrease in the safety of the vehicle caused by API calls without excessively restricting API calls by the execution entity of the application program.

[0011] The technologies disclosed herein can be implemented in various forms, for example, in the form of mobile device control devices and methods, computer programs that implement such methods, and non-temporary recording media on which such computer programs are stored.

[0012] Diagram illustrating the configuration of the vehicle 10 in this embodiment Block diagram illustrating the functional configuration of the central ECU 100 Diagram illustrating an example of vehicle configuration information VC Diagram illustrating an example of safety class SC Diagram illustrating an example of access control information AC Diagram illustrating an example of access control information AC Diagram illustrating an example of vehicle state VS Flowchart illustrating access control processing Diagram illustrating an example of vehicle configuration information VC in another embodiment Diagram illustrating an example of vehicle configuration information VC in another embodiment Diagram illustrating an example of access control information AC in another embodiment Diagram illustrating an example of access control information AC in another embodiment Flowchart illustrating access control processing in another embodiment

[0013] (Embodiment) Figure 1 is an explanatory diagram showing the configuration of the vehicle 10 in this embodiment. The vehicle 10 is, for example, an automobile. The vehicle 10 is an example of a mobile body.

[0014] Vehicle 10 includes a central ECU 100, a sensor 150, a driver assistance ECU 160, a display ECU 170, a display 172, a window ECU 180, a window 182, a seat ECU 190, and a seat 192. Each ECU included in vehicle 10 is composed of a computer and is connected to each other via an in-vehicle network such as a CAN (Control Area Network).

[0015] The sensor 150 is a device for detecting the state of the vehicle 10 and the state of the surroundings of the vehicle 10, and includes, for example, at least one of a vehicle speed sensor, a yaw rate sensor, a GPS, a radar, a lidar, and a camera unit.

[0016] The driver assistance ECU 160 is a device for assisting the driving of the vehicle 10. Based on signals from the sensor 150, the driver assistance ECU 160 intervenes in the acceleration, deceleration, and steering of the vehicle 10, thereby assisting the driver of the vehicle 10 and reducing the driver's workload. In this embodiment, the driving states of the vehicle 10 provided by the driver assistance ECU 160 are classified into the following four categories: (1) Manual driving: A state in which the vehicle driver performs some form of motion control. The driver has an obligation to focus on safe driving. For example, this corresponds to Level 0, Level 1, and Level 2 of the Society of Automotive Engineers (SAE), where hands-off driving is not possible. (2) Hands-off: A state in which the vehicle's motion control is automated, but the driver must constantly monitor the surrounding situation and be prepared for situations that the system cannot handle. For example, this corresponds to Level 2 of the SAE, where hands-off driving is possible. (3) Eyes-off: A state in which the vehicle's motion control is fully automated, and the driver does not need to focus on driving operations. However, the driver must be seated in the driver's seat and have an obligation to respond promptly to requests for handover of operations from the system. For example, this corresponds to SAE Level 3. (4) Driverless (brain off): The vehicle's motion control is fully automated, and the vehicle can operate safely even without a driver. For example, this corresponds to SAE Levels 4-5.

[0017] The display 172, window 182, and seat 192 are resources (objects, hardware) of the vehicle 10. The display 172 includes, for example, a HUD (Head-up Display) that displays images in the driver's forward field of view, an instrument panel display located in the instrument panel, a center display located in the center console, and at least one of a rear-seat display mainly provided for rear-seat passengers. The display 172 is controlled by the display ECU 170. The window 182 includes, for example, a power window that opens and closes electrically. The window 182 is controlled by the window ECU 180. The seat 192 includes, for example, a power seat that adjusts its position and tilt electrically. The seat 192 is controlled by the seat ECU 190. The ECUs for controlling these resources may be shared with other ECUs.

[0018] The central ECU 100 is a computer for controlling the entire vehicle 10. Figure 2 is a block diagram showing the functional configuration of the central ECU 100. The central ECU 100 has a CPU 110, RAM 120, ROM 130, and a communication interface (I / F) 140. The central ECU 100 is an example of a mobile device control system.

[0019] The ROM 130 stores a vehicle OS (Operating System) 131, including an access control program 132, and one or more application programs 133 as computer programs. Figure 1 illustrates application program 133a (e.g., car navigation) and application program 133b (e.g., a game). These computer programs may be pre-stored in the ROM 130 before the vehicle 10 is shipped, or they may be additionally installed via the communication interface 140 after the vehicle 10 is shipped. These programs may also be updated via the communication interface 140 after the vehicle 10 is shipped.

[0020] The CPU 110 is the main execution unit for each computer program. The CPU 110 functions as a vehicle OS execution unit 131X, including an access control unit 132X, by reading the vehicle OS 131 onto the RAM 120 and executing it. The CPU 110 also functions as an application execution unit 133X by reading the application program 133 onto the RAM 120 and executing it. Figure 2 illustrates an application execution unit 133Xa that executes application program 133a, and an application execution unit 133Xb that executes application program 133b.

[0021] The vehicle OS execution unit 131X provides the application execution unit 133X with an API (Application Programming Interface) 134, which is an interface for operating various resources (for example, the display 172, windows 182, and seats 192) of the vehicle 10. When the application execution unit 133X operates on a resource, it calls the API 134 corresponding to the resource to be operated on. The access control unit 132X executes access control processing to determine whether or not the application execution unit 133X can call the API 134. Details of the access control processing will be described later.

[0022] The ROM 130 of the central ECU 100 stores vehicle configuration information VC. The vehicle configuration information VC is stored in the ROM 130 in advance before the vehicle 10 is shipped. Figure 3 is an explanatory diagram showing an example of vehicle configuration information VC. The vehicle configuration information VC is information that indicates the safety characteristics of the resources possessed by the vehicle 10. In this embodiment, the safety characteristics of the resources are identified by the safety class SC.

[0023] Figure 4 is an explanatory diagram showing an example of a safety class SC. A safety class SC classifies the safety of resource instances into multiple classes for each type of resource that the vehicle 10 may have. Safety classes SC are pre-set, for example, by an organization that defines the specifications of API 134 provided by the vehicle OS 131.

[0024] In the example shown in Figure 4, the safety class SCa of the display is classified into four levels: A1, A2, A3, and A4. Safety class SCa: A1 is a display in which the amount of eye movement required by the driver when viewing the display is virtually zero, such as a HUD. Safety class SCa: A2 is a display in which the amount of eye movement required by the driver when viewing the display is small, such as an instrument panel display. Safety class SCa: A3 is a display in which the amount of eye movement required by the driver when viewing the display is large, such as a center display. Safety class SCa: A4 is a display that cannot be seen by the driver sitting in the driver's seat, such as a rear-seat display.

[0025] Furthermore, the window safety class SCb is classified into two levels, B1 and B2, in descending order of safety. Safety class SCb: B1 is a window with an anti-pinch function. Safety class SCb: B2 is a window without an anti-pinch function.

[0026] Furthermore, the safety class SCc of seats is classified into two levels, C1 and C2, in descending order of safety. Safety class SCc: C1 means that there is no danger in moving the seat while the vehicle is in motion; for example, this applies to seats other than the driver's seat. Safety class SCc: C2 means that there is a risk in moving the seat while the vehicle is in motion; for example, this applies to the driver's seat.

[0027] The vehicle configuration information VC (Figure 3) shows what resources the vehicle 10 has and which safety class SC each resource belongs to. For example, the vehicle configuration information VC shown in Figure 3 specifies that the vehicle 10 has three types of displays (displays 1 to 3) as display 172, and that the safety classes SC of these displays are A1, A2, and A4, respectively. Similarly, the vehicle configuration information VC shown in Figure 3 specifies that the vehicle 10 has one type of window as window 182, and that the safety class SC of that window is B1. Furthermore, the vehicle configuration information VC shown in Figure 3 specifies that the vehicle 10 has two types of seats (seats 1 to 2) as seat 192, and that the safety classes SC of these seats are C2 and C1, respectively.

[0028] Access control information AC is stored in the ROM 130 (Figure 1) of the central ECU 100. Access control information AC is information that specifies whether or not the application execution unit 133X that executes the application program 133 can call API 134. For example, the organization that specifies the specifications of API 134 identifies in advance API 134 calls that may perform operations related to the safety of the vehicle 10. The provider of the application program 133 that uses the relevant API 134 calls declares the API 134 calls to be used and undergoes a safety review by a review body (for example, the vehicle manufacturer (OEM) or an organization commissioned by the vehicle manufacturer). The review body conducts a safety review, for example, to determine whether the application program 133 performs dangerous controls or causes driver destruction. Based on the review results, the review body creates access control information AC that specifies the API 134 calls that the application program 133 is permitted to use. Access control information AC is distributed together with the application program 133 with the review body's signature.

[0029] Figures 5 and 6 are explanatory diagrams illustrating an example of access control information AC. Figure 5 shows an example of access control information ACa set for one application program 133a (e.g., car navigation) targeting the display 172. Figure 6 shows an example of access control information ACb set for another application program 133b (e.g., a game) targeting the display 172. In Figures 5 and 6, "○" indicates that API calls are permitted, and "×" indicates that API calls are not permitted (restricted).

[0030] As shown in Figures 5 and 6, the access control information AC defines whether or not to call API 134 in association with a combination of vehicle state VS and safety class SC. Figure 7 is an explanatory diagram showing an example of vehicle state VS. Vehicle state VS includes, for example, driving state and running state. The driving state of vehicle 10 is classified into, for example, the four driving states described above (manual driving, hands off, eyes off, driverless). The running state of vehicle 10 is classified into, for example, the following four: (1) Driving state: The vehicle is moving (speed is not zero). (2) Stopped state: The vehicle is temporarily stopped in the middle of driving. (3) Parking state: The shift lever is in parking, or the parking brake is engaged. (4) Power off state: The power to the powertrain is turned off. This includes the so-called accessory (ACC) mode.

[0031] The vehicle state VS is classified into 16 different states (S11 to S44) in a 4x4 grid, based on the combination of driving state and moving state, as shown in Figure 7, for example. The moving state is an example of a moving state.

[0032] As shown in Figure 5, in the access control information ACa set for application program 133a (e.g., car navigation), calling API 134 is permitted in all vehicle states VS for displays 172 (e.g., HUD) with safety class SCa "A1". On the other hand, calling API 134 is restricted in some vehicle states VS for displays 172 with other safety class SCa. For example, for a display 172 (e.g., center display) with safety class SCa "A3", calling API 134 is restricted in two vehicle states VS: S14 (manual driving) and S24 (hands-off driving). Furthermore, for displays 172 with safety class SCa "A4" (for example, rear-seat displays), in addition to S14 and S24, the calling of API 134 is restricted in the vehicle state VS of S13 (manual driving - stopped), S23 (hands off - stopped), S33 (eyes off - stopped), and S34 (eyes off - driving).

[0033] Furthermore, as shown in Figure 6, in the access control information ACb set for the application program 133b (e.g., a game), the calling of API 134 is restricted in several vehicle state VSs for the display 172 (e.g., HUD) with safety class SCa "A1". Specifically, for the display 172 with safety class SCa "A1", the calling of API 134 is restricted in four vehicle state VSs: S13 (manual driving - stopped), S14 (manual driving - driving), S23 (hands-free - stopped), and S24 (hands-off - driving). In addition, for the display 172 with safety class SCa "A4", the calling of API 134 is restricted in vehicle state VSs S33 (eyes off - stopped) and S34 (eyes off - driving), in addition to S13, S14, S23, and S24.

[0034] Similarly, access control information AC is set for other resources of the vehicle 10. For example, with respect to window 182, access control information AC set for a certain application program 133 allows calling API 134 for windows with safety class SCb: B1 (windows with anti-pinch function) in a specific vehicle state VS, while restricting calling API 134 for windows with safety class SCb: B2 (windows without anti-pinch function). On the other hand, access control information AC set for an application program 133 that has anti-pinch measures implemented on the application side allows calling API 134 for both windows with safety class SCb B1 and B2 in a similar specific vehicle state VS.

[0035] Furthermore, with respect to seat 192, in the access control information AC set for a certain application program 133, in a specific vehicle state VS, calling API 134 is permitted for seats with safety class SCc:C1 (seats that do not pose a risk even if moved while the vehicle is moving), while calling API 134 is restricted for seats with safety class SCc:C2 (seats that may pose a risk if moved while the vehicle is moving). On the other hand, in the access control information AC set for an application program 133 in which, for example, measures to prevent hazards associated with seat movement are taken on the application side, calling API 134 is permitted for both seats with safety class SCc C1 and C2 in a similar specific vehicle state VS.

[0036] Furthermore, for resources that do not have a safety class SC, the access control information AC specifies whether or not the API can be called for each vehicle state VS. In addition, if, for example, information regarding the applicable safety class SC does not exist in the access control information AC due to an update in the API specifications, the call to that API may be restricted.

[0037] Thus, in this embodiment, access control information AC is provided for each resource to be operated on and for each application program 133, and the possibility of calling the API is defined in the access control information AC for each combination of vehicle state VS and safety class SC. For example, in order to mediate between multiple application programs 133, the access control information AC associated with each application program 133 may include information indicating the highest usable operation priority.

[0038] (Access control processing) Figure 8 is a flowchart of the access control processing. Access control processing is the process by which the application execution unit 133X determines whether or not to call the API 134 for manipulating the resources of the vehicle 10.

[0039] First, the access control unit 132X (Figure 2) of the central ECU 100 receives a call to the API 134 for manipulating the resources of the vehicle 10 from the application execution unit 133X, which is the execution unit of the application program 133 (S110).

[0040] The access control unit 132X identifies the current vehicle state VS based on signals from the sensor 150, etc. (S120).

[0041] The access control unit 132X determines whether or not to call API 134 based on the vehicle configuration information VC and the access control information AC associated with the target application program 133 (S130). More specifically, the access control unit 132X refers to the vehicle configuration information VC (Figure 3) to identify the safety class SC of the resource to be operated on. Then, the access control unit 132X refers to the access control information AC (Figures 5, 6) to determine whether or not to call API 134 based on the identified combination of vehicle state VS and safety class SC.

[0042] If the access control unit 132X determines that the call is permitted (S140: YES), the access control unit 132X permits the call of the API 134 by the application execution unit 133X (S150). Accordingly, the application execution unit 133X can operate the resources of the vehicle 10 by calling the API 134.

[0043] On the other hand, if the access control unit 132X determines that the call is not permitted (S140: NO), the access control unit 132X restricts the call of the API 134 by the application execution unit 133X (S160). For example, the access control unit 132X returns an error code indicating that calling the API 134 is not permitted to the application execution unit 133X. Accordingly, the application execution unit 133X cannot operate the resources of the vehicle 10.

[0044] (Effects of the present embodiment) As described above, the central ECU 100 is a control device that controls the vehicle 10. The central ECU 100 includes the access control unit 132X. Based on the state of the vehicle 10, the access control unit 132X determines whether to permit a call to the API 134 for operating resources of the vehicle 10 from the application execution unit 133X, which is an execution subject of the application program 133.

[0045] The risk of reduced safety of the vehicle 10 caused by calling the API 134 for operating resources of the vehicle 10 by the application execution unit 133X can be affected by the state of the vehicle 10. In the present embodiment, whether to permit a call to the API 134 is determined based on the state of the vehicle 10, so that reduction in safety of the vehicle 10 caused by the call of the API 134 by the application execution unit 133X can be suppressed without excessively restricting the call.

[0046] In the present embodiment, the state of the vehicle 10 includes the traveling state of the vehicle 10. The risk of reduced safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X can be greatly affected by the traveling state of the vehicle 10. In the present embodiment, whether the API 134 can be invoked is determined based on the traveling state of the vehicle 10, so that a reduction in the safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X can be effectively suppressed.

[0047] In the present embodiment, the state of the vehicle 10 includes a driving state that represents the degree of load on the driver of the vehicle 10. The risk of reduced safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X can be greatly affected by the driving state. In the present embodiment, whether the API 134 can be invoked is determined based on the driving state, so that a reduction in the safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X can be effectively suppressed.

[0048] In the present embodiment, the access control unit 132X determines whether the API 134 can be invoked based on characteristics related to the safety of resources of the vehicle 10. The risk of reduced safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X may vary depending on characteristics related to the safety of the resource to be invoked. In the present embodiment, whether the API 134 can be invoked is determined based on characteristics related to resource safety, so that a reduction in the safety of the vehicle 10 caused by the invocation of the API 134 by the application execution unit 133X can be suppressed without excessively restricting the invocation.

[0049] In the present embodiment, the access control unit 132X determines whether the API 134 can be invoked based on access control information AC that defines whether the API 134 can be invoked for each characteristic related to the safety of resources of the vehicle 10. Therefore, by referencing the access control information AC, the determination of whether the API 134 can be invoked can be performed efficiently and with high accuracy.

[0050] In this embodiment, the access control unit 132X includes a safety class SC that classifies the safety characteristics of the vehicle 10's resources into multiple classes for each type of resource. Therefore, it can efficiently and accurately determine whether or not to call the API 134 according to the safety class SC, without being affected by the differences in resources for each vehicle 10.

[0051] (Other Embodiments) Next, other embodiments will be described. In the following, the same components and processes as those described in the embodiments above will be denoted by the same reference numerals, and their descriptions will be omitted as appropriate.

[0052] Figures 9 and 10 are explanatory diagrams showing an example of vehicle configuration information VC in another embodiment. In this embodiment as well, vehicle configuration information VC is information indicating the safety characteristics of the resources possessed by the vehicle 10. In this embodiment, the safety characteristics of the resources are identified by residual safety classes. Residual safety classes are safety classes (classifications of risks, also called "risk classes") that remain because no countermeasures have been taken by the vehicle 10 and / or the vehicle OS 131. For example, for windows, there is a safety class "Risk Pinch" indicating the risk of pinching when closing the window, and a safety class "Risk Open" indicating various risks associated with opening the window. If the windows of the vehicle 10 do not have an anti-pinch function, "Risk Pinch" remains. Therefore, in the vehicle configuration information VC of this vehicle 10, "Risk Pinch" is described as the residual safety class for the window, as shown in Figure 9. On the other hand, if the windows of the vehicle 10 have an anti-pinch function, "Risk Pinch" does not exist. Therefore, in the vehicle configuration information VC of this vehicle 10, "Risk Pinch" is not described as a residual safety class for the windows, as shown in Figure 10. Similarly, even if the windows of vehicle 10 do not have an anti-pinch function, if window pinch prevention is implemented by the vehicle OS 131, "Risk Pinch" is not described as a residual safety class for the windows. Similarly, for other safety classes for windows such as "Risk Open" and safety classes for other resources such as displays, the vehicle configuration information VC describes the residual safety classes that have not been addressed (countermeasures) by vehicle 10 and / or vehicle OS 131. Note that risk is not limited to personal injury risks, but may also include risks to other elements such as property, goods, the environment, and privacy.

[0053] Figures 11 and 12 are explanatory diagrams showing an example of access control information AC in another embodiment. In this embodiment, access control information AC is information that describes the safety class for which the application program 133 has taken action (countermeasures) for each resource of the vehicle 10. For example, as an action for the application program 133 to respond to "Risk Pinch" for a window, when the application program 133 calls API 134 which involves closing the window, it is conceivable that the application program 133 will inform the user that the window will be closed, for example by voice output or screen display, and will perform the window closing operation after obtaining the user's consent. Alternatively, it is conceivable that the application program 133 will inform the user that the window will be closed and also provide the user with a means to stop the window closing operation. In the access control information AC of the application program 133 which has taken such an action, "Risk Pinch" is described as the addressed safety class for the window, as shown in Figure 11. On the other hand, in the access control information AC of application program 133 that does not have a countermeasure against "Risk Pinch," "Risk Pinch" is not described as a countermeasured safety class, as shown in Figure 12. Similarly, for other safety classes related to windows such as "Risk Open," and safety classes related to other resources such as displays, only those that have been addressed (countermeasures) by application program 133 are described in the access control information AC.

[0054] Figure 13 is a flowchart illustrating the access control process in another embodiment. In the access control process in the other embodiment, when the access control unit 132X (Figure 2) receives a call to API 134 for manipulating the resources of the vehicle 10 from the application execution unit 133X, which is the execution body of the application program 133 (S110), it identifies the type of operation (service call and its parameters) (S112) and the vehicle state VS (S120). The vehicle state VS is defined, for example, by the driving state and the running state, as in the above embodiment. Subsequently, the access control unit 132X decides whether or not to call API 134 based on the type of operation and the vehicle state VS (S132).

[0055] More specifically, the access control unit 132X refers to the vehicle configuration information VC (Figures 9 and 10) to identify the remaining safety class for the target resource, and also refers to the access control information AC (Figures 11 and 12) to identify the safety class already handled by the application program 133. Then, if the safety class (risk class) for the target resource is either not remaining or has been handled by the application program 133, the access control unit 132X determines that it is callable (S140: YES) and allows the application execution unit 133X to call the API 134 (S150).

[0056] On the other hand, if the safety class (risk class) for the target resource remains and has not been addressed by the application program 133, the access control unit 132X makes a determination on whether a call is permitted based on the type of operation (service call and its parameters) and the vehicle status VS. This determination is performed in the same way as the determination in the embodiment described above (Figure 8). If the access control unit 132X determines in this determination that a call is permitted (S140: YES), it permits the application execution unit 133X to call the API 134 (S150). On the other hand, if the access control unit 132X determines in this determination that a call is not permitted (S140: NO), it does not permit the application execution unit 133X to call the API 134 (S160).

[0057] Thus, in the other embodiments shown in Figures 9 to 13, the access control unit 132X determines whether or not to call API 134 based on the safety characteristics of the vehicle 10's resources. Therefore, it is possible to suppress a decrease in the safety of the vehicle 10 caused by such calls without excessively restricting API 134 calls by the application execution unit 133X.

[0058] (Modifications) The technologies disclosed herein are not limited to the embodiments described above and can be modified in various forms without departing from the spirit thereof, for example, the following modifications are possible.

[0059] The configuration of the vehicle 10 in the above embodiment is merely an example and can be modified in various ways. Furthermore, the content of the access control processing in the above embodiment is merely an example and can be modified in various ways.

[0060] In the above embodiment, the vehicle state VS may not include either the driving state or the operating state. Alternatively, the vehicle state VS may include states other than the driving state and the operating state. For example, the vehicle state VS may include the driving environment. Examples of the driving environment include whether it is a public road or an unpublic road (e.g., a circuit), whether it is an expressway or a public road, and the country and / or region in which the vehicle is being driven. The risk of reduced safety of the vehicle 10 due to the calling of API 134 by the application execution unit 133X can be greatly influenced by the driving environment. By determining whether or not to call API 134 based on the driving environment, the reduction in safety of the vehicle 10 due to the calling of API 134 by the application execution unit 133X can be effectively suppressed. The driving environment is an example of a moving environment. In addition, the vehicle state VS may include the battery state (battery level), occupant status (whether or not there are occupants, how many occupants there are), abnormal conditions (malfunctions, accidents, and their severity), etc.

[0061] In the above embodiment, the access control information AC may be information that determines whether or not to call API 134 based on the vehicle state VS, regardless of the characteristics related to the safety of the resource.

[0062] In the above embodiment, the characteristics related to the safety of the resource may be identified by a method other than classification by safety class SC.

[0063] In the above embodiment, the access control unit 132X may perform access control from a security standpoint. For example, if the application is compromised, the access control unit 132X may prevent any service calls other than those necessary from being made. In the above embodiment, the access control unit 132X may also perform access control from a privacy standpoint.

[0064] In the above embodiment, at least one of the functional units included in the central ECU 100 may be included in another device (for example, a smartphone, a server on the cloud, etc.). Each step of the access restriction processing in the above embodiment does not necessarily have to be performed by a single device, but may be performed by different devices. In the above embodiment, some of the configurations implemented by hardware may be replaced with software, and conversely, some of the configurations implemented by software may be replaced with hardware.

[0065] Although the above embodiment described a vehicle 10 as an example, the technologies disclosed herein are similarly applicable to other mobile devices (drones, helicopters, airplanes, satellites, etc.).

[0066] 10: Vehicle 100: Central ECU 110: CPU 120: RAM 130: ROM 131: Vehicle OS 131X: Vehicle OS execution unit 132: Access control program 132X: Access control unit 133: Application program 133X: Application execution unit 134: API 140: Communication interface 150: Sensor 160: Driver assistance ECU 170: Display ECU 172: Display 180: Window ECU 182: Window 190: Seat ECU 192: Seat AC: Access control information SC: Safety class VC: Vehicle configuration information

Claims

1. A computer program that causes a computer controlling a mobile object to execute a process that determines whether or not an API call for manipulating the resources from the execution entity of an application program is permitted, based on the safety characteristics of the resources of the mobile object.

2. A computer program according to claim 1, wherein the processing is performed based on access control information that specifies whether or not the execution entity can make the call for each characteristic relating to the safety of the resource.

3. A computer program according to claim 2, wherein the characteristics relating to the safety of the resource include a safety class that classifies the safety of each type of resource into a plurality of classes.

4. A computer program according to any one of claims 1 to 3, wherein the mobile body is a vehicle.

5. A mobile device control device for controlling a mobile object, comprising an access control unit that determines whether or not an API call for manipulating the resources from an application program execution entity is permitted, based on the safety characteristics of the resources of the mobile object.

6. A mobile body control method for controlling a mobile body, comprising the step of determining whether or not an API call for manipulating the resources from an application program execution entity is permitted, based on the safety characteristics of the resources of the mobile body.

Images