In-vehicle equipment and log collection system

Abstract

To provide an on-vehicle facility which collects logs that can be connected to reliability analysis from a view point of a software behavior.SOLUTION: An on-vehicle facility 100 which executes an application executed on an OS (Operation System) and for collecting an on-vehicle apparatus, collects attribute information including application log information acquired by the application in association with OS log information acquired by the OS. As information included in the attribute information, an acquisition time point of the application log, an acquisition time point of the OS log, information on an identifier of a vehicle mounting the on-vehicle facility, and information regarding all or a part of a processor, a memory, and a storage being constitution information of a computer executing the OS may be collected.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to in-vehicle equipment and a log collection system that can obtain logs that can be linked to reliability analysis from the perspective of software behavior.

Background Art

[0002] As an existing technology related to the reliability of moving bodies such as vehicles, ships, and aircraft, for example, there is Patent Document 1 ("Normalcy System and Method for Autonomous Aircraft").

[0003] In Patent Document 1, in order to determine the normalcy of an autonomously flying aircraft, operations are performed in cooperation with some remote servers. For example, engine deterioration, etc. is determined from the operating conditions of the aircraft obtained by sensors, but it has a configuration that operates independently and does not support discrimination from data collected from multiple aircraft or from long-term data accumulation.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In recent years, for example, in vehicles aiming for autonomous driving, regarding various in-vehicle devices such as cameras for monitoring the vehicle surroundings, control is performed by software operating under an OS (Operating System) executed by a computer of the in-vehicle equipment. Here, in order to ensure the reliability of moving bodies such as vehicles, it is desirable to ensure sufficient logs in a form that can be analyzed from the perspective of software behavior, so as to lead to reliability analysis such as pre-detection and analysis of situations where abnormalities may occur, but such efforts have not been made in the prior art.

[0006] For example, Patent Document 1 described a method for determining the reliability of a single aircraft by comparing it with pre-known criteria for deterioration and abnormalities. However, the method in Patent Document 1 could not collect logs in an analyzable format from a large number of aircraft, nor could it aim to pre-detect potential abnormalities from the perspective of software behavior.

[0007] In view of the problems of the above-mentioned conventional technology, the present invention aims to provide an in-vehicle device that collects logs that can be used for reliability analysis from the perspective of software behavior. [Means for solving the problem]

[0008] To achieve the above objective, the present invention provides an in-vehicle device that runs on an OS (operating system) and executes an application that controls in-vehicle devices, characterized in that it collects attribute information, including application log information acquired by the application, in association with OS log information acquired by the OS. [Effects of the Invention]

[0009] According to the present invention, by collecting attribute information, including application log information, in association with OS log information, the attribute information can be used as a search key for OS log information, thereby enabling the collection of logs that can be used for reliability analysis from the perspective of software behavior. [Brief explanation of the drawing]

[0010] [Figure 1] This is a configuration diagram of a log collection system according to one embodiment. [Figure 2] This is a functional block diagram of a log collection system according to one embodiment. [Figure 3] This diagram schematically illustrates the hierarchical structure of the OS and in-vehicle applications implemented in the in-vehicle function unit, and the relationship between these applications and the in-vehicle devices they control. [Figure 4] This is a flowchart showing the operation of a log collection system according to one embodiment. [Figure 5]This is a diagram showing the structure of the formatted log information collected by the log collection unit. [Figure 6] This is a schematic diagram illustrating an example of the relationship between the acquisition time of OS logs and the acquisition time of application logs. [Figure 7] This figure shows an example of a typical computer hardware configuration. [Modes for carrying out the invention]

[0011] Figure 1 is a diagram of the log collection system 50 according to one embodiment, which comprises an arbitrary number of N vehicles such as automobiles 10-1, 10-2, ..., 10-N, a monitoring device 20 as a server that collects logs from each of these vehicles 10-1, 10-2, ..., 10-N via a network such as a mobile network, and an analysis device 30 as a server that can access the monitoring device 20 via a network or the like.

