Engineering Process: Fault Lines (P1)

Whether you prefer fishing⁽¹⁾ or gardening⁽²⁾ metaphors, for the next few posts I’m going to take you into the process I follow when solving a problem to show you how I fish.

The problem statement

As is often the case, I will pull a problem from work I have done across multiple customers. I do this for two reasons. First, I have vetted the solution “in the field,”⁽⁴⁾ and second I know that this is an issue that is commonly faced.

How do we simulate dropped and corrupted signals inside our system?
Multiple

The first step

The first step in designing a solution is to understand the problem. The questions that I have are…

Does a solution already exist?
What does “inside our system” mean?
In the deployment code where and how can signals be corrupted?

The critical question to answer is “where and how?” There are three primary ways that signals and data can be corrupted. The first is through incorrectly written code; since there are other methods for determining this issue it is usually dropped from the analysis. The second method is through interrupt data events (e.g., the execution of a function is put on hold while a higher priority function executes). The value of data changes during the interrupt resulting in corrupted data. This is of potential interest, however it results in a very large testing scope as the interrupt can occur at any point in function. As a result solutions to this problem are placed at a lower priority.⁽⁵⁾

The final method is through corruption of transmitted signals (e.g., messages sent over CAN / LIN / RS-232).⁽⁶⁾ Thinking about this issue, we get the solution to our second question: what does “inside the system” mean? Transmitted errors occur at the boundary of functions, and from there we have an answer to the first question: does a solution already exist…

What we already have…

For individual models we have a solution; test vectors can be created that simulate dropped and corrupted signals. However for a system of models, Simulink does not have a built-in method for dropping signals for models on the “inside” of the system.

Problem Restatement

With this understanding I came up with a new problem statement. One that reflected the design I would build towards. As you will see in the upcoming blog, there is further iteration on the new problem statement as the life cycle issues are considered.⁽⁷⁾

For a system of models create a method for simulating dropped signals for models not directly connected to the root level I/O

Footnotes

E.g. give a person a fish, they eat for a day, but teach a person to fish and they eat for life.
A teacher is a gardener who plants the seeds of learning in your mind⁽³⁾
That both of these metaphors are about foundational tasks of humanity gives an idea how old this concept is.
Since one of my customers was an agricultural company it was literally validated in multiple fields
That we talk about priorities with interrupts is only appropriate as the priorities determines if the interrupt can occur.
No interface, no matter how ancient ever fully goes away.
This is my “cliff hanger” to bring you back to the next post.