GMES Sentinel-3 Mission Planning Facility (MPF) Design Justification File (DJF)

skillfulwolverineSoftware and s/w Development

Dec 2, 2013 (3 years and 10 months ago)

174 views




© EUMETSAT

The copyright of this
document is the property of EUMETSAT.

























Doc.No.

:

EUM/LEO
-
SEN3/DOC/12/0091

Issue

:

v1E Draft

Date

:

8 November 2012

WBS

:

-

GMES Sentinel
-
3 Mission Planning
Facility (MPF) Design Justification
File (DJF)

EUMETSAT

Eumetsat
-
Allee 1
, D
-
64295 Darmstadt, Germany

Tel: +49 6151 807
-
7

Fax: +49 6151 807 555

http://www.eumetsat.int




GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
2

of
106

Document Signature Table


Name

Function

Signature

Date

Prepared by:

S3MPF

Team

GMV

X
S3MPF Team

25
/
10
/2012

Reviewed by:

Santiago Ledesma
Subirán

GMV Quality
Manager

X
Santiago Ledesma
Quality Manager

25
/
10
/2012

Approved by:

Fran Colmenero Lechuga

GMV Project
Manager

X
Fran Colmenero
Project Manager

25
/
10
/2012

Reviewed by:

Chris Stuart

EUM
S
-
3 MPF
Engineer

X
Chris Stuart
Technical & Operational Interface


Reviewed by:

Vincent
Fournier
-
Sicre

EUM

S
-
3 PDGS
Procurement
Engineer

X
EUM Reviewer


Reviewed by:

Francesco Croce

EUM

M&C
Applications Team
Leader

X
EUM Reviewer


Approved by:

Robert Cunningham

EUM S
-
3 FOS
Manager

X
Robert Cunningham
Procurement Management (FOS)



Distribution List

Distribution list

Name

No. of Copies

Chris Stuart

Electronic
distribution

Vincent Fournier
-
Sicre

Electronic distribution

Francesco Croce

Electronic distribution

Robert Cunningham

Electronic distribution




GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
3

of
106

Document Change Record

Issue /
Revision

Date

DCN.
No

Changed Pages / Paragraphs

V1A
Draft

21
st

February

201
2


First draft version delivered for SWRR.

V1B
Draft

20
th

April 2012


Issue updated after SWRR dispositions in
accordance with all identified actions as follows

-

Updated version and date of FRS in section
2.1

-

Corrected Document Signature and
Distribution list due to the implementation of
RID#9 and RID#10 (S3MPFSRR
--
EUM
-
FC
-
009 and S3MPFSRR
-
Al/GMV
-
EUM
-
FC
-
010).

-

RID #5
8 (
S3MPFSRR
-
A19/GMV
-
EUM
-
CSt
-
058
):

Fixed indentation in the “design
drivers” paragraph of Section
3
.

-

RID #59 (
S3MPFSRR
-
A19/GMV
-
EUM
-
CSt
-
059
):

Updated Section
4.2
.

-

RID #50 (
S3MPFSRR
-
A19/GMV
-
EUM
-
CSt
-
060
) : Updated Section
4.3.1.1

-

RID #65 (
S3MPFSRR
-
A19/GMV
-
EUM
-
CSt
-
065
) : Updated Section
5.1.4.8

-

RID #66 (
S3MPFSRR
-
A19/GMV
-
EUM
-
CSt
-
066
) : Fixed broken reference in Section
5.1.10.1.2

-

RID #128 (
S3MPFSRR
-
A19/GMV
-
ESA
-
JPB
-
021
) : Updated Section
5.1.5.1

-

Added Open Issues section
2.3

due to RID
#123 (
S3MPFSRR
-
A17/GMV
-
ESA
-
JPB
-
016
)



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
4

of
106

V1C Draft

2
nd

August 2012


Document updated according to upgrade of
baseline documentation. The following sections
have been updated:

-

Section
1.1
: updated scope of document to
eliminate draft version

-

Section
2.1
:
updated applicable documents

-

Section
2.3
: updated Open Issues

-

Section
5.1.12.1
:
T
ime formats handling
(
S3
-
MPF
-
80
)

-

Section
5.1.2

and
5.1.13
:

The E
xternal
I
nterfaces

-

Section
5.1.4.4
:
Usage of resources by
FOS Events

(
S3
-
MPF
-
1440
)

-

Section
5.1.4.9
: Request and FOS Event
Definition file generation

(
S3
-
MPF
-
1555
)

-

Section
5.1.6.1
: The MTP functionality (S3
-
MPF
-
1760)

-

Section
5.1.16
: updated to correct the
name of the interface Station Acquisition
Plan

-

Sections
5.3

and
5.4

updated to make
reference to other documents.

V1D Draft

25
th

Octobe
r

2012


Document updated after PDR

dispositions in
accordance with all identified actions as follows
:

-

RID #21
7

(
S3MPFPDR
-
A3/EUM
-
FC
-
002
)
:
Updated sections

2.1
.

-

RID #218 (
S3MPFPDR
-
A3/EUM
-
FC
-
003
):
Updated sections
2.1

and
2.2
.

-

RID #220 (
S3MPFPDR
-
A3/EUM
-
FC
-
003
):
Updated section
5
.4
.

-

RID #236 (
S3MPFPDR
-
A3/EUM
-
JVi
-
001
):
Updated
paragraph in
section
5.2.1
.

-

RID #237 (
S3MPFPDR
-
A3/EUM
-
JVi
-
002
):
Updated paragraph in section
5.2.1
.

-

RID #251 (
S3MPFPDR
-
A19/GMV
-
ESA
-
GI
-
007
): section
4.3.6.2

updated to explain
NPIF CC processing implications.

-

RID #252 (
S3MPFPDR
-
A19/GMV
-
ESA
-
GI
-
008
): Updated paragraph in section
5.1.4.8
.

-

RID #253 (
S3MPFPDR
-
A19/GMV
-
ESA
-
GI
-
009
): Updated table of contents and fixed
missing references

in section
5.1.12.5
.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
5

of
106




GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
6

of
106

Table of Contents

1

Introduction

................................
................................
................................
................................
..

7

1.1

Purpose and Scope

................................
................................
................................
.............

7

1.2

Docum
ent Structure

................................
................................
................................
............

7

2

References

................................
................................
................................
................................
...

8

2.1

Applicable documents

................................
................................
................................
.........

8

2.2

Reference documents

................................
................................
................................
.........

8

2.3

Open Issues

................................
................................
................................
........................

8

3

Design Description

................................
................................
................................
......................

8

4

Design Justification File Synthesis

................................
................................
...........................

9

4.1

Introduction

................................
................................
................................
........................

10

4.2

Open Issues/Critical Points

................................
................................
...............................

11

4.3

Requirements Synthesis: Overview of the Sentinel 3 Mission Planning Process

............

12

4.3.1

Mission E
nvironment Preparation

................................
................................
........

12

4.3.2

Instrument and SVM Events Generation

................................
..............................

19

4.3.3

Mid Term Plan

................................
................................
................................
......

21

4.3.4

Schedule Generation

................................
................................
............................

22

4.3.5

Conflict Detection and Resolution

................................
................................
........

24

4.3.6

Output Files Generator

................................
................................
.........................

26

4.4

Non
-
conformance’s Requirements
................................
................................
....................

28

5

Justification of the Functional Architecture

................................
................................
...........

28

5.1

Proposed Delta Architectural Design

................................
................................
................

29

5.1.1

High
-
level components

................................
................................
.........................

31

5.1.2

External Interfaces

................................
................................
...............................

32

5.1.3

Modifications to the main HMI process

................................
................................

37

5.1.4

Modifications

to the MEP
................................
................................
......................

39

5.1.5

Modifications to ISEG

................................
................................
...........................

53

5.1.6

Modifications to
MTP

................................
................................
............................

57

5.1.7

Modifications to SG

................................
................................
..............................

60

5.1.8

Modifications to CR

................................
................................
..............................

61

5.1.9

Automation of the schedule generation process (new module)

...........................

68

5.1.1
0

Output files generation (new module)

................................
................................
..

69

5.1.11

Modifications to RAE

................................
................................
............................

77

5.1.12

Modifications to Common Services

................................
................................
......

87

5.1.13

Modifications to the External interfaces

................................
...............................

94



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
7

of
106

5.1.14

Migration of existing functionality
(AIX


Linux)

................................
................

100

5.1.15

Support to PDGS common services

................................
................................
..

102

5.1.16

Re
use of Sentinel
-
1 Mission planning facility

................................
.....................

103

5.2

Proposed Delta Configuration Design

................................
................................
.............

103

5.2.1

Three Layer Configuration Approach

................................
................................
.

104

5.3

Proposed of the Physical Architecture

................................
................................
............

105

5.4

RAMS Objectives Justification

................................
................................
........................

105

6

Glossary of terms

................................
................................
................................
....................

106

INTRODUCTION

1.1

Purpose and Scope

This document is the Design Justification File (DJF)

of the Mission Planning Facility (MPF) within
the Payload Data Ground Segment (PDGS) for the Sentinel
-
3 satellites

(hereafter S3MPF).

This document is intended to cover the following deliverables items list of the SOW:



Deliverable
A0: MPF Delta Design
an
d Development Plan

(only the part corresponding to
the de MPF Delta Design; Development Plan is covered in the S3MPF SDP).



Delivera
ble

A19: MPF
D
esign Justification File
.

The objective of
this document

is to present the rationale for the selection of the d
esign solution,
and to demonstrate that the design meets the baseline requirements.

The
DJF
contains results obtained during the evolution of the design as a consequence of the
activities performed along the design process
; this release
contai
ns

the synthe
sis of the applicable
documents (S3MPF SOW, PDGS_MPF_SRD, PDGS_MPF_ICD) and the justification of the
functional architecture proposed at proposal phase plus the incorporation of the understanding and
conclusions agreed between EUM/GMV along the Software Re
quirements phase implementation.

First
finalized
version shall be

produced and delivered in PDR phase and updated according to the
evolution of the next phases of the project.

1.2

Document Structure

This document contains the following sections:

1.

Introduction
;

this section.

2.

Applicable and reference documents
; references containing the applicable and referenced
document to this one.

3.

Design Description
;
contain
s

a description of the expected product, its intended mission,
architecture and design, and the functioning principles on which it is based
.

4.

Design Justification File Synthesis
;
present
s

status of the design justification in response to
requirements, with emphasis on the driving requirements that have a big impact on the
system design, production and maintainability
.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
8

of
106

5.

Justification of the Functional Architecture
;
contain
s

the high level de
signed architecture for
software and hardware needed to develop the software architecture.

6.

Glossary of terms
;

this section contains a table with the a
cronyms

used along this document.


2

REFERENCES

2.1

Applicable

documents

Ref.

Document Title

Document reference

Issue and Revision

Date

[AD
-
1]


GMES Sentinel
-
3 Mission Planning
Facility (MPF) Statement of Work

EUM/LEO
-
SEN3/SOW/11/0056

V
1E

02
/
08
/201
2

[AD
-
2]


GMES Sentinel
-
3 EUMETSAT
Payload Data Ground Segment
(PDGS) Mission Planning Facility
(MPF) Requirements Document

EUM/LEO
-
SEN3/REQ/09/0134

V2
A

20
/
0
4
/201
2

[AD
-
3]


GMES Sentinel
-
3 EUMETSAT
Payload Data Ground Segment (PDGS)
Mission Planning Facility (MPF)
Interfaces Specification

EUM/LEO
-
SEN3/ICD/11/0019

V1A

20
/
04
/201
2

[AD
-
4]


GMES Sentinel
-
3 Mission Planning
Facility (MPF)
Software
Requirements Specification

EUM/LEO
-
SEN3/REQ/12/0081

V
1.
2

02
/0
8
/2012

[AD
-
5]


GMES

Sentinel
-
3 Mission Planning
Facility (MPF) RAMS Analysis
Report

S3MPF
-
GMV
-
RPT
-
0005

V1.0

02/08/2012

[AD
-
6]


Sentinel
-
3 Mission Planning
Facility
Software Budget Report (SBR)


GMV
-
S3MPF
-
SBR
-
0001

V1.0 draft

02/08/2012

[AD
-
7]


GMES Sentinel
-
3 Mission Planning
Facility (MPF) Target Platform
Specification

EUM/LEO
-
SEN3/SPE/12/0340

V1.0

02/08/2012

2.2

Reference documents

2.3

Open Issues

None.

3

DESIGN
DESCRIPTION

GMES Sentinel
-
3 Mission Planning Facility (S3MPF) design and development is based on the main
mandatory driver described in the SOW
[AD
-
1]
:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
9

of
106



“D
evelopment

of the GMES Sentinel
-
3 MPF is a delta development based on
mandatory re
-
use of existing MPF software originally developed in the context of the EUMETSAT EPS
Programme


It means that the EPS MPF software is considered an input (CFI) for the S3MPF developm
ent,
which lead to design S3MPF as described in the following sections.

The following design drivers will be considered for the implementation of the S3MPF:



Modular: The design of the S3MPF will follow the same one of the EPSMPF: It is a
modular design, c
omposed by a set of libraries that encapsulates each one a specific purpose
(common services, Schedule generation, Mid Term Planning, etc...). The following aspects
are related to it:



The replacement of such libraries by new versions and the adding of new
ones can be easily
performed, the scalability of the system is granted.



The system can be operated in degraded mode if some of the functions are not available



The S3MPF shall not depend of the hardware: there will not be any use of hardware
dependent funct
ions.



For system calls, standard functions provided by the programming language will be used.



telnet/ssh/VNC operation is possible



Error handling: all the functions are designed (when possible) returning an error code.
Handling of these errors is perform
ed by the parent function that invokes it and mechanisms
like exceptions are used to guarantee the error handling. Fatal failures in the system are
minimised.



Isolation: S3MPF design shall allow to operate individually each S3MPF instance:

-

There is no sup
port with the prime redundant concept. The redundancy must be
guaranteed as PDGS system level. No propagation of errors shall be produced from
prime to backup.

-

There is no interaction between parallel operations
.



Data Consistency and Integrity: two mechani
sms are used in order to guarantee the data
consistency and integrity: database model, database access modules and HMI checks.



Operability: The S3MPF will be operate by one or several operators in parallel


4

DESIGN JUSTIFICATION

FILE SYNTHESIS

Next section

is dedicated to describe briefly the overall mission planning concept of the S3MPF and
a description of the technical solution in terms of functionality and usage of the system. A more
detailed technical description is provided in the subsequent sections.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
10

of
106

4.1

Introduction

The GMES Sentinel 3 Mission Planning Facility will be in charge to generate conflict
-
free plans for
the payload sensing and downlink. The nominal strategy is to perform the data acquisitions in a
systematic and continuous way. This nominal st
rategy is also shared by the EPS and this
commonality is a key factor for the reuse of the EPS Mission Planning Facility by using the flexible
way to generate schedules by using planning rules and the possibility to modify the planning
strategy by modifyin
g the planning rules at any phase of the mission (commissioning, routine, S3A
and S3B scenario, etc...).

The process to generate the schedules is very similar to the one used in EPS with some differences
that are re
-
marked below.

The main differences betw
een the two Mission Planning Facilities are based in the following facts:



EPS generates the whole schedule to be executed (including platform and payload) and no
iterations with external entities are needed to reach the final state of the schedule. For
Sen
tinel
-
3 it is needed an iteration with FOS in order to reach the final state. This is because
S3MPF

does not plan the whole activities of the satellites and any additional activity added
by FOS can imply the deletion of activities scheduled by the
S3MPF

be
cause of potential
conflicts between them. For EPS the generation of the executable schedule and their
execution is the final stage of the planning process. For S3 it is needed an additional
iteration with FOS in order to close the planning process.



EPS ex
ecutes the schedule in “real time” connecting with the Mission Control Centre by
using the Schedule Execution Process and the contents of the schedule are executed one by
one, receiving in real time the replay of the Mission Control Centre. The whole sched
ule is
executed using this way independently of the destination that each item (named Procedures)
of the schedule (satellite, Ground Station, etc...) has. S3 makes use of a file exchange
mechanism to “execute” the schedules. Output files are generated base
d in filtered contents
of the whole schedule. For the Ground Stations only tasks in the schedule related to the
downlink of data will be included. For the satellites only tasks in the schedule related to the
sensing and downlink will be included: there is
no real time replay and only the feedback
from FOS is received by processing the reply file named NPIF file.



S3 supports the Orbit position Schedule: it is possible to tag any activity in the schedule with
the orbit number within the Repeat Cycle and the o
rbit position (Angle from the Ascending
Node Crossing). There are two types of tasks based in this mechanism: Single Repeat Cycle
and Multiple Repeat Cycle (see next bullet). Note that also the “classic” time tag of the
activities is supported. This implie
s that this feature is an “add
-
on” feature with respect to
the EPS functionality.



Multiple Repeat Cycle Requests: In S3 it is possible to schedule OPS Multiple Repeat Cycle
Requests (OPS MRC). The Requests loaded on
-
board are systematically repeated in a r
epeat
cycle period basis. There is no need to reload these kinds of requests. As consequence of
this, there are two possible output files: one containing the full schedule that contains all the
scheduled Requests and a “delta” schedule that contains only t
he Requests that are not MRC
and the modifications of the MRC Requests. This implies that the schedules generated by
the
S3MPF

will contain tasks that are effectively commanded (in case of generation of a


GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
11

of
106

“Delta” schedule) and some tasks that will not be c
ommanded but must be taken into
account by the conflict detection and resolution. This implies that a “memory” of the OPS
MRC Request (an image) must be maintained by the MPF in order to compute the contents
of the “delta” schedules. Also, because it is po
ssible that some of the OPS MRC Requests
could be discarded by the FOS, the maintenance of the image must take into account the
feedback provided by FOS about the final commanding of the OPS MRC Requests. Also a
manual maintenance of the image must be allo
wed. This is also an “add
-
on” feature with
respect to the EPS functionality.



EPS uses all the input files: All the EPS input files are ingested and used for the mission
planning loop. In S3 there are a set of files where the MPF acts as router.
S3MPF

recei
ves
the files and forwards the file to specific components of the PDGS. No data contained in the
file is used in the Mission Planning process and no ingestion of the file is performed. This
adds the need to have a file inventory in the MPF in order to hand
le the input and output
files. The input files are registered in the file inventory when the file is ingested or when the
file is simply registered. File inventory is queried in order to extract the list of available files
for delivery to the destinations.

This is also an “add
-
on” feature with respect to the EPS
functionality.

There is also a set of functionality that is requested in S3 in order to improve the efficiency of the
mission planning process. These improvements are not specific of S3 and could be

applicable to
EPS in order to improve the EPS MPF operations. The major features are:



Resource usage with slope: It will be possible to define the resource usage/production as a
linear function of time. This will allow additional model of resource usage b
y the tasks. A
typical example of this is the model of the on
-
board memory where the consumption slope is
the recording data rate and the production slope is the downlink data rate.



Platforms selectable tasks: This feature allows assigning the platform by
using the rules or
by taking the platform of the parent task or event in the case of the operations. With this
feature it will be possible to generate common set of rules for both satellites S3A and S3B.



Input Interfaces configurable: This will allow addi
ng/removing new interfaces in a
straightforward way. New parsers will be added with a minimum cost.



Conflict Detection by rules: It will be possible to add new conflicts by defining conditions
on rules. This will allow using potentially any item in the sch
edule (events, tasks, resource
usage, and resource availability) to create conflicts.



Automatic Conflict Resolution: It will be possible to define policy to solve conflicts by the
use of rules. This will minimise the time of the operations in the conflict
detection and
resolution subsystem.

4.2

Open Issues/Critical Points

The current evolving issues, relating to the S3MPF include:



MPF
-
OI
1 of
[AD
-
2]
:
The format

and

content
of some
of the files interfacing with the MPF
are not yet formally defined, or require further clarification

(due date PDR)
. These include

at
least

the following data
items:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
12

of
106

-

FOS/Satellite Unavailability Report

-

Instrument Parameter tables

-

TC History Report File;

-

Zone D
atabase File



TC History File processing and TC History Report generation based on the informal are
pending of a formal descoping (due date PDR).



Final conclusion about
Sentinel
-
3 MPF Target Platform Specification

is still an Open Issue
(due date PDR).



Implementation of the PDGS Data Circulation Agent requires further clarification

(due date
PDR
)

4.3

Requirements
Synthesis:

Overview of the Sentinel 3 M
ission Planning
Process

The proposed
S3MPF

is based in a modular concept where each module represents a stage in the
mission planning process in order to fulfil the Sentinel
-
3 requirements.

S3MPF

will be composed of the following modules:



Mission Environme
nt Preparation (MEP)



Instrument and Service Module Event Generation (ISEG)



Mid Term Planning (MTP)



Schedule Generation (SG)



Conflict Detection and Resolution (CDR)



Output Files Generator (OFG)

Each module is described in the following sections.

4.3.1

Mission Env
ironment Preparation

Mission Environment Preparation subsystem is in charge to configure the
S3MPF

in order to meet
the Sentinel
-
3 requirements.

In the mission environment preparation the elements used by the MPF planning loop are defined.
These elements
are:



Events: and the generation rules for ISEG and ISEG MRC



Tasks: and the relationship between Tasks



Resources: and the consumption/production by the Tasks



Master Schedules: and the schedule generation rules



Conflict Detection rules



Conflict Resolution
Rules



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
13

of
106



Input Interfaces

All the configuration items are stored in the database and in files
,

allowing the
export/import
of
these data by dedicated scripts that perform automatically the database dump and the packaging of
the files. This data in named no run
time data.

Also it is possible to export/import the complete data set including the runtime data.

Only compatible data with the one already stored in the database can be imported.

The very first task to be done in the
S3MPF

is the configuration of the miss
ion. Using the inputs of
the operational concept from the different sources: PDGS, FOS, manufacturer of the satellite and
payload, etc..., a first draft of the Initial Operational Implementation must be produced that will
result in the initial configuratio
n of the system.

The following items are configured directly in the database:



Number of platforms and names: S3A, S3B, Ground.

4.3.1.1

Requests and FOS Events definition

Once the database model is produced, the next step is the population of the MEP with the low l
evel
tasks: Requests and FOS events. In order to synchronize the FOS with the
S3MPF

it is needed to
exchange between the two systems the Requests and FOS events definitions. This will be done by
means of the Requests and FOS event definition files. The for
mat and content of these files are not
defined as stated in the MPF
-
OI
1 of
[AD
-
2]
. A format

must be defined in agreement with FOS
team and EUMETSAT in order to fulfil the configuration needs of the
S3MPF
.
Although
the usage
of
this functionality in practice

is still to be
confirmed
,
i
t is
important to note

th
at

if
resource
consumption slots
are
defined in the Requests Definition File
, they shall allow

to use the de
-
conflicting filter in the CDR as the Request will contain at the end a sequence of telecommands that
will not
consume resources during the complete duration of the Requests. The use of the de
-
conflicting filter allows to plan in parallel Requests that consume the same resource that “a priori”
cannot be planned simultaneously.


The ingestion of the Requests and FOS

event definition files will result in the population of the
database with the low level tasks: FOS Events and Requests that will be ready to create the
hierarchical task tree.

The ingestion of the Request and FOS events Definition files will done punctual
ly during the
mission and only punctual updates of the definitions will be envisaged, as they are defined from the
commands database provided by the manufacturer of the satellite.

4.3.1.2

Resources Definitions

In order to model the constraints of the system, a def
inition of resources must be done based in the
needs of the mission.

Two possible resource types can be defined depending of the way that the resource is used:



Temporal: The consumption/production of the resource is produced at the start time of the
task a
nd is released at the stop time of the task.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
14

of
106



Permanent: The consumption/production of the resource is produced at the start time of the
task but it is not released at the stop time of the task. This is used to model resources with
limited usage like switch
es of on
-
board resources.

Also it is possible to define a pattern of resource availability in order to be repeated in time.


Figure
4.3.1
-
1
:
Resource defined with a pattern of resource availability

4.3.1.3

Event
Definitions

Events are the inputs of the Schedule Generation subsystem. There are the following types of
events:



External events: Events whose instances are contained in the input files configured as events
parser. These event definitions provide the MPF w
ith the information to recognize the event
instances when an input event file is ingested. Also an exclusion time period can be
associated to the event definition in order to be used in the MTP to avoid the inclusion of
events that are too close.



Internal
Events: Events whose instances are manually created by the operator in the MTP. A
frequency can be added to the definition in order to be used when the instance is created in
MTP to propagate the event along the MTP interval.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
15

of
106



ISEG Events: Events whose inst
ances are created by the ISEG process by using generation
rules. For ISEG events a Master and secondary events must be associated to the event
definition and a set of generation rules. Master and secondary events are used in the
condition part of the gener
ation rule. For the secondary events is also possible to define
forwards and backwards time range in order to use in the generation process only the
instances of the secondary events that are in the time range defined with respect to the
Master event
. Als
o it is possible to link to the ISEG event definition another ISEG event
definition. This link

will be used when the ISEG event is added to the MTP. The generation
rules are created by using the Rules Editor application that provides friendly functionality

to
elaborate the generation rules. Rules Editor is opened in ISEG mode that means that rules
can have the following characteristics:

-

Conditions only can be defined on Events and Resources Availabilities

-

Generation part only can include ISEG Events


Figure
4.3.1
-
2
:

Rules Editor for ISEG

For all types of events it is possible to define them as OPS MRC, OPS SRC or MTL. In the case of
ISEG events, if they are defined as MRC, there are some specifics:



There
will not be allowed to define Master or Secondary events that are defined as SRC



a new mode of the Rules editor will be opened allowing define rules based in Repeat cycle
relative times (using relative orbit, elapsed time from ascending node crossing and a
ngle
from the ascending node crossing) instead of absolute times. These generation rules will be
stored in a separate repository allowing similar functionality that the one that ISEG has
(copy and paste of rules, drag & drop of definitions, etc...)



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
16

of
106

4.3.1.4

Task De
finitions

Once the low level tasks are
ingested (as explained in section
4.3.1.1
), it is

need to define the rest of
hierarchy levels of tasks and to

define the timeline constraints between the tasks. There are four
levels of hierarchies:



Operation



Template



Activity



Request, Tag Task and FOS events

Requests and FOS events definitions are already ingested and operations, templates, activities and
Tag Ta
sks must be defined. All the instances of these tasks are not visible outside of the MPF and
are used to model timeline relationships between the Requests and FOS events, to group sequences
of Requests or/and FOS events in order to fulfil any specific oper
ation and to define resource
consumption (in the case of the Tag Tasks) to model exclusion mechanism between Tasks or to
simulate any consumption profile.

The timeline relationships that can be defined between the hierarchical levels are:



Start time of the

task with respect to the Start time of the parent task + delay



Start time of the task with respect to the Stop time of the parent task+ delay



Stop time of the task with respect to the Start time of the parent task+ delay



Stop time of the task with respect

to the Stop time of the parent task+ delay

With relation =, < or >. Delay can be expressed as an absolute number (in milliseconds) or as a
function of the values of the parameters of the parent task.

During the Task Definition is also possible to define t
he usage of the resources by the Requests.

The usage of the resources can be modelled as:



Constant resource consumption/production: A resource is consumed/produced at a constant
value



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
17

of
106


Figure
4.3.1
-
3
:

Exampl
e of constant usage




Consumption with slope: A resource is consumed/produced as a linear function of time


Figure
4.3.1
-
4
:

Example of consumption with slope usage



Full consumption: The resource is completely

consumed by the task. This is usually used to
model mutual task exclusion



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
18

of
106

4.3.1.5

Master

Schedules

Master Schedules are the placeholder where all the planning strategy is created. A Master Schedule
can be identified as an operational scenario and the mission plan
ning policy that must be applied in
case of selection of it.

A Master Schedule is composed by:



A set of operation definitions



A set of generation rules that will generate instances of those Operations

The way to define rules is by using the Rules editor in

the scope of the Master Schedules. In this
scope the Rules Editor is opened in SG mode that means that the Rules that can have the following
characteristics:



Conditions

only can be defined on Events and Resources Availabilities and predefined
functions that can parse, for instance, instrument calibration files.



Generation part only can include Tasks, where an Operation definition is mandatory and
optional the rest of hie
rarchy levels. For tasks where the platform is not defined in the MEP
definition, it is possible to assign it in the rules.

Master Schedules are selected in the Schedule Generation subsystem in order to apply the
generation rules when the working schedule
is created

4.3.1.6

Conflicts
Definition

A set of configurable conflicts can be defined in MEP in order to cover those conflicts that has not
been defined by the use of the timeline (in the task definition) or the resource usage.

The definition of conflicts has two

steps:

1.

Definition of a new code of conflict with the description of the conflict

2.

Definition of the Conflict making use of the Rules editor in conflict definition mode. In this
mode the rules will have the following characteristics:

a.

Conditions only can be
defined on Events, Resource availability profiles, and Tasks

b.

Generation part can only include Conflicts.

Conflicts rules are fired in the CDR when the checking schedule is created and the set of conflicts to
be detected are selectable by the user.

4.3.1.7

Conflict

Resolution Definition

The decision to be made when the automatic resolution of conflicts is performed can be defined in
MEP. In order to define conflict resolution a set of rules can be defined. In order to define conflict
resolution rules the Rules edito
r will be opened in Conflict Resolution mode. In this mode the
following policy will apply:



Conditions
can

only

be defined on Events, Resource availab
ility and consumption profiles,
Tasks

and Conflicts detected.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
19

of
106



Generation part can only include Actions to
be performed on the conflicting task. Actions
that can be done on the tasks are as minimum:

-

Modification of the Start time in UTC format, Stop time in UTC format, Start orbit,
Stop orbit, Start Offset, Stop Offset.

-

Deletion of the task

-

Modification of any
parameter value of the task

A priority can be assigned to the rule, in order to handle the order to be fired.

4.3.1.8

External

Input Interfaces definition

The external interfaces must be configured in MEP. In order to define external interfaces, the
following data

must be associated for each external interface

defined:



Name of the interface: For the case of events, this name is used to assign the event type



Parser to be used to ingest the file: from the list of available parsers. If no parser is defined,
the file i
s only registered in the file inventory (for files that must be forwarded to other
destinations)



Input tray: directory where the input file is put



Polling period: if set to 0, a manual user intervention must be done. If > 0 an automatic
polling of the
input tray is performed.

4.3.2

Instrument and SVM Events Generation

The generation of ISEG events is, in fact, the first task in the process of the generation of the
schedules. ISEG events are generated taking as inputs the event instances ingested using the
aut
omatic polling mechanism of the Main Process

(new Monitor Process)

and the ISEG definitions
available in MEP.

The ISEG process is an independent process that can be triggered manually, by using the ISEG
HMI, or automatically by the main process
(new Monito
r Process)
on a periodic basis. When it is
triggered manually, it is possible to select for which ISEG event definitions the generation process
will be run. In the automatic trigger all the ISEG event definitions present in MEP are run.

The ISEG generation

process generates one by one the ISEG event instances that correspond to
each ISEG event definition. This means that for each ISEG event definition a new generation
procedure is performed.

The ISEG generation procedure will be different if the ISEG event
to be generated is MRC or not.

In case that the ISEG event will not be tagged as MRC the following steps are followed in the
generation process:

1.

Event instances of the Master event (Master Event name is taken from the ISEG definition)
are extracted from th
e database and inserted in the working memory. Only event instances
whose start time is major than the system date minus a configurable value are used.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
20

of
106

2.

Event instances of the Secondary events are extracted from the database and inserted in the
working memo
ry. Only event instances whose start time is major than the system date minus
a configurable value and that also meet the time range condition put in the ISEG event
definition are used

3.

ISEG generation rules that correspond to the ISEG event definition are
fired.

4.

Results of the generation are ISEG event instances that are extracted from the working
memory and stored in the database ready to be used by the Schedule Generator subsystem in
case that will be included in the MTP.

In case that the ISEG event will
be MRC, the process is slightly different:

1.

Event instances of the Master event are extracted from the database and inserted in the
working memory. Event instances to be used will be the ones whose start time corresponds
to the time interval:

a.

(current date
+ configurable value, current date + configurable value + duration of a
cycle) or,

b.

Next repeat cycle in the future.

2.

Event instances of the Secondary events are extracted from the database and inserted in the
working memory. The same approach than
bullet
1
is followed plus the
need to meet the
time range condition put in the ISEG event definition is

used.

3.

ISEG generation rules that correspond to the ISEG event definition are fired.

4.

Results of the generation are ISEG MRC event instances that are extracted fro
m the working
memory and stored in the database in a specific database table, replacing the old ones, if
they exist. These instances are no “real” instances because their start/stop times are relative
times and related to their position in time in the Repe
at Cycle. It is mandatory to add these
events in the MTP in order to create the real instances of these events with absolute times.

All the resulting ISEG events could be visualized by means of a Gantt
-
Chart in the ISEG HMI. In
order to visualize the
generated ISEG MRC events, propagation along the displayed time interval
will be performed in order to create simulated ISEG MRC events.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
21

of
106


Figure
4.3.2
-
1
:

ISEG Gantt
-
Chart

Since the ISEG events are created by

putting conditions in the ISEG event generation rules over
External events, it could be possible that the ingestion of updates of the external events will make
the ISEG event instances obsoletes. If this is the case, the ISEG event definitions affected wi
ll be
highlighted in the list of event definitions in the ISEG HMI. In order to mitigate this, a new ISEG
generation process must be run.

4.3.3

Mid
Term

Plan

The next step in the schedule creation process is the Mid Term Plan creation. Mid Term Plan is a
uniqu
e timeline of events that are used during the schedule generation process. There is only one
instance of the Mid Term Plan and it is the way to customize the inputs that will be available when
the schedule generation rules engine is launched.

The user defi
nes a time interval where he intends to work and all the actions performed are
applicable to the selected time interval. This means that the way to work with the Mid Term Plan is
by using time interval snapshots of the whole timeline that are committed at
the end of the working
session.

The following main tasks can be performed in the Mid Term Plan:



Add Events: from a list of available Event definitions (external and ISEG) it is possible to
select which will be added to the MTP time interval in edition.
This will perform the
following actions:

-

For external events the event instances are tagged as “included” in the database. No
instances are generated.

-

For ISEG events:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
22

of
106



If it is an MRC, ISEG event instances are created by propagating along the
MTP time inte
rval in edition by using the “instances” created in the ISEG
generation (see section
4.3.2
).
These instances cannot be edited (in
opposition to the SRC or MTL even
ts which can be edited).



If it is not and MRC, the same approach than for external events are
followed.



Linked ISEG events are also added or created (in case of MRC) to the MTP
interval edited
.



Create internal events: Internal events are manually created i
n the MTP. When an internal
event is created, it is possible to specify the value of the default attributes (start time and
stop time in UTC, absolute orbit, offset from ANX, relative orbit, cycle number and angle
from ANX; entity, platform) and the value
of the parameters and attributes. Also it is
possible to propagate the event along the MTP interval in edition by using the frequency of
the MEP event definition



Create manual events: It is also possible to create instances of external and ISEG events
manu
ally.

Once the MTP interval is populated, all the events included in the MTP interval are potentially
ready to be used by the schedule generation subsystem.

4.3.4

Schedule
Generation

Schedule generation subsystem is in charge of generating the working schedules
by applying the
Generation rules defined in the Master Schedules (see section
4.3.1.5
).

In order to generate a schedule the user must input:



A free text in the
name of the schedule (optional)



A description (optional)



If it is a trial or not: Trial schedules are used for simulations and a trial schedule cannot be
used operationally



Time covered by the schedule



Extension backwards and forwards to the previous time
interval in order to collect the MTP
included events: Only events instances whose start time belongs the extended time interval
will be used during the generation process.

It shall be checked for every type of MRC event
that either all or none of the event

instances are in the interval.



Master Schedules to be used: The generation rules associated to these Master Schedules will
be fired.


The process to generate schedules is:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
23

of
106

1.

All the MTP events whose start time is included in the (start time of the schedule


backward extension, stop time of the schedule + forward extension) are retrieved from the
database and inserted in the working memory

2.

Resource availability profiles intervals for all the resources defined in MEP are created and
inserted in the working me
mory

3.

Each set of Master Schedule generation rules are executed and when the conditions are met,
tasks are created in the working memory

4.

Generated tasks are extracted from the working memory for further processing

5.

Tasks of Operation hierarchy level are proc
essed in first place and the default lower level
hierarchy that corresponds to this Operation are created from the MEP definition

6.

If any of the lower level hierarchical
tasks

has been created in the working memory by the
rules, the corresponding task gener
ated by default in 5 is replaced.

7.

A check is performed in order to know if there is any remaining task not linked to any
Operation. If there is any, an error is raised to the log (there is an erroneous generation rule).

8.


Operations whose whole hierarchy is

outside of the time interval of the schedule are
discarded (can be created because of the defined time extensions)

9.

Resulting tasks are stored in the database.

Once the working schedule is created, it is possible to perform manual fine tuning of the result
ing
schedule by editing it. It is possible to add, remove and modify any task. Also it is possible to copy
tasks from another schedule. A dedicated Gantt
-
Chart is used to help the operator in this edition.


Figure
4.3.4
-
1
:

SG Gantt
-
Chart

Note that at this stage of the schedule generation process, the selection of the output file has not
been done. This implies:



If an incremental schedule is to be created, the adequate Master Schedules must be selected
in ord
er to create the desired tasks.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
24

of
106



If a DNNPF is to be created, a full schedule must be created at this stage in order to allow in
the next stages to compute what are the “Delta” Requests to be included. In order to provide
with a reference, it is possible t
o visualize the contents of the OPS MRC image in a separate
window.

Schedule Generation does not know anything about the output to be generated. This information
will be taken into account in the next steps of the planning process.

4.3.5

Conflict Detection
and

Resolution

Conflict Detection and Resolution is the subsystem in charge of generating the final conflict
-
free
executable schedule where the output files contents will be extracted.

The process begins with the selection of the working schedule (or executab
le, in case of DNPPF) to
be checked. It is possible to select the working/executable schedule from a list of available
schedules present in the database.

The next step will depend on the output to be generated:



If the desired output is an incremental sched
ule, an executable schedule covering the whole
time interval covered by the working will be selected. This is in order to “merge” the
executable schedule with the working schedule.



If the desired output is an NPPF
/DNPPF
, a parent executable schedule whose
stop time
is
mayor

or equal to the start time of the working schedule must be selected. Also the
crossover time between the two schedules can be selected. This is in order to grant the
continuity between the two schedules.

This implies the selection of the

output schedule

(incremental or not)

at this stage of the planning
process.

Also it is possible to tag the schedule (NPPF
/DNPPF

or Incremental) as Trial that will be used for
simulation purposes. Trial schedules cannot be converted in operational ones.

On
ce the selection is done the following actions are performed:

1.

A window is presented to the operator to select:

a.

Which conflict detection rules will be applied (an option for “all selected/all
deselected will be provided in order to improve the selection pro
cess): A list with all
the conflict detection rules defined in MEP will be displayed.

b.

If the Automatic Conflict Resolution

(ACR)

must be enabled (default value taken
from the configuration file). If enabled, the following selection option is presented to
t
he operator.

i.

Which Conflict Resolution Rules will be applied (an option for “all
selected/all deselected will be provided in order to improve the selection
process): A list with all the conflict resolution rules defined in MEP will be
displayed.

2.

The checki
ng schedule is created:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
25

of
106

a.

If it is an incremental schedule, a new schedule is created by merging the executable
schedule with the working schedule. The tasks that belong to the incremental
schedule are tagged.

b.

If it is an NPPF
/DNPPF

a copy of the working sc
hedule is performed and the
operations that belong to the parent executable schedule having any lower level
hierarchical task starting before the time covered by the working schedule, are
copied in order to assure the continuity between schedules.

Finally,

it will be
possible to generate only one NPPF/DNNPF and later, in the Output File Generation
module to select which file will be generated (NPPF/DNNPF) inserting their
corresponding deletions requests.

3.

The conflict detection is run as follows:

a.

Violations

of the timelines defined in MEP between tasks of the same hierarchy are
checked. Also it is checked if there is any missing task in the hierarchy with respect
to the MEP definition. Detected conflicts are stored in the database.

