This is why cybersecurity in transportation infrastructure cannot be treated the way it is treated in most enterprise IT environments. The threat model is different, the consequences of failure are different, and the technical environment presents challenges that standard IT security approaches were not designed to handle.

The problem that connectivity created

For most of their operational history, transportation infrastructure systems were physically isolated. A tunnel control system ran on proprietary hardware, communicated over dedicated cabling, and had no connection to the outside world (effectively air-gapped). Security through isolation was imperfect, but it was genuinely effective against the vast majority of threats that existed at the time.

That isolation is gone. Modern traffic management platforms connect to cloud analytics services. Enforcement systems transmit data to central processing facilities over public networks. Roadside units communicate with vehicles (V2X / C-ITS), with each other, and with operations centres in real time. Remote monitoring and maintenance access means that a technician can connect to a field device from an office or a laptop, typically over a VPN or vendor remote-access link, without being physically present at the installation.

Each of these connectivity requirements is operationally justified. Remote access significantly reduces maintenance costs, and cloud analytics enables capabilities that local processing cannot economically match. Vehicle-to-infrastructure communication is a prerequisite for the safety applications that modern transportation networks depend on. The connectivity is not going away. The question is whether the security architecture was designed to handle it, or whether it was added as an afterthought to a system that was not built with it in mind.

Why are transportation systems particularly exposed?

Most transportation infrastructure was designed by engineers whose primary expertise is in traffic, structural, or mechanical engineering. Cybersecurity was not a design requirement when most of the currently operational systems were specified. The result is that a significant proportion of active transportation infrastructure relies on operational technology built for reliability and availability (the OT domain now framed by the IEC 62443 industrial-security standard), with security considerations addressed only minimally, if at all.

This creates a specific vulnerability profile. Many field devices run embedded software that cannot be patched without physical access or system downtime. Communication protocols used between subsystems were designed for reliability on closed networks and do not include authentication or encryption (for example legacy serial/fieldbus links, or Modbus and early NTCIP profiles with no native security). Default credentials on installed hardware are often left unchanged from factory settings because the device is on a network assumed to be isolated – a practice the EU Cyber Resilience Act will effectively prohibit for new products. Configuration data is sometimes stored in plaintext because the system predates any expectation that the storage medium could be accessed remotely.

None of these are the result of negligence. They reflect the design assumptions of a different era, applied to systems that are now connected to networks their designers never anticipated. The problem is compounded by asset lifecycles. Transportation infrastructure has a long service life. Hardware installed fifteen years ago is still operational and will remain operational for another decade. Upgrading the cybersecurity posture of that hardware is technically constrained and often expensive.

The OT/IT distinction that matters for procurement

The IT systems that most organisations are familiar with (such as standard office networks, email platforms, and enterprise software) operate under an availability model that tolerates planned downtime for patching and maintenance. A server that needs to restart for a security update can be scheduled for a maintenance window and applications can be taken offline temporarily without physical consequences.

Operational technology in transportation infrastructure does not have this flexibility. A tunnel management system cannot be taken offline for a software update during peak hours; a traffic signal controller that needs to restart mid-cycle creates a safety event. Enforcement systems that go offline lose evidential continuity. The availability requirement in OT environments is often 99.99%, meaning less than an hour of unplanned downtime per year, so patching is tied to redundancy and scheduled maintenance windows rather than automatic updates, and even planned downtime requires careful coordination with operational teams.

This means that standard enterprise IT security practices, regular patching cycles, centrally pushed software updates, and aggressive monitoring that generates high volumes of alerts requiring human review do not translate directly into OT environments without adaptation – passive, OT-aware intrusion detection and network anomaly monitoring are usually preferred to intrusive active scanning. Security measures that are routine in an office network can be genuinely disruptive when applied to a tunnel control system or a signal management platform.

Vendors who propose the same security architecture for transportation infrastructure that they use for enterprise IT deployments reveal something important about how deeply they understand the environment they are working in.

What goes into a system matters from day one (security by design)

The cybersecurity posture of a transportation infrastructure deployment is largely determined before a single cable is laid. The hardware selected, the software platform, the communication protocols, the network architecture, and the access control model: these decisions, made during the design and specification phase will determine the security envelope of the completed system. Retrofitting security to a system not designed for it is especially expensive. This is precisely the “security by design and by default” principle that the EU Cyber Resilience Act (Regulation (EU) 2024/2847) now makes a legal obligation for products with digital elements placed on the EU market.

This has direct implications for procurement, since the cybersecurity requirements in a tender document must to go beyond mere certification compliance. ISO 27001 certification tells you that a vendor has a documented information security management system (and, for OT, IEC 62443 certification of both the product and the integrator’s processes is more telling), but it does not tell you how authentication is implemented between field devices and the central platform; whether communication between roadside units and the control centre is encrypted end-to-end (for example mutual TLS with per-device certificates), or how the system detects and isolates a compromised component before it affects the broader network.

Hardware provenance is also a genuine consideration in critical infrastructure. Equipment manufactured in jurisdictions with different regulatory frameworks governing data access and security disclosure obligations poses risks that are difficult to evaluate and manage once the hardware is installed. The supply chain question, which includes hardware vendors, software components, and communication platforms, belongs in the security assessment alongside the architecture questions. Under NIS2 this is explicit: operators must manage supply-chain and vendor risk, and a software bill of materials (SBOM) – now expected under the Cyber Resilience Act – is becoming the baseline evidence for it.

The regulatory dimension

In the European Union, the NIS2 Directive (Directive (EU) 2022/2555) substantially expanded the scope of cybersecurity obligations for operators of essential services, and transportation infrastructure (road, rail, air and water transport are named in Annex I) falls explicitly within its scope. Operators are required to implement appropriate technical and organisational measures to manage cybersecurity risks – the baseline set of measures is detailed in Commission Implementing Regulation (EU) 2024/2690 -, report significant incidents within defined timeframes (a 24-hour early warning and a 72-hour incident notification to the national CSIRT), and ensure that their supply chains meet adequate security standards. Member states began enforcement from late 2024, with direct senior-management accountability and fines of up to €10 million or 2% of global annual turnover, and the implications for infrastructure operators and their technology vendors are material.

Two newer EU instruments matter just as much for procurement. The Cyber Resilience Act (Regulation (EU) 2024/2847) sets mandatory cybersecurity requirements for “products with digital elements” – which covers the controllers, roadside units, cameras and software in a transport deployment – mandating secure-by-default configuration, no hard-coded default passwords, coordinated vulnerability handling and security updates for the support period, evidenced by CE marking (its main obligations apply from 2027). The Critical Entities Resilience (CER) Directive (Directive (EU) 2022/2557) adds physical-resilience duties for the same transport operators, complementing NIS2 on the cyber side. And the Cybersecurity Act (Regulation (EU) 2019/881) established ENISA and the EU cybersecurity certification framework – including the EUCC scheme – against which OT products can be certified. Read together: NIS2 governs the operator, the CRA governs the product, CER governs physical resilience, and the Cybersecurity Act governs certification.

GDPR (the General Data Protection Regulation, Regulation (EU) 2016/679) comes into play whenever transportation systems collect data that can be linked to identifiable individuals. Enforcement cameras that capture vehicle registration plates, V2X systems that communicate with specific vehicles, and monitoring platforms that record movement patterns: all of these involve personal data under EU law. Data minimisation, purpose limitation, and appropriate technical safeguards are not optional additions; they are legal requirements that affect how systems must be designed, not just how they are operated.

