WO2022163316A1

WO2022163316A1 - Device for vehicles

Info

Publication number: WO2022163316A1
Application number: PCT/JP2022/000235
Authority: WO
Inventors: 憲一大西
Original assignee: 株式会社デンソー
Priority date: 2021-01-26
Filing date: 2022-01-06
Publication date: 2022-08-04
Also published as: JP2022114163A

Abstract

An device 1 for vehicles according to an embodiment comprises: a control unit 101 which is capable of accessing a peripheral apparatus 3 and capable of carrying out a function that is provided when a vehicle is used; a connection unit 5 which is capable of communicating with the control unit 101 and to which an external device 2 capable of carrying out a function that is provided when the vehicle is used is to be connected; and a selection unit 14 which carries out a process pertaining to the selection of whether or not the external device 2 is to be used, wherein the control unit 101 causes the external device to be available for use when use of the external device is selected.

Description

vehicle equipment

Cross-reference to related applications

This application is based on Japanese Application No. 2021-010337 filed on January 26, 2021, and the contents thereof are incorporated herein.

The present disclosure relates to a vehicle device.

In recent years, as shown in Patent Document 1, for example, mounting multiple operating systems on vehicle devices has rapidly spread. Hereinafter, the operating system will be referred to as OS. At this time, the vehicle equipment includes a so-called real-time OS suitable for processing that requires real-time processing, and a multimedia processing such as display on a display, which is used in general mobile terminals. A general-purpose OS may be implemented.

Patent No. 6130617

By the way, the general-purpose OS used in mobile terminals and the like is updated relatively frequently, and the functions installed in the OS are expanded by the update. As the functions expand, the required hardware performance also increases.

However, in vehicle devices installed in vehicles, there is a problem that it is difficult to take measures to update the hardware after shipment, for example, every year or every few years.
The present disclosure has been made in view of the circumstances described above, and an object thereof is to provide a vehicle device capable of improving performance even after shipment.

To achieve the above object, a vehicle device according to one aspect of the present disclosure includes: a control unit that can access peripheral devices and can execute functions provided when using a vehicle; and a connection unit to which an external device capable of executing a function provided when using the vehicle is connected, and a selection unit that executes processing related to selection of whether or not to use the external device. The unit enables the external device if it is selected to use the external device.

As a result, for example, in a situation where the vehicle had the required performance when it was shipped, but a subsequent update of the operating system required higher performance, the performance can be improved by connecting an external device. It is easy to plan.

The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description with reference to the accompanying drawings. The drawing is
FIG. 1 is a diagram schematically showing an electrical configuration example of a vehicle device and an external device in the first embodiment; FIG. 2 is a diagram schematically showing a software configuration example of a vehicle device and an external device; FIG. 3 is a diagram showing the flow of processing when the vehicle device and the external device are activated; FIG. 4 is a diagram showing the flow of processing during normal operation of the vehicle device and the external device; FIG. 5 is a diagram showing the flow of OS startup processing of the vehicle device; FIG. 6 is a diagram showing the flow of activation processing, FIG. 7 is a diagram schematically showing a simplified software configuration example, FIG. 8 is a diagram showing the flow of regular confirmation processing, FIG. 9 is a diagram showing the flow of invalidation processing, FIG. 10 is a diagram schematically showing another software configuration example, FIG. 11 is a diagram showing the flow of data erasure processing in the second embodiment. FIG. 12 is a diagram showing the flow of data migration processing; FIG. 13 is a diagram showing the flow of removal processing, FIG. 14 is a diagram showing the flow of data transfer processing; FIG. 15 is a diagram schematically showing a software configuration example in the third embodiment; FIG. 16 is a diagram showing the flow of processing at startup, FIG. 17 is a diagram showing the flow of device selection processing; FIG. 18 is a diagram showing the flow of data selection processing.

A plurality of embodiments will be described below. Moreover, the same code|symbol shall be attached|subjected to the substantially common part in each embodiment.

(First embodiment)
The first embodiment will be described below. As shown in FIG. 1, the vehicle device 1 is realized as a semiconductor integrated circuit configured by, for example, an SoC, and is connectable to an external device 2 and accessible to a peripheral device 3. there is The vehicle device 1, the external device 2, and the peripheral devices 3 configure a vehicle system 4 by operating in cooperation with each other.

Specifically, the vehicle device 1 includes a control unit 101 capable of executing functions provided when the vehicle is used, and an external input/output circuit 102 for inputting/outputting various signals to/from the peripheral device 3. , a USB connector 103 to which an external device 2 capable of communicating with the control unit 101 and capable of executing functions provided when using the vehicle is connected. SoC is an abbreviation for System on a Chip, and USB is an abbreviation for Universal Serial Bus. In FIG. 1, the external input/output circuit 102 is shown as one block for simplification of explanation, but it can be composed of a plurality of circuits corresponding to the peripheral device 3 .

The control unit 101 includes a CPU 104, a ROM 105, a RAM 106, an input/output port 107, a communication circuit 108, and the like, which are connected by a bus 109. The CPU 104 executes programs stored in the ROM 105 to perform various processes for controlling the vehicle device 1 and various functions provided when the vehicle is used. Also, part or all of the functions executed by the CPU 104 can be configured as hardware by one or more ICs.

In this embodiment, the functions provided when using the vehicle include functions provided to the user who uses the vehicle, and functions for using the vehicle even if the user does not directly know it. It assumes a function for controlling peripheral devices 3 including in-vehicle devices required for In other words, the functions provided when using the vehicle mean functions that can be provided by the vehicle device 1 and functions that can be provided by the external device 2 via the vehicle device 1 .

The ROM 105 is a non-volatile memory composed of eMMC, for example. Note that eMMC is an abbreviation for embedded Multi Media Card. The ROM 105 stores various programs to be executed by the CPU 104, data to be referred to when executing the programs, data mainly used for vehicle equipment such as the set temperature of the air conditioner, the position and angle of the seat and huddle, The home location and phone number used for navigation, and data used for mainly provided functions such as music are stored. Hereinafter, among these data, data unique to the user, such as seat position and telephone number, are also referred to as user information.

In addition, the ROM 105 is composed of a non-volatile memory, and is provided with a read-only area and a writable area. For example, data that is basically not rewritten, such as an OS image, is stored in a read-only area, while data to be stored even when the vehicle device 1 is turned off is stored in a writable area. be. This ROM 105 constitutes a storage unit 110 .

The RAM 106 is composed of volatile memory and temporarily stores data such as calculation results. The data stored in the RAM 106 is stored in a writable area of the ROM 105, for example, when the operation of the vehicle device 1 is finished, if necessary.

The input/output port 107 is a circuit for inputting/outputting signals between the control unit 101 and the peripheral device 3 or the external device 2 . The communication circuit 108 conforms to the USB standard in this embodiment, and transmits and receives data to and from the external device 2 via the USB connector 103, which is physical connection means. The USB connector 103 and communication circuit 108 constitute the connection section 5 in this embodiment.

The external device 2 is realized, for example, as a semiconductor integrated circuit configured by SoC, and in this embodiment is configured as a USB module that is connected to the vehicle device 1 via USB. The external device 2 is communicably connected to the control unit 101 of the vehicle device 1 via a USB cable 6 , so that the peripheral device 3 can be accessed via the vehicle device 1 . Further, the external device 2 is supplied with power from the vehicle device 1 via the USB connector 103 during operation.

The external device 2 includes a module-side control unit 201 capable of executing functions provided when using the vehicle, and an external input/output unit for inputting/outputting various signals between the peripheral device 3 and the wireless communication device 203. and circuit 202 . The module-side control unit 201 includes a CPU 204 , a ROM 205 , a RAM 206 , an input/output port 207 , a communication circuit 208 and the like, which are connected by a bus 209 .

In FIG. 1, the external input/output circuit 202 is shown as one block for the sake of simplification of explanation. It can be composed of multiple circuits.

The CPU 204 executes programs stored in the ROM 205 to perform communication with the vehicle device 1 and various functions provided when using the vehicle. The ROM 205 constitutes a module-side storage unit 210 that stores programs executed by the CPU 204 and data referred to when the programs are executed. The module-side storage unit 210 of the external device 2 can also store data such as user information transmitted from the vehicle device 1 .

In this embodiment, the module-side control section 201 is configured to have higher processing performance than the control section 101 of the vehicle device 1 . Therefore, when executing the same processing, the external device 2 can complete the processing in a shorter time than the vehicle device 1 can. Also, part or all of the functions executed by the CPU 204 can be implemented in hardware by one or more ICs.

The input/output port 207 is a circuit for inputting/outputting signals between the module-side control unit 201 and other devices. In the present embodiment, as other devices, the vehicle device 1, the peripheral device 3 controlled via the vehicle device 1, for example, the wireless communication device 203 that communicates with the mobile terminal 7 owned by the user, etc. are assumed. is doing.

The communication circuit 208 conforms to the USB standard for communicating with the vehicle device 1 in this embodiment. The wireless communication device 203 includes a wireless communication unit compatible with, for example, Wi-Fi (registered trademark) and Bluetooth (registered trademark), and performs wireless communication with the mobile terminal 7 . Note that the wireless communication device 203 may have a function of communicating with the mobile terminal 7 using a wired connection method.

