CDF System Description Rev 2 - European Space...

a

ESTEC Keplerlaan 1 - 2201 AZ Noordwijk - The Netherlands Tel. (31) 71 5656565 - Fax (31) 71 5656040

CDF-SYS-01 Issue2 Rev0 System

Description.doc

CDF

document title/titre du document

YSTEM ESCRIPTION

reference/réference CDF-SYS-001 issue/édition 2 revision/révision 0 status/état FINAL date of issue/date d’édition 20th January 2008 document type/type de document System Description

CDF System Descriptionissue 2 revision 0 – 20th Jan 2008

CDF-SYS-001page 2 of 39

A P P R O V A L

title titre

CDF System Description issue

issue

2 revision

revision 0

author auteur

Ross Henderson / Andrew Caldwell date date

11/09/07

approved by approuvé par

Massimo Bandecchi TEC-SYE date date

C H A N G E L O G

reason for change /raison du changement issue/issue revision/revision date/date

Addition of policy, update of domains, documents Restructuring in Line with new Documents

1 2

3 0

13/02/06 20/01/08

C H A N G E R E C O R D

issue/issue change/change page(s)/page(s) paragraph(s)/paragraph(s)

1/3 Sections Added: Added domains/workbooks 9 2.1.3,2.1.4

1/3 Report Distribution Policy Added 25 3.6.4

1/3 Facility Documents Updated 26 3.6.4

2/0 Document Restructured All All



T A B L E O F C O N T E N T S

1 INTRODUCTION........................................................................................................... 5 1.1 Background..........................................................................................................................5

2 CONCURRENT ENGINEERING................................................................................... 7 2.1 Definition of Concurrent Engineering .................................................................................7 2.2 Why Concurrent Design? ....................................................................................................8

3 THE APPROACH ....................................................................................................... 10 3.1 Top Level Requirements for the CDF ...............................................................................10 3.2 Implications for Project Phases .........................................................................................11 3.3 Communication Facilitation ..............................................................................................12

3.3.1 Information Sharing ...............................................................................................12 3.3.2 Data Sharing...........................................................................................................12

4 THE PROCESS .......................................................................................................... 14 4.1 Overview............................................................................................................................14 4.2 Iterations of the Spiral Model ............................................................................................14 4.3 Sessions Definitions...........................................................................................................15

4.3.1 Design Sessions .....................................................................................................15 4.3.2 Working Sessions...................................................................................................16 4.3.3 Presentation Sessions .............................................................................................16 4.3.4 Off-line Meetings...................................................................................................16

5 THE TOOLS................................................................................................................ 17 5.1 The Facility Infrastructure .................................................................................................17

5.1.1 Physical Schematic ................................................................................................17 5.1.2 Hardware Description ............................................................................................17 5.1.3 Software Description .............................................................................................19 5.1.4 Domain Tools Description.....................................................................................19

5.2 The Design Team...............................................................................................................20 5.2.1 The Central Team ..................................................................................................20 5.2.2 Other Members ......................................................................................................23

5.3 Administration ...................................................................................................................23 5.3.1 Study Administration .............................................................................................23 5.3.2 Facility Administration ..........................................................................................24

6 THE PRODUCTS........................................................................................................ 25 6.1 Final Model........................................................................................................................25 6.2 Presentations ......................................................................................................................25 6.3 Study Reports.....................................................................................................................26 6.4 CDF’s Distribution Policy .................................................................................................26



7 INTEGRATED DESIGN MODEL.................................................................................27

7.1 Description ........................................................................................................................ 27 7.2 Structure of Design Model ................................................................................................ 28 7.3 Model Segments................................................................................................................ 31

7.3.1 Data ExchAnge...................................................................................................... 31 7.3.2 System Workbook ................................................................................................. 31 7.3.3 IDM Workbooks.................................................................................................... 31

7.3.3.1 Principle Technical Domains..................................................................... 31 7.3.3.2 Other Domains........................................................................................... 32

7.3.4 IDAM Workbooks................................................................................................. 33 7.3.5 ISS & HUMAN Mission Workbooks ................................................................... 33

7.4 Versions............................................................................................................................. 33 7.4.1 Description of Version Numbers........................................................................... 33 7.4.2 Implementation in the Model ................................................................................ 34

8 THE RESULT ..............................................................................................................35 8.1 Integration of CDF Elements ............................................................................................ 35 8.2 Facility Documentation..................................................................................................... 36

9 REFERENCES ............................................................................................................38

10 ACRONYMS................................................................................................................39



1 INTRODUCTION

The aim of this document is to provide a brief description of the principal system level aspects of the ESTEC Concurrent Design Facility. Initially, it covers the approach towards concurrent engineering; how it is defined, why it is useful and how it impacts the design process.

The process and tools used to implement concurrent engineering are then discussed. This includes details on operations, sessions, infrastructure, the design team, and administration. Then, the resulting products from a CDF Study are outlined.

The characteristics to the nucleus of the facility, the Concurrent Design Facility Integrated Design Model (CDF-IDM) are also covered. However, only the general characteristics and the features common to all the components of the Model itself are considered here. Its special aspects (e.g. specific sub-system MS Excel® workbooks and models) have been instead considered in separate documents and User Manuals.

The utilisation of the Model itself and the capability of the various workbooks it is composed of are fully described in the CDF User Manual [1] and in the relevant workbook User Manuals, respectively.

Since the CDF Model is continuously evolving, this document will follow, with continuous improvements and updates over time. Take care, therefore, to use its latest revision or version.

1.1 Background

The scope of the ESTEC Concurrent Design Facility Integrated Design Model (The Model) is to provide a complete model, at system level, and with a sufficient level of detail, of a given spacecraft, lander or rover mission. All the mission preliminary design aspects, from mission analysis to, for example, cost and risk estimate, or from the various sub-systems design to programmatics and ground segment definition and design, are therefore covered. The central core of the Model is based on several different MS Excel® workbooks, used to model the various technical domains associated with the design of a spacecraft.