Neither NIS2 nor GDPR (nor the CRA) compliance is primarily a documentation exercise. The compliance status of a transportation system is a function of how it was designed and built, which means the time to address it is during specification and procurement rather than after deployment.

What a cybersecurity-serious deployment looks like

A transportation infrastructure system with a mature cybersecurity architecture exhibits several characteristics evident during procurement evaluation. The network is segmented into IEC 62443 zones and conduits, with a demilitarised zone (DMZ) between the IT and OT networks, so that a compromise in one zone (a public-facing web interface, a maintenance access point, a field device) cannot propagate freely to other zones. Authentication between system components is explicit rather than assumed; devices identify themselves to each other using per-device credentials or certificates (mutual TLS) rather than relying on network location as a proxy for trust. Logging is comprehensive enough that a security event can be reconstructed after the fact, ideally aggregated into a SIEM, supporting both incident response and legal proceedings if required. The system should be able to detect anomalous behaviour in field devices and isolate them without taking the broader system offline.

Perhaps most importantly, security has been considered in the context of what happens when things go wrong. Fail-safe and fail-secure behaviour during a cyberattack, specifically maintaining safety-critical functions while isolating and recovering compromised components, requires that the system was designed with that scenario in mind from the outset.

Procurement evaluation processes that ask vendors to describe their security architecture in operational terms, rather than simply providing certification documentation, surface the difference between vendors who have genuinely embedded security in their design practice and those who have not.

Lillyneir’s approach to cybersecurity in transportation systems starts at the architecture design phase and is built around the specific operational constraints of OT environments: availability requirements, long asset lifecycles, multi-vendor subsystem integration, and the regulatory obligations applicable in each deployment jurisdiction. If cybersecurity is a consideration in a current or upcoming project evaluation, it is a conversation worth having early. As an intelligent transport systems (ITS) integrator, Lillyneir designs to IEC 62443, engineers NIS2- and CRA-aligned security by design (network segmentation, mutual authentication, SBOM and coordinated vulnerability handling, secure remote access), and maps each requirement to the specific EU obligation – NIS2, the Cyber Resilience Act, the CER Directive, the Cybersecurity Act and GDPR – that applies in your deployment jurisdiction.

And yet a substantial proportion of these projects underperform against their original objectives. The technology works. The vendor has genuine expertise. The point of failure sits in the integration itself—the interfaces, data flows, and operational hand-over between subsystems. The system integration fails anyway, or takes twice as long as projected, or delivers a system that operations staff work around rather than with. The failure mode is almost never the one the RFP was designed to prevent.

What follows are four evaluation criteria that experienced project managers know matter, but that rarely appear explicitly within transportation infrastructure tenders.

1. The depth of legacy integration experience

Most tender documents ask for a list of previous projects and a count of integrated subsystem types. What they do not ask is how the integrator handled projects in which the legacy systems were poorly documented, vendor APIs were incomplete, protocols were non-standard (proprietary serial links, undocumented Modbus registers, or partial DATEX II / NTCIP / OCIT implementations), or the installed hardware predated current specifications by twenty years.

Every major transportation infrastructure project involves legacy systems that do not behave as specified. A signal installation from 2008 running a legacy urban-traffic-control (UTC) controller. A SCADA platform running a customised version of software that the original vendor no longer supports. A tunnel fire detection system integrated by a company that was acquired twice since the initial deployment, with documentation that reflects none of the field modifications made over twelve years of operation.

The question worth asking explicitly is not “how many subsystem types have you integrated?” It is “describe a project where the legacy integration was significantly more complex than specified, and explain how you resolved it.” The answer reveals more about actual capability than any reference list. In practice the tell is whether the integrator works from interface control documents (ICDs) and protocol adapters, and validates every interface through factory and site acceptance testing (FAT/SAT) rather than assuming the documentation is correct.

An integrator with experience across 50 or more subsystem types from multiple vendors has, by definition, encountered the full range of integration problems that exist in the field. One with a narrower portfolio may have excellent capability within a specific technology stack and genuine gaps outside it.

2. The support model after go-live, not just during implementation

Implementation teams and support teams are often different groups with varying skill levels and commercial incentives. A vendor can staff a project with senior engineers during the deployment phase and transition the client to a junior service desk at go-live, often with little structured knowledge transfer. This transition is rarely visible during the procurement process and becomes apparent only when the first serious operational issue arises at 2am on a Sunday.

The questions that surface this risk are specific. Who handles critical incident response after go-live, and what are their qualifications relative to the implementation team? What is the contractual response time for safety-critical system failures – the guaranteed response and restoration times (MTTR), the 24/7 coverage model, and the escalation path – , and what are the financial consequences if that SLA is missed? Has the authority spoken to existing clients about their experience with post-implementation support rather than with the implementation itself?

The cost of a transportation system that collapses during a peak operating period is substantial. An unplanned tunnel closure costs in the order of $500,000 per hour in direct economic impact on freight and commuter flows. A support model that cannot restore critical systems within a defined window is not a minor service quality issue. It is a financial and reputational risk for the authority.

3. Cybersecurity architecture as a first-class design requirement

Transportation infrastructure systems are increasingly recognised as critical national infrastructure and are increasingly targeted by cyberattacks, and are now explicitly in scope of the EU NIS2 Directive (2022/2555) and the Cyber Resilience Act (2024/2847). Despite this, cybersecurity is often treated in tender documents as a compliance checkbox rather than an architectural requirement. Vendors are asked to confirm that they follow relevant standards (ISO 27001, and for OT the IEC 62443 series). Few are asked to explain how cybersecurity is embedded in the system design from the outset, rather than applied as a layer on top of an architecture not designed with security in mind.

The distinction matters because the two approaches produce fundamentally different systems. Security applied as an afterthought tends to create perimeter defences that protect against known attack vectors but leave the underlying system architecture vulnerable if those perimeters are breached. Security embedded in the architecture from the design phase means that individual components are hardened, communications between subsystems are authenticated and encrypted (for example segmented into IEC 62443 zones and conduits, with mutual TLS between components), and the system can detect and isolate a compromised component before it affects the extended network.

4. Clarity about what the vendor will not do

A vendor who is candid about the scope of their capability is giving valuable information. A vendor who presents as capable of everything is providing a warning sign.

Major transportation infrastructure projects almost always involve scope evolution during delivery. Requirements that were clear at the tender stage become ambiguous in execution. New regulatory requirements emerge mid-project (a new NIS2 or CRA obligation, for instance). The authority requests changes that were not anticipated in the original specification. How the integrator handles these situations depends significantly on whether the contract was won on realistic commitments or on commitments designed to secure the project.

The most useful question in this area is direct: “Describe a project where the scope changed significantly during delivery, and explain how you managed the client relationship and the commercial implications.” A vendor with genuine delivery experience has clear examples. One who manages scope creep primarily through contract enforcement rather than collaborative problem-solving will reveal this in the answer.

It is also worth examining what the vendor explicitly excludes from their capability. An integrator who is specific about the subsystem types, geographic markets, or regulatory environments where they lack depth is easier to work with than one who claims universal competence and discovers limitations during delivery.

None of these criteria requires significant additional evaluation effort. They require different questions in the same evaluation process. The difference between a transportation infrastructure project that delivers against its objectives and one that absorbs years of operational bandwidth managing problems that could have been anticipated is often traceable to what was asked during partner selection rather than what was specified in the technical tender.

