# Presentation: 144685

## Assessing the Effect of Failure Severity, Coincident Failures and Usage-Profiles on the Reliability of Embedded Control Systems

*ACM Symposium on Applied Computing*
*Nicosia Cyprus*
- March 16, 2004

## Agenda

- Synopsis, Goals, Definition and Motivation
- Example Embedded System – The Anti-lock Braking System
- Modeling Strategy, SPN Models and SAN Models
- Reliability Analysis Results and Discussion
- Conclusion and Scope of Future Work

## Synopsis: Stochastic Modeling Case Study of Anti-lock Braking System

- Problem/Domain: Model road vehicle ABS emphasizing *failure severity*, *coincident failures* and *usage profiles* using SPNs and SANs formalisms.
- Challenges:
- Need to handle large state space –complex systems often include many layers of complexity and *numerous* constituent components
- For realistic results we must model components to a sufficient level of detail
- Models should be scalable and extensible to accommodate the larger context
- Benefits: Greater insight about contribution of components and non-functional factors to the overall system reliability.
- Establishes a framework for studying important factors that determine system reliability
- Related work:
- F.T. Sheldon and K. Jerath, “Specification, safety and reliability analysis using Stochastic Petri Net models”, in Proc. Int’l Symp. on Applied Computing , Nicosia Cyprus, pp. 826-833, Mar. 14-17, 2004.

## Synopsis: Stochastic Modeling Case Study of Anti-lock Braking System

- Problems/Results: Transient analysis of SPNs (using Stochastic Petri Net Package v. 6) and Stochastic Activity Network (UltraSAN v. 3.5) models was carried out and the *results compared for validation purposes*.
- Results emphasized the importance of modeling failure severity, coincident failures and usage-profiles for measuring system reliability.
- Status/Plans:
- Carry out the *sensitivity analysis* for the models developed to gain an insight into which components affect reliability more than others.
- Model the entire system. ABS is a small part of the *Dynamic Driving Regulation* system and shares components with the ESA (Electronic Steer Assistance) and TC (Traction Control).
- Simulation needed to model of the entire system. The model of the system would be too complex to allow numerical means of analysis.
- Validate the results of the analysis against real data (should data become available).

## DDR (Dynamic Driving Regulation System)

**DDR ****(Dynamic Driving Regulation System)**

## The Modeling Cycle

- Descriptive modeling
- Computational modeling
- Making it tractable
- Model solution
- Validation and model refinement
- Operational
- Proposed

## State Transition System

- Deciding how the faults affect nominal and off nominal operation
- Failure modes
- Loss of vehicle
- Loss of stability
- Degraded function
- Over/Under-steer

## Slide 8

## Goals

*Model* and analyze the Anti-lock Braking System (ABS) of a passenger vehicle.
- Model *severity of failures*, *coincident failures* and *usage-profiles.*
- Carry out the *reliability* analysis using different stochastic formalisms – Stochastic Petri Nets (SPNs) and Stochastic Activity Networks (SANs).
- Develop an approach that is generic and extensible for this application domain.

**Notes:**
The research models and analyzes the Anti-lock Braking system of a passenger vehicle.
Special emphasis is laid on modeling extra-functional characteristics of severity of failures, coincident failures and usage-profiles
The modeling and analysis is carried out using two different stochastic formalisms – Stochastic Petri Nets (SPNs) and Stochastic Activity Networks (SANs)

## Definition (1)

***Model***: An abstraction of a system that includes sufficient detail to facilitate an understanding of system behavior.
***Reliability***: Probability that a system will deliver intended functionality/quality for a specified period of time, given that the system was functioning properly at the start of this period.
***Failure***: An observed departure of the external result of operation from requirements or user expectations.

**Notes:**
A model is an abstraction of a system that includes sufficient detail to facilitate an understanding of system behavior. The purpose of building a model is to evaluate and predict the behavior of the system that is modeled. The model is studied as a surrogate for the actual system. Hence, the model should reflect the important system characteristics to be useful. 

The behavior that I focus on, in my research is the reliability of the Anti-lock Braking System. Reliability is the probability that a system will deliver its intended functionality/quality for a specified period of time, given that the system was functioning properly at the start of this period.

An observed departure of the result of operation from requirements or user expectations is called a failure.

## Definition (2)

***Severity of failure***: The impact the failure has on the operation of the system. An example of a service impact classification is critical, major and minor.
***Coincident failures***: All failures are not independent. Components generally interact with each other during operation and affect the probability of failure of other components.
***Usage-Profiles***: Quantitative characterization of how a system (hardware and software) is used. (a.k.a. operational profiles, workload)

**Notes:**
The study focuses on the extra-functional characteristics of severity of failure, coincident failures and usage-profiles.

Severity of failure is the impact the failure has on the operation of the system. One impact classification would be critical, major and minor. Many such different classifications are possible and depends on the system under study.

Failures occurring in a system may not be independent. A system is built up of components and these components generally interact with each other during operation. Failure of one component might affect another component and cause it to fail. This is called coincident failures or correlated failures.

Usage-profile is the quantitative characterization of how a system is used. Also known as operational profile or workload. The reliability of a system depends on its usage-profile – users interact with the system in an intermittent fashion, resulting in operational workload profiles that alternates between periods of “Active” and “passive” use. Failures occurring during the “Active” use of the system only should contribute to reliability calculations.

Independent models overestimate the dependability of the model by orders of magnitude

## Motivation

- Reliability analysis of an ABS model to predict/estimate the likelihood and characteristic properties of failures occurring in the system.
- Reliability function & Mean Time To Failure (MTTF).
- The need for a realistic, scalable & extensible model
- Important to model severity and coincident failures
- Important to model usage-profiles
- Comparing results from two stochastic formalisms – SPNs and SANs
- Validation by comparison against actual data beyond the scope of this research.

**Notes:**
The motivation for the reliability analysis of an ABS is extremely high as it can provide an insight to automobile designers about the “weak links” in the system, an increased understanding about which components are likely to fail, and estimate the likelihood of failures occurring in the system 

The model needs to be realistic enough to incorporate the features that affect reliability calculations. Do these include severity, coincident failures and usage-profiles? This is answered by the results from the analysis of the models developed. Further, any model developed should be extensible or scalable to include other such characteristics if required.

Two different formalisms – SPNs and SANs are used to model and analyze the ABS. The motivation behind doing this is to be able to compare the results from the two analyses. Validation of the results against actual data being beyond the scope of this research, this is the second best approach used by scientists to validate their results.

## Synopsis, Goals, Definition and Motivation
Example Embedded System – The Anti-lock Braking System
Modeling Strategy, SPN Models and SAN Models
Reliability Analysis Results and Discussion
Conclusion and Scope of Future Work

**Example Embedded System – The Anti-lock Braking System**
- Modeling Strategy, SPN Models and SAN Models
- Reliability Analysis Results and Discussion
- Conclusion and Scope of Future Work

- Part II

## Anti-lock Braking System (1)

- An integrated part of the braking system of vehicle.
- Prevents wheel lock up during emergency stop by modulating  wheel pressure.
- Permits the driver to maintain steering control while braking.
- Main Components
- Wheel speed sensors.
- Electronic control unit (controller).
- Hydraulic control unit (hydraulic pump).
- Valves.

**Notes:**
The system that has been modeled is the Anti-lock braking system. It is an integrated part of the braking system of the vehicle. It prevents wheel lock-up during emergency stop by modulating the wheel pressure. And this permits the driver to maintain steering control while braking.

The main components of the ABS are the wheel speed sensors, the electronic control unit also called the controller, the hydraulic control unit and the valves.

## Anti-lock Braking System (2)

- Functioning
- Wheel speed sensors measure wheel-speed.
- The electronic control unit (ECU) “reads” signals from the wheel speed sensors.
- If a wheel’s rotation suddenly decreases, the ECU orders the hydraulic control unit (HCU) to reduce the line pressure to that wheel’s brake.
- The HCU reduces the pressure in that brake line by controlling the valves present there.
- Once the wheel resumes normal operation, the control restores pressure to that wheel’s brake.

**Notes:**
The wheel speed sensors measure the wheel speed and the controller reads these signals from the speed sensors. At the time of braking, if the wheel’s rotation suddenly decreases (Which is an indication that it is locking up), the controller orders the HCU to decrease the line pressure to that wheel’s brake. The HCU does that by controlling the valves present in the brake line. When the wheel resumes normal operation, the pressure is restored back.  This pulsing in the pressure in the brake line can occur upto 15 times per second.

## Top Level Schematic of ABS

**Notes:**
The top level schematic of the ABS shows the sensors, processing and actuators.
Point out – speed sensors, brakes, HCU And ECU.

## Detailed Schematic

**Detailed Schematic**

## ABS Assumptions

- Modes of operation (different levels of degraded performance  *failure severity*)
*Normal operation*
*Degraded mode*
*Lost stability mode*
- Lifetime of a vehicle: 300-600 hrs/yr for an average of 10-15 yrs (i.e. 3000-9000 hrs)
- Four-channel four-sensor ABS scheme

**Notes:**
A number of assumptions about the ABS were made.

The modes of operation (different levels of degraded performance) assumed were: normal operation, degraded mode and lost stability mode. Critical failures seriously impact the operation of the system, and are assumed to cause loss of vehicle. This assumption introduced on the basis of the failure data available and shown on the next slide.

The average lifetime of a vehicle 3000-9000 hrs. This estimate important while considering the duration for which to carry out the reliability analysis.

Different schemes of ABS are present like 4channel 4 sensor, 3 channel 3 sensor, 2 channel 2 sensor etc. Assume a 4C4S ABS for this study.

## Failure Rates of Components†

| 
Component | 
# | 
Base Failure Rate | Probability |  |  |
| --- | --- | --- | --- | --- | --- |
|  |  |  | Degraded Operation | Loss of Stability | Loss of Vehicle |
| Wheel Speed Sensor | 4 | 2.00E-11 | 0.38 | 0.62 | - |
| Pressure Sensor | 4 | 1.50E-11 | 0.64 | 0.36 | - |
| Main Brake Cylinder | 1 | 1.00E-11 | - | - | 1.0 |
| Pressure Limiting Valve | 2 | 6.00E-13 | - | 0.22 | 0.78 |
| Inlet Valve | 4 | 6.00E-13 | - | 0.18 | 0.82 |
| Drain Valve | 4 | 6.00E-13 | - | 0.19 | 0.81 |
| Toggle Switching Valve | 2 | 6.00E-13 | 1.0 | - | - |
| Hydraulic Pump | 2 | 6.80E-11 | - | - | 1.0 |
| Pressure Tank | 2 | 2.00E-12 | - | - | 1.0 |
| Controller | 1 | 6.00E-12 | 0.2 | 0.4 | 0.4 |
| Tubing | 1 | 3.00E-12 | 0.33 | - | 0.67 |
| Piping  | 1 | 4.00E-12 | 0.33 | - | 0.67 |

- Obtained from DaimlerChrysler. The data has been falsified for publishing as part of this research.

**†**

## Synopsis, Goals, Definition and Motivation
Example Embedded System – The Anti-lock Braking System
Modeling Strategy, SPN Models and SAN Models
Reliability Analysis Results and Discussion
Conclusion and Scope of Future Work

- Example Embedded System – The Anti-lock Braking System
**Modeling Strategy, SPN Models and SAN Models**
- Reliability Analysis Results and Discussion
- Conclusion and Scope of Future Work

- Part III

## Stochastic Modeling

- Mathematical (numerical solution) method
- Defined over a given probability space and indexed by the parameter *t *(time).
- Markov Processes
- Memoryless property: Future development depends only on the current state and not how the process arrived in that state.
- Markov Reward Models (MRM): Associate reward rates with state occupancies in Markov processes.
- Common solution method for performability.

**Notes:**
A Markov process is a stochastic process whose dynamic behavior is such that probability distributions for future development depends only on the present state and not on how the process arrived in that state. (the so-called memory less property).

MRMs are a common technique for modeling degradable systems. MRM associates reward rates with state occupancies in Markov processes. Can be used to obtain not only system performance but also system reliability/availability measures, also combined measures.

## Modeling Challenges

- Practical Issues
- Obtaining reliability data
- Limited ability of capturing interactions b/w components
- Need to estimate fault correlation b/w components
- Incorporating usage information
- Direct validation of results
- Problems in stochastic modeling
- Large state space: Size of the Markov model grows exponentially with no. of components in the model.
- Stiffness: Due to the different orders of magnitude of failure rates.

**Notes:**
Markov models have been used successfully in numerous instances to specify and evaluate the performance/reliability of systems. However, practical issues that stand in the way of developing models include:
Obtaining reliability data of components
A simple model is able to capture only limited interactions between components
The need to estimate the fault correlation between components.
Incorporating usage-information into the model.

