Analysis system for a fault in a vehicle, and related analysis method

Abstract

Analysis system (5) for analyzing a fault in a vehicle (10), comprising: the vehicle (10), with a control unit (20) and a data acquisition module (12) comprising sensors (141…, 14i,… 14N) and components (161…, 16j,… 16M); and an analysis control unit (30). The control unit (20) is configured to: receive detection data from the sensors (141…, 14i,… 14N) and from the components (161…, 16j,… 16M); and based on the detection data, generate one or more DTCs. The analysis control unit (30) or the control unit (20) is configured to: verify a belonging category condition of the one or more DTCs by choosing from a plurality of predefined belonging categories; verify an identification category condition of the one or more DTCs by choosing from a plurality of predefined identification categories; verify an action condition of the one or more DTCs by choosing from a plurality of predefined repair actions usable to repair the fault; and generate an action signal indicative of the repair action to be performed to repair the fault, possibly also providing the indication of the success probability of the repair action.

Description

[0001] "ANALYSIS SYSTEM FOR A FAULT IN A VEHICLE , AND RELATED

[0002] ANALYSIS METHOD"

[0003] Cross-Reference to Related Applications

[0004] This Patent Application claims priority from Italian Patent Application No . 102024000000414 filed on January 11 , 2024 , the entire disclosure of which is incorporated herein by reference .

[0005] Technical Field

[0006] The present invention relates to an analysis system for a fault in a vehicle , and related analysis method . Furthermore , it relates to an analysis control unit configured to perform the analysis method .

[0007] The present invention is preferably, although not exclusively, applied to the search of the fault in engine applications of industrial type , for example equipped with diesel engines , engines fed with methane or propulsion systems of electrical type . In the following, reference will be made to such application by way of example .

[0008] State of the Prior Art

[0009] Industrial propulsion systems are designed to be diagnosed by various actors and with various diagnostic tools .

[0010] The most common case is that of the diagnosis carried out by a software present in an electronic control unit (ECU) of the vehicle , which codes the fault events based on suitable diagnostic trouble codes ( DTCs ) . For example , this is done by means of an onboard diagnostics ( OBD) system present in the ECU .

[0011] Consequently, a real fault event is recogni zed, coded and thus registered as diagnostic event . Generally, the diagnosis is carried out in the ECU, which is one of the most powerful diagnostics means on board of vehicles .

[0012] In the mentioned case , the ECU memory can be consulted by the technicians , in the authori zed repair shops for example , by means of its connection with speci f ic tools capable of reading what previously occurred, and thus what coded and registered as fault code . The ECU memory can also be consulted by the technicians remotely, namely with telematics techniques made possible by speci fic remote data- reading devices and by digital infrastructures which allow processing large quantities of data quickly and with high resolution .

[0013] A real (physical , chemical or electrical , for example ) event has , in general , properties that , by means of a more or less complex series of criteria and logics written in the ECU software , de fine a diagnostic equivalent thereof , of which the number, the type , the seriousness and di f ferent other attributions are generally defined .

[0014] These properties obviously depend on the class of the engine application under examination . It is evident that a very simple system can be managed and diagnosed by a j ust as simple control system and, vice versa, that a complex system is managed through a measurement and control chain based on a high number of sensors , actuators , global and local intelligences and a software with more complex logics .

[0015] Starting from the logics underlying the operation of the propulsion system and from those that allow the diagnostics thereof , in the state of the art there are di f ferent solutions which have the obj ect to filter, process and obtain an added value from the available information . Such added value aims at increasing the descriptive capabilities of the diagnostic events , ideally tending to the characteri zation of the real event of which the diagnostic one is only the token . Defining the " fault mechanism" as the set of the conditions that characteri ze a fault , namely the evolution of (physical , chemical or electrical , for example ) parameters up to the real fault event and also comprising it , it is legitimate to think that being able to have a high number of encodings available , namely a high number of diagnostic events for the same fault mechanism, allows a high-resolution diagnosis , in one word, an ef fective diagnosis .

[0016] However, in an ECU the diagnostics is defined via a finite number of DTCs , and also the number of further analysis means which can be implemented inside or outside the ECU is reasonably limited, in a manner evident per se . The state of the art accepts di f ferent examples of interaction between the encodings of the faults in ECU and these further analysis means , and also in these cases it is a limited number of interactions between a number of interacting elements which is also limited .

[0017] The diagnostics thus has the character of being a limited system, measurable and quanti fiable where the reality is complex and operates on a system of variables which is not illimited but certainly much greater in number and complexity .

[0018] The known generic diagnostic system is a highly integrated system, containing within itsel f di f ferent aspects , among the main ones : the description of the diagnostic events , the potential association with a fault mechanism, the indication of the possible causes that individually or synergistically can produce that fault mechanism, the guidance to a test phase for veri fying the potential fault mechanism and thus the individual or multiple causes of such fault mechanism, the indication of the repair to be carried out for restoring the monitoring condition of the diagnostic system starting from that of active noti fication of the fault or rather of a fault token in the ECU .

[0019] The state of the art encompasses di f ferent examples of processes and methods , hardware and software , aimed at making ef ficient one or more of the main aspects of a diagnostic system, such as for example the indication of the possible causes that can produce a speci fic fault mechanism and the indication of the repair to be carried out .

[0020] The search of the root cause of a problem related to a propulsor, very often is identi f ied as the search of the main component or subcomponent which results to be af fected by a fault based on a token in ECU or in one of the above- mentioned analysis means . A component generally results to be formed by one or more mechanical and mechatronic parts based on the class of the component . A component or system is generally achieved by the diagnostic system by means of the measurement and control chain and then by means of controllers and calculation models in ECU or which dialogue with the ECU .

[0021] The root cause can be dif ficult to reproduce and therefore the same fault mechanism results to be di f ficult to reproduce . As a consequence thereof , also the diagnostic event can be di fficult to detect during a veri fication of the health status of the engine . This means that in the search of the root cause , one very often stops at the most likely hypothesis that it was possible to veri fy . The definition of the root cause thus occurs with a certain level of uncertainty . The repair technique put into practice , similarly, bears an uncertainty with it which can be said to be equivalent to or even greater than that of the detection of the root cause , since a repair technique can have several root causes . The level of generality increases when the diagnostic events associated with a fault mechanism are more than one and when the components potentially involved in the fault mechanism are more than one and are located in di f ferent areas of the system to be diagnosed .

[0022] In general , such known systems currently have problems that translate into limitations to the obtainable detection performance .

