Closing the loop: SCAPE requirements move towards final validation
A successful technology project is not only about developing innovative components. It is also about making sure that the components, subsystems and tests developed over several years still respond to the needs and requirements that originally shaped the system.
In SCAPE, this overseeing role is responsibility of Work Package 2, led by AVL-TR, who continues the supervision as the project moves towards its final validation activities.
WP2 has provided the systems-engineering backbone for the project. Its task has included the definition of the collaboration methodology between partners, representative electric-vehicle use cases, system-level requirements and their decomposition into lower-level technical requirements, together with the test cases needed to verify them. The team has also produced successive gap analyses to check how the evolving technical implementation compares with the requirements originally established.

The overall process is structured around a V-cycle tailored to SCAPE. On one side of the V, vehicle and system needs are progressively translated into more detailed requirements for the architecture and its individual elements. On the other, components and subsystems are integrated and tested, allowing the project to verify whether the resulting solution fulfils those requirements.
As development has progressed, this process has necessarily become iterative. Technical decisions made in one work package can have consequences elsewhere: an updated converter design, a new interface, a change in a switching-cell implementation or a constraint emerging during validation may require lower-level requirements or associated test cases to be reconsidered.
For this reason, AVL-TR has remained closely involved in the activities of the other technical work packages even after the principal requirements-definition tasks were completed. WP2 experts continue to review technical developments and participate in cross-WP exchanges to identify changes that may affect the requirements chain and assess their wider impact.
This activity feeds directly into the project’s final gap-analysis and change-management work. The aim is to compare the requirements with the system that has actually been implemented and the validation activities now being carried out, identify any remaining discrepancies and, where necessary, manage changes in a controlled and agreed way.
Rather than treating the original requirements as a static checklist, the process ensures that they remain connected to the technical reality of the project while preserving traceability across the complete system.
As SCAPE approaches its concluding validation activities, this final consistency check will therefore help close the V-cycle: linking the project’s original ambitions and use cases to the switching cells, converter architecture, controls, integrated powertrain and test results developed across the consortium.

