On-board equipment and control devices

Abstract

To improve efficiency of development of a secure application for automobiles.SOLUTION: An on-vehicle device 1 includes: an IoT microcomputer 10 that receives input of information; and a control system microcomputer 20 that executes processing of controlling a vehicle. The IoT microcomputer 10 has a non-secure area 11 that stores information on an application obtained from the outside, and a secure area 12 more secure than the non-secure area 11. The IoT microcomputer 10 and the control system microcomputer 20 perform input / output of information though an interface provided in the secure area 12 of the IoT microcomputer 10.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an in-vehicle device and control device

Background Art

[0002] Recently, there is a market trend that the added value of automobiles is shifting to software, and "Software First" (SF) has been proposed.

[0003] In the multimedia and user interface section, the trend towards SF is progressing. On the other hand, in the control systems related to "running", "turning", and "stopping", the trend towards SF has not progressed due to safety concerns.

[0004] Also, conventionally, a secure area and a non-secure area are provided in one microcomputer, and in the execution environment of the process of downloading data from an external network, a technique for making the secure area inaccessible is known (for example, see Patent Document 1).

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, the conventional technology has a problem that it is difficult to efficiently develop a secure application for automobiles.

[0007] The control applications targeted for SF are mainly developed by automobile manufacturers. On the other hand, the platform software called BSW (Basic Software) is mainly developed by ECU (Electronic Control Unit) suppliers.

[0008] ​ Applications and BSWs (Bodywork Software) are closely linked in terms of processing timing, interfaces (IFs), and random access memory (RAM). Therefore, developing applications that run on BSWs may require coordination between automotive manufacturers and ECU suppliers, resulting in lower work efficiency.

[0009] Furthermore, from a reliability standpoint, it is undesirable for malfunctions in applications other than the control system, such as multimedia applications, to affect the control system. Therefore, when developing applications, it is necessary to give full consideration to their impact on the control system.

[0010] The present invention has been made in view of the above, and aims to improve the efficiency of developing secure applications for automobiles. [Means for solving the problem]

[0011] To solve the above-mentioned problems and achieve the objective, the in-vehicle device according to the present invention comprises a first information processing unit that receives information input and a second information processing unit that executes processing to control the vehicle. The first information processing unit has a first memory area for storing application information obtained from an external source and a second memory area that is more secure than the first memory area. The first information processing unit and the second information processing unit perform information input and output via an interface provided in the second memory area of ​​the first information processing unit. [Effects of the Invention]

[0012] According to the present invention, the efficiency of developing secure applications for automobiles can be improved. [Brief explanation of the drawing]

[0013] [Figure 1] Figure 1 shows an example of the configuration of an in-vehicle device according to an embodiment. [Figure 2] Figure 2 is a diagram illustrating the virtualization arbitration process. [Figure 3] Figure 3 is a diagram illustrating the fail-safe process. [Modes for carrying out the invention]

[0014] The embodiments of the in-vehicle device disclosed herein will be described in detail below with reference to the attached drawings. However, the present invention is not limited to the embodiments described below.

[0015] Figure 1 shows an example of the configuration of an in-vehicle device according to an embodiment. As shown in Figure 1, the in-vehicle device 1 includes an IoT microcontroller 10 that receives information input and a control system microcontroller 20 that executes processing to control the vehicle. An IoT microcontroller is not a microcontroller specifically customized for a particular product, but rather a general-purpose microcontroller generally used in household devices and the like that can connect to the internet.

[0016] The IoT microcontroller 10 is an example of a first information processing unit. The control system microcontroller 20 is an example of a second information processing unit.

[0017] Furthermore, the IoT microcontroller and the control system microcontroller 20 each have a processor (for example, a CPU (Central Processing Unit)).

[0018] The IoT microcontroller 10 has a non-secure area 11 for storing application information and a secure area 12 that is more secure than the non-secure area 11. The IoT microcontroller 10 and the control system microcontroller 20 input and output information via an interface provided in the secure area 12 of the IoT microcontroller 10. The application developer is different from the developer of the control system microcontroller 20.

[0019] For example, the application is developed by the vehicle manufacturer, etc. Also, for example, the control system microcontroller 20 is developed by the supplier.

[0020] In this case, since the vehicle manufacturer and the supplier can conduct development in parallel during the same period, the overall development work is streamlined.

[0021] Note that the non-secure area 11 is an example of the first memory area. Also, the secure area 12 is an example of the second memory area.

[0022] For example, the non-secure area 11 and the secure area 12 correspond to the normal world and the secure world in TrustZone (registered trademark), respectively. Reference: Mechanism of TrustZone for Cortex-A (https: / / www.arm.com / ja / why-arm / technologies / trustzone-for-cortex-a)

[0023] For example, the non-secure area 11 and the secure area 12 can be realized by partitioning the memory area.

[0024] The application placed in the non-secure area 11 cannot directly access the resources of the secure area 12. Therefore, the secure area 12 can be called a secure memory area. Here, secure means a state that is protected from external intrusion, unauthorized operation, destruction, modification, information leakage, deletion, seizure, communication interference, etc., or a state with a high level of protection.

[0025] The IoT microcontroller 10 has connected interfaces such as BLE (Bluetooth Low Energy) 141, USB (Universal Serial Bus) 142, and audio IF 143. Thereby, the IoT microcontroller 10 can perform communication via OTA (Over The Air).

[0026] A connected interface is an interface that enables communication and connection. Examples include interfaces for communication and connection between devices, interfaces for communication and connection between the IoT microcontroller 10 and the outside world, and interfaces between devices and users.

[0027] Furthermore, the IoT microcontroller 10 acquires application information from external sources, such as the cloud, via wireless communication, and places it in the non-secure area 11, and also updates application information already placed in the non-secure area 11. It is prohibited to place application information acquired from outside the in-vehicle device 1 in the secure area 12. Here, placing application information is synonymous with storing it.

[0028] For example, app information is the package file of an application. Note that in the following explanation, the term "application" may be abbreviated to "app."

[0029] In this way, the IoT microcontroller 10 places information acquired from outside the in-vehicle device 1 in the non-secure area 11, rather than directly in the secure area 12. Therefore, for example, applications placed in the non-secure area 11 cannot directly access the control system microcontroller 20. As a result, the security of the control system microcontroller 20 is improved.

[0030] In the example shown in Figure 1, the non-secure area 11 contains application information 111, application information 112, and application information 113. Although three application information entries are shown in Figure 1, the number of application information entries can be any number.

[0031] The application corresponding to each application information may be one that controls the vehicle (automobile), or it may be one related to a connected interface such as BLE141 or USB142.

[0032] Applications include those that control battery operation, acceleration and other driving controls, those that acquire vehicle information (INPUT processing) and pass it to the user's device such as a smartphone, and those that issue voice commands to the control system.

[0033] For example, once application development is complete, the application developer can rewrite the IoT microcontroller 10 via OTA (Over-the-Air) through the cloud, thereby deploying the application information.

[0034] Thus, according to this embodiment, application developers can develop and update applications without having to coordinate with BSW developers.

[0035] The secure area 12 houses the service interface 121 and the authentication unit 122.

[0036] The service IF121 has the function of acquiring information input from the control system microcontroller 20 (corresponding to the "INPUT processing" described later) and the function of issuing instructions to the BSW of the control system microcontroller 20 in response to the execution of the vehicle control application stored in the IoT microcontroller 10 (corresponding to the "instruction processing by application" described later).

[0037] The authentication unit 122 authenticates that the application information placed in the non-secure area 11 is genuine. For example, it authenticates application information downloaded from the cloud by the IoT microcontroller 10 via OTA.

[0038] For example, the authentication unit 122 verifies whether the encryption key assigned to the application information is legitimate. Also, for example, the authentication unit 122 verifies whether the downloaded application information is legitimately distributed on the application store by using a whitelist, which is a list of applications and programs deemed secure.