Peripheral devices 3 connected to the vehicle device 1 include, for example, a center display 301, a meter display 302, a head-up display 303, an air conditioner display 304, a speaker 305, a camera 306, a microphone 307, a position detection device 308, a tuner 309, and a DSM 310. , LIDAR 311, radar 312, ECU 313, and the like. However, the types and numbers of the peripheral devices 3 shown in FIG. 1 are only examples, and the vehicle device 1 does not necessarily need to be connected to all of these, and other peripheral devices 3 not illustrated may be connected. can also

The center display 301 is arranged in front, for example, between the driver's seat and the passenger's seat. The center display 301 is used, for example, as a display screen when executing a navigation function or as an operation screen when using a touch panel (not shown) provided corresponding to the display area. That is, the center display 301 functions as the input unit 10 for inputting user's operations.

However, as the input unit 10, other than the touch panel, for example, mechanical operation switches (not shown) may be arranged around the screen to input operations. Further, as the input unit 10, other displays or steering switches (not shown) can be adopted, or they can be shared with a touch panel or operation switches.

The meter display 302 is placed in front of the steering wheel to display meters such as speed and number of revolutions, as well as display such as warning lights. The head-up display 303 displays various types of information on a windshield placed in front of the driver or a display board placed on the dashboard. The air conditioner display 304 displays information regarding control of the air conditioner, such as the current set temperature and outside temperature. However, the air conditioner display 304 can be provided exclusively, or can be configured to use part of another display.

The speaker 305 is installed inside the vehicle and outputs audio based on audio data output from the vehicle device 1 or the external device 2 . The speaker 305 is used, for example, for warning from the vehicle device 1 or the external device 2, operation guidance, or reproduction of music. The microphone 307 is installed in the vehicle interior, and outputs the voice uttered by the passenger of the vehicle to the vehicle device 1 and the external device 2 as voice data. The microphone 307 is used for inputting voice commands for operating the vehicle device 1 and the external device 2 . Also, the microphone 307 and the speaker 305 can be used for voice input and voice output during a hands-free call using the mobile terminal 7 .

The position detection device 308 is composed of a GPS receiver and a gyro sensor (not shown), and acquires the current position and orientation of the vehicle. GPS is an abbreviation for Global Positioning System. The GPS receiver receives GPS positioning signals transmitted from GPS satellites and outputs the received GPS positioning signals. It detects the angular velocity of the rotation.

The camera 306 is attached to the rear side of the vehicle, for example, and continuously captures the situation behind the vehicle. The image picked up by the camera 306 is displayed on the center display 301 or other displays together with, for example, detection results of objects present in the image and guidance lines for guiding the vehicle. Tuner 309 receives radio broadcast signals of AM and FM broadcasts. A tuner 309 for receiving television broadcasting can also be provided.

The DSM 310 is a driver status monitor that is composed of an imaging device and the like, and that detects the driver's condition by analyzing the face image of the driver's face. DSM 310 is an abbreviation for Driver Status Monitor. The LIDAR 311 detects the positions of objects existing around the vehicle by transmitting and receiving laser light. Note that LIDAR 311 is an abbreviation for Light Detection and Ranging.

The radar 312 detects the position of objects existing around the vehicle by transmitting and receiving radar 312 waves in the millimeter wave band. The results of detection by the DSM 310, LIDAR 311, or radar 312 are notified to the driver by, for example, warning display or warning display on the display or audio output from the speaker 305. FIG.

The ECU 313 is an electronic device mounted on the vehicle. In general, a vehicle is equipped with a plurality of ECUs 313, and the vehicle device 1 receives various information about the vehicle from these ECUs 313, such as the drive state of drive units such as an engine and a motor, and the open/closed state of a door. get. The ECU 313 is an abbreviation for Electronic Control Unit.

Although one ECU 313 is shown in FIG. 1 for simplification of explanation, a plurality of ECUs 313 are mounted in the vehicle, and the vehicle device 1 can communicate with a plurality of ECUs 313 via an in-vehicle network such as CAN, for example. is communicably connected to the ECU 313 of the Note that CAN is an abbreviation for Controller Area Network.

Next, the basic software configuration of the vehicle device 1 will be described. As shown in FIG. 2, the vehicle device 1 has a virtualized environment in which a plurality of operating systems can operate. Hereinafter, the operating system will be referred to as OS8. Note that OS is an abbreviation for Operating System. Also, in FIG. 2, illustration of some peripheral devices 3 is omitted for simplification of explanation.

In the vehicle device 1, a hypervisor 111, a service bus 112, a firewall 113, an RTOS 81, and an MMOS 82A are mounted on the control unit 101. Note that RTOS 81 is an abbreviation for Real Time OS, and MMOS 82 is an abbreviation for Multi Media OS. Further, in the present embodiment, the MMOS 82 is mounted on the vehicle device 1 and the external device 2, respectively, so that the MMOS 82 mounted on the vehicle device 1 is denoted by A in order to make it easier to distinguish between the two. , the MMOS 82 mounted on the external device 2 is denoted by B. FIG.

Also, in this embodiment, Android (registered trademark) is adopted as the MMOS 82 . In the following, when describing items common to the RTOS 81 and the MMOS 82, they may simply be referred to as the OS8. In addition, when describing items common to the MMOS 82A and the MMOS 82B, the MMOS 82 may be simply referred to. Also, the MMOS 82A2 and MMOS 82B are assumed to be of the same version or sufficiently compatible versions.

The hypervisor 111 is a general technology, so a detailed description is omitted, but it is a program for enabling multiple OSs 8 such as the RTOS 81 and the MMOS 82A to be executed in parallel on the control unit 101. It has a function to manage and a function to assist communication between each OS8. However, the hypervisor 111 can also be implemented as part of the functions of the RTOS 81, for example.

The service bus 112 is a program for exchanging data between the application layer of each OS 8 and a lower layer indicating any lower layer. This service bus 112 allows data to be exchanged between the vehicle device 1 and the external device 2 as if they were one device. It has a database for matching.

Further, the service bus 112 converts the data format between the application layer and the lower layer by referring to the database, between the RTOS 81 and the MMOS 82A in the vehicle device 1, and between the vehicle device 1 and the external device. Allows data exchange with the device 2 .

The firewall 113 has a function of restricting unauthorized access between each OS 8 and unauthorized access to the RTOS 81 and MMOS 82A from the outside. Whether or not to implement the firewall 113 can be selected as appropriate, and if security can be ensured by another technique, the firewall 113 may not be implemented.

The RTOS 81 is suitable for executing processes that require real-time performance, and mainly executes processes related to vehicle control and safety. The MMOS 82A is a general-purpose device used in, for example, a general mobile terminal 7, and is suitable for executing multimedia processing. In this embodiment, the MMOS 82 performs, for example, display processing on the screen.

However, each OS 8 is not limited to processing suitable for itself. processing can be performed.

Application 9 and various functional units are implemented in these OS8. Each application 9 is a program executed on each OS 8 to implement functions provided when using the vehicle. However, in FIG. 2, some of those implemented in each OS 8 are extracted and illustrated, and applications 9 and functional units other than those shown in FIG. 2 can be implemented in each OS 8. FIG.

Further, the vehicle device 1 and the external device 2 do not necessarily have to implement all the applications 9 and functional units shown in FIG. All you have to do is Hereinafter, the application 9 is also simply referred to as an application. Further, the vehicle device 1 and the external device 2 can update or newly acquire the application 9 by OTA via the portable terminal 7, for example. Note that OTA is an abbreviation for Over The Air.

For example, a meter application 901, a HUD application 902, and a camera application 903 are installed in the RTOS 81 as applications 9. HUD is an abbreviation for Head Up Display. The meter application 901 executes processing for controlling display on the meter display 302, and executes processing for generating images such as speedometers and warning lights to be displayed on the meter display.

The HUD application 902 executes processing for controlling display on the head-up display 303, and executes processing for generating images and information to be displayed on the head-up display 303, for example. The camera application 903 executes processing for controlling display of an image captured by the camera 306, and includes processing for detecting an object existing in the image, generation of a guidance line for guiding the vehicle when backing up, and image processing. , and perform processing for synthesizing

Also, the RTOS 81 is equipped with an HMI processing unit 11, a determination unit 12, a data management unit 13, and a selection unit 14 as functional units. HMI is an abbreviation for Human Machine Interface. These functional units are realized by software in this embodiment. However, part or all of each functional unit can be implemented in the MMOS 82A, or a configuration in which part or all of each functional unit is realized by hardware is also possible.

The HMI processing unit 11 executes processing for controlling displays on the center display 301, the meter display 302, the head-up display 303, and the air conditioner display 304 based on data input from the peripheral device 3 and other applications 9. . The HMI processing unit 11 also executes processing such as controlling audio output from the speaker 305 based on input data.

The determination unit 12 executes processing for determining whether or not the external device 2 is connected in a operable state. As will be described later, the determination unit 12 communicates with the external device 2 and grasps the connection state and operation state of the external device 2 to determine whether the function is executable or not. judge. In other words, the determination unit 12 executes processing for determining whether or not the external device 2 is in a usable state. The determination unit 12 also executes processing for selecting whether or not to use the external device 2, although the details will be described in another embodiment.

The data management unit 13 executes processing to make data stored in the external device 2 available, although the details will be described in another embodiment. Specifically, the data management unit 13 executes processing related to erasure and migration of data used by the external device 2, and together with the selection unit 14 selects whether or not to use the data stored in the external device 2. enable

