First, an explanation of a couple of terms:

What do we mean by the panel logic software?
A communication panel's operational state is determined by its present switch or control settings combined with, in many cases, its previous state. For example, The SHINCOM terminal uses a specific key sequence to place a point-to-point call (i.e. the keys: call, 1, 2, 3), where the current interpretation of the numeral 1, is determined by the preceding call key. Thus, a state machine is required to correctly interpret each key sequence in a manner which produces the same end-result, or state, as produced by the actual equipment.

What do we mean by the "superstate" connectivity logic software?
When an operator tries to establish a connection to another device, his ability to establish the connection, and the ensuing sequence of events, is a function of conditions outside of the local panel environment. The control of these sequences must be handled by a set of software that sits on top of the system and is aware of every panel's status.

The decision to centralize state machine software in a "Model Server" led to two other decisions; the development of the PIU, and the development of the cell-based communication protocol. Therefore, this decision itself merits some discussion.

The decision to centralize the panel logic software is discussed in more detail in Appendix B. However, in summary:

• Hosting the logic in each panel would have created problems with software configuration management and made the software revision level an intrinsic part of the LRU part number.
  
  
• It would have created a more expensive, or a more hostile, processing platform for the state machines.
  
  
• It would have made final system test of the panels dependent upon the software.
  
  
• For the SHINCOM it was necessary to hold system connectivity control in a "superstate" machine. This clearly could not be hosted in a local panel.

Once we had made the decision to centralize processing, we then undertook the task of choosing an operating system whose requirements of true multi-tasking, stability, and low processor overhead were critical. Windows NT might seem an obvious choice, but was quickly eliminated due to perceived instability and the high OS overhead; additionally, its cost (and the cost of its development tools) was rather unattractive. After some additional research, Linux was chosen since it offered multi-tasking, stability, low processor overhead, low cost, and the ultimate in maintainability since its source code is open.

Next page: Hardware Design