Failure analysis support system and failure analysis support method

Abstract

To further improve detection accuracy of a failure of an ECU.SOLUTION: A failure analysis support system generates trace information of in-vehicle network information including a date and time of occurrence of the in-vehicle network information from a log of the in-vehicle network information transmitted and received from a plurality of in-vehicle components via an in-vehicle network. Then, the failure analysis support system generates a time-series pattern of the in-vehicle network information from the trace information. Then, the failure analysis support system estimates a function based on the time-series pattern generated from the trace information using a function estimation model for estimating a function operating in the vehicle when the time-series pattern is generated.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present invention relates to a failure analysis support system and a failure analysis support method. [Background technology]

[0002] Recent automobiles (hereinafter referred to as "vehicles") are equipped with numerous ECUs (Electronic Control Units). The ECUs installed in the vehicle communicate with each other via an in-vehicle network such as a Controller Area Network (CAN (registered trademark)) and cooperate to control the running of the vehicle.

[0003] Because ECUs operate in cooperation with other ECUs via the in-vehicle network, problems related to the in-vehicle network or problems that cannot be identified through self-diagnosis by each ECU alone may occur.

[0004] For example, Patent Document 1 discloses a vehicle faulty part detection device that can identify faults related to an in-vehicle network and faults that cannot be identified by self-diagnosis by each ECU alone. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2005-14743 Summary of the Invention [Problem to be solved by the invention]

[0006] However, the above-mentioned conventional technology implements expected patterns, such as CAN frame data and processing sequences that are caused by ECU malfunctions, and detects malfunctions based on the difference between the expected patterns. Therefore, in a situation where multiple ECUs from different vendors are mixed, only expected malfunctions (malfunctions that are easy to analyze) are detected. On the other hand, many difficult-to-solve malfunctions (malfunctions that are difficult to analyze) arise from unexpected causes and are difficult to detect by extracting differences from expected patterns.

[0007] The present invention has been made in view of the above-mentioned problems, and has an object to further improve the accuracy of detecting malfunctions in ECUs. [Means for solving the problem]

[0008] In order to achieve the above-mentioned object, one aspect of the present invention is a malfunction analysis support system that supports analysis of malfunctions that occur in a vehicle having a plurality of on-board components that are connected via an on-board network to perform functions, the malfunction analysis support system having a processor and a memory, wherein the processor generates trace information of on-board network information, including a date and time of occurrence of the on-board network information, from a log of the on-board network information transmitted and received from the plurality of on-board components via the on-board network, generates a time series pattern of the on-board network information from the trace information, and estimates the function that was operating in the vehicle when the time series pattern occurred, based on the time series pattern generated from the trace information, using an estimation model that estimates the function. [Effects of the Invention]

[0009] According to the present invention, for example, it is possible to further improve the accuracy of detecting malfunctions in ECUs. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram showing the configuration of a defect analysis support system according to an embodiment. [Figure 2] FIG. 4 is a diagram showing the configuration of analytical trace information according to the embodiment. [Figure 3] FIG. 4 is a diagram showing the configuration of an analysis table according to the embodiment. [Figure 4] FIG. 2 is a diagram showing the configuration of CAN signal definition information according to the embodiment. [Figure 5] FIG. 4 is a diagram showing the configuration of matching result information according to the embodiment. [Figure 6] FIG. 10 is a diagram showing the configuration of a specific result record table according to the embodiment. [Figure 7] FIG. 10 is a diagram showing a state in which a signal name is entered in a time slot in the identification result record table according to the embodiment. [Figure 8] FIG. 2 is a diagram showing a function estimation model according to the embodiment. [Figure 9] FIG. 10 is a diagram showing a function estimation model (with occurrence time) according to the embodiment. [Figure 10] FIG. 10 is a diagram showing the configuration of identification result information according to the embodiment. [Figure 11] 10 is a flowchart showing a defect analysis support process according to the embodiment. [Figure 12] 10 is a flowchart showing a design information reading process according to the embodiment. [Figure 13] 10 is a flowchart showing a matching process according to the embodiment. [Figure 14] 10 is a flowchart showing an operation function identification process according to the embodiment. [Figure 15] 10 is a flowchart showing an inquiry destination / related specification information output process according to the embodiment. [Figure 16] FIG. 2 is a diagram showing an Ethernet frame that encapsulates a CAN frame according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of the present invention will be described with reference to the drawings. The embodiments are examples for explaining the present invention, and appropriate omissions and simplifications have been made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. The position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0012] Examples of various types of information may be described using expressions such as "table," "list," "queue," and "database," but the various types of information may also be expressed using data structures other than these. For example, various types of information such as "XX table," "XX list," and "XX queue" may also be expressed as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are interchangeable.

