Patent ID: 12216448

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of embodiments of the present invention. Generally, this application is intended to cover any adaptations or variations of the specific embodiments discussed herein.

DETAILED DESCRIPTION

FIG.1shows a schematic flow diagram illustrating a method for determining an optimal system configuration out of a plurality of candidate system configurations.

In a step S10, data indicating a plurality of candidate system configurations for a system to be considered or designed or to be produced are received, e.g. by an input interface of a computing device.

In a step S20, at least one quantitative dependability metric value for each of the plurality of candidate system configurations is determined, wherein the at least one quantitative dependability metric value for each of the plurality of candidate system configurations is based ona) a dependability property fulfilment value Xijfor each of a list of dependability properties “i” for each individual candidate system configuration “j” and further based onb) a dependability property weighting factor Kifor each of the list of dependability properties “i” for all of the plurality of candidate system configurations “j”.

In an embodiment, as has been described in the foregoing, the at least one quantitative dependability metric value may be a single dependability priority number DPNjfor each of the candidate system configurations “j”. The dependability priority number DPNjmay be calculated in any of the ways that have been previously described. Desirably, DPNj=ΣiXij*Ki.

Step S20may comprise at least one sub-step S20-iof determining a dependability property fulfilment value Xijfor one of the dependability properties “i” for at least one of the candidate system configurations “j” (for all of the candidate system configurations “j”), and may comprise sub-steps S20-iof determining the dependability property fulfilment value Xijfor all of the dependability properties “i”. Any known methods may be employed for this as will be explained in greater detail in the following.

Each sub-step S20-imay comprise sub-steps of identifying (or: eliciting, or receiving) goals of stakeholders, determining relevant scenarios based on the identified goals, identifying (or: eliciting) functional requirements based on the determined scenarios, and determining properties (such as a Risk Priority Number RPN, a Safety Integrity Level SIL and/or the like) of the candidate system configurations “j” based on the identified functional requirements, as will be explained in more detail in the following.

The sub-steps of identifying goals, determining relevant scenarios, identifying functional requirements and determining properties may also be performed once for all dependability properties “i” jointly.

Alternatively, or additionally, any or all functional requirements may also be received from an external source such as a domain authority.

In a step S30, an optimal system configuration out of the plurality of candidate system configurations “j” based on a quantitative comparison between the at least one quantitative dependability metric value for each of the plurality of candidate system configurations “j”. This step may also be designated as a “trade-off analysis”, as the information implicit in the determined quantitative dependability metric value is used to analyze the candidate system configurations and to determine the optimal one.

In an embodiment, when the quantitative dependability metric value is the dependability priority number DPNj, the optimal system configuration is determined based on a comparison of the dependability priority numbers DPNj. In some variants, the candidate system configuration “j” with the highest dependability priority number DPNjis determined as the optimal system configuration.

In other variants, e.g. when the dependability priority numbers DPNjare to be compared digit by digit, rules may be established according to which the optimal system configuration is determined based on the respective dependability priority numbers DPNj. In the above-described variants where each digit of the dependability priority number DPNjindicates fulfilment of a goal for a specific dependability property “i”, a hierarchy may be set according to which the digits of the dependability priority numbers DPNjfor various candidate system configurations “j” are compared with one another.

For example, first the third digit of the dependability priority numbers DPNjmay be compared and the candidate system configurations “j” may be selected with the highest value therein, next from the selected candidate system configurations “j” the second digit of the dependability priority numbers DPNjmay be compared and so on until one or more optimal candidate system configurations “j” are found. The order of consideration for the digits of the dependability priority number DPNjcorresponds to a hierarchy of importance, or priority, assigned to the individual digits and thus to individual dependability properties “i” in this example.

Optionally, the method may further comprise a step S40of generating an output signal based on the determined optimal system configuration, a step S50of transmitting the output signal to a producing machine, and a step S60of controlling the producing machine, by the output signal, to produce the determined optimal system.

FIG.2show a schematic block diagram for illustrating a system1000for determining an optimal system configuration out of a plurality of candidate system configurations, according to an embodiment of the second aspect of the present invention.

The system1000comprises a computing device100. The computing device100comprises an input interface110, a processor120, a memory130and an output interface140.

The input interface110is configured to receive an input signal71comprising data indicating a plurality of candidate system configurations, in particular as has been described with respect toFIG.1and step S10.

The computing device100(in particular the processor120in operative connection with the memory130, for example by the processor120executing program instructions stored in the memory130) is configured to implement a dependability metric module122and a optimizing module124.

The dependability metric module122is configured to determine at least one quantitative dependability metric value (the dependability priority number DPNj) for each of the plurality of candidate system configurations “j”,wherein the at least one quantitative dependability metric value for each of the plurality of candidate system configurations “j” is based ona) a dependability property fulfilment value Xijfor each of a list of dependability properties “i” for each individual candidate system configuration “j”; and further based onb) a dependability property weighting factor Kifor each of the list of dependability properties “i” for all of the plurality of candidate system configurations “j”.

The dependability metric module122may perform these actions as has been described with respect toFIG.1and step S20in the foregoing.

The optimizing module124is configured to determine an optimal system configuration out of the plurality of candidate system configurations “j” based on a quantitative comparison between the at least one quantitative dependability metric value for each of the plurality of candidate system configurations, as has been described with respect toFIG.1and step S30in the foregoing.

The output interface140is configured to output an output signal72indicating the determined optimal system configuration.

The system1000may comprise a producing machine200(or, alternatively or additionally, a gathering machine, a composing machine and/or the like) to which the output signal72is transmitted. The output signal72and the producing machine200(and/or other machines of the sort) are configured such that the producing machine200is controlled by the output signal72to produce the determined optimal system (or, respectively, to gather corresponding (e.g. raw) materials or components, to compose a text regarding the determined optimal system and/or the like).

FIG.3shows a schematic dataflow for determining the dependability priority number DPNjin one possible embodiment.

