When transportation authorities evaluate intelligent traffic systems, the conversation typically focuses on what the technology does: detecting incidents, optimising signal timing, communicating with vehicles (V2X, including SPaT\/MAP signal messages), and predicting congestion. What receives less attention is where the computation happens, and within safety-critical applications, that question matters more than most procurement specifications acknowledge.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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 \u2014 increasingly a GPU\/NPU-equipped node running on-device inference \u2014 receives sensor data, runs the relevant algorithms locally, and issues the actuation command without waiting for a round-trip to a central server.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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?<\/p>\n
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 \u2014 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.<\/p>\n
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.<\/p>\n
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.<\/p>","protected":false},"excerpt":{"rendered":"
In intelligent transport systems (ITS), edge computing is now a safety requirement, not an option. Learn why cloud-only architectures fall short on the sub-100 ms latency that V2X and signal safety demand.<\/p>","protected":false},"author":4,"featured_media":2263,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Edge Computing: Why cloud alone isn't enough for ITS","_seopress_titles_desc":"In intelligent transport systems, edge computing is now a safety requirement, not an option. Learn why cloud-only architectures fall short on the sub-100 ms latency that V2X and signal safety demand.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[8],"tags":[],"class_list":["post-2262","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-article"],"_links":{"self":[{"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/posts\/2262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/comments?post=2262"}],"version-history":[{"count":1,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/posts\/2262\/revisions"}],"predecessor-version":[{"id":2264,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/posts\/2262\/revisions\/2264"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/media\/2263"}],"wp:attachment":[{"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/media?parent=2262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/categories?post=2262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lillyneir.com\/ar\/wp-json\/wp\/v2\/tags?post=2262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}