European Space Agency Directorate of Operations and Infrastructure Mission Operations Department GMES SENTINEL-1

Transcription

1 European Space Agency Directorate of Operations and Infrastructure Mission Operations Department GMES SENTINEL-1 (ESOIRD) S1-RS-ESA-SY-0006 Issue April 2006 ESOC European Space Operations Centre

2 : ii DOCUMENT APPROVAL Prepared by: Earth Observation Missions FOS TEAM Approved by: P.P. Emanuelli (OPS-OE) Earth Observation Missions Ground Segment Division G.Levrini (EOP-PW)

3 : iii Issue No. Rev. No. CHANGE RECORD SHEET Description and No. Approval Authorisation 15-Aug-04 Draft Draft issue Phase B input Draft Issue Oct-04 Draft Draft issue for Phase-1 input Draft issue --- Project comments included 08-Oct-04 Issue First issue for Phase-1 input First issue Feb-06 Issue 1 1 Revision including Industry and Project comments 17-Mar-06 Issue 2 draft --- Revision including latest ESOC QMS DRD and Project comments 10-Apr-06 Issue Second issue for ITT. Updated wrt SRR dispositions. Requirements section 2 and 4 moved to SOW and SRD CR No. Revision --- Second draft issue --- Second issue ---

4 : iv DISTRIBUTION LIST Recipient Organisation Recipient Organisation W. Frank OPS-O R. Zobl EOP-P P.P. Emanuelli OPS-OE G. Levrini EOP-PW P. Bargellini OPS-OEA H. Moeller EOP-GDM N. Mardle OPS-OEC S. Lokas EOP-PW J. Piñeiro OPS-OEG R. Torres EOP-PW J.L. Pellon-Bailon OPS-OSA J. Wardill OPS-ONF

5 : v TABLE OF CONTENTS 1 INTRODUCTION PURPOSE AND SCOPE STRUCTURE OF THE DOCUMENT APPLICABLE DOCUMENTS REFERENCE DOCUMENTS MISSION OBJECTIVES GENERAL OPERATIONS CONCEPT SATELLITE OPERATIONS AND FUNCTIONAL REQUIREMENTS GENERAL TELECOMMANDS TELEMETRY TIMING SPACECRAFT AUTONOMY ON-BOARD SOFTWARE DATA ENCRYPTION ASPECTS PACKET FUNCTIONAL REQUIREMENTS GENERAL SERVICE 1: TELECOMMAND VERIFICATION SERVICE 2: DEVICE COMMANDING High-Priority (CPDU) Commands Distribute On/Off and Register Load Commands SERVICE 3: PERIODIC REPORTING SERVICE 4: STATISTICS REPORTING SERVICE 5: EVENT REPORTING SERVICE 6: MEMORY MANAGEMENT SERVICE 8: FUNCTIONS MANAGEMENT SERVICE 9: ON-BOARD TIME MANAGEMENT SERVICE 11: ON-BOARD MISSION TIME LINE SERVICE 12: ON-BOARD MONITORING SERVICE 13: LARGE DATA TRANSFER SERVICE 14: PACKET TRANSMISSION CONTROL SERVICE 15: ON-BOARD STORAGE AND RETRIEVAL SERVICE 17: CONNECTION TEST SERVICE 18: ON-BOARD OPERATIONS CONTROL PROCEDURES MANAGEMENT SERVICE 19: EVENT DETECTION AND ACTION EXECUTION SERVICE >128: MISSION SPECIFIC SERVICES OPERATIONS DATA DELIVERY REQUIREMENTS SENTINEL-1 SYSTEM VALIDATION TESTS Introduction SVT Requirements SENTINEL-1 SPACECRAFT USERS MANUAL Introduction Content Requirements Delivery Requirements SPACECRAFT DATABASE Content Requirements Delivery Requirements... 25

6 : vi 4.4 FLIGHT DYNAMICS DATABASE Content Requirements Delivery Requirements ON-BOARD SOFTWARE Content Requirements Delivery Requirements SENTINEL-1 S-BAND RF SUITCASE Introduction Content Requirements Delivery Requirements ANNEX 1: SPACECRAFT USER MANUAL CONTENTS ANNEX 2: LIST OF ACRONYMS... 28

7 : 7 1 INTRODUCTION 1.1 Purpose and Scope The purpose of this document is to identify the functional requirements on the Sentinel-1 spacecraft, necessary for the conduct of all mission operations. In addition, requirements related to the major deliverable items needed at the Operations Control Centre for the preparation and execution of the mission operations are identified in this document and further detailed in AD-1 and AD-2. The Contractor may, at his responsibility, deviate in his proposal from the specified requirements and tasks but shall state clearly the deviations together with his justification and shall submit the related modifications for the Agency approval. 1.2 Structure of the Document Section 2 provides high-level requirements related to spacecraft operability and autonomy, including telemetry and telecommand functionality. Note that these requirements have been incorporated in the Sentinel-1 SRD, AD-2. Section 3 defines the services related to packet utilisation, and is derived largely from the ECSS Packet Utilisation Standard, RD-1. Section 4 contains the requirements related to the delivery of operational inputs (User Manual, Satellite DB, Flight Dynamics DB, On-board Software deliveries). Note that these requirements have been incorporated in the Sentinel-1 SOW, AD-1, and the Sentinel-1 SRD, AD-2. It should be noted that essential complement to this document are: The Space/Ground Interface Control Document, which contains all details of the structure and functionality of the TM and TC frames and packets. This document will be generated by Industry and presented as part of the space segment PDR. The Satellite Database Interface Control Document, which contains all details on the spacecraft database format. This document will be generated by Industry and presented as part of the space segment PDR. The Sentinel-1 Mission Analysis Report, which contains all assumptions relevant to the definition of the reference orbit and orbit maintenance concept. This document will be generated by Industry and presented as part of the space segment PDR. 1.3 Applicable Documents AD-1 GMES Sentinel-1 Phase B2/C/D/E1 Statement of Work, S1-SW-ESA-SY-0001 AD-2 Annex A: GMES Sentinel-1 System, S1-RS-ESA-SY Reference Documents RD-1 ECSS Ground Systems and Operations. Telemetry and telecommand packet utilisation, ECSS-E A, 30 January RD-2 ECSS Ground Systems and Operations. Part2: Document requirements definitions, ECSS-E-70 Part 2A., 2 April 2001 RD-3 SCOS 2000 Database Import ICD, EGOS-MCS-S2K-ICD-0001, Issue 6.1.

