concept of operations functional requirements system design€¦ · functional requirements system...

Third-Gen CARS-Segment

Concept of Operations Functional Requirements

System Design

Prepared by:

Castle Rock Associates

Prepared for: Minnesota Department of Transportation

June 30, 2015

Final Third-Gen CARS-Segment_SDD_08m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 2

Document Version History

Version Author Date Change Notes

1 pd 8.7.14 First draft based on Abby’s work with Iowa.

2 pd 8.10.14 Second draft following 8/8/14 phone conference.

3 pd 8.13.14 New design concept.

4 pd 8.17.14 Finished up new diagrams. Sent to Iowa.

5 pd 8.18.14 Adding feedback from Iowa.

6 pd 8.23.14 Added Segment Location Tool changes. Finalized for

submission and build.

7 du 12.11.14 Added appendix for MN configurations

8m du 6.30.15 Updated for MnDOT final submission


Table of Contents

CONCEPT OF OPERATIONS ................................................................................................................... 1

FUNCTIONAL REQUIREMENTS............................................................................................................ 1

SYSTEM DESIGN ....................................................................................................................................... 1

1. CONCEPT OF OPERATIONS ............................................................................................................... 4

2. SYSTEM REQUIREMENTS .................................................................................................................. 8

2.1 OVERVIEW ............................................................................................................................................ 8 2.1.1 Capacity expansion ...................................................................................................................... 9

2.2 LOGIN AND PERMISSIONS ....................................................................................................................10 2.3 USER INTERFACE REQUIREMENTS .......................................................................................................10

2.3.1 Segment attributes .......................................................................................................................11 2.3.2 Segment display ..........................................................................................................................11 2.3.3 Segment selection ........................................................................................................................12 2.3.4 Condition Descriptors .................................................................................................................12 2.3.5 Contingent categories .................................................................................................................13 2.3.6 Duration and expiry period .........................................................................................................13 2.3.7 List views .....................................................................................................................................13 2.3.8 Editing restrictions ......................................................................................................................14

2.4 MAP DISPLAY REQUIREMENTS ............................................................................................................14 2.5 SYSTEM REQUIREMENTS .....................................................................................................................15

3. DETAILED DESIGN ..............................................................................................................................16

3.1 GENERAL REQUIREMENTS ...................................................................................................................16 3.1.1 User Access .................................................................................................................................16 3.1.2 Event report transfer into CARS .................................................................................................17

3.2 CARS SEGMENT TOOL CHANGES ........................................................................................................17 3.2.1 Segment numbering .....................................................................................................................18 3.2.2 Segment boundary names ............................................................................................................18

3.3 SEGMENT REVIEW FUNCTIONS ............................................................................................................21 3.3.1 Initial segment definition screen—local users ............................................................................22 3.3.2 Initial statewide user screen .......................................................................................................24 3.3.3 More search functions .................................................................................................................26 3.3.4 Conditions ...................................................................................................................................26 3.3.5 Segment and event times .............................................................................................................28 3.3.6 Event priorities ............................................................................................................................29

3.4 CHANGING SEGMENT CONDITIONS .......................................................................................................29 3.4.1 Entering condition values ...........................................................................................................31 3.4.2 Contingent categories .................................................................................................................34 3.4.3 Phrase sequencing ......................................................................................................................39

3.5 DATA EXCHANGE WITH CARS ............................................................................................................39 3.5.1 Data Flow ...................................................................................................................................39 3.5.2 Segment Aggregation ..................................................................................................................39 3.5.3 Segment IDs and URLs ...............................................................................................................39 3.5.4 Report Expiration ........................................................................................................................40

APPENDIX A: CATEGORIES AND DESCRIPTORS BY AGENCY ..................................................41

A.1 IOWA ...........................................................................................................................................41 A.1.1 Iowa Categories and Phrases ................................................................................................41

A.2 MINNESOTA ................................................................................................................................43 A.1.1 Minnesota Categories and Phrases .......................................................................................43


1. Concept of Operations

Public agencies use CARS (Condition Acquisition and Reporting System) as a reporting tool for transportation-related event and condition reports. Examples of CARS events include traffic and travel-related incidents, road condition information, special events, evacuations, homeland security alerts, and natural disasters. The CARS software maintains a current events and conditions database, and allows the exchange of event information with other centers and subsystems. Various add-on modules facilitate the sharing of traffic/travel event data with the public via 511 phone systems, the Web, and email/pager/text message notifications.

The standard CARS user interface allows operators to enter an event location as any single roadway point or any stretch of state highway. Local road data entry is also supported in CARS 4. This flexibility allows operators to select locations ranging from individual points to long stretches of road. Named geographic areas can also be event locations in CARS 4 and CARS-CAP (a CARS input software module that imports weather warnings conveyed via the NWS Common Alerting Protocol). A CARS location database known as CARS-Location stores the geographic information that is common to all CARS modules. Many CARS agencies also need to enter specific types of events for pre-defined roadway segments—typically fixed in relation to groups of snow plow routes used by maintenance operators. The CARS-Segment software provides a simple and intuitive web-based interface to enable authorized operators to quickly and easily enter winter road conditions into CARS. It also aggregates identical conditions on adjacent winter road reporting segments in order to streamline the number of events in CARS at any given time, helping to reduce “clutter” in CARS, CARS-Web, and CARS-511. CARS-Segment stores each state’s predefined segments and cross-references them to the common CARS-Location database using route numbers and linear references. TG-Segment will adopt the same approach, based upon state DOT linear references and designated route numbers.1 Although the initial CARS-Segment project (around 2003/4) was a multi-state collaborative effort among Idaho, Iowa, and Maine, each state had different procedures and requirements for reporting winter weather. For example, each state used different terms for describing road and weather conditions. In addition, some agencies report road conditions but do not include a weather report, while others do both. Also, agencies had different methods for entering the geographic location of the event—some reported by area, and others by road segment or group of segments. CARS-Segment was designed to take advantage of the similarities between the agencies’ requirements, while still allowing agencies to maintain their individual reporting styles and procedures.

1 Until recently it had been thought that TG-Segment would need to drop its use of linear references because OSM (Open Street Map) imports would make these subject to frequent change. Now a method has been proposed for preserving current CARS linear reference data in successive updates of TG-Location, with changes being made to these data only when the source linear references are changed by a DOT.


