BE1023041B1 - Device and method for distributed diagnostic analysis - Google Patents

Abstract

A device (106) is disclosed to determine a confidence measure for a function performed by functional blocks of a system component (105, 120, 130, 140). The device comprises - input means

(200) for receiving, for each functional block that contributes to the function execution, pieces of information each representing a state of a functional block of a system component to be assessed, said functional block being involved in performing the function, - a module (201) for classifying said states, obtaining test interval information and determining a reliability estimate of functional blocks for each of the functional blocks based on the test interval information and / or of the classified states, calculating means (202) ter determining a confidence measure for that function performed by the functional blocks based on the reliability estimates - decision means (203) to decide on said confidence measure for said function, output means (204) to feed the decision in adapted format.

Description

Field of the Invention The present invention relates roughly to the field of systems capable of real-time analysis of local and distributed diagnostics.

Background of the Invention Many systems provide all kinds of diagnostics. At the end, it is often difficult for the user to combine all diagnostic data and formulate a substantiated conclusion as to whether certain system functions are still operational or not, or to what extent the functionality still works within known limits. In the case of safety systems in particular, it is essential to see through the reliability of a function, preferably at all times.

The prior art solutions combine diagnostics claims in a rather arbitrary manner by analyzing individual diagnostics events individually or partially combined. For large systems, such a method cannot be considered deterministic and gives uncertainties about marginal cases or uncovered defect combinations.

Application US2002 / 138184 discloses an interface for receiving input with respect to observed symptoms indicative of one or more defective components, a processing element for correlating input with regard to the observed symptoms with at least one suspected component which is capable of causing the observed symptoms after failure, and a display for presenting information regarding the suspect components. The system is used to detect the defective component.

In GB2450241, a method is disclosed for evaluating a state of a controlled system in which a plurality of signals indicative of observation states of a plurality of operation variables are received. The controlled system includes a system on board an aircraft. Using a diagnostic model of the controlled system, a combined probability analysis of the signals is performed to obtain a health prognosis of the controlled system. The proposed system is not scalable and has no assessment of the reliability of the functions.

US2002 / 083372 discloses a diagnostic method for a technical installation for determining a cause of an error event described by an error state variable. The method comprises determining an operating state of the installation defined by state variables, by determining diagnostic parameters that each characterize one of the state variables. By configuring the dependency tree with hierarchical levels, a dependency tree is compiled that contains at least some of the diagnostic parameters. One important limitation of the method is that the determination tree is kept static. There is no dynamic assessment of possible state combinations that are not provided.

In WO2009 / 148984 a process is proposed for determining the root cause of a fault in a vehicle by using multiple models and observations. Each of the models provides a reliability estimate about the observation it makes regarding a potential error condition. A hierarchical tree is used to analyze diagnostic codes and other signals from subsystems and components. Each level of the hierarchical tree gains access to the information it has before making a decision. The information from different branches of the tree can be dynamically changed based on vehicle information, such as speed dependence. The reliability estimates of the model can also be determined using data from multiple vehicles. However, no mechanism is provided to dynamically assess the effect of different error finding intervals in the system.

Therefore, there is a need for a solution that leaves room for processing diagnostic information about the various functions performed by a component of a system, so that it is no longer necessary to switch off the entire system as soon as a defect is detected in e.g. one system component.

Summary of the Invention It is an object of embodiments of the present invention to provide an apparatus and method for performing diagnostics based on the real-time reliability examination of system components and sub-components of a system in a distributed manner in order to achieve operational come to conclusions for one or more functions provided by the system.

The above object is achieved by the solution of the present invention.

In a first aspect, the invention relates to an apparatus for determining a reliability measure for a given function performed by one or more functional blocks of a system component to be assessed. The device comprises - input means for receiving, for each functional block that contributes to the execution of said given function, pieces of information from one or more diagnostic blocks that each represent a state of the respective functional block of a system component to be assessed, said functional block is involved in performing a given function, - one or more modules placed to classify said states, to obtain diagnostic test interval information and to determine a reliability estimate of functional blocks for each of the functional blocks based on the diagnostic test interval information and / or of the classified states, - calculation means adapted to determine a confidence measure for that given function performed by the one or more functional blocks based on the reliability estimates of the one or more of functional b lure, - decision means to derive a decision from said confidence measure for said given function, - output means to supply said decision in a format adapted to a physical interface of said system component.

The proposed solution indeed leaves room for the real-time evaluation of correct operation of functions with respect to a system component and to independently assess whether or not a function is affected by a defect of a particular functional block covered by diagnostics. More specifically, the invention discloses a real-time, time-dependent allocation of a reliability estimate of a function with respect to a system component. It is clear that when a functional block within a component has just been diagnosed as functioning correctly, it is very likely that this functional block will still function correctly a short time later. However, if diagnostics are not performed for a long period of time, the probability of ensuring that the functional block is still operational can be very low. This aspect has been taken into account in the present invention where various ways are presented to assign a reliability estimate to a functional block.

In an embodiment of the invention, the module for classifying said states comprises one or more first classifiers operatively based on a threshold level.

In one embodiment, the module comprises an internal clock for performing time display. In another embodiment, the module is adapted to receive an external clock signal for outputting time.

Preferably, the module comprises an interval counter adapted to be reset after a diagnostic test.

In a preferred embodiment, the device is implemented in a self-programmable logic matrix [Field Programmable Gate Array] (FPGA) or an application-specific integrated circuit (ASIC). Alternatively, the device is designed with separate hardware components.