[0023] A first problem relates to the fact that many of the processing operations are based on the diagnostic events and more typically on the trouble codes or DTCs , which are however analyzed by means of techniques and logics that do not take into account the physical nature of the individual (physical , chemical , electrical etc . ) parameters which are indicative of the fault . Even when the fault codes are associated with a more or less complex series of algorithms involving the aforementioned parameters , the problem of the signi ficance of the interactions between these two approaches remains . It is in fact easy to understand that di f ferent inertias come into play, some typical of the sensors , controllers and calculation models and others typical of the logics and activation times underlying the DTCs .

[0024] A second problem relates to the fact that many processing operations require test actions and veri fy whether a negative feedback is obtained ( i . e . whether the validation of the root cause fails ) . Consequently, they result in an iterative process of trials and tests that do not lead to a univocal repair solution .

[0025] This means that in the complex case of a fault mechanism involving di f ferent elements dislocated along the measurement and control chain of the engine , which have di f ferent inertias and di f ferent operating principles , di f ferent known techniques for searching the fault could be put into practice without finding anomalies despite a fault token has been registered . The risk of a new onset of the fault would thus remain consistent when the vehicle is given back to the owner for resuming the normal activity .

[0026] A third problem relates to the fact that many processing operations of the diagnostic system aim at searching the fault and not at searching the root cause . This means that once the fault has been identi fied, thanks to the speci fic search technique used, and once the repair has been carried out , which anyway has a certain level of uncertainty, the possibility to continue searching the root cause is lost . In fact , although the system under observation after the repair is di f ferent from the original one , a new fault occurrence could anyway bring with it other factors ( e . g . introduced with the repairs carried out , with the further aging of the system, or with other phenomena ) which confuse and at worst totally invalidate the search of the root cause .

[0027] Document DE 10 2020 107367 B4 relates to a method for providing error data for a motor vehicle , a database device , a motor vehicle control device and a system made up of both .

[0028] The need is thus felt to overcome the disadvantages described so far, in particular for minimizing the uncertainty of the repair techniques and maximi zing the ef ficiency thereof .

[0029] The obj ect of the present invention is to satis fy the needs set forth above .

[0030] Summary of the Invention

[0031] The aforementioned obj ect is achieved by an analysis system for a fault in a vehicle , an analysis method and an analysis control unit configured to perform the analysis method, as claimed in the appended claims .

[0032] Brief Description of the Drawings

[0033] In order to better understand the present invention, a preferred embodiment is described in the following, by way of non-limiting example and with reference to the accompanying drawings wherein :

[0034] • Figure 1 is a block diagram which schematically shows an analysis system, according to an embodiment of the present invention;

[0035] • Figure 2 is a block diagram which schematically shows an analysis method performed by the analysis system, according to an embodiment of the present invention; and

[0036] • Figures 3A-3C are tables which show correlations between quantities that are used in the analysis method, according to an exempli fying embodiment of the present invention .

[0037] In the following, elements common to the various embodiments are indicated by the same reference numerals .

[0038] Detailed Description of the Invention

[0039] Figure 1 shows an analysis system 5 comprising a vehicle 10 , such as a heavy vehicle or a work vehicle ( e . g . tractor ) .

[0040] The analysis system 5 is configured to analyze a fault of the vehicle 10 and to provide a piece of information related to the most suitable repair action to be adopted for resolving the fault.

[0041] The vehicle 10 comprises a data acquisition module 12 comprising a plurality of sensors 14i..., 14i,... 14N and a plurality of components (or subsystems) 16i..., 16 j , ... 16M. The sensors 14i..., 14i,... 14N and the components 16i..., 16j, ... 16M are comprised in the vehicle 10 and are of known type.

[0042] In detail, the sensors 14i..., 14i,... 14N and the components 16i..., 16 □ , ... 16M are elements or subsystems of the vehicle 10 which, during the use of the vehicle 10, can become faulty or be indicative of faults of other elements or subsystems of the vehicle 10.

[0043] In other words, the sensors 14i..., 14i,... 14N and the components 16i..., 16 j , ... 16M generate in use respective detection data indicative of their operation and / or of the operation of other sensors 14i..., 14i,... 14N and / or components

[0044] 161..., 16 j , ... 16M of the vehicle 10.

[0045] For example, the detection data comprise electric signals generated by the sensors 14i..., 14i,... 14N and indicative of the measurements carried out by the sensors

[0046] 141..., 14i,... 14N, and electric signals generated by the components 16i..., 16 j , ... 16M and indicative of their operation or of the operation of other sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M of the vehicle 10, operatively coupled to the considered component 16 j .

[0047] According to an exemplifying and non-limiting embodiment, the sensors 14i..., 14i,... 14N can comprise pressure sensors, temperature sensors, rotation sensors, acceleration sensors, chemical sensors that namely detect the presence and / or concentration of chemical species, sensors that detect the management of the injection system or the quality of the combustion, virtual sensors based on a calibrated model in an electronic control unit of the vehicle 10 which operates through algorithms starting from values coming from other sensors or from other models, etc., and the components 16i..., 1 j , ... 16M can comprise an engine, an exhaust gas treatment system, a transmission system and a series of auxiliaries typically mounted on the vehicle 10, such as for example those that allow managing the stocking of the fuel in the vehicles fed for example with natural gas, or also parts of these mentioned components (e.g. a turbine and a supercharger, injectors and an injection pump, a urea dosing pump, elements of the electronic control unit of the vehicle 10, an exhaust gas recirculation valve, etc.) . It is anyway evident that other types of sensors 14i..., 14i,... 14N and components 16i..., 16 j , ... 16M can similarly be considered, in place of or in addition to the ones described herein.

[0048] The data acquisition module 12 is thus configured to acquire the detection data from the sensors 14i..., 14i,... 14N and from the components 16i..., 16 j , ... 16M.

[0049] Optionally and in a manner not shown, the data acquisition module 12 can also comprise an interface unit configured to pre-process the detection data in a manner known per se (e.g. amplify the signals, filter them, etc.) , for the purpose of making them available for following processing operations.

[0050] The vehicle 10 further comprises a control unit 20 operatively coupled to the data acquisition module 12 and thus to the sensors 14i..., 14i,... 14N and to the components 16i... , 16 j , ... 16M •

[0051] In detail, the control unit 10 is an electronic control unit (ECU) of the vehicle 10. In greater detail and in a manner not shown, the ECU comprises an onboard diagnostics (OBD) system which is configured to perform a part of the fault analysis better described in the following.

