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.

Processor architecture design pattern relationships

Operations and Maintenance (O&M) 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.


  • 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.


  • 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:
    1. Obtain system loading statistics
    2. Create a subscriber
    3. List major alarms
    4. List subscriber related critical alarms
    5. 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:
    1. Obtain central manager statistics
    2. Obtain system status as seen by module manager
    3. 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

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.


  • 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


  • 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 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.


  • 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.


  • 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

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.


  • 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)


  • 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

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


  • 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. 


  • 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.