Capturing Architectural Artefacts in a Configuration Management tool Vittorio Torroni Serco Italia Frascati, Italy Copyright © held by the author Abstract— too many architectural artefacts are lost in the features of the CM and Service Management tool transition from the Design to the Operations phase. This paper used to support the the O&M processes; shows how to extract key architectural information from a System Model or set of documents and translate them into  Section III describes the process that was adopted artefacts that can be added to a Configuration Management tool to translate the need to perform automated and to facilitate change impact analysis. robust Change Impact Analysis into specific updates applied to the CM tool; Keywords—Configuration Management; Transition Stage; System Modelling; Change Impact Analysis; Service Management  Section IV illustrates the lessons learned from this exercise and provides recommendations on the choice of tools to facilitate the implementation of I. INTRODUCTION this method in other contexts; The Systems Engineering (SE) good practices described in the INCOSE SE Handbook [1] focus on the activities performed in the Concept and Development stages, in order to avoid discovering costly mistakes later in the Production and II. CRYOSAT-2 PDGS CONTEXT Utilization/Support stages. ESA’s CryoSat mission is dedicated to measuring the Unfortunately, in practical applications, this emphasis on thickness of polar sea ice and monitoring changes in the ice requirements and design often translates in using the SE sheets that blanket Greenland and Antarctica. approach and methods in the requirements, architecture and A general description of the mission can be found in [2] design definition processes, and abandoning them in the and a description of the PDGS can be found in [3] (this paper Operations and Maintenance processes. A typical symptom of references only information sources that are in the public this approach is that important System Model information domain; references to specific software vendors have also been (regardless of whether they were defined in a System omitted). Modelling tool or in architectural documents) are not handed over to the Operations and Maintenance (O&M) teams. For In summary, the measurements of the radar altimeter on- example, if the Design team used a modelling tool, the O&M board the spacecraft are downloaded to the ground, where team often does not perceive the value of using it to support dedicated HW and SW infrastructure archives the raw data, O&M processes. processes them to create scientific products, and distributes them to the scientific community. The PDGS also provides the This approach makes it difficult to perform Change Impact functionality to decide which measurement type to perform in Analysis as part of the O&M processes. What O&M teams do which geographical area. always use is a Configuration Management (CM) tool, which may be integrated with other tools, such as Anomaly During the Transition stage, a set of documents was handed Management, Documentation Management, etc. over to the O&M team. These documents included the standard set of technical documents: requirements documents, This paper presents the results of a case study, performed in architectural design documents, Interface Control Documents the framework of the Operations and Maintenance of the (ICD), format specifications, and list of Configuration Items CryoSat-2 Payload Data Ground Segment (PDGS), managed (CI). by the European Space Agency (ESA), directorate of Earth Observation Programmes, Ground Segment Infrastructure and The entire set of O&M processes is implemented as a Operations Management Division. Service, which is managed using an ISO-20000 [4] compliant Service Management Tool, which implements the Incident The paper is organized as follows: Management, Problem Management, Change Management,  Section II provides a description of the CryoSat-2 Release Management and Configuration Management PDGS context, the architectural information processes. handed over by the Design team, and the main The tool provides the capability to define a new CI and  The CI class that was chosen to represent external assign it to a class, chosen among a set of pre-defined classes. service providers was “Data Center”: this not an The tool also allows to define a relationship between two CIs, ideal name, but it was the closest match among the where the relationship name and type is chosen among a set of list of possible classes; pre-defined relationships. In the context of the CryoSat-2 PDGS, all interfaces are The tool does not provide the functionality to define new CI implemented, at SW level, as exchange of files. classes and new relationship types: this constraint represents the biggest challenge to overcome. In order to implement requirement n.2, it was necessary to take into account the fact that the CM tool does not allow using the same relationship name to connect different pairs of CI classes, III. DESCRIPTION OF THE PROCESS so for example the relationship “interfaces with” can only be Following good SE practices, the process has been broken established between a pair of CI of class “Application”, down in the following steps: whereas the relationship “Exchange Data with” can only be established between a CI of type “server” and another CI of 1. Identify needs; type “server” or “Data Center”. 2. Derive requirements and constraints; The CM tool used was already compliant with requirement n.3. 3. Define solution; Figure 1 below shows an example of how the CM tool, after 4. Test solution; the implementation, allows to display all the interfaces of a specific CI. 5. Implement changes; The main need is to facilitate change impact analysis: when a change needs to be applied to a CI, it is necessary to assess the impact that it will have on other CIs. If this analysis is not performed, deploying the change could break one or more interfaces. Without having the support of a SW tool, the change impact assessment needs to be performed manually, by collecting all the ICDs where the CI to be modified is involved, and determine if any other CI requires modification. This manual assessment is error prone and relies on the documentation to contain the correct, complete and up-to-date set of information required, which might not always be the case if the design documentation is not maintained by the O&M team. The requirements derived from the need are: Fig. 1. Displaying the interfaces of a CI. 1. Each component described in the architectural documentation should correspond to a CI in the IV. LESSONS LEARNED AND RECOMMENDATIONS CM database; The successful completion of this exercise has shown that it 2. Each interface described in the architectural is possible to implement a mechanism that facilitates a robust documentation should be implemented as a change impact assessment by using only a CM tool. relationship between two CIs; In this example, the starting point was a System description 3. The CM tool shall provide the capability of captured in a set of documents, but if a System modelling tool selecting a CI and displaying all its relationships is used, the model could be exported (e.g. as XMI [5]), or, if with other CIs; both the System modelling tool and the CM tool support it, an OSLC service [6] could be implemented that automatically In order to implement the requirement N.1, new CIs have creates CIs and relationships in the CM tool starting from the been created: components and interfaces defined in the modelling tool.  A set of CIs that describe external service Another possible approach is to adopt the approach defined in providers (these were originally not present the Modelling and Simulation High-Level Architecture (see [7] because their configuration control is performed and [8]) to ensure interoperability between tools used in the by the service providers); Design phase and tools used in the Operations and Maintenance phase.  A set of CIs that describe the fact that different instances of SW applications might have the same binary executables but different configurations; ACKNOWLEDGMENT initiative. In Proceedings of the 20th International Symposium on Distributed Simulation and Real-Time Applications (pp. 100-107). IEEE The author would like to thank the ESA staff at the ESRIN Press. site for authorizing this exercise and provide the necessary [8] Möller, B., Garro, A., Falcone, A., Crues, E. Z., & Dexter, D. E. (2017, resources to implement the recommended changes to the CM October). On the execution control of HLA federations using the SISO tool. space reference FOM. In Distributed Simulation and Real Time Applications (DS-RT), 2017 IEEE/ACM 21st International Symposium on (pp. 1-8). IEEE. REFERENCES [1] INCOSE, “Systems Engineering Handbook”, INCOSE-TP-2003-002-04 [2] https://www.esa.int/Our_Activities/Observing_the_Earth/CryoSat [3] https://www.esa.int/Our_Activities/Observing_the_Earth/CryoSat/Data_ flow [4] ISO/IEC 20000 Information technology - Service management [5] https://www.omg.org/spec/XMI/2.5.1/ [6] http://open-services.net/ [7] Möller, B., Garro, A., Falcone, A., Crues, E. Z., & Dexter, D. E. (2016, September). Promoting a-priori interoperability of HLA-based Simulations in the Space domain: the SISO Space Reference FOM