Top 10 modeling hints for system engineers: #4 Design patterns reuse proven solutions

In hint #4 of Bruce Douglass's top 10 modeling hints series you'll learn about the importance of leveraging the experience and knowledge of other designers through abstraction or design pattern reuse.

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rational Chief Evangelist, Systems Engineering, IBM

author photoEmbedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of more than 5,700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space. Bruce consults with and mentors IBM customers all over the world. Follow Bruce on Twitter @BruceDouglass.



26 November 2013

Also available in Chinese Russian Japanese

Design patterns are generalized solutions to commonly occurring problems. That is, they are the abstractions of a set of solutions that solve the same problem in different contexts. The abstraction removes the specifics of the context so that you can reapply the solution in a new context. This allows you to reuse proven solutions as you approach new design tasks. This lets you leverage the experience of other designers. It's a win-win.

For example, consider a safety critical system which uses pressure and flow to perform closed loop control on the delivery of a drug in a medical infusion pump. That system needs to be safe and accurate. Is there a way to arrange design elements to achieve these goals in an optimal way?

Pattern: Protected single channel

Description
Organize the components into a series of control and data transformational steps. Add error and safety checks at component boundaries.
 
Problem
Protects against faults in a cost-effect way.
 
Solution
Organize the components into a series of transformational steps with lightweight redundancy to provide error and safety checks.
 
Consequences
Low-design cost, low-recurring cost, but not able to continue in the presence of a fault, so there must be a fail-safe state.
 

The base pattern looks like Figure 1. The components are connected as a series of transformational elements (Abstract Data Transforms), each of which may add validity and safety checks (Abstract Transformational Checker). The concrete versions elements are where the components in the model are substituted to apply the pattern in your design.

Figure 1. Single channel protected pattern
model of the base pattern

Figure 2 shows an application of this pattern. The pressure and flow sensor components feed in raw data which is passed through a moving average and band pass filter before it is used to calculate the updated position of the pump. Each of these transforms has an element to verify it;

  • Pressure and flow are checked to ensure that they are within reasonable limits
  • Calculated position is verified to ensure that the step taken from the last pump position isn't too large.

If errors are detected, alerts are sent to the alarm manager so that the attending physician can address the problem. In that event, the pump enters its fail-safe state (monitoring, but not delivering drugs).

Figure 2. Application of the single -channel protected pattern
Diagram of the pattern

The Harmony process identifies 5 key views of architecture (see Figure 3). They are:

Subsystem and component view
The large-scale pieces of the system, their responsibilities and interfaces.
 
Concurrency and resource view
The identification of the concurrency units and their scheduling properties, the allocation of software elements to those threads, strategies for task synchronization and policies for resource use.
 
Deployment view
The allocation of responsibilities across different engineering disciplines, such as mechanical, electronic, and software.
 
Distribution view
The decisions about the distribution intelligence across processing nodes and the technology and policies for communication and collaboration.
 
Dependability view
How system integrity ( safety, reliability, and security) is maintained during the execution of the system, including the identification, isolation, and run-time correction of faults and attacks.
 

The system architecture is, in an important sense, the sum of the design decisions and patterns in each of these critical areas.

Figure 3. Harmony 5 key view of architecture
the harmony architecture

You can see design patterns for these different architectural aspects in my books "Real-Time Design Patterns" (Addison-Wesley, 2003) and "Design Patterns for Embedded Systems in C" (Elsevier Press, 2011).

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=954464
ArticleTitle=Top 10 modeling hints for system engineers: #4 Design patterns reuse proven solutions
publish-date=11262013