Information processing system and program

Abstract

Status monitoring units (12, 13) monitor vehicle statuses related to the execution of an application. An execution management unit (14) selects any one of a first execution pattern, a second execution pattern, and a third execution pattern in accordance within the monitoring results of the status monitoring units, and causes an in-vehicle executing unit (11) and an out-of-vehicle executing unit (21) to execute the application in accordance with the selected execution pattern. With the first execution pattern, functional units are distributed to the in-vehicle execution unit and the out-of-vehicle executing unit, and a normal version of the application is executed. With the second execution pattern, the normal version of the application is executed by the in-vehicle execution unit. With the third execution pattern, a lightweight version of the application is executed by the in-vehicle execution unit.

Description

Information processing systems and programs CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2024-043387, filed with the Japan Patent Office on March 19, 2024, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a technology for executing an application that utilizes data acquired in a vehicle.

[0003] The following Patent Document 1 describes a technology that evaluates a computational task based on the tasks being executed in the vehicle and the vehicle's status, and performs either in-vehicle processing of the computational task, out-vehicle processing of the computational task (i.e., off-road processing), or discarding the computational task according to the evaluation results.

[0004] U.S. Pat. No. 1,141,8597

[0005] However, after detailed investigation by the inventors, it was found that the conventional technology only switched between processing inside or outside the vehicle on a task-by-task basis depending on the vehicle's situation, and was unable to perform appropriate load distribution in accordance with the diverse vehicle situations.

[0006] One aspect of the present disclosure provides a technology for achieving appropriate load distribution in accordance with various vehicle situations.

[0007] One aspect of the present disclosure is an information processing system including an in-vehicle execution unit, an external execution unit, a situation monitoring unit, and an execution management unit. The in-vehicle execution unit is provided in a vehicle and configured to execute either a normal version app or a lightweight version app. The normal version app is an application that includes processing using data acquired in the vehicle and has multiple individually executable functional units. The lightweight version app is an application that has the same purpose as the normal version app but achieves simple functions with less resource usage. The external execution unit is provided in an external device that can communicate with the vehicle and configured to execute the normal version app. The situation monitoring unit is configured to monitor a vehicle situation related to application execution. The execution management unit is configured to select one of a first execution pattern, a second execution pattern, and a third execution pattern according to the monitoring result of the situation monitoring unit, and to cause the in-vehicle execution unit and the external execution unit to execute the application according to the selected execution pattern. In the first execution pattern, functional units are allocated to the in-vehicle execution unit and the external execution unit to execute the normal version app. In the second execution pattern, the normal version app is executed by the in-vehicle execution unit. In the third execution pattern, the lightweight application is executed by the in-vehicle execution unit.

[0008] With this configuration, it is possible to achieve appropriate load distribution according to various vehicle conditions.

[0009] One aspect of the present disclosure is a program that causes a computer to function as an in-vehicle execution unit, an out-vehicle execution unit, a situation monitoring unit, and an execution management unit.

[0010] By executing such a program, it is possible to obtain the same effects as those of the above-mentioned information processing system.

[0011] 1 is a block diagram showing a hardware configuration of an information processing system. FIG. 2 is a block diagram showing a functional configuration of an information processing system. FIG. 3 is an explanatory diagram showing the structure and arrangement of application programs. FIG. 4 is an explanatory diagram illustrating an example of a combination of programs started in a first execution pattern. FIG. 5 is an explanatory diagram showing programs started in a second execution pattern. FIG. 6 is an explanatory diagram showing programs started in a third execution pattern. FIG. 7 is an explanatory diagram showing selection of an execution state when an application program is started. FIG. 8 is an explanatory diagram showing transitions of execution states while an application program is running. FIG. 9 is an explanatory diagram showing the structure of an object detection app. FIG. 10 is a specific example showing state transitions when an object detection app is used.

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

[0013] [1. Configuration] As shown in Fig. 1, an information processing system 1 of this embodiment includes an in-vehicle system 100 mounted on a vehicle and a cloud server 200. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the in-vehicle system 100 will be simply referred to as a vehicle.