The Model has been developed for use within the ESTEC CDF for preliminary assessment studies, to aid the design process and improve its speed, allowing fast design iterations. With the utilisation of the Model, the production and fast communication of quantitative information is made easier, thus efficiently complementing the discussion, essential component of the concurrent design approach, taking place during the Design Sessions. Furthermore, the Model can be used to keep a record, and to act as a background, for information generated during the design process itself.

The present CDF Model has evolved from the Integrated Design Model (IDM) developed by Matra Marconi Space (MMS) for ESA1. Using the MMS IDM as a starting point, then, ESA has developed the CDF Model, reorganising it on several workbooks, dedicated to the various technical domains. These MS Excel® files have then been provided to, and further developed by, in their

1 Spacecraft Modelling – A Spacecraft Integrated Design Model, MMS (UK), December 1996



internal pages, the relevant ESA specialists, so introducing new modelling capabilities to each area of the Model2.

2 The CDF Integrated System Model, CDF-YGT-001, 24/3/2000



2 CONCURRENT ENGINEERING

2.1 Definition of Concurrent Engineering

Depending mainly on the context and the application environment, various different definitions of Concurrent Engineering and Concurrent Design have, up to now, been introduced and used in literature. In the ESTEC CDF context case, the following definition has been adopted:

General Concurrent Engineering Philosophy: Development of an engineering design team covering all relevant disciplines from the kick-off; working and communicating in a single environment; to establish a system(s) design; within a short period of time; and in a more consistent way; with respect to other approaches.

As it has also been made clear by the adopted definition, in the case of a space system design phase problem, therefore, concurrent design represents an alternative to other approaches, the three main examples of can be then described as follows:

• Sequential The overall design passes, during the various design steps, from a technical domain specialist (working in isolation from the rest of the design team) to another, in successive time steps. The removal of design inconsistencies, to guarantee the design convergence, is obtained with the iteration of the process itself.

• Centralised The various technical domain specialists provide sub-system design information and data to a core team of one or more system engineers, whose task is to analyse and check the design at system level, promoting and encouraging communication between specialists when appropriate or required.

• Concurrent The complete design team, composed of the various technical domain specialists, starts working on the different aspects of the project at the beginning of the design process. The rapid gain of design consistency and the final reaching of overall project convergence is obtained also with constant direct communication and data interchange amongst the team members.

The three reported alternatives are schematically represented in Figure 2-1.



Figure 2-1: Alternative Approaches to Space System Design

2.2 Why Concurrent Design?

Due to the fact that all the aspects of the spacecraft mission design are studied at the same time, with the application of the concurrent design approach the project consistency degree improves rapidly, over a time period dramatically shorter than in the case of a classical design approach. Each discipline is, in fact, always in communication with all the others, and all design decisions, when not directly taken at team level, are quickly communicated to the whole team for immediate verification, as shown in Figure 2-2. Therefore, all the design team members can constantly follow the same design path, avoiding the occurrence of incompatible approaches to the various sub-systems design, and reducing therefore the time and workload required by the Study.

Sequential Design

Centralised Design

Concurrent Design



Des

ired

Des

ign

Pat

h

Ultimate Goal

Specialist A Specialist B

DivergenceDesign Decision

Path

Communication

Figure 2-2: Influence of the concurrent engineering approach on design consistency



3 THE APPROACH

The result of concurrent design should be the rapid production of a final, consistent and well documented, system design of, in our case, a space mission, focussing on the provision of efficient and continuous communication between the team members. The basic involved processes do not depend on design definition level of the Study, and can therefore be applied, at least in theory, with minor changes, to all the phases of a project. Depending on the design definition level required by the customer, however, the CDF hardware and software capabilities can be involved and used at different levels.

3.1 Top Level Requirements for the CDF

The top-level requirements on the facility come from two major sources:

• The philosophy behind the design approach.

• The interaction with external entities that place demands on the facility.

The philosophy is a result of the demands placed on the facility, but in practice it is necessary to separate them. The concurrent design and management approach has lead to requirements being placed on external entities and vice-versa. A level of compromise has been achieved between the two so that a relatively fixed system has been established, and to allow the facility to become highly efficient. The demands placed on the two Facility Requirements Sources by each other are fed through the facility and have to some extent been established during the initial development of the CDF. This source dependency is depicted in Figure 3-1.

Figure 3-1: The Impact of the Top-Level Requirements on the ESTEC CDF

ESTEC CDF

External Entities

Customer

ESA Management

Standards

Others

Philosophy

Requirements



The customer may wish the design approach to be done in a different way to that planned for the facility. These differences have to be accounted for in the Requirement Map, and will lead to several paths (options) that can be taken. The CDF is flexible enough to cope with varying customer needs. At the same time the CDF has a level of rigidity so that it can remain efficient.

3.2 Implications for Project Phases

The concurrent approach can be taken past the design phase to encompass manufacturing, verification and testing. The overall philosophy can still apply, and allows for overlapping of the various phases of development and makes sure there is good communication between the specialists involved in these phases. This is depicted in Figure 3-2.

Figure 3-2: Comparison between Conventional and Concurrent Engineering Project Phases

Phase 0 to B could be classed as a single “design” phase, which continues from initial concept to the finished design using the same specialists and tools. There is still a need for reviews and acceptance at different phases of the design, but this could be achieved through “snap shots” of the ongoing process as shown in Figure 3-3. However, this approach may not be suitable directly for the ESA environment.

Time

Phase 0 Phase A Phase B

Phase C/D

Concept Feasibility

Design Production, Verification & Testing

Conventional Sequential

Time

Phase 0 Phase A Phase B

Phase C/D

Concept Feasibility

Design Production, Verification & Testing

Concurrent Engineering

Ops

Ops



Figure 3-3: ESA Project Phases using Concurrent Engineering

The concurrent engineering concept is applied to the organisational philosophy of a given project. The philosophy for design remains in the most part, a separate issue. However, the organisation of a project will have some effect on the design chosen. The CDF environment allows the philosophy of design of different areas of the system to be more consistent at an earlier stage.

3.3 Communication Facilitation

One of the keys to any successful concurrent engineering activity is facilitating quick and simple communication between the team members. This allows for information to flow freely and for problems to be solved quickly. Therefore, it is important that the system allows for the passing of both information and data between participants. The system must also be robust enough to allow participants from external locations to interact in a similar way to internal ones. The CDF does this in the following ways:

3.3.1 INFORMATION SHARING

Direct communication between collocated team members is the primary form of communication for any CDF Study. This form of face-to-face verbal communication allows for the clearest and most robust way of sharing information. However, it is not always possible for all participants of a Study to be in the same room. Therefore the system is capable of using advanced teleconference and videoconference capabilities to simulate this face-to-face interaction.

3.3.2 DATA SHARING

While allowing participants to share qualitative information quickly is important, the ability to pass precise quantitative information between participants is critical to any engineering design. The CDF-IDM has been specifically designed to allow for this. Through its system of workbooks and macros it can pass data accurately and simple between participants and subsystems.

The CDF-IDM is located on servers inside the ESA firewall, but for participants external to the Agency, there are a number of ways for data to be shared with them. There is an external FTP server which allows for the uploading and downloading of files from external sites, and display sharing software, such as Microsoft NetMeeting©, is also used to view presentations and

Design Phase Phase C/D

Concept

Design

Production, Verification & Testing

Single Design Phase Approach

Ops

Reviews and Acceptance



workbooks externally. However, the implementation of the iCDF allows access to a CDF server from the internet, giving the same experience to all participants, no matter their location.



4 THE PROCESS

4.1 Overview

The CDF is operated by the Concurrent Engineering Section (TEC-SYE) of the System, Synthesis and Technologies Department (TEC-S). The Section is in charge of operations (e.g. studies organisation) as well as maintenance and development of the facility, including IT and communication aspects. The operational activities are mostly requested by ESA Projects and Programmes Directorates, but are occasionally also requested by external entities (National Agencies, Industries). These activities are jointly prepared and conducted with the Customer’s participation (generally a Study Manager and/or a Study Scientist).

The preparation phase for these studies includes the gathering and consolidation of the mission requirements and constraints (e.g. for a mission Study) and the Study objectives (incl. manpower quotation). Preparation meetings are attended by the CDF Manager, the Team Leader, the System Engineer and some ad-hoc discipline’s specialists.

The CDF Management is responsible for the interface with the Customer, enrolment of TEC and ESOC specialists, the training and formation of the Study TEAM.

The concurrent process is conducted by a Team Leader (TL), with the support of a System Engineer (SE). However, the Customer is also invited to participate in all sessions.

The Study is organised in bi-weekly, half day sessions with the participation of all disciplines (concurrent approach) needed for the thorough assessment of the mission. For a Study there are between 6 and 10 sessions (i.e. 3-6 weeks). These are initiated with a kick-off (first session) and concluded by an Internal Final Presentation (IFP, last session).

TEC-SYE is in charge of the overall infrastructure, incl. the interdisciplinary / concurrent layer and the HW and SW tools, licenses, data-bases commonly used by more disciplines. The HW/SW for discipline specific purpose is provided by the relevant technical TEC or OPS area and is hosted (or made accessible via) CDF.

The Study is completed by the production of a technical report and a cost estimate report (ESA official series) compiled with the contribution of all technical specialists, under the coordination of a Technical Author. The CDF Management is in charge of the Study product quality assurance.

4.2 Iterations of the Spiral Model

The concurrent design process conforms to the so-called Spiral Model (see Figure 4-1), in that successive iterations by the domain specialists converge to one or more design options to meet the mission requirements. A single iteration of the design is considered to occur when an overall system budget has been achieved. At the beginning of a Study this may just be a definition of initial sub-system mass estimates. But these figures and the mission/design characteristics that produced them must be within the Model workbooks. At the end of all iterations the Model is archived. The version number will then be changed in the working Model for the start of the new iteration



Figure 4-1: The Spiral Model as applied to the CDF

To identify the progress of the Model during an iteration there is also a System Date. This is available within the Model and is incremented during an iteration to identify only when some agreed design status or progress has taken place. It is not updated necessarily on a daily basis.

4.3 Sessions Definitions

One of the concurrent design process’ fundamental elements is represented by different kinds of sessions, with various functions and purposes. In a project development timeframe, therefore, periodic meetings are held, with the total or partial participation of the design team, depending on the needs. The different session and meeting typologies and purposes can be shortly described as follows.

4.3.1 DESIGN SESSIONS

The Design Sessions represent a fundamental element of the concurrent design approach. Led by the Team Leader and with the participation of the whole design team, several scheduled Design Sessions are held in every Study timeframe, with the overall purpose of allowing fast and interactive discussion amongst the team components and the immediate communication of all the relevant sub-system design decisions to the whole team. During the design Sessions, therefore, all the various mission design aspects and, mainly, their numerous interactions, are continuously discussed, with the main aim to identify at the earliest possible stage any design problem or inconsistency. A typical Design Session is based on presentations, by the relevant team members, on the status of the various systems or technical domains design and of the currently achieved

Mission requirements

analysis

Mission analysis

Sub-system

Design verification

Risk assessment

Cost Analysis

The Spiral



results and performance levels, followed by discussion amongst the team to forward the design evolution and refinement. The Design Sessions also envisage the participation of the customer, with the possibility of mission requirements refinement throughout the Study, and of constant evaluation of the Study evolution and of the requirements satisfaction. All the Design Sessions presentations and results, as well as minutes of meetings, are stored for future reference.

4.3.2 WORKING SESSIONS

Working Sessions are then contemplated, to give the team members the possibility to work in detail on their aspect of the mission design or to, for example, develop their workbook capabilities or write their contribution to the required Study reports. They also usually envisage the participation of the entire design team, even though they are sensibly more relaxed, with respect to Design Sessions. Working Sessions can also be used for the discussion of the various technical aspects of the design work within more restricted sub-teams.

4.3.3 PRESENTATION SESSIONS

Presentation Sessions are furthermore foreseen by the concurrent design approach. Presentation Sessions can be used, at the beginning of a Study, by the customer payload engineers and Study manager to explain the mission requirements to the design team or, on the other side, at the end of a Study, by the design team to show the customer the obtained results. Typical examples of Presentation Sessions are represented by the Kick-Off Meeting and by the Mid-Term and Final Presentation Meetings.

