Tag Archives: Arithmetics

Availability Requirements Engineering Video

[008] Using a System Model for Iterative Availability Management

Using a System Model For Iterative Availability Management, Power Supply System ExampleThe description of the last post [007] showed, how we added related quantities and arithmetics to compute availability and non-availability for individual items. This extension made them smarter and also added some “decoration” to display the parameter values.

Today’s video post guides us from item level back up to system level. At the end of the day, it is the availability of a system – or better: of certain system functions – that we are interested in.


Simply by using the amended versions of the original item classes allowed it to extend the benefit of the existing system model – here in the example of the power supply system – without actually having to touch and modify it in any way. The topology remains the same as already known and graphically specified before.

The idea is, that the individual topological context of an individual item not only determines its functionality, but also the computation of the availability of a service that this item shall provide. That means, not only its own “standalone” properties of the relevant parameters – like MTBF and MTTR as shown in post [007] – determine the service availability, but also its individual supplies have to be taken into account.

According to the local dependencies of the individual item the behavior description of its unique category automatically provides the correct arithmetics to compute this availability value. That makes it very easy to compute the availability of a system, since the computation equation is assembled automatically, just by graphically connecting the various outputs and inputs of the used items – independent if they represent real hardware components, process steps or e.g. logistical activities.

Having direct and interactive access to all relevant parameters allows to easily modify values of Mean Time Between Failures MTBF or Mean Time To Repair MTTR of any item. Just by doing a system simulation it immediately becomes clear, if these modifications help to come closer to the target number – like five nines – or also the MTBF or MTTR requirements of other items have to be tightened.

So using a graphical hierarchical system model to iteratively find out optimal target values for the items or item categories – including the feature to save and load scenarios – adds a great flexibility to the process of availability management or specification. In a later post we plan to support this process even more by considering also criteria like cost or time to get a better idea of the performance of designated assembly architectures.

In this example we assumed that the parameters MTBF and MTTR – as some of the main drivers of item availability – were given. But they are just some statistical values and depend on other properties as well. How the target function availability of a system really is affected in case a certain item is down, will probably be the topic of post [009].

For the time being, feel free to get in contact with us. Get in contact ...

Availability RAMS Reliability

[006] Computing the Availability of a System, some Basics

Cartoon Maintenance, Computing the Availability of a system, five ninesSimilar to the concept of Reliability computation introduced in post [003], we also would like to support the computation of system Availability with the model blocks. However, before talking about the availability arithmetics, again we have to clarify its meaning.

So what is system availability? – Basically, a system can be “up” and operating, i.e. providing the required service, or “down” and non-operating, i.e. not providing the service. Being in downtime can be planned (e.g. scheduled maintenance) or unplanned (e.g. irregular failure of system parts). Dependent on the required work effort, the need and delivery time of spare parts, the qualification of the repair and maintenance team etc. it takes more or less time to repair the system and get it back into the desired “Up”-mode.


While Reliability is used to express, how probable it is that a certain desired functionality of a system fails within a given period of time, the feature of Availability quantifies the operating time within such a period. Simply put, Wikipedia summarizes Availability being “the proportion of time a system is in a functioning condition”. (If interested, please look up more explanations there.)

Besides the already mentioned MTBF, important additional calculation symbols in this context are:

  • A: the symbol denoting the Availability of the respective part, item or service with theoretical values between 0 and 1, but practically usually being close to one, e.g. in high availability systems the magic “five nines” like 0.99999 or in percent this value is 99.999%, meaning 5 minutes per year (!);
  • N: the symbol denoting the Non-Availability of the respective part, item or service and the complement to A, i.e. the sum of A and N is always 1;
  • MTTR: the symbol denoting the Mean Time To Repair, the time needed to repair the system and get it back to service. To be correct, this time is not only needed for repair, but often is used to represent the complete downtime period, including fault detection and reporting, parts ordering (and delays), assembling, testing, start-up etc.

With these variables and stochastical parameters, the basic equations to compute the availability of a system item is:

A = MTBF / (MTBF + MTTR).

Although this maybe looks like a quite familiar equation, it is important to have a clear picture, to what these quantities really relate. Ok, MTBF and MTTR are kind of statistical parameters that have been estimated or gathered from the field and clearly can be associated to individual components. But with respect to A, we referred to certain services or functions of an item, that shall be available.

As long as we talk about system items providing only one single service, this distinction between components and their provided functions might appear artificial and not be so obvious: we can clearly observe it being Up or Down and there is a 1:1-mapping between the hardware and the functionality.

But as soon as we consider hierarchical systems or sub-systems that provide more than one single service or function, it is important to have proper and separated variable slots for the availability of system components and system functions, according to the orthogonal view we introduced earlier.

In terms of building-blocks of the SmartRAMDependencies of component output availability on inputs, MTBF and MTTRS-library in the “Availability layer” we need to provide MTBF and MTTR parameter slots only once for each component. However, concerning availability, variable slots have to be provided for each interacting service, the outgoing and the incoming ones, as illustrated in the picture. Thanks to the modular port-concept of Modelica, extending the already existing interfaces – or ports – by an additional variable for A is a matter of just one single model statement.

This were some basic thoughts about the required variable slots. Adding also the required arithmetics to the existing model classes and demonstrating it along the emergency power system that we used in the risk assessment example will be topic of post [007] .

 

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.