The document outlines various real-time design patterns in software engineering, categorized into design pattern basics, subsystem and component architecture patterns, concurrency patterns, memory patterns, and safety and reliability patterns. It emphasizes the importance of design patterns as reusable solutions to recurring problems and discusses optimization strategies in system architecture. The document also addresses redundancy patterns that enhance safety and reliability in high-assurance systems.

1. 1
Real Time Design Patterns
Oleh Medvedyev
Manager, Engineering
29 March 2017

2. 2
1. Design Pattern Basics
2. Subsystem and Component Architecture Patterns
3. Concurrency Patterns
4. Memory Patterns
5. Safety and Reliability Patterns
Agenda

3. 3
Lucius Annaeus Seneca
The way is long if one follows
precepts, but short... if one follows
patterns.

4. 4
Design Pattern Basics

5. 5
“Design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design.”
”Design pattern is a written document that describes a general
solution to a design problem that recurs repeatedly in many
projects.”
”Design pattern is a repeatable solution to a software
engineering problem.”
Patterns are not just software reuse but rather a kind of
concept reuse.
Design Pattern Basics

6. 6
• Design is always an optimization of an analysis model.
• Design patterns are always a general concept for how to
optimize an analysis model in a particular way with particular
effects.
• Optimization always entails improving some aspect of the
system at the expense of others.
• To be a pattern, the problem must recur often enough to be
usefully generalizable.
• The solution must also be general enough to be applied in a
wide set of application domains.
Design Pattern Basics

7. 7
Design Pattern Basics
Pattern Hatching Pattern
Mining

8. 8
UML Basics

9. 9
Subsystem and Component
Architecture Patterns

10. 10
• For many small- to
medium-scale systems, a
similar organization of the
logical architecture permits
developers to quickly and
easily understand the
organization of a new
system
• Simple organizational
pattern, allows portability of
the application to other
platforms and OS’s
Five-Layer Architecture Pattern
Collaboration Roles
• Application
• User Interface
• Communication
- Middleware
- Data transport
• Abstract OS
• Abstract Hardware

11. 11
• The basic concept of the
Recursive Containment
Pattern is that the way to
construct a very complex
system is to think of it as a
set of interrelated parts at a
number of levels of
successive detail,
something like a
microscope with multiple
levels of magnification.
Recursive Containment Pattern
Collaboration
Roles
Element - has two
basic features.
First, it provides a
set of services
through one or
more opaque
interfaces. Second,
internally, it
provides these
services largely by
delegation and
coordination of
smaller parts.

12. 12
• The Hierarchical Control
Pattern uses two types of
interfaces: control
interfaces that monitor and
control how the behaviors
are achieved and
functional interfaces,
which provide the services
controlled by the other set
of interfaces.
Hierarchical Control Pattern
Collaboration Roles
• Control Interface - provides
services to manage how the
functional services are performed—
for example, switching to a different
algorithm or providing a different
quality of service
• Controller - provides two kinds of
opaque interfaces to its clients:
control interface and functional
interfaces
• Functional Interface - provides the
normal semantic services of the
Controller.
• Leaf Element - class of any kind
other than a Controller

13. 13
Concurrency Patterns

14. 14
• The Message Queuing
Pattern uses asynchronous
communications,
implemented via queued
messages, to synchronize
and share information
among tasks.
• Any information shared
among threads is passed
by value to the separate
thread.
• Relatively heavyweight
approach
Message Queuing Pattern
Collaboration Roles
• Thread - it is the root of an operating system thread, task, or process. It can both
create messages to send to other Threads and receive and process messages
when it runs.
• Queue - container that can hold a number of messages.
• Mutex - provides protection from multiple access to the Queue contents

15. 15
• Sometimes asynchronous
communication schemes,
such as the Message
Queuing Pattern, do not
provide timely responses
across a thread boundary.
An alternative is to
synchronously invoke a
method of an object,
nominally running in
another thread. Care must
be taken to ensure data
integrity and to avoid
synchronization and
deadlock problems.
Guarded Call Pattern
Collaboration Roles
• Server Thread - share the Shared
Resource and protect them with the
Mutex.
• Client Thread – caller
• Boundary Object - provides the
protected interface to the Server
objects
• Mutex - permits only a single caller
through at a time
• Server - uses the Shared Resource
object, and second, it may provide a
service useable to a Client across the
thread boundary that may use the
Shared Resource
• Shared Resource - any object that
provides data or a service

16. 16
• As each thread becomes
ready to rendezvous, it
registers with the
Rendezvous class and then
blocks until the
Rendezvous class releases
it to run. Once the set of
preconditions is met, then
the registered tasks are
released to run using
whatever scheduling policy
is currently in force.
Rendezvous Pattern
Collaboration Roles
• Callback - holds the address of the
Client Thread.
• Client Threads – when they reach
their synchronization point, they
register with the Rendezvous object
and pass their callback
• Rendezvous - manages the Thread
Synchronization. It has a
register(callback:address) operation
that the Client Threads invoke to
indicate that they have reached their
synchronization point.
• Synch Policy - reifies the set of
preconditions into a single concept

17. 17
Memory Patterns

18. 18
• The application of this
pattern means that all
objects are allocated during
system initialization.
Provided that the memory
loading can be known at
design time and the worst-
case loading can be
allocated entirely in
memory, the system will
take a bit longer to initialize,
but it will operate well
during execution.
Static Allocation Pattern
Collaboration Roles
• Allocation Plan - identifies the
order in which the largest system
composite objects should be
allocated
• Composite Object – is responsible
for the creation of all objects that it
owns via composition
• Primitive Object - does not allocate
any other objects
• Part Object - superclass of
Composite Object and Primitive
Object
• System Object - structurally the
same as a Composite Object, except
that it may own an Allocation Plan
and creates and initializes the highest
level Composite Objects

