JP2024039283A - On-vehicle facility and log collection system - Google Patents

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

The present invention relates to in-vehicle equipment and a log collection system that acquire logs that can be used for reliability analysis from the perspective of software behavior.

As an existing technology related to the reliability of moving objects such as vehicles, ships, and aircraft, there is, for example, Patent Document 1 (``Autonomous Aircraft Normality System and Method'').

In Patent Document 1, in order to determine the normality of an autonomously flying aircraft, some operations are performed in cooperation with a remote server. For example, engine deterioration, etc. is determined from the operating conditions of the aircraft acquired by sensors, but this is a configuration that operates independently and does not support discrimination based on data collected from multiple aircraft or data accumulated over a long period of time. Not yet.

Special Publication No. 2020-523596

In recent years, for example, in vehicles aiming for autonomous driving, various in-vehicle devices such as cameras for monitoring the surroundings of the vehicle are controlled by software running under an OS (operating system) run on the computer of the in-vehicle equipment. It is being said. In order to ensure the reliability of moving objects such as vehicles, from the perspective of software behavior, by securing sufficient logs in an analyzable format, it is possible to detect situations in which abnormalities may occur in advance. Although it is hoped that this will lead to reliability analysis such as analysis, efforts have not been made in this kind of framework with conventional technology.

For example, Patent Document 1 is a method of determining the reliability of a single aircraft by comparing it with previously known criteria regarding deterioration and abnormalities. With the method of Patent Document 1, it was not possible to collect logs from a large number of aircraft in an analyzable form, and from the viewpoint of software behavior, it was also not possible to aim for advance detection of possible abnormalities.

In view of the problems of the prior art described above, an object of the present invention is to provide an in-vehicle facility that collects logs that can be connected to reliability analysis from the viewpoint of software behavior.

In order to achieve the above object, the present invention provides in-vehicle equipment that executes an application (application) for controlling in-vehicle equipment, which is executed on an OS (operating system), and includes application log information acquired by the application. It is characterized in that attribute information is collected in association with OS log information acquired by the OS.

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, which improves reliability from the perspective of software behavior. It is possible to collect logs that can be used for analysis.

FIG. 1 is a configuration diagram of a log collection system according to an embodiment. FIG. 1 is a functional block diagram of a log collection system according to an embodiment. FIG. 2 is a diagram schematically showing a hierarchical structure between an OS and an in-vehicle application implemented in an in-vehicle functional unit, and a relationship between in-vehicle devices controlled by the in-vehicle application. It is a flowchart of the operation of the log collection system according to one embodiment. FIG. 2 is a configuration diagram of formatted log information collected by a log collection unit. FIG. 2 is a schematic diagram illustrating an example of the relationship between an OS log acquisition time and an application log acquisition time. 1 is a diagram showing an example of a hardware configuration in a general computer.

FIG. 1 is a configuration diagram of a log collection system 50 according to an embodiment. , a monitoring device 20 as a server that collects logs from each of these vehicles 10-1, 10-2,..., 10-N via a network NW such as a mobile network, and a monitoring device 20 that serves as a server that collects logs from each of these vehicles 10-1, 10-2,..., 10-N via a network NW such as a mobile network. and an analysis device 30 as a server that can be accessed by the user.

FIG. 2 is a functional block diagram of the log collection system 50 according to one embodiment. In FIG. 2, the vehicle 10 is any one of the N vehicles 10-1, 10-2,..., 10-N in FIG. 1 and has a common configuration. The vehicle equipment 100 includes an on-vehicle functional unit 11, a log collection unit 12, and a vehicle-side storage unit 13 as functional blocks. An overview of the functions of each of these parts is as follows.

The in-vehicle functional unit 11 is realized when a processor such as a CPU executes a predetermined program, and in this embodiment, functions by executing a predetermined OS (operating system) and management of the OS. This in-vehicle function unit 11 is responsible for the functions of the in-vehicle application (software) that is further executed below. The in-vehicle application is responsible for controlling the in-vehicle device D. The log collection unit 12 collects logs from the in-vehicle function unit 11, formats the logs in a predetermined format, and stores the logs in the vehicle-side storage unit 13, which is a storage medium.

The monitoring device 20 including the server-side storage unit 21 and the search unit 22 collects the logs stored in the vehicle-side storage unit 13 of each of the N vehicles 10-1, 10-2,..., 10-N. Then, the information is stored in the server-side storage unit 21, which is a storage medium, and a database is constructed. In the analysis device 30, which includes a reception section 31 and a display section 32, the reception section 31 receives a log search input from a user who performs log analysis, transmits the log search request to the monitoring device 20, and the search section 22 searches the database. The server-side storage unit 21 performs a search according to the requested log search conditions, obtains search results, and sends them back to the analysis device 30, and displays the returned search results on the display unit 32.