[0014] The in-vehicle system 100 includes one electronic control unit (hereinafter referred to as ECU) 2, a plurality of ECUs 3, a plurality of ECUs 4, an external communication device 5, and an internal communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0015] The ECU 2 controls a plurality of ECUs 3 to realize coordinated control of the entire vehicle.

[0016] An ECU 3 is provided for each domain, which is divided according to the vehicle's functions, and mainly controls the multiple ECUs 4 present within that domain. Each ECU 3 is connected to its subordinate ECUs 4 via a lower-layer network individually provided for each ECU 3. The lower-layer network may be, for example, a Controller Area Network (hereinafter, CAN). The ECU 3 has the function of centrally managing access rights and the like for the subordinate ECUs 4 and authenticating users. The domains may be, for example, a powertrain, a body, a chassis, a cockpit, etc.

[0017] The ECUs 4 connected to the ECU 3 belonging to the powertrain domain include, for example, an ECU 4 that controls the engine, an ECU 4 that controls the motor, and an ECU 4 that controls the battery.

[0018] The ECUs 4 connected to the ECU 3 belonging to the body domain include, for example, an ECU 4 that controls an air conditioner, an ECU 4 that controls doors, and the like.

[0019] The ECUs 4 connected to the ECU 3 belonging to the chassis domain include, for example, an ECU that controls the brakes and an ECU 4 that controls the steering.

[0020] The ECUs 4 connected to the ECU 3 belonging to the cockpit domain include, for example, an ECU 4 that controls the display of meters and navigation systems, and an ECU 4 that controls an HMI device operated by a vehicle occupant, etc. HMI is an abbreviation for Human Machine Interface.

[0021] The external vehicle communication device 5 performs data communication with external vehicle devices such as the cloud server 200 via a wide area wireless communication network.

[0022] The in-vehicle communication network 6 includes CAN with Flexible Data Rate (hereinafter referred to as CAN FD) and Ethernet. Ethernet is a registered trademark. The CAN FD may connect the ECU 2 to each ECU 3 and the exterior-vehicle communication device 5 via a bus. The Ethernet may connect the ECU 2 to each ECU 3 and the exterior-vehicle communication device 5 individually.

[0023] The ECU 2 is an electronic control device mainly composed of a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, etc. Various functions of the microcomputer are realized by the CPU 2a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 2b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 2a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU 2 may be one or more.

[0024] The ECU 3, the ECU 4, and the exterior communication device 5 are all electronic control devices that are mainly configured with a microcomputer including a CPU, a ROM, a RAM, etc., similar to the ECU 2. The number of microcomputers that make up the ECU 3, the ECU 4, and the exterior communication device 5 may be one or more.

[0025] In the following description, the ECU 2, ECU 3, ECU 4, and the external communication device 5 will be referred to as the in-vehicle devices 2 to 5 unless there is a need to distinguish between them.

[0026] The cloud server 200 includes a control unit 7 and a communication unit 8 .

[0027] The control unit 7, like the in-vehicle devices 2 to 5, is an electronic control device mainly composed of a microcomputer including a CPU 7a, a ROM 7b, a RAM 7c, etc. The various functions of the microcomputer are realized by the CPU executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 7b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 7a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 7 may be one or more.

[0028] The communication unit 8 performs data communication with the in-vehicle system 100 via a wide area wireless communication network.

[0029] The cloud server 200 is executed by the in-vehicle system 100, and has a function of executing some or all of the applications executed by the in-vehicle system 100 on behalf of the in-vehicle system 100 in order to reduce the processing load of the applications. Note that the applications executed by the in-vehicle system 100 include processes that utilize data acquired by the vehicle.

[0030] 2. Functional Configuration The functional configuration of the information processing system 1 will be described.