Iowa has now begun the development of a Third-Gen CARS-Segment module (TG-Segment). At launch, data entry was carried out by state patrol at the “communications area” level, dividing the state into six regions for reporting purposes. Specific coverage phrases used in Iowa include normal, wet, partially covered, mostly covered, completely covered, and impassable/road closed. Coverage type includes options for frost, ice, snow, slush, and mixed cover. Iowa also allows users to check options for reporting visibility no more than 1/8th of a mile, dense patchy fog, or white out; blowing or drifting snow; icy bridges; or travel not advised. In 2010, Iowa revised all of its segments to support more easily understood segment boundaries in its 511 reports. Later, in 2013, IADOT took over reporting responsibilities from the Iowa State Patrol. New reporting procedures were developed that included the use of wirelessly connected tablets in the field. Some performance problems then emerged in CARS-Segment with slow system responses after data entry. These are thought to result from the larger numbers of segments (>1000) and much larger numbers of data enterers than before. Iowa also updates every segment in the state every couple of hours to create new timestamps without changing any other values. Minnesota has also added a lot of segments and had reported some slowness. The other states such as Idaho (with only a few hundred segments) say that no slowness has been observed. Now, in Iowa (and potentially in Minnesota), TG-Segment will further enhance and optimize winter condition reporting, and will generally refresh the software with emphasis on tablet users. The re-architected TG-Segment module will address improvements to the system performance and the modernization of the user interface graphics. The potential advantages of a mobile tablet version are manifold. Currently CARS-Segment—designed only for use on PCs—requires clicking many checkboxes and other small controls. A mobile web site will enable the creation of big, clickable touch-screen buttons that will be easier to press even while wearing thick, heavy-duty winter gear. Returning to the history, in 2011, three CARS-Segment states—Iowa, Idaho, and Minnesota—decided to develop a Segment Tool for configuration management, so that they could manage and maintain their winter and pass closure segment boundaries in-house. The CARS Segment Location Tool (part 1 of a new TG-Location module) is independent of CARS-Segment. It enables states that deploy it to manage their own fixed roadway reporting segment names and boundaries for CARS-Segment. Some CARS-Segment agencies require annual changes to their roadway segment definitions—e.g., segment start/end points need to be adjusted; segment names need to be changed; new segments must be added; existing segments have to be combined, grouped, or removed altogether, etc. The segment management tool allows authorized users to make changes to predefined segments at the start of each winter season. Now, in September 2014, Mn/DOT will join Iowa in the development of the TG-Segment software. Castle Rock will enhance Mn/DOT’s existing segment winter driving software with a new HTML5 app that takes account of its changes in operating environment—mainly the increased numbers of segments. An app—unlike a standard web site—is always accessible, even when no Internet connection is available. Thus, snow plow operators and


other in-field personnel will still be able to perform data entry using the Segment App, even if there is no data service. Then, when the tablet is able to connect to the Internet again—either through a cellular or a Wi-Fi link—the data entered in the field will be uploaded to the system. The Mn/DOT TG-Segment App (Phase 2 of this effort) will work on laptops and on tablets as well as on PCs; it will allow data entry by people at the home office and out in the field (wearing winter driving gear); and it will support data entry that is easy for the DOT and also meaningful for the public. Originally, the new Iowa and Minnesota systems were to have been implemented and made fully operational in time for the 2014-2015 winter reporting season. Now, after contracting holdups in Minnesota, and delays in obtaining Iowa operational users’ inputs, this is no longer possible. Instead a phased deployment of TG-Segment is proposed, with some performance enhancements being put in place by October 2014, and a re-launched TG-Segment later in the winter—all new features completed by June 2015, if possible. The Minnesota project will be completed within one year of receiving notice to proceed. A third project being funded by all the CARS states under the MU (Maintenance Updates) program will interact with TG-Segment as follows. The common CARS-Location database is being upgraded to a TG-Location version that will replace old state DOT GIS data with geographic data sourced from OpenStreetMap (OSM). An addition to this work now partially funded in MU Year 3 is a Linear Reference System (LRS) Importer. The CARS LRS importer will be very important in ensuring stability of TG-Segment definitions, as explained below. Although OSM has been chosen as the base data for public location descriptions, a few CARS-Location data elements required by state agencies cannot be found in OSM. Perhaps the most important of these is Linear Referencing System (LRS) data. LRS is defined in each state by a reference system such as ESRI Roads and Highways or an AgileAssets Network Manager. Iowa uses its own bespoke system known as MLLRS (Multi-Level Linear Referencing System). Local agencies such as counties may use other reference systems. Idaho has funded an initial state DOT LRS importer that will allow for flexibility and manual intervention where automated solutions cannot fully meet the agencies’ key goals. In July 2014, Iowa also joined this TG-Location LRS imports effort as part of its Year 3 MU effort. The two task orders are funding the planning and development of an open standards import framework for bringing linear references into TG-Location using data consistent with that of its existing statewide deployment. Depending on the availability of suitable milepoint data, the new import tool will work in either a facilitated manual or semi-automated mode. Its goal is to allow states to maintain and update their existing CARS-Location linear references—including “DOT miles” (“DOTm”)—keeping future CARS 5 milepoints synchronized with those of the state’s master reference systems. This work should also help ensure that CARS-Segment’s segment boundaries (defined by linear references) are not significantly changed by the adoption of OSM location data. In August 2014, a technical approach was identified that will import the standard LRS and DOTm data already used in the existing CARS-Location module, bringing it forward for


reuse with OSM imports. Existing CARS-Location milepoints will be merged with OSM centerline and cross-street data in a new, composite TG-Location database. The Idaho/Iowa work will pilot a prototype importer that will merge milepoints with the OSM data in TG-Location. The work will be closely coordinated with and supported by related work on GIS system data exchanges that is slated to take place in Indiana. The Indiana work (if funded) would go further than the Idaho/Iowa work by supporting the fully automated updating of LRS and DOTm imports when mileage definitions change, from at least that state’s source reference systems.


2. System Requirements

Priority 1 work will focus on performance improvements planned for deployment at the start of the 2014 winter season. Priority 2 work addresses Iowa’s needs for a mobile web site suitable for use on tablets. Priority 3 will cover Mn/DOT’s proposed Segment App, and (if required) further work on optimizing performance in both states. TG-Segment will be required to meet 100% of the applicable critical requirements and at least 80% of the applicable lower-level requirements, excluding those described as future enhancements. Critical requirements are those marked with a “ * ”.

2.1 Overview

Functional Requirements Priority Build

1. TG-Segment shall support the quick entry of winter driving conditions for pre-defined roadway segments.*

1 1.0.0-alpha-5

2. The module will comprise a web-based software application, wholly separate from CARS 4 and 5.

1 1.0.0-alpha-5

3. TG-Segment shall create event reports by aggregating identical conditions on adjacent segments along a designated route.*

1 1.0.0-alpha-5

4. TG-Segment shall pass the aggregated event reports one-way to the CARS 4/5 event database, “TG-Event”.*

1 1.0.0-alpha-5

5. TG-Segment event reports in TG-Event shall continue not tracking any event histories.

1

6. Starting at 1, segments shall be uniquely numbered sequentially in the positive direction along each designated route.

2 1.0.0-alpha-5

7. TG-Segment event reports in TG-Event shall be identified by a new, unique event ID based on the new segment numbers.

2

8. The new event ID shall comprise the route designator, the start segment number and the end segment number.

2

9. FEU update numbers will now be used to distinguish between old and new versions of a given event ID.

2

10. To handle more users and more segments, steps shall be taken to increase system capacity as described below.*

2 1.0.0-alpha-5

11. TG-Segment shall be designed to run on wirelessly connected HTML5 compatible tablets as well as on computers (PCs).*

2 1.0.0-alpha-5

12. Minnesota’s TG-Segment will be available in the form of a mobile app as well as being available as a web site.*

3 1.0.0-alpha-5


2.1.1 Capacity expansion

13. When an operator applies changes, TG-Segment shall no longer wait for all affected events to be changed before responding.*

1 1.0.0-alpha-5

