American Institute of Aeronautics and Astronautics
An innovative approach to operational validation process
based on CPN (Colored Petri Nets)
Gaetano Censi 1, Sandro Bevilacqua 2, Marco Cerone 3, Claudio De Bellis 4, Fabrizio Faenza 5, Antonio Michetti 6, Simone Nardangeli 7.
Telespazio SpA, Fucino Space Centre, Ortucchio, Italy, 67050 and
Mario Palumbo 8 Gaetanino Paolone 9 Maria Antonietta Fusco 10 University of L’Aquila, Italy, 67100
This paper aims to bring the study carried out in the field of Operation Engineering to accomplish a pre-validation of operational products (mostly processes and procedures). Main objective is to allow the validation (pre-validation) of operational processes, as they are available during the phases of Requirement Analysis and Concept Development. Pre-validation is performed, through the use of Colored Petri Nets (CPN), in terms of correctness of input and output exchanged. Model has been designed and implemented at University of L’Aquila, Department of Industrial and Information Engineering and Economics (DIIIE), on a generic satellites ground control system (telemetry and remote control) by means of CPN Tools.
Nomenclature
CPN = Colored Petri Nets
ECSS = European Cooperation for Space Standardization ILS = Integrated Logistics Support
P/T = Place / Transition OPS = Operations
1 Head of Operations Engineering Department, Fucino Space Centre, Italy / [email protected] 2 EGNOS Program Manager, Head of EGNOS Program, Fucino Space Centre, Italy /
3 Spacecraft Operations Manager, Satellite Operations, Fucino Space Centre, Italy / [email protected] 4 Design engineer, Satellite Systems and Applications – Mission Control Department, Fucino Space Centre, Italy /
5
Ground Operations Engineer, Operations Engineering Department, Fucino Space Centre, Italy / [email protected]
6 Head of In-Site Programs Department, Fucino Space Centre, Italy / [email protected] 7Ground Operations Engineer, Operations Engineering Department, Fucino Space Centre, Italy /
8
Associate Professor of Manufacturing Systems at the University of L’Aquila, Italy
9 External Professor of Business Information Systems at the University of L’Aquila, Italy 10 Graduate student at the University of L’Aquila, Italy.
Downloaded by 134.122.89.123 on April 26, 2021 | http://arc.aiaa.org | DOI: 10.2514/6.2014-1813
SpaceOps 2014 Conference 5-9 May 2014, Pasadena, CA
10.2514/6.2014-1813 SpaceOps Conferences
I.
Introduction
The ILS&OPS Engineering foremost objectives are the preparation of Mission operations and maintenance activities, together with the definition of the support processes and elements aimed at guaranteeing these operations. A dedicated ILS&OPS Engineering Team assures the design and development of all the ILS&OPS Products (Plans, Procedures, Training Materials, etc) since early projects stages, being responsible for:
• managing the implementation of the ILS&OPS design and development tasks and ensuring their consistency, • ensuring that ILS&OPS activities and relevant deliverables are in line with the program requirements, • ensuring the interfaces with the Ground Segment Teams, to encourage a concurrent engineering approach. Upon completion of the preparation phase, a
dedicated ILS&OPS Operational and Maintenance Team will assure the execution phase.
According to ECSS standard (ECSS-E-ST-70C [4,5]) engineering processes, inside each phase, can be summarized as reported in Figure 1.
In particular, ILS&OPS Validation process is meant to validate the Ground system from an ILS&OPS point of view before the launch, including:
• Proper functioning and set–up of the System including internal and external interfaces;
• Correctness and adequacy of Mission Operations data;
• Correctness and adequacy of Logistic Data and Recourses (e.g., spares,…); • Qualification of ILS&OPS personnel;
• Ability of the ILS&OPS Teams to support the mission.
II.
(Ground) System Operational Validation
The execution of the Operation Engineering activities indeed identifies: the Operational Function needed to “operate” the system, the Operational Processes necessary to “run” the Function and eventually the Operational Tasks and procedures which detail (step-by-step) the activities to be done.
The preparation phase of Operations Engineering is achieved by the Validation process that declares: “fully validated ground segment, including personnel and procedures, ready for in-orbit operations and exploitation” [4]. In order to obtain coherent validation scenarios, Operations Engineering, based on an operational analysis, expects that: • applicable technical and operational Requirements are associated to Functions and/or Processes and/or
Tasks;
• Scenarios are created putting in a correct sequential way the operational processes;
• Scenarios are translated into Validation Test Case(s) and executed in specific validation session(s) [1]. A. Colored Petri Nets (CPN) & Ground Operational Validation
A Petri net (also known as a place/transition net or P/T net) is one of several mathematical modeling languages for the description of discrete event systems. Colored Petri Nets (CPN) extend the classical Petri net formalism with data, time and hierarchy making possible to model complex processes. CPN modeling language is a general purpose modeling language used to model a very broad class of systems where concurrency and communication are main features. Typical application fields of CPN are communication protocols, data networks, distributed algorithms, embedded systems, business process, workflow modeling and manufacturer systems [2]. Hence, Colored Petri Nets are particularly suited to modeling operational processes and subsequent scenarios. In fact, CPN allow to model systems whose evolution depends on synchronous and asynchronous discrete events, allowing the verification of properties and the prove of its correctness.
Essentially, each place (drawn as an ellipse or circle) contains a set of markers called tokens and the color set (positioned at the bottom right of the place) specifies the type of tokens the place can hold. Token color describes different objects and thus tokens carry data value of different types. Transitions (drawn as rectangles) inspect token
Figure 1. Operation Preparation and Execution phases
Figure 2. Operational processes block diagram colors and the guard-function, if present, decides if transition is enabled or not. The arcs (drawn as arrows) describe how the state of the net changes when the transitions occur. When a transition is enabled, it can occur by removing tokens from its input places and adding tokens to its output places. The colors of the tokens removed from input places and added to output places are determined by means of the arc expressions that are the textual inscriptions positioned close to each arc.
In Telespazio’s proposed approach, the use of Colored Petri Nets makes it possible to create a math model representing the operational processes defined for a space mission, starting from the idea that it can be viewed as a pool of discrete event systems [6]. In this approach, the verification and validation processes of the operational products can be viewed as validation and verification of discrete event systems. Each main process can be modeled as a set of discrete events that cause state changes corresponding to the activation / deactivation of the different operational tasks with their associated sets of data.
The target is to analyze CPN models of operational processes both from the operational and functional points of view in order to perform a pre-validation of operational processes and scenarios, as well as task, as they are available during the Operations Engineering phases.
B. Operational Analysis and Simulation Model
The operational processes resulting from operational analysis of a generic satellite ground control system are listed below and shown schematically in Figure 2:
• Mission Plan Generation [MPL01] encompassing the activities needed to receive the current Requests List(s) from user(s) and to gather all the input data (i.e., orbital data) necessary to generate the Payload Telecommands file;
• Flight Operations Planning [SMC01]
encompassing the activities needed to develop the Station Plan (to properly book ground stations if more than one ground station is available), to schedule, prepare and translate the on board activities in mission commands sequences (including payload, platform and satellite maintenance telecommands);
• Real Time Flight Operations
Execution [SMC02] encompassing the passes management and the activities related to spacecraft visibility such as pre-pass, pass-surveillance and post-pass;
• Flight Dynamics Operations
[SMC03] encompassing the activities needed to determine and propagate the
Satellite's orbit, to calculate the orbital events and ground stations' passes, to calculate the necessary attitude and orbit correction maneuvers and to support the Satellite's platform;
• Ground Segment Data Ingestion [DAP01] encompassing the activities involved in the reception and routing of the Real Time Telemetry from satellite to the Satellite Control Centre;
• Ground Segment Equipment Monitoring [GMC01] encompassing the activities performed to monitor and
control the whole Ground Control Segment equipment including the antenna and relevant network.
The resulting CPN model consisting of a graph representing the main operational scenario is depicted in Figure 3. Processes taken into account are the ones coming from the operational analysis carried out on the ground segment; particularly, these processes involve operational activities to be performed according to the satellite status. The test scenario involves basic operational processes and related activities to be accomplished at ground station for managing a mission of remote sensing via satellite.
Hence, each substitution transition (drawn as rectangular boxes with double line border) identifies an operational process, with the exception of Satellite model substitution transition on lower right in blue color. The latter has been modeled in order to automatically simulate the alternation of visible and invisible states of the satellite from the ground station. This will result in the activation or deactivation of different processes depending on the current period of the satellite represented by the place Satellite Pass.
On the whole, starting from the user requests corresponding to the red place in the upper left, the execution of the operational processes is based on the satellite status along with the proper data flows required and shall lead to telemetry (TM) data reception and telecommands (TCs) sending to the satellite. Final outputs of the model are identified by the green places in the lower left corner and obtaining them is the assurance of the fulfillment of user requests.
Figure 3. Main Operational Scenario
For the start of the simulation and execution of the model, it is necessary to set an initial marking that is an initial state of the system consistent with the expected operation. In the present case, the initial marking is shown in Figure 4 and it is assumed that:
• the orbital data are provided by the process SMC03; • a programming requests list has been received; • the satellite is not currently visible.
The presence of tokens in the places related to the status identifying the availability of these input data allows the evolution of the whole system. For example, the inscriptions at the upper right side of the places Elaborated Data/TLE, Orbital Data/TLE and Elaborated Orbital Data/TLE specify the initial marking of these places (coloured as OrbitalData) consisting of one token with the colour (value) OrbDataTLE.
This indicates that we want orbital data file as the first data value to be accessible in order to start the operational activities. It should be noted that the three places just mentioned identify the elaboration of the same type of data. This state has tripled since the orbital data have to be made simultaneously (in parallel) available in three different processes.
Figure 4. Main Operational Scenario with initial marking
Figure 5 represents an intermediate status of the system during the satellite invisibility obtained by simulating the net for some iterations starting from its initial state. Specifically, the system status shows an accumulation of user requests incoming to the process MPL01. In the same time span, and in accordance with these request lists, the process SMC01 elaborated both the list of mission commands (payload and platform telecommands) to be sent to the satellite and the Station Plan. In order to produce its outputs, SMC01 had to receive, during a previous system status, all the necessary input data (i.e., Orbital Data from the process SMC03 and Payload Telecommand file from the process MPL01). In the end, the state illustrated means that everything is ready to manage the satellite visibility. Actually, the reference antenna, monitored by the process GMC01, is properly operating and the process DAP01, responsible for the satellite acquisition during its pass, receives all the necessary resources such as orbital data and Station Plan.
Figure 5. Main Operational Scenario during an intermediate status
Finally, Figure 6 shows the system status during satellite visibility. In particular, SMC02 processes the raw telemetry received by DAP01 in a previous state and sends the list of telecommands (both payload TC and platform TC) to the satellite. It should be noted how the user requests have now been disposed. Moreover, the process DAP01 sends to the process SMC03 the orbital data of ranging measurement and angular data type (referred to, in the model, as RngMeasAndAngData colour of the token), downloaded directly from the satellite. These data will be used by the process SMC03 to refine the orbital position for the next passes.
Figure 6. Main Operational Scenario during satellite visibility status
The scenario model has been organized as a hierarchical one, as allowed by the CPN models, associating a module (i.e., an operational process) with each substitution transition. When a module is linked with a substitution transition it becomes a submodule. In CPN Tools the substitution transitions can be recognized by a double line border and by a rectangular submodule tag positioned close to them that contains the name of the submodule related to the substitution transition. Each submodule presents a more detailed view of the behavior represented by the relevant substitution transition. In other words, every process can be further detailed with its own activities and data flows. For instance, the submodule concerning to the Flight Operations Planning [SMC01] process is depicted in Figure 7 and Figure 8 and it models all the operational tasks necessary to “run” the process itself. In detail, the operational tasks defined for the process are the following:
• TC Command File Generation: performing the telecommands file generation about the payload
activities;
• S-band Station Booking: performing the necessary activities to booking the S-Band Station.
The proper execution of the process requires the knowledge of the orbital data previously processed by the process SMC06 and the list of payload commands supplied by the process MPL01 based on user requests.
Figure 7 explains the process status during which all these input resources are prepared for the related tasks so become enabled. Therefore tasks are “lit” green, according to mean they are ready to perform their duties in parallel. After the shot of both transitions (i.e., of both tasks), the next process status shown in Figure 8 defines that the outputs data has been generated. Notably, the activity TC Command File Generation [SCC-PROG01] has produced the file containing all the mission plan commands necessary to get the payload activities; while the activity S-Band Station Booking [SCC-PROG02] has detailed the Station Plan. Since the Station Plan has to be communicated to both the process DAP01, for the S-Band acquisition, and the process SMC02, for the real time operations execution,
two transmission channels (i.e., two identical places) of the Station Plan are essential. The input and output places constitute the interface through which the SMC01 module exchanges tokens with the other modules. The SMC01 module will import tokens via the input ports and will export tokens via the output ports. The same is applicable for the other modules. In CPN Tools, these ports can be recognized by the rectangular port-type tags positioned close to them specifying whether the port place is an input, output, or input/output port.
Figure 7. SMC01 submodule (initial status) Figure 8. SMC01 submodule (final status) It is very important to emphasize that it is possible to increase the level of detail for each process by associating with each transition (i.e., each task of the sub-module), drawn as rectangular box, a substitution transition. Then it is possible to define more elementary activities for each task, in a process involving ever greater levels of detail according to the operation needs. This is possible thanks to the hierarchical structures of the CPN models, not allowed by the classical Petri Nets.
From the validation point of view, it is possible to investigate the development of all the modeled processes and scenarios using simulation.
CPN Tools offer, in fact, interactive simulations where the results are presented directly on the CPN diagram as figuredin the previous pictures. As a result, the operational processes and scenarios can be pre-validated through the analysis of their CPN model which is an executable model representing the states (places marking) of the operations and the actions (transitions) that can cause the system to change state. The validation by CPN models enables to monitor and check the designed data flows and the behavior of each process with respect to the requested inputs, the expected outputs and to the overall state of the system.
III.
Conclusion
The application of Colored Petri Nets to the Operations Engineering field has mostly been based on the association of processes and tasks to transitions, places to the specific states of processes and tasks, token colors to the kind of information needed, arc expressions to the data to be processed or transmitted. Consequently the flows of tokens here represent the resource flows exchanged among the various operational processes and tasks. The availability of the input data required by a process or task is identified by means of tokens into the places in the inlet of the relevant transition. The outcomes of each activity are captured by the specified state change of the transition through the presence of tokens into its output places.
The pre-validation of operational processes and scenarios can be considered successfully passed if each modeled and simulated process provides the correct outputs in relation to the inputs and its current state. Also it is possible to get information about any anomalies in the system through the observation of the live transitions and the undesirable accumulation or lack of tokens.
Moreover, the realization of the same CPN models supplies the signal of the correctness of designed processes, and of their interactions into operational scenarios, by means of the constraints imposed by the structure of these nets.
The adopted use case for the validation (pre-validation) of operational processes by means of CPN has demonstrated that is possible to anticipate the validation of processes, scenarios and tasks obtained from the earliest stages of the operational analysis (Requirement Analysis and Concept Development); this pre-validation allows to anticipate possible operational inconsistencies, accelerate the validation of formal operational validation, focusing on end-to-end scenarios. Indeed, CPN put into evidence interactions between processes and involved data flows.
Accurate modeling through CPN could be usefully adopted to validate operational scenarios in such a way that subsequent validation sessions could be reduced, avoiding completely, in best of cases, the “check” of Operational Processes. In the latter case, it would be possible to concentrate the activity of ILS&OPS engineers on staff training and go straight to verify the staff readiness.
References
Reports, Theses, and Individual Papers
1. M. A. Fusco, “Satellite Mission Operations Engineering and an innovative approach to operational validation based on Colored Petri Nets”, Thesis, Department of Industrial and Information Engineering and Econonics (DIIIE), University of L’Aquila, AQ, 67100, 2014
2. K. Jensen, L.M. Kristensen, and L. Wells. Coloured Petri Nets and CPN Tools for Modelling and Validation of Concurrent Systems. International Journal on Software Tools for Technology Transfer (STTT)9(3-4), pp. 213-254, 2007
Computer Software
3. CPN Tools 4.0 , Eindhoven University of Technology, The Netherlands( http://cpntools.org/) Books
4.Space Engineering. Ground systems and operations. ECSS-E-ST-70C - 31 July 2008 5.Space Engineering. Ground systems and operations. ECSS-E-ST-70C. Chaps. 5, 6 Proceedings
6.C. De Bellis, T. Compagno, (ed.), Modello di un Ground Segment Satellitare con reti di Petri Colorate, Finmeccanica Innovation Award 2012, Telespazio, Rome 2012
