Tag Archives: Library

Availability Reliability Requirements Engineering

[007] Amending Item Models by MTTR and Availability Computation

Item model with parameters MTBF and MTTR and associated item Availability, displyed as simple block iconIn this post we’re going to amend the existing library blocks by the quantities and arithmetics introduced in post [006] and see how this can facilitate the computation of the availability of a system.

What we need in the first step are the required variable and parameter slots, assigned to each individual item. For the time being we assume that the Mean Time To Repair MTTR is given as a known parameter for each item with the default unit of hours.

In the Modelica modeling language, parameters are quantities whose value has to be assigned prior to a simulation run, i.e. they will not be calculated. In that aspect the parameter type differs from normal variables. We plan to consider also other ways to determine and represent the MTTR and will describe this in future posts.

Cartoon, Maintenance and Lubrication, Improving Mean Time Between Failures MTBFSince the Mean Time Between Failures MTBF has been introduced in a similar parametric way in the default item, the local availability A of this particular item may immediately be calculated according to the arithmetics in post [006]. So if the pre-assigned parameter values of MTBF is 10000 hours and the Mean Time To Repair is 1 hour, this results in a local item availability of 0.9999 or 99.99%. In case we want to achiev 99.999% i.e. five nines, we would have to modify e.g. MTTR to 0.1 hour – i.e. speed up the repair action – or increase MTBF to 100000 hours – i.e. get higher-quality parts. Since such modifications can be done interactively “on the fly”, this might help the system engineer to specify the quality requirements.

We may specify in the item graphics, that these parameter values shall be displayed besides the visual icon, along with the individual name (see intro figure).

As the modeling approach follows an object-oriented concept, all item models are derived from one general item class and we need to do these declarations only at a single spot in the library. The next figure shows how this new functionality can be implemented very quickly in a few lines of code in the internal modeling language. Its only a reference to the GeneralItem master model, the equations for A and N and the declaration of the mttr parameter in a one-liner:

Amending the base class by parameters and arithmetics to compute the Availability and Non-Availability of an item

Before we proceed, it’s important to understand what we really have achieved now. We have just added the parameter MTTR to the master item description in the library. Such an item might represent various things like

  • a certain technical hardware unit within a machine,
  • a process step within a bigger procedure,
  • an adminstrative item within an organisation
  • or any other kind of element in a bigger context.

Together with the already existing parameter MTBF this allowed us to compute the also newly introduced availability quantity A. However, this item availability value is rather a theoretical value, describing a statistical value of this “box” in a standalone view, assuming that it is properly supplied.

In a real system, such an item almost never exists isolated. Instead, it will be connected to and interacting with its neighbors in a more or less complex environment. So in order to compute the actual service availability at the output of this box, we have to consider also the individual supply situation at its input. This will be the topic of post [008], then allowing us to efficiently compute the service availability of the power supply system from post [005]. And the good message is: this is possible without having to touch the overall system model!

Thanks for sharing this article!

Architecture Product Development RAMS Reliability Safety Video

[004] From Root Cause Investigation to Fault Tree Analysis

Example Fault Tree Analysis FTA, generated automatically from a component modelIn post [003] we referred to “each directly or indirectly required componen“, when talking about determination of the system function’s failure rate. But which components are required? – Well, basically all these individual items or combinations of items whose local failure will affect the considered function in a way that it does not work any longer.

In other words, we have to find out those components that are crucial for the functionality. A common way of doing that is a so-called root-cause investigation, assuming the individual function has failed.

One aspect of this post’s video is the demonstration, how these root-causes can easily be derived from the functional system model, using a kind of automatic backward reasoning. For each detected root-cause – be it a single fault, double fault or even higher order fault – the graphic of the connected SmartRAMS-blocks displays the affected system parts for each particular scenario.

Root cause analysis is often performed during system operation – i.e. late in the product life cycle – during diagnosis or troubleshooting. However, its reasoning and findings are very related to the top-down investigation in the context of a Fault Tree Analysis FTA, usually performed very early in product development.

Risk analysis by FTA has the goal to check if the safety and reliability requirements are met by the anticipated architecture. The system model composed from the simple Boolean library items supports also this purpose. We can automatically derive the Fault Trees and – as a side effect – compute the function failure rates from the component’s lambda-values. This is the other aspect shown in the video:

In post [005] we are going to demonstrate these features using a emergency power system as a simple risk assessment example.


General Product Development

[000] What is it about?

Training and education (cartoon)Here we intend to write in a sporadic manner about the development of the library.

We will talk about the motivation, ideas behind, requirements, some principal ideas, arithmetics, design issues and possible application scenarios. But also on general aspects of system engineering and safety engineering.

The more mature the library gets, we will probably show its capability to support in various RAMS analyses, FMEA and FMECA  generation, Fault Tree Analyses, diagnosis, support of safety standards and safety integrity levels (SIL) and the like.

And we will demonstrate some of these things in video clips.

So come back soon or subscribe to the mailing list. In post [001] we will start with clarification of the system engineering view on components and function.