Processor Architecture Patterns II

We have already seen processorarchitecture patterns that are helpful in architecturedesign. In this article we will compare the requirements for different typesof processors that are used in developing a system.

Comparison Matrix

Different Processor Patterns are compared for different attributes in thefollowing matrix:

Complexity depends upon the following factors:

• Overall system complexity
• Total number of processors that need to be maintained
• Skill level of operators using the O&M Processor

Complexity depends upon the following factors:

• Total number and type of Module Managers controlled
• Degree of involvement in every transaction
• Redundancy and Availability Requirements
• Global resources that need to be managed

Complexity depends upon the following factors:

• Total number and type of nested Module Managers controlled
• Total number and type of Terminal Managers controlled
• Module resources that need to be managed
• Redundancy and Availability Requirements

Complexity depends upon the following factors:

• Number and type of Terminals managed
• Number of terminals that share the same hardware
• Degree of transparency needed from future hardware changes
• Impact of Terminal Manager cost on the cost of the complete system

Complexity depends upon the following factors:

• Programming model of the hardware device
• Degree of transparency needed from future hardware changes
• Impact of Device Controller cost on the cost of the complete system

Use of HTTP, Java and SNMP increases the performance requirements for a O&M Processor.

A high performance platform should be used as the Central Manager so that its performance doesn't become a bottleneck when the system is expanded.

In most cases the top level Module Managers will handle most of the transaction processing load on the system. A high performance platform should be used. 

Overall performance requirements for the Terminal Manager might not be very high. However, the Terminal Manager might be executing a lot of time critical code, thus needing a reasonably good performance platform.

Device controller performance requirement varies a lot from one device to another. For example, a controller involved in digital signal processing might need a very high MIPS CPU. A device handling protocols might work well with a medium performance CPU. Most devices however would work very well even with low performance CPUs. 

Failure of the O&M processor has no impact on system performance. A replacement can be brought in service manually. (This assumes that both O&M processors communicate to an off-the-shelf database server machine.)

Central Manager's failure can result in the complete system going out of control. Thus a hot standby should be maintained for quick recovery from the fault condition.

e.g. CAS card in Xenon Switching System.

All transactions handled by a failed Module Manager will be released abnormally by the Central Manager. Central Manager would then configure a spare Module Manager to replace the failed module. 

e.g. XEN card in Xenon Switching System.

All transactions handled by a failed Terminal Manager will be released abnormally by the controlling Module Manager. Controlling Module Manager would then configure a spare Terminal Manager to replace the failed board.

e.g. Digital trunk card in Xenon Switching System.

Device controllers are not redundant within a Terminal Manager.

Only two machines are required for the O&M Processor. The cost of these machines is not a significant portion of the overall hardware cost.

Only two machines are required for the Central Manager. The cost of these machines is not a significant portion of the overall hardware cost.

Typically a system will need many Module Managers. Their aggregate cost may be a significant portion of the system cost.

A large number of Terminal Managers might be needed. Aggregate cost of Terminal Managers may be a large percentage of the total system cost. This might mean that the software developers have to optimize their code to work within the cost limitations.

A very large number of Device Controllers might be needed. Aggregate cost of Device Controllers may be a very large percentage of the total system cost. This might mean that the software developers have to optimize their code to work within the cost limitations.

• Unix Servers and Work Stations
• Linux PC Servers
• Windows PC Server

• Unix Servers and Work Stations
• Linux PC Servers
• Windows PC Server

• Unix Servers and Work Stations
• Linux PC Servers
• Windows PC Server

If the Module Manager performs time critical operations, use PCs running:

• VxWorks
• P-SOS
• RT-Linux
• etc.

• VxWorks
• P-SOS
• RT-Linux
• etc.

O&M Processor completely handles the operator interface.

Central Manager has a large operator interface component.  It supports system wide statistics, status and alarm reporting.

Module Manager has a considerable operator interface component.  It supports module wide statistics, status and alarm reporting.

Terminal Manager does not have a direct operator interface. It reports statistics and alarm conditions to the Module Manager. Module Manager would then directly interact with the O&M processor.

Device Controller might report error conditions which result in alarms being generated. It might report some statistics to the Terminal Manager.

• Graphical user interfaces
• Relational databases
• SNMP
• HTTP/HTML
• Java

• State machine design
• Message interaction design
• System level design experience
• Object oriented design
• C/C++

• State machine design
• Message interaction design
• Real-time software development
• Object oriented design
• C/C++

• Real-time software development
• State machine design
• C/C++
• Software and hardware interfacing

• Device programming
• Hardware interfacing and hardware design knowledge
• C/C++
• Assembly programming
• Signal processing knowledge
• DSP programming

• O&M Processor
• Xenon Operator Interface
• Hardware Fault Tolerance
• Handling Processor Reboot

• Central Manager
• Resource Allocation Patterns
• Resource Manager Pattern
• Feature Coordination Patterns
• Hierarchical State Machine
• State Machine Inheritance
• Publish-Subscribe Design Patterns
• Timer Management Design Patterns
• STL Design Patterns
• STL Design Patterns II
• Software Fault Tolerance
• Handling Processor Reboot
• Hardware Fault Tolerance
• Reliability and Availability Basics
• System Reliability and Availability
• Congestion Control

• Module Manager
• Hierarchical State Machine
• State Machine Inheritance
• Half Call Design Pattern
• Collector State Pattern
• Parallel Wait State Pattern
• Serial Wait State Pattern
• Resource Allocation Patterns
• Resource Manager Pattern
• Feature Coordination Patterns
• Timer Management Design Patterns
• Publish-Subscribe Design Patterns
• STL Design Patterns
• STL Design Patterns II
• Software Fault Tolerance
• Handling Processor Reboot
• Hardware Fault Tolerance
• Fault Handling Techniques
• Congestion Control

• Terminal Manager
• Manager Design Pattern
• Transmit Protocol Handler Design Pattern
• Receive Protocol Handler Design Pattern
• DMA and Interrupt Handling
• Processor Bus Cycles

• Device Controller
• Hardware Device Design Pattern
• Serial Port Design Pattern
• High Speed Serial Port
• Hardware Diagnostics
• DMA and Interrupt Handling
• Processor Bus Cycles