OPS-G Forum An Appraisal of Ground Segment & Operations Standards for ESOC Michael Jones and Mario Merri OPS-GD

Roadmap Introduction (MJ) ECSS – Organisation and Standards (MJ) CCSDS – Organisation and Standards (MM) Standardisation in ESA – ESB (MM) Standardisation in D/OPS (MM) Conclusions (MJ)

Introduction (MJ)

ECSS – Organisation and Standards (MJ)

CCSDS – Organisation and Standards (MM)

Standardisation in ESA – ESB (MM)

Standardisation in D/OPS (MM)

Conclusions (MJ)

Why do we need Standards? Standards make the development, manufacturing and supply of products and services more efficient, safer and cheaper Standards facilitate smooth and fair trading between organisations Standards aid in the transfer of knowledge and enhance the engineering capabilities of smaller or developing organisations Standards assist in the education of today’s and future engineers conformance to standards avoids "reinventing the wheel" Standards have an important role in enabling European industry to remain competitive in the marketplace and to conquer new markets

Standards make the development, manufacturing and supply of products and services more efficient, safer and cheaper

Standards facilitate smooth and fair trading between organisations

Standards aid in the transfer of knowledge and enhance the engineering capabilities of smaller or developing organisations

Standards assist in the education of today’s and future engineers

conformance to standards avoids "reinventing the wheel"

Standards have an important role in enabling European industry to remain competitive in the marketplace and to conquer new markets

What is ECSS? HISTORY: Established in1993, superseding ESA’s role in producing the Procedures, Standards and Specifications (PSS) series COMPOSITION : ESA, National Space Agencies and European Space Industry (represented via Eurospace) OBJECTIVE : To build a complete system of European standards elaborated on a consensual basis by the different partners for the benefit of the whole European space community ACHIEVEMENT: More than 100 standards have been published since 1996 covering Management, Quality and Engineering WEB: www.ecss.nl

HISTORY:

Established in1993, superseding ESA’s role in producing the Procedures, Standards and Specifications (PSS) series

COMPOSITION :

ESA, National Space Agencies and European Space Industry (represented via Eurospace)

OBJECTIVE :

To build a complete system of European standards elaborated on a consensual basis by the different partners for the benefit of the whole European space community

ACHIEVEMENT:

More than 100 standards have been published since 1996 covering Management, Quality and Engineering

WEB:

www.ecss.nl

The ECSS Standards Tree ECSS-E-10 System engineering ECSS-E-20 Electrical and electronic ECSS-E-30 Mechanical ECSS-E-40 Software ECSS-E-50 Communications ECSS-E-60 Space engineering control ECSS-E-70 Ground systems and operations ECSS-E-00 Policy and principles Level 3 Engineering standards ECSS-S-00 ECSS System: Description and implementation ECSS-P-001 Glossary of terms Space engineering Level 1 Level 2 Level 3 Level 0 ECSS-Q-20 Quality assurance ECSS-Q-30 Dependability ECSS-Q-40 Safety ECSS-Q-60 EEE Components ECSS-Q-70 Materials, mechanical parts and processes ECSS-Q-80 Software product assurance Level 3 Product assurance standards Space product assurance ECSS-Q-00 Policy and principles ECSS-M-00 Policy and principles ECSS-M-10 Project breakdown structure ECSS-M-20 Project organisation ECSS-M-30 Project phasing and planning ECSS-M-40 Configuration management ECSS-M-50 Information/document management ECSS-M-60 Cost and schedule management ECSS-M-70 Integrated logistic support Level 3 Management standards Space project management

ECSS: Recent Organisational Developments BACKGROUND In late 2005 it was recognized by ECSS Steering board that The maturity of the published standards set was increasing  maintenance required, not all the published material was completely suitable for direct use in business agreements CONSEQUENCES To address this, the ECSS Steering board decided appointed two Task Forces: Task Force #1 - Organization of ECSS, and Task Force #2 - ECSS Content

BACKGROUND

In late 2005 it was recognized by ECSS Steering board that

The maturity of the published standards set was increasing  maintenance required,

not all the published material was completely suitable for direct use in business agreements

CONSEQUENCES

To address this, the ECSS Steering board decided appointed two Task Forces:

Task Force #1 - Organization of ECSS, and

Task Force #2 - ECSS Content

ECSS Task Force #1: The Results Task Force #1 remit: To assess the current ECSS organization in view of a transition to a phase with the main weight on maintaining the set of standards from this, to propose a new ECSS organization for SB approval TF #1 produced 10 recommendations. A central one was recommendation #4 “ To establish a Technical Authority (TA) as the main technical approval authority for all changes to existing ECSS standards and the release of new ECSS standards. The process of evaluating and implementing changes to existing documents and to endorse new documents will be covered by this single forum providing the technical advisory and approval function of standards within the ECSS organization TA is composed of Delegates who are not ad personam, they represent their organization and have a mandate to vote on behalf of the member organization”

Task Force #1 remit:

To assess the current ECSS organization in view of a transition to a phase with the main weight on maintaining the set of standards

from this, to propose a new ECSS organization for SB approval

TF #1 produced 10 recommendations.

A central one was recommendation #4

“ To establish a Technical Authority (TA) as the main technical approval authority for all changes to existing ECSS standards and the release of new ECSS standards.

The process of evaluating and implementing changes to existing documents and to endorse new documents will be covered by this single forum providing the technical advisory and approval function of standards within the ECSS organization

TA is composed of Delegates who are not ad personam, they represent their organization and have a mandate to vote on behalf of the member organization”

New ECSS Organization ex TF #1 The previous organization had three panels at the level of the Technical Authority For a smooth transition, these panels still exist and are attached (as consultative bodies) to the TA. Phase-out criteria will be defined by TA and endorsed by SB Steering Board Working Group Executive Secretariat Technical Authority Working Group Network of experts Working Group Working Group

The previous organization had three panels at the level of the Technical Authority

For a smooth transition, these panels still exist and are attached (as consultative bodies) to the TA.

Phase-out criteria will be defined by TA and endorsed by SB

ECSS Task Force #2: The Results The "ECSS Content Task force" had the tasks of: Examining the quality of the standards documents Determining the adequacy of the agreed Work Plan completing a "Minimum set of Standards" suitable for user in business agreements for all types of Space projects. General Observations of TF#2: The Management Standards are mature The Quality branch is widely used in space projects and mature, but Some of the standards need improvement 10 documents are “mixtures” of standards and handbook material The Safety standard should be replaced by an equivalent ISO standard Engineering Branch presents more problems to the user community than the Management or Quality branches: Not all directly usable in business agreements, especially for “mixture” documents In some cases, tailoring is essential but non-trivial. As such TF#2 recommended that standard should require only minimal tailoring

The "ECSS Content Task force" had the tasks of:

Examining the quality of the standards documents

Determining the adequacy of the agreed Work Plan completing a "Minimum set of Standards" suitable for user in business agreements for all types of Space projects.

General Observations of TF#2:

The Management Standards are mature

The Quality branch is widely used in space projects and mature, but

Some of the standards need improvement

10 documents are “mixtures” of standards and handbook material

The Safety standard should be replaced by an equivalent ISO standard

Engineering Branch presents more problems to the user community than the Management or Quality branches:

Not all directly usable in business agreements, especially for “mixture” documents

In some cases, tailoring is essential but non-trivial. As such TF#2 recommended that standard should require only minimal tailoring

The E-40 Branch: Software Engineering Software Engineering ( presented in OPS-G Forum on 20 Jan 2006) ESOC approach is based on the use of a tailored version of the ECSS standards (SETG) ECSS-E-40 strongly criticised by TF#2 as “ too general to be directly applied to common categories of space related software. ” TF#2 also required “ A normative applicability matrix to be added to define which quality requirement is applicable for software of which criticality class.” The TF2 detailed recommendations are being discussed by BSSC with a approach along the following lines: Provide a pre-tailoring of E-40 per criticality level in a new E-40 version E-040C Give more precision on testing requirements (e.g. test coverage) Give more precision on the incremental life-cycle model ESOC’s SETG can be updated to E-40C referring to Points 2 and 4 seem to have come from space segment users: Dealing with point (3) must be considered carefully by ESOC Inappropriate choice of criticality levels could push up costs significantly Simulator Model Portability 2

Software Engineering ( presented in OPS-G Forum on 20 Jan 2006)

ESOC approach is based on the use of a tailored version of the ECSS standards (SETG)

ECSS-E-40 strongly criticised by TF#2 as “ too general to be directly applied to common categories of space related software. ”

TF#2 also required “ A normative applicability matrix to be added to define which quality requirement is applicable for software of which criticality class.”

The TF2 detailed recommendations are being discussed by BSSC with a approach along the following lines:

Provide a pre-tailoring of E-40 per criticality level in a new E-40 version E-040C

Give more precision on testing requirements (e.g. test coverage)

Give more precision on the incremental life-cycle model

ESOC’s SETG can be updated to E-40C referring to

Points 2 and 4 seem to have come from space segment users:

Dealing with point (3) must be considered carefully by ESOC

Inappropriate choice of criticality levels could push up costs significantly

Simulator Model Portability 2

The E-50 Branch: Communications TF2 recommended that “ ECSS produce a set of ECSS communications documents for procurement of European Space Systems. These ECSS documents should be made consistent with the relevant CCSDS documents and may call them up as written where appropriate.” TF2 noted that 3 published standards are suitable and that 5 more in various stages of preparation (including ECSS-50-03A Telemetry, ECSS-E-30-04A Telecommand) need to be completed and published urgently (1) Implies that rewriting of CCSDS documents will be avoided

TF2 recommended that “ ECSS produce a set of ECSS communications documents for procurement of European Space Systems. These ECSS documents should be made consistent with the relevant CCSDS documents and may call them up as written where appropriate.”

TF2 noted that 3 published standards are suitable and that 5 more in various stages of preparation (including ECSS-50-03A Telemetry, ECSS-E-30-04A Telecommand) need to be completed and published urgently

(1) Implies that rewriting of CCSDS documents will be avoided

The E-70 Branch: Ground systems and operations standards TF2 View: TF2 considered that the documents in this branch are good examples of standards Available E-70 Standards: E-70A Ground Systems and Operations Part 1 and Part 2 E-70-11 Space Segment Operability E-70-32 Test and Operations Procedure Language E-70-41 Telemetry and Telecommand Packet Utilization (“PUS”) In Preparation: E-70B – will replace E-70A Part 1 and Part 2 E-70-01 On-board Control Procedures E-70-31 Monitoring and Control Data Definition Other: Space Link Extension (SLE) services are also in this branch. They will probably be incorporated via an adoption notice of the ISO/CCSDS standards

TF2 View:

TF2 considered that the documents in this branch are good examples of standards

Available E-70 Standards:

E-70A Ground Systems and Operations Part 1 and Part 2

E-70-11 Space Segment Operability

E-70-32 Test and Operations Procedure Language

E-70-41 Telemetry and Telecommand Packet Utilization (“PUS”)

In Preparation:

E-70B – will replace E-70A Part 1 and Part 2

E-70-01 On-board Control Procedures

E-70-31 Monitoring and Control Data Definition

Other:

Space Link Extension (SLE) services are also in this branch. They will probably be incorporated via an adoption notice of the ISO/CCSDS standards

E-70B: Scope and Status (1) The Standard has been restructured to clearly separate Ground Segment Engineering and Operations Engineering disciplines (reflecting the fact that there may be different suppliers) The processes for these engineering disciplines are first defined and then the processes are mapped onto the classical development and operation phases (A,B,C,D,E,F) The process names (and associated documentation and reviews) have been aligned with E-10 “System Engineering” wherever possible. In a few appropriate cases, they have been tailored for application to the Ground Segment domain As a departure from the E-70A approach, no reference architecture is assumed for the ground segment. Instead, the generic major functions are identified with no presumption on how they are grouped or distributed Functions are harmonised with the European technology Harmonisation for Ground Software Systems Some detailed requirements of E-70A have been deleted (those addressing the “how” rather than the “what”)

The Standard has been restructured to clearly separate Ground Segment Engineering and Operations Engineering disciplines (reflecting the fact that there may be different suppliers)

