WO2024048328A1

WO2024048328A1 - In-vehicle device, program, and, information processing method

Info

Publication number: WO2024048328A1
Application number: PCT/JP2023/029890
Authority: WO
Inventors: 絢早川; 駿岡広
Original assignee: 株式会社オートネットワーク技術研究所; 住友電装株式会社; 住友電気工業株式会社
Priority date: 2022-09-01
Filing date: 2023-08-18
Publication date: 2024-03-07
Also published as: JP2024034849A

Abstract

This in-vehicle device is installed in a vehicle and is connected with an in-vehicle ECU via an in-vehicle network so as to be capable of communicating with the in-vehicle ECU, said in-vehicle device comprising: a storage unit in which a plurality of applications are stored; and a control unit which performs processing related to the applications, wherein the control unit adds an application stored in the storage unit to thereby expand a function that can be executed by the vehicle, and outputs, to the in-vehicle ECU corresponding to the function, the result of executing the application.

Description

In-vehicle device, program and information processing method

The present disclosure relates to an in-vehicle device, a program, and an information processing method.
This application claims priority based on Japanese Application No. 2022-139371 filed on September 1, 2022, and incorporates all the contents described in the said Japanese application.

Vehicles are equipped with an on-board ECU (Electronic Control Unit) for controlling on-board equipment such as the power train system such as engine control, and the body system such as air conditioner control. The in-vehicle ECU includes an arithmetic processing unit such as an MPU, a rewritable non-volatile storage unit such as a RAM, and a communication unit for communicating with other in-vehicle ECUs, and reads and executes a control program stored in the storage unit. This enables control of in-vehicle equipment. Furthermore, the vehicle is equipped with a relay device equipped with a wireless communication function, which communicates with a program providing device connected to a network outside the vehicle through the relay device, and controls the in-vehicle ECU from the program providing device. It is possible to download (receive) a program and update the control program of the in-vehicle ECU (for example, see Patent Document 1).

Japanese Patent Application Publication No. 2017-97851

An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is installed in a vehicle and is communicably connected to an in-vehicle ECU via an in-vehicle network, and includes a storage unit that stores a plurality of applications, and a storage unit that stores a plurality of applications. and a control unit that performs processing, and the control unit expands the functions executable by the vehicle by adding the application stored in the storage unit, and adds the execution result of the application to the function. Output to the corresponding in-vehicle ECU.

1 is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to a first embodiment. FIG. 2 is a block diagram illustrating the configuration of an in-vehicle device and the like. FIG. 2 is an explanatory diagram illustrating an example of a software hierarchy installed in an in-vehicle device. It is an explanatory diagram showing an example of an application table. FIG. 2 is an explanatory diagram showing an example of application switching. 3 is a flowchart illustrating processing of a control unit of an in-vehicle device. 12 is a flowchart illustrating processing of a control unit of an in-vehicle device according to a second embodiment.

[Problems that this disclosure seeks to solve]
The relay device of Patent Document 1 does not take into account the possibility of expanding executable functions by adding applications stored in the storage unit.

An object of the present disclosure is to provide an in-vehicle device or the like that can expand executable functions by adding applications stored in a storage unit.

[Effects of this disclosure]
According to one aspect of the present disclosure, it is possible to provide an in-vehicle device or the like that expands executable functions by adding an application stored in a storage unit.

[Description of embodiments of the present disclosure]
First, embodiments of the present disclosure will be listed and described. Furthermore, at least some of the embodiments described below may be combined arbitrarily.