14. Instead the changes shall be placed in a queue, to be completed by CARS-Event as soon as possible.

1 1.0.0-alpha-5

15. Thus, multiple users can now make updates simultaneously without waiting for other users’ changes to be completed.

1 1.0.0-alpha-5

16. When conditions change without altering the event ID (event boundaries), CARS-Event shall now simply update the event.

1 1.0.0-alpha-5

17. This update shall change the event’s description, update time and update # without keeping the old event record in CARS-Event.

1

18. Only when aggregation patterns change shall affected event reports now be deleted and new aggregated event reports be created.

1 1.0.0-alpha-5

19. In this case, impacted old event reports shall be marked as deleted, with new event reports being created in parallel.

1 1.0.0-alpha-5

20. A housekeeping routine shall run continuously in CARS-Event removing Segment marked as deleted events as soon as possible.

1 1.0.0-alpha-5

21. This routine shall be distinct from the CARS 4 housekeeping routine that removes marked CARS 4 events >48 hours old.

1 1.0.0-alpha-5

22.

If a new event is now created with a yet-to-be deleted marked as deleted event’s boundaries (i.e., sharing the same event ID), the new update # shall be incremented relative to its old value.

1

23. Upon selecting conditions unchanged, all impacted events shall now be updated instead of deleting and recreating the events.

1 1.0.0-alpha-5

24. These updates shall change the event’s update time & update # without keeping the old event record in the database.

1

25. The update time of the last “real” segment condition change (not just a timestamp change) shall be tracked for each segment.

2 1.0.0-alpha-5

26. The last confirmation time (whether new conditions are entered or conditions are unchanged) shall be tracked for each segment.

2 1.0.0-alpha-5

27. These two segment times may both be earlier than the event report’s last update time, which equals the latest confirmation time of any segment in the aggregated event.

1 1.0.0-alpha-5

28. If the above solutions don’t solve Iowa’s performance problems, only a new statewide confirmation time shall be updated when conditions unchanged is entered statewide.

3 1.0.0-alpha-5


29. All CARS public-facing modules would then display the most recent local or statewide confirmation time as events’ timestamps.

3 1.0.0-alpha-5

2.2 Login and Permissions

Functional Requirements

30. TG-Segment shall require users to log in with a username and password.

1 1.0.0-alpha-

5

31. Users shall require the privilege “TG-Segment access” to be able to log into TG-Segment and create or view events.

1

32. TG-Segment shall use the CARS 4/5 user database as its reference for validating usernames and passwords.

1

2.3 User Interface Requirements


33. At this time, only winter road condition reporting shall be supported in TG-Segment.

1 1.0.0-alpha-

5

34. In the future, TG-Segment may be able to support other, distinct operating functions, e.g., predefined closures.

N/A

35. In TG-Segment, users can enter winter reports for predefined segments.

1 1.0.0-alpha-

5

36. Each event report created through TG-Segment shall include a description, a location and a last updated time.

1 1.0.0-alpha-

5

37. All predefined segments shall be bidirectional, covering both directions of travel.

1 1.0.0-alpha-

5

38. In the future, separate data entry may be allowed for each direction of travel.2

N/A

39. The predefined segments shall have been created in the CARS Segment Location Tool, which is part of TG-Location.

1 1.0.0-alpha-

5

40. TG-Segment shall define segments using LRS (linear reference) values along each designated (numbered) route.

1 1.0.0-alpha-5

41. When TG-Location is populated from OSM, existing LRS 2 1.0.0-

2 Caltrans I-80 chain controls (now deprecated) had separate segments in each direction. All other routes are currently bi-directional. TG-Web, LB-Web and CARS 4 cannot currently show different winter painted colors for each direction.


values shall have been imported from CARS-Location. alpha-5

2.3.1 Segment attributes

42. Each predefined segment shall have a free text name, defined in the CARS Segment Location tool.

1 1.0.0-alpha-

5

43. The CARS Segment Location tool shall ensure that segments don’t bridge across jumps or breaks in the designated route.

1 1.0.0-alpha-

5

44. In TG-Segment, each predefined segment shall no longer have a “long” geographic name.

2 1.0.0-alpha-

5

45. The long geographic name will now only be available in the CARS Segment Location tool that is used to define segments.

2 1.0.0-alpha-

5

46. A system-defined reference that begins with the numeric route designator (e.g., 80) shall define each segment.

2 1.0.0-alpha-

5

47. If Kentucky joins TG-Segment, dummy alphabetic route designators shall be assigned to un-numbered parkways.

2 N/A

48. Each system-defined reference code shall end with the segment’s sequential segment number (e.g., 80-17).

2 1.0.0-alpha-

5

49. Users can search for segment(s) by road and segment number, road and segment range, and by its local area/subarea name.

2

50. Searchers shall see the local subarea view that includes this segment.

2

51. At the subarea (garage) level, users shall immediately see their own local view as the default, without searching.

2 1.0.0-alpha-

5

2.3.2 Segment display

52. A segment display shall indicate whether a segment is due to be updated, or its report has already expired.

1 1.0.0-alpha-

5

53. Local users shall be able to see summary conditions along their designated routes, centered on their local segments.

2 1.0.0-alpha-

5

54. Users who searched for roads/segments shall see summary conditions on those roads, centered on those segments.

2

55. Users can opt to see the detailed conditions posted for all segments along displayed roads.

2 1.0.0-alpha-

5

56. Segment conditions shall be color-coded to match the condition display color to be shown to the public.

2 1.0.0-alpha-

5

57. TG-Segment users shall be able to see jumps/breaks on roads that prevent segment aggregation.

2 1.0.0-alpha-

5


58. Users can opt to see the free text segment names of segments along displayed roads.

2 1.0.0-alpha-

5

59. Users can opt to see the details of when displayed segments were updated and confirmed, and by whom.

2 1.0.0-alpha-

5

2.3.3 Segment selection

60. Users shall be able to select multiple segments to which a condition update shall apply.

1 1.0.0-alpha-

5

61. Users shall also be able to select all segments on a route or in an area (including statewide).

1 1.0.0-alpha-

5

62. TG-Segment shall allow users to add to or remove segments from any selected group of segments.

1 1.0.0-alpha-

5

63. A new counter at the top of the page shall remind users how many segments they have selected for each update.

2 1.0.0-alpha-

5

64. The new system reference codes will remind users which segments they have selected (e.g., 29-7-8, 80-1-4).

2 1.0.0-alpha-

5

2.3.4 Condition Descriptors

65. 12

Users shall begin to edit conditions by selecting one or more descriptors from at least one initial descriptor category.

2 1.0.0-alpha-

5

66. Each agency shall be able to determine the actual reporting descriptors (categories/values) displayed in their deployment.

1 1.0.0-alpha-

5

67. Descriptors can include up to ten3 condition values per category. 2 1.0.0-

alpha-5

68. Each segment condition shall become part of a winter driving event report for that route.

1 1.0.0-alpha-

5

69. Selected categori(es) can be made mandatory, in that a value must be selected.

1 1.0.0-alpha-

5

70. Other categori(es) can be optional, users being given the option of not selecting a value for that category.

1 1.0.0-alpha-

5

71. The interface shall be able to control whether only one or more than one descriptor can be entered from a category.

