Failure analysis assistance system and failure analysis assistance method

Abstract

A failure analysis assistance system according to the present invention generates, from a log of in-vehicle network information transmitted and received from a plurality of in-vehicle components via an in-vehicle network, trace information of the in-vehicle network information including an occurrence date and time of the in-vehicle network information. The failure analysis assistance system then generates a time-series pattern of the in-vehicle network information from the trace information. By using a function estimation model that estimates a function that was in operation in the vehicle at the time at which the time-series pattern occurred, the failure analysis assistance system then estimates the function on the basis of the time-series pattern generated from the trace information.

Description

Fault analysis support system and fault analysis support method

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

[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] In this way, since the ECU operates in cooperation with other ECUs via the in-vehicle network, malfunctions related to the in-vehicle network or malfunctions that cannot be identified by 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.

[0005] Japanese Patent Application Laid-Open No. 2005-14743

[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 differences from the expected patterns. Therefore, in a situation where multiple ECUs from different vendors are mixed, only expected malfunctions (malfunctions that are easy to analyze) can be 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.

[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.

[0009] According to the present invention, for example, it is possible to further improve the accuracy of detecting malfunctions in an ECU.

[0010] 1 is a diagram showing the configuration of a failure analysis support system according to an embodiment. FIG. 1 is a diagram showing the configuration of analytical trace information according to an embodiment. FIG. 2 is a diagram showing the configuration of an analysis table according to an embodiment. FIG. 3 is a diagram showing the configuration of CAN signal definition information according to an embodiment. FIG. 4 is a diagram showing the configuration of matching result information according to an embodiment. FIG. 5 is a diagram showing the configuration of a identification result record table according to an embodiment. FIG. 6 is a diagram showing a state in which signal names are input into time slots in the identification result record table according to an embodiment. FIG. 7 is a diagram showing a function estimation model according to an embodiment. FIG. 8 is a diagram showing a function estimation model (with occurrence time) according to an embodiment. FIG. 9 is a diagram showing the configuration of identification result information according to an embodiment. A flowchart showing a failure analysis support process according to an embodiment. A flowchart showing a design information read process according to an embodiment. A flowchart showing a matching process according to an embodiment. A flowchart showing an operation function identification process according to an embodiment. A flowchart showing an inquiry destination / related specification information output process according to an embodiment. A diagram showing an Ethernet frame encapsulating a CAN frame according to an embodiment.

[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), 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 a malfunction analysis support system 1 according to an embodiment) Fig. 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 an ECU and a CAN (Controller Area Network, registered trademark (hereinafter the same)) installed in a target vehicle 100 (or a test environment simulating the vehicle 100) based on a CAN transmission log 2a acquired via a diagnostic machine 101 from the vehicle 100 (or a test environment simulating the vehicle 100) in which a plurality of ECUs (Electronic Control Units) are connected via a CAN 100.

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

[0019] The defect 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 memory 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 executing the programs, 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 11 a receives the CAN transmission log 2 a and the DBC information 2 b as input, parses the CAN transmission log 2 a based on the DBC information 2 b, generates analytical trace information 13 a, and stores the analytical trace information 13 a in the storage 13 .

[0025] The CAN transmission log 2a is a log of the CAN signal expressed in binary that is acquired from the vehicle 100 via the diagnostic device 101. The DBC information 2b is a conversion file for converting the 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 a single 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] The matching processing unit 11b then 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 (categories) and function names (details) extracted from the design documents, etc., into the portion of the analysis table 13b0 surrounded by dashed lines 13b1. In the example of FIG. 3, "autonomous driving function," "vehicle body control," etc. are function names (categories), 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," "brake control instruction reception," ....

[0031] CAN signal definition list information 2d is information that defines bit data within a 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, a 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, and identifies the "CAN signal name" based on the "CAN ID" by referring to the CAN signal definition list information 2d. The matching processing unit 11b then enters "○" in all columns of the rows corresponding to the identified "CAN signal name" in the analysis table 13b0. 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 Figure 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 are arranged horizontally as the number of function names (details) extracted from design documents, etc. In the identification result record table 13d0, the number of slots N in 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] The operation function identification unit 11c then 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 for 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] Note that if multiple "CAN signal names" belong to one time slot T, the "CAN signal name" with the most entries is input. Fig. 7 shows the identification result record table 13d0 in a state where "function name (details)" and "CAN signal name" have been input.