For example, the selection unit 14 selects whether or not to use the external device 2 itself, and selects whether or not to use a function executable by the external device 2, although the details will be described in another embodiment. selection of whether to use the external device 2; Execute the process.

Also, the MMOS 82A is equipped with, for example, a radio application 904, an air conditioner application 905, a navigation application 906, a voice recognition application 907, and the like. The radio application 904 executes processing for listening to radio broadcasts, such as processing for outputting audio based on the radio broadcast signal received by the tuner 309 and changing the reception frequency according to user's operation.

An air conditioner application 905 executes processing related to control of an air conditioner installed in the vehicle. , performs processing for providing a so-called navigation function for guiding a route from the current location to the destination. The speech recognition application 907 executes processing for recognizing speech detected by the microphone 307, processing for responding based on the recognition result, and the like.

For example, an external device communication application 908 is installed in the MMOS 82B of the external device 2. The external device communication application 908 transmits and receives data to and from the mobile terminal 7 by wireless communication using the wireless communication device 203 , and transmits received data to the vehicle device 1 . to the portable terminal 7, and the like. Note that although one application 9 is shown in FIG. 2 for simplification of explanation, other applications 9 can be installed in the external device 2 .

In addition, in the present embodiment, the external device 2 performs display on the display and audio output from the speaker 305 via the vehicle device 1, and performs user operations such as execution and stop of functions via the vehicle device 1. is entered. Therefore, even when the external device 2 is connected and the function is executed by the external device 2 , it seems to the user that the function is added to the vehicle device 1 .

As described above, the external device 2 is assumed to be used by being connected to the vehicle device 1, and the OS 8 and the application 9 mounted there also cooperate with the vehicle device 1, for example, It is capable of responding to confirmation of functions from the device 1 and the like.

Next, the operation of the configuration described above will be described.
As described above, when multiple OSs 8 are installed in the vehicle device 1, the RTOS 81 suitable for real-time processing and the MMOS 82 suitable for multimedia processing may be installed. At this time, as the MMOS 82, the OS 8 used in general mobile terminals 7 and the like may be used.

It is assumed that such an MMOS 82 will be updated relatively frequently, and while the functions installed by the update will be expanded, the required hardware performance will also increase. However, it is difficult to update the hardware of the vehicle device 1 installed in the vehicle, for example, once a year or several years after shipment, and it is difficult to update the MMOS 82 and expand its functions. It is assumed that

Therefore, even after the vehicle device 1 of the present embodiment is shipped, it is possible to add new functions and improve the processing speed of existing functions. The configuration facilitates performance improvement such as expansion of functions provided via the device 1 .

First, I will explain the outline. The vehicle device 1 includes a connection unit 5 to which the external device 2 is connected, and a determination unit 12 that determines whether or not the external device 2 is connected in a operable state. The external device 2 includes a module-side control section 201 capable of executing functions provided when using the vehicle.

In other words, the vehicle device 1 is configured to be able to use the external device 2 connected to the connection unit 5 in addition to the control unit 101 included in itself when providing functions. Therefore, the vehicle device 1 can substantially secure new hardware resources that can be used when providing functions.

Since the vehicle device 1 and the external device 2 are communicably connected via the connection unit 5, the vehicle device 1 and the external device 2 can be connected to each other even after the vehicle device 1 is attached to the vehicle. and can be easily connected. As a result, for example, the external device 2 can be easily connected after shipment, and the performance of the vehicle device 1 can be easily improved. At this time, if the vehicle device 1 and the external device 2 are configured to be USB-connected as in the present embodiment, the connection itself can be easily performed.

Now, in this embodiment, the external device 2 is equipped with, for example, an external device communication application 908 that the vehicle device 1 does not have, and can access the peripheral device 3 via the vehicle device 1 . At this time, for example, an operation screen of the external device communication application 908, an operation result, and the like are displayed on a display or the like.

Therefore, from the user's point of view, the vehicle device 1 looks like a new function has been added. In other words, when the external device 2 is connected in an operable state, the vehicle device 1 can substantially newly secure resources that can be used when providing functions.

Next, specific processing performed by the vehicle device 1 and the external device 2 will be described. 3 and the steady-state sequence showing the flow of processing during normal operation shown in FIG. will be described while comparing the flow of processing of . Although these processes are performed by each unit such as the control unit 101, the data management unit 13, and the module-side control unit 201, the vehicle device 1 and the external device 2 will be described below for the sake of simplification of the description. do.

As shown in FIG. 3, when the vehicle device 1 is powered on, it executes a process of activating the CPU 104 in step S101, and after the CPU 104 is activated, loads the BSP in step S102. BSP is an abbreviation for Board Support Package, and is configured as a group of programs necessary for executing OS8 on the control unit 101, and includes programs for initializing hardware.

When the BSP is loaded, the vehicle device 1 activates the hypervisor in step S103, and after the hypervisor 111 is activated, executes OS activation processing in step S104. In this OS activation process, as shown in FIG. 5, the vehicle device 1 activates the RTOS 81 in step S301, and then activates the MMOS 82A in step S302.

On the other hand, as shown in FIG. 3, when the power is turned on, the external device 2 executes processing for activating the CPU 204 in step S201, loads the BSP in step S202 after the CPU 204 is activated, and Activate MMOS 82B. At this time, in this embodiment, the external device 2 has higher performance than the vehicle device 1, and the software configuration is simple.

Therefore, basically, it is considered that the OS 8 on the external device 2 side starts up before the OS 8 on the vehicle device 1 side starts up, and enters a standby state waiting for an instruction from the vehicle device 1 side. After that, when there is confirmation from the vehicle device 1, the external device 2 waits for the next instruction while executing connection response processing in response to it in step S204.

Now, when the RTOS 81 and MMOS 82A are activated, the vehicle device 1 activates the service bus 112 in step S105, and then executes connection determination processing in step S106. This connection determination process is a process executed by the determination unit 12, and determines whether or not the external device 2 is connected in a function-executable state. Hereinafter, a state in which the external device 2 is connected so as to be able to execute its functions is referred to as a connected state, and a state in which the external device 2 is not connected to the connection section 5 or is operable even if it is connected to the connection section 5. A state that is not is referred to as a canceled state.

In the connection determination process, the vehicle device 1 exchanges data for confirming connection with the external device 2 and determines that the connection is established when there is a response from the external device 2. If there is no response from the external device 2, it is determined to be in the released state. The data exchanged in this connection determination process can be set as appropriate.

For example, the data to be exchanged can include version information of the MMOS 82B, version information of the application 9 installed in the MMOS 82B, and information that can identify the provided functions. This makes it possible to check the connection status, check the functions executable by the external device 2, and determine whether or not the connected external device 2 is supported.

At this time, if the vehicle device 1 determines that it is in a connected state, it stores information such as a serial number unique to the external device 2 so that resetting and the like can be performed when the device is started next time. It is not necessary to do it.

Now, when there is no response from the external device 2, the vehicle device 1 determines that it is in a canceled state in which the execution of the function by the external device 2 is not possible. S108 is omitted. On the other hand, when there is a response from the external device 2, the vehicle device 1 determines that it is in a connected state in which the function can be executed by the external device 2. , an activation process is executed in step S108.

This activation process is a process for causing the connected external device 2 to execute the function. Specifically, as shown in FIG. 6, the vehicle device 1 executes processing for synchronizing with the MMOS 82B in step S401, and allocates resources to the MMOS 82B in step S402. In this step S401, processing for matching the time used by the RTOS 81, MMOS 82A and MMOS 82B is performed, and in step S402, processing for enabling access to the peripheral device 3 from the MMOS 82B is performed.

Subsequently, in step S403, the vehicle device 1 determines whether or not there is backup data. Although the details of the backup data will be described later, the data used by the external device 2 during the previous operation is backed up on the vehicle device 1 side. By delivering this backup data to the external device 2, the external device 2 can execute functions in the same state as before without the trouble of resetting.

Therefore, if there is backup data, the vehicular device 1 restores the backup data in step S404 because YES is determined in step S403. That is, the vehicular device 1 transfers the backup data backed up by itself to the external device 2 so that the external device 2 can use the backup data. Note that, if there is no backup data, the vehicle device 1 determines NO in step S403, and therefore skips step S404 and proceeds to the next step.

Subsequently, in step S405, the vehicle device 1 causes the application 9 on the MMOS 82B side to be executed. For example, in the case of the software configuration shown in FIG. 2, the vehicle device 1 gives an execution instruction to the external device 2 as shown in FIG. 3 in order to execute the external device communication application 908 . Then, the external device 2 to which the execution instruction has been given executes the external device communication application 908 using the allocated resources, and starts providing functions using the mobile terminal 7 .

After that, in step S406, the vehicle device 1 determines whether or not there is a duplicate application. Here, the redundant application means an application 9 installed in the vehicle device 1 that has the same function as the application 9 that instructs the external device 2 to execute. This is done to identify the function to be executed by the external device 2 and stop the identified function.

To put it more simply, a duplicate application is for realizing a function that can be executed by the external device 2 among the functions that can be executed by the vehicle device 1 . Further, overlapping functions include the case where the same function can be provided by the application 9 executed by the external device 2 and the case where the compatible function can be provided.

These specific processes will be described below with reference to another software configuration example shown in FIG. First, as an example in which the same functions can be provided, as shown in FIG. Suppose that In addition, it is assumed that the MMOS 82B of the external device 2 is equipped with a voice recognition application 907B capable of providing the same function as the voice recognition application 907A implemented in the MMOS 82A2 or an upwardly compatible function.

