In-vehicle device and startup method

Abstract

According to the present invention, a data collection device (2) comprises: first and second units (100, 110) operated by a first control unit (11); and a second microcomputer (15). The second microcomputer (15) detects an abnormality of the first unit (100) and the second control unit (15), and the first unit (100) detects an abnormality of the second unit (110). During abnormality detection of the first or second unit (100, 110), the second microcomputer (15) restarts the first and second units (100, 110), and during abnormality detection of the second microcomputer (15), the second microcomputer (15) restarts the first and second units (100, 110) and the second control unit (15).

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2021-110911, filed with the Japan Patent Office on July 2, 2021, and the entire contents of Japanese Patent Application No. 2021-110911 are incorporated by reference into this international application. [Technical field]

[0002] The present disclosure relates to an in-vehicle device capable of accessing a cloud and a method for starting the in-vehicle device. [Background technology]

[0003] As described in Patent Document 1, an in-vehicle device is known that is equipped with an OS having real-time capabilities (hereinafter, referred to as RTOS) and a general-purpose OS not having real-time capabilities (hereinafter, referred to as GPOS). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-201762 A Summary of the Invention

[0005] However, as a result of detailed investigation by the inventors, it was found that in order to improve the reliability of such an in-vehicle device, it is necessary to appropriately monitor the GPOS and RTOS. One aspect of the present disclosure provides a technique for improving the reliability of an in-vehicle device.

[0006] One aspect of the present disclosure is an in-vehicle device that can access a cloud via a communication unit, and includes a first control unit, a first unit, a second unit, and a second control unit. The first control unit has at least one physical core. The first unit is configured to operate by the first control unit and perform processing related to hardware control. The second unit is configured to operate by the first control unit and perform processing related to service provision. The second control unit is configured to start the first control unit in response to the occurrence of a start-up cause. When started by the second control unit, the first control unit is configured to start the first unit before the second unit. The second control unit is configured to detect an abnormality in the first unit and an abnormality in the second control unit. The first unit is configured to detect an abnormality in the second unit. The second control unit is configured to restart the first and second units when an abnormality in the first or second unit is detected, and to restart the first and second units and the second control unit when an abnormality in the second control unit is detected.

[0007] According to the above configuration, abnormalities in the first and second units and the second control unit can be detected effectively. When an abnormality in the first or second unit is detected, the first and second units are restarted, and when an abnormality in the second control unit is detected, the first and second units and the second control unit are restarted. Therefore, abnormalities in the first and second units and abnormalities in the second control unit can be dealt with effectively. Therefore, the reliability of the in-vehicle device can be improved.

[0008] In the above-described in-vehicle device, the procedure performed by the first and second control units may be provided as a startup method, which provides the same effects as those described above. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing the configuration of a mobility IoT system. [Diagram 2] FIG. 2 is a block diagram showing a configuration of a data collection device. [Diagram 3] FIG. 2 is a block diagram showing a program configuration of the data collection device. [Figure 4] FIG. 2 is a block diagram of a program that realizes each function of the data collection device. [Diagram 5] FIG. 2 is a state transition diagram of the operation mode of the data collection device. [Figure 6] 13 is a flowchart of a startup process. [Figure 7] 13 is a flowchart of a second microcomputer monitoring process. [Figure 8] 13 is a flowchart of a first unit monitoring process. [Figure 9] 13 is a flowchart of a low power mode transition process. [Figure 10] 13 is a flowchart of a stop mode transition process. [Figure 11] 1 is a block diagram showing a connection state when a plurality of ECUs including a data collection device are mounted on a vehicle. [Figure 12] FIG. 13 is a block diagram showing a program configuration of a data collection device in a modified example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. [1. Overall composition] 1, a mobility IoT system 1 of this embodiment includes a plurality of data collection devices 2 that can access a cloud 3 via a wide area wireless communication network NW, and a management center 3a and a service providing server 3b provided by the cloud 3. Note that IoT is an abbreviation for Internet of Things.

[0011] The data collection device 2 is mounted on a vehicle and has a function of performing data communication with the management center 3a. Hereinafter, the vehicle on which the data collection device 2 is mounted is referred to as the host vehicle. The management center 3a manages the mobility IoT system 1. The management center 3a has a function of performing data communication between the multiple data collection devices 2 and the service providing server 3b via the wide area wireless communication network NW.

[0012] The service providing server 3b is, for example, a server for providing a service for managing vehicle operation. The mobility IoT system 1 may include multiple service providing servers each providing different service contents.

[0013] [2. Data collection device configuration] As shown in FIG. 2, the data collection device 2 includes a first microcomputer 11, a vehicle interface (hereinafter, vehicle I / F) 12, a communication unit 13, a storage unit 14, and a second microcomputer 15.

[0014] The first microcomputer 11 includes first to third cores 21 to 23 which are physical cores, a ROM 24, a RAM 25, a flash memory 26, an input / output unit 27, and a bus . Various functions of the first microcomputer 11 are realized by the first to third cores 21 to 23 executing a program stored in a non-transient substantial recording medium. In this example, the ROM 24 and the RAM 25 correspond to the non-transient substantial recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions realized by the first to third cores 21 to 23 may be realized by hardware such as at least one IC.

[0015] The flash memory 26 is a rewritable non-volatile memory. The input / output unit 27 is a circuit for inputting and outputting data between the outside of the first microcomputer 11 and the first to third cores 21 to 23.

[0016] The bus 28 connects the first to third cores 21 to 23, the ROM 24, the RAM 25, the flash memory 26, and the input / output unit 27 so as to enable data input / output between them. The vehicle I / F 12 is an input / output circuit for inputting and outputting signals between the data collection device 2 and other electronic control devices, sensors, etc. The vehicle I / F 12 includes, for example, a power supply voltage input port, a general-purpose input / output port, a CAN communication port, an Ethernet communication port, a wireless LAN communication port, a short-range wireless communication port, a GPS communication port, and a camera communication port.

[0017] The power supply voltage input port is connected to a battery of the host vehicle which serves as the power source for the data collection device 2, and the voltage of the power supply is input to the power supply voltage input port. A CAN communication port is a port for transmitting and receiving data according to the CAN communication protocol. An Ethernet communication port is a port for transmitting and receiving data based on the Ethernet communication protocol. CAN is an abbreviation for Controller Area Network. CAN and Ethernet are registered trademarks.

[0018] Other electronic control units mounted on the vehicle are connected to the CAN communication port and the Ethernet communication port, which allows the data collection device 2 to transmit and receive communication frames to and from the other electronic control units.

[0019] The wireless LAN communication port is a port for transmitting and receiving data via wireless LAN. The short-range wireless communication port is a port for transmitting and receiving data via a short-range wireless communication technology such as Bluetooth (registered trademark). These ports can be connected to communication control devices, and the data collection device 2 transmits and receives data to and from other electronic control devices via the communication control devices connected to the ports.

[0020] The GPS communication port is a port to which a device equipped with a GPS is connected, and the data collection device 2 controls the GPS via the GPS communication port. The camera communication port is a port to which a camera mounted on the vehicle is connected. The camera is configured to capture images of the surroundings and / or the interior of the vehicle, and the data collection device 2 controls the camera via the camera communication port.

[0021] In addition, various devices, such as a device for performing machine learning or a monitor, can be connected to the general-purpose input / output port in the vehicle I / F 12. The communication unit 13 is connected to the data collection device 2 via a communication port. The communication unit 13 accesses the wide area wireless communication network NW by wireless communication according to a communication standard such as LTE, and performs data communication with the cloud 3 via the wide area wireless communication network NW.

[0022] The storage unit 14 is a storage device for storing various data. The second microcomputer 15 starts and stops the first microcomputer 11. The second microcomputer 15 is configured to execute real-time processing, and has a lower processing load than the first microcomputer 11.

[0023] 11, the vehicle is equipped with one ECU 210, a plurality of ECUs 220, a plurality of ECUs 230, an exterior communication device 240, and an interior communication network 250. ECU is an abbreviation for Electronic Control Unit.

[0024] The ECU 210 controls a plurality of ECUs 220 to realize coordinated control of the entire vehicle. An ECU 220 is provided for each domain divided according to the vehicle's functions, and mainly controls a plurality of ECUs 230 present in the domain. Each ECU 220 is connected to the subordinate ECUs 230 via a lower-layer network (e.g., CAN) provided individually for each ECU 220. The ECU 220 has a function of centrally managing access rights to the subordinate ECUs 230 and authenticating users. The domains are, for example, a power train, a body, a chassis, and a cockpit.

[0025] The ECUs 230 connected to the ECU 220 belonging to the powertrain domain include, for example, an ECU 230 that controls an engine, an ECU 230 that controls a motor, and an ECU 230 that controls a battery.

[0026] The ECUs 230 connected to the ECU 220 belonging to the body domain include, for example, an ECU 230 that controls an air conditioner, an ECU 230 that controls doors, and the like. The ECUs 230 connected to the ECU 220 belonging to the chassis domain include, for example, an ECU 230 that controls braking, and an ECU 230 that controls steering.

[0027] The ECUs 230 connected to the ECU 220 belonging to the cockpit domain include, for example, an ECU 230 that controls the display of meters and navigation, and an ECU 230 that controls an input device operated by a vehicle occupant.

[0028] The external vehicle communication device 240 performs data communication with a communication device (eg, a cloud server) outside the vehicle via the wide area wireless communication network NW. The in-vehicle communication network 250 includes CAN FD and Ethernet. CAN FD is an abbreviation for CAN with Flexible Data Rate. The CAN FD connects the ECU 210 to each ECU 220 and the external-vehicle communication device 240 via a bus. The Ethernet connects the ECU 210 to each ECU 220 and the external-vehicle communication device 240 individually.

[0029] The ECU 210 is an electronic control device mainly composed of a microcomputer including a CPU 210a, a ROM 210b, a RAM 210c, etc. Various functions of the microcomputer are realized by the CPU 210a executing a program stored in a non-transient real recording medium. In this example, the ROM 210b corresponds to the non-transient real recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 210a may be configured in hardware form using one or more ICs, etc. Also, the number of microcomputers constituting the ECU 210 may be one or more.

[0030] Like the ECU 210, the ECU 220, the ECU 230, and the exterior communication device 240 are all electronic control devices mainly configured with a microcomputer including a CPU, a ROM, a RAM, etc. Also, the number of microcomputers constituting the ECU 220, the ECU 230, and the exterior communication device 240 may be one or more. The ECU 220 is an ECU that controls one or more ECUs 230, and the ECU 210 is an ECU that controls one or more ECUs 220 or controls the ECUs 220, 230 of the entire vehicle including the exterior communication device 240.

[0031] The data collection device 2 is connected to the ECU 210 so as to be able to communicate data with the ECU 210. That is, the data collection device 2 receives information from the ECUs 210, 220, and 230 via the ECU 210. The data collection device 2 also transmits requests related to vehicle control to the ECU 210 and to the ECUs 220 and 230 via the ECU 210.

[0032] [3. Program Structure] The first microcomputer 11 of the data collection device 2 executes programs stored in the ROM 24 and programs loaded into the RAM 25. These programs include first and second units 100, 110 and firmware 120 (see FIG. 3).