The processes for these engineering disciplines are first defined and then the processes are mapped onto the classical development and operation phases (A,B,C,D,E,F)

The process names (and associated documentation and reviews) have been aligned with E-10 “System Engineering” wherever possible. In a few appropriate cases, they have been tailored for application to the Ground Segment domain

As a departure from the E-70A approach, no reference architecture is assumed for the ground segment. Instead, the generic major functions are identified with no presumption on how they are grouped or distributed

Functions are harmonised with the European technology Harmonisation for Ground Software Systems

Some detailed requirements of E-70A have been deleted (those addressing the “how” rather than the “what”)

E-70B Scope and Status (2) The ECSS Task Force 2 identified E-70 Part 2 as being of the nature of a “Handbook”, rather than a “Standard”. Consequently, Part 2 will lapse and will be replaced instead by a set of new “normative” Annexes to E-70B. The current DRDs will be significantly slimmed-down to retain only the essential requirements for document contents (work in progress) A new Ground Segment and Operations document has been identified covering “Customer Furnished Items and Services Requirements (CFISRD)”. The generic requirements to be included in this document will be defined in a new Annex to E-70B (work in progress)

The ECSS Task Force 2 identified E-70 Part 2 as being of the nature of a “Handbook”, rather than a “Standard”. Consequently, Part 2 will lapse and will be replaced instead by a set of new “normative” Annexes to E-70B. The current DRDs will be significantly slimmed-down to retain only the essential requirements for document contents (work in progress)

A new Ground Segment and Operations document has been identified covering “Customer Furnished Items and Services Requirements (CFISRD)”. The generic requirements to be included in this document will be defined in a new Annex to E-70B (work in progress)

E-70-01: Satellite On-board Control Procedures OBJECTIVES To standardise the source language, such that: procedure scripts can be re-used between missions spacecraft engineers can work with a single language To standardise the target language, such that: on-board interpreters can be re-used between missions ground tools can be re-used between missions To standardise the interface between the on-board execution environment and the other on-board systems To standardise the interface with the spacecraft database (on ground) STATUS Currently a working group draft The E-70-01 working group started work in 2005 The standard is expected to be ready for Public Review in mid-2007 and to be published in 2008 SCOPE STATUS

OBJECTIVES

To standardise the source language, such that:

procedure scripts can be re-used between missions

spacecraft engineers can work with a single language

To standardise the target language, such that:

on-board interpreters can be re-used between missions

ground tools can be re-used between missions

To standardise the interface between the on-board execution environment and the other on-board systems

To standardise the interface with the spacecraft database (on ground)

STATUS

Currently a working group draft

The E-70-01 working group started work in 2005

The standard is expected to be ready for Public Review in mid-2007 and to be published in 2008

E-70-31: Monitoring and Control Data Definition OBJECTIVES Specifies the mission-specific data used by ground systems to perform space system integration, testing and mission operations Promotes a life-cycle approach to monitoring and control data from low-level testing to in-flight operations Requirements are defined in terms of “what” data is provided by the supplier to the customer. “How” this data is provided is outside the scope of this standard and may benefit from the CCSDS XTCE work (see later) STATUS Public Review completed in 2005. More than 200 DRRs were received from ECSS partners The E-70-31 working group has processed the DRRs and updated the standard accordingly. The new draft is under final review by the ECSS Engineering Panel SCOPE STATUS

OBJECTIVES

Specifies the mission-specific data used by ground systems to perform space system integration, testing and mission operations

Promotes a life-cycle approach to monitoring and control data from low-level testing to in-flight operations

Requirements are defined in terms of “what” data is provided by the supplier to the customer. “How” this data is provided is outside the scope of this standard and may benefit from the CCSDS XTCE work (see later)

STATUS

Public Review completed in 2005. More than 200 DRRs were received from ECSS partners

The E-70-31 working group has processed the DRRs and updated the standard accordingly. The new draft is under final review by the ECSS Engineering Panel

Roadmap Introduction (MJ) ECSS – Organisation and Standards (MJ) CCSDS – Organisation and Standards (MM) Standardisation in ESA – ESB (MM) Standardisation in D/OPS (MM) Conclusions (MJ)

