Back to Intro

Adding degradation levels

In the previous example, we were able to model and query the state and designs of the architecture given a certain hardware failure. It turned out that if we lost any of our sensors, our system would no longer be functional. We address this issue by being less restrictive and allowing functions to fail (i.e. they don’t have a device node to deploy to) but to still allow the system to be considered functional but with some level of degradation.

In order to do this we have to annotate each of our functions with a level of degradation. This level should be based on two things:

1. The degradation level of the incoming connections (inputs).
2. The degradation of the function itself (i.e., if only one of two inputs are provided, we are less functional).

Furthermore, our control functions require at least one input to be considered functional. If the control function does not have any inputs we should remove it from the architecture. This requires that we annotate each function in our FAA to be optional. This means that while the function may not have failed, it is not longer providing any functionality to the system due to underlying hardware failure or missing inputs from cascading effects of removing functionality.

Therefore we need to add the following properties or children clafers to the FunctionalAnalysisComponent concept:

1. Input: The function connector providing the input to the function
2. Output: The function connector providing the output to other functions
3. Degradation Level: The degradation level of the function based on available inputs and hardware used.
   1. Level 1: No degradation - fully functional
   2. Level 2: Slightly degraded but functional to an acceptable standard
   3. Level 3: Severely degraded. Most likely in “limp home”
   4. Level 4: Not functional
4. Resulting Degradation Level: The resulting degradation level which is computed as the maximum of the set containing the incoming input degradation levels and the degradation level of the function itself.

Updated reference model

We encoded these additions as follows in our updated reference model:

Architecture of the autopilot system with degradation levels

We can then modify our architecture by setting these properties correctly as well as writing a set of constraints based on the inputs and outputs of a function to determine if it is functional (i.e., whether it is present in the architecture).

Now we can reason about a failure of the front radar sensor as before and find that a functional architecture does exists, however it is degraded (and we know what the degradation level is)

Replacement Functions to Mitigate Failures

Back to Modeling HW Failures

Back to Intro