Software Requirements

  • Software Types
    • Commercial off the Shelf (COTS) - Used as is (no changes made for NASA use)
    • Modified COTS - Software modified for NASA use, Often PI developed and modified for use on ISS
    • Custom - PI or ROI developed
  • Software Classification
    • All ROI flown software is assumed to be Class C and follows the guidelines in NPR 7150.2 Rev D, Appendix D.
  • Software Requirements
    • General:
      • Software requiring HRF rack interfaces should request additional information from ROI.
        • Health and Status packet format.
        • Real time telemetry packet format.
      • Software with a graphical user interface must follow display design requirements.
        • Display screenshots must be submitted for review.
        • See PDRT/IDAGS.
      • Software developers should be scoped for the lifetime of a project for maintenance/troubleshooting.
        • User interface modifications may be required after display screenshot review.
        • Operating system or hardware platform changes may require code updates.
      • Software developers should develop and test with the flight operating system and hardware environment.
        • Flight operating system are standardized and and are not the most current available.
        • Flight computers are standardized and are often older models.
      • Software installation:
        • Installer packages should contain all dependencies and should not require internet access.
        • Installer should install executable in the same location every time. (No Microsoft "Click Once" installation packages).
      • Configuration file
        • Software should read variables from a text editable file.
        • File should contain variables that may change during the lifetime of the experiment.
        • Variables can be changed without recompiling code.
      • Experiment Data location
        • Experiment data is stored in different locations on different platforms for downlink.
        • Experiment software running on the SSCs usually stores data on the SSC server.
        • Experiment software running on the HRF PCs usually store data on the secondary hard drive.
        • Data location should be a variable in the configuration file because names of the desired storage location change.
        • Following data storage convention helps operations personnel easily downlink experiment data and clean up hard drive space.
      • No access to servers outside the ISS Domain.
        • Experiment software does not have internet access on ISS.
        • Experiment software has no acccess to servers outside of the ISS domain.
        • HRF PCs do not have access to the SSC server for experiment data storage.
      • If the application collects data and does not require access to the iPad hardware (camera, microphone, etc.), PIs should develop a web-based application for the SSC server.
        • iPad implementation has many challenges. iPad Certification.
        • Risk to iPad app approval if no iPad hardware is required.
        • Web Apps can be used on any platform on the ISS Ops LAN.
        • Much easier to update server applications on-orbit.
      • iOS is updated on ISS approximately four (4) times a year when Apple releases their major increment releases (iOS 15, 16, etc.) March/April, June/July, September/October and December/January.
        • Do not assume the latest iOS is on ISS.
        • It is recommended to develop the app as a Business to Business (B2B) application.
        • A SSC Workflow CR must be submitted in order to schedule and obtain approval for the uplink and installation of the app on ISS.
        • The app must be tested in the flight like environment in the SSC Lab for the initial installation of the app on ISS.
        • Thereafter, for each iOS update on ISS, the app will undergo functionality testing to ensure proper function. Any updates necessary will be the responsibility of the PI.
      • Software should generate error log files/dump files in due case software crashes and ROI need to troubleshoot event. This should be the case for MOTS specifically and custom (no COTS).
    • File Structure:
      • Need to specify the data storage file structure.
        • When data is archived, a key will need to be provided for data file/folder structure.
      • Individual files should be at static locations.
      • Folder Structure should have unique names.
      • Unique filenames are preferred.
        • Unique filenames are preferred but a file name can be reused. The documentation needs to indicate if all file names are unique or not.
      • File names shall not contain PII.
        • File names containing PII or login IDs cause problems for data handling. It is difficult to encrypt file names prior to downlink.
      • Database files - Flat file databases are preferred over use of database tools. Database tools change and software must be maintained to function with the database application.
    • Lessons Learned:
      • Successful ground implementation does NOT mean the implementation will work as is on ISS.
        • Analog environments have different requirements than ISS.
      • PIs should plan for ISS unique implementation regardless of platform.
      • There are hidden costs associated with crowd source development.
      • Complex client/server applications have not performed well on ISS.
    • Best Practices:
      • It is helpful to have the version number displayed on the main screen of software.
      • Plan for communication overhead among developer, contracts, OD and ROI software integration.
      • Recommend using a simple server implementation rather than an interactive one.
        • Simple means the application accesses configuration files on the server no more than once when application is launched and saves data to the server only when the user submits it.