AI-enabled ECU validation on AWS using Corellium Atlas virtual ECUs

How Infosys and Corellium built an AI-powered firmware validation pipeline that eliminates hardware bottlenecks in automotive software development

Automotive firmware teams face a structural bottleneck: physical electronic control unit (ECU) hardware doesn’t scale at the pace of software development. Waiting for hardware access creates delayed test cycles, late defect detection, and limited parallel coverage across Software Defined Vehicle (SDV) programs. Infosys and Corellium addressed this by building a validated solution on Amazon Web Services (AWS) that runs production firmware on cloud-hosted virtual ECUs with Amazon Bedrock Agents acting as the AI orchestration layer integrated directly into the pipeline from the start.

The solution runs the same unmodified ELF binary intended for physical deployment on a cloud-hosted virtual NXP S32K344 using Corellium Atlas. AWS CodePipeline automates every stage from build through validation. Amazon Bedrock Agents evaluates every test result, makes autonomous pass/block gate decisions, logs structured failure tickets to Jira or GitHub Issues, and optimizes compute allocation; all without manual intervention between pipeline stages.

Solution overview

The solution integrates three layers into a single automated pipeline:

1. Virtual ECU: Corellium Atlas hosts a cloud-based NXP S32K344 device model with instruction-set simulation for the Cortex-M7, virtual FlexCAN/CAN-FD, and SIUL2 GPIO peripherals. Production firmware runs as-is; no physical hardware required.
2. AWS Continuous integration and delivery (CI/CD): CodePipeline orchestrates build, static analysis, binary validation, artifact storage in Amazon Simple Storage Service (Amazon S3), and deployment to the virtual ECU through an event-driven AWS Lambda function.
3. Amazon Bedrock Agents: An AI orchestration layer that’s a first-class pipeline stage, not a post-processing add-on. It makes quality gate decisions, auto-logs structured failure tickets with AI-generated root cause analysis, and right-sizes compute resources based on historical build data.

The use case is a geofence-based headlight high-beam assist feature, validated with CAN-driven inputs and GPIO-driven outputs across positive and negative test scenarios. The following figure shows the complete solution architecture, including the Amazon Bedrock Agents AI quality gate stage at the end of the pipeline.

Figure 1 – Solution architecture

How the pipeline works

A code commit triggers the pipeline, which carries the firmware through six automated stages before any human reviews a result:

1. Build: AWS CodeBuild compiles the firmware for the NXP S32K344 using the S32 toolchain, runs static analysis (cppcheck, MISRA), validates the ELF binary for linker correctness and symbol integrity, and runs security scans. The encrypted, versioned artifact is stored in Amazon S3.
2. Deploy: An event-driven AWS Lambda function retrieves the ELF from S3, fetches the Corellium API token from AWS Secrets Manager, and deploys to the virtual ECU over HTTPS.
3. Validate: The virtual NXP S32K344 boots the firmware, receives CAN message inputs, and verifies GPIO outputs against expected behavior; covering positive scenarios (high-beam on/off, geofence enable/disable) and negative scenarios (malformed CAN messages, out-of-range values).
4. AI quality gate: Amazon Bedrock Agents receives the structured JSON test output from Lambda, evaluates it against defined success criteria—pass rate thresholds, GPIO output conformance, CAN message accuracy—and issues a PASS or BLOCK decision. PASS promotes the firmware automatically. BLOCK halts the pipeline and immediately creates a structured ticket in Jira or GitHub issues containing the test details, failure logs, firmware version, and AI-generated root cause analysis. There’s no manual log review required.

Throughout all stages, Amazon CloudWatch collects logs and AWS CloudTrail records all API activity, providing the end-to-end audit trail required by automotive cybersecurity frameworks such as ISO 21434.

Amazon Bedrock Agents: AI orchestration built into the pipeline

Amazon Bedrock Agents is provisioned as a declared pipeline stage and configured with three action groups that run autonomously after every virtual ECU validation. The following figure shows how it connects to the pipeline and manages the version promotion flow across three firmware versions (V1.0, V1.0.1, V1.0.2).

Figure 2 – Quality gate, issue logging, resource optimization, and Amazon Bedrock Agents

After each virtual ECU validation run, Amazon Bedrock Agents evaluates structured test output against configured success criteria. It can weigh multiple signals simultaneously and flag borderline results for human review. It maintains a structured record of every gate decision for audit traceability. The criteria are configured once; the agent applies them consistently across every firmware build.

Automated issue logging

On a BLOCK decision, Amazon Bedrock Agents invokes an issue-logging action group that creates a structured ticket in Jira, GitHub Issues, ServiceNow, Azure DevOps, or any API-accessible tool. Each ticket includes test case details, failure logs, firmware version, and AI-generated root cause analysis. Engineers receive an actionable ticket, not raw logs, when a failure is detected.

Resource optimization

Amazon Bedrock Agents analyzes historical build patterns and CloudWatch resource consumption data to right-size CodeBuild instances for each pipeline stage, schedule validation runs during lower-cost periods and consolidate parallel workloads. For programs running multiple firmware variants across several ECU configurations, this ongoing optimization reduces cloud spend without manual tuning between sprints.

Amazon Bedrock Agents and responsible AI

For automotive development workflows, autonomous AI gate decisions require clearly defined boundaries and human oversight. Amazon Bedrock agents are configured within the pipeline to enforce four key controls:

1. Human-approval fallback: Borderline gate results—where test outcomes fall within a configured confidence margin rather than a clear pass or fail—are automatically routed to a human reviewer before any promotion or block decision is applied. Amazon Bedrock Agents don’t act autonomously on ambiguous outcomes.
2. Gate decision audit log: Every gate decision—PASS, BLOCK, or escalated to human review—is recorded with the full reasoning trace, test inputs, criteria applied, and timestamp. This log is stored in Amazon S3 and indexed by CloudTrail, providing the traceability record expected under automotive cybersecurity and functional safety frameworks.
3. Confidence threshold enforcement: Success criteria thresholds are defined in the agent configuration and enforced consistently across every build cycle. The agent can’t lower or bypass these thresholds autonomously; any criteria change requires an authorized configuration update and is captured in CloudTrail.
4. No autonomous action on safety-critical failures: Any failure that triggers a safety-relevant test case—such as a GPIO state mismatch on a critical output—is categorized as a mandatory human-review escalation, not an automated BLOCK. The pipeline halts and requires explicit engineer sign-off before the build can be resubmitted.

Measured outcomes

The solution delivered the following results during the validation engagement:

1. Hardware dependency eliminated: Firmware validation runs on demand in the cloud at any pipeline stage, with no physical ECU required.
2. 70% reduction in validation cycle time: Automated build-to-result cycles replaced manual flash-and-test workflows. Parallel firmware variant runs execute concurrently without hardware queue contention.
3. Failure-to-ticket reduced from minutes to seconds: Amazon Bedrock Agents auto-creates structured Jira or GitHub Issues tickets on BLOCK, eliminating manual log review entirely between validation and developer assignment.
4. Zero undetected build regressions: AI-driven gate decisions caught all functional failures across three firmware versions—V1.0 (deployment blocked), V1.0.1 (functional failure blocked), V1.0.2 (production ready, promoted)—before any reached downstream stages.
5. Three-fold test coverage expansion: Negative scenarios (malformed CAN messages, out-of-range GPIO values) are included by default; scenarios that are impractical to run at volume on physical rigs.
6. Full audit trail for ISO 21434: CloudTrail and CloudWatch provide end-to-end traceability from code commit through validation result, meeting automotive cybersecurity documentation requirements.

The Corellium Atlas virtual ECU

The following figure shows the three-layer architecture of the Corellium Atlas virtual ECU. The same production ELF binary runs unmodified at the application layer; this isn’t a conceptual simulation. Virtual device drivers—FlexCAN/CAN-FD, SIUL2 GPIO—and a full NXP S32K344 device model with Cortex-M7 instruction set simulation sit beneath it, all managed through Corellium’s REST API and web console.

Figure 3 – Corellium Atlas virtualized ECU stack

Security architecture

Security is embedded at every layer from initial provisioning, not added afterwards. Key controls include:

1. AWS Identity and Access Management (IAM) least-privilege roles separate build, deployment, and monitoring permissions with no cross-boundary access.
2. Secrets Manager stores Corellium API tokens dynamically; no credentials are stored in pipeline definitions or code.
3. AWS Key Management Service (AWS KMS) encrypts firmware artifacts at rest in Amazon S3 (SSE-KMS) and all secrets in Secrets Manager.
4. Amazon Virtual Private Cloud (Amazon VPC) with a NAT gateway controls all outbound traffic to Corellium Atlas over HTTPS with token-based authentication.
5. Build-stage validation includes static analysis (cppcheck, MISRA), security scanning, and ELF binary integrity checks; defects are caught before any deployment to the virtual ECU.
6. Amazon S3 artifact versioning supports full build reproducibility, rollback capability, and historical firmware tracking across all program variants.

Get started

This solution is available now through the AWS Automotive partner ecosystem. Infosys and Corellium can deploy a production-ready virtual ECU validation pipeline into an existing AWS account—scoped to specific ECU targets, firmware toolchain, and issue-tracking tools—in days, not months.

Contact your AWS account team to schedule a solution workshop and see the pipeline running against your firmware. Corellium Atlas is available through the AWS Partner Network, and the full pipeline—AWS CI/CD stages, Amazon Bedrock Agents quality gate, and security controls—deploys using CloudFormation into any AWS Region.