To: file

From: Jon Hagen

Date: Oct. 23, 2003, Nov. 21, 2003

Subject: Pointing System Control Computer

The present pointing system (azimuth, dome, and carriage house) was designed, built, and installed by Vertex, GMBH. The system works well, but we have two concerns:

First Concern: the Siemens S5 series controller components (CPU modules, I/O modules, and crate) are obsolete. So far, only one component, the CP581 CPU module, has been unreliable. But three of these units have failed and they are not repairable. We have two spares on hand, but Siemens says there are no more available.

Second Concern: We are only marginally able to deal with the Vertex software. The slightest modification (changing a limit value, etc) is difficult. Troubleshooting the system is extremely difficult. The code is written in a 'PLC' language which seems more primitive than even the earliest assembly languages. Vertex furnished almost no documentation for the code. The code itself is hardly 'self documenting'; the hundreds of pages of listing contain few comments and variables are seldom named.. Instead, they are referenced by absolute addresses. Vertex produced this software by modifying code written for another customer. They could have written all-new code in a style specified or, at least, approved or by us, but at a higher cost.

An in-house effort to replace this control system would, in my opinion, be expensive in terms of our manpower resources (though, in any event, we must specify the hardware and software architectures and monitor the detailed system design). Vertex, however, with its intimate knowledge of the present system, might be able to furnish a replacement at a much lower cost. We could approach Vertex (and other outside system houses) for price quotations. I list below the design features I/O think should be included in any RFP:

1. All programming should be done in a widely-known high-level language, e.g. "C".

Programming style conventions should be specified in the contract. The ergonomics, i.e. operation and maintenance screen designs should be specified by us.

2. The system should come with high-level documentation - not just "self documentation" through comments in the code. This high-level documentation should consist of appropriate diagrams and text.

3. An Arecibo engineer should be assigned to monitor the contract - keeping up to date on the system design and the documentation. This engineer would also be in charge of acceptance testing and would make sure that everything is received, including all necessary vendor documentation, licenses, etc.

4. The program should not reside in EPROMs. EPROMs are probably a bad idea in any system that is subject to change. They are appealing in that they can't lose the program. But changing them always seems to requires a separate programming set-up: a prom burner, cables, floppies containing the drivers for the burner, a PC, floppies containing the software development system, personal and corporate memory of how to use all this and how to keep track of the separate components. We attempted to maintain an programming facility for the pre-Vertex 8080-based pointing system but failed; when the program finally needed changing, it was done in the most primitive way, using the binary listings and a stand-alone PROM burner. The system should be and remain always fully integrated

5. The system design should include ample provision for self test and diagnostics. The operator should be able to specify a number of program variables for on-screen monitoring while the program is running. These variables would be sampled either periodically (e.g. every second), or at selected points in the program.

6. The contract should include spare hardware modules. When these are purchased later, they are invariably newer (different) versions which require program modifications or changes in operational and test procedures.

7. Acceptance tests should include demonstrations that the system comes up and runs correctly with any mixture of primary and spare boards.

8. The system should contain its own development system, i.e. it should be possible to program and reprogram the system from its own operating console or terminal. That terminal should be as generic as possible - a 'plain vanilla' PC. If a remote processor or processors are required, they should all be accessible (controllable, loadable, readable) from the central terminal. Parameters such as limits, etc. should be stored in an easily edited parameter file rather than in the body of the program. When started, the program would read these values. It should be possible to tune parameters such as loop coefficients while the program is running, stepping the values up or down. (The adjusted values would not be written automatically into the configuration file. One display screen could show the working parameters. The configuration file would be manually edited to reflect any desired changes).

9. The system should be designed for the fastest possible installation, i.e. the telescope down time should be minimized. To that end, the servo control loop designs should, at least initially, be identical to the those in the present system.

Desirable hardware features:

The present system uses Siemens I/O modules that reside in the Siemens S5 crate and can communicate only with that crate's proprietary back plane. A better system would use I/O modules that communicate via a fast generic serial bus, e.g. Ethernet. Each module would have an associated software driver. When a module becomes obsolete or unsatisfactory, its replacement could be simply plugged onto the bus. Only its driver would need modification or replacement. We would not be limited only to the set of modules available for a particular instrumentation crate or computer bus.

Using I/O modules on an Ethernet bus ('open environment') would allow us to choose virtually any control computer. The obvious choice is a generic high-performance PC. A single-CPU system is preferable. The present dual-CPU system presents various start-up problems; the two CPUs must be synchronized. Timing loops that facilitate the synchronization were designed for the original hardware, and became a problem when failed CPUs were replaced by newer, faster versions. (Of course, any or all of the individual I/O modules could (and probably would) contain 'transparent' embedded microprocessors).