1 1.0.0-alpha-

5

72. There are no current plans (per FG-Segment) for descriptors that comprise numeric values instead of condition statements.

2 N/A

73. There are no current plans for entries to create two events per route—e.g., one truckers’ report and one general report.

2 N/A

3 In TG-Segment, the number of allowed values per category will be reduced from 20 to 10, to help reduce screen clutter, allow bigger buttons and simplify the information given to the public.


2.3.5 Contingent categories

74. “Contingent” categories can be opened for selection if specific descriptor(s) are chosen from a prior category.

1 1.0.0-alpha-

5

75. For example, in Iowa, “partly” or “completely” covered opens “with what?” in a contingent category.

1 1.0.0-alpha-

5

76. Similarly, “impassible” causes web text and phone text to appear as optional entries.

1 1.0.0-alpha-

5

77. TG-Segment shall also be able to disable a category if a particular descriptor is selected from a prior category.

1 1.0.0-alpha-

5

78. TG-Segment shall be able to map TMDD phrases to the combination of conditions selected from two categories.4

1 1.0.0-alpha-

5

79. TG-Segment shall avoid duplication of words when detailing the prior categories selected.

2 1.0.0-alpha-

5

80. In the future, contingent categories may contain TMDD causes (for example, if a road closure has been picked).5

N/A

2.3.6 Duration and expiry period

81. TG-Segment event reports’ durations/end times shall be ‘until further notice”, passing on no end time info to travelers.

1 1.0.0-alpha-

5

82. A fixed (silent) expiry period shall be the default in each state. 1 1.0.0-

alpha-5

83. A two-hour grace period (configurable) shall be added to each CARS-Segment expiry time.

1 1.0.0-alpha-

5

84. In Iowa, the fixed expiry period shall be until further notice (i.e., no automated expiry).

1 1.0.0-alpha-

5

85. There are no current plans for operators to continue to be able to select a (silent) expiry period for their segment reports.

2 N/A

86. If closure segments are later added for Idaho, there shall be two fixed expiry periods: 1 day for winter reports, and until further notice (no automated expiry) for closures.

N/A

2.3.7 List views

87. Each user shall be assigned to one area—statewide, to a 1 1.0.0-alpha-

4 In Iowa, the local phrase “partly covered with snow” is formulated by concatenating the Category 1 “partly covered” selection with the Category 2 “snow” selection. 5 This feature was added by ITD as a later enhancement to CARS-Segment, allowing the inclusion of event causes in the specific case of road closures. Initially this is not required, but it may be needed later if Idaho joins TG-Segment.


specific area or to a specific sub-area. 5

88. Users shall be able to see a list of all roadways. 2 1.0.0-

alpha-5

89. Area and roads trees shall no longer be used in TG-Segment 2 1.0.0-

alpha-5

90. In the future, the areas list may optionally be able to be set up so that there are 3 or 4 levels of state/area/subarea reporting.

N/A

91. If Idaho joins, a separate roads list may handle frequent closures. (It will no longer be a “branch” of one roads “tree”.)

N/A

2.3.8 Editing restrictions

92. Users can view, create, update and delete conditions on any segment in the state. (Editing restrictions will be abolished.)

2 1.0.0-alpha-

5

2.4 Map Display Requirements


93. TG-Segment shall allow users to view an end user map in an HTML iframe.

2 1.0.0-alpha-

5

94. In computer (PC) environments, event display shall be similar to that of TG-Web.

2 1.0.0-alpha-

5

95. In mobile environments, map display shall be based on that of CARS-App.

3

96. Map displays shall show only winter painted roads. 2 1.0.0-

alpha-5

97. The software shall have controls enabling users to switch between map displays and segment editing.

2 1.0.0-alpha-

5

98. Changes made in the segment editor shall not immediately be accessible in the map display pages.

2 1.0.0-alpha-

5

99. Instead the map display pages will update only after the public can see the updates in TG-Event.

2 1.0.0-alpha-

5

100. The initial map centering and zoom shall give a statewide or nearly statewide view.

2 1.0.0-alpha-

5

101. In the future, a local/regional map may also be supported that is configurable for each user area/subarea.

N/A

102. In the future, users may be able to link to the event’s album page from TG-Web.

N/A


2.5 System Requirements


103. All FEU events created through TG-Segment shall list “Seg-Winter” as the FEU center-id.

1 1.0.0-alpha-

5

104. The CARS user-id with which the user logged on shall appear in the FEU contact-id data element.

1 1.0.0-alpha-

5

105. Events created through TG-Segment shall not be editable by operators in the CARS 4 or CARS 5 GUIs.

1 1.0.0-alpha-

5

106. At least every hour, a full event data overwrite shall correct any mistakes in Java Messaging caused by restarts, etc.

2

107. TG-Segment shall be accessible from any Internet-enabled computer running IE 9, Firefox 10, or later versions.

2 1.0.0-alpha-

5

108. TG-Segment’s user interface shall also be able to run on wirelessly connected HTML5 compatible tablets.

2 1.0.0-alpha-

5

109. As Priority 3, TG-Segment’s user interface shall be able to run as an app on HTML 5 compatible tablets.

3 1.0.0-alpha-

5

110. In Iowa, TG-Segment shall no longer generate a text file listing all Iowa segments and currently active segment reports.

2 N/A


3. Detailed Design

3.1 General Requirements

3.1.1 User Access

TG-Segment is intended to give CARS agencies a roadway segment condition reporting tool that allows authorized users quickly to review, enter, modify, or delete winter reports for fixed, pre-defined segment locations. Data entry occurs for groups of segments sorted by maintenance garage areas; by designated route; or for all reporting segments statewide. Two new versions of TG-Segment are currently planned—one web-based and one a mobile app. Both will use essentially the same HTML5 code. The initial (Iowa) segment reporting interface will be web-based, not requiring any special software other than an up-to-date version of Microsoft Internet Explorer (version 9+) or Firefox 10+ on the client PC or tablet. Later, the HTML5 app version may allow data entry even when the tablet is not connected to the Internet. Subject to certain safeguards, the data would be relayed to operational CARS systems when the tablet is reconnected to the web. Before the first web version of the new HTML5 software is developed, some interim capacity enhancements will be made to the existing CARS-Segment software. These capacity enhancements are due for release in time for the start of winter reporting in the 2014-15 winter season. In the new HTML5 web version, the URL of the login page shall identify the agency and instance (staging vs. production) of the deployment. URLs of subsequent pages need not be shown, and when used on tablets should preferably disappear off the tops of all pages other than the login page.

Figure 1: TG-Segment Login Screen

There are two main groups of users: local users, and global/statewide users. In Iowa, local

Winter Driving