[0031] 2, the in-vehicle system 100 includes functional blocks that are realized by the CPU 2a or the like executing programs stored in the ROM 2b or the like, such as an in-vehicle execution unit 11, a communication monitoring unit 12, a resource monitoring unit 13, and an execution management unit 14. Note that these functional blocks 11 to 14 are not limited to the ROM 2b and CPU 2a mounted on the ECU 2, and may also be realized by ROMs and CPUs mounted on other in-vehicle devices 3 to 5.

[0032] The cloud server 200 includes an off-vehicle execution unit 21 as a functional block realized by the CPU 7a executing a program stored in the ROM 7b.

[0033] The in-vehicle execution unit 11 manages the execution of apps installed in the vehicle in accordance with instructions from the execution management unit 14. Specifically, the in-vehicle execution unit 11 allocates vehicle resources 16 to apps to be executed and starts the apps.

[0034] The applications managed by the in-vehicle execution unit 11 include a normal application NA and a lightweight application SA.

[0035] As shown in FIG. 3 , the regular version application NA has multiple software components (hereinafter referred to as components) that divide the application into functional units. The regular version application NA is configured so that execution or non-execution can be selected on a component-by-component basis. The lightweight version application SA is an application that achieves the same purpose as the regular version application NA but with simpler functions, while using fewer resources than the regular version application NA. The regular version application NA and the lightweight version application SA may be distributed together from the cloud server 200, etc. Alternatively, there may be an application that omits the lightweight version application SA and distributes only the regular version application NA. The regular version application NA is installed in both the in-vehicle system 100 and the cloud server 200, and the lightweight version application SA is installed only in the in-vehicle system 100.

[0036] The communication monitoring unit 12 monitors the communication status between the in-vehicle system 100 and the cloud server 200 by monitoring the communication device 15 included in the in-vehicle system 100. The communication device 15 may be the external communication device 5 shown in FIG. 1 or a communication device that is retrofitted to the in-vehicle system 100. The communication device 15 may be, for example, a device that performs Wi-Fi communication or cellular communication. Wi-Fi is a registered trademark.

[0037] The communication status to be monitored may be, for example, the communication speed or the size of the communication bandwidth allocated by the infrastructure that provides the communication. In this embodiment, the communication monitoring unit 12 monitors the communication speed. Hereinafter, the communication speed detected by the communication monitoring unit 12 is represented by X [Mbps].

[0038] The resource monitoring unit 13 monitors the usage status of vehicle resources 16. The vehicle resources 16 are resources installed in the vehicle and used to execute apps that are managed by the in-vehicle execution unit 11. When the apps that are managed are executed by the ECU 2, the vehicle resources 16 may include the available processing capacity of the CPU 2a and the available memory capacity, including the ROM 2b and RAM 2a, that is available to the CPU 2a. Hereinafter, the available available processing capacity detected by the resource monitoring unit 13 will be represented as Y [MIPS], and the available available memory capacity will be represented as Z [MB].

[0039] The execution management unit 14 transitions the execution state of the app based on monitoring information obtained from the communication monitoring unit 12 and the resource monitoring unit 13, and sends instructions according to the execution state to the in-vehicle execution unit 11 and the out-vehicle execution unit 21.

[0040] The execution states of an application are represented by states 1 to 3. The in-vehicle execution unit 11 and the out-vehicle execution unit 21 execute the application in a first execution pattern in the first state, in a second execution pattern in the second state, and in a third execution pattern in the third state.

[0041] In the initial state before the apps are launched, as shown in Figure 3, the lightweight version app SA and the regular version app NA installed in the in-vehicle system 100, and the regular version app NA installed in the cloud server 200 are all in an inactive state.

[0042] In the first execution pattern, as shown in FIG. 4 , the normal version application NA is executed by allocating it to the in-vehicle system 100 and the cloud server 200 on a component-by-component basis. FIG. 4 shows that, of the normal version application NA divided into three functions 1 to 3, the component that realizes function 1 is executed by the in-vehicle system 100, and the components that realize functions 2 and 3 are executed by the cloud server 200. Unlike the second and third execution patterns described below, the first execution pattern requires communication between the components executed by the in-vehicle system 100 and the components executed by the cloud server 200. Therefore, component allocation may be performed dynamically, taking into account communication costs, energy efficiency, response time, and the like. Executing the application in the first execution pattern enables fine-grained reduction in power consumption on a component-by-component basis.