[0033] The first unit 100 is executed by the first core 21 and includes a real-time operating system (hereinafter, RTOS) 101 and at least one first application 102. However, the first unit 100 does not need to include the first application 102. Note that the application is an abbreviation of application. In the present embodiment, the first unit 100 includes, as an example, a plurality of first applications 102. The first application 102 mainly performs processing related to hardware control, and the processing performed by the first application 102 has real-time characteristics. In addition, the RTOS 101 operates the first application 102 so as to ensure the real-time characteristics of the processing by the first application 102. For example, the first application 102 controls a camera (not shown) connected to the data collecting device 2, communicates with an ECU connected to the data collecting device 2, and issues instructions to other electronic control devices via the ECU.

[0034] The second unit 110 is executed by the second core 22 and includes a general purpose operating system (hereinafter, GPOS) 111 and at least one second application 115. In the present embodiment, the second unit 110 includes, as an example, a plurality of second applications 115. The second application 115 mainly executes a process for providing a service to a user. More specifically, the second application 115 may execute a process for realizing a service provided by the cloud 3, or may execute a process for realizing a service provided without linking with the cloud 3. The process executed by the second application 115 does not have real-time properties. The GPOS 110 is basic software that operates the second application 115 without ensuring real-time properties. For example, Linux (registered trademark) may be used as the GPOS 111.

[0035] Moreover, the GPOS 111 includes a device driver 112, a library 113, and a package 114, which constitute software resources in the GPOS 111. The device driver 112 is a program for controlling hardware resources provided in the first microcomputer 11 or in its periphery. The library 113 and the package 114 are programs for realizing specific functions.

[0036] Furthermore, the GPOS 111 includes a container engine, and all or a part of the second application 115 that runs on the GPOS 111 is container-based virtualized. The container-based virtualized second application 115 is configured to perform processing using a device driver 112, a library 113, and a package 114 provided in the GPOS 111.

[0037] Of course, the second unit 110 may include a second application 115 that is not container-based virtualized. Such a second application 115 may also be configured to perform processing using the device driver 112, library 113, and package 114 provided in the GPOS 110.

[0038] The firmware 120 is executed by the third core 23 to perform boot processing of the first microcomputer 11 and start and stop the first and second units 100 and 110. A part of the RAM 25 of the first microcomputer 11 is configured as a shared memory accessible by the first to third cores 21 to 23. The first and second units 100, 110 and the firmware 120 (in other words, the first to third cores 21 to 23) transmit and receive data via the shared memory and the bus 28.

[0039] [4. About the function] The first microcomputer 11 of the data collection device 2 performs processing for providing a vehicle function and a service function (see FIG. 4). The vehicle function is mainly a function related to the control of the data collection device 2 and an electronic control device connected to the data collection device 2. The data collection device 2 also has a function as an edge that performs processing for realizing a service provided by the cloud 3. The service function corresponds to the function as an edge.

[0040] Some of the vehicle functions are realized by a first application 102 that runs on an RTOS 101. In addition, a vehicle management unit 130 is provided as a program for realizing the vehicle functions. The vehicle management unit 130 includes a security management unit 131, a vehicle authority management unit 132, a vehicle user management unit 133, and a vehicle state management unit 134.

[0041] The security management unit 131 provides functions related to the security of the vehicle. Specifically, for example, the security management unit 131 may perform processing for preventing tampering with vehicle data, such as encryption of vehicle data.

[0042] The vehicle authority management unit 132 restricts access to vehicle data and the like in accordance with the authority of the user who uses the data collection device 2 . The vehicle user management unit 133 adds and deletes users who use the data collection device 2, and sets the authority of each user.

[0043] The vehicle state management unit 134 starts and stops the RTOS 101 and manages the power supply of the data collection device 2 . In addition, there are provided an API 140, a standardization processing unit 141, a vehicle data acquisition unit 142, a cloud communication unit 143, a GPS control unit 144, a video control unit 145, and a sensor control unit 146 as programs for realizing vehicle functions.

[0044] The API 140 provides an interface for using a program for implementing a vehicle function, and is configured to restrict the use of the program according to the authority given to the user.

[0045] The standardization processing unit 141 converts the vehicle data acquired by the vehicle data acquisition unit 142 into a standard format, and stores the converted vehicle data in the flash memory 26 as standardized vehicle data.

[0046] The vehicle data acquisition unit 142 acquires a communication frame having vehicle data from an electronic control device mounted on the vehicle via the vehicle I / F 12. The vehicle data is data indicating the state of the vehicle. Specifically, the vehicle data may include, for example, the running state such as the vehicle speed and steering angle, the attributes of the vehicle such as the vehicle type, the remaining amount of fuel or the battery of the vehicle, and the like.

[0047] The cloud communication unit 143 communicates with the cloud 3 via the communication unit 13 . The GPS control unit 144 controls the GPS connected to the vehicle I / F 12 to detect the current location of the vehicle.

[0048] The image control unit 145 controls the camera connected to the vehicle I / F 12 to capture images of the surroundings or interior of the vehicle and to obtain captured image data. The sensor control unit 146 controls a sensor (eg, UWB) connected to the vehicle I / F 12, and acquires detection data by the sensor.

[0049] The security management unit 131, the vehicle state management unit 134, the vehicle data acquisition unit 142, the video control unit 145, and the sensor control unit 146 operate on the RTOS 101, and are included in the first unit 100. The vehicle authority management unit 132, the vehicle user management unit 133, the cloud communication unit 143, and the GPS control unit 144 operate on the GPOS 111, and these components are included in the second unit 110. On the other hand, the API 140 and the standardization processing unit 141 operate on the RTOS 101 and the GPOS 111, and are included in the first and second units 100, 110.

[0050] On the other hand, a part of the service function is realized by the second application 115 operated by the GPOS 111. Specifically, for example, the second application 115 may detect a suspicious person using a sensor such as a camera connected via the vehicle I / F 12, or may detect an accident of the vehicle using a collision sensor connected via the vehicle I / F 12. In addition, the second application 115 includes a service management unit 150, an API 160, and a vehicle data providing unit 161 as programs for realizing the vehicle function. The service management unit 150 also includes a security management unit 151, a process management unit 152, a service authority management unit 153, a service user management unit 154, and an edge state management unit 155.

