SCM - Scheduling and Commanding Message - Standard

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 effors 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.

Raumfahrt - Überwachung der Weltraumlageerfassung - Planungs- und Kommando-Nachricht

1.1   Zweck:
SCM - Scheduling and Commanding Messages - legt ein Standardformat für die Zeitplanung und Befehlserteilung von Beobachtungssystemen fest. Dieses Dokument soll Planungs- und Betriebsprozesse vereinfachen und den Aufwand für Forscher reduzieren, die mehrere verschiedene Beobachtungssysteme und/oder Simulationssoftwareprodukte verwenden.
Die SCM legt eine allgemeine Sprache für den Austausch von Informationen zu Planung, Zeitplanung und Durchführung von Beobachtungen von Himmelskörpern fest. Dadurch wird letztlich Folgendes erreicht:
a)   die Interoperabilität wird vereinfacht und das Ausgeben einheitlicher Warnungen zwischen Daten-urhebern, die Himmelsbeobachtungen durchführen, und den Stellen oder Forschern, die diese Daten nutzen, ermöglicht und
b)   die Automatisierung von Beobachtungsprozessen wird vereinfacht.
1.2   Anwendbarkeit:
Der SCM-Standard ist auf bodengestützte Aktivitäten hinsichtlich der Planung, Zeitplanung und Durch-führung von Beobachtungen von Himmelskörpern anwendbar. Er wird von Planungssoftware, Scheduling-Software und Teleskop-Befehlssoftware eingesetzt. Er ist auch bei optischen Teleskopen anwendbar.

SCM - Message de planification et de commande - Norme

1.1   Objet :
Le « SCM » (Scheduling and Commanding Message) spécifie un format normalisé pour les commandes et la planification du système d'observation. Le présent document vise à faciliter les processus de planification et d'exploitation et à alléger le travail des chercheurs qui utilisent plusieurs systèmes d'observation et/ou logiciels de simulation différents.
Le SCM définit un langage commun permettant d'échanger des informations sur la planification, l'ordonnancement et la réalisation d'observations d'objets célestes. Au final, cela permettra :
a)   de faciliter l'interopérabilité et de transmettre des notifications cohérentes entre les émetteurs de données qui fournissent les observations célestes et les entités ou les chercheurs qui les utilisent ; et
b)   de faciliter l'automatisation des processus d'observation.
1.2   Applicabilité :
Le SCM s'applique aux activités au sol liées à la planification, à l'ordonnancement et à la réalisation d'observations d'objets célestes. Il est utilisé par des logiciels de planification, d'ordonnancement et de commande de télescope. Il s'applique aux télescopes optiques.

SCM - Obrazec za časovno razporejanje in vodenje - Standardizirani format

General Information

Status
Published
Public Enquiry End Date
24-Jul-2019
Publication Date
13-Aug-2020
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
13-Aug-2020
Due Date
18-Oct-2020
Completion Date
14-Aug-2020

Buy Standard

Standard
SIST EN 17350:2020
English language
64 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

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

---------------------- 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

---------------------- 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.
---------------------- 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.
---------------------- 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
---------------------- 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

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.
---------------------- 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)

---------------------- 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
---------------------- 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.

---------------------- 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.

---------------------- 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
---------------------- 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.
---------------------- 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.
---------------------- 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 >
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.