4.3.4 OFF-LINE MEETINGS

The so called Off-Line Meetings are represented by meetings occurring off-line from design or working session, involving a reduced team group the and possibly the customer. Although not strictly classed as sessions, they are listed here to highlight their use and usefulness. Most of them take place in the facility, even if this is not strictly required. All the presentations and results of these meetings, as well as their minutes, must be anyway stored as a reference and be presented to the remainder of the design team during a full session.



5 THE TOOLS

5.1 The Facility Infrastructure

5.1.1 PHYSICAL SCHEMATIC

The architectural layout and hardware equipment disposition of the ESTEC Concurrent Design Facility Design Room are sketched in the following Figure 5-1 for a spacecraft Study. Other layouts are selected depending on the specialists and workbooks required. The infrastructure has been developed on the basis of the requirements and demands placed by the other CDF key elements, namely the Design Team, the Sessions and the System Model.

Figure 5-1: The ESA/ESTEC Concurrent Design Facility Layout

5.1.2 HARDWARE DESCRIPTION

The CDF uses a server-orientated architecture which allows for all participants to have the same desktop experience anywhere through a terminal server. The participant can log into the CDF Server Farm through the Citirix MetaFrame XP application from any workstation. The Servers contained within the CDF Server Farm are shown in Figure 5-2. They are configured in this arrangement to allow for complete redundancy, allowing for Sessions and design work to continue through all eventualities.

ESTEC Dh015

TeamLeader

CommsGS & Ops

Mechanisms

Instruments

Risks

CostSystems

PowerDHS

Structure

Thermal

Doc.’n

Simulation

MissionPropulsion

AOCS

MULTIMEDIA WALL

Cus

tom

er a

nd A

d-H

ocEx

pert

s

Custom

er and Ad-H

ocExpertsConfig.

Progr.’s



CDF Server Farm

Terminal Server 1 Terminal Server 2

Published Application Server 1

Published Application Server 2

File Server

Citrix MetaFrameXP Interface

Study Participant

Figure 5-2: The Hardware Topology of the CDF

Inside the CDF there are numerous workstations, as shown in Figure 5-1, which allow for the Study participants to connect to the CDF Server Farm. Alongside these terminals there are 3 modelling workstations which have a direct connection to the CDF Model files and allow intensive 3D domain tools to be used by the appropriate disciplines.

In conjunction with the computer infrastructure there are 3 displays which make-up the Multimedia Wall. There are two large LCD rear projection screens and one SmartBoard© which can display outputs from a number of PCs in the room, as well as other video sources supplied by the Tanderberg Video Conference System.

The Tanderberg Video Conference System controls the multiple displays in the CDF and allows a number of different input sources, which include:

• 2 of the Design Workstations • 2 of the Modelling Workstations • VHS/DVD/TV Input • Visualizer • Video Conference Participants

The Video Conference System allows for up to 5 simultaneous video conference calls as well as numerous audio calls. In conjunction with this there are 9 fixed microphones, 2 mobile microphones



1 ambient microphone, a wide angle camera and 2 directional cameras which allows for the participants to communicate with external sites.

5.1.3 SOFTWARE DESCRIPTION

The software available for participants in the CDF includes the following tools available for all participants:

• Citrix MetaFrameXP • Windows Server 2003 • Microsoft Office 2003 Suite • Microsoft NetMeeting 3.01 • Adobe Acrobat 6.0 • Lotus Notes 6.5 • CDF-IDM

The CDF-IDM is the core piece of software for the CDF and is based on Microsoft Excel 2003 and a series of custom-written XLAs and VBA scripts. The environment on the CDF Servers has been customized to allow for the CDF-IDM to operate properly, and thus the Model performs at its optimum in this environment. The CDF-IDM is explained fully in Chapter 7 of this document.

5.1.4 DOMAIN TOOLS DESCRIPTION

The CDF-IDM and the other tools available for all the participants are extended via a series of domain-specific tools, which include, but are not limited to:

• Adobe Framemaker • AGI STK ver 6 • CATIA ver 7, PATRAN, NASTRAN, SimDesigner • CEDRE, Small Satellite Cost Model, RACE Model, TIW-O, TIW-D, PRICE • EUROSIM • JAQAR Swing-by Calculator • Macromedia MX Suite • Mathsoft MathCAD ver 13 • Mathworks Matlab ver 7 • Matrix X • Orion • Paintshop Pro • PowerCAP • ThermXL



5.2 The Design Team

The design team is one of the most important components of the concurrent design facility. The number of members it is composed of is variable, depending on the Study complexity. Some positions are always present in the team, and some are used for only specific types of studies. The core elements of the design team, as well as of the CDF central team itself, are listed below. A brief overview, not aiming to

represent a complete job description, on the role and the duties of each of the introduced positions is also given. The given structure is, in addition, not completely fixed, and it is therefore also possible to have a single member performing more than one of the described tasks or, on the other side, to have one or more of them split amongst several team members and allocated to various technical domains engineers.

5.2.1 THE CENTRAL TEAM

• CDF Manager: He/she is responsible for the smooth CDF overall running and for the interaction with customers and the CDF external environment. The holder of this position also plans the future utilisation and capabilities improvement and enlargement of the facility itself (e.g. the scheduling of future projects, the analysis of possible applications of concurrent engineering to successive project phases and its implementation), and is responsible for all the administrative work. The CDF Manager, however, should also have a deep knowledge of the system Model, and be able to run design sessions when required, and help in the system engineering aspects of the Study.

• CDF Team Leader: He/she is responsible for the smooth running of the studies, from preliminary set-up to the distribution of the Study final documentation. His/her tasks include the design team composition, together with the customer and the CDF Manager, and, again in accordance with the customer requirements, the definition of the Study and mission requirements and of the Study time frame and accuracy level. During the studies, then, the Team Leader organises and chairs the design sessions, leading and continuously keeping control of the team members’ work, assuring the fastest possible convergence of the mission design with the given requirements. He/she also leads the various internal and external presentations held during the studies, being in charge of the preparation of their introductory and overall mission and system description part, as well of the Study conclusions. Together with the Technical Author, the System Engineer and the Assistant System Engineer, the Team Leader also takes care of the overall consistency of all the Study documentation.



