SIST EN 17350:2020

SLOVENSKI STANDARD
SIST EN 17350:2020
01-oktober-2020
SCM - Obrazec za časovno razporejanje in vodenje - Standardizirani format
SCM - Scheduling and Commanding Message - Standard
Raumfahrt - Überwachung der Weltraumlageerfassung - Planungs- und Kommando-
Nachricht
SCM - Message de planification et de commande - Norme
Ta slovenski standard je istoveten z: EN 17350:2020
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
SIST EN 17350:2020 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST EN 17350:2020

---------------------- Page: 2 ----------------------
SIST EN 17350:2020


EUROPEAN STANDARD
EN 17350

NORME EUROPÉENNE

EUROPÄISCHE NORM
August 2020
ICS 49.140

English version

SCM - Scheduling and Commanding Message - Standard
SCM - Message de planification et de commande - SCM - Planungs- und Befehlsnachricht - Standard
Norme
This European Standard was approved by CEN on 17 May 2020.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
























CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2020 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 17350:2020 E
reserved worldwide for CEN national Members and for
CENELEC Members.

---------------------- Page: 3 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
Contents Page

European foreword . 4
0 Introduction . 5
0.1 Document structure . 5
0.2 Verbal conventions . 5
1 Scope . 6
1.1 Purpose . 6
1.2 Applicability . 6
2 Normative references . 6
3 Terms, definitions, symbols and abbreviations . 6
3.1 Terms and definitions . 6
3.2 Symbols and abbreviations . 9
4 Overview — Context of the document . 10
5 General nature of the standard — Documentation within the format . 11
6 SCM structure and content . 11
6.1 General structure . 11
6.2 Nested logical segments in the format. 15
6.3 Auxiliary messages . 15
6.4 General rules . 15
6.5 OS Control Computer and OS Scheduler Inputs . 17
6.6 Quantization of Commands/Requests . 18
6.7 Parameter Types . 18
7 Detailed SCM Syntax . 19
7.1 Introduction: First-Level Structure . 19
7.2 Definition of the segment 'header' . 20
7.3 Definition of the segment 'metaData' . 21
7.4 Definition of the segment 'commonData' . 23
7.5 Definition of the segment 'command' . 23
7.6 Definition of the segment 'scheduleRequest' . 34
7.7 Macros . 46
8 Sequence higher level structures . 46
8.1 Higher Level logical structures (“sequence” segments) . 46
8.2 Handling of FITS header keywords — General expected behaviour in regard to
writing to FITS headers . 49
Annex A (informative) Commanding and Scheduling Message background . 50
Annex B (informative) Examples . 51
B.1 Commanding a Series of Observations . 51
B.2 Requesting Follow-up observations two hours apart . 54
Annex C (informative) Survey Strategy Types and Related Parameter Requirements —
Description of Survey Strategies . 59
2

---------------------- Page: 4 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
C.1 General . 59
C.2 Parameter Requirements for Survey Strategy Type 1 (vertical strip) . 61
C.3 Parameter Requirements for Survey Strategy Type 2 (horizontal strip) . 61
C.4 Parameter Requirements for Survey Strategy Type 3 (free mosaic) . 61
Annex D (informative) Handling of Filter Requests . 62
D.1 Filter specification. 62
D.2 Specifying narrowband filter types (wavelength value) . 63
Bibliography . 64


3

---------------------- Page: 5 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
European foreword
This document (EN 17350:2020) has been prepared by Technical Committee CEN/CLC/JTC 5 “Space”,
the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2021, and conflicting national standards
shall be withdrawn at the latest by February 2021.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
4

---------------------- Page: 6 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
0 Introduction
0.1 Document structure
Clause 2 provides an overview of the SCM.
Clause 3 describes the scope and general nature of the SCM.
Clause 4 describes the general format of the SCM standard.
Clause 5 describes the detailed syntax of SCM communications.
Clause 6 provides additional information about headers.
Annex A (informative) provides SCM background.
Annex B (informative) provides SCM examples.
Annex C (informative) describes the survey strategy types and related parameter requirements.
Annex D (informative) informs about the handling of filter requests.
0.2 Verbal conventions
The following conventions apply:
a) 'shall' implies a requirement;
b) 'should' implies a recommendation;
c) 'may' implies a permission; and
d) 'is', 'are', and 'will' denote factual statements.
5

---------------------- Page: 7 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
1 Scope
1.1 Purpose
The “Scheduling and Commanding Messages” (SCM) specifies a standard format for observing system
commanding and scheduling. This document aims to ease the planning and operation processes and to
reduce the efforts from researchers that use several different observing systems and/or simulation
software products.
The SCM establishes a common language for exchanging information on planning, scheduling, and
executing observations of celestial objects. In the end this will:
a) Facilitate interoperability and enable consistent warning between data originators who supply
celestial observations and the entities or researchers who use it; and
b) Facilitate the automation of observation processes.
1.2 Applicability
The SCM is applicable to ground-based activities related to the planning, scheduling, and execution of
the observations of celestial objects. It is used by planning software, scheduling software, telescope
commanding software. It is applicable for optical telescopes.
2 Normative references
There are no normative references in this document.
3 Terms, definitions, symbols and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1.1
Observing System Command File
“observation plan”
data file which is used to control an observing system (OS), which contains absolute information on
actions the OS is due to perform, e.g. absolute times and sky coordinates for observations, and which is
read by an OS control computer that still processes part of their content (e.g. conversion of equatorial
coordinates to telescope hardware coordinates, execution of pre-defined standard routines for
calibration processes that are called by a single entry in the command file, etc.) and sends commands to
the hardware drivers
6

---------------------- Page: 8 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
3.1.2
Observing System Scheduler Input File
“scheduler request”
data file providing input to an observation scheduler
Note 1 to entry: Opposed to Observing system command files, these files usually do not contain absolute
information on when an OS is due to perform a certain action, but rather constraints that allow a scheduler to
flexibly allocate the requested actions. The scheduler, on the other hand, can write command files which are
subsequently passed on to an OS control computer.
3.1.3
Hardware Driver Input
commands that are produced by an OS control computer and are selectively sent to the according
hardware drivers, e.g. the telescope mount drivers, dome drivers, etc.
3.1.4
Near-Earth Object
NEO
Solar System objects whose orbit brings them into close proximity with the Earth, which all have a
6
perihelion distance < 1.3 astronomical units (the distance Sun - Earth, ~149,6x10 km), and which
include near-Earth asteroids (NEAs), near-Earth comets, a number of solar-orbiting spacecraft, and
meteoroids large enough to be tracked in space before striking the Earth
3.1.5
follow-up
term used in the NEO field, identical to 'tracking' in the SST field. It is a specific effort to obtain
observations of an interesting object at times subsequent its discovery, with the goal of improving the
knowledge of its orbit and the predictability of its future motion
Note 1 to entry: Follow-up telescopes are generally distinct from survey telescopes, and operate with a more
close supervision of an observer, which selects the targets in need of follow-up. Survey telescopes may also
observe known objects, thus providing follow-up observations, although these observations are often not the goal
of the project.
Note 2 to entry: 'Tracking' is used in the SST field and identical to 'follow-up' in the NEO field.
3.1.6
range
radial distance between an observer and an object at a given instant of time, which is one of the direct
observable that can be derived from a radar observation, by measuring the travelling time of a radio
wave reflected from the object's surface, and which, since ground-based optical astrometry does not
allow to directly determine radial distances, range measurements from radar are extremely powerful
for orbital determination
3.1.7
survey
project operating telescopes designed to detect unknown moving objects in the sky, some of which will
become new discoveries
Note 1 to entry: Surveys typically operate in a mostly automated way, and can detect and report measurements
for thousands of objects every night.
7

---------------------- Page: 9 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
3.1.8
sensor
in the SST field, complete observation system, i.e. an optical telescope together with its camera, or a
radar system
in the NEO field, detector, i.e. light-sensitive device in a camera (CCD or CMOS)
8

---------------------- Page: 10 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
3.2 Symbols and abbreviations
Table 1 — Symbols
n.a. not applicable
Table 2 — Abbreviations
ASCII American Standard Code for Information Interchange
ASCOM Astronomy Common Object Model
AstDyS Asteroids Dynamic Site
CCD Charge-Coupled Device
CCSDS Consultative Committee for Space Data Systems
CDM Conjunction Data Message
CMOS Complementary Metal–Oxide–Semiconductor
ESA European Space Agency
ESO European Southern Observatory
FITS Flexible Image Transport System
IAC Instituto de Astrofísica de Canarias
INDI Instrument-Neutral Distributed Interface
JSON JavaScript Object Notation
NEO Near-Earth Object
NEODyS Near-Earth Objects Dynamic Site
OCA Observatoire de la Côte d'Azur
OGS Optical Ground Station
OS Observing System
RTML Remote Telescope Markup Language
RTS2 Remote Telescope System 2nd Version
SCM Scheduling and Commanding Message
SSA Space Situational Awareness
SST Space Surveillance and Tracking
TBT Test Bed Telescope
TDM Tracking Data Message
TLE Two-line element
UTC Coordinated Universal Time
VLT Very Large Telescope
XML eXtensible Markup Language

9

---------------------- Page: 11 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
The SCM generally uses units that are part of the International System of Units (SI), either base, derived,
or non-SI units that are accepted for use within the SI. The following units are used in the SCM:
Table 3 — Unit conventions
deg decimal degrees
as seconds of arc (1/3 600 °)
m meter
mm millimetre
nm nanometer
s SI seconds
min minutes (60 SI seconds)

In order to simplify the standard and the interface to an observing system control computer or
scheduler, only one notation per parameter is foreseen.
4 Overview — Context of the document
This document gathers the requirements described in the Proposal for a Telescope Commanding and
Scheduling Data Standard [2].
The basic application scenarios of the standard are illustrated in Figures 1 and 2, once for the
application as a scheduler input file and once for the application as an OS command file.
In the first case, the SCM file is created by a human operator or an automated planning tool and either
directly submitted to an observation scheduler or retrieved by it from a database. The scheduler creates
an observation schedule based on the targets and constraints provided in the SCM and sends
corresponding commands to the OS control computer. In case of an OS network it is also possible that a
central scheduler sends commands to several OSs. The scheduler can be located at the OS or work
remotely. The scheduler needs to be reasonably “smart” to interpret the constraints in the SCM and to
preferably calculate pointing coordinates from provided object ephemerides or retrieve information on
objects from online sources.

Figure 1 — Basic context of SCM used as a scheduler input file
It is well possible that the observation scheduler passes on the command to the OS control computer via
another SCM, as illustrated in Figure 2. The OS control computer in this case is likely to be allocated
somewhere close to the OS. It needs to be much less “smart” than the scheduler, assuming that in the
typical case it will already be provided by a simple coordinates and timing information.
10

---------------------- Page: 12 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)

Figure 2 — Basic context of SCM used as OS command files
5 General nature of the standard — Documentation within the format
For individual images, the FITS (Flexible Image Transport System) standard allows the inclusion of a
considerable amount of information in the machine- and human-readable image header. There is thus
no need to duplicate this information in a separate file for observations of several images. The same
applies to information on used hardware in robotic OS networks where observation requests are not
submitted to individual OSs. The information on the OS used can also be written to the images' FITS
headers, as done in the Las Cumbres Observatory Global Telescope Network, for example. In case of
larger campaigns, however, it might be useful to have access to concise observation history in one file
(i.e. which observations have really been carried out, actual observation conditions, …). For the sake of
clearness, it is preferable to have this information in a single file, not interrupted by command or other
information.
To guarantee traceability from an image to the underlying command, the command message format
foresees the option to request the command message ID (and potentially also its location) to be written
into the image's FITS header.
6 SCM structure and content
6.1 General structure
6.1.1 General
An SCM file consists of at least one “observation block” which can be either a “command” or a “schedule
request”. The “header” element contains basic parameters of the message itself. All actual commanding
parameters for the OS are, in the basic case, included in a “command” element. In this element, the
camera to be used is specified, the path and filename where the resulting image file shall be saved are
detailed, information to be written into the image file’s FITS header can be passed on, and the physical
observation parameters are transferred. Hereby, coordinates are defined in decimal degrees, exposure
time in seconds. If more than one observation is desired, another “command” segment can be added at
the end of the file. Overlapping information can be defined for all “commands” in a “commonData”
segment.
The standard is described in an XML-based language. The logical layout of an XML document always
follows a tree structure. The higher-level structure of an SCM is shown in Table 4.
11

---------------------- Page: 13 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
Table 4 — Higher-level structure of an SCM

 - Header
 - MetaData
   - Project
   - Contact
   - Linked SCM
   - Wait Constraint
 - Common Data
   - Camera
   - Device
   - Spectrograph
   - Image Data
   - Target
   - Surey Strategy
   - Exposure
   - Observation
   - Macros
 - Command
   - MetaData
   - Camera
     - Detector
     - Chips
     - Chip
     - Windowing
     - Binning
    - Device
     - Device
    - Spectrograph
     - Detector
     - Device
     - Grating
     - FilterWheel
     - Slit
     - xyPosition
     - Coordinates
    - ImageData
      - FitsHeader
    - Target
      - Coordinates
      - Ephemerides
      - OrbitalElements
      - RaDecList
      - TargetBrightness
      - TrackRate
    - CalibrationObservation
    - Exposure
      - Dithering
    - Shutter
    - Observation
 - ScheduleRequest
