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.
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.
Ground Support Equipment
University of California - Berkeley
GSE Requirements Documents
Backplane Interface Board (BIB)
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:
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.
Design as presented at CDR.
Backplane Interface Board commands BEB DAC, MUX, and enables ACTEST signals.
Used for: characterization and test of BEB electronics.
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.
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.
“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.
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 Software = Additions to GSEOS
What is GSEOS?
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
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
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:
We have a plan for data products.
Things we’ve done are compatible with things to come.
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.
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:
No easy console interface
Not quite as flexible as we wanted
Scripting interface developed, enabling:
List available 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
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…