b.

Resource consumption is
computed for Requests and Tag Tasks (FOS events does
not consume/produce resources). It is checked if there is any overconsumption.
Detected conflicts are stored in the database.

c.

Working memory is populated with the Tasks, Resource intervals and the events
.
Selected conflict detection rules are fired and the resulting conflicts are extracted
from the working memory and stored in the database.

4.

If the ACR is enabled,
the Working M
emory is populated with the Tasks, R
esource
intervals, Resource con
sumption inte
rvals, detected conflicts and events. Selected conflict
resolution rules are fired in order. The resulting Actions are extracted from the working
memory resulting of executing the first rule and processed. A new working memory is
created with the changes f
rom the actions resulting from the first execution and the second
rule is executed. The process is repeated until the last rule is executed. The conflict detection
is launched and if any conflict is found, the process is repeated until a conflict free or
c
onflict overwritten schedule is generated or the limit of iterations is reach. A report with the
actions performed is displayed to the operator for confirmation or undo
(see section for
further details
5.1.8.1
).

5.

All the confirmed changes are committed to the checking schedule.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
26

of
106


Figure
4.3.5
-
1
:

Example of a Conflict Resolution Report

The status of the r
esulting schedule could be:



In conflict: It is needed to solve the conflicts: the remaining conflicts can be solved
manually by the operator by editing the tasks directly in the Gantt
-
Chart, by overriding the
conflicts or by triggering again the ACR. Also
the visualization of the OPS MRC is
available in order to help the operator to solve the conflicts.



Conflict Overridden: the checking schedule has conflicts, but all of them have been
overridden by the operator or by the Resolution rules.



Conflict Free: Th
e checking schedule is conflict free.

For Conflict Free and Conflict Overridden it is possible to save the checking schedule as
executable. This means that all the times of the tasks are put in freeze state (in order to maintain the
status of the schedule)

and the schedule is ready to be used to generate outputs in the OFG.

4.3.6

Output Files
Generator

Output Files Generator is the
S3MPF

subsystem in charge to generate the output files from the
content of the schedules and to transfer them to the corresponding destinations.

The first task is to select which executable schedule from a list of available schedules (generated in
the CDR) will

be used to create the output files.



For Incremental executable schedules, Incremental Schedule File will be allowed.



For NPPF executable schedules,
Nominal Payload Planning File

will be allowed



For DNNPF executable schedules, Delta
Nominal Payload Planni
ng File

will be allowed.

Besides, the following output files could be generated:



NPPF

files: The whole content of the executable schedule is included in the file. Also a
deletion Request for the whole on board image is included.



DNPPF files: The whole con
tent of the executable schedule is included in the file. Also a
deletion Request for the
updating

on board image is included.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
27

of
106



S3
Contact Schedules



DFEP schedules



Visibility Segments



And any other output, like informative reports.

The task filter criteria
to include tasks in the files can be specified here.

The second task is to transfer the output files to the destinations

(using Data Circulation
mechanism)
.

Note that not only the generated files from the executable schedules will be available but also th
e
files where the
S3MPF

acts as router.

A list with all the generated files plus the registered files will be available to the operator to select
which ones are desired for transfer

(copied to the MPF DC output tray)
.

4.3.6.1

Tasks to be
performed

after the output

files released

When the output files are
copied to the MPF DC output tray (to be
transferred to the FOS
)
, it must
be needed to perform an analysis of the feedback provided by the FOS in order to maintain the OPS
MRC image.

FOS provides
four

feedback files

to the MPF:



NPIF and NPIF Constraints Checking Report: These files contain the Requests that have
been commanded by the FOS to the satellite.
Both files must be ingested and processed by
the MPF.



TC History File: This file contains the set of telecommands

that have been uplinked and
executed.

This file is only registered and stored to allow the operator its review.



Filtered TC History files: this file contains the set of telecommands that have been uplinked
and whose execution has failed.

This file is only

registered and stored to allow the operator
its review.

4.3.6.2

NPIF and NPIF
Constraints

Checking Report Processing

NPIF and NPIF Constraints Checking Report
(NPIF CC)
are used primarily to update the OPS
MRC image the MPF used during the generation process of t
he DNNPF.

The process starts when a DNNPF or NPPF are sent to the FOS. FOS must generate a NPIF and
NPIF Constraints Checking Report as response of the DNNPF or NPPF. If the file is not received in
a configurable time, an error is raised in the log to info
rm the operator.

When a NPIF file is received from FOS is not automatically ingested by the MPF. A warning log
message is raised in order to inform the operator about the reception. The operator must manually
invoke the processing of the file using the man
ual ingestion
window (see section
5.1.3.1
).

The first file to be processed is the NPIF CC reporting the constraint violations detected at FOS
level
. In case there are constraints reported the complete NPPF has been rejected at FOS and the


GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
28

of
106

NPIF accompanying the NPIF CC must not be processed. Instead the user needs to analyse the
constraint violations reported in order to introduce the necessary update
s in the schedule. After re
-
scheduling

new NPPF and DNPPF are forwarded to FOS
-
MPS.

When no constrain violations are detected by the FOS constraint checker, the NPIF CC is empty. In
this case the user can process the NPIF and perform a visual comparison be
tween its contents and
the corresponding NPPF/DNPPF. If no differences are found or if they are assumed by the user, the
OPS MRC Image can be updated

from the NPIF contents
-

upon operator request.

The processing of the NPIF produces the following outputs
:



The OPS MRC image is updated



A report containing the differences between the output file sent (incremental, DNPPF,
NPPF) and the NPIF and NPIF Constraints Checking Report is generated



It is possible to visualize in a Gantt
-
Chart the NPIF contents and the

DNPPF/NPPF contents
in order to compare them visually



The associated executable schedule is updated with the differences found in the report.

If a NPIF is not desired to be ingested, it can be discarded for processing

4.3.6.3

TC History File and Filtered TC
History files processing

The list containing the failed TCs is
valuable

feedback information from FOS in order to know what
has been executed or not on board of the output executable schedules. When a TC history file and
filtered TC history file are
receiv
ed they are registered in the MPF File Inventory and the operator is
notified via messages in graphical log.

This information is used in order to know if any of the OPS MRC Requests have been failed. With
this information it will be possible to manually update the OPS MRC image maintained by the
MPF
(see section
5.1.4.8
).

4.4

Non
-
conformance’s Requirements

This section is intended to collect the list of requirements which have not been met (e.g. non
-
conformances if any), including proposed actions on them.

Req.
Id

Description

Comment

Action Id





Table
4.3.6
-
1
: Non
-
Conformance’s Requirements


5

JUSTIFICATION OF THE

FUNCTIONAL ARCHITECT
URE

This section contains information about the selected approach to be followed
in the S3MPF
development life cycl
e:



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
29

of
106