Introduction (MJ)

ECSS – Organisation and Standards (MJ)

CCSDS – Organisation and Standards (MM)

Standardisation in ESA – ESB (MM)

Standardisation in D/OPS (MM)

Conclusions (MJ)

What is CCSDS? The Consultative Committee for Space Data Systems (CCSDS) formed in 1982 by the major space agencies of the world provides a forum for discussion of common problems in the development and operation of space data systems It is currently composed of 10 member agencies ASI, BNSC, CNES, CSA, DLR, ESA, FSA, INPE, JAXA, NASA 22 observer agencies over 100 industrial associate CCSDS develops Recommendations for data- and information-systems standards to reduce the cost to the various agencies of performing common data functions by eliminating unjustified project-unique design and development, and promote interoperability and cross support among cooperating space agencies to reduce operations costs by sharing facilities

The Consultative Committee for Space Data Systems (CCSDS)

formed in 1982 by the major space agencies of the world

provides a forum for discussion of common problems in the development and operation of space data systems

It is currently composed of

10 member agencies

ASI, BNSC, CNES, CSA, DLR, ESA, FSA, INPE, JAXA, NASA

22 observer agencies

over 100 industrial associate

CCSDS develops Recommendations for data- and information-systems standards to

reduce the cost to the various agencies of performing common data functions by eliminating unjustified project-unique design and development, and

promote interoperability and cross support among cooperating space agencies to reduce operations costs by sharing facilities

CCSDS - Overview and Organisation

CCSDS WGs More general info and docs download: www.ccsds.org More about WGs: public.ccsds.org/sites/cwe/default.aspx ESA member ESA lead

More general info and docs download:

www.ccsds.org

More about WGs:

public.ccsds.org/sites/cwe/default.aspx

CCSDS: Systems Engineering Area (SEA) Security WG Encryption Standard [Q2/07] Authentication Standard [Q2/07] see D. Fischer’s OPS-G forum of 3 rd Nov 06 XML Standards & Guidelines SIG Delta-Differential One-way Ranging (Delta-DOR) Green book in preparation

Security WG

Encryption Standard [Q2/07]

Authentication Standard [Q2/07]

see D. Fischer’s OPS-G forum of 3 rd Nov 06

XML Standards & Guidelines SIG

Delta-Differential One-way Ranging (Delta-DOR)

Green book in preparation

CCSDS: Mission Operations and Information Management Services Area (MOIMS) Data Archive Ingestion WG Standardise archive submission information (e.g. metadata keywords ) Submission Information Package (SIP) [Q3/07] Navigation WG Standardise data content and formats of tracking, attitude, trajectory, and ancillary data: Orbit Data Message (ODM) [available] Attitude Data Message (ADM) [Q2/07] Tracking Data Message (TDM) [Q3/07] XML Navigation Data Message [Q4/07] Information Packaging and Registries WG Standardise information packaging (i.e. how to associate and package data and metadata) XML Formatted Data Unit (XFDU) [Q3/07] Spacecraft Monitoring & Control WG Standardise Mission Operations Services to enable build up M&C systems by use of “plug & play” components, maybe from different Agencies, systems and suppliers Set of SM&C Services [Q4/07] XML Telemetric and Command Exchange (XTCE) [Q2/07]

Data Archive Ingestion WG

Standardise archive submission information (e.g. metadata keywords )

Submission Information Package (SIP) [Q3/07]

Navigation WG

Standardise data content and formats of tracking, attitude, trajectory, and ancillary data:

Orbit Data Message (ODM) [available]

Attitude Data Message (ADM) [Q2/07]

Tracking Data Message (TDM) [Q3/07]

XML Navigation Data Message [Q4/07]

Information Packaging and Registries WG

Standardise information packaging (i.e. how to associate and package data and metadata)

XML Formatted Data Unit (XFDU) [Q3/07]

Spacecraft Monitoring & Control WG

Standardise Mission Operations Services to enable build up M&C systems by use of “plug & play” components, maybe from different Agencies, systems and suppliers

Set of SM&C Services [Q4/07]

XML Telemetric and Command Exchange (XTCE) [Q2/07]