• Technical Author: The holder of this position works closely with the Team Leader, the customer and the System Engineer throughout the whole Study duration. During the studies, the Technical Author’s tasks include the possibly most accurate recording of the design sessions discussions and results (possibly through minutes), and the production and editing of all the final Study documentation (e.g. the technical and cost reports, the Study final presentation, etc.), starting from the various sub-systems and technical domains contributions. He/she also takes care of the production and editing of all the technical documentation related to the CDF itself and its utilisation as, for example, the various technical domain workbooks user’s manuals, the CDF user’s manual, etc.

• System Engineer: In the Study timeframe, in strict relationship with the Study Team Leader, the CDF System Engineer conducts the majority of the mission design system engineering work. The holder of this post is, however, also capable of running design sessions together or without the Team Leader and is continuously organising the other team members’ work, to keep the various mission design aspects on track and to, therefore, ensure the rapid convergence and consistency of the overall project. He/she is also responsible, together with the Assistant System Engineer, for the continuous and correct update of the design information contained in the CDF Model. The System Engineer’s tasks also include the preparation, again in collaboration with the Assistant System Engineer, of all the system level description components of the various Study documents.

• Assistant System Engineer: The Assistant System Engineer’s role during the studies is in conjunction with the System Engineer’s one. He/she is in fact responsible for the complete Model smooth functioning, for the Model’s system aspects and for the proper integration and update of the design data flow between the various team components. The production and collection of system level design data from the various system Model elements, and their proper utilisation for the production of system level analyses is, in addition, part of the Assistant System Engineer’s duties, as well as the collaboration in the production and editing of the system description contribution to the Study documentation.

• Payload Engineer: The CDF Payload Engineer is responsible for all the payload related aspects of a Study, including the definition of the payload requirements and interfaces, together with the customer too, as well as their refinement, in the Study ongoing. He/she acts in fact as an interface between the Study customer Principle Investigators team and the CDF design team.



• Mission Analyst: The CDF Mission Analyst works together with the customer, the Team Leader, the System Engineer and the Assistant System Engineer, since the preliminary set-up phase of a Study, to the definition and refinement of mission requirements and to the development of a mission profile, taking into account both mission objectives, in accordance with the customer requirements, and design constraints. Throughout the whole Study, then, he/she is responsible for the refinement and optimisation of the mission profile and for the production and update of design data related to the navigation aspects of all the mission phases (e.g. possible launch options, orbit trajectories, cruise or attitude manoeuvres ∆v’s budgets, etc.).

• Electrical Systems Engineer: The CDF Electrical Systems Engineer is responsible for the electrical systems related aspects of the spacecraft design and for the co-ordination of the design work in the inherent technical domains. The holder of this position is therefore the key decision-maker for this spacecraft design area. This position can be shared between specialist disciplines, e.g. power, data handling and communications (see chapter 5.2.2).

• Mechanical Engineer: The CDF Mechanical Engineer is responsible for the mechanical systems related aspects of the spacecraft design and for the co-ordination of the design work in the inherent technical domains. The holder of this position is therefore the key decision-maker for this spacecraft design area. This position can be shared between specialist disciplines, e.g. structures, thermal and mechanisms (see chapter 5.2.2).

• Operations Engineer: The CDF Operations Engineer is responsible for the consistency of spacecraft operations, with respect to spacecraft design and Ground Systems.

• Cost Analyst: The holder of this position is responsible for the production of preliminary design industrial cost estimates and for the provision of a cost guided approach to the overall system design throughout a Study.

• Risk Analyst: The holder of this position is responsible for the production of preliminary design and operation risk estimates and for the provision of a risk guided approach to the overall system design throughout a Study, with the aim of a reduction of mission failure risk.

• CAD Expert: The holder of this position is responsible for the CAD related aspects of the spacecraft design, throughout the Study timeframe. With the production of 3D spacecraft configuration drawings, he/she allows the visualisation of the ongoing design,



helping therefore the discussion amongst the team members and the early highlighting of design architectural inconsistencies.

5.2.2 OTHER MEMBERS

The complete design of a space mission and of a spacecraft system obviously requires the active participation of several additional team members to the design process. Many technical domains are, in fact, taken into consideration and analysed during every Study, although the specific knowledge requirements may change from Study to Study and the total number of covered positions and, therefore of design team members, is consequently variable on a case by case basis. The list below, however, indicates the technical domains usually part of a Study team composition:

• AOCS / GNC • Propulsion • On-Board Data Handling • Simulation • Ground Systems / Operations • Structures • Mechanisms • Telecommunications • Electrical Power • Thermal Control • Programmatics • Risk

Additional design areas and technical domains may be taken into consideration and analysed during different studies, depending on the specific needs of the project. Some examples can be represented by environmental and radiation analysis, or by the presence in the team composition of an optical or an antenna design engineer. For special applications as, for example, instrument design exercises, a strongly different design team composition can then be envisaged.

5.3 Administration

A certain degree of administration is required to allow the whole Concurrent Design Facility, the Design Team, the Sessions and the Model to run smoothly. Many different tasks are in fact required to allow the facility to keep up and running properly. This administrative aspect of the CDF can either be separated from its other elements or treated in an integrated way. However, there is a strong requirement for documentation by both the CDF and the project being studied.

5.3.1 STUDY ADMINISTRATION

The running of a project within the concurrent design facility and the successful completion of a Study also require a certain amount of administrative work as, for example, the setting of the design team, the scheduling and organisation of sessions and meetings, the distribution and collection of the Study information, etc. Some general purpose software tools, already included in the ESA infrastructure standard software library, are also used, with this aim, by all team members. The main ones are listed in Table 5-1.



FUNCTION TOOLS USED

Documentation Storage and Archiving Microsoft Windows Server 2003®

Electronic Communication Lotus Notes® mail

System Modelling Microsoft Excel®

Study Presentations Microsoft PowerPoint®

Study documentation Microsoft Word®

Table 5-1: The Primary Tools Used in the Administration of CDF Studies

5.3.2 FACILITY ADMINISTRATION