[0039] For example, a whitelist might include a list of applications that are officially distributed through application stores, or a list of programs that have been previously verified as legitimate.

[0040] In this way, the authentication unit 122 can prevent unauthorized applications from being executed by authenticating that the application information stored in the non-secure area 11 is legitimate.

[0041] The VMM (Virtual Machine Monitor) 13 arbitrates the execution rights of processors in the non-secure area 11 and the secure area 12.

[0042] Furthermore, the execution of the service IF121, authentication unit 122, VMM13, and the applications corresponding to each application information is realized by the processor provided in the IoT microcontroller 10.

[0043] The control system microcontroller 20 may be a microcontroller with higher quality and safety compared to the IoT microcontroller 10. For example, the control system microcontroller 20 is a microcontroller that minimizes variations in the processor clock. Also, for example, the control system microcontroller 20 is a microcontroller that complies with the ISO 26262 standard. The developer of the control system microcontroller 20 may be different from the developer of the application stored in the IoT microcontroller 10. For example, the control system microcontroller may be developed by a supplier to a vehicle manufacturer. References: Functional Safety (ISO 26262) | Japan Automobile Research Institute (http: / / www.jari.or.jp / tabid / 112 / Default.aspx)

[0044] The control system microcontroller 20 includes a switching unit 21, a backup control application 22, and a BSW 23. The switching unit 21, the backup control application 22, and the BSW 23 are implemented by a processor provided in the control system microcontroller 20.

[0045] The switching unit 21 and the backup control application 22 execute fail-safe processing. Details of the fail-safe processing will be described later.

[0046] Furthermore, the control system microcontroller 20 has I / O interfaces such as CAN (Controller Area Network) 241, GPIO (General Purpose Input / Output) 242, and AD (Autonomous Driving) 243.

[0047] Furthermore, serial communication, CAN communication, Ethernet (registered trademark), and wireless communication (Bluetooth (registered trademark), Wi-Fi (registered trademark), etc.) are used for communication between the IoT microcontroller 10 and the control system microcontroller 20.

[0048] (Virtualized mediation process) Figure 2 illustrates the virtualization arbitration process performed by VMM13. Figure 2 is a diagram illustrating the virtualization arbitration process.

[0049] Applications running in the non-secure area 11 and service IF121 in the secure area 12 have independent time schedules. VMM13 mediates the time schedules.

[0050] VMM13 sequentially grants processor privileges to the non-secure area 11 and the secure area 12 using the TDMA (Time Division Multiple Access) method.

[0051] VMM13 executes processes at specified intervals in the following order: INPUT processing, application execution processing, and application instruction processing.

[0052] The INPUT process is the process in which the service IF 121 acquires information from the control system microcontroller 20 in the secure area 12. The information acquired from the control system microcontroller 20 is sent to the application that requires the acquired information. This transmission of acquired information to the application may also be included in the INPUT process. The process of executing the application is performed in the non-secure area 11. The result of the execution by the application is sent from the application as an instruction. The instruction processing, which receives and processes instructions from the application, is the process in which the service IF 121 receives the instruction sent from the application in the secure area 12 and outputs the received instruction to the control system microcontroller 20.

[0053] Here, the information acquired by Service IF121 and the instructions issued by Service IF121 relate to vehicle control, including body control (driver IF such as shift operation, wiper operation, and turn signal operation), drive control, battery control, power supply control, motor control, and engine control.

[0054] For example, during INPUT processing, the service IF121 acquires information such as accelerator opening, brake signal, shift signal, motor temperature, and starter signal from the control system microcontroller 20.

[0055] Furthermore, for example, in the processing of instructions by an application, the service IF121 issues instructions to the control system microcontroller 20 using signals related to driving force, lighting / extinguishing of various indicators (hazard lights, shift, turn lamps (direction indicators)), and ON / OFF of various power system relays.

[0056] Thus, the processing of service IF121 in secure area 12 is divided into INPUT processing (a) and application-instructed processing (b), but other processing may also be performed.