users—mainly equipped with tablets—operate at the garage and garage supervisor level, being responsible for reporting or confirming conditions on a specific set of segments. They can also look at (and occasionally enter) conditions elsewhere in the state. Global users operate at the district level or statewide, usually with PCs. They are responsible for quality control of reporting, and (in Iowa only) for the periodic updating of all report timestamps, statewide. Users log in to the TG-Segment module by entering a user name and password. A recent copy of the CARS 4/5 user database shall be used by TG-Segment to validate these. The TG-Segment software shall show the logged-in user’s ID at the top right corner of each screen. Users can log out by pressing and holding their logged-in name (tablet) or by clicking their name with the mouse (PC). A modal dialogue box shall appear, asking the user to confirm that they want to log out. TG-Segment shall have its own database of users, linked to the CARS user database. Only users that appear in the TG-Segment database shall be able to log into TG-Segment and create or view events. This permission shall be set on the ‘Administer Users’ page within the TG-Segment user interface. Further configuration tables in TG-Segment shall determine whether a user granted access to the software shall have preferred access statewide, to a specific supervision area (e.g., D4- Avoca-Oakland) or to a maintenance garage sub-area (e.g., Avoca). These preferences shall also be set via the “administer users” page of the user interface.

3.1.2 Event report transfer into CARS

In current CARS-Segment deployments, as each segment report is updated, new and updated condition reports are pushed to CARS 4 via FEU-compatible Java Messages. Deleted messages are removed from CARS 4 by way of an FEU Java Message push with an “event-ended” indicator. Now, TG-Segment will be upgraded to be more efficient. FEU-based Java messaging shall be replaced by TG-Segment writing directly into the TG-Event database of CARS 4. The goal will be to create a robust and rapid data transfer mechanism that cannot lose updates during system restarts. Detailed requirements for event report updates are given in the second subsection of the System Requirements (Section 2), above. As priorities 1-3, the TG-Segment module shall support one function: Winter Reporting. Later, predefined Road Closure segments may be added. There are no plans to add other functions such as Posted Roads, Chain Controls or Mountain Passes that were present in past CARS-Segment software versions.

3.2 CARS Segment Tool Changes

TG-Segment will require some changes to the CARS Segment Location Tool, a part of the new TG-Location user interface that is used to prepare the data for CARS-Segment. These will be documented in that tool’s separate SDD called “TG-Location.” However, the


changes are briefly summarized below.

Figure 2: Segment numbering

3.2.1 Segment numbering

In the CARS Segment Location Tool’s GUI, segments are numbered from “1” upwards, beginning at the start of the road and incrementing in the positive direction (the increasing Linear Reference direction). Currently, the Segment Tool numbering restarts at each jump (places where the road becomes concurrent with another highway that is the principal designated route across the jump). This shall be changed so that segment numbers in the Segment Location Tool always continue to increment, even across jumps. As a result, every segment will have a unique reference number, comprising the numerical route designator and the segment number. These segment numbers shall now be stored in the new version of the TG-Segment location database. This sequential numbering system will now be utilized throughout TG-Segment and in CARS-Event (displayed as parts of event URLs in LB- and TG-Web) to reference specific segments and segment aggregations in the GUI and in system databases. Thus, “80-1” references “I-80: Nebraska Line to I-29 North.” “80-4-7” references an aggregated event on I-80 that extends from I-29 South to I-680, or a set of the same I-80 segments being searched for by a user.

3.2.2 Segment boundary names

The new TG-Segment will also require simple, brief names for segment end points (based on cross-streets or other landmarks such as small towns selected by DOT staff). These will be created by modifying the CARS Segment Location Tool so as to propose, edit and store end point names. Other minor changes/clarifications to the segment entry screen will also be made, as follows.

First, a new title will emphasize the designated roadway currently being edited (e.g., “IA 44 segments”). Also, sequential segment numbers will be made larger, and shall be shown in bold text. Segment end points/boundaries will now be shown using grey panels. Where


roads begin, end or jump, a light grey panel will be shown. Segment boundaries that allow aggregation will use a mid-grey color. The named locations dropdown currently labeled “At:”

will be moved onto the grey segment end-point panel. As in the present GUI, only the boundary at the end of the segment currently being edited can normally be changed. The top grey boundary panel has already been defined while editing the previous segment—though special rules will now apply to the start of the road, as described further below. Next to the segment end point drop-down on the second grey panel shall be the CARS linear reference of that point, shown in miles and thousandths of a mile. By moving the drop-down and milepoint next to one another (as they are in CARS 4/5), the GUI will help show that there are two different ways of choosing a segment end point—dragging the pin/entering a linear reference (LR) value, or by picking a named location from the drop-down menu. Also, as in CARS 4/5, the Segment Location Tool will now emphasize which method was actually used, by showing the chosen value (the LR or the location name) on a white background. Otherwise, a light grey background shall be used. Thus, the segment 2-3 boundary below was entered using mileage (LR) rather than by selecting US 59 in the dropdown. The chosen boundary is very slightly off the US 59 junction point (usually a bad thing, but occasionally a result desired by the data enterer).

Figure 3: Segment Location Tool—segment data entry

The brief name of the segment boundary shall also be shown on the grey panel, at the right-hand end. If the segment boundary is being changed or newly created, any prior text in the brief name box shall be erased and replaced by a shortened version of the nearest named CARS location to the new segment end-point. The user will be free to accept this proposed name, to edit its text or to replace it with new text. Note that nearest is not the same logic as that used in CARS 4, which builds descriptions


using locations that the event lies between. In the Segment Tool, the suggested boundary name shall be based on the nearest named location, even if it comes a little before the end of newly defined segment. Below are rules for proposing brief segment boundary names. If there is nothing but “Exit n” or “Exit: n” in the cross-street name, include “Ex ” and all letters and numbers that immediately follow the space, e.g., Ex 156B. Otherwise ignore “Exit n: ” or “Exit n ”. If route designator(s) such as “I-n”, “I n”, “US n” “SR n” or “IA n” are present, use the highest system designator listed first (e.g., I-29) and ignore everything else. If I-, US or IA (etc.) is not present, but “County Road” or “County Roads” is present, replace this with “CR” and add the characters that immediately follow the subsequent space, before the next space or punctuation mark; e.g., “CR P53”. Ignore all that comes before or after the “CR n”. Filter out all words such as “South”, “North”, “Northwest”, “the”, or (in Iowa) “Iowa”. Never include “;”. Pick the first word that is not filtered out, e.g., “Madison”, “Antique.” If the string is an ordinal number, e.g., “2nd”, “83rd”, “156th”, add the next two letters after the space, e.g., “2nd Av”, “83rd St”, “156th Dr”. If the string is too long for the TG-Segment brief name, truncate it without any punctuation, e.g., “Mississi”, or “156th D”. The user can also click on any shortened name and change it to any character string that fits the segment end-point brief name field. Such strings shall appear in red text on a light grey or white background. Other than on Segment 1 of a route, the first grey panel cannot be changed as it must match the second grey panel of the previous segment. However, in the current Segment Location Tool, Segment 1 always begins at the start of the roadway (usually LR 0.000). The new design shown below allows the first segment to begin at a named point or LR other than the exact start of the roadway. This will allow some routes imported from OSM to have a short section prior to the first named cross-street, as can happen due to certain intersection layouts.


If the start of the roadway (usually CARS linear reference zero) is a named location, its name will be used as the basis of the brief segment boundary name that appears on the first grey panel, as shown below. If it is not a named location, the nearest named location shall be presented in the suggested name box. In either case, the suggested name can be changed or overwritten by the user, as described above. The drop-down list can also now be used to make the first segment start at the first named location rather than at LR 0.000, if so desired.

Figure 4: First segment of the route