Here, being able to provide the same function means that the function provided by the speech recognition application 907A can be provided by the speech recognition application 907B. In simpler terms, the speech recognition application 907B may be an upper-compatible application 9 of the speech recognition application 907A, and the speech recognition application 907B may provide functions not included in the speech recognition application 907A.

After activating the RTOS 81 and then activating the plurality of MMOS 82 in sequence or in parallel, the vehicular device 1 recognizes the presence of the voice recognition application 907B in the external device 2 in the activation process, and instructs its execution. . On the other hand, the external device 2 activates the plurality of MMOS 82 in order or in parallel and waits for an instruction from the vehicle device 1 .

Then, since the speech recognition application 907A on the MMOS 82A2 provides the same function as the speech recognition application 907B instructing the external device 2 to execute, the vehicle device 1 determines that there is a duplicate application. Become. Therefore, the vehicular device 1 stops the duplicate application in step S407 because the determination in step S406 is YES. Then, in step S408, the vehicular device 1 determines whether or not another application 9 is executed by the MMOS 82A2 in which the redundant application is implemented.

In the case of the example of FIG. 7, one voice recognition application 907A is installed in the MMOS 82A2. to return. However, if there is a duplicate application and the other application 9 is not executed, the duplicate application may be stopped by stopping the OS 8, that is, the function may be stopped by stopping the OS 8. can.

Next, as an example in which compatible functions can be provided, as shown in FIG. A configuration in which is implemented will be described as an example. An external device communication application 908 installed in the external device 2 can access the speaker 305 and the microphone 307 via the vehicle device 1, for example, in order to enable hands-free calling.

At this time, the external device communication application 908 may be able to operate the mobile terminal 7 by voice, such as starting or ending a call or calling up the phonebook, according to the voice input from the microphone 307 . In other words, the external device communication application 908 may include a voice recognition function for recognizing voice input from the microphone 307 .

In this case, if the external device communication application 908 is executed, the voice recognition function can be provided as part of the function of the external device communication application 908 without executing the voice recognition application 907 on the vehicle device 1 side. It is possible. That is, even different applications 9 may be able to provide compatible functions.

Therefore, when the external device communication application 908 is caused to be executed by the external device 2, the vehicle device 1 provides a compatible function. After making a decision, the voice recognition application 907 is stopped in step S407. Since another application 9 is executed in the MMOS 82A, the vehicular device 1 returns YES in step S408.

In this way, if there is a function that overlaps with the function executed by the external device 2, the vehicle device 1 stops its own function by stopping the operation of the overlapping application. Further, when there is a function that overlaps with a function executed by the external device 2, the vehicle device 1 stops its own function by stopping the operation of the OS 8 in which the overlapping application is installed.

Now, when these series of start-up sequences are executed, the vehicle device 1 and the external device 2 execute the normal sequence shown in FIG. It should be noted that the steady state means a normal operating state. The vehicle device 1 executes a steady process in step S109. Although the specific contents of the steady process are omitted, the steady process is various processes required when the vehicle device 1 performs normal operations, and includes processes for providing functions.

In step S206, the external device 2 performs regular processing including various types of processing including, for example, execution of the external device communication application 908. In step S207, the external device 2 performs regular response processing for responding to periodic confirmations from the vehicle device 1, and the like. is repeatedly executed until a predetermined termination condition is satisfied. In the present embodiment, as conditions for terminating the external device 2, it is assumed that notification of a termination instruction from the vehicle device 1 and a drop in the power supply voltage are assumed.

Then, in step S110, the vehicle device 1 executes regular confirmation processing. This periodical confirmation processing includes processing for confirming whether or not the external device 2 is in a connected state, and processing for backing up data from the external device 2 in a connected state. is repeated periodically during normal operation. It should be noted that the period during which the vehicle device 1 is operating normally means the period until it is determined in step S111 that the termination condition is satisfied, that is, the period until the vehicle device 1 terminates the operation.

In this periodic confirmation process, the vehicle device 1 determines whether or not the external device 2 is connected in step S501, as shown in FIG. At this time, the vehicle device 1 determines whether or not the external device 2 is connected, regardless of the state of the external device 2 confirmed in the activation sequence. This is because the external device 2 may be connected later during the operation of the vehicle device 1, or the connected external device 2 may be disconnected for some reason.

Then, when the vehicle device 1 determines that the external device 2 is connected, YES is obtained in step S501, so in step S502 it is determined whether the external device 2 is operating normally. judge. This is because the operation of the external device 2 may malfunction for some reason during the operation of the vehicle device 1 .

When the vehicle device 1 determines that the external device 2 is operating normally, it becomes YES in step S502, so in step S503 it determines whether or not it is a backup cycle. This backup cycle is set in advance. Then, when the backup period comes, the vehicle device 1 executes the backup process in step S504 because the determination in step S503 is YES. This backup processing is mainly executed by the data management unit 13 .

In this backup process, data is transmitted and received between the vehicle device 1 and the external device 2, and in this embodiment, data used by the external device 2 is stored in the storage unit 110 of the vehicle device 1. . The data stored at this time corresponds to backup data, and the backup data is retained even when the vehicle device 1 is powered off.

This backup data includes, for example, data used by the MMOS 82B and data used by the application 9 running on the MMOS 82B. The backup data also includes information such as the type of application 9 running on the external device 2 . That is, the vehicle device 1 is configured to be able to identify the application 9 executed by the external device 2 . Also, the backup data is restored in the external device 2 as described above, thereby enabling the external device 2 to provide functions using the same data as before.

On the other hand, if the vehicle device 1 determines that the external device 2 is not operating normally even if it is in the connected state, the determination in step S502 is NO. Run. To put it simply, this invalidation process cancels the software connection between the vehicle device 1 and the external device 2 to make the external device 2 removable without affecting the vehicle device 1. This process is for

First, as shown in FIG. 9, the vehicular device 1 determines whether or not there is an OS 8 that is stopped in step S601. For example, in the configuration example of FIG. 7 described above, the MMOS 82A2 is stopped in the enabling process. Therefore, the vehicular device 1 determines that the MMOS 82A2 is not activated, and since YES is determined in step S601, the stopped MMOS 82A2 is activated in step S602. That is, the vehicle device 1 restarts the environment for realizing the function.

Then, in step S603, the vehicle device 1 switches the resource allocated to, for example, the MMOS 82B of the external device 2 to its own stopped MMOS 82A2. This allows access to the peripheral device 3 from the MMOS 82A2.

Alternatively, in the case of the configuration example of FIG. 2 described above, the vehicle device 1 determines that there is no OS 8 that is stopped because the MMOS 82A is not stopped in the activation process. In this case, the vehicular device 1 determines YES in step S601, so steps S602 and S603 are omitted and the process proceeds to the next step.

By the way, when invalidating the external device 2, if some function has been executed by the external device 2 until then, interruption of the execution of the function may be disadvantageous to the user. In addition, if a user's operation is required to execute the interrupted function, there is a possibility that the usability will be deteriorated or the user will feel annoyed.

Therefore, in step S604, the vehicle device 1 determines whether or not there is an application 9 that is stopped. That is, the vehicular device 1 determines whether or not there is an application 9 of its own that has stopped due to the provision of the function from the external device 2 . Then, if there is an application 9 whose execution has been stopped such as a duplicate application, or if the application 9 has not yet been executed after starting the OS 8 that has been stopped as described above, the device 1 for a vehicle 1 is stopped. It is determined that there is an application 9 of

In this case, the vehicle device 1 determines YES in step S604, refers to the backup data in step S605, and uses the backup data if necessary to activate the stopped application 9 in step S606. In other words, the vehicle device 1 executes the function that has been stopped by the execution of the external device 2, thereby bringing the function provided by the external device 2 into the same state as if the external device 2 provided the function. to resume its own provision.

This enables the in-vehicle device 1 to provide a function that is no longer provided by the external device 2 by disabling the external device 2, and by referring to the backup data, the functions provided by the external device 2 until then can be provided. It will be possible to provide functionality in the same state as it was.

In other words, since the vehicle device 1 identifies the application 9 being executed by the external device 2 as described above, the vehicle device 1 can recognize functions that are stopped when the external device 2 is stopped. If the function is not possible, that is, if it is not a duplicate application, the function is not provided. Further, when the vehicle device 1 determines that there is no stopped application 9, the determination in step S604 is NO, so steps S605 and S606 are omitted and the process proceeds to the next step.

After that, the vehicle device 1 determines whether or not the external device 2 is connected in step S606. At this time, if the invalidation process is called from the periodic confirmation process, it is considered that the external device 2 is in a connected state. However, as will be described later, the invalidation process may be executed based on an instruction from a user or a dealer worker. It is determined whether That is, the vehicle device 1 reconfirms the connection of the external device 2 .

When the vehicle device 1 determines that the external device 2 is connected, YES is determined in step S606, so the application 9 of the external device 2 is stopped in step S607, and the external device 2 is stopped in step S608. Stop OS8 and return. On the other hand, if the vehicle device 1 determines that the external device 2 is not connected, the determination in step S606 is NO.

In addition, when the vehicle device 1 determines in the regular confirmation process that the external device 2 is not connected, the result in step S501 is NO, so the connection determination process is executed in step S506. This assumes a situation in which the external device 2 is connected while the vehicle device 1 is operating, as described above. In this connection determination process, it is determined whether or not the external device 2 is connected, as in step S106. At this time, the vehicle device 1 also acquires information that can specify the type of the application 9 executed by the external device 2 .

