EGS-CC specification is based on a number of concepts defined during phase A, which provide the principles of the way the system will work. Concepts are the result of discussions and agreements between the EGS-CC stakeholders, based on extensive experience in operating and validating satellites.
The Monitoring and Control Model (MCM) provides the functional core of the EGS-CC kernel. It includes the capability to model the complete space system from a monitoring and control perspective. It encapsulates the main monitoring and control functions (e.g. parameter processor, activities handler, events processor) and provides access to all data of Monitoring and Control (M&C) relevance, thus acting as an abstraction layer for M&C operations. It is based on the principles of the M&C view of the Space System Model (SSM) defined within the ECSS E-ST-70-31C Ground Systems and Operations – Monitoring and Control Data Definition [4]. Information is organized in a structured way which reflects the functional decomposition of the space system, including the controlled system as well as the control system itself and covering both the Space Segment (e.g. a satellite or launcher) and Ground Segment (i.e. the overall infrastructure required during Development, Assembly, Integration and Testing and for Operations) for the AIT or operational contexts.
The Figure shows how the space system is represented in the MCM as a hierarchy of System Elements (SE). The system element is a data structure whose properties provide the means to organise the space system knowledge in a hierarchical structure. From the highest level downwards, this is typically: system, subsystem, set, equipment or software product, assembly, part (hardware) or module (software), but it is not required to be a one-to-one mapping of the physical decomposition of the space system. The space system monitoring and control knowledge is categorised into activities, events and reporting data, according to the following definitions:
Although the MCM organises reporting data, activities and events into a more logical structure, the view presented to the end user can be customised as required. For example, it is still possible for the end user to view and interact with the system as a more traditional flat list of parameters and commands if so desired. The MCM concept ensures a clean separation between the M&C abstract view and generic processing and the specific processing related to the data units exchanged with the controlled system. This approach allows the application of the same M&C kernel to different types of controlled systems, such as spacecraft, SCOE equipment, ground station equipment, etc. It means that the M&C system can control not only the target system (e.g. a spacecraft), but also all other contributing ground systems (e.g. EGSE supporting equipment, and the EGS-CC itself), with which the exchanged data are not necessarily based on TM/TC packets. Knowledge about the space system can be "static" or "dynamic" in nature.
The MCM static knowledge is stored in the M&C database while the dynamically generated MCM state information is stored in a data archive.
The MCM is a model of the complete space system for the purpose of monitoring and control. The main inputs to the MCM therefore is monitoring data received from the controlled system, referred to as source monitoring data. There is also other data generated by the EGS-CC applications inside and outside the kernel which can change the state of the MCM (e.g. requests to initiate activities). Both the raw data received from an external system (e.g. the controlled system) as well as the internally generated source data are stored in a source data archive. The source data is fed into an MCM processing model which generates the dynamic state of the MCM which is stored in the processed data archive.
The processed data archive is populated with data from the MCM processor when raw data is received from the controlled system in live mode or when the raw and internal data stored in the source data archive is re-processed in playback or reprocessing mode. The processed data may be retrieved from the processed data archive at any stage and does not require the (re)processing of data stored in the source data archive in order to be returned to the retrieving application in an engineering meaningful form.
The EGS-CC system comprises of the software source code and binaries for a given EGS-CC based system, applied to a specific application and mission. The system is composed of at-least the EGS-CC Kernel which is independent of a specific mission, specific adaptations and any other additional auxiliary systems. A system instance is a particular system release installed on a specific target platform. The running system instance is the set of processes executed at run-time, which belong to a single system instance, which can be managed together in terms of start/stop and status monitoring.
The system session is a logical grouping of EGS-CC components belonging to a given running system instance, which use a given tailoring and configuration , dedicated to the processing of the data of a controlled space system and generating a separate set of outputs within the processed data archive. In the context of EGS-CC, tailoring is the process of mission data definition for adapting customised EGS-CC system software (if needed) to a given mission and operations concept, while configuration is the tuning of the configuration parameters for the run-time system (i.e. without the need to recompile the system).
There may be different types of system sessions: operational, simulations, tests, administration, and analysis. Several system sessions can run in parallel, especially in the space AIT environment, producing independent set of results. Within a specific system session, there may be any number of user sessions which provide the execution of a specific context dedicated to a given user.
The EGS-CC is intended to support a number of standards which will enable the EGS-CC to interoperate with other systems and other segments. The open nature of the EGS-CC allows support for standards to be added as specific adaptations, but a number of standards will be supported as part of the base implementation, including:
