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.

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

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:

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.

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.

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.

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.

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.

The Model Philosophy is described in RD8.

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.

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.

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.

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

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