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.
An Advanced Traffic Management System is the ITS subsystem that observes the road network in real time, decides how it should be operated, and issues the control and information actions that follow from that decision. In the architecture's vocabulary it is the traffic management centre subsystem, together with the roadway field subsystem it controls and the centre-to-centre links to its peers. The proposal below is written for a municipality of moderate size and is organised under the four headings the question sets.
The system's functions divide into monitoring, control, response and stewardship. Surveillance and monitoring is the foundation: continuous measurement of volume, speed, occupancy and queue on the managed network, with camera coverage sufficient to let an operator see any location a detector reports as abnormal. Incident management is the function with the largest measurable benefit, and it runs from automatic detection through operator verification on camera, to notification of police, fire and ambulance, to the implementation of a response plan, to clearance and the return to normal operation; roughly half of urban congestion is non-recurrent, so a system that shortens incident duration attacks the half of the problem that retiming cannot reach. Signal control and coordination covers the operation of the timing plans discussed in Question 2. Lane, speed and queue management covers variable speed limits, lane-use signals and queue-warning on the higher-order roads. Ramp metering applies where the municipality operates freeway ramps. Work-zone and special-event management covers the planned disruptions, which are more numerous than incidents and far more amenable to preparation. Road-weather management covers winter operations and the surface-condition warnings that matter in a Canadian city. Traveller-information generation is the function that feeds Question 4's ATIS. Inter-agency coordination is the centre-to-centre function — transit, police, the provincial highway operator, the neighbouring municipality. Finally, performance measurement and archiving retains the operational data as a planning asset, and is the function that agencies most often omit and most often regret omitting.
The architecture is the conventional three-layer one, and the layers correspond exactly to the architecture's subsystem classes. The field layer holds vehicle detectors, pan-tilt-zoom cameras, signal controllers and, where applicable, ramp meters, dynamic message signs and variable speed limit signs, and road weather information stations. The communications layer binds the field to the centre: a fibre-optic backbone on the primary corridors, leased or cellular service for outlying sites, and 5.9 GHz roadside units where connected-vehicle applications are deployed, all speaking NTCIP to the field and TMDD to peer centres. The centre layer is the traffic management centre itself — a video wall and operator consoles, the ATMS software that performs surveillance, control and incident management, a decision-support function holding the library of pre-planned responses, the archived data system and its performance reporting, and the interfaces to the external agencies. Around all three sits an institutional layer that is not drawn on any diagram but decides whether the system works: the memoranda of understanding with police and transit, the staffing model, the maintenance contract, and the operating budget.
Two architectural decisions deserve to be argued explicitly in a proposal to a municipality. The first is that the centre should be specified against performance and open interfaces rather than against a named product, so that detectors, controllers and software can be replaced independently over the system's life. The second is that the centre should be designed for the staffing the municipality can actually sustain: a video wall that requires three operators around the clock is a liability in a city that can fund one operator on weekdays, and a system that degrades gracefully to automatic operation outside staffed hours is worth more than a more capable one that does not.
The system's data needs follow from its functions, and each has an accuracy, a latency and a coverage requirement that should be stated in the specification rather than left to the vendor. Traffic state data — volume, occupancy, speed, vehicle classification, queue length and turning-movement proportions — is needed at every managed intersection and at system detector stations, with latency of seconds where it drives control and of a minute where it drives information. Travel time between defined points is needed on the corridors on which performance is reported. Signal event data, the high-resolution log of phase and detector state, is needed continuously and is the input to every performance measure. Incident data — location, type, lanes affected, expected duration, responding agencies — is needed as soon as it exists and is largely obtained from other agencies rather than measured. Road-weather and pavement-condition data is needed at the sites where conditions are known to differ from the general forecast. Video is needed for verification rather than measurement. Static network and asset data — the geometry, the lane configuration, the device inventory with its maintenance history — is needed permanently and is what most agencies discover they do not have. Archived data, finally, is the accumulated record, retained indefinitely, from which the annual performance report and the next transportation plan are written.
The technologies divide into intrusive detectors installed in or under the pavement, non-intrusive detectors mounted above or beside the road, probe-based methods that observe the vehicle rather than the road, and the external feeds. The table below sets out the principal choices and what each is actually good for; the engineering judgement in the proposal lies in matching technology to function rather than in adopting one technology everywhere.
| Technology | Class | Directly measures | Strengths and limitations |
|---|---|---|---|
| Inductive loop | Intrusive | Presence, volume, occupancy; speed with a pair | Cheap, accurate, mature; requires lane closure to install and fails with pavement deterioration |
| Magnetometer (wireless) | Intrusive | Presence, volume, occupancy | Small core hole rather than a saw cut; battery life limits service life |
| Piezoelectric sensor and weigh-in-motion | Intrusive | Axle count and spacing, classification, dynamic axle load | The only practical source of classification and weight; sensitive to temperature and pavement condition |
| Microwave radar (Doppler and frequency-modulated) | Non-intrusive | Speed, volume, presence; multi-lane with a side-fire unit | Unaffected by light or weather; side-fire units lose accuracy in heavy congestion through occlusion |
| Video image processing | Non-intrusive | Presence, volume, speed, queue, turning movements | One camera replaces many loops and gives the operator a picture; degraded by low sun angle, snow, fog and shadow |
| Infrared, passive and active | Non-intrusive | Presence, volume, speed, classification | Works in darkness; active units are affected by heavy precipitation |
| Ultrasonic and acoustic | Non-intrusive | Presence, volume, occupancy | Inexpensive; sensitive to temperature gradients and ambient noise |
| LiDAR | Non-intrusive | Position, speed, classification, pedestrian and cyclist tracking | Excellent multi-modal tracking at intersections; higher cost and processing load |
| Bluetooth and Wi-Fi address re-identification | Probe | Point-to-point travel time and its distribution | Directly measures the quantity the traveller cares about; a sample only, and requires an address-hashing privacy design |
| Automatic number-plate recognition and toll-tag readers | Probe | Travel time, origin-destination | High match rates; strong privacy and retention obligations |
| GPS fleet probes and connected-vehicle messages | Probe | Speed and travel time on the whole network, not only at instrumented points | Network-wide coverage without field equipment; penetration-dependent and, if purchased, a recurring cost |
| Cellular network data and crowd-sourced applications | Probe | Speed, congestion and incident reports | Very wide coverage at low agency cost; location accuracy and provenance are outside the agency's control |
| Road weather information station | External | Air and surface temperature, precipitation, wind, surface state | Essential for winter operations; site-specific, so placement decides its value |
| Closed-circuit television | Verification | Nothing numerically — it confirms what a detector reports | Indispensable for incident verification; consumes communications bandwidth and raises privacy expectations |
The recommendation for a municipality of moderate size is a layered one: retain and maintain loops where they exist and are healthy; adopt radar or video for new and rebuilt intersections, since neither requires the road to be closed for maintenance; deploy Bluetooth re-identification on the corridors on which travel time is reported; purchase a probe-data feed for network-wide coverage rather than attempting to instrument every link; and put cameras only where an operator will actually need to look. The archived data function should be specified from the outset, because retrofitting it costs several times what including it costs.
Check: assumed municipal context. The question names only “a Municipality”. The proposal above assumes a Canadian city of moderate size operating its own arterial network with a limited number of freeway ramps, staffing a centre during weekday business hours with automatic operation outside them, and subject to provincial privacy legislation governing any re-identification data. A different scale — a large metropolitan region, or a small town with thirty signals — would change the staffing model, the communications choice and the case for adaptive control, though not the functional list or the architecture.