FIG. 3 schematically shows the hierarchical structure of the OS and the in-vehicle application implemented in the in-vehicle function unit 11, and the relationship between the in-vehicle devices controlled by the in-vehicle application. The functions of the OS are realized by the CPU executing programs corresponding to the OS, and these functions include a log generation function at the OS level. Under the management of the OS, the functions of n in-vehicle applications APk (k=1,2,...n) are realized by the CPU executing a predetermined program, and the functions of each in-vehicle application APk are based on the application level. Includes log generation functionality. Each in-vehicle application APk has a function of controlling a corresponding predetermined in-vehicle device Dk (k=1, 2,...,n).

Each of the in-vehicle devices Dk may be any device that performs a driving-related function in the vehicle 10. For example, LiDAR (light detection and measurement) may be used as a device that performs driving-related or incidental sensing of the surrounding environment of the vehicle 10. It may be a sensor (range, laser image detection and ranging) or a camera that takes normal RGB images, it may be a light that lights up the outside or inside of the vehicle 10, or it may be a light that lights up the outside or inside of the vehicle 10. It may also be a display or speaker that provides various types of content and other information. Note that although the example in FIG. 3 shows a case where one in-vehicle application APk controls only one corresponding in-vehicle device Dk, one in-vehicle application may control two or more in-vehicle devices. It may be configured as follows. (The in-vehicle device Dk and the in-vehicle application APk may be anything related to providing added value by making the vehicle 10 intelligent or connected.On the other hand, the in-vehicle device Dk and the in-vehicle application APk of the present invention may be APk does not deal with anything directly related to safety.For example, the EDR (event data recorder) used to analyze events such as collisions during manual driving uses engine speed, brake pedal operation, etc. Although things directly related to safety such as the situation and accelerator pedal operation status are recorded, the in-vehicle device Dk and the in-vehicle application APk of the present invention do not handle anything directly related to safety.)

In addition, as a modified example, all or part of the in-vehicle application APk that controls the in-vehicle device Dk is executed on a sub-OS that is separate from the main OS, and on a processor that is different from the processor on which the main OS is executed. It may be. 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 it is sufficient to collect the logs of these sub-OSes and the logs of the in-vehicle application APk, as shown in parentheses in Figure 3. As shown in , 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 bundled by this domain ECU. (As shown in parentheses in Figure 3, it is possible to configure so that only one application APk is executed on one sub-OS(k).)

FIG. 4 is a flowchart of the operation of the log collection system 50 according to one embodiment. In step S1, in each of the N vehicles 10-1, 10-2,..., 10-N, the in-vehicle equipment 100 constantly obtains OS logs and application logs, and stores these logs in a linked manner. The linked and saved log information is periodically transmitted to the monitoring device 20. In step S2, the monitoring device updates and manages the database by periodically saving logs sent from each of the N vehicles 10-1, 10-2,..., 10-N in step S1. 20, when a user requests a log search from the analysis device 30, the result of the log search is sent back to the analysis device 30.

Note that the log collection in step S1 in FIG. 4 may be performed at all times while the in-vehicle equipment 100 of each vehicle 10 is in operation, and the transmission of the collected logs to the monitoring device 20 may be performed, for example, in step S1. It can be executed periodically by uploading once a day at night. On the premise of the constant log collection and periodic log transmission in step S1, the search process in step S2 can be executed at any timing desired by the user using the analysis device 30.

Details of log collection in step S1 (details of the log collection unit 12) will be described below.

The log collection unit 12 adds attribute information such as the parts configuration of in-vehicle equipment and the type and status of running software to OS log information that traces OS kernel level information (CPU, memory, storage, communication). By doing so, the formatted log information is acquired and stored in the vehicle-side storage unit 13.

FIG. 5 is a configuration diagram of formatted log information collected by the log collection unit 12. As shown in FIG. 5, for OS log information which is tracing data at the OS kernel level, as attribute information, Formed log information can be obtained by linking the vehicle identifier, acquisition time, configuration information regarding the parts configuration of the in-vehicle equipment, and application log information that describes the status of the application.

As for the vehicle identifier, a predetermined vehicle identifier recorded in the OS may be used, or an OS identifier (such as the MAC (Media Access Control) address of the in-vehicle equipment 100) may be used instead.

As explained below, both OS log information and application log information are acquired irregularly when a predetermined event occurs, or as information that is recorded periodically. It is something that will be done. As terms, "OS log information" means a collection of "OS logs" as individual elements, and "application log information" means a collection of "application logs" as individual elements. In other words, a collection of individual "OS logs" in which various types of information are acquired at various acquisition times constitutes "OS log information," and similarly, various types of information are acquired at various acquisition times. The entire collection of acquired individual "application logs" constitutes "application log information."

