1 / 18

Ground Support Equipment

Ground Support Equipment. Will Rachelson University of California - Berkeley WRachelson@ssl.berkeley.edu. Outline of GSE Topics. GSE Requirements Documents GSE Hardware Backplane Interface Board (BIB) BEB DCB PCB IDPU GSE Software GSEOS Extensions. GSE Requirements.

ignatius-bates
Download Presentation

Ground Support Equipment

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ground Support Equipment Will Rachelson University of California - Berkeley WRachelson@ssl.berkeley.edu

  2. Outline of GSE Topics GSE Requirements Documents GSE Hardware Backplane Interface Board (BIB) BEB DCB PCB IDPU GSE Software GSEOS Extensions

  3. GSE Requirements For GSE hardware, design drivers come from specifications and requirements of the hardware to be supported: RBSP_EFW_BPL_001M_Specification.pdf RBSP_EFW_LVPS_001I_Specification.doc RBSP_EFW_DCB_001N.pdf RBSP_EFW_DCB_003E_Specification.pdf RBSP_EFW_DFB_001B_SPECrevB.pdf etc. For GSE Software, from the EFW GSE Software Requirements Document: RBSP_EFW_GSE_001_Requirements.doc

  4. 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.

  5. Backplane Interface Board Design as presented at CDR.

  6. 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)

  7. GSE Supporting BEB Testing Backplane Interface Board commands BEB DAC, MUX, and enables ACTEST signals. Used for: characterization and test of BEB electronics.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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 Scripting Displays

  13. 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_UUT01_TVAC_DAY1/ |-- 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

  14. Data Products We have a plan for data products. Things we’ve done are compatible with things to come.

  15. 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.

  16. 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.

  17. 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: 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

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

More Related