[0052] Furthermore, the analysis system 5 comprises an analysis control unit 30 operatively coupled to the vehicle 10 and in detail to the control unit 20. The analysis control unit 30 is a control unit of electronic type configured to perform a remaining part of the fault analysis better described in the following.

[0053] In detail, the analysis control unit 30 is an electronic data processing unit, such as a dedicated electronic unit, a processor, a telematic device, etc.

[0054] By way of example and as is shown in Figure 1, the analysis control unit 30 can be comprised in a repair equipment 40 with which a repair technician (also called user) , in charge of repairing the fault in the vehicle 10, is provided.

[0055] In use, the control unit 20 and the analysis control unit 30 implement an analysis method 50, shown in Figure 2, for detecting the fault (and thus the malfunction) of one or more of the sensors 14i..., 14i,... 14N and / or of the components 16i..., 1 j , ... 16M of the vehicle 10.

[0056] In the following, only one iteration of the analysis method 50 is described by way of example, nonetheless it is evident that the steps described herein can be repeated over time (e.g. periodically) so as to perform a continuous analysis or at least an analysis repeated over time.

[0057] Alternatively, the analysis method 50 can be performed upon request of the repair technician.

[0058] In detail, at a step SOI of the analysis method 50, the control unit 20 receives the detection data from the data acquisition module 12.

[0059] In particular, the detection data are generated in real time. The control unit 20 can store them in a storing unit of its own (not shown and for example a volatile memory) , so that both the detection data acquired at the current time instant (e.g. corresponding to the current iteration) and the passed detection data (i.e. the detection data acquired at time instants that precede the current time instant) are available. This also allows performing the analysis method 50 deferred with respect to the acquisition of the detection data, i.e. not in real time; in this case, when the analysis method 50 is performed, the detection data to be used in the following steps are already stored and thus available.

[0060] At a step S03 consecutive to step SOI, the control unit 20, based on the received detection data and in case of malfunction of one or more of the sensors 14i..., 14i,... 14N and / or of the components 16i..., 16j, ... 16M, generates one or more diagnostic trouble codes (DTCs) indicative of this malfunction. The processing of the detection data and the consequent generation of the DTCs, if necessary, occur in a manner known per se and thus are not described in detail herein .

[0061] In particular, each DTC codes the occurrence of a respective fault of one or more of the sensors 14i..., 14i,... 14N and / or of the components 16i..., 16 j , ... 16M, and thus of a malfunction of the one or more of the sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M under examination. In detail, the DTC is a code (e.g. a data string) of known type which is indicative of a fault in one or more of the sensors 14i..., 14i,... 14N and / or of the components 16i..., 16 j , ... 16M.

[0062] In the following, for the sake of description simplicity, the exemplifying case is considered in which only one DTC is present, indicative of the fault of only one of the sensors 14i..., 14i,... 14N or the components 16i..., 16 j , ... 16M. Nonetheless, it is evident that the cases in which only one DTC is indicative of the fault of more sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M, can be similarly considered, as well as the case in which more DTCs are simultaneously present.

[0063] In detail, the case in which a fault is actually present and thus a corresponding DTC is generated is considered herein. In the opposite case and as is evident per se, the following steps are not performed and the current iteration ends, because there are no faults to be analyzed.

[0064] The DTC generated by the control unit 20 is thus sent to the analysis control unit 30, which deals with performing the remaining steps of the analysis method 50 based on the received DTC.

[0065] At a step S05 consecutive to step S03, the analysis control unit 30 verifies a belonging category condition of the detected DTC, i.e. determines to which among a plurality of predefined belonging categories the DTC belongs. The predefined belonging categories are indicative of respective belonging categories possible for the DTC, i.e. correspond to respective classifications, each grouping a respective plurality of DTCs.

[0066] According to an exemplifying and non-limiting embodiment, the predefined belonging categories can comprise a plurality of the following categories: electrical category; out-of-limits category; plausibility category; and initialization category. Nonetheless, it is evident that other categories can be similarly considered, in place of or in addition to the categories mentioned herein.

[0067] In detail, the electrical category comprises the DTCs that are generated when one or more activation criteria (or conditions) indicative of anomalies in the measurement of a parameter of electrical type (voltage, current, resistance, etc.) are detected in the detection data. In detail, the DTCs corresponding to anomalies of electrical type, i.e. related to parameters directly indicative of electrical quantities, can be part of this category; in other words, the DTCs related to measurements of parameters that are not of electrical type and in which only the output signal indicative of the measurement carried out is of electrical type (e.g. a sensor which measures a non-electrical quantity, e.g. a pressure, and generates at the output an electric signal corresponding to the measurement carried out) are not part of this category. For example, the DTC belongs to the electrical category if it is generated in response to the fact that the detection data coming from one of the sensors 14i..., 14i,... 14N or components 16i..., 16 j , ... 16M are indicative of a short circuit (or, alternatively, of an open circuit) in the corresponding sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M (e.g. the short circuit of a temperature sensor of the winding of the electromagnet of an actuator for the blades of a turbine with a variable geometry, of the electrical motor of an exhaust gas recirculation valve, etc . ) .

[0068] The out-of-limits category comprises the DTCs that are generated when one or more comparison criteria (or conditions) are detected in the detection data, indicative of anomalies relative to respective (predefined) limit reference values that define, for each detection datum, a respective maximum limit variation range that the detection datum can assume for being considered indicative of a correct operation. In other words, considering a specific sensor

[0069] 14i,... 14N or component 16i..., 16 j , ... 16M and thus a specific detection datum, there is a DTC belonging to the out-of-limits category if the detection datum is not comprised in the maximum limit variation range which is predefined and specific for the considered sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M and which is indicative of the correct operation of the respective sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M. In detail, the maximum limit variation range for the detection datum of each sensor 14i...,

[0070] 141.... 14N or component 16i..., 16j,... 16M is defined regardless of the operation or of the influence of the other sensors

[0071] 141..., 14i,... 14N and / or components 16i..., 16 j , ... 16M. By way of example, the maximum limit variation range for the detection datum of each sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M corresponds to a maximum variation range established at datasheet level for the specific sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M, or to a limit operating range which can be monitored and diagnosed in both or only one of the extremes defining a limit activation threshold which can be different from the limit datasheet one (and thus constructive limit) . For example, considering the case of a pressure sensor, there is a DTC in the out-of-limits category when the measurement of the pressure sensor exceeds a limit reference value (in detail, the minimum or the maximum measurable pressure value established by datasheet, or a similar limit value of correct operation different from the minimum or maximum measurable pressure value established by datasheet) and which can be defined as extremal value that the pressure measurement can assume when indicative of the correct operation of the components 16i..., 16 j , ... 1 6M or of the system that the sensor 14i..., 14i, ... 14N is called to monitor and when considered in isolation from the measurements and operations of the other sensors 14i..., 14i, ... 14N or components 16i... , 16 j , ... 16M •