[0043] 5 , in the second execution pattern, the normal version of the application NA installed in the in-vehicle system 100 is activated. That is, in the in-vehicle system 100, the normal version of the application NA is executed without requiring communication with the cloud server 200. By executing the application in the second execution pattern, the processing load on the in-vehicle system 100 increases, but it becomes possible to achieve high functionality within the in-vehicle system 100 alone.

[0044] 6, the lightweight application SA installed in the in-vehicle system 100 is activated. That is, the lightweight application SA is executed in the in-vehicle system 100 without requiring communication with the cloud server 200. Executing the application in the third execution pattern reduces the processing load on the in-vehicle system 100 while realizing the minimum required functionality.

[0045] Then, when an application is launched, the execution management unit 14 transitions the execution state of the application from the initial state before launch to one of the first to third states depending on the vehicle conditions (e.g., communication conditions and vehicle resource conditions). Specifically, as shown in FIG. 7 , the execution management unit 14 transitions to the first state when communication is stable (hereinafter referred to as the stable communication state). Furthermore, when communication is unstable (hereinafter referred to as the unstable communication state) and there are ample vehicle resources (hereinafter referred to as the ample resource state), the execution management unit 14 transitions to the second state. When communication is unstable and there is a shortage of vehicle resources (hereinafter referred to as the resource shortage state), the execution management unit 14 transitions to the third state.

[0046] The execution management unit 14 determines the communication status and vehicle resource status using a communication threshold Sx, a processing threshold Sy, and a capacity threshold Sz. In other words, a stable communication status indicates that the communication speed X detected by the communication monitoring unit 12 is equal to or greater than the communication threshold Sx (i.e., X≧Sx), and an unstable communication status indicates that the communication speed X is less than the communication threshold Sx (i.e., X<Sx). A resource surplus status indicates that the CPU's available processing capacity Y detected by the resource monitoring unit 13 is equal to or greater than the processing threshold Sy (i.e., Y≧Sy) and that the memory's available capacity Z is equal to or greater than the capacity threshold Sz (i.e., Z≧Sz). A resource tight status indicates that the CPU's available processing capacity Y is less than the processing threshold Sy (i.e., Y<Sy) or that the memory's available capacity Z is less than the capacity threshold Sz (i.e., Z<Sz).

[0047] The execution management unit 14 transitions the execution state of the application according to the communication status and the vehicle resource status even while the application is running. Here, a change in the communication status from an unstable communication status to a stable communication status is referred to as communication stabilization, and a change in the communication status from a stable communication status to an unstable communication status is referred to as communication instability. Furthermore, a change in the vehicle resource status from a resource tight status to a resource surplus status is referred to as resource surplus, and a change in the vehicle resource status from a resource surplus status to a resource tight status is referred to as resource tightness.

[0048] While the application is running, the execution management unit 14 uses the above-mentioned communication threshold Sx, processing threshold Sy, and capacity threshold Sz to determine whether communication is unstable and resources are running low, and uses the communication threshold Mx, processing threshold My, and capacity threshold Mz to determine whether communication is stable and resources are available.

[0049] Specifically, as shown in Figure 8, when the execution state of the app is in the first state, if communication becomes unstable, the execution management unit 14 transitions to the second state if there is a resource surplus, or to the third state if there is a resource shortage. When the execution state of the app is in the second state, if communication stabilizes, the execution management unit 14 transitions to the first state, and when resources become tight while communication remains unstable, the execution management unit 14 transitions to the third state. When the execution state is in the third state, if there is a resource surplus while communication remains unstable, the execution management unit 14 transitions to the second state, and when there is a resource surplus and communication stabilizes, the execution management unit 14 transitions to the first state.