(1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is installed in a vehicle, is communicably connected to an in-vehicle ECU via an in-vehicle network, and stores a plurality of applications. The control unit includes a storage unit and a control unit that performs processing related to the application, and the control unit expands the functions executable by the vehicle by adding the application stored in the storage unit, and expands the functions that the vehicle can execute. The execution result is output to the in-vehicle ECU corresponding to the function.

In this aspect, the in-vehicle device communicates with an external server such as an OTA server, obtains software programs such as applications compatible with various services used in operating the vehicle, and stores the obtained application in a storage unit. Perform the installation by doing so. The in-vehicle device is an ECU that can expand the executable functions and increase the types of services that can be supported by installing (applying) and adding new applications in this way. Function. In order to provide the requested function (service), the control unit of the in-vehicle device executes an application corresponding to the function (service), and sends the result data, request signal, or control signal generated as the execution result to the function (service). It is output (transmitted) to the in-vehicle ECU, which is responsible for the actual drive related to the service. An actuator that is driven to perform required functions (services) is directly connected to the in-vehicle ECU via a wire harness or the like. The in-vehicle ECU is, for example, a body ECU (BCU) that is responsible for drive control of body-related actuators, and is connected to the in-vehicle ECU (BCU) in response to a request signal acquired (received) from an in-vehicle device (function expansion ECU). drive actuators (vehicle-mounted devices) such as lighting devices, wipers, and door mirrors. In this way, when adding a new function (service) to a vehicle, applications that perform information processing to execute the function (service) are integrated and installed (applied) on the in-vehicle device (function expansion ECU). By doing so, it is possible to prevent the program implementation environment in the existing in-vehicle ECU connected to the in-vehicle network from being affected. As a result, even when adding new functions (services) to the vehicle, it is not necessary to re-verify programs already applied to the in-vehicle ECU. Further, in providing the function (service), distributed processing can be performed by the in-vehicle ECU and the in-vehicle device (function expansion ECU), and the processing load on the in-vehicle ECU can be reduced.

(2) In the in-vehicle device according to one aspect of the present disclosure, the storage unit stores an input/output program that performs input/output processing when the application is executed, and the input/output program and a plurality of The respective applications are linked through a common interface.

In this aspect, the storage unit of the in-vehicle device stores an input/output program for transmitting and receiving data with the in-vehicle ECU when executing an application corresponding to a requested function (service). The input/output program and each of the multiple applications are coded using, for example, a common communication socket library, and are linked through a common communication interface and connected through inter-process communication, etc. . Therefore, even if the data input/output specifications differ for each application, by intervening the input/output program in the communication between each of the multiple applications and the program executed on the in-vehicle ECU side, these applications can can ensure versatility.

(3) In the vehicle-mounted device according to one aspect of the present disclosure, an operating system is stored in the storage unit, and each of the plurality of applications is executed on the operating system.

In this aspect, the storage unit of the vehicle-mounted device stores an operating system for accessing the hardware resources of the vehicle-mounted device, and each of the plurality of applications is executed on the operating system. Therefore, even if new applications are added to the in-vehicle device, the operating system will manage the processes and control access to hardware resources for these applications to avoid conflicts in access to hardware resources. be able to.

(4) In the in-vehicle device according to one aspect of the present disclosure, the control unit acquires operator information regarding an operator of the vehicle, and selects the application to be executed according to the acquired operator information.

In this aspect, the control unit of the vehicle-mounted device acquires operator information regarding the operator of the vehicle transmitted from a mobile terminal or smart key owned by the operator of the vehicle, for example. The control unit of the in-vehicle device selects an application to be executed based on the acquired operator information and executes the selected application, so it is possible to appropriately apply functions (services) according to the operator of the vehicle. .

(5) In the in-vehicle device according to one aspect of the present disclosure, the control unit acquires vehicle status information regarding the status of the vehicle, and selects the application to be executed according to the acquired vehicle status information.

In this aspect, the control unit of the in-vehicle device obtains vehicle state information regarding the state of the vehicle by, for example, obtaining on/off signals from the IG switch, messages from the body ECU (BCU), and the like. The control unit of the in-vehicle device selects an application to be executed based on the acquired vehicle status information and executes the selected application, so that functions (services) depending on the status of the vehicle can be appropriately applied.

(6) In the in-vehicle device according to one aspect of the present disclosure, the plurality of applications stored in the storage unit are positioned at A grade, B grade, or QM in ASIL (Automotive Safety Integrity Level) of ISO26262.

In this aspect, multiple applications stored in the storage unit of the in-vehicle device, that is, applications executed by the in-vehicle device to provide various functions (services), are grade A and B in ASIL (Automotive Safety Integrity Level) of ISO26262. This is an application that is classified as grade or QM. It is assumed that all applications that can be applied to the vehicle-mounted device (Function Expansion ECU) are installed (full package installation). Even when a variety of applications coexist in this way, by setting the ASIL level of the applications installed on the in-vehicle device to A grade, B grade, or QM, it is possible to select applications that have relatively little impact on vehicle safety. , it can be carried by an on-vehicle device.

(7) A program according to an aspect of the present disclosure is installed in a computer that is installed in a vehicle, is communicatively connected to an in-vehicle ECU via an in-vehicle network, and includes a storage unit in which a plurality of applications are stored. By adding the stored application, the functions executable by the vehicle are expanded, and the execution results of the application are output to the in-vehicle ECU corresponding to the function.

In this aspect, it is possible to provide a program that causes a computer to operate as an in-vehicle device that expands executable functions by adding applications stored in the storage unit.

(8) An information processing method according to an aspect of the present disclosure includes a computer that is installed in a vehicle, is communicably connected to an in-vehicle ECU via an in-vehicle network, and includes a storage section in which a plurality of applications are stored. By adding the application stored in the section, the functions executable by the vehicle are expanded, and the execution results of the application are output to the in-vehicle ECU corresponding to the function.

In this aspect, it is possible to provide an information processing method that causes a computer to operate as an in-vehicle device that expands executable functions by adding applications stored in the storage unit.

[Details of embodiments of the present disclosure]
Specific examples of the in-vehicle device 2 and the like according to the embodiment of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is indicated by the scope of the claims, and is intended to include all changes within the meaning and scope equivalent to the scope of the claims.

(Embodiment 1)
Hereinafter, embodiments will be described based on the drawings. FIG. 1 is a schematic diagram illustrating the configuration of an in-vehicle system S including an in-vehicle device 2 according to a first embodiment. FIG. 2 is a block diagram illustrating the configuration of the in-vehicle device 2 and the like. The in-vehicle system is configured with an in-vehicle device 2 as a main device, and the in-vehicle device 2 is communicably connected to various in-vehicle ECUs 4 including a body ECU 41 and the like via an in-vehicle network 5. A relay device 3 having a function such as an Ethernet SW or a CAN gateway is connected to the in-vehicle network 5, and the relay device 3 relays communication data transmitted and received via a plurality of communication lines 51 that constitute the in-vehicle network 5. It may be something that does. The in-vehicle device 2 is communicably connected to an external server 100 connected to an external network N via an external communication device 1 .

The external server 100 is a computer such as a server connected to an external network N such as the Internet or a public line network. The external server 100 is communicably connected to a plurality of vehicles C via an external network N, and connects various application APs to the in-vehicle devices 2 of these vehicles C using, for example, OTA (Over The Air). It may also function as an OTA server that transmits (distributes).

The external communication device 1 includes an external communication section 11 and an in-vehicle communication section 12. The in-vehicle communication unit 12 is, for example, an Ethernet PHY unit that supports TCP/IP packets transmitted over a communication line 51 using an Ethernet cable such as 100BASE-T1 or 1000BASE-T1. The external communication device 1 is communicably connected to the in-vehicle device 2 via an in-vehicle communication section 12 and a communication line 51 such as an Ethernet cable.

The external communication unit 11 is a communication device for wireless communication using mobile communication protocols such as 4G, 5G, WiFi (registered trademark), and Bluetooth (registered trademark), and is connected to the external communication unit 11. Data is transmitted and received via the antenna 13 to an external server 100 or a mobile terminal 101 such as a smart phone. Communication between the outside-vehicle communication device 1 and the outside-vehicle server 100 or the mobile terminal 101 is performed via an outside-vehicle network N such as a short-range communication network, a public line network, or the Internet.

In this embodiment, the external communication device 1 is a separate device from the in-vehicle device 2, and these devices are communicably connected by the in-vehicle communication section 12, but the present invention is not limited to this. The external communication device 1 may be built into the vehicle-mounted device 2 as a component of the vehicle-mounted device 2 .

Various actuators 411 that are drive-controlled by the plurality of in-vehicle ECUs 4 mounted on the vehicle C are connected. The actuator 411 includes, for example, a wiper, a door mirror, a door lock, a lighting device, a seat drive device, a car air conditioner, a display device (HMI device), and the like. The vehicle-mounted ECU 4 may be, for example, a body ECU 41 that drives and controls body-related actuators 411 such as wipers, door locks, door mirrors, and lighting devices. Alternatively, the in-vehicle ECU 4 may be an integrated ECU (vehicle computer) that performs overall control of the vehicle C, or an individual ECU that operates under the integrated ECU.

An IG switch 6 that starts and stops the vehicle C may be connected to the body ECU 41. The operation of the engine (on or off) is acquired by the signal indicating on or off of the IG switch 6, and the application AP corresponding to when the engine is on (when the engine starts operating) or when the engine is off (when the engine is stopped) is activated. It can be a trigger. The activation trigger is not limited to these, and may be triggered by an event such as putting on and taking off a seatbelt or opening/closing a door.

The in-vehicle device 2 and the body ECU 41 are connected to a power supply device 7 such as a lead battery, a secondary battery, or an alternator via a power line 71. Other in-vehicle ECUs 4 are similarly connected to the power supply device 7, and are supplied with power from the power supply device 7. The body ECU 41 is constantly supplied with power from the power supply device 7 and is in a wake-up state, and when an operator with a mobile terminal 101 such as a smartphone or a smart key approaches the vehicle C, the mobile terminal 101 is activated. The operator information may also be acquired by performing short-range communication with, etc. When the body ECU 41 acquires the operator information, it transmits a wake-up signal to the in-vehicle device 2 in the sleep state, transitions the in-vehicle device 2 to a wake-up state, and then transfers the operator information to the in-vehicle device 2. It may also be something that is sent to.

The in-vehicle device 2 includes a control section 20, a storage section 21, an input/output I/F 22, an in-vehicle communication section 23, and the like. The in-vehicle device 2 regularly communicates with an external server, acquires various application APs using OTA (Over The Air), etc., and installs (applies) the acquired application APs to perform executable functions. It functions as a function expansion ECU that expands the Although details will be described later, the in-vehicle device 2 (function expansion ECU) selects an application AP based on the state of the vehicle C and the combination of operators, and executes the selected application AP. The in-vehicle device 2 transmits execution result data, which is the execution result of the application AP, to the in-vehicle ECU 4 corresponding to the function performed by executing the application AP. The in-vehicle ECU 4 is connected to an actuator 411 that is drive-controlled according to the function performed by the application AP by the in-vehicle device 2 .

When expanding the functions of vehicle C, it is necessary to add new application APs to perform the functions. , it is possible to prevent the software configuration applied to the existing in-vehicle ECU 4 from being affected. Therefore, even if a new application AP is added to expand the functionality, it is not necessary to verify the software configuration installed in the existing in-vehicle ECU 4. Since the in-vehicle device 2 executes the application AP to perform the expanded function, distributed processing is performed by the in-vehicle device 2 and the in-vehicle ECU 4 corresponding to the function. Thereby, the processing load on the vehicle-mounted ECU 4 can be reduced, and an increase in the specifications required for hardware resources such as memory or CPU mounted on the vehicle-mounted ECU 4 can be suppressed.

The control unit 20 is composed of a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or the like. The control unit 20 performs various control processes, calculation processes, etc. by reading out and executing the control program P (program product) and data stored in advance in the storage unit 21 . The control program P (program product) stored in the storage unit 21 may be one in which a control program P (program product) read from a recording medium M readable by the in-vehicle device 2 is stored. Further, the control program P (program product) stored in the storage unit 21 may be a program downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 21. .

The storage unit 21 is composed of a volatile memory element such as a RAM (Random Access Memory), or a non-volatile memory element such as a ROM (Read Only Memory), an EEPROM (Electrically Erasable Programmable ROM), or a flash memory. The storage unit 21 stores a control program P including a plurality of applications AP, an input/output program IP, an operating system OP, and the like. Furthermore, the storage unit 21 stores an application table, which will be described later.

The input/output I/F 22 is, for example, a communication interface for serial communication. Via the input/output I/F 22, the in-vehicle device 2 is communicably connected to a camera 221, sensors 222 such as LiDAR, RADAR, ultrasonic sensor, temperature/humidity sensor, and infrared sensor, and a display device (HMI device) such as a display. be done. Various necessary sensors 222 may be additionally connected (retrofitted) to the input/output I/F 22 according to the various added applications AP. That is, the input/output I/F 22 may be compatible with standards such as GMSL, FPD-LINK, etc., which are IFs for the camera 221 system, for example. The control unit 20 performs image processing, point cloud processing, object detection, living body detection, etc. on the image captured by the camera 221 via the input/output I/F 22 by executing various applications AP. Various types of processing can be performed.

The in-vehicle communication unit 23 is an input/output interface (Ethernet PHY unit, CAN transceiver, etc.) using a communication protocol such as Ethernet (registered trademark) or CAN (Controller Area Network). The control unit 20 communicates with the relay device 3 , the in-vehicle ECU 4 , or the external communication device 1 connected to the in-vehicle network 5 via the in-vehicle communication unit 23 .

FIG. 3 is an explanatory diagram showing an example of a software hierarchy installed in the on-vehicle device 2. The control program P stored in the storage unit 21 of the in-vehicle device 2 may include a plurality of applications AP, an input/output program IP, and an operating system OP. As for the software hierarchy (layer structure), the input/output program IP is the highest layer, and the lower layers are the application AP and the operating system OP in that order.

The plurality of applications AP are selectively executed depending on the combination of the operator of the vehicle C (operator information) and the state of the vehicle C (vehicle state information), and are switched for each operator. It is something that is carried out. The in-vehicle device 2 (function expansion ECU) acquires these application APs from the external server 100 using OTA (Over The Air) or the like, and installs them by storing them in the storage unit 21. By acquiring the application AP from the external server 100 in this manner, the functions (executable functions) that the in-vehicle device 2 can perform can be expanded according to the acquired application AP.

The input/output program IP performs processing (input/output processing) related to input/output with the in-vehicle ECU 4, which is the destination of the request signal generated as a result of executing the application AP, when executing the application AP according to the type of expanded function. I do. When the input/output program IP performs input/output processing with the in-vehicle ECU 4, that is, front-end processing for the in-vehicle ECU 4, the input/output program IP and each of the plurality of application APs are linked by a common interface, and for example, the process The device is configured to be connected by intercommunication or shared memory method. The input/output program IP and each of the plurality of application APs are coded using, for example, a common communication socket library, and each application AP and input/output program IP are coded using a process defined by the library. It may also be one that performs inter-communication. In this way, the input/output program IP performs transparent communication processing with each application AP by transmitting and receiving data assumed in advance in each application AP, and also performs transparent communication processing with each application AP. Performs data transmission/reception processing corresponding to the ECU 4.

The storage unit 21 of the in-vehicle device 2 stores an application AP and the in-vehicle ECU 4 to which the execution result (request signal) of the application AP is transmitted in association with each other, for example, in a list format (app list). It may be. In the application list, the name of the application AP (executable file name) and the ECU number (MAC address, IP address, ECUID, etc.) that uniquely identifies the in-vehicle ECU 4 corresponding to the function performed by the application AP are associated. It is defined as

When executing the input/output program IP, the control unit 20 identifies the in-vehicle ECU 4 to which the execution result (request signal) of the executed application AP is to be transmitted by reading the application list as a data file, and transmits the execution result. (request signal) is transmitted to the specified in-vehicle ECU 4. The in-vehicle ECU 4 serving as the transmission destination is an in-vehicle ECU 4 that corresponds to the function exhibited by the application AP, and is the in-vehicle ECU 4 to which an actuator 411 driven by the function is connected.

When multiple application APs are being executed simultaneously, the input/output program IP determines the priority among these application APs and performs processing (application control processing) to resolve resource conflicts, etc. between these application APs. There may be. The input/output program IP configured in this way functions as communication middleware when performing communication processing with the in-vehicle ECU 4, and is used to connect various application APs acquired from the external server 100 and various types installed in the vehicle C. It is possible to improve the compatibility and transparency with the in-vehicle ECU 4 and ensure the versatility of the application AP.

The operating system OP is, for example, basic software such as Linux (registered trademark) or AUTOSAR (registered trademark)-OS. All the application APs installed (applied) to the in-vehicle device 2 operate on the operating system OP, thereby controlling the processes or threads generated for the execution of the application APs and the access to hardware resources by the application APs. Access is controlled. The operating system OP includes, for example, a security module, device drivers such as a camera 221 and a sensor 222 connected to the input/output I/F 22, and an OTA module used when acquiring or updating an application AP from the external server 100. It may be. The operating system OP is responsible for controlling access to hardware resources such as the control unit 20, the storage unit 21, the input/output I/F 22, and the in-vehicle communication unit 23, as well as time slice processing.

FIG. 4 is an explanatory diagram showing an example of an application table. The storage unit 21 stores an application table in which an application AP specified by a combination of the operator of the vehicle C (operator information) and the state of the vehicle C (vehicle state information) is defined. The application table is configured, for example, in a matrix format, and includes an operator field and a vehicle status field as management items, and defines an application AP to be executed based on a combination of these operator and vehicle status. There may be.

In the present embodiment, for example, when the operator is User-A and the vehicle C is in the riding state, the automatic door release application AP is executed. Further, even when the operator is User-B and the user is getting into the vehicle C, the application AP to be executed is defined as automatic door release. When the engine of the vehicle C is in operation, User-A is defined as an application AP that executes a camera DMS (Driver Monitor), and User-B is defined as an application AP that executes a biosensor DMS. In this way, even if the state of the vehicle C (vehicle state information) is the same, the control unit 20 of the in-vehicle device 2 (function expansion ECU) can switch the application AP to be executed depending on the operator (operator information). Can be done.

It goes without saying that automatic door release, camera DMS, biosensor DMS, etc. are examples of applications AP that are selectively executed, and are not limited to these. Applications AP that are executed when the state of vehicle C (vehicle state information) is that the vehicle is in a vehicle include, for example, door unlocking using biometric authentication, user authentication for a shared car, user authentication and payment for a taxi or bus, etc., and child boarding. It may also include changing the door settings at the time of confirmation. Further, the application APs executed when the state of the vehicle C (vehicle state information) is that the engine is operating are, for example, various DMS (Driver Monitor), EDR (data recording), sign recognition, signal recognition, emergency vehicle C. It may include detection (sound), drive record function (data storage), etc. In addition, the application AP that is executed when the state of vehicle C (vehicle state information) is exiting the vehicle is, for example, collision warning when opening/closing a door, user authentication and payment for taxis or buses, child abandonment detection, smart home, etc. It may include cooperation, garage opening, etc.

These application APs stored in the storage unit 21 and defined in the application table may be positioned in A grade, B grade, or QM in ASIL (Automotive Safety Integrity Level) of ISO26262. The in-vehicle device 2 that functions as a function-enhanced ECU acquires and updates various application APs from the external server 100 periodically or regularly using OTA or the like, so it acquires and updates all the application APs applicable to the in-vehicle device 2. can be maintained in an executable state.

The information that becomes the original data of the application table may be information related to subscription users that is centrally managed by the external server 100. The subscription user is a user who can be the operator of the vehicle C, and the external server 100 centrally manages application AP information (user master information) desired by each user for all subscription users. The control unit 20 of the in-vehicle device 2 may periodically communicate with the out-of-vehicle server 100 and update the application table.

FIG. 5 is an explanatory diagram showing an example of application AP switching. In the illustrations in this embodiment, the in-vehicle device 2 (function expansion ECU) switches the application AP to be executed depending on the operator of the vehicle C (operator information) and the state of the vehicle C (vehicle state information) (use case ). When the state of vehicle C (vehicle state information) is when the vehicle is in the vehicle, the operator (A) and operator (B) of vehicle C are both set as an application AP that executes automatic door release (defined in the application table). ), the door automatic release application AP is executed.