If any of these questions resonate with an evaluation you are currently running, Lillyneir’s team is available to answer them directly about our own practice and experience. As an intelligent transport systems (ITS) integrator, Lillyneir can speak to each criterion directly: 50+ integrated subsystem types across multiple vendors; legacy integration via interface control documents and protocol adapters (DATEX II, NTCIP, OCIT); a defined post-go-live support model with safety-critical SLAs and 24/7 response; security engineered to IEC 62443 and aligned with NIS2 and the CRA from the design phase; and a candid account of where our scope ends.

The short version: cloud computing is genuinely powerful, and modern transportation systems depend on it. But there is a category of decision that a cloud-based system cannot make fast enough. Understanding where that boundary sits determines whether a transportation network is actually safe or merely appears to be.

The speed that safety requires

A vehicle travelling at 100 km/h covers approximately 28 metres per second. An autonomous vehicle or a V2X-enabled intersection management system making a safety-critical decision – collision warning, emergency braking coordination, signal phase change for an approaching emergency vehicle (a DENM or SPaT message generated from a CAM stream) – needs to complete the full cycle from sensor input to actuation command in well under 100 milliseconds. For the most demanding autonomous vehicle coordination applications, the target is below 10 milliseconds, in the URLLC (ultra-reliable low-latency communication) class.

A typical round-trip from a roadside unit to a cloud data centre and back, under a good network environment, takes between 50 and 150 milliseconds, and rarely with the bounded, deterministic jitter that safety functions require. Under congested network situations, or with any packet loss requiring retransmission, that figure climbs significantly. This is not a problem that faster internet connections fully solve. Physical distance imposes a latency floor that cannot be engineered away; regardless of bandwidth, the speed of light through fibre sets a hard limit on how quickly data can travel hundreds of kilometres and return.

For applications that can tolerate latency (such as historical analysis, network-wide optimisation, long-range traffic prediction, and maintenance scheduling), cloud computing is the right environment. It provides scalability, storage, and processing power that edge hardware cannot match economically. The problem arises when cloud-first architectures are applied to applications that require sub-100ms response times, because those applications fail silently. The system appears to function until the moment latency causes a safety event.

What edge computing actually means in a transportation context

Edge computing in transportation means placing processing capability at or near the point where data is generated and where action needs to be taken at the roadside unit (RSU), inside the tunnel control cabinet, at the intersection (in or beside the traffic-signal controller), or on the enforcement sensor. The edge processor — increasingly a GPU/NPU-equipped node running on-device inference — receives sensor data, runs the relevant algorithms locally, and issues the actuation command without waiting for a round-trip to a central server.

This is not a new concept in transportation. Adaptive traffic signal controllers have always done local processing. What has changed is the complexity of the decisions being made at the edge and the integration requirements between edge nodes and central systems (typically over NTCIP or DATEX II). A modern edge deployment at a signalised intersection might run computer vision algorithms for vehicle detection and classification, V2X message processing for connected-vehicle coordination (broadcasting SPaT/MAP and enabling GLOSA), incident-detection logic, and signal optimisation – all locally, with sub-100ms response times – while simultaneously sending aggregated data to a cloud analytics platform for network-wide optimisation and reporting.

The edge and the cloud are not competing architectures. They handle different parts of the problem. Getting the division of labour right is the critical design decision.

Where the division of labour should fall

The clearest way to think about this is in terms of response time requirements. Decisions that need to happen in under 100 milliseconds belong at the edge without exception. This includes collision warning processing, emergency vehicle preemption (signal priority / SPaT phase change), immediate incident detection and alerting, and any V2X safety message generation (CAM/DENM over ETSI ITS-G5 or C-V2X PC5). Processing these in the cloud introduces unacceptable latency, regardless of how well the network performs.

Decisions that operate on a timescale of seconds to minutes can tolerate a hybrid approach, in which edge processing handles the immediate response and cloud systems provide optimised parameters. Dynamic signal timing (adaptive urban traffic control) is a good example: the edge controller adjusts signal phases in real time based on local sensor data, while the cloud analytics platform updates the optimisation model every 30 seconds based on network-wide patterns. Neither layer does the full job alone.

Decisions that operate on a timescale of hours, days, or longer belong primarily in the cloud. Predictive maintenance scheduling, long-range traffic forecasting, performance reporting, and model training for machine learning systems; these require the storage capacity and computational scale that cloud infrastructure provides, and the latency of cloud processing is irrelevant at that timescale.

Why this matters in procurement

Transportation system tenders frequently specify cloud-based management platforms without explicitly addressing edge architecture requirements. This creates a risk that vendors deliver systems in which the cloud platform is well-specified, and the edge layer is underinvested. Adequate for monitoring and reporting functions, but insufficient for the real-time safety applications the system is supposed to support.

The questions worth asking explicitly in any procurement evaluation are: where does incident detection processing occur, and what is the measured latency from sensor trigger to alert output (end-to-end, and at the 99th percentile, not just the average)? What is the edge hardware specification at each roadside unit (compute, environmental/IP rating, secure boot and OTA update path), and what algorithms run locally? How does the system behave when cloud connectivity is degraded or lost? Does the edge layer maintain safety-critical functions autonomously, or does the system fail to a reduced capability state?

Fail-safe behaviour during connectivity loss is particularly important. A transportation system whose safety functions depend on continuous cloud connectivity has a single point of failure that weather events, network outages, and cyberattacks can exploit — a design that also runs counter to IEC 62443 and NIS2 resilience expectations for critical infrastructure. Edge architecture that retains local decision-making capability during cloud disconnection is a resilience requirement, not an optional feature.

The autonomous vehicle dimension

The latency constraint becomes more acute as transportation networks prepare for the integration of autonomous vehicles. Autonomous vehicles operating at highway speeds require infrastructure support with response times below 10 milliseconds for collision-relevant communications (the URLLC target, carried over C-V2X PC5 side-link). This is achievable only with edge processing co-located with the roadside infrastructure: multi-access edge computing (MEC) nodes integrated with 5G network slicing and time-sensitive networking (TSN) for bounded latency, positioned to minimise the physical distance between computation and vehicle.

Authorities that invest in cloud-centric architectures today will incur retrofit costs when autonomous vehicle volumes require edge capabilities not built into the existing system design. Building edge infrastructure into transportation systems now, even where current applications do not fully demand it, creates the foundation for autonomous vehicle readiness without a disruptive and expensive upgrade cycle later.

This is worth examining honestly, because a failed or underperforming digital twin deployment does not just waste capital. It consumes years of organisational bandwidth and leaves decision-makers reluctant to revisit the technology when conditions actually warrant it.

What a transportation digital twin actually does in this context

Before evaluating whether the economics work, it helps to be precise about what a transportation digital twin does operationally. It creates a continuously updated virtual replica of physical infrastructure – roads, tunnels, bridges, traffic signals and signal controllers, tunnel ventilation and SCADA systems, variable message signs (VMS), CCTV/ANPR, and roadside sensor networks- synchronised in real time through IoT sensors, OT/SCADA telemetry, and traffic data feeds. The model does not just display current status; it runs physics-based simulations and machine-learning predictions against live operational data to forecast equipment failures, model traffic scenarios, and test control strategies before implementing them in the physical environment.