[0050] The thresholds are set so that Sx≦Mx, Sy≦My, and Sz≦Mz. This setting is made because it is expected that the vehicle situation will change more significantly during operation than at startup. This setting is intended to ensure that state transitions occur when communication is sufficiently stabilized and there is sufficient resource surplus. In other words, this prevents frequent state transitions from occurring, such as when communication is determined to have become unstable immediately after communication has stabilized, or when resources are determined to have become constrained immediately after resources have become surplus.

[0051] 2, the off-vehicle execution unit 21 receives instructions from the execution management unit 14 of the in-vehicle system 100 via the communication device 22, and manages the execution of the standard version application NA installed on the cloud server 200 in accordance with the instructions. Specifically, the off-vehicle execution unit 21 allocates cloud resources 23 to the application to be executed and starts the application.

[0052] The communication device 22 communicates with the communication device 15 of the in-vehicle system 100. The communication device 22 may be the communication unit 8 shown in FIG. 1 or another communication device present in the cloud. The cloud resources 23 are resources owned by the cloud and used to execute apps managed by the off-vehicle execution unit 21. The cloud resources 23 may include the free processing capacity of the CPU 7a and the free memory capacity available to the CPU 2a, including the ROM 7b and RAM 7a.

[0053] When the normal version application NA is executed in the first execution pattern, the components allocated to the in-vehicle system 100 and the cloud server 200 communicate with each other via the communication devices 15 and 22 .

[0054] 3. Specific Example Using the object detection application 30 as an example, a specific operation of the information processing system 1 will be described with reference to FIGS. 9 and 10. FIG.

[0055] [3-1. Premise] The object detection application 30 realizes a function of inputting an image and outputting information that links the image with the position and type of an object.

[0056] 9 , the standard version 30A of the object detection application 30 (hereinafter referred to as the standard version application) requires a CPU processing capacity of 300 MIPS or more and free memory space of 0.2 MB or more. The lightweight version 30B of the object detection application 30 (hereinafter referred to as the lightweight version application) requires a CPU processing capacity of 100 MIPS or more and free memory space of 0.1 MB or more.

[0057] The standard version application 30A is configured from an image processing component 31, an object position identification component 32, and an object type identification component 33.

[0058] When the input image of the image processing component 31 is communicated between the in-vehicle system 100 and the cloud server 200, a communication speed of 7 Mbps is required.

[0059] The image processing component 31, for example, divides an input image into a plurality of regions and executes a process of extracting boundaries of objects and the like for each divided region.

[0060] When the processing results of the image processing component 31, that is, the input data of the object location identification component 32, are communicated between the in-vehicle system 100 and the cloud server 200, a communication speed of 2 Mbps is required.

[0061] The object position identification component 32, for example, collects the processing results for each divided region and executes a process of extracting the position where the object is captured.

[0062] When the processing result of the object position identification component 32, that is, the input data of the object type identification component 33, is communicated between the in-vehicle system 100 and the cloud server 200, a communication speed of 3 Mbps is required.

[0063] The object type identification component 33 executes, for example, a process of identifying the type of object captured at each object position extracted by the object position identification component 32 .

[0064] When the processing results of the object type identification component 33 are communicated between the in-vehicle system 100 and the cloud server 200, a communication speed of 5 Mbps is required.

[0065] 10, for example, thresholds used for determining startup, communication instability, and vehicle resource shortage are Sx = 5 [Mbps], Sy = 300 [MIPS], and Sz = 0.2 [MB]. Also, thresholds used for determining communication stabilization and vehicle resource surplus are Mx = 9 [Mbps], My = 500 [MIPS], and Mz = 0.2 [MB].

[0066] In the first execution pattern, the allocation of components to be processed by the in-vehicle system 100 and the cloud server 200 differs depending on whether the first condition, that is, the communication speed X is 7 Mbps or more, is met or the second condition, that is, the communication speed X is 5 to 7 Mbps.

[0067] If the first condition is satisfied, the image processing component 31 is executed in the in-vehicle system 100, and the object position identification component 32 and the object type identification component 33 are executed in the cloud server 200. In this case, communication of the processing result of the image processing component 31 (i.e., the required communication speed is 2 Mbps) and communication of the processing result of the object type identification component 33 (i.e., the required communication speed is 5 Mbps) are executed between the in-vehicle system 100 and the cloud server 200.