In the future, a control may be added to the CARS-Segment Location Tool that allows the user to switch between LR and DOT miles (DOTm). This is a “nice to have” feature that is not required for the current work, but may be considered as a future enhancement.

3.3 Segment Review Functions

The new TG-Segment web site shall require the tablet to be used in landscape orientation—though the names of segment boundaries will be shown as if portrait orientation. It is not necessary or desirable for the tablet page views to rotate through 90 degrees when the tablet is turned as the user reads a segment boundary name. The software will be easier to use if it always stays in primarily landscape orientation. Users will therefore be free to tilt their tablet to help read segment boundary names without the screen interrupting their usage by redrawing itself in portrait orientation.


Figure 5: Local user—initial segment definition screen

3.3.1 Initial segment definition screen—local users

Above is the initial screen for a local user whose sub-area is Avoca. The left column shows that Avoca covers parts of five state roads (I-80, US 59, IA 37, IA 44 and IA 83). Road numbers appear on an Interstate shield, a US highway shield or a generic state shield, which will be the same shape in all states. On IA 37, Avoca includes segments 2 and 3. The Avoca subarea also covers segments 1-4 of IA 44; 8-12 of US 59; 9-14 of I-80; etc. Segments with dashed surrounds are located in other subareas. These segments present their names/locations (or any other detailed items such as times) in grey. IA 37 has a total of three segments, two being in the Avoca sub-area. Similarly, IA 83 has four segments, two of which are in Avoca. We can see that US 59 has at least seven segments, five of which are in Avoca. I-80 has many segments, at least six of which are in Avoca. Users can swish along any road to view all its segments. In this example, the Summary view has been selected, with all visible segments showing normal driving conditions (green). The segment colors shall match the painted road colors of TG-Web maps. (Iowa plans to use five colors, assumed here to be green, blue, pink, purple and red.) Between segments are shown major cross-streets or cities that define segment boundaries. Users can also select a summary screen (below) should they no longer need to see details of segment names/locations by touching/clicking the Summary button. The screen will change so that visible segments’ free text names are no longer shown in addition to the segment number, the current painted road color and major cross-street names.


Figure 6: Summary screen for Avoca

Figure 7: Local supervisor—summary screen


Local supervisors see all the segments in their composite areas with solid surrounds, if necessary by swishing up and down / left and right. In any display with more than five roads, the top of a sixth row shall show with the right colors but without any route or segment numbers, or other details. In this case (above), the partly showing road is IA 83. The Avoca supervisor can reach this, and his seventh road IA 92, by swishing along the column of route shields or by holding a finger or mouse on the partly visible shield.

Figure 8: Statewide user—initial screen, showing the latest statewide time update (Iowa)

3.3.2 Initial statewide user screen

When Statewide users first log in, no segments are initially drawn. Instead, a list of all state roadways shall be available as black hyperlinks, not underlined. Local users can also reach this page by deleting their area name and typing “Statewide” into the title/search box. (Tablet users do this by pressing and holding the title until it turns blue and a keyboard appears. They can now delete the current title and use the box to search for new information.) For local users, a home button shall now appear next to the title “Statewide” that will take them back to their local area/subarea. Users can now select any hyperlinked road number (or type in the road number) to make a Summary view of segments appear for that selected road. Initially, other roads are blank (with white space below the first road). For Statewide users, all the segments on that road will have solid edges, as they are still in “Statewide” mode. In Local users’ systems, only their own area’s segments have solid edges—all the others being dashed. Users can return to their initial screen by pressing the Home symbol.


Figure 9: Statewide user selects IA 44

Users can also type in a series of numeric route designators separated by spaces or commas to see the above display for several road numbers of their choice, each starting at segment 1. When other states join, it is expected that “District 1”, “District 2”, etc., may become valid initial settings for some users, so long as these areas have been set up in the CARS Segment Location tool. When segments are displayed along one or more roads, any user can swish along it. In any view (Summary, Segment, Conditions, Updated) users can press/click and hold any segment box to switch to the local sub-area view for that segment. The local sub-area name that includes the segment shall now appear in the title box, and a screen showing that subarea’s roads and segments shall appear. The new subarea is shown in the same view (Summary, Segment, Conditions, Updated) as were the previous segment boxes. This allows users easily to find the local sub-area for any segment, and to edit segments in that local area. For Local users only, the new subarea name shall be shown in red, to warn that they are viewing/editing segments out of their normal subarea. Statewide users shall see all area/subarea titles in black. All users—whether local or statewide—now see solid and dashed segments that represent the local view for Adair. In this mode, they can review and edit segments as would an authorized Adair user. Users can return to their usual area by pressing the Home symbol. (When Statewide users select “Home”, they return to the initial Statewide search screen.) Any user can also press and hold any dashed segment to switch to editing segments for that segment’s local subarea. Its name, roads and segments shall again appear on a local subarea page as above, with the local name in red if they are “out-of-area”.


Figure 10: Press and hold a segment to switch to its subarea view

3.3.3 More search functions

Any user can search for an area or subarea by clearing the title box and entering the area’s name. As the user types, words shall appear in the box that anticipate the name(s) being entered from the state’s full list of areas/subareas. Users can also type a road number (e.g., 80), a road and segment number (e.g., 80-52), a road and segment range (e.g., 80-52-56), or multiple roads/segments/segment ranges separated by commas. The behavior is similar on a PC, allowing the user’s preselected area name to be deleted and a new area, road or segment(s) entered. Touch-screen users can look along a road to see more segments by dragging a finger along the segments of a single roadway. Only one roadway shall move at a time. Users can also click or touch the partially concealed segment box on the right or left of the screen to move one segment step in that direction. Clicking and holding (or pressing and holding) that area of the screen shall cause the user to take successive steps along the roadway. Steps begin slowly and speed up over time to hasten searches on long roadways.

3.3.4 Conditions

Below is a Conditions screen showing a mixture of Normal and Wet conditions, with Icy Bridges flagged on segment 1 of IA 37 using an abbreviation “ib”. If a segment partly showing on the right or left edge of the screen is currently posted with miscellaneous info, these initials shall be made visible in the bottom left of that segment box. Further below is


the same situation in a Summary view.

Figure 11: Current conditions (normal/wet, some icy bridges)


Figure 12: Summarizing conditions shown in the previous screen

Figure 13: Partly/completely covered, one segment impassable

The second summary screen, above, shows segments partly and completely covered with frost, snow, ice, slush or mixed conditions. Again, segments partly showing at the edges allow users to see what conditions have been posted in the adjacent areas—this time in the top corners. If necessary, segments will show both the coverage and abbreviations for miscellaneous additional information, in the top and bottom corners respectively. White spaces between segments indicate jumps across which no events can be created. This happens when a section of the road becomes double banded and is not the primary posted route. Light grey spaces show that conditions could be aggregated across this segment boundary. Dark grey connecting bars indicate that the current reports really have been aggregated into a single CARS event. We recommend that operators be encouraged to enter reports consistent with those of their neighbors’ segments whenever possible.

3.3.5 Segment and event times

In TG-Segment, all reports are created for a fixed duration of “until further notice.” Iowa also creates all its Segment events with an unlimited event expiry time, preventing reports from being automatically deleted as they grow old. Also, as shown earlier, a statewide time update is used to confirm to the public that all the information is being frequently refreshed. In Iowa’s TG-Segment, two reporting times shall be tracked for every segment. One (confirmation time) tracks the time when that segment’s report was last confirmed (bold,


above). The other (update time) tracks when the currently shown conditions were entered.

Figure 14: Segment times—confirmation time, update time, and update author

According to Iowa policies, the confirmation timestamp should always very recent, so no date or day will be shown unless the report’s latest confirmation occurred more than 24 hours ago. If this timestamp is more than 3 hours old (system-wide configurable), it shall appear in red. Note that the event’s published timestamp shall continue to equal the latest confirmation time of any segment in the aggregated event. The second segment timestamp records when the reported segment conditions were actually updated, and by whom.

3.3.6 Event priorities

The event report’s priority shall be set to match that of the highest-priority phrase included in the report (regardless of whether it is the “key” or first phrase in the event description or not), via a look-up table.

3.4 Changing segment conditions

To enter new segment conditions, local users must start from the local subarea view that gives access to the required segment(s). Usually this will be for their own subarea, as indicated by the subarea name in black in the title bar. Local users can also change the conditions for other subareas by pushing and holding a segment from that other area. The


“foreign” subarea name will now be shown in red, as shown earlier. Statewide users can select segments from any local area, all the segments on a road, or all the segments in the state. In the future, users may also be able to select all the segments in a district. Users select a segment by touching its segment box in any of the four display modes (Summary, Segment, Conditions or Updated). Below, segment 44-3 has been selected, causing it to be displayed with a solid color. The page title changes from Avoca to 44-3. Users can return to Avoca by pressing the home symbol, or by selecting the segment a second time, causing it to toggle back to being unselected. The segment counter changes to 1/19. A “Next” button appears that is used to move on to the conditions selection screen once all the required segments have been selected.

Figure 15: Segment 44-3 is selected

Users can continue to select segments by touching or clicking more segment boxes. They can also select all the segments in their chosen area along a given road by touching and clicking the road’s route shield. To select all segments in their area, they can touch/click and hold the “n/19” symbol, e.g., “0/19” or “1/19” above. The selected segments will change to solid colors—colors that serve as a reminder of the current reports about to be overwritten. Users in local subarea mode cannot select segments from another subarea. To do this, they have to switch to the other subarea and see its title in red. Now they are authorized to edit that other area’s segments. The purpose of this restriction is to help prevent accidental edits to other subareas’ segments. However, statewide users can select whole roads or the whole state, changing conditions as well as timestamps. They can select a whole road by searching


for the whole road (instead of going into Local subarea mode using an area name) and then holding down the route shield until all the visible segments become colored and the whole road appears in the title bar (e.g., 80-1-54). Statewide users can select the whole state by pressing and holding “0/1056” (assuming there were 1056 segments in the state) until it changes to “1056/1056.” The title bar now says “All state roads”.

Figure 16: Segments 44-3, 59-8-10, 80-11-12, and 83-1 are selected

When the user has selected all the segments to be changed, they can use the right arrow or (for tablet users) simply swish the whole screen to the left so that a new condition entry screen rolls in from the right.

3.4.1 Entering condition values

Users shall set segment conditions by selecting condition values from some initial categories of conditions, which shall appear as buttons on the conditions data entry screen. The selection boxes in each descriptor category can each include up to ten report values (e.g., partly covered, completely covered, etc.). These report values are known as “descriptors.” Iowa has just one initial category, from which one (or no) values can be picked. Clicking or touching a box selects that value, causing the box to display a solid color and other areas of the screen to change. Users can click a second time to unselect the value, or can click a different value in the first column causing the display to change once more. To get back to the initial conditions screen the user can also push “Cancel entry.” If the conditions are unchanged, the user can update timestamps by pressing “Update timestamps.” Note that


currently, Iowa chooses to do this at statewide level rather than locally.

Figure 17: Iowa’s initial descriptor category (pick one from five, or send null report)

Figure 18: Iowa’s initial descriptor category—user picks “Normal” driving conditions


When the user picks “Normal” driving conditions, five miscellaneous detailed report options appear. The user can touch either visibility or dense fog; either drifting or blowing snow; and/or icy bridges, causing them to display in solid grey with white text. Low visibility shall be paired with dense fog, and drifting snow with blowing snow If a second visibility/fog option is picked, the other shall be automatically deselected. Similarly, if a second blowing or drifting snow option is picked, the first shall be deselected. Icy bridges stands on its own. When the report is complete, the user picks “Send changes.” That button switches to a solid grey color with white text while TG-Segment sends out (but does not wait for completion of) a set of segment conditions changes. Each agency shall choose its own descriptors for each category that it uses. Each category shall be configurable to require users to select either only one or one or more descriptors when creating a new report. The descriptors associated with a particular category and the allowable combinations of descriptors shall be defined in tables listed in a configuration file.

Figure 19: Iowa’s categories—user picks “Wet” pavements and reduced visibility

In Iowa, if the user picks “Wet” pavements, five possible miscellaneous reports appear. Again, the user can touch either visibility or dense fog; either drifting or blowing snow; and/or icy bridges, causing them to display in solid grey with white text. A second touch on the same box, or a touch on the other paired box, causes the miscellaneous report to become unselected. In the example above, the user has selected “Visibility less than 1/8th mile”, which cannot be picked in the same report as dense fog.


3.4.2 Contingent categories

In many states, contingent categories are used in addition to initial categories. Contingent categories only become available after certain descriptors are selected from another category menu. In Iowa, the major example is that picking either partly or completely covered requires a choice be made from Category 2.

Pavement Coverage

Agency Report Public Phrase

Impassable Impassible

Completely Covered Completely Covered with [Category 2]

Partly Covered Partially Covered with [Category 2]

Wet Wet pavement

Normal Normal driving conditions

In these cases, “Send changes” remains disabled until both these columns have one pick. The TMDD phrase pushed to CARS is a concatenation of the Category 1 and Category 2 descriptor selections. If the user now chooses a Category 1 descriptor other than partly or completely covered, then the Category 2 menu shall grey out.

Figure 20: Iowa’s initial descriptor category—user picks “Partly” covered


Figure 21: Iowa’s initial descriptor category—user completes “Partly” covered entry

Figure 22: Iowa categories—user picks “Completely” covered with “Snow”


Figure 23: Iowa—user picks “Impassable” and “Travel not advised”

Figure 24: User picks “Impassable” plus “Travel not advised”; then enters free text


Figure 25: User sends changes: Impassable, Travel not advised, and free text

Figure 26: Conditions entry page—no segments selected


Figure 27: Map page—initial view

Figure 28: Map after pan and zoom actions


3.4.3 Phrase sequencing

As in the current CARS-Segment, phrase sequence in the event description shall be arranged (1) by TG-Segment initial descriptor category and (2) by phrase priority. In each phrase-based Category drop-down list, descriptors shall be listed from highest to lowest priority. When a report is created or updated, the phrase selected from Category 1 (or, in Iowa, Categories 1 and 2) shall always come first (be the headline phrase) in the corresponding FEU message. If one or more descriptors are chosen from Category 3, they follow any Category 1/2 phrase(s) in the FEU message.

