Protocol re-engineering
Understanding how systems communicate. Turning observed exchanges, timing and state into documented behaviour and maintainable implementations.
INDEPENDENT ENGINEERING01 — OVERVIEW
Preserve the
capability.
Replace the
dependency.
Useful systems deserve a life beyond the platforms they were built on.
We re-engineer legacy protocols, software and interfaces so that proven equipment and useful capabilities can keep working — without obsolete computers, operating systems or proprietary applications.
Explore the work01 / RETAINUseful equipmentThe capability worth keeping
Existing protocol / interface
02 / RE-ENGINEERA maintainable bridgeUnderstood. Documented. Tested.
Open, documented interface
03 / RECONNECTModern systemsIndependent of the original platform
Keep what works. Understand what connects it.
PROTOCOLS / SOFTWARE / HARDWARE INTERFACESBuilt on observation. Verified against behaviour.
02 — PERSPECTIVEObsolescence rarely
Obsolescence rarely
has a deadline.
A system can keep working long after the ability to maintain or replace it has begun to disappear.
When the knowledge leaves
Technology moves forward, but a working system offers little reason to stop and reconsider it. There may be no clear end date: just older hardware, fewer supported tools, and a shrinking number of people who understand how it all fits together.
As experienced engineers approach retirement, more than documentation is at stake. Years of diagnosis, exceptions and practical judgement become an instinct for what to check and how to respond. A knowledge management system can preserve valuable records, but cannot be assumed to capture all of that experience.
By the time the gap becomes visible, the people best placed to engineer out the dependency may already have left. Recognising that risk while their knowledge is still available creates an opportunity to observe, question, test and replace.
Recover the function, not every constraint
Legacy complexity often reflects the limits of the period in which a system was built. Its architecture may tell us as much about available memory, components and development tools as it does about the function we need today.
Examining the interfaces — inputs, outputs, timing, state and responses to faults — can reveal the behaviour that matters. That evidence gives us a basis for a modern implementation, without automatically reproducing every internal detail of the original design.
The interface is a starting point, not proof of the whole specification. Hidden states, unusual operating conditions and safety requirements still need investigation and validation, ideally with the people who know the system.
03 — PROJECTSOld dependencies.
Old dependencies.
New possibilities.
Our work centres on the interfaces between systems: the places where useful equipment becomes tied to something that can no longer be maintained.
Software independence
Separating a useful function from an obsolete operating system, proprietary application or abandoned development environment.
Interface replacement
Bridging legacy equipment to current systems. Replacing the surrounding interface hardware while preserving the behaviour that matters.
04 — APPROACHEvidence before
Evidence before
assumptions.
A replacement earns trust by behaving correctly. We work from observation through to repeatable tests, keeping the original system as a reference wherever possible.
- 01
Observe
Capture real exchanges, signals, timing and failure behaviour.
- 02
Document
Describe what is known. Keep hypotheses separate from observed facts.
- 03
Reproduce
Build the smallest implementation that explains the evidence.
- 04
Validate
Compare against the original using test benches, fixtures and replay.
- 05
Replace
Remove the obsolete dependency. Retain the tests and understanding.
The deliverable is more than working code. It is an interface that can be understood and maintained.
05 — SIMULATION & TESTSee inside.
See inside.
Stop time.
Test again.
Simulations, emulators and test fixtures bring modern development methods to legacy systems. They make behaviour easier to inspect and experiments easier to repeat, before returning to real hardware.
Building a machine to understand it
One investigation began with a system from the 1960s–1970s, little information online, and original documentation describing the processor and its functions. Building a CPU simulator became a way to learn its machine code: write a program, run it, and observe what happened.
The first version was an HTML file with JavaScript. It grew into a C program, then a simulation of the entire hardware system: disc drives, display systems, serial interfaces and even the bootstrap ROM.
Working through the original CPU’s primitive handkey interface was the established approach. The simulator opened another route to understanding — one that could be shared with other software engineers and used without access to the old machine.
Make behaviour visible and repeatable
Inside a simulation, execution can be paused and the machine’s internal state examined in detail. Engineers can follow an instruction or an exchange, revisit an earlier experiment, and explore behaviour that is difficult to observe on physical hardware.
Test fixtures turn those investigations into repeatable checks: known inputs, controlled conditions and expected responses. Captured exchanges and confirmed observations can become regression cases, preserving understanding as the implementation evolves.
The model remains something to validate against documentation and the real system. Simulation lets more development and diagnosis happen before a hardware session, improving the chance that the first real test is a useful one.
06 — TECHNOLOGIESThe right tool
The right tool
for the interface.
Practical tools for understanding existing systems and building replacements that remain accessible.
- Software & systems
- Python / C / C++ / Linux / Containers
- Embedded & hardware
- Microcontrollers / Serial interfaces / Interface bridges
- Protocols & connectivity
- Serial & network protocols / Service discovery
- Measurement & verification
- Packet captures / Logic analysis / Simulation / Test benches
07 — PROJECT NOTESUnderstanding,
Understanding,
worth keeping.
ARCHIVE IN PREPARATION
Technical write-ups will collect protocol observations, implementation decisions and lessons from the bench.
No notes published yet. The archive will grow as work is documented for public release.