Generic Emulator Test System GETS

1
Generic Emulator Test System (GETS)
D. Cosi Dataspazio S.p.A.
M.Irvine, J.Ochs VEGA Informations-Technologien
GmbH
2
Project Organisation

• The GETS study is performed under contract to
  ESOC.
• ESOC Technical Officer is David Verrier.
• VEGA is the prime contractor.
• Dataspazio responsible for development of GETS
  off-line tools.
• VEGA responsible for test tool development.

3
Introduction

• All recent operational simulators, developed for
  ESOC, have included one or more processor
  emulators running the actual flight software.
• ESOC have frequently had problems with the
  availability and quality of the flight software
  to be used within an emulator.

4
Purpose

• The aim of the GETS study is to demonstrate that
  it is possible to have configurable flight
  software that implements the key parts of the
  Packet Utilisation Standard and acts as source
  and sink of telemetry and telecommand packets.
• This software can be reused across missions to
  help the simulator development and to postpone
  the need of the real flight software.

5
Components

• The Generic Emulator Test System consists of
  four components
• Configuration Editor
• Development System
• Generic Emulator Software
• Validation System

6
Configuration Editor

• load and export TM, TC and BUS configurations.
• provide a set of GUIs

7
Development System

• load configuration
• generate part of software
• build the software binary image (ERC32)
• export MIB files
• provide GUI

8
Generic Emulator Software (GES)

• Import the configuration
• implement the key parts of the Packet
  Utilisation Standard
• exchange data with external devices via APIs

9
Validation System

• Windows/SIMSAT-2003 simulator
• validate the flight software
• include an ERC32 emulator (ESOC ERC32 or TSIM)
• provide an external spacecraft subsystem model
  (TC sink and TM source)
• support testing with MCS connection
• support testing stand-alone - TCs injected and
  TM output stream decoding

10
GETS Overview
11
TM Parameter Editor

• The TM Parameter Editor allows to define and
  update telemetry parameters. Each parameter is
  characterised by
• Name, it uniquely identifies the parameter.
• Size, size (number of bits) of the parameter.
• PTC, Parameter Type Code. It controls the
  encoding format of the parameter. It is used by
  SCOS-2000 in order to decode the value of
  parameters extracted from TM packets
• PFC, Parameter Format Code. Along with the
  Parameter Type Code this field controls the
  length of the parameter. It is used by SCOS-2000
  for parameters extracted from TM packets

12
TM Packet Editor

• TM Packet Editor allows to
• define a new TM packet to be added to the current
  TM configuration
• update TM packet header parameters and
  characteristics (time period and VCID)
• remove a TM packet from the current TM
  configuration
• Add TM parameters to a TM packet
• remove TM parameters from a TM packet.

13
TM Packet Editor

• The TM Packets table displays the list of packets
  currently defined.
• Name, TM packet name. It uniquely identifies the
  telemetry packet.
• APID, packet APID field of the packet header.
• Length, packet length field. It specifies the
  number of octets contained within the packet data
  field.
• DFH, Data Field Header Flag. It indicates the
  presence or absence of a data field header.
• Type, service type (packet data field header).
  It indicates the service to which the telemetry
  source packet relates.
• Subtype, service subtype (packet data field
  header). Together with the service type, the
  subtype uniquely identifies the nature of the
  service report constituted by this telemetry
  source packet.
• VCID, virtual channel identifier where the packet
  has to be routed.
• Period, packet generation time period.
• Time Code, it defines the telemetry source packet
  time field in the packets data field header
  (NONE, CDS or CUC).

14
TM Packet Editor

• The Source Data table defines the source data
  field of the of the selected packet, it consists
  of the following fields
• Par. Name, name of the telemetry parameter
  located at the specified byte and bit offsets in
  the packet.
• Byte-offset, number of bytes between the start of
  the TM parameter and the first byte of the packet
  (Byte 0).
• Bit-offset, number of bits between the start of
  the TM parameter and the specified byte offset

15
Bus Editor
The Bus Editor allows to define the OBDH bus
interrogations or MIL 1553 bus transactions to be
performed by the flight software to retrieve the
telemetry source data generated by the on-board
models.
16
Bus Editor
17
TC Parameter Editor

• The TC Parameter Editor allows to define and
  update telecommand parameters. Each parameter is
  characterised by
• Name, it uniquely identifies the parameter.
• Size, size (number of bits) of the parameter.
• PTC, Parameter Type Code. It controls the
  encoding format of the parameter. It is used by
  SCOS-2000 in order to decode the value of
  parameters extracted from packets
• PFC, Parameter Format Code. Along with the
  Parameter Type Code this field controls the
  length of the parameter. It is used by SCOS-2000
  for parameters extracted from packets