When the vehicle device 1 determines that the external device 2 is in the connected state, it becomes YES in step S507, so it executes the activation process in step S508. As a result, it becomes possible to use the external device 2 and to cause the external device 2 to execute a function. On the other hand, if the vehicle device 1 determines that the external device 2 is not in the connected state, the determination in step S507 is NO, so step S508 is omitted and the process returns.

In this manner, the vehicle device 1 periodically checks the connection state of the external device 2 and whether it is operating normally during normal operation, and confirms whether the external device 2 is operating normally. periodically backs up data used by the external device 2. At this time, the vehicle device 1 can be configured to periodically back up at predetermined time intervals. Further, the vehicle device 1 can be configured to periodically back up at a predetermined time.

Then, as shown in FIG. 4, in step S111, the vehicle device 1 determines whether or not the termination condition is satisfied, and repeatedly executes the steady process and the periodic confirmation process until the termination condition is satisfied. In the present embodiment, it is assumed that the user has input a stop operation to the vehicle device 1 and that the power supply voltage to the vehicle device 1 has decreased as end conditions. As a situation in which the power supply voltage drops, it is assumed that the user turns off the accessory power supply, or that the power supply is cut off due to some kind of trouble.

When the vehicular device 1 determines that the end condition is not satisfied, the result is NO in step S111, so the steady process and the periodic confirmation process are repeated. On the other hand, if the vehicle device 1 determines that the termination condition is met, the determination in step S111 is YES, so in step S112 it is determined whether or not the external device 2 is in the connected state.

Then, when the vehicle device 1 determines that the external device 2 is in the connected state, it becomes YES in step S112. Therefore, after executing the backup process in step S113, the end process is executed in step S114 to complete the process. do. In this termination process, the application 9 is stopped, the OS 8 is shut down, and the termination instruction is notified to the external device 2 .

In addition, the external device 2 determines whether or not the termination condition is satisfied in step S209. The function is provided by repeatedly executing periodic response processing. On the other hand, if the external device 2 determines that the termination condition is satisfied, the result is YES in step S209, and thus termination processing such as stopping the application 9 or shutting down the OS 8 is performed and the processing is terminated.

Thus, the vehicle device 1 determines whether or not the external device 2 is connected to the connection unit 5 in a state in which the function can be executed, and determines whether the external device 2 is connected in a state in which the function can be executed. If it is determined that the application 9 is executed by the external device 2, the function can be provided, and, for example, in the present embodiment, duplicate applications are stopped.

According to the vehicle device 1 described above, the following effects can be obtained.
The vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and a determination unit 12, and determines that the external device 2 is connected in a state in which it can perform its functions. In this case, the external device 2 is enabled to execute its functions, and at least one of its executable functions is stopped.

As a result, for example, in a situation where the vehicle had the required performance at the time of shipment, but a later update of the OS 8 requires higher performance, the function can be provided by connecting the external device 2 . Therefore, the performance can be easily improved.

Further, in the case of using the external device 2 to improve performance, power consumption will increase if redundant functions are executed. Power consumption is suppressed by stopping one of them. As a result, it is possible to suppress an excessive increase in power consumption due to improved performance.

In addition, the vehicle device 1 stops the functions that overlap with the functions executed by the external device 2 among the functions that can be executed by itself. This makes it possible to prevent the loss of functions, that is, the non-provision of functions that can be provided. Also, by stopping overlapping functions, it is possible to suppress an excessive increase in power consumption.

In addition, the vehicle device 1 stops the function by stopping the operation of the application 9 that implements the function. As a result, it is possible to easily stop the function, and it is also easy to restart the provision of the function.

In addition, the vehicle device 1 stops the function by stopping the operation of the OS 8 such as the MMOS 82A on which the application 9 that implements the function is installed. As a result, it is possible to easily stop the function, and it is also easy to restart the provision of the function. Moreover, since resources allocated to the OS 8 can be reduced, the load can be reduced.

Further, when the vehicle device 1 determines that the external device 2 is no longer in a state in which the function can be executed during operation, the vehicle device 1 executes its own function that has been stopped by the execution by the external device 2 . As a result, loss of function can be suppressed. Also, by referring to backup data as in the embodiment, functions can be provided in the same state as provided by the external device 2 .

In addition, the vehicle device 1 repeatedly determines whether or not the external device 2 is in a state in which the function can be executed during the operation of the vehicle device 1 . As a result, even if the connection with the external device 2 is disconnected for some reason or the external device 2 breaks down, it is possible to prevent loss of functions.

The vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and an input unit 10 for inputting an operation. Back up the data you use. As a result, first, by connecting the external device 2, it is possible to easily improve the performance for providing the function.

By backing up the data used by the external device 2, the function can be executed in the same environment when the external device 2 is connected next time. Further, even if the connection of the external device 2 is unintentionally disconnected, the function can be executed in the similar environment on the vehicle device 1 side using the backup data.

In addition, when the external device 2 is connected, the vehicle device 1 periodically backs up data used by the external device 2 . As a result, for example, when the connection of the external device 2 is unintentionally disconnected, the functions that have been executed by the external device 2 can be executed on the vehicle device 1 side in the same environment. It is possible to avoid failure.

In addition, the vehicle device 1 can be configured to back up when the data of the external device 2 is updated, in addition to the configuration of periodically backing up as in the embodiment. At this time, for example, in the periodical confirmation process shown in FIG. You can understand what has been done.

In addition, the vehicle device 1 can back up each time the data is updated, or can back up the data at an arbitrary timing such as when there is a margin in the processing after recognizing that the data has been updated. can.

Also, when the external device 2 is connected, the vehicle device 1 transfers the backed up data to the external device 2 . As a result, the function can be executed in the same environment as before without requiring user's operation such as setting.

Further, the vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and a determination unit 12. , performs the function that was performed by the external device 2 by itself. For example, when the connection of the external device 2 is unintentionally disconnected, the function that has been executed by the external device 2 can be executed on the vehicle device 1 side in the same environment, thereby preventing the malfunction. It is possible to avoid.

Further, when it is determined that the external device 2 is not in a state in which the function can be executed, the vehicle device 1 executes its own function that has been stopped by executing it in the external device 2 . In the example of the embodiment, the function realized by the overlapping application corresponds to its own function whose operation is stopped when the external device 2 executes the function. As a result, it is possible to continue providing the functions without incurring a malfunction such as stopping the functions that have been provided so far.

In addition, the vehicle device 1 executes the function by activating its own application 9 whose operation is stopped when the external device 2 executes the function. In the example of the embodiment, this corresponds to the own application 9 whose operation is stopped when the duplicate application executes the function on the external device 2 . As a result, it is possible to continue providing the functions without incurring a malfunction such as stopping the functions that have been provided so far.

In addition, the vehicle device 1 executes the function by activating its own operating system whose operation was stopped when the external device 2 executed the function. In the example of the embodiment, the MMOS 82A2 shown in FIG. 7 corresponds to its own operating system whose operation is stopped when the external device 2 executes its functions. As a result, it is possible to continue providing the functions without incurring a malfunction such as stopping the functions that have been provided so far.

In addition, the vehicle device 1 repeatedly determines whether or not the external device 2 is in a state in which it can perform its functions during operation. As a result, for example, when the connection of the external device 2 is unintentionally disconnected, it is possible to prevent the functions that have been provided until then from not being provided.

In addition, when the external device 2 is connected, the vehicle device 1 makes the data stored in itself available to the external device 2 . Functions can be executed in the same environment as before without requiring user's operation such as setting.

When the data stored in the external device 2 is updated, the vehicle device 1 backs it up on the vehicle device 1 side. As a result, even if the connection of the external device 2 is unintentionally disconnected, the latest data is backed up, so that the same environment as before can be easily reproduced.

In the embodiment, an example in which the vehicle device 1 and the external device 2 are physically communicably connected by a USB connection as the service bus 112 is shown, but the service bus 112 is not limited to communication by a USB connection, and the vehicle device 1 and the external device 2 can be connected so as to be able to communicate with each other. For example, by adopting a wireless communication circuit as the connection unit 5, the vehicle device 1 and the external device 2 can be configured to be communicably connected without physical connection.

In the embodiment, an example of judging the connection state of the external device 2 by communication is shown, but it is judged whether the external device 2 is connected or the portable terminal 7 having a similar MMOS 82 is connected. Therefore, the vehicle device 1 may be provided with the authentication function of the external device 2 . As a result, it is possible to reduce the risk of erroneously recognizing the portable terminal 7 mounted with a similar MMOS 82 as the external device 2, and to easily improve the performance of the vehicle device 1. You can get the same effect as the form.

Although the embodiment shows an example in which the hypervisor 111 is mounted independently from each OS 8 and each OS 8 is operated on the hypervisor 111, other configurations are possible. For example, if the RTOS 81 has the hypervisor 111 function, the RTOS 81 may be activated first to enable the hypervisor 111 function, and then the MMOS 82A may be executed on the RTOS 81. FIG.

In the embodiment, a software configuration example in which multiple OSs 8 are installed in the vehicle device 1 and one OS 8 is installed in the external device 2 is shown, but other software configurations are possible. For example, as shown in FIG. 10, the vehicle device 1 may have one RTOS 81, and the external device 2 may have a plurality of OSs 8 such as MMOS 82B1 and MMOS 82B2.

