c FE FSW at APL FSW Reusability C

c. FE FSW at APL & FSW Reusability C. Monaco chris. monaco@jhuapl. edu 240 -228 -5387

Overview • APL use of c. FE – Application Template – Libraries • Spark discussion in the community regarding best practices for – Abstracting HW & Platform – Increasing the reusability of FSW – Use of drivers 2 9/18/2021

c. FE at APL • Van Allen Probes – – – First use of c. FE (c. FE 5. 1. 0 & OSAL 2. 11) RAD 750, Vx. Works 6. 4 Two spacecraft Earth orbiters Launched 8/30/2012 • Predecessor APL missions STEREO and MESSENGER did not use c. FE & OSAL middleware – Much of the APL FSW infrastructure was able to be adapted into the c. FE environment + 3 9/18/2021 c. FE & OSAL

c. FE at APL • 2011 – 2012 - JHU APL / GSFC IRAD efforts – Memory Protection IRAD Ø c. FE running in user-mode on an embedded system running Vx. Works 6. 7 – Multi-Core IRAD Ø c. FE systems running in Asymmetric Multiprocessing (AMP) & Symmetric Multiprocessing (SMP) • Solar Probe Plus Ø One spacecraft (SC) with 3 Single Board Computers (SBCs) Ø 2018 Launch – Flight Software Ø RTEMS 4. 10 Ø APL developed SBC with UT 699 E Ø c. FE 6. 4. 0, OSAL 4. 1 – Testbed Ø Red. Hawk 6. 3. 3 Linux – with real-time kernel patch Ø Hosts emulations of SC components that are unavailable on a particular testbed 4 9/18/2021

Application Commonality • During the development of Van Allen Probes FSW it was recognized that applications that use c. FE have a lot in common – – – Initialization with c. FE Initialization with scheduler (SCH) application Housekeeping telemetry generation Initialization of parameter management Some common commands Common features Ø Counters Ø Telltales Ø Message processing (message & response handler infrastructure) Ø Command processing (command & response handler infrastructure) – All applications need to be maintained 5 9/18/2021

Application Template • A Common Application Template was developed under Van Allen Probes • Van Allen Probes: Each APL-Developed FSW application will be built upon a Common Application Template – Isolate infrastructure from application-specific functionality – Jump-start software development for new applications – Allow developers to focus on the personality of each application rather than the basic application infrastructure – Provides application uniformity & simplification of software maintenance • The Common Application Template is cloned to create new applications – Reduces code review materials – Reduces unit test effort – References to TMP within the template source are automatically converted to the mnemonic for the application Ø TMP_App. Wakeup() becomes AUT_App. Wakeup() 6 9/18/2021

Application Template – reusability and maintainability • The Application Template exists in separate source files from the application-specific code • Maintaining the Application Template is similar to maintaining a middleware – The APIs have an incentive to remain the same – The implementation may be changed – The updated template can be deployed to existing applications and new applications alike Ø With zero or minimal disruption to existing applications 7 9/18/2021

APL c. FE Applications • OSAL allows the software applications to be abstracted from the OS • c. FE helps abstract one application from another – Rather than making direct function calls (whose APIs could change) from one application to another, messages are sent on the software bus • Applications – Some C&DH applications are highly re-usable – have no SC / platform dependencies – Some FSW applications have some SC / platform dependencies but are otherwise largely independent of the SC / Platform – Other applications are very dependent upon the SC / Platform 8 9/18/2021

APL c. FE Applications • A goal was to maximize the potential for reuse of FSW applications from mission to mission • A goal was to facilitate FSW development on the ubiquitous linux platform – Free up valuable test-bed time • Therefore, a design objective of the APL Flight Software Application was to (within reason) abstract the hardware from the applications 9 9/18/2021

APL Libraries for c. FE Systems • Some FSW libraries exist to provide common functionality to multiple applications – Table management – Utility functions, etc. • Some FSW libraries exist to provide an abstraction to SC or HW – Enable development on pc-linux platform – Enhances reuse for subsequent missions. 10 9/18/2021

APL Libraries for c. FE Systems • Memory Object Handler – An example of a SC / platform independent library – Rather than using the c. FE Table Services, much of the APL legacy flight software used “Memory Objects” Ø Custom parameter management system was subsequently ported to the c. FE environment as MOH_lib – Applications “Register” with the Memory Object Handler Library: Ø Register “memory object type” with the library Ø Register “memory object IDs” q Individual memory objects or a group if the same kind of memory object Ø Register call-back functions to allow access, manipulation and verification of the registered objects Ø Provides mechanism for modifying, uplinking, downlinking the contents of selected tables or internal data structures 11 9/18/2021

APL Libraries for c. FE Systems • EEPROM Library – Van Allen Probes had EEPROM non-volatile memory – This library abstracted the details of EEPROM from the applications that required access: EE_Read(), EE_Write. Enable. Disable(), etc. – A simple port of this library was created to emulate EEPROM using a file for pc-linux Ø This allowed development on Van Allen Probes to proceed in the pc-linux environment – The existence of this library allowed the software that used it to be portable to other NVM technologies through a different port of the library • APL BSP Library – Interface to timers for scheduler (SCH) application interrupt and synchronization – Which NVM image was booted and is running – Collect CPU utilization metrics – Check validity of RAM addresses – A port exists for Van Allen Probes, PC Linux, and SPP 12 9/18/2021

APL Libraries for c. FE Systems • SSR Library – – Access to SSR registers SSR DMA Provide housekeeping specific to the SSR hardware Provide consistent access to SSR by FSW applications Ø Mutual exclusion, maintenance of applicable state information • SCIF Library – Most spacecraft specific – Opportunity for reuse across missions is minimal – Enables FSW to run on pc-linux for the particular mission Ø Abstraction of uplink/downlink hardware Ø Abstraction of Spacecraft Interface (SCIF) HW Ø Abstraction of the Space. Wire Router Ø Abstraction of other mission unique hardware 13 9/18/2021

APL Libraries for c. FE Systems • Source code for the libraries is either – Flat: for libraries that exist to provide common functionality across multiple applications Ø MOH_lib/<source>. c – Parallel: for libraries that exist to abstract SC or platform Ø SCIF_lib/shared/<source>. c Ø SCIF_lib/spp-sbc/<source>. c Ø SCIF_lib/pc-linux/<source>. c – Environment variables in the build (similar to those that help locate the PSP port) are used to select the library port. 14 9/18/2021

Follow Up • The community could benefit from more discussion on – Best practices of use of Drivers & Libraries 15 9/18/2021