The acquisition time (time stamp) may include 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, the OS log is In general, it can be periodically acquired at each time t = 1, 2, 3, etc. of the OS processing timing, and on the other hand, as part of the OS log, for example, network session information (pair of communication source and communication destination) information) and memory error information are obtained irregularly, whereas application logs are generally obtained when the log generation conditions are met at each time t=1, 2, 3,... of the OS processing timing. shows behavior that is acquired irregularly and at discrete times (for example, discretely, such as t=100, 301, 905,...). (Note that some application logs may also be obtained periodically, for example, generated every hour.One of the irregular application logs is an irregular OS log. (For example, there may be something that indicates the behavior that is obtained in conjunction with memory error information.)

Therefore, for regular OS logs, in addition to the embodiment in which all of the times t=1, 2, 3, etc. are saved, there is also an embodiment in which irregular application logs or irregular OS logs are Only the times within the range may be saved. In the example in Figure 6, when application log AL1 occurs at a certain time t=T1, this neighborhood range R1={t|T1-W1≦t≦T1+W1}( W1>0 is a constant).Similarly, when application log AL2 occurs at a certain time t=T2, this neighborhood range R2={ Only t|T2-W2≦t≦T2+W2} (W2>0 is a constant) may be saved. In addition, instead of saving only the nearby range and deleting the outside of the nearby range, it is possible to link and save OS logs in the nearby range to irregular application logs and their occurrence times ( The OS log is also saved, but it may be saved without being linked to the application log and the time of its occurrence. In addition, even if the neighborhood range is not linked, by linking the tracing data (OS log information) at the same time t as the acquisition time t of the application log, the user using the analysis device 30 can When searching for information, tracing data at the same time t as the app log acquisition time t can be referenced, and the user can check the behavior of the tracing data in the vicinity of this time t if necessary. This makes it possible to perform analysis tasks such as

The time range of OS logs that are saved in association with application logs may be set according to the type of application log. For example, for app logs that show normal behavior, OS logs for a relatively short time range are linked and saved, and for app logs that show abnormal behavior, OS logs for a relatively long time range are linked and saved. You may also do so. Furthermore, the time range of OS logs that are saved in association with application logs depends on the type k of application APk (k=1,2,...,n), as shown in the schematic example in Figure 3. It may be within a predetermined range.

Regarding configuration information regarding the parts configuration of in-vehicle equipment, etc., as shown in the schematic example in Figure 3, this app APk performs control processing according to the type k of the app APk (k=1, 2,...,n). The configuration information of the in-vehicle device Dk (for example, a camera, etc.) in charge may be used, and this information can be obtained as preset information for the application APk.

In addition, this configuration information further includes information on the type k of the app APk (k=1,2,...,n) that generated the app log, and the type and/or version of the OS running the app APk. Information and computer configuration information constituting the in-vehicle equipment 100 may include the performance and type of the CPU, memory, and storage.

App log information may include direct text information that is output as a log, or it may be in the form of a predetermined error code, etc., in the form of a code that pre-classifies the operating status (including normal operating status) of the app's software. You may also give it as

Tracing data as OS log information may be acquired using a kernel-level tracing data acquisition function provided by the OS. For example, if the in-vehicle equipment 100 is configured with a computer running Linux (registered trademark) as the OS, trace log data at the OS kernel level can be obtained using eBPF (extended Berkeley Packet Filter) technology. Even if the in-vehicle equipment 100 is implemented using another built-in OS or the like, a predetermined tracing data acquisition function may be used.

The content of tracing data at the kernel level includes information at each time t, such as CPU (processing retention time, occupancy rate), memory (error occurrence), storage (read/write speed), network (communication presence/absence, session information), etc. (This information can be obtained using eBPF technology) and trace log data may be obtained.

Note that all types of tracing data that can be obtained may be acquired regardless of the type k of the application APk, or a predetermined type according to the type k of the application APk may be acquired, as shown in the following two examples. Tracing data may also be acquired.
(1) For apps that record logs, tracing data of read/write speed of recording storage (2) For apps that require real-time processing, tracing data of CPU processing residence time

As described above, the log collection unit 12 of the in-vehicle equipment 100 according to the present embodiment stores logs in a form that links OS logs and application logs, and the logs stored in a large number of vehicles 10 are stored in the monitoring device. 20 to build a database, so when performing a log search from the analyzer 30, by narrowing down the logs using attribute information, log information can be extracted according to conditions such as a specific vehicle or only a specific OS version, and reliability can be improved. It becomes possible to use it for analysis in applications.

In other words, the configuration of the in-vehicle equipment 100 (performance and type of CPU, memory, and storage) and the operating status of the software being used are recorded as attribute information in a form linked to OS kernel-level behavior logs, and then sent to a remote server. (Monitoring device 20), when analyzing data acquired from multiple vehicles over a long period of time, it is possible to extract data for analysis according to conditions by using attribute information as a key. . In order to analyze whether the in-vehicle equipment 100 is operating normally from log information traced at the OS kernel level, it is considered necessary to accumulate data acquired from multiple vehicles 10 over a long period of time, so this implementation By adding attribute information based on format, it becomes possible to extract only logs acquired under the same conditions, and it becomes possible to perform analysis related only to in-vehicle equipment with a specific configuration or a specific application. This can contribute to improving reliability.

An example of a situation that can be analyzed related to improving reliability from a software perspective is, for example, when the in-vehicle device is LiDAR or a camera, a larger number of feature points than expected are extracted, increasing the processing load and reducing the number of features. There are situations in which the stability of operations such as object detection processing after point extraction is reduced. According to this embodiment, it is possible to analyze such cases.

FIG. 7 is a diagram showing an example of the hardware configuration of a general computer. Each of the in-vehicle equipment 100, the monitoring device 20, and the analysis device 30 that constitute the log collection system 50 can be realized as one or more computer devices 70 having such a configuration. Note that when a partial configuration of the log collection system 50 is implemented using 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) as a dedicated processor that executes some or all of the instructions executed by the CPU 71 instead of the CPU 71 or in cooperation with the CPU 71. ) 72, RAM 73 as main memory that provides a work area for CPU 71 (and GPU 72), ROM 74 as auxiliary storage, communication interface 75, display 76, user input via mouse, keyboard, touch panel, etc. The vehicle includes an input interface 77 for receiving data, an in-vehicle device D, and a bus BS for exchanging data between them. (Note that the on-vehicle equipment D is provided in the on-vehicle equipment 100 mounted on the vehicle 10, and may be omitted in the monitoring device 20 and the analysis device 30. The display 76 and input interface 77 as components may be omitted in the in-vehicle equipment 100, and one or more in-vehicle equipment D may have a display function or an input function.)