Also, a configuration without the firewall 113 is possible. Even with such a configuration, by stopping the application 9 on the side of the vehicle device 1 when providing a function from the external device 2 side, the performance of the vehicle device 1 can be easily improved and the power consumption can be improved. can be reduced, and the same effect as the embodiment can be obtained.

In the embodiment, an example of backing up data by storing it in the storage unit 110 of the vehicle device 1 has been shown. It can be configured such that it is stored in a server on a network that is communicably connected via the mobile terminal 7 . That is, the storage unit 110 can be configured to be provided in the vehicle device 1 or can be configured to be provided outside the vehicle device 1 .

In addition, the vehicle system 4 including the vehicle device 1 and the external device 2 can easily improve performance in a situation where high performance is required, for example, and the performance has been improved. It is possible to similarly obtain the various effects described above, such as being able to suppress an excessive increase in power consumption that accompanies this.

(Second embodiment)
A second embodiment will be described below. In the second embodiment, handling of data in each device will be described. Also, since some of the configurations and processes of the vehicle device 1 and the external device 2 are common to other embodiments, the description will be made with reference to the drawings of the other embodiments.

The external device 2 uses various data when providing functions. Further, the external device 2 side can also store user information transmitted from the vehicle device 1 side as described in the first embodiment. Although these data are basically stored in the module-side storage unit 210 on the external device 2 side, they are also backed up on the vehicle device 1 side as described in the first embodiment.

Since the external device 2 is configured to be connectable to the vehicle device 1, it can be removed from the vehicle device 1 as well. As a situation where a user or a dealer's worker intentionally removes the external device 2 from the vehicle device 1, the external device 2 may be replaced with a newer external device 2, or the external device 2 may be attached to another vehicle device 1. case is conceivable. In this case, in the former case, the vehicle device 1 is the same and the external device 2 is updated, and in the latter case the external device 2 is the same and the vehicle device 1 is updated.

However, it is considered desirable to change the handling of data stored in the external device 2 between the former and the latter. This is because the vehicle device 1 stores data used in vehicle equipment and data used in provided functions, and the data used by the external device 2 is also backed up. This is because, for example, in the former case, it is assumed that the removed external device 2 will not be used thereafter. In other words, in the former case, it is considered that there is little need to leave data in the external device 2 .

On the other hand, in the latter case, if the user information can be migrated to the new vehicle device 1 as it is, resetting and re-inputting of data will be unnecessary, which is considered to be advantageous for the user. In other words, in the latter case, it is considered desirable to leave the data in the external device 2 .

Therefore, when the external device 2 is intentionally removed, the vehicular device 1 executes a process of selectively managing whether or not to erase the data stored in the external device 2 . Although this processing is basically performed by the data management unit 13, the vehicle device 1 will be mainly described below in order to facilitate understanding. Further, the operation of the user or the worker of the dealer can be input at any timing when the vehicle device 1 is in the normal operation state.

The vehicle device 1 accepts operations by displaying an operation menu or the like on the center display 301, for example. At this time, in relation to the present embodiment, the vehicle device 1 displays an icon for inputting an instruction to remove the external device 2, a selection as to whether or not to erase data at that time, and a An HMI such as an icon or a check button that can be set to determine whether or not to migrate data is displayed. Note that the display of the HMI shown here is just an example, and any display that can input similar instructions may be used. Hereinafter, representative removal modes will be individually described.

<Example of erasing data>
When an instruction to erase the data and remove the external device 2 is input, the vehicle device 1 executes the data erasing process shown in FIG. 11 . In this data erasing process, the vehicle device 1 executes a backup process in step S701 to back up the data on the external device 2 side. Subsequently, in step S702, the vehicle device 1 executes erasing processing for actually erasing the data.

In this erasing process, the vehicle device 1 individually erases designated data, collectively erases data by so-called formatting the writable area of the ROM, and initializes the external device 2 so that it can be deleted after shipment. By collectively deleting the stored data, the data stored in the module-side storage unit 210 of the external device 2 is deleted.

Then, when the erasure of the data is completed, the vehicle device 1 executes invalidation processing in step S703. As a result, the software connection between the vehicle device 1 and the external device 2 is released, and the external device 2 can be removed without affecting the vehicle device 1 or the backup data. In addition, since the data on the external device 2 side has been erased, it is possible to reduce the risk of leakage of user information and the like.

<Example of migrating data>
When an instruction to migrate data and remove the external device 2 is input, the vehicle device 1 executes data migration processing shown in FIG. 12 . In this data migration process, the vehicle device 1 executes the migration process of actually migrating the data in step S801.

In this migration process, the vehicle device 1 individually migrates the specified data, or copies the entire writable area of the ROM and migrates it all at once, thereby transferring the data to the storage unit 110 of the vehicle device 1. The stored data is transferred to the external device 2. At this time, by including information such as a serial number unique to the vehicle device 1 in the data to be transferred, the risk of the data being transferred to a different vehicle device 1 can be reduced.

Then, when the data migration is completed, the vehicle device 1 executes invalidation processing in step S802. As a result, the software connection between the vehicle device 1 and the external device 2 is released, and the external device 2 can be removed without affecting the external device 2 or transferred data. In this case, since the data is stored in the external device 2, if the external device 2 is connected to another vehicle device 1, the data can be easily transferred from the previous vehicle device 1 to the new vehicle device 1. can be done.

Therefore, not only when the user migrates the data by himself but also when, for example, a dealer worker wants to migrate the data from the old vehicle device 1 to the new vehicle device 1 after purchasing a new vehicle, the user can easily transfer the data. Data such as information can be migrated.

<Example of removal>
When an instruction to simply remove the external device 2 for inspection or the like is input, the vehicle device 1 executes the removal process shown in FIG. 13 . In this removal process, the vehicle device 1 executes backup processing in step S901, and then executes invalidation processing in step S902.

As a result, the software connection between the vehicle device 1 and the external device 2 is released, and the external device 2 can be removed without affecting the vehicle device 1 and the external device 2 . In this case, since the data is backed up in the vehicle device 1 side and stored in the external device 2 as well, if the external device 2 is reconnected to the vehicle device 1, the previous state can be used. can be done.

<Example of transferring data from external device 2>
The vehicle device 1 can transfer the data stored on the external device 2 side to itself. Specifically, the vehicle device 1 executes the data transfer processing shown in FIG. 14, for example, after the power is turned on and the OS 8 is activated. In this case, the vehicle device 1 determines whether or not the external device 2 is connected in step S1001.

When the vehicle device 1 determines that the external device 2 is connected, YES is determined in step S1001. match or not. The information stored by itself is data acquired when the external device 2 was previously connected.

When the vehicle device 1 determines that the information matches, it returns YES in step S1002, and returns as it is. This is because the connected external device 2 was previously connected, and since the data stored in the external device 2 has already been stored in itself by backup or the like, there is no need to transfer the data. This is because it is conceivable.

On the other hand, if the vehicle device 1 determines that the information does not match, it is NO in step S1002, so in step S1003 it determines whether or not the data transfer is permitted. In this case, the user's permission to transfer the data can be obtained by, for example, displaying a message to the effect that the data is to be transferred and an icon for selecting whether or not to permit the transfer on the center display 301 .

Then, when the data transfer is permitted, the vehicle device 1 transfers the data stored in itself to the vehicle device 1 in step S1004. For example, the vehicle device 1 overwrites the backup data stored in itself with the data stored in the external device 2 .

On the other hand, if the data transfer is not permitted, the vehicular device 1 returns as NO in step S1003. However, even after the data transfer process has been temporarily completed, the vehicle device 1 may perform the data transfer process at an arbitrary timing, such as when an operation instructing data transfer is input by a user or a dealer worker. can be run with

According to the vehicle device 1 described above, the following effects can be obtained.
The vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and an input unit 10 for inputting an operation. Back up the data you use. As a result, it is possible to obtain the same effects as in the first embodiment, such as the ability to easily improve the performance for providing functions by first connecting the external device 2 .

The vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and when the external device 2 is connected to the connection unit 5, data stored in the external device 2 can be used. and a data management unit 13 . This makes it possible to easily transfer data using the external device 2 when, for example, the vehicle is replaced and the vehicle device 1 is updated.

In addition, the vehicle device 1 makes available data used in functions provided when the vehicle is used. This allows us to provide functionality in a similar environment as before.

In addition, the vehicle device 1 makes available data used in vehicle equipment. As a result, the vehicle can be used in the same environment as before, for example, data such as seat position and steering wheel position can be transferred to the new vehicle.
Further, the vehicle device 1 makes available the data used by the peripheral device 3 . This allows us to provide functionality in a similar environment as before.

In addition, the vehicle device 1 makes it possible to select whether or not to use the data stored in the external device 2 . As a result, it is possible to reduce the risk that the HMI or the like will be changed to an unintended state, or that the backup data will be unintentionally updated.

In addition, the vehicle device 1 periodically backs up the data stored in the external device 2 to the vehicle device 1 side. As a result, when migrating or transferring data, the latest data can be migrated or transferred.

In addition, the vehicle device 1 erases the data stored in the external device 2 when the external device 2 is removed. This reduces the risk of data leakage when, for example, the external device 2 is replaced with a new one.