When the state of vehicle C (vehicle state information) is that the engine is operating, the operator (A) sets it as an application AP that executes camera DMS, and the operator (B) sets it as an application AP that executes biosensor DMS. are doing. Therefore, when the operator (A) is in the vehicle, camera DMS is executed while the engine is operating. When the operator (B) is in the vehicle, the biosensor DMS is executed while the engine is operating.

When the state of vehicle C (vehicle state information) is when exiting the vehicle, the operator (A) and operator (B) of vehicle C are both set as an application AP that executes a door opening/closing warning (in the application table). (definition), a warning is executed when the door is opened or closed. In this way, the application AP can be switched and executed depending on the state of the vehicle C (vehicle state information). Furthermore, even if the state of vehicle C (vehicle state information) is the same and the engine is operating, the application AP executed by the operator (A) and the operator (B) will be different, depending on the operator. Application APs can be switched and executed.

FIG. 6 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 regularly performs the following processing, for example, when the vehicle C is in a starting state (IG switch 6 is on) or in a stopped state (IG switch 6 is off).

In performing the following processing, the control unit 20 of the in-vehicle device 2 periodically or regularly communicates with the external server 100 such as an OTA server to check whether there is a newly added application AP. If there is an application AP to be added, the control unit 20 of the in-vehicle device 2 acquires (downloads) the application AP to be added from the external server 100 (OTA server), stores it in the storage unit 21, and installs (applies) it. do.

