Observe and React
20.2.1 Observe and React
Monitoring systems are an important class of embedded real-time systems. A moni- toring system examines its environment through a set of sensors and, usually, dis- plays the state of the environment in some way. This could be on a built-in screen, on special-purpose instrument displays or on a remote display. If some exceptional event or sensor state is detected by the system, the monitoring system takes some action. Often, this involves raising an alarm to draw an operator’s attention to the event. Sometimes the system may initiate some other preventative action, such as shutting down the system to preserve it from damage.
The Observe and React pattern (Figure 20.6 and Figure 20.7) is a pattern that is commonly used in monitoring systems. The values of sensors are observed and when
20.2 ■ Architectural patterns 549
Values Display
Figure 20.7 Observe and React process
Other Equipment structure
Alarm
particular values are detected, the system reacts in some way. Monitoring systems may be composed of several instantiations of the Observe and React pattern, one for each type of sensor in the system. Depending on the system requirements, you may then optimize the design by combining processes (e.g., you may use a single display process to display the information from all of the different types of sensors).
As an example of the use of this pattern, consider the design of a burglar alarm system that might be installed in an office building:
A software system is to be implemented as part of a burglar alarm system for commercial buildings. This uses several different types of sensors. These include movement detectors in individual rooms, door sensors that detect cor- ridor doors opening, and window sensors on ground-floor windows that can detect when a window has been opened.
When a sensor detects the presence of an intruder, the system automatically calls the local police and, using a voice synthesizer, reports the location of the alarm. It switches on lights in the rooms around the active sensor and sets off an audible alarm. The sensor system is normally powered by mains power but is equipped with a battery backup. Power loss is detected using a separate power circuit monitor that monitors the mains voltage. If a voltage drop is detected, the system assumes that intruders have interrupted the power supply so an alarm is raised.
A possible process architecture for the alarm system is shown in Figure 20.8. In this diagram, the arrows represent signals sent from one process to another. This system is
a ‘soft’ real-time system that does not have stringent timing requirements. The sensors do not need to detect high-speed events, so they need only be polled relatively infre- quently. The timing requirements for this system are covered in Section 20.3.
I have already introduced the stimuli and responses in this alarm system in Figure 20.1. These are used as a starting point for the system design. The Observe
550 Chapter 20 ■ Embedded software
Door Sensor
Control Panel
Process
Process
Testing Process
Movement Detector Process
System
Console Display
Controller
Process
Voltage Monitor Process
Power Management
Window Sensor
Process
Process
Figure 20.8 Process
External Alert structure for a burglar
Audible Alarm
Lighting Control
Process alarm system
Process
Process
and React pattern is used in this design. There are observer processes associated with each type of sensor and reactor processes for each type of reaction. There is a single analysis process that checks the data from all of the sensors. The display processes in the pattern are combined into a single display process.
Parts
» Software Engineering Ian Sommerville(www.ebook dl.com)
» An insulin pump control system
» A patient information system for mental health care
» A wilderness weather station
» ■ Agile software development 57
» Plan-driven and agile development
» ■ Requirements engineering 83
» The software requirements document
» Requirements engineering processes
» Architectural design decisions
» System context and interactions
» Preventative maintenance by refactoring
» ■ Sociotechnical systems 265
» Verification and formal methods
» Safety and dependability cases
» Components and component models
» Two-tier client–server architectures
» Multi-tier client–server architectures
» Distributed component architectures
» ■ Service-oriented architecture 509
» ■ Service-oriented architecture 511
» ■ Service-oriented architecture 513
» Services as reusable components
» Service candidate identification
» Service implementation and deployment
» Workflow design and implementation
» Project duration and staffing
» The process improvement process
» The CMMI process improvement framework
Show more