Program, server device, information processing device, and mobile body

Abstract

The present invention suppresses the occurrence of inconvenience due to a version difference between a system program in a facility and firmware in a mobile body. The present invention provides a program that causes an information processing device installed in a mobile body to execute: a step for determining whether or not the mobile body is traveling toward a second region from a first region; a step for, when the mobile body is moving toward the second region, determining whether or not a predefined batch of processes is under execution; a step for, when the batch of processes is under execution and the current speed is to be maintained, determining whether or not the mobile body enters the second region before the batch of processes under execution is completed; and a step for, when it is determined that the mobile body enters the second region before the batch of processes under execution is completed, controlling the traveling speed so as to complete the batch of processes before entering the second region and then enter the second region.

Description

Program, server device, information processing device, mobile object

[0001] The present invention relates to a program, a server device, an information processing device, and a mobile object.

[0002] When upgrading a program, staged upgrades are sometimes performed to prevent widespread problems. For example, when releasing a new version of a web service, the service provider may test the new version by releasing it to only a select number of users in advance. Releasing a new version of a program to only a select number of users in advance is called a "canary release." Figure 1 illustrates a canary release. In a canary release, as shown in Figure 1, the service provider allocates the new version (conveniently referred to as Ver. 2) to, for example, 5% to 10% of the total users, and allocates the remaining users to the previous version (conveniently referred to as Ver. 1). In Figure 1, the load balancer 201 connects 5% to 10% of users to the Ver. 2 web service and the remaining users to the Ver. 1 web service.

[0003] If there are no problems with Version 2 and the user response is good, the service provider will gradually increase the number of users connecting to the Version 2 web service, and eventually connect all users to the Version 2 web service.If problems are found in the Version 2 web service or user response is poor, the service provider may postpone the release of the Version 2 web service and make further improvements.Patent Document 1 discloses a technology for canary releases that limits the impact of program bugs and shortens the interval between program releases.

[0004] Furthermore, there is known a technology for upgrading a program to one suitable for a specific area when a mobile object moves to that area. Patent Document 2 discloses a technology for recognizing the current location using a signal from a GPS receiver, and reading and executing application software corresponding to the current location.

[0005] JP-A-2007-120973 JP-A-10-153437

[0006] Recently, there have been areas known as smart cities, which are designated areas where mobile objects move. Smart cities are sustainable cities and areas that utilize cutting-edge technologies such as ICT (information and communication technology) to solve urban and regional issues and create new value.

[0007] Fig. 2 schematically shows a smart city 202. In the smart city 202, services provided by various facilities such as traffic lights are realized by programs (hereinafter simply referred to as system programs). In the smart city 202, a canary release of a system program may also be performed. In Fig. 2, a new version (Ver. 2) of the system program is canary released only in a partial area 203 within the smart city 202.

[0008] When a mobile object moves within a smart city, it may obtain information from surrounding fixed facilities or request certain processing from the facilities. For example, the mobile object can receive traffic information from traffic lights and congestion information at its destination. The mobile object can also receive information from the facilities about the speed at which it should move without stopping at red lights, and move within the smart city at this speed. The mobile object can also open the shutters of buildings at its destination or the gates of parking lots. Such processing is performed by firmware installed on the computer of the mobile object 220.

[0009] 3 is a diagram illustrating the relationship between fixed facilities 210 and mobile objects 220 in a smart city 202. The fixed facilities 210 include traffic lights 211, cameras 212, and monitoring devices 213. The mobile objects 220 include electric kick scooters 221, bicycles 222, and four-wheeled automobiles 223.

[0010] 2, when a new system program is canary released in the smart city 202, only a partial area 203 of the smart city 202 is subject to the canary release. In the partial area 203, the firmware of the mobile object loses compatibility with the system program that controls the facility 210, which may cause the mobile object 220 to become unable to move or to move without following the rules within the smart city.

[0011] More specifically, the following problems may occur: (1) Misinterpretation of Real-Time Traffic Information: If the firmware of the mobile unit 220 continues to support an old version of the system program's API, it may not be able to correctly interpret the format of traffic information updated with a new system program version. This could result in the driver receiving incorrect traffic information and risking traffic congestion or accidents. (2) Malfunction of the Navigation Device: The firmware of the mobile unit 220 relates to the navigation device. If the navigation device does not support a new version of the API published by the system program, it may not be able to calculate an optimal route, and the driver may take longer than necessary to reach their destination. (3) Reservation System Error: If the reservation system for parking lots or charging stations depends on the version of the system program's API, the navigation device may not be able to process reservations correctly due to a version mismatch. (4) Security Vulnerabilities: Old versions of the system program's API may not have new security measures applied, increasing their vulnerability to cyberattacks.

[0012] In order to prevent such inconveniences, it is being considered to restrict (prohibit) the mobile objects 220 that can enter (enter) the application area of ​​the new system program (partial area 203) within the smart city 202, but this is inconvenient for users as they will not be able to freely enter and exit the application area of ​​the new system program.

[0013] Although such inconveniences mainly occur in basic software that controls the movement of the mobile object 220, they may also occur in application software (e.g., navigation software) if there is communication with the facility 210. Furthermore, they may also occur in mobile objects 220 other than automobiles (e.g., drones) if there is communication with the facility 210.

[0014] In view of the above-mentioned problems, the present invention provides a technique for suppressing inconveniences caused by version differences between a system program of a facility and firmware of a mobile object.

[0015] The present invention provides a program that causes an information processing device mounted on a moving body to execute the following steps: determining whether or not it is moving from a first area to a second area; if it is moving toward the second area, determining whether or not a predefined block of processing is being executed; determining whether or not it will enter the second area before the block of processing currently being executed is completed if the block of processing is being executed and the current speed is maintained; and controlling the moving speed so that, if it is determined that it will enter the second area before the block of processing currently being executed is completed, it will enter the second area only after completing the block of processing before entering the second area.

[0016] This can prevent problems caused by version differences between the equipment's system program and the mobile unit's firmware.

[0017] 1 is a diagram explaining canary release. It is a diagram illustrating a smart city. It is a diagram explaining the relationship between fixed facilities and mobile objects in a smart city. It is a diagram explaining the version switching of a vehicle's firmware. It is an example of a schematic configuration diagram of a mobility assistance system having a server device capable of communicating with a vehicle. It is a diagram showing an example configuration of an in-vehicle system possessed by a vehicle capable of autonomous driving. It is an example of a functional block diagram explaining the function of an autonomous driving control device related to the firmware switching function. It is a diagram explaining buffer zones and a block of processing. It is a diagram explaining buffer zones and a block of processing. It is a diagram explaining a block of processing. It is a diagram explaining a method for determining the speed for completing a block of processing before switching from firmware version A to firmware version B. For each of processes 1 to 3, the actual required time for the past n executions is recorded. It is an example of a flowchart explaining the processing corresponding to method 2 when a block of processing is started immediately before the boundary between the buffer zone and the application area of ​​the system program version 2. It is an example of a flowchart explaining the processing in which the autonomous driving control device suspends processing other than the processing for switching firmware for a certain period of time after the completion of a block of processing. 1 is a sequence diagram illustrating a method for determining a speed at which a group of processes is completed before switching from firmware version A to firmware version B when a vehicle and a server device communicate with each other.