The CDF administration work, as in everything required to keep the facility up and running, is kept separate from the previously mentioned Study administration. All the infrastructure tasks required to support a Study completion are however included in this definition, as well as the facility management, organisation and development work. The facility IT equipment management, the constant upgrade of the facility hardware, the acquisition, implementation and integration of more recent software tools, the continuous update of the facility server software environment and the integration of new software tools in the system Model are some examples of this kind of work.



6 THE PRODUCTS

The great deal of qualitative and quantitative information related to the large amount of technical design data produced in a Study timeframe must be properly documented and stored. At the completion of a Study, comprehensive presentations and handouts are produced and distributed to all the Study participants and the customer team. Technical reports/documents are furthermore created, with a standard formatting and authoring, at the end of the Study period, as well as detailed final reports shortly after the end of the Study. For each performed Study, then, the CDF customer has the possibility to choose the composition of the Study products set, the type and definition level of the required technical report, etc. The usual CDF Technical Assessment Study Documentation Set, for example, includes a Final Presentation, a Technical Report, an Internal Industrial Cost Report (with a restricted distribution) and a Mission Simulation movie. The CDF Assessment Study Reports completed to date are shown on the CDF home page www.esa.int/cdf. Sequential references will then be allocated at completion of additional assessment studies. Technical feasibility studies, at a lower definition level, as well as technical reviews of industrial or external Phase A studies and different types of technical analyses have furthermore, been performed also shown on the CDF home page. Different Technical Documentation sets, matching, on a case by case basis, the customer’s requests, have then been produced for these works. Each kind of report is based on a standard template available, to improve the compilation process speed and to minimise the production effort, to all the design team members for their inputs contribution.

This information is given in three formats, the Final Model, the Presentations, and the Study Reports, which are all described below:

6.1 Final Model

The CDF Integrated Design Model represents the principal Study related information repository. In the Model, all the relevant design parameters from each of the technical domains are stored, as well as many spacecraft, system and sub-system configuration and architecture qualitative design information such as, for example, design options, assumptions and drivers.

6.2 Presentations

All important communications amongst the team members are recorded and stored too. The storage of this design information is done through proper archiving of all the documents, presentations, e-mails, etc., used and shown in the Study timeframe. This gives each team member the possibility to easily keep track of the evolution of the design of the mission, of the overall spacecraft system and of the various sub-system, as well as of the various sub-system design approach aspects affecting the overall mission and spacecraft design.

At the end of the Study, the presentations given as part of the final Session (usually the Internal Final Presentation) are prepared as a published documents, provided as an official output of the Study.

http://www.esa.int/cdf



6.3 Study Reports

At the end of each Study a report is then published, with a standard format and template, according to the analysed technical domains and the Study depth. The detailed report contents and definition level are however, agreed, on a case by case basis, between the customer and the CDF management. These reports will usually include a Final Report and a Final Cost Report, however this may be varied or extended depending on a number of circumstances.

6.4 CDF’s Distribution Policy

REPORT DISTRIBUTION POLICY The policy of CDF regarding the reports is based on the following rules: 1) the report is property of the Customer, represented by the Study Manager, hence any

distribution of it and/or part of it has to be requested to and authorised by him/her, as stated on page 4 of each CDF report.

2) CDF is the repository of the further copies (paper, pdf file) of the report and, depending on availability, can supply them on specific instruction of the Customer.

3) in case some subpart/extract (text and/or graphics) of the report is used separately and independently from the report, then we require to clearly mention the reference source (e.g. ESA CDF report #xx (A) + the relevant chapter/page).

4) no distorsion/manipulation/omission of the information from the report’s context is permitted.

5) in case of use of the report (or parts of) in/for official presentations (conferences, etc.) and/or publications (media) the CDF must be informed for our own record.

Note that generally the reports produced in the CDF are used: 1) to provide inputs to the decision making process as to whether the mission will become a

project at industrial level 2) in the case of an industrial activity being initiated, for example at Phase A, the report

becomes part of the input specifications. For both of these reasons there is normally a restriction to avoid “premature” distribution of the report externally to ESA, or even the Study team.



7 INTEGRATED DESIGN MODEL

7.1 Description

The MS Excel® software tool is based on three different working area levels. The lowest is represented by the “Worksheet”. One or more worksheets can then be stored within a “Workbook”, the second working level, represented by a saveable file. Furthermore, in the MS Excel® environment, several workbooks (files) can be opened at the same time, to form a so-called “Workspace”, the third and uppermost working level.

The actual CDF Model is simply based on several MS Excel® workbooks, originated by the fragmentation of the original MMS IDM single workbook and the creation of different separate files from its technical domains worksheets. The data interchange between the various workbooks of the Model is then provided by standard MS Excel® links, as will be better explained in the following. In order to keep control of the data flow amongst the various Model components, the various technical domain workbooks are not, however, directly linked to each other. For each performed Study, instead, from each workbook the link path is directed to a central data repository. This is represented by an additional MS Excel® workbook, called “Data Exchange”, containing the most updated version of the shareable data and linked, in turn, to all the technical domain workbooks. The various technical domain workbooks can be then linked, directly or via a manual data interchange, to external software tools. A schematic representation of the CDF Model is given in Figure 7-1.

Figure 7-1: Overall CDF Model Representation

Data Exchange

External Tool

Domain

MS Excel® Workbooks



7.2 Structure of Design Model

The three-tiered set of data which makes up the Overall CDF Model is stored on the CDF Server Farm (see Chapter 5.1.2 for more information). The data stored on the server for a Study is broken down in a structure to allow for the filing and storage of the different data-types. The structure is shown in Figure 7-2.

CDF Study

Background Information

General Notes

Admin Information

Presnetations

Meeting History

Report

Information Models

Element 1

Element 2

System Information

Model 2Model 1

Figure 7-2: The Data Structure for a CDF Study

The CDF-IDM makes up the Models in this schematic. Thus, the design data is stored within the Models. There is usually one Model per Study, but there can be more. Inside each Model there are multiple Elements, and the data is stored in the Elements according to the structure outlined in Figure 7-3.



Subsystem 1

Subsystem 2

Element Information

Instrument Subsystem

