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

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

The plan will be evolved as the project progresses.

The institutes who will contribute instrument hardware and software for EIS are:

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 US partner was selected under the auspices of the three agencies since the last issue of this plan.

The breakdown of responsibilities is indicated in the Work Breakdown Structure (WBS) EIS-sys-eng-wbs. The table below is copied from version 2 (12 July 99) of the WBS. Some details of allocation of responsibility remain to be finalised.

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.

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.

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:

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 2. Flow of Interface Information.

The System Design Team (SDT) will have the central role developing the instrument in response to the as-stated requirements. The SDT meetings will be chaired by the Project Manager and will include the individuals named in the technical disciplines shown in the diagram. 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.

In addition to this document, there are other key documents that relate to the planned work and actual progress of that plan. These include:

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 Project 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.

It is intended that a project documentation distribution and archive system be developed which

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

Since the resources available do not extend to the employment of full time systems engineer, 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. Refer to "Management of Requirements" later in this document.

The Model Philosophy describes the intermediate stages of design, development and test, the order and approximate timing of these stages and their relationship to the final, delivered instrument.

The Model philosophy for Solar-B (including EIS) is very similar to that employed in previous missions conducted by the ISAS (the Japanese Agency for space science). Some of the details, such as the names given to certain models, differ somewhat from ESA and NASA practice. This document adopts the ISAS terminology.

The spacecraft model philosophy consists of a Prototype Model (PM), a mechanical test model MTM (MTM), a Thermal Test Model (TTM), and the Flight Model (FM). As well as delivering the FM instrument, the EIS experiment team is also expected to participate in the PM, MTM, and TTM test programs.

This is a prototype (as opposed to protoflight) philosophy in that the qualification tests are performed on non-flight models.

Breadboards (BB)

Breadboard models of many subsystems will be developed, the purpose of which will be to demonstrate the suitability of technology to be employed in later models, to expose any unforeseen problems which may exist and to further refine the system requirements.

The areas to be addressed within the UK are : Camera (focal plane assembly and readout electronics), instrument control unit, mechanism/heater drivers, structure and door. There will be a need for a software development platform.

Subsystem level tests (exact content of these tests is TBD) will be performed on these partial breadboards. Some partial integrations may be achieved at breadboard level.

The NRL group may elect to produce an optical breadboard system. This is TBD.

Pre-flight models (PM, MTM, TTM)

The Prototype Model (PM) is used to verify the functional operation of the system, including its electrical interfaces with the spacecraft and ground segment. Another model (or two models) is used for further (Mechanical and Thermal) spacecraft level interface design verification.

The PM will not be fully functional in that it will not contain optical elements. Mechanical and thermal properties need not be representative of the final design, except where necessary for validation in the areas which are tested. The validation tests to be performed on this model will include (TBD) :

The results of both the MTM and TTM tests could be used in the further development of the instrument flight model (although the schedule does not allow significant interval between MTM/TTM test and FM manufacture).

Comment : There are no optical components in any of the preflight models. Some additional methods of gaining confidence in the optical technology (production, alignment, etc.) may be necessary.

Flight Model (FM)

At this stage of development a high level of confidence in the design will have been obtained from previous models.

The flight model (FM) is the only model to be fully calibrated. It is also the only model that contains a set of optical elements (not including optics breadboards).

It will be used for system level mechanical and thermal testing together with performance verification/ validation tests to demonstrate full compliance with requirements. The level of the testing is TBD (e.g. environmental tests could be at a lower - "acceptance" - level than the qualification tests carried out during the MTM/TTM phase).

Some further, minor, development of the FM design can be expected during FM integration.

Spares

There will not be a complete spare instrument, nor indeed a complete set of spare parts, but rather a spares philosophy will be adopted which involves the provision of key items and contingency planning. This posture is adopted as a means of reducing costs. Critical items which require spares will be identified prior to FM parts procurement.

The User Requirements document expresses the scientific goals which the system's operation will achieve.

The System Requirements document is partly a Functional Requirements Document. It reflects the User Requirements by stating the functional requirements of the system in measurable terms (what the system must do and how well it must do it). Any additional requirements or technical and managerial constraints are also contained in this document. This covers the spacecraft resource allocation, interfaces and environmental characteristics.

The System Specification document describes how the system will meet the requirements. This will refer to the technology to be employed (whereas the Requirements do not). It is recognised however that there will be some iteration between the capabilities of the solution and these requirements, the aim being to arrive at an achievable set of requirements.

Each of these documents is described in more detail below.

If there are competing solutions, which otherwise meet the requirements, then each will have its own Specifications document. Each Specification document will refer for further detail to a Design Document. The Design document refers to all other technical documentation related to that solution, including where appropriate a set of Requirements, Specifications and a Design for each subsystem.

Competing solutions will be subject to evaluation based on the Design Criteria.

The User Requirements document

There is a wide interest in the outcome of the Solar-B mission in the solar physics communities of the U.K., Japan and the U.S.A. The interests of these communities are partly represented by the funding agencies in each countries. Their interests have also been expressed in reports such as Solar-B Science Definition Team - Final Report, and others. These are the broad needs.

However, it is not the intention of the PM or the SDT to comprehensively address the broad needs. The User Requirements document records the specific requirements of the EIS consortium, as represented by the Principal Investigator (PI) and the Science Team. It will be the responsibility of the SDT to ensure that the User Requirements are well formed and measurable.

For the purposes of the User Requirements Document the PI and the Science Team are regarded as the Users of EIS.

The System Requirements document

This document contains the System Requirements that emanate from the User Requirements (scientific requirements), and the other requirements. The latter are technical constraints (due to accommodation of the instrument on the spacecraft), managerial constraints, interface requirements, and others. The origin of these will be justified.

This document states what should be achieved but does not state how it is to be done.

The System Specifications document

This document elaborates on the System Requirements document and will contain an outline of a technical solution to the problem posed by the requirements.

This document will contain a statement of what elements comprise the system and what interfaces exist, both between them and externally (with the spacecraft). It will also refer to a document known generally as the Design Document.

This document will be subject to review at the PDR and CDR.

The Design Document

This is the top-level design document for the system. It contains or refers to

The management of interfaces is described in section 3.5.

Design Criteria constitute the rules for prioritising competing designs. Competing designs are those which meet the requirements (and are therefore satisfactory in other respects). Very often these choices are made implicitly. Here we explicitly state each Criterion that is presently known, firstly in general areas applicable to the whole system and secondly in particular technology areas or subsystems.

This list is presented as material for discussion in the SDT.

The general criteria are as follows:

Management : success is defined in relation to three main drivers.

Each ICD will be prepared to a format specified by the Project Manager.
These formats will be specified in [EIS-sys-eng-icdform]. They (ICDs) will be authored jointly by the institutes concerned. Approval for the project will be by the Project Manager. Approval for incorporation of an interface document to be part of a baseline design (Functional, Allocated) will be by Review as indicated above.

This section will contain details of all the reviews. The following are scheduled at the time of writing:

Other reviews may be undertaken at subsystem (unit) level, depending on the criticality of each subsystem.

Preliminary design review

Critical design review

The System Test Plan, which will later be included here, will show 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 will show 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.

This plan will be elaborated in future editions. Topics will include:

A PA plan will be developed for EIS, based on existing PA plans.

The topics will include

Quality Assurance

Configuration Management

Reliability Assurance

Component Quality

Materials and Processes Selection

Safety Assurance

(This section will be later included in the Product Assurance Plan).

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.

This document is "Risk Analysis" EIS-sys-eng-risk
Issue 1, 15 July 99

This includes a statement of the programmatic risk and operational risk for each WBS element (all level 2 items and some level 3 items) in the system as well as for the system as a whole. Reference may be made to sub-system level risk analyses - these will be 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.

All documents in EIS are uniquely identified by an alphanumeric string. Document Identifiers in the EIS project conform to the following general scheme. As far as possible, all documents are stored electronically, and the storage location in the archive (the file name) can be identified directly with the document identifier.

There is a system for documents generated within EIS and a notation for documents generated outside.

Internal Document identifiers have five fields

Fields 2 and 3 should be taken from the WBS issued by the project manager.

The full document identifier is constructed from these fields, separated by ‘-’ (hyphen). "EIS" is written in capitals and the rest are lower case. It is recommended to show such identifiers in italic to distinguish them from surrounding text.

For example, the following shows the format : EIS-unit1-section2-swnotes-3.27, where Unit 1 and Section 2 are phrases in the WBS. The Label "swnotes" indicates that the document might contain Software Notes. The final numeral indicates that the document is at Issue 3, release 27.

File names are constructed from the same document identifier fields, using whatever separator characters are required by the file system (e.g. ‘/’ or ‘\’). An additional suffix is used to denote the document format (e.g. .txt, .doc, .pdf).

The file types which may be encountered are TBD.

The full location is found be prefixing the location of the document archive (this may vary depending on site and implementation).

External documents are denoted differently. If the document has a clear number or other concise reference (as in a Journal Paper) then that is used. Otherwise If the document does not have a clear number then it is given a serial number in a table of such documents maintained by the project manager. These are of the form

EIS-x-###

The letter x denotes the fact that it is an external document. ### may be any number. For example: