Home > Real-time Mantra > Design Patterns > Processor Architecture Patterns II
Processor Architecture Patterns II

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