Interface management incose2014_lisi

Daniele Gianni(1), Volker Schaus(2), Andrea D’Ambrogio(3) , Andreas Gerndt (2) , Marco Lisi(4) , Pierluigi De Simone(4)

(1)Consultant at EUMETSAT Darmstadt, Germany

danielegmail-‐[email protected]

(3)Dept. of Enterprise Engineering University of Rome TorVergata (Rome), Italy

[email protected]

(2)Deutsches Zentrum für LuN-‐ und Raumfahrt (DLR)

Braunschweig, Germany {Volker.Schaus, Andreas.Gerndt}@dlr.de

(4)European Space Agency Noordwijk, The Netherlands

{Pierluigi.DeSimone, Marco.Lisi}esa.int

Interface Management in Concurrent Engineering FaciliHes for

Systems and Service Systems Engineering A Model-‐based Approach

CIISE 2014 -‐ Conferenza INCOSE Italia su Systems Engineering Roma, 24 -‐ 25 Novembre 2014

Outline

•  Background •  Model-‐based Interface Engineering (MBIE) for – Systems Engineering – Service Systems Engineering

•  Bring it to Concurrent Engineering •  Exemplary ApplicaHons: – Galileo Receivers – Galileo Early Services

CIISE'14 -‐ Nov 24th, 2014 Model-‐based Interface Engineering 2

DefiniHons From INCOSE: Systems Engineering

Model-‐based Systems Engineering


MBIE for Concurrent Systems Engineering

•  What is it? MBSE applicaHon to interface specificaHons •  Why doing it?

–  Interface specificaHons (ICDs) are of great importance

–  3 Principles •  “Can/must/should understand” principle •  “Can-‐reveal” principle •  “Need-‐to-‐know” principle

–  Support the verificaHon acHviHes with more effecHve verificaHon campaigns, reducing risks in the transiHon to user acHviHes

•  How? –  UML-‐based Interface CommunicaHon Modelling Language (prototype) –  ICML deployment in CE environments (outline)


Interface CommunicaHon Modelling Language

•  Prototypal UML Profile •  Sketched integraHon with SysML •  Originated by modelling support

acHvity for Galileo OS •  Oriented to Electric Analog and

Digital interfaces •  Structured in 5 levels •  Each level concerns one aspect of

signal-‐in-‐space representaHon •  Defines also 8 processes to convert

data (i.e. Instances of an interface model) from adjacent levels

•  Number of use cases and future exploitaHon cases idenHfied


Service Systems Engineering From SEBoK (Systems Engineering Book of Knowledge): “Service systems engineering (SSE) is a mulYdisciplinary approach to manage and design value co-‐creaYon of a service system. It extends the holisYc view of a system to a customer-‐centric, end-‐to-‐end view of service system design. Service systems engineers must play the role of an integrator by considering the interface requirements for the interoperability of service system enYYes, not only for technical integraYon, but also for the processes and organizaYon required for opYmal customer experience during service operaYons.”


MBIE for Concurrent Service Engineering

•  Interfaces are central in the service specificaHons –  Define how a service can be consumed –  Are the socket point to aeach other relevant informaHon on Quality of Service

–  Service performance may also depend on external service performance besides from the internally measured process KPIs

•  CriHcal in System of Systems configuraHons: –  Only interface models may be disclosed with partners –  Interface models can support systems interoperability –  Interface models can contribute to the performance evaluaHon of SoS configuraHons (e.g. availability, reliability) from the performance of individual systems


MBIE Benefits for CE AcHviHes MBIE can bring similar benefits to those provided by MBSE: •  SupporHng the communicaHon

for integraHon-‐specific aspects, similarly to what currently achieved by state-‐of-‐the-‐art MBSE for systems in CEFs;

•  ContribuHng to define restricted views on what is strictly necessary to share with project partners for systems and funcHonal domain integraHons

•  Maintaining traceability between interface elements and system models

•  Providing means for the assessment of the impact of interface modificaHon on the internal system funcHonal and physical design.


MBIE in Concurrent Engineering Three dimensions are to be considered: -‐  Physical domain: discipline parHHoning -‐  Sub-‐/System: hierarchical parHHoning of the system or SoS -‐  Enterprise context: scope of responsibility/authority Each dimension idenHfies a disHnguishing aspect in MBIE: -‐  Physical domain: interface models use the same physical

quanHHes -‐  Sub-‐/System: interface models related to physically

adjacent components -‐  Enterprise context: limitaHon on sharing of interfaces

models and of traced system models


Relevant dimensions for CE Actors Physical Domain

(Within) Thermal, Mechanical,

Electronics, etc.

Sub-‐/System (Between)

Sensor, Instrument, Satellite, Ground Segment, etc.

Enterprise Context (Within)

Core Team, Project Team, SoS ConfiguraJon, Public Service

Domain Expert

For workload parHHoning among experts of the same domain, over disHnct components

Important only for transducer components

Not directly interested. May be subjected to model sharing restricHons, depending on the system / service interfaces with external world

Systems Engineer

Not interested For system integraHon if all the components are designed by the same organisaHon

For system integraHon when the components are designed by different organisaHons (sharing condiHons may apply on interface and system models)

Users, Project Partners, Third-‐party Service Providers

Only system and service interfaces related to the integraHon with the external world

Only interested in interfaces related to the integraHon with the external world

For system integraHon and service consumpHon (sharing condiHons may apply on interface models)


Deployment Outline

Design and Integration Tools

System ModelCentral

Repository

Team leader Systems engineer

Verification expert

Domain experts

VirSat

VirSat

VirSat

Interface ModelCentral

Repository

System integration engineer

SoS integration engineer

Third-party Service Provider

Overlay Service Provider

WebVirSat

Direct User

Model Distribution Access Control

Enterprise VirSat User Credential Management

Interface Modification Impact Analysis Tool

Other tools

SoS Simulation Tools

WebVirSat

Web and MobileVirSat

Rich ClientVirSat

Rich Client VirSat

Interoperability and Compatibility Evaluation Tool

Service Level Agreement

Generation Tool

ICMLThird-Party

Interface ModelRepository

ICMLDepending Interfaces

VirSat

System ModelCentral

Repository

Using Systems

Customer

Stakeholder Viewpoint

Platform Viewpoint

Service Viewpoint

ConcurrentEngineering Facility

Integration Viewpoint

Enterprise Context (Project Team)

Physical Domain (any)

Implementing /Depending Systems

Model Distribution

Policy

Data Policy

Definition


ApplicaHons to Galileo Receivers We idenHfied three possible exploitaHon scenarios in Physical Domain (Electronics), Sub-‐/System (Instrument), Enterprise Context (Project Team):

Scenario 1: idenHficaHon of the receiver requirements that are introduced or modified by the Galileo OS SIS, with respect to exisHng GPS receivers. Scenario 2: linking between the ICML specificaHon and the receiver funcHonal schema to idenHfy how a Galileo receiver will differ from exisHng GPS soluHons. Scenario 3: a development of Scenario 1 and Scenario 2, in which the physical schema definiHon and the physical components idenHficaHon (HW and SW) may further exploit the ICML-‐based approach for supporHng the reuse of exisHng GPS components.


ApplicaHons to Galileo Receivers Simplified Galileo OS Interface Model (Level 3)

•  One Data Frame •  Two Subframes Pages

and PragmaHcs


ApplicaHons to Galileo Receivers Simplified Receiver Model


ApplicaHons to Galileo Receivers Model ExploitaHon (Scenario 2)


ApplicaHon to Galileo Early Services •  Galileo is entering in its Services Delivery phase, while the

system proceeds towards its Full OperaHonal Capability configuraHon;

•  European Commission, European GNSS Agency (GSA) and ESA are presently engineering and developing the organizaHon needed for a conHnuous and reliable provision of services to EU and worldwide users.

•  Interface specificaHon is key to: –  Develop the end-‐user community (Receiver applicaHon, Scenario 3)

–  Support overlay service providers (geolocaHon service providers requiring Galileo accuracy) (Switching costs from other GNSSs)

–  IntegraHon with third-‐party service providers (e.g., COSPAR-‐SAT integraHon, MulH-‐GNSS interoperability)


ApplicaHon to Galileo Early Services •  Switching costs from other GNSSs – Provider side: Cost-‐benefit analysis (idenHficaHon of systems to be updated or replaced—extension of receiver scenario 2) – Galileo side: Reduce switching costs (promoHng understanding of interface and linking to compliant soluHons—extension of receiver scenario 3)

•  MulH-‐GNSS Interoperability: – Support for GNSSs-‐receiver side interoperability (i.e. the receiver capability to use independent GNSS signals for the computaHon of the global posiHoning)

•  How? Achieving ICML wider integraHon with UML diagrams (e.g. collaboraHon), SoaML (service interface descripHons), and UPDM (for SoS integraHon)


Conclusions

•  Model-‐based Interface Engineering (MBIE) can bring several benefits to CollaboraHve Systems and Service Systems Engineering

•  Brief overview of ICML (Interface CommunicaHon Modelling Language) – Website: heps://sites.google.com/site/icmlmodellinglanguage/

•  Deployment outline in VirSat / Concurrent Engineering Facility

•  Discussed two possible applicaHons for Galileo receivers and Galileo early services
