Project Management for VXI Data Acquisition System

Ian Lazarus

26th Jan 1990 (first draft; comments please)

1 Introduction

The VXI integrated instrumentation proposal is an ambitious project which will push the limits of technology in several areas, particularly packing density and accuracy. There are many areas of difficulty both technical and logistic which will be encountered during the design and in order to overcome them we must control the project properly. This document is intended to identify areas where problems may be anticipated and suggests some methods to overcome them and increase the probability of producing a working system on a reasonable timescale.

2 Potential Problem Areas

There are many problems which will arise from a large project being conducted by a diverse group of engineers at different physical locations using a new bus system. The first seven problems relate to communication and the last group are the result of using VXI bus and state of the art technology.

1. Language The engineers involved at present are English, French and German. It is likely that communication problems will slow down discussion and that misunderstandings will occur in translation either of documents or speech.

2. Location We are in different locations, several hundred miles apart, in three different countries. It is not possible to have the normal informal discussions at lunchtime or coffee time which are normally helpful in avoiding misunderstandings and in solving problems.

3. Aim There is no written system specification as yet, and certainly not a specification which the users have seen and agreed. Until this document is written we will not know the targets at which we are aiming. This is true of the system as a whole and of individual modules. This definition is also required in order to ascertain when the project is complete. The alternative is an open ended project, subject to various upgrades and requiring an open ended budget and manpower allocation.

4. Standards of Practice It is not clear to me that we agree on what is an acceptable standard of engineering for the system and for the modules. I do not consider a quick connect or a wire wrapped board to be suitable for collecting experimental data other than as a prototype used in ‘standard’ experiments with well known results to prove that the basic design is correct. It is not clear that everyone involved will insist on properly produced pcbs (or perhaps multiwire boards). This relates to the Aims section: I don’t consider the project complete until we have a reliable, maintainable electronics system (which rules out wire wrap and quick connect!) which has been proven to meet its specifications to the satisfaction of the physicists.

5. Proper Specifications As mentioned above there is not a proper system specification to define the project. A system test requirements specification is also required to detail the minimum acceptable levels of observability and controllability in every module and a standard method of operation in terms of hardware and software. The detailed specifications for the various modules (Ge Card, BGO card, Readout card, Trigger cards, Event formatter card, resource manager software, slot 0 card) must contain at least as much information as the equivalent commercial system datasheet for the physicist, and additional information for the designer. In particular the internal functions, the software interface and the and the interfaces hardware must be properly specified. A detailed interface specification will contain an overview of what is passed through the interface as well as the following details of every signal:

• Signal type (TTL, 100K ECL, Fast NIM, Slow NIM, Futurebus, if analogue then voltage and current range, input/output impedance …)

• Signal active state (low active, high active, high to low transition, low to high transition, level or pulse, pulse duration)

• Signal meaning (trigger, data bit …)

• Signal timeout period if applicable

• Connector type and standard.

6. Adherance to Specifications There is no point in defining specifications if designers ignore them or unilaterally modify them. This will result in incompatiblity problems and delays while modifications are made. It is not sensible and certainly is very bad engineering practice to commence design without an agreed specification.

7. Documentation A project is not complete until it is documented. There are several reasons why this is the case, but the most obvious is maintenance. It is not possible to maintain a system without circuit diagrams, a circuit operation manual, test programs and the manufacturing information from which to build spare modules. This information is required at system level, at crate level, at board level and at component level for such things as ASICs and hybrids. Furthermore there must be a proper change control procedure which ensures that the modification level of the board can always be matched to a circuit diagram at the same revision level. The same is true of ASICs and hybrids.

8. VXI

(a) Multicrate Operation VXI has only a limited multicrate link (MXI) and does not specify ways to extend triggers between crates. We must therefore make our own standards for distribution of signals between crates (cable type, connector type, signal definition, signal timing specifications). Signals we must send between crates include the analogue multiplicity, trigger, validation, readout bus, various other control and logic signals.

(b) Specification VXI is a new standard and so subject to revision although the major manufacturers seem to have finished changing the specification now. The next changes will come when IEEE makes the VXI specification a standard.

(c) Experience None of the participators has any experience of VXI although some know VME. This puts us in a slightly better position than a totally new user, but it is likely that as the first group to apply VXI to nuclear physics instrumentation we will encounter VXI related problems.

(d) Accuracy and EMI VXI specifies the EMC characteristics of modules but we must better these for our low level pre-amp inputs to Ge cards. This is not a trivial task and requires shielding from magnetic fields. We will get 14 bits from the ADC, but we must ensure that all 14 contain data rather than noise.