[0051] The security management unit 151 performs processing for ensuring security when the data collection device 2 accesses the cloud 3. Specifically, the security management unit 151 performs processing for, for example, encrypting data to be transmitted to the cloud 3, decrypting encrypted data received from the cloud 3, preventing unauthorized access to the cloud 3 and the data collection device 2, and the like.

[0052] The process management unit 152 is a program that manages the processes that run on the GPOS 111, and performs tasks such as allocating resources to these processes. The service authority management unit 153 restricts access to the services provided by the cloud 3 according to the authority given to the user.

[0053] The service user management unit 154 restricts access to functions installed in the vehicle according to the authority given to the user. The edge state management unit 155 starts and stops the GPOS 111 and also performs processing related to the power supply of the data collection device 2.

[0054] The API 160 provides an interface for using a program for implementing a service function, and is configured to restrict the use of the program according to the authority given to the user.

[0055] The vehicle data providing unit 161 transmits the standardized vehicle data stored in the flash memory 26 to the cloud 3. In the cloud 3, the state of the vehicle is reproduced in a digital twin, which is a virtual space, based on the received standardized vehicle data.

[0056] In addition, for example, the second application 115, the library 113 provided in the GPOS 111, or the package 114 (in other words, the second unit 110) may be provided with an image recognition function. Then, for example, the image recognition function may analyze the captured image data acquired by the captured image data to detect a suspicious person or the like.

[0057] [5. Operation mode] The data collection device 2 is provided with at least the following operation modes (see FIG. 5): a service execution mode 200, a low power mode 201, a stop mode 202, an initial setting mode 203, a maintenance mode 204, and a development mode 205. Note that while the data collection device 2 is in operation, it is in an operation mode other than the stop mode 202.

[0058] The service execution mode 200 is a state in which the data collection device 2 can provide a service, and the first microcomputer 11 and the second microcomputer 15 are in operation. That is, during the service execution mode 200, the first and second units 100, 110 are in operation.

[0059] The low power mode 201 is an operation mode that reduces power consumption of the data collecting device 2 by stopping some functions of the data collecting device 2. In the low power mode 201, at least the first and second units 100, 110 in the first microcomputer 11 are stopped. In the present embodiment, as an example, the first microcomputer 11 is stopped in the low power mode 201. Also, in the low power mode 201, at least some functions of the second microcomputer 15 are operating.

[0060] The stop mode 202 is a state in which the operation of the data collecting device 2 is stopped. Of course, in the stop mode, the operations of the first microcomputer 11 and the second microcomputer 15 are stopped. The initial setting mode 203 is an operation mode in which the initial setting of the data collection device 2 can be performed, and the maintenance mode 204 is an operation mode in which the maintenance of the data collection device 2 can be performed. The development mode 205 is an operation mode for performing operations such as debugging during development of the data collection device 2.

[0061] Then, when any of the start-up factors occurs during the low power mode 201, the operation mode transitions to the service execution mode 200. Although details will be described later, in this embodiment, as an example of the start-up factors, the start-up operation of the vehicle (for example, turning on the power switch or key switch) and the reception of a start-up instruction from the cloud 3 or another electronic control device are included. Even during the low power mode 201, power is supplied to the data collection device 2 from the battery. For this reason, the data collection device 2 can receive, for example, instructions from the cloud 3 via the communication unit 13, and can receive inputs from sensors and other electronic control devices via the vehicle I / F 12.

[0062] Furthermore, during the service execution mode 200, if an operation to stop driving of the vehicle is performed and the driving stop state continues for a predetermined waiting time, the operation mode transitions to the low power mode 201. The operation mode may transition to the low power mode 201 in response to an instruction from the cloud 3. Furthermore, the driving stop operation means, for example, an operation to turn off the power switch or key switch of the vehicle. Furthermore, the driving stop state means, for example, a state in which the power switch or key switch is turned off.

[0063] Furthermore, if the vehicle remains stopped for a predetermined stop time (for example, about 12 hours) during the low power mode 201, the operation mode transitions to the stop mode 202. In addition, if the voltage of the power source falls below a first threshold during the low power mode 201, even before the stop time has elapsed, the operation mode transitions to the stop mode 202. Furthermore, the operation mode may transition to the stop mode 202 in response to an instruction from the cloud 3.

[0064] In addition, when the operation mode has shifted from the low power mode 201 to the stop mode 202 because the voltage of the power supply has fallen below the first threshold, the operation mode may shift from the stop mode 202 to the low power mode 201 when the voltage of the power supply exceeds the second threshold. In addition, the second threshold may be the same value as the first threshold, or may be a value larger than the first threshold.

[0065] The data collection device 2 is also provided with a setting switch that determines the operation mode to which the device transitions from the stop mode 202. When the vehicle is started to drive during the stop mode 202 and the voltage of the power source exceeds a second threshold, the operation mode transitions to any one of the service execution mode 200, the initial setting mode 203, the maintenance mode 204, and the development mode 205, depending on the state of the setting switch.

[0066] In addition, during the initial setting mode 203, the maintenance mode 204, and the development mode 205, if an operation indicating completion of the work is performed on the data collection device 2, the operation mode transitions to the stop mode 202.

[0067] [6. About behavior monitoring] During the service execution mode 200, the process management unit 152 operated by the GPOS 111 monitors the operation of the second application 115. If an abnormality such as a runaway is detected in the second application 115, the process management unit 152 restarts it.

