INTERFACE CONTROL
Interface Control Document (ICD)
During the design phases of the program the ICD is a 'living' document; It must be actively maintained and controlled. The tool used for defining the interfaces is the ICD Matrix on this HTML page with hyperlinks to MS word documents that specify each bilateral interface agreement.
General Comments about Interfaces & Interface Control (master ICD
document):
ICD introduction, guidance and generalities
(E030647-01)
ICD SECTIONS
click on hyperlinked symbol in Matrix for MS Word file
|
? Perhaps Interfaces Here |
|
|
|
# Draft Revision # Completed |
|
|
A Completed (Lettered revision means approved & released into configuration control) |
Partially Completed
Empty (to be written)
Outlined
|
WBS |
|
1 |
2 |
3A |
3B |
4 |
5 |
6 |
7 |
8 |
9 |
12 |
13 |
14.5 |
|
|
SubSys |
FAC |
SEI |
SUS/ |
SUS/ |
PSL |
IO |
COC |
AOS |
ISC |
DAQ |
LDAS |
INS |
SYS |
|
1 |
FAC |
|
|
? |
? |
|
|
|
|
|
|
|
|
|
|
2 |
SEI |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3A |
SUS/UK |
|
|
|
|
|
|
|
|
|
||||
|
3B |
SUS/US |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4 |
PSL |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5 |
IO |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6 |
COC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7 |
AOS |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
8 |
ISC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9 |
DAQ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
12 |
LDAS |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
13 |
INS |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
14.5 |
SYS |
|
|
|
|
|
|
|
|
|
|
|
|
|
Interface Control in Advanced LIGO
Interfaces in Advanced LIGO are defined, negotiated, documented and controlled by an Interface Control Working Group(s). The interface definition is captured in an Interface Control Document (ICD) as a pair-wise set of interfaces between the advanced LIGO susbsystem, as indicated in this matrix, where the shaded green boxes indicate the ICDs associated with the SUS/UK effort:
Interface Control Working Group (ICWG)
The responsibility of the ICD is in the hands of the Interface Control Working Group (ICWG) for the interface. By default the members of the ICWG are the lead engineer and cognizant scientist for each subsystem (as listed here). The subsystem leader can designate another individual if appropriate. The systems group arbitrates disputes in the interface. The Configuration Control Board (CCB) ultimately mediates the consequences, of any changes in the interface. The systems engineer chairs the ICWG.
A single individual is the responsible editor/author for each ICD. This
person enlists the help of key technical staff from the subsystems to define
the requirements and later to monitor the design against the interface
requirements and arbitrate change requests at the interface. Currently this
person is the systems engineer (though volunteers from the subsystems are
requested!)
Interface Working Notes
The following are some working notes on interfaces that have not yet been resolved:
SUS Quad Interfaces: meeting held 2 Dec 2004, some general notes on significant and unresolved SUS quad interfaces:
T050005-01, revised after the meeting (changes indicated)
STATUS & NEXT STEPS (15
Jun 2005)
Records of Decision or Agreement (RODA)
Many of the AL RODAs involve interface agreements made prior to formal ICDs
are established. See the RODA
Status Web Page for the latest.
Configuration Control
The ICD will be in considerable flux during the design and development of
the subsystems (especially the early phases of design). In addition the
disparate subsystem development schedules lead to varying levels of maturity in
the definition of the ICD sections. For these reasons the entire ICD (i.e. the
collection of all of the bilateral ICDs at the subsystem level) will not be
placed into configuration control. Each of the individual ICDs will be
configuration controlled. The configuration control procedure is as described
in E030350-A.
The Document Change Notice (DCN) which releases the ICD must be signed by at
least one representative of each subsystem and the systems engineer. The entire
ICD will also be occasionally issued and archived. The individual bilateral
ICDs will be included as chapters (using the master document feature in MS
Word) with their separate LIGO assigned document number and revision indicated;
The overall ICD will always have a numbered revision (i.e. not under
configuration control).
Interface control in Initial LIGO
For reference, in initial LIGO at the overall system level, there were pair-wise Interface Control Documents (ICD) between the major LIGO elements/contracts (Vacuum Equipment, Civil Construction, Beam Tubes and Detector):
- E950092-00-E Interface Control Document (ICD): Beam Tube (BT) - Vacuum Equipment (VE)
- E950091-00-E Interface Control Document (ICD): LIGO System & Detector (Det) - Vacuum Equipment (VE)
- E950090-00-E Interface Control Document ICD): LIGO System & Detector (DET) - Civil Construction (CC)
- E950089-01-E Interface Control Document (ICD): Beam Tube (BT) - Civil Construction (CC), Final Draft
- E950088-03-E Interface Control Document (ICD): Vacuum Equipment (VE) - Civil Construction (CC)
(at this time none are available electronically; only paper copies)
In the Detector system, interface control was handled differently and rather non-uniformly. There were some "Naming Convention and Interface Definition" documents, but they tended to identify the interfaces to be defined and did not give the details (i.e. often incomplete, but raised awareness on both sides of the interface). Examples include:
- Naming Convention and Interface Definition for ASC/Wavefront Centering: T950069-00
- Comparable document for SUS, Naming Convention and Interface Definition for SUS, T950060-03, (not available electronically)
- Pre-Stabilized Laser (PSL) to Control and Data Systems (CDS) Interface Control Document (ICD), T950045-C (not available electronically)
In practice the interface definitions were handled by the fact that there was one group (well two groups, MIT & CIT, but they worked very closely together) and the interface requirements were typically captured in the requirements documents for the subsystems, e.g. see for example the sections labeled "assumptions" in any initial LIGO subsystem requirements document, such as section 3.1 of the Suspension Design Requirements: T950011-19.pdf
The systems engineering approach for initial LIGO worked reasonably well since it was all managed by a relatively few people and the work was all accomplished within the LIGO Lab. A more rigorous approach is needed to manage the systems engineering effort for advanced LIGO due to the increased technical and managerial/organizational complexity.