8 : 8 RD-4 SCOS 2000 OBSM External Interfaces Control Document, EGOS-MCS-S2K-ICD-0014, Issue 1.4. RD-5 Sentinel-1 FOP Production Rules and Guidelines, TBD. RD-6 Sentinel-1 Space / Ground Interface Control Document (SGICD), TBD. 1.5 Mission Objectives Sentinel 1 will be the C-Band radar element of the GMES Space Component. Its aim will be to provide continuity to and improve the C-Band earth observation data of programs such as ERS, ENVISAT and the Canadian RADARSAT. An overview of the mission objectives is provided in Annex A, AD General Operations Concept The Sentinel-1 operations concept is defined in Annex A Sentinel-1 System, AD-2.

9 : 9 2 SATELLITE OPERATIONS AND FUNCTIONAL REQUIREMENTS Note: the requirements detailed in this section have been incorporated in the Sentinel-1 SRD, AD General This section considers the general issues related to Spacecraft Control, aiming at a smooth ground to spacecraft interaction. GEN-1 Response time top level requirements are detailed in AD-2, section 4.7 Fault Management. GEN-2 Availability of HK Telemetry top level requirements are detailed in AD-2, section 4.5 Observability Requirements. GEN-3 Guarantee of commanding capabilities from ground top level requirements are detailed in AD- 2, section 4.6 Commandability Requirements. 2.2 Telecommands These requirements are detailed in AD-2, section 4.6 Commandability Requirements. 2.3 Telemetry These requirements are detailed in AD-2, section 4.5 Observability Requirements and section Housekeeping data. 2.4 Timing These requirements are detailed in AD-2, section Timing and section Housekeeping data. 2.5 Spacecraft Autonomy This section contains the requirements related to ground control and monitoring of all on-board autonomous functions. These requirements are detailed in AD-2, section Spacecraft Autonomy and section 4.7 Fault Management. 2.6 On-board Software These requirements are detailed in AD-2, section Memory Loading and Dumping. 2.7 Data Encryption Aspects Data encryption requirements are specified in Annex A Sentinel-1 System Requirements document AD-2.

10 : 10 3 PACKET FUNCTIONAL REQUIREMENTS These requirements define the services applicable to the space-ground interface. The implementation of these services shall conform to the Telemetry and Telecommand packet utilization standard RD-1. Any deviation in the implementation with respect to the standard shall be previously agreed with ESA. The implementation of additional services supported by the standard and not requested in here shall also be previously agreed with ESA. Additional services that might be needed for Sentinel-1 and are not supported by the standard shall be implemented as mission specific services or sub-services, in the numerical range allocated to this purpose, and after agreement with ESA. 3.1 General This section covers the general requirements related to the on-board handling of TM and TC packets. It does not cover specific issues (e.g. the allocation of the TM source packets to the different Virtual Channels), which are specified in the Space/Ground ICD. PACK-1 For Telemetry packets the Application ID (APID) shall be divided into Process ID (first 7 bits) and Packet Category (last 4 bits), to be defined and documented in tables contained in the Space-Ground ICD. Note: this implies that independent Packet Source Sequence Counters are handled by the same on-board packet terminal (Process ID) for each Packet Category. PACK-2 PACK-3 PACK-4 All telemetry packets down-linked as part of VC-0 (except Idle Packets and Time Packets) shall contain a Data Field Header containing the Packet type and subtype. The structure of the Data Field Header shall be exactly identical for all packets containing it. Telecommands destined to different spacecraft subsystems and instruments shall be assigned different Process ID. Telemetry packets originating from a spacecraft unit shall be assigned the same PID as used for the telecommands to that unit wherever possible. Note: this implies that the first 7 bits of the telecommand APID are the same to the ones used for the TM packets. PACK-5 It shall be possible to implicitly derive the location of a parameter within a HK telemetry packet based on its APID, Packet Type/Subtype and up to two additional packets identification fields. Note: For HK TM Packets, this is referred to as the Structure ID (SID). PACK-6 All SIDs shall be unique within an APID and shall be located at a fixed position in all telemetry packets of the same Type/Sub-type. Note: this latter constraint applies also across APIDs i.e. the SID shall be located always in the same position in all packets with the same type/subtype (even though they have different APIDs). PACK-7 PACK-8 PACK-9 The number of SIDs per APID shall be minimised. Parameter sub-commutation (i.e. a sample of a parameter every n-th packets) shall not be used. Parameter super-commutation (i.e. multiple samples of the same parameter within the same packet) is allowed if the parameter is sampled regularly in time, at an interval that is

11 : 11 PACK-10 PACK-11 PACK-12 PACK-13 PACK-14 PACK-15 PACK-16 PACK-17 PACK-18 PACK-19 the same for all occurrences of the packet; consecutive packets guarantee continuous sampling of the parameter and the time offset of the first sample of the parameter within a packet is known. A telemetry parameter shall always have the same structure and interpretation in all telemetry packets in which it appears. Telemetry parameters shall be sampled at a frequency ensuring that no information of operational significance, for all nominal and contingency operations, is lost. The sampling time of a telemetry parameter in a packet with respect to the packet time shall be implicitly and uniquely defined by the packet APID, Type/Subtype and SID. All telemetry packets shall have a time field (with the possible exception of the Time Packet and the idle packets) identifying the packet generation time. The time field of all the housekeeping telemetry packets should have exactly the same time format, with the same maximum range, and the same precision. The time counter in all the telemetry packets shall not wraparound for the duration of the mission, including any conceivable mission extension. Telemetry parameters which are accessible to on-board functions (such as the on-board monitoring) shall be uniquely identified by a Parameter ID which is unaffected by reprogramming activities (such as changing the position of the parameter in the on-board polling and/or in the HK packet). APIDs shall be agreed by ESA Project Office and defined in the Space to Ground ICD. Telecommand packets shall be validated by the destination application process at the moment of acceptance via checksum verification. It shall be possible, but not mandatory, to pack a set of telecommand packets into a single telecommand segment such that they are all encoded and transmitted in the same transfer frame/cltu. After unpacking the command segment, all contained commands shall be sent for execution in the same order as contained in the segment. Note: in addition to the maximum segment length, the only restriction to this shall be that all commands aggregated in the same segment are destined to the same MAP ID, are not CPDU commands, and use the same transmission mode (AD/BD). PACK-20 In case of redundant on-board units that are only allowed to operate in cold stand-by (i.e. only one unit can be on at any given time), the equivalent telecommands and telemetry on the prime and redundant equipment shall be identical and be allocated the same APID. Note: this does not refer to the case where redundant units are supposed to be operated in cold stand-by, but could actually by design be powered and accept TC s simultaneously. In these cases the APID shall be different. Note as well that this refers to the TC/TM accepted/produced by the unit itself. HW statuses that are persistent on a unit power off (configuration registers, relays, etc) shall have different TC/TM for the two units. PACK-21 PACK-22 PACK-23 In case of redundant on-board units that are allowed to operate in hot stand-by, the equivalent telecommands and telemetry on the prime and redundant equipment shall only be different as they use a different destination APID. The data encoding types of telemetry and telecommand parameter fields shall be compliant with the parameter types defined in Section 23 of the ESA Packet Utilisation Standard (see RD-1). Any deviation or addition must be agreed by ESA. The organisation of the data fields forming the telemetry and telecommand packets shall comply with the structure rules specified in Section 23 of the ESA Packet Utilisation Standard (see RD-1). Any deviation or addition must be agreed by ESA.

12 : 12 PACK-24 PACK-25 Whenever present, the Packet Error Control Field of both telemetry and telecommand packets shall be compliant with the Cyclic Redundancy Code as specified in Appendix A of the ESA Packet Utilisation Standard (see RD-1). The Telemetry source packet size shall be limited to a maximum value. This limit shall be defined taking into account the downlink bandwidth and shall be agreed with the Agency. 3.2 Service 1: Telecommand Verification TCV-1 TCV-2 TCV-3 A telemetry packet for successful command acceptance shall be generated by the receiving application for every telecommand properly received and containing valid data. A telemetry packet for unsuccessful command acceptance shall be generated by the receiving application for every telecommand failing any integrity check or containing invalid data. This telemetry packet shall indicate the reason for not acceptance of the related telecommand. A telemetry packet for successful command execution shall be generated by the receiving application for every telecommand properly executed. Note: this requirement applies in particular to report the execution completion of those telecommands which do not have fixed execution duration e.g. Memory Dumps. TCV-4 TCV-5 TCV-6 TCV-7 TCV-8 TCV-9 TCV-10 A telemetry packet for unsuccessful command execution shall be generated by the receiving application for every telecommand not properly executed. This telemetry packet shall indicate the reason for the failed execution of the related telecommand. It shall be possible for the ground to suspend transmission to ground of all successful telecommand verification packets. The level of successful verification required in telemetry (none, acceptance only, acceptance and execution, execution only) shall be controlled by setting appropriate flags in each telecommand. Telecommand verification packets shall indicate the source of the telecommand (e.g. ground, on-board Mission Schedule, other on-board source). Telecommand verification packets shall be generated within 10 seconds from the reception or execution of the related telecommand. In addition to the telecommand verification packets, direct confirmation of the effects of all executed telecommands shall be provided in the housekeeping telemetry wherever applicable. All verification packets for unsuccessful command acceptance or execution shall be stored on-board (as part of the system log ) and available for down-link on-request from ground (as part of the housekeeping virtual channel). 3.3 Service 2: Device Commanding This service includes two different types of commands with respect to their routing. One type is the high-priority commands, distributed directly from the CPDU, and the other is the ones routed via the DMS software. This distinction is used here in the grouping of the requirements.