[0068] As described above, the first unit 100 operating on the first core 21 of the first microcomputer 11 has an RTOS 101 having real-time capabilities, and the second unit 110 operating on the second core 22 has a GPOS 111 not having real-time capabilities. The second unit 110 has a larger processing load than the first unit 100, and the first unit 100 has higher reliability than the second unit 110. The second microcomputer 15 executes processing having real-time capabilities, and this processing has a lower load and higher reliability than the processing executed by each of the first and second units 100 and 110.

[0069] Therefore, during the service execution mode 200, the first unit 100 (specifically, for example, the RTOS 101 or the first application 102) monitors the operation of the second unit 110. Also, during the service execution mode 200, the second microcomputer 15 monitors the operation of the first unit 100. Also, during the service execution mode 200, the second microcomputer 15 monitors the operation of the second microcomputer 15, for example, by a watchdog timer or the like.

[0070] 5, when the first unit 100 detects an abnormality in the second unit 110 (210) and when the second microcomputer 15 detects an abnormality in the first unit 100 (211), the first and second units 100, 110 are restarted (213). When an abnormality in the second microcomputer 15 is detected, the second microcomputer 15 and the first and second units 100, 110 are restarted (214).

[0071] [7. Startup process] Next, a startup process in which the first and second units 100, 110 are started up in response to the occurrence of a startup cause during the low power mode and the operation mode is set to the service execution mode will be described with reference to the flowchart of FIG.

[0072] In this embodiment, as an example, the following multiple start-up factors are provided. (a) The vehicle I / F 12 receives a notification that an operation to start driving the vehicle has been performed. (b) The communication unit 13 receives a start-up instruction from the cloud 3.

[0073] (c) The vehicle I / F 12 receives a start instruction from another electronic control unit via, for example, CAN, Ethernet, wireless LAN, short-range wireless communication, or the like. When a start-up factor occurs, a start-up signal is output from the vehicle I / F 12 or the communication unit 13 to the second microcomputer 15.

[0074] In addition, for example, the detection of a predetermined event by a sensor connected to the data collecting device 2 may be used as the activation trigger. Specifically, for example, a proximity sensor that detects the approach of an object such as a suspicious person to the vehicle may be connected to the second microcomputer 15, and the activation signal may be a signal output from the proximity sensor that detects the approach to the second microcomputer 15. In addition, for example, a vibration sensor that detects vibrations caused by a collision with the vehicle or the like may be connected to the second microcomputer 15, and the activation signal may be a signal output from the vibration sensor that detects the vibration to the second microcomputer 15.

[0075] During the low power mode, the second microcomputer 15 periodically monitors whether a start-up signal has been input, and when a start-up signal has been input (S300: Yes), it starts up the first microcomputer 11 (S305). At this time, the firmware 120 is started in the first microcomputer 11 in response to an instruction from the second microcomputer 15, and boot processing is started. Also, at this time, the second microcomputer 15 determines which start-up cause has occurred based on the start-up signal, etc., and notifies the first microcomputer 11 of the determination result.

[0076] Then, the firmware 120 starts the first unit 100. Specifically, the firmware 120 starts the RTOS 110 (S310). As an example, it takes about 700 ms to start the RTOS 110. After that, the RTOS 110 selects the first application 102 according to the start-up cause (S315) and starts the selected first application 102 (S320). This starts the control of the hardware selected according to the start-up cause. The firmware 120 may start the RTOS 110 after the start of an initialization process (S325) to be described later and before the completion of the initialization process. The firmware 120 may also determine whether to start the RTOS 110 based on the start-up cause that has occurred, and start the RTOS 110 (in other words, the first unit 100) when a specific start-up cause has occurred.

[0077] After the RTOS 103 is started, the firmware 120 executes an initialization process (S325). In the initialization process, for example, the second unit 110 is initialized, such as loading the kernel of the GPOS 111 into the main memory (in other words, the RAM 25). In addition, in the initialization process, the port of the second core 22 may be set.

[0078] When the initialization process is completed, the firmware 120 starts the second unit 110. Specifically, the firmware 120 starts the GPOS 111 (S330). As an example, it takes about 7 seconds to start the GPOS 111. The GPOS 111 selects the second application 115 according to the start-up cause (S335) and starts the selected second application 115 (S340). This starts the provision of the service selected according to the start-up cause. The firmware 120 may determine whether to start the GPOS 111 based on the start-up cause that has occurred, and start the GPOS 111 (in other words, the second unit 110) when a specific start-up cause has occurred.

[0079] Then, the operation mode transitions from the low power mode to the service execution mode (S345). As described above, if the vehicle is started during the stop mode 202 and the power supply voltage exceeds the second threshold, the operation mode transitions to the service execution mode 200 or the like depending on the state of the setting switch. In this case, too, the first microcomputer 11 is started up by a process similar to the start-up process.

[0080] Specifically, in the stop mode 202, when the voltage of the power supply exceeds the second threshold, when the vehicle is started, a start signal is input to the second microcomputer 15, and the second microcomputer 15 is started. After that, the first microcomputer 11 is started by a process similar to the start process. In this case, the application and OS to be started may be selected according to the state of the setting switch. In addition, in this case, in S345, the operation mode is changed to one of the service execution mode, the initial setting mode, the maintenance mode, and the development mode according to the state of the setting switch.

[0081] [8. Specific examples of startup processing] As described above, in the data collection device 2, when the operation mode transitions to the service execution mode, the application and OS to be started can be selected depending on the start cause.

[0082] Specifically, for example, the data collection device 2 may provide a digital key service for locking and unlocking the vehicle using a mobile terminal such as a smartphone. When providing the digital key service, the data collection device 2 controls the devices mounted on the vehicle without linking with the cloud 3.

[0083] In other words, during low power mode, when a mobile terminal instructs the data collection device 2 to lock or unlock the vehicle using the digital key service, the data collection device 2 transitions to the service execution mode and executes processing to lock or unlock the vehicle.