[0018] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A mobility assistance system and a control method performed by the mobility assistance system will be described below with reference to the drawings as an example of an embodiment of the present invention.

[0019] [First embodiment] <Overview of software version switching> In this embodiment, when a mobile body 220 enters an area where a system program that controls equipment has been canary-released, such as part of a smart city, the version of firmware installed in the mobile body 220 is switched to a version that is compatible with the version of the system program that has been canary-released.

[0020] FIG. 4 is a diagram illustrating firmware version switching for the four-wheeled motor vehicle 223. Assume that the system program for equipment in a smart city includes versions 1 and 2. Version 2 is the newer version of the system program. In some areas of the smart city where the newer version of the system program has been canary-released, the version of the system program for the equipment is version 2. While some functions of versions 1 and 2 may be compatible, they are not completely compatible. In other words, there may be situations where firmware compatible with version 2 is not compatible with version 1. For this reason, when driving in a smart city where the system program has been canary-released in some areas, it is not sufficient for the four-wheeled motor vehicle 223 to simply upgrade its firmware to version 2 compatible in advance.

[0021] Furthermore, the mobile unit 220 has firmware version A (an example of first firmware) and firmware version B (an example of second firmware). Firmware version B may be installed externally when necessary. The canary-released system program version and firmware version will operate properly for the equipment 210 in the following combinations: - System program version 1 and firmware version A - System program version 2 and firmware version B When the mobile unit 220 enters an application area for system program version 2, the firmware is switched to version B. Therefore, if it is expected that problems will occur due to version differences between the equipment's system program and the mobile unit 220's firmware, such as in some areas of a smart city, the mobile unit 220 can automatically switch firmware versions.

[0022] <Terminology> A process block is a group of multiple processes, and switching firmware versions when only some of them are executed can cause a malfunction. A process block is also called an atomic process. In information engineering, a process block is a combination of multiple processes that appear as a single operation from the perspective of other parts of the system. A process block is automatically initiated while the vehicle 220 is moving due to factors such as the surrounding environment or the operation of the occupant. A process block is considered to be a set, and multiple processes are listed in advance. Process blocks do not necessarily have to be executed consecutively; a process block with a higher priority may be sandwiched between processes.

[0023] The mobile body 220 may be any object that can move automatically or semi-automatically on land, on water, underwater, or in the air, with or without a passenger on board. Examples of the mobile body 220 include automobiles, trains, airplanes, motorcycles, bicycles, handcarts, wheelchairs, ships, jet skis, submarines, drones, and robots.

[0024] The mobile object 220 is equipped with an information processing device. An information processing device is a device that processes information, and is also called a computer or a microcomputer. The mobile object 220 is equipped with one or more information processing devices, and the information processing devices execute programs. The programs include firmware and applications.

[0025] Furthermore, the program may be one that is executed by the mobile body 220. The program is assumed to be a program related to (for example, communicating with) equipment installed / laid in a smart city or the like. Examples of the program include basic software (sometimes called firmware) that controls the movement of the mobile body 220, and application software such as car navigation systems. Firmware refers to software that has the function of managing basic control of hardware. Firmware is a type of software that operates in the part closest to the hardware. In contrast, software that operates closer to humans is called an application. In this embodiment, the program will be described using the term firmware, but the program may also include an application.

[0026] A system program is a program that controls the equipment installed in a smart city or the like. There can be various types of system programs depending on the installation / equipment. For example, system programs control traffic lights, manage congestion information, guide moving objects, and provide store guidance.

[0027] The first area is the application area of ​​the system program Ver. 1, and the second area is the application area of ​​the system program Ver. 2.

[0028] <System Configuration Example> Fig. 5 is a schematic configuration diagram of a mobility assistance system 500 having a server device 50 that can communicate with an automobile 223. In the following, an automobile 223 will be described as an example of a moving body 220. The automobile 223 is equipped with a navigation device 40 and an automated driving system 10. The navigation device 40 and the automated driving system 10 may be integrated.

[0029] The navigation device 40 can communicate with the server device 50 via the base station 9 (access point) and the network N, and can obtain information about the smart city 202 from the server device 50.

[0030] The navigation device 40 has at least a function of searching for a route to a destination. In addition to the search function, the navigation device 40 often also has a function of displaying the route to the destination on a display mounted on the four-wheeled motor vehicle 223.

[0031] The navigation device 40 searches for a route from a departure point to a destination and sets it on a road map, displays the route and the current location on an electronic map displayed on a screen, outputs voice guidance before a course change based on the route, and provides guidance on an appropriate course using animations, etc. In addition, the navigation device 40 may have an AV (Audio Visual) playback function, an Internet communication function, etc. The navigation device 40 may also be called a tuner, a PND (Portable Navigation Device), or a car audio device.

[0032] A device that does not have a navigation function but mainly has an AV function and a communication function is called a display audio. A display audio provides navigation functions through communication with a terminal device such as a smartphone. In this case, an app installed on the smartphone creates a navigation screen, which the display audio acquires through communication and displays on the display of the in-vehicle device. Known examples of such apps that run on smartphones include CarPlay (registered trademark) and Android Auto (registered trademark). The navigation device 40 may be a display audio.

[0033] The navigation device 40 may be a general-purpose information processing terminal or a dedicated terminal for a vehicle. General-purpose information processing terminals include, for example, smartphones, tablet terminals, mobile phones, PDAs (Personal Digital Assistants), notebook PCs, and wearable PCs (for example, wristwatch-type or sunglasses-type). These devices are normally used as information processing terminals, but when application software for navigation is executed, they perform route search and route guidance, just like a dedicated terminal. Dedicated terminals include the above-mentioned navigation device 40, a tuner, or a car audio system, as well as a PND (Portable Navigation Device).

[0034] The navigation device 40 may be switchable between an in-vehicle state and a portable state, whether it is a general-purpose information processing terminal or a dedicated navigation terminal. In other words, the navigation device 40 may be detachable from the vehicle.