Also, when the external device 2 is removed, the vehicle device 1 causes the external device 2 to store the data stored in the vehicle device 1 . As a result, for example, when the external device 2 is connected to the new vehicle device 1, the same environment as before can be reproduced without requiring user's operation such as setting.

So far, an example has been shown in which data is mainly handled by the vehicle device 1, but the external device 2 can access the peripheral device 3 via the vehicle device 1 and execute its function. A module-side control unit 201, a module-side storage unit 210 for storing data, and data (not shown) for executing a process of transferring stored data to the vehicle device 1 when connected to the vehicle device 1. A data transfer unit may be provided, and the external device 2 may be configured to handle data.

Specifically, the data transfer unit displays an icon or the like to indicate whether the data transfer is permitted or not, indicating that the data is to be transferred, and is stored in the vehicle device 1 when permission is given by the user. It can be configured to update the data that is stored. With such a configuration as well, the same effects as those of the vehicle device 1 can be obtained, for example, data can be easily migrated to a new vehicle device 1 without requiring resetting or re-input of data.

At this time, if the information of the vehicle device 1 is acquired, it is possible to determine whether or not the vehicle device 1 has been previously connected, and the data is stored in the other vehicle device 1 . It is possible to suppress the risk of data being transferred and unintentionally leaked. In addition, if permission is required when transferring data, it is possible to reduce the risk of data leakage or erroneous overwriting of backup data on the vehicle device 1 side.

Further, the vehicle system 4 including the vehicle device 1 and the external device 2 can perform functions in the same environment when the external device 2 is connected next time. Various effects described above can be similarly obtained.

(Third Embodiment)
A third embodiment will be described below. In the third embodiment, the selection of whether or not to use the external device 2 and the selection of which data of the vehicle device 1 and the external device 2 are to be used will be described. Also, since some of the configurations and processes of the vehicle device 1 and the external device 2 are common to other embodiments, the description will be made with reference to the drawings of the other embodiments.

For example, when a new vehicle is purchased, it is assumed that the vehicle device 1 is updated to a new one that matches the vehicle, while the external device 2 is not updated because it is diverted from what has been used up to now. . Hereinafter, in the vehicle device 1 and the external device 2, a relatively new version will be referred to as a higher version, and a relatively older version will be referred to as a lower version.

By the way, in the higher version, the display mode is lower, such as the size, pattern, or position of the icon to be displayed is changed, the icon that existed so far is deleted, or the display name is changed. version may be changed. In addition, regardless of the display mode, in the higher version, for example, the menus that have been used so far may disappear, the menus may have different names, or the hierarchical structure of the menu may change to change the operation procedure. version may be changed.

In other words, the HMI, such as the display mode and operation mode, may change as the version is upgraded. At this time, since version upgrades are basically done to improve performance and fix problems, it is thought that HMI changes accompanying version upgrades will be done to make them more suitable. be done.

However, when the HMI is changed, in addition to the need to learn a new operation mode, the user may feel that the operation has become difficult because the display mode is different from the display mode that they have been accustomed to, or they may not be able to perform the desired operation. It is also assumed that it will take time and effort. In other words, it is assumed that the change of HMI may become a demerit for the user.

Therefore, the vehicular device 1 of the present embodiment makes it possible to select which version to use, the higher version or the lower version. That is, the vehicular device 1 selects whether to use the functions of the external device 2, selects which data to use, and selects whether to use HMI-related functions. Although these processes are basically performed by the data management unit 13 and the selection unit 14, the vehicle device 1 will be mainly described below for simplification of description.

As shown in FIG. 15, vehicle-side identification information 20 is stored in the storage unit 110 of the vehicle device 1, and module-side identification information 21 and transition data 22 are stored in the module-side storage unit 210 of the external device 2. It is In FIG. 15, illustration of the firewall 113, the application 9, and the like is omitted for the sake of simplicity of explanation.

The vehicle-side identification information 20 is data including information that can identify the version of the vehicle device 1, and can be read from the RTOS 81 and MMOS 82A. The vehicle-side identification information 20 includes, for example, information unique to the vehicle device 1 such as the serial number and date of manufacture, and information belonging to the same product group such as the type and version of the installed OS 8 and application 9. Information common to the vehicle device 1 is included.

The module-side identification information 21 is data containing information that can identify the version of the external device 2, and can be read from the MMOS 82B. The module-side identification information 21 is data including information that can identify the version of the external device 2, and can be read from the MMOS 82B.

The module-side identification information 21 includes, for example, information unique to the external device 2 such as the serial number and date of manufacture, and external information belonging to the same product group such as the type and version of the installed OS 8 and application 9. It contains information common to the device 2 . The transfer data 22 includes data used by the external device 2 and data transferred from the vehicle device 1 such as the user information described above, and can be read from the MMOS 82B.

Therefore, by communicating with the external device 2, the vehicle device 1 can acquire the version of the external device 2 for each device or for each individual application 9, and can also acquire the transition data 22. At this time, for the transfer data 22, by referring to the contents of the data, it is possible to selectively acquire data that can be used by the peripheral device 3 mounted on the current vehicle. Similarly, the external device 2 can acquire the version of the vehicle device 1 for each device or for each individual application 9 by communicating with the vehicle device 1 .

With such a configuration, the vehicle device 1 executes a device selection process for selecting whether or not to use the external device 2, for example, at startup, as shown in FIG. However, the device selection process can be executed at any timing other than at startup, and even after it has been executed once, according to an instruction from the user or the dealer's operator.

As in the startup sequence described in the first embodiment, when the power is turned on, the vehicle device 1 starts the CPU 104 in step S1101, loads the BSP in step S1102, and starts the hypervisor 111 in step S1103. Then, in step S1104, OS startup processing is executed, and in step S1105, the service bus 112 is started. Subsequently, the vehicular device 1 performs connection determination processing in step S1106, and if it determines that it is in a connected state, it becomes YES in step S1107, and thus performs device selection processing in step S1108.

In this device selection process, as shown in FIG. 17, the vehicle device 1 determines in step S1201 whether or not the external device 2 is of a higher version. In this case, the vehicle device 1 refers to and compares the vehicle-side identification information 20 and the module-side identification information 21 to determine which is the higher version.

Although the vehicle device 1 can acquire the module-side identification information 21 from the external device 2 in step S1201 for comparison, the module-side identification information 21 is acquired in advance in the connection determination process in step S1106. A comparison can also be made in step S1201.

When the vehicle device 1 determines that the external device 2 is of a higher version, the determination in step S1201 is YES, so in step S1202 the external device 2 is registered as a valid device and the process returns. Here, a valid device means a device whose use is permitted. That is, in steps S1201 and S1202, the vehicle device 1 uses the external device 2 because it is considered that the performance will be improved when the external device 2 with a newer version than itself is connected.

Further, when registered as a valid device, information indicating that it has been registered as a valid device is stored together with the module-side identification information 21, and is used to confirm whether or not the device has already been registered at the time of subsequent connection. . In other words, when the use of the external device 2 is selected, the vehicular device 1 takes over the state of use from the next time onwards. It is possible to take over the state that is not used after that.

On the other hand, if the vehicle device 1 determines that the external device 2 is of a lower version, the determination in step S1201 is NO. It is determined whether or not the device has been registered.

If the vehicular device 1 determines that it is a registered device, it is YES in step S1203, so the process moves to step S1202, registers it as a valid device, and returns. Note that in the case of a registered device, if data such as user information and settings have been backed up at the time of past use, the data will be used to operate.

On the other hand, if the vehicular device 1 determines that it is not a registered device, it is NO in step S1203, so it determines whether or not to register in step S1204. In this case, the vehicle device 1 displays, for example, an icon or the like for selecting whether or not to register on the center display 301 and waits for an operation by the user or the dealer. You can check if you register.

On the other hand, the vehicle device 1 can determine that registration is not to be performed when an operation to the effect that registration is not performed is input or an operation is not performed within a predetermined period of time. Note that the predetermined time can be set as appropriate, but if the predetermined time is extremely short, the processing will be the same as not substantially waiting, and if the predetermined time is long, the processing will substantially wait until an operation is input. The same processing time as

If the vehicle device 1 determines to register, the result is YES in step S1204, so the process proceeds to step S1202, registers as a valid device, and returns. On the other hand, if the vehicle device 1 determines not to register, it becomes NO in step S1204. determine whether

This is because if a relatively old version of the external device 2 is connected, it may have been connected for data migration as described in the second embodiment. In this case, the vehicle device 1 displays an icon or the like for selecting whether or not to share on the center display 301, for example, and waits for an operation by the user or the dealer. If an operation to the effect of not sharing is input or if the operation is not performed within a predetermined time, it is determined not to be shared.

When the vehicular device 1 determines to share the data, YES is obtained in step S1205, so the data is shared in step S1206. At this time, the vehicle device 1 acquires the transfer data 22 stored in the external device 2 and stores it in its own storage unit 110, or stores, for example, the seat position, the steering wheel position, the home address, the telephone directory, the music, etc. By registering user information in itself, it is possible to easily share data between different vehicle apparatuses 1, ie, transfer data here.

After sharing the data, the vehicle device 1 registers as an invalid device in step S1207, and then returns. Here, an invalid device means a device whose use is not permitted. On the other hand, if the vehicle device 1 determines to share the data, it is NO in step S1205, so it registers as an invalid device in step S1207 and then returns.

