JP7760973B2 - In-vehicle device, program, and information processing method - Google Patents

Description

The present invention relates to an in-vehicle device, a program, and an information processing method.

Vehicles are equipped with an on-board ECU (Electronic Control Unit) for controlling on-board equipment such as powertrain systems (e.g., engine control) and body systems (e.g., air conditioning control). The on-board ECU includes a processing unit such as an MPU, a rewritable non-volatile memory unit such as RAM, and a communication unit for communicating with other on-board ECUs. The on-board ECU controls the on-board equipment by reading and executing control programs stored in the memory unit. Furthermore, the vehicle is equipped with a relay device with wireless communication capabilities, which allows it to communicate with a program provider connected to an external network via the relay device, download (receive) the on-board ECU's control program from the program provider, and update the on-board ECU's control program (see, for example, Patent Document 1).

Japanese Patent Application Laid-Open No. 2017-97851

However, the relay device in Patent Document 1 does not take into consideration the possibility of expanding executable functions by adding applications stored in the storage unit.

The purpose of this disclosure is to provide an in-vehicle device or the like that can expand executable functions by adding applications stored in the storage unit.

An in-vehicle device according to one aspect of the present disclosure is mounted on a vehicle and communicatively connected to an in-vehicle ECU via an in-vehicle network. The in-vehicle device includes a memory unit that stores multiple applications and a control unit that performs processing related to the applications. The control unit adds applications stored in the memory unit to expand the functions that the vehicle can execute, and outputs the execution results of the applications to the in-vehicle ECU that corresponds to the functions.

According to one aspect of the present disclosure, it is possible to provide an in-vehicle device or the like that can expand executable functions by adding applications stored in a storage unit.

1 is a schematic diagram illustrating a configuration of an in-vehicle system including an in-vehicle device according to a first embodiment; FIG. 1 is a block diagram illustrating a configuration of an in-vehicle device, etc. FIG. 2 is an explanatory diagram illustrating an example of software layers implemented in an in-vehicle device. FIG. 10 is an explanatory diagram illustrating an example of an application table. FIG. 10 is an explanatory diagram illustrating an example of application switching. 4 is a flowchart illustrating processing by a control unit of an in-vehicle device. 10 is a flowchart illustrating processing by a control unit of an in-vehicle device according to a second embodiment.

[Description of the embodiment of the present invention]
First, embodiments of the present disclosure will be listed and described. At least some of the embodiments described below may be combined in any desired manner.

(1) An in-vehicle device according to one aspect of the present disclosure is mounted on a vehicle and communicatively connected to an in-vehicle ECU via an in-vehicle network, and includes a storage unit that stores multiple applications and a control unit that performs processing related to the applications. The control unit adds applications stored in the storage unit to expand the functions that the vehicle can execute, and outputs the execution results of the applications to the in-vehicle ECU that corresponds to the functions.

In this embodiment, the in-vehicle device communicates with an external server, such as an OTA server, to acquire software programs, such as applications, corresponding to various services used in operating the vehicle, and installs the acquired applications by storing them in a memory unit. By installing (applying) new applications in this manner, the in-vehicle device is an ECU that can expand the executable functions and increase the variety of services it can support, functioning as a function-expansion ECU. To provide a requested function (service), the control unit of the in-vehicle device executes the application corresponding to the function (service) and outputs (transmits) the resulting data, request signal, or control signal to the in-vehicle ECU that actually drives the function (service). An actuator that drives the requested function (service) is directly connected to the in-vehicle ECU via a wire harness or the like. The in-vehicle ECU, for example, is a body ECU (BCU) that controls the drive of body actuators. In response to request signals received from an in-vehicle device (function-expansion ECU), the ECU drives actuators (in-vehicle devices) connected to the BCU, such as lighting devices, wipers, and door mirrors. When adding a new function (service) to a vehicle, the application that performs the information processing required to execute the function (service) is centralized and installed in the in-vehicle device (function-expansion ECU), preventing any impact on the program implementation environment of existing in-vehicle ECUs connected to the in-vehicle network. This eliminates the need to re-verify programs already applied to the in-vehicle ECU, even when adding a new function (service) to the vehicle. Furthermore, when providing the function (service), distributed processing can be performed between the in-vehicle ECU and the in-vehicle device (function-expansion ECU), reducing the processing load on the in-vehicle ECU.

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

In this aspect, the storage unit of the in-vehicle device stores an input/output program for transmitting and receiving data to and from the in-vehicle ECU when executing an application corresponding to a required 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 via a common communication interface and connected via inter-process communication, etc. Therefore, even if the data input/output specifications for each application are different, the versatility of these applications can be ensured by using the input/output program in communication between each of the multiple applications and the program executed on the in-vehicle ECU.

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

In this embodiment, the storage unit of the in-vehicle device stores an operating system for accessing the in-vehicle device's hardware resources, and each of the multiple applications runs on that operating system. Therefore, even if new applications are added to the in-vehicle device, the operating system manages the processes and controls access to hardware resources for these applications, preventing conflicts with access to hardware resources.

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

In this aspect, the control unit of the in-vehicle device acquires operator information about the vehicle operator, transmitted, for example, from a mobile device or smart key carried by the vehicle operator. The control unit of the in-vehicle device selects an application to run based on the acquired operator information and executes the selected application, thereby appropriately applying functions (services) appropriate for the vehicle operator.

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

In this embodiment, the control unit of the in-vehicle device acquires vehicle status information regarding the vehicle's condition by, for example, receiving an on/off signal from the IG switch, a message from the body ECU (BCU), etc. The control unit of the in-vehicle device selects an application to run based on the acquired vehicle status information and executes the selected application, thereby appropriately applying functions (services) according to the vehicle's status.

(6) In an in-vehicle device according to one aspect of the present disclosure, the multiple applications stored in the memory unit are rated as Grade A, Grade B, or QM in the ASIL (Automotive Safety Integrity Level) of ISO 26262.

In this embodiment, the multiple applications stored in the memory unit of the in-vehicle device, i.e., the applications executed by the in-vehicle device to provide various functions (services), are applications that are classified as Grade A, Grade B, or QM in the ASIL (Automotive Safety Integrity Level) of ISO 26262. It is assumed that all applications that can be applied to the in-vehicle device will be installed (full package installation) in the in-vehicle device (function-enhanced ECU). Even when a wide variety of applications are mixed in this way, by setting the ASIL level of the applications installed in the in-vehicle device to Grade A, Grade B, or QM, the in-vehicle device can be responsible for applications that have a relatively small impact on vehicle safety.

(7) A program according to one aspect of the present disclosure is mounted on a vehicle, communicatively connected to an on-board ECU via an on-board network, and includes a memory unit in which multiple applications are stored. By adding the applications stored in the memory unit to the computer, the program expands the functions that the vehicle can execute, and outputs the execution results of the applications to the on-board ECU corresponding to the functions.

In this aspect, a program can be provided 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 one aspect of the present disclosure extends the functions executable by a vehicle by adding applications stored in a storage unit of a computer that is mounted on a vehicle, communicatively connected to an on-board ECU via an on-board network, and stores multiple applications, and outputs the execution results of the applications to the on-board ECU corresponding to the functions.

In this aspect, an information processing method can be provided that operates a computer as an in-vehicle device that expands executable functions by adding applications stored in a storage unit.

[Details of the embodiments of the present disclosure]
Specific examples of the in-vehicle device 2 according to the embodiments 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 defined by the claims, and is intended to include all modifications within the meaning and scope of the claims.

(Embodiment 1)
Hereinafter, embodiments will be described with reference to 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 the first embodiment. FIG. 2 is a block diagram illustrating the configuration of the in-vehicle device 2 and other components. The in-vehicle system is configured with the in-vehicle device 2 as a main device, and the in-vehicle device 2 is communicatively connected to various in-vehicle ECUs 4, including a body ECU 41, via an in-vehicle network 5. A relay device 3 having functions such as an Ethernet switch or a CAN gateway is connected to the in-vehicle network 5, and the relay device 3 may relay communication data transmitted and received via multiple communication lines 51 that constitute the in-vehicle network 5. The in-vehicle device 2 is communicatively connected to an external server 100 connected to an external network N via an external communication device 1.

