\documentstyle[11pt,a4wide]{article}
\title{Project Management for VXI Data Acquisition System}
\author{Ian Lazarus}
\date{26th Jan 1990 \em{(first draft; comments please)}}
\begin{document}
\maketitle
 
\section{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.
 
\section{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.
\begin{enumerate}
\item {\bf 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.
\item {\bf 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.
\item {\bf 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.
\item {\bf 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.
\item {\bf 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:
\begin{itemize}
\item Signal type (TTL, 100K ECL, Fast NIM, Slow
NIM, Futurebus, if analogue then voltage and current range, input/output
impedance \ldots) 
\item Signal active state (low active, high active, high to
low transition, low to high transition, level or pulse, pulse duration)
\item Signal meaning (trigger, data bit \ldots) 
\item Signal timeout period if applicable
\item Connector type and standard.
\end{itemize}
\item {\bf 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.
\item {\bf 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.
\item {\bf VXI} 
\begin{enumerate}
\item {\bf 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.
\item {\bf 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. 
\item {\bf 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.
\item {\bf 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.
\item {\bf Power Supplies} VXI uses switching power supplies which are too
noisy for accurate analogue circuitry.
 Replacing these with linear power supplies (except $\pm$5V) 
will cause space, weight and cost problems as well as making our crates
non-standard.
\end{enumerate}
\item {\bf 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!)
\end{enumerate}
 
\section{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.
 
\section{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.
 
\subsection{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).
 
\subsection{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.
 
\subsection{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 \ldots). 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.
 
\section{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. 
 
\end{document}