19. 19
• In many applications clients
may need to create data
objects or message objects
as the system operates in a
complex, changing
environment. In this case, it
makes sense to have pools
of these objects—created
but not necessarily
initialized and available
upon request. Clients can
request them as necessary
and release them back to
the pool when they're done
with them.
Pool Allocation Pattern
Collaboration Roles
• Client - object that has a need to use
one or more objects of class
resourceClassClient
• Generic Pool Manager –
parameterized (template) class
specifies the class of the objects
pooled and the number of them to
create
• PooledClass - formal parameter to
the Generic Pool Manager. Most
often, they are simple, small classes
used by a variety of clients.
• Resource Pool Manager -
instantiated Generic Pool Manager, in
which a specific class
(ResourceClass) and a specific
number of objects (size) are passed
as actual parameters.

20. 20
• Some systems are complex
enough to require dynamic
random allocation of
memory but they cannot
tolerate one of the major
problems associated with
dynamic allocation:
fragmentation. For such
systems, the Fixed Sized
Buffer Pattern offers a
viable solution:
fragmentation-free dynamic
memory allocation at the
cost of some loss of
memory usage optimality.
Fixed Sized Buffer Pattern
• Object Factory - allocates an
appropriately sized block of memory
from one of the Sized Heaps and
maps the newly created object's data
members into it
• Sized Heap - manages the free and
allocated blocks from a single
Memory Segment
Collaboration Roles
• Client - the user of the objects
allocated from the fixed sized heaps
• Free Block List – list of the
unallocated blocks of memory within
a single Memory Segment
• Heap Manager - s manages the
sized heaps
• Memory Segment - a block of
memory divided into equal-sized
blocks, which may be allocated or
unallocated

21. 21
Safety and Reliability Patterns

22. 22
• Safety may be defined as freedom from accident or losses.
• Reliability refers to the probability that a system will continue to function for a
specified period of time.
• A safe system may fail frequently as long as it does not cause accidents, while the
reliability of a system does not refer at all to the consequences of failure if it should
occur.
• Both require redundancy of some kind in the design of systems.
• Faults come in two flavors: systematic and random.
• Failsafe state - condition of existence known to be safe
• Not all systems have a fail-safe state.
• Reliable systems rely on system self-tests, either on power up (called Power On Self
Test, or POST) or during execution (called Built In Test, or BIT)
Safety and Reliability

23. 23
Safety Versus Reliability

24. 24
• For high-safety and reliability systems, it is common to provide redundant channels to
enable the system to identify faults and to continue safe and reliable operation in the
presence of faults.
• Homogeneous Redundancy Pattern
• Triple Modular Redundancy Pattern
• Heterogeneous Redundancy Pattern
Redundancy Patterns

25. 25
Heterogeneous Redundancy Pattern
Collaboration Roles
• (Primary or Secondary)
Actuation Validation
• (Primary or Secondary)
Actuator
• (Primary or Secondary)
Data Transformation
• (Primary or Secondary)
Data Validation
• (Primary or Secondary)
Input Processing
• (Primary or Secondary)
Input Sensor
• (Primary or
Secondary) Output
Processing
• (Primary or
Secondary) Actuation
channel

26. 26
Monitor-Actuator Pattern
Collaboration Roles
• Actuation Channel
• Actuation Data Source
• Actuator
• Actuator Monitor Sensor
• Data Integrity Checks
• Data Transformation
• Monitor
• Monitoring Channel
• Monitoring Input Processing
• Output Processing
• Sensor Input Processing
• Set Point Source

27. 27
Sanity Check Pattern
Collaboration Roles
• Actuation Channel
• Actuation Data Source
• Actuator
• Actuator Monitor Sensor
• Data Integrity Checks
• Data Transformation
• Monitor
• Monitoring Input Channel
• Output Processing
• Sanity Check Channel
• Sensor Input Processing
• Set Point Source

28. 28
Watchdog Pattern
Collaboration Roles
• Actuation Channel
• Actuation Data Source
• Actuator
• Data Transformation
• Integrity Checks
• Output Processing
• Sensor Input Processing
• Timebase
• Watchdog

29. 29
Questions and Answers

30. 30
• Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. A System of Patterns:
Pattern Oriented Software Architecture, New York: Wiley and Sons, 1996.
• Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of
Reusable Object Oriented Software, Reading, MA: Addison-Wesley, 1995.
• Douglass, Bruce Powel. Real-Time Design Patterns: Robust Scalable Architecture for
Real-Time Systems, Addison-Wesley, 2002.
• Douglass, Bruce Powel. Real-Time UML, 2nd Edition: Developing Efficient Objects for
Embedded Systems, Boston, MA: Addison-Wesley, 2000.
• Douglass, Bruce Powel. Doing Hard Time: Developing Real-Time Systems with UML,
Objects, Frameworks and Patterns, Reading, MA: Addison-Wesley, 1999.
• Zalewski, Janusz. Real-Time Software Architecture and Design Patterns: Fundamental
Concepts and Their Consequences. Annual Reviews in Control, Vol. 25, No. 1, pp. 133–
146, July 2001.
• Vlissides, John. Pattern Hatching: Design Patterns Applied, Reading, MA: Addison-
Wesley, 1998
References

31. 31
Thank you
Oleh Medvedyev
Manager, Engineering
oleh.medvedyev@globallogic.com
+380322448347x3504