By Simon Roy Co-Founder, Coherent Laboratories
Simon Roy is a Co-Founder of Coherent Laboratories, a new venture aimed at solving the continuous verification challenges teams face when building cutting-edge embedded systems. As a former Staff Firmware Engineer at Tesla, he worked on architecting, implementing, and productionizing motor control algorithms and inverter firmware for the company’s vehicle product lineup.
The transition toward electrification, from electric vehicles to utility-scale battery storage, is characterized by rapid innovation, constantly evolving software, and the mounting complexity of cyber-physical systems. This pushes embedded software engineers to deliver increasingly complex software, faster, while maintaining the engineering rigor necessary to build safety-critical systems. Organizations are therefore rethinking traditional design methodologies and adopting a new paradigm of development.
The traditional V-model of development, an evolution of the Waterfall model, is recognized by its sequential design phases, multi-layered structure, and distinct design and verification stages. It relies on carefully planning what to build, how to build it, and how to test it. The V-model is mandated by some industry regulations as the required state-of-the-art methodology for designing safety-critical systems.
On embedded software systems, the verification phases typically consist of:
01 – Unit testing
The lowest level of testing, focused on the smallest testable units like individual functions or logic blocks for correct implementation.
02 – Integration and system testing
Testing the interfaces and interactions between major subsystems or components to ensure they work together.
03 – HIL/SIL testing
Testing at the component level of the embedded system using Software-inthe-Loop (SIL) or Hardware-in-the-Loop (HIL) test platforms.
04 – Acceptance testing
The highest level of testing verifying complete product compliance.
The V-model allows for design changes when issues are discovered during verification. This process involves revisiting prior design phases, updating all downstream artifacts, and repeating the test sequences linearly. However, identifying design issues late during the verification stage can cause long delays and costly redesigns. Additionally, the V-model’s expectation of a static product definition is misaligned with the dynamic nature of fast-paced environments, and its attempt to design the product correctly the first time, conflicts with the practical aspects of embedded system development. Only through testing on the physical product can the hardware and software design be refined. To address these shortcomings, a hybrid “Agile-V” approach is increasingly being adopted.
Agile-V preserves the V-model’s macro structure and engineering rigor while embedding fast Agile iterations. By quickly getting the product into a workable state, Agile-V facilitates the early discovery of critical software and hardware design issues. Additional features and improvements are incorporated in subsequent iterations, also known as “sprints”.
Agile software organizations implement this process by leveraging the concept of continuous verification. Within a sprint, focused versions of the V-model are executed on individual work items. Once specified, implemented, and tested, these changes are verified against a narrower verification cycle before merging into the codebase. Once a sprint’s feature completion deadline arrives, the codebase is locked into a release state with only critical fixes allowed. Full verification is performed on the combined set of changes, effectively closing the broader V-model for the given sprint.
On embedded systems, failure to follow these principles can result in costly production delays, product recalls, and inoperable hardware. Engineering teams must adopt the right culture, incentives, and tooling for the Agile-V process to be successful.
ADOPTING AGILE-V REQUIRES ADHERENCE TO KEY PRINCIPLES:
- Keep requirements, design, and traceability up-to-date: While the Agile-V allows for direct changes to the implementation, component owners must ensure that all relevant design artifacts stay up-to-date despite the sprint’s incentive to focus on delivering the immediate features. This avoids stakeholder confusion and process non-compliance.
- Expand and maintain test case coverage: Continuously developing and adapting the product’s software also means adding and updating test cases according to the required coverage metrics.
- Maximize test automation: Continuous verification requires a highly automated testing infrastructure. Executing a larger share of the overall verification prior to merging reduces the likelihood of product regressions discovered late in the sprint. Manual testing scales poorly under this paradigm.
Coherent Laboratories helps teams maximize their test coverage and test automation by automatically generating test cases on HiL and SiL platforms. Our AI agents use the requirements and a deep understanding of the device under test to generate and maintain traceable test cases. The time spent on adding and updating tests is saved, allowing software engineers to shift their focus toward requirements, design, and implementation.