(e) Power Supplies VXI uses switching power supplies which are too noisy for accurate analogue circuitry. Replacing these with linear power supplies (except ±5V) will cause space, weight and cost problems as well as making our crates nonstandard.

9. Use of hybrids and ASICs This makes us rely on subcontractors to conform to timescale and to produce hybrids and ASICs to the required specification. Normally this would not be too much of a problem, but this project will demand high density and will push processes to their limits resulting in reduced yield. We may also come across unforseen problems in ASIC design tools and in testing methods. (This is based on experience!)

3 Suggested Solutions

The language problem can be overcome to an extent by language tuition and by recognising the potential for misunderstandings. It will be very hard to eradicate it entirely.

The physical separation problem can be overcome by design review meetings (see section 4.2) which will also help to avoid incompatibility problems.

The specification and aims problem may be overcome simply by writing proper specifications before beginning the design phase. This will be a natural consequence of following good engineering practice.

VXI problems of multicrate operation can be overcome by well written specifications to which we all adhere. Linear power supplies and clean power supplies will require some thought and mechanical design to overcome the problems described. Accuracy is a related problem and can be achieved by clean power, proper grounding, sensible partitioning and good magnetic shielding. We must identify and use expertise in these specialities. The question of specification changes is out of our hands and could only be controlled by ‘freezing’ using one particular version such as the current rev 1.3.

Hybrids and ASICs are another area which will be largely outside our direct control in terms of production scheduling and delays. We can, however, be very careful in selection of suppliers and processes to ensure that designs of the same size and complexity as ours have been successfully executed several times before. This may incur cost penalties and require extra time to select suitable suppliers, but this should be regarded as a sort of insurance policy.

4 Design Practice

There are two ways to build electronics: the first iss to design it properly, preferably using CAE tools for simulation, and prove that it will work under all conditions. The other is to build prototypes using guesswork and intuition until a working circuit is found. The latter is not acceptable.

4.1 Design Tools

For a project of this size it is necessary to use CAE tools. These will enable us to simulate ASICs, Hybrids, sub-modules, boards and even groups of boards in a small system. When this simulation has been performed successfully we will know that our design is functionally correct and we can start to build it with a high degree of confidence that it will work. The simulation results can be converted to test patterns with which to begin commissioning the system components and for later use in maintenance. Without these tools we will spend a long time correcting design faults which could have been detected by simulation.

Good modern tools are required for pcb design too: IBM PC based systems are not capable of handling the size and complexity of design or the stringent noise reduction design rules. Suitable systems run on powerful workstations and are available from companies such as Mentor Graphics and Valid Systems (world leaders in sales of CAE because they have the best products).

4.2 Design Review Meetings

These will complement the CAE tools and are a more traditional approach to ensuring that a design is correct before building it. They are equally applicable to hardware and software, the software version often being called a ‘walkthrough’. They should be held at several points during a design and a design review meeting must be held before the design is frozen for production of the prototype board. At the meeting the designer will explain his circuit, preferably showing his successful simulation results. The other designers at the meeting will attempt to find any flaws in the design or anything which might lead to unreliability or which might make it difficult to maintain. If serious problems are unearthed then the design must be reworked. Otherwise it proceeds to production of a prototype.

4.3 Project Planning and Cost Control

Projects are allocated a certain amount of manpower and money based on estimates of what is required to complete the job. To make sensible estimates it necessary to break down the project into identifiable work items, to cost each item in terms of money, manpower and other resources (CAD, workshop assembly time, subcontractor …). When a project plan and resource details are produced we are in a position to make realistic estimates of timescale, cost and manpower required and if we don’t get all we need then we can adjust the plans accordingly, for example by lengthening the timescale where jobs must be done serially by one person instead of in parallel by two or three. Planning will also identify critical paths on which resources can be concentrated.

During the life of a project the plans provide a measure of our performance by setting milestones, such as design freeze dates, and comparing actual dates with target dates at each milestone. Milestones should be typically 4 weeks apart. This method identifies problem areas as they develop and alerts us to the need to maybe re-allocate manpower or money to overcome unforseen problems. Without project management tools this is virtually impossible.

Suitable packages exist for IBM PC (e.g. Superproject) and Macintoshes (e.g. MacProject). They are cheap and there is no excuse for not using them.

5 Summary

The only way to successfully build the VXI integrated instrumentation system is to engineer it professionally using proper design practice in a properly managed and controlled project. This has not yet begun and if the project is to succeed it must start now with a full set of specifications and a realistic, detailed project plan.