ASTERIX Feed Suite. Problem to Lessons.
A transmitter and receiver for surveillance data feeds in ASTERIX, the open EUROCONTROL format for exchanging surveillance data. It is built for Windows, Linux and 2 single-board computer cards. This page follows it through the life cycle, from the problem to what I learned. AI wrote the code. I set the requirements, designed the checks and decided what passed.
All data on this page is simulated · figures are from bench tests on simulated dataDoes Every Record Arrive?
A surveillance feed is a steady stream of numbered records. If a feed tool only proves it starts up and reports the right version, nobody knows whether every record really gets through, in order, on every platform it is packaged for. A dropped record makes no noise. It just goes missing.
So the question was not “does it run?” but “can I show, with numbers, that a feed sent from each package arrives complete?”
Five Requirements, Each With a Check
Restated for this page from the suite’s evidence summary. Each has a stated verification method: I inspection, A analysis, D demonstration, T test.
| ID | Requirement | Method | Result |
|---|---|---|---|
| FS-R1 | Every release package (Windows, Linux, single-board computer card) shall carry records end to end, not just report a version. | T | 11 of 11 feeds passed |
| FS-R2 | The receiver shall count records and report any gap in the sequence. | T | 196,852 records, 0 gaps |
| FS-R3 | The receiving card shall boot straight into receiving, with no set-up steps. | D | Met on bench hardware |
| FS-R4 | Every fault found shall be recorded with its cause and how it was found. | I | 15 faults across 5 releases |
| FS-R5 | All test data shall be simulated. No operational data shall be used. | I | Met |
Two Blocks and a Check
The transmitter and receiver are kept separate, so each can be tested alone and then together. A sequence check sits after the receiver and counts every record and gap. The defect record collects every fault, wherever it was found.
The orange ring marks the interface between transmitter and receiver. That seam turned out to matter more than either block.
AI Built It. I Briefed and Reviewed.
- Language: Python, packaged separately for Windows, Linux and the single-board computer cards.
- Brief: each change started from a written brief to the model: the purpose, the record format, the requirement it serves and how it would be tested.
- Review: I read each change against the requirement it serves. Passing its own tests was not enough on its own to accept it.
- Releases: 5 releases up to version 2.7.7, with every fault fixed along the way written into the defect record.
Four Levels of Testing
Watch the Sequence Check Work
This runs in your browser with made-up records. Press “Drop a record” to lose one in transit and watch the check catch it.
What the Evidence Says
These figures come from the suite’s own test and defect records, run on simulated data. They show the requirements were met in my tests. They are not an independent assessment.
What a Defect Record Entry Looks Like
- Defect
- SIM-D07 (illustrative, not a real entry)
- Seen
- The receiver reports one gap after a long simulated run, but the transmitter log shows every record sent.
- Found by
- The end-to-end sequence check. Transmitter and receiver tests both passed on their own.
- Cause
- The two sides disagreed on where the sequence number wraps back to zero.
- Fix
- One wrap rule written into the interface requirement, plus a test that crosses the wrap point.
- Lesson
- The fault lived in the seam, not in either part.
What This Is Not
- A prototype tool. It is not certified and is not part of any formal safety case.
- Verified by my own tests and reviews. No independent body has assessed it.
- Tested on bench hardware with simulated data only. No operational data was used.
- A passing test is evidence, not proof. The test set is only as good as the cases I thought of.
- The demo and the defect entry on this page are illustrations. They show the method, not real results.
What I Would Tell the Next Project
- Test the interface on purpose. Most of the 15 faults sat at the seam between 2 parts that had each passed their own tests.
- Make every package carry data. A version string proves it starts. Only records through the whole chain prove it works.
- Count, don’t eyeball. A sequence check turns “looks fine” into a number someone else can check.
- Keep the defect record from day one. Writing down how each fault was found shows where the testing is weak.
- The AI is fast, not careful. Code that passes its own tests can still be wrong end to end. Deciding what correct means stays with me.