[0012] Figure 2 is a functional block diagram of a log collection system 50 according to one embodiment. In Figure 2, the vehicle 10 is any one of the N vehicles 10-1, 10-2, ..., 10-N in Figure 1, and their common configuration is shown. The vehicle 10 is equipped with on-board equipment 100 as a computer device, and the on-board equipment 100 has a functional block configuration consisting of an on-board function unit 11, a log collection unit 12, and a vehicle-side storage unit 13. The general functions of each of these units are as follows.

[0013] The in-vehicle function unit 11 is realized by a processor such as a CPU executing a predetermined program. In this embodiment, the in-vehicle function unit 11 is responsible for the functions of a predetermined OS (operating system) and the functions of an in-vehicle application (software) that is further executed under the management of the OS. The in-vehicle application is responsible for the control processing of the in-vehicle device D. The log collection unit 12 collects logs from the in-vehicle function unit 11 and stores the logs, which have been formatted in a predetermined format, in the vehicle-side storage unit 13, which is a storage medium.

[0014] The monitoring device 20, which includes a server-side storage unit 21 and a search unit 22, collects logs stored in the vehicle-side storage units 13 of N vehicles 10-1, 10-2, ..., 10-N, stores them in the server-side storage unit 21, which is a storage medium, and constructs a database. The analysis device 30, which includes a reception unit 31 and a display unit 32, receives log search input from a user performing log analysis in the reception unit 31, sends the log search request to the monitoring device 20, the search unit 22 performs a search from the server-side storage unit 21, which is the database, according to the requested log search conditions, obtains the search results and returns them to the analysis device 30, and the display unit 32 displays these returned search results.

[0015] Figure 3 schematically shows the hierarchical structure of the OS and in-vehicle applications realized in the in-vehicle function unit 11, and the relationship between the in-vehicle devices controlled by the in-vehicle applications. The CPU executes a program corresponding to the OS, thereby realizing the functions of the OS, and these functions include a log generation function at the OS level. Under the management of the OS, the CPU executes a predetermined program, thereby realizing the functions of n in-vehicle application APk (k=1,2,...n), and the functions of each in-vehicle application APk include a log generation function at the application level. Each in-vehicle application APk is responsible for the function of controlling a corresponding predetermined in-vehicle device Dk (k=1,2,...n).

[0016] Each of the in-vehicle devices Dk may be any device that performs driving-related functions in the vehicle 10. For example, it may be a device that performs sensing of the surrounding environment of the vehicle 10 related to or accompanying driving, such as a LiDAR (light detection and ranging, laser image detection and ranging) sensor or a camera that takes normal RGB images, or it may be a light that illuminates the outside or inside of the vehicle 10, or it may be a display or speaker that provides various content and other information to the occupants of the vehicle 10. In the example in Figure 3, a case is shown in which one in-vehicle application APk controls only one corresponding in-vehicle device Dk, but one in-vehicle application may be configured to control two or more in-vehicle devices. (Note that the in-vehicle device Dk and in-vehicle application APk only need to be related to providing added value by making the vehicle 10 intelligent or connected. On the other hand, the in-vehicle device Dk and in-vehicle application APk of the present invention do not handle anything directly related to safety. For example, an EDR (Event Data Recorder) used to analyze events such as collision accidents during manual driving records things directly related to safety, such as engine speed, brake pedal operation status, and accelerator pedal operation status, but the in-vehicle device Dk and in-vehicle application APk of the present invention do not handle such things directly related to safety.)

[0017] As a modification, all or part of the in-vehicle application APk that controls the in-vehicle device Dk may be executed on a sub-OS separate from the main OS by a processor different from the processor on which the main OS is executed. In this case, the sub-OS is responsible for the log generation function of the sub-OS, the in-vehicle application APk is responsible for its own log generation function, and the logs of these sub-OS and the in-vehicle application APk may be collected. As shown in the parentheses in FIG. 3, these may be collected by the log collection application AP'k executed on the main OS. The main OS may be executed by a domain ECU (electronic control unit), and the sub-OS may be executed in each of a plurality of small ECUs grouped by this domain ECU. (Note that, as shown in the parentheses in FIG. 3, it can be configured such that only one application APk is executed on one sub-OS (k).)