The value does not come from the 3D visualisation, which is often a prominent feature in vendor demonstrations. It comes from three specific capabilities: predictive, condition-based maintenance of critical assets before they fail; simulating traffic and incident scenarios without disrupting live operations; and correlating data across asset types-traffic, structural, and electromechanical- in ways that siloed monitoring systems cannot.

Digital twin-based traffic simulation: the core capability

The single capability that most often justifies the investment is digital twin-based traffic simulation. Because the twin mirrors the live network – signal timings, lane configurations, incident status, and real-time flow and occupancy from inductive-loop, radar, and Bluetooth/ANPR sensors – operators can run “what-if” scenarios against current conditions rather than a static historical model. Before a signal-timing plan, a lane closure, a diversion, or a major-event traffic scheme is applied on the street, it is first tested in the twin: microscopic and mesoscopic simulation predicts queue lengths, journey times, emissions, and knock-on effects across adjacent junctions and corridors. The result is a closed decision loop – observe, simulate, validate, deploy – that lets a traffic control centre trial adaptive control strategies, incident-response plans, and roadworks phasing at zero operational risk, and increasingly run them predictively as the model forecasts congestion before it forms. This is where a digital twin stops being a monitoring dashboard and becomes an operational tool: it is the simulation, not the 3D view, that changes decisions and delivers the measured gains in incident response and network performance.

Where the ROI is calculable and genuine

The financial case for digital twin deployment is strongest when three conditions align.

The first is asset density and complexity. A digital twin earns its implementation cost when the infrastructure it monitors is sufficiently complex that meaningful patterns would otherwise go undetected. A single tunnel with standard monitoring equipment probably does not justify a full digital twin deployment on its own. A network of tunnels, urban motorway interchanges, bridges, and associated control systems (traffic management systems, adaptive signal networks, and ITS field devices) – where interactions among asset conditions, traffic patterns, and maintenance schedules create compounding effects – is precisely the environment in which predictive intelligence generates returns that manual analysis cannot replicate.

The second condition is a demonstrable gap between the current maintenance approach and the optimal timing of maintenance. The 35% maintenance cost reduction typically reported for condition-based maintenance programmes achievable through digital twin deployment comes almost entirely from the shift away from schedule-based (calendar-driven) maintenance toward condition-based intervention, aligned with ISO 55000 asset-management practice. If an authority is already running a sophisticated condition monitoring programme with good data, the marginal gain from a digital twin is smaller. If maintenance scheduling is primarily calendar-driven, with limited real-time visibility into actual asset condition, the gap between current spend and optimal spend is wide enough that the platform pays for itself through maintenance savings alone, even within 12 to 18 months.

The third condition is operational scale. Improvements in incident response time of 50% and planning accuracy gains of 85% only translate into meaningful financial figures when operational volume is large enough. A major urban transport authority managing thousands of daily incidents, planned works, and service disruptions generates enormous value from better decision support. A smaller regional roads authority with lower complexity may find that simpler monitoring tools deliver most of the benefit at a fraction of the implementation cost.

Where the business case falls apart

The most common failure mode is what might be called the visualisation trap. Organisations invest in digital twin platforms primarily for the immersive 3D interface – the impressive traffic control centre video wall that shows the entire network in real time. The interface is valuable, but it is not where the financial returns come from. If the underlying data infrastructure is weak (for example, sensors are sparse, data quality is poor, or legacy ITS and SCADA systems lack open interfaces such as DATEX II, NTCIP, or OCIT and cannot reliably feed the model), the visualisation presents an inaccurate picture in an attractive format. Decisions made on that picture are no better than decisions made without it.

The second failure mode is scope mismatch. Digital twin projects that attempt to replicate an entire national infrastructure estate simultaneously routinely underperform. The data collection, calibration, and integration work required to build an accurate model is substantial, and attempting it everywhere at once means doing it poorly everywhere. Projects that begin with a defined, high-value subset of infrastructure (for example a critical tunnel corridor, a congested urban interchange, or a bridge network approaching the end of its design life) and demonstrate measurable returns before expanding regularly outperform comprehensive rollouts in both monetary outcomes and organisational adoption. The third failure mode is treating the digital twin as an IT project rather than an operational transformation. The platform does not generate value by existing, it generates value when operations teams change how they make decisions about maintenance, routing, and incident response based on what it tells them. Authorities that invest in the technology without investing equally in the process change and training required to act on its outputs find themselves with an expensive monitoring dashboard and unchanged operational performance. In an ITS context this means starting with a well-instrumented corridor – a strategic tunnel, an adaptive traffic-signal network, or a motorway control section – integrating its SCADA/OT and traffic feeds first, standing up the traffic-simulation loop, and only scaling the digital twin once the operations team is demonstrably acting on its outputs.

A practical evaluation framework

Before committing to a digital twin deployment, four questions determine whether the business case is likely to hold.

Can you quantify your current maintenance efficiency gap? If the difference between your actual maintenance expenditure and an optimised schedule (based on real asset condition rather than elapsed time) can be estimated with reasonable confidence, the first major ROI stream is calculable. If it cannot be estimated, the data quality problem must be addressed first.

What proportion of your unplanned downtime is attributable to failures that better condition monitoring could have predicted? Not all failures are predictable with current sensor technology. Equipment that fails suddenly without detectable precursor signals does not benefit from predictive maintenance algorithms. Knowing what proportion of your actual downtime falls into the predictable category determines whether the 60% unplanned-downtime reduction figure applies to your specific asset portfolio. In practice, only failures preceded by detectable precursors – bearing vibration, thermal drift, insulation degradation, or current-signature anomalies in pumps, fans, and signal controllers – are addressable by predictive-maintenance models.

Do you have the data infrastructure to feed an accurate model? A digital twin is only as accurate as its inputs. Sparse sensor coverage, inconsistent data pipelines, and poorly integrated legacy systems produce a model that drifts from physical reality over time. The calibration and maintenance effort required to keep it accurate should be scoped explicitly before implementation. For transport estates this usually hinges on standards-based interoperability: without open interfaces such as DATEX II, NTCIP, or OCIT, fusing legacy ITS and SCADA data into a single, calibrated model – accurate enough to drive traffic simulation – is where most of the effort and cost actually lands.

Is your organisation prepared to change operational decisions based on algorithmic recommendations? This is the question that receives the least attention in procurement evaluations and has the most impact on actual outcomes. The technology recommendation is only valuable if the operational response changes. Organisations with strong process discipline and leadership commitment to evidence-based decision-making capture substantially more value from digital twin deployments than those that treat the platform as a reporting tool.

The honest assessment

Digital twin technology in transportation infrastructure is not overhyped, in that its technical capabilities are genuine and the results from well-designed deployments are real. The 12- to 18-month payback period for infrastructure management costs, the maintenance savings, and the incident response improvements: these are achievable under the right conditions.

The hype problem is one of indiscriminate application. Not every infrastructure estate is at the right scale, data maturity, or operational readiness to support those outcomes. The most productive conversation a transportation authority can have with a digital twin vendor is not about the platform’s capabilities. It is about whether the authority’s specific infrastructure profile, data maturity, and operational model create the conditions for those capabilities to produce the projected returns.