12

---------------------- Page: 14 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
    - MetaData
      - LinkedBlock
    - Camera
     - Detector
     - Chips
     - Chip
     - Windowing
     - Binning
    - Device
     - Device
    - Spectrograph
     - Detector
     - Device
     - Grating
     - FilterWheel
     - Slit
     - xyPosition
     - Coordinates
    - ImageData
     - FitsHeader
    - Target
     - Coordinates
     - Ephemerides
     - OrbitalElements
     - RaDecList
     - TargetBrightness
     - TrackRate
    - SurveyStrategy
    - Constraints
      - AirmassConstraint
      - DateTimeConstraint
      - EclipticConstraint
      - ExposureConstraint
      - FieldOfViewConstraint
      - GalacticPlaneConstraint
      - InformationGainConstraint
        - Interval
      - MoonConstraint
      - NightConstraint
      - SunConstraint
      - WaitConstraint
      - Other Constraints
    - CalibrationObservation
    - Exposure
      - Dithering
    - Shutter
    - Observation

6.1.2 XML document header
The header carries information on the format of the document, but also information necessary to check
the validity of the XML document (through the comparison with an XML grammar). It also lists the
document’s unique identification code.
13

---------------------- Page: 15 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
As Figure 3 shows, the third part of the document header appears in the form of attributes of the root
element (shown as red dots in the tree diagram). As the ASCII code of the header below shows, these
are written directly into the opening tag of the root element. The content of the attributes is added on
the right side in XML Notepad, or in the form attribute=”content” in ASCII format.

Figure 3 — XML document declaration and root element attributes
1 XML declaration. Defines the XML version and the character encoding.
2 Root element of the document (i.e. defining: “this is an SCM document”)
3 Root element attributes. Each has the following functions:
 xmlns:xsi - defines the namespace used in the document. The
URL does actually point to the website, but is the
name of the namespace.
 xsi:noNameSpaceSchemaLocation - Defines the location of the XML schema (the
grammar to be used for validation) for elements
that do not belong to any namespace (basically all
elements in an SCM)
 id - Identification code for the document code. Shall
always be “ESA_SCM”.
 version - Identifies the version of the SCM data format that
is used throughout the document.
Header in ASCII code:



6.1.3 Segment
Higher-level XML element that might contain child elements or other segments. For instance, the
segment “Header” only contains elements (COMMENT, CREATION_DATE, …) while segment
“commonData” containts other segments (camera, device, …) which, in turn, containts elements.
See Clause 7 for the description of each segment.
6.1.4 Observation Block
Smallest unit of an observation request/command. Are included in a Scheduling and Commanding
Message, with each Observation Block being represented by one XML element (with child elements).
Observation blocks are treated as impartible and are the smallest unit to which the status
“succeeded”/”not succeeded” can be assigned.
14

---------------------- Page: 16 ----------------------
SIST EN 17350:2020
EN 17350:2020 (E)
6.1.5 Command
Single observation block used to command an action from an OS. Represented by an XML element called
“command” (with child elements).
6.1.6 Schedule Request
Single observation block used to describe an observation request to a scheduler. Represented by an
XML element called “scheduleRequest” (with child elements, see 7.6).
6.2 Nested logical segments in the format
The format uses nested XML elements, with the elements holding child elements being referred to as
“logical segments”. In the following description, not the entire hierarchical structure is displayed
graphically. Instead, elements are listed in tables with:
a) Logical segments of second level elements being indicated by an empty line before and after the
segment, and the segment being introduced with its name;
b) Logical segments within second or lower level elements being indicated by being indented. In this
case, all elements listed after the segment title are part of this particular segment until either a new
segment starts (indicated by a segment name on the same level) or the indent moves back to the
higher level.
Lower-level elements that are marked as mandatory but located within a logical segment that is not
mandatory are only mandatory if the optional, higher-level logical segment is used.
6.3 Auxiliary messages
For unrestricted control of the OS and custom operation, the SCM provides an open string element, the
AUXILIARY_MESSAGE. It is primarily foreseen to providing additional data that is not foreseen to be
transmitted in an SCM. It can, however, also be used for a variety of other applications, such as to
provide custom scripts to a local scheduler or to pass OS specific commands directly through to the
control level below the local scheduler / OS control computer directly interfaced by SCMs.
AUXILIARY_MESSAGEs can generally be added at any location in an SCM and may contain any Unicode
characters. The characters &, <, >, “, and ‘ need to be escaped with the following entities: & with & ,
< with < , > with >
...