[0013] When there are multiple components with the same or similar functions, they may be described using the same reference numeral with different subscripts. When there is no need to distinguish between these multiple components, the subscripts may be omitted.

[0014] The processing performed by executing a program may be described with the program as the subject. Here, a computer executes the program using a processor (e.g., a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit)) and performs the processing defined by the program using storage resources (e.g., memory) and interface devices (e.g., communication ports). Therefore, the subject of the processing performed by executing a program may be the processor.

[0015] Similarly, the entity that executes the program and performs the processing may be a controller, device, system, computer, or node having a processor. The entity that executes the program and performs the processing may be any computing unit, and may include a dedicated circuit that performs specific processing. Here, the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device).

[0016] A program may be installed on a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and storage resources for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in an embodiment, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0017] (Configuration of the defect analysis support system 1 according to the embodiment) 1 is a diagram showing the configuration of a malfunction analysis support system 1 according to an embodiment. The malfunction analysis support system 1 analyzes malfunctions of ECUs (Controller Area Network, registered trademark (hereinafter the same)) installed in a vehicle 100 based on a CAN transmission log 2a acquired via a diagnostic machine 101 from a target vehicle 100 (or a test environment simulating the vehicle 100) on which a plurality of ECUs (Electronic Control Units) are connected via a CAN 101.

[0018] Here, the ECU is an example of an in-vehicle component that transmits and receives in-vehicle network information.

[0019] The failure analysis support system 1 includes a processor 11, a memory 12, a storage 13, and an input / output unit 14.

[0020] The processor 11 loads a program stored in a predetermined storage area such as storage 13 into memory 12 and executes it, thereby realizing a parsing processing unit 11a, a matching processing unit 11b, an operation function identification unit 11c, and a related information acquisition unit 11d.

[0021] The memory 12 functions as a storage area used when the processor 11 executes a program.

[0022] The storage 13 stores the above-mentioned programs, various data used when the programs are executed, analytical trace information 13a, matching result information 13b, function estimation models 13c, and identification result information 13d.

[0023] The input / output unit 14 includes an output device such as a display that displays information presented to the user by the failure analysis support system 1, and an input device such as a keyboard that accepts information input to the failure analysis support system 1 by the user.

[0024] The parsing processing unit 11a receives the CAN transmission log 2a and the DBC information 2b as input, parses the CAN transmission log 2a based on the DBC information 2b, generates analytical trace information 13a, and stores the analytical trace information 13a in the storage 13.

[0025] The CAN transmission log 2a is a log of CAN signals expressed in binary that are acquired from the vehicle 100 via the diagnostic device 101. The DBC information 2b is a conversion file for converting bit data in the data frame of the CAN signal into human-readable information.

[0026] As shown in Figure 2, the analytical trace information 13a is readable information extracted from the CAN transmission log 2a based on the DBC information 2b, and is information in which the CAN signals included in the CAN transmission log 2a are arranged in chronological order. In the example of Figure 2, the CAN signal with a "trace ID" of "001" has a "transmission date" of "2024 / 03 / 08," an "occurrence time" of "07:00:30," a "CAN ID" of "0001," and one bit of "1" stored in the "data section 1" field. The CAN signal with a "trace ID" of "001" has no data stored in the "data sections 2 to M" fields.

[0027] The matching processing unit 11b reads out the analytical trace information 13a and performs a matching process between the analytical trace information 13a and the design information 2c. The design information 2c includes design documents (document files), specifications, design models, etc. contained in a PLM (Product Lifecycle Management) / ALM (Application Lifecycle Management) DB (Data Base) 2e.

[0028] Prior to the matching process, the matching processing unit 11b extracts the function names (classifications) of the in-vehicle functions realized by the ECU and the function names (details) that indicate the details of the functions from the design documents included in the design information 2c.

[0029] Then, the matching processing unit 11b generates an analysis table 13b0 (Fig. 3) for each occurrence date and time (transmission date + occurrence time) of the analytical trace information 13a, and expands the function names (classifications) and function names (details) extracted from the design documents, etc., into the portion enclosed by dashed line 13b1 of the analysis table 13b0. In the example of Fig. 3, "automatic driving function," "vehicle body control," etc. are function names (classifications), and "pre-crash braking," "lane keeping," "brake control," etc. are function names (details).

