Month: March 2017

Projects of Interest (III): Protecting against emergent properties

Published on by Michael BurkeLeave a comment

With today’s control algorithms we no longer deal with systems, rather we work with systems of systems.  (For a comparison the refrigerator I purchased two months ago has a more advanced ECU then my first car)(1).  Because of this, we need to consider fail-safe systems to protect against emergent properties.

Emergent properties can be defined as “a phenomenon whereby larger
entities arise through interactions among smaller or simpler entities such
that the larger entities exhibit properties, the smaller/simpler entities do not
exhibit.”

Fail-Safe systems

Until a solution to the halting problem is found the best we can do is the creation of fail-safe systems.  Fail-safe systems are characterized as

Inherently responding in a way that will cause no or minimal
harm to other equipment, the environment or to people.

3b86d3c4ed6f50dae8b8ba7df6953dda

My safe failures…

Starting off in the automotive industry there was a saying “a critical failure is too much energy; everything else is a fault.” Think of a vehicle oscillating out due to bad shocks or an engine overheating due to a lack of coolant; examples of kinetic and thermal energy overabundance.

If the problem is too much energy that the solution, obviously(2), is to remove energy.  However, let’s take the two cases outlined above.

First in the case of the bad shocks.  The “obvious” method for removing energy is to slow the car down by applying the brakes to slow the vehicle down.  In this case, hard braking can add energy into the system; therefore a slow controlled braking event is required.

Something know is wrong, what should we do?

dr_strangelove_t

First off how do you know something is wrong?  The answer should be that you have a fault detection system in operation.  The fault detection sits outside of your system of systems and monitors the system.  To monitor the system, you need the following information

  1. What are the “standard” operational parameters of the system?  E.g. maximum engine temperature,  biggest “bounce” of your spring?
  2. How long can you be outside of the “normal”?
  3. Are there multiple ways you can be abnormal?
  4. How do you pull the energy out?

The Northstar engine

During my first job, I worked at the GM development center in Flint Michigan.  The work focused on simulations of the Northstar engine and ABS braking systems.  At the time a unique feature of the Northstar engine was the ability to selectively shut down cylinders during steady state cruise; this was shown to provide a 5 ~ 6% fuel economy savings.

NorthStar

At some point during the diagnostic phase of development a bright engineer, not me, realized that the ability to selectively shut down cylinders also provided a way to cool down an overheating engine.

Final thoughts

As our system of systems become more complicated, the protections for those systems have the worrisome trend of becoming more complex.  Ensuring that the fault monitoring systems are independent of each other and do not interject faults into the system will be a topic for a future post.

Footnotes

(1) A sad but true story, the car caught on fire before I was able to drive it more than 100 miles.

(2) Like most obvious solutions it is true in some cases but tragically wrong in others.

(3) Growing up in Michigan during the 80’s Flint and the metro Detroit area was well past their heydays; still was and is a living community.

Video Blog: Fault detection

Published on by Michael Burke2 Comments

This video blog looks at fault detection and error handling.  The included images of State Machines show templates for how I generally model fault detection algorithms.

In this first example there are two things to note:

  1. Debounce protection:  Returning from “move to fault” and “no fault.”  The signal needs to fall below the trigger signal – a delta to the signal.  This prevents “jitter” in the signal.  (Green circle.)
  2. Temporal logic:  The move to “in fault” only takes place after you have held the fault condition as true for a set period of time. (Orange circle and black circle.)

faultPattern

The next example is more complex; in this example, a single variable “engine temp” can result in two different error modes.  “High Temp” or “Critical High Temp.”  In reality, the pattern is a slight variation on the previous version however it shows how it can be expanded to more complex fault conditions.

criticalTemp

Model-Based Design and version control

Published on by Michael Burke4 Comments

In a previous post, I wrote about general best practices for version control.  In today’s posting, I am going to cover using version controls in the Model-Based Design workflow. Note for this blog post, I will be using generic terms for version control practices.

Derived and source objects

A derived object is any file that is generated from a source object or process.  Within a traditional C language development process this would include

  • .lib /.o / .exe
  • Coverage reports
  • Test results
  • Data files
  • …

Like a traditional text-based language approaches a Model-Based Design has both source and derived objects; in the case of Model-Based Design the design objects are one level of abstraction removed from the C source files (1).

automated-test-suite-generation-for-timecontinuous-simulink-models-4-638Utilities and project files

Within the MBD development process, there are both project and utility files(2).  Version control best practices map are influenced by the data and architectural best practices.  We will look at how releases are defined within this context.

What is a release?  When to release?

Within the Model-Based Design context, a release is defined as the set of data and models that

  1. Contains consistent interfaces: the interfaces between the parent and child models are correct and the data definitions are compatible(3)across all the models.
  2. Reached a significant milestone: the models and data capture a significant portion of the desired functionality(4).
  3. Is stable: the models and the data pass a significant(5) percentage of the tests associated with the model.

Keep in mind, releases should not be made on a temporal basis.  E.g. having a release every two weeks is not a good practice unless the conditions above are meet (at least condition 1 and 3.)  At the same time allowing a long time to go between releases can make it more difficult for developers to integrate into the final project.

Version control, models, data and the system architect

Best practices for model architecture recommend a multi-level (integration level/child level) systems.  Within this structure, the controls engineers are responsible for the checking in/out of their models.  Further, they are responsible for ensuring the data that is unique to their models is correct.

The role of the system architect is to ensure that the individual models integrate together.  They do this through the following tasks

  1. Validate that the model’s functional interfaces are compatible
  2. Validate that the use of global data is consistent across models(6)
  3. Running system level tests

In the case where there is a conflict between the functional interfaces or the use of global data, the system architect is responsible for arbitrating those conflicts.

releaseflow

Summary thoughts

Version control best practice for Model-Based Design or any software development is, in the end, dependent on communication between the team working on the software. The larger the team is the more the need for communication increases.  Both documentation of the intended process and linking development to requirements will improve this process. In the end, try not to be this group…

git

Footnotes

(1) For Model-Based Design, the “source files” could be C / C++ / VHDL / PLC or any other textual language.

(2) Utility files should also be placed under version control.

(3) For any given release the data may not be correct, e.g. having the final values as determined through requirements and testing; hence the term “compatible.”

(4) Note in some cases a release may be a ‘branch’ or experimental branch which may not be part of the final release of the software.

(5) The collection of the models and the data do not need to pass all tests, rather they should pass the tests that engineering judgment are considered significant at that point in time.  However, it should be noted that best practice is that as release advance towards the final release the number of tests passing should increase.

(6) Globally used data includes parameters and variables as well as structure definitions and enumerated data types.  As with all software development use of global data should be minimized.