“Goal” inFIG.3indicates the optional elicitation of the goals of the stakeholders. Here the typical goal graph methods, such as goal structure notation, i* for Non-Functional Requirements etc. may be used.

The goals may comprise target values for any or all of the dependability properties “i” and/or goals influenced or affected by the dependability properties “i”.

A coarse trade-off analysis among the identified goals could be performed already at this step, in order to identify the possible dependencies and conflicts. This trade-off analysis could be done by use of goal graph methods.

Based on the identified goals, the relevant scenarios with certain execution sequences will be determined (“Scenario” inFIG.3).

Such sequences including the sequence of stimulus, response in connection with ports, data, and environments, are e.g. described in “Elahi et al.”. The scenarios define the circumstance in which the candidate system configurations (or: design alternatives) are made. An example of such scenarios is “robot X shall be stopped when safety bumper is engaged”. Scenarios define the aims and scope of the trade-off analysis.

Functional requirements may then be elicited based on the identified scenarios. For safety-critical systems, it is possible that the functional requirements, hazards (to be handled by the designated system) and their tolerable hazard rate THR are given by the domain authorities. The method may thus comprise receiving a signal indicating functional requirements, hazards and/or tolerable hazard rates THRs; such a signal may also be received by the input interface110of the system1000.

The trade-off analysis may thus also be performed without explicitly defining the goals and scenarios additionally for any system or component that have been defined clearly be the domain authorities in the signal. If there are no such standardized requirements and their tolerable hazard rate THR, the functional requirements are to be elicited.

Based on the identified functional requirements (or: demands), properties of the candidate system configurations “j” will be determined. For example, a functional hazard analysis or function-based FMEA will be performed. The corresponding hazards, their Risk Priority Numbers RPN, their Safety Integrity Level SIL, and available measures can thus be identified. For fulfilling the previously set goals (e.g. Safety Integrity Level SIL) additional measures could be identified.

In the conventional art, required measures for fulfilling the predefined Safety Integrity Level SILs are assessed by a risk assessment only once. Normally the evidence of the fulfillment of the Safety Integrity Level SIL (safety requirement) is described implicitly by the risk assessment.

But there is no indication available in the conventional art whether this measure is the most suitable one and whether the introduction of this measure could harm the fulfilment of other dependability properties (such as Availability) or not. Embodiments of the present invention solve these issues by considering a plurality of candidate system configuration and performing a trade-off analysis thereon.

In the given example, where there is no further information about the system components and their failure rates, a qualitative FMEA or FHA will be performed for each of the candidate system configurations such that the improvements of the quality in Safety Integrity Level SIL or Risk Priority Number RPN of the alternative could be compared with the first measure. The rest steps of a qualitative trade-off analysis will be performed, wherein the possible conflicts to other dependability availability could be identified. In these steps the expert estimation is required.

The individual candidate system configurations may correspond to different suggested or known measures for dealing with a given issue, as will be explained in more detail in the following.

Determining the dependability property fulfilment values in the at least one sub-step S20-imay be based on, e.g. any or all of the following trade-off criteria:an actual value;an expected value;an acceptable upper limit;an acceptable lower limit;an evaluation of a benefit of the actual value;an evaluation of a drawback of the actual value;a cost of improving the actual value towards the expected value;a time-to-achievement of the improving;overall acceptance;further action.

The actual value may be obtained by Functional Hazard Analysis, Risk Priority Number through Failure Mode and Effect Criticality Analysis FMECA qualitatively, or quantitatively by the Failure Mode and Effect Diagnostic Analysis FMEDA, Component Fault Tree Analysis CFTA, Fault Tree Analysis FTA, or other quantitative dependability techniques.

For fulfilling the predefined quality goals (e.g. Safety Integrity Level SIL) additional measures could be identified. Normally the additional required measures for fulfilling the predefined Safety Integrity Level SIL are assessed by a risk assessment agency or module only once, and the evidence of the fulfillment of the Safety Integrity Level SIL (safety requirement) is described implicitly by the risk assessment.

The results of such analyses will be used for the rest of the quantitative dependability trade-off analysis as set forth herein. For example, a Failure Rate and a Safety Integrity Level SIL may be determined and/or calculated and then used for determining the dependability property of “Safety”. A Mean Time Between/To Failure may be determined and/or calculated and then used for determining the dependability property “Reliability”. An availability value may be determined and/or calculated and then used for determining the dependability property “Availability”. A Mean Down Time may be calculated and/or determined and then used for determining the dependability property “Maintainability”, and so on.

For example when Component Fault Tree CFT is chosen as trade-off analysis technique, quantitative details about the system to be considered are available. Different measures (reflected in, or realized by, different candidate system configurations) that affect the basic system design can be identified. Such measures are for example implementing additional redundancy, adding a monitoring mechanism etc. They have clear and defined influences on the architecture of the system to be considered (or evaluated). The resulting candidate system configurations resulting from the different measures (and optionally also a basic system to be modified by the measures) are than modeled by the Component Fault Tree CFT.

The calculated results for dependability parameters such as Mean Time to Failure MTTF, Failure Rate λ (lambda), Availability value A, Mean Down Time MDT etc. are then used for comparing the candidate system configurations. For example, for the dependability property “Safety”, calculated (and/or even qualitative) Risk Priority Number RPN, Safety Integrity Level SIL, Mean Time to Failure MTTF, Failure Rate λ (lambda) and/or the like may be used as actual value. A corresponding expected value is typically predefined either by the authorities or by the references systems.

The dependability property fulfilment value is then determined based on trade-off criteria, at least based on the calculated and/or determined actual value and the expected value. For example, the dependability property fulfilment value may be based on a quotient, or a percentage, of the actual value with respect to the expected value, in particular directly proportional to the quotient or percentage.

However, additional trade-off criteria may be used to determine the dependability property fulfilment value, such as limits (or: thresholds).