D
ue to the mandatory re
-
use of the existing EPS MPF CFI software together with its
associated documentation this delta development shall be built upon these existing CFI
retaining (where available) existing formats and
structures and re
-
naming the outputs to
become the GMES Sentinel
-
3 MPF deliverables
.



The

EPS MPF CFI

re
-
usage approach implies that the baseline software is used as
-
is and

the
S3
MPF
software

shall
be developed

on top of it.

5.1

Proposed Delta Architectural Des
ign

Because a reuse of the EPSMPF is requested, the solution for the
S3MPF

must be based on

the
current architecture of the EPSMPF.

EPSMPF is composed by several subsystems. Each subsystem is composed by business services
and a user services. Besides,
common modules provide services to each subsystem.

The subsystems currently available in EPSMPF are the following:



Mission Environment Preparation (MEP)
: In charge of configuring the EPSMPF to meet the
requirements of the mission. In MEP it is possible to
define input events, internal events,
ISEG events and their generation rules, tasks and resources and is the place where the
Master Schedules and the planning rules are defined.



Mid
-
Term Planning (MTP)
: In charge of defining the set of events to be taken i
nto account
during the schedule generation process. In MTP it is possible to include, exclude and
manually define the Event instances for a defined period of time.



Instrument and SVM Event Generation

(ISEG)
: In charge to generate ISEG events taking as
inpu
t the input Events instances and the generation rules defined in MEP.



Schedule Generator (SG)
: In charge of generating the plans using as inputs the events
included in the MTP and the decision tables defined in MEP.



Conflict Detection (CR)
: In charge to de
tect the conflicts presents in the working schedule
generated by the SG and to provide the tools to the operator to solve them manually



Schedule Execution (SE)
: In charge to execute, control and monitor the conflict free
schedules generated by the CR. This

subsystem is very specific to EPS and only some
functionality related to the database access for executable schedules will be reused.

The Common modules that provide services are the following:



HMI
: There are one per subsystem and two additional ones for
common services:
CommonHMI and MPF Gantt Chart



Rules Offline Authoring Environment (RAE)
: Providing the creation and edition of existing
rules files for the SG and the ISEG.



Common_Services
: library that provides functionality used by the rest of subsystem
s such
as: logging services, time handling, configuration handling, etc...



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
30

of
106



Rules Online execution environment
: library that provides functionality related to the
execution of the rules engine. In the EPSMPF is used by the ISEG to generate ISEG events,
the
SG to generate working schedules and by the CR to update the parameters when an
executable schedule is created.



External Interfaces
: library that provides all the required services related to the ingestion of
input files and the generation of output files
such as the datastore files associated to the
procedure execution requests.


Figure
4.3.6
-
1
:
EPSMPF high level architecture

The
S3MPF

must be based in the EPS Mission Planning Facility. This implies an activ
ity where it
is needed to identify whose components of the EPSMPF Software can be reused for the
S3MPF
,
whose components must be discarded because are specific for EPS mission and whose components
are new.

Because of this reason, the activity to be done ca
n be resumed in three major points:



Migration of functionality, actually run in AIX to Linux OS
.



Modification of the common functionality to EPS and Sentinel
-
3 in order to have a common
“kernel” to both missions
.



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
31

of
106



Implementation of new functionality due to
the specification of Sentinel
-
3. This new
implementation can be divided in two:

-

Implementation of new functionality specific to Sentinel
-
3 mission
.

-

Implementation of new functionality reusable in current of future missions
.

The technical solution proposed

by GMV will be based in the description of the modifications to be
performed to each EPSMPF subsystem in order to
meet the requirements of
[AD
-
2]
.
The

modifications have been distributed by the main subsystems where the change will be done in spite
that the changes of most of them affect to different subsystems (that are also described in the
corresponding section).

5.1.1

High
-
level

components

In the follo
wing figure is depicted the overall view of the components of the EPSMPF with their
usage and the new components to be developed in the frame of the
S3MPF
.


Figure
5.1.1
-
1
:
S3MPF

Modules with their usage

Database

Main HMI

Process

MP

Mission

Environment

Preparation

MEP

Mid Term Plan

MTP

Schedule

Generation

SG

Conflict

Resolution

CR

Instrument

and SVM Event

Generator

ISEG


Main Process

MP

Common

Services

CS

Rules Tool

External

Interfaces

EI

Planning

&

Scheduling Modules

Process Management Module

Database

&

File Repository

Support Modules

Interface Module

Access and Control Module

Executable

Schedule

Process

Data

Circulation

Integration

DC

Common HMI

Database

MPF Gantt

Chart

MPF

Monitor

Rules Adapter

Rules Manager

Rules Editor

Schedule

Execution

SE

Common

Services

Modified Reused

Module

Schedule

Execution

Not used

Module

Rules Tool

Open

Source

Output Files

Generator

New

Development

Output Files

Generator

OFG

Database

Reused

Module

Monitor

Process

MP

Action
Scheduler



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
32

of
106

The following components will be reused with modifications:



Main HMI Process



MEP



MTP



ISEG



SG



CR: This module will be modified

and will be CDR in the delta architecture



Common Services



MPF Gantt Chart



MPF Monitor:
this component will be migrated to Linux and renamed to
Action Scheduler
.



Rules Adapter



Common HMI



Rules Manager



Rules Editor



External Interfaces: If some of the EPSMPF

parsers are reused, this module will be migrated
to Linux

The following components are discarded to be used in
S3MPF
:



Schedule Execution



Executable Schedule Process



Main Process
;

this component will be migrated to Linux and renamed to Monitor Process.

The

following components are new:



Monitor Process



Output Files Generator



Data Circulation Integration

The following components will be used unmodified:



Database

5.1.2

External Interfaces

S3MPF

has the external interfaces
depicted in

Figure
5.1.2
-
1
.

Also it is included the input
interfaces,
in
Table
5.1.2
-
1
,
the output interfaces in

Table
5
.1.2
-
2 and 5.1.2
-
3
. Some of the
interfaces are common to all the Sentinel missions.
The section
5.1.16

is dedicated

to list those
interfaces common
to Sentinel
-
1 Mission Planning Facility.




GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number:

-




Page
33

of
106





Input Files for MPF

Data Stream

Source

Request and FOS
Events Definitions File

Manually generated by user upon reference documentation.

Orbital Events File

EGF

S
-
Band Station Plan
View File

FOS
-
ESTRACK
Management System

X
-
Band Banned
Segments File

SRA

Ground Stations
Unavailability File

SRA

Ground Station
Unavailability Report

X
-
Band Core and Local Ground Stations

FOS & Satellite
Unavailability Report
Files

FOS
-
FCT



GMES Sentinel
-
3 Mission Planning Facility
(MPF) Design Justification File (DJF)

EUM/LEO
-
SEN3/DOC/12/0091

v1E Draft

8 November 2012

WBS Number: