Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing!
Get the Details »
WEBINAR
AI is transforming every stage of embedded software development, from writing code and analyzing defects to automating verification and improving software quality. It’s becoming integral to the embedded products we rely on; autonomous vehicles, industrial automation, medical devices, industrial robots, aerospace, and more.
These advances promise significant productivity gains, but they also raise a harder question: How do we know when to trust the result?
Can we trust AI-generated code? AI-generated tests? An automated fix? What about an AI model trained on incomplete data or operating in a situation it has never encountered?
Join Arthur Hicken, Parasoft evangelist, as he hosts an interactive discussion with Chris Rommel, executive vice president at VDC Research, and Ricardo Camacho, director of product strategy at Parasoft. Together, they’ll explore how engineering organizations can responsibly integrate AI into embedded software development while maintaining confidence in the software and intelligent systems they deliver.
Drawing on real-world engineering examples and practical experience, the panel explores:
The panel also discusses emerging safety standards like ISO/PAS 8800 and how to build confidence for the next generation of AI-enabled embedded and safety-critical systems.
AI is changing embedded engineering in two fundamentally different ways.
The first is AI for engineering. Generative AI and large language models (LLMs) can help developers write code, generate tests, remediate defects, analyze results, and automate other development activities.
The second is AI in the product. Machine learning and other AI models increasingly influence or make decisions inside vehicles, robots, medical devices, industrial equipment, and other embedded systems.
Both require trust, but the verification challenges are different. With AI-generated software, engineers need evidence that the resulting code, tests, or fixes are correct. With AI operating inside a product, engineers must also account for uncertainty, incomplete data, unexpected conditions, and situations outside the model’s experience.
In a safety-critical product, trust cannot be based on the fact that a model has performed well in the past. It has to be designed into the system and supported by evidence.
Traditional software is largely deterministic. When engineers identify a defect, they can locate the problem, correct it, and run tests to demonstrate that the fix behaves as expected.
AI introduces another challenge. An AI component can produce an inadequate result without experiencing a conventional software failure. Its implementation may operate as designed, yet the model may still misinterpret a situation because of limitations in its training data, assumptions, or ability to generalize.
Engineers must therefore consider AI insufficiency as well as traditional software failure.
AI-generated code deserves the same scrutiny as any other code entering an embedded software project.
Whether code is written by a senior engineer, a new developer, or generated by an AI assistant, it should pass through established verification practices:
AI can also participate in verification by helping remediate static analysis findings, generate test cases, and identify coverage gaps.
But the principle remains the same: AI can propose. Verification must prove.
Deterministic analysis, testing, traceability, and human review provide the evidence needed to determine whether the AI-generated result is acceptable
The same principle applies when AI becomes part of the product.
An AI model should not be expected to make every high-impact decision correctly under every possible condition. Engineering teams need safeguards around the model that can detect, constrain, or mitigate unexpected behavior.
These protections may include input validation, redundant sensors, plausibility checks, output limits, safe fallback behavior, runtime monitoring, and human intervention paths.
The objective is not to prove that an AI model will never produce an incorrect result. It is to design the surrounding system so that an inadequate AI result does not automatically become hazardous system behavior.
This distinction is becoming increasingly important in emerging AI safety standards.
ISO/PAS 8800 addresses safety and AI in road vehicles and recognizes that engineers must consider more than conventional component failures. AI systems can exhibit performance limitations or functional insufficiencies even when their implementation is operating as designed.
Engineering teams therefore need to consider the AI model, the data used to develop and evaluate it, its operating environment, and the deterministic software and safeguards surrounding it.
Verification must go beyond asking, “Does the software execute correctly?”
Teams must also ask: Where can the AI be insufficient, and what prevents that insufficiency from becoming unsafe behavior?
AI can help analyze requirements, write software, create tests, find defects, suggest fixes, close coverage gaps, and analyze engineering data.
But safety- and security-critical development still requires engineering judgment and accountability. Requirements may be incomplete or ambiguous, and regulatory, safety, security, and operational decisions cannot simply be assumed away by automation.
The goal should not be to remove engineering controls. It should be to make them faster.
Use AI to accelerate each engineering step, not to skip the steps.
AI will continue to change both how embedded software is developed and what embedded systems can do. The challenge is not to slow that change, but to make the results trustworthy.
That means combining AI with strong verification: static analysis, automated testing, code coverage, requirements traceability, security analysis, human review, and compliance evidence.
Parasoft C/C++test, C/C++test CT, and DTP help provide this verification layer for C and C++ development. AI-assisted remediation and test creation can accelerate engineering tasks, while established analysis, testing, coverage, traceability, and reporting provide deterministic evidence to evaluate the results.
Engineering trust does not come from assuming AI will always be right. It comes from having the processes and safeguards to determine when it is right, detect when it is not, and respond safely when something unexpected happens.
AI can accelerate engineering. Verification turns that speed into evidence you can trust.
