UAS Sustainment Workbench

A tool you run on your own machine to keep the maintenance and operations records of a small civil unmanned aircraft fleet. It reads the flight logs, counts what each aircraft and each part has used, and says what is due and why.

Live demo, synthetic data, nothing to install: https://tornidomaroc-web.github.io/uas-sustainment-workbench/

In one minute

What it does.

• It reads flight logs in the ULog (.ulg) format of PX4 and the DataFlash (.bin) format of ArduPilot. Each log becomes one flight record: flight time, arm cycles, landings, battery energy and the faults the autopilot reported. A value a log cannot give is marked not known, with the reason.
• It keeps a maintenance ledger of work orders, components and inspections. An entry, once written, is never changed or removed. A correction is a new entry that supersedes the old one, which stays in the history.
• From the logs and the ledger it computes a due list and a board state for each aircraft: serviceable, serviceable with deferred defects, unserviceable, in maintenance, AOG, or not known. Every state but serviceable comes with its reason in a sentence.
• It writes a "Draft records summary for the operator's own review" for one aircraft or for the whole fleet.

Who it is for. An operator who must keep maintenance and operations records. One example is UAS.SPEC.050(1)(g) of Regulation (EU) 2019/947. It asks the operator to keep records of (ii) the maintenance activities on the aircraft and (iii) information on its operations, including unusual occurrences, each for at least 3 years. The summary sets what the workbench holds against those points. It holds no (g)(i) training records, and the summary says so. For (iii) it holds the flight records and what they show as unusual, but no occurrence report written by a person, so that point reads partly at most. The code is also here for open-source maintainers to read and reuse, and for anyone reviewing how it was built.

How it works.

• Board states are computed from the logs and the ledger on every read. None is typed in or stored.
• It compares consecutive logs of one aircraft with the autopilot's own lifetime counter and reports flight that no log covers. On a public research dataset it finds "355 s of flight on aircraft alfa-fixed-wing is not covered by any log".
• Every entry and flight record is linked into a hash chain as it is written. uasw verify says whether the chain is intact. Given a head you kept from an earlier run, it says whether the records are unchanged since then. It never says they are true.
• The summary marks each point with one of four statuses: supported by these records, partly, not evidenced by this workbench, or not known. It decides nothing. The authority decides.
• Every aircraft, flight, component and work order is marked synthetic or real. The seven synthetic aircraft of the demo fleet describe no real aircraft.

Try it in a few minutes. You need git and Python 3.12 or later; python --version says which Python you have. Some Linux and macOS systems ship an older one, name the command python3, or keep the venv module in a system package of its own: there, install 3.12 or later and make the environment with the one you installed, by the name it has there, such as python3.12 -m venv .venv, in place of the third line below; python3 can still be the older one. Once the environment is active, python is its own. Every line works in bash, cmd and PowerShell, one at a time, except the line that activates the environment, which differs by shell. Past the shell names beside those, no line carries a comment: cmd has none, and would pass the words after # to the command.

git clone https://github.com/tornidomaroc-web/uas-sustainment-workbench
cd uas-sustainment-workbench
python -m venv .venv

Activate it with the line for your shell, then run the rest in that same window:

. .venv/bin/activate              # bash or zsh on Linux or macOS
. .venv/Scripts/activate          # bash on Windows
.venv\Scripts\activate.bat        # cmd
.venv\Scripts\Activate.ps1        # PowerShell

If PowerShell answers that running scripts is disabled on this system, use cmd for these steps. Then, from the clone's folder:

python -m pip install -e .
uasw seed
uasw records SYN-04 --out records.html
uasw verify
uasw serve

uasw seed puts the demo fleet in the store: 7 synthetic aircraft plus 2 real ones from public logs. uasw records writes a draft records summary of SYN-04 to records.html; open it in a browser. uasw verify checks the write journal and prints its head. uasw serve runs the HTTP API until Ctrl+C; open http://localhost:8000/docs in a browser meanwhile.

The store goes to data/local/fleet.sqlite, which git ignores. If uasw is not found, or the system blocks it, python -m uas_workbench.service.cli is the same command, with the same arguments: python -m uas_workbench.service.cli seed.

Your own logs, in a store of their own. Without --db, every command uses data/local/fleet.sqlite, the store uasw seed fills with the demo fleet, and uasw serve fills too when it finds it empty. A log ingested there sits beside those nine aircraft in every list and in the fleet summary. Give your own logs another file and name it with --db, before the command, every time:

uasw --db data/local/own.sqlite ingest my-aircraft tests/fixtures/alfa/2018-07-30_16-30-14.bin
uasw --db data/local/own.sqlite records my-aircraft --out own-records.html
uasw --db data/local/own.sqlite verify
uasw --db data/local/own.sqlite serve

This is the beginning of the README. Read the rest at the original. Read the full README ↗