[0037] Then, the operation 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 the "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 a time series pattern of a CAN signal was generated. The degree of match is the percentage of times when the order of occurrence of the CAN signal and the time slot SLT in 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] 8, 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)." 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 "forward obstacle detection → distance detection → driver notification → engine inhibition → brake control signal transmission → meter display" (for Pre-crash brake 1). Also, if the "Function name (details)" is "Pre-crash brake," the CAN signal time sequence is "forward obstacle detection → distance detection → driver notification → brake control signal determination → brake control signal transmission → meter display" (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 identifying unit 11c calculates the degree of coincidence in pattern matching between the time series of CAN signals included in the function estimation model 13c and the time series of 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 FIG. 9A, 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 FIG. 9B, statistical values ​​of the occurrence time may be assigned to each CAN signal in the function estimation model 13c. The "function name (details)" is identified using the function estimation model 13c as follows: (1) The time series order of the input CAN signals is compared, and a matching function (function name (details)) is extracted (or the degree of matching is equal to or greater than a predetermined value). (2-1) If there is one matching function (function name (details)), the matching function (function name (details)) is output as the activated function. (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 in the function estimation model 13c is calculated, and the function with the smallest error is output as the activated function.

[0044] If the "function name (details)" entered in the identification result record 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 / ALM DB 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 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 of 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] 11 is a flowchart showing the failure analysis support process according to the embodiment. The failure analysis support process is triggered by a user instruction via an analysis instruction screen (not shown) displayed on the input / output unit 14 or at a predetermined interval, and performs matching between the design information 2c extracted from the PLM / ALM 2e and the analytical trace information 13a.

[0048] First, in step S11, the parsing processing unit 11a parses the CAN transmission log 2a based on the DBC information 2b, and generates analytical trace information 13a.

[0049] Next, in step S12, the matching processing unit 11b executes a design information read 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 specifying unit 11c executes an operation function specifying 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, and excludes from the identification result information 13d, among the CAN signal time series (operation functions) identified in step S14, CAN signal time series (operation functions) whose degree of match is less than a threshold.

[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 14.

[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 signals 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 Readout Process According to the Embodiment) FIG. 12 is a flowchart showing design information readout process according to the embodiment.

[0056] First, the matching processing unit 11b repeats steps S12a to S12e for the PLM / ALM DB 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 stores the information in the memory 12. Next, in step S12b, the matching processing unit 11b extracts function names (classifications) from the design information 2c stored in the memory 12. In step S12b, function names (classifications) or terms similar to function names (classifications) are extracted from the design documents, for example. Next, in step S12c, the matching processing unit 11b registers the function names (classifications) extracted in step S12b in the area surrounded by the 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 the 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, 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) Fig. 13 is a flowchart showing the matching process according to the embodiment. In the matching process according to the embodiment, the analytical trace information 13a and the 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 enters "x" in 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 entered 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 obtains a CAN signal name from the trace information read in step S13d. The CAN signal name is obtained by converting the CAN ID with reference to the CAN signal definition list information 2d. Next, in step S13f, the matching processing unit 11b obtains 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. After 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 signal based on the CAN ID 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 row in the analysis table 13b0 that corresponds 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 operation function identification process according to the embodiment.

[0075] First, in step S14a, the operation function specifying 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 allocates 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 specifying 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 specifying unit 11c repeats steps S14d to S14f for the matching result information 13b 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 specifying 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 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 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 CAN signals shown in a 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 of the CAN signal and the CAN signal name.

[0084] Next, in step S14i, the operation function identification unit 11c rearranges the columns of the CAN signal time series and CAN signal names in 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 specifying unit 11c stores the final specifying result record table 13d0 obtained through the processes up to step S14i as the specifying 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 indicating the identification result of the correspondence between the time series pattern of the CAN signal and the function name (details) is generated.

[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 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 the vehicle system being analyzed has a malfunction. A malfunction here refers to the presence of a function name (details) in the identification result information 13d whose "degree of match" exceeds a threshold. If the vehicle system being analyzed has a malfunction (YES in step S17a), the related information acquisition unit 11d proceeds to step S17b. On the other hand, if the vehicle system being analyzed does not have a malfunction (NO in step S17a), the related information acquisition unit 11d terminates 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 contact information related to the defect is to be displayed on the screen.

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

[0093] Next, in step S17d, the related information acquisition unit 11d determines whether the input received in step S17c is design information. If the input is design information, the related information acquisition unit 11d proceeds to step S17e, and if the input 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, the related information acquisition unit 11d acquires design information 2c of the vehicle 100 related to the function estimated to be defective 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 14.

[0096] Meanwhile, in step S17g, the related information acquisition unit 11d refers to the PLM / ALM DB 2e based on the function name (details) determined to be defective in step S17a, 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 Frames) 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. 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 field 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 defect analysis support system 1 can process the CAN frames as in the embodiment and the Ethernet frames as described above, thereby making them the subject of analysis.

[0101] In the above-described embodiment, a 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, using a function estimation model that estimates an in-vehicle function that was operating when a time series pattern of a CAN signal was generated. 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 location 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 the CAN signals generated using an analysis table having two axes, one for the function names 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 the time series patterns that cover all patterns, even if the malfunction occurs due to an unexpected cause, the in-vehicle functions that were operating when the malfunction occurred can be identified.

[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] In addition, 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.

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

Claims

1. A malfunction analysis support system that supports the analysis of malfunctions that occur in a vehicle equipped with multiple on-board components that are connected via an on-board network and perform functions, the malfunction analysis support system having a processor and memory, wherein the processor generates trace information of on-board network information, including the 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 multiple on-board components via the on-board network, generates a time series pattern of the on-board network information from the trace information, and uses a function estimation model that estimates the function that was operating in the vehicle when the time series pattern occurred, to estimate the function based on the time series pattern generated from the trace information.

2. A fault analysis support system as described in claim 1, wherein the processor, when estimating the function based on the time series pattern, calculates an estimated likelihood of the estimated function, and presents the function whose calculated estimated likelihood is equal to or greater than a threshold value to the user via an output device as a candidate for the function in which the fault has occurred.

3. A defect analysis support system as described in claim 1, characterized in that the processor acquires design information or reference information of the vehicle related to the estimated function from a predetermined database, and presents the acquired design information or reference information to a user via an output device.

4. A fault analysis support system as described in claim 1, wherein the processor: extracts, from the design information of the vehicle, the function names of functions operating in the vehicle and the information names of the in-vehicle network information; generates, for each of the occurrence dates and times, an analysis table in which the function names are arranged in columns and the information names are arranged in rows; enters a check mark in the column of the row corresponding to the occurrence date and time corresponding to the trace information, corresponding to the in-vehicle network information included in the trace information; sorts the analysis tables with the check marks entered in chronological order of the occurrence dates and times, thereby 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; and uses the function estimation model to estimate the function that was operating in the vehicle when the time series pattern occurred based on the time series pattern in the identification result information.

5. A fault analysis support system as described in claim 1, characterized in that the in-vehicle network is a CAN (Controller Area Network, registered trademark) or an Ethernet (registered trademark), and the in-vehicle network information is a CAN (registered trademark) signal or an Ethernet (registered trademark) signal.

6. A failure analysis support method executed by a failure analysis support system that supports the analysis of failures that occur in a vehicle equipped with a plurality of on-board components that are connected via an on-board network and perform functions, comprising the steps of: generating trace information of on-board network information, including the 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; generating a time series pattern of the on-board network information from the trace information; and using a function estimation model that estimates the function that was operating in the vehicle when the time series pattern occurred, estimating the function based on the time series pattern generated from the trace information.

Images