[0068] If the second condition is satisfied, the in-vehicle system 100 executes the image processing component 31 and the object type identification component 33, and the cloud server 200 executes the object location identification component 32. In this case, communication of the processing result of the image processing component 31 (i.e., the required communication speed is 2 Mbps) and communication of the processing result of the object location identification component 32 (i.e., the required communication speed is 3 Mbps) are executed between the in-vehicle system 100 and the cloud server 200.

[0069] In a stable communication state (i.e., X≧Sx), the application is executed in a first execution pattern that requires communication between components between the in-vehicle system 100 and the cloud server 200. In an unstable communication state (i.e., X<Sx), the application is executed in a second or third execution pattern that does not require communication between components between the in-vehicle system 100 and the cloud server 200.

[0070] When communication is unstable (i.e., X<Sx) but resources are surplus (i.e., Y≧Sy and Z≧Sz), the application is executed in the second execution pattern, which requires more vehicle resources.

[0071] When communication is unstable (i.e., X<Sx) and resources are tight (i.e., Y<Sx or Z<Sz), the application is executed using the third execution pattern, which requires fewer vehicle resources.

[0072] That is, the communication threshold Sx is set in consideration of the communication speed required for communication of input / output data between the components 31 to 33. The processing threshold Sy and the capacity threshold Sz are set in consideration of the available processing capacity and available capacity required for executing the standard version application 30A.

[0073] Note that the communication threshold Mx, processing threshold My, and capacity threshold Mz are used to determine communication stabilization and on-board resource availability, i.e., to determine transitions from the second state to the first state, from the third state to the first state, and from the third state to the second state. The communication threshold Mx, processing threshold My, and capacity threshold Mz are set to values ​​that are, for example, 1.5 to 2 times the values ​​of the thresholds Sx, Sy, and Sz in order to prevent frequent state transitions.

[0074] [4. Correspondence of Terms] The communication monitoring unit 12 and the resource monitoring unit 13 of this embodiment correspond to the status monitoring unit in this disclosure, and the communication status detected by the communication monitoring unit 12 and the vehicle resource status detected by the resource monitoring unit 13 correspond to the monitoring results of the status monitoring unit. The communication performed via the communication devices 15 and 22 of this embodiment corresponds to the external communication in this disclosure. The cloud server 200 of this embodiment corresponds to the external device capable of communicating with the vehicle in this disclosure. The communication threshold Sx, processing threshold Sy, and capacity threshold Sz of this embodiment correspond to the required amount in this disclosure.

[0075] 5. Effects According to the embodiment described above in detail, the following effects are achieved.

[0076] (5a) The information processing system 1 monitors the vehicle status (i.e., the status of communication and vehicle resources) and changes the execution state of applications and, ultimately, the execution pattern of applications depending on the vehicle status. Therefore, the information processing system 1 can flexibly change the execution pattern of applications in accordance with various vehicle statuses, thereby achieving appropriate load distribution.

[0077] (5b) When communication is stable, the information processing system 1 executes the standard version application NA by appropriately allocating the components constituting the application NA to the in-vehicle system 100 and the cloud server 200. Furthermore, the allocation of components is dynamically changed depending on the vehicle status so as to comprehensively optimize the processing load, communication volume, required time, power consumption, and the like in the in-vehicle system 100. Therefore, it is possible to achieve fine-tuned power consumption reductions, etc.

[0078] (5c) In the information processing system 1, when communication is unstable, the application is executed in the second execution pattern or the third execution pattern, which does not require communication with the cloud server 200. Moreover, when there is a surplus of vehicle resources, the normal version application NA is executed, and when vehicle resources are tight, the lightweight version application SA is executed. Therefore, according to the information processing system 1, even in a situation where communication with the cloud server 200 is impossible, it is possible to realize maximum functionality or minimum functionality according to the vehicle resource situation.