13 3.3.1 High-Priority (CPDU) Commands : 13 DVC-1 DVC-2 DVC-3 DVC-4 High-Priority Telecommands shall be provided to satisfy the general requirement to be able to command individually and directly any on-board device without imposing any constraint such as that other low level units are currently in an operational state. It shall be possible to issue ON/OFF high-priority telecommands directly from the on-board telecommand decoder. The two telecommand decoders shall support fully redundant high-priority telecommands i.e. both decoders shall be able to perform exactly the same actions but using two independent hardware implementations of high-priority telecommands. The two high-priority telecommands performing the same action (one for each decoder) shall be identical. Note: the actual high-priority telecommand that will be executed will depend on the addressed telecommand decoder Distribute On/Off and Register Load Commands DVC-5 It shall be possible to issue ON/OFF and Register Load Commands and distribute them onboard using the standard bus interface. 3.4 Service 3: Periodic Reporting PERP-1 PERP-2 Periodic telemetry packets shall be fixed in length and shall not contain any variable data field i.e. the interpretation of each packet field shall be implicitly known based on the absolute position of the field within the packet. To allow the definition of special diagnostic telemetry packets that support oversampling of selected parameters for troubleshooting purposes, the on-board system shall ensure that the maximum achievable sampling rate is adequate to perform all required diagnostic operations. Note: in case the maximum achievable parameter sampling rate is limited by the on-board data distribution, it is recommended to perform a local storage of the diagnostic telemetry packets and only initiate their distribution (and downlink) after completing the diagnostic data collection. PERP-3 It shall be possible to define new periodic telemetry packet structures via a dedicated telecommand. Note: it is acceptable that only pre-defined parameters can be included in a newly defined packet. The periodic telemetry packet structures that are created using this service are referred to as programmable telemetry packets in the next requirements. PERP-4 A pre-defined (hard-coded) set of periodic telemetry packets shall be available onboard. Note: spare Structure IDs (SIDs) shall be available for the definition of new housekeeping telemetry packets. PERP-5 PERP-6 It shall be possible to delete the definition of a programmable telemetry packet structure via dedicated telecommand, provided it is not a pre-defined (hard-coded) packet. It shall be possible to enable/disable the generation of a specified programmable telemetry packet via a dedicated telecommand.

14 : 14 PERP-7 PERP-8 PERP-9 It shall be possible to request, via a dedicated telecommand, the generation of a telemetry report containing the current enable status of all programmable telemetry packets. It shall be possible to request, via a dedicated telecommand, the generation of a telemetry report containing the definition of any specified programmable telemetry packet. It shall be possible to set the generation rate of a specified housekeeping (or diagnostic) telemetry packet via a dedicated telecommand. 3.5 Service 4: Statistics Reporting OSF-1 OSF-2 OSF-3 OSF-4 OSF-5 OSF-6 OSF-7 OSF-8 An On-Board Statistics Function (OSF) shall be provided, capable of evaluating the minimum, maximum and average values of selected parameters (including internal Platform S/W parameters) between two subsequent reset commands. It shall be possible to enable/disable the On-Board Statistics Function. The OSF shall be enabled by default whenever the DMS is active. It shall be possible to add parameters to the statistic list by specifying: the parameter to be monitored by means of a mnemonic that uniquely identifies it (see requirement PACK-16 in Section 3.1). It shall be possible to delete a selected parameter from the statistic list. It shall be possible to request a report of the current contents of the statistic list, giving the list of all parameters in the list. It shall be possible to request a report of the current statistics, giving the list of all parameters that are currently in the list along with all the associated data (including at least the average value, the minimum value and the time when it was reached, the maximum value and the time when it was reached). It shall be possible to request the reset of the on-board statistics (without affecting the list of parameters for which statistics are to be evaluated). 3.6 Service 5: Event Reporting EVRP-1 EVRP-2 EVRP-3 EVRP-4 EVRP-5 Event based reporting shall be supported by means of dedicated report telemetry packets (progress, warning or anomaly reports). All on-board events of operational significance, including notification of all on-board autonomous actions, shall be reported in a complete and unambiguous manner using event reports packets. Anomaly reports shall contain a unique identification of the anomaly, its time of occurrence and a record of the input data to the anomaly detection function. Input data to the anomaly detection function shall be recorded on-board such that it can be reported in the anomaly report packet for an appropriate interval of time centred in the time of occurrence of the anomaly. Individual Event or Anomaly reports should not contain variable data, i.e. for a specific event id the packet length should be constant. The design of the reporting mechanism shall be such to avoid excessive use of the down-link bandwidth (and of the on-board storage capacity).