The off-vehicle server 100 is a computer such as a server connected to an off-vehicle network N, such as the Internet or a public line network. The off-vehicle server 100 is communicatively connected to multiple vehicles C via the off-vehicle network N, and may function as an OTA (Over The Air) server that transmits (distributes) various applications AP to the on-board devices 2 of these vehicles C, for example, using OTA (Over The Air).

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

The exterior communication unit 11 is a communication device for wireless communication using a mobile communication protocol such as 4G, 5G, Wi-Fi (registered trademark), or Bluetooth (registered trademark), and transmits and receives data to and from an exterior server 100 or a mobile terminal 101 such as a smartphone via an antenna 13 connected to the exterior communication unit 11.
The communication with the vehicle is performed via an external network N such as a short-range communication network, a public line network, or the Internet.

In this embodiment, the external-vehicle communication device 1 is a separate device from the in-vehicle device 2, and these devices are communicatively connected via an in-vehicle communication unit 12 or the like, but this is not limited to this. The external-vehicle communication device 1 may also be built into the in-vehicle device 2 as a component of the in-vehicle device 2.

Various actuators 411 that are driven and controlled by the on-board ECUs 4 are connected to multiple on-board ECUs 4 mounted on the vehicle C. The actuators 411 include, for example, wipers, door mirrors, door locks, lighting devices, seat drive devices, car air conditioners, and display devices (HMI devices). As an example, the on-board ECU 4 may be a body ECU 41 that drives and controls body-related actuators 411 such as wipers, door locks, door mirrors, and lighting devices. Alternatively, the on-board 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 control of the integrated ECU.

An IG switch 6 that starts and stops the vehicle C may be connected to the body ECU 41. The engine operation (on or off) can be obtained from a signal indicating whether the IG switch 6 is on or off, and this can be used as a start-up trigger for an application AP that corresponds to when the engine is on (when the engine starts operating) or when the engine is off (when the engine is stopped). The start-up trigger is not limited to this, and events such as fastening or unfastening a seat belt, opening or closing a door, etc. may also be used as a start-up trigger.

The in-vehicle device 2 and body ECU 41 are connected to a power supply device 7, such as a lead battery, secondary battery, or alternator, via a power line 71. The other in-vehicle ECUs 4 are similarly connected to the power supply device 7 and receive power from the power supply device 7. The body ECU 41 is constantly powered by the power supply device 7 and is in an activated (wake-up) state. When an operator with a mobile terminal 101 such as a smartphone or a smart key approaches the vehicle C, the body ECU 41 may acquire operator information by short-range communication with the mobile terminal 101. When the body ECU 41 acquires the operator information, it may transmit a wake-up signal to the in-vehicle device 2, which is in a sleep state, to transition the in-vehicle device 2 to an activated (wake-up) state, and then transmit the operator information to the in-vehicle device 2.

The in-vehicle device 2 includes a control unit 20, a memory unit 21, an input/output I/F 22, an in-vehicle communication unit 23, etc. The in-vehicle device 2 periodically communicates with an external server, acquires various applications AP using OTA (Over The Air), etc., and installs (applies) the acquired applications AP, thereby functioning as a function-expanding ECU that expands executable functions. As will be described in detail below, the in-vehicle device 2 (function-expanding ECU) selects an application AP based on the state of the vehicle C and the operator, and executes the selected application AP. The in-vehicle device 2 transmits execution result data representing the execution result of the application AP to the in-vehicle ECU 4 corresponding to the function implemented by executing the application AP. The in-vehicle ECU 4 is connected to an actuator 411 that is driven and controlled in accordance with the function implemented by the application AP by the in-vehicle device 2.

