Radiation Belt Storm Probes RBSP Ground Support Equipment
Radiation Belt Storm Probes RBSP Ground Support Equipment Will Rachelson University of California - Berkeley WRachelson@ssl. berkeley. edu RBSP/EFW CDR 2009 9/30 -10/1 647
Outline of GSE Topics • GSE Requirements Documents • GSE Hardware – – – Backplane Interface Board (BIB) BEB DCB PCB IDPU • GSE Software – GSEOS Extensions Rachelson RBSP/EFW CDR 2009 9/30 -10/1 648
GSE Requirements • For GSE hardware, design drivers come from specifications and requirements of the hardware to be supported: • • • RBSP_EFW_BPL_001 M_Specification. pdf RBSP_EFW_LVPS_001 I_Specification. doc RBSP_EFW_DCB_001 N. pdf RBSP_EFW_DCB_003 E_Specification. pdf RBSP_EFW_DFB_001 B_SPECrev. B. pdf etc. • For GSE Software, from the EFW GSE Software Requirements Document: • RBSP_EFW_GSE_001_Requirements. doc Rachelson RBSP/EFW CDR 2009 9/30 -10/1 649
GSE General Architecture Rachelson RBSP/EFW CDR 2009 9/30 -10/1 • 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. 650
Backplane Interface Board Design as presented at CDR. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 651
Backplane Interface Board Design as-built. 1. Opal-Kelly FPGA. Same board as APL S/C emulators = Easy integration with GSEOS. Code re -use from DCB FPGA. 2. Backplane connection to one of BEB, DCB, or PCB. 3. External timing stimulus input (from SCE’s PPS/SP line) Rachelson RBSP/EFW CDR 2009 9/30 -10/1 652
GSE Supporting BEB Testing Backplane Interface Board commands BEB DAC, MUX, and enables ACTEST signals. Used for: characterization and test of BEB electronics. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 653
GSE Supporting DCB Testing BIB and DCB reside in GSE chassis on GSE Backplane. Bench supplies power DCB and 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. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 654
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. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 655
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. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 656
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. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 657
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 Telemetry Definition Parser Scripting Displays Rachelson RBSP/EFW CDR 2009 9/30 -10/1 658
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 Ap. ID) – 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_UUT 01_TVAC_DAY 1/ |-- 20090901_104123_UUT 99_APID_241. ptp |-- 20090901_104123_UUT 99_APID_243. ptp |-- 20090901_104123_UUT 99_APID_244. ptp |-- 20090901_104123_UUT 99_APID_267. ptp |-- 20090901_104123_UUT 99_APID_268. ptp |-- 20090901_104123_UUT 99_APID_26 a. ptp |-- 20090901_104123_currents_screenshot. jpg |-- 20090901_104123_UUT 99_ITF. raw `-- 20090901_104123_UUT 99_log. log Rachelson RBSP/EFW CDR 2009 9/30 -10/1 659
Data Products We have a plan for data products. Things we’ve done are compatible with things to come. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 660
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, Dec. Status_RBSPCmd. Instr. MET, that represents the MET of the most recently clocked out S/C Time and Status (Ap. ID 0 x 100) packet. • Verified prior to instrument testing. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 661
Command Telemetry Definition Parser • • • What we call “CTM” is the Command Telemetry Definition Document, an Excel spreadsheet. From this document, GSEOS configuration files are built. Didn’t use GSEOS’s tool for this because: – – • • Python script, invoked from GSEOS: reload_ctm() Reads CTM definitions (. xls file) and generates GSEOS configuration files: – – – • • • It wasn’t released yet Wanted to support our existing document format 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 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. Rachelson RBSP/EFW CDR 2009 9/30 -10/1 662
Scripting • • • 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: – – – • 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: – – • Syntactic overhead No easy console interface Not quite as flexible as we wanted 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 Rachelson RBSP/EFW CDR 2009 9/30 -10/1 663
Displays Of course, a host of display screens were also developed… Rachelson RBSP/EFW CDR 2009 9/30 -10/1 664
- Slides: 18