Each functional unit of the log collection system 50 can be realized by the CPU 71 and/or the GPU 72 that read a predetermined program corresponding to the function of each unit from the ROM 74 and execute it. Note that both the CPU 71 and the GPU 72 are a type of arithmetic device (processor). Here, when display-related processing is performed, the display 76 also operates in conjunction, and when communication-related processing regarding data transmission and reception is performed, the communication interface 75 further operates in conjunction.

According to the log collection system 50 of this embodiment, it is possible to contribute to making vehicles smart by incorporating information systems into them. It will be possible to contribute to the development of infrastructure, promote sustainable industrialization, and expand innovation.

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 section, 22...Search section, 31...Reception section, 32...Display section

Claims (12)

In-vehicle equipment that executes an application (application) that controls in-vehicle equipment that runs on an OS (operating system),
An in-vehicle device characterized in that attribute information including application log information acquired by the application is collected in association with OS log information acquired by the OS. As information included in the attribute information, the acquisition time of each individual application log, which is a component of the application log information, is collected, and as information included in the OS log information, the acquisition time of each individual application log, which is a component of the OS log information, is collected. The in-vehicle equipment according to claim 1, wherein the in-vehicle equipment collects an OS log acquisition time. 3. The in-vehicle equipment according to claim 2, wherein the OS logs in a time range close to the acquisition time of the application log are collected by being associated with each other. The on-vehicle equipment according to claim 1, wherein information on an identifier of a vehicle in which the on-vehicle equipment is mounted is collected as information included in the attribute information. The in-vehicle equipment according to claim 1, characterized in that information regarding in-vehicle equipment controlled by the application is collected as information included in the attribute information. The in-vehicle equipment according to claim 1, wherein information that specifies the type of the application is collected as the information included in the attribute information. The in-vehicle equipment according to claim 1, wherein information regarding the type and/or version of the OS is collected as the information included in the attribute information. 2. The in-vehicle equipment according to claim 1, wherein information included in the attribute information includes information on all or part of a processor, memory, and storage, which is configuration information of a computer that executes the OS. The in-vehicle equipment according to claim 1, wherein information on a software operating state of the application is collected as application log information generated by the application. The OS log information is used as tracing data at the kernel level of the OS to determine processing retention time and occupancy of the CPU (central processing unit), presence or absence of memory errors, storage read/write speed, presence or absence of network communication, and sessions. The in-vehicle device according to claim 1, wherein the in-vehicle device collects all or part of the information. The in-vehicle equipment according to claim 1, which is provided in each of a plurality of vehicles;
A log collection system comprising: a monitoring device that constructs a database by collecting the linked attribute information and OS log information from each of the plurality of in-vehicle equipment. 12. The log collection system according to claim 11, wherein the monitoring device receives a search request for the database and returns a search result.

Images