Download Change Record

Large Synoptic Survey Telescope (LSST)
Interface Control Process
Brian Selvy
LSE-151
Latest Revision Date: 03/15/2013
.
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Change Record
Version
Date
0.1
01/02/13
0.2
02/15/13
0.3
03/07/13
0.4
03/14/13
0.5
03/15/13
Description
Initial writing.
Owner name
Brian Selvy
Updated to address comments from Jan. 17-18,
2013 face-to-face meeting.
Made the following changes based on feedback
received prior to the CCB meeting:
Section 1.4: Refined this section into two
subsections so as to categorize LSST and
external reference documents. Added LSE-161
as an LSST reference document.
Section 2.4.2: Added “Logical” and
“Deliverable” as two additional interface
classifications. Added definitions for each.
Section 3.2.1: Moved the tables of ISDs to a
new document (LSE-161) that is not under
change control. This is because this list may
change more frequently.
During the 3/13/13 Change Control Board
(CCB), it was decided to remove Section 4 of
this document and move it to the Verification
and Validation Process Document (LSE-160).
The following changes have been made to this
version:
Title: Changed to “Interface Control Process”
to reflect that compliance is being moved to
LSE-160
Section 2.3.1.2: Updated Figure 2-1 to include
EPO on the schematic
Section 4 (Interface Compliance Documents):
Removed from this document and transferred
to LSE-160.
One additional needed change was captured in
the meeting minutes from the 3/13/13 CCB.
Section 2.3.1.1: Added LSE-72 in a new row to
Table 2-1.
i
Brian Selvy
Brian Selvy
Brian Selvy
Brian Selvy
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Table of Contents
1 Contents
Change Record ............................................................................................................................................... i
2
1.1
Summary ...................................................................................................................................... iii
1.2
Acronyms ..................................................................................................................................... iii
1.3
Definitions of Terms ..................................................................................................................... iii
1.4
Reference Documents.................................................................................................................. iv
1.4.1
LSST Reference Documents ................................................................................................. iv
1.4.2
External Reference Documents ........................................................................................... iv
Interface Control Documents................................................................................................................ 1
2.1
Purpose ......................................................................................................................................... 1
2.2
Development Phases .................................................................................................................... 1
2.3
Responsibility ................................................................................................................................ 1
2.3.1
System-Level and Cross Subsystem Interfaces ..................................................................... 1
2.3.2
Sub-sub-System Interfaces.................................................................................................... 3
2.4
3
Content ......................................................................................................................................... 3
2.4.1
Introduction and Overview ................................................................................................... 3
2.4.2
Interface Classifications ........................................................................................................ 4
2.4.3
Requirement Structure ......................................................................................................... 5
2.4.4
Verification Planning ............................................................................................................. 6
Interface Support Documents ............................................................................................................... 7
3.1
Purpose ......................................................................................................................................... 7
3.2
Responsibility ................................................................................................................................ 7
3.2.1
3.3
List of Interface Support Documents .................................................................................... 7
Content ......................................................................................................................................... 7
ii
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Interface Control and Interface Compliance
Management Process
1.1 Summary
The purpose of this document is to provide a project-wide process for Interface Control and Interface
Compliance management.
1.2 Acronyms
CH – Connection Hardware
DM – Data Management
EPO - Education and Public Outreach
FDR – Final Design Review
ICD – Interface Control Document
ICoD – Interface Compliance Document
ID – Identification
ISD – Interface Support Document
OCS – Observatory Control System
SEMP – Systems Engineering Management Plan
T&S – Telescope and Site
1.3 Definitions of Terms
Interface – A boundary between two or more subsystems, subsystem elements, or between the system
and the external environment.
Project Controlled Interface – An interface between two or more subsystems or system to external
environment where the ownership authority on either side of the interface is a different entity, team, or
organization. These boundaries can be a result of project organizational structures where sub-teams
have been given design authority for various subsystems and/or components of the overall system,
creating interfaces that need to be rigorously controlled as a result of the needed interactions between
the subsystems.
Interface Control Document – A document that defines all of the requirements needed to properly
define both sides of a shared interface. This defines the “what” of the interface.
Interface Compliance Document – A document that shows the design solution which meets the
requirements defined in the ICD. This defines the “how” of the interface and is used during the design
phase to show the design is compliant with the requirements prior to actual hardware/software
integration. This document is used to ensure the “as designed” system has a high probability of meeting
all interface requirements during the integration and verification phase.
Interface Support Document – A document that supports the understanding of interfaces via common
dictionaries, protocols, system-wide architectural frameworks, etc. These documents may have input
from more than one sub-system team or organization, but they do not include requirements. These
documents are used by the overall project.
iii
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
1.4 Reference Documents
1.4.1 LSST Reference Documents
LSE-161 Interface Support Document List
1.4.2 External Reference Documents
Haskins, Cecilia (ed.), Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities. INCOSE-TP-2003-002-03.2. January, 2010.
Weilkiens, Tim. Systems Engineering with SysML/UML. Amsterdam: Morgan Kaufmann OMG Press,
2006.
iv
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Interface Control and Interface Compliance
Management Process
2 Interface Control Documents
2.1 Purpose
The purpose of the Interface Control Documents (ICDs) is to define all of the requirements of a given
interface that are needed to complete the design of the subsystems or components on either side of the
interface.
2.2 Development Phases
Interfaces will follow three phases of development according to the relative importance in driving the
design at that particular phase. The three phases are defined as follows:
Phase 1:




Identification of the interface and definition of scope, design impact, and not to exceed costs;
Definition of boundaries, connectivity, and design envelopes;
Listing deliverables for interface hardware and software elements;
Assignment of responsibility and ownership for the interface scope to support the not-to-exceed
costs;
Phase 2:




Refinement of the interface as it drives, or is driven by, subsystem design maturation;
Refinement of the interface boundaries as dictated by the design state;
Definition of all loads, physical flows, and logical/data flows across the interface boundary;
Specification of functional requirements of the interface including data structures, operations,
and communication protocols;
Phase 3:



Completion of all interface specifications;
Detailing all information needed to finalize subsystem designs;
Specification of component-level interface details – such as cable connector pin-out or API
signatures.
2.3 Responsibility
2.3.1 System-Level and Cross Subsystem Interfaces
The Project Systems Engineering office is responsible for cross subsystem (e.g., when two or more
subsystem teams are involved with interfacing hardware/software) and system-to-external environment
interface control.
1
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
2.3.1.1 List of Project Systems Engineering-Controlled ICDs
Table 2-1 lists the ICDs that are controlled by the Project Systems Engineering Office. The table also
shows which subsystems are impacted by the document. Note that the one document categorized as
“hybrid” currently has design details (ISD content) and requirements (ICD content).
Table 2-1: List of ICDs Controlled by Project Systems Engineering Office
Doc.
No.
LSE78
LSE69
LSE68
LSE75
LSE76
LSE77
LSE131
LSE64
LSE65
LSE80
LSE66
LSE67
LSE71
LSE72
LSE73
LSE132
LSE139
LSE140
Title
Type
T&S
DM
Camera
LSST Observatory Network Design
Interface between the Camera and Data
Management
Data Acquisition Interface between Data
Management and Camera
Control System Interfaces between the Telescope
and Data Management
Infrastructure Interfaces between Summit Facility
and Data Management
Infrastructure Interfaces between Base Facility
and Data Management
Data Management Interface Requirements to
Support Education and Public Outreach
Utilities & Services Interface between the Camera
and the Telescope
Summit Facility Interface between the Camera
and Telescope
Mechanical, Thermal, and Access Interfaces
between the Camera and Telescope
Guider Interface between the Camera and
Telescope
Wavefront Sensor Interface between the Camera
and Telescope
Hybrid
X
X
X
ICD
X
X
ICD
X
X
OCS-Camera Software Communication Interface
ICD
OCS-Command Dictionary for Data Management
ICD
OCS Command Dictionary for the Telescope
Infrastructure Interfaces between the Summit
Facility and OCS
Auxiliary Instrumentation Interface between the
OCS and Telescope
ICD
X
X
ICD
X
X
ICD
X
X
ICD
X
Auxiliary Instrumentation Interface between Data
Management and Telescope
2
ICD
X
X
ICD
X
X
ICD
X
X
ICD
X
X
X
ICD
X
X
ICD
X
X
ICD
X
X
ICD
X
X
X
X
OCS
X
X
ICD
X
EPO
X
X
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
2.3.1.2 Project Wide System Level Interface Overview
Figure 2-1 shows a summary of the major LSST subsystems and the interfaces between them.
Figure 2-1: LSST Interface Block Diagram
2.3.2 Sub-sub-System Interfaces
For interfaces in which a single subsystem team (e.g., Data Management, Camera, Telescope and Site,
Education & Public Outreach, Observatory Control System) controls both sides of the interface, the
subsystem team has interface responsibility.
2.4 Content
Interface Control Documents will define all needed interface requirements for the subsystem teams to
fully design their responsible hardware or software on their side of each interface.
2.4.1 Introduction and Overview
Each ICD will provide an introduction to the purpose and scope/content contained within it. A high level
schematic / block diagram will be included to orient the user to the major subsystems and components
on each side of the interface and the interfaces between them. See Figure 2-2 as a proposed example.
Interfaces will be represented as lines. Arrows will be used to indicate the direction of data, thermal,
fluid flow, etc. The color of the lines will indicate the classification type of the interface (defined in
Section 2.4.2; a consistent coloring scheme across schematics will be used).
3
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Figure 2-2: Sample Interface Control Schematic (For LSE-65)
2.4.2 Interface Classifications
There are several categories of interfaces that each ICD should address. These have been defined as:
 Structural: Includes items such as mass, center of gravity, moments, accelerations, vibrations,