Unit 1 Unit 2Subsystem Information

Instrument 1 Instrument 2Instrument Totals

Instrument 1 Unit 1

Instrument 1 Unit 2

Instrument 1 Totals

Propellant Info

Element 1 Element 2 Element n

Figure 7-3: The Data Structure of an Element

The data within an Element is broken down into Element Information, Propellant Information, multiple Subsystems and an Instrument Subsystem. Inside each of the Subsystems there is overall information and multiple Units. However, inside the Instrument Subsystems there are Instrument-level Elements which have their own details and their own Instrument Units. The data stored within Units is shown in Figure 7-4.



Figure 7-4: The Structure of a Unit

Inside a Unit there is detailed information about mass, structural properties, power usage, costs and risks. This is where the detailed information of the Model is input on the subsystem level. The information contained within these Units is then shared between subsystems and collected together to form overall information about the Elements and the System for the Model. For example, the power usage per-mode input by all of the subsystems for each of their Units is combined together in



the Electrical Power Subsystem to form the power budget and size the power system for the spacecraft.

7.3 Model Segments

As a general rule, the CDF Model consists of the technical domain workbooks listed below. It is anyway not required to always use the complete Model, as a whole. The actual utilisation of the various workbooks for each Study, and their number, in fact, depend on the effective need of the current project to analyse a certain mission aspect.

7.3.1 DATA EXCHANGE

The central workbook to the CDF-IDM is the Data Exchange. It is a central and dynamical data storage point during the studies that is shared between any and all disciplines. This workbook is a complete collection of all the data contained in the output worksheets of all the workbooks a Study Model is made of. On the other hand, the inputs worksheets of all the Model workbooks are, for the update procedure of their input data, linked to the Data Exchange workbook.

7.3.2 SYSTEM WORKBOOK

The System workbook is also contained in the CDF Model. Its content primarily consists in summary information, at a system level, on the various aspects of the mission and the spacecraft design, or in general information as, for example, the definition of the S/C Modes of Operation, required by most of the technical domains. A general overview of the satellite mission design can be therefore obtained with the help of the limited number of worksheets contained in the System workbook. It also provides the Study system engineer and the team leader with the possibility to easily follow the design data flow and the Study progress. A complete administration worksheet, listing for example modifications to the CDF Model occurring during the studies, is furthermore contained in this workbook.

7.3.3 IDM WORKBOOKS

7.3.3.1 Principle Technical Domains

The essential workbooks for spacecraft sub-systems design, as well as their main purpose and utilisation field, are listed below:

1. Mission Analysis Mission operational orbit definition, mission orbital and navigation phases definition, trajectories and manoeuvres characterisation.

2. AOCS Attitude and Orbit Control System design, mass and power budgets assessment.

3. Data Handling On-board data handling system design, mass, power, memory and computational resources budgets assessment.



4. Power Power generation, distribution and storage sub-systems design, system mass and power budgets assessment, S/C power and dissipation budgets assessment.

5. Propulsion Propulsion system design, mass and power budgets assessment.

6. Structures Structures design and dimensioning, spacecraft configuration assessment.

7. Thermal Thermal control system modelling and design, mass and power budgets assessment.

8. Telecommunications Telecommunications system design link budget and resources assessment.

9. Instruments Payload requirements and interface assessment and definition.

10. Ground Systems Mission operations assessment and ground segment infrastructure design.

7.3.3.2 Other Domains

More specific areas of mission Study and spacecraft design have also been included in the Model, with the introduction of the following additional, specialised, workbooks:

1. Aerothermodynamics Design of geometry and analysis of trajectories in atmospheric flight and any other regimes where aerothermodynamics is relevant.

2. Mechanisms On-board mechanisms and mechanical devices architecture design, mass and power budgets assessment.

3. Pyrotechnics Pyrotechnic devices requirements definition, safety related aspects analysis and resources assessment.

4. Radiation Mission environmental and radiation aspects analysis.

The following additional workbooks, introducing the possibility of analysis of further aspects of a space mission already in the early Study phases, have also been included in the CDF Model:

1. Programmatics Overall programme schedule assessment, preliminary spacecraft AIV schedule and assessment.

2. Risk Preliminary risk assessment.

3. Simulation Mission phases modelling and visualisation.

A separate cost estimate (“Cost”) workbook is furthermore part of the CDF Model. For security and confidentiality reasons, however, it only contains the results of the overall mission industrial cost estimate, performed with the help of workbooks and different software tools not part of the CDF Model.



7.3.4 IDAM WORKBOOKS

Detailed Instrument Design Activity (IDA) tasks require specialist workbooks. Some example workbooks are shown below in Table 7-1, these change depending on the detail required and type of instrument, e.g. front-end and back-end electronics including spectrometers and filters may require specialist attention.

Workbook Name Function

Instrument Systems Resource budgets (mass, power, data), science compliance. Wave Interaction Electromagnetics simulation of target RF & DH Systems Electrical systems resources, RF analysis and simulation Antenna Antenna characteristics database, analysis Radiometry Signal Noise Ratio and Noise equivalent temperature curves Optics Geometry and configuration analysis, ray tracing for optics design Structure/Configuration Instrument mechanical analysis, configuration, interfaces and design Mechanisms Instrument mechanical analysis and design Thermal Instrument thermal analysis and design Cost Instrument costing (parametric modelling) Risk Instrument programmatic and mission risk assessment Programmatics Instrument AIV and project schedule

Table 7-1: Example Instrument IDM Workbooks

7.3.5 ISS & HUMAN MISSION WORKBOOKS

Specific workbooks may be required for International Space Station (ISS) and human missions activities as follows:

• Derivation of technical and assessment of science requirements for ISS payload accommodation in payload racks require the application of a Requirements Comparison Tool.

• ISS external payloads accommodation requires the addition of a robotics simulation workbook. • Human missions require the addition of an Environmental Control and Life Support System

(ECLSS) workbook.

7.4 Versions

7.4.1 DESCRIPTION OF VERSION NUMBERS

To achieve the management a Model version strategy is used. When appropriate entire versions of the Model (i.e. all the workbooks) are archived. A numbering system has been set out to deal with this process. The Model Version Number consists of three digits: for example, 1.14

