Avoid Design Choices Requiring Hard Real Time Response |
 |
 |
 |
| Written by Graham Stoney | |
|
Embedded systems often perform some sort of real-time processing that has to keep up with events in the real world. These events fall into two classes: those that require a hard real-time response, and those that require a soft real-time response. Hard real-time requirements are harder to meet, and should be avoided when possible.
The distinction between the two is that if a system fails to meet its hard real time requirements, the system fails in some way. And that's bad. On the other hand, if a system fails to meet its soft real time requirements, the performance of the system simply degrades. Often the distinction between a hard real-time system and a soft-real time system is the result of a design choice somewhere in the system, or the subcomponents. Sometimes an off-the-shelf component imposes an interfacing requirement that there is little you can do about. But in other cases, the design choice is simply a trade-off on the part of the designer. Simple modifications to a protocol or a hardware interface can sometimes turn a hard real-time requirement into a soft one. For example, a communication protocol which allows for retries can be tolerant of dropped packets due to missed processing deadlines. Such a system is “soft” in its real-time requirements, and much easier to implement. Standard desktop operating systems like Linux can handle soft real-time requirements in user space; harder real-time requirements may require a kernel space driver, or one of the real-time kernel variants.Real-time operating systems have their place, and you'll never completely do away with measuring interrupt latencies and counting clock cycles in critical sections, but if you can make your system only require a soft real-time response, rather than a hard one, then it will generally be easier to build and debug. Social Bookmark this page:         
|