Broadly speaking, control systems are broken down into event and continuous(2) time driven domains. Continuous systems are always taking in stimulus and putting out responses. While event driven systems respond when the event happens, the rest of the time they sit patiently quite unlike an 8 year old waiting for the gates of Disneyland to open.(3) A challenge arises when you start to mix the two types of systems together; how do you mix the chocolate of continuous time with the peanut butter of events to create a greater whole?(5)
Everything was going…
smoothly then there was a break
Events interrupt the smooth execution of continuous time systems. If the event preempts the execution of the continuous time system, you are halting the logic and calculations of the system. The return to the execution of the system can pose challenges. Let’s take a look at a few…
Something’s changed
The most common problem that occurs is that when the interrupt event happens there is an overall change in the system state and the data (pre and post interrupt) is no longer in correspondence.(6) This can result in incorrect calculations and / or commands.
Falling behind
In some instances the code associated with events can take a long time; as a result the periodic update of the continuous time system can “fall behind”; potentially missing multiple updates. In some instances important data is missed during that “time out.”
What to do?
Like many situations there is no “one-size fits all” solution; but there are general rules of thumb.
- When something has changed:
- Buffered or protected, data can be used to resume execution of the code with contiguous data.
- A “return from event” handler can be used to determine if a system reset is required.
- Falling behind:
- For the “important” events a buffer can be constructed within the event driven code.
Testing the wind
Testing interrupted code is a sticky problem as by definition, when the interrupt happens it is an unknown. Use of random interrupt generators provide one method for testing the code but cannot provide full coverage. The recommendation for this blog is to create “worst case” interrupts; e.g. look at your model and ask “what is the worst place where the execution could be interrupted” and then do it there…
Worst place for an emergency
- In the middle of nested if/else-if/else logic: The branch you are in may no longer be valid.
- Performing differentiation: When your “dt” changes the diff can wiff(7)
- Fault / error detection: If the code’s job is to detect errors then, well, this is one area where you may want to protect against interrupts.(8)
Footnotes
- Back at the dawn of time “Ring-Ring” was the sound that a phone made, a common “event driven” experience for many people.
- I went back and forth 2 or 3 times on the “continuous time” driven domains. The world we live in is continuous time, it keeps on slipping into the future. However most modern control algorithms are implemented on discreet time hardware and require a discreet time implementation.
- Like an 8 year old who can happily read a book while waiting for the gates(4) to open, the poor control algorithm just sits there waiting for the event to ring.
- That comment may or may not be autobiographical.
- I want to distinguish between states end events; technically the shift from Neutral to First gear in a car is an event; however, it operates within the set of data for the continuous controller. The types of events to be examined are often called “asynchronous” events.
- Back in the old days control algorithms would send long letters betwixt each other, now with email, texts and phones correspondents are less common
- Wiff: to miss, to have an unpleasant smell. Note: in general, integration operations are interrupt tolerant as they average values over time.
- Events and errors come in all levels of severity; setting the priority of the event and the given error handling code enables your OS to arbitrate between the two functions.