[0072] The plausibility category comprises the DTCs that are generated when one or more comparison criteria ( or conditions ) are detected in the detection data, indicative of anomalies relative to respective (predefined) plausibility reference values that are defined taking into account the interactions and correlations existing among the di f ferent sensors 14i..., 14i, ... 14N and / or the di f ferent components 16i..., 16 j , ... 1 6M . In detail , the plausibility reference values are defined, for example at the level of the analysis control unit 30 , according to statistical analyses based on high measurement numbers and identi fy plausible limits of the values of the detection data when the sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M are considered in a crossed manner . In greater detail , a DTC belongs to the plausibility category when anomalies are present in a plurality of distinct detection data ( i . e . anomalies coming from di f ferent sensors 14i..., 14i, ... 14N or components 16i..., 16 j , ... 1 6M) which are known for being correlated with one another ( for example , because the respective sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M are operatively connected to one another such that their measurements result to be correlated) . For example , considering the case of a pressure sensor and of a temperature sensor which are coupled to the same component of the vehicle 10 and which provide at the output pressure measurements and temperature measurements , respectively, correlated with the operation of this component , there is a DTC in the plausibility category when the measurements of the pressure sensor and of the temperature sensor exceed respective plausibility reference values which are defined not based on the extremal values that the pressure and temperature measurements could assume i f considered in isolation, but rather based on extremal values that the pressure and temperature measurements simultaneously and in a combined manner must not exceed so as to continue being plausible . For example , in the considered exempli fying case , there is a DTC when the measurements of the pressure sensor and of the temperature sensor are incompatible with each other ( e . g . because , when considered individually, they result to be indicative of operating states of the component of the vehicle 10 which are di f ferent with respect to one another ) .

[0073] Generally, the plausibility reference values define for each detection datum a maximum plausibility variation range that is di f ferent from the respective maximum limit variation range or value used for the out-of-limits category ( e . g . that is comprised in, and narrower than, the maximum limit variation range ) . Furthermore , the plausibility reference values are not uniquely defined based on the considered sensor 14i..., 14i, ... 14N or component 16i..., 16 j , ... 1 6M ( as instead it occurs for the corresponding limit reference values of the out-of-limits category) but rather vary as a function of each possible combination of the considered sensor 14i..., 14i, ... 14N or component 16i..., 16j , ... 1 6M with the remaining sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M operatively coupled to it . For example , therefore , the same pressure sensor can have plausibility reference values that are different from one another in the case where it is considered associated with the previously mentioned temperature sensor or in the case where it is considered associated with a further sensor (e.g. acceleration sensor) also coupled to the previously mentioned component of the vehicle 10.

[0074] The initialization category comprises the DTCs that are generated when in the detection data, acquired in an initialization phase of the considered sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M, one or more initialization criteria (or conditions) are detected indicative of anomalies related to exceeding deviations of the trend over time of the respective detection datum relative to an initialization pattern. In other words, generally the considered sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M is initialized by means of an initialization procedure before being actually used. During this initialization procedure (which can comprise the execution of a sequence of predefined actions, such as specific movements and rotations of the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M etc.) , the respective detection datum should have an initialization pattern which is predefined (e.g. stored in the analysis control unit 30) and depends on the specific initialization procedure (i.e. corresponds to the trend over time of the detection datum when the correctly operating sensor 14i..., 14i,... 14N or component 16i..., 16j, ... 16M is subjected to the initialization procedure) . If the detection datum during the initialization procedure exceedingly deviates from the initialization pattern, this means that the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M has not been correctly initialized and / or is not correctly operating. In this case, a DTC belonging to the initialization category is generated. This exceeding deviation can be defined in a manner obvious per se, for example there is an exceeding deviation when the detection datum during the initialization procedure and the initialization pattern have, at least at a time instant, a relative difference greater than a threshold difference (e.g. equal to 10% of the value at that time instant of the initialization pattern) .

[0075] At a step S07 consecutive to step S05, the analysis control unit 30 verifies an identification condition of the detected DTC, i.e. determines to which among a plurality of predefined identification categories the DTC belongs. The predefined identification categories are indicative of respective possible identification categories for the DTC and correspond to respective classifications based on the fact that the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that gave origin to the DTC is or is not the actually faulty one.

[0076] According to an exemplifying and non-limiting embodiment, the predefined identification categories can comprise the following categories: component category; and system category. Nonetheless, it is evident that other categories can be similarly considered, in place of or in addition to the categories mentioned herein.

[0077] In detail, the component category comprises the DTCs that are generated by sensors 14i..., 14i,... 14N or components 16i..., 16 j , ... 16M which are actually faulty. In other words, if a sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M gives origin to a DTC because it is itself faulty, then the DTC belongs to the component category. For example, if an element of the engine of the vehicle 10 is faulty and thus generates a detection datum that causes the generation of a DTC, this DTC belongs to the component category .

[0078] The system category instead comprises the DTCs that are generated by sensors 14i..., 14i, ... 14N or components 16i..., 16 j , ... 1 6M that are not actually faulty but that are operatively coupled to other sensors 14i..., 14i, ... 14N and / or components

[0079] 161..., 16 j , ... 1 6M that are faulty . In other words , i f a sensor

[0080] 141..., 14i, ... 14N or component 16i..., 16 j , ... 1 6M gives origin to a DTC because , although operating correctly, it is operatively correlated to another sensor 14i..., 14i, ... 14N or component 16i..., 16 j , ... 1 6M which instead is faulty and thus its measurement is influenced by the mal function of the sensor 14i..., 14i, ... 14N or component 16i..., 16 j , ... 1 6M coupled to it , then the DTC belongs to the system category . For example , i f a correctly operating pressure sensor is operatively coupled to a faulty element of the engine of the vehicle 10 and generates a detection datum indicative of the mal function of the faulty element , the corresponding DTC belongs to the system category .

[0081] In particular, the determination of the identi fication category occurs based on the sensor 14i..., 14i , ... 14N or component 16i..., 16 j , ... 1 6M that generates the DTC and based on the knowledge of the correlations in the operation among the various sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M ( known in the design phase of the vehicle 10 ) . Furthermore , the determination of the identi fication category occurs based on the belonging category determined at step S 05 .