[0035] The server device 50 keeps track of the situation within the smart city. For example, the server device 50 manages the current version of a system program that controls facilities within the smart city 202, and provides this to the automobile 223. In addition, the server device 50 appropriately transmits to the automobile 223 information that may affect the movement of the automobile 223, such as accidents, traffic jams, and equipment failures occurring in the smart city 202.

[0036] <Functions> FIG. 6 is a diagram showing an example of the configuration of an in-vehicle system 100 provided in a vehicle capable of autonomous driving.

[0037] The following levels of autonomous driving have been defined: Level 0: The driver controls everything Level 1: The system supports either steering or acceleration / deceleration Level 2: The system supports both steering and acceleration / deceleration Level 3: The system controls everything in a specific location, with the driver controlling in an emergency Level 4: The system controls everything in a specific location Level 5: The system controls everything regardless of location In this embodiment, a situation is assumed in which firmware is switched before the automated four-wheeled vehicle 223 autonomously enters a specific area of ​​a smart city where a new version of the system program has been canary released. Level 2 autonomous driving has been put into practical use at least on expressways. In this embodiment, the in-vehicle system 100 is capable of autonomous driving at level 2 or higher. Furthermore, autonomous driving at level 2 or higher is not required; the in-vehicle system 100 of this embodiment is only required to be able to automatically control vehicle speed like cruise control.

[0038] As shown in FIG. 6 , the in-vehicle system 100 includes a navigation device 40 and an autonomous driving system 10. The navigation device 40 may have an existing configuration. For example, the navigation device 40 is compatible with a Global Navigation Satellite System (GNSS), such as a GPS receiver, and detects the current location of the vehicle and displays the vehicle's position on an electronic map. The navigation device 40 also accepts input of a departure point and a destination, searches for a route from the departure point to the destination, and displays the route on an electronic map, and provides guidance to the vehicle occupants on the direction of travel before a lane change by voice, text (displayed on a display), animation, or the like.

[0039] The navigation device 40 does not have to be fixed to the vehicle. That is, the in-vehicle system 100 may communicate with a navigation server via the communication device 41, and receive an electronic map or a route to a destination from the server.

[0040] The in-vehicle system 100 has a communication device 41. The communication device 41 communicates with an external device via a network N. The network N is, for example, a mobile communication network such as 3G, 4G, 5G, or 6G, or a wireless LAN. Alternatively, the communication device 41 may communicate via road-to-vehicle communication or vehicle-to-vehicle communication. The external device may be on the network N. The external device is, for example, a server device 50 that manages a smart city and provides information related to vehicle movement, such as traffic congestion information, weather information, or disaster information.

[0041] For example, the communication device 41 may inquire of an external device regarding the presence or absence of information in response to an operation by the occupant or periodically and automatically, and, when a traffic jam or the like occurs, may receive information such as the location of the traffic jam and the distance the traffic jam will last. If a push notification can be sent from the external device to the communication device 41, the communication device 41 need not inquire of the external device. Furthermore, when a destination is set in the navigation device 40, the communication device 41 inquires of the smart city server device 50 whether a canary release of the system program is in progress at the destination (or along the route to the destination). If a canary release of the system program is in progress, the communication device 41 inquires of the smart city server device 50 regarding the version of the canary release system program. The navigation device 40 notifies the automated driving system 10 of the canary release system program version. The automated driving system 10 can switch to a firmware version associated with the canary release system program version. The communication device 41 may also obtain the target firmware version itself from the smart city server device 50.

[0042] The communication device 41 may communicate with an information processing terminal such as a smartphone carried by a user via short-range wireless communication such as Bluetooth (registered trademark). In this case, the information processing terminal communicates with the server device 50.

[0043] The navigation device 40 and the autonomous driving system 10 communicate with each other via an in-vehicle network NW such as a Controller Area Network (CAN) bus. The autonomous driving system 10 includes an external sensor 11, an engine ECU (Electronic Control Unit) 13, a brake ECU 14, a steering ECU 15, and an autonomous driving control device 12.

[0044] The external sensors 11 include a camera 18 that can capture images of the vehicle's surroundings, a radar 17 (millimeter-wave radar, LiDAR: Light Detection and Ranging, Laser Imaging Detection and Ranging) that detects obstacles, and a wireless communication unit 19. The camera 18 is mainly used to recognize driving lanes and obstacles, and to detect the distance and position of the obstacles. The camera 18 may be a stereo camera or a monocular camera, but a stereo camera is preferable for calculating the spatial position of an obstacle. However, there are techniques for calculating the spatial position of an obstacle even with a monocular camera. The radar 17 is used to detect the distance and direction to an obstacle. The wireless communication unit can obtain the vehicle's current location or the vehicle's current direction of travel by receiving signals from traffic lights, road signs, beacons embedded in the road surface, etc.

[0045] The engine ECU 13 is a computer (electronic control unit) that controls the engine. In response to control from the automatic driving control device 12, the engine ECU 13 performs feedback control of the throttle opening and fuel injection amount in response to the difference between a target vehicle speed and the current vehicle speed, and the difference between a target TTC (Time to Collision) and the current TTC, for example, so that the vehicle can travel at a constant speed or can follow a preceding vehicle. In addition, the engine ECU 13 controls the transmission based on an automatic shift map to perform downshifts and upshifts.

[0046] The brake ECU 14 performs automatic braking and emergency braking in response to control from the automatic driving control device 12. The brake ECU 14 also controls the braking force of each wheel of the vehicle even without the driver of the vehicle operating the brake pedal, for example, ABS (Antilock Braking System) control and stop state maintenance control when starting on a slope.

[0047] The steering ECU 15 sets a target driving line so that the vehicle will travel in the center of the driving lane, and steers the vehicle in a direction to maintain driving on this line or in a direction to avoid approaching an obstacle, without the need for steering wheel operation by the vehicle occupant, in accordance with control from the automatic driving control device 12. The steering ECU 15 also performs steering necessary for lane changes and for turning right or left to travel along a route.

[0048] The autonomous driving control device 12 communicates with the navigation device 40 to accurately determine the vehicle's position, and then controls the engine ECU 13, brake ECU 14, and steering ECU 15 to travel in compliance with traffic laws and regulations based on the route to the destination. If the external sensor 11 does not detect any obstacles ahead, the vehicle travels in the center of the driving lane on the route at the legal speed. If the external sensor 11 detects a leading vehicle ahead, the vehicle travels in the center of the driving lane on the route, following the leading vehicle. If the leading vehicle slows down or stops, the external sensor 11 checks the status of the adjacent driving lane and, if it is clear, performs a lane change. Furthermore, if the TTC with the leading obstacle is below a threshold, emergency braking is performed. While traveling, the camera 18 monitors the status of traffic lights and the vehicle stops, starts, etc. according to the signal phase. The autonomous driving control device 12 also detects road signs using the camera 18, road-to-vehicle communication, a road information database, etc., and travels in compliance with traffic laws and regulations. If the route indicates a right or left turn, move into the lane designated for turning and steer in the direction indicated by the route.

