Book Review: Real-Time Design Patterns

reviewed by Graham D. Wall

After winning an autographed copy of Bruce Powel Douglass's newest book, Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems [1], at the Embedded Systems Conference in Boston last November, I felt compelled to review it. Douglass's latest offering is a well-organized wealth of information that features an accurate catalogue of highly recognizable, real-time system-level patterns. Roughly, design patterns are to requirements and design specification as software libraries are to code. The line is a bit blurry as to whether the target audience for this book is introductory or advanced, since the first part is clearly introductory, whereas the second part is best approached having some practical real-time experience under your belt. Nevertheless, I want to emphasize that the applicability of the patterns that Douglass presents here deserves a long look from both neophytes and masters alike.

The first third of this 500-page book is devoted to introductory and review materials that have been developed extensively in Real-Time UML [2] and Doing Hard Time [3]. UML is a well-defined, non-proprietary, intuitive, and extensively used standard. Douglass provides a good overview of UML and related object-oriented theory in the first chapter, and the interested reader may consult his two previous books for more detail.

Douglass defines architecture as "…the set of strategic design decisions that affect most or all of the system" (p. 56) and a design pattern as "a generalized solution to a commonly occurring problem" (p.59). According to Douglass, physical as opposed to logical architecture is the run-time organization of a system that can be described in terms of five different views: subsystem and component, concurrency and resource, distribution, safety and reliability, and deployment. Design patterns are chosen on the basis of Quality of Service properties that they optimize in the system, for example, worst-case performance, safety, and reusability, to list a few.

Next, Douglass reviews the ROPES development methodology. The aim of the Rapid Object-Oriented Process for Embedded Systems is "to produce systems with less effort, fewer defects, and greater project predictability" (p.101). He makes the excellent point that even though the waterfall lifecycle model of software development has been heavily criticized and methodologies such as ROPES are much more practical, most new embedded software projects are still scheduled as linear processes. The reason that a large percentage of software projects are late is that good development is cyclic and intensely iterative, but a linear schedule allows many serious defects to propagate to the final stages of the project before they are detected.

The second part focuses on the book's nominal topic and architectural-design patterns for real-time systems. The design patterns that are discussed in Doing Hard Time are used to bring about particular behaviors of a real-time system, whereas the novel set of patterns that Douglass has "hatched" or "mined" and finally collected in Real-Time Design Patterns are related to a large-scale structure on a system-wide scale. For each pattern, the following are provided to aid the implementer: a pattern abstract, the problem it solves, pattern structure, collaboration rules, consequences, implementation strategies, related patterns, and a sample model.

One of the most important and relevant pattern families elaborated in the book is the set of safety and reliability patterns. Robustness is generally lacking in new embedded products. In a recent issue of Embedded Systems Programming, Jack G. Ganssle recounts the humorous story of when the firmware controlling the range exhaust fan in his kitchen crashed [4]. He harkens unto us:

"What's the embedded world coming to? Will programmers and companies everywhere realize the cost of their mistakes and clean up their act? Or will the entire world become accustomed to occasionally rebooting everything they own? Will expensive embedded devices come with a 'reset' button advertised as a feature?"

I certainly hope that "percussive maintenance" is not the way of the future, and one way to improve the situation is to take the sort of methodology that this book advocates to heart.

Safety and reliability patterns make use of fail-safe states, redundancy, retries, alerts, and system restarts to ensure that the system does not cause accidental loss or harm, and continues to be available at the required times. The designer may choose to increase the availability of the system by using one of the redundancy patterns: Single Protected Channel (the one way of doing something in the system is protected by checks); Homogenous Redundancy (backup copies of the same way of doing something are available to fall back on); Triple Modular Redundancy (an odd number of copies of the same way of doing something exist and are voted upon); or Heterogeneous Redundancy (multiple independent designs of how to do something exist and can be compared or used to fall back on).

Other patterns increase system safety. The Monitor-Actuator pattern checks for conditions that are specified as hazardous to the system and puts the system into fail-safe when these conditions are true. The Sanity Check pattern checks that nothing in the system appears to be seriously wrong, and if one of the checks fails, it puts the system into fail-safe mode. The watchdog pattern checks that the low-level processing of the application code proceeds in a timely manner as expected, but when this check fails it can take a specified action such as resetting the system. The Safety Executive pattern coordinates complex procedures needed to put the system into fail-safe, as opposed to simply resetting the system without doing a graceful shutdown. I think that most designers and their customers would agree with me in saying that these patterns should be used more often in an embedded development.

I recently used the Sanity Check Pattern in an embedded project to handle accesses to configuration parameters stored in the EEPROM of an industrial process measurement device to provide safety and reliability.

The material in this book is accurate, clearly written, and systematically laid out. The example models that Douglass provides with each pattern description should be a good start for most designers to apply to their projects. The advanced reader may easily skip Part I of the book, or simply refer to Douglass's earlier publications, whereas the beginner may want to peruse the first part and then either read the other books or dive head first into implementing these patterns. If you haven't been lucky enough to win this book at a tradeshow, I recommend buying this book to complement either your personal or professional libraries. Douglass's writing style has become more clear and concise since Doing Hard Time, and here, he has managed to make another significant contribution to the embedded culture. Think of Real-Time Design Patterns as a best practices document for use in real-time embedded projects.

Notes

[1] Bruce P. Douglass. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems (Addison-Wesley, 2002).

[2] Bruce P. Douglass. Real-Time UML: Developing Efficient Objects for Embedded Systems (Addison-Wesley, 1998).

[3] Bruce P. Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns (Addison-Wesley, 1999).

[4] Jack G. Ganssle. "Born to Fail," Embedded Systems Programming, January 2003.