Further problems associated with stochastic modeling are:
- Large state space: The size of a Markov model grows exponentially with the number of components in the model. If there are n components, the Markov model may have upto 2^n states.
- Stiffness: Due to the different orders of magnitude between the rates of events.

These problems cause the analysis to take a lot of time.

A number of techniques exist that can be used to generate the (large) underlying Markov models automatically from a concise description of the system. SPNs and SANs.

## Stochastic Petri Nets (SPNs)

- Graphical and mathematical tool for describing and studying concurrent, asynchronous, distributed, parallel, non-deterministic and/or stochastic systems.
- Concise description of the system, which can be automatically converted to underlying Markov chains.
- Bipartite directed graph whose nodes are divided into two disjoint sets: *places* and *transitions.*

**Notes:**
Petri Nets are abstract formal models that have been developed in search for natural, simple and powerful methods fpr describing and analyzing the flow of information and control in systems.

They are a graphical and mathematical tool for describing and studying concurrent, asynchronous, distributed, parallel, non-deterministic and /or stochastic systems.

## Stochastic Petri Net Symbols

|  | Places (drawn as circles) represent conditions. |
| --- | --- |
|  | Transitions (drawn as bars) represent events. Timed transitions and Immediate transitions. |
|  | Arcs (drawn as arrows) signify which combination of events must hold before/after an event. Input arcs and Output arcs. |
|  | Inhibitor arcs (drawn as circle-headed arcs) test for zero marking condition. |
|  | Tokens (drawn as small filled circles) denote the conditions holding at any given time. |

## Stochastic Petri Net Package

- Stochastic Petri Net Package (SPNP) allows specification of Stochastic Reward Nets (SRNs)  and the computation of steady-state, transient, cumulative, time-averaged measures.
- SRNs are specified using CSPL (C-based Stochastic Petri net Language).
- Sparse Matrix techniques are used to solve the underlying Markov Reward Model (MRM).
- Version 6

**Notes:**
A number of software packages exist that enable the performability and reliability analysis of SPNs. The SPNP has been developed by Ciardo et al. at Duke university.

## SPN Models Representing Severity and Coincident Failures (1)

**Assumptions**
- Exponential Failure Rates to allow Markov chain analysis
- Levels of failure severity: degraded mode, loss of stability (LOS) and loss of vehicle (LOV)
- Impact of failure on failure rates:
- Degraded – two orders of magnitude
- LOS – four orders of magnitude
- Limited number of inter-dependencies modeled

**Notes:**
To model complex systems, assumptions need to be made. The assumptions made for modeling severity of failures and coincident failures are:
To allow a Markov chain analysis, the time to failure of all components is assumed to have an exponential distribution. This signifies that the distribution of the remaining life of the component does not depend on how long the component has been operating.
Levels of failure severity
Impact of failure severity and coincident failures on failure rates.
Limited number of coincident failures modeled.

## SPN Models Representing Severity and Coincident Failures (2)

- All ABS components represented in the global model.
- Components grouped according to their cardinality.
*degraded_operation*, *loss_of_stability* and *loss_of_vehicle* places model severity of failure.
- Next slide shows controller detail...

**Notes:**
To model the inter-dependence in the Anti-lock Braking System it is important to use a global Markov model. The ABS is represented as a combination of all the important components it consists of. The components are sorted into two groups: central and axle. 

The components under axle are further segregated according to the corresponding wheel – FRWheel (Front Right Wheel), FLWheel (Front Left Wheel), RRWheel (Rear Right  Wheel) and RLWheel (Rear Left Wheel). This division into groups is representative of the number of a given component present in the system. A component like the Wheel Speed Sensor, one for each wheel, finds its place under each of the four wheel categories (FRWheel, FLWheel, RRWheel and RLWheel). A component like the Hydraulic Pump, one for each axle, finds its place in the axleCentral group under the axle place. A component like the Main Brake Cylinder, of which there is only one instance, finds its place under the central category. 

The places degraded_operation, loss_of_stability and loss_of_vehicle model the severity of failure. The system is functioning normally when there are no tokens in any of these places.

The model is instantiated with a single token in the start place. When the central_op and the axle_op transitions fire, a token is deposited in each place that represents a component of the ABS. The operation of each component is now independent of every other component 

## SPN Models Representing Severity and Coincident Failures (3)