[0084] When providing the digital key service, a lock instruction and an unlock instruction are activation triggers. When the vehicle I / F 12 receives a lock instruction or an unlock instruction from the mobile terminal, it outputs an activation signal to the second microcomputer 15, and the second microcomputer 15 that receives the activation signal activates the first microcomputer 11. Then, the firmware 120 of the first microcomputer 11 activates the RTOS 110, but does not activate the GPOS 111. In addition, the RTOS 110 activates, among the first applications 102, those first applications 102 that are related to the digital key service, but does not activate other first applications 102.

[0085] Of course, it is also assumed that an instruction to start providing a service other than the digital key service may be a start-up trigger. In addition, when the operation mode is shifted from the low power mode to the service execution mode due to the occurrence of such a start-up trigger, it is also assumed that the GPOS 111 and a part of the second application 115 are started, but the RTOS 110 is not started.

[0086] [9. Second microcomputer monitoring process] Next, a second microcomputer monitoring process in which the second microcomputer 15 detects abnormalities in the first unit 100 and the second microcomputer 15 during the service execution mode will be described with reference to the flowchart of FIG.

[0087] In this embodiment, as an example, an abnormality in the second microcomputer 15 is detected by a watchdog timer, which is a hardware resource of the second microcomputer 15. Of course, the second microcomputer 15 may detect an abnormality in the second microcomputer 15 by a method other than the watchdog timer. When an abnormality in the second microcomputer 15 is detected (S400: Yes), the second microcomputer 15 is reset and restarted (S405).

[0088] Then, the restarted second microcomputer 15 resets the first microcomputer 11 (or the first and second cores 21, 22), and thereafter starts up the first and second units 100, 110 (S410) in the same manner as in S305 to S340 of the startup process. At this time, the firmware 120, the RTOS 101, and the GPOS 111 may start up the OS and application that were operating immediately before the abnormality was detected.

[0089] On the other hand, if the watchdog timer does not detect an abnormality (S400: No), the second microcomputer 15 periodically determines whether or not an abnormality has occurred in the first unit 100 (S415). Specifically, for example, the first unit 100 may periodically notify the second microcomputer 15, and if no notification is received, it may be assumed that an abnormality has occurred in the first unit 100.

[0090] If an abnormality occurs in the first unit 100 (S415: Yes), the first microcomputer 11 (or the first and second cores 21, 22) is reset in the same manner as in S410, and then the first and second units 100, 110 are started up (S420). Then, this process ends.

[0091] [10. First unit monitoring process] Next, a first unit monitoring process in which the first unit 100 detects an abnormality in the second unit 110 during the service execution mode will be described with reference to the flowchart of Fig. 8. The first unit monitoring process is periodically executed by the RTOS 101 or the first application 102, for example.

[0092] In S500, the first unit 100 determines whether or not an abnormality has occurred in the second unit 110. Specifically, for example, the second unit 110 may periodically notify the first unit 100, and if no notification is received, it may be assumed that an abnormality has occurred in the second unit 110. If a positive determination is obtained (S500: Yes), the process proceeds to S505, and if a negative determination is obtained (S500: No), the process ends.

[0093] In S505, the first unit 100 notifies the second microcomputer 15 of the abnormality of the second unit 110. Then, the second microcomputer 15 resets the first microcomputer 11 (or the first and second cores 21, 22). Thereafter, the first and second units 100, 110 are started up in the same manner as in S305 to S350 of the startup process, and this process ends. Depending on the state of the abnormality of the second unit 110, instead of resetting the first microcomputer 11, a software reset of the second unit 110 may be performed.

[0094] [11. Low power mode transition process] Next, a low power mode transition process for transitioning the operation mode to the low power mode due to an operation stop operation during the service execution mode will be described with reference to the flowchart of Fig. 9. Note that the low power mode transition process is periodically executed during the service execution mode.

[0095] In S600, the second microcomputer 15 determines whether the operation stop state continues for the standby time after detecting the operation stop operation via the vehicle I / F 12. If a positive determination is obtained (S600: Yes), the process proceeds to S605, and if a negative determination is obtained (S600: No), the process ends.

[0096] In S605, the second microcomputer 15 instructs the first microcomputer 11 to stop. Then, in the first microcomputer 11 that has received the instruction, the second unit 110 is first stopped (S610). Specifically, for example, when the instruction is given, the RTOS 101 may stop the process being executed in the GPOS 111, and then stop the GPOS 111 by, for example, a HALT command.

[0097] When the GPOS 111 stops, the RTOS 101 stops operating (S615), which causes the first unit 100 to stop operating and transition to a low power consumption mode (S620).

[0098] [12. Stop mode transition process] Next, a stop mode transition process for transitioning the operation mode to the stop mode due to a voltage drop of the power supply during the low power mode will be described with reference to the flowchart of Fig. 10. The stop mode transition process is periodically executed during the low power mode.

[0099] In S700, the second microcomputer 15 determines whether the voltage of the power source acquired via the vehicle I / F 12 is lower than the first threshold value. If a positive determination is obtained (S700: Yes), the process proceeds to S710, and if a negative determination is obtained (S700: No), the process proceeds to S705.

[0100] In S705, the second microcomputer 15 judges whether the low power mode has continued for the entire stop time. If the judgment is affirmative (S705: Yes), the process proceeds to S710, and if the judgment is negative (S705: No), the process ends.

[0101] In S710, the second microcomputer 15 stops operating, and the operation mode transitions to the low power mode (S715), after which this process ends. [13. Modifications] In the data collection device 2 of the modified example, the first microcomputer 11 includes first and second cores 21, 22, but does not include a third core 23. Also, first and second units 100, 110 are provided as programs for operating the first microcomputer 11, but firmware 120 is not provided (see FIG. 12).

