Ground support equipment
1 / 18

Ground Support Equipment - PowerPoint PPT Presentation

  • Uploaded on

Ground Support Equipment. Will Rachelson University of California - Berkeley [email protected] Outline of GSE Topics. GSE Requirements Documents GSE Hardware Backplane Interface Board (BIB) BEB DCB PCB IDPU GSE Software GSEOS Extensions. GSE Requirements.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Ground Support Equipment' - ignatius-bates

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ground support equipment

Ground Support Equipment

Will Rachelson

University of California - Berkeley

[email protected]

Outline of gse topics
Outline of GSE Topics

GSE Requirements Documents

GSE Hardware

Backplane Interface Board (BIB)





GSE Software

GSEOS Extensions

Gse requirements
GSE Requirements

For GSE hardware, design drivers come from specifications and requirements of the hardware to be supported:







For GSE Software, from the EFW GSE Software Requirements Document:


Gse general architecture
GSE General Architecture

This is the general configuration of the GSE used to bring up the individual boards of the IDPU, as well as in testing the integrated IDPU.

IDPU boards have low level hardware interfaces, so GSE Backplane Interface Board is needed to control them from the GSE PC.

GSE PC runs GSEOS, which is extended to talk to devices such as the GPIB test equipment, the Backplane Interface Board, and the Spacecraft Emulator.

Backplane interface board
Backplane Interface Board

Design as presented at CDR.

Backplane interface board1
Backplane Interface Board

  • Design as-built.

  • Opal-Kelly FPGA. Same board as APL S/C emulators = Easy integration with GSEOS. Code re-use from DCB FPGA.

  • Backplane connection to one of BEB, DCB, or PCB.

  • External timing stimulus input (from SCE’s PPS/SP line)

Gse supporting beb testing
GSE Supporting BEB Testing

Backplane Interface Board commands BEB DAC, MUX, and enables ACTEST signals.

Used for: characterization and test of BEB electronics.

Gse supporting dcb testing
GSE Supporting DCB Testing

BIB and DCB reside in GSE chassis on GSE Backplane.

Bench supplies power DCB and BIB.

BIB generates fixed test pattern data as if it were the DFB. The test pattern is played out on the DCB’s debug port.

The GSE Laptop records the played back test pattern, allowing verification of the DCB-FPGA module.

Gse supporting pcb testing
GSE Supporting PCB Testing

BIB harnessed to LVPS (or both reside in backplane).

BIB commands PCB portion of the LVPS.

Boom Loads Box used for verification of PCB functions.

Gse supporting idpu testing
GSE Supporting IDPU Testing

“Standard” GSE configuration.

Signal is applied to the sensor sphere.

The IDPU samples the signal from the sphere and sends data to the GSE laptop via the SCE.

Used for: characterization of electronics.

Gse supporting idpu testing1
GSE Supporting IDPU Testing

BIB used to gate the SCE’s PPS/SP signal. When armed by the GSE laptop, it can release a single pulse at a known MET.

Used for: timing analysis.

Gse supporting fsw testing
GSE Supporting FSW Testing

GSE Software = Additions to GSEOS

What is GSEOS?

Commercial software

Supplied with APL S/C Emulator to each instrument team

Thomas Hauck at GSEOS implemented an “RBSP Bios” for GSEOS, which interfaces with the APL S/C Emulator and handles protocols used in this mission: ITF, CCSDS, etc.

Up to instrument teams to further customize GSEOS for their instrument

Key EFW Additions to GSEOS:

Data Product Management

Knowledge of Current MET

Command and Telemetry Definition Parser



Data product management
Data Product Management

One place for any data generated during a test

Test name assigned at startup or reassigned during execution

Data products include:

PTP files (CCSDS data split by ApID) – MOC format, works with same NRT tool down the road

Raw ITF – every byte the emulator receives from the instrument

Single log file – all GSEOS events captured to one location

Screenshots, other test data, etc

Rsync process

So that data doesn’t live on the GSEOS laptop itself

Data collected at one location from any GSE workstation

Data backed up at central location

Sample output directory:


|-- 20090901_104123_UUT99_APID_241.ptp

|-- 20090901_104123_UUT99_APID_243.ptp

|-- 20090901_104123_UUT99_APID_244.ptp

|-- 20090901_104123_UUT99_APID_267.ptp

|-- 20090901_104123_UUT99_APID_268.ptp

|-- 20090901_104123_UUT99_APID_26a.ptp

|-- 20090901_104123_currents_screenshot.jpg

|-- 20090901_104123_UUT99_ITF.raw

`-- 20090901_104123_UUT99_log.log

Data products
Data Products

We have a plan for data products.

Things we’ve done are compatible with things to come.

Knowledge of current met
Knowledge of Current MET

Wanted to make an ARM PPS Trigger command in GSEOS.

In order to support timing tests using the SCE’s PPS/SP signal, we needed GSEOS to have some knowledge of the MET the instrument received from the SCE.

Worked with Thomas Hauck in order to get this in GSEOS.

Result was a new release of GSEOS that has a variable, DecStatus_RBSPCmd.InstrMET, that represents the MET of the most recently clocked out S/C Time and Status (ApID 0x100) packet.

Verified prior to instrument testing.

Command and telemetry definition parser
Command and Telemetry Definition Parser

What we call “CTM” is the Command and Telemetry Definition Document, an Excel spreadsheet.

From this document, GSEOS configuration files are built.

Didn’t use GSEOS’s tool for this because:

It wasn’t released yet

Wanted to support our existing document format

Python script, invoked from GSEOS: reload_ctm()

Reads CTM definitions (.xls file) and generates GSEOS configuration files:

Limit definitions for telemetry items (.alarm files)

Engineering unit conversions (.qlf files)

Text references (.tr files)

TLM formats (.blk files)

CMD formats (.cpd files)

This means a user can edit an Excel document to manipulate the available set of commands and telemetry formats available in GSEOS.

GSEOS code decoupled from the spec, spec can change without programmer assistance.

Version information stored in CTM document and propagated into GSEOS configuration files and session logs.


Requirement for closed-loop instrument control

GSEOS has Python interpreter but no concept of a “script” that could be invoked by the user. Nearest thing to scripts were sequencers.

Did not use sequencers because:

Syntactic overhead

No easy console interface

Not quite as flexible as we wanted

Scripting interface developed, enabling:

List available scripts

Start/Stop scripts

Scripts can call other scripts, return values

Scripts have access to command dictionary, TLM items

Code reuse. Frequently performed actions (e.g., configuring the instrument for a certain mode) are scripts which can be called by other scripts.

All scripts have common features, like logging and error handling

Scripting interface:

User creates a Python file in any subdirectory of EFW/scripts/

User defines a main() function

The script is then available for execution within GSEOS

No GSEOS restart or additional reloading required

We created a collection of fully documented example scripts that demonstrate script capabilities. From these examples users have been able to create their own scripts.

Version control: all scripts stored in SVN


Of course, a host of display screens were also developed…