For the dependability property “Safety”, i.e. in the safety domain, the acceptable lower limit may e.g. be set as the predefined expected value. It is however also possible, a feasibility safety study of the system is the goal of the project, in this case the acceptable lower limit will be the expected acceptable lower limit.

In embodiments or variants where Failure Mode and Effect Diagnostic Analysis FMEDA is employed for determining a Safe Failure Fraction SFF (for estimation of the Safety Integrity Level), the Failure Mode and Effect Diagnostic Analysis FMEDA may be performed at least once for each candidate system configuration.

The calculated Safe Failure Fractions SFF and the corresponding Safety Integrity Levels SIL may then be used as respective actual value for comparison to an expected value in order to determine at least one of the dependability property fulfilment values Xij.

In case a basic system configuration is set as a starting point (and also as one of the candidate system configuration, i.e. it is possible that no change at all is advised after the trade-off analysis), and a number of possible modifications resulting in candidate system configurations is considered by the method according to an embodiment of the invention, and when a measure neither leads to architecture changes nor to a structural change in the fault tree, the changed availability will be captured by e.g. the changed Mean Down Time.

For example, a warning contact may be provided to output a warning output signal indicating whether a brake of the train is worn out (has “worn out” status); for instance, the warning output signal may indicate a logical “HIGH” when the brake has the “worn out” status and a logical “LOW” when the brake does not have the “worn out” status.

Different system configuration candidates may, in this example, relate to which measures are to be taken when the output signal of the warning contact indicates the brake having the “worn out” status.” One candidate system configuration may be the basic system configuration which is set up such that the measure is “stopping the train”. Another candidate system configuration may be set up such that the measure is setting the train into a “low speed drive” mode.

The first measure of “stopping the train” heavily affects the dependability property “availability” negatively such that the dependability property fulfilment value Xijfor the dependability property “availability” is determined to be 0 (indicating “totally unacceptable”); moreover, the measure of “stop” provides no remarkable improvement on the dependability property “Safety” compared to the measure “low speed mode”.

On the other hand, the measure “low speed drive” is sufficient (regarding the dependability property “Safety”) to handle the warning output signal indicating the “worn out” status of the brake. The “low speed drive” can thus replace “stopping the train” as measure in case of the output signal being “HIGH”.

This change will clearly improve the dependability property “availability” of the train. This change does not necessarily change the structure of the fault tree of the train, but down time will be reduced. The reduced down time will affect the calculation of the dependability property “availability” A positively because of A=MTBF/(MTBF+MDT), wherein MTBF is the Mean Time Between Failures which remains unchanged and MDT is the Mean Down Time which is reduced.

In this way, the availability comparison between the basic system configuration with the measure “stopping the train” and new solution “low speed drive” can be done even without changing the fault tree structure.

The following categories made be provided for the trade-off criteria to be used for evaluating the alternative candidate system configurations:a) benefit of better actual values:i) none;ii) longer useful life time because of higher quality;iii) better reliability or availability of the system;iv) potential public image benefit;v) eventually better sale price.b) drawback of worse actual values:i) none;ii) no certificate;iii) financial disaster;iv) worse availability;V) damage of public image;vi) postponement of the project finish time;vii) increased purchase cost.c) cost for improvement towards expected value:i) none;ii) ignorable;iii) proportional;iv) quite high;v) too high.d) time to achieve the expected value:i) none;ii) ignorable;iii) proportional;iv) quite long;V) too long.e) further action:i) noneii) redundancyiii) use of higher quality componentiv) development of new component

Based on the trade-off criteria, the following acceptance level values (i.e. numerical values for the dependability property fulfilment values Xij) may be defined:i) 0: totally unacceptable;ii) 0.2: almost unacceptable;iii) 0.4: predominantly unacceptable;iv) 0.6: predominantly acceptable;V) 0.8: almost acceptable;vi) 1: totally acceptable

The respective weighting factors Kifor the dependability properties “i” may be set based on an expert opinion and on an importance of the individual dependability properties “i” for the system to be considered.

In some advantageous embodiments, one principle for defining the acceptance level values as well as the dependability property weighting factors Kiis to make the differences in the dependability priority number DPNjbetween two alternative candidate system configurations “j” big enough and to avoid possible mutual counterweighing or compensating among the evaluation results.

For example, the following dependability property weighting factors Kimay be set:a) “Safety”: i=1, K1=100;b) “Reliability”: i=2, K2=10;c) “Availability”: i=3, K3=1;d) “Maintainability”: i=4, K4=0.1;e) “Security”: i=5, K5=0.01.

Combined with e.g. the discrete acceptance level values of 0, 0.2, 0.4, 0.6, 0.8 and 1 defined above for the dependability property fulfilment values Xij, this ensures that no change in any of the dependability property fulfilment values Xpj(with i=p) can outweigh, or compensate, as far as the total value of the dependability priority number DPN is concerned, a change in any of the dependability property fulfilment values Xrj(with i=r) when r<p.

In this embodiment, the smaller the value of “i” is, the more significant is the corresponding dependability priority “i”. In the described example, the dependability property “Reliability” will be considered for deciding between a candidate system configurations “j′” and a candidate system configuration “j″” when the two candidate system configurations “j′” and “j″” yield e.g. the same dependability property fulfilment value for the dependability property “Safety”, i.e. X1j′=X1j″.

With the dependability property weighting factor Kias defined above, as well as with the acceptance level values defined above for the dependability property fulfilment values Xij, the maximum possible dependability priority number DPNjis then 100*1+10*1+1*1+0.1*1+0.01*1=111.11.

As one possible application, in certain instances an increase of the dependability property fulfilment value X1jfor the dependability property “Safety” may occur together with a decrease in the dependability property fulfilment value X3jfor the dependability property “Availability”. Using the dependability priority number DPNj, it is possible to represent such potentially negative inter-dependencies of the dependability property fulfilment values Xij. The selection of the optimal system configuration may be made based on (or: determined by) the highest dependability priority number DPNjand/or based on (or: determined by) the highest value of a dependability property fulfilment value Xijwith the highest priority (e.g. based on the highest dependability property fulfilment value X1jfor the dependability property “Safety” instead of e.g. the highest dependability property fulfilment value X2jfor the dependability property “Reliability”).

