The scope of the renovation wave
The current renovation wave reflects a generational reality. Much of Europe's strategic infrastructure (highways, waterway locks, movable bridges, tunnels, treatment plants, pumping stations, terminal automation in ports) was built in the 1960s, 1970s, and early 1980s, with major automation upgrades in the late 1990s and early 2000s. Both the civil structures and the first generation of meaningful automation are now hitting end-of-life on overlapping schedules.
In the Netherlands specifically, Rijkswaterstaat, the provinces, the water boards, and municipal operators are all working through multi-decade renewal programs that touch hundreds of objects. The civil works are visible: bridges replaced, tunnels relined, locks rebuilt. The automation works are less visible, more expensive in aggregate, and more consequential for how the assets behave for the next thirty years.
Why infrastructure automation is fundamentally different
Modernizing infrastructure automation is not a smaller version of greenfield construction. The constraints are categorically different, and they shape what platforms and approaches are viable.
The civil asset is the constant. Bridges, tunnels, and treatment plants are physical structures that will keep operating for decades after any single automation generation has been replaced. The automation has to fit the asset, not the other way around.
The behavior is mostly already correct. Twenty or thirty years of operational learning have produced a system that, for all its technical debt, does what the operator needs it to do. The modernization has to preserve that operational behavior, not redesign it. This is different from greenfield, where the behavior is being defined for the first time.
The cutover window is small. Infrastructure assets cannot easily be taken offline for months while a new system is commissioned. Many can only be taken offline for hours, on specific dates, with specific traffic or operational conditions. Modernization has to be staged, testable in advance, and reversible.
The asset owner is often a public entity. Rijkswaterstaat, water boards, provinces, and municipal operators face procurement rules, transparency obligations, and audit requirements that private industrial operators do not. The engineering work product has to be portable, readable, and ownable by the public entity, not locked inside a single integrator's tools.
These four constraints together make infrastructure automation modernization a specific problem class. The platforms and approaches that work for new factory automation projects often do not work here. The platforms that do work are the ones that treat behavior preservation, vendor independence, and operational continuity as first-class design properties.
Why automation is the next phase after civil renewal
Civil and automation are renewed on different cycles, but they interact. A civil renewal creates an opportunity to modernize the automation while the asset is offline anyway. Conversely, automation that is reaching end-of-support forces a modernization regardless of whether the civil structure is due. Several factors are now compounding to make automation modernization a near-term priority across the portfolio:
- End-of-support hardware. Controllers from the late 1990s and early 2000s are reaching end-of-life, and replacements have to be qualified.
- Cybersecurity exposure. Operating systems and protocols designed before modern threat models are no longer defensible. The NIS2 directive raises the bar for critical-infrastructure operators across the EU.
- Workforce turnover. The engineers who built and maintained the previous generation of automation are retiring, and the institutional knowledge has to be captured before it leaves.
- Climate adaptation. Water management and flood protection require behavioral changes that the original automation was not designed for: changing pumping regimes, new monitoring obligations, more frequent operating cycles.
- Standardization pressure. Operators with hundreds of similar objects (locks, bridges, treatment plants) cannot afford to maintain hundreds of bespoke automation systems. Cross-object standardization has become an explicit programmatic goal.
The specific challenges of automation modernization in infrastructure
Those categorical constraints translate into specific engineering challenges. Modernizing automation on infrastructure objects is technically and organizationally different from modernizing a single industrial plant.
Long lifecycles. The civil asset will live another 50 to 80 years. The automation has to be renewable on a tighter cadence (10 to 15 years) without re-specifying the system each time. That requires a maintained engineering work product that survives multiple controller generations.
Multi-vendor heterogeneity. A typical operator's portfolio includes systems built by different integrators with different controller families across decades. There is no realistic path to a single-vendor portfolio. The renewal has to handle heterogeneity by design.
Knowledge loss. Operational behavior, including the field-discovered exceptions that nobody wrote down, has to be captured before the engineers who know it leave. This is a discovery problem as much as an engineering problem.
Operational continuity. The asset has to keep working during modernization. There is rarely a long shutdown window. Cutover risk has to be small.
Audit and compliance. Public infrastructure operators face increasing demands for traceability, evidence-based operations, and demonstrable safety. The renewed automation has to be auditable in ways that the original was not.
Why standardization across multiple objects matters
One of the structural lessons of the current renovation wave is that operators with portfolios of similar objects benefit disproportionately from standardization. A single bridge is one engineering project. Twenty bridges, modernized one at a time over a decade, are either twenty separate engineering projects (expensive, inconsistent, hard to maintain) or one engineering platform deployed twenty times (cheaper per object, consistent, easier to maintain).
Standardization at the level of the engineering platform is what makes the second pattern feasible. A model-centric platform lets shared behavior be captured once in a model family, with object-specific variation expressed cleanly. New objects inherit shared behavior; behavioral improvements propagate across the portfolio; modernization budgets compound rather than fragmenting.
The difference is concrete. A national waterway operator managing fifteen lock complexes built between 1968 and 1995 across four different controller families faces a choice. Replacing each system as it reaches end-of-life means fifteen separate engineering projects over the next decade, with no architectural consistency and a fifteen-year repeat cycle. Modernizing under one model family means one engineering platform, fifteen deployment instances, and the next renewal cycle is incremental rather than complete re-engineering.
Stakeholders and decision-making
In the Netherlands, the decision-making landscape for infrastructure automation involves several levels:
- Rijkswaterstaat for national infrastructure (highways, locks, storm surge barriers, major waterways).
- Provinces and municipalities for regional and local infrastructure (provincial bridges, urban tunnels, ferry terminals).
- Water boards for water management infrastructure (pumping stations, weirs, treatment plants).
- System integrators who deliver and often operate the automation on behalf of the asset owner.
- Maintenance contractors who handle ongoing operational support across multiple asset owners.
The procurement model has shifted in recent years toward longer-term DBFM (Design-Build-Finance-Maintain) contracts, which align the integrator's incentives with long-term operability. That alignment makes model-centric platforms more attractive: the integrator who is responsible for thirty years of operation has a direct financial interest in not building a code-centric system that will become unchangeable in fifteen.
The European context
The pattern visible in the Netherlands is not unique. Across Europe, similar infrastructure renovation programs are underway with overlapping timelines and similar constraints.
Germany faces extensive bridge replacement and tunnel renewal across the federal Autobahn network, with automation modernization following the civil works. The United Kingdom is renewing canal infrastructure, lock systems, and tidal barriers, with the same pattern of civil renewal preceding automation upgrade. Belgium and France are working through analogous programs on inland waterways and movable bridges. Scandinavian countries face similar challenges on tunnel automation, ferry terminals, and water management infrastructure.
The specific procurement structures differ by country, but the underlying problem is consistent: a generation of infrastructure built between 1960 and 1985 is reaching end-of-life on overlapping civil and automation cycles, with workforce turnover and tightening regulatory expectations adding pressure. The architectural choices made in this decade will determine how this infrastructure operates for the next thirty to fifty years.
The role of model-centric platforms in this context
Model-centric platforms are well suited to infrastructure automation modernization for three reasons that map directly onto the constraints above.
First, the model survives multiple controller generations. The civil asset's lifecycle is decoupled from the controller lifecycle, because the model is the maintained artifact and code is regenerated for each new target.
Second, the model handles heterogeneity. The same model can generate code for different vendor targets across the portfolio, so operators are not forced into single-vendor lock-in to achieve consistency.
Third, the model captures intent. Modernization projects can ingest legacy behavior into the model, validate it, and generate new code without losing the field-discovered exceptions that make the system actually work.
How Cordis SUITE fits infrastructure renovation
Cordis SUITE has been used for infrastructure automation modernization across Dutch national infrastructure for over two decades. The pattern is consistent across object types, whether the asset is a movable bridge, a lock complex, a storm surge barrier, a water treatment plant, or a terminal automation system. The platform handles the constraints that make infrastructure modernization different.
Behavior preservation. The legacy system's operational behavior, including the field-discovered exceptions that nobody documented, can be captured in the model and validated against the running system before any new code is deployed. The model becomes the place where institutional knowledge is preserved as the engineers who built the original system retire.
Vendor independence across the portfolio. A water board with thirty pumping stations built across three decades by four different integrators on five different controller families can standardize the engineering work product without forcing a single-vendor portfolio. The model is the constant; the deployment target varies per object based on procurement, certification, or local-support reasons.
Standardization across similar objects. A national infrastructure operator with portfolios of similar objects (bridges, locks, treatment plants) can build model families in which shared behavior is captured once. Each subsequent object inherits the shared model, with variation expressed cleanly. The cost of modernization compounds favorably across the portfolio rather than fragmenting into separate projects.
Gradual migration with operational continuity. Many infrastructure operators cannot replace an entire automation system in one cutover. Cordis SUITE supports gradual replacement: model-based components can be deployed alongside legacy systems, connected through standard interfaces, and progressively expanded as renewal cycles allow. Migration happens on the maintenance budget, asset by asset, subsystem by subsystem.
Audit and compliance built in. Public infrastructure operators face increasing demands for traceability, evidence-based operations, and demonstrable safety. In Cordis SUITE, traceability is a property of the model: requirements link to behavior, behavior links to generated code, code links to tests, tests link to runtime evidence. Audits become guided tours of a current artifact rather than reconstructions of historical documents.
Long-term independence. Cordis SUITE is built explicitly against vendor lock-in. The generated code is structured and readable, operational data is stored in standard databases (such as InfluxDB), the runtime layer exposes data through standard interfaces such as gRPC, and models can be exported as SVG. For public asset owners, this matters more than for private operators: the engineering work product has to remain accessible decades after the original integrator relationship ends.
The platform was built for exactly this class of problem from the start, before "infrastructure renovation wave" became a recognized programmatic priority. The architecture predates the demand it now meets.
The honest framing
The infrastructure renovation wave is not just a procurement opportunity. It is the moment at which a generation of asset owners chooses what their automation will look like for the next thirty to fifty years. The platforms selected during this decade will shape lifecycle cost, operational flexibility, audit defensibility, and vendor leverage long after the people making the selection have moved on.
The choice that compounds favorably is the one that treats automation as a long-lived engineering work product, not as a project deliverable that gets replaced every fifteen years. Model-centric platforms are the architectural answer to that framing. The platforms that approach this wave as another round of code-centric procurement will be doing it again in fifteen years, at higher cost, with less institutional knowledge, and against tighter regulatory bars. The ones that treat this as a one-time architectural shift will not.