[0030] Similarly, the matching processing unit 11b extracts CAN signal names from CAN signal definition list information 2d included in the design information 2c. Then, the matching processing unit 11b expands the CAN signal names extracted from the CAN signal definition list information 2d into the portion enclosed by the dashed line 13b2 in the analysis table 13b0 (FIG. 3). In the example of FIG. 3, the CAN signal names are "obstacle detection," "user notification," "brake control instruction transmission," "accelerator control instruction transmission," and "brake control instruction reception."

[0031] CAN signal definition list information 2d is information that defines bit data within the CAN frame of a CAN signal identified by a CAN ID and a CAN signal name that indicates processing or operation related to the CAN signal, as shown in Fig. 4. In the example of Fig. 4, for example, the CAN frame of a CAN signal with a "CAN ID" of "0001" and a "CAN signal name" of "Autonomous driving assistance function initialization" has a 1-bit "Autonomous driving initialization flag" field (data section 1) following the "CAN ID" field at the beginning.

[0032] The matching processing unit 11b then reads the analytical trace information 13a line by line, refers to the CAN signal definition list information 2d, and identifies the "CAN signal name" based on the "CAN ID." The matching processing unit 11b then enters "○" in all columns of the rows in the analysis table 13b0 that correspond to the identified "CAN signal name." Note that "×" is entered in advance in the columns of functions (details) that are not the subject of analysis.

[0033] The matching processing unit 11b then inputs a "# (number)" that identifies the matching result, a "trace ID" that identifies the analytical trace information 13a, and a "date and time" that corresponds to the timestamp of the corresponding row of the analytical trace information 13a into the analysis table 13b0. In this way, the matching processing unit 11b generates matching result information 13b (FIG. 5). Matching result information 13b is generated for each "# (number)" and "trace ID."

[0034] As shown in Fig. 6, the operation function identification unit 11c generates an identification result record table 13d0 in which a function name (details) input field 13d1, a time slot SLT, and a matching degree input field 13d2 are arranged vertically, and the same number of columns as the function names (details) extracted from the design document, etc. are arranged horizontally. In the identification result record table 13d0, the number of slots N of the time slot SLT is (TM-T1) / T0, which is the trace time TM-T1 from the start date and time T1 to the end date and time TM of the analysis trace information 13a to be analyzed, divided by the sampling period T0. Time slot SLT=1 is the time slot that includes the start date and time T1. The sampling period T0 (the duration of each time slot SLT) is assumed to be input by the user via the input / output unit 14.

[0035] Then, the operation function identification unit 11c transfers the "○" entered in association with the "function name (details)" and the "CAN signal name" in each piece of matching result information 13b to the column of the row of the time slot SLT of the "function name (details)" in the identification result record table 13d0 to which the "date and time" of each piece of matching result information 13b belongs.

[0036] If multiple "CAN signal names" belong to one time slot T, enter the "CAN signal name" that has the most entries. Figure 7 shows the identification result record table 13d0 in a state where the "function name (details)" and "CAN signal name" have been entered.

[0037] Then, the operating function identification unit 11c performs pattern matching between the function estimation model 13c and the identification result record table 13d0 in which the "function name (details)" and "CAN signal name" have been input. Through pattern matching, the "function name (details)" that is estimated to have been operating when the time series of the "CAN signal name" (CAN signal) stored in the identification result record table 13d0 occurred is identified.

[0038] The function estimation model 13c is an estimation model that estimates the function that was operating in the vehicle 100 when the time series pattern of the CAN signal occurred. The degree of match is the rate at which the order of occurrence of the CAN signal and the time slot SLT at which the CAN signal occurred are the same between the function estimation model 13c and the time series of the CAN signal stored in the identification result record table 13d0. The degree of match is also called "estimation likelihood."

[0039] The function estimation model 13c is an estimation model that takes statistics of historical information that actually occurred in the past and patterns the time series of CAN signals transmitted for each "function name (details)," as shown in Fig. 8. Alternatively, it may be a Markov model configured based on the history of CAN signals transmitted for each "function name (details)."

[0040] For example, if the "Function name (details)" is "Pre-crash brake," the CAN signal time sequence is "Detect obstacle ahead → Detect distance → Notify driver → Suppress engine → Send brake control signal → Display meter" (for Pre-crash brake 1). Also, if the "Function name (details)" is "Pre-crash brake," the time sequence is "Detect obstacle ahead → Detect distance → Notify driver → Determine brake control signal → Send brake control signal → Display meter" (for Pre-crash brake 2).