[0079] (5d) In the information processing system 1, the thresholds Mx, My, and Mz used to determine communication stabilization and vehicle resource surplus are set to values ​​equal to or greater than the thresholds Sx, Sy, and Sz used to determine communication instability and vehicle resource crunch. Therefore, the information processing system 1 can suppress frequent switching between a stable and unstable communication state and between a surplus and crunch state of vehicle resources, i.e., frequent switching of execution patterns.

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

[0081] (6a) In the above embodiment, the vehicle conditions to be monitored are exemplified by the communication conditions and the vehicle resource usage conditions, but are not limited to these.

[0082] (6b) In the above embodiment, one standard application NA is linked to one lightweight application SA, but multiple lightweight applications may be linked to one standard application NA. In this case, vehicle situations may be classified into more detailed categories, and the lightweight application to be executed may be switched for each classified vehicle situation.

[0083] (6c) In the above embodiment, in the first execution pattern, the allocation of components to the in-vehicle system 100 and the cloud server 200 is switched depending on the communication speed X. However, the allocation may also be switched taking into account, for example, the usage status of the cloud resources 23.

[0084] (6d) The in-vehicle devices 2 to 5 and control unit 7, as well as the methods described herein, may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the in-vehicle devices 2 to 5 and control unit 7, as well as the methods described herein, may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the in-vehicle devices 2 to 5 and control unit 7, as well as the methods described herein, may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium.

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

[0086] (6f) In addition to the above-mentioned information processing system 1, in-vehicle system 100, and cloud server 200, the present disclosure can also be realized in various forms, such as a program for causing a computer to function as the in-vehicle system 100 and cloud server 200, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a method for switching app execution patterns.

[0087] [7. Technical Ideas Disclosed in the Present Specification] [Item 1] An in-vehicle execution unit (11) provided in a vehicle and configured to execute either a normal version app, which is an application including processing using data acquired in the vehicle and having a plurality of individually executable functional units, or a lightweight version app, which is an application having the same purpose as the normal version app but realizing simple functions with less resource usage; an external device (21) provided in an external device capable of communicating with the vehicle and configured to execute the normal version app; a situation monitoring unit (12, 13) configured to monitor a vehicle situation related to execution of the application; and an execution management unit (14) configured to select one of a first execution pattern, a second execution pattern, and a third execution pattern according to a monitoring result by the situation monitoring unit, and to have the in-vehicle execution unit and the external execution unit execute the application according to the selected execution pattern, wherein the first execution pattern allocates the functional units to the in-vehicle execution unit and the external execution unit and executes the normal version app; and the second execution pattern executes the normal version app by the in-vehicle execution unit. In the third execution pattern, the lightweight application is executed by the in-vehicle execution unit.

[0088] [Item 2] The information processing system according to Item 1, wherein the status monitoring unit is configured to monitor, as the vehicle status, a communication status of external communication, which is communication between the vehicle and the external device, and a vehicle resource status indicating a status of vehicle resources used to execute the application in the vehicle; and the execution management unit is configured to select the first execution pattern when the vehicle is in a stable communication status, which is the communication status where a communication speed of the external communication is equal to or greater than a communication threshold; select the second execution pattern when the vehicle is in an unstable communication status, which is the communication status where the communication speed of the external communication is lower than the communication threshold, and is in a resource surplus status, which is the vehicle resource status where more than a required amount of vehicle resources required for execution of the normal version app are available; and select the third execution pattern when the vehicle is in the unstable communication status and is in a resource constrained status, which is the vehicle resource status where the available vehicle resources are less than the required amount.

[0089] [Item 3] The information processing system according to item 1 or 2, wherein the execution management unit is configured to select the execution pattern when the application is started.

[0090] [Item 4] The information processing system according to any one of items 1 to 3, wherein the execution management unit is configured to dynamically change the execution pattern by repeatedly selecting the execution pattern while the application is running.

