Building Trusted Firmware for EV and Connected Mobility Applications

The integration testing module called test_battery_and_motor.c demonstrates first sets up a state with charging off and the motor enabled. Then it initiates charging and verifies that the motor goes to the disabled state.

The module then simulates an overvoltage condition, verifies that an attempt to initiate charging fails, and that in this case the motor can be enabled because the battery isn’t being charged.

Automation and Evidence Generation

The next section discusses how execution of unit and integration tests becomes automatic and consistent when they’re incorporated into a CI/CD pipeline.

And later it will be demonstrated how unit and integration test results become auditable evidence for:

• Functional-safety cases under ISO 26262
• Cybersecurity requirements under ISO/SAE 21434

CI/CD and Regression Testing

Manual build processes and ad-hoc testing inevitably lead to inconsistent quality. Automated CI/CD pipelines ensure that the same steps are executed consistently for every build.

These pipelines automate firmware building and testing using platforms such as Azure DevOps, Jenkins, or GitLab CI.

CI/CD is also highly practical for regulatory compliance, although not mandatory.  It’s a common approach to maintaining the consistent and thorough evidence collection demanded across repetitive audit cycles, and throughout an EV product’s evolution over its lifetime.

In practice, CI/CD is often referred to simply as CI. Indeed, continuous delivery alludes essentially to readying a product automatically for release, but it’s primarily in continuous integration that product development and evidence generation primarily occur.

Pipeline Structure

A typical CI pipeline includes:

• Static analysis (with MISRA reporting)
• Firmware build
• Unit testing
• Integration testing
• Artifact packaging

The artifact package contains all outputs relevant to compliance audits, including firmware images, manifests, metadata, and test reports.

Regression Testing

Regression testing is the primary purpose of CI. Each time a new build is created, all tests — static analysis, unit tests, and integration tests — are rerun.

Regression refers to the unintended introduction or reintroduction of defects following changes such as bug fixes or enhancements. Automated regression testing ensures that new updates don’t break existing behavior.

When a defect is discovered in the field, its fix must include a corresponding regression test. And naturally it will, since it’s the CI pipeline that produces a new build from the corrected code.

Keeping everything in perspective, we should point out that automatic regression testing doesn’t eliminate the need for manual regression testing. For example, manual testing must still be used when proof of human safety depends on the user’s experience, such as by their interaction with a user interface, or when automatically obtaining feedback of a test’s result is not practical.

Furthermore, human maintenance of the automated regression testing is necessary; for instance, adding new unit and integration tests to support new product features.

The next section will explain how to organize regression test data and results into traceable compliance-ready evidence.

Traceability and Compliance

Traceability is what ties everything together. It links requirements to design, code, and tests. These traceable links form the core of compliance evidence. Traceability supports:

• Functional-safety audits (ISO 26262)
• Cybersecurity audits (ISO/SAE 21434)
• ASPICE process assessments

Without traceability, a bug may be missed because there’s no clear link between a requirement and a test verifying the requirement’s implementation.

Regulatory compliance auditors need evidence that every safety and security requirement has been implemented and verified. Traceability makes audits systematic by clearly demonstrating coverage of requirements.

Requirements Traceability Matrix

The primary tool for documenting traceability is the Requirements Traceability Matrix (RTM). An RTM links each requirement to:

• Its implementation in code.
• The test cases that verify it.
• The results and associated artifacts.

An RTM capturing the example tests that were demonstrated previously would look something like the following table.