Determining S30the optimal system configuration out of the plurality of candidate system configurations “j” may be performed based on a comparison of the total numeric value of the dependability priority number DPNj. The highest numeric values of the dependability priority number DPNjcorresponds to the best overall dependability (according to the previously defined values and criteria) of the candidate system configuration “j”.

Determining S30the optimal system configuration may in some embodiments consist of determining the candidate system configuration “j” with the highest dependability priority number DPNj. In other advantageous embodiments, comparing the dependability priority numbers DPNjmay only be part of determining S30the optimal system configuration.

For example, determining S30the optimal system configuration may comprise determining the first N (N being a pre-set integer value) candidate system configurations “j” with the N highest dependability priority numbers DPNjand then performing at least one additional analysis on the group of N candidate system configurations “j” selected in this way. The final decision which of the candidate system configurations “j” to select may then be further based e.g. additionally on the determined actual values of trade-off criteria. For instance, the Mean Time to Failure may be compared between the candidate system configurations “j” in the selected group, and the candidate system configuration “j” with the highest Mean Time to Failure may then be determined as the optimal system configuration.

An embodiment of the method may e.g. be performed by a portable computing system, e.g. a laptop or a portable edge device connected to a cloud computing platform. In a discussion with a current or potential customer, the customer may elicit goals or demands for a system to be designed. A user of the embodiment of the method may then model these goals and demands into the different trade-off criteria. The method then presents the user with e.g. a list of N candidate system configurations “j” that are available for achieving the goals and satisfying the demands of the customer. This task may otherwise, without the method, have been impossible to complete because after a certain number of goals and variable parameters the possible combinations require a prohibitive amount of computing power and memory.

However, in alternative embodiments, the dependability priority numbers DPNjmay be calculated as described in the foregoing, but comparisons of different dependability priority numbers DPNjare performed digit-wise, i.e. by comparing each digit of the dependability priority number DPNjseparately.

FIG.3shows a schematic block diagram illustrating a meta-model with data flows based on the workflow as described in the foregoing.

Malfunctions and hazards may be identified, for example, by use of functional hazard analysis FHA based on the determined functional requirements. Based on hazards and/or risk values, measures may be identified.

In a traditional safety analysis, only one measure for mitigating the risk of certain hazard is necessary. A sufficient measure is able to reduce the risk to the pre-defined acceptable level. However, for the overall dependability of a candidate system configuration implementing a specific measure it is necessary to know whether all the dependability properties “i” are fulfilled or not, and optionally to which degree.

Therefore, the trade-off analysis proposed herein is performed for different candidate system configurations “j”, e.g. design alternatives. Design alternatives could be caused by different actuators being provided. The alternative measures could also consist of, or comprise, alternative treatments of one of such actuators. These alternative measures can be analyzed, one by one (in parallel) to determine which one fulfils the most of the dependability properties “j”. The measures could be for example redundancy (providing two sensors for the same task) or extra monitoring of a single sensor, both of which could be used to mitigate the risk of a certain hazard such as a “false positive” of the sensor or a “false negative” of the sensor.

The parameters, or trade-off criteria, used to determine the dependability property fulfilment values Xijfor alternative measures realized by different candidate system configurations may be results of qualitative or quantitative analyses. Such analyses are also possible after the dependability priority numbers DPNjhave been determined and compared, in order to further differentiate between different candidate system configurations “j” and/or to better understand at least one of the candidate system configurations “j”.

A qualitative analysis may comprise a functional hazard analysis FHA or Failure Mode and Affect Analysis FMEA for determining the reduced Risk Priority Number RPN or Safety Integrity Levels SIL resulting from the use of different measures in different candidate system configurations “j”. Such results are represented as RPNjand SILjfor, respectively, each candidate system configuration “j”.

A quantitative trade-off analysis may comprise repeated Failure Mode and Effect Diagnostic Analysis FMEDA or (Component) Fault Tree (C)FT Analysis for calculating the Failure Rates λj(lambda), Mean Time To Failure MTTFj, Mean Time Between Failures MTBFj, Availability Aj, Mean Down Time MDTjand/or the like.

Through the comparison of the Failure Rates λj(lambda) for all candidate system configurations “j”, for example, the safer and/or more reliable measure can be identified. Further the comparison of aforementioned values could contribute to an overall evaluation of the dependability properties “i”.

In the end, the actual value closest to the corresponding expected value will be considered as the more dependable value. Accordingly, in many variants the dependability priority number DPNjclosest to the expected value DPNexpectedfor the dependability priority number DPN (e.g. 111.11 as has been described in the foregoing)

The calculation of the expected value DPNexpectedand the actual value DPNj(which may be, more explicitly, designated as DPNjactual) are, as has been described in the foregoing, calculated by DPNj=ΣiXij*Ki, wherein the dependability property fulfilment values Xijare based on the evaluation of the trade-off criteria as mentioned previously.

In some advantageous embodiments, the expected value DPNexpectedfor the dependability priority number DPN, and the actual values DPNjfor the various candidate system configurations “j” are then used further to determine whether the DPNj≥DPNj≥DPNexpected: if this is the case, all the demands on the dependability properties “i” (or: goals) are fulfilled. If this is not the case, at least one, or even all, of the demands on the dependability properties “i” (or: goals) are possibly not fulfilled.

Which dependability property DPNjor dependability properties DPNj, DPNk, . . . are not fulfilled can be identified e.g. by comparing the expected value DPNexpectedwith the actual values of the dependability priority number DPNjfor a candidate system configuration “j” under analysis.

As has been described, in advantageous embodiments the allowed values of Xijand the dependability property weighting factors Kiare chosen such that each digit of the dependability priority number DPNjclearly corresponds to one of the dependability properties “j”, and the trade-off analysis does not only compare the overall numeric value of the dependability priority number DPNjbut each of its digits individually.