etc. This also includes mechanical connections (including connection hardware).
 Network Connectivity: Includes bandwidth, type of protocol, etc.
 Logical: Includes any of the data or information that is transmitted across the physical network
and/or utility hardware. This includes telemetry data and command and control data.
 Handling/Access: Includes allowable carts and fixtures, pick points, crane access, and allowable
access points/volumes for integration and maintenance activities.
 Accommodation: Includes the physical volumes allocated for equipment.
 Thermal: Includes all thermal loads transferred across the interface.
 Power/Utilities: Includes power, grounding, lighting, and electrical safety. Utilities also include
fluid transfer (for example, cooling fluids)
 Personal Access: Includes personal access for integration, maintenance and operations
 Deliverable: Items provided by one organization to another. There are two sub-classifications
defined.
o Operational and Support Unit Deliverables: Items provided by one organization to
support operations of the fully integrated system, integration, maintenance and testing.
o Pre-Integration Units: Items provided by one organization to support pre-integration
activities and sub-system verification. This includes prototypes, pre-production
software, DAQ test stands, etc.
4
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
2.4.3 Requirement Structure
For each Interface Classification, requirements will be documented as needed to fully define the
interface. The following verb definitions apply to the writing of requirement statements.
 Will – A statement of fact. Will statements document something that will occur through the
course of normal design practice, project process, etc. These statements do not get formally
verified.
 Shall – A requirement that gets formally verified. Shall statements document critical
requirements that must be verified through inspection, demonstration, analysis, or test during
the verification phase of the project to ensure objectively that the as-built design meets the
requirement.
 Should – A goal. Should statements document a stretch goal. A should statement will be
partnered with a shall statement. Should statements do not get formally verified.
2.4.3.1 Drawings Supporting Requirements
If a drawing can more accurately represent the intent of a requirement, the requirement statement will
reference the drawing number and applicable page, view, section, and/or callout. As a reminder, the
drawing must represent the actual requirement rather than the design solution. Figure 2-3 shows an
example from LSE-18 of a page that defines a preferred format for documenting both sides of a physical
interface using an additional table to specify the details of each side of the interface.
5
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Figure 2-3: Example of Drawing to Support ICD Requirements
2.4.4 Verification Planning
By Phase 3, the verification plan for each interface requirement will be defined. It is a systems
engineering best practice to develop the verification plan alongside the development of the
requirements to ensure that clear and verifiable requirements are written. It is therefore natural to put
the verification plan alongside the associated requirements in the same document, as it allows easy oneto-one cross-references between the requirements and verification plan. Include a verification table at
the end of the ICD that includes the following information:
 Verification Method: Options are Test, Demonstration, Analysis, and Inspection. These are
