IIoT & Energy
A development platform that lets the client build product variants independently
For a product family of drive controls, a platform in C++ on which the client defines the sequences of its customer applications as a state diagram, generates code from it, builds it into 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 ships a separate control for every customer: different buttons, different motion sequences, different special functions. Until now, each variant was a development project of its own, with firmware expertise the client did not have in house, or with an external partner for every change.
At the same time, AI-assisted development is changing how software emerges from a requirement. 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, one that already contains everything demanding 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. What differs per customer is only 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 is flashed. A variant needs no hand-written code, and the core stays untouched. The behaviour of a variant can be reviewed on the diagram; generated code and integration are covered by the same pipeline tests as the core.
AI enters before code generation: it takes up 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 non-binding: a responsible engineer at the client reviews and releases the diagram, and only then is code generated.
We built the platform: the system architecture and the firmware core. The client builds its products on it: modelling, review and release stay in house; programming work on the firmware core and outside expertise are no longer needed for a variant.