[0018] FIG. 4 is a flowchart of the operation of the log collection system 50 according to an embodiment. In step S1, in each of the N vehicles 10-1, 10-2,..., 10-N, the in-vehicle equipment 100 always acquires the OS log and the application log, associates and stores these logs, and periodically transmits the associated and stored log information to the monitoring device 20. In step S2, when the user makes a log search request from the analysis device 30 to the monitoring device 20 that updates and manages the database by saving the logs periodically transmitted from each of the N vehicles 10-1, 10-2,..., 10-N in step S1, the analysis device 30 returns the result of the log search.

[0019] Note that the log collection in step S1 of FIG. 4 may be always executed in the state where the in-vehicle equipment 100 of each vehicle 10 is operating, and the transmission of the collected logs to the monitoring device 20 can be executed periodically, for example, by uploading once a day at night. Based on the always log collection and the periodic log transmission in this step S1, the search process in step S2 can be executed at an arbitrary timing desired by the user who uses the analysis device 30.

[0020] Next, the details of log collection in step S1 (details of the log collection unit 12) will be described.

[0021] The log collection unit 12 obtains formatted log information by adding, as attribute information, the component configuration of in-vehicle equipment, the type and status of the software in operation, etc. to the OS log information obtained by tracing information at the OS kernel level (CPU, memory, storage, communication), and stores it in the vehicle-side storage unit 13.

[0022] FIG. 5 is a configuration diagram of the formatted log information collected by the log collection unit 12. As shown in FIG. 5, for the OS log information, which is tracing data at the OS kernel level, as attribute information, a vehicle identifier, an acquisition time, configuration information regarding the component configuration of in-vehicle equipment, etc., and app log information describing the status of the app are associated, whereby formatted log information can be obtained.

[0023] Regarding the vehicle identifier, a predetermined vehicle identifier recorded in the OS may be used, or it may be substituted with an OS identifier (such as the MAC (Media Access Control) address of the in-vehicle equipment 100).

[0024] Note that, as will also be described below, both the OS log information and the app log information are obtained by recording them irregularly when a predetermined event occurs or by periodically recording some information. As terms, "OS log information" means a set of "OS logs" as individual elements, and "app log information" means a set of "app logs" as individual elements. That is, the whole formed by collecting individual "OS logs" in which various types of information are obtained at various acquisition times constitutes "OS log information", and similarly, the whole formed by collecting individual "app logs" in which various types of information are obtained at various acquisition times constitutes "app log information".

[0025] Regarding the acquisition time (timestamp), it is sufficient to include both the acquisition time of the OS log and the acquisition time of the application log. Figure 6 is a schematic diagram showing an example of the relationship between the acquisition time of the OS log and the acquisition time of the application log. As shown in Figure 6, OS logs can generally be acquired periodically at each OS processing time t=1,2,3,... for usage of CPU, memory, storage, communication, etc. On the other hand, some parts of the OS log, such as network session information (communication source and communication destination pair information) and memory error information, are acquired irregularly. In contrast, application logs generally behave as being acquired irregularly at discrete times (for example, discretely at t=100,301,905,...) when the log generation conditions are met at each OS processing time t=1,2,3,.... (Furthermore, application logs may also be collected periodically, for example, every hour. Additionally, one of the irregularly collected application logs may exhibit behavior that is consequently linked to irregularly collected OS logs (e.g., memory error information).)

[0026] Therefore, in addition to the embodiment in which periodic OS logs are saved for all time points t=1, 2, 3, ..., it is also possible to save irregular application logs and irregular OS logs only for time points in the vicinity of the time when they occur. In the example in Figure 6, when application log AL1 occurs at a time t=T1, only the nearby range R1={t|T1-W1≦t≦T1+W1}(W1>0 is a constant) may be saved as the OS log associated with it. Similarly, when application log AL2 occurs at a time t=T2, only the nearby range R2={t|T2-W2≦t≦T2+W2}(W2>0 is a constant) may be saved as the OS log associated with it. Alternatively, instead of saving only the nearby range and deleting everything outside of it, the OS logs within the nearby range may be linked and saved to the irregular application logs and their occurrence times (OS logs outside the nearby range are also saved, but they are saved without being linked to the application logs and their occurrence times). Furthermore, even if the nearby range is not linked, by linking the tracing data (OS log information) at the same time t as the application log acquisition time t, when a user using the analysis device 30 searches using attribute information, they can refer to the tracing data at the same time t as the application log acquisition time t. This allows the user to perform analysis tasks such as checking the behavior of the tracing data in the nearby range at this time t as needed.

