IIoT & Energy
A development platform on which the client builds its product variants itself
For a product family of drive controls, a C++ platform on which the client defines the sequences of its customer applications as a state diagram, generates code from it, builds the firmware and flashes it to the device. AI helps on the way from requirement to diagram, not in the product.
The task
A supplier of adjustment drives to equipment manufacturers delivers a separate control for every customer: different buttons, different motion sequences, different special functions. Until now, each of these variants was a development project of its own, requiring firmware expertise the client did not have in-house, or an external partner for every change.
At the same time, AI-assisted development is changing how a requirement becomes software. The client wanted to take that step without making the safety of a drive depend on a language model. It needed a platform on which it defines the customer-specific sequences itself and turns them into a working device, and which already contains everything that requires specialist knowledge.
The solution
The platform separates what all variants share from what differs per customer. Shared are motor control, position sensing, calibration, storage, radio and Bluetooth, voltage monitoring and the toolchain; all of that sits in the core, in C++ on semf, our software architecture. The only thing that differs per customer is the behaviour: which button triggers what, in which order the drives move, which positions are stored.
That behaviour is a state diagram. The client defines it with StateSmith, the generator produces the C++ state machine from it, the pipeline builds one firmware per behaviour, and that firmware is flashed. No hand-written code is created for a variant, and the core stays untouched. The behaviour of a variant can be reviewed on the diagram; the pipeline covers generated code and integration with the same tests as the core.
AI comes in before code generation: it takes the end customer's requirements and turns them into the draft diagram, which the client discusses with its customer before a single line of firmware exists. The draft is not binding: a responsible engineer at the client reviews and releases the diagram, and only then is code generated. Both sides agree on the diagram, which both of them can read.
We built the platform: the system architecture and the firmware core. The client builds its products on it. Modelling, review and release stay with the client; for a variant, it no longer needs programming work on the firmware core or outside expertise.