When acquiring application APs from the external server 100, the control unit 20 of the in-vehicle device 2 may acquire all application APs (full package) that can be applied to the in-vehicle device 2. The in-vehicle device 2 selects the application AP to be executed depending on the operator of the vehicle C, but it is assumed that the vehicle C is operated by a plurality of different operators, such as driving. Even in such a case, since all application APs (full packages) are installed (applied) to the in-vehicle device 2 in advance, no matter which operator operates the vehicle C, the relevant operation It is possible to eliminate the need to obtain an application AP each time according to the user.

The control unit 20 of the in-vehicle device 2 may acquire user information regarding the subscription user (operator of the vehicle C) registered in the external server 100 in conjunction with the additional acquisition of the application AP. The control unit 20 of the in-vehicle device 2 grasps the application AP (provided service) requested by each subscription user (operator of vehicle C) based on the acquired user information, and updates the application table. There may be.

The control unit 20 of the vehicle-mounted device 2 acquires operator information regarding the operator of the vehicle C (S101). The control unit 20 of the vehicle-mounted device 2 acquires operator information transmitted from the mobile terminal 101 or smart key held by the operator of the vehicle C, for example, via the body ECU 41. The body ECU 41 is constantly supplied with power to the power supply device 7 and is in a wake-up state, and when an operator having a mobile terminal 101 or the like approaches the vehicle C, the body ECU 41 performs short-range communication with the mobile terminal 101. By doing so, the operator information is acquired. In this case, the body ECU 41 transmits, for example, a wake-up signal to the in-vehicle device 2 in a sleep state, transitions the in-vehicle device 2 to an activated (wake-up) state, and further transmits operator information to the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 stores the operator information acquired from the body ECU 41 and the acquisition time in the storage unit 21 in association with each other.