When expanding the functions of the vehicle C, it is necessary to add a new application AP to realize the function. However, by consolidating the added application AP in the in-vehicle device 2 (function-expanding ECU), it is possible to prevent the software configuration applied to the existing in-vehicle ECU 4 from being affected. Therefore, even when a new application AP is added to expand the function, it is not necessary to verify the software configuration implemented in the existing in-vehicle ECU 4. To realize the expanded function, the in-vehicle device 2 executes the application AP, so distributed processing is performed between the in-vehicle device 2 and the in-vehicle ECU 4 corresponding to the function. This reduces the processing load on the in-vehicle ECU 4 and prevents an increase in the specifications required for hardware resources such as memory and a CPU implemented in the in-vehicle ECU 4.

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

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

The input/output I/F 22 is, for example, a communications interface for serial communication. Via the input/output I/F 22, the in-vehicle device 2 is communicatively connected to sensors 222, such as a camera 221, LiDAR, RADAR, ultrasonic sensor, temperature/humidity sensor, or infrared sensor, and a display device (HMI device) such as a display. Various sensors 222 may be additionally connected (post-installed) to the input/output I/F 22 as required depending on the various added applications AP. That is, the input/output I/F 22 may be compatible with standards such as GMSL and FPD-LINK, which are camera 221-related interfaces. In this way, the control unit 20 can execute various applications AP on images captured by the camera 221 via the input/output I/F 22, thereby performing various processes such as image processing, point cloud processing, object detection, and living organism detection.

The in-vehicle communication unit 23 is an input/output interface (Ethernet PHY unit, CAN transceiver, etc.) that uses 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.

Figure 3 is an explanatory diagram showing an example of the software hierarchy implemented in the in-vehicle device 2. The control program P stored in the storage unit 21 of the in-vehicle device 2 may include multiple applications AP, an input/output program IP, and an operating system OP. In terms of the software hierarchy (layer structure), the input/output program IP is at the top, followed in order by the application AP and the operating system OP.

The multiple applications AP are selectively executed based on a combination of the operator of the vehicle C (operator information) and the state of the vehicle C (vehicle state information), and are switched and executed for each operator. The in-vehicle device 2 (function-enhancing ECU) acquires these applications AP from the external server 100 using OTA (Over The Air) or the like, and installs them by storing them in the memory unit 21. By acquiring the applications AP from the external server 100 in this way, the functions that the in-vehicle device 2 can perform (executable functions) can be expanded according to the acquired applications AP.

When executing an application AP according to the type of extended function, the input/output program IP performs input/output processing (input/output processing) with the onboard ECU 4, which is the destination of the request signal generated as a result of the execution of the application AP. When the input/output program IP performs input/output processing with the onboard ECU 4, i.e., front-end processing for the onboard ECU 4, the input/output program IP and each of the multiple application APs are linked via a common interface and are configured to be connected, for example, via inter-process communication or a shared memory method. The input/output program IP and each of the multiple application APs may be coded using, for example, a common communication socket library, and each application AP and the input/output program IP may perform inter-process communication defined by that library. In this way, the input/output program IP performs pre-expected data exchange processing in each application AP, thereby performing transparent communication processing with each application AP and transmitting and receiving data corresponding to the onboard ECU 4, which is the destination of the request signal.

The storage unit 21 of the in-vehicle device 2 may store, for example, in a list format (application list), applications AP associated with the in-vehicle ECUs 4 to which the execution results (request signals) of the applications AP are sent. The application list defines, in association with each other, the names of the applications AP (executable file names) and ECU numbers (MAC addresses, IP addresses, ECU IDs, etc.) that uniquely identify the in-vehicle ECUs 4 corresponding to the functions performed by the applications AP.

When executing the input/output program IP, the control unit 20 reads the application list as a data file, identifies the in-vehicle ECU 4 to which the execution result (request signal) of the executed application AP is to be sent, and sends the execution result (request signal) to the identified in-vehicle ECU 4. The in-vehicle ECU 4 to which the execution result (request signal) is to be sent is the in-vehicle ECU 4 that corresponds to the function performed by the application AP and is connected to the actuator 411 that is driven by that function.