[0057] As shown in Figure 2, for example, the processor executes three processes sequentially in each cycle every Xms.

[0058] This allows synchronization between the IoT microcontroller 10 and the control system microcontroller 20, each of which has its own processor. Furthermore, if an application wants to immediately issue instructions to the control system microcontroller 20, the application executes an immediate execution command, thereby executing process (b).

[0059] (Fail-safe processing) The switching unit 21 of the control system microcontroller 20 determines whether or not an abnormality has occurred in the IoT microcontroller 10. The determination of whether or not an abnormality has occurred by the switching unit 21 will be described later. If the switching unit 21 determines that no abnormality has occurred in the IoT microcontroller 10, the BSW 23 executes a process to control the vehicle according to the instructions from the service IF 121.

[0060] When the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10, it executes a process to control the vehicle by running an application (backup control application 22) that has been previously stored in the control system microcontroller 20.

[0061] This ensures that the control system remains operational even if an abnormality occurs in the IoT microcontroller 10. Furthermore, the backup control application 22 may also cause the vehicle to perform an emergency escape maneuver.

[0062] Figure 3 illustrates the fail-safe process. The switching unit 21 periodically initiates a switching determination (step S101).

[0063] First, in step S102, the switching unit 21 determines whether there has been an unauthorized request from an application running on the IoT microcontroller 10. If there has been an unauthorized request from an application running on the IoT microcontroller 10 (step S102, Yes), the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10.

[0064] For example, consider a case where a service interface executes an API (Application Programming Interface) to BSW23, specifying argument parameters. In this case, there are conditions under which the argument parameters are judged to be abnormal.

[0065] For example, suppose an application that controls the speed of a vehicle is executed, and the new vehicle speed is specified by an argument parameter. In this case, if the specified speed exceeds a threshold, or if the difference between the previously specified speed and the currently specified speed exceeds a threshold, the argument parameter is determined to be abnormal.

[0066] If the number of times an argument parameter is determined to be abnormal exceeds a specified number, the switching unit 21 determines that there has been an unauthorized request from the application.

[0067] If the switching unit 21 does not determine that there was an unauthorized request from the application (step S102, No), it proceeds to step S103.

[0068] In step S103, the switching unit 21 determines whether there is a microcontroller malfunction in the IoT microcontroller. If there is a microcontroller malfunction in the IoT microcontroller, that is, if the IoT microcontroller 10 performs a specific abnormal operation (step S103, Yes), the switching unit 21 determines that a malfunction has occurred in the IoT microcontroller 10.

[0069] For example, if the WDC (Watchdog Clear) signal to the IoT microcontroller 10 stops, the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10.

[0070] Furthermore, for example, if there is an abnormality in the signal check (sum check, CRC (Cyclic Redundancy Check)) received from the IoT microcontroller 10, the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10.

[0071] Furthermore, for example, if an unauthorized interrupt occurs from the IoT microcontroller 10, the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10.

[0072] If the switching unit 21 does not determine that there is a microcontroller abnormality in the IoT microcontroller (step S103, No), it proceeds to step S104.

[0073] In step S104, the switching unit 21 determines whether there was an abnormality in the communication between the microcontrollers. If there was an abnormality in the communication between the microcontrollers (step S104, Yes), the switching unit 21 determines that an abnormality has occurred in the IoT microcontroller 10.

[0074] For example, if there is no communication response from the IoT microcontroller 10 for a certain period of time, the switching unit 21 determines that there is an abnormality in the communication between the microcontrollers.

[0075] If the switching unit 21 does not determine that there is an abnormality in the communication between microcontrollers (step S104, No), it returns to step S101.

[0076] If the switching unit 21 determines that any abnormality exists (Yes in any of steps S102, S103, or S104), it switches to the backup control application 22 (step S105).

[0077] In this way, by determining abnormalities in the IoT microcontroller 10 from multiple perspectives, the accuracy of abnormality detection can be improved.

