Solar B - EIS
MULLARD SPACE SCIENCE LABORATORY
UNIVERSITY COLLEGE LONDON
Author: A Dibbens

SOLAR B - EIS MANAGEMENT PLAN

Document Number: MSSL/SLB-EIS/AD004.03 02 July 2000

Distribution:

NRL
G Doschek


C Korendyke


S Myers


C Brown


K Dere


J Mariska




NAOJ
H Hara


T Watanabe




RAL
J Lang


B Kent


D Pike

BU
C Castelli


S Mahmoud

Mullard Space Science Laboratory
J L Culhane


A Smith


A James


L Harra


A McCalden
.

C McFee


R Chaudery


P Thomas


R Card


W Oliver


P Coker


R Gowen


K Al Janabi


M Whillock

SLB-EIS Project Office
A Dibbens
Orig

Author:

Date:





Authorised By

Date:





Distributed:

Date:




Change History
Issue, Date
Author
Section
Changes
1.2d, Feb 15 1999
M. Whyndham
2.2
2.2
3.5

3.11
Added contact list .
Removed Organigram.
Added material in Definition of System Design and Interface .
Added material in Treatment of Risk.
2, July 16, 1999
M. Whyndham
2.1
2.2

2.3
2.4
2.5
3.1

3.3

3.4
3.5
3.6-3.10
3.11
Added actual institutes and WBS
Restored Organigram Figure 1
Added Interface Information Organigram (f. 2)
Revised SDT roles
Revised Planning & Reporting
Elaborated Archive concepts
Table (2) of Models Added
Model Philosophy clarified
Removed Requirements management chart
Clarified Requirements concepts
Design Critera edited
Minor edits
Edits throughout. Reference to future plans
Updated
3, July 2, 2000
A.P. Dibbens
All
Major revision in most sections to ensure consistency with other documentation and to remove duplication of information.
Addition of Project Director
Addition of Norwegian involvement
Update of personnel assignments

Contents

1 Introduction

This document is the top level plan for management and systems engineering for Solar-B EIS (the EUV Imaging Spectrometer).

This plan supersedes the management plan in the UK proposal. It also covers the activities of non-UK institutions.

2 Applicable Documents

RD 1
MSSL/SLB-EIS/AD/005
Risk Assessment
RD 2
MSSL/SLB-EIS/PA/001
Document List
RD 3
MSSL/SLB-EIS/PA/002
PA Plan
RD 4
MSSL/SLB-EIS/PA/003
Contamination Control Plan
RD 5
MSSL/SLB-EIS/SP/006
EIS Structure Requirements
RD 6
MSSL/SLB-EIS/SP/007
EIS Science Requirements
RD 7
MSSL/SLB-EIS/SP/001
EIS CCD Camera – System Requirements
RD 8
MSSL/SLB-EIS/SP/008
Model Philosophy and Test Plan
RD 9
MSSL/SLB-EIS/SP/009
EGSE Requirements
RD 10
MSSL/SLB-EIS/SP/011
System Definition
RD 11
MSSL/SLB-EIS/SP/012
ICU Design Requirements
RD 12
MSSL/SLB-EIS/SP/013
EIS Mode Definition
RD 13
MSSL/SLB-EIS/SP/014
Specification of Power System
RD 14
EIS-man-wbs
Work Breakdown Structure

3 General Management

3.1 Responsibilities of Institutions

The institutes who will contribute instrument hardware and/or software for EIS are:
Mullard Space Science Laboratory (MSSL), University College London
University of Birmingham (BU)
Rutherford Appleton Laboratory (RAL)
US Naval Research Laboratory (NRL)
NASA Goddard Space Flight Center (GSFC)
University of Oslo
PPARC is the UK funding body for this instrument. NASA is the funding agency for the US teams.

ISAS is the Japanese body responsible for the Solar-B project.



The general hardware/software responsibilities of the contributing institutes are indicated below. The detailed breakdown of responsibilities is indicated in RD 14.

MSSL: Project Management, Systems Engineering, System PA, Instrument Control Unit, Camera, Harness (internal), Mechanism and Heater Control Unit (FM), On-board software, EGSE, PM AIV
Birmingham University: Structure, thermal design, clamshell door, thermal blankets, MGSE, MTM/TTM AIV
Rutherford Appleton Laboratory: Cleanliness, QCM, FM AIV
Navel Research Laboratories: Optical elements, filters, mechanisms, mechanism and heater control unit breadboarding.
Oslo: support to EGSE software

3.2 Organisation of Staff

The main chain of responsibility is from ISAS, through the UK Principal Investigator (PI) to the Project Manager.