- Every component either functions “normally” as shown by *controllerOp* or “fails” as shown by *controllerFail*.
- Failed component may cause degraded-operation, loss-of-stability or loss-of-vehicle.
- Degraded-operation/ loss-of- stability: component continues to operate with increased failure rate (by 2 and 4 orders of magnitude respectively).

**Notes:**
Every component either functions “normally” as shown by the controllerOp transition or “fails” as shown by the controllerFail transition. 
A failed component may either cause degraded operation, loss of stability or loss of vehicle (as represented by the controllerDegradedOp, controllerLOSOp and controllerLOV immediate transitions respectively). The probability of any one of these three transitions occurring (obtained from measures on the real system) is different for each component. 

When the failure causes either degraded operation or loss of stability, the component continues to operate (token recycled back to the controller place), though the failure rate increases by two and four orders of magnitude respectively. 

## SPN Models Representing Severity and Coincident Failures (4)

- Each failure transition has a variable rate determined by a corresponding function.
- Failure of component B affects failure rate of component A by including the condition:
- 	if *failedB* then
- 	     *failureA* = *failureA* * *order*
*	*where *order* is 100 in case of degraded operation and 10000 in case of loss of stability.

**Notes:**
The failure of a component A to a degraded mode causes the failure rate of a “related” component B to increase by two orders of magnitude. The failure of component A to a lost stability mode causes the failure rate of a “related” component B to increase by four orders of magnitude. (There was no data available to confirm or validate this assumption for modeling coincident failures). 

## SPN Models Representing Usage-Profiles (1)

- User’s interact with the system in an intermittent fashion, resulting in operational workload profiles that alternate between periods of “active” and “passive” use.
- Assumptions
- Exponential Failure Rates to allow Markov chain analysis.
- Infinite repair rate  all repairs occur instantaneously.
- Exponentially distributed workload.
- Two usage-profiles: Low usage and High usage which are *two* orders of magnitude different.

**Notes:**
Infinite repair rate is realistic: Repair is considered only when a failure occurs when the component was not in active use ( or was in passive use). Such a failure (in passive mode) does not affect the reliability of the system, and hence is equivalent to never having occurred. As a result, instantaneous repair time (or infinite repair rate) is justified. This is achieved by assigning a rather high value to the repair transition as compared to the failure transitions. (say 1 to repair transition against 1e-11 to failure transitions). 
If we did not have this assumption, we would have to assign appropriate “repair rate” to these repair transitions.

## SPN Models Representing Usage-Profiles (2)

**SPN Models Representing Usage-Profiles (2)**

