Information processing device, information processing method, non-transitory storage medium and vehicle
By designing an information processing device in the vehicle network system, and using the coordination between the processor and module, the problems of multi-task matching and control interference are solved, and efficient coordination of vehicle movements and convenience of application development are achieved.
Patent Information
- Application Number
- CN202110907245.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-11-10
- Filing Date
- 2021-08-09
- Publication Date
- 2024-12-20
- Estimated Expiration
- 2041-08-09
AI Technical Summary
Existing vehicle network systems are difficult to avoid control interference while ensuring the matching of multiple tasks, resulting in complexity and inefficiency of vehicle motion control.
An information processing device is designed to initiate an application based on the vehicle's operation plan through a processor, receive and convert instructions to control vehicle equipment, manage the external and internal states of the vehicle, and ensure task matching and coordination of vehicle control. The device includes a service application, an instruction library, a travel system control unit, an information sharing entrance and an integration manager. Through API calls and coordination between modules, the overall control of the vehicle is realized.
It ensures matching and coordination of vehicle control in a multi-task environment, reduces control interference, improves vehicle movement efficiency and application development convenience, and avoids inspection work hours for adverse conditions.
Smart Images

Figure CN114454824B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to an information processing device mounted on a vehicle, an information processing method, a non-transitory storage medium, and a vehicle. Background Art
[0002] Japanese Patent Application Laid-Open No. 2006-142994 discloses a vehicle network system that can shorten the development period even when developing a complex large-scale system. In the vehicle network system, a distributed control platform structure divided into multiple levels is constructed for a network across multiple electronic control units (ECUs), and each level plays its own role, thereby achieving cooperative control.
[0003] The system described in Japanese Patent Application Laid-Open No. 2006-142994 is a structure that aims to realize a single complex action such as vehicle motion by cooperating with multiple electronic control devices and actuators. Therefore, it is difficult to avoid control interference while ensuring compatibility between multiple independent and different tasks. Summary of the invention
[0004] The present disclosure provides an information processing device, an information processing method, a non-transitory storage medium, and a vehicle that are capable of appropriately controlling a vehicle while ensuring compatibility of a plurality of tasks.
[0005] The information processing device mounted on a vehicle according to the first embodiment of the present disclosure includes a processor. The processor is configured to issue a startup instruction for an application based on a vehicle operation plan. The processor is configured to accept a first instruction as a request from an application that is started according to the startup instruction. The processor is configured to transform the accepted first instruction into a second instruction used in controlling the vehicle for realizing the request. The processor is configured to control a device mounted on the vehicle based on the second instruction.
[0006] In the information processing device involved in the first embodiment of the present disclosure, the processor may be configured to manage the external state of the vehicle and the internal state of the vehicle. The external state of the vehicle and the internal state of the vehicle may include at least scene information. The processor may be configured to transform the first instruction into the second instruction based on the managed external state and the managed internal state.
[0007] In the information processing device according to the first aspect of the present disclosure, the processor may be configured to manage a control mode that at least instructs the behavior of a vehicle. The processor may be configured to convert the first instruction into the second instruction based on the managed control mode.
[0008] The information processing method involved in the second mode of the present invention comprises: issuing a startup instruction for an application based on the operation plan of the above-mentioned vehicle; accepting a first instruction as a request from the above-mentioned application started according to the above-mentioned startup instruction; converting the above-mentioned accepted first instruction into a second instruction used in controlling the above-mentioned vehicle for realizing the above-mentioned request; and controlling the equipment installed in the above-mentioned vehicle based on the above-mentioned second instruction.
[0009] The non-transitory storage medium involved in the third aspect of the present disclosure stores commands that can be executed by one or more processors of an information processing device mounted on a vehicle and cause the one or more processors to perform the following functions. The above functions include: issuing an application startup instruction based on the operation plan of the above vehicle; accepting a first instruction as a request from the above application started according to the above startup instruction; converting the above accepted first instruction into a second instruction used in controlling the above vehicle for realizing the above request; and controlling a device mounted on the vehicle based on the above second instruction.
[0010] An information processing device according to a first aspect of the present disclosure is mounted on a vehicle.
[0011] According to the information processing device of the present disclosure, only necessary applications are instructed to be activated based on the vehicle's operation plan, so that the vehicle can be properly controlled while ensuring compatibility of multiple tasks. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Hereinafter, features, advantages, technical and industrial significance of exemplary embodiments of the present invention will be described with reference to the accompanying drawings, in which like reference numerals represent like components, wherein:
[0013] Figure 1 This is a functional block diagram of a vehicle control system including an information processing device according to one embodiment.
[0014] Figure 2 This is an example of a detailed process flow between the functional modules when making an operation reservation for a mobility service.
[0015] Figure 3 This is an example of a detailed process flow between each functional module when starting the operation of the mobility service.
[0016] Figure 4 It is an example of a running INDEX stored in the information storage memory.
[0017] Figure 5 This is an example of a detailed processing flow between each functional module when the operation of the travel service is terminated.
[0018] Figure 6 This is an example of a detailed process flow between each functional module when operating a transportation service in a travel service.
[0019] Figure 7 This is an example of a timetable of an operation plan stored in the information storage memory.
[0020] Fig. 8A This is an example of a start determination condition for a service mode.
[0021] Figure 8B This is an example of an arrival determination condition for a service method.
[0022] Fig. 9A This is an example of a method for creating a charging plan for a mobility service that makes use of an existing simulator.
[0023] Fig. 9B This is an example of a method for creating a charging plan in a mobility service that makes use of the simulator of the present disclosure.
[0024] Fig.10 This is an example in which the transportation plan is corrected using the method disclosed in the present invention. DETAILED DESCRIPTION
[0025] The information processing device disclosed in the present invention provides the function of a control platform that acts as a brain center for integrated control of the actions and behaviors of the entire vehicle. The function of the control platform is provided by a vehicle integrated ECU (central ECU) unit, or an off-vehicle cloud unit, or the collaboration of the vehicle integrated ECU and the off-vehicle cloud unit. By using this control platform, it is possible to ensure the compatibility of multiple tasks and properly control the vehicle.
[0026] <Implementation Method>
[0027] [structure]
[0028] Figure 1 1 is a functional block diagram of a vehicle control system including the information processing device 20 according to one embodiment of the present disclosure. Figure 1 The functional modules illustrated in the example include a service application 10, an information processing device 20, a vehicle device 30, a plant library 40, and a driving application 50. The information processing device 20 includes an instruction library 21, a travel system control unit 22, an information sharing portal 23, and an integrated manager 24. The vehicle control system can be installed in a vehicle such as an automobile.
[0029] 1. Service Application 10
[0030] The service application 10 is a functional module of an application installed to implement a service. The service is implemented by flexibly utilizing information inside and outside the vehicle and components of the vehicle. In addition to the actual work of the vehicle as a car or a product, the service also includes, for example, reservations related to the startup of applications (this application, other applications) based on set times, collection and processing of databases, recording to recording media, and wireless transmission to the outside. The application of this embodiment is configured to request (call) abstract instructions pre-defined in the instruction library 21 to the information processing device 20 via an API (Application Programming Interface). The abstract request may include additional information (service execution assumed time, priority, frequency, etc.). Companies that provide services use APIs corresponding to the purpose to program applications and can provide any service. The content of the API disclosed by companies can be changed according to the level of software developers. As a result, developers of companies can easily develop applications for implementing new functions. In this development, developers of companies do not need to understand the electronic platform assembled in the vehicle, the structure of the equipment (actuators, sensors, etc.) possessed by the vehicle, and the energy (electricity, heat, etc.) system of the vehicle. As applications, various applications can be exemplified. Applications include cockpit UX (cockpit Usere Xperience), remote services, MaaS (Mobility as a Service), energy management services, OTA (Over The Air) update services, vehicle operation reservations, energy mobility, and transportation services (departure determination, arrival determination, etc.).
[0031] The service application 10 requests various services from the instruction library 21. This request is an example of the "first instruction" of the present disclosure. In addition, the service application 10 refers to the shared information disclosed by the information sharing portal 23. In addition, the service application 10 can input a trigger indicating the start of the application from the travel system control unit 22 to the information sharing portal 23. In addition, the service application 10 can output a request to the vehicle equipment 30. In addition, the service application 10 can exchange information with the complete equipment library 40. In principle, each application of the service application 10 is executed in the vehicle, but part of the application can also be clouded.
[0032] 2. Instruction library 21
[0033] The instruction library 21 is a functional module equipped with an abstract API. The API implements control corresponding to the service request through an abstract request (service API call) related to the service from the service application 10. In other words, the instruction library 21 is a conversion unit configured to convert the request (first instruction) received from the service application 10 into a request (second instruction) for the integrated manager 24 and the travel system control unit 22. As an example, the instruction library 21 has various instructions as a library that realize the linkage of the functions shown below.
[0034] (1) A function of embodying a single or complex operation command to the vehicle device 30 (actuator, etc.). The operation command is a command for realizing a request received from the service application 10 .
[0035] (2) A function to output (send) a vehicle control mode transition trigger. The vehicle control mode determines the behavior of the vehicle (how the vehicle is used as a product).
[0036] (3) A function to start and stop the power supply. The power supply operates the system required to realize the request.
[0037] (4) A function of instructing coordination of energy supply sources for input energy demand (demand integration, demand weighting, supply availability judgment, supply source selection).
[0038] (5) Function of registering shared information in the information sharing portal 23. Shared information is processed and / or generated using various data.
[0039] (6) The function of storing the required information in the memory and operating the communication equipment inside and outside the vehicle.
[0040] (7) A timer function for starting a designated application at a set time.
[0041] The instruction library 21 outputs triggers indicating the migration of the vehicle control mode, transmits the operation plan, and notifies the reservation, etc. to the travel system control unit 22 via the information sharing portal 23. In addition, the instruction library 21 outputs a control request or a service request (the second instruction) to the integrated manager 24. In addition, the instruction library 21 has an acceptance unit. The acceptance unit accepts requests for various services from the service application 10 (the first instruction). In addition, the instruction library 21 can provide the processing information of the application to the information sharing portal 23 for disclosure. In addition, the instruction library 21 can refer to the shared information disclosed by the information sharing portal 23. In addition, the instruction library 21 can output requests to the vehicle equipment 30. In addition, the instruction library 21 can exchange information with the complete equipment library 40.
[0042] 3. Travel system control unit 22
[0043] The travel system control unit 22 is a functional module configured to perform centralized management of control conditions related to the behavior of the vehicle (usage method, action, etc.), promotion management of a series of tasks based on the operation plan, and management of the schedule, etc. As an example, the travel system control unit 22 has the following management functions.
[0044] (1) Vehicle control mode management function
[0045] The travel system control unit 22 manages the overall control of the vehicle using the following components (multiple modes and states). In addition, the travel system control unit 22 manages the behavior of each structure and system of the vehicle equipment 30. In addition, the travel system control unit 22 coordinates UX requests corresponding to the situation (TPO) in which the vehicle is located. The travel system control unit 22 is an example of a second management unit.
[0046] Main mode: Determines the overall usage of the vehicle according to the situation
[0047] <Car mode / Electric mode / Generator mode / Sleep mode>
[0048] State: manages the transition of vehicle states corresponding to sequential control phases
[0049] <Driving status (standby, start, driving, end) / Movement status (fixed, stopped, startable, driving, stop) / Transport status (standby, stop, departure, moving) / Power facility coordination status (standby, ready, charging, power supply) >
[0050] Submode: Define the control purpose and means in a single or multiple modes
[0051] <Driving sub-mode (manual, semi-automatic, fully automatic) / Charging sub-mode (rest, AC, DC, contact, non-contact, solar) / Equipment power supply sub-mode (rest, electric service, mobile preparation, passenger boarding and disembarking, OTA) / Auxiliary machine replenishment sub-mode (rest, high voltage, solar) / AC power supply sub-mode (rest, indoor, outdoor), etc.>
[0052] (2) Schedule management (scheduler) function
[0053] The mobility system control unit 22 performs reservation of the start time and end time of the designated activity or application. The mobility system control unit 22 can reserve the start and end of applications corresponding to a single service or a plurality of consecutive services at any time. A transportation service can be exemplified.
[0054] (3) Operation management function
[0055] The mobility system control unit 22 manages the progress of vehicle movement, transportation services (people flow / logistics), retention services (preparation, flexible use of space), and accompanying tasks (command functions, etc.) based on the operation schedule in the use of MaaS. For the transportation service, the mobility system control unit 22 can realize the repeated progress management of a series of movements and stops by reading the operation INDEX and the operation schedule. The operation INDEX includes information such as the location coordinates of each stop, the target time, and the accompanying tasks.
[0056] (4) Fault Operation (FOP) Management Function
[0057] Centrally manage fail-safe and FOP not only in PoV (Personally Owned Vehicle) but also in MaaS. In addition, this function includes generation of reliability information of major subsystems and system diagnosis as needed.
[0058] The travel system control unit 22 outputs indicators required for coordination and instructions for permission / prohibition of control to the integrated manager 24. In addition, the travel system control unit 22 outputs a trigger to the information sharing portal 23. The trigger instructs the service application 10 to start the application. That is, the travel system control unit 22 is an example of an instruction unit. In addition, the travel system control unit 22 obtains triggers, operation plans, reservations, etc. that indicate the migration of vehicle control modes from the instruction library 21 via the information sharing portal 23. In addition, the travel system control unit 22 can provide travel system information (control mode, operation status, UX coordination results, etc.) to the information sharing portal 23 for public disclosure. In addition, the travel system control unit 22 refers to the shared information disclosed by the information sharing portal 23. In addition, the travel system control unit 22 can read the operation INDEX and the operation plan table from the specified information storage memory. In addition, the travel system control unit 22 can provide the driving application 50 with travel system information (driving mode, destination, etc.) and refer to the information of the driving application 50.
[0059] 4. Information sharing portal 23
[0060] The information sharing portal 23 is a functional module (first management unit) configured to collect globally disclosed information (shared information) for reference by each functional module such as the service application 10, the instruction library 21, the travel system control unit 22, and the integrated manager 24. The shared information can also be referenced from each control domain connected to the vehicle integrated ECU (central ECU) through communication and the cloud outside the vehicle. As shared information, information on the state of the vehicle and the state of the surrounding area of the vehicle, scene information inside and outside the vehicle, information on the detection results of user needs, sensor input value information, current time information, and current location information can be exemplified. Each functional module can refer to the shared information of the information sharing portal 23. When referring to the shared information, each functional module does not recognize the source of generation (providing) of the shared information. In addition, the information sharing portal 23 may include a coordinator that can process information such as the vehicle's operating status, stop status, vehicle driving scene (time, weather, temperature, etc.), vehicle user authentication results, storage capacity, etc.
[0061] The information sharing portal 23 discloses shared information to the service application 10, the instruction library 21, the travel system control unit 22, the integrated manager 24, the vehicle device 30, and the driving application 50. In addition, the information sharing portal 23 can obtain the processing information of the application that can be disclosed from the instruction library 21. In addition, the information sharing portal 23 can obtain the travel system information (control mode, operating status, UX coordination result, event request, etc.), migration trigger, start trigger, etc. that can be disclosed from the travel system control unit 22. In addition, the information sharing portal 23 can obtain the coordination result that can be disclosed from the integrated manager 24. In addition, the information sharing portal 23 can obtain the general information (sensor, communication, analog signal, etc.) that can be disclosed from the vehicle device 30. The information sharing portal 23 can function as a gateway configured to output the general information obtained from the vehicle device 30 to the service application 10 unchanged. In addition, the information sharing portal 23 can obtain the driving status (stop determination result, etc.) that can be disclosed from the driving application 50. The information disclosed by the information sharing portal 23 is registered (stored) in principle in the vehicle. Part of the information can also be registered (stored) in the cloud.
[0062] 5. Integrated Manager 24
[0063] The integrated manager 24 is a functional module configured to coordinate the acceptance of requests (service API calls) from the service application 10 and physical quantity restrictions, and to determine the final instructions to the vehicle device 30 for implementing the request. The coordination is implemented based on the control status of the travel system control unit 22 and various shared information that can be referenced from the information sharing portal 23. As an example, the integrated manager 24 includes a manager for managing the functions shown below. In this embodiment, the integrated manager 24 is configured to eliminate differences (hardware differences) caused by changes in vehicle equipment.
[0064] (1) System start / stop manager (power manager) function
[0065] The integrated manager 24 controls activation and deactivation of necessary systems belonging to the vehicle based on the requested service requirements, and outputs commands (power on / off, NM trigger, communication request).
[0066] (2) Power manager function
[0067] The integrated manager 24 efficiently controls the consumption and supply of electric power such as charging and discharging, voltage conversion, etc. in the vehicle. In the present embodiment, the integrated manager 24 coordinates the fair supply of all energy demands (power, electricity) input by the vehicle (including reservations), determines whether services are allowed, determines the upper / lower limits of electric power income and expenditure, and selects the electric power supply source (high-voltage battery, charger, etc.).
[0068] (3) Thermal manager function
[0069] The integrated manager 24 efficiently controls the heat demand and supply of the vehicle such as heat dissipation and heating. In the present embodiment, the integrated manager 24 coordinates the heating request (air conditioning, component temperature control) from the service application 10. In addition, the integrated manager 24 outputs an engine start instruction or a fuel cell (FC) start instruction within the range of satisfying the fuel efficiency / displacement requirements.
[0070] (4) Motion Manager Function
[0071] The integrated manager 24 coordinates requests to the motion system configured to control functions related to the motion of the vehicle, such as "driving", "turning", and "stopping". In the present embodiment, the integrated manager 24 reflects the requirements (driving state, motion state, and transportation operation management) in the mobility system control unit 22 and new requests related to MaaS services (start prohibition, vehicle stationary request / unbanning, etc.).
[0072] The integrated manager 24 receives inputs of indicators required for coordination and control permission / prohibition instructions from the travel system control unit 22. In addition, the integrated manager 24 receives inputs of control requests (or service requests) from the instruction library 21. The integrated manager 24 can function as a gateway configured to output the control requests input from the instruction library 21 to the vehicle device 30 unchanged. In addition, the integrated manager 24 outputs coordinated instructions (ACTR, communication, drive output, etc.) for controlling the device to the vehicle device 30. That is, the integrated manager 24 is an example of a control unit. In addition, the integrated manager 24 can provide the coordination results of each manager to the information sharing portal 23 for disclosure. In addition, the integrated manager 24 refers to the shared information disclosed by the information sharing portal 23 for coordination. In addition, the integrated manager 24 can provide the driving application 50 with the response of the motion manager, the coordination results, and reference to the information related to the vehicle motion requested from the driving application 50 (acceleration, steering angle, etc.).
[0073] In addition, in addition to the above-mentioned managers, the integrated manager 24 may also include, for example, an HMI (Human Machine Interface) manager that controls functions related to electrical control (ease of use) that appropriately displays information on the vehicle's navigation screen, instruments, etc. and appropriately provides vehicle operations, and an upper manager (upper manager) that controls functions related to electrical control other than the vehicle's running system, such as the vehicle's headlights, wipers, and seats.
[0074] 6. Vehicle equipment 30
[0075] The vehicle equipment 30 is a functional module having devices such as sensors and actuators as final input and output targets of control information, action requests, data, signals, etc. As examples of the vehicle equipment 30, sensors configured to obtain information indicating the surrounding conditions of the vehicle and information indicating the state of the vehicle, sensors configured to obtain information related to vehicle driving operations (operations of accelerators, brakes, steering wheels, gear levers, etc.) by the driver, etc. In addition, as examples of the vehicle equipment 30, a power driver configured to control the power supply of the powertrain, etc., Ethernet (registered trademark) connected to the advanced driver assistance system (ADAS) or multimedia (MM), CAN (Controller Area Network) connected to the powertrain or chassis, and a shift lock, etc. can be exemplified.
[0076] The vehicle device 30 receives coordinated commands (ACTR, communication, drive output, etc.) from the integrated manager 24. In addition, the vehicle device 30 can provide general information (sensors, communication, analog signals, etc.) to the information sharing portal 23 for public disclosure. In addition, the service application 10 and the command library 21 can input requests to the vehicle device 30.
[0077] 7. Complete equipment library 40
[0078] The equipment library 40 is a functional module configured to provide a simulator configured to execute various simulations (remaining charging time estimation, mapping conversion, etc.) that can be flexibly applied to improve controllability in the service application 10, a database that can be viewed from inside and outside the vehicle, and an artificial intelligence (AI) or machine learning algorithm environment. A part or all of these environments can be installed in the vehicle or configured in the cloud.
[0079] The equipment library 40 can request the service application 10, the instruction library 21, and the driving application 50 for necessary information via a predetermined API. In addition, the equipment library 40 enables the service application 10, the instruction library 21, and the driving application 50 to obtain information as a result of a predetermined process (such as simulation) via a predetermined API. The functions of the equipment library 40 are generally installed in the vehicle, but part of the functions may be cloud-based.
[0080] 8. Driving Application 50
[0081] The driving application 50 is an application installed in the vehicle and is dedicated to driving the vehicle and assisting the vehicle, other than the application installed in the service application 10. Examples of the driving application 50 include remote driving such as automatic parking, autonomous driving (AD), autonomous driving based on MaaS (Autono-MaaS), and advanced driver assistance system (ADAS).
[0082] The driving application 50 can refer to the information (driving mode, destination, etc.) disclosed by the travel system control unit 22 via the prescribed vehicle driving API. In addition, the driving application 50 can make the travel system control unit 22 refer to information. In addition, the driving application 50 can provide the driving status (stop determination results, etc.) to the information sharing portal 23 via the prescribed vehicle driving API, and obtain the shared information (various data) disclosed in the information sharing portal 23. In addition, the driving application 50 can request the vehicle movement (acceleration, steering angle, etc.) to the integrated manager 24 via the prescribed vehicle driving API, and receive the response (coordination results, etc.) from the integrated manager 24. In addition, the driving application 50 can exchange information with the complete equipment library 40. In principle, each application of the driving application 50 is executed in the vehicle, but part of the application can also be clouded.
[0083] Since the vehicle control system of this embodiment has the above-mentioned functional modules, the vehicle control system can realize various services simply by installing applications developed without understanding the structure of the control platform, prescribed instructions, the system structure of the vehicle, and the energy system processed in the vehicle.
[0084] [control]
[0085] Reference Figure 2 to Figure 10 A specific example of a service implemented by the vehicle control system of the present disclosure will be described, which is a specific example of a case where the progress of transportation / stay or a combined service thereof (mobility service) is managed by the mobility system control unit 22 (dispatcher, operation management, vehicle control mode management).
[0086] <Mobility service: Operation reservation>
[0087] Figure 2 An example of a detailed processing flow between the functional modules when making a reservation for a travel service is shown in FIG. Figure 2 In the illustrated processing flow, the application (operation reservation application) receives a new operation schedule ( Figure 2 [a]). The operation reservation application is installed in the service application 10 from the travel system control unit 22. The operation reservation application is an application inherent to the travel system. The operation schedule is used in the operation reservation of the vehicle. It is preferred that the operation schedule is received via a remote function unit that ensures safety.
[0088] If the operation schedule is received, the operation reservation application reads out the existing operation schedule that has been reserved ( Figure 2[b]). The existing operation plan that has been booked is stored in an information storage device that is provided in the vehicle or is set externally (in a cloud configuration). In addition, the operation booking application confirms whether the new operation plan in the received operation schedule table does not conflict with the existing operation plan and is established.
[0089] When the existing operation plan does not conflict with the new operation plan and is established, the operation reservation application transmits these operation plans to the energy travel application ( Figure 2 [c]). The energy travel application is an application inherent to the travel system installed in the service application 10. The energy travel application is an application that is an option for the scheduler that can confirm whether an additional reservation can be made based on whether there is a conflict with the reservation of other services. The presence or absence of a conflict with the reservation of other services is determined based on simulations such as the time required for the moving driving route and the energy consumed, the energy consumed by the detention service, and the time required for charging at the designated equipment for energy replenishment. The energy travel application performs simulations related to the operation based on the operation plan transmitted from the operation reservation application. Simulations related to the operation are, for example, simulations of whether it is possible to move to the previous and next locations, whether the energy supply is sufficient, etc. Among them, the existing mobile preparation services of the PoV, such as charging and pre-air conditioning, are managed as other plans before and after.
[0090] The energy travel application transmits the simulation results of the running simulator to the running reservation application ( Figure 2 [d]). Based on the result received from the energy travel application, the operation reservation application responds to the provider of the operation plan table, etc., whether a new operation plan based on the operation plan table can be added ( Figure 2 [e]). When it is possible to add a new operation plan based on the operation plan table, the operation reservation application uses the API instructions inherent in the travel system to make an appointment with the dispatcher for the latest operation plan that adds the new operation plan to the existing operation plan ( Figure 2 [f]). In addition, the operation reservation application rewrites the scheduled operation plan stored in the information storage memory to the latest operation plan for updating ( Figure 2 [g]).
[0091] In addition, it is possible to implement the operation reservation management implemented by the operation reservation application and the simulation of vehicle operation implemented by the energy travel application through cloud configuration. In the case of this structure, only the dispatcher and information storage memory are used on the vehicle side (In-Car side), and the cloud side (Out-Car side) can obtain the information required for reference from the vehicle side ( Figure 2 [h]).
[0092] In addition, regarding the specifications of the operation reservation library, the library is open source and can be updated (to cope with changes in the schedule during operation, etc.). The controllable range can be changed according to the level of the vehicle user.
[0093] <Mobility service: Operation starts (common)>
[0094] Figure 3 An example of a detailed processing flow between each functional module when starting the operation of the travel service is shown in FIG. Figure 3 In the illustrated processing flow, the scheduler of the travel system control unit 22 refers to the current time disclosed by the information sharing portal 23, and sends a trigger ( Figure 3 [a]). When the trigger is sent, the scheduler reads the operation INDEX and the transport operation schedule stored in the information storage memory provided in the vehicle or set in an external (cloud configuration) storage memory ( Figure 3 [b]).
[0095] Figure 4 An example of a running INDEX stored in the information storage memory is shown in FIG. Figure 4 The illustrated operation INDEX arranges a series of services in time series based on tasks or control modes (car mode / electric mode). In addition, the operation INDEX is divided into each mode of transportation (people flow / logistics flow) or retention (preparation, flexible use of space). For the target start time in each action, the mode of transportation or retention is recorded. In the case of transportation, the identification code (operation schedule ID) that determines the operation schedule and the identification code (linked application ID) that determines the application to be started in linkage are recorded.
[0096] The scheduler publishes the start trigger at the information sharing portal 23. Furthermore, the scheduler starts the application (application X, application Y) of the service application 10 ( Figure 3 Application X and application Y control the linked tasks. The started application calls the instruction library 21 ( Figure 3 [d-1] of ). The instruction library 21 publishes the migration trigger in the information sharing entry 23 according to the call ( Figure 3 [d-2] of FIG. 2 ). The travel system control unit 22 refers to the transition trigger disclosed in the information sharing portal 23 and appropriately performs the transition to the corresponding vehicle control mode ( Figure 3 [d-3]). In addition, in the case of standard autonomous operation scenarios such as air conditioning startup or unmanned transportation, the scheduler can directly instruct the management function unit to migrate the vehicle control mode by publishing the migration trigger at the information sharing portal 23 ( Figure 3 [f, d-3]).
[0097] The power manager of the integrated manager 24 activates the corresponding power source based on the vehicle control mode or activity requirements transmitted from the travel system control unit 22 ( Figure 3 [e]). The HMI manager of the integrated manager 24 notifies the service company or the driver of the start time of the vehicle operation through multimedia (MM). Figure 3 [g]).
[0098] In addition, if the supply cannot keep up with the power demand for the service (activity), the request can be rejected (rejected). In this case, the power manager of the integrated manager 24 registers the request rejection to the information sharing portal 23 ( Figure 3 Furthermore, the application (application X, application Y) of the service application 10 refers to the request rejection ( Figure 3 <Travel service: end of operation (staying service)>
[0099] Figure 5 An example of a detailed processing flow between the functional modules when the operation of the travel service is terminated is shown in FIG. Figure 5 In the illustrated processing flow, the scheduler refers to the current time ( Figure 5 [a]), a reminder is sent when the current time reaches the scheduled end time of the operation. While sending the reminder, the scheduler publicly specifies the event request ( Figure 5 [b]). The cooperating applications (application X, application Y) refer to the event request published in the information sharing portal 23 to execute the event ( Figure 5 [c]).
[0100] When it is necessary to urge a service company or a driver to perform an action for ending the operation of the vehicle, the cooperating application (application X, application Y) notifies the service company or the driver who needs to take action through multimedia (MM). Figure 5 [d]).
[0101] If the information indicating that the vehicle operation termination condition is satisfied is disclosed at the information sharing portal 23 ( Figure 5 [e-1]), the cooperating applications (application X, application Y) call the instruction library 21 ( Figure 5 [e-2]). The instruction library 21 publishes the end trigger at the information sharing entry 23 according to the call ( Figure 5 [e-3]).
[0102] The travel system control unit 22 refers to the termination trigger ( Figure 5[f]) to end the operation mode in the vehicle control mode. In addition, in order to transition to the next service, the scheduler of the travel system control unit 22 prepares for the next task ( Figure 5 In addition, the operation mode can be terminated synchronously with the task processing in the event or under the same conditions as the task termination.
[0103] <Mobility service: Transportation service operation>
[0104] Figure 6 An example of a detailed processing flow between each functional module when a transportation service in a travel service is performed is shown in FIG. Figure 6 In the illustrated processing flow, the dispatcher of the travel system control unit 22 reads the timetable of the operation plan stored in the information storage memory provided in the vehicle or provided in an external (cloud configuration) manner ( Figure 6 [a]).
[0105] Figure 7 An example of a timetable of an operation plan stored in the information storage memory is shown in FIG. Figure 7 In the example, the information storage device stores, for each process (process number), the operation mode of the process (mode), the time to start the operation based on the mode (start time), the time to end the operation based on the mode (end time), the place where the process is aimed at (destination), information related to the flow of people in the process (people flow information), information related to the flow of goods, etc. in the process (logistics information), and information related to the tasks in the process (task information), etc.
[0106] The scheduler manages the progress of the process based on the read operation plan timetable in conjunction with the transportation status operated and managed by the travel system control unit 22 ( Figure 6 [b]). In addition, the dispatcher also intervenes in the movement of the vehicle by linking with the movement state managed by the travel system control unit 22 mode ( Figure 6 [c]).
[0107] The means for determining the transition of the transport state in each process and the accompanying tasks depend on the service mode. Therefore, in the service application 10, an appropriate application corresponding to the service mode is selected ( Figure 6[d]). As the application to be selected, there can be exemplified transportation service applications such as a departure determination dedicated application and an arrival determination dedicated application. The departure determination dedicated application (departure determination) enables the functional unit of the operation management of the travel system control unit 22 to determine the transition trigger from stay to departure based on conditions corresponding to the service method or purpose. The arrival determination dedicated application (arrival determination) enables the functional unit of the operation management of the travel system control unit 22 to determine the transition trigger from departure to stay based on conditions corresponding to changes in driving means or acquired information. In addition, as a transportation service application, an energy replenishment plan application that can reserve an advance energy replenishment plan that cooperates with the operation plan can be included. The energy replenishment plan application is an application that is an option for the scheduler.
[0108] Fig. 8A , Figure 8B An example of the departure determination condition and the arrival determination condition for the service mode is shown in Figure 1 . Regarding the departure determination condition, when the service mode is a bus, if the scheduled departure time has passed and the stay state is more than the specified time, a departure determination is made. When the service mode is on-demand transportation, if information indicating that the procedures for boarding or getting off the vehicle for the user who applied for the use of the vehicle are completed is received, a departure determination is made. According to the departure determination, the transportation state is transferred from staying to departure (moving). In addition, regarding the arrival determination condition, when the service mode is manual driving, if the vehicle is parked within a specified distance from the destination and the driver fixes the gear lever of the vehicle in the parking position (P lock), an arrival determination is made. When the service mode is automatic driving (with landmark buildings), if the vehicle is parked in a permitted specified area including landmark buildings, an arrival determination is made. When the service mode is automatic driving (without landmark buildings), an arrival determination is made if a signal is received from the automatic driving system to determine that the stay is completed.
[0109] The integrated manager 24 performs appropriate coordination through the motion manager, the upper manager, and the HMI manager based on the request and information output from the command library 21 and the mobility system control unit 22, and outputs a command ( Figure 6 [e]).
[0110] When the vehicle is operated by automatic driving, the dispatcher of the mobility system control unit 22 transmits the destination of the operation to the vehicle equipment 30 ( Figure 6 [f]). In addition, information for determining the appropriateness of the stop position may also be transmitted from the dispatcher to the vehicle device 30. On the other hand, when the vehicle is operated by manual driving, the destination of the operation ( Figure 6[g]), it is possible to provide driving guidance to the driver with the help of a navigation device installed in the vehicle.
[0111] <Mobility Services: Charging Plan>
[0112] Fig. 9A as well as Fig. 9B This is a diagram for explaining an example of a method for creating a charging plan in a mobility service using a simulator. Fig. 9A A method of creating a charging plan based on a conventional method (a representative pattern example of the current PoV) is shown. Fig. 9B A method for creating a charging plan based on the technique disclosed in the present invention is shown.
[0113] In the existing method ( Fig. 9A ), the user himself performs reverse calculation based on the arrival plan and manually sets the departure time. The timer function automatically sets the time to activate the charging function (timer reservation time) so that the energy of the vehicle battery is fully charged (full) at the departure time manually set by the user when the vehicle is plugged into the charging device connected to the vehicle before departure. In other words, the time required until full charging is estimated, and the timer reservation time is automatically set before departure.
[0114] In contrast, in the method disclosed in the present invention ( Fig. 9B ), the travel system control unit 22 automatically determines the operation route including the intermediate stop charging station equipment (rapid, normal) based on the estimation of the power balance based on the arrival plan. The travel system control unit 22 determines the necessary and sufficient energy replenishment amount of the vehicle battery in each of the plugged-in connected charging equipment and the intermediate stop charging station equipment before departure. In addition, the travel system control unit 22 automatically sets the time (timer reservation time) to start the charging function in advance before departure based on the estimation of the charging time in each device.
[0115] Fig.10 An example of using the method disclosed in the present invention to correct a delivery plan is shown in FIG. Fig.10 As shown, in the basic transportation plan, the vehicle starts moving from time a and arrives at destination C before time d. In the revised transportation plan, the vehicle battery is DC charged during the stay from time b to time c at destination B. The time of arrival at destination C is revised from time d to time e due to the stay for charging. In addition to the revision of the transportation plan, an energy replenishment plan is added. In the energy replenishment plan, vehicle charging before departure (reservation number 1) and vehicle charging at destination B (reservation number 2) are additionally specified.
[0116] If the Fig. 9A , Fig. 9B as well as Fig.10As shown, according to the method of the present disclosure, it is possible to provide automation of an operation plan that can minimize energy consumption taking into account the amount of loss and shorten the vehicle's tied-up time due to charging to maximize the vehicle's operation rate.
[0117] [Effects, etc.]
[0118] As described above, the information processing device involved in one embodiment of the present disclosure is provided with various instructions as a library in advance in the control architecture that enables the realization of activities, and the various instructions are instructions that can automatically determine various controls by simply calling predetermined abstract instructions. The various controls are, for example, complex actuator action coordination, power startup for starting necessary systems, energy supply coordination for energy demand (determination of feasibility, selection of energy supply source), and mode migration that determines the behavior of the entire vehicle.
[0119] As a result, application developers can easily develop new or additional applications (services) based on intuitive algorithmic design for the purpose. Application developers do not need to recognize the vehicle's electronic platform structure, specified instructions, system configuration (hardware changes), and energy system during development.
[0120] Furthermore, the information processing device according to the present embodiment refers to shared entry information and utilizes a command library, and can add functions by installing a new or additional application in a single unit. That is, it is not necessary to modify related applications.
[0121] In addition, application developers can easily develop new or additional applications.
[0122] Furthermore, the information processing device according to the present embodiment can avoid an increase in the man-hours for checking a malfunction caused by an unexpected behavior of the vehicle or the man-hours for checking control interference and the like.
[0123] Furthermore, the information processing device according to the present embodiment instructs activation of necessary applications based on the vehicle operation plans confirmed by simulation that the contents of the multiple plans do not conflict with each other. Therefore, the vehicle can be appropriately controlled while ensuring compatibility of the multiple tasks.
[0124] An embodiment of the technology disclosed herein has been described above, but the technology disclosed herein can be used not only as an information processing device, but also as a method executed by an information processing device having a processor and a memory, a program of the method, a computer-readable non-temporary recording medium storing the program, or a vehicle equipped with an information processing device, etc.
[0125] The present disclosure is useful in an information processing device mounted on a vehicle or the like.
Claims
1. An information processing device, mounted on a vehicle, characterized in that: The invention comprises a processor (20), wherein the processor (20) is configured as follows: providing a trigger for a start indication for applying a service application based on an operation plan of the vehicle; accepting a first command as a request from the application activated in response to the activation instruction; Managing the status of the vehicle's exterior and interior including at least information on time, location, weather, temperature, and operating conditions; Management includes at least a car mode in which the vehicle is used as a means of transportation and a control mode in which the vehicle is used as a means of power supply; The command library includes various commands that are implemented by linking functions as a library, and converts the received first command into a second command used for controlling the vehicle for implementing the request based on the managed state and the managed control mode; and controlling a device mounted on the vehicle based on the second instruction, The information processing device instructs activation of a necessary application based on a vehicle operation plan confirmed through a simulation that a plurality of plan contents do not conflict with each other.
2. An information processing method, executed by a processor (20) of an information processing device mounted on a vehicle, characterized in that: include: providing a trigger for a start indication for applying a service application based on an operation plan of the vehicle; accepting a first command as a request from the application activated in response to the activation instruction; Managing the status of the vehicle's exterior and interior including at least information on time, location, weather, temperature, and operating conditions; Management includes at least a car mode in which the vehicle is used as a means of transportation and a control mode in which the vehicle is used as a means of power supply; The command library includes various commands that are implemented by linking functions as a library, and converts the received first command into a second command used for controlling the vehicle for implementing the request based on the managed state and the managed control mode; and controlling a device mounted on the vehicle based on the second instruction, The information processing method instructs activation of a necessary application based on a vehicle operation plan confirmed through a simulation that a plurality of plan contents do not conflict with each other.
3. A non-transitory storage medium, characterized in that: A command is stored which can be executed by one or more processors (20) of an information processing device mounted on a vehicle and can cause the one or more processors (20) to execute the following functions: providing a trigger for a start indication for applying a service application based on an operation plan of the vehicle; accepting a first command as a request from the application activated in response to the activation instruction; Managing the status of the vehicle's exterior and interior including at least information on time, location, weather, temperature, and operating conditions; Management includes at least a car mode in which the vehicle is used as a means of transportation and a control mode in which the vehicle is used as a means of power supply; The command library includes various commands that are implemented by linking functions as a library, and converts the received first command into a second command used for controlling the vehicle for implementing the request based on the managed state and the managed control mode; and Based on the second instruction, the device mounted on the vehicle is controlled, The activation of the necessary application is instructed based on the vehicle operation plan confirmed through the simulation that the plurality of plan contents do not conflict with each other.
4. A vehicle, characterized in that: The information processing device according to claim 1 is mounted thereon.