[0049] The autonomous driving control device 12 is installed with various firmware 16 that performs control related to autonomous driving. This firmware 16 includes firmware that performs processing according to traffic light indications and road signs in smart cities, etc., as described above. While existing traffic lights and road signs are installed in smart cities, new equipment may be installed in parts of the smart city, and a new system program may be canary-released for this equipment. In this case, if firmware version A is not compatible with the system program version 2, the autonomous driving control device 12 will not be able to perform the control and processing required by the system program version 2. For this reason, firmware version B that is compatible with the system program version 2 that has been canary-released is provided in the autonomous driving control device 12.

[0050] Next, the function of the automatic driving control device 12 to switch firmware versions will be described with reference to Fig. 7. Fig. 7 is a functional block diagram illustrating the function of the automatic driving control device 12 related to the function of switching firmware. Note that Fig. 7 omits functions related to automatic driving control.

[0051] The automatic driving control device 12 has a judgment unit 21, a speed determination unit 22, a speed control unit 23, a firmware switching unit 24, and a processing stop unit 25. These functional blocks of the automatic driving control device 12 are functions or means realized by the CPU executing a program (which may also be firmware) expanded in memory.

[0052] The determination unit 21 makes various determinations regarding firmware switching, such as whether the vehicle is moving in a buffer zone 232 (see FIGS. 8A and 8B ) described below, and whether a block of processing described below is being executed.

[0053] The speed determination unit 22 determines an upper limit speed for completing one processing block within the buffer zone 232. The speed control unit 23 moves the vehicle at a speed lower than the upper limit speed determined by the speed determination unit 22.

[0054] The firmware switching unit 24 can switch between firmware version A, which is compatible with system program version 1, and firmware version B, which is compatible with system program version 2. That is, the firmware switching unit 24 switches from the current firmware to firmware that is valid in the destination area. For example, when the automobile 223 is traveling toward an area where system program version 2 is released and is traveling through the buffer zone 232, the firmware switching unit 24 switches from firmware version A to firmware version B. Similarly, when the automobile starts traveling from an area where system program version 2 is released toward an area where system program version 1 is released, the firmware switching unit 24 switches from firmware version B to firmware version A before reaching the area where system program version 1 is released.

[0055] 7, the determination unit 21, the speed determination unit 22, and the processing stop unit 25 may be included in the server device 50. In this case, the communication device 41 transmits information necessary for the processing by the determination unit 21, the speed determination unit 22, and the processing stop unit 25 to the server device 50. The communication device 41 receives the determination result by the determination unit 21 and the speed for completing a block of processing, and therefore can achieve the same effect as when the processing is performed by the automatic driving control device 12.

[0056] <Buffer Zone and Block Processing> Figures 8A and 8B are diagrams illustrating a buffer zone 232 and block processing. A four-wheeled motor vehicle 223 moves from an application area 231 of the system program version 1 to an application area 233 of the system program version 2. A buffer zone 232 is established during the movement. First, the buffer zone 232 is as follows: The buffer zone 232 is an area in which the system program controlling the equipment is compatible with both firmware version A and firmware version B. For example, the buffer zone 232 may be an area in which a traffic light controlled by the system program version 1 and a traffic light controlled by the system program version 2 are installed in the same location. Alternatively, the buffer zone 232 may be an area in which equipment compatible with both firmware version A and firmware version B (e.g., equipment controlled by the basic version of the system program version 0) is installed. In these buffer zones 232, the automatic driving system 10 switches firmware, so that the automatic driving system 10 can receive equipment services in both firmware version A and firmware version B.

[0057] The buffer zone 232 is included in the first area when the four-wheeled motor vehicle 223 is heading from the first area to the second area, and is included in the second area when the four-wheeled motor vehicle 223 is heading from the second area to the first area.

[0058] Furthermore, a "group of processes" is a group of processes that will cause a malfunction if the firmware version is switched while only some of them are being executed. For example, if the group of processes is processes 1 to 3, then switching from firmware version A to version B will cause a malfunction if only process 1 is being executed. Therefore, a group of processes that is currently being executed is a process that takes priority over firmware switching. A group of processes is defined in advance. A group of processes is automatically started to be executed while the four-wheeled motor vehicle 223 is moving, due to the surrounding conditions, the operation of the occupant, or the like.

[0059] 8A, processes 1 to 3, which are a group of processes included in firmware version A, are started in buffer zone 232. The automatic driving control device 12 wants to complete processes 1 to 3 before starting to switch to firmware version B, but it is not expected that process 3 will be able to be completed within buffer zone 232.

[0060] Therefore, in this embodiment, the automatic driving control device 12 adjusts (reduces) the vehicle's speed so that it does not enter the area where the Ver. 2 system program is applied until processes 1 to 3 are completed. That is, the automatic driving control device 12 adjusts the vehicle's speed so that it does not cross the boundary between the buffer zone 232 and the area where the Ver. 2 system program is applied until processes 1 to 3 are completed. In this embodiment, the automatic driving control device 12 reduces the speed of the automatic four-wheeled vehicle 223. Because a sudden stop of the automatic four-wheeled vehicle 223 in front of the boundary would cause inconvenience to the user, it is preferable that the automatic driving control device 12 gradually reduce the vehicle's speed without the user noticing. The navigation device 40 may also display on its display that the speed is being reduced to switch firmware. The navigation device 40 may also display the amount of delay (e.g., the difference between the original estimated arrival time and the delayed estimated arrival time) at the destination (in this embodiment, the destination in the area where the Ver. B system program is applied) due to the speed reduction.

[0061] 8B, the vehicle slows down, and process 3 is completed near the end of buffer zone 232. In this way, by determining the priority of the process for switching firmware versions and the group of processes, and by having the automatic driving control device 12 control the processes, it is possible to complete the execution of the group of processes and switch to the appropriate firmware before entering an area where the Ver. 2 system program is applied.

[0062] After completing process 3, the automatic driving control device 12 switches from firmware version A to firmware version B and cancels the speed adjustment.

[0063] As shown in Figure 9, an example of a block of processing is as follows. Figure 9 is a diagram that schematically explains a block of processing. (1) Rewrite setting value 1. In Figure 9, "123" is rewritten to "456". (2) Rewrite setting value 2. In Figure 9, "321" is rewritten to "654". (3) Rewrite setting value 3 by calculation from setting values ​​1 and 2. In Figure 9, "789" is rewritten to "999".