When multiple applications AP are running simultaneously, the input/output program IP may determine the priority order among these applications AP and perform processing (application control processing) to resolve resource conflicts between these applications AP. The input/output program IP configured in this manner functions as communication middleware when performing communication processing with the on-board ECU 4, and can increase the affinity and transparency between the various applications AP obtained from the off-vehicle server 100 and the various on-board ECUs 4 installed in the vehicle C, ensuring the versatility of the application AP.

The operating system OP is basic software such as Linux (registered trademark) or AUTOSAR (registered trademark)-OS. All applications AP installed (applied) on the in-vehicle device 2 run on the operating system OP, which controls the processes or threads generated for the execution of the applications AP and the application AP's access to hardware resources. The operating system OP may include, for example, a security module, device drivers for the camera 221 and sensor 222 connected to the input/output I/F 22, and an OTA module used to acquire or update the application AP from the off-vehicle server 100. The operating system OP is responsible for controlling access to hardware resources such as the control unit 20, memory unit 21, input/output I/F 22, and in-vehicle communication unit 23, as well as time slice processing.

4 is an explanatory diagram showing an example of an application table. The storage unit 21 stores an application table in which applications AP specified by a combination of the operator of the vehicle C (operator information) and the state of the vehicle C (vehicle state information) are defined. The application table may be configured, for example, as a matrix table, and may include, as management items, a field for the operator and a field for the vehicle state, and may define an application AP to be executed by a combination of the operator and the vehicle state.

In this embodiment, for example, if the operator is User-A and the vehicle C is in the driver's seat, the automatic door release application AP is executed. Also, if the operator is User-B and the vehicle C is in the driver's seat state, the application AP to be executed is defined as automatic door release. If the vehicle C is in the engine running state, the application AP to be executed for User-A is defined as the camera DMS (Driver Monitor) application AP, and for User-B is defined as the biometric sensor DMS application AP. In this way, even if the vehicle C is in the same state (vehicle state information), the control unit 20 of the in-vehicle device 2 (function-enhanced ECU) can switch the application AP to be executed depending on the operator (operator information).

Automatic door unlocking, camera DMS, biometric sensor DMS, etc. are examples of selectively executed applications AP, and needless to say, they are not limited to these. Applications APs executed when the vehicle C's state (vehicle state information) is "inside the vehicle" may include, for example, door unlocking using biometric authentication, user authentication for shared cars, user authentication and payment for taxis or buses, changing door settings when confirming that a child is on board, etc. Applications APs executed when the vehicle C's state (vehicle state information) is "engine running" may include, for example, various DMS (Driver Monitor), EDR (data recording), sign recognition, traffic light recognition, emergency vehicle C detection (sound), dashcam function (data storage), etc. Applications APs executed when the vehicle C's state (vehicle state information) is "outside the vehicle" may include, for example, collision warning when opening and closing doors, user authentication and payment for taxis or buses, child abandonment detection, smart home integration, garage opening, etc.

These applications AP stored in the memory unit 21 and defined in the application table may be classified as grade A, grade B, or QM in the ISO 26262 ASIL (Automotive Safety Integrity Level). The in-vehicle device 2 functioning as a function-enhancing ECU periodically or periodically acquires and updates various applications AP from the off-vehicle server 100 using OTA or the like, thereby maintaining a state in which all applications AP applicable to the in-vehicle device 2 can be executed.

The information that forms the source data for the application table may be information about subscription users that is centrally managed by the off-vehicle server 100. These subscription users are users who can become operators of the vehicle C, and the off-vehicle server 100 centrally manages information about the applications APs desired by each user for all subscription users (user master information). The control unit 20 of the in-vehicle device 2 may periodically communicate with the off-vehicle server 100 and update the application table.