CCSDS: Cross Support Services Area (CSS) Service Management WG Standardise the arranging, scheduling, control, and monitoring of SLE TT&C services Space Link Extension - Service Management - Service Specification [Q2/07] Cross Support Transfer Service WG Standardise the SLE transfer services Return All Frames (RAF) [available] Return Channel Frames (RCF) [available] Return Operational Control Fields (ROCF) [available] Forward CLTU [available] Forward Space Packet (FSP) [available] Use of SLE Transfer Services over TCP/IP [ Q2/07] Specification of APIs for each Transfer Services [ Q2/07]

Service Management WG

Standardise the arranging, scheduling, control, and monitoring of SLE TT&C services

Space Link Extension - Service Management - Service Specification [Q2/07]

Cross Support Transfer Service WG

Standardise the SLE transfer services

Return All Frames (RAF) [available]

Return Channel Frames (RCF) [available]

Return Operational Control Fields (ROCF) [available]

Forward CLTU [available]

Forward Space Packet (FSP) [available]

Use of SLE Transfer Services over TCP/IP [ Q2/07]

Specification of APIs for each Transfer Services [ Q2/07]

CCSDS: Spacecraft Onboard Interface Services Area (SOIS) It defines generic services to simplify the way flight software interacts with flight hardware and permit interoperability and reusability Not relevant to D/OPS as it deals mainly with on-board interfaces

It defines generic services to simplify the way flight software interacts with flight hardware and permit interoperability and reusability

Not relevant to D/OPS as it deals mainly with on-board interfaces

CCSDS: Space Link Services Area (SLS) RF and Modulation WG Standardisation of RF and Modulation in 26 and 32 GHz frequency band [ Q1/09] Space Link Coding and Synchronization WG Standardisation of High Performance Coding Serially Concatenated Convolutional Codes [Q4/07] Digital Video Broadcasting Usage by Space Missions (DBV-S2) [Q4/07] Long Erasure Codes [Q4/07] Data Compression WG Standardisation of highly efficient data compression schemes Lossless Data Compression [available] Image Data Compression [available] Ranging WG Standardisation of ranging for interplanetary missions Pseudo-Noise Ranging [Q3/08]

RF and Modulation WG

Standardisation of RF and Modulation in 26 and 32 GHz frequency band [ Q1/09]

Space Link Coding and Synchronization WG

Standardisation of High Performance Coding

Serially Concatenated Convolutional Codes [Q4/07]

Digital Video Broadcasting Usage by Space Missions (DBV-S2) [Q4/07]

Long Erasure Codes [Q4/07]

Data Compression WG

Standardisation of highly efficient data compression schemes

Lossless Data Compression [available]

Image Data Compression [available]

Ranging WG

Standardisation of ranging for interplanetary missions

Pseudo-Noise Ranging [Q3/08]

CCSDS: Space Internetworking Services Area (SIS) It provides services and protocols to address networked interactions of many forms: between spacecraft and earth-based resources among spacecraft between spacecraft and landed elements, and within heterogeneous spacecraft Not that relevant to D/OPS with the exception of CCSDS File Transfer Protocol [available] Mars communication profile BOF

It provides services and protocols to address networked interactions of many forms:

between spacecraft and earth-based resources

among spacecraft

between spacecraft and landed elements, and

within heterogeneous spacecraft

Not that relevant to D/OPS with the exception of

CCSDS File Transfer Protocol [available]

Mars communication profile BOF

Where and How does ESA Fit? ES B

