|
Issue |
1 (draft) |
|
Document ID |
EIS-management-general-manplan-1d |
|
Document File |
D:\Users\mwt\Projects\Solar-B\EIS\docs\man\manplan1d.doc |
|
Authors |
Matthew Whyndham, MSSL |
|
Date |
November 16, 1998 |
Contents
Introduction
*General Management
*Responsibilities of Institutions
*Organisation of Staff
*The System Design Team
*Planning and Reporting
*Archiving of Project Material
*Equipment
*Document Identification System
*Documents created within EIS
*Example
*Documents which originate outside EIS
*Systems Engineering Management
*General Approach to Systems Engineering
*Model Philosophy
*Breadboards (BB)
*Pre-flight models (PM, MTM, TTM)
*Flight Model (FM) and Spares
*Management of Requirements
*The User Needs document
*The System Requirements document
*The System Specifications document
*Definition of System Design and Interfaces
*The Design document
*Evaluation of System Performance
*Design Criteria
*Reviews
*Preliminary design review
*Critical design review
*Treatment of Risk
*Programmatic Risk
*Operational Risk
*AIV
*Product Assurance
*Configuration Management
*
This document is the top level plan for management and systems engineering for Solar-B EIS (EUV Imaging Spectrometer).
This plan will eventually supersede the management plan in the UK proposal. It also covers the activities of non-UK institutions.
Responsibilities of Institutions
The initial breakdown of responsibilities is indicated in the UK proposal (p 37). The details are subject to changes in the future, depending on design evolution. When finally agreed the breakdown will be listed here.
At the time of writing, the funding parameters for the US partner is not known, although the overall budget for US involvement in Solar-B as a whole is indicated in the NASA AO. In the UK the overall funding profile for each participant has been agreed with PPARC.
Figure 1 : EIS organigram.
Figure 1 shows an organigram showing staff roles and reporting lines - mainly within the UK. The main chain of responsibility is from ISAS, through the UK Principal Investigator (PI) to the Project Manager.
All science-related correspondence in the project should be copied to the UK PI, Len Culhane. All technical correspondence should be initiated with, or copied to, the Project Manager (PM).
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.
The System Design Team (SDT) will have a central role in forming the design of the instrument in response to the as-stated requirements, and implementation of that design. 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 of the system. Other functions are listed (non-exclusively) in Table 1.
|
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 amd any required subsystem documentation |
|
Selection of Design Criteria |
|
|
Interface Definition |
With spacecraft and internal |
|
Project Management Activities |
Detailed Schedules, costing |
|
Testing |
|
|
Product Assurance |
|
|
Configuration Management |
|
|
Reviews |
Table 1. Roles of the system design team.
Minutes of SDT meetings will be made available to all project participants.
schedules
reports to PI and Project Review forum
need for archive
show audit trail of development decisions
allow later use within project institutions of generated designs and hardware
formats within the electronic document - permitted, official
use of archive to distribute material
propagation of the archive
maintenance of links within project documents - types of link
documentation standards - templates, required information, requested information
configuration control system
Storage of equipment
Document Identification System
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
|
Field |
1 |
2 |
3 |
4 |
5 |
|
Purpose |
Project Name |
Subsystem |
component or lower level system |
Label |
Issue details |
|
Notes |
"EIS" is used to distinguish project documents from those in other projects |
These are the first level items in the WBS |
Lower level items in WBS |
This field describes the content of the document. If possible use a unique, memorable string. |
Any numeral with optional suffix "d" indicating draft status. A single point may be used to differentiate minor releases. |
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 is TBD.
The full location is found be prefixing the location of the document archive (this may vary depending on site and implementation).
Suppose that Issue 2 of the STM Focal Plane Assembly Requirements list is denoted by
EIS-fpa-stm-reqlist-2
This is the identifier. The corresponding file name depends on the method of delivery of the archive and the format in which the document is stored. The Label will be concatenated with the Issue suffix.
Therefore in the archive stored at \\mssljs\solar-b (on Windows NT - directories separted by \) it is located at
\\mssljs\solar-b\EIS\fpa\stm\reqlist2.doc
(The .doc indicates a Word document.)
Suppose the same archive is available through a web server http://eis-www.rummidge.ac.uk/ with the archive rooted at "documents". Then Issue 4 of the same document might be available as a PDF file as
http://eis-www.rummidge.ac.uk/documents/EIS/fpa/stm/reqlist4.pdf
Documents which originate outside EIS
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:
EIS-x-2 : The Solar-B Mission - Final Report of the Science Definition Team, June 19, 1997. (Various authors).
http://wwwssl.msfc.nasa.gov/ssl/pad/solar/sdt-rpt.htm
Systems Engineering Management
General Approach to Systems Engineering
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 to not extend to the employment of full time systems engineer, the responsibility for systems engineering is held collectively by the system design team. Additionally, the management techniques should not be laborious, and therefore the approach to systems engineering is relatively informal to 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. In most systems engineering texts, the term "Systems Engineering Paradigm" is used to denote what is called the Model Philosophy here.
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. In this document we have adopted the Japanese terminology.
The system model philosophy consists of Breadboards (BB), a Prototype Model (PM), a mechanical and structural model or models, and the Flight Model (FM). All models except the Breadboards are "deliverable" items, that is, they will be integrated with a model or models of the spacecraft and other payload items.
Breadboard models of many subsystems will be developed, of 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 : focal plane assembly, electronics box, door. There is likely to 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.
US: Optic breadboard.
Pre-flight models (PM, MTM, TTM)
A Prototype Model is used to verify the functional operation of the system, including its interfaces with the spacecraft and ground segment. Another model (or two models) is used for further spacecraft level interface design verification.
Prototype Model (PM) : This 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 PM will also be used as a platform for further electronic and software development.
There will be two models of the spacecraft which will be used for mechanical and thermal tests. They are called the Mechanical Test Model (MTM) and the Thermal Test Model (TTM). These will undergo separate programs of tests. Consequently there is a need for a suitable model of EIS to participate in each of these tests. It is unclear whether this requirement can be satisfied with a single Structural-Thermal Model (STM) or whether two separate models will be required. For purpose of this discussion assume that two such models will exist.
Mechanical test Model (MTM): this is highly representative in mechanical terms but will contain no optics or electronics. All the mechanical qualification tests will be done on this model :
Thermal Test Model (TTM): This will have sufficient representation to allow thermal qualification of the design. It will contain no optics or electronics. The following tests are done on this model:
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.
At this stage of development a high level of confidence in the design should 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, hopefully minor, development of the FM design can be expected during FM integration.
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 development of the system (the EIS instrument) is controlled at the highest level by three documents, namely the User Needs document, the System Requirements document and the System Specifications document. Refer to Figure 2.
Figure 2 : Structure of the top level documentation tree
The User Needs document (ref) expresses the goals which the systems operation will achieve.
The System Requirements document (ref) is partly a Functional Requirements Document. It reflects a subset of the needs 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 (ref) 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 Critera.
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.
However, this document records the wishes of the EIS consortium, as represented by the Principal Investigator (PI) and the Science Team.
For the purposes of the User Needs document the PI and the Science Team are regarded as the Users of EIS.
The System Requirements document
This document contains the system requirements which emanate from the user needs, called scientific requirements, and the other requirements. The later are technical constraints (due to accommodation of the instrument on the spacecraft), managerial constraints, interface requirements, and others (TBD).
The System Specifications document
Definition of System Design and Interfaces
Evaluation of System Performance
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 = the triangle
Technology
Areas where Tradeoff can be expected
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 purpose at the preliminary design review is to demonstrate the feasibility of the design. The follfol will be submitted for review in:
All specification documents, including software specifications
Following this review detailed design can begin. The interfaces are frozen (under configuration control?).
Details (internals) of the subsystems need not be fixed at this time. There could be major areas requiring further study.
The purpose of the critical design review is to gain confidence in the detailed design so that production (of EM and STM level subsystems) can begin. The risks of implementation should be well understood and acceptable.
Material to be available at this review will include (as well as updated versions of the documents brought before the PDR):
This section will supercede the risk analysis in the UK proposal.
Attitudes
Areas of Concern
Method of response
Most types of risk fall into following broad categories:
Programmatic risk: the probability of not delivering a working (i.e. to the required specification) instrument because of a human or organisational failure
Operational risk: the failure probability of the instrument during its operation
Some sources of programmatic risk:
confusion caused by project documentation, including this
misunderstanding of interfaces
failure of contractors to deliver component to required performance or cost
change of launch date
failure, at late stage, during environmental testing
incompatiblity with spacecraft discovered during integration
failure modes analysis required?
some sources:
meteoroid ingress
contamination of optics or detector
loss of optics motion
door failure
spacecraft misalignment thermal effects
radiation damage, e.g. to detector, memory, processor
on board software error
bad command
loss of functionality in electronics
loss of attitude information
= Assembly, Integration, Verification
includes (or refers) model test matrix
includes regimes for calibration
cleanliness - see Plan
testing - see AIV
parts, processes and materials selection
models & design freezes
ncr/ecr
document archive (again)