Figure 5 is an explanatory diagram showing an example of application AP switching. The illustration in this embodiment explains a mode (use case) in which the in-vehicle device 2 (function-enhanced ECU) switches the application AP to be executed depending on the operator of vehicle C (operator information) and the state of vehicle C (vehicle state information). When the state (vehicle state information) of vehicle C is while in the vehicle, both operators (A) and (B) of vehicle C are set (defined in the application table) as application APs that execute automatic door release, and therefore the application AP for automatic door release is executed.

When the state of vehicle C (vehicle state information) is that the engine is running, operator (A) sets the camera DMS as the application AP that runs, and operator (B) sets the biosensor DMS as the application AP that runs. Therefore, when operator (A) is in the car, the camera DMS runs while the engine is running. When operator (B) is in the car, the biosensor DMS runs while the engine is running.

When the state of vehicle C (vehicle state information) is when disembarking, both operators (A) and (B) of vehicle C are set (defined in the application table) as application APs that execute a door opening/closing warning, so a door opening/closing warning is executed. In this way, the application AP can be switched and executed depending on the state of vehicle C (vehicle state information). Furthermore, even if the state of vehicle C (vehicle state information) is the same (engine running), the application AP executed by operator (A) and operator (B) will be different, and the application AP can be switched and executed depending on the operator.

Figure 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 steadily performs the following processing, for example, when the vehicle C is in a running state (IG switch 6 is on) or a stopped state (IG switch 6 is off).

When performing the following processing, the control unit 20 of the in-vehicle device 2 periodically or periodically communicates with an external server 100, such as an OTA server, to check whether there is a new application AP to add. If there is an application AP to add, 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) and stores it in the memory unit 21, thereby installing (applying) it.

When acquiring an application AP 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 an application AP to run depending on the operator of the vehicle C, but it is expected that the vehicle C will be driven and operated by multiple different operators. Even in such a case, because all application APs (full package) are pre-installed (applied) on the in-vehicle device 2, it is not necessary to acquire an application AP tailored to the operator each time, regardless of which operator operates the vehicle C.

The control unit 20 of the in-vehicle device 2 may acquire user information about subscription users (operators of vehicle C) registered on the off-vehicle server 100 in addition to acquiring additional applications AP. Based on the acquired user information, the control unit 20 of the in-vehicle device 2 may determine the applications AP (services to be provided) desired by each subscription user (operator of vehicle C) and update the application table.

The control unit 20 of the in-vehicle device 2 acquires operator information related to the operator of the vehicle C (S101). The control unit 20 of the in-vehicle device 2 acquires the 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 power supply device 7 is constantly powered and the body ECU 41 is in an activated (wake-up) state. When an operator carrying the mobile terminal 101 or the like approaches the vehicle C, the body ECU 41 acquires the operator information by performing short-range communication with the mobile terminal 101. In this case, the body ECU 41 transmits a wake-up signal to the in-vehicle device 2, which is in a sleep state, to transition the in-vehicle device 2 to an activated (wake-up) state, and further transmits the operator information to the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 associates the operator information acquired from the body ECU 41 with the acquisition time and stores the information in the storage unit 21.

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 if the result of the authentication processing is positive. When performing the authentication processing, the control unit 20 of the in-vehicle device 2 may transmit the acquired operator information to the off-vehicle server 100 and request the off-vehicle server 100 to perform authentication processing. Alternatively, a biometric authentication device that performs fingerprint authentication or the like may be connected to the in-vehicle device 2, and the control unit 20 of the in-vehicle device 2 may authenticate the operator of the vehicle C using the biometric authentication device.

The control unit 20 of the in-vehicle device 2 acquires vehicle state information related to the state of the vehicle C (S102). The control unit 20 of the in-vehicle device 2 receives messages transmitted from each in-vehicle ECU 4, such as the body ECU 41, acquires the vehicle state information contained in the received messages, associates the vehicle state information with the acquisition time, and stores the information in the storage unit 21. Alternatively, the control unit 20 of the in-vehicle device 2 may acquire vehicle state information based on a signal transmitted from the IG switch 6 when the IG switch 6 is turned on or off. The message may be, for example, a CAN message or an IP packet, and the control unit 20 of the in-vehicle device 2 can acquire vehicle state information based on the message ID of the CAN message, the TCP port number of the IP packet, or data stored in the payload of the message. The vehicle state information includes information indicating various states, such as whether the operator is in the vehicle, the operator is out of the vehicle, the engine is running, the engine is stopped, the vehicle speed, the operating states of the various actuators 411, whether the vehicle is in automatic driving or manual driving.

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

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, control signals, or request signals generated as a result of the execution to the in-vehicle ECU 4 corresponding to the application AP. The application AP is intended to perform a function (service) requested by the operator. The function (service) may include, for example, automatic door unlocking, light activation, and collision risk when opening and closing a door. The actuators 411 that are actually driven to perform these functions (services) are connected to the in-vehicle ECU 4, which is the destination of the request signals. The in-vehicle ECU 4 to which the actuators 411 that are driven to perform the function (service) connects controls the actuators 411 connected to it, such as door locks and lights, in response to the received request signals (messages). This reduces the processing load on the in-vehicle ECU 4, while executing the application AP requested by the operator of the vehicle C in accordance with the state of the vehicle C, and providing the function (service) requested by the operator.

The control unit 20 of the in-vehicle device 2 acquires vehicle state information regarding the state of vehicle C (S105). As in process S102, the control unit 20 of the in-vehicle device 2 acquires vehicle state information regarding the state of vehicle C, associates the vehicle state information with the acquisition time, and stores it in the memory unit 21.

The control unit 20 of the in-vehicle device 2 determines whether the vehicle state information has changed (S106).
The control unit 20 of the in-vehicle device 2 determines whether or not there has been a change between the vehicle state information acquired this time and the vehicle state information acquired last time.

If the vehicle state information has changed (S106: YES), the control unit 20 of the in-vehicle device 2 performs loop processing to execute the process of S103 again. If the vehicle state information has changed, the control unit 20 of the in-vehicle device 2 performs loop processing to execute the process of S103 again, thereby selecting and executing an application AP based on the combination of the current state of the vehicle C and the operator. This makes it possible to select and execute an appropriate application AP in response to changes in the state of the vehicle C.

If the vehicle state 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 vehicle C (S107). If the vehicle state information has not changed, the control unit 20 of the in-vehicle device 2 determines whether the operator has left the vicinity of 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), and the body ECU 41 periodically determines whether the operator is inside vehicle C or is outside vehicle C within a predetermined distance. The control unit 20 of the in-vehicle device 2 determines whether the operator has left the vicinity of vehicle C, for example, by obtaining information about the operator's location from the body ECU 41.

If the operator has not left the vicinity of vehicle C (S107: NO), the control unit 20 of the in-vehicle device 2 performs loop processing to execute the processing from S105 again. If the operator has not left the vicinity of vehicle C, the control unit 20 of the in-vehicle device 2 can continue to regularly or periodically acquire vehicle status information by executing the processing from S105 again. This allows the selection and execution of an appropriate application AP in accordance with the periodically acquired vehicle status information while the operator has not left the vicinity of vehicle C. If the operator has left the vicinity of vehicle C (S107: YES), the control unit 20 of the in-vehicle device 2 ends the processing in this flowchart.

(Embodiment 2)
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 processing of S201, similar to the processing of S101 in 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 memory 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 external server 100 and requests the external server 100 for user information corresponding to the operator information. The operator information includes, for example, a user ID that uniquely identifies the operator. The external server 100 centrally manages (master registers) data related to the operator of the vehicle C, who is a subscription user, and stores a list of services requested by each user (user ID), i.e., applications AP to be executed. The control unit 20 of the in-vehicle device 2 transmits the operator information including the user ID and the like to the external server 100, thereby acquiring user information including the application AP to be executed for the operator, from the external server 100, which centrally manages information on all users.

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 adds information to the application table regarding the operator (user ID) of the currently acquired operator information and the application AP (service provided) that the operator (user ID) requests to be executed in each vehicle C state.