defined as:
o Inspection: An examination of the item against applicable documentation to confirm
compliance with requirements. Inspection is used to verify properties best determined
by examination and observation (e.g., paint color, weight, etc.)
o Analysis: Use of analytical data or simulations under defined conditions to show
theoretical compliance. Analysis (including simulation) is used where verifying to
realistic conditions cannot be achieved or is not cost-effective and when such means
establish that the appropriate requirement, specification, or derived requirement is met
by the proposed solution.
o Demonstration: A qualitative exhibition of functional performance, usually
accomplished with no or minimal instrumentation. Demonstration (a set of verification
activities with system stimuli selected by the system developer) may be used to show
that system or subsystem response to stimuli is suitable. Demonstration may also be
appropriate when requirements or specifications are given in statistical terms (e.g.,
mean time to repair, average power consumption, etc.)
o Test: An action by which the operability, supportability, or performance capability of an
item is verified when subjected to controlled conditions that are real or simulated.
These verifications often use special test equipment or instrumentation to obtain very
accurate quantitative data for analysis. (Haskins, 127)
 Verification Level: This field is to indicate if the interface will be verified at 1) the component
level prior to integration with a simulator or mockup to represent the other side of the interface
or 2) as part of integration on the mountain in Chile. For interfaces, option 1) may be done as a
compliance check in addition to option 2), but option 2) will in all cases be conducted as part of
commissioning.
 Verification Timing: This is a field to indicate the relative timing of the verification. The intent is
to specify a time period (to the calendar quarter-year level of fidelity) and any predecessor
relationships to any other verification events that must be completed prior to this verification
event, if known.
 Verification Requirement: This is a statement that defines precisely what will be done to verify
the requirement. If a test or demonstration is to be conducted, it should state what type of test
or demonstration will take place (for example, a vibration test), where it will take place (if
known), and if any special test equipment is required (special test equipment is defined as any
equipment that is not typically available at the facility at which the test or demonstration will be
conducted). If an analysis is to be conducted, the analysis tool should be specified as well as any
boundary conditions and limiting assumptions that are relevant to the analysis. Verification
6
Interface Control & Compliance Management Process
LSE-151
Latest Revision 03/15/2013
Requirements will be written in standard requirements language. The standard format is:
o “The <name of the requirement> shall be verified by <verification method>”. <The next
sentence describes the details of the verification event>.
 Success Criteria: This is a statement that defines the explicit pass/fail criteria. This statement
should be clear enough that an independent third party observer should be able to determine if
the verification event was successful or not. For performance and other quantitative
requirements, the success criteria should include the specific value (or range), units, and any
statistical information necessary.
Table 2-2 shows the format of a verification table to be placed at the end of each ICD by Phase 3.
Table 2-2: Verification Table
Req.
ID #
Requirement Text
Verif.
Verif.
Method Level
Verif.
Timing
Verification
Requirement
Success Criteria
3 Interface Support Documents
3.1 Purpose
Interface Support Documents are written for a variety of reasons but are also useful to teams working
on interface control. These documents provide constraints to the ICDs themselves. The ICDs must be
compliant with these documents. They may contain dictionaries, protocols, or definition of system-wide
architectural frameworks by which the subsystem teams must abide. These documents do not contain
requirements.
3.2 Responsibility
Interface Support Documents are written by the subsystem teams that have a stake in the subject
matter. These documents will be placed under configuration control.
3.2.1 List of Interface Support Documents
The current list of Interface Support Documents is defined in LSE-161 Interface Support Document List.
3.3 Content
Interface Support Documents do not have defined content. As support documents, they may contain
information in a variety of formats to best express the information to the end user.
7