Processor Architecture Patterns
One of the most important steps in architecture
design is identifying processors/modules in the system and assigning
roles/requirements to them. This article focuses on this very subject. Here we
will explore different processor design patterns commonly seen in embedded and
distributed systems.
The following processor architecture patterns are seen in many embedded and
distributed systems:
The figure below shows the relationship between some of the processor
architecture patterns listed above. Note that the this list is by no means complete.
Embedded systems span a wide spectrum, so these patterns should be treated as
being representative only. In simple systems you might design the architecture
by assigning multiple processor architecture patterns to a single processor.
In most embedded and distributed systems the operator controls the complete
system from a console. When you are designing a distributed system the
operations and maintenance processor should provide a unified view about the
management of the system. The operator should be given a simple task based view
of the system.
Keep in mind that O&M capabilities of the system have a lot of impact on
the perceived quality of the system. The operators often judge the quality of
the system just from the ease-of-use of the user interface. A good user
interface lowers the cost of ownership for your customers and thus
increases the chance of getting more business.
Role
- Provides form based screens interface to the operator to control the
system.
- Provides statistics screens to ascertain the health of the system
- Provides interface to notify the operator of serious
problems that need operator intervention.
- Provide Periodic and on-demand reports about the health and performance of the
system
- Support configuring and dimensioning of the system.
Guidelines
- As mentioned earlier, user interface design should be task based. i.e.
make a list of tasks that the operator would perform with the system.
Provide direct screens to accomplish the tasks. The operator screens in the
system should be more like:
- Obtain system loading statistics
- Create a subscriber
- List major alarms
- List subscriber related critical alarms
- Add a new device
- Conduct usability studies with the world be operators. See if they feel
comfortable with the operator interface. For more information about
usability studies and task based user interface design refer to the
following external
link.
- Do not implement architecture based screens. Stick to task based screens.
The operator is just interested in getting the job done. He/she should not
be interested in how your architecture works. Your screens should not
read like:
- Obtain central manager statistics
- Obtain system status as seen by module manager
- Check device controller 0 alarms
- Generate alarms only for actions that need operator intervention. Do not
use alarms as a field level debugging tool. Thus suggestions like "Lets
add a critical alarm to see if the code is entering this error leg"
should be shot down and the designers should be asked to use alternative
debugging mechanisms.
- Minimize the number of configurable parameters. Restrict configurable
parameters to customers needs. Adding configurable parameter for system
tuning by engineers almost always turns out to be a bad idea.
- Architect your O&M processor as an HTTP server. This way the operators
would be able to use any client with a browser to access the user interface.
- Failure of the O&M processor should not have any impact on the systems
operation. The system should be able to go on for days without an O&M
processor.
Central Manager pattern should be used to define a central processor that
will manage the operations of the complete system. Central Manager maintains a
system level view of the system. Typically the Central Manager interacts with
Module Managers.
Role
- Maintains the health of the system by checking the sanity of the highest
level modules. Global fault handling is performed at this level.
- Allocates resources that are shared at a global level.
- Coordinates system start up and other activities that involve system wide
coordination
- Interfaces with the O&M processor for operator interface for system
wide commands/statistics.
- Manages the network with highest level module managers
Guidelines
- Only truly global activities should be assigned to the Central Manager. If
the Central Manager is involved in too many activities, it will soon become
a bottleneck in system performance.
- Care should be taken to reduce Central Manager involvement from complexity
point of view. If adequate attention is not given, you might end up with a
complex and difficult to debug Central Manager.
- Central Manager should coordinate activities between the highest level
Module Managers. This leads to a simpler system design as Module
Managers do not need to handle system level coordination.
- As far as possible, keep the Central Manager out of transaction level
processing. If this is not possible, minimize the role played by the Central
Manager in every transaction. For example, if your system is designed to
handle telephone calls, minimize the involvement of the Central Manager in
call processing.
- If a IP based architecture is used, the central manager and the highest
level module managers should communicate on a single IP network. Nodes
belonging to an individual module will not connect to this global
network.
- Failure of the Central Manager should have minimal impact on existing
transactions. Setup of new transactions may be impacted by the failure of
the Central Manager,
Module can be defined to be collection of processors that implement an
important part of the system's functionality. Module Manager is any processor in
the system that manages all other processors belonging to the module. This is a
hierarchical pattern. A Module Manager might further manage sub-modules. The
sub-modules further manage their own processors.
Role
- Handles commands and requests from the Central Manager (applicable to
highest level Module Managers)
- Handles commands and requests from a higher level Module Manager
(applicable to sub-module managers)
- Highest level Module Managers participate in the global network connecting
them with the Central Manager.
- Module level fault handling is carried out by the Module Manager.
Intra-module faults are not reported to the Central Manager.
- Manages the state and startup of Terminal Managers and other processors
within the module.
- Performs most of the transaction processing. For example, in a switching
system, most of the call processing will be handled by the Module Manager.
- Coordinates transaction processing actions within the module. For example,
when a call is setup by a Module Manager, it will coordinate the ringer set
up, tone generation etc. by talking to specialized processors within the
module.
- Module Manager controls the local intra-module network.
- Handles all O&M processor requests for operator initiated commands.
Guidelines
- The interface between the Central Manager and Module Manager should be
designed to be simple. All the interfacing complexity should be handled within
the Module Manager.
- Module Manager should coordinate most of the transaction processing.
Services of other processors in the module should be used as and when
required.
Terminal Manager is a hardware board that supports a number of
entities of the same type (terminals). For example, a digital trunk manager card
might manage several digital trunk circuits. The Terminal Manager card has a
single microprocessor that controls all the devices. Thus a Module Manager can
assign individual terminals. Most of the Module Manager software just deals with
individual terminals and is transparent to the the number of terminals per
Terminal Manager card. The fault handling software keeps track of the health of
the Terminal Manager cards. When a Terminal Manager fails, the fault handling
module informs rest of the software in terms of individual terminal failures.
Role
- Partitions hardware and software resources on the board into terminals.
- Handles terminal configuration and de-configuration requests from the controlling
Module Manager.
- Handles operator status change requests from the operator. (The Terminal
Manager does not directly interface with the O&M processor It receives
the requests from the controlling Module Manager).
- Monitors the status of individual devices implementing the terminals.
Terminal Manager also exchanges health messages with micro-controller and
DSP controlled terminals.
- Hides the rest of the system from specific hardware implementation of
terminals (e.g. the Terminal Manager might consist of say 8 DSPs
implementing four terminals per DSP. All other processors just see the card
as a collection of 32 terminals)
Guidelines
- Interface between Terminal Manager and other cards should be designed to
scale automatically with hardware changes. One simple way of achieving this
is to let the Terminal Manager report the type and count of terminals it can
support. Thus if a new board is designed, it can report a higher number of
terminals to the other boards. This way new versions of the hardware will
work with older software without any hitch.
- Terminal resource management should not be performed on the Terminal
Manager as this would break the abstraction provided to the controlling
Module Manager. Note that in any case the Module Manager would have to
select the Terminal Manager card for allocation. Thus spreading the terminal
allocation and deallocation logic at two places. In other words, keep the
Terminal Manager dumb.
- Terminal Manager interfaces should be designed to allow for operation of
different types of Terminal Manager cards to work in the same chassis. This
minimizes the impact on software of inevitable hardware upgrades to the
Terminal Manager.
- If terminals are implemented using micro-controllers/DSPs, the interface
between the main processor and terminal processors should be clearly
defined.
Device Controller is a processor which interacts with the lowest level of
hardware. A few examples of Device Controllers are:
- DSPs implementing terminals in a Terminal Manager
- A microprocessor controlling a transducer, heat sensor etc.
- Micro-controller operating a stepper motor
A Device Controller can interface with other processors with any of the
following interfaces:
- FIFO
- Dual Ported RAM
- Serial link
- Ethernet
- DMA Operations
Role
- Provides a message level device programming interface to higher layer
software
- Handles interrupts and device interactions, thus offloading the main
processor from device level processing
- Keeps other processors transparent to the actual device operation.
Guidelines
- Clearly define the message interface between the Device Controller and
other parts of the system
- Device Controllers are often implemented by lower end microprocessors.
Restrict the Device Controller to just handling the device.
- Keep the Device Controller dumb. It should need very little configuration
information. All decision making should be left to the other higher end
processors in the system.
|