Lillyneir’s approach to digital twin deployment begins with precisely that conversation. Our discovery and assessment phase produces an honest ROI model before any implementation commitment is made; mapping use cases to expected value streams, identifying data infrastructure gaps that need to be addressed first, and defining the scope where returns are most clearly calculable. If the numbers do not support the investment, that is worth knowing before the project starts. As an intelligent transport systems (ITS) integrator, Lillyneir maps each use case to the underlying traffic-management, tunnel, and SCADA/OT assets, quantifies the maintenance and incident-response value streams, and flags the DATEX II, NTCIP, and OCIT integration work needed before the model can be trusted. Our TM-Hub platform provides the traffic-management and control-centre layer that feeds live ITS field data into the digital twin and drives the traffic-simulation loop – so scenarios are tested against the authority’s real network, and adaptive strategies validated in the twin before they reach the road.

The fourth power law: what it means in practice

Pavement damage from axle loads does not scale linearly. It follows what engineers call the fourth power law (the load-equivalency principle behind equivalent single-axle loads, or ESALs), established through the AASHO Road Test in the 1960s and validated repeatedly since: the damage caused by a vehicle rises with approximately the fourth power of the axle load ratio relative to the legal limit.

Put concretely: a truck carrying 20% more than its legal axle limit does not cause 20% more damage. It causes roughly twice as much pavement damage per kilometre as a compliant vehicle carrying the same legal load (a load-equivalency factor of about 2.0). A truck at 50% overload causes approximately five times the damage. At double the legal axle weight (a scenario that does occur, particularly in freight corridors with poor enforcement), the damage multiplier reaches sixteen.

This is not a theoretical concern. A single overloaded heavy goods vehicle travelling a 100 km corridor can cause more structural damage to that road surface than several thousand fully compliant passenger vehicles making the same journey. The arithmetic is unambiguous and has clear implications for how transportation authorities should approach weight enforcement budgets.

Where and when the damage shows up

The delay between cause and visible consequence is what makes overloading damage so easy to underestimate. Pavement fatigue is cumulative. A road surface subjected to repeated passes by overloaded axles develops micro-cracking and base-layer deformation (fatigue cracking and rutting) that may not show as visible surface distress for months or years. By the time potholes or structural failure become visible, the maintenance cost is already locked in, and frequently misattributed to weather, age, or design life rather than load exceedance.

This matters because it distorts investment decisions. Authorities that cannot identify overloading as the main cause of damage tend to respond with resurfacing cycles that treat the symptom rather than the cause. The road gets repaved on schedule, overloaded vehicles carry on using it, and the premature deterioration cycle repeats. The maintenance budget absorbs the cost without ever fixing the root cause.

High-speed weigh-in-motion data changes this. When load profiles are continuously recorded across a network by in-pavement WIM sensors (piezoelectric, quartz, or bending-plate), it becomes possible to correlate actual axle-load distributions with detected pavement-condition degradation, fed into the pavement management system (PMS). Corridors with high overloading frequency show accelerated deterioration that statistical analysis can now attribute correctly. That attribution, in turn, justifies investment in enforcement with evidence which connects with finance departments: here is the damage rate, here is its cause, here is the cost of not acting.

Translating the physics into budget figures

The maintenance cost implications vary by pavement type, climate, traffic composition, and base construction, but the order of magnitude is consistent across international road management literature. Overloaded vehicles account for a disproportionate share of unplanned maintenance expenditure on freight corridors; estimates typically range from 30% to 60% of premature pavement deterioration on heavily used commercial routes.

On a major freight corridor handling 5,000 heavy vehicle movements per day, with a non-compliance rate of even 10% (which is conservative for routes without active weight enforcement), the annual pavement damage attributable to overloading runs into figures that dwarf the cost of a WIM system by a wide margin. Infrastructure preservation alone, without counting enforcement revenue or reduced accident costs, typically delivers payback on integrated weight enforcement within two to four years of deployment.

The 25% reduction in road damage from overweight vehicles achieved through WIM enforcement is not a marginal improvement. Applied to a freight corridor where overloading is a primary cause of deterioration, that figure amounts to a substantial deferral of capital expenditure on resurfacing and structural repair. For a national highway authority managing thousands of kilometres of freight routes, the cumulative saving over a ten-year asset lifecycle (whole-life cost, ISO 55000 asset management) is material at the budget level where infrastructure investment decisions are actually made.

The enforcement gap: most authorities are not measuring

Manual weight enforcement, such as spot checks, static weighbridges, and police-directed pull-asides, captures only a small fraction of total overloading events. Coverage is inherently limited: a team operating a static weighbridge can screen perhaps a few hundred vehicles per shift. In a corridor that moves thousands of heavy vehicles per day, the probability of any given overloaded vehicle being subject to enforcement is low enough that rational operators factor it into their logistics costs.

This is the fundamental problem with enforcement models that rely on detection-by-exception. The compliance improvement comes not from catching violators after the fact, but from making detection appear sufficiently probable that operators change their behaviour in advance. High-speed WIM deployed visibly on a corridor, integrated with ANPR and connected to downstream enforcement capability (a virtual weigh station, increasingly with direct, evidential WIM enforcement), shifts that probability calculation. When operators realise that every vehicle is screened on every pass, the business case for overloading deteriorates quickly.

The virtual weigh station: from detection to deterrence

The mechanism that makes this work is the virtual weigh station: a high-speed WIM array in the running lane, paired with ANPR and – increasingly – direct, evidential enforcement, that screens 100% of heavy vehicles at traffic speed instead of sampling a few hundred per shift. Vehicles flagged as overloaded are either guided to a low-speed WIM or static weighbridge for a legally defensible re-weigh, or, where direct WIM enforcement is permitted, penalised on the evidential record itself. Because screening is total and visible, the operator’s expected cost of overloading rises on every pass – and that, rather than the occasional fine, is what actually shifts corridor load profiles. It is the deterrent, not the penalty revenue, that preserves the pavement: under the fourth power law, removing the heaviest outlier axles yields a disproportionately large reduction in structural damage. A visibly instrumented corridor therefore protects the asset, deters non-compliance, and generates the axle-load evidence base in a single deployment.

Weight compliance rates of 85% (achievable with integrated WIM and ANPR enforcement, based on deployed system data) represent a structural shift in corridor load profiles rather than a marginal improvement in compliance. At that compliance level, the fourth power law works in reverse: the reduction in damage from eliminating the heaviest outlier loads is disproportionately large relative to the proportion of vehicles affected.

What the numbers tell decision-makers

The case for investment in weight enforcement tends to be made on safety grounds, projections of fine revenue, or broad infrastructure protection arguments. These are all legitimate, but they often fail to connect with the officials who control maintenance budgets, because the link between enforcement spending and maintenance savings is not made explicit.

The fourth power law makes that link explicit. A transport authority that can demonstrate (with its own WIM data) that a specific percentage of vehicles on a specific corridor are exceeding legal axle limits by specific amounts can calculate the pavement damage cost of that overloading with reasonable precision. That calculation, presented alongside the capital and operating cost of a WIM monitoring system, produces a financial argument that infrastructure asset managers find difficult to dismiss.

The question is not whether overweight trucks are damaging your roads. They are, on any corridor without active weight enforcement. The question is whether the damage rate has been quantified, and whether the enforcement investment needed to reduce it has been evaluated against the maintenance savings it would generate. Most authorities that work through that calculation reach the same conclusion.

Lillyneir’s weight enforcement platform – combining high-speed WIM screening, low-speed confirmation, ANPR integration, and centralised analytics – gives transportation authorities the data infrastructure to make that calculation and act on it. If you want to understand what overloading is costing your network specifically, our team can help you build the analysis from your traffic and maintenance data. As an intelligent transport systems (ITS) integrator, Lillyneir delivers WIM to recognised accuracy classes (OIML R134 / COST 323), links ANPR identification and axle-load spectra to your pavement management system, and can extend screening to evidential direct enforcement (eWIM) and DATEX II data sharing—so a single corridor deployment protects the pavement, deters overloading, and feeds your asset-management (ISO 55000) business case.

This is worth getting right before procurement. The two system types serve different functions, carry different legal implications, and integrate differently with the rest of your enforcement ecosystem. Selecting the wrong one not only wastes budget; it also creates coverage gaps that overloaded vehicles will exploit.

What Low-Speed WIM actually does

Low-speed WIM systems measure vehicle weight at speeds typically between 5 and 40 km/h. High-accuracy sensors – load cells, bending plates, or digital strain-gauge (bar/strip) sensors – embedded in the road surface capture individual axle loads and gross vehicle weight as the vehicle passes slowly over a dedicated weighing platform. The Van Jee LSWIM solution, for example, uses OIML R60-approved digital strain-gauge bar sensors in an interleaved layout and is type-certified to OIML R134 (by NMi, Netherlands), achieving accuracy of roughly ±2.5% at initial verification and ±5% in service. The reduced speed improves measurement reliability, and in most regulatory structures, this configuration produces legally admissible weight data for direct enforcement action – and, where permitted, weight-based tolling (toll-by-weight).

The practical setup is a controlled checkpoint, an entry to an industrial zone, a port gate, a border crossing, or a dedicated enforcement bay on a highway. Vehicles are directed through the measurement zone; the system captures gross vehicle weight and individual axle loads to a legally defensible OIML R134 accuracy class, and violations trigger immediate action: a pull-aside instruction, an automated fine, or integration with an ANPR system to flag the vehicle for inspection.

Low-speed WIM is precise. It is also, by definition, a bottleneck. Every vehicle that passes through the checkpoint slows down. That is acceptable in freight-heavy locations with manageable volumes. On a busy highway corridor carrying mixed traffic, it could be impractical.

What High-Speed WIM actually does

High-speed WIM systems measure vehicles at full traffic speed (up to 80 km/h) without any intervention or lane separation. The sensors (typically quartz or piezoelectric strip sensors) are embedded in the live traffic lane, and the system passively captures weight data as vehicles pass through. The driver is not even aware that the measurement is happening.

This changes the enforcement model entirely. High-speed WIM does not stop vehicles; it identifies them. Combined with ANPR, the system builds a dataset of overloaded vehicles by registration plate, time, location, and load profile. That data feeds into three distinct use cases: selective enforcement downstream (only flagged vehicles are directed to a low-speed checkpoint), statistical load monitoring for infrastructure planning, and repeat offender profiling for targeted regulatory action against specific operators.

The accuracy tolerance of high-speed WIM is wider than that of its low-speed counterpart, typically within 5-15% of the actual axle weight, depending on sensor technology, road surface quality, and vehicle speed (the lower OIML R134 accuracy classes). This is precise enough for pre-selection and statistical analysis. It is generally insufficient to issue a fine directly without a secondary confirmation step, which is why most regulatory systems treat high-speed WIM data as indicative rather than conclusive.

The question authorities usually get wrong

The most common procurement mistake is treating low-speed and high-speed WIM as alternatives when, in most serious deployments, they are complementary. A transportation authority protecting a major freight corridor faces two separate problems simultaneously: it needs to catch individual violations with legal certainty, and it needs to screen thousands of vehicles per day without disrupting traffic flow. Neither system alone solves both.

High-speed WIM handles the screening. It processes the full traffic stream continuously and flags a subset of vehicles for closer attention. Low-speed WIM handles the confirmation and prosecution. The flagged vehicles are directed to a checkpoint where thorough, legally admissible measurements are taken on the OIML R134-certified LSWIM instrument. The result is an enforcement framework that is both complete and operationally efficient: the checkpoint handles a fraction of the total traffic, focusing entirely on vehicles already identified as probable violators.

Where each system stands alone

There are genuine single-system use cases. A port authority managing controlled-access freight entry has no need for high-speed WIM, since every vehicle passes through a gate at low speed anyway, and the checkpoint model fits naturally. A road asset management team that needs load data across a national highway network for pavement design has no enforcement mandate; high-speed WIM sensors at strategic locations provide the statistical picture they need without any checkpoint infrastructure.

The decision matrix is clear. If the primary goal is direct enforcement with legal certainty and volumes are manageable, low-speed WIM at a fixed location (an OIML R134-certified LSWIM such as the Van Jee solution) is sufficient. If the goal is network-wide screening, statistical load monitoring, or pre-selection for downstream enforcement, high-speed WIM is the right instrument. If both goals apply (which is the ideal case for most national highway authorities), the two systems belong together.

The legal dimension

Before selecting either system, authorities need to verify the applicable regulatory framework in their jurisdiction. OIML R 134 sets international standards for WIM instruments used in legal metrology applications, defining the accuracy classes and the type-approval (pattern-approval) route – issued, for example, by NMi in the Netherlands, but national implementation varies significantly. Some jurisdictions permit high-speed WIM data to serve as the sole basis for a fine, with appropriate type approval; others require a low-speed confirmation step regardless of measurement precision. This is not a technology question but rather a legal one, and it directly determines which system architecture is viable for enforcement purposes.

Getting the legal framework right before designing the system architecture saves significant retrofit cost later.

A practical starting point

For most transportation authorities evaluating WIM for the first time, the most productive starting question is not “low-speed or high-speed?” It is “what do we want to do with the data?” Enforcement action with legal certainty, infrastructure load monitoring, operator compliance profiling, and pavement design input each have different data requirements and different system implications. The technology choice follows from the use case, not the other way around.

Lillyneir’s integrated enforcement platform supports both WIM configurations within a unified ecosystem, combining the Van Jee LSWIM solution – OIML R134-certified digital strain-gauge sensors – as the enforcement-grade weighing anchor, alongside high-speed WIM screening, ANPR, edge computing and centralised analytics to provide transportation authorities with complete coverage across enforcement goals. If you are evaluating weight enforcement options for your network, our team can help you map use cases to your system architecture before making procurement decisions.

Simulation, Digital Twins, and Data

Any AI solution worth deploying needs large volumes of high-quality training data. In traffic engineering, simulation is the most practical way to generate that data at scale. Tools such as SUMO (Simulation of Urban Mobility) can model traffic at micro-, meso-, and macro-levels, providing engineers with accurate outputs for everything from a single motorway stretch to a citywide road network. That synthetic data, covering both individual vehicles and the network as a whole, feeds directly into AI training and validation workflows. Multi-objective optimisation adds further requirements: emissions per vehicle or per road segment, accident risk, and fundamental traffic parameters such as density, average speed, and queue length, all of which simulators can produce.

Digital twin technology further improves simulation precision by mirroring the physical parameters of real vehicles as closely as possible. Modern co-simulation environments, where multiple specialised simulators run in concert, create a high-fidelity development sandbox for AI solutions. Game engines such as Unity 3D and Unreal Engine allow engineers to reconstruct complex cityscapes in exceptional detail, providing added context for AI model training.

Figure 1: Complex urban network modelled in SUMO traffic simulation software

Beyond simulation, real-world data remains essential. It can come from embedded road detectors, cameras, navigation systems, or aggregated mobile network data. Measured data fulfils a dual purpose: directly training AI models for traffic estimation and forecasting, and calibrating the simulations themselves.

