Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing!
Get the Details »
Jump to Section
Parasoft Blog
AI is changing what robots can do and increasing the complexity of the software behind them. Discover how to verify that software long before the hardware is ready—and progressively move testing closer to the real robot.
Jump to Section
Modern robots are becoming extraordinarily sophisticated. AI and computer vision let robots perceive their surroundings, recognize objects, navigate changing environments, and make decisions that would have been difficult to automate just a few years ago.
But behind those capabilities is an enormous amount of embedded software that teams still have to develop, test, and verify. And there’s a very practical problem. How do you test the software inside a robot when you don’t always have it?
A robotics development organization may have hundreds of software engineers but only a limited number of physical robots, prototype systems, hardware benches, or target processors. Early in development, the final hardware may not even exist. Later, access to it may become a bottleneck.
Some tests are also difficult, expensive, or potentially unsafe to perform repeatedly on the complete machine. Waiting until the robot is available to begin serious robotics software testing isn’t a viable strategy.
The better approach is to start verification long before the complete robot exists, and progressively move testing closer to the real system as development advances.
AI is changing robotics in two important ways.
First, it’s changing what robots can do. Perception, planning, object recognition, natural-language interaction, and increasingly autonomous decision-making are expanding the range of tasks robots can perform.
Second, AI is increasing the complexity of the software systems around those capabilities. An AI model does not operate a robot by itself. Modern robotic systems still depend on embedded software for functions such as motion control, sensor processing, actuator control, communications, diagnostics, state management, fault handling, and safety mechanisms. Much of that software is developed in C and C++.
AI also introduces new safety questions. This is reflected in the evolving standards landscape. ISO/IEC TR 5469:2024 currently provides industry-agnostic guidance on functional safety and AI systems. The emerging ISO/IEC TS 22440 series is being developed as its successor, moving toward more actionable requirements and guidance for functional safety involving AI systems.
The planned series consists of:
The series is still under development, but its direction reinforces an important point for robotics engineering: as AI assumes a larger role in physical systems, verification of the software and safety mechanisms surrounding it becomes increasingly important. Fortunately, much of that verification does not require waiting for a complete robot.
Consider a developer implementing software responsible for motor control, sensor processing, communications, or a state machine. The first useful test environment may simply be the developer’s workstation. With host-based testing, developers can test the software on their own workstation before running it on the robot’s embedded hardware.
Static analysis can begin as soon as compilable code exists. Developers can identify potential defects, undefined behavior, security weaknesses, and coding standard violations without running the software on a physical robot.
Standards such as MISRA C/C++ can provide guardrails for safety- and reliability-oriented development, while CERT C/C++ and CWE-oriented analysis can help identify potential security weaknesses.
Unit testing can begin just as early. A developer doesn’t necessarily need a motor to test the logic that determines a motor command. Nor does the actual sensor have to be connected to verify how software handles particular sensor values.
Dependencies can be isolated or simulated so individual software components can be exercised independently. This gives robotics teams an important advantage: software verification can begin while hardware development is still underway.
Testing without the complete system provides another benefit that is easy to overlook.
Some of the most valuable software tests involve conditions you may not want to reproduce physically.
Creating some of these conditions on an actual robot can be inconvenient. Others may require specialized equipment. Some could potentially place hardware, or people, at unnecessary risk.
At the unit level, engineers can deliberately inject inputs and simulate dependencies to exercise these behaviors in a controlled environment. This is particularly important for defensive software.
A robot operating normally may execute the same successful paths thousands of times while rarely exercising the error handling, fault recovery, and abnormal-condition logic intended to protect it when something goes wrong.
Running a large number of tests doesn’t necessarily mean the software has been thoroughly exercised. That’s where structural code coverage becomes valuable.
Statement and branch coverage can reveal portions of the implementation that tests have never executed. For software requiring more rigorous verification, MC/DC can provide additional evidence about the independent effect of conditions within decisions. Coverage gaps can also reveal something more interesting than a simple percentage.
Suppose the unexecuted code handles a sensor failure, communication timeout, invalid command, or transition into a safe state. That gap tells the engineering team exactly where additional testing may matter. Instead of only asking, "Did our tests pass?" Teams can ask, "What haven’t our tests exercised?"
For robotics software with large numbers of states, inputs, fault conditions, and hardware interactions, the latter is a much more powerful question.
Developer testing is only the beginning. As multiple engineers contribute to the software, automated verification should move into continuous integration.
With continuous testing, every software change can trigger appropriate static analysis, unit tests, regression tests, and coverage analysis. Problems can then be identified close to the change that introduced them rather than weeks later during system integration.
This becomes particularly important as AI accelerates software development itself.
Generative AI can help engineers:
That can increase development velocity significantly. But increased development velocity also increases the rate at which software must be verified. Whether code was written manually or generated with AI assistance, the engineering requirement remains the same: teams need objective evidence that it satisfies its requirements and behaves correctly.
AI can also help accelerate the verification side of that equation, assisting with activities such as remediation of static analysis findings, unit test creation, and closing code coverage gaps. The result is not AI replacing verification. It is AI making continuous automated verification even more important.
Host-based testing provides speed and scalability, but embedded software eventually needs to be exercised under conditions representative of the environment in which it will operate. That is where a progressive testing strategy becomes powerful. Testing can move through increasingly realistic environments:
Developer workstation → CI → Simulator → Target hardware → Complete robotic system
Not every test needs to run at every stage.
A unit test that validates an algorithm may run perfectly well on a development machine and execute thousands of times in CI. Other tests may need a simulator.
Tests involving compiler behavior, processor architecture, operating system behavior, hardware interfaces, or target-specific conditions require on-target testing, where tests run on the actual embedded hardware.
And finally, system-level testing can verify how the integrated software, electronics, sensors, actuators, AI components, and mechanical system behave together.
Each environment answers different questions. The key is not to postpone verification until the final environment becomes available.
This is also where the choice of testing workflow matters.
Robotics organizations increasingly use open-source C and C++ testing frameworks such as GoogleTest. Developers appreciate familiar frameworks because tests can be created naturally as part of normal software development. Those tests become even more valuable when they can travel with the software.
A test developed early on a host machine should not necessarily become disposable when the project moves toward integration. Where appropriate, teams should be able to execute or adapt the same tests within CI, simulators, and target environments while collecting consistent results and coverage information.
That turns testing into a progression rather than a sequence of disconnected activities. The question becomes less about where a test was created and more about where the test needs to execute to provide the required evidence.
There’s another problem that appears as robotics projects scale. A team may eventually have thousands of tests. Passing thousands of tests sounds reassuring, but it doesn’t necessarily answer an important engineering question. Have we verified the requirements that matter?
Requirements traceability connects software requirements with the tests intended to verify them and the results showing whether those tests passed. For safety-related functionality, this can be particularly valuable.
Consider a requirement specifying how the robot should respond when a sensor becomes unreliable. The engineering evidence might include:
Now verification becomes more than a collection of green test results. It becomes a traceable evidence chain.
Parasoft’s embedded testing solutions support this progressive approach to robotics software verification. Parasoft C/C++test enables developers to:
These activities can begin early, before complete robotic hardware is available.
C/C++test also supports workflows for safety-critical embedded development and is TÜV SÜD certified for functional safety standards including IEC 61508.
As testing moves into CI/CD, Parasoft C/C++test CT provides a framework-agnostic approach to continuous testing. Teams can work with existing C and C++ testing frameworks, including GoogleTest, while collecting test results and structural coverage such as statement, branch, and MC/DC coverage.
This is particularly useful for robotics because testing does not have to remain tied to one execution environment. Tests can be incorporated into automated build pipelines and executed in environments appropriate to the software being verified, including representative embedded targets.
In addition, Parasoft’s AI-assisted capabilities further accelerate verification by helping engineers address static analysis findings and coverage gaps while keeping engineers in control of the resulting changes.
Finally, Parasoft DTP brings verification information together across the development process. Test results, coverage, static analysis findings, requirements traceability, and compliance information can be presented through centralized dashboards and reports.
That visibility becomes increasingly valuable when testing is distributed across developers, CI pipelines, different test environments, and target systems. The objective is a connected verification workflow rather than isolated testing activities.
The final robotic system will always need testing. No host environment or simulator can completely reproduce every interaction among processors, electronics, sensors, actuators, networks, AI models, mechanical components, people, and the physical environment.
But that does not mean verification should wait for the finished machine. Quite the opposite.
By the time the complete robot becomes available, the goal should not be to start discovering whether its embedded software works. Much of that work should already have been done. The robot should be where teams confirm the assumptions that could only be verified on the complete system, not where software verification begins.
As AI makes robots more capable and robotics software more complex, that distinction will become increasingly important. You don’t need the robot to start testing it. The earlier you start, the more confidence you have when the real machine finally comes to life.
See how to put these methods into practice with C/C++test and C/C++test CT demo videos, covering unit testing, code coverage, and CI/CD workflows.
See how a continuous robotics verification workflow works in practice for your embedded robotics software.