An organigram showing staff roles and reporting lines - mainly within the UK is shown in Figure 1.


In order to formulate the scientific and technical requirements of the instrument, the PM will work closely with the PI and will attend meetings of the Science Team.

Points of contact in each Institute for scientific and technical issues have been nominated as follows:

Institute
Local Manager
Science Contact
Technical Contact
MSSL, UCL
Tony Dibbens
(Ady James from Sep 00)
Louise Harra
cc. Len Culhane
Matthew Whyndham
Birmingham University
Chris Castelli
George Simnett
Saad Mahmoud
cc Chris Goodall
RAL
Jim Lang
Jim Lang
Jim Lang
Naval Research Lab
Steve Myers
George Doschek
Clarence Korendyke
cc George Doschek
NAOJ

Tetsuya Watanabe
cc Hirohisa Hara
Hirohisa Hara
cc Tetsuya Watanabe
ISAS
Takeo Kosugi
Takeo Kosugi
Takeo Kosugi
Oslo
TBD
TBD
TBD
Cambridge University
-
Helen Mason
-
Imperial College
-
Peter Cargill
-
St Andrews University
-
Eric Priest
-

All science-related correspondence in the project shall be raised with the UK Project Scientist, Louise Harra, and copied to the UK PI, Len Culhane. All technical correspondence shall be raised with, or copied to, the Project Manager (PM). The flow of Solar-B spacecraft interface information is through the EIS secretariat, Dr. H. Hara at NAOJ. This is shown in Figure 2.


Within the UK a Project Director is responsible to PPARC for programmatic issues including resources and scheduling.

Individuals’ email addresses and phone numbers are shown in the “Contact List” EIS-man-contacts. Institute addresses are found in the “Institutes List” EIS-man-institutes. Several email distribution lists have been established for Technical and Science topics, see the document “Mailing Lists” EIS-man-mlists.

Figure 1. Organigram of Staff.



Figure 2. Flow of Interface Information.





3.3 The System Design Team

The System Design Team (SDT) will have the central role developing the instrument in response to the requirements. The SDT will include the individuals named in the technical disciplines shown in figure 1. For institutes other than MSSL, these represent the points of contact for those institutes. The SDT will seek advice and information from others from time to time.

The SDT will hold regular meeting chaired by the PM. The main purpose of these meetings will be to advance the resolution of technical issues affecting the design and implementation, including test and calibration of the system. Other functions are listed (non-exclusively) in Table 1. Minutes of SDT meetings will be made available to all project participants.

System Design Team Functions
Notes
System Design
Identification and resolution of system-level issues
SEMP
System Engineering Management Plan, iteration and concurrence
WBS
Work Breakdown Structure, development and concurrence
Requirements
Development of system functional requirements, system specifications, system test requirements and any required subsystem documentation
System functional concepts
Development of operating concepts
Selection of design criteria

Interface Definition

Budget Management
For items which are subject to budgeting, such as mass, power, alignment, contamination etc.
AIV
Assembly, Integration and Verification (including system testing). Plans and oversight
Project Management Activities
Detailed Schedules and costing
Product Assurance
Plans and concurrence
Configuration Management
Plans and concurrence
Reviews

Risk Management
Identification of Risks, Control and Reporting
Table 1. Roles of the system design team.

3.4 Planning and Reporting

A requirements driven systems engineering process will be employed. This is manifest in the creation by a document set consisting of:


The Management of the process will be governed by:

While this is not a complete list of all project documentation it shows the general philosophy adopted.

The following project meetings will occur. Other, ad-hoc meetings will be commonplace.


Meetings of the SDT or relevant subsets are expected ~monthly on average, but no longer than two months apart. The meetings follow an agenda : EIS-meet-sdt-genda. Brief minutes of these meetings will be made generally available and circulated to the technical contacts. All significant systems engineering decision-making is done by or with the agreement of this group, which has representation from all parties having technical involvement in the instrument. A series of teleconferences between MSSL and NRL has been established. These are treated in the same way as SDT meetings. SDT meeting minutes are generally as EIS-meet-sdt-minutesX, X being the number of the meeting. The teleconference minutes are filed as EIS-meet-sdt-tcXXXX, where X is another serial number.

From time to time, there will be Engineering team meetings, with similar remit to the SDT, and Consortium Meetings, whose membership also includes the consortium science team and whose remit therefore extends to definition of the basic requirements. These meetings will also be minuted as EIS-meet-cons-YYMMmins, where YY and MM are the year and month of the meeting.

