Software-defined products are engineered to make our lives simpler, be it the automated assistance features in modern vehicles, the sophisticated systems piloting commercial airplanes, or the intelligent equipment streamlining production on the factory floor.
As these products become more intuitive and easier to use, the software supporting them grows inherently more complex. It is a paradox that rings true across industries, from automotive, to aerospace and defense, to industrial equipment and energy systems.
Naturally, as complexity grows, so do engineering challenges. For every new feature, there’s a new set of dependencies, interactions, and requirements to sort through. For engineers, it’s not only a matter of how to build more software, but how to create and validate it with confidence.
Complexity is Outpacing Traditional Engineering Practices
Yet engineers continue to face the same pressures often competing for their attention from several directions. Consumers expect more features as companies press for shorter development cycles and lower costs. In response, engineering teams are expected to significantly scale output without compromising on quality, safety, or security.
Integration is a flashpoint during development as software must work with hardware, networks, and other related components in response to user inputs and other environmental conditions. It involves many teams from various disciplines, suppliers and organizations working with different tools and processes to uncover component issues that often surface when combined.
Engineering complexity grows as more features, dependencies, and connected technologies converge within a single system.
In this environment, the traditional, manual, often siloed way of doing things falls short, and is often followed by late-stage defects.
“We see our customers are getting into more and more trouble with the integration of software into the system,” says Robert Fey, business development director at Synopsys. “We see a lot of late-stage defects, which is for us an indicator. And these are problems that people want to solve.”
Organizations are responding with AI, digital twins, model-based systems engineering and new testing frameworks to accelerate engineering activities
AI can help engineers generate artifacts, analyze data, and identify patterns more efficiently. Yet its effectiveness depends heavily on the quality, consistency, and structure of the engineering information it consumes. When requirements, models, and validation assets are fragmented, AI can amplify inconsistencies just as easily as it accelerates productivity.
Speed matters. But speed without structure does not scale.
Structure is Becoming an Engineering Necessity
Introducing structure into a software-defined engineering process gives teams a way to reason through, rather than react to, more complex challenges. A structured approach connects requirements to intended behavior, intended behavior to implementation, and implementation to evidence that suggests the system has been evaluated appropriately.
Requirements-driven, model-based development does not lean on implementation to define the product. Instead, teams can create a model that defines how the software should behave, subject to a defined set of rules. The objective is to make sophisticated software more understandable, reviewable, and maintainable.
“Ansys SCADE software is relevant to this approach as it offers a model-based, formally structured approach to software development,” says Vincent Rossignol, senior manager, product management at Ansys, part of Synopsys. “It’s been built on purpose to support the creation of an engineering representation that preserves intent as implementations change and products evolve. This is especially important for systems with long operational lives.”
A complex, software-defined product does not necessarily have an end life. It may need to be updated, investigated or adapted post-development to understand what and why it was created, as well as how any future changes might affect it. Structured artifacts (models) provide continuity between teams creating the product, and those responsible for it further down the road.
Verification Faces Its Own Complexity Crisis
Software-defined product development is only half of the challenge. Verification and validation practices must scale with the software they are intended to evaluate.
Consider a traditional requirements-based approach. It derives test cases from requirements, constructs a situation, applies inputs, and then determines whether the observed output matches the expected behavior. However, when applied to software development, its practical limitations become more apparent as the number of operating conditions expands.
“In this scenario, one thing’s for certain,” says Fey. “No team can test every possible combination of speed, system state, user action, environmental condition, and component interaction. The time investment often outweighs the benefits. In this case, verification depends on what must be prioritized for testing, and when is the evidence sufficient to achieve validation.”
There’s also what happens after test cases are created.
These long-lived engineering assets must be stored and revisited as the system changes. Their testing is tightly connected to implementation details, which can have a cascading effect on failure if the underlying requirements are not addressed.
Although software may be quickly changed, evaluating, addressing, and re-running affected tests can create significant bottlenecks. Engineers find themselves spending more time distinguishing between actual product defects and test-maintenance than on problems.
From Isolated Test Cases to Reusable Behavioral Knowledge
A more scalable validation methodology separates two concepts that are often embedded together: the situation used to stimulate the system and the behavior expected in response.
“A test may switch a light on and off several times to exercise different internal states,” says Fey. “Instead of annotating the expected result every time that action appears, an engineer can define the behavioral rule once: whenever the switch is on, the light should be on; whenever the switch is off, the light should be off. The rule can then be evaluated across many test situations.”
What effect does this method have on validation?
“This separation turns expected behavior into reusable engineering knowledge,” says Fey. “If a requirement changes, rather than revising each test individually the corresponding rule can be updated and applied across relevant tests. The value is not simply fewer edits. It is stronger alignment between the requirement, the expected behavior, and the evidence produced through validation.”
The Ansys TPT embedded software testing tool separates test simulation from evaluation criteria and supporting rules derived from requirements, enabling teams to capture behavioral intent independent of specific scenarios. This reusable validation knowledge can reduce repeated work, make changes easier to absorb, and help testing organizations keep pace with development.
Shortening the Feedback Cycle Between Development and Testing
Engineering teams can derive great value in combining structured software development and validation. A requirements-based foundation provides common ground.
SCADE software gives development teams a structured representation of the software, while TPT gives validation teams a structured approach to tests and behavioral rules. Through their integration, testers can work against model-level elements from their own environment, execute requirements-based tests, compute model coverage, and pass results back to the development environment for further investigation.
“Using this combination of tools, developers can see failures in terms of requirements, situations, and relevant behavior over time,” says Rossignol. “Reusing test data in a development environment also reduces the effort required to recreate a problem. Development and testing move from ‘a testing failure’ to ‘behavior changes under these specific conditions.’”
Working from this perspective, testers and developers can build a shared understanding of system behavior that leads to greater insights during development.
A look at the transition from manual model-level testing to integrated, automated validation across the development lifecycle.
Looking Ahead
In the race to software-defined innovation, those who come out ahead will treat models, requirements, tests, and validation rules as reusable (rather than disposable) knowledge supported by a structured approach to development.
“Software-defined systems will continue to become more capable,” says Fey. “With that comes greater complexity. The challenge is no longer just building software. It’s understanding, validating, and evolving it. The organizations best positioned for the future will be those that can explain what their software should do, demonstrate how it was evaluated, understand why it failed, and safely evolve it over time.”
To learn more about how SCADE software and TPT software can be used to support software-defined development, be sure to check out Bringing Structure in the Development and Testing of Embedded Control Software with SCADE and TPT, and Introducing Ansys TPT, Embedded Software Testing.
