Academia.eduAcademia.edu

Figure 8 – uploaded by Mario Merri

See full PDFdownloadDownload figure
Fig. 8: Design Proposal for the Setup of the Testbed The prototype implementations will have to demonstrate that the interoperability can be achieved. Each prototype will act both as a service provider and as a service consumer. To be able to exercise the service provider and consumer operations, a testbed will be used on either side. To reduce the implementation effort, the goal is to work with a shared testbed, which is currently under development alongside the development of the prototypes. A proposed design for this testbed is depicted in Fig. 8 below.

Figure 8 Design Proposal for the Setup of the Testbed The prototype implementations will have to demonstrate that the interoperability can be achieved. Each prototype will act both as a service provider and as a service consumer. To be able to exercise the service provider and consumer operations, a testbed will be used on either side. To reduce the implementation effort, the goal is to work with a shared testbed, which is currently under development alongside the development of the prototypes. A proposed design for this testbed is depicted in Fig. 8 below.

Related Figures (13)

Fig. 1: Functions involved in Mission Planning This section provides an overview of the main functions, interactions, concepts and use cases of Mission Planning and Scheduling of space missions. It should be noted that in the wider context of space mission operations, the term Scheduling is sometimes used to refer to “Plan Execution”. In the context of the Mission Planning and Scheduling standardization activity described in this paper, there is no distinction between the terms Planning and Scheduling and from here on only the term Planning is used.
Fig. 1: Functions involved in Mission Planning This section provides an overview of the main functions, interactions, concepts and use cases of Mission Planning and Scheduling of space missions. It should be noted that in the wider context of space mission operations, the term Scheduling is sometimes used to refer to “Plan Execution”. In the context of the Mission Planning and Scheduling standardization activity described in this paper, there is no distinction between the terms Planning and Scheduling and from here on only the term Planning is used.
Fig. 2: Entities and Functions involved in Mission Planning
Fig. 2: Entities and Functions involved in Mission Planning
Fig. 3: Mission Operations Functional Areas and their Interactions ae Ee Ee ee Re: ee ee ROE ee ee een CCSDS is currently developing a Reference Architecture [3], in which all CCSDS standards can be identified, together with their role and to show how CCSDS standards relate to each other and support the deployment and integration of space systems. Mission Planning encompasses application level functions whose interfaces fall within the remit of the Mission Operations and Information Management Services (MOIMS) area of CCSDS.
Fig. 3: Mission Operations Functional Areas and their Interactions ae Ee Ee ee Re: ee ee ROE ee ee een CCSDS is currently developing a Reference Architecture [3], in which all CCSDS standards can be identified, together with their role and to show how CCSDS standards relate to each other and support the deployment and integration of space systems. Mission Planning encompasses application level functions whose interfaces fall within the remit of the Mission Operations and Information Management Services (MOIMS) area of CCSDS.
A high-level overview of the MPS Information Model is given in Fig. 4. This shows the principal MPS data items and their interrelationships using standard UML notation. The rectangles in the diagram correspond to standard data items. The lines between them define the relationships between those data items. Mission Planning data items are shown in blue. The following principal MPS data items are shown in the diagram:
A high-level overview of the MPS Information Model is given in Fig. 4. This shows the principal MPS data items and their interrelationships using standard UML notation. The rectangles in the diagram correspond to standard data items. The lines between them define the relationships between those data items. Mission Planning data items are shown in blue. The following principal MPS data items are shown in the diagram:
The main characteristic of the Planning Request is that, being a container, it needs to hold references to, or instances of, the constituent information items that are required by the planner and agreed by the interacting parties for exchange at interface level. It has one or more planning activities as the basis of the request. In addition, the request may optionally reference planning events. Information about planning constraints on when a requested activity can or shall be planned may be exchanged as part of the Planning Request, by referencing constraints on the timing or position of Planning Activities, both absolute and relative to Planning Events or other Planning Activities, and on the state of planning resources. The Plan definition is illustrated in Fig. 5. Planning Requests follow the MO Instance Object Pattern, comprising Definition and Instance classes of MO Object, although in this case Planning Request instances can be created without reference to a Planning Request Definition. Request Definitions provide a re-usable template for common Planning Requests from which specific Request Instances can be created and form part of the Planning Configuration Data for a mission planning system.
The main characteristic of the Planning Request is that, being a container, it needs to hold references to, or instances of, the constituent information items that are required by the planner and agreed by the interacting parties for exchange at interface level. It has one or more planning activities as the basis of the request. In addition, the request may optionally reference planning events. Information about planning constraints on when a requested activity can or shall be planned may be exchanged as part of the Planning Request, by referencing constraints on the timing or position of Planning Activities, both absolute and relative to Planning Events or other Planning Activities, and on the state of planning resources. The Plan definition is illustrated in Fig. 5. Planning Requests follow the MO Instance Object Pattern, comprising Definition and Instance classes of MO Object, although in this case Planning Request instances can be created without reference to a Planning Request Definition. Request Definitions provide a re-usable template for common Planning Requests from which specific Request Instances can be created and form part of the Planning Configuration Data for a mission planning system.
FS iro a SENSES SNS ee at ggmear ne etre LEIS re A Planning Activity i is the basic building block for the planning: a meaningful unit of what can be planned. As such, it has to be understood by the planning function. It could eventually be translated to something that can be executed by a plan execution function; this includes telecommands and automation procedures (that may represent any automated telecommand sequence, operational procedure, on-board control procedure, or function).
FS iro a SENSES SNS ee at ggmear ne etre LEIS re A Planning Activity i is the basic building block for the planning: a meaningful unit of what can be planned. As such, it has to be understood by the planning function. It could eventually be translated to something that can be executed by a plan execution function; this includes telecommands and automation procedures (that may represent any automated telecommand sequence, operational procedure, on-board control procedure, or function).
Table 1: Planning Request Service Operations
Table 1: Planning Request Service Operations
Fig. 7 illustrates a generic deployment of MPS services using the Mission Operations (MO) service framework [4] and the Message Abstraction Layer (MAL) [5], with service consumer and provider functions hosted on different deployment nodes. The application level MPS service interaction is shown by the direct interface between service provider and service consumer functions, carrying MPS service messages that are defined in terms of data structures specified in the MPS Information Model. 16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. right 2021 by European Space Agency (ESA). Published by the IAF, with permission and released to the IAF to publish in all forms g yy p' Pp gency yy Pp P
Fig. 7 illustrates a generic deployment of MPS services using the Mission Operations (MO) service framework [4] and the Message Abstraction Layer (MAL) [5], with service consumer and provider functions hosted on different deployment nodes. The application level MPS service interaction is shown by the direct interface between service provider and service consumer functions, carrying MPS service messages that are defined in terms of data structures specified in the MPS Information Model. 16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. right 2021 by European Space Agency (ESA). Published by the IAF, with permission and released to the IAF to publish in all forms g yy p' Pp gency yy Pp P
16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. Copyright 2021 by European Space Agency (ESA). Published by the LAF, with permission and released to the IAF to publish in all form ‘os: Pa SE, ee SE eae: ew ee The Plan Distribution Service is offered by the planning function of an MPS system to enable its users to obtain the Plans output by it, as well as to receive feedback on their status. The service may be used by another planning function in a hierarchical or distributed MPS system, or by an MPS system user.
16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. Copyright 2021 by European Space Agency (ESA). Published by the LAF, with permission and released to the IAF to publish in all form ‘os: Pa SE, ee SE eae: ew ee The Plan Distribution Service is offered by the planning function of an MPS system to enable its users to obtain the Plans output by it, as well as to receive feedback on their status. The service may be used by another planning function in a hierarchical or distributed MPS system, or by an MPS system user.
Table 2: Plan Distribution Service Operations Fe A $41 LAWSUIT SVE Dei V Inv The Plan Execution Control Service is offered by an MPS system’s plan execution function to enable its users to submit (and revoke) Plans for execution; to control their execution at Plan, Sub-Plan and Activity levels; and to receive feedback on their execution status. The Plan Execution Control Service may be used by a planning function, or by an MPS system user responsible for mission operations.
Table 2: Plan Distribution Service Operations Fe A $41 LAWSUIT SVE Dei V Inv The Plan Execution Control Service is offered by an MPS system’s plan execution function to enable its users to submit (and revoke) Plans for execution; to control their execution at Plan, Sub-Plan and Activity levels; and to receive feedback on their execution status. The Plan Execution Control Service may be used by a planning function, or by an MPS system user responsible for mission operations.
ee Se a ee ae a The Plan Information Management Service is offered by the planning function of an MPS system to enable its users to list and retrieve available definitions for MPS data items, including: planning requests, planning events, planning activities, planning resources and MPS system configuration data. The service may also be offered by a plan execution function. Sub-plans are not defined as an MO Object in the MPS Information Model, but are specified by an Identifie associated with the constituent Activity Instances contained in a Plan. This can be used to sub-divide a Plan based or domain (spacecraft or subsystem), operational responsibility, or another criterion. Each Activity Instance can only be associated with a single Sub-plan. Control may be exercised via the service at the level of sub-plans. The service operations are defined in Table 3 below. Only the operations in capability set 1 are mandatory.
ee Se a ee ae a The Plan Information Management Service is offered by the planning function of an MPS system to enable its users to list and retrieve available definitions for MPS data items, including: planning requests, planning events, planning activities, planning resources and MPS system configuration data. The service may also be offered by a plan execution function. Sub-plans are not defined as an MO Object in the MPS Information Model, but are specified by an Identifie associated with the constituent Activity Instances contained in a Plan. This can be used to sub-divide a Plan based or domain (spacecraft or subsystem), operational responsibility, or another criterion. Each Activity Instance can only be associated with a single Sub-plan. Control may be exercised via the service at the level of sub-plans. The service operations are defined in Table 3 below. Only the operations in capability set 1 are mandatory.
Table 4: Plan Information Management Service Operations The Plan Edit Service is offered by an MPS system’s plan execution function to enable its users to modify Plan: that have already been submitted for execution. It allows an external user or function to update the status of the Plan insert, modify or delete planning activity and event instances; update the value of resources; and apply a time shift tc a Plan.
Table 4: Plan Information Management Service Operations The Plan Edit Service is offered by an MPS system’s plan execution function to enable its users to modify Plan: that have already been submitted for execution. It allows an external user or function to update the status of the Plan insert, modify or delete planning activity and event instances; update the value of resources; and apply a time shift tc a Plan.
5. Prototyping Activities 16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. Copyright 2021 by European Space Agency (ESA). Published by the LAF, with permission and released to the IAF to publish in all forms. es As a proof of concept for the Mission Planning and Scheduling Services standard, two prototypes will have to be implemented. These prototypes shall independently demonstrate that the definitions found in the MPS Blue Book are comprehensive, self-explanatory, sufficient and implementable. ESA and DLR agreed to serve this task and will share a common test scenario covering the mandatory functionalities of the standard.
5. Prototyping Activities 16th International Conference on Space Operations, Cape Town, South Africa — 3 - 5 May 2021. Copyright 2021 by European Space Agency (ESA). Published by the LAF, with permission and released to the IAF to publish in all forms. es As a proof of concept for the Mission Planning and Scheduling Services standard, two prototypes will have to be implemented. These prototypes shall independently demonstrate that the definitions found in the MPS Blue Book are comprehensive, self-explanatory, sufficient and implementable. ESA and DLR agreed to serve this task and will share a common test scenario covering the mandatory functionalities of the standard.
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved