=Paper=
{{Paper
|id=Vol-2248/paper14
|storemode=property
|title=Capturing Architectural Artefacts in a Configuration Management Tool
|pdfUrl=https://ceur-ws.org/Vol-2248/paper14.pdf
|volume=Vol-2248
|authors=Vittorio Torroni
|dblpUrl=https://dblp.org/rec/conf/ciise/Torroni18
}}
==Capturing Architectural Artefacts in a Configuration Management Tool==
https://ceur-ws.org/Vol-2248/paper14.pdf
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