[0041] Conversely, if the CAN signal time sequence is "forward obstacle detected → distance detected → driver notification → engine inhibited → brake control signal sent → meter display," it is presumed that the Pre-Crash Brake 1 function has been activated.Also, if the CAN signal time sequence is "forward obstacle detected → distance detected → driver notification → brake control signal determined → brake control signal sent → meter display," it is presumed that the Pre-Crash Brake 2 function has been activated.

[0042] The operation function identification unit 11c calculates the degree of coincidence in pattern matching between the time series of the CAN signals included in the function estimation model 13c and the time series of the CAN signals already input to the identification result record table 13d0, and then rearranges the columns of the identification result record table 13d0 in descending order of the degree of coincidence.

[0043] As shown in Figure 9(a), a history of the occurrence time T of each CAN signal for each time slot SLT may be stored, and statistical values ​​such as the average value of the occurrence time may be calculated and learned. Then, as shown in Figure 9(b), the statistical value of the occurrence time may be assigned to each CAN signal in the function estimation model 13c. The "function name (details)" using the function estimation model 13c is identified as follows: (1) The time series order of the input CAN signals is compared, and functions (function names (details)) that match (or match to a predetermined value or more) are extracted. (2-1) If there is one matching function (function name (details)), output the matching function (function name (details)) as the function that worked. (2-2) If there are multiple matching functions (function names (details)), the difference between the actual occurrence time for each process (CAN signal) and the statistical value of the occurrence time on the function estimation model 13c is calculated, and the function with the smallest error is output as the function that has operated.

[0044] If the "function name (details)" entered in the identification result recording table 13d0 differs from the "function name (details)" identified using the function estimation model 13c, it is updated with the "function name (details)" identified using the function estimation model 13c.

[0045] The related information acquisition unit 11d refers to the PLM / ALMDB 2e based on the function name (classification) and function name (details) identified by the operation function identification unit 11c, and acquires design information 2c related to the corresponding function name (classification) and function name (details). The related information acquisition unit 11d also refers to the contract information DB 2f based on the function name (classification) and function name (details) identified by the operation function identification unit 11c, and acquires contact information for a vendor or the like responsible for maintaining and managing the corresponding function name (classification) and function name (details). The related information acquisition unit 11d presents the acquired design information 2c and contact information to the user via an analysis result display screen (not shown) displayed on the input / output unit 14.

[0046] (Configuration of identification result information 13d according to the embodiment) Fig. 10 is a diagram showing the configuration of identification result information 13d according to the embodiment. Fig. 10 shows an example of identification result information 13d generated as described above. The identification result information 13d is a list of function names (details) that match the time series of the CAN signals input to the identification result record table 13d0, arranged in descending order of degree of match. The example in Fig. 10 shows that the "function name (details)" "pre-crash braking" has a degree of match of 94%, and the "function name (details)" "lane keeping" has a degree of match of 25%...

[0047] (Fault analysis support process according to the embodiment) 11 is a flowchart showing a defect analysis support process according to the embodiment. The defect analysis support process matches design information 2c extracted from PLM / ALM 2e with analytical trace information 13a in response to a user instruction via an analysis instruction screen (not shown) displayed on the input / output unit 14 or at a predetermined interval.

[0048] First, in step S11, the parsing processor 11a parses the CAN transmission log 2a based on the DBC information 2b to generate analytical trace information 13a.

[0049] Next, in step S12, the matching processing unit 11b executes a design information reading process, the details of which will be described later with reference to FIG.

[0050] Next, in step S13, the matching processing unit 11b executes a matching process between the design information 2c and the analytical trace information 13a. Details of the matching process will be described later with reference to FIG.

[0051] Next, in step S14, the operation function identifying unit 11c executes an operation function identifying process, the details of which will be described later with reference to FIG.

[0052] Next, in step S15, the operational function identification unit 11c executes a process of detecting CAN signal time series (operation functions) that are statistically outliers. In step S15, among the CAN signal time series (operation functions) identified in step S14, CAN signal time series (operation functions) whose degree of coincidence is less than a threshold are excluded from the identification result information 13d.

[0053] Next, in step S16, the operation function identification unit 11c outputs the identification result information 13d from which the outlier operation functions have been excluded in step S15, from a display screen (not shown) displayed on the input / output unit .

