Slide 1 ISO JCT1 SC32 WG2 Berlin 2012 The “Knowledge Sharing Challenge” for Partners in European Space Projects Serge Valera European Space Agency

Slide 1Slide 1ISO JCT1 SC32 WG2 Berlin 2012

The

“Knowledge Sharing Challenge”

for Partners in

European Space Projects

Serge Valera

European Space Agency


The

“Knowledge Sharing Challenge”

for Partners in

European Space Projects

Serge Valera - ESA


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


19 ESA Member States

Austria

BelgiumCzech Republic

Denmark

Finland

France

Germany

Greece

Ireland

Italy

Luxembourg

Norway

The Netherlands

Portugal

Spain

Sweden

Switzerland

United Kingdom

Romania


ESA’s presence worldwide

Houston

Washington

Kourou

Moscow

Establishments

Offices

ESTEC(Noordwijk)

BrusselsESA HQ(Paris)

Toulouse

ESAC(Villanueva

de la Cañada)

ESRIN(Frascat

i)

EAC (Cologne)

ESOC(Darmstadt)

Harwell

Redu

Salmijaervi(Kiruna)

Ground stations

New Norcia

Santa Maria

Cebreros(Villafranca)

Oberpfaffenhofen

Maspalomas

PerthMalargüe


ESTEC, Noordwijk, The Netherlands


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

EmploysApprox. 2000 staff


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


Typical ESA Project - EarthCARE

Base Platform: Astrium Limited

Launcher RussianSoyuz (Kourou or Baikonour)

Zenit (Baikonour)

Satellite Prime Contractor: Astrium GmbH

ESA Kiruna Ground Station

Star Tracker: Jena-Optronik GmbH

Multispectral Imager: SSTL

Broadband Radiometer: SEA Ltd.

Flight Operation Segment: ESOC

Backscatter Lidar: Astrium-SAS

Cloud Profiling Radar: JAXA

Onboard Computer: RUAG Aerospace

Payload Data Segments:

ESRIN

JAXA for CPR

Slide 10Slide 10

ISO JCT1 SC32 WG2 Berlin 2012

Knowledge exchange: Towards a solution

Standardise the space system development and operation processes and their inputs & outputs

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

European Cooperation for Space Standardisation E CSS

Slide 11Slide 11


ES...

ES 2

ES 1

US...

US 2

US 1

SSC …SSC 2PSC 1SSC …SSC 2SSC 1

Unit Supplier

Unit Supplier

Unit Supplier

Payload SubcontractorPayload SubcontractorSubsystem SubcontractorSubsystem Subcontractor

Usually ESA

Customer – Supplier Network

Top-level Customer

Customer

Supplier

Equipment Supplier

Equipment Supplier

Equipment Supplier

Network of Customer-Supplier

relationships

Business Agreement

Business Agreements

Business Agreements

Customer

Supplier

Customer

Supplier

Specifications

Products and associated information

PayloadSubcontractorSubsystem Subcontractor

Satellite Prime ContractorPC

E CSS

Slide 12Slide 12


ECSS SystemECSS System

Project ManagementProject Management EngineeringEngineeringProduct AssuranceProduct Assurance

Project planning and implementation

Project planning and implementation

Configuration and information management

Configuration and information management

Cost and schedule management

Cost and schedule management

Integratedlogistic support

Integratedlogistic support

Risk managementRisk management

Product assurance management

Product assurance management

Quality assuranceQuality assurance

DependabilityDependability

SafetySafety

EEE componentsEEE components

Materials, mechanicalparts and processes

Materials, mechanicalparts and processes

Softwareproduct assurance

Softwareproduct assurance

System engineeringSystem engineering

Electrical andoptical engineering

Electrical andoptical engineering

Mechanical engineering

Mechanical engineering

Software engineering

Software engineering

CommunicationsCommunications

Control engineeringControl engineering

Ground systemsand operations

Ground systemsand operations

Branches

Disciplines

ECSS Document ArchitectureE CSS

Slide 13Slide 13


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

E CSS

Slide 14Slide 14


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 Discourse is 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

E CSS

Slide 15Slide 15


European Space knowledge sharing – The needs

= “Working Together” and exploiting “Knowledge” for consistent development and utilisation of the “Overall System”

Need: Global Conceptual Modelling Language

Promoted approach: Modelling at “GLOBAL” level The Overall System

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

E CSS

Slide 16Slide 16


Supplier Customer

Utilisation

Data Data

Exchanging Knowledge:

Toward Semantic Interoperability

Requirements

Meta-Data

Developments

Meta-Data

Transformation

System/User Specification

Proposal & Compliance

Preliminary DesignDetailed DesignCritical DesignQualification

Delivery & Acceptance

VerificationAt acceptance, Validation

Slide 17Slide 17


Supplier Customer

Model at global level to ensure semantic

interoperability

Implementation specifics

Physical layer

Physical layer

A formal language for specifying the conceptual

models Fact-Based Modelling

Transformation algorithm from “Architecture” to

”Detailed Design/Coding”Technology

specifics

Logical layer

Logical layer



Transformation algorithm from “Specification” to

”Architecture”

A Formal Language for Conceptual Modelling, rich enough to model GLOBAL including all LOCAL views

Toward Semantic Interoperability - Engineering

Conceptual layer

Conceptual layer

Slide 18Slide 18


Toward Semantic Interoperability – Re-Engineering

Supplier Customer

Physical layer

Physical layer

Logical layer

Conceptual layer

Assess the semantic compatibility

between the two schemas

Remove Implementation

specifics

Remove Technology

specifics

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 transformation algorithm to re-engineer to

”Conceptual Models”



A transformation algorithm to re-engineer to ”logical

Models”

Logical layer

Conceptual layer

Slide 19Slide 19


A Fact Based Modelling Architecture Ecosystemfrom an Overall System Perspective

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

European Space knowledge sharing – A solution

FAMOUS = Fact based Modelling Unifying System

Slide 20Slide 20


User /System

Requirements

Architectural Engineering

Software Design

Software Requirements

Verification SWRR PDR DDR CDR QR AR

Coding TestingDelivery & Acceptance

Operation & Maintenance

Validation √√

Conceptual Data Model

PhysicalData Models

LogicalData Models

FAMOUS Database Software Engineering - 1

Slide 21Slide 21


Logical Models

Relational Hierarchical Object Oriented ..

..XSD

SQL

…MMI

MMI

XSD

…XMI

…

Physical Models

Fo

r R

e-e

ng

ine

eri

ng

FAMOUS Database Software Engineering - 2

Conceptual Model

FactType

Role

is called / calls

has / belongs to

ObjectType

plays / is played by

RoleName

Reading

has / describes

Slide 22Slide 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

ER

DR

VR

FF

FT

CD

EV

Exchange rulesER

ER

Derivation rulesDR

DR

Validation rulesVR

VR

Fact type formsFF

FF

Fact typesFT

FT

Concept definitionsCD

CD

EventsEV

EV

Generic Component

Domain-specificComponent

Facts

Ground Facts

Conceptual Schema

FAMOUS Fact Based Conceptual Modelling

Fact Based Conceptual Model

FactType

Role

is called / calls

has / belongs to

ObjectType

plays / is played by

RoleName

Reading

has / describes

TheKnowledgeTriangle

TheKnowledgeTriangleTHE

KNOWLEDGETRIANGLE

Documents

Slide 1 ISO JCT1 SC32 WG2 Berlin 2012 The “Knowledge Sharing Challenge” for Partners in European Space Projects Serge Valera European Space Agency