The ESA Context and D/OPS Focus ESSB ESA Standardisation Steering Board ESSB ESA Standardisation Steering Board PA - CCB PA & Safety Configuration Control Board PA - CCB PA & Safety Configuration Control Board ESB Engineering Standardisation Board ESB Engineering Standardisation Board MSSG Management Standards Steering Group MSSG Management Standards Steering Group DG BSSC Board for Software Standardisation & Control BSSC Board for Software Standardisation & Control MESB Mechanical Eng. Standardisation Board MESB Mechanical Eng. Standardisation Board CESB Control Engineering Standardisation Board CESB Control Engineering Standardisation Board EESB Electrical Engineering Standardisation Board EESB Electrical Engineering Standardisation Board SESB System Engineering Standardisation Board SESB System Engineering Standardisation Board GOSB Ground Systems & Ops Standardisation Board GOSB Ground Systems & Ops Standardisation Board STAB Standards Approval Board for TLM & TLC STAB Standards Approval Board for TLM & TLC ESSB ESA Standardisation Steering Board ESSB ESA Standardisation Steering Board PA - CCB PA & Safety Configuration Control Board PA - CCB PA & Safety Configuration Control Board ESB Engineering Standardisation Board ESB Engineering Standardisation Board MSSG Management Standards Steering Group MSSG Management Standards Steering Group DG BSSC Board for Software Standardisation & Control BSSC Board for Software Standardisation & Control MESB Mechanical Eng. Standardisation Board MESB Mechanical Eng. Standardisation Board CESB Control Engineering Standardisation Board CESB Control Engineering Standardisation Board EESB Electrical Engineering Standardisation Board EESB Electrical Engineering Standardisation Board SESB System Engineering Standardisation Board SESB System Engineering Standardisation Board GOSB Ground Systems & Ops Standardisation Board GOSB Ground Systems & Ops Standardisation Board STAB Standards Approval Board for TLM & TLC STAB Standards Approval Board for TLM & TLC Full D/OPS involvement Partial D/OPS involvement

ESB Workflow Workplan Approval proposals decisions Activities’ Monitor & Control reporting controlling ESB Sub-Board ESA Rep. ECSS/CCSDS WG ESB Sub-Board ESA Rep. ECSS/CCSDS WG Tech. Rep. ESB recommends inclusion of published standards in the “ ESA Approved Standards ” list, which makes their use mandatory for future missions! http://ids2.esa.int:81/ATTACHEMENTS/A132787/index.htm

D/OPS Standardization Framework 1. Interoperable Onboard Interfaces 2. Highly Efficient Communications in Resource-Constrained Environments 3. Mission Operations Services 4. Data Interchange and Archiving Services 5. System Engineering 6. Software Engineering STAB GOSB GOSB SESB BSSC CESB

Safeguarding D/OPS’s Interests Invest in the development of standards that meets the D/OPS strategy objectives: Reduce technical risks in ground segment systems and operations Reduce cost of ground segment systems and operations Establish the baseline for the development of the ESA ground segment infrastructure Allow interoperability within and across organisations Increase competitiveness of ground segment European Industry Maintain the leadership in ground segment systems and operations and avoid insurgence of undesired standards Provide D/OPS with visibility on the status of relevant activities

Invest in the development of standards that meets the D/OPS strategy objectives:

Reduce technical risks in ground segment systems and operations

Reduce cost of ground segment systems and operations

Establish the baseline for the development of the ESA ground segment infrastructure

Allow interoperability within and across organisations

Increase competitiveness of ground segment European Industry

Maintain the leadership in ground segment systems and operations and avoid insurgence of undesired standards

Provide D/OPS with visibility on the status of relevant activities

Approach to D/OPS Standardization Planning Use already in place organisation (ESB) for an ESA-wide-consistent standardization workplan Rely on D/OPS representatives in ESB to assure compliance to D/OPS objectives J.F. Kaufeler, OPS-G, D/OPS member in ESB M. Merri, OPS-GD, ESB Secretary and GOSB chair M. Spada, OPS-GD, co-chair of BSSC D/OPS representative in sub-boards and working groups Document workplan fit to D/OPS objectives in “D/OPS Engineering Standardization Plan and Report” (once per year in Nov) Execution Use already in place organisation (ESB) to monitor and control activities Improve reporting capabilities of: ESB on activities’ status Creation of central ESB DB agreed at last ESB meeting D/OPS on resource utilisation One-to-one correspondence between approved workplan and PFMS Authorisation procedure for Mission Travels and Industrial Costs Reporting to D/OPS on resource utilisation in Appendix of “D/OPS Engineering Standardization Plan and Report” (twice per year in Nov and Jul)

Planning

Use already in place organisation (ESB) for an ESA-wide-consistent standardization workplan

Rely on D/OPS representatives in ESB to assure compliance to D/OPS objectives

