An industrial controller built on an RTOS from 2006 needed a CRA-ready audit trail. The port took under a working week of engineering, most of it proven before the hardware was involved, and the hardware still taught the library something.
From December 2027 the Cyber Resilience Act applies to every product with digital elements placed on the EU market, including those built on an operating system that left its vendor’s current range long ago. Earlier this month I ported SolidSyslog to one of them: VxWorks 6.4, inside a client’s industrial controller.
Few readers will be running VxWorks 6.4. What matters is the method, which applies to whichever legacy RTOS your own products are built on.
The timing
The first commit was on 30 September. The first record reached a syslog collector on 3 October, and the work was merged into SolidSyslog on 10 October. Across those eleven days the engineering came to under a working week, fewer than 40 hours. The library’s core changed very little, and most of those changes were lessons worth keeping for every platform.
What was built
In this integration SolidSyslog is more than a UDP sender: a buffer absorbs start-up bursts, a store on disk keeps records through a power cut, and tested UDP and TCP senders deliver them to the collector.
How it was done
The work went in four stages, each building confidence before the next.
A simulation environment first. Time on real hardware is scarce, and every test run on it is slow. Wind River supplies a board support package for a board that the QEMU emulator models, so the first goal was a VxWorks 6.4 image booting under emulation with SolidSyslog linked in. That took a day, including two fixes to the board support package before it would work with an emulated disk.
Unit tests on an ordinary PC. The VxWorks platform code was written test first against stand-ins for the VxWorks API, so it builds and runs its tests on Linux or Windows without a Wind River licence. Its 330 tests cover every line and every reachable branch.
The existing behaviour tests, unchanged. SolidSyslog has a suite of behaviour scenarios that every supported platform must pass against a real collector, from reconnection to replay after a power cycle. The same 41 scenarios now run against VxWorks under emulation. That is the main reason the port was quick: the definition of “working” already existed.
Integration on the client’s hardware. Only then did the library go into the controller. SolidSyslog is written in C99 and the product compiles as C89, so the library builds in its own dialect within the product’s build, and its public headers compile as C89. The product’s own code was not changed to suit it.
What the hardware taught the library
Emulation found most things, but not everything. At a cold start, with nothing yet in the network stack’s address cache, the first fourteen records of a start-up burst never reached the collector, although every send reported success. The VxWorks 6.4 stack holds only the latest packet while it looks up the next hop, and silently drops the rest. The emulator answers those lookups instantly, so no amount of simulation would have shown it.
The VxWorks platform code now waits for the lookup before sending, and reports a failure if it takes too long, so the record stays in the store. The more useful change went into the core. “A datagram send reports success only once the next hop is resolved” is now part of the contract every platform must meet, and the others are being brought into line.
What is left to the product team
Once the integration has been proven on their hardware, adding an event to the audit trail is a call to SolidSyslog_Log(...) wherever the product has something to record. Deciding which events those should be is the harder question, and one I discussed in Is a defrost command a security event?
What it costs
On the client’s PowerPC controller, built with the Wind River compiler optimised for size, the loadable image grew by about 42 KiB and static RAM by about 20.5 KiB. PowerPC code from that older compiler is less compact than ARM code from a current GCC, so these figures are higher than those for the ARM worked example on the product page.
Most of that RAM is a buffer sized to absorb a 40-event start-up burst at the maximum message size; without it, the library’s own static RAM is about 1.7 KiB. The store on disk is capped at about 244 KiB, set by how many events had to survive an outage. Both are configuration, not fixed costs.
Who owns what
The port was done for the client under a proof-of-concept agreement, which set out how the work would be done and who owns what. COSOSO owns SolidSyslog, including the VxWorks 6.4 platform code and its tests. The client owns its modified board support package, its application and every change made to it. The integration was done on a PC the client provided, with their build environment, and none of the client’s code left that machine. That is why the board support package fixes are described here but not published.
Crafted with AI
This port was crafted with AI. It was not vibe coded. The repository shows this openly: Claude, Codex, Copilot and CodeRabbit appear alongside me as contributors. AI was of most benefit in the build, test and git work. In the code it worked in small, test-first steps, each of which I reviewed before it went in, and every pull request was reviewed by AI before it was merged, several by more than one tool.
The checks that do not depend on AI all remain: three compilers, sanitizers, coverage gates, MISRA analysis with every deviation recorded, and the behaviour tests on every platform. My view is that the industry should now expect software engineers to use AI, and should ask how its output is checked. I will write more about that.
Next
The VxWorks 6.4 support is on SolidSyslog’s main branch and will be in 0.3.0, due at the end of October. TLS was out of scope for this client, so it carries syslog over UDP and TCP.
If your products run on an operating system or network stack that SolidSyslog does not yet support, a port is a smaller job than you might expect. Where COSOSO keeps ownership of the port, its cost can be offset against the licence, agreed case by case. Any organisation can evaluate SolidSyslog free under the PolyForm Internal Use licence, with no time limit. Start from the product page or talk to us about your product.
The newsletter carries release announcements and occasional notes like this one.
Follow SolidSyslog
Get the 1.0.0 release announcement and occasional CRA compliance notes. Low volume, unsubscribe anytime.