In another embodiment, the module is positioned to generate a time indication based on a level transition, a rising or falling edge, specific protocol agreements, or signal flanks.

In a preferred embodiment, the device comprises an output state evaluator adapted to evaluate the reliability measure. The output state evaluator preferably includes at least one second classifier for performing that evaluation.

In another embodiment, the device comprises an internal diagnostics infrastructure for checking internal processes in the device. The reliability estimator preferably provides internal and external interfaces to communicate its conclusions and real-time reliability estimates for further processing in the system.

In yet another embodiment, the device comprises a configuration infrastructure block for setting parameters of the input means and / or the module. The reliability estimator is then able to perform a configuration that allows programming the selection of input and output, to concretize the different reliability models with their related parameters and to the way to measure the reliability of the functional blocks in the function-related reliability. to combine. This interface also allows the storage of the reliability estimator parameters to look up these data after a duty cycle, leaving room for correct time measurement.

In a further embodiment, the device comprises an output interface for passing on said reliability measure. In a system comprising a plurality of system components, the reliability estimators are capable of communicating their findings to each other, which makes it possible for the reliability information regarding a system function to be transmitted throughout the entire system. Based on this passed data, the relevant system component, which acts as a decision node for a particular function, will be able to switch system functions on or off based on diagnostics relevant to the specific function.

The invention also relates to a system comprising one or more devices as previously described and a number of system components, wherein each system component comprises one or more functional blocks arranged for performing one or more functions.

In another aspect, the invention relates to a method for determining a confidence measure for a given function determined by one or more functional blocks of a system component to be assessed, the method comprising: - receiving, for each functional block which contributes to the performance of said given function, of pieces of information from one or more diagnostic blocks that each represent a state of the respective functional block of a system component to be assessed, said functional block being involved in determining a given function, classifying said states - obtaining diagnostic test interval information - determining a reliability estimate of functional blocks for each of said functional blocks based on said diagnostic test interval information and / or of said classified states, - determining a reliability dsize for said given function determined by said one or more functional blocks on the basis of said reliability estimates of one or more of functional blocks, - deriving a decision from said reliability measure, - sending said decision in a format adapted to a physical interface of said system component.

The invention also relates to a program executable on a programmable device that contains instructions that when executed perform the method as described.

In yet another aspect, the invention relates to a method for upgrading a system comprising a plurality of system components, wherein each of the system components comprises one or more functional blocks for performing one or more functions. The method comprises providing a device as previously described, so that a confidence measure can be determined for a given function determined by one or more functional blocks of one of the system components, wherein the reliability measure is based on reliability estimates of one or more functional blocks.

To summarize the invention and the advantages achieved over the prior art, certain objects and advantages of the invention have been described above. It is, of course, understood that not all of these objectives or advantages can be achieved by any specific embodiment of the invention. Thus, for example, those skilled in the art will recognize that the invention can be embodied or implemented in a manner that achieves or optimizes one advantage or a group of benefits as provided herein, without necessarily achieving other objectives or benefits that may be offered or suggested herein.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment (s) described below.

Brief description of the figures The invention will now be further described, by way of example, with reference to the accompanying figures, wherein in the various figures the same reference numerals refer to the same elements.

Fig. 1 illustrates the relationship between a system architecture and system functions.

Fig. 2 illustrates a system as considered in the invention, comprising a number of components.

Fig. 3 illustrates an exemplary component of the system of Fig. 1.

Fig. 4 illustrates a detailed analysis of a reliability estimator.

Fig. 5 illustrates a decomposition of an input state assessor.

Fig. 6 illustrates a decomposition of a fault finding interval processor.

Fig. 7 illustrates the effect of error finding interval timing.

Fig. 8 illustrates a decomposition of a reliability allocator.

FIG. 9 illustrates the combination of the current reliability estimates from different reliability allocators in a function reliability calculator.

Fig. 10 illustrates an output state assessor.

Fig. 11 illustrates a physical output interface.

Fig. 12 illustrates an exemplary embodiment of a hierarchical system topology.

Fig. 13 illustrates the error tree functions associated with the functions of the system of Fig. 10.

Fig. 14 illustrates the evolution of the reliability estimate for system components of Fig. 12.

Fig. 15 illustrates the overall and intermediate reliability estimate for the detection function of excessive shocks.

Fig. 16 illustrates an evolution of a reliability value when accelerometer XI is defective in Sensor 1.

Fig. 17 illustrates the effect of X1 failure on the reliability function output of S1.

Fig. 1S illustrates the evolution of the confidence value if the shock detector in Fig. 12 is defective.

Fig. 19 illustrates the evolution of the reliability figure in the case CAN bus 2 in Fig. 12 is defective.

Fig. 20 illustrates the confidence level of the detection function of excessive shocks.

Fig. 21 illustrates a reduction in the confidence level of the instability detection function.

Fig.22 illustrates the evolution of the reliability value in the event that the control panel in Fig.12 is defective.

Fig. 23 illustrates the loss of confidence level for the derailment detection function.

Fig. 24 illustrates the evolution of the confidence figure if X1 and Z2 are defective in Fig. 12.

Fig. 25 illustrates that the defect of X1 has no effect on the functionality for excessive shocks, but the defect of Z2 causes the function to no longer be reliable.

Fig. 26 illustrates the influence on the reliability of the instability detection function in the event that XI is defective.

Fig. 27 illustrates the evolution of the confidence value in the case of an increased error finding interval on the recording element Z1 in Fig. 12.

Fig. 28 illustrates the corresponding detection reliability of excessive shocks.