If the number of subscription users registered on the off-vehicle server 100 increases to a huge number, there is a concern that registering (mirroring) information about all users in the application table of each individual vehicle C may cause the storage area in the storage unit 21 to become congested. Therefore, by additionally registering information about new operators (user IDs) in the application table of each vehicle C as needed, it is possible to prevent the storage area in the storage unit 21 from becoming congested.

Because the in-vehicle device 2 periodically performs OTA processing using the external server 100, all applications APs applicable to the in-vehicle device 2 are stored (full package installed) in the storage unit 21 of the in-vehicle device 2. Therefore, because each application AP defined in the application table is already installed, even when a new operator (user ID) is registered, it is not necessary to install the application APs in conjunction with the user registration. Alternatively, the control unit 20 of the in-vehicle device 2 may obtain the application APs requested by the operator from the external server 100 in conjunction with registering the 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 vehicle C (S203). The control unit 20 of the in-vehicle device 2 performs S203 in the same manner as in process S102 of embodiment 1. After executing S203, the control unit 20 of the in-vehicle device 2 performs processes from S204 to S208 in the same manner as in processes S103 to S107 of embodiment 1.

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

Multiple claims set forth in the claims section may be combined with each other regardless of the form of reference. The claims section may contain multiple dependent claims that depend on multiple claims. The claims section may not contain multiple dependent claims that depend on multiple dependent claims, but multiple dependent claims that depend on multiple dependent claims may be included.

S: In-vehicle system C: Vehicle N: External network 100: External server (OTA server)
101 Portable terminal 1 Exterior communication device 11 Exterior communication unit 12 Interior communication unit 13 Antenna 2 In-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 unit 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 (6)

An in-vehicle device that is mounted on a vehicle and communicably connected to an in-vehicle ECU via an in-vehicle network,
a storage unit in which a plurality of applications are stored;
a control unit that performs processing related to the application,
The control unit
By adding the application stored in the storage unit, functions executable by the vehicle are expanded;
outputting the execution result of the application to an in-vehicle ECU corresponding to the function ;
acquiring operator information relating to an operator of the vehicle;
acquiring vehicle status information relating to a status of the vehicle;
selecting the application to be executed in accordance with a combination of the acquired operator information and the acquired vehicle state information;
the storage unit stores an application table in which the application identified by a combination of an operator of the vehicle and a state of the vehicle is defined;
The control unit refers to the application table and selects the application.
In-vehicle device. 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 via 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 plurality of applications stored in the storage unit are classified as A grade, B grade, or QM in ASIL (Automotive Safety Integrity Level) of ISO 26262.
The in-vehicle device according to any one of claims 1 to 3 . A computer is mounted on a vehicle, is communicably connected to an on-board ECU via an on-board network, and includes a storage unit that stores a plurality of applications.
By adding the application stored in the storage unit, functions executable by the vehicle are expanded;
outputting the execution result of the application to an in-vehicle ECU corresponding to the function ;
acquiring operator information relating to an operator of the vehicle;
acquiring vehicle status information relating to a status of the vehicle;
selecting the application to be executed in accordance with a combination of the acquired operator information and the acquired vehicle state information;
the storage unit stores an application table in which the application identified by a combination of an operator of the vehicle and a state of the vehicle is defined;
Refer to the application table and select the application.
A program that executes a process. A computer is mounted on a vehicle, is communicably connected to an on-board ECU via an on-board network, and includes a storage unit that stores a plurality of applications.
By adding the application stored in the storage unit, functions executable by the vehicle are expanded;
outputting the execution result of the application to an in-vehicle ECU corresponding to the function ;
acquiring operator information relating to an operator of the vehicle;
acquiring vehicle status information relating to a status of the vehicle;
selecting the application to be executed in accordance with a combination of the acquired operator information and the acquired vehicle state information;
the storage unit stores an application table in which the application identified by a combination of an operator of the vehicle and a state of the vehicle is defined;
Refer to the application table and select the application.
An information processing method for executing processing.