- When a component fails, check if it was in “active” use or not.
- The parameter 1/*mu* indicates the mean duration of active use while the parameter 1/*alpha* indicates the mean duration of passive use.
- Failure of component in “active” mode only affects reliability.

**Notes:**
In case of a failure (failedController), the model differentiates between the two situations regarding whether the system was in active use (along the branch to transition labeled mu) or not (along the branch to transition labeled alpha). 

The parameter 1/mu indicates the mean duration of active use while the parameter 1/alpha indicates the mean duration of passive use. 

In the case where the failure occurs during the active period (inUseController), the system either continues to operate in the degraded (controllerDegradedOp) or lost stability mode (controllerLOSOp) or causes loss of vehicle (controllerLOVOp). In the case where the failure occurs during passive use of the system (repairableController), the fault can be repaired and an infinite repair rate is assumed. The system continues to operate as if no failure had occurred. 

## SPN Models Representing Usage-Profiles (3)

- State explosion problem due to increased number of states.
- Work-around: The model was simplified to incorporate the usage parameters while calculating the failure rate itself for each component.
- The value of *mu* was assumed to be 2.5 for infrequent use periods and 250 for frequent use periods.

## SPN Reliability Measure

- Reliability measure expressed in terms of expected values of reward rate functions.
- The *reliab()* function defines a single set of 0/1 rewards.
- Used as an input argument to
- void pr_expected(char* string, double (**func*)())
- provided by SPNP that computes the expected value of the measure returned by *func*.

## SPN Halting Condition

- Necessary to explicitly impose a halting condition because the developed SPN models recycle tokens.
- The system is assumed to fail when
- > 5 components function in a degraded mode, or
- > 3 components cause loss of stability, or
- the failure of an important component causes loss of vehicle.

## Stochastic Activity Networks (SANs)

- A generalization of SPNs, permit the representation of concurrency, fault tolerance, and degradable performance in a single model.
- Use *graphical primitives*, are *more compact* and provide *greater insight* into the behavior of the network.
- Permit both the representation of complex interactions among concurrent activities (as can be represented in SPNs) and non-determinism in actions taken at the completion of some activity.

**Notes:**
SPNs are limited in their expressive power. SANS are an extension to SPNs.

## Stochastic Activity Network Modeling Constructs

|  | Places (drawn as circles) represent the state of the modeled system |
| --- | --- |
|  | Activities (drawn as ovals) represent events. Timed and Instantaneous activities. Case probabilities (as circles on right of activity). |
|  | Input Gates (triangles with point connected to activity) control the enabling of activities. |
|  | Output Gates (triangles with flat side connected to activity) define the marking changes that occur when activity completes. |

## UltraSAN

- An X-windows based software tool for evaluating systems represented as SANs.
- Three main tools: SAN editor, composed model editor, performance model editor.
- Analytical solvers as well as simulators available.
- Steady-state and transient solutions are possible.
- Reduced base model construction used to overcome largeness of state-space problem.
- Version 3.5

**Notes:**
* Steady-state and transient solutions are possible: Different solvers are available for steady-state and transient solutions. Each solver uses a different approach like Successive Over Relaxation (SOR), Uniformization etc.

* Reduced base model construction: Before running any of the analytic solvers, the state space must be generated, following the reduced base model construction approach.  Largeness of state space is overcome by constructing a reduced base model. This model retains only the necessary information for a desired output measure. 

## SAN Models Representing Severity and Coincident Failures (1)

- Assumptions
- Exponential Failure Rates to allow Markov chain analysis
- Levels of failure severity: degraded mode, loss of stability (LOS) and loss of vehicle (LOV)
- Impact of failure on failure rates:
- Degraded – two orders of magnitude
- LOS – four orders of magnitude
- Limited number of inter-dependencies modeled

## SAN Models Representing Severity and Coincident Failures (2)

- Three individual SAN sub-models: Central_1, Central_2 and Wheel (replicated four times).
- The division into three sub-categories done to facilitate  representation of coincident failures.
- Avoid replication of sub-nets where unnecessary.

## SAN Models Representing Severity and Coincident Failures (3)

- All subnets share common places: *degraded*, *LOS*, *LOV* and *halted*.
- Presence of tokens in *degraded*, *LOS*, and *LOV* places indicates degraded operation, loss of stability and loss of vehicle resp.
- Output cases of an activity have different probabilities to model conflict between the outcome of failure.

## SAN Models Representing Severity and Coincident Failures (4)

- Degraded-operation/ loss-of- stability: failure rate increases (by 2 and 4 orders of magnitude respectively).
- Failure of component A to degraded mode causes the failure rate of component B to increase by 2 orders.
- Failure of component A to a loss of stability mode causes the failure rate of component B to increase by 4 orders.

**Notes:**
Severity: The controllerFail activity models the failure of the controller. There are three possible outcomes of this activity. The controller either fails causing degraded operation (Case 3 with probability 0.2), or causes loss of stability (Case 2 with probability 0.4), or causes loss of vehicle (Case 1 with probability 0.4). UltraSAN requires the failure rate to be specified in a single statement, hence the use of the special if-then-else construct available in the C programming language. If the controller fails causing degraded operation (i.e., MARK(controllerDegraded)!=0), it continues to function manifested by recycling the token back to the controller place, and the failure rate for the controllerFail activity increases by two orders of magnitude (i.e. controllerRate*100). Similarly, if the controller fails causing loss of stability (i.e., MARK(controllerLOS)!=0), it continues to function manifested by recycling the token back to the controller place, and the failure rate for the controllerFail activity increases by four orders of magnitude (i.e. controllerRate*10000). 

Coincident failures: Consider the controllerFail activity. Since a failed tubing (in degraded mode) is assumed to affect the failure rate of the controller, if the number of tokens in the tubingDegraded place is not zero (i.e., MARK(tubingDegraded)!=0), the failure rate for the controller increases by two orders of magnitude (i.e., controllerRate*100). Similarly, for the hydraulicPumpFail activity, we have assumed that a failed controller affects the failure rate of the hydraulic pump. Thus, the failure rate for the hydraulic pump increases by four orders of magnitude if the controller has failed causing loss of stability, and increases by two orders of magnitude if the controller is operating in a degraded mode. 

## Slide 46

## SAN Models Representing Usage-Profiles (1)

- Assumptions
- Exponential Failure Rates to allow Markov chain analysis.
- Infinite repair rate: all repairs occur instantaneously.
- Exponentially distributed workload.
- Two usage-profiles: Low usage and High usage which are *one* order of magnitude different.

## SAN Models Representing Usage-Profiles (2)

- When a component fails, check if it was in “active” use or not.
- Failure of component in “active” mode only affects reliability.
- Work around the state explosion problem by incorporating the usage parameters while calculating the failure rate of component (lambda+mu).
- mu same for all components

## SAN Reliability Measure

- Reward rates specified using a predicate and function.
- If the system is not in an absorbing state (system failed), reliability is a function of the number of tokens in *degraded*, *LOS* and *LOV*.
- For normal operation, the function evaluates to 1. Reliability is 0 when the predicate evaluates to false, by default.

## SAN Halting Condition

- Input condition on each activity states that it is enabled only if there is no token in *halted* place (common to all subnets).
- Presence of token in *halted* place indicates an absorbing state.

## Synopsis, Goals, Definition and Motivation
Example Embedded System – The Anti-lock Braking System
Modeling Strategy, SPN Models and SAN Models
Reliability Analysis Results and Discussion
Conclusion and Scope of Future Work

- Example Embedded System – The Anti-lock Braking System
- Modeling Strategy, SPN Models and SAN Models
**Reliability Analysis Results and Discussion**
- Conclusion and Scope of Future Work

- Part IV

## SPN Reliability Analysis Results

- Transient Analysis carried out using SPNP (Stochastic Petri Net Package) version 6 on a Sun Ultra 10 (400 MHz) with 500 MB memory.
- 164,209 tangible markings of which 91,880 were absorbing.
- Approximate running time of the solver was 144-168 hrs.

## SPN Results for Coincident Failures and Severity (1)

- The Y-axis gives the measure of interest i.e. reliability, the time range (0 to 50K hrs) is along X-axis.
- MTTF for the model with coincident failures (784,856.4 hrs) is ~421 hrs less than without coincident failures (785,277.6 hrs).

## SPN Reliability Analysis Results for Coincident Failures and Severity

**SPN Reliability Analysis Results for Coincident Failures and Severity**

## SPN Reliability Results for Coincident Failures and Severity (2)

- Graph shows the difference between the reliability functions.
- Start diverging around 350 hrs of operation.
- The difference in reliability between the two cases becomes marked (after 13K hrs) only beyond the average lifetime of the vehicle (3K-9K hrs).

## Difference in Reliability Functions (With and without coincident failures)

**Difference in Reliability Functions (With and without coincident failures)**

## SPN Reliability Results for Usage Profiles 

**SPN Reliability Results for *****Usage Profiles***** **

- MTTF for the high usage case is 771,022.9 hrs as opposed to 775,111.7 hrs for the low usage case, a difference of ~ 4089 hrs
- Reliability of the system with heavy usage decreases *alarmingly *(!) within the first 1K hrs, while the reliability of the system with low usage decreases *perceptibly* (!!) only after 2.5K hrs of operation and then steadily thereafter

## SPN Reliability Analysis Results for Usage Profiles

**SPN Reliability Analysis Results for Usage Profiles**

## SAN Reliability Results

- Transient Analysis carried out using UltraSAN version 3.5 on a Sun Ultra 10 (400 MHz) with 500 MB memory.
- 859,958 states generated.
- Approximate running time of the solver (transient solver trs) was 120-144 hrs.

## SAN Reliability Results for Coincident Failures and Severity

- Reliability functions diverge perceptibly after around 1K hrs of operation, difference increases w/ time.
- After 5K hrs the difference is 0.025, after 10K hrs 0.049.
- Time to failure for model with coincident failures is 25,409 hrs, for model without coincident failures is 29,167 hrs (diff. of 3,758 hrs).

## SAN Reliability Analysis Results for Coincident Failures and Severity

**SAN Reliability Analysis Results for Coincident Failures and Severity**

## SAN Reliability Usage Profiles Results

- System Reliability with heavy usage decreases *alarmingly * after 100hrs, while the reliability of the system with low usage decreases only *perceptibly* after 100hrs of operation.
- At the extreme end of average lifetime (9Khrs) of the vehicle, reliability has dropped to ~0 for heavy usage and to ~0.4 for low usage.
- Time to failure for model with low usage is 12,262hrs, for model with high usage is 1,687 hrs (diff. of 10,575hrs).

## SAN Reliability Analysis Results for Usage-Profiles

**SAN Reliability Analysis Results for Usage-Profiles**

## Comparing the SPN & SAN Results (1)

- Because it is beyond the scope of this research to validate the results from the analytic experiments against *real data*, . . .
- we compare the results from SPN & SAN analyses.
- The difference in the range of actual reliability values between the SPN and SAN models may be attributed to the different ways in which the reliability reward is defined.
- See the plots where both curves are in the same graph
- Severity and Coincident Failures
- SPNs - The curves for the two cases completely overlapped.
- SANs -  The curves diverge after 1K hrs of operation.

## Comparison of SPN and SAN Reliability Results for Models Representing Severity and Coincident Failures 

**Comparison of SPN and SAN Reliability Results for Models Representing Severity and Coincident Failures**** **

## Comparison of SPN and SAN Reliability Results for Models Representing Usage-Profiles (with failure severity and coincident failures)

**Comparison of SPN and SAN Reliability Results for Models Representing Usage-Profiles**** (with failure severity and coincident failures)**

## Comparing the SPN & SAN Results (2)

- Usage Profiles
- SPNs – Reliability for high usage decreases alarmingly within first 1K hrs, for low usage only after 2.5K hrs.
- SANs -  Reliability for high usage decreases alarmingly after 100 hrs, for low usage only perceptibly after 100 hrs.
- Results from both models agree on the fact that failure severity, coincident failures and usage-profiles contribute significantly to predicting system reliability.
- Which of these results is more realistic?
- Comparing results does not make up for validation against real data.

## Comparing the SPN & SAN Results (3)

| Criteria | SPN Models | SAN Models |
| --- | --- | --- |
| Assumptions | Same  | Same |
| Reliability measure | Different | Different |
| Number of states | 164,209 | 859,958 |
| Solvers’ Running time | 144-168 hrs | 120-144 hrs |
| Reliability at 9Khrs (severity & co.failures) | 9.5792578e-01 vs. 9.5792653e-01 | 7.3672e-01 vs. 7.8600e-01  |
| Reliability at 9Khrs (usage-profiles) | 8.9621556e-01 vs. 7.6658329e-01 | 4.455167e-01 vs. 3.130521e-03 |

## Synopsis, Goals, Definition and Motivation
Example Embedded System – The Anti-lock Braking System
Modeling Strategy, SPN Models and SAN Models
Reliability Analysis Results and Discussion
Conclusion and Scope of Future Work

- Example Embedded System – The Anti-lock Braking System
- Modeling Strategy, SPN Models and SAN Models
- Reliability Analysis Results and Discussion
**Conclusion and Scope of Future Work**

- Part V

## Conclusions (1)

- Modeling and Analysis: The Anti-lock Braking System of a passenger vehicle was modeled (with emphasis on failure severity, coincident failures and usage profiles) and analyzed.
- Realistic Models: The models were built incrementally to achieve the best balance between faithfulness to the real system and keeping the model tractable at the same time.
- Extensible Models: The models developed can be easily extended to incorporate different levels of severity, other coincident failures and usage levels.

## Conclusions (2)

- Two stochastic formalisms: Stochastic Petri Nets & Stochastic Activity Networks, were used to analyze the developed models for reliability measures.
- Results justified the modeling strategy adopted and highlighted the importance of modeling severity, coincident failures and usage-profiles while examining system reliability.
*This research has successfully established a framework for investigating system reliability and the basis for further investigations in this application domain.*

## Future Work (1)

- Sensitivity Analysis: The analysis of the effect of small variations in system parameters on the output measures and can be studied by computing the derivatives of the output measures with respect to the parameter.
- Model the entire system: The ABS is a small part of the DDR (Dynamic Driving Regulation) system which consists of other subsystems like the Electronic Steering Assistance (ESA) and the traction control (TC).

## Future Work (2)

- Simulation: Evaluate the (complex) model numerically in order to *estimate* the desired true characteristics of the system.
- Validation: Results from experiments on the real system to validate analysis results to incrementally arrive at a realistic model.
- Generalization of modeling strategy for modeling both software and hardware components and the way of representing severity, coincident failures and usage profiles.

## Contact Information