Fig. 29 illustrates a case where the recording element Z1 and the shock detector are defective.

Fig. 30 illustrates a decrease in reliability of the function for excessive shocks.

Detailed Description of Illustrative Embodiments The present invention will be described with respect to particular embodiments and with reference to certain drawings, however, the invention is not limited thereto but is only limited by the claims.

Furthermore, the terms first, second, third and the like in the description and in the claims are used to distinguish similar elements and not necessarily for describing an order, neither in time, nor spatially, nor in order or in any other way. It is to be understood that the terms used in this way are suitable under interchangeable conditions and that the embodiments of the invention described herein are capable of operating in a different order than described or depicted herein.

It is to be noted that the term "comprises," as used in the claims, is not to be interpreted as being limited to the means described thereafter; this term does not exclude other elements or steps. It can therefore be interpreted as specifying the presence of the listed features, values, steps or components referred to, but does not exclude the presence or addition of one or more other features, values, steps or components, or groups thereof. Thus, the scope of the expression "a device comprising means A and B" should not be limited to devices that consist only of components A and B. It means that with regard to the present invention, A and B are the only relevant components of the device.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, occurrence of the expressions "in one embodiment" or "in an embodiment" at various places throughout this specification may not necessarily all refer to the same embodiment, but may do so. Furthermore, the specific features, structures, or characteristics may be combined in any suitable manner, as would be apparent to those skilled in the art based on this disclosure, in one or more embodiments.

Similarly, it should be appreciated that in the description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and assisting in the disclosure. understanding one or more of the various inventive aspects. This method of disclosure should not be interpreted in any way as a reflection of an intention that the invention requires more features than explicitly mentioned in any claim. Rather, as the following claims reflect, inventive aspects lie in less than all the features of a single prior disclosed embodiment. Thus, the claims following the detailed description are hereby explicitly included in this detailed description, with each independent claim as a separate embodiment of the present invention.

Furthermore, while some embodiments described herein include some, but not other, features included in other embodiments, combinations of features of different embodiments are intended to be within the scope of the invention, and constitute different embodiments, as would be understood. by the skilled person. For example, in the following claims, any of the described embodiments can be used in any combination.

It should be noted that the use of particular terminology in describing certain features or aspects of the invention should not be construed to imply that the terminology is redefined herein to be limited to specific features of the features or aspects of the invention with which this terminology is associated.

Numerous specific details are set forth in the description provided herein. It is, however, understood that embodiments of the invention can be practiced without these specific details. In other cases, well-known methods, structures and techniques have not been shown in detail to keep this description clear.

Fig. 1 shows a system configuration comprising a variety of components. The considered system performs a number of functions. Depending on the function, one or more components shown in the figure are involved in performing said function. Depending on the function, a component can act as a decision-making node for that specific function or it only forms part of the data flow path for that function where some processing is performed on an incoming signal and then an output signal is forwarded. A component can also act as a decision-making node for one function, while for another function it is only part of the data flow path.

A defect of one of the system components may potentially have an impact on the functional behavior of one or more functions. By organizing the diagnostics performed on the components so that diagnostic 'events' (ie diagnostic tests) are translated into a measure of the reliability of the component and by assessing the total desired reliability value of an individual function, it can be determined on based on the reliability of the various component components of the function, whether the function still meets the criteria to ensure correct operational implementation.

The present invention discloses a solution for real-time analysis of local and distributed diagnostics that facilitates decisions about functions provided by the system in which the solution is implemented. The invention utilizes a scalable concept of real-time reliability estimation of system components and functions and propagation of reliability information regarding specific functions throughout a system built up with a number of components. More specifically, the invention describes a scalable, distributed, standardized way of determining and communicating the real-time operational reliability of at least relevant components of a component or a system comprising that component, in order to local or centralized accurate diagnostic conclusion and decision making. support, taking online and offline tests into account.

The proposed approach can be realized in a pure software implementation, but it can also be organized in the form of hardware. Embodiments of the system of the invention include implementations in hardware circuits, in silicon chip devices, but also purely in software that runs on the system component controller or on one or more programmable devices.

In the invention, systems are considered comprising a number of components arranged in a topology comprising a number of hierarchical levels, a mesh topology or any other type of topology. Each component is designed to perform one or more tasks in or for the system. Each task supports one or more functions to be performed by the system or at least a part thereof. One or more system components are adapted to perform internal diagnostics to evaluate the extent to which the component parts of the system component in question work correctly. The invention proposes adding reliability estimation at the system component level and in most cases (but not necessarily always) passing on information to other components that results from an analysis based on the reliability estimation for said system component or for at least part of a system component. function.

The invention contemplates a system that includes components in which diagnostic data is utilized to assess the reliability of certain functions with respect to test time intervals. A reliability value or a weighting factor is assigned to specific component functions. This reliability information can be passed on to other system components (possibly at a different hierarchical level, if the system is hierarchical) for inclusion in further function reliability estimates. Based on the reliability figures, the state of functions (i.e. whether they still work reliably or not) can be assessed unambiguously by components of the system. This allows the use of certain system functionalities to continue even though diagnostic errors were reported while other functions are disabled.

The proposed solution provides a real-time assessment of the state of a system function based on reliability estimates of functional blocks of system components. In the case of a defect of specific functional blocks in a system, it can be unambiguously determined which system functions can still function reliably. As a result of the proposed approach, system functions that are not affected by the defect will continue to operate as such, leading to an overall improvement in system availability.