[0102] The processes that were performed by the firmware 120 are now performed by the RTOS 101 of the first unit 100. That is, the boot process of the first microcomputer 11 and the start and stop of the second unit 110 are performed by the RTOS 101. Note that these processes may be performed by a program other than the RTOS 101 of the first unit 100.

[0103] Specifically, in S305 of the startup process, when the first microcomputer 11 is started, the firmware 120 is not started, and in the following S310, the RTOS 101 is started in conjunction with the startup of the first microcomputer 11, and the boot process is started.

[0104] In addition, in S325 of the startup process, the RTOS 101 executes an initialization process. Then, when the initialization process is completed, the RTOS 101 starts the second unit 110 (specifically, the GPOS 111) (S330). Note that the RTOS 101 may determine whether to start the GPOS 111 based on the startup cause that has occurred, and start the GPOS 111 (in other words, the second unit 110) when a specific startup cause has occurred.

[0105] [14. Effects] According to the above embodiment, the following effects are achieved. (1) According to the above embodiment, the processing in the first unit 100 has a lower load and is more reliable than the processing in the second unit 110. Furthermore, the processing in the second microcomputer 15 has a lower load and is more reliable than the processing in the first unit 100. Furthermore, an abnormality in the second unit 110 is detected by the first unit 100, and an abnormality in the first unit 100 is detected by the second microcomputer 15. Furthermore, an abnormality in the second microcomputer 15 is detected by the second microcomputer 15 itself. Therefore, abnormalities in the first and second units 100, 110 and the second microcomputer 15 can be detected well.

[0106] When an abnormality is detected in the first or second unit 100, 110, the first and second units 100, 110 are restarted, and when an abnormality is detected in the second microcomputer 15, the first and second units 100, 110 and the second microcomputer 15 are restarted. This makes it possible to effectively deal with abnormalities in the first and second units 100, 110 and the second microcomputer 15. This makes it possible to improve the reliability of the data collection device 2.

[0107] (2) Furthermore, when the first microcomputer 11 is started by the second microcomputer 15, the firmware 120 starts the RTOS 101 and then starts the GPOS 111. Therefore, the RTOS 101 and the GPOS 111 can be started appropriately.

[0108] (3) On the other hand, in the modified example, the first microcomputer 11 is not provided with the firmware 120, and when the first microcomputer 11 is started by the second microcomputer 15, the RTOS 101 is started, and the RTOS 101 starts the GPOS 111. Even in the case of such a configuration, the RTOS 101 and the GPOS 111 can be started appropriately.

[0109] (4) Furthermore, a start instruction from the cloud 3 is provided as one of the start factors of the data collection device 2. This improves the convenience of the data collection device 2. (5) Furthermore, when a startup trigger occurs during the low power mode, in the first microcomputer 11, the first unit 100 that performs processing related to the control of hardware is started, and then the second unit 110 that performs processing related to the provision of services is started. Therefore, when the data collecting device 2 is started, collection of data necessary for the provision of services in the data collecting device 2 can be started early. Therefore, after the data collecting device 2 is started, services based on the collected data can be provided sooner.

[0110] (6) Furthermore, the data collection device 2 has three operation modes: a service execution mode 200, a low power mode 201, and a stop mode 202. The operation mode changes depending on the occurrence of a start-up factor, an operation to stop driving the vehicle, etc. Therefore, the data collection device 2 can be suitably started and stopped.

[0111] (7) Furthermore, when an operation to start operation is performed during the stop mode 202, the operation mode transitions to the service execution mode 200 without passing through the low power mode 201. This allows the provision of a service to be started promptly.

[0112] (8) In addition, the first unit 100 performs at least a process for collecting information related to the vehicle and / or information detected via a sensor mounted on the vehicle. In addition, the second unit 110 performs at least an image recognition process. Therefore, the processes can be appropriately assigned to each of the first and second units 100 and 110.

[0113] (9) During the service execution mode, when the operation mode is shifted to the low power mode in response to the operation stop operation, in the first microcomputer 11, first, the second unit 110 stops operation, and then the first unit 100 stops operation. Specifically, when the second unit 110 is stopped, the RTOS 101 stops the process being executed in the GPOS 111, and then stops the GPOS 111. This makes it possible to prevent unnecessary data from remaining in the main memory in which the second unit 110 is loaded. In addition, the stop of the second unit 110 makes it possible to prevent interruption of access to storage (e.g., the flash memory 26, the storage unit 14, etc.) in the second unit 110, thereby preventing destruction of the storage.

[0114] (10) In addition, in the second unit 110, the second application 115 that has been subjected to container-based virtualization performs processing by using software resources of the GPOS 111. This makes it possible to suppress the data size of the second application 115 and reduce the load on the second core 22 when the second application 115 is operated. In addition, since the second application 115 can use software resources whose quality has been verified, reliability is improved.

[0115] (11) When the data collection device 2 is started in the low power mode, the first and second applications 102 and 115 that are started in response to a start-up cause are selected. This makes it possible to avoid starting unnecessary applications and quickly start providing a required service in response to the occurrence of a start-up cause.

[0116] (12) Furthermore, when the data collection device 2 is started in the low power mode, the unit to be started is selected according to the start-up cause. This makes it possible to avoid starting unnecessary units and quickly start providing the necessary services in response to the occurrence of the start-up cause.

[0117] [15. Other embodiments] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0118] (1) In the above embodiment, the first microcomputer 11 of the data collecting device 2 includes the first to third cores 21 to 23. However, the number of physical cores in the first microcomputer 11 is not limited to three and may be determined as appropriate. Specifically, for example, a core for running the firmware 120 may be provided, and a virtual machine environment may be constructed to run the RTOS 101 and the GPOS 111 using one or three or more cores. Also, for example, a virtual machine environment may be constructed to run the firmware 120, the RTOS 101, and the GPOS 111 using two or less or three or more cores. Even in the case of such a configuration, the first and second units 100 and 110 can be started and stopped in the same manner as in the above embodiment.