• First Digit (1.14) The initial digit is used to signify an ISSUE of the Model. An ISSUE is created when a final version of the Model is required, e.g. at the end of a Study. Further issues may be created if further work is done on the mission/design at a later date.



• Second Digit (1.14) This digit is used to signify the MAJOR DESIGN OPTION under Study. System level options to be studied are given a specific number to identify them. These options are normally those design choices that fundamentally affect the entire design (and Model), such as a change in mission characteristics, or a major configuration change. These numbers can be allocated at the beginning of a design, or at anytime during the Study.

• Third Digit (1.14) This digit shows the iterations of the design that have been completed (explained below). This is the most important number to be considered during the design process. Domain specialists can use this information to check that their input information is up-to-date with the rest of the Model. The digit is increased at the beginning of that iteration and distributed through the Model. By the end of an iteration all workbooks will have been updated.

7.4.2 IMPLEMENTATION IN THE MODEL

The Version Number of the Model and the System Date are stored and updated within the Systems workbook, within its Admin sheet. The System engineer maintains this information and updates it when appropriate. There is a table within this sheet to describe the significance of each version of the Model.

From the Admin sheet the Version and Date will be distributed throughout the Model via the Systems Output sheet and the Data Exchange. Each domain workbook must link to this data, and keep it up-to-date. A user form will appear whenever a domain workbook is opened (except systems) to show whether the workbook needs to be updated. For every version a note is added to the table within the Admin sheet to explain the significance of the version.

Each archived version of the Model is stored in the MASTER directory, under the specific Study folder. Within this Study folder, there is another folder call “model versions” which contains all the Models.

Details on the specifics of this implementation and its use can be found in the CDF User Manual [1].



8 THE RESULT

8.1 Integration of CDF Elements

It is important to look at the integration of the various elements of the CDF to reduce any overlapping of work, and to therefore make the facility more efficient. Looking at each element separately could lead to work being completed a number of times in different ways. A consistent approach will help to reduce workload and introduce harmony between the design and the infrastructure behind the design.

The design process must be the first consideration when developing the integration between CDF elements. The Team is the key element to a successful design, and shall be supported by the other elements of the facility. To work concurrently the Team works and communicates within the Sessions, which are organised in such a way as to make this job as efficient and easy as possible. Concurrent design is a model driven approach, and the Model supports the Team’s work. However, the Team also works on the development of the Model, which in turn provides benefit to their design work.

The Model is used in the Sessions for real-time answers and calculations, and used to present information to the group assembled. Each workbook of the Model is used in this way, and has been developed so that information can be presented (via workstations or projector) to the team. The Model also allows information to flow between workbooks in quasi-real-time, so that data flow can occur during Sessions. This allows design iterations to take place within a Session. The Model is therefore used as the basis for much of the discussion within the Sessions. In this way less work is required, because preparing for Sessions and developing the Model are almost one and the same thing.

The Infrastructure has been developed to support this Model-Session approach, allowing the Model to be used by each Team member during the Session. It also allows individual workbooks and other software tools, to be communicated (presented) to the Team. It is possible to have 100% of the MS Excel® Model open at the same time in the facility, during a Session. Other software design tools can also be used during a Session. Out of these tools, one can use and display the CAD system Model during any point during a Session, or any other meeting. During Sessions the infrastructure of the CDF also allows for communications to take place with specialist outside of the facility (e.g. through video conferencing). The CDF Infrastructure provides all equipment needed to run the Session, the Model, the Administration and Documentation.

The administration and documentation for the facility has been developed in an integrated way. The administration of the facility is mainly be the work of a select group of the Team. They keep the facility workable and organise its development. The administration has been developed to serve the design process through the Sessions and general running of the facility. The documentation will be completed to serve the Customer and Team. Where possible the Model is used in the creation of both user guides and technical design reports. The Sessions are also used to some extent for the completion of documentation and administration. The creation of design documents, such as minutes and design reports are integrated with the creation of the Model. Transferring packets of



information directly from the Model to documents helps to reduce the overall effort required from the Team to complete a Study. Thus, the CDF reduces duplication of work wherever possible.

This integration of the CDF infrastructure is shown schematically in Figure 8-1.

Updates to Infrastructure

Figure 8-1: Integration of the CDF Major Elements

8.2 Facility Documentation

A large amount of clear and continuously updated documentation is also needed for the proper utilisation of the CDF and for recording the various aspects of its continuous development. Different document types are anyway necessary for the newcomer team members, for the customer and the general user of the facility, for the potential customer, and for PR and other purposes. User manuals are therefore available, or in preparation, for example, for the various technical domain workbooks, as well as for the general system Model, discussing the various features they contain, their software implementation, their utilisation and listing the workbooks’ capabilities. Other



documents and user guides are then available to explain different facility utilisation aspects, as well as to introduce the user to the CDF hardware and software environment and to a proper use of its capabilities. This document, in addition, briefly introduces the general user to the concurrent design approach and to some of the aspects of its application to the ESTEC CDF. The facility documentation work is carried on, in a consistent and co-ordinated way, by the relevant team members, as previously introduced. A complete documentation archive, including a references library and all the completed Study reports is available for the CDF studies.

The complete CDF facility documentation list is shown is provided in the CDF Document Register database. (Note: this is stored on the CDF Server on the Master drive at M:\0_CDF_Documentation\CDF document register.mdb )

The CDF configuration management and control process conforms to ESA standards as defined in ECSS-M-40.



9 REFERENCES

[1] CDF User Manual, CDF-UM-001, Issue 3, Rev 0.



10 ACRONYMS

Acronym Definition

ACS Attitude (and Orbit) Control System

ADM Administration

CDF Concurrent Design Facility

ESA European Space Agency

ESTEC European Space Technical and Engineering Centre

IDA Instrument Design Activity

IDAM Instrument Design Activity Model

IDM Integrated Design Model

ISM Integrated System Model

MMS Matra Marconi Space

PR Procedure

PRC Procedure

REV Revision

CDF System Description Rev 2 - European Space...

Documents

Transcript of CDF System Description Rev 2 - European Space...