In this case, advantageously the expected value DPNexpectedmay encode thresholds for the individual dependability properties “j” that are at least to be met, and exceeded. For example, the dependability property weighting factors Kimay be defined as above, wherein the individual weighting factors Kidiffer from one another by factors that are powers of 10, and in particular, where there is only a factor of 10 between each pair of adjacent dependability property weighting factors Ki, Ki+1(i.e. Ki=10 Ki+1). Furthermore, the values of the dependability property fulfilment values Xijmay be allowed to be only in the range between 0 and 1, wherein 0 is included and wherein 1 may be included or excluded.

Then, when e.g. it is determined that the dependability property fulfilment of the dependability properties “Safety” (i=1), “Reliability” (i=2), “Maintainability” (i=4) and “Security” (i=5) must all be “totally acceptable” (corresponding to the dependability property fulfilment value X1j=X2j=X4j=X5j=1), and when it is further determined that it is sufficient if the dependability property fulfilment of the dependability property “Availability” (i=3) is “predominantly acceptable” (corresponding to the dependability property fulfilment value X3j=0.6), then the expected value DPNexpectedfor the dependability priority numbers DPNjmay be not 111.11 as above but instead DPNexpected=110.71.

If in these embodiments the individual digit of the dependability priority number DPNjis larger than, or equal to, the expected individual digit of the expected value DPNexpectedthen fulfilment of the demands on that dependability property “i” is proven, otherwise the demands on that dependability property “i” are not fulfilled.

The unfulfilled dependability property demands thus require at least one further measure until all fulfilled. In the end all the demands on all the dependability properties “i” shall in the ideal case be fulfilled.

It is possible that there are conflicts by fulfilling demands on different dependability properties: for example, the fulfilment of demands on the dependability property “Safety” in certain circumstances decreases the availability. This happens, in the above example with the potential measures for dealing with an output signal of a brake warning contact of a train, for example if the train is stopped for certain safety reasons, which in turn means an immediate reduction of the dependability property “Availability”.

In addition, both the dependability properties “Reliability”and “Availability” may have a negative influence on the dependability property“Maintainability”—for example, systems with more redundancy are in general more reliable and thus more available but the redundancies decrease ease of maintenance and/or increase the time needed for the maintenance.

It is also possible, that actually not all of the demands on all of the dependability properties “i” can be fulfilled, but this could also be a result that the stakeholders would like to know/achieve.

For instance, for a system under development, a capability study of the fulfilment of certain demands on the dependability property “Safety” or other dependability properties could be essential. In other words, a product certification feasibility of an existing system towards Safety Integrity Level SIL 2 and λ (lambda) of 10−6/h could be investigated.

After the investigation, the result could be that the demands of certification of Safety Integrity Level SIL 2 and of a λ (lambda) of 10−6/h cannot both be fulfilled for the current version of the product. If the certification is not a mandatory requirement, this analysis result may already be sufficient, and may save numerous hours of experimental testing and tweaking.

Here the decisions of acceptance and/or where to stop the analysis can be made based on the comparison of the individual dependability priority numbers DPNjand the expected value DPNexpectedfor them, and even on the comparison of the individual dependability priority numbers DPNjbetween alternative measures, i.e. candidate system configurations “j”.

Further a prioritization of the measures (i.e. candidate system configurations “j”) may be made based on the individual dependability priority numbers DPNj.

Not only quality goals and functional requirements are possible objects of the trade-off analysis; also design artefacts and maintenance artefacts are potential objects. Design artefacts offer e.g. design alternatives. Maintenance artefacts may e.g. be a number of maintenance teams and/or a possible maintenance strategy as conditions which also play a role in determining a maintenance priority number (basically the calculable Mean Down Time MDT).

In the following, the previously mentioned example of a brake warning contact will be used to describe additional advantageous options and variants of embodiments of the method ofFIG.1.

Ideally, the brake warning contact is supposed (functional requirement) to send a warning signal to a dashboard (in the train and/or in a remote operating facility for the train) and set the train to a “degraded mode”.

Next, a Failure Mode and Effect Criticality Analysis FMECA (and/or Functional Hazard Analysis and/or Failure Mode and Effect Analysis FMEA as shown inFIG.2) may be performed to identify measures.

Based on the identified functional requirement, possible failure modes and measures will be determined. In addition, the Risk Assessment may also be performed. The Failure Mode and Effect Criticality Analysis FMECA for dependability analysis may be different from a traditional Failure Mode and Effect Criticality Analysis FMECA, because more than one measure for the same failure mode could be identified. The effects of the different measures are then compared qualitatively through the comparison of the improved Risk Priority Number RPN and quantitatively through the comparison of the dependability priority number DPN based on i.e. quantitative component fault tree analysis.

In the present example, two main types of measures will be considered to have been identified:M1: redundancy(providing more than one brake warning contact)M2: monitoring(monitoring the state of health of the brake warning contact)

FIG.4shows a schematic and exemplary table of calculated values for these two measures M1 and M2. “Current RPN” and “New RPN” indicate current and new (after the corresponding measure) “Risk Priority Number”; “Current P” and “New P” indicate current and new (after the corresponding measure) “Probability of Failure”; “Current D” and “New D” indicate current and new (after the corresponding measure) “Probability of Detection” of an error; and “Current S” and “New S” indicate current and new (after the corresponding measure) “Severity” or the error.

These two measures M1, M2 are compared according to the dependability goals. The new Risk Priority Numbers RPN (“New RPN”) according to each measure M1, M2 will be compared. However, at this stage, the performed Risk Assessment result could be misleading. For example, in the risk assessment illustrated inFIG.4, the Risk Priority Number of the monitoring measure M2 is 16 which is lower (and thus better) than the Risk Priority Number of 56 of the redundancy measure M1.