[0082] In detail , based on the determined belonging category and as a function of the correlations in the operation among the various sensors 14i..., 14i, ... 1 4N and / or components 16i..., 16 j , ... 1 6M, it is possible to know whether the sensor 14i..., 14i, ... 14N or component 16i..., 16 j , ... 1 6M that generates the DTC is the one actually faulty ( component category) or is indicative of the fault of another sensor 14i..., 14i, ... 14N or component 16i..., 16 j , ... 16M( system category) .

[0083] Optionally, in case of more DTCs simultaneously present for di f ferent sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M, also the simultaneous analysis and the comparison among these DTCs can be used for choosing between the component category and the system category . Normally, the simultaneous presence of more DTCs is an indication of the belonging of these DTCs to the system category; this assumption is then confirmed i f the sensors 14i..., 14i, ... 14N and / or components 16i..., 16 j , ... 1 6M that generated these DTCs are operatively coupled and for example are correlated to the operation of a speci fic ( faulty) element of the vehicle 10 .

[0084] At a step S 09 consecutive to step S 07 , the analysis control unit 30 veri fies an action condition for the detected DTC, i . e . determines which among a plurality of possible actions is to be performed in response to the detected DTC . In particular, the actions mentioned herein are monitoring, test and / or repair actions and for example are performed by quali fied technical personnel ( e . g . the repair technician that has to repair the vehicle 10 and has access to the information of the DTCs ) .

[0085] The action condition is determined based on the belonging category of the DTC, on the identi fication category of the DTC and based on the correlations in the operation among the various sensors 14i..., 14i, ... 14N and / or components 161..., 1 j , ... 16M of the vehicle 10 (in other words, it is determined based on the logic of the DTC) . Optionally, in case of more DTCs simultaneously present for different sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M, also the simultaneous analysis and the comparison among these DTCs can be used for determining the action to be performed.

[0086] According to an exemplifying and non-limiting embodiment, the possible actions are the following: verification action; verification and replacement action; replacement action. Nonetheless, it is evident that other actions can be similarly considered, in place of or in addition to the categories mentioned herein.

[0087] In detail, the verification action (or test action) is indicative of the need to perform in-depth analyses on the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that generated the considered DTC, or also on the vehicle 10 in general and thus on at least one part of the other sensors

[0088] 141..., 14i,... 14N or components 16i..., 16 j , ... 16M. For example, these analyses are of known type and allow the repair technician to better examine the real fault at the basis of the DTC for possibly assessing further actions to be performed. Unlike the known cases, the information inferable from the belonging category of the DTC and from the identification category of the DTC allow performing a much more specific and aimed verification relative to the considered DTC, thus allowing a saving with regard to the costs and the time required for the repair.

[0089] The replacement action is indicative of the need to replace the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that the considered DTC communicated (if the DTC belongs to the component category) , or another sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that is operatively coupled to the sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that the considered DTC communicated (if the DTC belongs to the system category) .

[0090] The verification and replacement action is indicative of the need to perform both the verification action and the replacement action (e.g. first the verification and then, based on the result of the verification, a more aimed replacement) .

[0091] At a step Sil consecutive to step S09, the analysis control unit 30 generates an action signal, indicative of the action to be performed determined at step S09, and also a success probability signal.

[0092] In detail, the success probability signal is indicative of the probability that the action chosen in response to the examined DTC actually resolves the detected fault. This success probability is calculated by the analysis control unit 30 based on respective replacement success probabilities of the sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M (e.g. determined in a statistical manner in design phase of a given algorithm and stored in the analysis control unit 30) , in particular also taking into account, as input, the belonging category of the DTC, the identification category of the DTC and the correlations in the operation among the various sensors 14i..., 14i,... 14N and / or components 16i..., 16 j , ... 16M of the vehicle 10. For example, the success probability in the replacement of a sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 16M that refers to a DTC of electrical type and of the component category for which only electrical continuity tests are suggested is higher than the success probability in the replacement of a sensor 14i..., 14i,... 14N or component 16i..., 16 j , ... 1 6M that refers to a DTC of plausibility type , for which di f ferent functional trials and only as a last resort the replacement are suggested, and of the system category .

[0093] Consequently, at step S i l this success probability is calculated and a corresponding success probability signal is generated .

[0094] Furthermore , the calculated success probability can also be used for assessing, in case o f more actions available for the same DTC, which of these actions to choose . In fact , in the case of more actions available for the same DTC, it is possible to choose the action associated with the greater success probability . In this manner, the repair by the repair technician is further simpli fied and optimi zed .

[0095] For example , the information carried by the action and success probability signals are provided to the repair technician by means of a suitable graphic and / or sound interface of the analysis system 5 , for example being part of the repair equipment 40 of which the repair technician is provided and shown in Figure 1 by reference numeral 35 .

[0096] In particular, the action and success probability signals can be respective electric signals emitted by the analysis control unit 30 and for example sent to the graphic and / or sound interface 35 , so that the respective information can be provided to the repair technician by means of corresponding visual or auditory signals .

[0097] In general , therefore , the analysis method 50 al lows associating each DTC with the possible belonging category conditions , the possible identification category conditions and the possible repair / replacement actions , as well as calculating the success probability indicative of the residual risk .

[0098] In other words , it is possible to define a matrix that comprises a DTC vector, a belonging category vector, an identi fication category vector and an action vector . This matrix is thus indicative of all the possible combinations of these elements . For example , this matrix is stored in the analysis control unit 30 and is consulted when the DTC has to be analyzed, making the identi fication of the replacement to be carried out quick and simple .

[0099] For example , Figure 3A shows side by side the DTC vector and the belonging category vector, Figure 3B shows side by side the DTC vector and the identi fication category vector, and Figure 3C shows side by side the DTC vector and the action vector . As it can be noted, each DTC can be associated with one or more possible belonging categories , one or more possible identi fication categories and one or more possible actions , from which to choose during the execution of the analysis method 50 .

[0100] Based on the foregoing, the advantages of the present solution are evident .

[0101] In particular, the analysis method 50 takes into account what is present in the control unit 20 as token of a real fault and provides an indication in the search of the fault without requiring a continuous observation of parameters during a validation test . This allows working by observing the diagnostic events at discrete ranges ( i . e . the DTCs , without the need to examine in detail the trend over time of the detection data ) and to make an ef ficient characteri zation thereof in relation to the most probable fault mechanism and thus to the most probable root cause , i . e . to the repair with the least residual risk . In the practical case of most interest of an industrial application af fected by a mal function that prevents the operation thereof , and in the need of a reduced restoration time , the analysis method 50 produces information that suggests a repair in real time with the highest probability of removing the host of the root cause . The analysi s method 50 also allows being quantitatively aware of the residual risk of unsuccess linked to the repair carried out .

