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.