[0054] Next, in step S17, the related information acquisition unit 11d executes a related information acquisition process to acquire related documents such as related specifications related to the time series (operation functions) of the CAN signal excluding the outliers, as well as contact information for vendors, etc. Details of the related information acquisition process will be described later with reference to FIG.

[0055] (Design Information Reading Process According to the Embodiment) FIG. 12 is a flowchart showing the design information reading process according to the embodiment.

[0056] First, the matching processing unit 11b repeats steps S12a to S12e for the PLM / ALMDB 2e of the product to be analyzed.

[0057] First, in step S12a, the matching processing unit 11b acquires design information 2c, such as design documents (document files) and design models, stored in the PLM / ALM 2e, and expands it in the memory 12. Next, in step S12b, the matching processing unit 11b extracts function names (classifications) from the design information 2c expanded in the memory 12. In step S12b, for example, function names (classifications) or terms similar to function names (classifications) are extracted from the design documents, etc. Next, in step S12c, the matching processing unit 11b registers the function names (classifications) extracted in step S12b in the area surrounded by dashed line 13b1 in the analysis table 13b0 (FIG. 3).

[0058] Next, the matching processing unit 11b repeats steps S12d to S12e for each function (detail) included in the function name (classification).

[0059] In step S12d, the matching processing unit 11b extracts function names (details) from the design information 2c expanded in the memory 12. In step S12d, for example, function names (details) under each function name (classification) described in the design document or terms similar to function names (details) are extracted. Next, in step S12e, the matching processing unit 11b registers the function names (details) extracted in step S12d in the area surrounded by dashed line 13b1 in the analysis table 13b0 (FIG. 3).

[0060] Next, in step S12f, the matching processing unit 11b acquires the CAN signal definition list information 2d.

[0061] Next, the matching processing unit 11b repeats steps S12g to S12h for all CANIDs acquired in step S12f.

[0062] Next, in step S12g, the matching processing unit 11b acquires the CAN signal name from the CAN signal definition list information 2d acquired in step S12f. Next, in step S12h, the matching processing unit 11b registers the CAN signal name acquired in step S12g in the area surrounded by the dashed line 13b2 in the analysis table 13b0.

[0063] Next, in step S12i, the matching processing unit 11b stores in the memory 12 the analysis table 13b0 in which the function names (classifications), function names (details), and CAN signal names are registered.

[0064] (Matching process according to the embodiment) 13 is a flowchart showing the matching process according to the embodiment. In the matching process according to the embodiment, analytical trace information 13a and design information 2c are matched.

[0065] First, in step S13a, the matching processing unit 11b acquires the analytical trace information 13a generated in step S11. Next, in step S13b, the matching processing unit 11b acquires the analysis table 13b0 stored in the memory 12 as a template for the matching result information 13b.

[0066] Next, in step S13c, the matching processing unit 11b inputs "x" into the column corresponding to the combination of the function name (details) and CAN signal name that are not the analysis target in the analysis table 13b0 acquired in step S13b. The position where "x" is input is determined based on the information of the current debugging target set by the user.

[0067] Next, the matching processing unit 11b repeats steps S13d to S13l for all of the analytical trace information 13a acquired in step S13b.

[0068] In step S13d, the matching processing unit 11b reads one line of unprocessed trace information from the analytical trace information 13a. Next, in step S13e, the matching processing unit 11b acquires the CAN signal name from the trace information read in step S13d. The CAN signal name is acquired by converting the CAN ID with reference to the CAN signal definition list information 2d. Next, in step S13f, the matching processing unit 11b acquires the "occurrence time" from the trace information read in step S13d.

[0069] Next, in step S13g, the matching processing unit 11b determines whether the trace information read in step S13d has a trace ID. If the trace information read in step S13d has a trace ID (step S13g YES), the matching processing unit 11b proceeds to step S13h, and if the trace information does not have a trace ID (step S13g NO), the matching processing unit 11b proceeds to step S13i.

[0070] In step S13h, the matching processing unit 11b acquires a trace ID from the trace information. Meanwhile, in step S13i, the matching processing unit 11b generates a new trace ID. When step S13h or S13i is completed, the matching processing unit 11b proceeds to step S13j.

[0071] In step S13j, the matching processing unit 11b stores the trace ID and the occurrence time acquired in step S13f in the analysis table 13b0, and updates # (number) in the analysis table 13b0.

[0072] Next, in step S13k, the matching processing unit 11b identifies the transmitted CAN signals based on the CAN IDs in the trace information and the CAN signal definition list information 2d. Next, in step S13l, the matching processing unit 11b enters a "○" (check mark) in all columns of the CAN signal name rows in the analysis table 13b0 that correspond to all CAN signals identified in step S13k.