[0064] Suppose that switching from firmware version A to firmware version B changes the meanings of setting values ​​1 to 3 and the calculation method for setting value 3. If the automatic driving control device 12 switches from firmware version A to firmware version B after starting (1) but before completing (3), an error will occur in the calculation of setting value 3. For this reason, switching from firmware version A to firmware version B must be done after the completion of (3), which is the completion of one block of processing.

[0065] The time required for processes 1 to 3 varies depending on the process. As shown in Figure 9, if processes 1 to 3 involve calculations or memory rewriting, the time required for processes 1 to 3 is less than one second. However, if processes 1 to 3 involve downloading data from an external device or querying an external device, it will take several tens of seconds or more. It is assumed that the time required for firmware switching is several tens of seconds.

[0066] <Operation or Processing> Next, a method for determining the speed at which the automatic driving control device 12 completes a block of processing will be described with reference to FIG. 10. FIG. 10 is a diagram illustrating a method for determining the speed at which a block of processing is completed before switching from firmware version A to firmware version B. The flowchart in FIG. 10 describes the process from the "start of a decision loop" to the "end of a decision loop" for determining the vehicle speed. The decision loop is repeatedly executed at regular intervals.

[0067] The navigation device 40 is notified of the destination and the route to the destination. The communication device 41 queries the server device 50 as to whether there is a smart city between the destination and the route to the destination. If there is a smart city, the communication device 41 queries the server device 50 as to whether a new system program has been canary-released in a certain area. If a new system program has been canary-released, the communication device 41 queries the server device 50 of the smart city as to the version of the system program that has been canary-released. The navigation device 40 notifies the automated driving system 10 of the version of the system program that has been canary-released (S11). The automated driving control device 12 has been notified of the destination and the route to the destination by the navigation device 40. The automated driving system 10 determines that it is necessary to switch to a version of firmware that is compatible with the version of the system program that has been canary-released.

[0068] If the destination is changed and the vehicle is no longer traveling to a smart city, the navigation device 40 notifies the autonomous driving system 10 of the current system program version. This allows the autonomous driving system 10 to determine that firmware switching is no longer necessary.

[0069] When it is determined that the firmware needs to be switched, the determination unit 21 determines whether the vehicle is moving in the buffer zone 232 (S12). Note that the vehicle may be stopped. The buffer zone 232 is assumed to be set on the map.

[0070] If the determination in S12 is Yes, the process proceeds to S13, and if No, the process of FIG. 10 ends.

[0071] In S13, the determination unit 21 determines whether the automatic driving control device 12 is currently executing a group of processes (S13). The group of processes is defined in advance, and the determination unit 21 inquires of, for example, the OS about the processes currently being executed.

[0072] If the determination in S13 is Yes, the process proceeds to S14, and if No, the process of FIG. 10 ends.

[0073] In S14, the determination unit 21 determines whether the vehicle will cross the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program before the completion of one processing block (S14).

[0074] The judgment in S14 will be explained in detail. Assumption 1) A processing group includes n processes. Assumption 2) The estimated time required for the entire processing group is p. Assumption 3) The start time of the first process in the processing group is T1. Assumption 4) The time ratio of the xth process to the entire processing group is R. x Therefore, the progress of a batch of processing is R1 to R n (n is the number of the process that has been completed at this point). Assumption 5) The end time of the xth process is Tx. Assumption 6) The end time of the entire process block is e (= Tn). However, e is unknown during the process block, so it is not used in S14.

