=Paper=
{{Paper
|id=Vol-1728/paper12
|storemode=property
|title=Leonardo-Finmeccanica – Aircraft Division needs for Integrated Systems Engineering: the CRYSTAL user experience
|pdfUrl=https://ceur-ws.org/Vol-1728/paper12.pdf
|volume=Vol-1728
|authors=Bruno Di Giandomenico,Claudio Pessa,Laura Valacca,Elena Valfrè,Ivo Viglietti
|dblpUrl=https://dblp.org/rec/conf/ciise/GiandomenicoPVV16
}}
==Leonardo-Finmeccanica – Aircraft Division needs for Integrated Systems Engineering: the CRYSTAL user experience==
https://ceur-ws.org/Vol-1728/paper12.pdf
Leonardo-Finmeccanica – Aircraft Division needs
for Integrated Systems Engineering: the CRYSTAL
user experience
Bruno Di Giandomenico, Claudio Pessa, Laura Valacca, Elena Valfrè, Ivo Viglietti
Engineering Department
Leonardo-Finmeccanica - Aircraft Division
Torino, Italy
Copyright © held by the authors.
Abstract—In the aerospace sector the products complexity supporting the engineering activities throughout the entire
clearly highlights the need to manage a wide variety of lifecycle. Often these ‘systems’ are based on the “best in
technologies in evolving and changeable scenarios. class” solutions in a given discipline, that in many cases
A way to successfully govern this multiplicity is by designing should be complemented by customized in-house ones (often
products thoughtfully integrated and ready to operate in
proprietary).
scenarios that grow more and more entangled by the day. Fully
embracing an integrated Systems Engineering (SE) approach is One of the initiatives aimed to validate our choices we
one way to untie this knot. Leonardo-Finmeccanica – Aircraft have been involved in is the ARTEMIS CRYSTAL research
Division has been involved in different innovation initiatives project that is mainly focused in establishing and pushing the
aimed at promoting the use of Model Based Systems Engineering
(MBSE) methodologies and tools integration as standard
development and adoption of an Inter-Operability
practices, in order to define an internal structured and robust Specification (IOS) as an open European standard for the
Systems Engineering Process. development of embedded systems in the automotive,
The participation to the ARTEMIS CRYSTAL research aerospace, rail and health care domains. Based on open Web
project is part of these initiatives and is focused on validating technologies such as OSLC [8], IOS allows loosely coupled
innovative workflows and modeling approaches in a multi tool – tools to share and interlink their data enabling interoperability
multi user scenario. The definition of an appropriate Project among different engineering environments without closely
Management environment and of a minimum set of coupled process integration.. Within the project a dedicated
Configuration Items to be properly managed starting from the process description language, SPEM [6] supported the
Preliminary Design phase also represents a primary objective.
formalization of the Engineering Environment specification
This paper explains the industrial needs, the applied solutions
and the experience made in implementing the demonstration and of the System Engineering “best practices”.
scenario in the CRYSTAL research project focused on a specific For this research project, we have selected an industrial
aerospace Case Study.
Case Study implemented with the support of a dedicated tool
Keywords—Model Based Systems Engineering; Interoperability chain and focusing on the Preliminary Design Phase of the
Specification; Tool Chain; OSLC; SPEM; Product Lifecycle Aeronautical products Lifecycle. This paper focuses on the
Management. Case Study implementation.
I. INTRODUCTION II. CHALLENGES AND CRYSTAL VISION
In order to maintain a competitive position in a very A. Industrial Needs
crowded market scenario, it is vital to reduce the development
projects costs. “Best practices” collection and reuse The market for most aeronautic companies shows a
management criteria are additional means which can help to heightened sensibility on costs and is subject to many
realize this objective. customers’ budget reductions. To keep the market share, the
robustness of design and awareness of budget must be
Our choice has been to fully embrace a Model Based supported by adequate methodologies, virtual validation and
engineering approach enabling us first and foremost to provide comprehension of design choices and changes impact costs
the capabilities required by the stakeholders requirements with since the earliest phases of product lifecycle. The growing
a strong focus on the integration aspects of the product’s operational complexity of aeronautical products also fosters
functionalities [1], [2]. To support our multidisciplinary, the need for a strong relationship between suppliers and
concurrent and integrated development process the challenge customer who does not want anymore a simple product, but an
lies in harmonizing all the growing specialized ‘systems’ organized set of functions to be satisfied in different
(processes, methods and tools) and related heterogeneous data operational scenarios.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
The current emerging standard in the aerospace field, SAE Standardization through a validation provided by
ARP-4754A [4] suggests an approach in which development “Close-to-real-world” demonstrators.
and safety assurance processes are closely coupled and puts a 4. To support Small and Medium Enterprise integration
strong emphasis on the functional driven development which in the engineering ecosystem for the embedded
can be represented with models to deliver a structured, linked systems development.
and retrievable information set. A system model may support
also various degrees of simulation to assess and validate the
customer’s requirements already in the first phases of the C. Enabling Technologies
project development. As a reference, we have chosen the The analysis of the project needs for interoperation led to
emerging standard language in functional modeling, the the identification of innovative “enabling” technologies, the
System Modeling Language (SysML) [5], which also aid in most relevant ones being OSLC [8] to support interoperability
accelerating the change from Document Based to Model and SPEM [6] to support process and knowledge
Based Engineering and shall have a major impact in our formalization and reuse.
company engineering practices, by changing the basic
perception of the product design and improving knowledge
reuse. OSLC
Open Services for Lifecycle Collaboration (OSLC) [8] is a
community which is creating specifications to allow
B. Project Approach conforming independent software and product lifecycle tools
CRYSTAL, as an ARTEMIS Innovation Pilot Project to integrate their data and workflows in support of end-to-end
takes up the research results of previous projects in the field of lifecycle processes. Examples of lifecycle tools may include
Reference Technology Platforms (RTP) and Interoperability requirements management, change management, asset
Specification (IOS) (e.g. CESAR, MBAT) and aims at management, etc.
enhancing and maturing them with the clear objective of In OSLC, each artefact in the lifecycle – for example, a
industrialization take-up. requirement, a test case, a source file, a model element and so
on – is an HTTP resource that is manipulated using the
CRYSTAL’s vision is to enable new Systems Engineering
methods and practices by promoting the RTP, an open tool standard methods of the HTTP specification (GET, PUT,
integration platform that can be viewed as a set of formalized POST, DELETE).
components (tools, methods, connectors) that can be used to OSLC specifies a common tool protocol for Creating,
set up a Systems Engineering environment in a company, and Retrieving, Updating and Deleting (CRUD) lifecycle data
supporting an IOS which will simplify tools connection by based on internet standards like HTTP and Resource
exposing services and linked data. Description Framework (RDF), using a Linked Data model
achieved by embedding the HTTP URL of one resource in the
RTP and IOS can enable common interoperability among representation of another.
various lifecycle domains, which can reduce significantly the
complexity of the entire integration. CRYSTAL is strongly
industry-oriented and is aiming at providing ready-to-use SPEM
integrated tool chains with a mature Technology Readiness SPEM (Software and System Process Engineering Meta-
Level (up to TRL 7). model) is a process meta-model with focus on engineering
Following the ARTEMIS mission, in order to strengthen processes. It is an Object Management Group specification
the European market for Embedded Systems, CRYSTAL and it is based on the Meta-Object Facility (MOF) model [9]
fosters cross-domain reusability (Aerospace, Automotive, and its UML2 Profile. SPEM can be considered as an
Health and Rail) and drives the IOS towards standardization. industrial standard that facilitates human understanding and
communication of software processes to promote their reuse
The strategy for CRYSTAL technical innovation is based and improvement.
on 4 pillars:
It has been selected in our context because it is widely
1. To increase the maturity of existing concepts used for process definition, becoming a de facto standard that
developed in previous projects and allowing allows companies to define highly personalized processes. It
integration into existing environments, by applying allows the representation of the basic items that compose
them in industrial scenarios. processes: the approach is having two main branches called
2. To provide high maturity technical innovations to fill “Process” and “Method Content” respectively which are based
the gaps through a step by step evolution and an on a Core specification and are developed to allows users to
assisted Systems Engineering environment select the packages they need to define their processes, giving
configuration approach. some freedom in applying the specification and avoiding
3. To contribute to the ARTEMIS envisaged useless implementation by reusing already accomplished
Cooperative RTP and to push the IOS towards work.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
recognized process specification standards which is an
efficient enabler for interoperability at process level. We
III. CASE STUDY applied the SPEM meta-model with a dedicated structured
Our Case Study had to fulfill the CRYSTAL objective of library for the knowledge representation and organization.
staying strongly industry oriented, focusing on a highly One of our achievements was a proposal for the above
relevant on-board system for future aeronautical products. mentioned library, as shown in Fig. 2 that have been defined
Health and performance monitoring functionalities and the on the basis of experiences gained through the past ARTEMIS
related integration with ground systems for the flight data CESAR project [3]. This library has been adopted to shape
analysis and the identification of the maintenance activity is and build the applied processes description.
undergoing a fast evolution. We have thus identified the need
to specify the functionalities of an Enhanced Integrated
Monitoring and Support System (EIMSS), which includes
processing capabilities in a Maintenance Computer (MC) and
a Multi-Functional Display (MFD) and monitors “member”
systems’ health. In addition, the Ground components of the
EIMSS which enables operator to interact with the Aircraft is
called Ground Support System (GSS). Fig. 1 illustrates the
most important relations among the EIMSS and the other
systems.
Fig. 1. Interactions of EIMSS with other systems
Fig. 2. Structure of the implemented Practices Library
As the main focus of the Case Study is on the flight
It takes into account the need of modularity and of content
phase’s functionalities, the design of a representative
re-use at both domain/cross-domain level. The knowledge was
Aircraft’s system to be monitored is also part of the exercise.
partitioned in different “method plug-ins” that can be filled
The Fuel System has been selected as representative on-board
and exported/imported independently. A method plug-in is
system, in order to verify the capability of the EIMSS in
defined as “generic” and stores concepts that are valid at a
collecting and elaborating different types of data (e.g. discrete/
cross-domain level, while another is defined as “base-
analogue inputs) coming from different types of sources (e.g.
aerospace” and stores concepts to be considered basic for the
sensors, control units, electronic circuitries, etc..).
entire Aeronautical domain.
A. Process Management Practices plug-ins allow the definition and storage of
proper, domain specific, delivery processes through the
One of the requirements in implementing a complex composition of activities and tasks. In this library we defined a
scenario from the Aeronautical domain was related to the structure related to Aeronautical domain.
formalization and the “persistence” of both domain knowledge The approach expects the definition of proper “catalogues”
and best practices, such as design activities and approaches. for both activities and methods, where we can define and store
During the Case Study implementation we also learned that all the knowledge that can be used for defining the intended
this requirement can be supported by the adoption and processes. After having defined these items we have
efficient use of Engineering Environments modeling services, proceeded with the composition of the Engineering (delivery)
such as the CRYSTAL Platform Builder Modeler. process itself.
The advantage in adopting Process formalization and
management services is the easier configurability through well
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
This process holds different levels of detail that can be These formal practices can be continuously improved and
navigated and filled with proper information, such as methods, stored in the related library for reuse.
applicable artefacts and roles for performing activities. .
The defined process can also be represented in terms of a
dedicated activity diagram that visually shows the activities
sequence and relations.
The next step in supporting the Engineering processes
enactment is represented by providing support to the users in
performing their daily tasks through the “collaboration” and
“guidance” capabilities offered by the Collaborative Lifecycle
Management platforms.
In order to simplify the acceptance and implementation of
new processes and practices by the stakeholders, such as
System Engineers and Domain Experts, we have to provide
them “context-aware” support and information about the
assigned tasks. This means providing access to the right
information about the system under development, including
the monitoring, development status and process
implementation.
We instantiated these solutions in the definition of
different Usage scenario developed in our Case Study:
a) Modeling and Analysis: Functional Modeling and
Reliability, Availability, Maintainability and Safety
(RAMS) Analysis Processes;
b) Product Configuration in the Design Process: Design
Review, Configuration Change and Requirement
Traceability Processes.
With respect to the SAE ARP-4754A reference process, a Fig. 4. Chief Engineer role in Formalized Design Review Process
simplified formal process has been considered in the RAMS
Analysis scenario including only the most significant RAMS
activities. The relevant workflow is reported in Fig. 3. B. Modeling and Analysis
As a first step in the Use Case development we performed
the requirement definition and analysis at aircraft level and
then at EIMSS and Fuel System level.
As a second step we then developed and animated the
functional model of the involved systems in order to assess in
a preliminary way the coherence and completeness of the
requirements. Different methodologies have been employed
for modeling the two systems, in order to assess how they
could be applied in different cases:
for the EIMSS system we have followed the
Harmony1 MBSE workflow, developed by IBM and
based on SysML, because we felt it was more
suitable for modeling new systems where defining
the "control" logic was the priority;
for modelling the functionalities of more "traditional"
systems like the Fuel System, in which the system
architecture is more consolidated, we followed a
Fig. 3. Formalized RAMS Analysis Process more direct in-house developed Systems Engineering
approach, also using SysML.
The Library also describes the “roles”, the “artefacts” and
the guidance that are applicable in the process. 1
With reference to Design Review activities Fig. 4 The Harmony workflow from IBM divides the development
describes the formal steps to be undertaken by Chief Engineer in 3 main basic phases, Requirement Analysis, Functional
role while performing the Design Review Process. Analysis, Design Synthesis.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
In both cases, we used the same modeling tool: IBM Finally, after logical architecture allocation to a physical
Doors Next Generation for Requirement Management and architecture in the Design Environment, the relevant physical
IBM Rhapsody/Design Manager for Functional Analysis and breakdown is transferred into RWB together with some
Design Modeling. identification information (e.g. Part Number).
As third step we validated and refined the initial Here reliability and maintainability predictions are
requirements referring to the output from the second step and performed and corresponding results are transferred into
we iterated until a reasonable design quality was obtained. Rhapsody to verify data previously allocated to the
The last goal in our approach was to link the functional corresponding logical blocks.
model to a specific disciplinary model for RAMS
investigations. We used Isograph Reliability WorkBench
(RWB) for RAMS Analysis and Isograph Data Link Manager C. Product Configuration in the Design Process
for linking Doors and RWB artifacts.
The process (see Fig. 3) starts from the execution of a Product Lifecycle Management (PLM) is a conceptualised
Functional Hazard Analysis on the system functional vision of interoperable and federated tools where all data
breakdown derived from the MBSE activities carried out across the disciplines in the context of a project are stored and
during the Functional Requirement Analysis, in order to derive managed along a lifecycle. It may follow that items of the
the Safety Requirements. With the evolution of the system various disciplines can be linked together to form traceability
design (logical architecture), RAM performance requirements, chains and queries can be performed to get impact analyses of
defined at system level during the preliminary requirement the linked data items; thus change management can be
definition phase, are allocated to system design architectural supported in a thru-lifecycle manner.
elements (Logical Blocks). As soon as preliminary physical The current aeronautical scenario is still far from this
system architectures are developed, preliminary RAMS vision; we have specific tools which have their own repository
analysis are carried out for an early verification of relevant and can exchange data and interface effectively to other tools
requirements to support Preliminary Design Review and only to a reduced extent. Product Data Management (PDM)
eventual changes on preliminary system design. In our tool has the main purpose of managing Physical Product Data
implementation, two main OSLC connections have been under Configuration Control while Application Lifecycle
considered and established between System design modeling Management (ALM) is more oriented to the management of
and RAMS analysis. the day by day System Design Development Data.
A connection gets data from Design Manager via OLSC In order to overcome this limitation, we implemented a
and provides them to RWB. On the opposite direction, another PLM as an aggregation of interoperable tools, with a PDM
connection transfers data from RWB versus Rhapsody to directly connected to some design tool and a number of
update the relevant model specification, tracking the changes. Application Lifecycle Management (ALM) tools integrated in
Typically, as first step, the functional breakdown is a federated architecture, where the access to information can
transferred into RWB to perform the Functional Hazard be provided via linked data and/or federated data-stores.
Analysis for Safety Requirements identification. The OSLC standard specification is the glue which knits it
In a second step, after system functions allocation to a all together, providing the capability of integrating the
preliminary logical architecture in the Design Environment, lifecycle components.
the relevant logical breakdown is transferred into RWB in The implementation built by the CRYSTAL project is
order to allocate System RAM performance requirements (e.g. using:
Mean Time Between Failure, Mean Time To Repair) to IBM Systems and Software Engineering (SSE) platform
logical blocks. as ALM repository for managing System Design
Development data (from requirements to System Models).
This implementation is based on the Jazz platform that
provides the basic services shared through Web
Applications which deliver all the requested
functionalities via OSLC links.
Siemens Teamcenter as PDM repository for managing
Physical Data under Configuration Control associated to
Design Data such as Computer Aided Design data, in an
OSLC compliant version.
The use of OSLC for the linked data supported the
realization of the scenario shown in Fig. 6 in which artefacts
in different repositories are linked together.
In addition, the PLM is an environment which can support
different Product Views all along Product Lifecycle for
System Integration, Configuration Management and Data
Fig. 5. Synchronization among RAMS Analysis and Design platforms Management Processes. The different Product Views of a
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
typical Aeronautical Product are the As Required, As
Conceived, As Designed, As Planned, As Built and As
Maintained views, as shown in Fig. 7.
Fig. 8. Data Model for ALM/PDM interoperability
Fig. 6. PLM Environment
The link joining the data between the ALM and PDM
environments is the “Implemented by”. In order to validate the
improvements, a detailed scenario related to a Change
An objective of the CRYSTAL project is to improve the
Management process during Preliminary Design Review has
interoperability between the ALM platform and the PDM
been defined and implemented.
commercial solutions. To minimize data duplication, a specific
data model has been defined as illustrated in Fig. 8. In our
CRYSTAL scenario implementation, focusing on the D. Design Review and Basic Release Change Scenario
Preliminary Design Phase, it has been decided that the The interoperability between the ALM and PDM
management of the System Element artifacts as Configuration environment has been implemented in a Basic Release Change
Items shall be performed in the ALM environment only. Scenario authorized following the successful accomplishment
System Elements are instantiated as Blocks of Internal Block of a Preliminary Design Review (PDR) in accordance with
Diagrams in the SysML view of the logical/physical ALM/PDM reference interactions described in Fig. 9.
architecture, while System Function artifacts are instantiated
as Activities in the Activity Diagrams of the SysML view and
are allocated on System Elements. They are linked using
OSLC to the Physical Elements of the “As Designed view” in
the PDM environment.
Fig. 9. ALM/PDM Change Process reference interactions
Fig. 7. PLM Product View
Before Preliminary Design Review, a Change Request is
created in order to authorize the Preliminary design
(functional and physical). A Request is created in the ALM
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
environment asking for Requirements, Functional and Safety IV. CONCLUSION
Analyses, while another request is created in PDM In our Case Study we had the objective of identifying the
environment asking for Preliminary Physical Product needs in terms of methods, practices, data models and tools
definition. A link between the two Change Requests have to interoperability required when setting up a structured,
be created. integrated and robust System Engineering development
During the same Review preparation, Requirement environment. Then we had to select those technical solutions
Traceability and Verification is then performed. proposed in the context of the project research activity that
After Review a parallel flow for Change Notice in both would be beneficial for supporting our needs.
ALM and PDM environments is launched in order to release We tested different MBSE approaches when designing the
the Requirement Baseline, the Functional Baseline and the systems that have been the subject of our exercise, taking into
Preliminary Product System View Structure. account the peculiarities of each of these systems: one is more
“software intensive” (EIMSS), the other is more traditional
E. Requirement Traceability (Fuel). Moreover we associated other discipline analysis to the
By using OSLC links it is possible to connect key artifacts pure functional analysis. In this paper we detailed the
of the System Development Lifecycle. integrated approach with RAMS analysis in order to define
Thus, navigation and reporting functionalities supporting and validate, starting from the Preliminary Design Phases, a
important processes such as Change impact analysis can be Logical architecture followed by a Physical one in order to be
easily ensured. Our implementation demonstrated how compliant with emerging standard in the aerospace field, such
requirements artifacts can be linked via OSLC and traced to a as SAE ARP-4754A.
design implementation developed using Rhapsody and Our approaches produced a significant amount of heavily
MATLAB/Simulink models which were stored in the Design interconnected outputs to be properly managed with dedicated
Manager tool. configuration and traceability tools; the seamless traceability
Data are stored with configurations, called “local between requirements and final output have to be granted all
configuration” in both DOORS Next Generation and Design along the project lifecycle through these “new” MBSE models
Manager. Each local configuration represents a baseline or via the “As Conceived” view that links requirements domain
stream and contains a set of versioned artifacts. (As Required) to the domain of development (As Designed).
Global Configuration Management assembles In order to enforce the required interoperability we
configurations for all contributing applications in order to give implemented a Change Management scenario in a Preliminary
an overall view of Product configuration. Design Review exploring interactions between ALM and
For traceability and impact analysis purposes, OSLC links PDM domains and relevant tool chains.
must be established among artifacts. In particular the link All the processes and tool chains implemented in our Case
“Satisfied by an architectural element” was used to connect Study have been successfully formalized by means of the
requirements to design implementation’s blocks/functions. extended SPEM language and the CRYSTAL Platform
Links can be navigated from requirement to block and vice Builder Data Model.
versa to show connections. Once the objects are linked via The implemented solutions proved to be valid and we were
OSLC, artifacts can be navigated and traceability/impact able to evaluate them in a near operational context.
analysis reports can be generated as shown in Fig. 10. Many of the involved tool providers also consider the
OSLC based Interoperability a promising technology to be
applied. As an Aeronautical company we believe that this
technology can reduce the effort in setting up tools
interoperation and data duplication/exchange with the use of
linked data.
Fig. 10. Impact Analysis Visualization
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.
[3] Odile Laurent, Airbus; Fabien Paganelli,SAGEM; Ivo Viglietti, Alenia
Acknowledgment SIA ; Stéphane Bonnet , CNRS ; Gérard Cristau, Thales TRT ; Nikolaos
The research leading to these results has received funding Priggouris , HAI; Philippe Baufreton, SAGEM. Customization
principles of an aeronautics SLM environment and an illustration on
from research project CRYSTAL (Critical System aeronautics Use Cases, the doors management system and the flight
Engineering Acceleration), funded from the ARTEMIS Joint control system. Embedded Real Time Software and Systems 2012.
Undertaking under grant agreement n. 332830 and from [4] SAE ARP 4754A “Guidelines for Development of Civil Aircraft and
ARTEMIS member states Austria, Belgium, Czech Republic, Systems” – Rev. A- Revised on 12/2010.
France, Germany, Italy, Netherlands, Spain, Sweden, United [5] Object Management Group, System Modeling language, v.1.3, 8 June
2012, http://www.omgsysml.org/.
Kingdom.
[6] Object Management Group, “Software & Systems Process Engineering
Meta-Model Specification Version 2.0,” 1 April 2008. [Online].
Available: http://www.omg.org/spec/SPEM/2.0/PDF.
References [7] The Eclipse Foundation, “Eclipse Process Framework Project (EPF)”
[1] M. Alemanni, E. M. Latino, A.Corallo and E. Valfrè. MBSE Feasibility 2015. [Online]. Available: http://eclipse.org/epf/.
Study to improve PLM Business Solution System Specification and [8] OSLC, “Open Services for Lifecycle Collaboration” 2015. [Online].
Design. 22nd Annual INCOSE International Symposium - Rome, Italy - Available: http://open-services.net/.
July 9-12, 2012 [9] Meta-Object Facility, version 2.5, June 2015,
[2] L. Lo Verde, E. Valfrè, G. Pavan and M. Fioriti. An Alenia Aermacchi http://www.omg.org/spec/MOF/2.5/.
study and experience on MBSE application. 22nd Annual INCOSE
International Symposium - Rome, Italy - July 9-12, 2012
Copyright © (2016) Leonardo-Finmeccanica S.P.A. Permesso concesso a AISE di pubblicare e utilizzare.