[0073] Through the above matching process, matching result information 13b is generated from the analysis table 13b0.

[0074] (Operation function identification process according to the embodiment) FIG. 14 is a flowchart showing the operation function identification process according to the embodiment.

[0075] First, in step S14a, the operation function identification unit 11c receives the setting of the sampling period T0, which is input by the user via an analysis instruction screen (not shown) displayed on the input / output unit 14.

[0076] Next, in step S14b, the operation function identification unit 11c secures the required number of rows and columns in the identification result record table 13d0. The required number of rows is the number N of the time slots SLT described above. The required number of columns is the number of the function names (details) described above.

[0077] Next, in step S14c, the operation function identifying unit 11c determines to which time slot SLT=1 to N all of the matching result information 13b belongs based on its "date and time".

[0078] Next, the operation function identifying unit 11c repeats steps S14d to S14f for the matching result information 13b that has been determined to belong to any one of the time slots SLT=1 to N, the number of times corresponding to N time slots SLT.

[0079] Furthermore, the operation function identification unit 11c repeats steps S14d to S14f for the matching result information 13b whose "date and time" falls within the sampling period (time width) corresponding to the number N=i (i=1, 2, ..., N) of each time slot SLT. That is, steps S14d to S14f are repeated for the matching result information 13b belonging to the same time slot SLT.

[0080] In step S14d, the operation function identification unit 11c extracts information stored in the matching result information 14d for each "date and time". Next, in step S14e, the operation function identification unit 11c extracts CAN signal names for which "○" has been entered for each "date and time" and function (details). Next, in step S14f, the operation function identification unit 11c enters the CAN signal names extracted in step S14e into the column corresponding to the combination of the corresponding function (details) and time slot SLT in the identification result record table 13d0. In step S14d, if there are multiple CAN signal names that belong to the same function (details) and the same time slot SLT, the most dominant CAN signal name is adopted.

[0081] When the two loops of repeating steps S14d to S14f are completed, the identification result record table 13d0 shown in FIG. 7 is generated.

[0082] Next, in step S14g, the operating function identifying unit 11c identifies the operated function. That is, the operating function identifying unit 11c estimates a function (details) from the time series of the CAN signals in each column of the identification result record table 13d0 using a pattern matching technique between the function estimation model 13c and the time series of the CAN signals in each column of the identification result record table 13d0. Note that if the function name (details) estimated from the time series of the CAN signals shown in the column of the identification result record table 13d0 differs from the function name (details) previously input in the identification result record table 13d0, the function name (details) is updated with the estimated function name (details).

[0083] Next, in step S14h, the operation function identification unit 11c calculates the degree of match of the CAN signal in the pattern matching between the function estimation model 13c and the time series of the CAN signal in step S14g, and inputs the calculated degree of match into the degree of match input field 13d3 of the identification result record table 13d0 corresponding to the time series and CAN signal name of the CAN signal.

[0084] Next, in step S14i, the operation function identification unit 11c rearranges the time series and CAN signal name columns of the identification result record table 13d0 in descending order of the degree of coincidence entered in the degree of coincidence input field 13d3 in step S14h.

[0085] Next, in step S14j, the operation function identifying unit 11c stores the final identification result record table 13d0 obtained through the processes up to step S14i as the identification result information 13d.

[0086] As described above, in the operation function identification process, the analysis table 13b0 in which "○" is entered is sorted in chronological order of the occurrence date and time, and identification result information 13d is generated that indicates the identification result of the correspondence between the time series pattern of the CAN signal and the function name (details).

[0087] Then, using the identification result information 13d and the function estimation model 13c, the function that was operating at the time when this time series pattern occurred is estimated based on the time series pattern generated from the analytical trace information 13a.

[0088] (Related information acquisition process according to the embodiment) FIG. 15 is a flowchart showing the related information acquisition process according to the embodiment.

[0089] First, in step S17a, the related information acquisition unit 11d refers to the identification result information 13d and determines whether there is a malfunction in the vehicle system being analyzed. A malfunction here means that there is a function name (details) in the identification result information 13d whose "degree of match" exceeds a threshold. If there is a malfunction in the vehicle system being analyzed (step S17a YES), the related information acquisition unit 11d proceeds to step S17b. On the other hand, if there is no malfunction in the vehicle system being analyzed (step S17a NO), the related information acquisition unit 11d ends the related information acquisition process.

