The “Knowledge Sharing Challenge” for Partners in European Space Projects Serge Valera European Space Agency

1. The “Knowledge Sharing Challenge” for Partners in European Space Projects Serge Valera European Space Agency

2. The “Knowledge Sharing Challenge” for Partners in European Space Projects Serge Valera - ESA

3. Article 2 of the ESA Convention “To provide for and promote, for exclusively peaceful purposes, cooperation among European states in space research and technology and their space applications.”

4. 19 ESA Member States Norway Finland Sweden Luxembourg Denmark Ireland The Netherlands United Kingdom Germany Belgium Czech Republic France Austria Romania Portugal Switzerland Spain Greece Italy

5. ESA’s presence worldwide EAC (Cologne) ESTEC (Noordwijk) Salmijaervi (Kiruna) Harwell ESOC (Darmstadt) Brussels ESA HQ (Paris) Establishments Redu Toulouse Offices Oberpfaffenhofen Cebreros (Villafranca) Ground stations ESAC (Villanueva de la Cañada) ESRIN (Frascati) Moscow Santa Maria Washington Kourou Maspalomas Houston New Norcia Perth Malargüe

6. ESTEC, Noordwijk, The Netherlands

7. ESTEC, Noordwijk, The Netherlands • Principal responsibilities • Studies, preparation and management of ESA space programmes: • Launchers • Science • Earth observation • Telecommunication • Navigation • Human spaceflight • Deep space exploration • Technical support to ESA project teams, including preparation andcoordination of ESA space technology R&D programme • Product assurance and safety for ESA space programmes • Management of ESTEC Test Centre and coordination with other test centres in Europe • Employs • Approx. 2000 staff

8. Knowledge Sharing: the Problem Space system development partners usually differ from project to project Partners are geographically dispersed Different partners participate at different points in time in the project schedule Mother tongues differ (English and French are ESA’s “official” languages) Legacy/proprietary systems are often deployed Development processes and procedures are standardised but their application and interpretation vary Exchange of Information between partners is frequently misinterpreted

9. Typical ESA Project - EarthCARE Satellite Prime Contractor: Astrium GmbH Cloud Profiling Radar: JAXA Base Platform: Astrium Limited Onboard Computer: RUAG Aerospace Star Tracker: Jena-Optronik GmbH Backscatter Lidar: Astrium-SAS Multispectral Imager: SSTL Broadband Radiometer: SEA Ltd. Launcher Russian Soyuz (Kourou or Baikonour) Zenit (Baikonour) ESA Kiruna Ground Station Flight Operation Segment: ESOC Payload Data Segments: ESRIN JAXA for CPR

10. Knowledge exchange: Towards a solution Standardise the space system development and operation processes and their inputs & outputs European Cooperation for Space Standardisation E CSS • Established in 1993 • Members are European Space Agencies, National Space Agencies and European Industry • Objective is to develop standards that address the “WHAT” of space system development and operation (not the “HOW”) • More than 100 standards have been developed across 3 branches and 19 disciplines • See www.ecss.nl for more details

11. Top-level Customer Supplier Supplier Supplier SSC 1 PSC 1 SSC 2 SSC 2 SSC … SSC … E CSS US 1 ES 1 US 2 ES 2 Customer Customer Customer Equipment Supplier Equipment Supplier Equipment Supplier Unit Supplier Unit Supplier Unit Supplier US... ES... Customer – Supplier Network Usually ESA Business Agreement Specifications Network of Customer-Supplier relationships PC Satellite Prime Contractor Business Agreements PayloadSubcontractor Subsystem Subcontractor Subsystem Subcontractor Payload Subcontractor Payload Subcontractor Subsystem Subcontractor Business Agreements Products and associated information

12. ECSS System Project Management Product Assurance Engineering Project planning and implementation Product assurance management System engineering Configuration and information management Quality assurance Electrical and optical engineering Dependability Cost and schedule management Mechanical engineering Safety Integrated logistic support Software engineering EEE components Risk management Communications Branches E Materials, mechanical parts and processes CSS Control engineering Software product assurance Ground systems and operations Disciplines ECSS Document Architecture

13. E CSS Applying ECSS Standards to a Project • The full set of ECSS documents constitutes the ECSS Universe of Discourse (UoD) • A space project “tailors” the ECSS standards to create its ProjectUniverse of Discourse. Tailoring means: • selecting which ECSS standards are applicable • de-selecting those requirements from each standard that are not applicable to the project • exceptionally, modifying existing ECSS requirements • adding project-specific requirements

14. E CSS Products within a Space Project • For each product developed for and integrated in a Space Project, a Statement of Work (SoW) is generated containing: • the product specification; • Its interface specifications with the rest of the system. • In the course of generating the SoW, the Project Universe of Discourseis further tailored to create a Product Universe of Discourse by: • selecting which project-tailored ECSS standards are applicable • de-selecting requirements that are not applicable to the product • adding product-specific requirements • assessing the compliance of the product to the project requirements and justifying deviations

15. European Space knowledge sharing – The needs = “Working Together” and exploiting “Knowledge” for consistent development and utilisation of the “Overall System” Promoted approach: Modelling at “GLOBAL” level The Overall System E CSS Need:Global Conceptual Modelling Language Need:“Engineering” methods and tools to develop “LOCALs” The Products Need:“Re-Engineering” methods and tools to re-engineer existing facilities for compliance with Global

16. Requirements Developments Meta-Data Meta-Data System/User Specification Proposal & Compliance Preliminary Design Detailed Design Critical Design Qualification Delivery & Acceptance Verification At acceptance, Validation Utilisation Data Data Toward Semantic Interoperability Exchanging Knowledge: Supplier Customer Transformation

17. Model at global level to ensure semantic interoperability A formal language for specifying the conceptual models  Fact-Based Modelling A formal language for specifying the conceptual models  Fact-Based Modelling Transformation algorithm from “Specification” to ”Architecture” Transformation algorithm from “Architecture” to ”Detailed Design/Coding” Conceptual layer Conceptual layer Technology specifics Logical layer Logical layer Implementation specifics Physical layer Physical layer Toward Semantic Interoperability - Engineering A Formal Language for Conceptual Modelling, rich enough to model GLOBAL including all LOCAL views Supplier Customer

18. A formal language for specifying the conceptual models  Fact-Based Modelling A common formal language for conceptual modelling, rich enough to support compatibility assessment A formal language for specifying the conceptual models  Fact-Based Modelling A formal language for specifying the conceptual models  Fact-Based Modelling A transformation algorithm to re-engineer to ”logical Models” A transformation algorithm to re-engineer to ”Conceptual Models” Toward Semantic Interoperability – Re-Engineering Assess the semantic compatibility between the two schemas Supplier Customer Conceptual layer Conceptual layer Remove Technology specifics Logical layer Logical layer Remove Implementation specifics Physical layer Physical layer

19. A Fact Based Modelling Architecture Ecosystem from an Overall System Perspective FAMOUS = Fact based Modelling UnifyingSystem European Space knowledge sharing – A solution • Standardising the development of Database Systems by: • Providing methods and tools for data modelling at conceptual, logical and physical level • Integrating data modelling with software engineering (including development of new systems, re-engineering of existing systems) • Enabling knowledge exchange by: • Providing the means to formally specify the Global Universe of Discourse • Providing the means to view the Local Universes of Discourse i.e. managing all Locals at Global level

20. Validation √ √ User /System Requirements Delivery & Acceptance Operation & Maintenance Coding Testing Architectural Engineering Software Design Verification PDR CDR DDR QR AR SWRR FAMOUSDatabase Software Engineering - 1 Conceptual Data Model Physical Data Models Logical Data Models Software Requirements

21. Conceptual Model Logical Models Relational Hierarchical Object Oriented .. For Re-engineering .. MMI XSD SQL XSD XMI MMI … … … FAMOUSDatabase Software Engineering - 2 Physical Models

22. At Global Level Model the UoD for the System Validate the global conceptual model At Local Level Tailor the UoD Extract the conceptual definitions for the local application Validate the local conceptual model Produce the logical and physical models EV Events ER Exchange rules DR Derivation rules VR Validation rules Fact Based Conceptual Model FF Fact type forms EV FT Fact types ER DR CD Concept definitions VR Facts FF FT CD Generic Component Conceptual Schema EV ER DR Domain-specific Component VR FF FT CD Ground Facts FAMOUSFact Based Conceptual Modelling THE KNOWLEDGE TRIANGLE The Knowledge Triangle The Knowledge Triangle