After returning from the device selection process, the vehicle device 1 determines whether or not it is a valid device in step S1109, as shown in FIG. Since it is determined as YES in step S1109, validation processing is executed in step S1110, and the process shifts to normal processing. Note that in the activation process, as shown in FIG. 6, processes such as synchronization of the OS 8, restoration of data, and suspension of overlapping applications are executed as necessary.

On the other hand, if the vehicle device 1 is registered as an invalid device in the device selection process, it determines that it is not a valid device, and since the result in step S1109 is NO, the process shifts to normal processing. However, the vehicular device 1 can be operated by a user or a dealer's worker to execute a device selection process, or can be directly executed to be registered as a valid device.

In other words, even if the external device 2 is once registered as an invalid device, the vehicle device 1 can re-register it as a valid device or migrate the data. In other words, the vehicular device 1 makes it possible to reselect whether or not to use what was once selected not to be used.

According to the vehicle device 1 described above, the following effects can be obtained.
The vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and an input unit 10 for inputting an operation. Back up the data you use. As a result, it is possible to obtain the same effects as those of the first and second embodiments, such as the ability to easily improve the performance for providing functions by connecting the external device 2 .

In addition, the vehicle device 1 includes a control unit 101, a connection unit 5 to which the external device 2 is connected, and a selection unit 14 that executes processing related to selection of whether or not to use the external device 2. 2 is selected, the external device 2 is made available. This makes it possible to select whether or not to use the external device 2 when, for example, there is a possibility that the HMI or operation mode will change due to version upgrade, and usability can be improved.

In addition, the selection unit 14 of the vehicle device 1 allows the user to select whether or not to use the external device 2 itself. As a result, it becomes possible to select which of the vehicle device 1 and the external device 2 to use on a device-by-device basis, and for example, it is possible to easily provide new functions.

In addition, the vehicle device 1 allows the user to select whether or not to use the functions provided by the external device 2 . As a result, it is possible to select on a function-by-function basis which of the functions provided by the vehicle device 1 and the functions provided by the external device 2 is to be used, and the functions can be provided in a more desirable state.

In addition, the vehicle device 1 allows the user to select whether or not to use functions related to the human-machine interface. As a result, it becomes possible to use the one that is easier to use, and it is possible to provide functions in a more favorable state.

In addition, the vehicle device 1 takes over the result of selection as to whether or not to use the external device 2 during subsequent operations. As a result, a desired environment can be reproduced without taking the time and effort to make the user select each time the device is activated.

In addition, the vehicle device 1 makes it possible to reselect whether or not to use the items that were once selected not to be used. As a result, when the version is updated and new functions are provided, the new functions can be used easily. This also applies to data described later.

Further, when the use of the external device 2 is selected, the vehicle device 1 does not execute the functions executed by the external device 2 by itself. Thereby, an increase in power consumption can be suppressed.

In addition, the vehicle device 1 can be configured so that the data used by the peripheral device 3 can be used. As a result, it is possible to prevent useless data from being stored when, for example, the vehicle is updated and the configuration of the peripheral device 3 is changed.

In the embodiment, the version of the vehicle device 1 and the version of the external device 2 are compared to determine the higher or lower rank for each device. , each application 9, or each data such as user information, a higher rank or a lower rank is determined to select valid/invalid.

At this time, the configuration for comparing versions also includes the configuration for comparing the functions that each has. This is because it is assumed that functions that were not present in the lower version will be added to the higher version, or functions that existed in the lower version will be deleted. That is, when the functions provided by the vehicle device 1 and the functions provided by the external device 2 are different, the process of selecting whether or not to use the external device can be executed.

The vehicle device 1 executes the data selection process shown in FIG. 18 in order to selectively use the data. This data selection process can be automatically executed at startup, or can be executed at an arbitrary timing based on instructions from the user or the dealer's operator.

Further, for example, the data selection process may be executed when the external device 2 is connected for the first time, and the data selection process may not be executed for the external device 2 that has already been registered the next time it is connected. That is, the vehicular device 1 can take over the result of selection as to whether or not to use the device and data in subsequent operations.

Although this data selection process is basically executed by the selection unit 14, the vehicle device 1 will be mainly described below for the sake of simplification of the description. Also, hereinafter, new data corresponding to a higher version will be referred to as new data, and old data corresponding to a lower version will be referred to as old data.

The data stored in the vehicle device 1 also includes the backup data described above. In addition, since the OS 8 and the application 9 can also be regarded as data in a broad sense, they are collectively referred to as data here. That is, the vehicle device 1 can select whether or not to use the data stored by the external device 2 .

The vehicle device 1 first compares the data stored in itself with the data stored in the external device 2 in step S1301, and determines whether or not to use the new data in step S1302.

In this case, the vehicle device 1 displays an icon or the like for selecting whether or not to use the new data on the center display 301, for example, and waits for an operation by the user or the dealer. is determined to use the new data, and when an operation to the effect that it is not used is input or when the operation is not performed within a predetermined time, it is determined not to be used. However, it is also possible to adopt a configuration in which new data is preferentially used without providing step S1302.

When the vehicle device 1 determines that the new data is to be used, the determination in step S1302 is YES, so in step S1303 the new data is selected as data to be used and returns. In this case, the vehicle device 1 makes the new data available by overwriting the old data with the new data or transferring the new data to the device that stored the old data. That is, the OS 8 and the application 9 are made to operate using the new data.

On the other hand, when the vehicle device 1 determines that the new data is to be used, the determination in step S1302 is NO, so step S1303 is omitted and the process returns. That is, the vehicle device 1 allows each device to operate in the same environment as before without updating data. As a result, it is possible to prevent the operating environment from being changed unintentionally.

In this way, the vehicle device 1 can be configured to compare the data stored in the external device 2 and the data stored in itself, select the newer data, and make it available. . With such a configuration, it is possible to select which of the new data and the old data to use when the data stored in each device is different.

For example, even if the version of the external device 2 is old, if an application 9 has been updated and has a newer version than the application 9 on the side of the vehicle device 1, the external device 2 side is regarded as a higher order for the application 9. It is possible to execute processing such as enabling by

At this time, the vehicle device 1 can confirm the version of the applications 9 installed in the external device 2 that are compatible with the applications 9 installed in itself. That is, it is possible to compare the functions of the vehicle device 1 and the functions of the external device 2 .

In addition, the vehicle device 1 can repeat confirmation of the version for each application 9. For example, when communicating with the external device 2 in the connection determination process, information including the application 9 on the external device 2 side and each version is obtained. is acquired in advance, and versions of a plurality of applications 9 can be confirmed. The same applies to the OS 8 installed in each device.

In addition, by making it possible to select whether or not to use a lower version, it is possible to continue to use the familiar environment. For example, assume that an application 9 of a newer version than the application 9 installed in the vehicle device 1 is installed in the external device 2 .

In that case, if the higher version is enabled as in the embodiment, it is assumed that an HMI different from the lower version application 9 installed in the vehicle device 1 is provided. Even in such a case, by making it possible to select whether to use the upper level or the lower level, the apparatus can be used without requiring skill in operation.

Further, even with the vehicle system 4 including the vehicle device 1 and the external device 2, it is possible to select whether or not to use the external device 2 when there is a possibility that the HMI or the operation mode may change due to, for example, a version upgrade. can be achieved, and the above-described various effects such as improved usability can be similarly obtained.

Each of the above-described embodiments can replace all or part of its configuration with all or part of the configuration of other embodiments, for example, by enabling the processing illustrated in the second embodiment to be executed during the steady processing of the first embodiment. It can be appropriately combined with the part.

Although the present disclosure has been described with reference to examples, it is understood that the present disclosure is not limited to those examples or structures. The present disclosure also includes various modifications and modifications within the equivalent range. In addition, various combinations and configurations, as well as other combinations and configurations, including single, more, or less elements thereof, are within the scope and spirit of this disclosure.

The controller and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by the computer program. may be Alternatively, the controls and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the control units and techniques described in this disclosure can be implemented by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. It may also be implemented by one or more dedicated computers configured. The computer program may also be stored as computer-executable instructions on a computer-readable non-transitional tangible recording medium.

Claims

a control unit (101) capable of accessing peripheral devices (3) and executing functions provided when using the vehicle;
a connection unit (5) to which an external device (2) capable of communicating with the control unit and capable of executing functions provided when using the vehicle is connected;
A selection unit (14) that executes processing related to selection of whether or not to use the external device,
A device for a vehicle, wherein the control unit enables the use of the external device when use of the external device is selected.
The vehicle device according to claim 1, wherein the selection unit executes a process of selecting whether or not to use the external device when a function provided by the vehicle device and a function provided by the external device are different.
3. The vehicle device according to claim 1 or 2, wherein the selection unit executes a process of selecting whether or not to use the external device when a function provided by the external device is older than a function provided by the vehicle device.
The vehicular device according to any one of claims 1 to 3, wherein the selection unit allows a user to select whether or not to use a function related to the human-machine interface.
The vehicular device according to any one of claims 1 to 4, wherein the selection unit executes processing for selecting whether or not to use the data stored in the external device.
The vehicular device according to any one of claims 1 to 5, wherein the selection unit carries out a process of handing over the selection result as to whether or not to use it in subsequent operations.
The vehicular device according to any one of claims 1 to 6, wherein the selection unit executes a process of enabling re-selection of whether to use or not for those once selected not to be used.
The vehicular device according to any one of claims 1 to 7, wherein the control unit does not execute the function executed by the external device by itself when the use of the external device is selected.