[0119] (2) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0120] (3) In addition to the above-described data collecting device 2, the present disclosure can be realized in various forms, such as a program for causing a computer to function as the first microcomputer 11 and the second microcomputer 15 of the data collecting device 2, a non-transient substantial recording medium such as a semiconductor memory on which this program is recorded, a method realized by this program, etc. Furthermore, the present disclosure can be realized in various forms, such as a method realized by the data collecting device 2, a method realized by the first microcomputer 11 and / or the second microcomputer 15, a method for starting the data collecting device 2, etc.

[0121] [16. Correspondence of Words] The data collection device 2 corresponds to an example of an in-vehicle device, the first microcomputer 11 of the data collection device 2 corresponds to an example of a control unit, and the second microcomputer 15 corresponds to an example of a second control unit.

Claims

1. An in-vehicle device (2) capable of accessing a cloud (3) via a communication unit (13), A first control unit (11) having at least one physical core (21-23); A first unit (100) configured to be operated by the first control unit and to perform processing related to the control of hardware; A second unit (110) configured to be operated by the first control unit and to perform processing related to the provision of services; A second control unit (15) configured to start the first control unit in response to the occurrence of a start-up factor; the first control unit is configured to start up the first unit prior to the second unit when started up by the second control unit, The second control unit is configured to detect an abnormality in the first unit and an abnormality in the second control unit, The first unit is configured to detect an abnormality in the second unit; The second control unit is configured to restart the first and second units when an abnormality is detected in the first or second unit, and to restart the first and second units and the second control unit when an abnormality is detected in the second control unit. In-vehicle device.

2. The in-vehicle device according to claim 1, The device further includes firmware (120) operated by the first control unit, The first unit has a first OS (101); The second unit has a second OS (111); The firmware is configured to start the first OS and then start the second OS when the first control unit is started by the second control unit. In-vehicle device.

3. The in-vehicle device according to claim 1, The first unit has a first OS (101); The second unit has a second OS (111); The first OS is configured to start the second OS when the first control unit is started by the second control unit. In-vehicle device.

4. The in-vehicle device according to any one of claims 1 to 3, The start-up trigger is at least reception of a start-up instruction from the cloud by the communication unit. In-vehicle device.

5. The in-vehicle device according to any one of claims 1 to 3, The operation modes of the in-vehicle device include at least a service execution mode (200) in which the first and second units are operable and the second control unit is operating, a low power mode (201) in which the first and second units are stopped and at least a part of the functions of the second control unit are operating, and a stop mode (202) in which the first and second units and the second control unit are stopped, during the service execution mode, when the first and second units stop operating due to a drive stop operation of the vehicle in which the in-vehicle device is installed, the operation mode transitions to the low power mode; When the first and second units are started in response to the occurrence of the start-up cause during the low power mode, the operation mode transitions to the service execution mode; During the low power mode, when the voltage of the power supply of the in-vehicle device drops, the second control unit stops operation, and the operation mode transitions to the stop mode. In-vehicle device.

6. The in-vehicle device according to claim 5, During the stop mode, when the voltage of the power source exceeds a predetermined threshold value and an operation to start driving the vehicle is performed, the second control unit starts its operation, activates the first control unit, and transitions to the service execution mode. In-vehicle device.

7. The in-vehicle device according to any one of claims 1 to 3, the first unit performs at least a process for collecting information about a vehicle in which the on-vehicle device is installed and / or information detected via a sensor installed in the vehicle; The second unit performs at least an image recognition process. In-vehicle device.

8. In the vehicle-mounted device according to claim 5, The second control unit instructs the first control unit to stop the operation due to a driving stop operation of the vehicle during the service execution mode, When the stop is instructed by the second control unit during the service execution mode, the first control unit stops the second unit and then stops the first unit. In-vehicle device.

9. The in-vehicle device according to any one of claims 1 to 3, The second unit includes at least one application (115) that has been container-based virtualized, and an OS (111) that runs the at least one application; The at least one application is configured to perform processing using software resources (112 to 114) provided in the OS. In-vehicle device.

10. The in-vehicle device according to any one of claims 1 to 3, The first unit has at least one first application (102); The second unit has at least one second app (115); The second control unit starts the first control unit in response to the occurrence of any one of the plurality of start-up factors, the first unit is configured to, when activated by the first control unit, activate the first application in response to the activation cause that has occurred; The second unit is configured to start the second application corresponding to the occurrence of the start-up cause when the second unit is started by the first control unit. In-vehicle device.

11. The in-vehicle device according to any one of claims 1 to 3, The second control unit starts the first control unit in response to the occurrence of any one of the plurality of start-up factors, The first control unit is configured to start up each of the first and second units in response to the occurrence of the start-up cause. In-vehicle device.

12. A method for activating an in-vehicle device (2) capable of accessing a cloud (3) via a communication unit (13), comprising the steps of: The in-vehicle device includes: A first control unit (11) having at least one physical core (21-23); A first unit (100) configured to be operated by the first control unit and to perform processing related to the control of hardware; A second unit (110) configured to be operated by the first control unit and to perform processing related to the provision of services; A second control unit (15), The second control unit starts the first control unit in response to the occurrence of a start-up cause, When the first control unit is activated by the second control unit, the first control unit activates the first unit and then activates the second unit; The second control unit detects an abnormality in the first unit and an abnormality in the second control unit, The first unit detects an abnormality in the second unit, The second control unit restarts the first and second units when an abnormality is detected in the first or second unit, and restarts the first and second units and the second control unit when an abnormality is detected in the second control unit. How to start.

Images