[0078] As explained above, the in-vehicle device 1 comprises an IoT microcontroller 10 that accepts information input and a control system microcontroller 20 that executes processes to control the vehicle. The IoT microcontroller 10 has a non-secure area 11 that stores application information obtained from the outside and a secure area 12 that is more secure than the non-secure area 11. The IoT microcontroller 10 and the control system microcontroller 20 input and output information via an interface provided in the secure area 12 of the IoT microcontroller 10.

[0079] Thus, in the in-vehicle device 1, the IoT microcontroller 10 and the control system microcontroller can be connected via the service IF 121 of the secure area 12 of the IoT microcontroller 10. This allows for the development of the IoT microcontroller 10 and the control system microcontroller independently, improving the efficiency of software development for the control system application and facilitating software updates. Furthermore, since information input and output between the IoT microcontroller 10 and the control system microcontroller are performed via the service IF 121 of the secure area 12, security is ensured.

[0080] This allows application developers to sometimes omit coordination with BSW developers. As a result, this embodiment can improve the efficiency of developing secure applications for automobiles. In other words, development efficiency can be improved because application development and BSW development can be carried out simultaneously.

[0081] Furthermore, according to this embodiment, it becomes easier to update application information placed on the IoT microcontroller 10 and to integrate applications other than the control system.

[0082] Furthermore, the secure area 12 can function as a firewall to the control system microcontroller 20.

[0083] Furthermore, this embodiment is not limited to vehicles, but may also be applied to microcontrollers mounted on other devices requiring high security and control, such as drones and robots.

[0084] Further effects and modifications can be readily derived by those skilled in the art. Therefore, broader aspects of the present invention are not limited to the specific details and representative embodiments expressed and described above. Accordingly, various modifications are possible without departing from the spirit or scope of the overall concept of the invention as defined by the appended claims and equivalents. [Explanation of Symbols]

[0085] 1 On-vehicle device 10 IoT Microcontrollers 11 Nonsecure Area 12 Secure Area 13 VMM 20 Control System Microcontrollers 21 Switching section 22 Backup control app 23 BSW 111, 112, 113 App Information 121 Service IF 122 Authentication Department 141 BLE 142 USB 143 Audio Interface 241 CAN 242 GPIO 243 AD

Claims

1. A first information processing unit that accepts information input, A second information processing unit that executes processes to control the vehicle, An in-vehicle device equipped with, The first information processing unit is, A first memory area that stores application information obtained from an external source, A second memory area that is more secure than the first memory area, It has, The interface provided in the second memory area performs a process of acquiring information from the second information processing unit. The process of executing an application in the first memory region, The process by which the interface issues instructions to the second information processing unit in the second memory area, The process is executed at the specified intervals in the order listed above. In-vehicle device.

2. The second information processing unit described above is: Determine whether or not an abnormality has occurred in the first information processing unit. If it is determined that no abnormality has occurred in the first information processing unit, the process of controlling the vehicle according to the instructions from the interface is executed. If the first information processing unit determines that an abnormality has occurred, the second information processing unit executes an application that has been pre-stored in it to perform a process to control the vehicle. The in-vehicle device according to claim 1.

3. The second information processing unit described above is: If an unauthorized request is made from the first information processing unit, if the first information processing unit performs a specific abnormal operation, or if communication between the first information processing unit and the second information processing unit is interrupted, an abnormality related to the first information processing unit is detected. The in-vehicle device according to claim 2.

4. The first information processing unit is: The information of the aforementioned application is updated via communication with an external source. The in-vehicle device according to claim 1.

5. The first information processing unit is, The system includes an authentication unit located in the second memory area that authenticates that the application information stored in the first memory area is legitimate. The in-vehicle device according to claim 1.

6. An in-vehicle control device capable of communicating with a control system device that controls a vehicle, A first memory area that stores application information obtained from an external source, The system comprises a second memory area which is more secure than the first memory area, The interface provided in the second memory area performs the process of acquiring information from the control system device. The process of executing an application in the first memory region, The process by which the interface issues instructions to the control system device in the second memory area, The process is executed at the specified intervals in the order listed above. Control device.

Images