16-Civ-B17 Intelligent Transportation Systems · December 2017
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Paper format. National Examinations, December 2017 — 16-Civ-B17 Intelligent Transportation Systems (ITS). Three-hour, open-book examination; any non-communicating calculator is permitted. Five questions are printed and the paper directs that all five be answered, all carrying equal weight, so each question is worth 20 points and the paper totals 100. The printed grading scheme is Q.1 (a) 2+8, (b) 10; Q.2 20; Q.3 20; Q.4 20; Q.5 (a) 12, (b) 8. The paper further directs that answers be given in essay format supplemented by illustrations (such as flow charts, process diagrams, etc.) and states that clarity and organization of the answer are important — presentation is itself examined here, which is why every answer below carries a purpose-built diagram. Candidates are invited to state any assumption made where the interpretation of a question is in doubt.
Reference texts.
Source note — the marks line in Q.1(a). The paper prints the marks for Question 1(a) as “(2+8 = points)”: the total has dropped out in printing. The arithmetic and the paper's own instruction that all questions carry equal weight fix the value: 2 + 8 = 10 points for (a), 10 points for (b), 20 points for Question 1. The answer below is proportioned accordingly.
Canadian context. Question 1(a) explicitly asks for the U.S. National ITS Architecture, so that is what is answered there, in the architecture's own vocabulary. Everywhere the paper does not name a jurisdiction — Questions 2 to 5, which are set in “a Municipality” — the answer is written in the Canadian frame: the ITS Architecture for Canada, MUTCDC devices and signal practice, TAC geometric guidance, provincial highway and privacy legislation, and Canadian transit examples.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Because this question is set explicitly as an extension of Question 3, the first thing the answer must do is say what is genuinely new. The ATMS already collects the network state, already detects and verifies incidents, and already owns dynamic message signs. What the ATIS adds is a different purpose for that data and a different audience: the ATMS acts on the network, while the ATIS acts on the traveller, and influencing a traveller's decision requires prediction, personalisation, wide dissemination and a level of trustworthiness that operational control does not. In architectural terms the extension introduces one new subsystem, the Information Service Provider, together with the wide-area wireless interface class that reaches travellers wherever they are. It also introduces a set of institutional obligations — data-sharing agreements, an open-data licence, a privacy regime for any probe data and a liability position on the advice given — that had no counterpart in the ATMS proposal.
The ATIS functions map almost one for one onto the traveller-facing user services of the Travel and Traffic Management bundle. Pre-trip travel information lets a traveller decide, before leaving, whether to travel, when, by which mode and by which route; it is the function with the greatest network benefit per user informed, because a decision not yet committed is cheap to change. En-route driver information delivers conditions ahead to a traveller already committed to a trip. Route guidance converts information into an instruction, and requires a network model and a prediction rather than merely a measurement. Ride matching and reservation supports carpooling and shared modes. Traveller services information covers the non-network content — parking availability and price, fuel and charging, park-and-ride capacity. Transit information supplies real-time arrival predictions, which is where the ATIS meets Question 5's APTS. Incident, weather and event alerting pushes exceptional conditions to travellers who have asked to be told. Predictive and personalised advice is the mature form of the service: not what conditions are now, but what they will be when this particular traveller arrives, on the route that traveller habitually uses.
The architecture is a collect–fuse–disseminate chain with the Information Service Provider at its centre. On the collection side the sources are the ATMS itself (detector volumes and speeds, verified incidents, planned closures, signal status), the transit agency's real-time feed, road weather stations and the meteorological forecast, purchased or crowd-sourced probe data, the parking system, and the municipality's own permit and special-event databases. On the processing side the Information Service Provider performs conflation of these sources onto a single network model, quality control and outlier rejection, fusion into one best estimate per link, short-term prediction, trip planning and route computation, and the personalisation and alerting logic that decides which traveller is told what. On the dissemination side the channels are dynamic message signs and highway advisory radio for the committed driver; a 511 telephone service and an agency web site for the general public; mobile applications and push alerts for the registered user; in-vehicle navigation and, increasingly, connected-vehicle traveller information messages broadcast to equipped vehicles; and transit stop and station displays.
A design decision worth arguing in the proposal is how much of this the municipality should build. The dissemination channels with the widest reach — the mapping and navigation applications people already use — are not owned by the agency, and the cheapest route to a large audience is usually to publish an authoritative open feed and let those applications consume it, reserving the agency's own build for the channels only it can provide: the signs on its roads, the 511 service, and the authoritative record of its own closures and events. The feedback loop shown on the diagram is real and worth stating: travellers who respond to information change the conditions being measured, so a system that ignores the response will systematically mispredict, and a system that gives every traveller the same diversion advice will simply move the queue.
The ATIS needs everything the ATMS needs, plus prediction inputs, plus content the ATMS has no use for. Specifically: current link speeds and travel times, and predicted values for the horizon over which a traveller will actually arrive, which is typically fifteen to sixty minutes and is a different product from a current measurement; incident and closure records with an estimated duration and an estimated clearance time, since a duration estimate is what allows a traveller to decide whether to divert or wait; planned works and special events with their start and end times; weather and road-surface condition; transit vehicle position, predicted arrival and service disruption; parking occupancy and price; toll and fare information; and an accurate, current static network map with turn restrictions, because route guidance computed on a stale map is worse than no guidance. Each item carries quality attributes that decide whether the service is used at all: accuracy, latency, spatial coverage, update frequency and, above all, consistency between channels — a message sign that contradicts the mobile application destroys confidence in both.
The acquisition technologies are largely those of Question 3, re-used at no extra capital cost, which is the strongest argument for adding the ATIS to an existing ATMS. The additions specific to the ATIS are the probe and crowd-sourced feeds, which give network-wide coverage that point detection never will; the transit agency's automatic vehicle location feed, published in the General Transit Feed Specification real-time format; parking occupancy sensing, whether by in-bay sensors, by entry and exit counting at structures, or by payment-transaction inference; road weather stations and the meteorological service's forecast products; and, for prediction, the archived data that the ATMS was already told to retain, since a short-term forecast is built from the historical relationship between current state and subsequent state at that place and time. Connected vehicles are the emerging acquisition path and the emerging dissemination path simultaneously.
The recommendation is to acquire nothing new that can be obtained by agreement instead. A data-sharing memorandum with the transit agency, the provincial highway operator and the neighbouring municipality typically yields more usable content than any capital purchase, and the reciprocal obligation — publishing the municipality's own data in an open, documented, licensed feed — costs little and multiplies the reach of the service through channels the municipality would otherwise have to build.
Check: privacy and liability assumptions. The proposal assumes that any re-identification technology (Bluetooth, Wi-Fi, plate recognition) is deployed with irreversible hashing at the roadside and a short retention period, and that the personalisation function stores traveller preferences under an explicit consent regime, consistent with Canadian federal and provincial privacy legislation. It further assumes that published advice carries a stated information-only position rather than a warranty of accuracy. Both assumptions are policy decisions for the municipality's solicitor, not engineering ones, but the architecture must be designed for whichever way they are decided.
