Concurrent engineering facilities (CEFs) are successfully used in the aeropsace sector to design systems and services that that fulfill the requirements. Model-‐based systems engineering (MBSE) enables the effective (i.e., unambiguous) communication in the collaborative activities within concurrent engineering and service systems engineering facilities. The advantages obtained by the MBSE approach can be further scaled up by an innovative approach that take into explicit account the representation of the inter-‐systems aspects, i.e., those aspects, namely interfaces, that stay in between the system, its sub-‐systems and external entities (other systems and organizations). Such an approach, briefly denoted as a Model-‐based Interface Engineering (MBIE), brings several benefits to the CEF activities. This paper illustrates the integration of the Interface Communication Modelling Language (ICML) into the existing MBSE methods for the CEF software framework VirSat, by identifying the business needs driving the use of MBIE approaches and showing example application scenarios.
system, its sub-‐systems and external entities (other systems and organizations). The same approaches can be successfully exploited in a service systems engineering context. Service systems focus on the delivery of services that satisfy the needs and expectations of customers. Such systems are characterized by the value that results from the interaction and the interoperability of service systems entities, from both a technical and an organizational point of view. It is thus essential to exploit model-‐based approaches that contribute to formally define the interfaces of a service system, in order to match them with internal and external counter-‐interfaces.
cross-‐functional and cross-‐enterprise systems integrations [
required for the individual parts of a CEF study, for independent functional domains and/or for segments/sub-‐parts of the full system. This can be particularly exacerbated in those cases were no internal know-‐how or resources are available for the full system engineering. In these cases, functional studies, or part of the systems engineering activities, may need to be outsourced or, more critically, the final system may have to integrate with existing or to-‐be-‐designed third-‐party systems (conventional systems or systems of systems). In these cases, using a Model-‐based Interface Engineering (MBIE) method (as a sub-‐set of MBSE), several benefits can be brought to the CEF activities as this method provides key capabilities for: 1) Supporting the communication for integration-‐specific aspects, similarly to what has been currently achieved by state-‐of-‐the-‐art MBSE for systems in CEFs; 2) Contributing to define restricted views on what is strictly necessary to share with project partners for systems and functional domain integrations; 3) Maintaining traceability between interface elements and system models; 4) Providing means for the identification of the impact of interface modification on the internal system functional and physical design.
(https://sites.google.com/site/icmlmodellinglanguage/) [
The CEF this paper refers to is the one setup in 2008 by the German Aerospace Center (DLR) to support the
early design studies of new spacecraft systems. The CEF layout is closely based on that of ESA’s concurrent
design facility (CDF). The parameters of the spacecraft that are set and discussed in the CEF studies are stored
in a so-‐called Integrated Design Model (IDM), which has to be maintained consistent and be shared across all
engineers of a session. The IDM was initially implemented by use of a document-‐based approach and to
overcome the aforementioned problems of such approaches, the DLR and other institutions have started to
move toward modern model based approaches [
early design phases. In parallel to ESA’s approach, DLR started with its own approach with Virtual Satellite (VirSat) intending to use a data model for the spacecraft design going beyond the early planning phase, by accessing and reusing the parameters of the first early studies to allow for further analysis in later phases.
down hierarchical approach, the engineers decompose the spacecraft starting from the overall system, down to individual parts. The shared data model is synchronized using a centralized version control system and, similarly to software development, only the local work copy is modified.
an interface specification consists of concepts and relationships that can be formulated in natural language or in a (semi-‐) formal graphical language. In systems and service systems engineering activities, the introduction of MBIE is motivated by the following observations: 1) A relevant part of the documents concerns interface specification (ICDs); 2) There may be no needs to share internal details of sub-‐systems (“can-‐understand” principle); 3) Confidentiality issues may limit the distribution of internal sub-‐systems module (e.g. when reusing third-‐party system); 4) Confidentiality issues may limit the access rights to the stakeholders of the interface models (“Need-‐to-‐know” principle in multi-‐partner projects); 5) Support for the verification activities with more effective verification campaigns, reducing risks in the transition to user activities (primarily in systems engineering); 6) Service performance may also depend on external service performance besides from the internally measured process Key Performance Indicators (KPIs) (primarily in service systems engineering); 7) Interface models are critical to ensure a seamless transition of a SoS configuration between two phases, involving different partners, e.g. from validation to operation with external users (primarily in service systems engineering); Similarly to MBSE, MBIE can be supported by the definition of modelling languages and technologies that can be used to represent interface specifications (i.e. interface control document) and to exploit the interface models within systems and service systems engineering activities, which are typically performed in CEF for large and complex projects. In theory, an interface modelling language can be defined in any available technology. In practice, however, most of the MBSE methods rely on UML-‐derived technologies and therefore one cannot disregard UML when defining an interface modelling language. However, the core issue is not about conforming to a set of technologies to offer a seamless exploitation to the end user. The core issue is rather to ensure that an interface model can be integrated with system and service systems models (typically in UML-‐based technologies). This allows interface elements to be traced onto systems and service systems models and will therefore contribute to provide a more comprehensive view of the systems and services being designed. Interface Modelling Communication Language (ICML)
modelling language for the representation of interface specification using UML-‐based technologies. ICML is defined as UML profile and can integrate with system specifications based on compliant technologies.
prototypal version has been implemented [
most popular UML and SysML open source modelling tool.
definition of both the message structure and conversion processes. The message structure consists of five abstraction levels, and describes how the data is structured within the message. The conversion processes describe how the data values are transformed between adjacent levels of the message specification. The message structure is defined at five levels: Data Definition, Binary Coding, Logical Binary Structure, Physical
For example, the Data Definition level covers the specification of the logical data structure, which includes the data items composing the message information. A data item is either of application or control type. An application data item represents a domain specific concept that conveys the information expected by the message recipient. Differently, a control data item represents a domain independent concept that can support the correctness and integrity verification of the associated application data items. A data item can also be associated to semantic and pragmatic Level 5 DBaitnaCaDrPye5Cfitnooid4tiionng2 Application DDaatata DefinitioCnontrol Data LLeovgeiclal dmeefainniitniogn osf. thThe e d aftoar miteemr asnpde c tihfiees la tttheer Level 4 BLion(gaCircyPaC4lBotoidn3ina)gry2 SpCecuisfitcoamtiBoninary CoRdeifns gtSotaInntdearnrdational BDian(taCarDPyCe4ftoiond5iitn)iogn2 fsAopnrea cloifgieotsuh stehly e, ctohsneetm eBxaitnnuataircly i nCtoeddrpienrfegint ialtetioivonen.l Level 3 LPohgy(CisciPacal3BltBioni2na)rayr2y SpCeLcuoisfigtcoaimctiaonl BinaryRSetfsrutSoctaItnuntderearnrdational LBoign(CiacrPayl3CBtoiond4ai)nryg2 Physical ccoovdeinrgs thfoer speeaccihfi caotfio nth eof dthaeta b iintearmy
PRhefysstoicInatlerBnaintioanrayl SCtaonddianrdg PLhoy(gsCiiccPaa2llBBtoiinn3aa)rryy2 Level idteefmin, e tdh eat b tinhaer yab coovdein lgev isel r. e Fporre sae ndtaetda Level 2PPhhyy(sCsiciPcaa2lBltSoin1iga)nray2l BinSaigrynaDClsautsatom SpecSifiycnactSihoirgnonnaizlsation laesa sbtin aary sseeqquueennccee a ndid eitn tinifcielur,d est haet semantic definition, and the pragmatic Level 1 RefsCPtouhsItnyotsemircnSaaptlieocSnifaiigclaSnttiaaonnldard PPhhyy(sCsiciPcaa1lSltBoigi2nn)aarly2 tdheefi nseitmioannst.i Sci manildar plyr a tgo m thaetic a bdoevfieni lteiovenls,
contributing to convey accurate
representation of the binary coding.
Figure 1 Layout of ICML-‐based interface specification [
concerning the above-‐defined level 3 and level 1. Figure 2 shows a detail of the specification for a reduced
consists of F/NAV Subframe 1 and F/NAV Subframe 2. Figure 3 details the specification of F/NAV-‐like Page 1. In particular, this page consists of four sequences: Eccentricity and Omegadot—representing application data;
Integration in Concurrent Engineering Facilities MBIE can bring similar and complementary benefits to those provided by MBSE deployed in CEFs. For example, in CEFs, MBIE can: further support the communication on integration-‐specific aspects for systems, sub-‐systems, and service systems; contribute to define restricted views on systems models that are strictly necessary to share with project partners for systems and functional domain integrations; maintain traceability between interface elements and system models; provide means for the assessment of the impact of interface modification on the internal system functional and physical design.
organisational boundaries) of a CEF activity, we have sketched an integration diagram that could extend the
The Stakeholder viewpoint concerns the identification of the possible actors in a VirSat environment that can support also MBIE and that can leverage interface models to enrich also its current capabilities. Besides the existing VirSat actors of Team Leader, System Engineer, Domain Expert, and Verification—which are shown at the bottom and bottom-‐left sides of the diagram for visual analogy with the existing VirSat integration layout—other actors become of relevance in the context of MBIE in CEF for systems and service systems engineering: System Integration Engineering, SoS Integration Engineering, Third-‐Party Service Provider, Overlay Service Provider, and Direct (or end interface) User. The Platform viewpoint concerns the platforms that the newly considered CEF actors can use to access interface models, primarily, and the traced system model, eventually and conditionally. Currently, three types of platforms are identified: Rich Client VirSat (i.e. the current VirtSat), Web VirSat (i.e. a web-‐enabled version of VirSat), and Web and Mobile VirSat (i.e. a light version that can be access through Web-‐mobile interfaces). The Service viewpoint illustrates the enriched services that can be introduced as consequence of the availability of interface models as limiting and tracing proxies for system models. Basing on the above observations, we foresee that service architecture based on three levels: Enterprise VirSat User Credential Management—which addresses the observations related to the model audience identification for the controlled distribution and access of interface and traced system model;
language in VirSat. In this viewpoint, the modelling facilities as well as the model storing facilities for interface specifications are introduced along side the existing one for system models. Moreover, this viewpoint also shows the links for the traceability between interfaces and systems models, the interdependencies between local interfaces and external systems, and between external interfaces and internal systems.
subjected to model sharing restrictions, depending on the system / service interfaces with external world
components are designed by different organisations (sharing conditions may apply on interface and system models)
MBIE approaches based on ICML can have a wide application to systems and service systems in CEF, far beyond the space domain. However, in the context of this experimental activity, we have initially focussed on the space domains and we have identified two possible applications to the Galileo receivers and to the Galileo early services. In both applications, ICML can bring the MBSE benefits toall the stakeholders, from systems engineers to the interface users. For example, ICML can: 1) provide a reference guideline for structuring the specification data and thus facilitating the communication between the Galileo SIS designers and the receivers producers, and more generally all the interface users (including also overlay service providers); 2) ease visual inspection of the specification, for verification purposes; 3) support syntactical model validation using existing tools; 4) support for future advance exploitation by means of a machine-‐readable data format. In particular, the availability of a machine-‐readable format is also the base for advanced use cases that can exploit the capabilities of modern computer technologies, such as model-‐based verification and model-‐driven simulation engineering with data-‐driven experiments. Application to Galileo Receivers • • •
“Electronics”, sub-‐/system “Instrument”, and enterprise context “Project Team” (Figure 5):
Physical Domain (any)
Domain experts
Verification expert Enterprise Context (Project Team)
VirSat
VirSat System integration engineer Rich Client
VirSat
SoS integration engineer Rich Client
VirSat
Third-party Service Provider
Web VirSat
Overlay Service Provider
Web VirSat
Direct
User Web and Mobile
VirSat Enterprise VirSat User Credential Management
Design and Integration Tools InImteprfaacct e A Mnaolydsifisic Taotiooln aIEnnvdtae Clruooampteiporanatb iTbioliilotiytl y GeSAnegrevrreiacetei mo Lneenv Tetol o l SoS STimooullsation Otothoelsr
Model Distribution Access Control
ICML Interface Model
Central
Repository System Model
Central Repository
Data Policy Model Definition Distribution
Policy Depending Interfaces
Customer IC
Third-Party Interface Model
Repository Implementing / U
Depending Systems sing Sy stem s
System Model
Central
Repository VirSat
VirSat Team leader
Systems engineer
Stakeholder Viewpoint Platform Viewpoint
Service Viewpoint Concurrent Engineering
Facility Integration Viewpoint physical components identification (HW and SW) may further exploit the ICML-‐based approach for supporting the reuse of existing GPS components. In the context of this paper, for the sake of brevity, we only present Scenario 2, which is however underpinning both Scenario 1 and Scenario 2.
functional schema. Similarly to the above diagrams, the diagrams below are introduced for exemplification purposes only, to show the ICML potential benefits. Indeed, these diagrams are not to be considered fully realistic and detailed for real Global Navigation Satellite System (GNSS) receivers. Moreover, only the above defined ICML level 1 and level 3 elements are considered. Application to Galileo Early Services
towards its Full Operational Capability configuration. In the preparation activities for this phase, the EC, the
continuous and reliable provision of the Galileo services to EU and worldwide users. In this context, the aspects related to the Galileo interface specifications are of primary importance to address three concerns: 1) Develop the end-‐user community; 2) Support overlay service providers (switching costs from other GNSSs); and, 3)
From initial investigative activities, the use of ICML—as MBIE method—has shown a promising potential to technically support the solution to the above three concerns, which on their technical side might also require a concurrent engineering approach because of their large scope and inherent complexity. In particular, Concern 1) can be addressed similarly to what already described in Scenario 3) as developing Galileo receivers may require new design and adaptation of existing software (SW) or hardware (HW), as well as new production chains and higher costs—in particular no recurring costs—are likely to occur with respect to the well-‐established GPS receivers. As a consequence, limitations may be experienced in the market penetration and in the growth velocity of the Galileo receivers’ share in the receiver market. In turn, this may hinder the estimated economical return for the Galileo project. Differently, Concern 2) can be analyzed from a provider prospective and from a Galileo programme prospective. On the provider side, cost-‐benefit analysis may need to be considered for balancing the cost of switching the positioning service to Galileo vs the enhanced Galileo accuracy. This analysis can be facilitated—therefore further reducing the analysis costs—by the guideline described for Scenario 2). Specifically, the service provider could benefit from the MBIE method offered by ICML for the identification of the systems to be updated or to be replaced. Differently, from the Galileo side, one possible objective is to reduce the switching costs from other GNSS service providers. Consequently, in this situation, Scenario 3) may be used as guideline for an extended process that can sustain the unambiguous understanding of the Galileo interfaces (starting from the signal in space one) and that may provide references for compliant solutions at functional and at physical levels, thus contributing to reduce the switching costs to the overlay service providers. Finally, Concern 3) is likely to the one requiring an engaging business-‐level strategy to be addressed. Nevertheless, an ICML-‐CEF approach may technically sustain possible business strategies by making their implementation economically more convenient for reasons similar to those above mentioned for Concern 1) and Concern 2). For Multi-‐GNSS interoperability, validated results have shown how the ICML language can support the receiver-‐side interoperability, i.e. the receiver capability to use independent GNSS signals for the computation of the global positioning. This capability implicitly requires that the receiver computations are decoupled from the signal-‐in-‐space interface of any GNSS. Key condition to achieve this decoupling is that the interface specifications are available in a consistent, unambiguous, and —if possible—a standard format, which can support engineers to more effectively design interoperable receivers.
involved actors in the respective studies. Currently, ICML has only a preliminary integration with UML and
integration with UML, SysML, and other related modelling standards can more evidently benefit the systems and service systems engineering activities. For example, integrating ICML with UML sequence diagrams can contribute to reduce the ambiguity on the format of the exchange message. Similarly, integrating ICML with
to values of a message for triggering state changes or process executions. Other examples can be drawn with
means to specify (and agree) on service specifications, further contributing the replacement of the ambiguous document-‐based specification with the model-‐based specification. Finally, in the case of UPDM, the integration can offer a multi-‐resolution modelling approach that spans from the service and architectural concerns down to the technical interoperability ones. Conclusions
undertaken in Concurrent Engineering Facilities (CEF) as MBIE can support the encapsulation of system models beyond interface models, thus reducing the visible complexity while supporting the identification of the systems models to be shared. Consequently, the communication with the stakeholder is also facilitated as it focalised on the boundary concerns represented by the interfaces, which can span several dimension. Moreover, the use of a MBIE can also enhance the existing MBSE capabilities with the traceability of the interface elements on the system functional and physical schemas, with the final objectives of supporting assessment of interface modification, supporting cost-‐benefit analysis in service provider switching, systems interoperability, system model distribution control, for instance. Aside from the motivation analysis, the paper has also outlined the definition of ICML (Interface Communication Modelling Language) as MBIE method, including a brief exemplification of a Galileo-‐like OS service interface specification. Next, the paper has also presented an initial integration and analysis between ICML and the VirSat CE tool. The integration analysis has proceeded in three steps: CEF actors identification in a interface-‐intensive engineering activity; actors concerns
Decoder DB (bottom) along the three dimensions of physical domains, system, or enterprise context; and integration diagram with
discussed two possible applications of ICML in VirSat, for the Galileo receivers and for the Galileo early services.
detailed with ICML and SysML diagrams. All the scenarios are aimed to support the design of Galileo receivers with the reuse of existing GNSS solutions for Galileo by tracing the interface elements on system models of existing receivers. Similarly, the application for Galileo early services can leverage on similar exploitation scenarios, in which a wider integration with UML and relevant languages, such as SOAML and UPDM, may be needed.