[0102] In detail , the present solution allows implementing a zero setting of the time line ( i . e . operates at null time ) . This means that it is based on algorithms , such as for example calculation or definition algorithms , which do not consider the time evolution of the detection data but are rather defined based on relations composing the diagnostic system defined based on DTCs , i . e . relations linked to the proj ect of the diagnostic system . The evolution over time of the diagnostic events is not determined actually following the time evolution of every parameter or derived quantity ( analysis which would be very costly from a computational point of view) , but rather considering the onset of the DTCs at discrete ranges ( analysis which is less costly from a computational point of view) .

[0103] In response to the previously described problem concerning the fact that many known solutions are based on processing operations that require test actions and that veri fy the occurrence of a negative feedback, the present solution implements instead an attempt repair . This means introducing a repair that has a calculated risk and informing thereof the technician operating on the vehicle so as to make the technician and the customer aware of the residual risk of fault when the vehicle is put back into circulation for resuming the normal activity . An action of this type is obtained in digital key, i . e . is coded in suitable manner so as to be repeatable and have a preset and veri fiable level of uncertainty .

[0104] The present invention offers in particular the possibility to minimi ze the ef fect of time in the analysis of the factors that define the fault mechanism . Considering that the typical times correlated to these factors can be very di f ferent , this means having the possibility to observe the diagnostic events at discrete ranges taking into consideration how the diagnostic system is designed even prior to how it is evolving over time .

[0105] The present invention of fers the possibility to de fine the risk level of a repair, namely define an attempt repair and assess the residual risk level , especially in the cases of a complex fault mechanism which involves di f ferent components dislocated along the measurement and control chain, which have di f ferent inertia and dif ferent operating principles . This is possible by means of the present encoding of the diagnostic events , in detail an encoding that is repeatable and measurable in returning a preset and veri fiable level of uncertainty .

[0106] The present invention further of fers the possibility to obtain all the benefits discussed so far maintaining a global constructive simplicity and thus a reduced level of implementation complexity of such techniques in a digital interface and a reduced impact in terms of costs and times required for this analysis .

[0107] Finally, it is clear that modi fications and variations can be made to the previously described solution which anyway do not depart from the scope of protection defined by the claims .

[0108] For example, steps S05-S11 can be implemented by the control unit 20 of the vehicle 10, so that all the steps of the analysis method 50 are performed inside the vehicle 10.

[0109] By way of non-limiting example, a practical example is now described in order to better clarify the previously described conditions.

[0110] In particular, the case can be considered in which a fault mechanism impacts on three different systems of the vehicle 10, the anomalies of which are detected by three different types of sensors. These three types of sensors can be different both for the type of measured quantity, and for the type of activation logic of the error (better described in the following) .

[0111] Considering by way of example that the vehicle 10 comprises a propulsor fed with natural gas, the vehicle 10 also comprises a suitable tank such as a cryogenic tank that allows stocking the fuel in the undercooled liquid phase at a given pressure. The fuel, through a suitable process, is vaporized and channeled in a feeding system (e.g. with rail) and from here dosed in indirect feeding to the combustion chambers in the cylinders of the engine of the vehicle 10.

[0112] A pressure sensor of the vehicle 10 monitors the feeding pressure present in the feeding system.

[0113] A suitable combustion sensor (e.g. based on a calculation model of known type) monitors the quality of the combustion .

[0114] After the combustion, the unburned gas arrives in the treatment system of the vehicle 10, before its expulsion into the atmosphere. In the exhaust gas treatment system, a temperature sensor of the vehicle 10 is present. As practical example , the case to consider is that of a fault mechanism whereby the pressure in the feeding system is less than what necessary for given revolution conditions and output power required for the drive shaft (what typically occurs in a severe mission with high load to be transported and a challenging upward slope ) .

[0115] In this case , the combustion in chamber is not optimal and there are events of non-combustion whereby fuel outflows from the exhaust valves and passes through all the various subsystems up to burning in the catalytic converter, thereby generating a high temperature that , ultimately, can irreparably damage the catalytic converter compromising the ef ficiency thereof and requiring the replacement thereof .

[0116] This fault mechanism is intercepted by the measurement and control chain through three dif ferent logics and three di f ferent types of sensors . The first is the pressure sensor placed in the feeding system and the detection logic based on the signaling of an anomaly when the measurement is above the predefined threshold . The second is the feeding sensor ( i . e . the intelligent sensor that classi fies the phenomena in the combustion chamber, for example through the microcurrents that circulate backwards in the spark plugs ) which signals an anomaly based on control logics for example based on the counting of events of non-plausibility of the values of the microcurrents with respect to a calibrated model and indicative of a correct operation . The third is the temperature sensor which is placed at the catalytic converter and signals an anomaly based on the control logic for example based on the measured temperature value exceeding a predefined threshold .

[0117] Therefore , a low pressure in the feeding system translates into three dif ferent anomalies with three di f ferent fault codes .

[0118] For the sake of greater clarity concerning the plausibility category, the case can be considered in which the values of the pressure measured by the pressure sensor in the feeding system are considered together with the temperature of the gas measured by the temperature sensor, with the number of revolutions of the engine read by an engine revolution sensor and with the temperature of the cooling water of the engine , read by means of a specially provided temperature sensor . In the considered case , although the pressure measurement falls within the operating limits and thus the DTC does not belong to the out-of-limits category, it could anyway relate to a gas , the temperature of which results to be too low considering the suitable one of the cooling water with respect to the revolutions of the engine . The compared comparison of these quantities correlated with one another leads to determining the fact that the generated DTC belongs to the plausibility category and thus it is a practical example of the latter .

[0119] For the sake of greater clarity concerning the fact that the determination of the identi fication category occurs based on the belonging category, the temperature sensor placed at the catalytic converter can be considered . In this case , a fault code of the " sensor in short-circuit" type belongs to the component category because it is activated based on the electrical response of the temperature sensor and indicates that the sensor is the obj ect of the anomaly . On the contrary, a fault code of the "high temperature" type belongs to the system category because it is activated based on the electrical response of the sensor but indicates that locally the temperature is exceedingly high : the temperature sensor has no operating problems , unlike the exhaust gas treatment system, which is subj ected to a strong thermal stress above the allowed limit . In fact , in this case the problem originates in the fuel distribution system and, by means of the combustion system, it trans fers as damage into the exhaust gas treatment system . Consequently and as previously described, the veri fication of the identi fication condition derives from the activation logic of the fault code .