3.5 Data Exchange with CARS

3.5.1 Data Flow

Data exchange between TG-Segment and CARS shall be one-way. Data shall flow from TG-Segment to CARS. TG-Segment reports shall not be editable in CARS 4 or CARS 5. The CARS Administrator can delete TG-Segment reports from CARS but cannot change them. Changes to TG-Segment reports can only occur in TG-Segment.

3.5.2 Segment Aggregation

When identical reports exist for two or more adjoining segments along the same designated CARS roadway, the segment reports shall be aggregated into one CARS event. The aggregated CARS event shall have the same start and end points as the start point of the first segment and the end point of the last segment in the aggregated group. When a segment report that is part of an aggregated CARS event is changed, deleted, or has expired, the CARS event shall be recreated as necessary. Where possible, the remaining segments shall then be re-aggregated with each other and/or with other segments. The detailed rules for this are presented in the requirements. Segment aggregation is intended to minimize repetitiveness of Next-Gen TG-Web, -511 and TG-Radio reports. It also keeps associated CARS events as uncluttered as possible on the main CARS map.

In states with event expiry times, if the separate segments have different expiry times, the aggregated event shall have the earliest expiry time of its individual segments. When the expiry time of any individual segment is reached, the aggregated event shall be deleted. TG-Segment shall then re-aggregate the remaining segments into a new event, where possible.

3.5.3 Segment IDs and URLs

In TG-Segment, event IDs shall be derived from segment numbers. Thus, an event on US 59 that aggregates segments 8 through 10 will always have the event ID “IASEG-59-8-10”. Update numbers shall be used in TG-Segment to distinguish between different instances of


the same event location. The new event IDs will ensure that users can easily find the segments that correspond to a specific event in TG-Web and LB-Web, e.g., http://iawebtg.carsstage.org/#roadReports/eventAlbum/IASEG-59-8-10

3.5.4 Report Expiration

When an event report’s expiry time is reached, it shall cease being shown in CARS. The event report shall be marked as deleted in the CARS database, and shall be removed as soon as possible. However, its segment reports shall be retained in TG-Segment and displayed in red text until an update eventually occurs.

A two-hour grace period (configurable) shall be added to each selected expiry time that is passed to CARS. This is intended to cover small irregularities in otherwise regular update cycles.

http://iawebtg.carsstage.org/#roadReports/eventAlbum/IASEG-59-8-10


Appendix A: Categories and Descriptors by Agency

A.1 Iowa

Iowa uses TG-Segment in the winter reporting operating mode (which is currently the only mode).

A.1.1 Iowa Categories and Phrases

Category 1 Mandatory? Yes (but the user can pick “none”). Contingent? No Allow Users to Pick More than One Descriptor? No Type: Phrase

Pavement Coverage

Agency-Specific Phrase Web Painted Road Color and

Legend Icon TMDD Phrase

Normal Green Normal driving conditions

Wet Blue Wet pavement

Partially Covered Pink Partially covered [Category 2]

Completely Covered

Purple Completely covered [Category 2]

Impassable Red, closure icon Closed

Category 2 Mandatory? Yes Contingent? Yes, if “partially” or “completely” covered is selected for Category 1.

Disabled if another descriptor is selected for Category 1. Allow Users to Pick More than One Descriptor? No Type: Phrase

Coverage Type

Maintenance Phrase TMDD Phrase

Frost [Category 1] with frost

Ice [Category 1] with ice

Snow [Category 1] with snow

Slush [Category 1] with slush

Mixed [Category 1] with mixed snow, ice, or slush


Category 3A (Visibility) Mandatory? No Contingent? See table Allow Users to Pick More than One Descriptor? No Type: Phrase

Additional Comments

Agency-Specific Phrase TMDD Phrase Category 1 selection

Dense fog Dense fog Any

Visibility at 1/8th Mile Reduced visibility Any, other than Impassable

Category 3B (Blowing or drifting snow) Mandatory? No Contingent? No Allow Users to Pick More than One Descriptor? No Type: Phrase

Additional Comments


Blowing snow Blowing snow Any

Drifting snow Drifting snow Any

Category 3C (Miscellaneous) Mandatory? No Contingent? See table Allow Users to Pick More than One Descriptor? Yes Type: Phrase

Additional Comments


Travel not advised Travel is not advised Completely or Impassable

Icy bridges Ice on bridges Any, other than Impassable

White out White out Any but Normal or Wet

Category 3A Reduced visibility/dense fog See 3A

Category 3B Drifting/blowing snow See 3B

Category 4 (Free text) Mandatory? No Contingent? Yes (user must have picked “impassable” in Category 1).

Disabled if another descriptor is selected for Category 1. Allow Users to Pick More than One Descriptor? Yes Type: Web and phone text.


A.1.1.1 Iowa error messages

If “partially” or “completely” covered is selected, but no Category 2 phrase is selected: “Select coverage type.”

A.2 Minnesota

Minnesota uses TG-Segment in the winter reporting operating mode (which is currently the only mode).

A.1.1 Minnesota Categories and Phrases

Category 1 Mandatory? Yes (but the user can pick “none”). Contingent? No Allow Users to Pick More than One Descriptor? No Type: Phrase

Driving Condition

Agency-Specific Phrase Web Painted Road Color and

Legend Icon TMDD Phrase

Normal Green (#99CC66) Normal driving conditions

Partially Covered Blue (#0099FF) Partially covered [Category 2]

Completely Covered

Pink (#FF33CC) Completely covered [Category 2]

Travel Not Advised Purple (#660099) Travel not advised

Closed Closure icon Closed

Category 2 Mandatory? Yes Contingent? Yes, if “partially” or “completely” covered is selected for Category 1.

Disabled if another descriptor is selected for Category 1. Allow Users to Pick More than One Descriptor? No Type: Phrase

Coverage Type

Maintenance Phrase TMDD Phrase

Frost [Category 1] with frost

Ice [Category 1] with ice


Snow [Category 1] with snow

Slush [Category 1] with slush

Mixed [Category 1] with mixed snow, ice, or slush

Category 3A (Visibility) Mandatory? No Contingent? No Allow Users to Pick More than One Descriptor? No Type: Phrase

Additional Comments


Reduced visibility Reduced visibility Any

Category 3B (Blowing or drifting snow) Mandatory? No Contingent? No Allow Users to Pick More than One Descriptor? No Type: Phrase

Additional Comments


Blowing snow Blowing snow Any

Drifting snow Drifting snow Any

Category 3C (Miscellaneous) Mandatory? No Contingent? See table Allow Users to Pick More than One Descriptor? Yes Type: Phrase

Additional Comments


Wet Wet Any

White out White out Any

Slippery Slippery Any

Black ice Black ice Any

Icy bridges Icy bridges Any

Category 4 (Free text) Mandatory? No Contingent? Yes (user must have picked “Closed” in Category 1).

Disabled if another descriptor is selected for Category 1. Allow Users to Pick More than One Descriptor? Yes


Type: Web and phone text.

A.1.1.1 Minnesota error messages

If “partially” or “completely” covered is selected, but no Category 2 phrase is selected: “Select coverage type.”

concept of operations functional requirements system design€¦ · functional requirements system...

Documents