Fig. 2 provides a diagram of a typical system that is considered in the present invention. Two system components 120 and 130 are shown which receive a number of input signals at their respective input interfaces. System component 130 is fed with inputs from 101 and 102. System component 120 receives inputs from Sensor1 and Sensor2 and also receives a signal output from component 130. In each system component, the basic building blocks are indicated. The one or more inputs applied to the input interfaces are required to perform a particular system functionality for which the component is designed. Resulting signals to be output by the component are applied to one or more output interfaces that provide for further propagation of one or more output signals to other components in the system. The diagnostic infrastructure block in Fig. 2 can receive information from the input and output interfaces and from performing or not performing a function for which the system component is responsible. The diagnostic infrastructure block represents the checking and diagnostic means provided in the system component to validate the associated functional block (s) in the system component. The diagnostic infrastructure provides input for the reliability estimator (106), which can also receive external input via an interface. In component 130, the reliability estimator receives a signal from an emergency button. The reliability estimator processes the data it receives at its input. The claims can be directly distributed to an external output and / or linked to component output interfaces. As can be seen from Fig. 2, the reliability estimator of component 140 receives input from another reliability estimator. This component 140 is a system component that receives inputs from both components 120 and 130. Component 140 has the same basic structure as the other two components shown in Fig. 2.

Fig. 3 illustrates an example of a practical implementation of a system component 105. The basic scheme of the system components is repeated at the top of the figure so that the various components in the implementation in the lower part can be easily recognized. The lower portion of Fig. 3 represents a system component that enables an analog sensor signal at its input to which hardware (107) is implemented to evaluate whether the sensor current meets specific requirements, for example, if the signal is between 4 mA and 20 mA. The analog diagnostic hardware block of the flow monitoring (107) is a diagnostic block that reports to the reliability estimator. A diagnostic block must be understood as a set of signals that is required to assess the correct operation of a particular function of the system component. If the current value does not fall within the specified range, the reliability estimator assigns a low reliability to the functional block related to the analog sensor signal.

The system component is also provided with two digital inputs 100 and 102. The analog input 101 and the digital input 102 are used to perform the function and communicate by the microcontroller to the CAN interfaces. In addition, a digital output 104 is manipulated as a function of the functional process.

The microcontroller itself is also provided with diagnostic infrastructure (107) such as an input / output state monitor, a watchdog that triggers the operating system and an internal software diagnostics process. These features are capable of detecting specific microcontroller related issues such as input / output issues, endless loops, memory corruption, ... Transitions in the diagnostic information are reported to the reliability estimator and provided with a reliability value.

In the reliability estimator, implemented here in an FPGA, the reliability allocations to the various functional blocks are combined in a function reliability estimate. As an example, the function can be based on the fact that the reliability of the analog signal and the control system must exceed a certain threshold to enable CAN communication. The reliability of both input L / Os must be high and there must be no internal error to allow confirmation of the digital output to be undone. The reliability estimator then evaluates whether these criteria are met as a function of time elapsed after the last diagnostic event for each function and taking the diagnostic state for each of the functions into account. If not, an indication is issued to respectively stop CAN communication and / or to cancel the confirmation of the digital output. He will also automatically undo the confirmation of his own specific digital output.

Each system component includes a reliability estimator to determine reliability values for diagnostic input from its own diagnostic infrastructure 107 (e.g., test circuits, watchdog circuits, ...) as well as from diagnostic facilities elsewhere in the system (ie from other reliability estimators) . Diagnostic input can also be provided by specific interfaces on the system component that directly supplies reliability data to the reliability estimator. This provides a transparent channel to the job reliability calculator. Processing means are available in the system component to process the input interfaces locally. The system component further comprises a reliability estimator to make local decisions about the reliability of a function of the component and is arranged to generate outputs to other system components based on local knowledge and the decision. Indeed, in most embodiments, there is propagation of reliability estimation information of one or more functions supported by the relevant system components.

The following sections describe the different building blocks of a system component in more detail.

Fig. 4A shows a detailed diagram of a reliability estimator block (106) that is part of a system component or implemented as a stand-alone device adapted to communicate with the system component. The main task of the reliability estimator is to translate diagnostic information from the system component into a value of estimated reliability of the one or more functional blocks in this component. By combining the reliability values of the relevant constituent blocks into a real-time reliability value for a function of the system component, an evaluation of its correct functional behavior is performed for that function. By combining the reliability values of the relevant component blocks differently, it is possible that a reliability estimate can be made for a different function of this system component. A reliability estimator includes a suitable input block for accepting various physical inputs. The physical interface at the input can thus be adapted to the requirements of the reliability estimator. Diagnostic hardware can occur in various types and must be adapted for communication with the input state assessor (see below). In some cases, this can be implemented with separate hardware components. In other cases it can be part of an ASIC, an FPGA or a system-on-chip.

The input block allows routing of the input triggers with respect to a particular diagnostic block to an input state evaluator and error finding interval processor. As already mentioned, a diagnostic block must be understood as a set of signals required for judging the correct operation of a particular function of the system component. As can be seen from Fig. 4, the estimator can include a number of reliability blockers of functional blocks, each coupled to a different diagnostic block. Each reliability block of functional blocks includes an input state evaluator and an error finding interval processor, the outputs of which are applied to the reliability block. The latter block calculates and performs an instantaneous reliability estimate for each functional block that is provided with diagnostics and is involved in the realization of that particular function. Reliability estimates performed by the reliability allocator blocks of different reliability allocators of functional blocks are combined in a reliability calculator for different system functions. The calculated reliability measures are fed to an output state assessor, which guides the reliability information to an output block.

The various input signals related to a specific diagnostic block of the component or to another reliability estimator or direct reliability estimator input are routed to the input state evaluator and error finding interval processor for that diagnostic block. In the case that there are multiple diagnostic blocks that each cover a section of the system component, there may be a number of reliability blockers of functional blocks, one for each diagnostic block, each containing an input state evaluator and an error finding interval processor, as illustrated in Fig.3. The error finding interval processor blocks indicate the time of the diagnostic events and further provide an output signal that a test was performed for the associated diagnostic block. The output signal may also possibly serve to classify the reliability of the diagnostic block in the reliability allocator. In parallel, the error finding interval processor triggers the input state evaluator to evaluate the result of the diagnostic event.

Fig. 5 shows the decomposition of an input state assessor block in a number of possible configurations. Different types of input information can be applied to the reliability estimator: analog, digital or a complex combination of interfaces linked to diagnostics. The input can also be coupled to an interface external to the system component and which leaves room for suitable propagation of reliability data throughout the system. Different types of input signals are handled by specific reliability classifiers in the input state assessor block. Based on the signals coming from the various reliability classifiers, a reliability event generator obtains a time-marked and classified reliability event for further processing. The reliability event is the result of the classification of the diagnostic information processed by the reliability classifier. The reliability event generator block is arranged for exchanging trigger signals with the error finding interval generator. The event source may, for example, relate to exceeding a level of an analog input signal, which is a diagnostic indication that the reliability of the connected functional block has decreased. Another source of an event may be the receipt of a notification from internal or external diagnostic infrastructure or from reliability estimators, which indicates that the reliability of a particular connected functional block has changed. This is reported to the reliability allocator via internal interfaces to which internal diagnostics can be provided, for example by adding periodic information from redundancy checks during data exchange.

A signal that comes from a diagnostics block and that enters an input state evaluator can be analog. In such a case, the analog signal is assigned to a level-based reliability classifier. This classifier gives the current signal a reliability class. In the event that a specific threshold level is exceeded, a trigger is sent to the error finding interval processor to provide this event with a time indication and to reset the error finding interval. At the same time, the event is reported to the reliability allocator by the reliability event generator. In the case that the input from the diagnostics block is a digital signal, a threshold-based reliability classifier in the input state evaluator triggers the reliability event generator to generate a classification event and the error finding interval processor again triggers to generate a time display event. A convention may be that a high input signal corresponds to a successful diagnostic test. If the input signal becomes low, a defect has been detected. Associated reliability can be determined for both cases. In the event that the data entry is used, a more complex mechanism is provided to communicate the findings of the diagnostic infrastructure or lower level system components. Such input can for example be SPI, I2C, parallel bus, ... The reliability classifier of the complex communication core drives the reliability event generator to generate the event classification and associated time display. The diagnostics infrastructure can also generate an alternate entry, such as a watchdog with time window. Depending on the implemented logic, a reliability event can be generated based on pulse shapes. This example illustrates that the invention can also be used as an advanced watchdog system capable of generating, for example, a system reset. In some cases, the architecture can be clearly optimized by combining the input state evaluator and the error finding interval processor in one functional block within the reliability estimator.

Fig. 6 illustrates an embodiment of a parsed error finding interval processor. It accepts different types of input signals (data input, switch input, external clock signal, ...), which may possibly be shared with the input state assessor. A test interval event generator uses the various inputs as the basis for time-indicated event processing. The diagnostic events are coupled with a time indication to check the error finding interval or to provide the necessary time data to the reliability allocator (s) of the reliability estimator (s) for use further in the process. An error finding interval must be understood as the time elapsed between two diagnostic tests of a given functional block. Time allocation can be organized on the basis of an internal or an external clock. Therefore, the input state evaluator evaluates the results of the diagnostic data and reports to the reliability allocator whether there was a particular event that affects the reliability of a functional block not based on the evolution of time, i.e., based on a defect that has occurred.

As illustrated in Fig. 6, the error finding interval controller may be adjusted with respect to timing source as well as interval reset source. Timing can be generated internally in the reliability estimator, but can also be applied from an external interface. A diagnostic event with respect to a particular functional block acts as an error finding interval timer reset.

An error finding interval processor handles the time-related information of the diagnostic events relating to a particular functional block. This means that in case a diagnostic action was performed (i.e. a diagnostic test was started), the error finding interval counter will be reset. From that moment on, time data is kept and reported to the reliability allocator that will be used in the respective reliability models. As shown in Fig. 7, the moment of reliability assessment is important in order to arrive at a correct assessment of the function reliability, since it can be clearly seen that, depending on the diagnosis planning, the evolution of the function reliability can behave considerably differently.

The error finding interval processor is also capable of extracting diagnostic data from time-based diagnostics. One example of this case is an implementation of a watchdog signal decoder for which a stage of the time triggered core reliability classifier can be used.

The error finding interval processor operates in close cooperation with the input state assessor and may use the same (same) input signal (s). The interval processor analyzes the timing aspects from the diagnostic infrastructure or lower level system components and marks the associated events with time indications. In the case of analog input signals, the time display event is based on a level transition. For digital inputs, the event is generated on a rising or falling edge. For data input, the event is generated based on specific protocol agreements, and for the switch input, the edges of the signal are also used.

The interval processor specifically tracks the time when a diagnostic test was performed. The error finding interval processor also has internal and / or external clock features available to enable the generation of a sufficiently accurate timestamp for the events and timer features to keep track of the elapsed time since the last diagnostic test was performed.