[0120] Considering now a di f ferent fault scenario for the same vehicle 10 previously considered by way of example , it could occur that due to an inj ector in short circuit the combustion is not optimal and that therefore there is the postcombustion of the gas at the catalytic converter, with a corresponding rise in the local temperature . In this case , there would thus be a scenario of multiple DTC with a DTC indicative of the short-circuit of the inj ector , a DTC indicative of the non-combustion and a DTC indicative of the high temperature of the catalytic converter . There could also be a DTC indicative of the low ef ficiency of the catalytic converter , which following the rise in the temperature is no longer capable of lowering the polluting emissions at the exhaust . In other words , a DTC with belonging category of electrical type and identi fication category of the component type because related to the inj ector, a DTC with plausibility belonging category and identi fication category of the system type because related to the combustion, a DTC with belonging category of the out- of-limits type and with identi fication category of the system type , and finally a DTC with plausibility belonging category and with identi f ication category of the system type which relates to the lowering operations of the exhaust gases are generated, respectively . Of these four fault codes , two are located in the exhaust gas treatment system ( one of plausibility type and one of the out-of-limits type ) , one is located in the combustion chamber and is of plausibility type , and finally the last one ( of component and of electrical type ) is located in the inj ection system and relates to the inj ector . As is evident , this information on the DTCs allows choosing the most suitable action, thereby preventing the problem from occurring again .

[0121] In particular, based on the categories of the DTCs , there are one or more associated replacement and / or veri fication actions . In relation to the category information of the DTC, a priority scale of actions to be performed can thus be defined, ranging from test and veri fication to even component replacement .

Claims

CLAIMS1. Analysis system (5) for analyzing a fault in a vehicle (10) , comprising:- the vehicle (10), comprising a data acquisition module (12) and a control unit (20) operatively coupled to each other, the data acquisition module (12) comprising a plurality of sensors (14i..., 14i,... 14N) and a plurality of components (16i..., 16 j , ... 16M) , each sensor (14i..., 14i,... 14N) or component (16i..., 16 j , ... 16M) being configured to generate a respective detection datum indicative of the operation of the respective sensor (14i..., 14i,... 14N) or component (16i..., 16j,... 16M) and / or the operation of others of the sensors (14i..., 14i,... 14N) and / or the components (16i..., 16 j , ... 16M) ; and- an analysis control unit (30) operatively coupled to the control unit (20) , wherein the control unit (20) is configured to:- receive the detection data from the sensors (14i..., 14i,... 14N) and from the components (16i..., 16 j , ... 16M) ;- based on the detection data and in case of a fault of at least one of the sensors (14i..., 14i,... 14N) and the components (16i..., 16j,... 16M) , generate one or more diagnostic trouble codes, DTCs, each DTC being indicative of the fault of the corresponding sensor (14i..., 14i,... 14N) and / or component (16i..., 16 j , ... 16M) , and wherein one of the analysis control unit (30) and the control unit (20) is configured to:- based on the one or more DTCs generated, verify a belonging category condition of the one or more DTCs by choosing from a plurality of predefined belonging categories;- based on the one or more DTCs generated and the belonging category of the one or more DTCs, verify an identification category condition of the one or more DTCs by choosing from aplurality of predefined identification categories indicative of the fact that the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that generated the one or more DTCs is the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that is faulty or the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that is operatively coupled to at least another of the sensors ( 14i..., 14i, ... 14N) and components ( 16i..., 16 j , ... 16M) which is faulty;- based on the one or more DTCs generated, the belonging category and the identification category of the one or more DTCs, verify an action condition of the one or more DTCs by choosing from a plurality of predefined repair actions usable to repair the fault; and- generate an action signal indicative of the repair action to be performed to repair the fault, wherein the one of the analysis control unit ( 30 ) and the control unit (20 ) is further configured to, based on the one or more DTCs generated, the belonging category, the identification category and the action condition of the one or more DTCs, generate a success probability signal indicative of the probability that the action chosen to repair the fault actually resolves the detected fault .

2. Analysis system according to claim 1 , wherein the predefined belonging categories comprise a plurality of the following categories : electrical category; out-of-limits category; plausibility category; and initialization category, wherein the electrical category comprises DTCs that are generated when the occurrence of one or more activation criteria indicative of anomalies in the measurement of one or more electrical parameters is detected in the detection data,wherein the out-of-limits category comprises DTCs that are generated when the occurrence of one or more comparison criteria is detected in the detection data, indicative of anomalies of the detection data relative to respective limit reference values that define, for each detection datum, a respective maximum limit variation range which is indicative of a correct operation of the respective sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) when considered in isolation from the other sensors ( 14i..., 14i, ... 14N) and / or components ( 16i..., 16 j , ... 16M) , wherein the plausibility category comprises DTCs that are generated when the occurrence of one or more comparison criteria is detected in the detection data, indicative of anomalies of the detection data relative to respective plausibility reference values that define, for each detection datum, a respective maximum plausibility variation range that is indicative of a correct operation of the respective sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) when considered relative to the other sensors ( 14i..., 14i, ... 14N) and / or components ( 16i..., 16j, ... 16M) to which it is operatively coupled, and wherein the initialization category comprises DTCs that are generated when it is detected in the detection data, acquired in an initialization phase of the sensors ( 14i..., 14i, ... 14N) and / or the components ( 16i..., 16j , ... 16M) , the occurrence of one or more initialization criteria indicative of anomalies in the detection data relative to respective initialization patterns, each initialization pattern being indicative of the trend over time of the detection datum of the respective sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) during the initialization phase and in case of correct operation of the respective sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) .

3. Analysis system according to claim 1 or 2 , wherein thepredefined identification categories comprise the following categories : component category; and system category, wherein the component category comprises DTCs that are generated by the sensors ( 14i..., 14i, ... 14N) and / or the components ( 16i..., 1 j , ... 16M) that are faulty, and wherein the system category comprises DTCs that are generated by the sensors ( 14i..., 14i, ... 14N) and / or the components ( 16i..., 16 j , ... 16M) that are correctly operating and are operatively coupled to sensors ( 14i..., 14i, ... 14N) and / or components ( 16i..., 16j, ... 16M) that are faulty.4 . Analysis system according to any of the previous claims, wherein the predefined repair actions comprise at least one of the following : verification action; verification and replacement action; replacement action, wherein the verification action is indicative of the need to perform analyses on the sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) that generated the considered DTC, and / or on at least one part of the other sensors ( 14i..., 14i, ... 14N) and / or components ( 16i..., 16 j , ... 16M) , wherein the replacement action is indicative of the need to replace the sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16 j , ... 16M) that generated the considered DTC, or of the need to replace at least another of the sensors ( 14i..., 14i, ... 14N) or components ( 16i..., 16 j , ... 16M) which are operatively coupled to the sensor ( 14i..., 14i, ... 14N) or component ( 16i..., 16j , ... 16M) which has generated the considered DTC, and wherein the verification and replacement action is indicative of the need to perform both the verification action and the replacement action .

5. Analysis system according to any of the previous claims, further comprising a graphic and / or sound interface ( 35)operatively coupled to the control unit (20) and / or to the analysis control unit (30) and configured to receive the action signal and provide a user with the information of the repair action to be performed to repair the fault.

6. The analysis system according to any of the previous claims, wherein the one of the analysis control unit (30) and the control unit (20) is configured to verify the action condition of the one or more DTCs by choosing, as repair action, the predefined repair action which, among the plurality of predefined repair actions, has the greatest probability of actually resolving the detected fault.

7. Analysis control unit (30) for analyzing a fault in a vehicle (10) , the vehicle (10) comprising a data acquisition module (12) and a control unit (20) operatively coupled to each other, the data acquisition module (12) comprising a plurality of sensors (14i..., 14i,... 14N) and a plurality of components (16i..., 16 j , ... 16M) , each sensor (14i..., 14i,... 14N) or component (16i..., 16 j , ... 16M) being configured to generate a respective detection datum indicative of the operation of the respective sensor (14i..., 14i,... 14N) or component (16i..., 16j,... 16M) and / or the operation of others of the sensors (14i..., 14i,... 14N) and / or the components (16i..., 16 j , ... 16M) , and the control unit (20) being configured to receive the detection data from the sensors (14i..., 14i,... 14N) and components (16i..., 16 j , ... 16M) and, based on the detection data and in case of fault of at least one of the sensors (14i..., 14i,... 14N) and components (16i..., 16 j , ... 16M) , generate one or more diagnostic trouble codes, DTCs, each DTC being indicative of the fault of the corresponding sensor (14i..., 14i,... 14N) and / or component (16i..., 16 j , ... 16M) , the analysis control unit (30) being operatively couplableto the control unit (20 ) and being configured to :- based on the one or more DTCs generated, verify a belonging category condition of the one or more DTCs by choosing from a plurality of predefined belonging categories ;- based on the one or more DTCs generated and the belonging category of the one or more DTCs, verify an identification category condition of the one or more DTCs by choosing from a plurality of predefined identification categories indicative of the fact that the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that generated the one or more DTCs is the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that is faulty or the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) that is operatively coupled to at least another of the sensors ( 14i..., 14i, ... 14N) and components ( 16i..., 16 j , ... 16M) which is faulty;- based on the one or more DTCs generated, the belonging category and the identification category of the one or more DTCs, verify an action condition of the one or more DTCs by choosing from a plurality of predefined repair actions usable to repair the fault; and- generate an action signal indicative of the repair action to be performed to repair the fault, wherein the analysis control unit ( 30 ) is further configured to, based on the one or more DTCs generated, the belonging category, the identification category and the action condition of the one or more DTCs, generate a success probability signal indicative of the probability that the action chosen to repair the fault actually resolves the detected fault .

8. Analysis method ( 50 ) for analyzing a fault in a vehicle( 10 ) ,the analysis method (50) being performed by an analysis system (50) comprising:- the vehicle (10), comprising a data acquisition module (12) and a control unit (20) operatively coupled to each other, the data acquisition module (12) comprising a plurality of sensors (14i..., 14i,... 14N) and a plurality of components (16i..., 16 j , ... 16M) , each sensor (14i..., 14i,... 14N) or component (16i..., 16 j , ... 16M) being configured to generate a respective detection datum indicative of the operation of the respective sensor (14i..., 14i,... 14N) or component (16i..., 16 j , ... 16M) and / or the operation of other sensors (14i..., 14i,... 14N) and / or components (16i..., 16j,... 16M) ; and- an analysis control unit (30) operatively coupled to the control unit (20) , wherein the analysis method (50) comprises the steps of:- receiving, from the control unit (20) , the detection data from the sensors (14i..., 14i,... 14N) and from the components (16i..., 16 j , ... 16M) ;- based on the detection data and in case of fault of at least one of the sensors (14i..., 14i,... 14N) and the components (16i..., 16 j , ... 16M) , generating, by the control unit (20) , one or more diagnostic trouble codes, DTCs, each DTC being indicative of the fault of the corresponding sensor (14i..., 14i,... 14N) and / or component (16i..., 16 j , ... 16M) ;- based on the one or more DTCs generated, verifying, by the analysis control unit (30) or the control unit (20) , a belonging category condition of the one or more DTCs by choosing from a plurality of predefined belonging categories;- based on the one or more DTCs generated and the belonging category of the one or more DTCs, verifying, by the analysis control unit (30) or the control unit (20) , an identification category condition of the one or more DTCs by choosing from aplurality of predefined identification categories indicative of the fact that the at least one of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16j , ... 16M) which has generated the one or more DTCs is the at least one of the sensors ( 14i..., 14i, ... 14N) and components ( 16i..., 16 j , ... 16M) that is faulty or is the at least one of the sensors ( 16i..., 16 j , ... 16M) and the components ( 16i..., 16 j , ... 16M) which is operatively coupled to at least another of the sensors ( 14i..., 14i, ... 14N) and the components ( 16i..., 16 j , ... 16M) which is faulty;- based on the one or more DTCs generated, the belonging category and the identification category of the one or more DTCs, verifying, by the analysis control unit ( 30 ) or the control unit (20 ) , an action condition of the one or more DTCs choosing from a plurality of predefined repair actions usable to repair the fault; and- generating, by the analysis control unit ( 30 ) or the control unit (20 ) , an action signal indicative of the repair action to be performed to repair the fault, wherein the analysis method ( 50 ) further comprises the step of, by the analysis control unit (30 ) or the control unit (20 ) , generating, based on the one or more DTCs generated, the belonging category, the identification category and the action condition of the one or more DTCs, a success probability signal indicative of the probability that the action chosen to repair the fault actually resolves the detected fault .

9. The analysis method according to claim 8 , wherein, in case of a plurality of DTCs, the step of verifying the identification category condition of the one or more DTCs also comprises simultaneously analyzing the DTCs .

Images