18
TC Packet Editor

• TC Packet Editor allows to
• add a new TC packet to the current TC
  configuration
• update the TC packet header parameters
• remove a TC packet from the current TC
  configuration
• add a TC parameter to a TC packet
• remove a TC parameter from a TC packet

19
TC Packet Editor

• The TC Packets table displays the list of packets
  currently defined.
• Name, TC packet name. It uniquely identifies the
  telecommand packet.
• APID, packet APID field of the packet header.
• Length, packet length field. It specifies the
  number of octets contained within the packet data
  field.
• DFH, Data Field Header Flag. It indicates the
  presence or absence of a data field header.
• Type, service type (packet data field header). It
  indicates the service to which the telecommand
  packet relates.
• Subtype, service subtype (packet data field
  header). Together with the service type, the
  subtype uniquely identifies the nature of the
  service request constituted by this telecommand
  packet.
• ACK, acknowledge (packet data field header). It
  indicates which acknowledgements, in the form of
  telecommand verification packets, shall be sent
  to the ground to notify acceptance and to verify
  execution of the telecommand packet.

20
TC Packet Editor

• The Application Data table defines the
  application data field of the of the selected
  packet,
• Par. Name, name of the telecommand parameter
  located at the specified byte and bit offsets in
  the packet.
• Byte-offset, number of bytes between the start of
  the TC parameter and the first byte of the packet
  (Byte 0).
• Bit-offset, number of bits between the start of
  the TC parameter and the specified byte offset.
• Default Value, value to be assigned to the
  parameter by default.

21
Development System

• The Development System allows to
• Load configuration files, exported by the
  Configuration Editor, which specialise the
  Generic Emulator Software.
• Produce a set of MIB files correspondent to the
  defined configuration.
• Generate a set of files used to complete the
  software source code in accordance with the
  defined configuration
• Build the Generic Emulator Software binary image

22
Generic Emulator Software - Services

• TM(1,1) Telecommand Acceptance Report - Success
• TM(1,2) Telecommand Acceptance Report - Failure
• TM(1,7) Telecommand Execution Completed Report -
  Success
• TM(1,8) Telecommand Execution Completed Report
  Failure
• TC(2,1) Distribute ON/OFF Commands
• TC(2,2) Distribute Register Load Commands
• TC(3,5) Enable Housekeeping Parameter Report
  Generation
• TC(3,6) Disable Housekeeping Parameter Report
  Generation
• TM(3,25) Housekeeping Parameter Report
• TM(5,1) Normal/Progress Report
• TM(5,2) Error/Anomaly Report - Low Severity
• TM(5,3) Error/Anomaly Report - Medium Severity
• TM(5,4) Error/Anomaly Report - High Severity
• TC(9,1) Change Time Report Generation Rate
• TM(9,2) Time Report

23
Generic Emulator Software - Services

• TC(14,1) Enable Forwarding of Telemetry Source
  Packets
• TC(14,2) Disable Forwarding of Telemetry Source
  Packets
• TC(14,3) Report Enabled Telemetry Source Packets
• TM(14,4) Enabled Telemetry Source Packets Report
• TC(14,5) Enable Forwarding of Housekeeping
  Packets
• TC(14,6) Disable Forwarding of Housekeeping
  Packets
• TC(14,7) Report Enabled Housekeeping Packets
• TM(14,8) Enabled Housekeeping Packets Report
• TC(14,13) Enable Forwarding of Event Report
  Packets
• TC(14,14) Disable Forwarding of Event Report
  Packets
• TC(14,15) Report Enabled Event Report Packets
• TM(14,16) Enabled Event Report Packets Report
• TC(17,1) Perform Connection Test
• TM(17,2) Link Connection Report

24
Portability
Configuration Editor and Development System have
been developed in Java. The Generic Emulator
Software has been developed in ANSI-C. GCC-ERC32
cross-compiler available for Sun SPARC Solaris,
IBM PC Linux and Microsoft Windows
25
Project Work-Flow
Requirements Phase - production of Software
Requirements document. Architectural Design Phase
- perform architectural design, production of SAD
and ICD documents. Implementation Phase - coding
and testing of the components. Acceptance Phase -
delivery, acceptance testing and training.
26
GETS - Work Flow
27
Project Status
Requirements Phase - completed. Architectural
Design Phase - completed D1 delivery -
Configuration Editor and Development System.
Delivered to ESOC, re-delivery planned 14 Nov. D2
delivery - contains all GETS components including
Validation System (VS). Planned for 16 December
2005. Remaining activities - completion of VS and
GES integration, formal testing and delivery.
28
Questions ?

• Thanks for your attention !

29
Contacts in Dataspazio
30
Contacts in VEGA