However, the quantitative analysis later on will show that the redundancy measure M1 is the only approach that fulfils all the set dependability goals. It may thus be arranged that the qualitative analysis shall be verified by the quantitative analysis.

To perform a quantitative dependability analysis, the Failure Mode and Effect Diagnostic Analysis FMEDA for the two measures M1, M2 may be first performed. Through the Failure Mode and Effect Diagnostic Analysis FMEDA the dangerous undetected failure rates can be identified. For example, the dangerous undetected failure rate of the redundancy measure M1 may be 5 FIT, the dangerous undetected failure rate of the monitoring measure M2 may be 1 FIT.

The Failure Rate (measured in Failures In Time FIT) of a device is the number of failures that can be expected in one billion (109) device-hours of operation, (e.g. 1000 devices for 1 million hours, or 1 million devices for 1000 hours each, or some other combination.) The relationship of FIT to Mean Time Between Failures MTBF may be expressed as MTBF=109device-hours=1/FIT.

The above Failure Rates are then used to calculate the system overall Failure Rate. The goal of the calculation is to determine which failure rate with candidate system configuration “j” leads to a lower (i.e. better) failure rate.

Next, Component Fault Tree Analyses CFT for the following candidate system configurations j=1, j=2, j=3 may be performed:

First, we will consider the case of j=1 corresponding to the basic system without any additional measure: the failure rate of the function “brake warning contact” is 5 FIT.

Because the redundancy measure M1 (j=2) does not include or provide any additional detection and control mechanism to reduce the failure rate, the failure rates of the function “brake warning contract” for the case without measure (j=1) and for the case with the redundancy measure M1 j=2) are the same.

But for the monitoring measure M2 (j=3), the dangerous undetected failure rate of this function decreases, in the present example to 1 FIT. The assumption for this effect is that the monitoring detects 90% dangerous failure. In summary, the failure rate used in the Component Fault Tree Analysis CFT of the redundancy measure M1 (j=2) is 5 FIT. The failure rate used in CFT for the monitoring measure M2 (j=3) is 1 FIT.

FIG.5shows a schematic Component Fault Tree for the candidate system configuration without measures (j=1) which illustrates the either a failure of the power supply (lower left: “Power supply fails”) of an electric brake of the train, and/or (see logical “OR” inFIG.5) a failure (lower right: “brake warning contact fails”) of the brake warning contact may result in the effect “electric brake fails”.

The element “power supply fails” may have its own Component Fault Tree as shown inFIG.6, according to which the power supply comprises two individual power supplies1and2and only fails when both of them (see logical “AND” inFIG.6) fail. InFIG.6, a failure rate for each individual power supply is illustrated to be assumed to be 10 FIT.

Similarly,FIG.7shows a possible Component Fault Tree for the element “brake warning contact fails”: this may be either the result of the break warning contact cable being broken (lower left, assumed dangerous undetected failure rate of 5 FIT) and/or (see logical “OR”) of the brake warning contact sensor itself being defect (lower right, assumed dangerous undetected failure rate of 5 FIT).

Based on the Component Fault Tress ofFIG.5throughFIG.7and the assumed failure rates therein, and with the assumption of a Mean Down Time of 24 hours and mission time of 8760 hours, a Mean Time Between Failures MTBF for the dependability property “Reliability”, an Availability value A for the dependability property “Availability”, a Mean Down Time MDT value for the dependability property “Maintainability” and a total Failure Rate value for the dependability property “Safety” can be calculated. The complete Component Fault Tree for the system without additional measure (j=1) with a corresponding RAMS analysis is schematically shown inFIG.8.

RAMS is an acronym for Reliability, Availability, Maintainability, and Safety. According to common definitions:“Reliability” is an ability of a system to perform a specific function and may be given as design reliability or operational reliability;“Availability” is the ability of a system to be kept in a functioning state;“Maintainability” is determined by the ease with which the system can be repaired or maintained;“Safety” is the requirement not to harm people, the environment, or any other assets during the life cycle of the system; and“Security” is the ability of the system to withstand attempts to compromise the integrity of its data or signals (e.g. attempts to access, steal, corrupt, or manipulate data or signals).

Next, we will consider the candidate system configuration j=2, wherein the redundancy measure M1 has been adopted.

With the redundancy measure M1 (j=2), the brake warning contact has been cloned and attached onto the OR-gate of the Component Fault Tree. Because of the redundancy, an AND-gate is added into the component fault tree. This AND-gate is then hanged under the OR-gate, seeFIG.9, which shows the analogue ofFIG.5(j=1) in the candidate system configuration j=2.

FIG.10schematically shows the analogue ofFIG.7(j=1) for the candidate system configuration j=2.

Next, we will consider the candidate system configuration j=3, wherein the monitoring measure M2 has been adopted.

With the monitoring measure M2 (j=3), the failure rate of the observed sub-system (brake warning contact) will be reduced. In the present example, it is assumed that the monitoring mechanism captures 90% of the dangerous failures such that the resulting dangerous undetected failure rate is 1 FIT.

However, the use of the monitoring mechanism introduces additional failure possibilities, because the monitoring can also fail. In this case, the brake warning contact fails if:1. the monitoring fails and the brake warning contact (9 FIT) detectably fails;
or2. the brake warning contact fails in the “dangerous undetected” way (1 FIT)

FIG.11andFIG.12illustrate this situation.FIG.11schematically shows the analogue ofFIG.5(=1) andFIG.8(j=2) for the candidate system configuration j=3.

FIG.12schematically shows the analogue ofFIG.7(j=1) andFIG.9(j=2) for the candidate system configuration j=3, with an assumed failure rate of the monitoring circuit of 10000 FIT.

The component brake warning contact is used two times, representing the two cases mentioned above. However, it is only possible to assign one failure rate to one component in the Component Fault Tree, therefore two components with slightlynaming difference are used: “brake warning contact dd” (dangerous detected) and “brake warning contact du” (dangerous undetected). The failure rate of monitoring clearly also plays a role.