15 : 15 Note: This means that anomaly reports shall be generated only once per anomaly occurrence, even if the detection cycle repeats itself. EVRP-6 EVRP-7 EVRP-8 EVRP-9 Information to identify the nature of the report packet shall be contained in the packet data field header. For processes with a long execution time the start and the end of the process shall be reported in telemetry via event reports. In addition, progress event reports either periodically or at pre-determined steps in the process shall be provided. All anomaly report packets shall be stored on-board as part of the system log and available for down-link on-request from ground (as part of the real-time house-keeping TM virtual channel). It shall be possible to clear the current on-board storage of anomaly report packets on ground request. 3.7 Service 6: Memory Management The requirements specified in this section refer to the management of on-board memories containing software code and/or data. This section is not relevant to the management of the mass memories containing stored telemetry data (see section 3.14). MM-1 MM-2 MM-3 MM-4 MM-5 MM-6 Functionally distinct memory areas shall be assigned to the following categories: code; fixed data; variables and parameters. It shall be possible to load any changeable memory area from ground. As a minimum, it shall be possible to load, with a single telecommand packet, a contiguous memory area (e.g. by indicating the start address for loading, the length of the load and the data to be loaded). In addition, it is desirable to be able to perform scatter loads (e.g. by specifying a set of memory addresses, length and data to be loaded). Each telecommand packet needed to load any area of memory shall be self-consistent, i.e.: the successful load shall not depend on previous packets; any single TC packet which is rejected may be uplinked at a later time without forcing re-uplink of other related TC packets already successfully uplinked. It shall be possible for the ground to dump any memory area (including non-volatile memories), on request except crypto related memory areas. It shall be possible for ground to dump the contents of the OBC mass memory for diagnostic purposes. Note: this is intended exclusively for trouble-shooting, and shall never be used to perform the nominal OBC telemetry dump. The requirements related to the nominal dump of the mass memories are specified in section MM-7 MM-8 The memory dump request shall specify the name of the memory to be dumped and indicate either a contiguous memory area (e.g. by indicating the start address and the length of the dump) or a scatter-dump (e.g. by specifying a set of pairs of start address and length). Only a single telecommand packet shall be required for a memory dump request, even if several telemetry source packets are required to convey the dumped data to the ground.

16 : 16 MM-9 A dump telemetry packet shall only be allowed to contain memory data covering memory areas that are associated to contiguous memory addresses. Note: this implies that several telemetry packets shall be generated to cover any area showing discontinuities in the memory addresses e.g. due to memory pages. MM-10 MM-11 MM-12 MM-13 It shall be possible for the ground to request a check of a specified area of an on-board memory over one range of memory addresses. In response to a request to check memory, the on-board action shall be to perform a check-summing over the requested addresses and report the result to the ground. The memory checksum algorithms used on-board shall be compliant with Appendix A of the ESA Packet Utilisation Standard (see RD-1). All the telecommand and telemetry parameters for the load and dump of a given memory area shall be expressed in the same unit of size. Note: This means that the increment from one address to the next should be the same number of octets that is used as a unit for specifying the length. MM-14 There shall be no grouping constraint in the number of addresses that can be loaded or dumped. Note: this means that it shall not be needed to command patch or dumps where the length or start address has always to be a multiple of a given number. MM-15 There shall be no need when commanding a memory load to insert dummy octets in the memory data part of the command. Note: e.g. it shall not be needed to insert an additional dummy octet at the end of the command depending on whether the patch length is even of odd, or it shall not be needed to insert a number of dummy octets after each group of so many octets of real data. MM-16 It shall be possible to load and dump all the on-board memories (except crypto memory areas) using physical addressing from a static image on ground. Note: This means that it shall not be necessary to use an address-mapping table in order to generate the commands from the image, or reconstruct the image from dump packets. MM-17 There shall be a sanity check of the load and dump commands before execution, that shall include at least a range check of the commanded addresses. In case the check fails, the command shall not be executed, and an execution failure report shall be generated. 3.8 Service 8: Functions Management Note that that differently to the old ESA PSS PUS, the ECSS Packet Utilisation standard (RD-1) allows two ways of implementing task or function control (e.g. start and stop task, load parameters, etc): As mission-specific services, with their own request (TC) and report (TM) data structures and service subtype models (typically a service subtype to start function, one to stop, one to load parameters, etc). Using a single, generic, high-level function service. In this concept, the function itself is specialised (e.g. configure experiment mode, set AOCS control mode), but the associated packet structure is standardized. Although the following requirements are formulated more inline with the terminology of the first bullet above, the requested functionality is applicable to and could also be implemented with the approach