The control unit 20 of the in-vehicle device 2 may perform authentication processing for the operator based on the acquired operator information, and may perform the following processing only when the result of the authentication processing is positive. . When performing the authentication process, the control unit 20 of the in-vehicle device 2 may transmit the acquired operator information to the external server 100 and request the external server 100 to perform the authentication process. Alternatively, a biometric authentication device that performs fingerprint authentication or the like is connected to the in-vehicle device 2, and the control unit 20 of the in-vehicle device 2 authenticates the operator of the vehicle C using the biometric authentication device. It's okay.

The control unit 20 of the in-vehicle device 2 acquires vehicle status information regarding the status of the vehicle C (S102). The control unit 20 of the in-vehicle device 2 receives a message transmitted from each in-vehicle ECU 4 such as the body ECU 41, acquires vehicle status information included in the received message, and associates the vehicle status information with the acquisition time. It is stored in the storage unit 21. Alternatively, the control unit 20 of the in-vehicle device 2 may acquire vehicle status information based on a signal transmitted from the IG switch 6 when the IG switch 6 is turned on or off. The message is, for example, a CAN message or an IP packet, and the control unit 20 of the in-vehicle device 2 controls the vehicle based on the message ID of the CAN message, the TCP port number of the IP packet, or the data stored in the payload of these messages. Status information can be obtained. The vehicle status information indicates, for example, various statuses such as when the operator is in the vehicle, when the operator is getting off the vehicle, when the engine is running, when the engine is stopped, the vehicle speed, the operation status of various actuators 411, and whether the vehicle is in automatic operation or manual operation. Contains information.