It may therefore be useful to investigate the impact of different monitoring circuits (e.g. sensors or the like), in particular of monitoring circuits with different failure rates of the monitoring. Monitoring circuits with lower failure rates are generally more expensive and/or larger (have a larger footprint) so that it is often important to know if these expenses and/or size issues are worth it in terms of increased dependability.

In the following, candidate system configuration equal to the candidate system configuration j=3 are considered, but with a failure rate of 10 FIT (j=4) for the monitoring circuit and with a failure rate of 1 FIT (=5) for the monitoring circuit are considered in addition.

The reason behind this selection is that 10 FIT (=4) and 1 FIT (j=5) are the closest to the brake warning contact du (1 FIT). 10000 FIT (j=3) has been selected with the intention of producing a significant difference in the evaluation result for instructive purposes.

FIG.13shows a table collecting RAMS results for all of the five candidate system configurations j=1 . . . 5.

In a next step, the calculated values or parameters are used to determine the dependability property fulfilment values Xij. As has been described, this is done by comparing the calculated actual values for the different candidate system configurations “j” to corresponding reference values such as expected values, upper/lower acceptable limits and so on (see trade-off criteria listed above).

The followingFIGS.14to18show comparisons between expected values and actual values of respective dependability/RAMS parameters. In the present simple example, the acceptable limit is set to the expected value for simplicity. In many real-world applications, the comparison is done between the actual acceptable limit for the dependability parameters and the actual values of the dependability parameters, and the dependability property fulfilment values Xijare then based on the comparison.

For example, the expected value for the Failure Rate (as a dependability parameter mainly connected to the dependability property “Safety”) is 10 FIT, so this value is used five times for comparison (for candidate system configuration j=1 . . . 5). In each of theFIGS.14to18, square points indicate respective expected values (constant in each Fig.), and diamond-shaped points indicate the actual values of the dependability parameters for each candidate system configuration “j”.

FIG.14shows the comparison of the expected and actual values for the Failure Rates (relevant for the dependability property “Safety”) for j=1 . . . 5 (horizontal axis) in FIT.

FIG.15shows the comparison of the expected and actual values for the Mean Time Between Failures MTBF (relevant for the dependability property “Reliability”) for j=1 . . . 5 (horizontal axis) in hours.

FIG.16shows the comparison of the expected and actual values for the Availability value A (relevant for the dependability property “Availability”) for j=1 . . . 5 (horizontal axis) in percent.

FIG.17shows the comparison of the expected and actual values for a Maintainability (mean down time) value (relevant for the dependability property “Maintainability”) for j=1 . . . 5 (horizontal axis) in hours.

FIG.18shows the comparison of the expected and actual values for a Security Assurance Level (relevant for the dependability property “Security”) for j=1 . . . 5 (horizontal axis) in levels.

FIG.14clearly shows that the redundancy measure M1 (j=2) has the lowest Failure Rate. Thus, based on the Failure Rate alone, the redundancy measure M1 (j=2) is the best measure.FIG.14throughFIG.18show that, with the exception of the Security Assurance Level inFIG.18which is equal for all candidate system configuration “j” (assumed here for simplicity), the redundancy measure M1 (j=2) is quantitatively the best measure.

Next, according to the trade-off analysis criteria described in the foregoing, the dependability property fulfilment values Xijwill be calculated. In the present result, this is done simply based on the actual and expected determined dependability parameter values as shown inFIG.14throughFIG.18. It will be understood that this calculation may be more complex and may comprise a plurality of comparisons, e.g. to different threshold values (upper/lower limits etc.) for each determined dependability parameter.

The result of the present analysis is a number between 0 and 1 for the dependability property fulfilment values Xijwhich will be multiplied by the assigned dependability property weighting factor Kiof the respective dependability property “i”. In the present example, the dependability property “Safety” has the weight of Ki=100, the dependability property “Reliability” the weight of K2=10 and so on as has been described in the foregoing. These products Pij=Ki*Xijwill be summed up, and the sum is then the DPNjof the respective candidate system configuration (corresponding to at least one measure) “j”.

FIG.19shows a table illustrating some results of the previous analysis. On the left side, the expected values (here: 100, 10, 1, 0.1 and 0.01) are shown. “DPN1 (actual)” indicates the dependability priority number DPN1of the basic candidate system configuration with j=1, i.e. without any additional measures. “DPN1 (expected” shows the expected value DPNexpectedfor all of the candidate system configurations “j”. “Dependable 1?” indicates whether DPN1=88,91 is such that the candidate system configuration j=1 is considered to be dependable or not. Here the result is “No”, as in this example the difference between the actual DPN1=88,91 is too small compared to the expected value DPNexpected=111,11.

FIG.20shows results for the dependability priority numbers DPNjfor j=1 . . . 5. In the comparison of the dependability priority numbers DPNi, the #redundancy measure M1 (j=2) shows the highest value. Its DPN2is equal to the expected value DPNexpected=111,11. In the present example, then this measure (i.e. candidate system configuration j=2) is selected.

The analysis also provides the additional information that, when using monitoring circuits (j=3, 4, 5), even a significant improvement of the Failure Rate of the monitoring circuits (e.g. from 10000 FIT at j=3 to 1 FIT at j=5) does not bring any change in the dependability priority number: DPN3=DPN4=DPN5. In other words, if for some reason an expert would still decide to employ the measure “monitoring”, the expert would know that a simpler monitoring circuit with e.g. 10000 FIT (as in j=3) is sufficient.

FIG.21shows a comparison of the individual products Ki*Xijfor j=1 . . . 5 (columns) and i=1 . . . 5 (lines, here indicated by the values for the Kiof 100, 10 and so on).FIG.21clearly illustrates how the dependability property “Availability” is massively reduced for j=3,4,5 compared to j=2 or even to j=1.

FIG.22shows a comparison of the dependability priority numbers DPNjfor j=1 . . . 5.FIG.22clearly illustrates the significant improvement with respect to the dependability priority number DPNjof candidate system configuration j=2 over candidate system configuration j=1 as well as the slight advantage of candidate system configuration j=2 over the candidate system configurations j=3,4,5.

In other words: the redundancy measure M1 (j=2) yields the best result of Safety and Availability, the monitoring measure M2 with a monitoring circuit of 10000 FIT j=3) keeps the Safety almost at the same level, but the Availability goes down dramatically.

