A European mission systems integrator designing, industrialising and validating systems for severe and industrial environments. The programme required a computer in an equipment rack to receive live data from a piece of specialist equipment and present it to an operator application, with the timing discipline the source imposes.
The equipment delivered a proprietary serial protocol over an RS422 link that no catalogue acquisition board could read. The application also needed a hardware synchronisation pulse, generated deterministically rather than in software.
Two options existed, and both were bad:
- Buy a board that does not do the job and solve it in software, accepting the timing risk.
- Or commission a clean sheet custom board
That is roughly a year of development, and it also means starting the whole conformity and qualification package again, before anything could ship:
- New CE marking
- New EMC test reports
- New MTBF and reliability calculation, fresh environmental test data
- Driver validation to redo
-
The protocol is specific to the programme: It is not a standard the market supports, so no product roadmap will ever cover it.
-
The timing is not negotiable: A hardware synchronisation pulse has to be generated deterministically, which rules out generating it in the operating system.
-
The integrator could not wait for the equipment: Development and testing had to start before the real source was available on the bench.
-
Schedule risk was the real constraint: A programme cannot absorb a year of board development plus a complete re-certification in order to read one message. The certification package is often the longer pole, not the electronics.
We kept the standard APCIe-1711 and wrote the customer protocol into its on-board FPGA as a dedicated function module, rather than forking the whole design. The board is built around four programmable function modules, so adding a function is a firmware activity, not a hardware one.
Two firmware builds were delivered:
-
A normal mode that decodes the live data stream and generates the hardware synchronisation pulse.
-
A simulation mode that generates protocol frames on the board itself, so the integrator could develop and validate their application without the live equipment on the bench.
The package included Linux drivers, a command line acquisition tool, and a CSV visualisation tool for inspecting captured data.
Every build was verified against a ModelSim test bench and on real hardware, and compiled through a CI pipeline so each release was reproducible. Decoding was then optimised to sustain 4096 values per acquisition cycle, and the write path was reworked to buffer a full acquisition period before writing to disk rather than writing per sample.
- The programme received a working, tested acquisition path in roughly six months from specification to on-site validation, instead of a year of board development.
- Because the base board was untouched, it kept its entire existing conformity and qualification package:
-
- CE marking,
- EMC test reports
- MTBF and reliability data, environmental test data
- Validated drivers across four operating systems
- From 10 to 20 year availability commitment
- The simulation mode removed the dependency on equipment availability, letting integration start months earlier than a hardware-only approach would have allowed.
- The delivered configuration has its own part number and can be reordered for the life of the programme.
- Validation was performed on site at the customer, and the project closed against its specification
-
APCIe-1711 PCI Express counter board, standard catalogue product
-
Custom VHDL function module in the on-board FPGA
-
RS422 interface, proprietary protocol decoding
-
Hardware synchronisation pulse generated on the board
-
Simulation mode firmware, to test without the live equipment
-
Linux drivers, acquisition tool and CSV visualisation tool
-
ModelSim test bench, on-hardware verification, CI pipeline
-
Optimised to 4096 values per acquisition cycle
Off the shelf did not fit. A clean sheet was a schedule risk. There is a third option: when the board is FPGA-based and the vendor owns the firmware, a proprietary protocol becomes a configuration rather than a new product. The customer got a bespoke capability while inheriting the certification, reliability data, availability and reorderability of a catalogue item.
Vous cherchez des conseils ?
Si vous avez des questions sur vos futurs projets, vous pouvez toujours contactez notre équipe d'expert.