J.F. Kaufeler, OPS-G, D/OPS member in ESB

M. Merri, OPS-GD, ESB Secretary and GOSB chair

M. Spada, OPS-GD, co-chair of BSSC

D/OPS representative in sub-boards and working groups

Document workplan fit to D/OPS objectives in “D/OPS Engineering Standardization Plan and Report” (once per year in Nov)

Execution

Use already in place organisation (ESB) to monitor and control activities

Improve reporting capabilities of:

ESB on activities’ status

Creation of central ESB DB agreed at last ESB meeting

D/OPS on resource utilisation

One-to-one correspondence between approved workplan and PFMS

Authorisation procedure for Mission Travels and Industrial Costs

Reporting to D/OPS on resource utilisation in Appendix of “D/OPS Engineering Standardization Plan and Report” (twice per year in Nov and Jul)

Nature of Standardization Work Standardization work is a very particular type of work it has not all the characteristics of a typical project its lifecycle can hardly be paced by a normal Project Management Plan In fact, standardization work is: speculative and experimental in several aspects typically based on “compromise engineering” where a large consensus must be achieved conducted by joining the forces of several organizations, each with very different agendas, different resource level, different interests and different authorities. This implies: More difficult to reach consensus More difficult to manage manpower and industrial cost expenses More difficult to control the schedule and the deliverables often done on a voluntary basis by staff who work on mission/infrastructure projects which naturally take priority

Standardization work is a very particular type of work

it has not all the characteristics of a typical project

its lifecycle can hardly be paced by a normal Project Management Plan

In fact, standardization work is:

speculative and experimental in several aspects

typically based on “compromise engineering” where a large consensus must be achieved

conducted by joining the forces of several organizations, each with very different agendas, different resource level, different interests and different authorities. This implies:

More difficult to reach consensus

More difficult to manage manpower and industrial cost expenses

More difficult to control the schedule and the deliverables

often done on a voluntary basis by staff who work on mission/infrastructure projects which naturally take priority

Another Challenge of International Standardisation

Summary of 2006 Achievements 7 3 STAB 12 1 7 0 1 No. Public Reviews 16 0 9 0 0 No. Documents Published Tot SESB GOSB CESB BSSC

Applicability of D/OPS Standardization to Missions and Infra- structure

Representation (ESA/OPS) ECSS 1/0 ECSS Steering Board 2/0 ECSS Executive 1/0 Engineering Panel 31/4 working group chairs Calzolari (GI), Gomez (GI), Jones (GD), Vassallo (OW) 122/18 members in 61 working groups CCSDS 1/1 ESA representative in CMC (J.F.Kaufeler) 1/1 deputy CESG chair (N. Peccia) 3/1 area directors (6 in total) Peccia (GI) 12/7 working group chairs 3xCalzolari (GI), Doat (GI), Merri (GD), 2xVassallo (OW) 23/10 members in 35 working groups OMG Passive role (observer)

ECSS

1/0 ECSS Steering Board

2/0 ECSS Executive

1/0 Engineering Panel

31/4 working group chairs

Calzolari (GI), Gomez (GI), Jones (GD), Vassallo (OW)

122/18 members in 61 working groups

CCSDS

1/1 ESA representative in CMC (J.F.Kaufeler)

1/1 deputy CESG chair (N. Peccia)

3/1 area directors (6 in total)

Peccia (GI)

12/7 working group chairs

3xCalzolari (GI), Doat (GI), Merri (GD), 2xVassallo (OW)

23/10 members in 35 working groups

OMG

Passive role (observer)

Conclusions ESOC Staff are heavily involved in preparing standards There are mature standards that are applicable to ESOC’s work We have highlighted newer or emerging standards that will be applicable or useful for ESOC A D/OPS standardization plan is now in place Measures are being put in place to allow better monitoring and reporting of standardization activities in ESA

ESOC Staff are heavily involved in preparing standards

There are mature standards that are applicable to ESOC’s work

We have highlighted newer or emerging standards that will be applicable or useful for ESOC

A D/OPS standardization plan is now in place

Measures are being put in place to allow better monitoring and reporting of standardization activities in ESA