Making e-bike motor control dependable from model to product
An e-bike motor is a physical system experienced directly by the rider: torque must feel responsive and consistent while the software works within converter, battery, sensor, thermal, and communication limits. This work focused on turning motor-control intent and models into maintainable application software, while making the surrounding development process more testable, traceable, and dependable.
Overview
Connecting motor-control behaviour, power electronics, and disciplined software delivery
The project combined application-layer motor-control development with the engineering practices needed to integrate and release embedded software consistently. It covered model integration, interfaces to the motor-control and power-electronics stack, bench validation, unit testing, Automotive SPICE-oriented development, and CI/CD across projects involving approximately 12 engineers.
Focus: E-bike motor control, embedded software integration, and delivery quality
Scope: Application software, model integration, interfaces, verification, and team practices
Bridging control models, embedded application software, and engineering delivery
Owned application-layer motor-control development and the integration boundary between control models, embedded software, and the surrounding power-electronics interfaces. In parallel, helped strengthen the engineering workflow by introducing more consistent unit testing, Automotive SPICE-oriented practices, and CI/CD across projects involving approximately 12 engineers.
Integrated control behaviour into production-oriented embedded software, clarified interfaces between application logic and the underlying motor-control and power-electronics functions, and supported bench-based verification. As Scrum Master for a six-person cross-functional team, also helped coordinate priorities, dependencies, and delivery practices so technical work could move through the team with clearer ownership and evidence.
Collaborators: Worked across controls, embedded software, electronics, power electronics, testing, platform, and product teams, connecting implementation decisions with interface agreements, verification needs, and delivery planning.
Tools & methods
Making rider-facing control behaviour survive real software and hardware interfaces
The software had to preserve intended motor behaviour while operating through real interfaces, signal timing, communication paths, converter limits, battery conditions, and thermal constraints. The development process also had to support traceability and repeatable verification without slowing a cross-functional team working across application software, models, electronics, and testing.
Risks considered: The main risks were model-to-code mismatches, unclear ownership at software interfaces, integration regressions, incomplete test coverage, and control behaviour that appeared correct in isolation but failed when combined with power-electronics limits, sensor signals, or the rest of the product software.
Moving from model integration to repeatable verification and release evidence
Process
Started from control-model and product requirements, then connected the intended behaviour to application-software interfaces and implementation boundaries. Used unit tests and bench validation to catch local regressions, strengthened the path from change to verification through CI/CD, and used Automotive SPICE-oriented practices to make requirements, implementation, and evidence easier to follow across the participating teams.
Key decisions
Treated software delivery practices as part of control quality rather than as separate process work. Favoured explicit interfaces and testable application boundaries so model behaviour could be checked independently from hardware integration, and introduced automation and traceability where they reduced repeated manual effort or made regressions visible earlier.
Delivering motor-control software and a more reliable development system
Delivered application-layer motor-control software, model-integration and power-electronics interfaces, bench-validation evidence, unit-test development, and a more consistent CI/CD and Automotive SPICE-oriented delivery approach. The work also included Scrum Master responsibility for a six-person cross-functional team and process improvements spanning projects involving approximately 12 engineers.
Evidence of more consistent, traceable software delivery
- Delivery scope
- Projects involving approximately 12 engineers
- Team leadership
- Scrum Master for a 6-person cross-functional team
- Engineering practices
- Unit testing · CI/CD · Automotive SPICE
- Product context
- E-bike motor control and power electronics
Reliable control depends on the system around the algorithm
The work reinforced that dependable control is not produced by an algorithm alone. It emerges when model intent, software interfaces, hardware behaviour, verification evidence, and team execution are connected well enough for changes to remain understandable and safe to integrate.
Contact
Interested in the engineering behind this work?
Use the contact page for role conversations, collaboration, project context, or focused technical questions.