[0027] The time range of the OS logs stored in association with the application logs may be a range corresponding to the type of application log. For example, application logs showing normal behavior may be associated with and stored with OS logs within a relatively short time range, while application logs showing abnormal behavior may be associated with and stored with OS logs within a relatively long time range. Furthermore, the time range of the OS logs stored in association with the application logs in this way may be a predetermined range corresponding to the type k of the application APk (k=1,2,…,n), as shown in the schematic example in Figure 3.

[0028] Regarding configuration information concerning the parts configuration of in-vehicle equipment, as shown in the schematic example in Figure 3, configuration information of the in-vehicle equipment Dk (e.g., a camera) for which the application APk (k=1,2,…,n) is responsible for control processing may be used, depending on the type k of the application APk. This information can be obtained as pre-configuration information for the application APk.

[0029] Furthermore, this configuration information may also include information on the type k of the application APk (k=1,2,…,n) that generated the application log, information on the type and / or version of the OS on which the application APk is running, and computer configuration information that constitutes the in-vehicle equipment 100, such as the performance and type of the CPU, memory, and storage.

[0030] The application log information may include direct text information output as a log, or it may be provided in a pre-classified code format that indicates the operating state of the application software (including normal operation) in the form of a predetermined error code.

[0031] Tracing data as OS log information can be obtained using the kernel-level tracing data acquisition function provided by the OS. For example, if the in-vehicle equipment 100 is a computer running Linux (registered trademark) as its OS, OS kernel-level trace log data can be obtained using eBPF (extended Berkeley Packet Filter) technology. Even if the in-vehicle equipment 100 is implemented with other embedded OSs, a predetermined tracing data acquisition function should be used.

[0032] The tracing data at the kernel level should include information at each time point t, such as CPU (processing dwell time, utilization), memory (whether or not errors occurred), storage (read / write speed), and network (whether or not communication occurred, session information). This information can be obtained using eBPF technology.

[0033] Alternatively, you may choose to acquire all types of tracing data that can be obtained regardless of the app APK type k, or you may choose to acquire a predetermined type of tracing data according to the app APK type k, as shown in the following two examples. (1) For apps that record logs, trace data of the read / write speed of the recording storage. (2) For applications that require real-time processing, trace data of CPU processing dwell time.

[0034] As described above, in the log collection unit 12 of the in-vehicle equipment 100 according to this embodiment, logs are stored in a manner that links OS logs and application logs, and the logs stored in a large number of vehicles 10 are aggregated by the monitoring device 20 to build a database. Therefore, when performing a log search from the analysis device 30, it is possible to extract log information that matches conditions such as specific vehicles or specific OS versions by narrowing down the search using attribute information, and to use it for reliability analysis.

[0035] In other words, the configuration of the in-vehicle equipment 100 (CPU, memory, storage performance and type) and the operating status of the software being used are recorded as attribute information, linked to logs of OS kernel-level behavior, and stored on a remote server (monitoring device 20). This allows for the extraction of data for analysis tailored to specific conditions by using the attribute information as a key when performing data analysis acquired over a long period from multiple vehicles. Analyzing log information that traces whether the in-vehicle equipment 100 is operating normally at the OS kernel level requires the accumulation of data acquired over a long period from multiple vehicles 10. However, by adding attribute information according to this embodiment, it becomes possible to extract only logs acquired under the same conditions, enabling analysis related only to in-vehicle equipment with a specific configuration or specific applications, thereby contributing to improved reliability from a software perspective.

[0036] Furthermore, one example of a situation that can be analyzed in relation to improving reliability from a software perspective is when in-vehicle equipment such as LiDAR or cameras extracts a larger number of feature points than expected, increasing the processing load and reducing the operational stability of object detection processing after feature point extraction. This embodiment makes it possible to analyze such cases.