By comparing an acceptable lower limit Alim,lowfor the Availability value A and the actual Availability value Ajfor the candidate system configurations “j”, it may then be determined that the candidate system configuration with j=2 is the only one measure that fulfils the availability goal.

Thus in the present example the decision has been made, namely the redundancy measure M1 j=2) is the measure that fulfils all the dependability property goals, incl. the availability goal. If this is not the case, then further analyses may be performed. In the case of none of the current measures fulfils all of the set dependability property goals, new measures will have to be introduced. It is possible in the practice that no available measure fulfils all the dependability property goals. In this case, a compromise solution may have to be accepted, e.g. in that the measure that fulfils most dependability property goals or fulfils the most important dependability property goals will be chosen. As has been described in the foregoing, this can also be achieved by comparing individual digits of the dependability priority numbers DPNjseparately and according to a defined hierarchy that indicates the respective importance of the dependability properties “i”.

In case of conflict between the dependability property goals, there are at least the following ways to handle this issue:1. analysis of new alternative measures; and/or2. if the conflicts cannot be solved, e.g. because an improvement towards one dependability property goal impacts at least one other dependability property goal so negatively that that dependability property goal cannot be fulfilled, a compromise has to be made.

In the conventional art, statements about the quality of dependability properties are obtained by different analysis techniques separately, but an overall statement in value about dependability which is obtained by the quantitative dependability analyses is missing.

By introducing the Dependability Priority Number DPN as described herein, candidate system configurations (design alternatives) such as measures for mitigating a hazard risk are analyzed qualitatively and quantitatively towards an overall statement of quality of the dependability of the candidate system configurations.

The dependability priority number DPN describes the overall dependability properties (and the fulfilment of demands thereon) efficiently, and the conflicts and dependencies between the dependability properties can be solved efficiently. By determining conflicts and dependencies between the dependability properties, avoidable penalties and possible additional costs which are caused by ignorance or insufficient handling of possible conflicts between design alternatives and quality goals are minimized.

FIG.23shows a schematic block diagram illustrating an apparatus1000according to an embodiment of the second aspect of the present invention for determining an optimal system configuration out of a plurality of candidate system configurations “j”. The apparatus1000is configured and adapted to perform the method according to an embodiment of the first aspect of the present invention, in particular the method as has been described in the foregoing with respect toFIG.1and/or any of the options or variants as have been described with respect toFIG.2toFIG.22. Thus, the apparatus1000may be adapted and modified according to any of the embodiments, modifications, variants and options as have been described for the method according to the first aspect of the present invention and vice versa.

The apparatus1000comprises a computing device100with an input interface110, a processor120, a memory130and an output interface140. The input interface is configured to receive an input signal comprising data indicating a plurality of candidate system configurations “j”, in particular as has been described with respect to step S10in the foregoing.

The computing device100is configured (in particular, the processor120and the memory130are configured, by the memory130comprising executable program instructions executed by the processor120) to implement a dependability metric module210and an optimizing module220.

The dependability metric module210is configured to determine at least one quantitative dependability metric value (in particular the dependability priority number DPNj) for each of the plurality of candidate system configurations “j”,wherein the at least one quantitative dependability metric value for each of the plurality of candidate system configurations “j” is based on:a) a dependability property fulfilment value Xijfor each of a list of dependability properties “i” for each individual candidate system configuration “j”; and further based onb) a dependability property weighting factor Kifor each of the list of dependability properties “i” for all of the plurality of candidate system configurations “j”.

In particular, the dependability metric module210is configured to perform step S20according to any or all embodiments, variants, modifications or improvements as has been described in the foregoing.

The optimizing module220is configured to determine an optimal system configuration out of the plurality of candidate system configurations “j” based on a quantitative comparison between the at least one quantitative dependability metric value (in particular the dependability priority number DPNj) for each of the plurality of candidate system configurations “j”. In particular, the optimizing module220is configured to perform step S30according to any or all embodiments, variants, modifications or improvements as has been described in the foregoing.

The output interface140is configured to output an output signal72indicating the determined optimal system configuration.

The apparatus1000(in particular the output interface140of the computing device100) may be configured to transmit the output signal72to a machine300. The machine300may be part of the apparatus1000or may be external to the apparatus1000.

The machine300may e.g. be a producing machine configured to produce systems and able to produce system in particular according to the determined optimal system configuration. The machine300and the output signal72may be configured such that the output signal72controls the machine300to produce the system with the determined optimal system configuration.

Alternatively, or additionally, the machine300may be a gathering machine configured to gather raw materials and/or input components based on the determined optimal system configuration and/or a composing machine configured to compose a manual, a blueprint, a list of instructions, an explosion view and/or the like which indicates how the system having the determined optimal system configuration is to be produced. The output signal72may be adapted to control any of the machines that are part of the apparatus in any given embodiment of the second aspect.

FIG.24schematically illustrates a computer program product400comprising executable program instructions450configured to, when executed, perform the method according to the second aspect of embodiments of the present invention, in particular as has been described with respect to the previous figures.

FIG.25schematically illustrates a non-transient computer-readable data storage medium500comprising executable program instructions550configured to, when executed, perform the method according to the second aspect of embodiments of the present invention, in particular as has been described with respect to the previous figures.

Although the present invention has been disclosed in the form of preferred embodiments and variations thereon, it will be understood that numerous additional modifications and variations could be made thereto without departing from the scope of the invention.

For the sake of clarity, it is to be understood that the use of “a” or “an” throughout this application does not exclude a plurality, and “comprising” does not exclude other steps or elements.