17 : 17 mentioned in the second bullet. FM-1 FM-2 It shall be possible for the ground to exercise control over an on-board software Application Function in the following manner: activate a Function; de-activate a Function; suspend/resume a Function (when meaningful for the function); communicate parameters to a Function. Any communication between the ground and a Function shall be effected by means of telecommand and telemetry source packets specifically designed for the purpose. Note: this means that the communication should not be achieved by using general-purpose memory write (memory load) and memory read (memory dump) packets. FM-3 It shall be possible for the ground to inspect the loaded Function parameters at any time prior to Function activation as well as whilst they are used. 3.9 Service 9: On-Board Time Management See also requirements in section 2.4. OBTM-1 OBTM-2 OBTM-3 It shall be possible for the ground to add a specified delta-time to the current DMS on-board time. All Packet Terminals shall support time synchronisation with the DMS Master Clock. The current DMS time reference shall be regularly downlinked (in a Time Packet) 3.10 Service 11: On-Board Mission Time Line OBMT-1 OBMT-2 OBMT-3 OBMT-4 OBMT-5 OBMT-6 The On-Board Mission Schedule shall be implemented as a Command Scheduling function using UTC-CCSDS time (MTL) or orbit position information (OPS) for tagging of individual commands. It shall be possible to build OPS Command Schedules based on Orbit Position, defined as Orbit Number and Orbit Angle relative to the ascending node. It shall be possible to load any S/W telecommand (including those which operate on the Command Schedule MTL/OPS itself) into storage on-board for execution at a location and/or time specified at the time of uplink within the telecommand packet. The satellite shall accept and order telecommands uplinked with an arbitrary sequence of time/position tags without interrupting nominal operations. The Command Schedule (MTL/OPS) shall be implemented in the DMS only. The Command Schedule (MTL/OPS) shall be active by default whenever the DMS is active. The Command Schedule (MTL/OPS) shall be capable of storing any and all the telecommands needed for the execution of operations, with the exception of high priority commands. This includes operations requiring accurate timing and operations over long non-coverage periods. Note: this imposes a constraint in the maximum allowed length of the software telecommands (as

18 : 18 otherwise it would not be possible to encapsulate them in the Insert Time/Postion-tag Command packet and still respect the maximum allowed length of the command segment). OBMT-7 OBMT-8 OBMT-9 It shall be possible to start/stop or reset the entire Command Schedule (MTL/OPS) by telecommand. It shall be possible to insert, overwrite and append commands to the Command Schedule (MTL/OPS), without the necessity of first stopping it. It shall be possible to associate commands to be inserted into the Command Schedule (MTL/OPS) to an execution time-tag and a sub-schedule ID. Note: the sub-schedule ID mechanism allows the logical grouping of MTL/OPS commands. The execution time-tag can be expressed as UTC-CCSDS or orbit position information. OBMT-10 OBMT-11 OBMT-12 A command loaded in the MTL with an expired execution time/position shall be rejected by the on-board software. A command loaded in the MTL with an execution time/position equal to a previous command shall not be rejected but executed as soon as possible after the other command with the same execution time/position. It shall be possible to enable/disable the release of commands from the on-board Mission Schedule: For all commands. For commands with a specific APID and all subschedule ID. For commands with a specific subschedule ID and all APID. For a specific APID/subschedule ID combination. OBMT-13 It shall be possible to delete commands from the MTL/OPS, without the necessity of first stopping it. The delete options shall include: one or more commands of a specified APID with contiguous Source Sequence Counters; all commands (i.e. reset/clear the MTL/OPS contents); commands from a specified time/position onwards; commands between two specified times/positions; using the two time/position based options above, it shall be possible to filter the deletion of commands by specifying one APID or Sub-Schedule ID. Note: the time can be expressed as UTC-CCSDS or orbit position information. OBMT-14 It shall be possible to time-shift (advance or retard) commands which have already been loaded in the MTL/OPS. This function is required to support re-planning of operations and to avoid having to delete and re-load the affected commands. The options for time-shifting shall include: Commands from a specified time onwards; Commands between specified times; Individual commands. These options shall be possible for either "all Application Process IDs", "specified application Process IDs only" or specified filter class (Sub-schedule) only. Note: the time can be expressed as UTC-CCSDS or orbit position information. OBMT-15 It shall be possible to request a report of the summary contents of the MTL/OPS containing for each command: Subschedule ID Time tag (expressed as UTC/CCSDS or orbit position) Packet Header

19 : 19 OBMT-16 OBMT-17 Data Field Header It shall be possible to request a full report of a single command in the MTL (identified by APID and SSC) containing: Subschedule ID Time Tag (expressed as UTC/CCSDS or orbit position) Telecommand Packet Length Raw Dump of the complete telecommand packet A command in the MTL/OPS which is disabled at the time when it is due for execution shall be removed from the MTL/OPS but not issued to its destination APID Service 12: On-Board Monitoring The On-Board Monitoring Function supports the ability to monitor the value of selected telemetry parameters. The violation of a parameter monitoring criteria leads to the generation of an event with a specified ID and thus can be used to automatically trigger the execution a predefined command via service 19 (typically the start of an OBCP). OBMF-1 An On-Board Monitoring Function (OBMF) shall be provided, capable of monitoring selected parameters including internal Platform S/W parameters. Note: it is acceptable that only pre-defined parameters can be selected for the on-board parameter monitoring function. OBMF-2 OBMF-3 The OBMF shall be enabled by default whenever the DMS is active. It shall be possible to add/modify monitoring checks to the parameter monitoring list by specifying: the parameter to be monitored by means of a mnemonic which uniquely identifies it (i.e. the parameter ID as defined in PACK-16, section 3.1). the type of monitoring to be applied (e.g. expected value, range) an upper and lower limit (or a single value in case of monitoring against an expected value) the sampling interval for the onboard monitoring (i.e. the monitoring frequency); a repetition filter, specifying the number of consecutive times that a parameter shall be registered as failing a check before being reported as such; the ID of the event report to be generated in case of monitoring check violation. Note: The event report ID can be optionally linked to an on-board action using Service 19. OBMF-4 OBMF-5 OBMF-6 It shall be possible to enable/disable a selected monitoring check. It shall be possible to enable/disable several monitoring checks using a single telecommand. It shall be possible to enable/disable the On-Board Monitoring Function using a single telecommand. Note: the execution of this command shall not affect the individual enable/disable state of each monitoring check. OBMF-7 It shall be possible to delete a selected monitoring check (provided that it is currently in a disabled state).

20 : 20 OBMF-8 OBMF-9 OBMF-10 A telemetry event packet with the specified ID shall be generated whenever an enabled monitoring check is violated, i.e. a monitored parameter has been detected out-of-limits based on the above specified monitoring criteria. It shall be possible to request a report of the current contents of the monitoring list, giving the list of all monitoring checks along with all the associated data (including the current status, i.e. enabled/disabled). It shall be possible to request a report of the out-of-limit list, giving the list of all monitoring checks that are currently in a non-nominal status along with all the associated data (including at least the limit violated, the parameter value and the check violation time) Service 13: Large Data Transfer There has been no requirement for this service identified for Sentinel Service 14: Packet Transmission Control PTXC-1 PTXC-2 PTXC-3 It shall be possible to enable/disable from ground the real-time transmission to the ground of selected telemetry HK packets (identified by the combination of APID and SID). It shall be possible to enable/disable the transmission to the ground of selected telemetry event packets (identified by the combination of APID and Event ID). It shall be possible to request a report listing all the HK and Event packets that are currently disabled for down-link Service 15: On-board Storage and Retrieval A Packet Store is defined as an area of the on-board Mass Memory in which packets are stored in the generation order, for later dump to the ground. The definition of which packets are stored in which Packet Store shall be contained in an on-board table which can be maintained by dedicated telecommands. The creation, size modification and deletion of Packet Stores is considered an on-board software maintenance activity. OBSR-1 OBSR-2 OBSR-3 OBSR-4 OBSR-5 A central on-board telemetry storage capability shall be implemented in the DMS. It shall be possible to record all telemetry packets that are generated on-board on the onboard storage, independently of the status of their transmission to ground at the time when they were generated. Storage shall be organised in virtual storages called Packet Stores. The selection of which telemetry packets shall be stored in which Packet Store shall be maintainable by means of dedicated telecommands. Any number of packets can be assigned to a specific Packet Store. The on-board telemetry storage shall support at least one Packet Store for each TM virtual channel used to down-link the stored telemetry (excluding the possible virtual channels generated by the hardware, e.g. VC-7 for the idle frames). It shall be possible to assign a specific telemetry packet to more than one single Packet

21 : 21 OBSR-6 OBSR-7 OBSR-8 OBSR-9 OBSR-10 OBSR-11 Store provided that they are down-linked in different TM virtual channels. It shall be possible to request a report of the current storage selection definitions. Telemetry shall be stored cyclically. Packet Stores shall be individually configurable such that either old data are overwritten or recording is stopped once the store is full. For Packet Stores with disabled overwrite, only stored data which have already been downlinked shall be overwritten by new data to be stored. Old data which have not been downlinked yet shall not be overwritten. It shall be possible for the ground to suspend/resume the down-link of the stored telemetry packets from a selected Packet Store. It shall be possible for the ground to suspend/resume the down-link of the stored telemetry packets for all Packet Stores using a single telecommand. When resuming the down-link of the stored telemetry packets, the dump shall start from the oldest undumped packet in the selected Packet Store. Note: the oldest undumped packet in the selected Packet Store is referred to in the following requirements as the Nominal Read Pointer. In case old data have been overwritten before being down-linked, this requirement implies that the down-link is resumed from the oldest packet in the Packet Store i.e. the Write Pointer pushes the Nominal Read Pointer. OBSR-12 OBSR-13 It shall be possible for the ground to set the Nominal Read Pointer to a specified point (identified by a packet) in a selected Packet Store. It shall be possible for the ground to request the down-link of all telemetry packets within a specified packet range (identified by a Start and End Packet) from a selected Packet Store. Note: this mechanism allows recovering telemetry data that have already been dumped but not received on ground for any reason. The Nominal Read Pointer shall not be affected by the execution of this extra dump operation (i.e. an independent Read Pointer shall be maintained for the two dump mechanisms). The packets to be down-linked shall not include the Start and End Packets used to identify the packet range (since these packets are the last one received before the gap, and the first one after respectively). OBSR-14 OBSR-15 OBSR-16 OBSR-17 OBSR-18 OBSR-19 OBSR-20 The down-link shall be stopped as soon as the specified End Packet is reached or in case the Nominal Read Pointer is reached before finding the specified End Packet. Housekeeping information shall be provided on the state of the on-board storage and retrieval function. Information on the used and available space on the on-board storage shall be included in the housekeeping telemetry. Information on the most recent down-linked packet (Packet APID, SSC and time) shall be available in the housekeeping telemetry. It shall be possible for the ground to enable and disable the storage function for a selected Packet Store. The storage of packets shall not be interrupted during the dump or the deletion operations of the current content of the on-board storage. It shall be possible to dump several Packet Stores simultaneously. Note: This could be achieved by either interleaving the packets read from different stores in the downlink according to a programmable bandwidth allocation, or reading a single Packet Store at any time, but configuring the downlink operation by providing an ordered list of Packet Stores to be dumped when the downlink is resumed. OBSR-21 It shall be possible for the ground to request the downlink of the telemetry packets

22 : 22 stored within a specified time range of a selected Packet Store from the on-board storage Service 17: Connection Test CTC-1 CTC-2 Dummy commands shall be provided for testing the end-to-end connection between ground and the DMS and/or any other on-board intelligent user. End-to-end verification of Dummy commands shall be provided by means of the standard command verification telemetry packets (see Service 1 above) Service 18: On-board Operations Control Procedures management OBCP-1 OBCP-2 It shall be possible to control OBCPs, via specific telecommand packets, in the following manner: start an OBCP; stop an OBCP; suspend an OBCP; resume an OBCP. Communicate parameters with an OBCP. In normal operations (as opposed to non-nominal situations), it shall be possible to communicate with an OBCP (i.e. pass it parameters or modify variables used by the OBCP) without the need for the ground to first stop, or suspend, the OBCP. OBCP-3 OBCP-4 It shall be possible for the ground to inspect the loaded data/control parameters and variables utilised by an OBCP at any time before, during or after the OBCP run. It shall be possible for the ground to load a new OBCP or to delete an existing one. Note: it is admissible that the actual load of the code for an OBCP is not done using service 18, but using service 6 instead. The process of declaring an OBCP (assigning a procedure ID to it) shall nevertheless be done using service 18. OBCP-5 OBCP-6 OBCP-7 OBCP-8 OBCP-9 It shall be possible for the ground to request a list of all OBCPs stored on-board. It shall be possible for the ground to request a list of all OBCPs that are currently active. The nominal progress in the execution of OBCPs shall be reported to ground by means of normal/progress event packets which are stored in the System Log. Any anomaly detected in the execution of OBCPs shall be reported to ground by means of error/anomaly event packets. The OBCP service shall provide the following minimum set of functionality: Send on-board TC with parameters Perform a wait for a certain delay. Access parameters in the TM datapool and take a logical decision based on the value (if-thenelse type of functionality). OBCP-10 The OBCP service shall include a prioritisation scheme ensuring correct completion of any triggered OBCP.

23 : Service 19: Event detection and Action execution EAF-1 EAF-2 EAF-3 EAF-4 EAF-5 EAF-6 An On-Board Event Detection and Action Execution Function (EAF) shall be provided, capable of monitoring selected on-board events such to trigger the execution of a specified command. The EAF shall be active by default whenever the DMS is active. It shall be possible to add entries to the event detection list by specifying: The identification of the event to be monitored (identified by the combination of PID and monitored event ID); One command (fully encoded) to be executed in case of detection of the specified event (typically this command will be used to start the execution of an OBCP). It shall be possible to enable/disable the execution of the action associated to a selected monitored event. It shall be possible to delete a selected entry in the event detection list (provided that its associated action is currently in a disabled state). It shall be possible to enable/disable the Event/Action Function using a single telecommand Note: the execution of this command shall not affect the individual enable/disable state of the actions associated to each monitored event. EAF-7 EAF-8 EAF-9 It shall be possible to request a report of the current contents of the event detection list, giving the list of all monitored event identifications together with all the associated data (including the current status, i.e. action enabled/disabled). A telemetry event packet shall be generated whenever an action is executed after being triggered by the detection of a monitored event. For the management of the actions triggered by the EAF the DMS shall provide a mechanism to cope with multiple entries triggering from the EAF without causing interference (e.g. prevent parallel triggering and handle a queuing mechanism) Service >128: Mission Specific services MISC-1 Any capability requiring definition of a mission specific PUS type, shall be allocated a service type number > 128. MISC-2 Any capability requiring definition of a mission specific PUS subtype, shall be allocated a service subtype number > 128.

24 : 24 4 OPERATIONS DATA DELIVERY REQUIREMENTS This section defines the requirements on delivery schedule and content of the Spacecraft Users Manual, the Spacecraft Database and the Flight Dynamics Database and the delivery of the On-board software to ESA. It has to be noted that the various software, and operational data inputs delivery requirements are linked to the System Validation Test (SVT) preparation activities and ultimately SVT execution dates. Note: the requirements detailed in this section have been incorporated in the SOW, AD-1 and the Sentinel-1 SRD, AD Sentinel-1 System Validation Tests Introduction Industry will provide access to the satellite for System Validation Testing with the overall ground segment. The SVT schedule will be incorporated into the AIV programme. SVTs will be based on Plans and Procedures produced by ESA and conducted by ESA personnel. The connection with the satellite will be established making use of an ESA provided Network Data Interface Unit (NDIU) SVT Requirements These requirements are detailed in AD Sentinel-1 Spacecraft Users Manual Introduction The Users Manual is the prime source of information used by ESA for establishment of the ground facilities needed to support the Sentinel-1 mission, and needed to correctly and reliably perform all mission operations. In this respect, the document must provide a clear, concise and comprehensive definition of all design, interface and, most importantly, all operational characteristics associated with control of the spacecraft in flight. Note: in the following subsections the term Spacecraft Users Manual (SUM) is used as equivalent to the Spacecraft Flight Operations Manual (FOM). The document shall consist of five parts: Mission definition. System definition. Subsystem definition. Instruments definition. A set of Annexes In simple terms the Users Manual must address the following aspects of the spacecraft and its design:

25 : 25 What it is What it has to do How it works How to operate it What to do if it doesn't go according to plan Content Requirements These requirements are detailed in AD Delivery Requirements These requirements are detailed in AD Spacecraft Database Content Requirements The detailed contents of the Spacecraft DB, and the topology and format information that is needed in order to import and use it in the Operations Control Centre, shall be defined in a dedicated ICD. This section covers the highest-level requirements. These requirements are detailed in AD Delivery Requirements These requirements are detailed in AD Flight Dynamics Database Content Requirements These requirements are detailed in AD Delivery Requirements These requirements are detailed in AD On-Board Software Content Requirements These requirements are detailed in AD-1.