2024-25 Software Planning

Owned by Aaron Chan (RIT Student)
Last updated: May 28, 2024
4 min read

Overall Goals

  • Increase software quality assurance through a variety of techniques, including but not limited to

    • Simulations

    • Unit Testing w/ code coverage scans

    • Static Analysis

    • Address Sanitizers

  • Develop infrastructure that can simplify interfacing between GSW and FSW

  • Develop frameworks to improve maintenance of future software

  • Heavily document software design and architectural decisions for future members to understand and learn from

Ground Software

  • Rewrite in Golang

    • Well-suited for networked and concurrent applications

    • Less likely to f*ck up memory (garbage collection)

    • Good tooling

    • Can work on almost any platform (can depend on our design though)

  • Prototype already in the works with a telemetry configuration manager and some semblance of communication between threads (not processes) using channels

  • Come up with how new GSW should operate. Ideally, in an extremely user friendly way that simplifies starting up the system, so anyone can do it

  • Idea: Write backend service(s) and have users run applications that take advantage of service(s). Most likely SOA though, so a single service. Might be simpler too and keep things standardized over microservices.

  • Service(s) should handle

    • Setting up a telemetry configuration on startup

    • Arbitrating between other specified nodes in a network to distribute compute. This can be somewhat complex, so we should start with just supporting a single machine, but make it extensible for this feature. Still looking into what our future ground station hardware will look like since we want to move away from LattePandas

    • Running other necessary services (i.e InfluxDB and Grafana)

    • Receiving all telemetry over UDP and processing it before serving it to application code (most likely going to be a broker architecture pattern)

    • Logging received telemetry over InfluxDB and csv

    • Logging internal messages (for debugging)

  • Applications

    • log_view - View logs. If we operate as a service, it would be ideal to have the logging service log to journalctl, but users may not be tech-pilled enough to do this, so read from that.

    • telem_view - Telemetry viewer. Can toggle viewing memory in base-2, 10 and 16.

Flight Software

  • Make code less hack(athon-)y

  • Re-write in C++ (TBD. Requires more prototyping, determining what the software team will look like and overall avionics team goals for 2024-2025. If we go this route, these are possible libraries (which must be properly designed, discussed and documented before implementation):

    • Transport - Interface for inter-board communication over various protocols (UDP, LoRa, SLIP)

    • Event Manager - Monitor and send events over a transport interface

    • Actors (Pub-Sub) - Have actors/tenants that can subscribe to message ports and send messages over message ports. See about using a zbus implementation with some prototyping. See about standardizing between all ground and flight hardware, which most likely necessitates an auto-gen tool. More on this later. Maybe have actors/tenants be able to share threads, if they access a shared resource?

    • Sensor - Generic sensor class with subclasses that handle retrieving data automagically

    • State Machine - Zephyr has a very barebones implemenation. Maybe make an autogen class that other classes inherit from. Concept of events and flags. User defines what are the possible state transitions and what events/flags will trigger these state changes.

  • Basic CONOPs of how the above should work

    • Initialize

      • Configure transports

      • Set up event manager

      • Create actors and subscribe to ports

      • Create tasks and assign actors to a task

      • “Start the RTOS” - Just starts all the tasks

    • Start tasks. When each tasks starts running it will go through

      • Startup() - Initialize stuff

        • This can include sensors!

      • Post-Startup() - Initialize stuff that has to be done after startup

    • Run

      • Until the end of time (or if we fail out or return early)

      • Different boolean flags can be set, or events can occur triggering state changes causing run method to change

      • Sensor classes will automatically grab data if possible and signal when tasks can take that data

      • etc.

  • Hardware Simulations

    • ModSim - Simulate operating a single module

    • Simplane - Simulate the above, but they all can communicate with each other

    • Need to determine software stack/tools for this

      • QEMU

      • Docker

  • CI Checks

    • Unit Tests. Unit Tests. Unit Tests. Easier to do earlier on in the process. Mandate unit tests, especially when we start library development

      • GTest

    • Static analysis tools.

      • Coverity is a good one

      • Maybe also IKOS?

    • Address sanitizer

    • Valgrind

      • TBD: Significantly slower than address sanitizers. There are trade-offs.

    • Add a linter and formatter

Internal Software Tooling

  • Commander (FSW) - Interface with the FSW event manager library by sending commands over a specified transport. Commands are expected to be an 8 bits.

  • OrkSim (FSW) - Take generated OpenRocket output, parse a configuration and send specific data from OpenRocket as telemetry over Ethernet to see how the backplane (besides sensor-module will respond)

  • Generator (GSW/FSW) - Needs further design, since this has high impcat on future GSW and GSW. Take a series of yaml files and generate header and source files that link to the rest of the GSW and FSW codebases. Maybe make this a submodule for both repositories to inherit and determine what to do.

    • Instead of re-inventing the wheel, take advantage of protobuffers for defining telemetry messages, a proven industry standard. This will come at the cost of some CPU and memory performance, but there is significantly more tooling support in place to support development, compared to developing our own in-house solutions.

    • Other things like state machine generators will have to be YAML or some other markup language still