The time display event, which indicates when a test was performed for a specific diagnostic block, and the event classification, which indicates whether a test failed, was successful or classifies it to a certain class, are routed to a reliability allocator that defines the current reliability estimate for the functional block that is covered by the diagnostics infrastructure.

A more detailed diagram of a reliability allocator is shown in Fig. 8. The allocator processes the classified diagnostic events as a function of their time indication to obtain a current reliability estimate for the part related to the diagnostic entry. Various methods are available in the technical field to assign an instantaneous reliability value. A number of options are illustrated in Figure 8. For example, a matrix allocator can assign a current confidence value based on the time since the last test or diagnostic event and based on the event classification. Another option is a mathematical reliability model that uses time since the last diagnostic event and a defined reliability coefficient. Of course other models can also be used.

In a simple form, a time / event matrix allocator is used to define a reliability figure as a function of a time zone with respect to the fault finding interval (FFI) time and the event classification. By filling in a table with reliability, a specific allocation can be organized depending on the event classification and the time that has elapsed since the last test. In another form, a mathematical model is used to define the reliability based on the FFI time of the event. More complex scenarios can be modeled depending on the classification. Examples of mathematical reliability functions are widely available.

The current reliability figure of the functional blocks covered by the different diagnostic infrastructure inputs can then be combined in a function reliability calculator (see Fig. 4) that uses standard error tree calculation techniques. Such a reliability calculator can be provided for each function of a system component. This means that a specific instantaneous reliability figure of part of the system component is available for reuse in other function reliability estimates.

In Fig. 9, the outputs of different reliability allocators are combined in a function reliability calculator. This block performs a mathematical error tree analysis function based on a defined configuration resulting in a current function reliability estimate. As shown in Fig. 4, a number of such function reliability calculators may be present in a reliability estimator.

In order to judge whether a particular function still works correctly, the figures of function reliability in an output state assessor (see Fig. 10) are evaluated against warning and error thresholds. The function reliability estimates are supplied to a level-based reliability classifier. This means that if the reliability estimate of a particular function falls below a certain warning threshold level, a warning alarm can be produced to the output from the output state assessor and, consequently, to the reliability estimator output or even the system component output. The warning level can be determined as a function of the estimated time before the error threshold level will be reached. This error level would be achieved in the event that no diagnostic defect events are reported. This shows that the method allows sufficient advance planning of preventive maintenance or specific test actions based on the warning levels determined for reliability functions. It may also force manual testing to reset certain error finding interval timers, thereby avoiding reaching the error threshold levels. In some cases this only happens if certain manual actions are planned. If the confidence level of a particular function falls further below an error threshold level, specific output is generated, just like for the warnings, resulting in application dependent error handling. Depending on the reliability allocation method used and the reliability, availability, maintenance, and safety warning and error system requirements, threshold levels can be automatically calculated to obtain a measured method to deal with these requirements. This can be done to evaluate the minima in the methods used in the reliability allocator in combination with the method used for the function reliability calculations and the applied safety levels and / or maintenance context. The conclusions of the assessments are then consolidated and combined in the output consolidation block and forwarded to the physical output interface (also corresponding to the "Output" block in Fig. 4) for further processing in the system.

The physical output interface in the reliability estimator allows, where relevant, the combination of the consolidated information in the output interfaces of the system components. This can be another system component that includes a reliability estimator, but can also be a bubble, a lamp, an input from a safety device, ... Fig. 11 shows the physical output interface that converts the signals from the output state evaluator into the physical interfaces available on the system component.

By combining system components as shown in Figs. 1 or 2, a complete system with all its functions with respect to reliability can be characterized individually. If the reliability of the functions exceeds a certain level, then everything is fine. If the level drops, there may be a need for maintenance, testing, or disabling of the specific function without having to disable the other functions.

Conventional diagnostics tells exactly what goes wrong, but does not indicate which part of the system can still be used reliably. There is no further indication as to whether diagnostic testing was planned in time and how this correlates with the time of testing of other system components or functional blocks. This could lead to unexpected problems with regard to dormant defects. These drawbacks are clearly overcome by the approach of the present invention.

In order to make the described system flexible, a configuration infrastructure (see Fig. 4) can be provided to define the input selection, the reliability allocation (updating the reliability consultation tables or changing the reliability model), function reliability, output status assessment and output configuration. possible. In addition, internal parameters such as current reliability values and error finding intervals can be stored in internal volatile or non-volatile memory to keep track of the evolution of the reliability of the system during its lifetime, providing notification to be calculated for duty cycles. Specific parameter updates and readings can be supported by numerous solutions.

An internal diagnostics infrastructure can also be part of the reliability estimator. This is illustrated in the above-mentioned Fig. 4. The internal diagnostics checks its internal processes and, in the event of a defect, directly influences the reliability estimates with regard to the related internal functional blocks. The internal diagnostics infrastructure block continuously performs diagnostics on the various constituent blocks of the reliability estimator. The findings are used in a specific function reliability calculation, which is then made available for further use. The internal diagnostics infrastructure block is also capable of manipulating the individual functional reliability or reliability of diagnostic blocks into specific rules in order to also have a measure of estimator defects.

The proposed approach can also be used to evaluate the current reliability of software components. By assigning a reliability measure to software blocks and using the hitch for unexpected events and internal software diagnostics, the principle can be fully implemented in the software itself, which also leads to substantiated decisions of functional operation. Any type of hybrid platform can be envisaged for reliability estimators of mixed hardware software.

The invention offers a solution to various problems. Firstly, the described method performs a real-time analysis of functional reliability as well as component reliability. In state-of-the-art solutions, this evaluation takes place only on a theoretical basis and only provides evidence of functional reliability in case the assumptions are met. This is often not the case, since in many systems diagnostics must be performed on manual triggers. If these triggers are not provided, the system is not tested, thus causing a high risk of dormant defects. The proposed approach provides clear insight into such situations and makes it possible to deal with such cases in an appropriate manner. In addition, the correlation of the timing of all relevant diagnostics is taken into account when assessing a functional reliability that is not seen in prior art solutions. Also in the approach described the abstraction level of the error message is very high, which leaves room for very uniform interface definitions at hardware and at Software level. Since the method covers the smallest component into a complete system, it makes it possible to maintain an overview and to act unequivocally on defects, but keeps the unaffected functions operational, thus maintaining a high reliability and availability of the system and its functions. This method also allows the definition of early warning based on the estimated time before an error level will be reached. This supports preventive maintenance or encourages specific manual test programs.

Fig. 12 shows an exemplary system topology in which two triaxial accelerometer sensors and a shock detection device are connected to a gate component. The port routes the data from the two sensor devices and the shock detector to a control panel where an assessment is made of three functions. Correct operation of each of the functions is indicated by a corresponding control light. The three connected lights come on based on the assessment.

A first function that is checked relates to detection of excessive vertical shocks. This function is based on the measurement of the vertical acceleration Z in both sensors. If the vertical acceleration in both sensors exceeds a threshold level, LI must be confirmed. A lamp LI comes on if the vertical shock is too high. The second function focuses on instability detection and is based on the measurement of the horizontal accelerometers X and Y in both sensors. If the characteristics of at least one of the accelerometers in the horizontal plane show instability behavior, L2 must be confirmed. Instability can be detected from a specific resonance frequency with associated level. The third function relates to derailment detection based on measurement of the vertical accelerometers in both sensors and the opening of a contact in the shock detector. If at least one of the vertical accelerometers or the shock detector indicates high shock behavior, L3 must be confirmed. A characteristic feature of a derailment event is the exceeding of a specific threshold at the level of vertical acceleration.

The acknowledgment tree defining the data path for turning on lights L1, L2 and 13, respectively, can be easily obtained from Fig. 12. The associated error tree functions are illustrated in Fig. 13. These functions will be used later in this description to interpret graphs in other figures.

It is now illustrated how reliability values evolve in the case of normal operation of the system shown in Fig. 12. Fig. 14 shows the evolution of the reliability estimate for the various system components of Fig. 12, each of which is individually covered by a specific diagnostic function. The individual graphs are to be interpreted as the output signals of a reliability allocator as defined in Fig. 4. To facilitate the interpretation of the graphs, the reliability functions are applied to an arbitrary estimated average time to defect expressed in hours. Based on standard reliability calculation methods, it can be expected with a certain probability that, for each of the functional blocks in the system component, it will fail within a certain amount of time. Each time a diagnostic block is performed on a functional block, the corresponding reliability value is reset to the initially expected average time to defect, since it is then known whether the functional block is still operational or not, as in the graphs can be seen. Some functional blocks are tested less often than others, which leads to higher variation in their reliability value.

Fig. 15 illustrates the overall and intermediate reliability estimate for the detection function of excessive shocks through the system. The individual graphs (for Sensor 1 (S1), Sensor 2 (S2), port [gateway] (GW), shock detector (SD), control panel (CP) and LI, respectively) can be considered as the reliability calculator output as defined in Fig.3 . The dotted line in the lower graph illustrates the theoretical lower threshold that can achieve system reliability in normal operation. If the function reliability level falls below this line, the function can no longer be used reliably. The reason for this may be that the diagnosis is no longer performed, or that the diagnosis indicates that the function no longer behaves correctly. Similar figures can be clearly obtained for the other two functions discussed above (i.e., instability detection and derailment detection).

Now an example is mentioned where accelerometer XI is defective in Sensor 1. Again, Figure 16 shows in graphical form the evolution of the reliability figure in this case. The graph corresponding to XI clearly shows a reliability drop in value at the end of the error finding interval where the diagnostics detect the problem. Since XI is not involved when excessive vertical shocks (function L1) or derailment (function L3) are detected, the defect of XI for these two functions is not reported. As a result, comparable curves of reliability figures for both functions can be obtained as in FIG. 15. However, as can be seen from Fig.17, the X1 defect has a clear effect on the reliability function output of S1. Although S1 and S2 are used for this function in a redundant scheme, it can be observed that the overall reliability of this function is greatly affected.

In the event that the recording element Z1 is defective, the detection function of excessive shocks no longer has reliability, since it is sufficient that one of the two vertical accelerometers is defective to achieve this effect. However, the detection of instability is not affected by the defect of Z1. The same applies to the derailment reliability, since there is triple redundancy on this function.

If the shock detector of the system in Fig. 12 is defective, the evolution of confidence values as shown in Figs. 18. Again the defect of the shock detector is clearly visible in the figure. Although the behavior of the shock detector is relevant to the derailment function (L3), the defect has no effect due to the triple redundancy on this function. Since the shock detector plays no role for the functions L1 and L2, they are not affected by the defect of the shock detector.

FIG. 19 shows the evolution of the reliability figures in graphical form in the event that CAN bus 2 of the system of FIG. 12 is defective. Fig. 20 shows that the confidence level of the detection function of excessive shocks is completely gone. As illustrated by Fig. 21, the confidence level of the instability detection function is lowered. There is no reliability effect for the derailment detection function.

In the event that controller 3 in the gate in Fig. 12 is defective, it is clear that the reliability levels of all three functions are severely compromised.

Fig. 22 shows the evolution of the reliability figures in the event that the control panel of the system in Fig. 12 is defective. It is not surprising that all three functions are affected by this problem. By way of example, Fig. 23 illustrates the confidence level loss for the derailment detection function. Note that due to the high error finding interval, the detection of a defective control panel takes a long time.

In a following example, a case is considered where the recording elements X1 and Z2 of the system in Fig. 12 are defective. Fig. 24 shows the corresponding evolution of reliability figures. Fig. 25 shows that the defect on X1 has no effect on the functionality of the excessive shocks, but the defect of Z2 makes the function no longer reliable. In Fig. 26 the effect is reversed. Here, the defect on XI causes a great effect on the reliability of the instability detection function.

Now a scenario is considered in which the error finding interval on registration element Z1 of the system in Fig. 12 is substantially increased. The evolution of reliability figures is shown in Fig. 27. Although there are no errors in the system, the detection reliability of excessive shocks still falls below the minimum threshold (see Fig. 28). This illustrates that the system is capable of detecting the case that diagnostic tests (manual or automated) are not performed on time.

A further example relates to a case where the recording element Z1 and the shock detector are defective. The defect of the elements is clearly visible in Fig. 29. The effect on the function of excessive shocks is a large decrease in reliability, as shown in Fig. 30. It is up to the definition of the diagnostic functionality to decide whether the decrease is low threshold or not. In this case, the function still works correctly, but shows that parts of the subsystem could fail and require maintenance.

Although the invention has been illustrated and described in detail in the figures and previous description, such illustration and description are to be considered as illustrative or exemplary and non-limiting. The foregoing description provides details of certain embodiments of the invention. It will be understood, however, that no matter how detailed the foregoing may appear in text, the invention may be practiced in many ways. The invention is not limited to the disclosed embodiments.

Other variations on the disclosed embodiments can be understood and accomplished by those skilled in the art in carrying out the invention for which protection is sought, from a study of the figures, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" does not exclude a number. A single processor or other unit can perform the functions of various items listed in the claims. The mere fact that certain provisions are listed in mutually different dependent claims does not indicate that a combination of these provisions cannot be used to advantage. A computer program can be stored / distributed on a suitable medium, such as an optical storage medium or an integrated medium provided together with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Reference numbers in the claims may not be interpreted to limit the scope of protection.

Claims (15)

Conclusions An apparatus (106) for determining a confidence measure for a given function performed by one or more functional blocks of a system component to be evaluated (105, 120, 130, 140), said apparatus comprising - input means (200) for receiving, for each functional block that contributes to execution of said given function, one or more pieces of information each representing a state of the respective functional block of a system component to be assessed, said functional block being involved in performing a given function, - a module (201) placed for classifying said states, obtaining diagnostic test interval information, and determining a reliability estimate of functional blocks for each of said functional blocks based on said diagnostic test interval information and / or said classified states, - calculation means (202) adapted for or determining a reliability measure for said given function performed by said one or more functional blocks on the basis of said reliability estimates of one or more functional blocks, decision means (203) to derive a decision from said reliability measure for said given function, - output means (204) to feed said decision in a format adapted to a physical interface of said system component. The device of claim 1, wherein said module for classifying said states comprises one or more first classifiers operatively based on a threshold level. Device as claimed in claim 1 or 2, wherein said module comprises an internal clock for carrying out time display. The device of claim 1 or 2, wherein said module is positioned to receive an external clock signal for outputting time. Device according to one of the preceding claims, implemented in an FPGA, an ASIC or with separate hardware components. Device as claimed in any of the foregoing claims, wherein said module is adapted to generate a time indication on the basis of a level transition, of a rising or falling edge, of specific protocol agreements or of the signal edges. The device of any preceding claim, comprising an output state assessor (203) disposed for evaluating said confidence measure. The device of claim 7, wherein said output status assessor comprises at least one second classifier for performing said evaluation. The device of any one of the preceding claims, comprising an internal diagnostics infrastructure (205) arranged to monitor internal processes in said device. The device of any preceding claim, comprising a configuration infrastructure block (206) for setting parameters of said input means and / or said module. Apparatus according to any of the preceding claims, comprising an output interface (204) for transmitting said confidence measure. 12. System comprising one or more devices according to one of the preceding claims and a number of system components, wherein each of said system components comprises one or more functional blocks adapted to perform one or more functions. A method for determining a confidence measure for a given function determined by one or more functional blocks of a system component to be assessed (105, 120, 130, 140), the method comprising: - receiving, for each functional block that contributes to execution of said given function , of pieces of information each representing a state of the respective functional block of a system component to be evaluated, said functional block being involved in performing a given function, - classifying said states - obtaining diagnostic test interval information - determining a reliability estimate of functional blocks for each of said functional blocks on the basis of said diagnostic test interval information and / or of said classified states, - determining a reliability measure for said given function performed by said one or more functional blocks based on said reliability estimates of one or more functional blocks, - deriving a decision from said reliability measure, - sending said decision in a format adapted to a physical interface of said system component. A program executable on a programmable device containing instructions that, when executed, perform the method of claim 13. A method for improving a system comprising a number of system components, wherein each of said system components comprises one or more functional blocks disposed for performing one or more functions, comprising: - providing a device according to any of claims 1- 11, - defining, for each functional block that contributes to the execution of said given function, one or more states of the respective functional block of a system component to be assessed, - performing the steps of the method of claim 13, using one or more pieces of information each representing one of the states, - improving said system component to be assessed according to said decision