[0091] [Item 5] An information processing system according to item 3 or 4, which refers to item 2, wherein the execution management unit is configured to differentiate a threshold value used when determining a change from the stable communication state to the unstable communication state and a change from the resource surplus state to the resource tight state from a threshold value used when determining a change from the unstable communication state to the stable communication state and a change from the resource tight state to the resource surplus state.

[0092] [Item 6] The information processing system according to any one of items 1 to 5, wherein the execution management unit is configured to change the allocation of the functional units to the in-vehicle execution unit and the out-vehicle execution unit in the first execution pattern depending on the vehicle situation.

Claims

1. An in-vehicle execution unit (11) provided in a vehicle and configured to execute either a normal version app, which is an application including processing using data acquired in the vehicle and having a plurality of individually executable functional units, or a lightweight version app, which is an application that has the same purpose as the normal version app but achieves simple functions with less resource usage; an external execution unit (21) provided in an external device capable of communicating with the vehicle and configured to execute the normal version app; a situation monitoring unit (12, 13) configured to monitor a vehicle situation related to the execution of the application; and an execution management unit (14) configured to select one of a first execution pattern, a second execution pattern, and a third execution pattern according to the monitoring result of the situation monitoring unit, and to have the in-vehicle execution unit and the external execution unit execute the application according to the selected execution pattern, wherein the first execution pattern allocates the functional units to the in-vehicle execution unit and the external execution unit and executes the normal version app; and the second execution pattern executes the normal version app in the in-vehicle execution unit. In the third execution pattern, the lightweight application is executed by the in-vehicle execution unit.

2. An information processing system according to claim 1, wherein the status monitoring unit is configured to monitor, as the vehicle status, a communication status of external communication, which is communication between the vehicle and the external device, and a vehicle resource status indicating a status of vehicle resources used to execute the application in the vehicle; and the execution management unit is configured to select the first execution pattern when the vehicle is in a stable communication status, which is the communication status where the communication speed of the external communication is equal to or greater than a communication threshold, select the second execution pattern when the vehicle is in an unstable communication status, which is the communication status where the communication speed of the external communication is less than the communication threshold, and is in a resource surplus status, which is the vehicle resource status where more than the required amount of vehicle resources required to execute the normal version app are available, and select the third execution pattern when the vehicle is in the unstable communication status and is in a resource tight status, which is the vehicle resource status where the available vehicle resources are less than the required amount.

3. An information processing system according to claim 2, wherein the execution management unit is configured to select the execution pattern when the application is started.

4. An information processing system according to claim 3, wherein the execution management unit is configured to dynamically change the execution pattern by repeatedly selecting the execution pattern while the application is running.

5. An information processing system as described in claim 4, wherein the execution management unit is configured to differentiate the threshold value used when determining a change from the stable communication state to the unstable communication state and a change from the resource surplus state to the resource tight state from the threshold value used when determining a change from the unstable communication state to the stable communication state and a change from the resource tight state to the resource surplus state.

6. An information processing system according to any one of claims 1 to 5, wherein the execution management unit is configured to change the allocation of the functional units to the in-vehicle execution unit and the out-vehicle execution unit in the first execution pattern depending on the vehicle situation.

7. A program for causing a computer to function as: an in-vehicle execution unit (11) provided in a vehicle and configured to execute either a normal version app, which is an application including processing using data acquired in the vehicle and having multiple individually executable functional units, or a lightweight version app that has the same purpose as the normal version app but achieves simple functions with less resource usage; an out-of-vehicle execution unit (21) provided in an external device capable of communicating with the vehicle and configured to execute the normal version app; a situation monitoring unit (12, 13) configured to monitor the vehicle situation related to the execution of the application; and an execution management unit (14) configured to allocate the functional units to the in-vehicle execution unit and the out-vehicle execution unit according to the monitoring results of the situation monitoring unit, and select one of a first execution pattern in which the normal version app is executed, a second execution pattern in which the normal version app is executed by the in-vehicle execution unit, or a third execution pattern in which the lightweight version app is executed by the in-vehicle execution unit, and cause the in-vehicle execution unit and the out-vehicle execution unit to execute the application according to the selected execution pattern.

Images