[0075] From the above, the elapsed time for the entire process at the end of the xth process is Tx - T1 ……(1). The progress of the entire process at the end of the xth process is Σ x K=1 R k …(2) (R1 to R x (The sum up to S15.) Therefore, (1)÷(2) = "the value obtained by dividing the value obtained by equation (1) by the value obtained by equation (2)" is the estimated value of the total required time. By adding the start time T1 to this, the completion time of the entire block of processing can be estimated. The navigation device 40 estimates the arrival time into the application area of ​​the Ver. 2 system program (this is the estimated time to arrive at the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program). The judgment unit 21 judges whether or not the "estimated arrival time < completion time calculated in S15" is satisfied.

[0076] If the determination in S14 is Yes, the process proceeds to S15, and if No, the process of FIG. 10 ends.

[0077] In S15, the speed determination unit 22 determines the speed at which the processes 1 to 3 must be completed before the four-wheeled motor vehicle 223 crosses the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program, and the speed control unit 23 controls the speed with the determined speed as the upper limit (S15). By reducing the speed, the time available for the processes 1 to 3 can be increased.

[0078] The speed determination method will now be described. For processes 1 to 3, which are a group of processes, the required time for past processing is recorded as shown in FIG. 11. FIG. 11 also records the actual required time for each of processes 1 to 3 over the past n iterations. The speed determination unit 22 acquires the recorded required time and obtains the total required time, s seconds, for the remaining processes 1 to 3. The required time, s seconds, is preferably the maximum of the recorded required times. The distance from the current position of the four-wheeled motor vehicle 223 to the application area of ​​the Ver. 2 system program is assumed to be x [m]. The current speed of the four-wheeled motor vehicle 223 approaching the application area of ​​the Ver. 2 system program is assumed to be v [m / s]. Furthermore, a processing time with sufficient leeway is assumed to be n times the maximum time required for processing (n is a real number greater than 1). From the above, if the following condition is satisfied: x ≦ v × s × n (3), it is determined that speed adjustment is necessary.

[0079] Furthermore, the speed determination unit 22 calculates the upper limit of the adjusted travel speed as follows: Adjusted travel speed = x ÷ (s × n) (4) If the vehicle travels to the boundary between the buffer zone and the application area of ​​the Ver. 2 system program at the speed calculated by equation (4), the automatic driving control device 12 can complete the group of processes 1 to 3 before arriving at the application area of ​​the Ver. 2 system program.

[0080] However, because firmware switching also takes some time, it is preferable to calculate the adjusted speed by taking into account the time t required for firmware switching. In this case, the total time s seconds required for processes 1 to 3 can be considered as "s + t." Therefore, equation (3) can be modified as follows:

[0081] When x≦v×(s+t)×n (5), it is determined that speed adjustment is necessary.

[0082] The speed determination unit 22 also calculates the upper limit of the adjusted moving speed as follows: Adjusted moving speed = x ÷ {(s + t) × n} (6) The speed control unit 23 controls the speed when moving to the application area of ​​the Ver. 2 system program, with the adjusted speed determined by equation (6) as the upper limit.

[0083] Next, the determination unit 21 determines whether or not the processing of one group is completed (S16). If the determination in S16 is Yes, the process proceeds to S17, and if No, the process repeats S16.

[0084] In S17, the firmware switching unit 24 switches from firmware version A to firmware version B (S17). The firmware switching unit 24 switches the firmware immediately after one group of processes is completed.

[0085] In this way, the automatic driving control device 12 of this embodiment switches from firmware version A to firmware version B when the automatic four-wheeled vehicle 223 enters an area where equipment is controlled by system program version 2. Furthermore, by slowing down the speed, the automatic driving control device 12 can increase the time available for a single processing block. The automatic driving control device 12 can reliably switch from firmware version A to firmware version B before the automatic four-wheeled vehicle 223 enters an area where equipment is controlled by system program version 2. Therefore, it is possible to prevent problems caused by version differences between the equipment installed in the application area of ​​system program version 2 and the firmware of the automatic four-wheeled vehicle 223.

[0086] It is also possible to speed up a block of processing and complete it in a short processing time as follows: The automatic driving control device 12 shortens the processing time by increasing the priority of the block of processing within the OS. The automatic driving control device 12 delays any other processing that is not part of the block of processing if it can be delayed. If the system has multiple CPU cores and there is a CPU core to which no processing has been assigned, the automatic driving control device 12 assigns it to the block of processing.

[0087] <<Regarding the Case Where a Block of Processing Starts Immediately Before the Boundary Between the Buffer Zone and the Application Area of ​​the System Program Version 2>> It is possible that a block of processing may start immediately before the boundary between the buffer zone 232 and the application area of ​​the system program Version 2. In this case, the following measures can be considered.

[0088] Method 1: The automatic driving control device 12 significantly reduces the speed (or stops the vehicle in some cases) so that the vehicle does not leave the buffer zone 232 before the processing of the group is completed.

[0089] Method 2: Before starting a block of processing, the automatic driving control device 12 inquires of the system about the impact on the user if the block is started. The system refers to the automatic driving control device 12's OS (Operating System) and the server device for automatic driving, etc. If the impact on the user is small and it is acceptable to execute the block of processing after entering the application area of ​​the Ver. 2 system program, there will be little inconvenience, and the automatic driving control device 12 will not start the processing.

[0090] 12 is a flowchart illustrating the processing performed by Method 2 when a block of processing is started immediately before the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program. The processing in FIG. 12 assumes that firmware switching is required and that the vehicle is traveling in the buffer zone 232.

[0091] First, the determination unit 21 determines whether a block of processing is about to start (S21). Since a block of processing is defined in advance, the determination unit 21 receives (or monitors) notification of the processing to be executed from the OS and determines whether it is a block of processing.

[0092] If the determination in S21 is Yes, the process proceeds to S22, and if No, the process in FIG. 12 ends.

[0093] In S22, the determination unit 21 determines whether the current location of the vehicle is within a certain distance from the application area of ​​the Ver. 2 system program (S22). The certain distance is a threshold value used to determine whether the vehicle is immediately before the boundary between the buffer zone and the application area of ​​the Ver. 2 system program. This certain distance may be, for example, the minimum time required to execute a block of processing, or the distance traveled by the four-wheeled motor vehicle 223 when moving at its current speed or average speed. Alternatively, the certain distance may be the calculated distance multiplied by a value less than 1. The minimum time required to execute a block of processing is determined for each block of processing based on the time required for previous processing.

[0094] If the determination in S22 is Yes, the process proceeds to S23, and if the determination is No, the process proceeds to S26.

[0095] In S23, the determination unit 21 determines whether the impact on the user is small and whether it is acceptable to enter the application area of ​​the Ver. 2 system program without executing a block of processing (S23). The determination unit 21 inquires of the OS, for example, whether there is any problem if the block of processing is not executed, and obtains a response.

[0096] If the determination in S23 is Yes, the process proceeds to S24, and if No, the process proceeds to S26.

[0097] In S24, the determination unit 21 halts the processing of the block. Then, the firmware switching unit 24 switches the firmware version (S25). Since the processing has been halted, the firmware is not switched. This is because the processing of the block may be effective only in the area in question, and even if it is postponed, it is unclear whether it will be possible to execute it later.

[0098] Furthermore, in S26, the determination unit 21 determines that a block of processing is to be executed (S26). The automatic driving control device 12 executes the block of processing. Furthermore, the firmware switching unit 24 switches the firmware version (S27). The automatic driving control device 12 may stop the automatic four-wheeled vehicle 223 until the firmware version switching is completed.

[0099] By this processing, when a block of processing starts immediately before the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program, the priority of the block of processing and firmware switching can be changed. In other words, the automatic driving control device 12 can prioritize firmware switching over the block of processing. When the block of processing is prioritized, the automatic driving control device 12 can stop the four-wheeled motor vehicle 223.

[0100] <<When firmware switching is not initiated after a block of processing is completed>> After a block of processing that was being executed is completed, the firmware switching unit 24 immediately initiates firmware switching. However, there is a possibility that the vehicle will not move to the application area of ​​the Ver. 2 system program before the block of processing is completed. In such a case, stopping processing other than the firmware switching process makes it easier to determine whether firmware switching is necessary.

[0101] 13 is a flowchart illustrating the process in which the automatic driving control device 12 suspends all processes other than the firmware switching process for a certain period of time after completing a set of processes. The process in FIG. 13 is repeatedly executed while the vehicle is moving through the buffer zone 232 and it is determined that firmware switching is necessary.

[0102] First, the determination unit 21 determines whether or not one processing block has been completed (S31). If the determination in S31 is Yes, the process proceeds to S32, and if No, the process in FIG.

[0103] In S32, the processing stop unit 25 stops processing other than the firmware switching processing for a certain period of time (S32). This certain period of time may be, for example, a few seconds. The certain period of time is a sufficient time from the completion of a group of processing to the start of the firmware switching processing. Furthermore, processing other than the firmware switching processing includes communication via a network, music or video playback, destination search, etc., excluding processing necessary for vehicle movement such as autonomous driving. In other words, processing with a priority level below a certain level is stopped.

[0104] Next, the determination unit 21 determines whether a certain time has elapsed (S33). If the determination in S33 is Yes, the process proceeds to S34, and if the determination in S33 is No, the determination in S33 continues.

[0105] In S34, the determination unit 21 determines whether firmware switching has started (S34). That is, if firmware switching does not start even after a certain period of time has elapsed with processes other than firmware switching stopped (load reduced), it can be determined that firmware switching is no longer necessary, for example, because the vehicle has stopped moving to the application area of ​​the Ver. 2 system program.

[0106] If the determination in S34 is Yes, the process proceeds to S35, and if the determination is No, the process proceeds to S36.

[0107] In S35, the process stopping unit 25 enables processes other than the process of switching firmware (S35). That is, the process stopping unit 25 returns to the original state.

[0108] In S36, the process stopping unit 25 enables execution of processes other than the process of switching firmware after switching the firmware (S36). That is, the process stopping unit 25 prioritizes the switching of firmware before returning to the original state.

[0109] According to the process of FIG. 13, by stopping processes other than the process for switching firmware, it becomes easier to determine whether firmware switching is necessary.

[0110] <Major Effects> The automatic driving control device 12 of this embodiment switches from firmware version A to firmware version B when the four-wheeled vehicle 223 enters an area where equipment is controlled by system program version 2. Furthermore, the automatic driving control device 12 can increase the time available for a single processing block by slowing down the vehicle's speed. The automatic driving control device 12 can reliably switch from firmware version A to firmware version B before the four-wheeled vehicle 223 enters an area where equipment is controlled by system program version 2. Therefore, it is possible to prevent problems caused by version differences between the equipment installed in the application area of ​​system program version 2 and the firmware of the four-wheeled vehicle 223.

[0111] Second Embodiment In this embodiment, a server device 50 will be described that calculates a speed at which the four-wheeled motor vehicle 223 will not reach the application area of ​​Ver. 2 until a group of processes is completed.

[0112] The functional block diagrams of the automatic driving control device 12 and the server device 50 will be described with reference to Figures 14A and 14B. Figure 14A is a functional block diagram of the automatic driving control device 12, and Figure 14B is a functional block diagram of the server device 50. The automatic driving control device 12 has a judgment unit 21, a speed control unit 23, and a firmware switching unit 24. These functions may be the same as those in the first embodiment. The server device 50 has a communication unit 31, a judgment unit 32, a speed determination unit 33, and a processing stop unit 34. These functions may be the same as those in the first embodiment, except for the communication unit 31. The communication unit 31 communicates with a communication device 41 of the four-wheeled motor vehicle 223.

[0113] FIG. 15 is a sequence diagram illustrating a method for determining the speed at which the automobile 223 and the server device 50 communicate to complete a block of processing before switching from firmware version A to firmware version B.

[0114] S201: When the automatic driving control device 12 starts a processing block, the communication device 41 transmits the current speed and position information to the server device 50.

[0115] S202: When the communication unit 31 of the server device 50 receives the speed and position information, it executes the process of FIG. 10 . More specifically, the server device 50 executes S11 to S15 of FIG. 10 . In S13, the determination unit 32 determines whether a block of processes is being executed based on information acquired from the mobile object 220 that enables determination of whether a block of processes is being executed. In S14, based on the same information acquired from the mobile object 220 as in S14, the determination unit 32 determines whether the vehicle will cross the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program before the block of processes is completed. In S15, it is sufficient to execute a process of calculating a speed for completing processes 1 to 3 before the four-wheeled motor vehicle 223 crosses the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program.

[0116] S203: The communication unit 31 transmits to the motor vehicle 223 a message to reduce the speed together with the speed calculated to complete processes 1 to 3. The communication unit 31 also instructs the motor vehicle 223 to switch firmware immediately after one group of processes is completed.

[0117] S204: The communication device 41 of the four-wheeled motor vehicle 223 receives the speed, and the speed control unit 23 controls the speed to an upper limit of the received speed.

[0118] S205: When a group of processes is completed, the firmware switching unit switches from firmware version A to firmware version B.

[0119] 13 in the first embodiment, after a group of processes is completed in the mobile body, the server device 50 suspends processes for the four-wheeled motor vehicle 223 other than the process of switching from firmware version A, which is compatible with the system in the application domain of the system program version 1, to firmware version B, which is compatible with the system in the application domain of the system program version 2, until a certain time has passed. If the server device 50 receives a notification that the process of switching from firmware version A to firmware version B has not started even after the certain time has passed, the server device 50 enables the four-wheeled motor vehicle 223 to execute processes other than the process of switching firmware.

[0120] Also, similar to FIG. 12 in the first embodiment, before the four-wheeled motor vehicle 223 starts the processing of a group of processes, the server device 50 receives an inquiry from the four-wheeled motor vehicle 223 about the inconvenience that would occur if the group of processes were not executed, and if it determines that there would be no inconvenience, causes the four-wheeled motor vehicle 223 to cancel the processing of the group of processes and switch from firmware Ver. A to firmware Ver. B.

[0121] <Main Effects> According to this embodiment, in addition to the effects of the first embodiment, the server device 50 determines the speed for completing processes 1 to 3 before the four-wheeled motor vehicle 223 crosses the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program, thereby reducing the load on the vehicle.

[0122] [Other Application Examples] The present invention is not limited to the above-described specifically disclosed embodiments, and various modifications and changes are possible without departing from the scope of the claims.

[0123] For example, the server device 50 may be a virtual server in addition to a physically existing server.

[0124] Furthermore, in this embodiment, firmware switching has been described using a mobile object as an example, but the information processing device that executes the firmware may also be carried by a person. For example, if a person is carrying a smartphone, the smartphone switches to the firmware required for the destination facility. Before crossing the boundary between the buffer zone 232 and the application area of ​​the Ver. 2 system program, the smartphone determines the speed for completing processes 1 to 3 and instructs the user by voice or display. The smartphone may also display the speed on a wearable device such as a wristwatch.

[0125] Furthermore, in this embodiment, the case of switching from firmware version A to firmware version B has been described, but the automatic driving control device 12 also switches from firmware version B to firmware version A. The switching method may be the same as the switching from firmware version A to firmware version B.

[0126] In addition, although the present embodiment has been described as applying the new system program to a smart city, the area to which the new system program is applied is not limited to a smart city. For example, the new system program may be applied to a prefecture, a city, a town, or village within a prefecture, a part of a city, a town, or village, or a part of private land within a country.

[0127] In addition, the configuration examples in Figures 6 and 7 are divided according to main functions to make it easier to understand the processing by the autonomous driving system 10. The method of dividing the processing units or the names of the processing units does not limit the present invention. The processing of the autonomous driving system 10 can also be divided into more processing units depending on the processing content. Furthermore, it can also be divided so that one processing unit includes even more processes.

[0128] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" as used herein includes a processor programmed to perform each function by software, such as a processor implemented by electronic circuits, as well as devices such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), or a conventional circuit module designed to perform each of the above-described functions.

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

[0130] 10 Automatic driving system 40 Navigation device 50 Server device

Claims

1. A program that causes an information processing device mounted on a moving body to execute the following steps: determining whether or not the moving body is moving from a first area to a second area; determining whether or not a predefined block of processing is being executed when the moving body is moving toward the second area; determining whether or not the moving body will enter the second area before the block of processing currently being executed is completed if the current speed is maintained while the block of processing is being executed; and controlling the moving speed so that the moving body will enter the second area after completing the block of processing currently being executed when it is determined that the moving body will enter the second area before the block of processing currently being executed is completed.

2. The program described in claim 1, wherein the mobile body is capable of switching between a first firmware that is compatible with the system of the first area and a second firmware that is compatible with the system of the second area, and the program causes the information processing device to execute a step of switching from the first firmware to the second firmware immediately after the processing of the block is completed.

3. The program according to claim 2, characterized in that, when the distance x is equal to or less than n×v×s, where x is the distance from the current location of the moving body to the boundary between the first area and the second area, v is the current speed of the moving body, and s is the time required for the processing block currently being executed to be completed, and n is a real number greater than 1, the step of controlling the moving speed controls the moving speed to be less than x / n×s.

4. The program of claim 2, wherein, when the distance x is equal to or less than n×v×(s+t), the step of controlling the moving speed controls the moving speed to be less than x / {n×(s+t)}, where x is the distance from the current location of the moving body to the boundary between the first area and the second area, v is the current speed of the moving body, s is the time required for the processing block currently being executed to be completed, and t is the time required for switching from the first firmware compatible with the system of the first area to the second firmware compatible with the system of the second area, and n is a real number greater than 1.

5. The time s required for the execution of the block of processing to be completed is: s = (Tx - T1) / Σ where T1 is the start time of the block of processing, Tx is the end time of the xth operation in the block of processing, and Rx is the proportion of the time required for the xth operation in the block of processing. x K=1 R k or the time s required for the processing block currently being executed to be completed is the maximum actual time required for the processing block to be completed in the past.

6. The time s required for the execution of the block of processing to be completed is: s = (Tx - T1) / Σ where T1 is the start time of the block of processing, Tx is the end time of the xth operation in the block of processing, and Rx is the proportion of the time required for the xth operation in the block of processing. x K=1 R k or the time s required for the processing block currently being executed to be completed is the maximum actual time required for the processing block to be completed in the past.

7. The program described in claim 1, characterized in that the information processing device stops all processing other than the process of switching from first firmware compatible with the system of the first area to second firmware compatible with the system of the second area until a certain period of time has elapsed after the completion of the group of processing.

8. The program described in claim 7, characterized in that if the process of switching from the first firmware to the second firmware is not started even after the certain period of time has elapsed, a process other than the process of switching from the first firmware to the second firmware can be executed.

9. The program described in claim 2, characterized in that the information processing device executes a step of inquiring of the system about any inconveniences that would occur if the group of processes were not executed before starting the group of processes, and if a response is received that there would be no inconveniences, the program stops the group of processes and switches from the first firmware to the second firmware.

10. A program that causes a server device that communicates with a mobile object via a network to execute the following steps: determining whether the mobile object is moving from a first area to a second area based on location information of the mobile object; determining whether a predefined block of processing is being executed based on information obtained from the mobile object when the mobile object is moving toward the second area; determining whether the mobile object will enter the second area before the block of processing currently being executed is completed if the current speed is maintained while the block of processing is being executed; and controlling the moving speed of the mobile object so that the mobile object will enter the second area after completing the block of processing currently being executed before entering the second area, if it is determined that the mobile object will enter the second area before the block of processing currently being executed is completed.

11. The program described in claim 10, wherein the mobile body is capable of switching between a first firmware compatible with the system of the first area and a second firmware compatible with the system of the second area, and the server device executes a step of causing the mobile body to switch from the first firmware to the second firmware immediately after the group of processes is completed in the mobile body.

12. The program described in claim 11, characterized in that, when the distance x is equal to or less than n×v×s, where x is the distance from the current location of the moving body to the boundary between the first area and the second area, v is the current speed of the moving body, and s is the time required for the processing block currently being executed to be completed, and n is a real number greater than 1, the step of controlling the moving speed controls the moving speed to be less than x / n×s.

13. The program described in claim 11, characterized in that, when the distance x is equal to or less than n×v×(s+t), the step of controlling the moving speed controls the moving speed to be less than x / {n×(s+t)}, where x is the distance from the current location of the moving body to the boundary between the first area and the second area, v is the current speed of the moving body, s is the time required for the processing block currently being executed to be completed, and t is the time required for switching from the first firmware compatible with the system of the first area to the second firmware compatible with the system of the second area, and n is a real number greater than 1.

14. The time s required for the execution of the block of processing to be completed is: s = (Tx - T1) / Σ where T1 is the start time of the block of processing, Tx is the end time of the xth operation in the block of processing, and Rx is the proportion of the time required for the xth operation in the block of processing. x K=1 R k or the time s required for the processing block currently being executed to be completed is the maximum actual time required for the processing block to be completed in the past.

15. The time s required for the execution of the block of processing to be completed is: s = (Tx - T1) / Σ where T1 is the start time of the block of processing, Tx is the end time of the xth operation in the block of processing, and Rx is the proportion of the time required for the xth operation in the block of processing. x K=1 R k or the time s required for the processing block currently being executed to be completed is the maximum actual time required for the processing block to be completed in the past.

16. The program described in claim 10, characterized in that the server device stops all processing on the mobile body other than the process of switching from first firmware compatible with the system of the first area to second firmware compatible with the system of the second area until a certain period of time has passed after the group of processing is completed on the mobile body.

17. The program described in claim 16, characterized in that when the server device receives notification that the process of switching from the first firmware to the second firmware has not started even after the certain period of time has elapsed, it enables the server device to execute processes other than the process of switching from the first firmware to the second firmware.

18. The program described in claim 11, characterized in that the server device executes a step of receiving an inquiry from the mobile device before starting the processing of the group of processes about any inconvenience that would occur if the group of processes were not executed, and if it is determined that there is no inconvenience, causing the mobile device to cancel the processing of the group of processes and switch from the first firmware to the second firmware.

19. An information processing device mounted on a mobile object that executes the program of any one of claims 1, 2, and 4 to 9.

20. An information processing device mounted on a moving body that executes the program of claim 3.

21. A server device that executes the program of any one of claims 10, 11, and 13 to 18.

22. A server device that executes the program of claim 12.

23. A moving object whose speed is controlled by an information processing device mounted on the moving object, which executes the program of any one of claims 1, 2, and 4 to 9.

24. A moving object whose speed is controlled by an information processing device mounted on the moving object that executes the program of claim 3.

25. A moving object whose speed is controlled by a server device that executes the program of any one of claims 10, 11, and 13 to 18.

26. A mobile object whose speed is controlled by a server device that executes the program of claim 12.

Images