- After the Production stage the PDGS system is verified and deployed in operation. If a traditional document based approach has been used, hundreds of documents has been written and the cost to change the pattern is very high. The aim of this paper is to present an “Hybrid MBSE” approach that can helps the SE in managing the Validation and Operation processes. This approach focus on the modelling of key information useful for managing Space Administration Phase E in a most effective way. Overall documents generated during the previous phase are referenced by the model and maintained under configuration control.
Normally in the Space Sector, phase E is not managed and operated by the same team (customer/industry) responsible of the previous phases. Currently the document centric approach is still the most used in previous phases so the possibility to inherit a model that can be used to manage operation phase is quite low. However, the Operational Teams does not need to go in the system detail design but still can get benefit in terms of work effectiveness from the creation of a model that describes the keys aspect and refers the documentation baseline. The proposed approach has been used during the Sentinel 5P transition from E1 to E2 phase and is currently used for the management of S5P Operation (Phase E2). Diagrams shown in this paper are examples extracted from the S5P Operation Model and have been generated using Enterprise Architect with Office MDG Integration. The approach refers to EA Suite but can easily adapted to a different tool providing the same functionality. The following section describes the approach used, while last section shows an example of approach implementation.
The main activities performed during the validation and operation phase are: Validation of the system versus user requirements; Documentation Baseline Management; NCR and CR analysis.
In order to manage effectively the above activities the SE automatically extracts from the available documentation (e.g. User Requirement Document, System Requirement Document, Architectural Design Document, Master ICD Document, Validation and Verification Plan, etc) and imports in the model key information like: requirements, building block, interfaces, testing procedures, data type, documents. Model can be populate starting from an editable Word Document (if not available the SE can use a pdf/doc converter) or Excel Document. The SE needs to properly reformats documents so that key information is marked with a proper style or header and use EA Office MDG Plugin (after the configuration of a proper template), to automatically import design elements and relations. SE can then manually refine the Model in order to group the information properly and create diagrams. Imported entities are linked to the documentation from which they has been extracted so that SE can quickly moves between model and documentation in order to look at detail not available in the model. SE can also decides to update the model with additional information included in the document that can be useful in the future.
The first activity performed at the end of phase E1 (and before starting E2) by the Operational Team was to validate what has been produced in the implementation stage versus the user requirements. Using the methodology described in the previous section, the Operational Team SE imported system/user requirements and validation procedures. While reading the procedure is “easy” to understand if a referred requirement has been tested as expected it is quite difficult to check that all User Requirements are properly traced by system requirements and by validation procedure. Typically, documentation includes traceability matrix but the review of the traceability performed just inspecting the document could be time consuming and mistake can be missed (e.g. requirements or procedures missing in the traceability matrix or referring removed entity). Using the approach described above the SE, reducing the time for checking and guaranteeing that no error are missed, was able to detect: 6 user requirements not properly traced by system requirements (mainly typo in the traceability); About 40 system requirements not referring to any user requirement; About 20 procedures not referring to any system requirement; About 10 system requirements not traced by any procedure (mainly typo in the traceability).
Sparx EA allows displaying a traceability matrix and highlighting missing relation in both direction (see Fig. 1). link/reference generated in the model the risk to underestimate impacts is heavily reduced. Usually using document based approach the management of the documentation baseline is mainly done ingesting document in a repository/DMS allowing cataloging and configuration control, typos/errors in the management of a documentation tree are quite common. An MBSE approach allows to create a documentation tree in order to define dependences in documents and to proper assess any impact of a document update. Using the CIDL document entities are automatically created in the model and using applicable and reference table dependency and/or generalization link can be created (see Fig. 2). To analyze NCR and CR impact properly the Operational Team SE imported for related documentation additional entities like Interfaces, DataType and Process. These entities were linked to the documents entities in order to allow the SE to quickly identify using the model where the imported entity is described in detail. During the operational phase, one of the main user of S5P data requested to have CH4 data within 2 days from sensing. So S5P Mission Manager requested an analysis to SE. Browsing the model he identified a dependency of the CH4 processing from Cloud NPP processing (L2_NP_*) and a dependency of Cloud NPP processing from the availability of VIIRS auxiliary data (Fig. 3). After an analysis on the delivery policy of the VIIRS data the SE prepared a maintenance diagram where all the needed changes and impacted entities are identified (Fig. 4). Analysis was completed in less than one day and thanks to
Thanks to the described approach, it was possible to create an operational model for S5P in less than three working weeks. Future improvement would be to create ad hoc template in order to automatically generate a subset of the project document (MICD, CIDL, TNs, …).