[0090] Thereafter, steps S17b to S17f are repeated for all function names (details) determined to be defective in step S17a.

[0091] In step S17b, the related information acquiring unit 11d displays a user input screen (not shown) on the input / output unit 14. The user input screen (not shown) includes a pull-down menu or the like for selecting which of the design information and the inquiry destination related to the defect is to be displayed on the screen.

[0092] Next, in step S17c, the related information acquiring unit 11d accepts a selection by the user from a user input screen (not shown) of either the design information to be displayed on the screen or the inquiry destination.

[0093] Next, in step S17d, the related information acquisition unit 11d determines whether the input received in step S17c is design information. If it is design information, the related information acquisition unit 11d proceeds to step S17e, and if it is an inquiry destination, the related information acquisition unit 11d proceeds to step S17g.

[0094] In step S17e, the related information acquisition unit 11d searches for and acquires design information by referring to the PLM / ALMDB 2e based on the name (details) of the function determined to be defective in step S17a. That is, in step S17e, design information 2c of the vehicle 100 related to the estimated defective function is acquired from the PLM / ALMDB 2e.

[0095] Next, in step S17f, the related information acquisition unit 11d outputs the information acquired in step S17e or S17h from a display screen (not shown) displayed on the input / output unit .

[0096] Meanwhile, in step S17g, the related information acquisition unit 11d refers to the PLM / ALMDB 2e based on the function name (details) determined to be defective in step S17a, and searches for and acquires person in charge information (vendor, supplier, etc.). Next, in step S17h, the related information acquisition unit 11d refers to the contract information DB 2f based on the person in charge information acquired in step S17g, and acquires reference information (contact information) such as a telephone number and email address from the person in charge name, department name, etc. That is, in step S17h, referral information related to the function estimated to be defective is acquired from the contract information DB 2f.

[0097] (Application of the embodiment to Ethernet Frame) FIG. 16 is a diagram showing an Ethernet frame in which a CAN frame according to the embodiment is encapsulated.

[0098] In the above-described embodiment, the in-vehicle network to be analyzed is a CAN network, and the information transmitted and received (in-vehicle network information) is a CAN frame (CAN signal). However, this is not limiting, and the in-vehicle system network may be Ethernet (registered trademark (hereinafter the same)), and the information transmitted and received may be an Ethernet frame (Ethernet signal). In this case, one or more CAN frames are encapsulated in an Ethernet frame, as shown in FIG. 16.

[0099] The failure analysis support system 1 stores Ethernet frames as logs instead of the CAN transmission log 2a. The parsing processing unit 11a (Fig. 1) then decapsulates the stored Ethernet frames to extract the CAN frames. During decapsulation, the data field is extracted from the Ethernet frame, and the CAN frames are extracted one by one using the SOF / ITM fields of the CAN frame as a marker. The extracted CAN frames are parsed based on the DBC information 2b.

[0100] Furthermore, even if the network of the in-vehicle system is a system in which both a CAN network and an Ethernet are connected, the malfunction analysis support system 1 can process the CAN frames as in the embodiment and the Ethernet frames as described above, making them the subject of analysis.

[0101] (Effects of the embodiment) In the above-described embodiment, a function estimation model is used to estimate an in-vehicle function that was operating when a time series pattern of a CAN signal was generated, and the function is estimated based on a time series pattern generated from trace information of CAN signals transmitted and received from multiple ECUs via an in-vehicle network. Therefore, it is possible to present to the user which in-vehicle function was operating when the CAN signal was transmitted and received, and therefore it is possible to prioritize investigation of the parts related to the estimated in-vehicle function when a malfunction occurs, thereby improving the efficiency of investigating and responding to the malfunction.

[0102] In the above-described embodiment, when an in-vehicle function is estimated based on a time-series pattern, the in-vehicle function whose estimated likelihood is equal to or greater than a threshold is presented to the user via an output device as a candidate for the malfunction. This narrows down the in-vehicle functions estimated when a malfunction occurs to those with higher accuracy, enabling more efficient investigation and response to the malfunction.

[0103] In the above-described embodiment, vehicle design information or reference information related to the estimated on-board function is obtained from a predetermined database, and the obtained design information or reference information is presented to the user via an output device. This allows the user to quickly access information necessary for resolving the problem, enabling the problem to be resolved quickly. Furthermore, once the cause of the problem is identified, the user can smoothly refer to the design information necessary for analysis.

