Doc-No.: GAIA.ASU.ICD.ESM.00001 Issue : 2 o Date : 08/06/2006 Sheet : 1 of 45 Copying of this document, and giving it to others and the use or communication of the contents thereof,are forbidden without express authority. Offenders are liable to the payment of damages. All rights are reserved in the event of the grant of a patent or the registration of a utility model or design Filename GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss2).doc Title: EGSE Interface Control Document DRD No.: D-YYn Prepared by: Date : Checked by: Date : Approved by: Date : Product Assurance: Date : Project Management: Date :
Transcript
Doc-No.: GAIA.ASU.ICD.ESM.00001
Issue : 2 o
Date : 08/06/2006
�����
Sheet : 1 of 45
Copying of this document, and giving it to others and the use or communication of the contents thereof,are forbidden without express authority. Offenders are liable to the payment of damages. All rights are reserved in the event of the grant of a patent or the registration of
This interface control document establishes a common network communication protocol to be used in the standardized EGSE environment for Gaia between the Core EGSE and all the SCOE´s and Front End Equipments that are connected to it.
This ICD also defines the details of the Gaia EGSE to EGSE cables, including pin functions, connector types and cable lengths (TBD).
Chapter 1 defines acronyms, applicable documents as well as terms and acronyms used in the context of this document.
Chapter 2 shows an overview of the EGSE components and EGSE interfaces this document deals with.
Chapter 3 introduces the LAN communication protocol and general message layout. This chapter is applicable to all LAN communications within the EGSE
Chapter 4 specifies the messages applicable to all network members including their detailed layout.
1.2 References
1.2.1 Applicable Documents
AD1 Gaia Packet Utilisation Standard (G-PUS) TBD
1.2.2 Reference Documents
RD1 ESA Packet Telemetry Standard ESA-PSS-04-106
RD2 ESA Packet Telecommand Standard ESA-PSS-04-107
RD3 Ground Systems and Operations – TM & TC PUS ECSS-E-70-41, Draft 5.1, August 2000
Automated Test Procedures (ATP's) are programs executed by the Core EGSE allowing to send telecommands and C&C messages and to evaluate the returning telemetry and simulator TM. AP's are written in a dedicated test language, which is a high level programming language providing the standard constructs for branches, loops, conditions. etc
C&C messages Commands sent by the Core EGSE to any EGSE or FEE. C&C messages are transported as CCSDS packets containing command strings. The protocol and format for C&C message communication is defined in [AD-01]. Note: Spacecraft Telecommands are not C&C messages.
C&C reply Answer toward the Core EGSE upon reception of a C&C message
Closed loop testing Testing to demonstrate and verify whether a control authority on-board, e.g. the DFAC, is capable to perform its function as intended. The RTS implements a simulation of the satellite and its equipment, receives and interprets the control authority's commands, and supplies the control authority with the feedback reflecting the consequences of the command.
The CAIE-DB contains a full definition of the flight harness and the various test harnesses.
Core EGSE Check-Out and Test System. It gives the user full control on automated ground testing and test result evaluation. Its responsibilities include:
assembly of telecommands and C&C messages
disassembly of telemetry and Simulator TM
monitoring and dynamic visualisation of telemetry
storage and administration of test configurations and test results
storage and administration of a database including TM/TC definitions, monitoring limits and calibration coefficients
Execution of test automated procedures
graphical user interface
Engineering databases The project's Satellite DB, CAIE-DB, Simulation TM-DB, and the Simulation Parameter DB are called the engineering databases.
Fine Strobe This signal is auto-generated by the RTS and is used to trigger one complete simulation cycle.
GMFE Generic Modular Front Ends are units allowing connect the Onboard Computer (OBC) with the Core EGSE or the RT Simulator. The interface towards the Core EGSE is a local area network (LAN), towards the RT simulator it is a VME bus.
Instance/Model For each simulated equipment type, there will be one model in the Real time simulator (e.g. attitude sensor model) defining the algorithm and the data interface of the simulation. Each existing equipment is represented by one instance of a model (e.g. Atitude_Sensor_A). The values of the model parameters can be different for each instance. (E.G. the sensor model has a parameter "MIL-Bus address", which has different values for Sensor_A and Sensor_B).
Mission Information Base (MIB)
The database to be delivered to the ground operations responsible. Usually an extract of the SRDB providing this input in a format as specified by the MIB ICD.
OBC Simulator TM Simulator TM is sent from the simulated CMDU towards the Core EGSE.
OBC-Simulator The OBC simulator models the complete onboard computer (OBC) allowing to execute the unmodified on-board software image on an ERC32 emulator, which forms the central part of the OBC simulator.
On-Board TC These are commands sent from the OBC towards S/C units. On-Board TC can be direct I/O commands (e.g. HPC) as well words on the MIL 1553 bus. The latter can be identical to the telecommands sent from ground, but need not necessarily be in all cases. Very often one telecommand from ground will be translated in a series of On-Board TCs by the OBC OBSW.
On-Board TM Data transferred from the S/C units towards the OBC. On-Board telemetry can be transferred to OBC via direct I/O (example thermistor read outs), serial lines or via MIL 1553 bus. The latter can be identical to the telemetry sent to ground, but needs not necessarily to be in all cases. Typically the OBC OBSW will collect all On-Broad telemetry and assemble new telemetry for the ground station.
Open loop testing Testing to verify in real-time on-board communication chains, in particular to verify the data traffic of sensors, actuators and other equipment with the OBC. The RTS will be used as gateway to access and serve the interfaces of the OBC. Open loop testing may include fix pattern stimulus, frozen input to the OBC (by frozen simulator variables), but also feeding data from predefined file. Conversely the RTS will be used to receive and record output commands from the OBC.
RT Simulator The Real Time simulator models spacecraft environment condition dynamics and all equipments except the Onboard Computer (OBC or OBC). The simulation is synchronized to an external time signal, which is provided by the real or simulated Onboard Computer
Satellite Reference Database (SRDB)
The SRDB contains all telecommand and telemetry definitions. It further contains the definition of all calibration functions and all limits for the monitoring of telemetry. Beyond that it may provide containers for all kinds of engineering data (project dependent). E.g. the simulation databases listed below could be considered as a subset of the SRDB.
SCOE Set of (electronic, magnetic, optical, etc.) equipment to stimulate and/or simulate the S/C’s interfaces like sensors and actuators and/or other units (e.g. sun, batteries, ...)
Simulation Parameter Database (SP-DB)
Simulation Parameter Database (SP-DB) contains all data used to parameterize the MDVE software models. Typical examples are power consumption, heat dissipation etc. in engineering values. This database is also used to define, which parameters shall be accessible via the simulator TM.
Simulation TM Database (STM-DB)
The Simulation TM Database (ST-DB) contains definition of simulator specific telemetry, using the same table definitions as the A-SDB
Simulator Configuration Files (XML files)
The RT simulator and the OBC simulator are configured at compile-time and/or start-up via ASCII input-files w.r.t. the following information:
- TM/TC Definitions
- Calibration Function Definition
- Simulator TM Definition
- On-Board TM/TC
- Accessibility of Simulator Variables
These input files are addressed as Simulator Configuration Files. Their format follows the XML standard.
Simulator TM The simulators can be commanded from the Core EGSE via C&C commands. Such commands are acknowledged back to C&C via an acknowledge. If parameter value queries were included in the C&C command a C&C reply furthermore is generated containing the queried value.
Besides that the simulator can send cyclically or single shot telemetry about the internal status of numerics or models to the Core EGSE. This simulator TM is not to be mixed with telemetry from the S/C.
Both S/C TM and the Simulator TM follow the same packet format standards, thus all TM packet contents can be evaluated by EGSE automated procedures.
For simulator TM the parameter sets to-be-transmitted can be defined in so-called SID definitions. Multiple SID definitions can exist in parallel and can be activated on demand.
Synoptic Pictures Graphical visualisation of received telemetry in Core EGSE. Synoptic pictures (also known as mimic displays) are updated dynamically during test execution.
System Simulator Synonym to Real Time Simulator in some drawings and documents
Telecommand Commands, which be send from the ground segment towards the spacecraft.
Telemetry Data, which can be sent from the spacecraft to the ground segment
Test Sequence See automated test procedure
Time The following two time scales are important in the simulation context:
a) Simulation elapsed time tsim: This time scale is a linear time counter, starting with zero each time a simulation is started. This time scale is also known as simulation elapsed time and relative mission time
Note that this time counter is not synchronized with any on-board computer power-on event.
b) Simulated mission time: This time scale defines the time of the simulated mission scenario. A time instant from this time scale is also known as epoch or modified julian date.
Another time scale called tsession exists, but is not used in the context of simulation. It starts at zero each time the RTS computer has finished booting and ends when the RTS computer is powered off.
All units forming the GAIA EGSE interface with each other via the EGSE Local Area Network (LAN).
2.1 Generic EGSE Configuration
The diagram in Figure 2.1-1 shows all EGSE elements and front end units and how they are interconnected. The diagram shows a generic EGSE configuration, which may be amended according to the needs of the actual AIT phase.
For all EGSE Local Area Networks (LAN), the implementation is based upon the “Open Systems Interconnection“ (OSI) Seven Layer Reference Model briefly presented below. The OSI Reference Model partitions networking functions into seven layers as depicted in Table 3.1-1.
Layer 7 APPLICATION
Layer 6 PRESENTATION
Layer 5 SESSION
Layer 4 TRANSPORT
Layer 3 NETWORK
Layer 2 DATA LINK
Layer 1 PHYSICAL
Table 3.1-1 OSI Reference Model
Layer 1: The physical layer is responsible for the transmission of raw data over a communication medium.
Layer 2: The data link layer provides the exchange of data between network layer entities. It detects and corrects any errors that may occur in the physical layer transmission.
Layer 3: The network layer manages the operation of the network. In particular, it is responsible for the routing and management of data exchange between transport layer entities within the network.
Layer 4: The transport layer provides transparent data transfer services between session layer entities by relieving them from concerns of how reliable and cost-effective transfer of data is achieved.
Layer 5: The session layer provides the services needed by presentation layer entities that enable them to organize and synchronize their dialogue and manage their data exchange.
Layer 6: The presentation layer manages the representation of information that application layer entities either communicate or reference in their communication.
Layer 7: The application layer serves as the window between corresponding application processes that are exchanging information.
A basic principle of the OSI Reference Model is that each layer provides services needed by the next higher layer in a way that frees the upper layer from concern about how these services are provided. This approach simplifies the design of each particular layer.
The physical layer is defined to be Gigabit Ethernet over copper.
Ethernet adapters supporting 1000BASE-T specification have to be used for all computers connected to the EGSE LAN.
To achieve Network speeds approaching 1Gb/s, any Gigabit Ethernet Network Interface Cards must be specified for the PCI-Express BUS.
The 1000BASE-T specification describes a process called Auto-Negotiation, which allows devices at each end of a network link to automatically exchange information about their capabilities and perform the configuration necessary to operate together at their maximum common level.
LAN connections are made using a Gigabit Switch.
3.1.3 Data Link Layer
The data link layer is defined to be GigaByte Ethernet according to IEEE 802.3z.
The network layer is defined to be implemented by the Internet Protocol (IP) and the transport layer is defined to be implemented by the Transmission Control Protocol (TCP) both conforming to TCP/IP protocol.
A unique IP Address must be defined and associated to every host interface, or node, on a TCP/IP network. This address is used to identify a node on a network; it also specifies routing information in an inter-network. The IP address identifies a node as a 32-bit address that is unique across a TCP/IP network. An address is usually represented in dotted decimal notation, which depicts each byte of an IP address as its decimal value and separates each byte with a period. An IP address looks like:
w.x.y.z (e.g. 130.201.8.99)
For all EGSE configuration networks Class-B type IP addresses are recommended assigning a value from 128 through 191 to the first byte “w“ of the IP address. Moreover it is recommended to split the Class-B network into 256 subnets each of which can have 254 nodes (values 0 and 255 should not be assigned to an Host Id; they are used as broadcast addresses, which are typically recognized by all nodes).
This leads to the following recommended IP address definition:
IP address fields w x y z
Class-B address network address subnet
address host id
Network Mask 255 255 0 0
Subnet Mask 255 255 255 0
Broadcast Mask network address subnet
address 255
Table 3.1-2 IP Address definition
3.1.5 Session and Presentation Layer
Not applicable to end-to-end inter-process communication.
The transport layer is the lowest layer in the Reference Model that provides the basic services of reliable, end-to-end data transfer needed by applications.
Inter-process communication between any EGSE element / subsystem takes place by means of Host-to-Host / end-to-end communication between two processes; each process executed on a different node. Any process that offers a service over the network to another process is known as a server. Servers accept requests from other processes, which are known as clients. A client sends a request and waits for the result from the server.
Inter-process communication is based on connection-oriented Transport Level Interface stream socket mechanism. A stream socket supports bi-directional, reliable, sequenced, and unduplicated flow of data without record boundaries. The receiving processes are guaranteed to receive the messages, in order, without a duplicated message.
Connection-mode stream socket is circuit-oriented and enables data to be transmitted over an established connection in a reliable, sequences manner. It also provides an identification mechanism that avoids the overhead of address resolution and transmission during the data transfer phase. This service supports long-lived data-stream-oriented interactions as required for all EGSE inter-process communication.
The connection-mode transport service is characterized by four phases: local management, connection establishment, data transfer, and connection release.
3.2 Application Protocol Specification
A server or client process has to be implemented on each network node while participating in inter-process communications. A pair of server / client processes shall be implemented for each host-to-host communication link between any two EGSE network nodes. Two logical links (i.e. two stream sockets) are recommended for each host-to-host link routing:
one bi-directional link is dedicated to the client process sending messages (i.e. commands) to the server process and receiving its corresponding acknowledgement from the server, if any.
Client process server process
one uni-directional link is dedicated to the server process sending messages (i.e. S/C TM, server TM, status messages, etc.) to the client process and receiving its corresponding acknowledgement from the client, if any.
client process server process
Thus, each network partner is able to send its unsolicited messages on its „send-link“ concurrently awaiting unsolicited input messages on its „receive-link“
Stream socket based inter-process communication is to be implemented for server and client processes as outlined below. Stream socket services are provided by the TCP/IP protocol implementation and are supported by operating system calls on e.g. UNIX-based systems. For details on stream socket services refer to dedicated TCP/IP / operating system documentation belonging to dedicated machines.
As a server will act on all EGSE elements providing network services, waiting for network operations by the connecting host, thus a server is always passive, being controlled by the client. Therefore the host (e.g. the Core EGSE) will be the client, as it is the active partner.
Once sockets are established they will only be released upon specific command sent by the client or shutdown of either side. Availability of a socket link does NOT imply the server being remote controlled by the client - see § 3.2.4.
An acknowledge / not-acknowledge (ACK/NAK) handshake is used for command and control messages issued by the client. Every command and control message is to be acknowledged by the server, sending an acknowledgement control message (keyword = ACK; see next section) to the client, with arguments if appropriate, to indicate that the requested action has been taken. A negative acknowledgement (keyword = NAK) is issued in the event of an error or any condition preventing the requested action from being taken. The acknowledgement is to be given immediately after syntax check and recipient mode verification (i.e. is the command requested actually allowed). Command execution is to be performed after sending the acknowledgement. This allows a unique command /acknowledgement time-out setting by the client to be applied to all C&C messages irrespective of their execution duration at destination. Command execution verification is expected to be done by means of equipment status reporting either via dedicated report request (ref. § 3.3.3.1) or via cyclical equipment telemetry data transfer (ref. §3.3.2).
The first argument of each ACK or NAK message is defined to be the command keyword the acknowledgement belongs to. No other information is mandatory. Additional arguments may be repeated by extraction from the command itself. Also an acknowledgement status may be added. However, the ACK/NAK message arguments are for information, only, forming part of the message logging not processed by the ACK/NAK receiver.
Arguments of the ACK/NAK message:
1st argument: command keyword of the message the acknowledgement belongs to
2nd argument: 1st argument of command message, if available
3rd argument: optional; only used in case of NAK: -> NAK reason return status
The ACK/NAK message arguments are for information, only, subject to message logging and display by the client.
To control the routing of telecommand source packets through the TM/TC front end equipment for up-link to the on-board telecommand receiver via X-band or TC bypass link, a TC handshake / acknowledgement mechanism is required. This protocol has to take into account the fact that the TC decoding by the TM/TC front-end equipment for generating the TC Source Packet Echo message to the command issuer is independent from the TC encoding w.r.t. timing and command to command echo correlation. The basic TM/TC FEE architecture and the resulting data-flow is shown in the Figure 3.2-1 below.
Figure 3.2-1 TC Handshake Mechanism
The Core EGSE, after having issued a TC Source Packet to the TM/TC front end equipment, will instantly receive a TC acknowledgement message from the front end indicating that the TC has been successfully (ACK) or not (NAK) queued into the front end TC processing buffer. The Core EGSE has to synchronize on this TC acknowledgement to release the next telecommand for sending to the TM/TC front end. The TC Source Packet Echo obtained by the TM/TC front-end equipment after decoding, is sent to the Core EGSE completely asynchronously to the TC send and TC acknowledgement. No correlation to the TC sending by the Core EGSE is required. The echo message is to be used by the Core EGSE for logging purposes only, indicating that the TC has left the TM/TC front end for up-link. In addition the TC echo message, providing the complete binary TC Source Packet, may be used by the Core EGSE for command issuing notification of connected supplementary test equipment such as instrument EGSE.
In case of TC retransmission by the TC FEE to the on-board system, multiple TC Echoes are generated by the TC Decoder of the FEE. Consequently, the command sequence indicated by the sequence of TC Echoes may not be identical to the on-ground commanded and on-board executed sequence.
Because at TC Source Packet level there is no correlation possible to the TC up-link at CLTU level, neither the TC FEE nor the Core EGSE are able to indicate whether or not a TC Echo corresponds to a successful up-link or a retransmission. Therefore the Core EGSE is requested to archive all TC Echoes received and - if distribution is enabled - distribute all TC Echoes to instrument EGSE.
The message data structure dedicated to the TC acknowledgement is outlined below.
The TC Source Packet Echo data structure that is sent by the TM/TC front-end equipment to the Core EGSE is identical to the TC Source Packet that was issued by the Core EGSE (see § 3.3.1.2).
Based on a two socket communication between the Core EGSE and the TM/TC front end equipment the TC acknowledgement message is returned by the front end on the same link (i.e. FEE receive link) as the TC Source Packet was received as it is an immediate handshake. Whereas the TC echo is an unsolicited message sent to the Core EGSE on the FEE send link. Receipt of a TC echo message is NOT acknowledged by the Core EGSE.
3.2.3.3 Telemetry Source Packet Acknowledgment
For telemetry source packet distribution acknowledgement is neither foreseen nor needed. Data transmission on the network is assured by the TCP/IP protocol and processing of received telemetry packets is up to the receiving node; in worst case the packets received will be discarded. The only constraint to every telemetry packet sink is that reading from the network port (socket) is never stopped or blocked as long as the communication link is established. If packets cannot be processed for any reason this must be notified to the operator and/or the telemetry source.
3.2.4 Remote Communication Control
At any time after establishing the network logical link (socket) connections, the client may start remote communication taking over command authority from the server local command instance by sending the C&C message "TRANSFER remote". If the server is ready to start communication and to hand over command authority to the server the acknowledge message returned will repeat the remote request (i.e. C&C: ACK TRANSFER remote) and the server will change its internal operating mode from LOCAL to REMOTE, otherwise a not-acknowledge message is returned by the server indicating that the server will remain in LOCAL operation mode (i.e. C&C: NAK TRANSFER remote). The server decision for transferring communication mode to REMOTE has to be derived from the internal application software status (i.e. ready or not-ready).
Once the server is in REMOTE communication mode messages can be exchanged in both directions. The client can command the server by sending messages on the client send link / server receive link. The server may send unsolicited (status) messages to the client on the server send link / client receive link.
Note: The server may send unsolicited (status) messages to the client on the server send link / client receive link even in LOCAL mode (i.e. prior to any TRANSFER remote or after TRANSFER local transition).
Mode transition from REMOTE back to LOCAL, performed by means of the C&C message "TRANSFER local", may be requested either by the server or by the client. Subsequent transition from local to remote has to be re-initiated by a "TRANSFER remote" request from the client.
Remote / local mode only indicates the status of the server (i.e. front-end equipment) with respect to the communication mode to the client (i.e. the Core EGSE). The server internal processing state (called „on-line“ / „off-line“) with respect to the data processing and / or connection to the peripherals (i.e. instrument or satellite subsystem) is not affected by a TRANSFER C&C message. However, the internal processing state (i.e. on-line / off-line) may influence the capability of transferring command authority to any other instance. As a consequence on an EGSE element, there may exist four mode states derived from the combination of internal processing state ONLINE / OFFLINE and command authority site LOCAL / REMOTE.
For all EGSE network inter-process communication consisting of command and control message distribution and TM/TC packet routing it is defined to use messages in the form of CCSDS source packets. This enables all EGSE nodes to look for a single type of incoming data structure and direct the processing of the packet on the basis of the socket name on which the message was received and the APID value. TM source packets and TC source packets are routed on the EGSE networks as native onboard source packets (i.e. without any additional envelope). There is no need to identify message source or destination with respect to EGSE network nodes because the inter-process communication is performed via dedicated logical point-to-point links as discussed above.
Source packets are distinguished through specific field assignments to the packet primary header as depicted in Table 3.3-1 below:
Primary Header Packet Identification Fields: Version # Type Data Field Header
Telemetry source packets down-linked by the spacecraft on various physical links are to be distributed and processed by the EGSE. Source and destination for telemetry packet distribution may vary on the different EGSE configurations.
Spacecraft specific telemetry source packets according to “RD1 ESA Packet Telemetry Standard” as well as telecommand source packets according to “RD2 ESA Packet Telecommand Standard” are detailed by the project specific Packet Structure Specification “AD1 Gaia Packet Utilisation Standard (G-PUS)”, tailoring the ESA PSS/ECSS Packet Utilization Standard “RD3 Ground Systems and Operations – TM & TC PUS” to the project needs. The general source packet structure is outlined in Table 3.3-2 below.
The TC acknowledgement and verification report message is a Telemetry Source Packet conforming to “RD1 ESA Packet Telemetry Standard” identifying the TM/TC front end equipment (TM/TC FEE) as the service providing application process. The purpose of this TM Source Packet is twofold; firstly, it acts as the TC handshake message releasing the next pending TC packet in the Core EGSE and secondly, it provides the TC processing status from the TC front end. For this purpose the application data field is defined in accordance with the "TC Verification Report" service given in “RD3 Ground Systems and Operations – TM & TC PUS” (see the packet structure in Table 3.3-4).
This message has to be generated independently from the "ACK flags" within the TC Packet DFH as these ACK flags only request on-board TC acknowledgement to be applied to a telecommand.
As shown in Table 3.3-7 the application data field provides the identification of the TC Source Packet acknowledged by repeating the first four bytes of the command packet Primary Header. In addition the TM/TC telecommand buffer status is reported and in case of not acknowledge (NAK service (1,130)) an error code gives the reason for the failure.
TC Packet Id
TC Sequence Control
Code only if NAK (1,130)
Source ID Error Code
2 byte 2 byte 1 byte 2 byte
Unsigned Int Unsigned Int Enumerated Enumerated
Table 3.3-7 TM Application Data Field for "TC ACK/NACK & TC Verification Report"
In the event of a NAK service (1,130) the additional error code reports the reason of TM/TC front end ‘not acknowledge’ (NAK). The following Error codes have been identified:
Error code : 1 = TC processing OFF 2 = Invalid Mode 3 = Inconsistent Packet 4 = TC Buffer Full 5 = forbidden TC etc. … additional ID's may be identified
The CCSDS Source Packet specification as defined in “RD1 ESA Packet Telemetry Standard” is to be applied to the EGSE internal HK TM Source Packet data structure definition. The EGSE internal HK TM Source Packet can be created by any EGSE element which is required to report its operational status and/or configuration and return any on-board monitored parameter data, similar to spacecraft telemetry data packets. Once enabled, such packets can be sent to the Core EGSE autonomously and periodically and can be treated by the Core EGSE as nominal telemetry packets for archiving, monitoring and display.
The source packet format shown in Table 3.3-8 consists of the following fields: 1. Primary Header 6 byte 2. Data Field Header + SID 11 byte 3. EGSE HK Data variable - 2030 byte maximum
SID
7 4 11
Version Number
EGSE HK Data
+ SID
Data Field Header
Packet Data Field (variable) Source Packet Primary Header (48 bits)
Packet Id Packet
Sequence Control
Packet Length
Data Field
Header Flag
Application Process Id
Process Id
Packet Category
Source Sequence
Count
Type
3 1 1 2 14 16 64 N * 8
Segmen tation Flags
8
DFH
Table 3.3-8 EGSE internal HK TM Source Packet Structure
Packet Length 2 0 16 number of bytes in the Packet data field - 1
Table 3.3-9 TM Primary Header Field Definition
As for spacecraft TM packets (see § 3.3.1.1) acknowledgement by the receiving Core EGSE is not foreseen for EGSE internal HK TM packets.
No Packet Error Control (PEC) word is provided, thus the field "Checksum Type" in the DFH is zero.
The Source Packet Data Field Header (DFH) as outlined in Table 3.3-10 below is defined to conform to the needs of the Packet Utilization Standard as defined in “RD3 Ground Systems and Operations – TM & TC PUS”, § 6.5.2 and in order to be compatible to the project specific needs tailored according to “AD1 Gaia Packet Utilisation Standard (G-PUS)”. As the only PUS service used is the "Housekeeping Reporting" defined by service type 3, sub-type 25, the DHF has a fixed layout.
According to PUS service (3,25), a Structure Identifier (SID) is prefixed to the HK data in the Packet Data Field, unambiguously identifying the contents of the packet in terms of parameters reported and their location within the packet data field. The SID is an 8 bit field and the assigned SID values have to be in the range of {1..255}; the value zero is not used.
PUS Vers
Checksum Type
Filler Service Type
Service Sub-Type
Time SID (Part of HK Data Field)
0
0 zero 3 25 not used ( = 0 ) TBD by EGSE
supplier
1 bit
3 bit
4 bit 1 byte 1 byte 5 bytes 1 byte
Table 3.3-10 EGSE HK TM Source Packet - Data Field Header
The Packet Data Field holds EGSE measurements as defined by the dedicated Structure Identifier (SID). A measurement is required to start at byte boundaries having a maximum size of 32 bits.
To enable the Core EGSE to specify, within the database, the measurements engineering representation and physical unit and to perform house-keeping data monitoring on EGSE parameters, a packet contents description dedicated to each defined SID has to provide at least the information as follows (see also Table 3.3-11 below):
Location of measurement inside the data field as byte offset value (i.e. first measurement starts at location 0) Length of measurement in number of bits.
Range: 32 bits max. for analog and digital parameters; 2040 bits max. (255 chars) for character strings Type of measurement (e.g. counter, signed/unsigned integer, real, digital status, etc.) Calibration law for real measurements or status text conversion for digital status Limits (high/low) for real measurements The table below, in its header lines, defines the information required, whereas the table lines show examples especially w.r.t. columns "parameter position", and explain the required information w.r.t. columns "parameter attributes".
Packet Data Field
DFH SID Para-1 Para-2 Para-3 .... Para-n
byte offset 0
SID = n
Parameter Position Parameter Attributes Para-meter Name
(Mnemo)
Byt
e of
fset
Sta
rt b
it (0
..7)
# of
bits
(1
..32)
or
(1…
2040
) Type Calibration Value Range
Limits Descrip-tion
<Para-1> 0 0 8 UINT Calibration point pairs
<Para-2> 1 0 16 INT Calibration point pairs
<Para-3> 3 0 32 REAL Real number according to
Annex 1
range of raw values and/or
engineering values
engineering values low and high limits the
parameter shall be checked against
un-used 7 0 6
<Para-4> 7 6 2 STATUS status-text 0 := OFF 1 := ON
<Para-5> 8 0 8 COUNT or REGISTER
no calibration range of raw values
raw value limits to check
<Para-6> 9 0 - CHAR(x) ASCII Text
textual short
description of
parameter purpose
30 chars max
Table 3.3-11 Packet Data Field - Examples
For character string fields defined in the HK TM Source Packet an absolute fixed length has to be allocated in the packet data field as shown in example <Para-6> of Table 3.3-11 above. The ASCII text inserted at run-time may be of variable length, with a maximum number of characters as defined by the allocated field length. A text string shorter than the reserved field length must be terminated by a binary zero byte. The remaining character field, up to the maximum length defined, shall be padded out with binary zero bytes in order to overwrite the contents from the preceding packet.
EGSE elements may issue unsolicited telemetry event packets, e.g. to communicate equipment problems / errors / warnings to the Core EGSE. If used, event TM Source Packets issued by the EGSE’s have to have the same data structure as for EGSE internal HK TM Packets defined in Table 3.3-8 above:
Primary Header: same APID as for EGSE internal HK TM packets Data Field Header: see Table 3.3-10 using "Service Type" = 5; "Service Sub-Type" = 1 Structure ID: called Report ID (RID), length = 16 bits (2 byte)
The RID is a 16 bit field and the assigned RID values have to be in the range of {1..65535}; the value zero is not used.
Event Data: fixed measurement allocation defined by dedicated RID according to the rules given above for measurement/parameter definition within the Packet Data Field.
Generation of such packets is considered driven by events and therefore not controlled by the routine Core EGSE TM/TC interrogation.
3.3.4 Command and Control Messages
Command and Control Messages (C&C Messages) are the EGSE equivalent to telecommands (TC) sent to the on-board system.
The CCSDS Source Packet specification, as fixed in “RD2 ESA Packet Telecommand Standard”, is to be applied to the EGSE Command and Control Message data structure definition. The Source packet format shown in Table 3.3-12 consists of the following fields:
1. Primary Header 6 byte
2. Data Field variable - 1024 byte (i.e. characters) maximum
7 4 11
Version Number
Command & Control Message
Packet Data Field (variable) Source Packet Primary Header (48 bits)
Packet Id Packet
Sequence Control
Packet Length Data
Field Header
Flag
Application Process Id
Process Id
Packet Category
Source Sequence
Count
Type
3 1 1 2 14 16 N * 8
Segmen tation Flags
Table 3.3-12 Command and Control Message Structure
Packet Length 2 0 16 number of bytes in application data field - 1
Table 3.3-13 C&C Primary Header Field Definition
The C&C ACK/NAK message has the same source packet primary header as the originating C&C message, with the exception of a different APID.
A unique application process identifier (APID) is allocated to all command and control (C&C) messages and a separate APID is used for the corresponding acknowledgement message (C&C ACK/NACK). The source of every control message is known by the socket through which it is received. The APID’s for EGSE command and control messages must be configurable in order to fit into the on-board equipment APID range defined in (“AD1 Gaia Packet Utilisation Standard (G-PUS)”. The Process Identifier and Packet Category shall be initially set to the values defined in Appendix 2, for each EGSE element
One Source Sequence Counter is maintained by each command issuing instance (i.e. on each point-to-point connection). The command receiving instance has to return this Source Sequence Counter within the command acknowledgement source packet allowing easy correlation between the C&C ACK/NAK message received and the C&C message issued.
No Data Field Header (DFH) is provided with the Command and Control Message data structure.
No Packet Error Control (PEC) field is used in the Command and Control Message data structure.
The C&C message has to be logged and archived by the generating node as well as by the receiving node and stamped with the creation date and time information and receipt date and time information, respectively. Thus the C&C message itself is not intended to carry time and date information for this purpose.
Command and control (C&C) messages are in the form of ASCII text, consisting of a statement followed by a semicolon, and optionally followed by free commentary text for up to a total source packet data field of 1024 characters. A statement is one of several keywords separated by a space, and followed by one or more optional arguments. One command and control message can hold only one command (i.e. one command per line).
The syntax of a command and control message expressed in BNF notation is as follows: c&c_message ::= <command> [<space><argument_list>] [;]
Parameters are names / mnemonics to identify internal processing arguments (e.g. telemetry items as specified in a database) that have significance to a particular command keyword. Values may be numeric, strings or Boolean identifiers.
Numeric values: decimal or hexadecimal integer value or real value in ASCII representation (e.g. 123 / -987680 / 0XA05F / 1.25 / 4.8e-3 )
Character string: string of characters delimited by double-quotes (e.g. “Select Channel 2“ )
Boolean identifiers: unquoted string (e.g. ON / OFF or TRUE / FALSE )
The different argument types - cmd options, parameters, values - may be mutual exclusive within one control message string or all types may be allowed, subject to dedicated interface requirement specification.
In the first instance the maximum number of arguments is not limited while not exceeding the maximum string length of the data field. However, implementation may require to limit maximum number of arguments allowed, subject to dedicated interface requirement specification.
; (semicolon) (optional) command termination - only used for compatibility to former implementations.
In addition the C&C ASCII string may be terminated by binary zero byte allowing C&C type TC Source Packets longer than the real C&C character string, padded out with zeros up to the length indicated by the packet primary header length field.
Keywords belonging to commands and arguments shall NOT be case-sensitive, thus it is allowed to use uppercase as well as lower case letters.
Identical actions defined upon various interfaces have to have assigned identical keywords. A list of common keywords is proposed to all C&C message network communications. The keywords listed - if applicable to a dedicated EGSE element - have to be used on all interfaces according to their definition given below. Or - alternatively - if a function listed below is required by an EGSE element, it has to be implemented using the command keyword specified. However, it is NOT mandatory to implement all listed keywords, if the function is not required in the EGSE element.
Keyword Description / Function
ACK command and control message acknowledge
APPLY request the FEE to apply a stimuli signal or pulse to a dedicated on-board unit signal line
CONTINUE continue/resume previously halted process / automated test sequence
ERROR error message displayed to the operator for information or requesting special action (to be displayed with different attributes than the nominal MESSAGE type)
GETTM specify APID and sample rate for EGSE Internal HK TM packets generated by the EGSE Front End to be routed to the command issuer
HALT halt/suspend previously started process / automated test sequence
MESSAGE message string to be displayed to the operator
NAK command and control message not-acknowledge
REPLY provides parameter value / status report requested by preceding REPORT command or other commands resulting in a response from the front end
REPORT request sending of parameter value / status report to the command issuer
RESET reset the commanded equipment to its initial status. This implies a state transition equivalent to TRANSFER local and a logical communication link (i.e. stream socket) disconnect
RESTART restart the commanded equipment, all or dedicated process
SET set parameter to value
START start a process / automated test sequence
STOP stop previously started process / automated test sequence
TEST perform EGSE self-test
TRANSFER remote partner mode transition control - arguments: remote, local
All IP addresses and socket / port numbers shall be configurable by the user. A step-by-step procedure describing IP address and port number settings shall be provided in the EGSE element user manual.
3.4.2 EGSE Synchronization
Time synchronization of EGSE computers shall be achieved via the EGSE LAN by means of UNIX / LINUX standard Network Time Protocol (NTP) with the Core EGSE acting as the timeserver.
3.4.3 LAN Load
SCOE Feedback data rates (EGSE TM/TC packets, C&C Messages, …) over the LAN shall not be higher than 20 kbps for each SCOE.
3.4.4 Network Access
All SCOEs having a controller shall support NFS (Network File System) and FTP to allow direct access from the CORE EGSE into the hard disks of the controller itself for files transfer purposes.
This section specifies the C&C message source packet data field contents belonging to common C&C messages according to keyword list given in section 3.3.4.2 above. The C&C source packet structure has to be implemented as defined in section 3.3.4 above and the command syntax according to section 3.3.4.1.
The messages outlined below belong to the Core EGSE as well as to any SCOE and Instrument EGSE. Both, SCOE and instrument EGSE are referred to as Front-End Equipment (FEE) as they are both considered front ends from the Core EGSE point of view.
Note: "Unsolicited C&C message issued by the FEE" in the sections below means: the FEE issues the C&C message on the uni-directional link (see Section 3.2) and there is no acknowledgement by the receiving side.
4.1 Remote Mode Transition Control
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE TRANSFER REMOTE
LOCAL
FEE ACK
NAK
TRANSFER argument-1 as provided by command
[<NAK return status>]
"TRANSFER LOCAL" may also be issued by the FEE.
Unsolicited C&C message issued by the FEE: issued by Keyword Argument-1 Argument-2 Argument-3
FEE TRANSFER LOCAL
4.2 Front End Equipment RESET
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE RESET
FEE ACK
NAK
RESET
[<NAK return status>]
No argument to the FEE can be provided with this command as the Core EGSE acts on the RESET keyword by closing the TCP logical communication links. In case selective FEE unit reset is needed, FEE specific keyword has to be introduced (e.g. <FEE>_RESET <unit>).
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE RESTART [<unit>]
FEE ACK
NAK
RESTART [<unit>]
[<NAK return status>]
4.4 Automated Sequence Control
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE
START
<test sequence name>
or
<test session name>
optional arg.2 through arg.n
Note: The number (n-1) of args supplied with the START command is recommended not to exceed 10.
The maximum length of each argument is proposed to be limited to 32 characters .
Core EGSE
HALT
CONTINUE
STOP
<test sequence name>
or
<test session name>
- none - - none -
FEE ACK
NAK
START
HALT
CONTINUE
STOP
<test sequence name>
or
<test session name>
<NAK return status>
The NAK status returned is an ASCII string as follows: „not found“ - sequence specified in arg.1 does not exist „wrong argument - <arg>“ - only on START „already active“ - only on START or CONTINUE „not running“ - only on HALT or STOP „already held“ - only on HALT
Responding the preceding report request an argument list separated by comma can be provided according to BNF notation (see also § 3.3.4.1for detailed BNF):
Note: the number of arguments supplied with the command is recommended not to exceed 10
<parameter_assig> ::= <parameter_id> = <value>
4.8 C&C Message of Type ERROR and Message
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE MESSAGE text string to be displayed to the operator - 80 char. maximum
FEE ACK
NAK
MESSAGE
[<NAK return status>]
<message text> = text string to be displayed to the operator - 80 characters maximum;
Unsolicited C&C message issued by the FEE: issued by Keyword Argument-1 Argument-2 Argument-3
Self-test results can be requested for report to the Core EGSE by REPORT TEST command:
issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE REPORT TEST <unit>
FEE ACK
NAK
REPORT TEST <unit> or
[<NAK return status>]
issued by Keyword Argument-1 Argument-2 Argument-3
FEE REPLY TEST <unit> <test result>
Core EGSE ACK
NAK
REPLY TEST <unit> or
[<NAK return status>]
Unsolicited C&C message issued by the FEE: issued by Keyword Argument-1 Argument-2 Argument-3
FEE REPLY TEST <unit> <test result> <unit to test> = TBD by FEE | ALL Note: ALL is default and may be omitted In case of command from Core EGSE is “REPORT TEST ALL“, the REPLY from the FEE only contains one global test result indication for each unit inside the front end equipment , e.g. "unit-1=OK,unit-2=OK,unit-3=NOK" ...etc. ( TBC. - if applicable - ) Detailed unit test reports are provided by means of unit specific REPORT requests. The contents reported within the REPLY message starting from argument-3 is to be defined by the specific equipment ICD to be provided by the FEE supplier.
4.10 EGSE Internal HK TM Source Packet Distribution Control
EGSE internal HK TM Source Packet acquisition (see § 3.3.3) from Front End Equipment is controlled through the Core EGSE by means of C&C command GETTM. issued by Keyword Argument-1 Argument-2 Argument-3
Core EGSE GETTM ON <SID> [<sample-rate>]
Core EGSE GETTM OFF <SID>
FEE ACK
NAK
GETTM ON
OFF
<SID> or [<NAK return status>]
<SID> = Packet Structure Identifier (see § 3.3.3 above) - value range TBD by FEE <sample-rate> = seconds in time - optional parameter for ON command
if omitted the packet is distributed cyclically on a default time base (e.g. 10 sec).
If not specified otherwise within this document, the following bit numbering and byte order conventions shall apply:
Bit numbering convention according to ESA standards:
− The most significant bit (MSB) within a bit array is identified as Bit 0. − The least significant bit (LSB) within a bit array of length = n bits is identified as Bit n-1. − A byte defines an 8-bit data structure with the MSB = bit 0 and the LSB = bit 7. − A word defines a 16-bit data structure with the MSB = bit 0 and the LSB = bit 15. − If an n-bit field is to be interpreted as "Unsigned Integer" value, bit-0 is the MSB and bit n-1 is the LSB. − If an n-bit field is to be interpreted as "Signed Integer" value, bit-0 indicates the sign with bit-0 = 0
corresponding to a positive number and bit-0 = 1 corresponding to a negative number. The value of a negative number is represented by the two’s complement (e.g. minus one (-1) = 1 111 1111bin for an eight bit wide signed number field).
Byte order convention:
Within one word the most significant byte (i.e. bit 0 through bit 7) is stored on the lower memory byte address and is transmitted first, whereas the least significant byte of a word (i.e. bit 8 through bit 15) is stored on the higher memory byte address and is transmitted last. This definition is known as the „Big Endian“ implementation.
5.2 Representation of Floating Point Numbers
Floating point numbers provided within EGSE internal House-Keeping telemetry source packet for monitoring and processing within the Core EGSE system are expected to conform to 32-bit binary single precision floating point representation according to IEEE 754 briefly described below:
1 8 23 bits
Sign Exponent Mantissa
The sign is the sign of the number. The sign of the exponent is built into the representation of the exponent value. The mantissa is the detail of the number, while the exponent represents the magnitude. The IEEE standard specifies that the sign of the number is 1 for negative and 0 for positive. The sign of the exponent is integrated into the value of the exponent. The representation of the exponent involves "excess n" notation. That means that the value stored as the exponent is actually n + the true value of the exponent. This makes it easier to sort floating point numbers by forcing very negative exponents to have low values. In single precision floating point numbers, n is 127.
The mantissa stores the significant figures of the number. Since every normalized binary floating point number starts with a 1 (except for true zero), the 1 is redundant and need not appear. The arithmetic processing logic assumes a 1 in that position. Some very small numbers also do without the understood 1 before the mantissa bits.
An exponent of all 1 bits has special significance and is treated as the mathematical entity infinity.
