Near-Term Functions of the Software Architecture and Standards TC

In regards to the charter for the Software Standards and Architecture Committee, we're talking mostly about flight software and the software we'll use in real-time support from the ground.

Right now, architecture is more urgent than standards. The big question we need to answer is: How much will it cost us to get this spaceship to the moon? To do that, we need to estimate some numbers:

• How much software we need to fly and operate this thing
• How the software is organized
• What we can get off the shelf
• What we'll have create and verify ourselves

At NASA, the software engineers use Source Lines of Code as their measure for estimating the software load, called "slocs". A sloc is an executable statement or a declaration, etc. It doesn't include comments or other non-functional lines.

A good way to start is by making a catalog of all the software functions and breaking it down into software modules. That will probably involve some brainstorming, a lot of asking questions of folks in the other technical committees, and touring around the stuff that NASA has produced to figure out how they control their spacecraft.

It'll turn out something like...

• Flight Software
  • Spacecraft Command and Control
    • Command Filtering and Security
    • Crew Displays
    • Control Executive and Event Scheduling
  • Communications
  • Navigation
    • Sensor Data Handling
    • Nav State Determination
    • Ephemeris Model
    • Earth Model
    • Moon Model
    • Space Traffic Model
  • Systems Monitoring and Control
    • Electrical Power System
    • Environmental Control System
      • Atmosphere System
      • Crew Potable Water System
      • Waste Control System
    • Lighting System
    • Propulsion System
    • Thermal Control System
    • Video System
    • Audio System
    • etc. etc. etc.
• Ground Control
  • Systems Monitoring
    (systems, system, systems)
  • Ground Support Displays
  • Ground Control Communication
  • Public Displays
  • Ground Crew Life Support (that is, the coffee pot)
  • Public Affairs Office Console Functions
  • Inter-site Communcation (for a distributed ground support function)

The section numbers should be made to mirror the Artemis Data Book outline as much as possible.

Once the Software Architecture and Standards Tech Committee has a handle on what software will be required, it can start guessing how much custom software will have to be written, and what can be acquired off the shelf. For the off-the-shelf software, an estimate of what it will cost to acquire the software needed would be prepared.

With that in hand, we'll have a good estimate of just how big this job will be. Then the software engineers who've done real flight software can prepare an estimate of how many man-hours it takes to create a sloc, and turn man-hours into money. We spread out the hours, and voila! We have a cashflow estimate.