Figure 2: Co-simulation between SUMO traffic simulator and Unity 3D game engine

Urban Signal Control with AI

AI-based traffic signal control is already moving from research papers toward physical deployment. The dominant approach in leading international research and industry projects is Reinforcement Learning (RL), which adapts in real time to shifting traffic patterns. The state of the art has moved well beyond isolated intersections. Multi-Agent RL systems now coordinate signals across entire urban corridors to maximise network-level throughput. The most advanced implementations fuse V2X communication data with roadside sensor inputs – cameras and LiDAR – for sharper environmental perception. The most significant recent paradigm shift is the incorporation of physics- and rule-based hard constraints, ensuring that neural network choices cannot violate fixed road safety requirements.

Figure 3: V2X and AI-based traffic signal control

The main remaining challenges are scalability and transfer learning: specifically, how to develop a general-purpose solution that works across several intersection types, and how to deploy a pre-trained AI engine quickly at any new location by fine-tuning a foundation model to the geometry and traffic characteristics of each individual junction. Solving this would radically cut engineering hours.

Multi-Objective Route Optimisation

Route choice is a major challenge for autonomous vehicle networks, where individual preference and collective benefit often pull in opposite directions. The question is how self-driving vehicles should select their routes to serve not just the individual driver (minimising travel time) but also a broader social optimum, reducing congestion and managing the network’s total emissions. AI offers a natural framework for this problem.

In this model, each vehicle operates as an independent learning agent, using deep reinforcement learning to continuously monitor its environment and improve its behaviour based on accumulated experience. The balancing act between individual goals and network-wide efficiency is the core design challenge. When the algorithm decides, it is not simply finding the fastest route for one vehicle; it is learning how that vehicle’s movement helps reduce congestion across the urban network. Research results consistently show that AI-based approaches outperform traditional shortest-path routing, particularly when optimising for social rather than individual metrics.

When Vehicles Communicate: V2X Technology

Gathering the volume of real-time data that AI traffic management demands requires a purpose-built communication layer. V2X wireless technology provides exactly that: a standardised, secure framework for vehicles to exchange information with each other and with infrastructure. The latest generation, C-V2X (Cellular Vehicle-to-Everything), extends this connectivity via mobile networks, bringing pedestrians, cyclists, and micromobility users, such as e-scooter riders, into the data-sharing ecosystem. Mobile network coverage means the entire urban environment can be included, with all agents receiving live traffic state information. V2X also enables low-latency exchange of safety-critical data, which is mandatory for autonomous vehicle decision-making and network-level optimisation. As C-V2X deployment scales up in the near term, it will become a core pillar of AI-based traffic management: more data, higher accuracy, greater efficiency.

Context-Aware Solutions: What the Future Holds

The next major leap in traffic management will likely come from integrating Large Language Models (LLMs). Current reinforcement learning algorithms – DDPG (Deep Deterministic Policy Gradient) and MAPPO (Multi-Agent Proximal Policy Optimisation), among them – perform well on numerical optimisation tasks. LLMs add something fundamentally different: the ability to understand complex, semantic context.

An LLM-powered traffic management system could, for example, read and interpret unstructured data feeds, such as news reports about road closures, weather forecasts, or social media posts with traffic implications. Where a conventional algorithm responds only after traffic changes, an LLM can understand the underlying cause of an event and proactively recommend traffic management adjustments before a jam forms.

Widespread deployment still faces real barriers. LLMs are computationally expensive to run, and cloud-based processing adds latency that traffic control cannot tolerate. Edge computing – running the model locally, close to the intersection – is an essential development path. Robustness is the other critical issue: the tendency of current LLMs to hallucinate would represent an unacceptable risk in a traffic management setting, so ongoing research concentrates heavily on hard-constrained output layers, which bound model determinations within mathematically verified safety envelopes.

The most credible way forward is a combined architecture: the LLM handles strategic decision-making and contextual interpretation, while robust reinforcement learning algorithms retain responsibility for safety-critical and tactical operations.

AI Traffic Development at Lillyneir Ltd.

Lillyneir Ltd. is leading the design and implementation of high-tech ITS infrastructure on the M1 motorway between Budapest and Győr – the country’s busiest transit corridor. Alongside lane expansion, the project features a fourth, dynamically controllable ITS lane. Known internationally as “hard shoulder running,” this approach allows the hard shoulder to be used as a traffic lane during peak hours or in incident scenarios, providing flexible capacity precisely when and where it is needed. A digital twin solution is being built as part of this development, simulating the entire system from the traffic management platform down to real-time measurement-based traffic modelling. Safe operation depends on a dense, reliable sensor network, precise traffic detection, software capable of analysing accident risk, and coordinated control of variable message signs. AI runs throughout the system: from automated incident detection and traffic forecasting to decision support for traffic-control interventions.

Lillyneir is also leading a DIMOP PLUS R&D project titled “Development of a Real-Time, AI-Based Complex Traffic Management System.” The project aims to develop a modular, AI-driven traffic management platform that uses real-time data to allow proactive, data-driven interventions in urban traffic control. The system covers infrastructure performance assessment, automatic event detection, and active intervention in traffic flow. Its centrepiece is a vendor-independent middleware-based data platform capable of ingesting sensor data from multiple device types and manufacturers into a unified structure. The platform provides structured storage, continuous preprocessing, and API-based services for traffic management platforms, urban operations centres, and other software modules. A core design priority throughout the project is to ensure the system can interface with existing transport infrastructure using open standards.

“AI hype is intellectual laziness,” says Attila Molnár, CEO of Lillyneir. The company he leads has become a defining systems engineering player in the Central European intelligent transport infrastructure sector. Its multidisciplinary team of more than 30 specialists competes in a field dominated by multinational giants, where current engineering know-how matters more than algorithms alone. AI does play a role in their work. The key question is where AI belongs and how it should be used. Lillyneir’s answer differs sharply from current market fashion.

Origins and momentum

Lillyneir Ltd. was founded in 2011 in Törökbálint, on the western edge of Budapest, originally focused on security technology. The strategic turning point came in 2017, when Attila Molnár joined as owner and repositioned the company from a traditional systems integrator into a systems engineering provider. Commercial momentum followed. Over the next eight years, revenue grew by two orders of magnitude, roughly a hundredfold.

The technology portfolio

Lillyneir develops six interconnected technology pillars: V2X communication systems, AI-powered traffic management, automated enforcement, advanced infrastructure monitoring, autonomous-ready intelligent transport infrastructure, and digital twin environments. Each pillar addresses a concrete operational problem in modern transport infrastructure.

Two live deployments show the approach in practice. A structural monitoring system on the Tomori Pál Bridge in Hungary measures vibrations, dynamic loads, and structural changes in real time, then flags maintenance intervention points from the processed data before visible damage develops. On Road 451 near Orosháza in southeastern Hungary, a certified high-speed weigh-in-motion system measures axle loads of heavy goods vehicles in free-flow traffic with legal-grade accuracy, protecting the pavement, the structure, and other road users.

Why Lillyneir

“We are not bridge engineers, but we have to understand how bridge engineers think. We are not tunnel builders either, but we have to understand the operational challenges of running a tunnel. And all of that has to be translated into the language of IT, electronics, and control engineering,” Attila Molnár explains.

That translation capability is the company’s competitive edge. Lillyneir does not deliver off-the-shelf solutions. Every project starts with a deep analysis of the specific infrastructure problem and produces a tailored engineering answer. The delivery model assigns the most qualified team to each task, drawing primarily on internal competence and bringing in external specialists when the problem demands it.

A second pillar of the model is vendor independence backed by a global supplier network. Lillyneir tracks the most advanced technology solutions from Australia through China to the United States, and often maintains direct working relationships with the local implementation partners executing on the ground. For the client, this means the engineering answer is never constrained by a single manufacturer’s catalogue.

The road ahead

Attila Molnár’s AI critique targets one specific habit: treating AI as the default answer to every engineering problem. The technology itself has clear and legitimate uses in Lillyneir’s portfolio.

Large language models (LLMs) help with certain routine tasks. For control work operating on millisecond decision windows, LLMs do not qualify: their response time cannot be guaranteed, their outputs are non-deterministic, and their error profiles cannot be audited against road safety standards.

“We cannot hand control procedures over to a technology whose runtime we cannot guarantee and whose output is not yet reliably what we need it to be,” Attila Molnár says.

This distinction shapes Lillyneir’s AI strategy. The company applies machine learning where the intended purpose and mode of use justify it. Elsewhere, classical deterministic engineering methods do the work, particularly when safety considerations rule out probabilistic systems.

Lillyneir’s long-term strategic direction follows two reinforcing tracks. Predictive infrastructure management built on real-time data sits at the core of the first, enabling significant cost savings for state and municipal infrastructure owners on maintenance. Beyond that sits infrastructure-side support for Cooperative, Connected and Automated Mobility (CCAM). Safe operation of autonomous vehicles depends on high-reliability digital maps, standardised V2X communication, and real-time traffic management. While the automotive industry builds the vehicles, Lillyneir builds the road network intelligence on which those vehicles can operate safely.

As a sponsor of the 2026 Transport Research Arena conference in Budapest, Lillyneir signals a clear intent. The company is stepping onto the international R&D stage and converting its existing academic collaborations into durable, long-term research and development relationships. These include its partnership with the Budapest University of Technology and Economics (BME) and ongoing university partnerships in the Middle East.

For a broader view of why authorities are moving away from legacy systems, see our earlier article on what automated traffic enforcement is and why it matters.

Transportation authorities need to make the right decisions before procurement starts. Which safety problems should the system address first? How will evidence move through the review process? Can the platform connect with existing systems? What will success look like after launch?

These four questions help structure that decision.

What safety problem should the system solve first?

Every enforcement project should begin with a clear operational objective. Speeding, red-light running, overloaded vehicles, and unsafe behaviour near pedestrian crossings all create different risks, and each requires different detection methods and deployment priorities. A city centre may need red light camera systems and pedestrian crossing enforcement, while a logistics corridor may require weight-in-motion enforcement. A clear use case helps choose the right technology, set measurable goals, and plan for future expansion.

How will evidence and review workflows work?

Detection is only one part of automated enforcement. The system also needs to capture reliable evidence, classify events using AI-based traffic violation detection, and move each case through the appropriate legal or administrative workflow. Authorities should define how evidence will be collected, reviewed, approved, and transferred to downstream systems. Images, timestamps, ANPR license plate recognition data, and system logs all need to support a defensible process, because a weak evidence chain leads to disputes and lower public trust.

Can the platform integrate with existing systems?

Most transportation authorities already operate a mix of traffic management tools, control centres, and legacy enforcement systems. A new traffic management platform must fit into this environment. Which systems need to exchange data with police, municipal departments, or national authorities? How will the platform handle cybersecurity, data protection, and user access? A well-integrated platform connects enforcement data with broader road safety planning and other intelligent transportation systems.

How will success be measured after deployment?

Automated enforcement projects need clear performance indicators, otherwise authorities may struggle to prove value or justify further expansion. A speed enforcement programme may track speed reduction and crash rates, while a red light enforcement project may focus on intersection safety and violation reduction. Operational metrics matter as well, including processing time, manual review workload, and false positive rates.

Public communication also plays a role. Enforcement projects attract scrutiny, especially when citizens see them only as revenue tools. Clear measurement helps authorities show that the project delivers safer roads, better use of public infrastructure, and more consistent compliance.

Partner with Lillyneir on automated traffic enforcement

Automated traffic enforcement delivers strong value when authorities treat it as an operational system. At Lillyneir, we design and deploy automated traffic enforcement solutions for transportation authorities and infrastructure operators. If enforcement modernisation is on your roadmap, let’s talk about how it fits your plans.

Here are five challenges where V2X makes a real difference.

Vehicles cannot see beyond their own sensors

Cameras, radar, and LIDAR have natural limits. A vehicle may miss a hazard around a corner or a fast-approaching emergency vehicle. Vehicle-to-vehicle communication is one of the foundations of cooperative intelligent transport systems, enabling vehicles to share collision warnings, brake alerts, and movement data. A few extra seconds of warning at intersections, high-risk corridors, highway merging areas, or tunnels can be critical.

Pedestrian and cyclist safety is critical

Vulnerable road users move in ways that are hard to anticipate, especially near schools and complex intersections. Vehicle-to-pedestrian communication lets vehicles and roadside units receive warnings about nearby pedestrians and cyclists. This can happen through connected devices, or sensor-based infrastructure that detects vulnerable road users and shares that information with the traffic environment.

The result is earlier awareness on the road. A driver may not immediately see a pedestrian stepping out from behind a parked vehicle, but a connected system can help identify the risk sooner.

Traffic signals lack real-time context

Many intersections still rely on fixed signal plans, but traffic rarely behaves predictably. Demand changes throughout the day, incidents might block lanes, and public transport can fall behind schedule. Vehicle-to-infrastructure communication lets connected vehicles share speed, position, and movement data with roadside infrastructure. Traffic management systems can then support smarter timing, green wave coordination, and priority for selected vehicle types.
This is how authorities move from isolated signal control to adaptive corridor management. Instead of treating each intersection as a separate asset, they can manage traffic flow across a connected corridor.

Emergency response depends on faster coordination

Emergency vehicles lose valuable time when signals cannot support priority movement. Connected infrastructure can detect approaching emergency vehicles and adjust signal timing accordingly, while nearby vehicles receive warnings earlier. This is called emergency vehicle preemption, and cities can evaluate it today on corridors serving hospitals, fire stations, and airports.

For decision-makers, this is one of the clearest V2X use cases. The public value is direct: less time lost in traffic for emergency vehicles, and more resilient operations across the network.

Infrastructure is not ready for autonomous mobility

Autonomous vehicles need more than onboard intelligence. Through vehicle-to-infrastructure and vehicle-to-network communication, transport systems can share real-time information about signal status, hazards, weather, and work zones with automated vehicles. This makes V2X a foundational element of any future autonomous vehicle infrastructure. It improves today’s operations while preparing the network for what comes next.

Autonomous readiness will not arrive through a single upgrade. It requires sensing, communication, edge processing, cybersecurity, and reliable integration between vehicles and infrastructure.

Why V2X deserves decision-maker attention

The real question is not which technology sounds most advanced, but which problems need better coordination. Road safety depends on earlier warnings, traffic signals require real-time context, and emergency vehicles need priority support. By helping the road network communicate, V2X addresses these challenges directly, while it is also one of the core building blocks of next-generation intelligent transportation systems.

Partner with Lillyneir on connected mobility

At Lillyneir, we design and deploy V2X solutions for transportation authorities and infrastructure operators. If V2X is on your roadmap, let’s talk about how it fits your plans.