The control unit 20 of the in-vehicle device 2 selects an application AP based on the operator information and vehicle status information (S103). The control unit 20 of the in-vehicle device 2 selects an application AP corresponding to the acquired operator information and vehicle status information, for example, by referring to an application table stored in the storage unit 21. The application table is stored in the storage unit 21 in a matrix format, for example, and the control unit 20 of the in-vehicle device 2 efficiently selects the application AP based on the combination of operator information and vehicle status information. be able to.

The control unit 20 of the in-vehicle device 2 executes the selected application AP (S104). The control unit 20 of the in-vehicle device 2 executes the selected application AP, and transmits a message including result data, a control signal, a request signal, etc. generated as an execution result to the in-vehicle ECU 4 corresponding to the application AP. The application AP is intended to perform the functions (services) requested by the operator, and the functions (services) include, for example, automatic door unlocking, lighting of lights, collision tendency when opening and closing doors, etc. including. In performing these functions (services), the actuator 411 that is actually driven is connected to the in-vehicle ECU 4 to which request signals and the like are transmitted. The in-vehicle ECU 4 to which the actuator 411 that is driven to perform the function (service) is connected drives and controls the actuator 411 for door locks, lighting, etc. connected to itself in accordance with the received request signal (message). do. As a result, the processing load on the in-vehicle ECU 4 is reduced, and the application AP requested by the operator of the vehicle C is executed according to the state of the vehicle C, and the functions (services) requested by the operator are provided. Can be done.