At MSSL, a Programme Review Meeting (PRM) is held on a monthly basis at which the PM will make a report concerning the general progress of the project, with a particular focus on activities within MSSL. Other institutes may have similar internal mechanisms. The PM will make his PRM reports (EIS-meet-prm-reportX) available.

At intervals (~2 times per year) there will be a meeting of the PPARC EIS steering committee, to which each UK participant project manager will make a report and financial statement and other materials as requested.

The UK Project Director will chair regular meetings of the UK local managers to review progress and resource implications.

3.5 Archiving of Project Material

It is intended that a project documentation distribution and archive system be maintained which:
The term Archive is used both in the sense of a repository of current material and a store of historical material. Certain types of electronic document will be permitted in the archive.

EIS documents will be subject to Configuration Control.

It will be encouraged that all project documents are made available in electronic form.

The document archive will be propagated from MSSL to other team institutes, either by network transfer or by other media.

A Document List is maintained at the MSSL project website.

4 Systems Engineering Management

4.1 General Approach

In this plan, the term "system" means the EIS instrument. The systems engineering approach adopted in this project should ensure that there is:

The responsibility for systems engineering is held collectively by the SDT. Additionally, the management techniques should not be laborious, and therefore the approach to systems engineering is relatively informal in most areas. However, particular attention is paid to documenting the needs, requirements and constraints of the system and subsystems.

4.2 Model Philosophy


The Model Philosophy is described in RD8.

4.3 Design Reviews

This section will contain details of all the reviews. The following are scheduled at the time of writing:
Other reviews may be required during the programme. These may include the following:

The US contributions to the project will be subject to internal NASA reviews which will be attended by EIS project staff. The outcome of these reviews will be input to the EIS reviews listed here.

4.4 Evaluation of System Performance

RD 8 shows how system performance is to be evaluated at various times, give an outline of full and abbreviated performance tests, and their relationship with calibration tests.

4.5 Assembly, Integration and Verification (AIV) Plan

The AIV Plan shows how the instrument will be brought together as a system from its units, for each of the models which exists as a system. This will include full references to all the necessary assembly and test procedures. An important aspect of the system verification is the End-to-End calibration of the instrument.

4.6 Product Assurance Plans

The PA plan (RD 3) is based on existing PA plans for other projects. It includes:

4.7 Treatment of Risk

It is necessary that the EIS instrument perform in accordance with its requirements throughout the planned mission and that the development programme be conducted in a timely and cost effective manner. There is always a finite probability that the development programme may not result in the delivery of an instrument that meets its initial requirements (termed "programmatic risk") or that the instrument may not perform to requirements throughout the mission life ("operational risk"). The programme will be managed to ensure an acceptable level of each these risks.

The degree to which risks can be reduced depends broadly on the time and resources available for development in relation to the requirements. Given that the programme has finite resources and a limited schedule, the first task must be to ensure that there are no unnecessary requirements.

The consortium will declare what its attitude to risk will be in relation to the likely scientific return of the instrument.

Certain established design criteria may be in conflict with risk reduction - for example a desire to use innovative technology. These conflicts will be exposed where they exist and a stance taken at consortium level.

Within the framework established by time, resources and requirements and attitude to risk, particular elements of the total risk can be ameliorated in several ways.

Programmatic risks are first reduced by assessing the system requirements. Excessive requirements are avoided.

The production processes of technological items are then studied. Margin in performance may be included in the specification of subsystems. Where the performance of a subsystem can deviate from an ideal value a budget for errors will be calculated, or its quality will be controlled to the required level. This is the subject of the Product Assurance plans. A means of escaping the consequences of failures, should they occur, will be sought. The existence of such fall-back options will be considered for each item where there is an appreciable development risk. In cases where the risks are high such options will be actively developed.
Management of operational risks demand the following types of responses: avoidance of hazardous conditions (processes, materials, operational procedures), escape from consequences of failure (e.g. by redundancy), management of degradation (by monitoring of condition).

Assessment of programmatic and operational risks will be a function of the Project Manager/Systems Engineer and the System Design Team, and will result in a series (at various stages during the life of the project) of system-level risk analyses.

The document Risk Analysis (RD 1) list and qualifies the existing risks to the development of operation of the EIS instrument both at system level and at subsystem level. Reference may be made to sub-system level risk analyses - these are prepared by the responsible groups.

Each risk source will have an “owner”, whose task it is to manage that risk, i.e. make quantitative assessment, suggest mitigation, provide evidence of achievement of quality etc. The ownership of each risk is stated in the Risk Analysis.

A Risk Register will be maintained following the PDR.
An Issues Register will be maintained following the PDR