vECU

Why Embedded Software Testing Can No Longer Rely on Traditional Methods

Why Embedded Software Testing Can No Longer Rely on Traditional Methods

FASTVLABS TECH INSIGHT

Why Embedded Software Testing Can No Longer Rely on Traditional Methods

FastVLabs: ISS-Based Embedded Target Virtualization Solution

In industries where safety and reliability are top priorities, such as automotive and aerospace, software testing must be precise, repeatable, and reproducible.

Yet many development environments still depend heavily on physical hardware. When equipment delivery is delayed, testing schedules slip. Security testing may also be postponed due to insufficient simulation environments, while repeated tests often require manual execution and consume substantial time.

At the same time, international standards such as ISO 26262, ISO/SAE 21434, DO-178C, and DO-326A increasingly require both functional safety and cybersecurity assurance, making it more difficult to respond effectively with conventional testing methods.

Development teams now need environments that enable automated testing from the early stages of development without waiting for physical hardware. This is why software testing based on full embedded hardware virtualization is gaining attention.

❌ Why Are Traditional Testing Methods Reaching Their Limits?

1. Hardware Dependency

  • Testing is delayed until physical ECUs or aerospace system modules are available.
  • Every change may require physical equipment to be reconfigured.

2. Limited Test Coverage

  • Functional safety tests are mandatory, but some scenarios such as Fault Injection are difficult to implement repeatedly in physical environments.
  • Boundary conditions and security threats are difficult to simulate without a virtual environment.

3. High Cost and Time Requirements

  • Equipment setup, maintenance, and repeated execution require significant resources.
  • Hundreds or thousands of tests may be required for standards such as ISO 26262 and DO-178, significantly increasing cost and time.

Automotive – The Dual Pressure of ISO 26262 and ISO/SAE 21434

As software directly controls critical vehicle functions, the automotive industry faces increasingly stringent requirements for both functional safety and cybersecurity.

ISO 26262 requires repeated testing of scenarios such as Fault Injection and Boundary Tests depending on ASIL level, making automation and reproducibility essential.

ISO/SAE 21434 requires lifecycle cybersecurity testing, including threat modeling and security scenario testing from the early stages of development.

As a result, automotive software now requires a testing strategy that satisfies both functional and security requirements.

Aerospace – Beyond DO-178C to DO-326A

Software is also playing an increasingly important role in the aerospace industry. Complex control logic, platform commonality, and in-service security response are making software-centric systems essential.

This is particularly true for UAVs and UAM systems, where autonomous flight and remote control increase software dependency and require systems to make decisions and recover autonomously.

While DO-178C and DO-254 have traditionally been used to demonstrate functional safety, organizations must now also address system security requirements through standards such as DO-326A, DO-355, and DO-356A.

Ultimately, Full Virtualization + Automation Is the Answer

RequirementLimitations of Traditional MethodsNew Approach
Rapid Repeat TestingHardware delays and equipment dependencyVirtualization-based simulation environment
Security Threat ValidationDifficult to reproduce attack scenariosAutomated attack simulation
Broader Test CoveragePhysical constraints limit scenariosSafe implementation in virtual environments
Certification SupportManual logs and limited reproducibilityAutomated reporting and repeatable test structures

Building a Next-Generation Test Environment with FastVLabs

FastVLabs is a Level 4 full virtualization-based testing platform designed to support this transition.

FV
  • Execute real binaries without modification (Real Binary Execution)
  • Fault Injection and reproducible testing for ISO 26262 / DO-178 compliance
  • Automated security test scenarios based on ISO/SAE 21434 and DO-326A
  • CLI-based automation for integration with CI/CD testing workflows

Conclusion: Testing Is Becoming Part of the Design Process

Testing is no longer a procedure that happens only after development; it must be integrated from the design stage.

In an era where certification and commercialization require evidence of both functional safety and cybersecurity, testing cannot be postponed until the end.

Not “test later,” but “test early, automatically, and virtually.”

FastVLabs can be an effective starting point for that transition.

Source | COONTEC, ES Business Team

Back to insights