[0104] In the above-described embodiment, the in-vehicle functions operating in the vehicle are estimated based on the time series patterns of CAN signals generated using an analysis table having two axes, one for the function names of functions extracted from the vehicle design information and the other for the CAN signal names. Therefore, since the in-vehicle functions operating in the vehicle are estimated from time series patterns that cover all patterns, it is possible to identify the in-vehicle functions operating at the time of the malfunction even if the malfunction occurred due to an unexpected cause.

[0105] The present invention is not limited to the above-described embodiments, and includes various modifications. Furthermore, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those having all of the described configurations. Furthermore, not only are such configurations removed, but replacement or addition of configurations is also possible. Furthermore, embodiments of the present invention also include those in which some or all of the above-described embodiments are appropriately combined to be consistent. Furthermore, the order of execution of each step of the various processes in the above-described embodiments can be changed as long as the processing results are the same.

[0106] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The present invention can also be implemented by software program code that implements the functions of the embodiments. In this case, a recording medium on which the program code is recorded is provided to a computer, and a processor within the computer reads the program code stored in the recording medium.

[0107] In this case, the program code itself read from the recording medium will realize the functions of the above-described embodiment, and the program code itself and the recording medium on which it is stored constitute the present invention. Examples of recording media for supplying such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, etc.

[0108] Furthermore, the program code that realizes the functions described in this embodiment can be implemented in a wide range of program or script languages, such as Python (registered trademark), assembler, C / C++, perl, Shell, PHP, Java (registered trademark), etc.

[0109] In the above-described embodiment, the control lines and information lines are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. All components may be interconnected. [Explanation of symbols]

[0110] 1: Defect analysis support system, 11: Processor, 12: Memory

Claims

1. A fault analysis support system that supports analysis of a fault that occurs in a vehicle having a plurality of on-board components that are connected via an on-board network and perform functions, the failure analysis support system includes a processor and a memory, The processor: generating trace information of the in-vehicle network information, including a date and time of generation of the in-vehicle network information, from a log of the in-vehicle network information transmitted and received from the plurality of in-vehicle components via the in-vehicle network; generating a time series pattern of the in-vehicle network information from the trace information; Using a function estimation model that estimates the function that was operating in the vehicle when the time series pattern occurred, the function is estimated based on the time series pattern generated from the trace information. A defect analysis support system characterized by:

2. 2. The defect analysis support system according to claim 1, The processor: When estimating the function based on the time series pattern, calculating an estimated likelihood of the estimated function; The function for which the calculated estimated likelihood is equal to or greater than a threshold is presented to a user via an output device as a candidate function for which the malfunction has occurred. A defect analysis support system characterized by:

3. 2. The defect analysis support system according to claim 1, The processor: acquiring design information or reference information of the vehicle related to the estimated function from a predetermined database; The acquired design information or reference information is presented to the user via an output device. A defect analysis support system characterized by:

4. 2. The defect analysis support system according to claim 1, The processor: extracting, from the design information of the vehicle, function names of functions that operate in the vehicle and information names of the in-vehicle network information; generating an analysis table for each occurrence date and time, in which the function names are arranged in the column direction and the information names are arranged in the row direction; In the analysis table corresponding to the occurrence date and time corresponding to the trace information, a check mark is entered in a column of a row corresponding to the information name of the in-vehicle network information included in the trace information; generating identification result information indicating the identification result of the correspondence between the time series pattern of the in-vehicle network information and the function name by sorting the analysis table into which the check marks have been input in chronological order of the occurrence date and time; Using the function estimation model, the function that was operating in the vehicle when the time series pattern occurred is estimated based on the time series pattern in the identification result information. A defect analysis support system characterized by:

5. 2. The defect analysis support system according to claim 1, the in-vehicle network is a Controller Area Network (CAN, registered trademark) or an Ethernet (registered trademark), The in-vehicle network information is a CAN (registered trademark) signal or an Ethernet (registered trademark) signal. A defect analysis support system characterized by:

6. A failure analysis support method executed by a failure analysis support system that supports analysis of a failure that occurs in a vehicle having a plurality of on-board components that are connected via an on-board network and perform functions, comprising: generating trace information of the in-vehicle network information, including a date and time of generation of the in-vehicle network information, from a log of the in-vehicle network information transmitted and received from the plurality of in-vehicle components via the in-vehicle network; generating a time series pattern of the in-vehicle network information from the trace information; a step of estimating the function based on the time series pattern generated from the trace information, using a function estimation model that estimates the function that was operating in the vehicle when the time series pattern occurred; A defect analysis support method comprising:

Images