Excavators, forestry machines, tractors, and other heavy equipment are no longer purely mechanical products. Today, they are software-defined systems, with code controlling everything from operator interfaces to hydraulic functions. At the same time, manufacturers face growing pressure to deliver new capabilities faster than ever before. Customers expect autonomy, remote operation, connectivity, and data-driven services, while development teams are expected to shorten time-to-market despite increasing product complexity.
Many organisations are still trying to meet these demands with disconnected documents, endless meetings, and knowledge locked in the minds of a few key experts. As a result, development cycles slow down and innovation becomes harder to scale.
“Product quality still matters enormously, but increasingly the competitive advantage comes from how quickly new features can be brought to market and deployed in the field,” says Petri Ingalsuo, Service Area Director at Gofore.
According to Ingalsuo, machinery manufacturers have become increasingly aware of the challenge. Customers now expect capabilities from machines that were never envisioned when the equipment was originally designed, making software updatability a necessity rather than a nice-to-have.
Slow product development is no longer just an engineering concern. It directly affects growth, competitiveness, and long-term business performance.
Understanding MBD and MBSE
One approach gaining momentum across the industry is model-based engineering. While the terminology is often used interchangeably, Model-Based Design (MBD) and Model-Based Systems Engineering (MBSE) serve different purposes.
Model-Based Design (MBD) focuses on designing and validating machine functionality through virtual models and simulations. Engineers can test behaviour before any physical hardware exists.
Model-Based Systems Engineering (MBSE) provides the broader framework that connects requirements, architecture, development, verification, and validation into a single traceable system.
“MBSE is the layer that connects requirements, tests, and results across engineering disciplines into a machine-level system view. When every requirement, test, and result is linked together, compliance becomes something that can be inspected and verified rather than reconstructed from documents and memory,” explains Otto Heikkonen, who leads MBSE services at Gofore.
Imagine an excavator manufacturer developing a new grapple attachment for handling pipes. Three requirements are defined: The grapple must securely grip the pipe. The attachment must lock correctly into the excavator interface. The operator must be able to control the grip through the control system. Each requirement has its own verification test.
When mechanics, hydraulics, control software, and the complete machine are tested together in simulation, the pipe slips from the grapple. Every subsystem passes its individual test, yet the overall system fails.
Because the failed result is linked back to the associated requirement, engineers can quickly identify the root cause. The requirement specifies that the grapple must hold the pipe, but not how much gripping force is needed. Once that acceptance criterion is added and the implementation updated, the same test can be run again to verify the fix.
“This is the essence of MBSE. Without the links, it would simply be good testing. With the links, you can trace a result back to the requirement it was built on and verify the correction using the same test.”
The digital thread connects engineering silos
In many organisations, mechanical, electrical, hydraulic, and software development still operate as separate domains.
Each team validates its own work, but what often remains unverified until late in the process is the machine as a complete system.
“Each team validates its own work and passes its own tests. What often remains unverified is the machine as a complete system. The first time everything is tested together may be when the prototype is built, and at that point fixes require modifying hardware that already exists,” says Heikkonen.
The challenge often becomes visible during prototyping, where hardware and software development move at different speeds.
“It is common for software to be completed months after the prototype is built. During that time the mechanical design may already have evolved, creating additional redesign cycles and unnecessary prototype iterations,” Ingalsuo adds.
This is where the digital thread becomes critical.
The digital thread connects requirements, designs, tests, and verification results throughout the lifecycle of a product. Instead of reconstructing information afterwards, organisations maintain traceability from the beginning.
When multidisciplinary systems are validated together in simulation environments, integration issues can often be identified before physical prototypes are built. Because every requirement, test, and result remains connected, teams can quickly understand why problems occur and where corrective action is needed.
AI accelerates the transition
If model-based approaches offer such clear benefits, why are they not already the industry standard?
One reason is the effort required to transform years of legacy documentation into structured, testable requirements.
Artificial intelligence is changing that equation.
Modern AI tools can analyse thousands of pages of specifications, instructions, and test plans, helping teams create initial drafts of requirements, test cases, and system descriptions.
“AI helps with the most labour-intensive part of the transition. Current tools can read existing specifications, instructions, and test plans and generate draft requirements as well as preliminary architectural descriptions,” says Heikkonen.
Human expertise, however, remains essential.
“The output can sometimes be wrong. That is why it is a draft, not a decision. A proposal that an engineer can challenge is far more valuable than starting from a blank page. Every requirement, interface, and traceability link is still reviewed and approved by a human.”
Looking ahead, Ingalsuo sees even greater potential.
Future AI solutions could identify conflicting requirements early in the development process and utilise operational field data to support new design decisions. To realise this potential, AI must become part of everyday engineering work rather than remain a collection of isolated experiments.
From digital thread to digital twin
The value of model-based engineering extends far beyond individual development projects.
Industrial machinery often remains in operation for decades, and customers expect upgrades, maintenance, and support throughout that lifecycle. The key question becomes: how can manufacturers maintain a reliable understanding of their products over time?
Gofore’s Digital Product Lifecycle approach addresses this challenge by ensuring products are created digitally first and that product information remains connected throughout their lifecycle.
Model-based engineering provides the foundation.
The digital thread begins with traceable links between requirements, tests, and validation results. Over time, it evolves into a comprehensive product information backbone.
“All digital information that exists about a product, and everything accumulated during its lifecycle, is connected into a unified whole. This allows the digital twins required at different lifecycle stages to be created automatically,” says Ingalsuo.
Digital twins are already common in product development, where virtual machines are simulated before physical manufacturing begins. The next evolution is a lifecycle-wide digital twin that continuously incorporates operational field data.
This creates opportunities far beyond engineering. Manufacturers can provide predictive maintenance, deliver software-driven improvements, and build entirely new service-based business models long after the original sale.
Start with a new way of working, not new tools
For manufacturers considering the transition, the first step does not need to be large.
“Choose a single subsystem, ideally one where mechanics, hydraulics, and software intersect. Define its requirements in a testable format, create tests for each requirement, and link the results back to those requirements using the tools you already have. Only move to the next subsystem once the first works end-to-end,” says Heikkonen.
The emphasis is on changing ways of working before investing in new technology.
“Initially, this is about changing the way of working, not buying new tools. Once the operating model has proven itself, scaling becomes much more effective.”
Organisations should also evaluate the business case through their own metrics. What is the cost of a design issue discovered during the prototype phase? How much time is spent preparing compliance evidence or audit documentation?
While Gofore develops simulators for machinery manufacturers, simulation itself is not the core of MBSE. The foundation is a shared system model that connects engineering disciplines. Simulation is one effective way to validate the complete system before physical hardware exists, but it is not a prerequisite for adopting MBSE.
That is why Gofore recommends starting small: implement one subsystem using existing tools, prove the value with measurable outcomes, and expand only after the benefits are clear.
“You do not need to transform everything at once. The important thing is to start. There are many ways to begin, but delaying the journey rarely makes it easier,” says Ingalsuo.
Discover how Model-Based Design, Model-Based Systems Engineering, AI, and digital lifecycle management can help you develop better products faster and unlock new value throughout the product lifecycle.