The control unit 20 of the vehicle-mounted device 2 acquires vehicle status information regarding the status of the vehicle C (S105). The control unit 20 of the in-vehicle device 2 acquires vehicle state information regarding the state of the vehicle C, and stores the vehicle state information and the acquisition time in the storage unit 21 in association with each other.

The control unit 20 of the in-vehicle device 2 determines whether the vehicle status information has changed (S106). The control unit 20 of the in-vehicle device 2 determines whether a change has occurred between the currently acquired vehicle status information and the previously acquired vehicle status information.

If the vehicle state information changes (S106: YES), the control unit 20 of the on-vehicle device 2 performs a loop process to execute the process of S103 again. When the vehicle state information changes, the control unit 20 of the in-vehicle device 2 selects an application AP based on the combination of the current state of the vehicle C and the operator by performing loop processing to execute the process of S103 again. and can be executed. Thereby, it is possible to select and execute an appropriate application AP in accordance with changes in the state of the vehicle C.

If the vehicle status information has not changed (S106: NO), the control unit 20 of the in-vehicle device 2 determines whether the operator has left the vicinity of the vehicle C (S107). If the vehicle status information has not changed, the control unit 20 of the on-vehicle device 2 determines whether the operator has left the vicinity of the vehicle C, for example, by communicating with the body ECU 41. The mobile terminal 101 or smart key held by the operator and the body ECU 41 perform short-range communication using, for example, RF (Radio Frequency) or LF (Low Frequency). It is periodically determined whether the vehicle C is inside or outside the vehicle C and within a predetermined distance. The control unit 20 of the vehicle-mounted device 2 determines whether the operator has left the vicinity of the vehicle C, for example, by acquiring information regarding the operator's position from the body ECU 41.

If the operator is not far from the vicinity of the vehicle C (S107: NO), the control unit 20 of the in-vehicle device 2 performs a loop process to execute the process from S105 again. If the operator is not far from the vicinity of the vehicle C, the control unit 20 of the in-vehicle device 2 continues to acquire vehicle status information regularly or periodically by executing the process from S105 again. Can be done. Thereby, while the operator is not far from the vicinity of the vehicle C, it is possible to continuously select and execute an appropriate application AP according to the regularly acquired vehicle status information. If the operator leaves the vicinity of the vehicle C (S107: YES), the control unit 20 of the in-vehicle device 2 ends the processing in this flowchart.

(Embodiment 2)
FIG. 7 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2 according to the second embodiment. The in-vehicle device 2 according to the second embodiment performs the process of S201 similarly to the process S101 of the first embodiment.

The control unit 20 of the in-vehicle device 2 determines whether the acquired operator information is registered in the application table (S202). The control unit 20 of the in-vehicle device 2 determines whether the acquired operator information (user ID) is registered in the operator field of the application table stored in the storage unit 21.

If the operator information is not registered in the application table (S202: NO), the control unit 20 of the in-vehicle device 2 acquires user information corresponding to the operator information from the external server 100 (S2021). If the operator information is not registered in the application table, the control unit 20 of the in-vehicle device 2 transmits the acquired operator information to the outside server 100, and sends the acquired operator information to the outside server 100, and sends the user information corresponding to the operator information to the outside server 100. request. The operator information includes, for example, a user ID that uniquely indicates the operator. The external server 100 centrally manages (master registration) data regarding the operator of the vehicle C who is a subscription user, and lists the services requested by each user (user ID), that is, the application APs to be executed. It is preserved. The control unit 20 of the in-vehicle device 2 transmits operator information including a user ID etc. to the out-of-vehicle server 100, so that an application to be executed corresponding to the operator is sent from the out-of-vehicle server 100 that centrally manages information of all users. Obtain user information including AP.

