[alma_na] ALMA System Block Diagram Procedures

[Larry D'Addario]

To the ALMA technical staff,

You'll recall that Rev F of the System Block Diagram, document
80.04.01.00-004, was released on March 21 (see my email of that
date).  Since then, Jeff Zivick and I have received many comments and
proposals for corrections.  We appreciate these, and the next revision
(now in preparation) will incorporate many of them.

In this process, it has become apparent that maintaining the block
diagram as an accurate representation of the ALMA telescope design is
a complicated task.  It is also apparent that many people would like
to rely on it as a primary reference document.  Errors, omissions, or
ambiguities may then cause confusion or worse.  Therefore, I want to
attempt here to clarify what the block diagram does and does not
contain.

Earlier versions of this document (through Rev E) were intended to
show only the "system level" design.  As such, it was considered a
*controlling* document, like a specification, from which deviations
were not permitted without suitable review.  In response to requests
that more detail be included, the SE IPT decided that the block
diagram should be a *reporting* document, so that current and future
versions should attempt to show things below system level that are
under the control of various IPTs other than SE; the diagram is then
reporting the design information provided by the responsible IPT.  It
should be obvious that not every detail can be shown, so we use our
best judgment in deciding what to include, based on the principle that
it should be enough to provide a clear understanding of how the
telescope works.

The following statement is intended to make this more precise.  A copy
can be found on ALMAEDM as document 80.04.01.00-006.


SYSTEM BLOCK DIAGRAM -- DEFINITIONS AND PROCEDURES

The ALMA System Block Diagram document contains two main kinds of
information:

1.  system level design information, including but not limited to the
    configuration of the main signal path, the assignment of functions
    to major subsystems, interconnections among major subsystems,
    locations of major assemblies, and some (but not all) parameters
    like frequencies, bandwidths, and signal levels; and

2.  subsystem design information, sufficient to provide a clear
    understanding of the telescope's functioning, including some
    subsystem design parameters.

Information in category 1 is determined by the Systems Engineering IPT
and is controlling of the ALMA design.  Information in category 2 is
based on documented design decisions of other IPTs.

To be considered a "documented design decision" the information must
be in an engineering drawing, specification, or other design document
that is

(a) accessible to all ALMA staff members (preferably on ALMAEDM), and

(b) capable of being referenced in a concise manner (preferably by
ALMA document number) and easily located from that reference.  

It is explicitly *not* required that such documents have project-level
approval, nor have passed any formal review, nor be in any pre-defined
format.  (However, some documents are not acceptable for this purpose,
including for example: slides shown at meetings; minutes of meetings;
email correspondence; notes on verbal communications; proposals,
discussion documents, and anything that is speculative or tentative on
its face; and ALMA Memos, except when included by reference in an
engineering document).

To have design decisions reported on the block diagram, the
responsible engineer should provide the appropriate reference to the
SE IPT.  While the block diagram will not normally show these
references, the authors of the block diagram should be able to provide
them upon request.

In practice, many design decisions in ALMA are not yet adequately
documented.  Others are uncertain, subject to change, or in flux.
Some design issues are simply undecided.  In a few cases, engineering
documents provide conflicting information or are known to be obsolete.
Until these matters are resolved, it is necessary for the block
diagram to contain a third kind of information:

3.  tentative design information, usually at the subsystem level or
    device level.

Where documented design decisions are not available, the authors of
the block diagram, on behalf of the SE IPT, will show what they
consider to be the most likely or most reasonable design.  Such
information will be updated only when the corresponding design is
documented.

The block diagram will attempt to show, by footnotes, when information
is tentative.  But to avoid clutter and because information is often
of mixed type, it cannot be guaranteed that all appropriate items will
be so marked.

It is a goal of the SE IPT that new documented design decisions will
be reflected in the system block diagram within 30 days after the
appropriate references are provided, but it cannot be guaranteed that
this goal will always be met.