Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
A Model-Based Approach for Reliability
Prediction
av
Per Askvid
LIU-IDA/LITH-EX-A--10/008--SE
2010-02-26
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings universitet
581 83 Linköping
Institutionen för datavetenskap
Department of Computer and Information Science
Master’s Thesis
Per Askvid
Reg Nr: LIU-IDA/LITH-EX-A--10/008--SE Linköping 2010
Supervisor: Peter Bunus Ph.D.
ida, Linköpings University
Burkhard Münker Ph.D.
Uptime Solutions AB
Examiner: Peter Bunus Ph.D.
ida, Linköpings University
Department of Computer and Information Science Linköpings universitet
Avdelning, Institution
Division, Department
Division for Software and Systems
Department of Computer and Information Science Linköpings universitet
SE-581 83 Linköping, Sweden
Datum Date 2010-02-26 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
http://www.ida.liu.se/divisions/sas/index.en.shtml http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-54323 ISBN — ISRN LIU-IDA/LITH-EX-A--10/008--SE
Serietitel och serienummer
Title of series, numbering
ISSN
—
Titel
Title
A Model-Based Approach for Reliability Prediction
Författare
Author
Per Askvid
Sammanfattning
Abstract
When developing products, reliability is an important factor that has to be considered. For safety critical systems it is important to know the probability that an item will perform a required function without failure under stated conditions for a stated period of time. The main goal of a reliability prediction analysis is to predict the rate at which the product of a system will fail. To perform this prediction there are a number of methodologies available.
This Master Thesis proposes a model-based approach for reliability prediction calculations based on the physics of failure and supported by analysis of test-data field returns and physical models provided by the FIDES methodology. FIDES based reliability models have been integrated into a model-based diagnosis envi-ronment for seamless integration with other safety assessment analysis.
The model-based diagnosis environment used in this thesis is model-based rea-soner RODON developed by Uptime Solutions AB. Components that uses the FIDES methodology have been developed in RODON, where components can be combined to systems by drag and drop method. Usage profiles that are defined according to the FIDES methodology in RODON are not system specific, which makes them reusable in other systems.
The developed library of components and usage profiles makes it easy to model complex systems and perform reliability predictions according to the FIDES methodology.
Nyckelord
Abstract
When developing products, reliability is an important factor that has to be considered. For safety critical systems it is important to know the probability that an item will perform a required function without failure under stated conditions for a stated period of time. The main goal of a reliability prediction analysis is to predict the rate at which the product of a system will fail. To perform this prediction there are a number of methodologies available.
This Master Thesis proposes a model-based approach for reliability prediction calculations based on the physics of failure and supported by analysis of test-data field returns and physical models provided by the FIDES methodology. FIDES based reliability models have been integrated into a model-based diagnosis envi-ronment for seamless integration with other safety assessment analysis.
The model-based diagnosis environment used in this thesis is model-based rea-soner RODON developed by Uptime Solutions AB. Components that uses the FIDES methodology have been developed in RODON, where components can be combined to systems by drag and drop method. Usage profiles that are defined according to the FIDES methodology in RODON are not system specific, which makes them reusable in other systems.
The developed library of components and usage profiles makes it easy to model complex systems and perform reliability predictions according to the FIDES methodology.
Acknowledgments
First and foremost I would like to thank my examiner Peter Bunus for giving me the opportunity to do this thesis and also for giving me the chance do part of my project at MBDA Missile Systems in München, Germany. At MBDA Missile Systems I would like to thank Dieter Fasol for giving me responsibility and trust. At Uptime Solutions I would like to thank my supervisor Burkhard Münker for his support and guidance along the way. Also thanks to my colleagues Olle Isaksson and Beate Frey for taking time to answer my questions.
Last but not least my girlfriend who had to listen to my endless talk about this master thesis.
Per Askvid Linköping, January 2010
Contents
1 Introduction 1
1.1 Problem description . . . 1
1.2 Objective . . . 2
1.3 Limitations . . . 2
2 Reliability Assessment Methodologies 3 2.1 MIL-HDBK-217 . . . 4
2.2 FIDES . . . 5
2.2.1 FIDES Guide 2009 . . . 6
2.2.2 Physics of failure . . . 6
2.2.3 Setting Up Life Profiles . . . 6
3 Background 9 3.1 Reliability . . . 9
3.2 Traditional Diagnosis . . . 10
3.3 Model Based Diagnosis . . . 11
3.4 Object Oriented Modeling . . . 12
3.5 RODON . . . 13
3.5.1 Composer . . . 13
3.5.2 Analyzer . . . 15
4 FIDES Library in RODON 19 4.1 Structure of the library . . . 19
4.2 Environment . . . 21
4.3 Components . . . 22
5 Using the FIDES Library 25 6 Testing FIDES on Steer by Wire Example 27 6.1 Test system . . . 27
6.2 Test Environment . . . 28
6.3 Results . . . 29 ix
x Contents 7 Related work 33 7.1 Manual procedure . . . 33 7.2 Relex . . . 33 7.3 Isograph . . . 33 8 Conclusions 35 8.1 Further development . . . 36 Bibliography 37 A Abbreviation 39
Chapter 1
Introduction
1.1
Problem description
With increased system complexity in recent years, almost every system under deployment is exposed to component failures or is under the risk of suffering a major breakdown during its lifetime.
If a critical system in a cellphone fails it would render the device unusable but most likely it will not cause any serious damages or human causalities. However if a critical system fails in a airplane during flight the outcome will be a disaster. To avoid this, product reliability need to be improved. One effort in this area is to have sensors that records how the system is used. The sensor package measures a number of environmental variables such as: humidity, temperature, vibrations etc. With this data, a reliability analysis can be performed at any time during the system’s life time. Previously a constant reliability number was calculated during the design phase. Today however, a reliability analysis can be created based on data of how the system has been used, which gives a more accurate prediction.
To be able to take advantage of this usage data a new reliability-prediction methodology has been developed, called FIDES. There is also a guidance docu-ment, called FIDES Guide 2009 [4] which describes how to use the methodology.
The FIDES methodology enables a realistic assessment of the reliability of electronic components and equipments by taking into consideration all the tech-nological, physical and usage factors that can influence the reliability. Mission profiles, various overstresses and failures linked to the component development, production, field operation and maintenance are some of the characteristics that are taken into consideration by the FIDES methodology.
2 Introduction
1.2
Objective
The objective of this thesis is to perform reliability calculations according to the FIDES methodology in a existing model-based reasoning tool for improved model reuseability and enhanced safety assessment process. The tool that will be used is RODON. The main goals are listed below.
• Investigate how the FIDES methodology can be implemented in the model based reasoning tool RODON.
• Create a library of components that can be used to calculate a mean time between failure (MTBF) value for each individual component.
• Show that it is possible to calculate failure probability for system functions based on the MTBF-values for the individual components.
• Create a way for the developed component model to combine with existing libraries of components without any modification of the existing.
1.3
Limitations
Since this is mearly a prototype not all components that are available in the FIDES methodology has been implemented. The components that have been implemented were chosen because the test system contained these components.
In the FIDES guide there is a part that handles how to perform an audit on the developing company and how this affects the reliability. This part is not considered in this thesis, the parameter that is included in the calculations is given the standard value that is recommended in the FIDES guide. This part is also not interesting to include in a calculation in RODON since it does not include any advanced calculations, only a lot of parameters.
Chapter 2
Reliability Assessment
Methodologies
Reliability is not an exact science, with an correct answer, but is based on statis-tics and probability. That is why the defense and avionics sector takes a very pessimistic approach to reliability prediction, since they have very high reliability demands. This can be seen on the accuracy of the failure rates used by avionics and defense applications 10−9 versus 10−6 for consumer electronic applications.
There are a number of methodologies to calculate the reliability of components, for example:
• Telecordia SR332 developed for the reliability prediction of commercial elec-tronic components.
• RIAC 217 Plus prediction module incorporates the component failure rate prediction models developed by the RIAC (Reliability Information Analysis Center).
• NSWC-98 is the US Naval Surface Warfare Center standard for the reliability prediction of mechanical components.
• IEC TR 62380 (formerly RDF 2000 (UTE C 80-810)) module is a reliability prediction program based on the French telecommunications standard. • GJB/Z 299B is a Chinese standard for the reliability prediction of electronic
components.
In this chapter two methodologies will be presented both are concentrated at making a realistic evaluation of the reliability of electronic products.
• MIL-HDBK-217 which has been and are the most used methodology in the defense and avionics industries.
4 Reliability Assessment Methodologies
• FIDES which is a newly developed methodology and is the one that are implemented in RODON in this thesis.
The MIL-HDBK-217 [10] is the most widely used methodology in the avionics and defense sector. However the last decades advances in electronics have made this standard outdated and need for a new standard has arisen so that the benefits from this development can be used.
In the last years, there has also been a rising interest from companies in the defense and avionics industry to buy commercial of the shelf (COTS) components. From previously only buying special “military” or “high reliability” components at a much higher cost. This since the production of electronic components have matured so much that the reliability of a COTS component are high enough to be used in safety critical equipment. But a problem is that for most COTS the stated MTBF value can not be motivated in such high grade that military standards require, they are based on to many estimations done by the developers. If the MTBF value can not be guaranteed according to the standards they are not allowed to be used in developed systems. There is a need to perform reliability analysis on COTS components, in order to use these components in safety critical systems.
This is a problem with MIL-HDBK-217 since it is not possible to use with COTS, the reliability of these components can not be guaranteed. The FIDES methodology on the other hand was initially developed for COTS items.
2.1
MIL-HDBK-217
In the defense and avionics industries the MIL-HDBK-217 [10] has been a largely used standard in order to perform reliability analysis.
The full name is Military Handbook in Reliability Prediction of Electronic Equipment MIL-HDBK-217 [10] and was released for the first time in 1961 and the last revision of the document was published in 1995. It was developed by the United States Department of Defense and is based on collected data and experience from the defense and avionic industries.
Since the standard was updated in 1995 a lot of new components have been developed, but since the standard does not include these component a reliability assessment can not be made. If an proper reliability assessment have not been performed then the component can not be used in safety critical systems.
The advantages with this standard is that it is the most widely known and used reliability prediction tool. It is easy to do the calculations as there are few parameters that needs to be decided, between five and ten depending on type of component.
Among these parameters are one describing which temperature the component is operating in and one describes which type of environment. The limitations with only having one parameter for the temperature and one for the environment is that reliability numbers can only be calculated for one specific usage phase. For different environmental conditions reliability numbers can only be achieved for one condition at a time and if the component is used in many different ways the only
2.2 FIDES 5
option is to perform a new reliability analysis. This limits the use to reliability analysis that can be done in the design phase to investigate what is the failure rate in a certain environment.
Another disadvantage about the MIL-HDBK-217 is that it is not able to handle COTS components.
2.2
FIDES
FIDES is the Latin word for faith and is a reliability assessment methodology for electronic product. Developer behind the FIDES methodology [4] is a consortium consisting of AIRBUS France, Eurocopter, Nexter Electronics, MBDA France, Thales Systèmes Aéroportés SA, Thales Avionics, Thales Corporate Services SAS and Thales Underwater Systems. The consortium were created under the super-vision of the DGA (Délégation Générale pour l’Armement - French Ministry of Defense).
The methodology is based on the physics of failure and is supported by analysis of test data, feedback from operations and existing models. It is different than the MIL-HDBK-217 which is mostly developed from statistical interpretation of feed-back from operations. Another difference is that the methodology was originally developed for electronic COTS items. Because of this it can be applied at a larger array of components, both COTS and special developed items.
The FIDES approach is based on combining three factors that contribute to a components reliability: technology, process and use. These factors are consid-ered for the entire life cycle from the product specification to the operation and maintenance phase.
A detailed description of how the system is used is needed to perform a re-liability analysis. This is done by dividing calendar year of the systems life into usage phases and then setting a number of predefined environmental parameters for each of the life phases. If these environmental parameters would be recorded by a sensor package a lot of new possibilities could open up in the reliability en-gineering area. It gives a whole new possibility to perform reliability analysis at any time during a products life. This is a big change in the reliability analysis area, from being something that is done during the design phase, to being able to do an analysis at any time during the products life. An large advantage since a customer could at any given time ask, after a time of usage, is the product still reliable. So called “on the fly” analysis could be performed with high credibility.
The disadvantage of FIDES is that extensive knowledge about the system us-age is required. To use FIDES, when comparing different system designs during the development of a system, would be very time consuming but result in a very good evaluation.
6 Reliability Assessment Methodologies
2.2.1
FIDES Guide 2009
The FIDES guide was first released in 2004 and a revision came in May 2009. The document describes how the FIDES methodology are supposed to be used and is called the FIDES guide [4], it consists of two parts.
• A reliability prediction guide.
• A reliability process control and audit guide.
The reliability process and audit guide is not addressed by this thesis.
2.2.2
Physics of failure
A difference between FIDES and MIL-HDBK-217 is that FIDES is based on models that describe the acceleration of failure mechanism due to the different types of stress.
In reliability engineering failure rate, failure per million hours, is a common unit to use and is denoted λ. The inverse of failure rate is MTBF (mean time between failure).
The FIDES general reliability model for an item is based on the following equation.
λ = λP hysical∗ ΠP M∗ ΠP rocess (2.1)
• λP hysicalrepresents the physical contributions to the systems total λ-value.
• ΠP M represents the quality and technical control over the manufacturing of
the process. PM stands for part manufacturing.
• The ΠP rocessrepresents how well the development process of the component
are done. It is dependent of the grades from a audit process, which have been conducted at the developers site.
Calculating the λP hysical value requires the largest amount of calculations of
the three. It represents physical stress that can affect the component, they are grouped into different families: electrical, thermal, temperature cycling, mechani-cal, humidity and chemical. Different previously known models are used to describe the physics of failure for each type of stress except for the chemical stress. The chemical stress is modeled qualitatively, there is no physical model for this stress.
2.2.3
Setting Up Life Profiles
One of the major parts in doing calculations with the FIDES methodology is to set up the systems life profile. It is done by identifying a number of usage phases in the life of a product.
A usage phase is described by a number of parameters which describes the en-vironment that the product is operating in and the duration of the phase. There
2.2 FIDES 7
is no upper limit for how many usage phases that are allowed, but at least one usage profile needs to be provided. The phases should be chosen so that they are sufficient to describe the different usage situations as realistically as possible. Few phases leads to fewer calculations but also a lower precision.
The duration of the usage phases must be expressed in hours and it is recom-mended that life profiles should be built up with a total duration of 1 year, 8760 hours. If another time frame is required the duration of the life profile can be changed but an easier way is be to normalize the time to one year.
To describe a products usage a day, 24 hours, is broken down in different usage phases. If the same usage of the system is repeated during the time frame it can be put together to one. If high precision is not required similar usage phases can be merged to one. To do this as easy as possible, on and off phase could be the only ones. Few phases would give easier calculations but precision in the reliability prediction is lost.
When the usage phases during 24 hours have been decided it is also important to look at environmental changes during the year, seasons. If large changes in the environmental conditions occur during summer and winter it would be preferable to add usage phases so that each season has its own set of usage phases.
A more detailed description of life profile construction is given in the FIDES guide 2009 [4] starting at page 33.
Chapter 3
Background
3.1
Reliability
Reliability is an area that continues to increase in importance as the systems are becoming more complex and the demands from customers are getting higher. To consider this when developing a system is a must and in many industries there are certification issues that stipulate that reliability analysis has to be done before the product is deployed, for example the avionics and defense industries.
According to International Electrotechnical Commission, the reliability perfor-mance of a product is defined as:
The ability of an item to perform a required function under given conditions, for a given time interval.
Quote from IEC 60050-191, para. 191-02-06 [2] When developing a system that has a critical task, a requirement on the reli-ability is specified [8]. For a relireli-ability requirement to be meaningful it has to be specified quantitatively. According to MIL-HDBK-338B [9], which is the electronic reliability design handbook, there are three basic ways to do this:
• As mean time between failure. This is the most common way for long life systems or systems were the mission times always are short relatively the specified mean life. The negative about this method is that it does not take into account the higher risks in early life.
• As a probability of survival for a specific period of time. Useful when a high reliability is required for a short mission time.
• As a probability of success , independent of time. Useful for one-shot devices, for example the reliability during the flight of a missile
10 Background
As seen in Chapter 2 there are different ways to estimate the reliability of systems and unfortunately none of them can exact predict when a system is going to fail. One thing that makes reliability a difficult area is that it is not constant over time. Experimental observations of systems have shown that the failure rate vary over time according to a “bathtub curve” Figure 3.1. In the beginning of the usage time of a system it has a higher failure rate because of process implementation problems. The normal life phase is represented by a constant failure rate this phase is often non-existing for mechanical system but the reference period of electronic systems. After a while the system starts to wear out, which leads to a higher failure rate.
Figure 3.1. The variation of failure rate λ over time.
The predicted failure rates is denoted the symbol λ and is expressed in FIT (failure in time) were 1 FIT is equal to 1 failure per 109 hours. Its inverse, called MTBF (mean time between failure) is also used in this thesis work and is simply called MTBF.
A traditional approach to enhance reliability is designing with hardware re-dundancy [3]. Is is common in security critical systems. A typical example is to use two sensors measuring the same physical quantity. By comparing the output from the two sensors a fault can be detected. With only two sensors it is hard to tell which one is the defective sensor but this can be solved by adding a third sensor.
In this thesis a system that is designed with hardware redundancy is used to test the developed library.
3.2
Traditional Diagnosis
Diagnose is a way to find the cause when a system is not working correctly. There are several ways to perform an automated diagnosis. Traditionally it has been done through limit checking [3]. The system has then been tested so that a table of the nominal value of the sensors in different operating conditions are generated.
3.3 Model Based Diagnosis 11
This table is then used to compare with the real sensor value as seen in Figure 3.2.
Figure 3.2. Figure of a diagnose with lookup-table
An example is the angular speed on the rotor blades of a helicopter at an certain throttle level. To get an table of nominal values data from a number of test at different throttle levels is collected. This results in a lookup-table that is used to compare with the values that the rotary sensor records during use. The problems with this concept is that extensive testing is required, which is expensive. The look-up table can never cover all cases, an interpolation is always necessary and transients are hard to handle with a table.
3.3
Model Based Diagnosis
Model based diagnosis is another method to find the cause of system failure but instead of using a look-up table as in traditional diagnostics, model based diagnosis can be used.
The basic idea of model based diagnosis is to compare the nominal behavior which is described in a model with a real measured value. The model is a number of equations that describes the behavior of the system. If these two are inconsistent the system is not working correctly. This requires both a good model and precise measurements. Figure 3.3 shows how a diagnostic reasoner is used to perform model based diagnosis. The diagnostic reasoner is able to detect discrepancies and also to generate and propose corrective actions that need to be performed on the real system to repair the identified fault.
A drawback of this approach is that developing the models can be very time consuming. It also require more calculation power onboard the system, since for every sensor sample a model calculation has to be done. There is also the question of how detailed the model can be, higher level of details would mean many and complicated equations, which requires more calculation power onbord. So a balance between available calculation power and level of detail in the model have to be found.
12 Background
Figure 3.3. Model based diagnosis of a passenger seat system
The main objective of this thesis is to investigate if model based diagnosis can be used together with the FIDES methodology.
3.4
Object Oriented Modeling
In most technological areas there are established ways to describe how a system of components are connected with each other [6] (For example a circuit diagram in electronics). A good way to build up a model of a system is to use the same structure, which is called object oriented modeling. This is the system that is used in RODON. In each component their behavior is described by a number of equations. The advantages with this is that the model of the system has the same structure as the real system and is thereby easier to understand. To develop models can be very time consuming. So being able to reuse models is a important part in object oriented modeling. This is achieved by creating library’s of models. In RODON there exists a number of library’s that includes the most common functions.
Modeling can be done in two different ways, qualitative and quantitative. Qual-itative modeling is done with logic blocks were every component can either be working or not. The result of a system modeled in this way would be an true/false if the system function is working. It can be used to evaluate different designs of a system. The quantitative modeling approach aim at describing the system as detailed as possible were the actual signals are described in the unit that they are in the real system. It is often an more time consuming approach than the quanti-tative but the range of analysis method that can be applied are bigger. RODON allows the use of both kinds of modeling which can be chosen depending on what
3.5 RODON 13
results the user is requiring.
The libraries created in this thesis have been designed to allow both qualitative and quantitative modeling. However, in the test system only qualitative modeling were used.
Object oriented modeling also have the advantage that superclass and sub-classes can be used. A superclass is a class that all other sub-classes are derived from, it contains all data that are common for the subclasses. This is used in this thesis to build one superclass that contains the common parameters and calculations and from this class extend to subclasses that inherits all properties from the superclass.
3.5
RODON
RODON [5] is a commercial model based diagnostics tool which is developed by Uptime Solutions. It uses the equation based object oriented language Rodelica which is strongly related to Modelica [1], but has been adapted to make it more suitable for diagnostic problems.
RODON is divided into different modules depending on the task preformed. The work describing a components behavior, referred as modeling, is done in the Composer. The other modules are using the models developed in the Composer. Among the diagnostic tasks that RODON can perform are:
• Automatic generation of FMEA tables (Failure Mode and Effect Analysis) • Automatic generation of decision trees, which is used for trouble-shooting a
system.
• Automatic generation of Fault trees.
• Reliability prediction calculations and architecture optimization.
3.5.1
Composer
The composer is where the modeling in RODON is done, by describing the individ-ual components behavior and setting up the topology of a system. The modeling is done either by coding in Rodelica or by using the graphical user interface to drag and drop classes into models.
The code is divided into two parts the attributes declaration part and behavior part, the dividing statement is behavior.
In attributes declaration all components and parameters that are used in the model are listed. Below the behavior statement the equations that describes the behavior of the component are listed.
In Example 3.1 there is an code example from the model of a wire. First the attributes declaration were it is listed that the wire consists of two pins, one in each end. Existing failure modes (fm) are also declared, in this case the wire can be either ok or disconnected.
14 Background
Below the behavior statement, the equations that describes the behavior of the component are listed. The equations can specify the nominal and failure behav-ior. In nominal behavior Kirchoff’s law is applied to describe the ideal behavbehav-ior. The failure mode disconnected is described by no current passes trough the wire. These equations are not evaluated until the component has been simulated in the analyzer.
Example 3.1: Model of a wire
model WireBasic public
/** Electrical pin 1 of component. */ WirePin p1;
/** Electrical pin 2 of component. */ WirePin p2;
/** Failure mode variable. */
FailureMode fm (max = 1, mapping = "ok, disconnected"); behavior
// Constraints for health state "ok": if (fm == 0)
{
// Current balance: p1.i + p2.i = 0;
// No voltage drop between pins 1 and 2: p1.u - p2.u = 0;
}
// Constraints for failure mode "disconnected": if (fm == 1) { // There is no current: p1.i = 0; p2.i = 0; } end WireBasic;
3.5 RODON 15
model called environment. The environment can also be given parameters. Figure 3.4 shows a simple electrical system represented in the Composer module.
Figure 3.4. An simple example of an circuit with a battery that powers a lamp.
3.5.2
Analyzer
After a system has been modeled in the composer it is loaded into the Analyzer where is can be simulated and diagnosed. All parameters in the system are ac-cessible and can be set in order to investigate system’s behavior with different settings. If the example shown, when the system is simulated in a nominal case, the bulb is bright. When the failure mode of wireBasic_1 is set to disconnected, the bulb is off, since no current are flowing through the circuit. This simulation is shown in Figure 3.5.
Diagnostics can also be performed. The same example is used and an observa-tion that the bulb is not shining, bulbOhmic_1.lightEmittance = off. This results in a conflict in the system and a list of candidates that explain the observation is given (see Figure 3.6).
16 Background
Figure 3.5. An simple example is simulated with wireBasic_1 in the failure mode
3.5 RODON 17
Figure 3.6. An simple scenario is diagnosed with the observation that the bulb is not
Chapter 4
FIDES Library in RODON
To be able to use the FIDES methodology to do reliability analysis in RODON a library of components has been developed. These components are able to perform calculations of the MTBF as described in the FIDES guide 2009 [4].
The functionality of RODON has been extended with the ability of calculating MTBF-values. In the software RODON MTBF has before been a constant, which had to be manually entered. That constant has been calculated outside of RODON with the help of a given reliability number from the component supplier.
Since MTBF is placed in the attributes declaration part in the Rodelica code, all calculations needs to be done above the behavior statement.
Only a subset of the components specified in the FIDES guide have been imple-mented in RODON. The implementation is intended to show a way to implement the functionality in RODON and also show a way that the rest of the components can be implemented. This is accomplished by developing the library with a lot of reusable code and a well defined structure that makes it easy to create more components with the same method and small changes. The new functionality of supporting the FIDES methodology is implemented without having to do any changes to RODON as a software.
4.1
Structure of the library
Everything that has to do with the FIDES methodology are collected in one pack-age called FIDES. The tree structure that the components are created in, Figure 4.1, are arranged in the same way as the chapters in the FIDES guide 2009 [4]. It is not the exact same order because RODON automatically sort the packages in alphabetical order. In RODON only classes in the same package or higher up in the tree structure of packages are accessible. This is why classes and functions are placed so that they are only accessible by the classes that needs them. The classes that are placed directly in the FIDES package are used by all the other components and therefor needs to be accessible by all. For each of the different types of components there are constants, these are also placed so that they are
20 FIDES Library in RODON
only accessible from the component that needs them. The constants can be basic failure rates for a certain type of component.
Figure 4.1. The implemented library of components and functions in RODON. The
Common package contains the already existing libraries.
Also placed in the FIDES package is the class that contains all data that describes one phase. When a system is created the number of phases of the current system decides how many of these classes that are created. They are then created as an array with the length decided by the number of phases.
In the FIDES methodology there exist three different kinds of parameters. • Parameters that are common for the entire system. For example
environ-mental parameters, Tamb.
• Parameters that are specific for each component but phase independent. For example quality assurance level of the component, QAcomponent.
• Parameters that are component specific and phase dependent. For example power dissipated by the component during the phase, Pdissipated.
The parameters that are common for the entire system are placed in the envi-ronment class, where they can be accessed by all components in the system.
The parameter specific components that is phase independent are declared in the components as parameters.
4.2 Environment 21
The parameters that are component specific and phase dependent are declared as a generic function that uses the function record to build up a number of structures that contain phases dependent data. These are then placed in the components as arrays with the same length as the number of phases.
4.2
Environment
The environment class contains parameters that are common for the entire sys-tem, they describes the environment the system is operating in. It also declares the Πruggedisingtable, found in [4] p.101, that needs to be filled out and represents
the influence of the policy for taking account of overstress in the product develop-ment. They can be accessed by all components that is a part of the system. The parameters that needs to be accessed by all component are the usage life phases that are created and set in the environment, since the entire system is assumed to operate in the same environment. Parameters placed here can be both dependent and independent of the phases.
Figure 4.2. A number of different life profiles can be used to test the system. The test
system extends from environment to get the structure of parameters.
The test system is where the topology of the system is created by combining the components to a system. This system can be previously existing but the com-ponents needs to be replaced with FIDES component’s.
The environment class does not contain any actual data, only a structure with default values. The environment data that are going to be used are placed in the life profile classes. They contain all life profile data, they extend from the test
22 FIDES Library in RODON
system and then loaded into the analyzer for evaluation. In figure 4.2 the structure can be seen.
A number of life profiles can be created. These can then be used to test the reliability of any system, that has FIDES components, in different environmental condition. This way it is easy to test a system with many different life profiles. The life profiles can be saved and reused on any system, since they are not system dependent.
4.3
Components
There are parameters and calculations that are common for all types of compo-nents in the FIDES methodology. To take advantage of this and avoid doing the same work many times a partial superclass, FIDESBaseComp, is created. This superclass includes all parameters that are common for all components. This is what partial means, that it cannot be instantiated itself it needs to be extended by another class in order to be usable.
Components are then created as extensions from this superclass as in Figure 4.3. When this method is used all parameters from the superclass are included in the subclass. The parameters that are individual for the different type of compo-nents are declared in the subclasses.
Figure 4.3. FIDESBaseComp is the superclass that all other components extends from
as subclasses.
The parameter ΠP Mis declare as replaceable in the superclass. This mean that
in the superclass a default equation is declared but the equation can be replaced in the subclass.
The most common equation have been chosen as default. The replaceable statement saves work when there are few number of variants but is not useful otherwise.
This is the case with ΠP M which is different depending on if it is a active
4.3 Components 23
Each type of component are affected by different types of stress. They are also affected in different ways by the stress, this means that equations describing how a component are affected by a certain stress are not the same for all, but individual parameters placed in the subclasses. The equations for each of the components are found in the FIDES Guide 2009 [4].
The components that has been created in this prototype are an IC, resistor, relay, battery and optocoupler.
Chapter 5
Using the FIDES Library
The components in the FIDES library only have one task and that is to calculate a MTBF-value. They have no description of the physical properties and functionality of the component. In order to do a reliability analysis in RODON, using the FIDES methodology, the FIDES component needs to be combined with a component of the same type from one of the existing libraries. The existing libraries are either electrical library which is used for quantitative modeling or the OptRel library which is used for qualitative modeling.
The combined component will have the same behavior as the one from the existing library but it will have its MTBF value calculated from the FIDES part. The Rodelica code for the combined component are seen in Example 5.1. The MTBF-value is set with the statement mtbf = lambda109 . Where lambda is the failure rate value calculated by the FIDES library. The 109 is to get the right unit, because FIDES calculates lambda in failures per 109 hours and MTBF in hours.
Example 5.1: Model of a ECU which is a integrated circuit
model Fides_ECU_2Dc
extends SteerByWire.BasicComponents.ECUs.Ecu_2Dc (mtbf = 1e9/lambda); extends FIDES.Electrical.IntegratedCircuits.ICcomponent;
end Fides_ECU_2Dc;
The FIDES component only sets a parameter in the existing components. So there is a possibility to take a system that has been modeled previously and use the FIDES methodology to do an reliability analysis.
To do a failure probability calculation of an existing system a new set of com-25
26 Using the FIDES Library
ponents needs to be created. This is done by combining the FIDES component with a component from one of the other already existing libraries, as described in 5.1. This gives the new component the parameters from both components and it can replace the old one without having to do any other changes to the system.
To analyze the system with different usage profiles either create a new or use one that has been created before. The usage profiles are not system dependent so once a usage profile has been created it can be saved and used on another system. A simple step by step method for how to perform reliability analysis with the FIDES library in RODON would be.
• Create a new package for the components that combine FIDES and original functions.
• Create all the needed component in the same way as example 5.1. • Model the system with the created components.
• Test the system with different life profiles by extending the test system and then loading the life profiles into the analyzer. The test system can either be created or reused from previously analysis.
Chapter 6
Testing FIDES on Steer by
Wire Example
6.1
Test system
To test the FIDES library a previously developed model is used as the one depicted in Figure 6.1. It is a qualitative model that is appropriate to use since it operates in a changing environment.
Figure 6.1. System that is used to steer the front wheel on an airbus.
The model describes the system that is used to steer the front wheel on an airplane. It is a so called “steer by wire”-system which means it has no mechani-cal connections from the cockpit,which gives the steering commands, to the front wheel. Instead there is electronics that interprets the steering command and
28 Testing FIDES on Steer by Wire Example
tuators that execute the command. This is a very critical system on an airplane, since losing the function of steering the front wheel would make the airplane im-mobilized on the ground. In order to achieve a high grade of reliability the system is designed with hardware redundancy. As seen in Figure 6.1 there are three an-gle sensors and they are parallel connected so that one differs from the other it is assumed to have failed. The same goes for the ECU, actuators and the dc supply. Not all of the components in the system have been modeled in the prototype FIDES library. The FIDES methodology will therefore not be used on all compo-nents in the system. Only dcSupply, ECU and actuator will have an MTBF-value that has been calculated with FIDES methodology. The comparison between the different usage phases will not be affected since the other components MTBF-values are set to a constant value of 10000 hours. A realistic value may not be achieved but the goal with the test is to show the implemented FIDES library can produce an calculated failure probability. And the actual numbers are not interesting.
To include an calculation according to the FIDES methodology the SteerBy-Wire system extends from the FIDES environment, to include all the required environmental data. The components previously mentioned that have been im-plemented in the FIDES library are exchanged to ones that support FIDES. To supply any actual environment data to the environment class two different life profiles is used to load the system into the analyzer for evaluation.
6.2
Test Environment
The two life profiles that are used in the test is taken from an example in the FIDES Guide 2009, p.65 [4]. The life profiles describes the environment for a computer in the avionics bay of an helicopter that operates as VIP transport. Its life consists of one short flight every other day and the rest of the time parked on the ground. They are both describing the same usage and have been divided into three usage phases, they are:
1. On the ground with systems turned off. 2. On the ground with systems turned on. 3. In the air during flight.
The first one, on the ground with system turned off, is the largest part of the time. All system are turned off in this phase so there are fewer types of stress applied to the system in this phase. The second one, parked on the ground with system turned on, are during start up an system checks that are performed before and also after flight. The last one is, in the air during flight. This phase is the one that puts most stress on the components, with large mechanical stress from vibrations.
6.3 Results 29
To show that different environmental conditions affects the reliability, two life profiles have been used. The first one is describing a temperate climate which has the same environmental parameters during the entire year and the second is an tropical climate that has four seasons, with different temperatures and humidity. The table with environmental data are shown in Figure 6.2.
The difference between the two cases is that there is a higher relative humidity and larger temperature difference in the tropical climate. This should not result in a big difference in failure probability but it should be noticeable.
These life profiles and environment conditions are chosen because it is a pos-sible use also for a airplane. The flight time represents a flight of little more that an hour every other day. This may not be the normal use for a medium large passenger plane.
When doing calculations following the FIDES methodology a lot of knowledge about which type of component and specific data on that component are required as parameters. In this case the component specific data are chosen to realistic values since specific data of the individual component could not be accessed. But since it is the same for the two test cases it will not affect the comparison between them.
The IC component are set as an microprocessor with 80 pins which is considered to be realistic. The actuator is an relay and the dcSupply is modeled as a battery.
6.3
Results
To calculate the failure probability of the system the reliability module in RODON is used. The MTBF is calculated for each individual component and for the system function the failure probability is calculated. The calculated values can be seen in Table 6.1.
temperate climate tropical climate MTBF for ECU [hours] 9.524 ∗ 108 1.8538 ∗ 108 MTBF for dcSupply [hours] 42169 42149
MTBF for actuator [hours] 6.5058 ∗ 106 4.3615 ∗ 106 Failure probability 1.410050796 ∗ 10−5 1.410050848 ∗ 10−5
Table 6.1. Calculated failure probability in the two test cases
The exact values are not that interesting because the component specific data is from an estimation of what is realistic for this type of system. What is interesting is that the different usage of the system gives a different reliability. This test is a way to see if the implemented FIDES library are able to produce calculated failure probability and show that an harsher environment results in an higher failure probability.
The result confirms this assumption. The tropical climate gives an lower MTBF-value on the components and an higher failure probability on the
sys-30 Testing FIDES on Steer by Wire Example
tem. This is an expected result though bigger temperature changes and higher humidity should generate more stress on the components.
The differences are very small between the cases this can be explained by it is the exact same component and the difference in environment conditions are not that big.
6.3 Results 31
Figure 6.2. Environmental data for the usage profiles of a temperate and a tropical
Chapter 7
Related work
7.1
Manual procedure
Performing reliability prediction without the help of a computer tool is possible. A table consisting of a number of parameters that describes different usage of a component is often supplied by the manufacturer of high reliability components. The parameters are combined in a defined way to get an failure rate of the compo-nent. Looking through these tables are done manually by an engineer. Performing reliability prediction this way is very time consuming since one component at a time has to be evaluated. After calculating failure rate for each component the failure probability for the entire system has to be calculated. To compare different usage means every component has to be evaluated again.
7.2
Relex
Another reliability prediction tool that can be used is Relex [11]. The difference between RODON and Relex is that Relex does not uses the model based approach to reliability prediction. Relex uses a interface which is table based. There is a big table over all the components and there failure rates, where systems in RODON is shown in a graphical way as they appear in a circuit diagram. Graphs can be made of failure rate versus parameters that that failure rate is dependent of.
7.3
Isograph
Isograph [7] is another tool that can be used to perform reliability predictions. It uses a tree structure to show all the components that make up a system. If a com-ponent is highlighted in the three structure all data about the specific comcom-ponent can be accessed. Just as in Relax graphs can be created that show a components failure rate versus temperature or another parameter that affects the failure rate.
Chapter 8
Conclusions
The main objective of this thesis was to investigate if it is possible to perform reliability calculations according to the FIDES methodology in a model based reasoning tool. The chosen tool was RODON. A prototype has been implemented in RODON to show how calculations following FIDES methodology can be done with a model-based approach.
This prototype uses the existing model-based ways that RODON are designed for and adds the functionality of calculating a failure rate. The failure rate func-tionality is implemented with a model based approach. A library of different components was developed and is now ready to be used, by drag and drop. Each component in the library contains all the equations that is needed to calculate its failure rate.
This structure of the library is working as shown by the test system in Chapter 6, where a different failure probability was achieved with different usage profiles. In the test system different failure probability was achieved with different life pro-files. This shows that the calculation of the failure rate according to FIDES is possible to do with a model-based approach.
The definition of usage profiles are done in a non system specific way. By choosing this approach the defined usage profiles can be reused in other systems. The implementation of the FIDES methodology has been done without having to do any changes to the software RODON.
Whether it is RODON or another diagnosis tool that is used there are big advantages with using a model-based approach to performing reliability prediction. Time saving is one of the biggest advantages with a model-based approach since a library of components, once created, exists and can be added to a system by drag and drop. A library of usage profiles also saves time so that a new usage profile does not have to be defined for each new system that is being modeled. To achieve a high reliability of a product it is crucial that different designs are considered in every step of the development process in order to find the optimal design from a reliability point of view. Since it is less time consuming to perform reliability
36 Conclusions
prediction this way it is more likely that the reliability is considered in every step of the development of a product.
The combination of drag and drop method for constructing complex systems and defining usage profiles separate from the system makes a model-based ap-proach a very efficient way to perform reliability predictions according to the FIDES methodology.
The model-based approach is a well established method in many areas, so there is a lot of knowledge of how to build models in a good way. As shown in this thesis the model-based approach is an excellent way to perform reliability calculations in any step of the development process. The conclusion that can be drawn is that there is no reason why the model-based approach should not become the standard way for performing reliability predictions.
8.1
Further development
The library developed for performing reliability calculations according to the FIDES methodology is only a prototype of how it could be done. To implement full sup-port in RODON the rest of the components that are described in FIDES guide 2009 needs to be implemented. This can be done in the same manner as the now implemented components with FIDESBaseComp as superclass.
Bibliography
[1] The Modelica Association. Modelica - a unified object-oriented language for physical systems modeling language specification version 3.1. URL: http://www.modelica.org/index_html/documents/ModelicaSpec31.pdf, 2009.
[2] International Electrotechnical Commission. Iec 60050-191, para. 191-02-06. URL: http://dom2.iec.ch/iev/iev.nsf/display?openformievref=191-02-06, Version 4.17, 27 September 2005.
[3] Mattias Nyberg Erik Frisk. Model Based Diagnosis of Technical Processes. LiuTryck, 2008. ISBN 0-201-52983-1.
[4] The FIDES Group. FIDES guide 2009. FIDES Group, May 2009. [5] Sörman information & Media AB. Rodon maunal v3.14. January 2006. [6] Torkel Glad Lennart Ljung. Modellbygge och simulering. Studentlitteratur,
2004. ISBN 91-44-02443-6.
[7] Isograph Ltd. Reliability workbench. URL: http://www.isograph-software.com/rwbover.htm, 2009.
[8] Trond Østerås Marvin Rausand, D.N. Prabhakar Murthy. Product Reliabil-ity, Specification and performance. Springer, 2008. ISBN 978-1-84800-270-8. [9] United States Department of Defence. Military handbook electronic reliability
design handbook. MIL-HDBK-338B, 1 October 1998.
[10] United States Department of Defence. Military handbook reliability predic-tion of electronic eqipment. MIL-HDBK-217, Version 4.17, 2 December 1991. [11] Relex. Relex reliability prediction software. URL:
http://www.relex.com/products/prediction.asp, 2009.
Appendix A
Abbreviation
A list of the abbreviation that are used in this thesis. • MTBF: Mean time between failure
• COTS: Commercial of the shelf
• MIL-HDBK-217: Military Handbook, Reliability prediction of electronic equipment [10]
• IEC: International Electrotechnical Commission • ECU: Electronic control unit
• MBD: Model based diagnosis • IC: Integrated circuit