The control unit 20 of the in-vehicle device 2 updates the application table based on the acquired user information (S2022). Based on the acquired user information, the control unit 20 of the in-vehicle device 2 determines the operator (user ID) of the currently acquired operator information and the request that the operator (user ID) executes in each vehicle state C. Information regarding the application AP (service provided) is additionally registered in the application table.

When the number of subscription users registered in the external server 100 increases and becomes enormous, registering (mirroring) information regarding all users in the application table of each vehicle C requires storage in the storage unit 21. There are concerns that this will lead to a tightening of the territory. Therefore, by additionally registering information regarding a new operator (user ID) in the application table of each vehicle C as necessary, it is possible to prevent the storage area of the storage unit 21 from becoming full.

Since the in-vehicle device 2 regularly executes OTA processing by the external server 100, all application APs applied to the in-vehicle device 2 are stored in the storage unit 21 of the in-vehicle device 2 (full package installed). ing. Therefore, since each application AP defined in the application table has already been installed, even when registering a new operator (user ID), the application AP must be installed in conjunction with the user registration. can be made unnecessary. Alternatively, the control unit 20 of the in-vehicle device 2 may acquire the application AP requested by the new operator (user ID) from the external server 100 in conjunction with the registration of a new operator (user ID).

If the operator information is registered in the application table (S202: YES), the control unit 20 of the in-vehicle device 2 acquires vehicle status information regarding the status of the vehicle C (S203). The control unit 20 of the in-vehicle device 2 performs S203 in the same manner as the process S102 of the first embodiment. After executing S203, the control unit 20 of the in-vehicle device 2 performs the processes from S204 to S208, similar to the processes from S103 to S107 of the first embodiment.

The embodiments disclosed herein are illustrative in all respects and should not be considered restrictive. The scope of the present invention is indicated by the scope of the claims, not the meaning described above, and is intended to include meanings equivalent to the scope of the claims and all changes within the scope.

Multiple claims described in the scope of claims may be combined with each other regardless of the citation format. The claims contain multiple dependent claims that are dependent on several claims. In the claims, multiple dependent claims that are dependent on multiple dependent claims are not recited, but multiple dependent claims that are dependent on multiple dependent claims may be recited.

S In-vehicle system C Vehicle N Ex-vehicle network 100 Ex-vehicle server (OTA server)
101 Mobile terminal 1 External communication device 11 External communication section 12 In-vehicle communication section 13 Antenna 2 On-vehicle device (function expansion ECU)
20 Control unit 21 Storage unit M Recording medium P Control program (program product)
AP Application IP Input/output program OP Operating system 22 Input/output I/F
221 Camera 222 Sensor 23 In-vehicle communication section 3 Relay device 4 In-vehicle ECU
41 Body ECU
411 Actuator 5 In-vehicle network 51 Communication line 6 IG switch 7 Power supply device 71 Power line

Claims

An in-vehicle device installed in a vehicle and communicably connected to an in-vehicle ECU via an in-vehicle network,
a storage unit in which multiple applications are stored;
and a control unit that performs processing related to the application,
The control unit includes:
Expanding the functions executable by the vehicle by adding the application stored in the storage unit,
An in-vehicle device that outputs an execution result of the application to an in-vehicle ECU corresponding to the function.
The storage unit stores an input/output program that handles input/output processing when the application is executed,
The in-vehicle device according to claim 1, wherein the input/output program and each of the plurality of applications are linked through a common interface.
The storage unit stores an operating system,
The in-vehicle device according to claim 2, wherein each of the plurality of applications is executed on the operating system.
The control unit includes:
Obtaining operator information regarding the operator of the vehicle;
The in-vehicle device according to any one of claims 1 to 3, wherein the application to be executed is selected according to the acquired operator information.
The control unit includes:
obtaining vehicle status information regarding the status of the vehicle;
The in-vehicle device according to claim 4, wherein the application to be executed is selected according to the acquired vehicle state information.
The plurality of applications stored in the storage unit comply with ASIL of ISO26262.
The in-vehicle device according to claim 5, which is positioned as A grade, B grade, or QM in (Automotive Safety Integrity Level).
A computer installed in a vehicle, communicably connected to an in-vehicle ECU via an in-vehicle network, and including a storage unit in which multiple applications are stored;
Expanding the functions executable by the vehicle by adding the application stored in the storage unit,
A program that executes a process of outputting an execution result of the application to an in-vehicle ECU corresponding to the function.
A computer installed in a vehicle, communicably connected to an in-vehicle ECU via an in-vehicle network, and including a storage unit in which a plurality of applications are stored;
Expanding the functions executable by the vehicle by adding the application stored in the storage unit,
An information processing method that outputs an execution result of the application to an in-vehicle ECU corresponding to the function.