[0037] Figure 7 shows an example of a hardware configuration in a typical computer. Each of the in-vehicle equipment 100, monitoring device 20, and analysis device 30 that constitute the log collection system 50 can be realized as one or more computer devices 70 having such a configuration. When a partial configuration of the log collection system 50 is realized with two or more computer devices 70, information necessary for processing may be sent and received via a network. The computer device 70 includes a CPU (Central Processing Unit) 71 that executes predetermined instructions, a GPU (Graphics Processing Unit) 72 as a dedicated processor that executes some or all of the execution instructions of the CPU 71 on behalf of or in cooperation with the CPU 71, RAM 73 as main memory that provides a work area to the CPU 71 (and GPU 72), ROM 74 as auxiliary storage, a communication interface 75, a display 76, an input interface 77 that accepts user input via a mouse, keyboard, touch panel, etc., in-vehicle equipment D, and a bus BS for sending and receiving data between them. (Note that the in-vehicle equipment D is provided in the in-vehicle equipment 100 mounted on the vehicle 10, and may be omitted in the monitoring device 20 and analysis device 30. Also, the display 76 and input interface 77, which are configured for use with a general desktop computer, may be omitted in the in-vehicle equipment 100, and display and input functions may be implemented in one or more in-vehicle equipment D.)

[0038] Each functional unit of the log collection system 50 can be implemented by a CPU 71 and / or GPU 72 that read and execute a predetermined program corresponding to the function of each unit from ROM 74. Both the CPU 71 and GPU 72 are types of arithmetic units (processors). When display-related processing is performed, the display 76 also operates in conjunction, and when communication-related processing for data transmission and reception is performed, the communication interface 75 also operates in conjunction.

[0039] The log collection system 50 of this embodiment can contribute to smartening vehicles by incorporating information systems, and thus can contribute to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), "Build resilient infrastructure, promote sustainable industrialization and foster innovation." [Explanation of Symbols]

[0040] 50...Log collection system, 10...Vehicle, 100...In-vehicle equipment, 20...Monitoring device, 30...Analysis device, 11...In-vehicle function unit, D...In-vehicle equipment, 12...Log collection unit, 13...Vehicle-side storage unit, 21...Server-side storage unit, 22...Search unit, 31...Reception unit, 32...Display unit

Claims

1. An in-vehicle device that runs on an OS (operating system) and executes an application that controls in-vehicle equipment, An in-vehicle device characterized by collecting attribute information, including application log information acquired by the aforementioned application, in association with OS log information acquired by the aforementioned OS.

2. The in-vehicle equipment according to claim 1, characterized in that, as information included in the attribute information, the acquisition time of individual application logs which are components of the application log information is collected, and as information included in the OS log information, the acquisition time of individual OS logs which are components of the OS log information is collected.

3. The in-vehicle equipment according to claim 2, characterized in that it associates and collects OS logs within a nearby time range with the acquisition time of the application log.

4. The in-vehicle equipment according to claim 1, characterized in that information of the identifier of the vehicle on which the in-vehicle equipment is installed is collected as information included in the attribute information.

5. The in-vehicle equipment according to claim 1, characterized in that it collects information relating to in-vehicle equipment controlled by the application as information included in the attribute information.

6. The in-vehicle equipment according to claim 1, characterized in that it collects information that identifies the type of application as information included in the attribute information.

7. The in-vehicle equipment according to claim 1, characterized in that it collects information relating to the type and / or version of the OS as information included in the attribute information.

8. The in-vehicle equipment according to claim 1, characterized in that it collects information relating to all or part of the processor, memory, and storage, which are configuration information of the computer running the OS, as information included in the attribute information.

9. The in-vehicle equipment according to claim 1, characterized in that it collects information on the software operating state of the application as application log information generated by the application.

10. The in-vehicle device according to claim 1, characterized in that the OS log information is collected as tracing data at the OS kernel level, including all or part of the following: CPU (central processing unit) processing dwell time and occupancy rate, presence or absence of memory errors, storage read / write speed, and presence or absence of network communication and session information.

11. The in-vehicle equipment described in claim 1, provided in each of the multiple vehicles, A log collection system characterized by including a monitoring device that collects attribute information and OS log information obtained in association from each of the multiple in-vehicle devices and constructs a database.

12. The log collection system according to claim 11, characterized in that the monitoring device receives a search request to the database and returns the search results.

Images