One Giant Leap - Lunar C&C

https://youtu.be/hV9nS7hdEyI

https://github.com/evandigby/lunar-cmd

One Giant Leap - Lunar Command and Control

What does it do?

Mission Log Entry

The current version of One Giant Leap provides hundreds of signed-in flight controllers with the ability to create and edit mission log entries using text, audio, and images (video is planned for the future). These entries are tagged with a timestamp and appear to all flight controllers viewing the mission log in real-time.

Editing Log Entries

Flight controllers can go back and edit their own log entries, but they cannot edit entries from other flight controllers. The application keeps an edit history for each log entry so that previous versions can be referred to when needed.

Multiple Logs

The flight controller has access, by default, to two logs: their own, and the entire mission. These logs can be sorted or filtered by any available field allowing the flight controller to change the logs they’re viewing. A planned but not yet complete feature allows the flight controller to define additional logs based on those filters for quick access.

Automated Audio Transcription

Audio entries are automatically transcribed and entered both as text entries, as well as audio attachments so flight controllers can refer to the source audio. Video transcriptions are planned once the application supports video. This feature not only provides a critical form of accessibility for flight controllers, but also allows radio communications to be directly linked to the mission log with transcriptions and original source audio clips appearing to all flight controllers in real-time.

Audit Trail

Every action taken by the flight controller that updates the mission log is recorded. This provides a complete audit trail allowing mission log owners to understand what the state of the mission log was at any given point in time. Since critical decisions can be made based on the information available to flight controllers, this auditability allows you to understand exactly what information was available to the flight controller at the time they made that decision whether during the mission, or when debriefing.

Custom Log Entry Types

This feature was planned and implemented as a mock-up only.

Custom Log Entry types allow flight controllers to define custom templates specific to the types of their information their role requires. These custom templates consist of type-validated form-fields the flight controller can use when creating new log entries to ensure they log all information required for an event, and ensure the data input is validated.

How does it work?

Event Sourcing

The “Event Sourcing” architecture pattern is used to enable a completely auditable and reliable mission log. This is the backbone to the service on top of which all other features have been built. The event sourcing process works as follows:

1. When a flight controller takes an action that modifies the log, whether adding or editing, and whether it’s a plain text entry, image, or audio, a “Command” is sent from the front-end to the back-end. This command contains a payload containing the log entry data, as well as a command type (e.g. “AppendLogEntryCommand” in the case of adding a new log entry).
2. Upon receipt of a new command, the system ensures it came from an authorized flight controller, and then records that command and its payload in the “commands” table. This is the reliable audit trail provided. 
3. Once the command is recorded, the system processes that command so that the resulting action is reflected in the current “view” of the log (called a “materialized view” in event sourcing terms).
4. After processing the command, the system is used to broadcast the new or updated entry to flight controllers for real-time updates.

Current Implementation

• One Giant Leap is a WebAssembly based web application, so the flight controller accesses it through a browser.
• Authentication and Authorization is provided by Azure Active Directory
• A CDN is used to allow for a custom domain and minimize usage costs for static assets
• Azure Function Apps is used to host the back-end services
• Azure Blob Storage is used to store large binary uploads
• SignalR is used to provide real-time notification capabilities (broadcast push-notifications to browser)
• Cosmos DB is used to store the log entry event history (the source of truth) as well as the current view of the mission log. 
• Azure Cognitive Services is used to provide speech-to-text capabilities for audio dictation and real-time radio communication transcription.

On-Premise Implementation

Nothing about the fundamental architecture would need to change to convert this to an on-premise solution. A few of the technologies would need to be swapped for other open-source technologies; however, the code has been designed using interfaces to minimize the impact to the code when swapping out services. Here is a list of the technologies you’d need to swap:

• Azure Active Directory can be swapped for Active Directory for authentication and authorization.
• Azure Functions could be swapped for Windows server or linux to host the back-end services.
• Apache Kafka could be used as a reliable event sink.
• PostgreSQL, MongoDB, or virtually any other database technology could be used instead of CosmosDB.
• A RAID Network Attached File System could be used in place of Azure Storage to host attachments and other large binary files.

What Benefits does it have?

• Event sourcing architecture allows for replay of mission logs for audit or training purposes.
• Audio transcription allows flight controllers to keep their hands free, and radio communications to be automatically transcribed into the official mission log.
• Architecture is scalable from tens of flight controllers to thousands of flight controllers with minimal effort.
• Architecture is reliable. If built on Azure, all services used are available as geo-redundant solutions. If built on-prem, all of the suggested tools use industry leading consensus algorithms and other standards to guarantee reliability.

What do we hope to achieve?

• We hope we have developed the most reliable, scalable, and auditable architecture solution to allow flight controllers to seamlessly maintain, update, and monitor mission logs for the Artemis missions, and beyond.

What tools, coding languages, hardware, or software did you use to develop your project?

Technologies Used

• Azure Functions App Service (Hosting, back-end services, and event sink)
• SignalR (Real time notification)
• .NET Core Blazor WebAssembly (User Interface)
• .NET 6.0 (Preview)
• Blazority (User Interface)
• Cosmos DB (Data Storage)
• Azure Active Directory (User Authentication)
• Azure Blob Storage (Storing File Attachments)
• Microsoft Cognitive Services (Speech to Text)

Suggested alterations for on-premise configuration

• Windows Server or Linux (Hosting, back-end services)
• Apache Kafka (Event sink)
• PostgreSQL or Mongo DB (Data Storage)
• Active Directory (User Authentication)
• RAID Network Attached File System (Storing File Attachments)
• All other services remain the same in on-premise configuration.

Where would we like to see it go in the future?

I could talk about all the features we wanted to implement like video stream and transcription, custom log entry schemas, etc.; however, honestly, what we really hope is that this project and its architecture inspires the developers of the systems that will actually be used on the Artemis missions. If even one ounce of this project is used as the foundation to a system used by NASA it would be a dream come true.

Try it out!

https://lunar.digby.dev

Accounts:

testuser1@lunarcommand.onmicrosoft.com - password: welcome to lunar command1!

testuser2@lunarcommand.onmicrosoft.com - password: welcome to lunar command1!

To develop this system we heavily relied on the data provided in the resources section of this project. These resources: the Apollo 13 hand-written logs, the Apollo flight journals, the NEEMO 12 Mission Journal, and the Apollo 11 logs, photos, and transcriptions were all used to lay the foundation for how a mission log system should operate. We also reviewed NASA’s Artemis Plan and associated videos and other materials as an inspiration for what the (near!) future of space travel holds, and what modern missions require to ensure they are carried out successfully.

Like all hackathons, the journey began way before the October 2nd, 2021 start date. I came across a Facebook post made by the Canadian Space Agency that said “Space Apps Challenge”. I am pretty sure these are all of my favorite words combined into one thing. I was sold already.

Once the challenges were announced I reviewed them all, but immediately was drawn to the Lunar Surface Operations: Real-Time Collaboration challenge for a few reasons. The first was that it was right in my wheelhouse, but required just enough new technology to push my abilities and learn something new. The second reason was that I grew up dreaming of walking on the moon, and then later, more practically, I started dreaming of building applications that would assist in space missions. Third, I felt like this project is something that I could see in-action someday.

With the project selected, and a few weeks still out, I began planning fundamental architecture and technology choices, and practicing how to integrate them together. I didn’t want to go into the hackathon with zero plan, and with no understanding of the tech I would use. In my search for the ideal architecture I came upon an article about event sourcing. It’s a pattern I had used in the past on large scale systems, and, when reminded of it, it immediately clicked as an ideal foundation for the project.

One week to go--I have no team. I considered ever-so-briefly “flying solo”--but that’s never the path to success. You need a diverse set of voices on any program, project, or mission. The chat is open, so I start looking for team members.

The team I found ended up being amazing. The work throughout the weekend has been so seamless. The best ideas did not come from me. The best work on the flight controller experience did not come from me. Ultimately, it was as true a team effort as any project I’ve worked on. Everyone did amazing work, and I feel blessed that I found each and every one of them.

I’m writing this in the final hours, so you won’t get to hear the end of this story. To know the end, you’ll have to review our project--I really appreciate the time you’re taking to do just that.

• Project Resources - https://2021.spaceappschallenge.org/challenges/statements/lunar-surface-operations-real-time-collaboration/resources
• Artemis Program - https://www.nasa.gov/specials/artemis/
• Event Sourcing Architecture - https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
• Apollo 11 transcript - https://www.hq.nasa.gov/alsj/a11/a11transcript_tec.html

#Moon, #Artemis, #Apollo, #AdLunam, #CommandAndControl, #App, #Cloud, #Azure

This project has been submitted for consideration during the Judging process.