Turbo Architecture User's Manual V41

National ITS Architecture
Turbo Architecture
User's Manual
Version 4.1
Prepared by the
National ITS Architecture Team
Prepared for:
Research and Innovative Technology Administration (RITA)
US Department of Transportation
Washington, DC 20590
March 2009
National ITS Architecture Turbo Architecture V4.1
Document Revision History

This section documents and tracks the changes to this User's Manual. The following table is a general
list of releases and major updates to released versions of Turbo Architecture:
Table 1. Document Revision History
Change Date By Whom Change Description
03-15-2000 Version 1.0 National ITS Architecture Team Version 1.0 release
08-04-2000 Interim National ITS Architecture Team Updated Regional to Project Architecture
Version 1.1 conversion.
04-09-2001 Version 1.1 National ITS Architecture Team Update based on Version 1.1 release
May 2005 National ITS Architecture Team Update based on Version 3.1 release
October 2007 National ITS Architecture Team Update based on Version 4.0 release
March 2009 National ITS Architecture Team Update based on Version 4.1 release
Whats New for Turbo Architecture Version 4.1

This section highlights the new features and changes to Turbo Architecture. On the National ITS
Architecture web site (http://www.its.dot.gov/arch/index.htm), click on the Turbo Architecture link and
you will see a page entitled Version 4.1 FAQs. This page describes many of the new options and
features available in Turbo. Some of those are highlighted below:
1. Turbo Architecture Version 4.1 is compatible with Version 6.1 of the National ITS Architecture
(released in January 2009). Turbo 4.1 allows development of Regional and Project ITS
Architectures that take advantage of the features in Version 6.1 of the National ITS Architecture
including expanded support for Field-Vehicle Communications, Clarus related weather interfaces,
electronic freight management interfaces, integrated corridor management, and updated transit
terminology. This also includes an updated mapping to the latest ITS standards such as SAEs
2735 Message Set for Dedicated Short Range Communication and v3 of the Traffic Management
Data Dictionary (TMDD).
2. Updated Turbo Conversion capability converts existing user architectures from previous
versions of the National ITS Architecture. Turbo Conversion will automatically convert existing
Regional and Project ITS Architectures (from prior releases of Turbo Architecture) so they are
consistent with the latest version of the National ITS Architecture.
3. Turbo Architecture Version 4.1 corrects all known software issues from previous versions.
4. Turbo Architecture Version 4.1 provides new features focused on the communications between
systems. For some regional and project architectures it is important to show the Communications
between systems as part of the region or project, e.g. hubs or gateways.
5. Turbo Architecture Version 4.1 also provides a new Output tool to generate hypertext (web)
pages from the turbo database that can be customized based on user inputs for styles and
templates.
6. Turbo Architecture Version 4.1 now provides a choice of recently opened files from the File pull-
down menu along with new reports for Suspicious (or Inconsistent) status values in your
architecture, and other performance improvements that will be seen on the Interfaces tab and
during Batch diagram generation.
7. Turbo Architecture Version 4.1 includes the capability to select multiple rows on the interfaces tab
and then include or exclude the selected rows from the architecture with a single click.
March 2009 ii User's Manual

Document Roadmap
Section 1 Introduction
Description of Turbo Architecture, high level discussion of certain functions of the system, list of
terminology.
Section 2 Getting Started

Information on tasks a region should perform before beginning to use Turbo Architecture, overview of
steps a user should go through in Turbo Architecture, how to manage your data, getting help,
overview of the Turbo CD-ROM, discussion of accessibility features of Turbo.
Section 3 Turbo Tabs

Discussion of how to enter data into the tool from the Tabs Start, Stakeholders, Inventory, etc.
Includes the Interview process and data entry tabs, discussion of stakeholder assignments and
element-stakeholder associations, building and customizing the architecture.
Section 4 Turbo Menubar

How to use the menu bar to access basic (File, Edit) and advanced functions (Extensions, Filters,
Outputs, etc.). Includes description of diagrams and reports, how to format them, how to save them,
how to print them.
Section 5 Being a Successful Turbo Architect

Discussion of the four basic capabilities of Turbo Architecture used to create a Project or Regional
Architecture, and step-by-step processes for using the tool to perform these four capabilities.
Section 6 Advanced Topics Design Issues

Recommendations and suggestions concerning naming conventions, managing your data, element
and flow status (when to use existing, planned, etc.), multi-phase projects, two-tier and three-tier
architectures, working with large architectures.
Section 7 Interview Dialog Questions

List of all questions in each Interview Dialog categories.
Section 8 Guidelines Summary

The section that brings together all of the GUIDELINE statements appearing throughout the
document.
March 2009 iii User's Manual

Table of Contents
1 INTRODUCTION 1
1.1 What is Turbo Architecture? 1
1.2 Turbo Architecture Users 2
1.3 Terminology 2
1.4 System Overview 4
1.4.1 Turbo Architecture Capabilities 5
1.4.2 User Scenarios 5
1.5 What is a Regional Architecture? 5
1.6 Architecture Definition Approaches 5
1.7 Architecture Creation 6
2 GETTING STARTED 7
2.1 Gathering the Data You Need 7
2.2 Suggestions for Success 7
2.3 Quick Start 7
2.4 Turbo Architecture and Microsoft Access 10
2.5 Overview of the Turbo Architecture Software 10
2.5.1 Installing and Running Turbo Architecture 10
2.5.2 Accessing and Using the Sample Marinara Turbo Database 11
2.6 File Overview 14
2.7 Accessibility Features of Turbo 14
2.7.1 Keyboard Shortcuts 14
2.7.2 Toggle between Open Applications without Mouse 16
3 TURBO TABS 17
3.1 Start Tab 18
3.1.1 Regional and Project Architecture Information 19
3.1.2 Related Architectures 27
3.1.3 Managing Items within an Architecture 29
3.1.4 Using the Interview 31
3.2 Stakeholders Tab 51
3.2.1 Add/Modify/Delete a Stakeholder 52
3.2.2 Rename a Stakeholder 53
3.3 Inventory Tab 54
3.3.1 Inventory Tab Views 54
3.3.2 Inventory Tab Basic Operations 60
3.3.3 Inventory Creating a New Element 66
3.3.4 Inventory Tab Editing an Element 67
3.3.5 Inventory Tab Deleting an Element 67
3.3.6 Inventory Tab Tips 68
3.4 Services Tab 72
3.4.1 Basic Operation 72
3.4.2 Market Package Instances 75
3.4.3 More on the Projects and Elements Lists 76
3.4.4 More on Market Package Status 77
3.4.5 More on Market Packages and Projects 77
3.5 Ops Concept Tab 79
3.5.1 Ops Concept Role and Responsibility Areas 79
3.5.2 Defining Stakeholder Roles and Responsibilities 82
3.5.3 Roles and Responsibilities for Project Architectures 83
3.5.4 Ops Concept Q&As 84
3.6 Requirements Tab 85
3.6.1 Requirements Tab Element View 85
March 2009 iv User's Manual

3.6.2 Requirements Tab Functional Areas View 87

3.6.3 Requirements Tab Functional Requirement Selection 88
3.7 Interfaces Tab 91
3.7.1 Adding Interfaces (Building the Architecture) 91
3.7.2 Customizing the Interfaces 97
3.8 Standards Tab 107
3.8.1 Standards Tab Entry 107
3.8.2 Modifying a Standard and Its Relationship to the Architecture 111
3.9 Agreements Tab 113
4 TURBO MENUBAR 115
4.1 File Menu 115
4.1.1 Creating a New Turbo Architecture Database File 115
4.1.2 Opening an Existing Turbo Architecture Database File 115
4.1.3 Opening a Prior Release Turbo Database File 116
4.1.4 Importing an Existing Project Architecture 129
4.1.5 Saving a Turbo Architecture Database File 140
4.1.6 Exiting from a Turbo Architecture Database File 140
4.2 Edit Menu 141
4.3 Tools Menu 141
4.3.1 Extending the Architecture 142
4.3.2 Synchronize Elements 149
4.3.3 Add/Modify/Delete Local Status Values 150
4.3.4 Check Request Flows 152
4.4 Output Menu 154
4.4.1 Data Filtering 154
4.4.2 Element Selection 157
4.4.3 Diagrams 161
4.4.4 Reports 171
4.4.5 Web Pages 179
4.5 Help Menu 219
4.5.1 Help Contents 219
4.5.2 Update Turbo 220
4.5.3 About Turbo Architecture Option 220
4.5.4 Context Sensitive Help 220
5 BEING A SUCCESSFUL TURBO ARCHITECT 221
5.1 Regional Architecture Step by Step 221
5.1.1 Create a Regional Architecture 221
5.1.2 Update an Existing Regional Architecture with a Project Architecture 222
5.2 Project Architecture Step by Step 222
5.2.1 Create a Project Architecture when no Regional Architecture Exists 222
5.2.2 Create a Project Architecture from an Existing Regional Architecture 224
5.3 Relationships Between Elements, Stakeholders, and Tabbed Windows 225
5.4 Mapping between Elements and Entities 226
5.5 Iterations through Turbo 226
6 ADVANCED TOPICS DESIGN ISSUES 229
6.1 Naming Conventions 229
6.1.1 General Naming of Turbo Items 229
6.1.2 Element Names 230
6.1.3 Naming Stakeholders 230
6.2 Keeping Project Architectures in Separate Database Files 231
6.3 Status of an Architecture Component 231
6.4 How the Build Step Selects Architecture Flows 231
6.4.1 Project vs. Region Build Selection Process 232
March 2009 v User's Manual

6.5 Managing Subsystem Permutations 235

6.5.1 Regional Architecture Permutations 236
6.5.2 Project Architecture Permutations 236
6.6 Maintaining Consistency between the Regional and Project Architectures 236
6.7 Multi-Phase Projects 239
6.7.1 Multi-Phase Strategies 239
6.7.2 Market Package Plan 239
6.7.3 Multi-Phase Projects in Turbo Architecture 240
6.8 Two-Tier Architecture 240
6.9 Three-Tier Architecture 241
6.10 Working with Large Architectures 244
6.11 General Issues 246
6.12 Maintenance of Turbo Upgrading to a New Release 246
6.13 Converting a Regional Architecture into a Project Architecture 246
7 INTERVIEW DIALOG QUESTIONS 249
8 GUIDELINES SUMMARY 257
March 2009 vi User's Manual

Table of Figures
Figure 3. Turbo Architecture Main Menu 8
Figure 4. Example of Marinara County Interconnects 13
Figure 5. Example of Marinara County Interconnect Diagram from Turbo 13
Figure 6. File Menu with Ctrl-Key Shortcuts 15
Figure 7. Main Menu with Alt-Key Shortcuts 15
Figure 9. Interview Option Window 20
Figure 10. Change Log Window 22
Figure 11. Merge Project into Regional 25
Figure 12. Project to Region Warning 25
Figure 13. Project to Region Inventory Message 26
Figure 14. Architecture Flows to be added to Regional Architecture 26
Figure 15. Start Tab with Related Architecture Information 28
Figure 16. Interview Start 33
Figure 17. Continue Interview 34
Figure 18. Interview Categories 35
Figure 19. Interview Categories Freeway Management Selected 36
Figure 20. View Interview Questions 37
Figure 21. Initial Center Identification 37
Figure 22. Center Selection 38
Figure 23. Create Stakeholder 38
Figure 24. Center Roadside Equipment Definition 39
Figure 25. Modify Element 39
Figure 26. Selecting an Existing Element 40
Figure 27. Interview Tree, Category Contains Added Element 41
Figure 28. Interview Tree with Element Selected 41
Figure 29. TMC to ISP Connection 44
Figure 30. TMC to Traveler Element (2 ISP's) Connection 45
Figure 31. Multiple FMC, TMC, ISP Center 46
Figure 32. Continue Interview What Category 49
Figure 33. End Interview 50
Figure 34. Stakeholders Tab 51
Figure 35. Autoselect Stakeholders Window 53
Figure 36. Autoselect Stakeholder Selections Recommendations Window 53
Figure 37. Inventory Tab for a Regional Architecture, Sorted by Element 55
Figure 38. Inventory Tab for a Regional Architecture, Sorted by Stakeholder 56
Figure 39. Inventory Tab for a Regional Architecture, Sorted by Subsystem/Terminator 57
Figure 40. Inventory Tab for a Project Architecture, Sorted by Element 58
Figure 41. Inventory Tab for a Project Architecture, Sorted by Stakeholder 59
Figure 42. Inventory Tab for a Project Architecture, Sorted by Subsystem/Terminator 60
Figure 43. Pop-up after Attempting to Create Identical Element 61
Figure 44. Inventory Tab Creating an Element Instance 62
Figure 45. Inventory Tab Inheriting a Parent Elements Attributes 62
Figure 46. Inventory Tab Instance Element 63
Figure 47. Inventory Tab Creating a Shared Element 63
Figure 48. Inventory Tab Communications Element 64
Figure 49. Inventory Tab New Stakeholder Window 65
Figure 50. Inventory Tab Status Value for Current Project 65
Figure 51. Inventory Tab Creating a New Element 66
Figure 52. Inventory Tab Edit 67
Figure 53. Inventory Tab View All Subsystems 68
Figure 54. Subsystem Aggregation and Replication 69
Figure 55. The Subsystem Diagram 70
Figure 56. Services Tab Regional Market Packages View 73
Figure 57. Services Tab Project Market Packages View 74
March 2009 vii User's Manual

Figure 58. Services Tab Instance of a Market Package 75

Figure 59. Ops Concept Tab Role and Responsibility Areas 80
Figure 60. Autoselect Role and Responsibilities 80
Figure 61. Autoselect Role and Responsibilities 81
Figure 62. Ops Concept Tab Stakeholder Roles and Responsibilities 82
Figure 63. Ops Concept Tab Adding a New Roles and Responsibility Area 83
Figure 64. Ops Concept Tab Locked Roles and Responsibilities 83
Figure 65. Requirements tab Inventory View 86
Figure 66. Requirements Autoselect Window 87
Figure 67. Requirements tab Functional Areas View 88
Figure 68. Functional Requirements Selection Window 89
Figure 69. Functional Requirement Tailoring Window 90
Figure 70. Initial Interfaces Tab Architecture Has Not Yet Been Built 91
Figure 71. Add Interfaces Window 93
Figure 72. Build Settings Window 94
Figure 73. Inventory to Market Package Comparison Report 96
Figure 75. Interfaces Tab Project Architecture with Group Selected 99
Figure 76. Interfaces Tab Sort Option 100
Figure 77. Interfaces Tab Supplemental Flow Information 101
Figure 78. Interfaces tab Interconnects for Regional Architecture 102
Figure 79. Project Architecture Interconnects to One Element 103
Figure 80. Architecture Flows for all Elements in a Regional Architecture 105
Figure 81. Architecture Flows for One Element in a Project Architecture 105
Figure 82. Standards tab All Standards View 108
Figure 83. Standards tab Info Screen 109
Figure 84. Standards tab New Standards Input 110
Figure 85. Standards tab Standards to Interface Relationship 111
Figure 86. Agreements tab 113
Figure 87. File Pull-down Menu 115
Figure 88. Select the Database File to Be Converted 118
Figure 89. Convert/Open the Database File Window 119
Figure 90. Select the Destination File for the Conversion 120
Figure 91. File Conversion Process Steps 121
Figure 92. Conversion Reports 122
Figure 93. Conversion Summary Report 123
Figure 94. Element Mapping Conversion Details Report 123
Figure 95. Flow Conversion Details Report 124
Figure 96. Market Package Changes Report 125
Figure 97. Delete Discontinued Entities and Flows? 126
Figure 98. Final Turbo Conversion Window 126
Figure 99. Project Architecture Import 130
Figure 100. Must Convert Old File Before Import 130
Figure 102. Import Manager Status Values 132
Figure 103. Import Manager Elements 132
Figure 104. Import Manager User Defined Entities 133
Figure 105. Import Manager Stakeholders 133
Figure 106. Import Manager Role and Responsibility Areas 134
Figure 107. Import Manager User Defined Flows 134
Figure 108. Import Manager Interfaces Tab Update 135
Figure 109. Import Manager Agreements 135
Figure 110. Import Manager Build the Architecture 136
Figure 111. Import Successful 136
Figure 112. Exit Warning Message 140
Figure 113. Edit Pulldown 141
Figure 114. Tools Pulldown 142
Figure 115. User Defined Entities 143
March 2009 viii User's Manual

Figure 116. Entering New User Defined Entity 144

Figure 117. User Defined Entity Change Applied 144
Figure 118. User Defined Flows Window 146
Figure 119. User Defined Flows Window Replacing Existing Flow Name 147
Figure 120. Build Step with User Defined Flows 148
Figure 121. Synchronize Elements Window 149
Figure 122. Synchronize Elements Functional Areas Dialog 150
Figure 123. Synchronize Elements Functional Areas Incorporated 150
Figure 124. Local Status Value Add/Modify/Delete 151
Figure 125. Consolidate Local Status Values 152
Figure 126. Check Request Flows Window Request Flows Tab 153
Figure 127. Check Request Flows Information Flows Tab 153
Figure 128. Output Menu 154
Figure 129. Filters Window Summary Tab 155
Figure 130. Filtering Entities 155
Figure 131. Filtering Interconnects 156
Figure 132. Filtering Flows 156
Figure 133. Filtering Market Packages 157
Figure 134. Element Selection Window 158
Figure 135. Flow Diagram between Two Selected Elements 159
Figure 136. Element Selection Window with Communications Elements 160
Figure 137. Diagrams Window 161
Figure 138. Subsystem Diagram Show Related Elements 163
Figure 139. Example Interconnect Diagram 164
Figure 140. Example Flow Diagram 165
Figure 141. Example Flow Diagram with Communications Hub Selected. 166
Figure 142. Diagram Settings Window Shapes 167
Figure 143. Diagram Settings Window Lines 168
Figure 144. Diagram Batch Processing Print Mode 168
Figure 145. Diagram Batch Processing Save Mode 169
Figure 146. Reports Window 171
Figure 147. Report with Export Option 177
Figure 148. Web Pages Window 179
Figure 149. Web Pages Setup Window 180
Figure 150. Web Pages Subfolder Creation Window 181
Figure 151. Web Pages Setup Content Window 182
Figure 152. Web Pages Setup Style Window 183
Figure 153. Web Pages Creation File Locations Window 184
Figure 154. Web Pages Creation Progress Window 185
Figure 155. Web Pages Viewed in Browser 186
Figure 156. Services (Market Packages) Web Pages Viewed in Browser 187
Figure 157. Home Web Page Viewed in Browser 188
Figure 158. Scope Web Page Viewed in Browser 189
Figure 159. Inventory Web Page Viewed in Browser 190
Figure 160. Inventory Element Detailed Web Page Viewed in Browser 191
Figure 161. Inventory Element Functionality Web Page Viewed in Browser 192
Figure 162. Inventory Element Context Diagram Web Page Viewed in Browser 193
Figure 163. Inventory Element Interfaces to Other Element Web Page Viewed in Browser 194
Figure 164. Applicable Standards Web Page Viewed in Browser 195
Figure 165. Inventory by Entity Web Page Viewed in Browser 196
Figure 166. Inventory by Stakeholder Web Page Viewed in Browser 197
Figure 167. Stakeholders Web Page Viewed in Browser 198
Figure 168. Stakeholder Details Web Page Viewed in Browser 199
Figure 169. Stakeholder Group Web Page Viewed in Browser 200
Figure 170. Services (Market Packages) Web Page Viewed in Browser 201
Figure 171. Services (Market Packages) Details Web Page Viewed in Browser 202
March 2009 ix User's Manual

Figure 172. Operational Concept Web Page Viewed in Browser 203

Figure 173. Roles & Responsibilities Web Page Viewed in Browser 204
Figure 174. Requirements Web Page Viewed in Browser 205
Figure 175. Functional Areas Web Page Viewed in Browser 206
Figure 176. Interfaces Web Page Viewed in Browser 207
Figure 177. Interfaces Context Diagram Web Page Viewed in Browser 208
Figure 178. Standards Web Page Viewed in Browser 209
Figure 179. Standards Detail Web Page Viewed in Browser 210
Figure 180. Agreements Web Page Viewed in Browser 211
Figure 181. Agreements Details Web Page Viewed in Browser 212
Figure 182. Projects Web Page Viewed in Browser 213
Figure 183. Projects Details Web Page Viewed in Browser 214
Figure 184. Web Page Setup/Content New Internal Page 216
Figure 185. Web Page Setup/Content New External Page 217
Figure 186. Web Page Setup/File Locations Page 218
Figure 187. Help Pulldown 219
Figure 188. Complex Subsystem/Terminator Mapping 226
Figure 189. Project Architecture Inventory Screen with an Element Instance 233
Figure 190. Moderate Build, New Element Part of Project 234
Figure 191. Aggressive Build, New Element Part of Project 234
Figure 193. Two-Tier Architecture Single Database 241
Figure 194. Two-Tier Architecture Two Databases 241
Figure 195. Two-Tier Architecture Multiple Databases 241
Figure 196. Three-Tier Architecture Customize Regional Architectures 242
Figure 197. Three-Tier Architecture Customize Project Architectures 243
Figure 198. Region to Project Conversion 247
Figure 199. Region to Project Conversion Continue 247
Figure 200. Region to Project Conversion Complete 248
Figure 201. Turbo Interview Window 249
March 2009 x User's Manual

Table of Tables
Table 1. Document Revision History ii
Table 2. Turbo Architecture Terminology 2
Table 3. Centers and Organizations of Marinara County 11
Table 4. ITS Service (Market Package) Areas 72
Table 5. Maximum Name Sizes in List Boxes 229
Table 6. Stakeholder Bound Entity Interfaces Automatically Resolved by Turbo 235
Table 7. List of Guidelines 257
March 2009 xi User's Manual

1 Introduction
Welcome to the Turbo Architecture Users Manual! This manual has been prepared to help the reader
use and become familiar with a truly unique Intelligent Transportation System (ITS) planning tool. Turbo
Architecture will become an indispensable tool for transportation professionals interested in planning for
the future, realizing the most benefit from regional ITS investments, and achieving integration of ITS
infrastructure.
Turbo Architecture is a software product that directly leverages the National ITS Architecture, allowing
users to map regional plans and project designs to the National ITS Architecture, thereby quickly
producing high-level architectures for regional and project ITS activities. Once an architecture has been
developed, it can be used as a basis for planning integration, scoping projects, and developing
information sharing relationships.
One of the most important capabilities of Turbo Architecture is its ability to capture individual projects as
part of an overall Regional ITS Architecture. By providing the user with information about how the
different parts of ITS being deployed can relate to each other, the user can make early, informed
decisions that will save time and money. With a Regional ITS Architecture to support ITS planning and
early design, each project can now be deployed with a clearer understanding of all the interfaces and
functions it will need to support over time.
The use of Turbo in the products name is intended to indicate the efficiency and speed with which
architectures can be developed using the tool. The ultimate tool would be one that requires no ITS
knowledge to use. Turbo Architecture is not this ultimate tool; to use this product the user will need a
good working knowledge of the National ITS Architecture, as well as this Users Manual, at least initially.
The contents of the National ITS Architecture can be accessed from the Architecture CD-ROM or on the
web at: http://www.its.dot.gov/arch/arch.htm. The Regional ITS Architecture Guidance document
describes the process to develop a Regional ITS Architecture (USDOT EDL document #114317,
http://www.ops.fhwa.dot.gov/publications/regitsarchguide/index.htm). With these prerequisites, there will
be no quicker way to build Regional and Project ITS Architectures than by using Turbo Architecture.
1.1 What is Turbo Architecture?

Turbo Architecture is a high level, interactive software program that aids transportation planners and
system integrators, both in the public and private sectors, in the development of a Regional and/or Project
ITS Architecture. Turbo Architecture is a planning and integration aid designed to facilitate usage of the
National ITS Architecture. The application will utilize user inputs and information from the National ITS
Architecture databases to provide users with tabular and graphical outputs comprising a high level
representation of their Regional or Project Architecture. In order to more easily use the tool, it is highly
recommended that the user of the Turbo Architecture application be familiar with the National ITS
Architecture. (This tool is not an introduction to or training aid for the National ITS Architecture.)
Turbo Architecture:
Guides users through the design of a Regional or Project Architecture, identifying and extracting
the required portions of the National ITS Architecture.
Assists in local mapping and tailoring to a region's needs.
Helps the user with potential conflict resolution between Regional and Project Architectures.
Provides a jumpstart toward architecture development and conformance to the National ITS
Architecture.
Is a standalone application.
Turbo Architecture is not a complete end-to-end solution to fully develop ITS architectures. User and
stakeholder interaction, gathering local requirements and systems, a Concept of Operations agreed to
by consensus, and extension of the resulting architectures will be required beyond the data, diagrams,
and reports that the tool provides, in order to meet the needs of the local transportation community. The
local region may require queries of the data or reports that are not part of Turbo Architecture. The FHWA
Rule 940 and FTA policy on Regional ITS Architectures and Standards requires various other documents
and data. Turbo Architecture aids the user in gathering much of this additional information.
March 2009 1 User's Manual

Feedback and consensus is required between the stakeholders during the creation of a Regional or
Project ITS Architecture. The architecture is NOT complete simply by following the Turbo Interview
questions, building the architecture, and printing the results. A great deal of customization may be
required, including iteration of the steps in Turbo Architecture, selecting additional market packages, etc.,
in order for the interconnections and architecture flows between elements to be complete and correct.
Stakeholders should be involved initially to attain consensus on the services (centers, data, equipment,
and interfaces) that a project or region require. They should become involved in the process again as the
Project or Regional Architecture is customized.
Throughout this document will appear certain paragraphs marked as GUIDELINE. These are
suggestions or recommendations of the best ways to use Turbo Architecture. In addition, they are
gathered together in Section 8, at the end of the manual.
1.2 Turbo Architecture Users

Many types of agencies and personnel may find Turbo Architecture useful. The following is an example
of potential users of the tool:
1. Local and state transportation agencies
a. Traffic Management Centers
b. Transit Management Centers
c. Emergency Management services deploying ITS in a region
2. Metropolitan Planning Organizations -- transportation planners
3. National ITS Architecture Deployment Workshop attendees
4. Consultants developing Regional and Project ITS Architectures
Turbo Architecture can be used to generate Regional and Project Architectures. Elements may exist
within each region that have already been deployed or are planned for the future, or an entire project may
be labeled as planned for the future. The output reports and diagrams produced by the tool will be able to
distinguish between existing and planned architecture elements within a region or project.
Architectures generated using the current release of the tool and National ITS Architecture databases are
planned to be upward compatible with future releases of these databases and software. The user needs
to be able to create an architecture today that represents the current transportation plan for a region,
along with elements that are known to be planned for the future. He must then be able to return to this
architecture in a year or two and move those planned elements to existing, flesh them out, and also
create new (existing or planned) projects that will be added to the architecture for the region. The
Regional and Project ITS Architectures are living documents for how communication is handled
between various agencies and groups in the region. The database structure that has been implemented
for the Turbo Architecture application makes this possible.
1.3 Terminology
The following terms are used frequently in this document.
Table 2. Turbo Architecture Terminology
Term Description
Architecture, An uncustomized architecture is one which has been built via the Build option on the
Uncustomized Interfaces tab in Turbo Architecture, but no changes to element or architecture flow
selections have been made, i.e., no tailoring of the architecture has been done yet.
Architecture, A customized architecture is one in which element and architecture flow associations
Customized have been modified on the Interfaces tab in Turbo Architecture. The flow status may be
changed or the project association for a flow or interconnect may be deselected (i.e., in
order not to display this flow or interconnect on the diagrams).

Term Description
Center Center is a term used in the Turbo Architecture Interview Dialog and represents the
primary Administration or Management Element. This may often be a physical
building (such as the Marinara County Freeway Management Center). The centers
defined during the Interview will also appear as elements on the Inventory tab.
Element This is the basic building block of a local regional or project ITS architecture. It is the
name used by the stakeholders to describe an instance of one or more ITS entities. An
element is defined by the name that a user gives to an instance of an ITS entity (e.g.,
Caltrans/California Highway Patrol District 12 Traffic Management Center). An element
is also assigned to a stakeholder. In addition to Transportation Elements like TMCs,
Turbo supports Communications Elements (e.g., communications gateways and hubs).
Entity An entity represents a National ITS Architecture subsystem or terminator from the
Physical Architecture, or a user defined (locally defined) entity (similar to a subsystem
or terminator). Each element should be associated with one or more entities.
File The definition of an architecture is saved in a file. Within a single Turbo Architecture
file (or database), the user may define zero or one Regional Architecture and/or zero
to many Project Architectures. A file is also referred to within this document as:
A database file
Turbo Architecture database file
Turbo Architecture file
Interfaces, Communications paths that carry information between entities (subsystems and
Interconnect terminators) of the National ITS Architecture and between elements of a Regional or
Project ITS Architecture. Interconnects are directionless and contain one or more
architecture flows.
Interfaces, Architecture flows define direction-specific information flow between entities of the
Architecture National ITS Architecture and between elements of a Regional or Project ITS
Flows Architecture such as road network conditions from a traffic management center to
an emergency center. Forms the basis for the standardization of ITS interfaces.
Project A project is a set of ITS deployment activities grouped together (usually within a single
procurement) for planning, deployment, and/or operational purposes. A project has
defined boundaries within the context of a region.
Project This term defines the elements and information exchanges of a single ITS project.
Architecture
Region A region is a geographical area spanning one or more jurisdictions. A region is a local
decision. It is not necessarily bounded politically. It could be a state or multiple states,
a metropolitan area or multiple metropolitan areas, one MPO or multiple MPO's, a
corridor (e.g., I-95 corridor), counties, rural towns or areas.
Regional The elements and information exchanges of the many ITS projects existing or planned
Architecture within a region. It should be a comprehensive organization of the region's ITS.
Stakeholder A stakeholder defines an organization that owns, operates, or interfaces with the ITS
elements in a region.
Subsystem There are 22 subsystems that make up the National ITS Architecture and encompass
all the functionality of the ITS User Services and are grouped into four classes: Centers,
Field, Vehicles, and Travelers. Examples include the Traffic Management Subsystem
(TMS), the Vehicle Subsystem (VS), and the Roadway Subsystem (RS), corresponding
to traffic operations centers, automobiles, and roadside signal controllers.

Term Description
System A system is a collection of hardware, software, data, processes, and people that work
together to achieve a common goal (definition from the NHI System Engineering
Course). NOTE that system is a relative term since many different types of systems fit
this definition. To a sign manufacturer, a dynamic message sign is a system. To a
state DOT, the same sign is only a component of a larger Freeway Management
System. In the National ITS Architecture, a Freeway Management System is a part of
the overall surface transportation system for the region.
Terminators Terminators are physical entities that define the boundary of an architecture. The
National ITS Architecture terminators represent the people, systems, and general
environment that interface to ITS. The interfaces between terminators and the
subsystems and processes within the National ITS Architecture are defined, but no
functional requirements are allocated to terminators.
To continue the terminology discussion, a user begins by creating a database file to contain
architectures. An architecture is composed of elements (centers, systems, vehicles, personnel, and
roadside equipment, etc.) and information flows that connect the elements together. The elements are
associated with entities (National ITS Architecture subsystems and terminators, and user defined
entities), projects (the current project or other projects in the region), and market packages.
The following figure describes the relationship between the National ITS Architecture entities and a
Turbo Architecture element:
National ITS EM
Architecture Entity
Entity 1
EXAMPLE:
TMS
Entity
National ITS
Architecture
Entity 2 Freeway
Management
Center Element
User's Element
Figure 1. Element to Entity Relationship
1.4 System Overview

Turbo Architecture is a Microsoft Windows based software product that uses the National ITS Architecture
databases to aid in the development of a Regional and/or Project ITS Architecture. Turbo can convert
existing Turbo databases of Regional and Project Architectures so they are consistent with the latest
version of the National ITS Architecture. Turbo Architecture includes this users manual, an installation
guide, and on-line help.
The computer system requirements to use Turbo are fairly straightforward:
PC-Compatible
Operating Systems: Windows 98 Second Edition, 2000, ME, XP, Vista
100MB Free on Hard Drive
Minimum 800X600 Monitor Resolution
CD-ROM
As with any software product these minimal specifications may work but youll want more memory and
processing speed to develop and maintain large, complex architectures.

1.4.1 Turbo Architecture Capabilities

The tool can be used to create a Regional Architecture, create a Project Architecture, modify a Regional
Architecture, modify a Project Architecture, or update one based upon the other. The basic uses of the
tool are to:
1. Create a new Regional Architecture
2. Create a Project Architecture when no Regional Architecture exists
3. Create a Project Architecture when a Regional Architecture does exist
4. Update an existing Regional Architecture with a Project Architecture definition
The steps a user would follow to create or update architectures using these four basic capabilities of
Turbo Architecture are described further in Section 5 in this document.
1.4.2 User Scenarios

Using the four basic capabilities listed above, there are several additional scenarios that the tool will
support. Included below are some of these (this list is by no means all-inclusive):
1. Create a Regional Architecture composed of many projects, some that exist in the plan for the
current year, and some which may occur in the near or distant future for the region.
2. Bring multiple disjoint project definitions together in order to define a Regional Architecture.
3. Create a multi-phase project, where part of a project is being developed currently, but other
phases may occur in subsequent years.
4. Create a two-tier or three-tier architecture. For example, several Regional Architectures are
combined into a corridor or statewide architecture.
5. Determine the ITS standards that may correspond to portions of a Project.
Section 6 provides details and suggestions on these uses of the tool which expand on the basic
capabilities listed above.
1.5 What is a Regional Architecture?

Regional Architectures may be built as a standalone architecture, or can be built around Project
Architectures. As the name implies, a Regional Architecture is a description of a region that may be used
for planning ITS projects and facilitating integration. It lists the functions, interconnections, services,
stakeholders, how they communicate, and how they are all connected. Many diagrams and reports can
be generated for later use by Turbo Architecture for the Regional and Project Architectures.
If transportation services are represented by market packages and functions in the National ITS
Architecture and the Regional Architecture, then the functions plus interfaces indicate how the services
are implemented. When a Market Package or National ITS Architecture entity (subsystem or terminator)
is associated with an inventory element or center in Turbo, many architecture flows are selected by the
system and provide connections to and from the element in the Regional or Project Architecture. These
indicate the interconnections for this element to the rest of the architecture.
Regional ITS Architectures are becoming the link between planning and ITS standards, enabling project
implementations to consider the standards based on the Regional ITS Architectures.
1.6 Architecture Definition Approaches

There are two main approaches that may be used to define architectures using Turbo Architecture: Top-
down, where a Regional Architecture is developed and used as the basis for defining Project
Architectures or Bottom-up, where a set of Project Architectures is defined and then merged together into
a Regional Architecture. There is a third approach where a Regional Architecture is built as a complete
standalone entity. It does not include any Project Architectures.
Turbo Architecture supports all of these approaches. In support of the top-down approach, a user may
develop a Regional Architecture, then use portions of this architecture to define a single or multiple
Project Architectures. The tool also supports the bottom-up approach by providing the capability to

update a previously defined Regional Architecture with a Project Architecture. If no Regional Architecture
exists, then this update capability can be used to create one from the projects defined in the database.
Within a single Turbo file, the user may define at most one Regional Architecture and/or zero to many
Project Architectures. Within a single database file, each Project Architecture corresponds to a single,
unique project. The user may also create separate files to represent different regions, or different
collections of projects (or phases of a project) within a single region.
See Section 6 for a discussion of multi-phase project design and a tiered approach to statewide
architecture definition.
1.7 Architecture Creation

The basic steps involved in creating a Regional or Project Architecture are listed below and shown in the
following diagram:
Gather the Initial Data Section 2.1
Input Data (Inventory) Section 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7
Build an Uncustomized Architecture Section 3.8.1
Customize the Architecture Section 3.8.2, 3.9, 3.10
Generate Outputs Section 4.4
Gather
Information
Architecture
Creation
Input Data
(Section 3.1-3.7)
Build Architecture
(Section 3.8.1)
Stakeholder
Input
Customize
Architecture
(Section 3.8.2)
Create
Outputs
(Section 4.4)
Turbo Architecture Tool
Figure 2. Turbo Architecture Process

2 Getting Started
2.1 Gathering the Data You Need
The following steps will help you to gather the data required to begin design of a Regional or Project
Architecture:
1. Interact with the stakeholders. Learn their issues and requirements.
2. Review the Early Deployment Plan for your region, if you have one. This will include the User
Service needs and an inventory of required centers, elements, systems, etc.
3. Review the Transportation Improvement Programs (TIP), Statewide TIP (STIP), State
Implementation Plan (SIP), Capital Improvement Programs, Long Range Plans, Congestion
Management Plans, the Commercial Vehicle Safety Plan (CVSP) for project scope and timing,
and other plans and studies to identify regional transportation priorities and implementation time
frames.
4. Review the Regional ITS Architecture Guidance document which describes a process for
creating Regional ITS Architectures with supporting examples for each architecture product and
discusses mainstreaming ITS into the planning and project development processes.
5. If you have identified User Service needs for your region, refer to the National ITS Architecture
Market Packages Document for information about how to convert these needs to market
packages that can be entered into Turbo Architecture. The Interview Dialog feature of the tool
will do this for the architecture selections made by the user. Additional market packages may be
selected on the Services tab in the tool.
6. Review Section 7 in this manual for the list of Interview questions that you will need to answer for
the centers that will be created for your region. It may help to review these questions in advance
and have an idea of how they will be answered before creating the architecture using Turbo.
In general, to effectively use Turbo Architecture, you will need a fairly complete understanding of the
stakeholders, centers, elements, and services that are involved in the architecture you wish to develop.
2.2 Suggestions for Success

The following suggestions may help you get the most from designing an architecture:
1. Gather the data for creation of your architecture(s).
2. Install the Turbo Architecture software.
3. Save intermediate backup versions of your architecture in files with different names, in case you
need to return to them. Turbo Architecture includes a Save As feature that may be used to
create checkpoints of an architecture in development.
4. Keep all paperwork together for each Regional or Project Architecture.
5. Organize the activity and personnel in a way that makes sense for your region. If you have
multiple people involved in developing Project Architectures (which you later plan on merging into
a single Regional Architecture), then it is best to develop a common set of terms for the element
and stakeholder names. This will greatly facilitate the merge part of the process. (For example,
do you call an element City Transportation Center or City TMC -- the tool will interpret these as
two different elements when you perform the operation to merge the projects into the Regional
Architecture.) The timing of the updates should be reviewed and a process put in place.
6. Keep communications open with the stakeholders. Review the architecture with them periodically
during the development and at the end of the development cycle. Keep them involved.
2.3 Quick Start

The following section will walk the user through a set of steps that illustrates simple usage of the tool.
After installing the tool, the user starts the tool by double clicking on the Turbo 4.1 icon on your
Desktop, double clicking on the Turbo Architecture executable file in the directory where it was placed, or
by selecting StartProgramsNational ArchitectureTurbo 4.1, or the program manager group

names that the user created during installation (see the Turbo Architecture Installation Guidelines
document) to run the tool. From the Start option, you may also review the Turbo documentation and
sample databases. The initial Start Tab appears in the figure below:
Figure 3. Turbo Architecture Main Menu

To create a new Turbo Architecture database file or open an existing file before opening an architecture,
from the menubar pulldown, select File => New to create a database file, or File => Open to open an
existing file. The first time into a new release of Turbo, the default directory is My Documents. If
opening an existing database file, this directory must be changed to the directory that holds your
architecture(s).
The next thing the user needs to do is to create or open an architecture in this file. To create a new
Regional ITS Architecture, select the New button in the Regional area on the Start tab. In the same
manner, to create a new project ITS architecture, select the New button in the Project area on the
Start tab. To open an existing architecture, select a name from the existing Regional ITS Architecture or
the list of Project ITS Architectures on this window.
GUIDELINE: Remember that only a single Turbo Architecture database file and a single
architecture in that file can be opened at any given time in a single session of the Turbo
Architecture program. If it is desired to view two architectures simultaneously, a second session
of Turbo Architecture must be initiated.
NOTE: In Turbo Architecture it is possible to open two sessions of the tool at the same time. However,
different files must be opened in each session.
To create a new architecture on the Start tab before creating a database file, place this architecture into a
new file later during the Save or Save As operation and enter the appropriate filename (this

architecture may not be placed into an existing file in this way). To create a new architecture, select
either New button on the Start tab.
The generic architecture definition process generally follows the Turbo Architecture tabs:
Create or update the system inventory (through Interview and/or tabbed windows).
Make or update market package selections (through Interview and/or tabbed windows).
Build the uncustomized architecture.
Customize the architecture interconnects and architecture flows.
The user is likely to iterate back and forth between steps several times before since new elements may
be defined or new services may be identified after an initial architecture is built. The following steps
define this process in more detail. In addition to the four basic steps, there are other tabs where a user
may define other information and attributes about the architecture.
1. The user may now begin to create, or continue development of, the architecture:
a. Begin the Interview (this is optional and available if creating a new architecture)
b. Continue the Interview (if you previously left the Interview by Quitting the Interview for Now;
if you chose Exit Interview the interview process cannot be used again for that architecture).
c. Enter via the tabs (Stakeholders, Inventory, Services, Ops Concept, Requirements,
Interfaces, Standards and Agreements).
d. Use the pulldown menus File, Edit, Tools, Output, and Help, to manage files
including importing a Regional or Project ITS Architecture from another database file, typical
Windows editing features, to extend the architecture and status, to check potential request
and information flow discrepancies, provide a wide variety of reports and diagrams as well as
help when you need it. Merging a project into the Regional Architecture in the current
database could also be done at this time, and is found as an option on the Start tab.
2. The following list includes more detail on creating the architecture using the above features:
a. The Interview Dialog leads the user through a set of questions in many different ITS-related
topic areas. The tool, in the background, makes element mapping and market package
selections that will appear on the Inventory and Services tabs, respectively after the Interview
is completed.
b. There are four main tabs (in addition to the Start tab) that are used to create the actual
architecture data that will be discussed later in this document. These tabs allow the user to
add or display additional information about the architecture:
(1) The Stakeholders tab is used to define new (or modify existing) stakeholders on this tab
as well as create stakeholder groups. These stakeholders are associated later with
inventory elements.
(2) The Inventory tab is used to define the list of elements that make up the architecture.
Elements are mapped to architecture stakeholders, entities (subsystems, terminators,
and user defined entities), and in some cases to projects in this window.
(3) The Services tab is used to define the services that are desired for the architecture. A
set of National ITS Architecture market packages is selected (if you do not understand
what Market Packages are, review the National ITS Architecture CD-ROM or web site -
http://www.its.dot.gov/arch/arch.htm). Architecture elements and projects are
associated with the selected market packages to be part of the architecture on this tab.
(4) The Interfaces tab is used to build and tailor, or customize, the architecture. Depending
whether or not a previous build was done, there may or may not be architecture
interconnects or flows already listed on this tab. To build the architecture, i.e., to add all
the newly defined inventory elements (or changes/additions made on the Services tab),
select the Build button. Read and follow the instructions you may display an
Inventory to Market Package Comparison report, establish settings for this Build,
then Build the architecture. If you choose to Apply the additions to the architecture,
you will see the message, The identified changes were successfully made. Use the

Interfaces tab to tailor the architecture to your specific needs. At this point you have
created an architecture and can move on to the other features of the Interfaces tab.
The rest of the Interfaces tab includes two views, Connect and Flows, that provide
the user with an editable list of the interfaces between elements which should should be
customized on this tab.
3. After the element inventory has been created and the architecture is built, the user has access to
reports and diagrams which may be displayed and/or printed (note that before a Build, there is
no data available for most reports and diagrams). The output from certain diagrams may be
exported to other software tools, such as, PowerPoint or Visio. Reports may also be saved in a
format that software tools, such as Excel and Word, may use.
All the operations and functions described above are covered in more detail in later sections of this
document.
2.4 Turbo Architecture and Microsoft Access

GUIDELINE: Turbo Architecture supports Windows 98 Second Edition, 2000, XP, and Vista
compatible databases and operating systems. However, databases designed in various releases of
Turbo Architecture using MS Access 97 and Access 2000 or XP MUST NOT be converted back and
forth. The various versions of MS Access are not compatible with each other, and parts of your
Turbo data will be LOST by doing this.
NOTE: All changes to the Regional or Project ITS Architectures as well as conversion to later versions of
Turbo Architecture for Turbo Architecture files MUST be done using Turbo Architecture. Turbo
Architecture includes a conversion mechanism to convert architectures developed with previous releases
of Turbo. This is the only method that should be used to convert these earlier databases.
Customer databases designed using Version 1.0 or 1.1 of Turbo Architecture were developed in the
Microsoft Access 97 database compatible format. THEY MUST NOT BE CONVERTED TO A NEWER
VERSION OF ACCESS by opening the database in these tools and selecting the Convert option, and
WILL NOT successfully operate in Turbo if they are. In addition, they should not be converted to Access
2000 or XP, then back to Access 97 this does not correct the problem. The underlying database
incompatibility problems will still exist, and the database will no longer be compatible with Turbo
Architecture. Turbo database files should only be opened with the Microsoft Access Software on
extremely rare occasions by an expert Access developer.
For more information on Access as it relates to using Turbo Architecture, please review the Turbo
Architecture FAQ page on the National ITS Architecture web site http://www.its.dot.gov/arch/arch.htm,
3
select the Turbo Architecture button, and then select the FAQ options by Turbo release version.
2.5 Overview of the Turbo Architecture Software

The Turbo Architecture software includes the Turbo installation (Setup) program includes the Turbo
executable software files, sample databases, and an electronic copy of all Turbo documentation,
including this manual. This section provides instructions on installing the tool, and a brief introduction to
the sample database.
2.5.1 Installing and Running Turbo Architecture

Turbo Architecture uses the Microsoft Windows user interface and will run under Windows 98 Second
Edition, 2000, XP, or Vista operating systems. The Turbo setup.exe file is executed to install the software
and link to the databases required to run Turbo Architecture. The installation setup is described in the
Turbo Architecture Installation Guidelines document.
To execute the tool after installation, simply double click with the left mouse button on the Turbo 4.1
icon on your Desktop; OR on the icon for the tool in the directory where you loaded Turbo; OR, from the
PC toolbar, select StartProgramsNational ArchitectureTurbo 4.1 (or your own Program
Manager Group name created during installation). The main window will appear, including menubar

options and architecture development tabs. All features are fully described in subsequent sections of this
document.
2.5.2 Accessing and Using the Sample Marinara Turbo Database

On the Turbo Architecture CD-ROM, a sample database is included called marinara.tbo. This sample
database can be used by the reader to become familiar with the functions of the Turbo Architecture
software described in this manual.
In the example, the Marinara County Transportation Region encompasses rural and urban areas,
including the rapidly expanding City of Saucelito. The total regional population of 675,000 is
demographically diverse: 5% continue the traditional regional farming activities, 62% are Saucelito
residents, and over 50% of the regions workers are in technology industries. Marinaras largest employer
is ParmaJohn, a pharmaceuticals firm with a payroll of over 11,000 workers.
Tourism has begun to supplant agriculture as Marinara Countys number one revenue generator. As the
largest producer of sundried tomato products in the northern Midwestcoast region, the vacation appeal
of the area is enormous. The 2001 Drying of the Tomatoes drew 2 million visitors during the peak 6-
week period. Over 500,000 of these attended the weekend Saucelito Tomato Wine festival alone. The
crush of this tourist load has pointed out the limitations of the current transportation system, as the
festivities bring local residential and business traffic to a halt during peak hours. This has led to several
regional initiatives in road improvements and information dissemination. In particular, Marinara County
DOT is pushing a travel information initiative with the acronym TOMATO.
Marinara County and its central business district in the City of Saucelito have significant activities in
technology, light industry, agriculture, and tourism. The organizations involved in transportation and
related activities in the county are quite varied. A brief overview is provided of the principle groups that
should be involved in any regionwide initiatives. The centers and other elements of Marinara County are
described in the next table.
Table 3. Centers and Organizations of Marinara County
System Status Center Description
Roadway Existing Marinara County Operates the freeway and state roads within the
Transportation Department of county:
Transportation 1. Loop Sensors (existing)
(MCDOT) 2. Dynamic Message Signs (DMS) (existing)
3. Highway Advisory Radio system (HAR)
(planned)
4. Share information with SCDOT on freeway
and arterial traffic and incidents (planned)
Roadway Existing Freeway Management Located in downtown Saucelito manages the
Transportation Center (FMC) freeway system around Saucelito
Roadway Existing Bay Area Safety Provides detailed electronic records of incident
Transportation Information Logging histories and impacts
(BASIL)
Roadway Existing Potential INCident Uses BASIL data to provide warnings to the
Transportation Hazards (PINCH) operators at times of high risk of incidents
Roadway Existing Saucelito City Dept of City Operations Center -- central point for
Transportation Transportation monitoring the signal system (327 intersections)
(SCDOT)
Roadway Existing Marinara County Dept Road maintenance activities within Marinara
Transportation of Public Works County
(MCDPW)

System Status Center Description

Roadway Existing Greater Area Tracking system for scheduled activities in
Transportation Roadway, Lane, and MCDPW, which can also provide estimates of the
Intersection Closure probable impacts on roadway capacity during the
(GARLIC) work period
Traveler Planned Travel Optimization for Provide enhanced regional traveler information
Information Metropolitan Area
Transportation
Operations
(TOMATO)
Transit Existing Peninsula Area The only public transportation provider (Bus
Service Transit Operations Center) in Marinara County -- 200
Agency (PASTA) bus fleet with most of the fixedroutes
concentrated within the City of Saucelito
Emergency Saucelito City Saucelito City runs the Saucelito Fire and
Services Government Rescue Center -- two substations with fire and
paramedic vehicles are located within the city
Parking Marinara County The County Government Building in downtown
Government Saucelito has a 1000-space lot and parking
garage facility -- monthly reserved spots
controlled by a vehicle tag, plus general parking
Parking Marinara County Capacity to park 1200 vehicles for normal events,
Fairground 800 more for special events
Private Sector Smith Cable Interested in expanding their cable coverage of
Incorporated local traffic conditions
Private Sector Existing SunDried Mall Operates the SunDried Mall on the southeast
Partners (SDMP) edge of Saucelito a 200,000 sq. ft. enclosed
pedestrian mall with parking for 2000 vehicles,
plus PASTA bus service
Other Existing Marinara County Primary organization facilitating any regionwide
Transportation transportation planning efforts planning to
Planning Board implement a data warehouse to allow rapid
(MCTPB) access to archived regional data
Other Saucelito City The City Council has appointed an Event
Council/Event Planning Board (EPB), which is focused on the
Planning Board issues that arise from the annual tourist events
Other Marinara Port Coordinate the air and water transportation of
Authority Marinara Countys agricultural products.
Intermodal port facility that manages access of
commercial vehicles to the local airport and the
dock area of the small port south of Saucelito,
and leasable depot facilities for trucks
The next figure illustrates the interconnections for the Marinara County Department of Transportation in a
way that might be used to engage a group of regional stakeholders.

MCDOT Traveler MCDOT FMC Operations

PASTA Bus
Kiosk Network Detectors & VMS Staff
Operations Center
ACCIDENT
AHEAD
MCDOT
Personal FMC
TOMATO
Computer Event
Traveler
Clearinghouse
Information SCDOT
Center
TV
Saucelito Fire and
Channel SCDOT Loops
Rescue Center
72 and Controllers
Figure 4. Example of Marinara County Interconnects

The next figure shows an Interconnect diagram generated by Turbo Architecture for Marinara Countys
TOMATO Regional Traveler Information system.
MCDOT and State Highway Patrol Saucelito City Department of Transpo... Event Clearinghouse
Marinara County Freeway City Operations Center
Management Center (BASIL and
PINCH)
Peninsula Area Service Transit Autho... Marinara County Department of Tran... Marinara County Department of Tran... Saucelito City Department of Transpo...
Bus Operations Center TOMATO Regional Traveler Detectors and VMS Loops and Controllers
Information
Saucelito Fire Department FMC Operations Staff TOMATO System Users

Saucelito Fire and Rescue Center Internet PC Access via the WWW
Marinara County Department of Tran... Traffic Channel 72 on cable

County Traveler Kiosk Network
Existing
Planned
Figure 5. Example of Marinara County Interconnect Diagram from Turbo

2.6 File Overview

Turbo Architecture is a stand-alone application. It does not require any other applications, or databases
in order to be used. Turbo generates Microsoft Access 2000 and XP-compatible databases, but it is not
necessary to have the Microsoft Access software resident on the machine in order to run Turbo. Nor
does Turbo require any National ITS Architecture databases from the National ITS Architecture CD-ROM
or web site. After bringing up the application, the Help => About Turbo Architecture option on the main
menubar displays the version number for the Turbo Architecture application, and for all portions of the
National ITS Architecture that are used with that version of Turbo Architecture.
Turbo Architecture V3.1 includes support for the file extension, .tbo. Turbo V3.1 accepts the file
extension .tbo as well as the older .mdb extension when opening or converting Turbo files. The .tbo
file may also be double clicked from a Windows Explorer window and the Turbo Architecture application
is launched. See Section 2.4 for a discussion of Turbo Architecture, Windows, and Microsoft Access.
Although the .tbo extension does not completely prevent a user from opening a Turbo database using
MS Access, which non-expert Access developers should never do, it is less likely that the user will want
to do this and damage his Turbo file.
When you use the tool to create an architecture, there will be a single Turbo Architecture database file
created by the tool. This database will contain data tables, relationships, and elements for a single
Regional Architecture and multiple Project Architectures. If a second Regional Architecture is to be
defined, this must be done in another Turbo Architecture database file. Instructions for creating and
maintaining the database files and architectures generated by the tool are discussed in Sections 3 and 4.
GUIDELINE: Save your work often. Data is only saved when you choose the Save or Save As
options (or when you exit the file and save). All work you do between saves is put into a temporary
file called turwork<time/date stamp>.mdb. As you work this temporary file grows in size. If you
wait too long to exit and save, this file can grow so large you may not be able to save it. If the tool
should fail with unsaved data, you may be able to partially recover. Look for the temporary file in
the Windows temp directory (C:\Documents and Settings\<logon id>\Local Settings\Temp).
Rename this file to end in .tbo and then try opening it with Turbo Architecture. See the release
notes for more hints on how to correct this problem if it happens.
In order to actually shrink the size of the temporary file while working with large architectures, you must
exit periodically from the file, or from Turbo. Saving the architecture places new work in the original user
file in compressed format, but the temporary file remains at the same size and keeps growing. To shrink
the temporary turwork<time/date stamp>.mdb file, the database file must be closed.
2.7 Accessibility Features of Turbo

In Turbo Architecture, Accessibility features are supported for compatibility with Section 508 of the
Rehabilitation Act of 1973, the Standards for Electronic and Information Technology section. These
features include the following:
1. Keyboard Shortcuts for all menu, toolbar, and window commands.
2. Accessibility Information in the Users Manual (all figures include alternative text and tables
include appropriate markup via PDF tags).
3. Users Manual and Installation Guidelines in accessible Adobe Acrobat Tagged PDF format.
2.7.1 Keyboard Shortcuts

There are several ways in which to access Turbo options and pulldown menus for accessibility without
using a mouse. Many options include a CTRL + <letter> shortcut to perform a Turbo option. These are
listed on the pulldown menus. For example, CTRL+S to save a file, appears next to the File => Save
option on the pulldown menu. CTRL+R will bring up the Reports window. The ESC key acts as a
cancel button.

The figure below illustrates the File pulldown menu, including the CTRL keyboard shortcuts.
Figure 6. File Menu with Ctrl-Key Shortcuts

There is another shortcut method that may also be used. If the user presses the ALT key, the menubar
appears with the first character (in some cases it is another character) of each pulldown menu underlined.
You may then type the underlined character for the menu and option that you are looking for, such as,
ALT key, F for the File pulldown, then O to open an existing architecture. Case is not important and
the ALT key does not have to be held down while pressing these other keys. The following figure
illustrates this feature for the Tools pulldown menu after pressing the ALT > t keys:
Figure 7. Main Menu with Alt-Key Shortcuts

You may also press the ALT key and the underlined letter (press at the same time) for each of the tabs
across the top of the Turbo main menu, or press ALT > s (Start tab) then the right and left arrows to
move between the tabs. For example, ALT > i will display the Inventory tab. Then it is a matter of
pressing the right, left, up, and down arrows, as well as the tab right and left (Shift > Tab) keys to move
between the list of Inventory items and the options and tabs on the right of this screen.
A combination of tab and arrow keys may also be used to move around the Reports windows, but to
return to the list of reports from the options on the right side of the window, you must press the left arrow
while you are on the Preview option, not the left tab. Tabs and arrows will both move between the
options on the Reports window.
One scenario for using the ALT key and tabs and arrows to move around the window might include:
1. Press ALT > S to view Start tab.
2. Press right tab 4 times to enter project list area, and up and down arrows to select a project.
3. Press ALT > i to view the Inventory tab.
4. Press right tab 2 times to view the Project Elements tab.
5. Press right arrow to view the All Elements tab.
6. Press right tab to bring the Inventory element list into focus.
7. Press up and down arrows to display each element and its attributes.

8. Press right tab several times to move to the New option. Enter will select the New option.
Then, use the tab keys to move between the data entry fields. Use Alt>down arrow to bring up
the list of Stakeholders, and the arrow keys to select (or create a new) stakeholder. If selecting
from the list, press Enter to make the selection.
9. Press right tab several times to move to the Delete option. Enter will select the Delete option
for the selected element.
10. The right tab will move from Delete to the Project Elements or All Elements tabs.
11. The right tab again will move into the element lists, and again will move to the attributes for a
selected element. Type a name or description, or use the arrow keys to move between and
select a new stakeholder for the element that is currently selected.
12. To select a new stakeholder, press the up and down arrows to find the required name, then the
right tab key to move to the Apply or Cancel options (the right tab key must be pressed a few
times to bounce over the other tabs and options on the right side of the Inventory tab).
13. The Shift > Tab (backwards tab) key combination will move backwards from field to field. If you
have just Applied a new stakeholder for a selected element, the backwards tab may be used to
move back to the Stakeholder field.
14. If on the Stakeholder field, tab to Selected Subsystems/Terminators, then the right arrow to
move to the All Subsystems/Terminators tab. The right tab key will move to the list of
subsystems and terminators where a new selection may be made using the arrow keys, then the
space bar to actually select this subsystem or terminator. [The user may expect the Enter key
to select the entity, but the space bar actually does the selection.] The space bar is also required
to select a project from the list.
You should get the idea. This requires a combination of the tab and arrow, Enter and space bar keys.
The Interfaces tab user interface works a little differently. The tab and arrow keys will move down the list
of architecture flows and to the options at the bottom of the window, but they do not move to the options
at the top of the window (Connect, Flows, etc.). This is a known problem with the third party tool that is
used to generate this screen. Hence, all of Turbo Architecture and the documentation is compliant with
Section 508 except for the toolbar on the Interfaces tab.
2.7.2 Toggle between Open Applications without Mouse

When using an application such as Turbo Architecture, the user may toggle between open applications in
Windows that appear across the task bar (generally at the bottom of the screen) without using a mouse.
There are two ways to navigate between open applications:
1. Use the ALT > TAB keys:
a. From any window, tab, or option in Turbo Architecture, press the ALT > TAB keys at the
same time. A small navigation window pops up with an icon representing each open
application.
b. While holding the ALT key down, use the right Tab and Shift > Tab keys to move
between the open applications. One of these applications is an icon for Turbo. If selected,
Turbo Architecture remains active. If another application is selected, such as a Windows
Explorer window, this screen pops in front of the Turbo window.
2. Use the ALT > ESC keys:
a. From any window, tab, or option in Turbo Architecture, press the ALT > ESC keys at the
same time. This will toggle between the open applications. The main difference is that with
ALT > ESC, the application windows must actually be active (click on each window to
maximize it). If ALT > ESC is attempted when an application window is minimized, it will not
come up.

3 Turbo Tabs
Notice that the appearance of the tabs across the top of the Turbo window is oriented towards the work
flow of generating a Regional Architecture (see the Regional Architecture Guidance document). There is
one tab for each major step in the architecture development work flow.
The tabular input windows consist of the following tabs where inventory elements and services may be
entered and customized:
Start Section 3.1 Create/modify/delete an architecture.

Use the Interview (section 3.1.4) when an architecture is first
created
Stakeholders Section 3.2 Create/modify/delete a stakeholder name or group, global to all
architectures in the file
Inventory Section 3.3 Create/modify/delete an element in the open architecture
Services Section 3.4 Associate a National ITS Architecture market package with local
inventory elements
Ops Concept Section 3.5 Create/modify/delete role and responsibility areas to the current
architecture based on market package choices
Requirements Section 3.6 Associate functional areas with inventory elements, then
create/modify/delete functional requirements based on the
inventory and market package choices
Interfaces Section 3.7 Build and customize the architecture
Standards Section 3.8 Customize the list of applicable ITS standards based on
inventory, market package, and interface choices
Agreements Section 3.9 Create/modify/delete lists of agreements between stakeholders
and agencies in the region
There is a certain order to be followed while using the tabbed windows. Several of the menubar options
or menu tabs will be grayed out if they cannot be used yet. For example, a user is not allowed to
customize the inventory and architecture flow list if an architecture has not been created or opened.
All tab windows indicate the deployment status of an item (element, market package, architecture flow).
As an aside, the items that you will see on the inventory input and customization tabbed windows (the
Inventory, Services, and Interfaces tabs) are directly related to the National ITS Architecture. There are
entities (subsystems and terminators) and market packages that when built into the Project or Regional
Architecture (i.e., selected and assigned to a local element) generate architecture flows that are directly
associated with the National ITS Architecture entities assigned to the elements.
GUIDELINE: It is strongly recommended that the user be trained in the terminology,
relationships, and usage of the National ITS Architecture. The USDOT offers classes across the
country on the Architecture. There is also the National ITS Architecture CD-ROM and web site
that may be used as a reference. The Regional ITS Architecture Guidance Document is also an
excellent resource to see how to apply the National ITS Architecture.

3.1 Start Tab

Managing the architectures contained within a file is done from the Start tab as shown in the figure below.
This tab allows the user to create a new architecture or select an existing architecture. The tab allows the
user to define scope, time frame, and other basic definition information for the new or selected
architecture.
This screen will either appear as it does in the referenced figure, before opening a database file, or it will
appear as follows after opening an existing file and selecting an architecture. All architectures contained
in the file will be shown, and the architecture that was last opened in the prior use of the file will
automatically be selected when the file is opened.
Figure 8. Start tab with Open File and Project Architecture Selected
The left-hand side allows the user to create a new architecture, delete an architecture, or select an
architecture. Selecting an architecture causes the right hand side of the window to be filled in and makes
the selected architecture the current architecture shown in the banner and on other tabs. The following
sections will explain in detail how to use these options.

3.1.1 Regional and Project Architecture Information
3.1.1.1 Beginning a New Architecture

A new architecture is created on the Start tab by selecting the New option under either the Regional or
Project Architecture areas. This adds a new architecture to the file. The following process may be used
to begin a new architecture:
1. Select the type of architecture:
a. When creating a new Regional Architecture in an open database file, the name of the
architecture must be entered. The other attributes of the architecture are optional. Notice
that for a Regional Architecture, there is no Status field. This field is available only for a
Project Architecture. Remember that there may only be a single Regional Architecture in a
Turbo Architecture database file. The system will not allow you to create a second one,
although the tool does not require that a Regional Architecture exist. The New button will
be active for a Regional Architecture only if there is not already a Regional Architecture
defined in the current file. The file may also consist only of Project Architectures.
b. When creating a new Project Architecture in an open database file, the name of the
architecture must be entered. The other items are optional. The names of existing Project
Architectures in this database file are displayed so the user may see the existing names. The
software checks if the user attempts to create a project with the same name as one
previously defined and prevents this. Select the status existing or planned and enter the
other options if needed. Then click Apply to actually create the architecture. This
architecture name will appear in the title bar of the Turbo Architecture main window, along
with the file name as well as in the Current Region/Project box at the top of each tab.
2. Enter or modify the attributes of the architecture on the right-hand side of the window. These
fields provide information for user to completely describe the scope of a Regional or Project
Architecture. Items such as Geographic Scope, Service Scope, and Timeframe, are discussed in
more detail in the Regional ITS Architecture Guidance document. All of these attributes may be
changed later on the Start tab, and will be displayed for each architecture in the file, in the
Architecture Summary report (see Section 4.4.4). The following is a description of the attributes
assigned to an architecture and whether those attributes are MANDATORY or OPTIONAL.
a. Name Name of the architecture. MANDATORY.
b. Description Description of the architecture. OPTIONAL.
c. Timeframe Define the planning timeframe that the Regional ITS Architecture will address.
Should the architecture encompass systems and services that are implemented over the next
five, ten, or twenty years? If this is a planned architecture for deployment in a future
planning cycle (e.g., two years from now, or the five, ten, or 20 year planning horizon), this
should be entered here. When developing a Project ITS Architecture this field can be used to
indicate the expected year or timeframe for deployment of the project. OPTIONAL.
d. Status Existing or planned, for a Project Architecture only. If the user has extended the list
of status values, all will appear in this list. MANDATORY.
e. Geographic Scope Where the architecture will be deployed (e.g., District 7, Southern
California). Ideally, the geographic scope of a region should be established so that it
encompasses all systems that should be integrated together. In practice, it is sometimes
difficult to determine where to draw the line so that the architecture is inclusive without
expanding to the point that the effort becomes unmanageable and consensus is difficult to
achieve. While this is frequently called a geographic area, it is usually a political map that is
being partitioned, defining a region along existing institutional boundaries. The rule/policy
states that metropolitan areas should consider the metropolitan planning area (MPA) as a
minimum size for a region. The MPA is a good place to start since this boundary normally
encompasses most integration opportunities and it coincides with the geographic region used
for transportation planning. OPTIONAL.

f. Service Scope Determine the basic scope of the services that will be covered. For
example, determine if the Regional ITS Architecture should define commercial vehicle related
services. OPTIONAL.
g. Developer Name of the person or team that has developed this architecture. OPTIONAL.
h. Maintainer Name of the person or team maintaining this architecture. OPTIONAL.
i. Version The user may enter a value for this field that makes sense for the region.
Architecture version numbers or names should be agreed to by all affected parties, and
should be consistent across all architectures in the region covered by this regional
architecture. OPTIONAL.
j. Date/Time This field displays the current date and time when a new architecture is first
created. The revision date/time field may be changed by the user when the architecture
attributes are modified. OPTIONAL.
The window that is displayed when creating a new Regional Architecture is similar to the above
it asks for the name and description of the architecture (and all other attributes except for status),
and will not allow you to create a new Regional Architecture if one already exists in the file.
3. When creating a new Regional or Project Architecture, the following window appears asking if
you would like to create it using the Interview Dialog or not. Select Begin Interview for the initial
architecture definition.
Figure 9. Interview Option Window

GUIDELINE: During a single Turbo Architecture session, the user will not be able to open more
than one database file at a time for update.
3.1.1.2 Continuing Development of an Existing Architecture

The following process is used to continue development of an architecture in progress.
1. To open an existing architecture, bring up the Start tab as above in an open database file, select
the Project or Regional Architecture name from the lists on the left, modify the attributes for the
selected architecture on the right, and click Apply (available only if attributes were changed).
These attributes were discussed in the previous section of this manual. The architecture name
will appear in the title bar of the Turbo Architecture main window, along with the file name.
2. To save and close this architecture and open another architecture from the same database file in
the same Turbo Architecture session, select the other architecture name on the Start tab, or
select the New option under Project or Regional Architectures (if a Regional Architecture does
not already exist) to create a new architecture in this file. Turbo Architecture allows only one
architecture to be opened at a time, so opening a second architecture will close the first. If
changes have been made to the first architecture, the user is asked to save them before the
second architecture is opened. The new architecture is opened in the same Turbo Architecture
session.

3. Because all of these architectures are stored as tables in the same database file, changes will not
be saved to the database unless explicitly requested by the user by one of the following
commands. See Section 4.1.5 for more information on saving the database.
o File => Save
o File => Save As (user is asked to enter a name for the database file)
o File => Open (opens a second database, user is asked to save architecture updates
and Turbo closes the first file and architecture)
o File => New (creates a new database, user is asked to save architecture updates and
Turbo closes the first file and architecture)
o File => Exit (user is asked to save updates to the open database and architecture)
3.1.1.3 Deleting an Architecture

The following process may be used to delete a Regional or Project Architecture from the database file.
1. To delete a Regional or Project Architecture in an open database file, go to the Start tab (see
Figure 8. ), select the architecture name to be deleted, then click the Delete option.
2. If you have selected an architecture to delete, a verification window will appear where you may
cancel the delete or continue.
NOTE that deleting the architecture from the database file does not actually delete all references to
elements used in this architecture that may be connected to other elements, stakeholders, entities, or
architecture flows, in the rest of the Regional Architecture. This process is manual and must be done by
the user on the Interfaces tab after deleting the architecture.
NOTE again that the architectures are stored as tables in a database file. However, changes made to the
file are not automatically saved to the database (this works differently from Microsoft Access). The user
should explicitly save changes periodically (this is automatic when exiting from an architecture the user
is asked to save updates). This also compresses the database file and removes the temporary files.
3.1.1.4 Modifying the Attributes of an Architecture

The following process may be used to modify the attributes of a Regional or Project Architecture in the
currently open database file. These attributes include the architecture name, description, status, and
many other items (see Section 3.1.1.1).
To modify a Regional or Project Architecture name, description, status, or other available attributes in an
open database file, go to the Start tab, select the architecture name whose attributes are to be modified,
and update the attributes on the right-hand portion of the screen. Click Apply to accept the changes, or
Cancel to ignore changes to the attributes of the architecture.
NOTE that this is the ONLY way to change the description or status (existing/planned) of an architecture
in Turbo Architecture. If you made a mistake when entering this information on the initial creation of an
architecture, or if a change is needed later, this feature is used to make these modifications. If a project
is being moved from the planning to the existing stage, this may be done here.
As with element and stakeholder names, the architecture name is stored by identification number in
Turbo Architecture, so changing the name of the architecture on the Start tab will change it everywhere in
the database file.
3.1.1.5 Change Log

Architectures are not static, they will undergo change. Turbo includes a Change Log that provides the
ability to record the changes made to the Turbo file. This log includes a record of the changes made to
the selected architecture as recorded by the user. The user can add/modify/delete entries in the change
log. Each entry includes timestamp, name, version, and change description.
1. Select the Change Log option at the bottom of the Start tab for an existing architecture in an
open database file. The following screen will appear:

Figure 10. Change Log Window

2. The window title identifies the architecture by name.
3. The left-hand list box lists all maintenance records for the current architecture, ordered by
Date/Time. Standard operation picking an item on the left causes all information for the record
to be displayed on the right.
4. This example displays a list of existing change log entries. The user is creating a new entry by
selecting the New option. Todays date/time has come up automatically, but this may be
changed by the user. The user then enters the name of the person (50 characters max) updating
the log (this could be a different person from the maintainer shown on the Start tab for this
architecture), a new version number (default is the version on the Start tab, 50 characters max),
and a description of the change. All fields are optional except for the date/time.
5. The Delete option can be used to delete maintenance records (change log entries).
6. Click Apply to accept the changes, or Cancel to ignore the changes, then Close to close this
window. The Close option toggles to Cancel and Apply is active when the user is editing.
7. The Date/Time and Version fields have buttons to the right of them with the title Apply to
Start Tab. Selecting these buttons will cause the date/time or version number that shows on the
Start tab to be updated. NOTE: If the person making the change is the same as the Maintainer
on the Start tab, then the Apply to Start buttons will default to checked. If the person is not the
same as the Maintainer, then the buttons will default to not checked.
3.1.1.6 Project Sequencing

In Turbo Architecture there is a method for ordering Project Architectures in sequence by time to enable
the user to generate a basic Project Sequencing report that categorizes projects by timeframe or status
value (e.g., Short-Term, Mid-Term, Long-Term). The timeframe and status value information can be

defined by the user, providing some latitude in the level of sequencing detail that is documented and
reported by Turbo Architecture. Projects are ordered in sequence based on regional needs and project
readiness.
Several steps may be performed in order to create a sequence of projects:
1. Gather the initial project sequencing information from existing Regional Architecture planning
documents, such as the TIP, STIP, SIP, etc.
2. Define the ITS projects for the region in terms of the existing Regional ITS Architecture.
3. Identify the dependencies between ITS projects based on the element inventory, functional
requirements, and system interfaces. Identify projects that must be implemented before other
projects may begin.
Similar to traditional planning, project sequencing is a consensus building process and should not be
viewed as a ranking of projects. Stakeholders should begin with existing planning documents and focus
on short, medium, and long term planning decisions. For more information on this process, see the
Regional ITS Architecture Guidance Document.
In Turbo Architecture, if there is a Timeframe defined on the Start tab for the projects, then the list of
projects can be sorted in alphabetical order by timeframe. Otherwise, the status values of existing,
planned, and local status values, are used, in the near-term to long-term order that they appear on the
Tools => Update Status window. The user might opt to use user defined status values to support
project sequencing (e.g., create values of Near-Term, Mid-Term, and Long-Term and then assign these
status values only to projects). The projects appear in order by timeframe first, then by status value, in
the Project Sequencing report.
If one project in the file includes both a timeframe and a status value, then all projects are ordered
by timeframe first, then by status.
If the timeframe is left blank on one project but other projects in the file include a timeframe, then
the projects with blank timeframe appear first in the list, in status value order, and all other
projects are ordered alphabetically by timeframe.
If there are no timeframe values on any project, then the projects are ordered only by status
value.
In addition to the options that add, modify, or delete an architecture on the Start tab, there are two
additional options that have not yet been discussed. They will be presented when appropriate, since both
of these options rely on other topics to be discussed first.
The Project to Region option will be discussed in Section 3.1.1.8. This option is used to merge
a Project Architecture into an existing Regional Architecture, and may be used in various
situations, one of which is after an Import, covered in Section 4.1.4.
The Region to Project option will be discussed in Section 6.13, after presenting information on
creating multi-tiered architectures. This option may also be used in a variety of situations, and is
handled as an Advanced Topic.
3.1.1.7 Importing an Existing Regional Architecture

The first version of Turbo Architecture did not support import of Regional Architectures. In all subsequent
versions beginning with Version 1.1, a Regional Architecture may be imported from a source file into a
destination file, similar to importing a Project Architecture. This is a two-step process, as follows.
1. First, prior to the Import, the Regional Architecture must be converted into a Project Architecture
in the source file using the Region to Project option on the Start tab. The process for doing
this is described in Section 6.13, as part of the section on advanced topics. This conversion
process is also required for creating multi-tiered architectures.
2. Next, the new Project Architecture (converted from the Regional Architecture) may now be
imported into the destination file using the File => Import option, built via the Build option on
the Interfaces tab, and merged into the Regional Architecture in the destination file via the
Project to Region option on the Start tab. The Import process is described in Section 4.1.4.

3.1.1.8 Merging a Project into an Existing Regional Architecture

The Project to Region option on the Start tab adds all architecture flows associated with a Project
Architecture to the Regional Architecture. This option allows the user to initially merge a project with the
Regional Architecture (i.e., populate the Regional Architecture with project data), or to merge the project
again if it has been changed (i.e., if new customization has been done).
In order to associate an imported project with the Regional Architecture, the imported Project Architecture
must be merged into the Regional Architecture as any other project would be. If there is no Regional
Architecture and the user has defined a Project Architecture, he may create an empty Regional
Architecture, then add (merge) the project into it. At this point, the Regional and Project Architectures
should be identical. Any changes or customization made to either architecture will, of course, change the
associations between these two architectures. See Section 6.6 for more information about maintaining
consistency between the two architectures, or between all projects and the Regional Architecture in a file.
The following process is used to merge (add) an existing project to an existing Regional Architecture in
the same Turbo Architecture database file. Only one project at a time may be merged into the Regional
Architecture.
1. Make sure that a Project Architecture has been built (the architecture has been taken through the
Build option on the Interfaces tab, and perhaps tailored via the Interfaces tab) and is open.
Open the Project Architecture that you want to merge by selecting the architecture on the Start
tab. [NOTE: If the project has just been imported then it automatically meets this criteria. See
the section on Importing for a discussion of building the architecture after Import.] Also make
sure that a Regional Architecture has been defined. By that we mean that a name has been
given to the Regional Architecture (which you can also do on the Start tab select New under
the Regional Architecture area and give it a name, then click Apply). This architecture may be
left empty by skipping the Interview when asked to begin creating the Regional Architecture. OR,
it may be an existing Regional Architecture to which you need to add a new project.
2. On the Start tab select the project to merge, then Project to Region.

Merge
Project into
Regional
Figure 11. Merge Project into Regional

a. NOTE: This option is not available if a Project Architecture is not open (or if there are no
projects in this file). However, if there is no Regional Architecture in the file, a message will
be displayed (see the figure below) telling the user to create a Regional Architecture before
running the Project to Region option.
Figure 12. Project to Region Warning

3. By running the Project to Region option, Turbo will first review the project stakeholders and
display which, if any, of the projects stakeholders need to be added to the region.
4. Next, Turbo will review the project inventory to determine whether there are any inventory
elements that are not already in the region and will provide a message asking whether the
elements should be added to the region (see the figure below).

Figure 13. Project to Region Inventory Message

5. Turbo checks to see of the Project included any unique Status Values that need to be
incorporated into the regional architecture.
6. Turbo checks whether any of the market packages and associated status values are not part of
the region and need to be added.
7. Turbo checks to see if there are any Roles and Responsibilities defined in the project and
displays a message asking if they should be incorporated into the regional architecture.
8. Turbo checks to see if there are any Functional Requirements defined in the project and displays
a message asking if they should be incorporated into the regional architecture.
9. Next the architecture flows that are part of the Project Architecture will appear in a list to be
added to the Regional Architecture. Click Yes to add them or No to cancel the operation. (If
there are no new flows or project customization to associate with the Regional Architecture, then
a message is displayed that there is nothing to merge.)
Figure 14. Architecture Flows to be added to Regional Architecture

10. Turbo checks to see if there are any Standards Mappings defined in the project and displays a
series of messages as needed asking if they should be incorporated into the regional
architecture.
11. Once you have selected Continue after the last Standards mapping message the operation is
completed.
3.1.2 Related Architectures

There are now approximately 330 ITS architectures representing statewide areas, metropolitan regions,
corridors, or districts within a state. There are also a small number of multi-state architectures. With so
many architectures across the country there is bound to be some overlap, either in geographic scope or
in the types of services that are represented. A regional ITS architecture can be developed to cover a
metropolitan area but it could also be developed for an entire state. In many places, both exist the
cities have their architecture for their existing and future services and there are district or statewide
architectures covering services planned by the state DOT for larger areas.
The Regional ITS Architecture Guidance document discusses this topic of adjacent and overlapping
architectures:
Consider the scope of other regional ITS architectures when defining the boundary.
Where there are adjoining or overlapping regional ITS architectures, coordinate with the
other region(s) to reach agreement on how common systems or interfaces will be
represented in the two (or more) regional ITS architectures. For example, many states
have created statewide ITS architectures that must be taken into account by the
metropolitan area architecture(s) in those states. A few agencies have also created their
own agency architectures that focus on internal agency interfaces, creating additional
levels of architecture definition that should be taken into account in establishing
architecture scope.
Special care is required when regional ITS architectures do overlap. Caution should be
used whenever the same ITS element or interface is included in more than one regional
ITS architecture. Unless automated methods like a relational database or Turbo
Architecture are used, it is almost certain that some difference or ambiguity will arise in
the two (or more) representations of the same architecture definition. Whenever possible,
it is a good idea to define the ITS element or interface in one architecture and reference
the one authoritative definition in all other regional ITS architectures.
Turbo Architecture includes a couple of features to help document that there are other architectures
involved and track the elements that may be included in another architecture. This can help the
maintainers of an architecture coordinate their updates with the stakeholders of the other architectures.

Figure 15. Start Tab with Related Architecture Information

On the Start tab, the Related box, shown in the figure above, lists other architectures that have been
input. These other architectures are meant to be other regional/statewide architectures that are in other
databases somewhere. It could also include a project architecture that is stored in another file.
To add a Related architecture, click the New button below the Related architecture box. The right side
of the screen will change to allow for data entry of the new related architecture. The Name is the only
required field but the Description, Timeframe, Status, Geographic Scope, Service Scope, Developer,
Maintainer, Version, and Date/Time can also be edited.
The Description field of the Related Architecture should be complete enough to understand something
about the other architecture and its relationship to the current architecture. Include the filename, the
overall scope, and the main agency responsible for it. Other information to include might be the reason
that this other architecture is related to the regional or project architectures in the current database.
Tip: An easy way to populate the Related Architecture information is to open that other architecture in
another Turbo window (Yes, you can have 2 copies of Turbo running at once). Then copy the information
from the Start tab of one screen and paste it into the Start tab of the other screen.
Once you hit Apply the information is stored and the name is added to the list on the bottom left side of
the Start Tab. To edit the information of a Related architecture, simply click the name on the left side of
the screen, change the attributes on the right as needed and click Apply.
To remove a Related Architecture, click the name of the Related architecture and click Delete. Click
Yes on the confirmation box and the name of the related architecture and its attributes will be removed
from the database. This would be useful when, perhaps, a project that used to be in a separate file has
been imported into this file.
The Related Architecture will be available on the Inventory tab to be able to identify an element as being
Shared with elements in another architecture. More on this in section 3.3.2.1.

3.1.3 Managing Items within an Architecture
3.1.3.1 Add/Modify/Delete Items within an Architecture

The Delete option on the Start tab only allows the user to delete an entire architecture from the
database. In order to add, modify, or delete items that make up an architecture, see the appropriate
sections of this manual.
Guideline: Remember that when naming an element, stakeholder, architecture, etc., certain special
characters (apostrophe (), ampersand (&), and quotes ()) may not be used in the name. Turbo will
give a warning message and not allow these names. Blanks, underscores (_), hyphens (-), are all
acceptable in a named item in Turbo.
3.1.3.2 Creating Elements and Architecture Flows

There are several ways in which to create new elements and architecture flows:
1. One way to create new elements/flows in a Project Architecture is to associate existing elements
with a project on the Inventory tab in the Regional Architecture. This may be done when initially
creating the Project Architecture (the name must already exist, but the project may be empty), or
to add new elements to an existing project from the Regional Architecture. You may need to
modify or select an additional market package on the Services tab, as well, in order for the Build
step (to build the architecture) to result in the desired architecture flows. Build the architecture,
then modify the flows on the Interfaces tab. Refer to the National ITS Architecture to determine
the flows that will be added for the new market package. If there are far more than you actually
want, you may try a Conservative Build first using the build Settings on the Build option on
the Interfaces tab. This will produce a list of all not planned flows. If too much customization
will be required with this list, select No (do not add this list to the architecture), then try a more
Aggressive Build. Finally, open the Project Architecture (on the Start tab) and merge the project
into the Regional Architecture (Project to Region option on the Start tab).
2. Another way to create new elements/flows in the Project Architecture is to add them on the
Inventory tab in the Project Architecture. Market package selections may be added or modified
on the Services tab. In order for these new elements and architecture flows to be visible to
Project to Region, Import, or to the Interfaces tab, the uncustomized architecture must be built
via the Build option on the Interfaces tab. Interconnections and architecture flows may then be
modified on the Interfaces tab prior to the Project to Region or Import processes.
3. A third way to create new flows is to open the Project Architecture and change a Not Planned
flow in the Flows view on the Interfaces tab to Existing or Planned, then select the Project to
Region option on the Start tab to merge (add) it into the Regional Architecture. When you re-run
the Build step to re-build the Regional Architecture, then look at the flows on the Interfaces tab
again, the flow will now appear in the Regional Architecture.
In the above discussion, note that only elements may be added on the Inventory tab. They will be
associated with architecture flows depending on a couple of factors, i.e., the entities (subsystems and
terminators) associated with the element on the Inventory tab, and the market package selections and
associations for the element. However, in order to actually add a new flow that is not part of the National
ITS Architecture, you must use the architecture extensions options (Add Entities, Add Flows), available
from the Tools pulldown on the menubar. See Section 4.3.1 for more on architecture extensions.
3.1.3.3 Rename an Element

To rename an existing element:
1. From the Inventory tab, select the element from the list on the left-hand side of the window.
2. Edit the Name field on the right-hand side of the window and click Apply. If the element is
renamed in this fashion, all references to the element also receive this new name.

NOTE that an element/center may not be renamed during the Interview dialog. You are not allowed to
type over an existing name on the Center Identification window of an Interview category. The only way
in which to rename an element is to follow the above instructions on the Inventory tab.
3.1.3.4 Merge Two Similar Elements

Two elements may be created that have similar names. This may happen during Import or by creating
them in the Interview for different projects in the same region. A common type of problem is that one
version of the name has imbedded blanks, and the other name includes underscores. Another common
problem is when one version of the name includes an acronym (TMC, for instance), and the other name
is spelled out.
If the user meant to use the same element name, the process to merge these elements is manual:
1. First, look at all the associations and elements related to both elements with similar names.
These will include the <element>_Personnel, <element>_Roadside Equipment,
<element>_Kiosks, and other elements created by the Interview or on the Inventory tab.
Decide which to keep and which to throw away later.
2. The user may wish to see if the interconnects are identical for the similar elements. The
Interconnect and Architecture Flow diagrams may be displayed and printed by selecting one
element on the Element Selection option of the diagrams pulldown menu, then selecting the
Show All option on the diagrams menu. Either diagram will show the interconnections and flows
between the selected element and all other elements it connects to in the architecture. Diagrams
for both the element that is to be kept, and the element that you would like to merge into it, should
be displayed, printed, and checked to see if the interconnections and flows are identical.
Discrepancies between the diagrams should be resolved before deleting the old element(s).
3. Next, if all associations (stakeholders, subsystems/terminators, market packages, projects, and
customizations interconnections and architecture flows) are the same as the element(s) that will
be kept, then reassign the element associations on the Services tab for the element(s) to be
deleted to the element(s) that will be kept. Finally, go to the Inventory tab, and delete the
unwanted elements. See Sections 3.3 and 3.4.
4. If the associated items and related elements are different, decide which to keep, reassign the
stakeholders, entities (subsystems, terminators, user defined entities), market packages, etc., on
the kept elements as appropriate, go to the Inventory tab, and delete the unwanted elements.
5. Make sure that any customization done on the deleted element(s) is also applied on the
element(s) that are kept. The links to flows and interconnects must be re-established for the kept
element(s) and the unwanted element(s), flows, and interconnects deleted. The output reports
and diagrams should help to re-establish the associations.
As you can see, this process may be time consuming if there are many associations, interconnects, and
flows for the two similarly named elements. It is far easier to establish a consistent naming convention at
the beginning of architecture definition than to try to fix this later. See Section 6.1 for some suggestions
and guidelines on naming elements and other items in Turbo Architecture. If element names in an
imported architecture are similar to names in the Import destination file, and they should be identical, the
element names should be changed in the architecture to be imported before actually doing the Import.
If all element associations are the same as in the destination file, then the element in the destination file is
retained.
3.1.3.5 Using Comments to Document the Architecture

GUIDELINE: The user will be able to add a comment to each element, market package, and
architecture flow when it is selected for the Regional or Project Architecture. These comments
may be used to state why a particular element was selected or not for the architecture, or what it
will be used for (for example, if it exists in a Project Architecture that has been added/merged
into a Regional Architecture, but is not needed for the Regional Architecture, or vice versa). The
user may also choose to display these comments on certain tabular output reports.

Comments exist mostly to document areas of the Project Architecture, but they may also be used in the
Regional Architecture. If a comment is changed in the Project Architecture, it is reflected in the Regional
Architecture (this is a global change). A comment field is available on most of the tabular windows, and
by selecting the Info button on the Interfaces tab, in the Flows view (see Section 3.7.2.4).
3.1.3.6 Printing Tab Data

If the user needs to print the information that is included on a tab window, such as the Inventory or
Customize window, use the buttons on the keyboard for Ctrl > Print Screen (or Alt > Print Screen)
and paste (Ctrl > v) the data into a document, note, or other file. Using the Ctrl button will copy the
entire screen, including all windows and the command task bar at the bottom of the screen. Using Alt
will only save the highlighted window on the screen. If you need to print the tabular data in a window, but
also would like to see some menubar pulldown, you must first make the Turbo window a full screen, scroll
down the command bar (so you cannot see it at the bottom of the screen), and use the Ctrl > Print
Screen buttons.
This method will not print a scrollable file. Multiple print screens and paste must be done to print the
scrolled information included in a scrollable window. NOTE that there is no File => Print option on the
main Turbo Architecture window. If there is a great deal of information on a tabular window that you
would like to print, one of the output reports may be a better way to go. Reports can be printed or saved
to a file for import into another tool such as Excel.
3.1.4 Using the Interview

There are two methods used to input information to the tool:
Narrative questionnaire screens interview dialog
Direct database table entry input via tabular windows
GUIDELINE: When defining a new Regional or Project Architecture, new users may want to do the
initial input using the Interview Dialog. After the initial interview questions have been completed,
the resulting data may be customized via the tabbed windows. More experienced users may find it
easier to skip the interview and go straight to the tabs.
See Section 7 for the list of the questions asked during the Interview Dialog.
The Interview guides the user through a series of questions and options that result in an element
inventory and a set of services being created. The tool will present questions and choices to the users
pertaining to general infrastructure or institutional elements of the architecture. Based upon the
responses, the tool will aid the users in making an initial set of choices regarding the architecture (either
Regional or Project) they are defining. The Interview dialog is meant to select common architecture
features, but not to cover all ITS elements or services. Once the Interview is completed, the user should
go to the Stakeholders, Inventory, and Services tabs, review the entries for correctness, and add any
additional elements or services that are in the region or project.
The alternate approach to data input is to forego the Interview and perform the entire data entry process
directly through the tabs. Beginning with the Inventory tab, for each element in the Region or Project, the
user defines an element name, a stakeholder who owns or operates the element, the status of the
element (existing or planned), the Project(s) which the element is a part of, and the mapping of the
element to one or more entities (subsystems and terminators from the National ITS Architecture, or local
user defined entities see Section 4.3.1). At this point, the user has the option to add user-defined
entities (parts of the architecture that represent extensions beyond the National ITS Architecture). Next
the user, on the Services tab, identifies the Market Packages (or services) that exist or are planned for
the particular project or region. For each Market Package selected, the user should make the appropriate
associations:
1. Assign all the elements that are involved in the Market Package.
2. Define the status of the Market Package, whether it is existing, planned, etc.
3. Assign the project(s) that the Market Package applies to.

3.1.4.1 Interview Basics

Before starting the Interview Dialog some initial legwork must be done to meet with stakeholders and
decide on exactly what the region currently requires and what may be planned for the future. Local
requirements and system element definitions must be agreed upon at these meetings. See Section 2.1,
for more information.
See Section 7 for a complete list of the Interview questions. These should be reviewed by the user (or
team) before attempting to answer them in Turbo Architecture.
The Interview Dialog portion of Turbo Architecture provides initial input only. The Interview produces an
inventory of local centers, systems, and related elements mapped to National ITS Architecture
subsystems and terminators, and a list of market packages from the National ITS Architecture, as well as
data about the interconnections between these entities.
NOTE that the Interview no longer includes human elements in the architectures that it generates as
these are counter to the Regional ITS Architecture guidance.
Turbo will associate a market package with existing services based on the narrative questionnaire
(Interview Dialog) screens for the Regional or Project Architecture. By associating a market package with
an inventory element during the Interview, Turbo Architecture is actually setting things up so that a set of
National ITS Architecture flows can be selected when you go to Build on the Interfaces tab.
NOTE that not every market package from the National ITS Architecture is covered by a question in the
Interview Dialog. When the Market Packages tab is displayed, a market package may be missing from
the list of selected market packages for this Interview category. Areas such as parking, Hazardous
Materials (HAZMAT), and Archived Data User Services (ADUS), are not completely covered by the
Interview. After the Interview, go to the Market Packages tab and add the market packages that may be
missing from your architecture. The Interview was always intended as a quick start, never as a
replacement for the tabbed windows.
GUIDELINE: The Interview does not create a complete architecture. The user must enter the
Inventory and Services tabs to add new elements or modify element and architecture flow
associations, and customize the architecture interconnections and flows on the Interfaces tab.
Each Interview question also asks the user to indicate if the architecture item or service is existing
(already deployed in the region), is planned for the future, or is not planned for deployment in the
region. If additional local status values have been added via the Tools => Update Status menubar
option, these will also be available for use during the Interview.
GUIDELINE: There are questions pertaining to Traffic included in the Freeway Management and
Arterial/Traffic Management Interview Categories. These include questions about environmental
sensor stations, ramp meters, signal preemption, lane control devices, and Highway Rail Intersection
(HRI). The Interview may also be used for collocating elements or centers. This is done by using
the Interview to select several aspects of a single center. For example, you may have a center that
performs both Freeway and Arterial Management. To input this information you answer the
questions for both categories. The first time through define the center and stakeholder (for the
first category), the second time through you merely select the same center and stakeholder (they
have already been created).
The Interview does not display the architecture flow level. This is done on the Interface tab. Once the
user begins to tailor the architecture, additional input will be done by using the Turbo tabbed windows.
GUIDELINE: When the user needs to customize the list of subsystems, terminators, and market
packages produced by the Interview Dialog, add locally defined elements (user defined entities or
flows), or define interconnections (integration permutations), he must exit the interview dialog
(never to return, for this architecture, that is) and enter the tabbed input windows to complete the
architecture.

3.1.4.2 Beginning the Interview

The Interview is initially available when creating an architecture. To begin the Interview Dialog:
1. For a new architecture, select the New option under either the Regional or Project Architecture
areas on the Start tab in an open database file. New is available for a Regional Architecture
only if there is no Regional Architecture already in the file. See Section 3.1.1.1 for information on
creating a new architecture via the Start tab.
a. On the Start tab, type the name and description (optional) of the new architecture, and enter
other attributes about the architecture as appropriate. The architecture name will then
appear in the title bar of the Turbo Architecture main window, along with the file name.
b. The prompt screen that appears includes two buttons, Skip Interview, which takes the user
to the tabular input windows, and Begin Interview, which initiates the Interview Dialog
shown below. Select Begin Interview. This displays the Interview Tree with the different
categories of questions (illustrated on page 35).
Figure 16. Interview Start

2. For an existing architecture, select the name of the architecture on the left-hand side of the
Start tab. See Section 3.1.1.2 for information on updating an existing architecture.
a. The architecture name will appear in the title bar of the Turbo Architecture main window,
along with the file name.
b. If the user had previously selected Quit the Interview for Now in the selected architecture,
he will then be prompted to continue the Interview when re-entering the architecture. NOTE
that most menubar items and tabs are grayed out, including opening another architecture.
The user must continue with the Interview for that paused architecture, and either answer
more questions about the architecture, or Exit the Interview for all options and architectures
to be available again. Select: Start (tab) => Continue Interview (button on the window in the
following figure).

Figure 17. Continue Interview

c. If the user had selected Exit Interview, or had been customizing the architecture using the
tabular windows, then he will not be able to re-enter the Interview Dialog in this architecture
and must continue entering data via the tabular windows.
NOTE that during the Interview (i.e., after selecting Quit the Interview for Now), the only menubar
options that are available are File, Edit, and Help. Output is not available output reports and
diagrams would display unexpected results while part-way through the Interview. Most reports and
diagrams will only have meaning after the Build step on the Interfaces tab has been done to build the
architecture. While on the Interview screens or in the Interview tree window, no menubar options are
available.

3.1.4.3 Interview Tree
Figure 18. Interview Categories

The Interview Dialog begins by displaying a tree of the various categories of Interview questions, as
shown above. The categories include:
Commercial Vehicle Operations -- Performs administrative functions supporting credentials, tax,
and safety regulations; issues credentials; collects fees and taxes, and supports enforcement of
credential requirements; processes credentials applications and collects fuel taxes,
weight/distance taxes, and other taxes and fees associated with commercial vehicle operations;
issues special Oversize / Overweight and HAZMAT permits; enables credential checking, weigh-
in-motion, and safety information collection. Corresponds to the National ITS Architecture
Commercial Vehicle Administration Subsystem (CVAS), Commercial Vehicle Check Subsystem
(CVCS), and Commercial Vehicle Subsystem (CVS).
Emergency Management -- Represents public safety, emergency management, and other allied
agency systems that support incident management, disaster response and evacuation, security
monitoring, and other security and public safety-oriented ITS applications. Includes public safety
call taker and dispatch centers operated by police (including transit police), fire, and emergency
medical services. Also represents other allied systems including centers associated with towing
and recovery, freeway service patrols, HAZMAT response teams, and mayday service providers.
Manages sensor and surveillance equipment used to enhance transportation security of the
roadway infrastructure (including bridges, tunnels, interchanges, and other key roadway
segments) and the public transportation system. Monitors alerts, advisories, and other threat
information. Interface with the Transit Management Subsystem (TRMS) allows coordinated use
of transit vehicles to facilitate response to major emergencies and to support evacuation efforts.
Provides incident detection and verification, incident response and clearance; monitors vehicle
location; provides fleet management support. Corresponds to the National ITS Architecture
Emergency Management (EM) subsystem, Emergency Vehicle Subsystem (EVS), and Traffic
Management Subsystem (TMS).
Electronic Tolling -- Provides payment at toll collection stop. Supports traveler enrollment and
collection of both pre-payment and post-payment transportation fees. Sets and administers the
pricing structures and includes the capability to implement road pricing policies in coordination
with the TMS. Corresponds to the National ITS Architecture Toll Administration Subsystem
(TAS), Toll Collection Subsystem (TCS), and Vehicle Subsystem (VS).

Freeway Management -- Monitors freeway conditions, identifies flow impediments, controls ramp
metering and lane control, controls Highway Advisory Radio (HAR) and Dynamic Message Signs
(DMS). Corresponds to the National ITS Architecture TMS and Roadway Subsystem (RS).
Maintenance and Construction Operations (MCO) -- Monitors and manages roadway
infrastructure construction and maintenance activities. Representing both public agencies and
private contractors that provide these functions, this system manages fleets of maintenance,
construction, or special service vehicles (e.g., snow and ice control equipment). MCO includes
such diverse tasks as vehicle dispatch, routing, and resource management for the vehicle fleets
and associated equipment, participates in incident response, interfaces to weather information
providers (the weather service and surface transportation weather service providers), remotely
monitors and manages ITS capabilities in work zones, gathering, storing, and disseminating work
zone information to other systems. Corresponds to the National ITS Architecture Maintenance
and Construction Management Subsystem (MCMS) and Maintenance and Construction Vehicle
Subsystem (MCVS).
Public Transportation -- Monitors transit vehicle position, disseminates real-time schedules,
provides computer aided dispatch, provides vehicle condition monitoring, includes electronic fare
payment information. Spans distinct central dispatch and garage management systems and
supports the spectrum of fixed route, flexible route, paratransit services, transit rail, and bus rapid
transit (BRT) service. Allows coordinated use of transit vehicles to facilitate response to major
emergencies or evacuations. Corresponds to the National ITS Architecture TRMS and Transit
Vehicle Subsystem (TRVS).
Regional Traveler Information -- Provides information distribution to the public. Corresponds to
the National ITS Architecture Information Service Provider (ISP) subsystem, Personal Information
Access Subsystem (PIAS), and Remote Traveler Support (RTS) subsystem.
Arterial/Traffic Management -- Monitors arterial network traffic, implements range of adaptive
control strategies, manages area wide signal coordination, provides remote monitoring of HRI.
Corresponds to the National ITS Architecture TMS and RS.
The following steps walk through how the user interacts with Turbo during the Interview process:
1. When the user selects an Interview category on the tree, such as Freeway Management (in the
figure below), the buttons View Questions and Answer Questions appear.
Figure 19. Interview Categories Freeway Management Selected

a. View Questions displays the list of Interview questions that will be asked for the selected
category (see the figure below).
Figure 20. View Interview Questions

b. Answer Questions launches the user into that category's questions. The first information
requested is the name and stakeholder for the center which is central to the category. For
example, the figure below shows the initial popup for the Freeway Management category.
Figure 21. Initial Center Identification

(1) If the wrong category has been selected, the user may exit from this first screen (Center
Identification) without creating an element that he does not want. Click on the Cancel
button to return to the Interview Tree window to select another category.
(2) If stakeholder and element names exist, there will be a pulldown list from which to select
a name. Otherwise, the user must create a new element (center) and stakeholder by

typing in the names and optional descriptions. Either select an existing element from the
list, or select the Create Center button to create a new element/center/system. In the
window that appears, type in the new element name and description, and select the
status (Existing or Planned). The (optional) description may include information about
the element, such as what the element is used for.
Figure 22. Center Selection

(3) Either select an existing stakeholder name or stakeholder group from the pulldown list, or
select the Create Stakeholder button to create a new stakeholder to associate with the
element. NOTE that a new stakeholder group may not be created on this screen. In the
window that appears (see the figure below), type in the new stakeholder name and
description. If it is not desired to enter a stakeholder for a center at this time, it may be
done later on the Inventory tab. If no stakeholder is associated with an element, the
interconnections may include more permutations than desired (and the stakeholder name
portion of the box in the Interconnect and Architecture Flow diagrams will be blank).
Figure 23. Create Stakeholder

3. Clicking OK or Cancel from either of the Create screens returns control to the Center
Identification screen. Clicking OK from the Center Identification screen launches the Interview
Dialog category for that element. The Interview Dialog asks the user questions about the
Regional or Project Architecture that is being designed and the new element that is being
created. Each category of questions begins with a question about the center or element, then
continues with questions about equipment, personnel, and data included in that center.

4. After selecting or creating an element/stakeholder name pair in the Freeway Management

category, for instance, the following screen appears asking for the name of the roadside
equipment element. The user has just answered the previous question, Are real-time traffic data
collection technologies used (or planned to be used) on any of your freeways managed by the
Freeway Management Center?, as planned or existing, so this window appears. This type of
window will be displayed periodically during the Interview for certain categories and elements to
determine the names of elements related to the center being defined based on the types of
services or equipment selected by the user.
Figure 24. Center Roadside Equipment Definition

a. There are three options at the bottom of this window. The first allows the user to keep the
name, description, and status generated by the tool for this element.
b. The next option allows the user to change this information. Modify the name, description,
and/or status for the element (the following figure), then click OK to continue with the
Interview, or Cancel to return to the previous window.
Figure 25. Modify Element

c. The third option allows the user to use an existing name for the element. All elements that
exist in the architecture are listed and the user may select one from this screen.
Figure 26. Selecting an Existing Element

d. Certain options ask the user to select from a list of capabilities or technologies to be included
in the architecture. For example, if a user wants all information provided to the public to
come from an element called Public Kiosks, then all the kiosks for all elements that ask for
this information should be named Public Kiosks. This is done by selecting option 3 on the
previous Interview window, then selecting this name from the displayed list.
e. To consolidate kiosks (merge 2 kiosk elements) after the Interview, the process is manual.
On the Inventory tab, manually copy the element to entity (subsystem, terminator) and project
associations from the first kiosk element to the second element. Go to the Services tab and
select each market package for the kiosk element. Make sure that each includes an
association for the element that is to be kept. Manually copy the architecture flow
associations and interconnects from the first element to the second element on the Interfaces
tab (if the architecture has been built via the Build option). Finally, delete the first kiosk
element on the Inventory tab. See Section 3.1.3.4 for more information on manually merging
two similar elements.
5. When all the questions for a category have been answered, the tree of Interview categories is
displayed again.
3.1.4.4 Add/Modify/Delete an Element during the Interview

The following steps walk-through how to affect the inventory of the regional or project architecture during
the interview process, including how to add multiple elements that perform similar services, modify
elements, or delete elements that were added earlier.
1. To add an element:
a. On the Interview tree window, select an Interview category.
b. The buttons Answer Questions and View Questions appear. Select Answer Questions.
c. Answer the questions for adding that element to the architecture for the selected category.
d. Once all questions have been completed, the Interview tree is displayed again, with a + to
the left of the category containing the newly created element (the next figure).

Figure 27. Interview Tree, Category Contains Added Element

2. To modify/delete an existing element:
a. To modify an existing element, return to an Interview category on the Interview Tree window.
b. When returning to an Interview category, the tree will appear with a + in front of a category
that contains elements that the user has defined (i.e. the user has already answered
Interview questions that created these elements). Click on the + to expand the tree.
Figure 28. Interview Tree with Element Selected

c. The list of elements is displayed for this category. When you select an element, three
buttons appear, View Answers, Modify, and Delete.
d. View Answers will take you to a window that displays your initial answers to the questions
for this category that created the selected element. This is a read-only window.

e. The Modify button actually returns you to the Interview questions for this element in order
to change your answers (the previous answers will appear for each question).
f. Clicking the Delete button will cause removal of the element from that category on the
Interview tree. NOTE: The center and other associated elements created by the Interview
WILL NOT be purged (deleted) from the architecture or database while in the Interview
dialog. The user must use the tabbed windows (Inventory tab) to purge an element from the
architecture and from the database. Complete element deletion from the database is
purposely avoided during the Interview since existing elements that are used in other
architectures may be selected during the Interview.
The answers to the questions allow the tool to select the National ITS Architecture subsystems,
terminators, and market packages that best fit the selections.
3.1.4.5 Status of a New Element/Center

There are several things to keep in mind when defining the status of an element.
What is the status of related elements created by Turbo during the Interview (roadside
equipment, kiosks, etc.)?
What is the status of market packages mapped to this element, and the flows that result?
This section explains how status values are assigned to elements, flows, and market packages, created
during the Interview while the user has assigned a status to the center element or answered a question
that includes a list of related technologies or equipment, each of which may include a different status
value.
1. The user will have the option of selecting status (existing, planned, or not planned, or locally
defined status values if they have been added on the Tools => Update Status window) for every
new element defined during the Interview. This allows the user to define elements in any order
and does not require a cycle (specific order) through sections of the Interview.
a. The status of each element must be selected during the Interview process. It may be
changed later on the tabbed windows.
b. For each Interview question, all status types will appear.
c. For the types of capabilities (services or equipment) on a screen associated with the
Interview question, only existing and planned (or local status values) will appear. Not
planned will not be available.
2. After entering a name for the element, a status value is required. After creating the center and
optionally the stakeholder, the Interview Dialog begins asking questions for the selected category
as described in the above sections. In general, the Interview technology questions are used to
select market packages and set market package status. The status choices for each technology
are used to set the status of the associated market package. The default status of all elements
that are created because of technology questions to match the status of the associated center.
The user can then easily change the default status later on the Inventory tab.
3. NOTE that if you select technologies with both existing and planned status, then the market
package status will be set to existing. The technology choices from the Interview questions will
have no effect on the default element status.
4. Interconnect status will be calculated to be equal to the nearest term status value that is assigned
to the architecture flows associated with the interconnect, based on the status value order defined
by the user on the Tools => Update Status window. For example, an interconnect that carries
both Existing and Planned architecture flows will have a calculated status of Existing based on
the initial status values.
5. Initial flow status will be calculated to be equal to the longest term status value that is assigned to
the inventory elements and the market package(s) associated with the architecture flow, based
on the status value order defined by the user. For example, an architecture flow that goes from
Element A (Existing) to Element B (Planned) that is associated with an Existing market package
would have an initial status value of Planned based on the default status values.

3.1.4.6 Connecting Centers Together

It is often required to connect two centers together, such as two TMC's. This may either be done in the
Interview Dialog or on the tabbed windows.
In the Interview Dialog, there is a question asked last in many of the categories. For example, in the
Arterial/Traffic Management category, the question appears as: Does your Arterial Management
Center share (or plan to share) traffic data with another Freeway Management Center or Arterial
Management Center?. If this question is answered with a status other than Not Planned the TMC's
created under these categories appear as interconnected on the Interfaces tab after the Build step. The
reason for this is that the market package ATMS07 Regional Traffic Management is selected by the
Interview process and causes the two TMCs to be connected.
To connect two centers using the tabbed windows: If a new element is created on the Inventory tab, the
Subsystems and Terminators must be selected to match the element that you want to connect to this new
element. The current project must also be selected in the All Projects box (unless this is a Regional
Architecture), as well as a status other than Not Planned at the bottom of the window. On the Services
tab, each market package in the Selected Market Packages box must be selected, and the new element
checked (selected) under the All Related Elements box to match the elements that this new element is
to connect to. In order to do this, the market package selections for the existing elements that will
connect to the new element should be reviewed. Finally, build the architecture via the Build option on
the Interfaces tab, and customize the architecture on the Interfaces tab. The new element and its
associated interconnects and flows should now appear.
Another way to connect two TMC's outside the Interview questionnaire is to go into the Services tab and
select a Market Package like ATMS07 Regional Traffic Management that involves center-to-center
interconnections. If you answered the Interview question above, the two TMC's should be connected and
you will see this here, and when you enter the Build option and Interfaces tab. If you did not answer the
Interview question (maybe you skipped the Interview), you can connect the TMC's here by selecting All
Related Elements and checking the elements you wish to connect to each other for this market package.
3.1.4.7 Using Stakeholders to Minimize Subsystem Permutations

See Section 6.5.2 for detailed information on managing subsystem permutations. A brief description is
given here since stakeholder names may be used (created during the Interview Dialog) to help alleviate
problems with subsystem permutations later.
GUIDELINE: If the same stakeholder is used for all TMCs, then ALL permutations of the TMCs
and their related elements will appear. To prevent all of these unwanted interconnections, use
separate stakeholders for each TMC. This will also minimize the TMS (Traffic Management
Subsystem) to RS (Roadway Subsystem) permutations.
This means that if there are three TMCs represented by a single stakeholder, and each TMC includes an
associated Roadside_Equipment element, for example, then there will be an interconnect between each
TMC and each Roadside_Equipment element. This is most likely NOT what the user intended. If
separate stakeholders are used for each TMC, then the TMCs may be connected to each other (by
answering the last Interview question in the category about sharing traffic data with other centers, or by
using the Regional Traffic Control market package), but only a TMC and its associated
Roadside_Equipment element will be interconnected.
3.1.4.8 Creating Two Centers for Same Facility

The breakdown of tasks and centers in a region may require a user to distinguish between two centers
that operate out of the same facility. This may be done in a variety of ways.
First of all, consider how the element(s) should be displayed on the diagrams. Do you really want a
single center/element, or a separate element for each type of facility? If you think of the facility as single
center this may require multiple entities be associated with it for traffic management, transit management,
and emergency management, for example. Assign these entities to the center either by answering the
appropriate questions while building this single center/element during the Interview dialog, or by creating

a single element on the Inventory tab and assigning it to these National ITS Architecture entities
(subsystems, terminators).
If you want to break out different boxes for each of these National ITS Architecture subsystems on the
diagrams, multiple elements/centers are needed. Each element will be associated with a different
National ITS Architecture entity, so instead of a single element in the diagram, there will be three in this
example (one for traffic management, one for transit management, and a third for emergency
management).
3.1.4.9 ISP Associations in the Interview

Pay close attention to this section so as not to be surprised by the results of the action described. This
will make it easier to apply Turbo Architecture to Regional Traveler Information in your region.
In the Arterial/Traffic Management Interview category, the following question appears: Does your
Arterial or Traffic Management Center provide (or plan to provide) surface street travel times, speeds, and
conditions information to the public?
If this question is answered with a status other than Not Planned and any of the technologies are
selected, such as Kiosks, the Arterial/Traffic Management element will include an association to the
Information Service Provider (ISP) and Traffic Management Subsystem (TMS) entities. This means that
the ISP functions are included in the TMC, which may or may not be what the user intended.
There are two things that the user should be aware of in this situation:
1. The user may believe that kiosk data is being distributed to an external ISP, when the TMC is
actually managing the kiosk data itself. There is no external company handling the kiosk
information.
2. The ISP entity is associated with the SAME architecture element as the TMS entity. It may be
difficult to easily separate the ISP from the TMC in this case.
One additional element is created by the Interview along with the TMC: the TMC Kiosk element
(connected to the RTS, the Remote Traveler Support National ITS Architecture entity). This element is
created if the user selected kiosks as the method of dissemination to the public of travel times, speeds,
and conditions. Other selections will result in the creation of other types of new elements related to the
center. A graphic of this situation is shown below:
ISP
TMS
T M C Elem ent
RT S
T M C Kiosk
Elem ent
Figure 29. TMC to ISP Connection

In addition, if the user then creates another ISP by answering questions in the Regional Traveler
Information Interview category, now there will be two ISP's -- one for the TMC, and one for the traveler

information element. The Regional Traveler Information question that leads to the creation of another
ISP (and perhaps another kiosk element) is: Does your Regional Traveler Information Center use (or
plan to use) different technologies to distribute traveler information to the public?
This results in the following graphic:
ISP ISP
Traveler Element
TMS
TMC Element
RTS
RTS
Traveler Kiosk
Element
TMC Kiosk
Element
Figure 30. TMC to Traveler Element (2 ISP's) Connection

The following situation results:
1. There are now two ISP's, one from creating the TMC element, and the other from creating the
Regional Traveler Information element.
2. After building the architecture, the two ISP's will communicate with each other via the Information
Service Provider to Other ISP National ITS Architecture flows.
The previous discussion assumes that all of these elements have been created in the same architecture.
One other situation that may be required is to create a Freeway and/or Traffic Management Center that
includes functions of a Freeway Management Center, a Traffic Management Center, and a Traveler
Information Center. Besides the above discussion that suggests that ISP functions can be added to an
FMC or a TMC by simply answering the ISP question in each category with a status other than Not
Planned in the FMC or TMC Interview questions, the following method can also be used to create a
multi-functional center:
1. In the Interview, select one of the following categories: Freeway Management, Arterial/Traffic
Management, or Regional Traveler Information.
2. Create a new center and new stakeholder from the Center Identification screen.
3. Answer all the questions in the category that pertain to the center, including the questions that
create the ISP as part of the FMC or TMC centers.
4. Select the other two categories, but instead of creating a new center and stakeholder for each,
use the name of the multiple center from step 2.

This results in the following graphic:
TM C
FM C
IS P
M ulti- TM C
E lem ent
(FM C, TM C,
IS P )
R TS RS
M ulti- TM C M ulti- TM C
K ios k Roa ds ide
E lem ent E lem ent
Figure 31. Multiple FMC, TMC, ISP Center

Suggested Solutions:
1. The ISP association to the TMC element may easily be deselected on the Inventory tab, or the
resulting Information Service Provider to Other ISP flows may be deselected on the Interfaces
tab. This will break the connection between the traveler element's ISP and the TMC element's
ISP (and/or delete the TMC element's ISP), if the user did not intend for a connection to exist.
The procedure for doing this is covered later in this manual.
2. OR, Answer one of the above Interview questions, either the Arterial/Traffic Management or the
Regional Traveler Information question that results in an ISP being created, as Not Planned.
This will create one ISP or the other, but not both.
3. OR, In the Interview, create the TMC element first, and include the ISP (answer the above
question in the Arterial/Traffic Management Interview category with a status other than Not
Planned). When creating the Regional Traveler element, select the same element and
stakeholder names (from the pulldown list) as for the TMC element on the Center Identification
Interview window. This will result in a single element being created the TMC element. This
element will include associations for the TMC (from the Arterial/Traffic Management answers)
and associations for the Regional Traveler element (from the Regional Traveler Information
answers).
3.1.4.10 Interview for CVO

The operation of the Interview for Commercial Vehicle Operations has a few differences to be aware of.
Many states have multiple roadside inspection facilities and in some cases the back-office functionality is
performed by a different state agency than the one that owns the roadside facilities. The Turbo

Architecture Interview questions for CVO are configured such that a single pass through the CVO
questions creates a single CVO Administration Center (CVAS, the Commercial Vehicle Administration
Subsystem in the National ITS Architecture), and a single Roadside Inspection Facility (CVCS, the
Commercial Vehicle Check Subsystem). To answer the concern that these do not necessarily report to
the same stakeholder group, the stakeholder for the Roadside Inspection Facility is left blank during the
interview. Go to the Inventory tab after the Interview is concluded and add the stakeholder name or
group for the Roadside Inspection Facility. At this time, add any additional Roadside Inspection Facility
elements or stakeholders that may be necessary. The Interview will not assign a second stakeholder to
the Roadside Inspection Facility or allow multiple Roadside Inspection Facilities to be created in a single
pass of the Interview. These associations may be changed on the Stakeholders, Inventory, Services, and
Interfaces tabs, and stakeholder groups may also be used.
Another area of CVO to be aware of concerns electronic screening of commercial vehicles. The Interview
assumes that all Commercial Vehicle Administration subsystems communicate with all Commercial
Vehicle Check subsystems. Safety information is not automatically included. These corrections may be
made fairly easily on the Interfaces tab in the Flows view. The CVAS to CVCS connections may be
selective based on stakeholder name or group on the Inventory and Interfaces tabs after the Interview.
3.1.4.11 How Other Capabilities Are Mapped

In many of the Interview categories, a question is included asking the user to choose a capability or
technology from a list of options. The first few choices are the most common technologies or capabilities
likely in current deployments. The last item in the list is often Other. This option is included in case you
have a technology that performs the same function, but is not in the list of common technologies (for
example, you use radar or image based sensors for measuring speed or occupancy). The idea behind
the Interview is that each of your answers creates a mapping from your element to a National ITS
Architecture entity, and the capability or technology creates a mapping to a National ITS Architecture
market package. The National ITS Architecture is largely technology independent, so this mapping is
based upon what the technology does, not the specific choice of technology.
In all cases, the selection of Other creates a mapping to some National ITS Architecture entity
(subsystem or terminator) and an assignment of this mapping to a market package. Given below is the
list of places in the Interview where this Other capability or technology is used, and how the Interview
maps this.
1. Interview Category: Freeway Management
a. Question: Are real-time traffic data collection technologies used (or planned to be used) on
any of your freeways managed by the Freeway Management Center?
If you choose Other, on the Inventory tab the <Users Name> Roadside Equipment
element will be mapped to Roadway Subsystem (RS). On the Services tab, the <Users
Name> Roadside Equipment element will be assigned to the following market package(s):
ATMS01 Network Surveillance
ATMS04 Freeway Control
b. Question: Does your Freeway Management Center currently distribute (or are there plans to
distribute) information to travelers directly using roadside infrastructure on the freeways?
ATMS06 Traffic Information Dissemination
c. Question: Does your Freeway Management Center disseminate (or plan to disseminate)
freeway travel times, speeds, and conditions information to the public?
If you choose Other, on the Inventory tab the User Personal Computing Devices element
will be mapped to Personal Information Access Subsystem (PIAS). On the Services tab, the
User Personal Computing Devices element will be assigned to the following market
package(s):
ATIS01 Broadcast Traveler Information.

2. Interview Category: Public Transportation

a. Question: Does your Public Transportation Center directly or indirectly (i.e., through another
agency/organization) disseminate (or plan to disseminate) info to the public?
package(s):
APTS08 Transit Traveler Information
3. Interview Category: Regional Traveler Information
a. Question: Does your Regional Traveler Information Center use (or plan to use) different
technologies to distribute traveler information to the public?
package(s):
4. Interview Category: Arterial/Traffic Management
a. Question: Are real-time traffic data collection technologies used (or planned to be used) on
any of your arterials managed by the Arterial or Traffic Management Center?
ATMS01 Network Surveillance
ATMS03 Surface Street Control
b. Question: Does your Arterial or Traffic Management Center distribute (or plan to distribute)
information to travelers directly using roadside media infrastructure on the arterials?
ATMS06 Traffic Information Dissemination
c. Question: Does your agency deploy (or plan to deploy) technologies associated with
highway-rail intersections?
ATMS13 Standard Railroad Grade Crossing
ATMS14 Advanced Railroad Grade Crossing
d. Question: Does your Arterial or Traffic Management Center provide (or plan to provide)
surface street travel times, speeds, and conditions information to the public?
package(s):
These Other capabilities and technologies are NOT user defined entities, but simply suggested
mappings to National ITS Architecture entities. If the user does not like the mapping that is created by
the Interview, these mappings may be changed as necessary on the Inventory and Services tabs.
To create an entirely new capability or technology mapping, add user defined entities and flows. See
Section 4.3.1 for information about extending the architecture.

GUIDELINE: The Interview assigns a single Roadside Element or user interface element for each
center defined. If the user would like multiple elements (i.e., they would like to call out cameras
and DMS separately because one is currently deployed and one is part of a planned project), then
following the Interview they should go to the Inventory tab and create additional elements with
appropriate status.
3.1.4.12 Returning to Previous Interview Categories

The user may return to each section of the Interview to review or change his selections by using the tree
of Interview Dialog categories to allow backups that cross these categories. When returning to an
Interview category, the tree will appear with a + in front of a category that contains existing elements.
The user can click the + to expand the tree, then select one of these elements to modify, or create a
new one by selecting the category itself. (See Section 3.1.4.4.)
In order to exit from the Interview for awhile, then return where you left off, do the following:
1. On most Interview screens, there is an option for End Interview.
2. On the End Interview window, select the option Quit Interview for Now. See Section 3.1.4.13.
3. The only available options on the Turbo Architecture main window now are the File, Edit, and
Help pulldown menus on the menubar. You may look at (or create) another architecture, or
save and exit from the current architecture.
4. The other available option appears as a button called Continue Interview on the Start tab.
When this option is selected, the window in the figure below appears, saying that you may
continue the Interview for category <name> and element or center <name>.
Figure 32. Continue Interview What Category

5. The window containing the next Interview question where you left off appears next. You may
either continue with the Interview for this category or select End Interview to pop back into the
Interview Tree window, where a new element may be created. In this way, the user may exit from
an Interview category without having to answer all the questions for that category. This can be
useful when modifying the answers for an element created earlier. If the category contains 15
questions, and the one you may need to modify is question #2, for instance, you do not want to
be forced to go through the rest of the questions for this category.
3.1.4.13 Ending the Interview

GUIDELINE: The user may leave the Interview by selecting End Interview on most screens. To
temporarily exit click the Quit Interview for Now button in the window that pops up. To return
to the Interview where he left off, click the Continue Interview button on the Start tab. Once
he has completed the Interview and left by clicking on the Exit Interview button, all updates must
be made using the tabbed windows. Updates may only be made on tabbed windows by exiting from
the Interview Dialog using the Exit Interview option.

Figure 33. End Interview

Until the Exit Interview choice is selected on the End Interview window, the Interview Tree screen is
accessible. As long as the tree window is available, the user may add, modify, or delete elements using
the Interview. When the Exit Interview button is selected, a verification screen will appear before
completing the Interview. Before exiting the Interview, most of the menu options and tabs are grayed out.
This happens while still in the Interview, and if the user has selected the Quit Interview for Now option.
After exiting the Interview with the Exit Interview option, all options and window tabs are again available.
The following are additional guidelines of how to answer the Interview Dialog in certain situations:
GUIDELINE: If a region includes four Transit Management Centers, and only one does Automatic
Vehicle Location (AVL), for example, then each center must be entered one at a time. Both the
Interview Dialog and the tabbed windows data input control this data entry by handling a single
center/element at a time. In the Interview, each center must be created separately by answering
all the questions for each new center in a category. One center may not be entered, then copied to
create another center (Turbo Architecture does not currently include a feature to copy an
element/center).
GUIDELINE: If a Freeway Management Center performs more than a single function, such as
traffic management, freeway management, and traveler information, then all three Interview
questions about these types of centers in the region must be answered with a status other than
Not Planned. There are Interview questions in the Freeway Management category about
disseminating information to the public (traveler information), and sharing traffic data with other
freeway or arterial/traffic management centers. Other Interview categories include similar
questions.

3.2 Stakeholders Tab

The following figure shows the stakeholder tab for a project architecture.
Figure 34. Stakeholders Tab

The Stakeholders tab above is used to carry out all changes to the architectures stakeholder list. The
Stakeholders tab is used to create, modify, or delete a stakeholder name or group. The stakeholder
name may be a primary or secondary stakeholder that is to be associated with (in charge of) a center or
element on the Inventory tab. Stakeholders are also used on the Ops Concept and Agreements tabs.
Stakeholders can be associated with the Regional architecture or one or more Project architectures.
Shown in the figure above is the list of stakeholders when a project architecture is active. Note the sub-
tabs on the left for Project Stakeholders and All Stakeholders. Clicking on Project Stakeholders would
only list the stakeholders that are in that project. Clicking on All Stakeholders as shown above shows all
of the stakeholders in the file and the check marks on the left identify which are associated with the
current architecture.
The Autoselect button on the Stakeholders tab preselects stakeholders to add to the list by looking
through the inventory elements associated with the current architecture. If any of the stakeholders
associated with those elements are not already part of the list of stakeholders for the current architecture
they will be added to the Stakeholders tab. This feature is useful if you started with the inventory tab to
create or select a list of elements for this architecture and now want to update the list of stakeholders.
A stakeholder group may also be associated with an inventory element. This could be a group of
stakeholders, such as several emergency services agencies, that may be in charge of an emergency
center in the Regional Architecture which is actually a group of emergency centers. On the Stakeholders
tab, individual stakeholders are represented by the single person icon while stakeholder groups are
shown using the multiple person icon. In the figure above, a stakeholder group is highlighted on the left
side of the screen and the Associated Stakeholders that make up that group are listed on the right.

See Section 6.1.3 for suggestions on naming stakeholders in a consistent manner throughout the
architectures in a region.
3.2.1 Add/Modify/Delete a Stakeholder

The following describes the basic features of the Stakeholders tab and the steps to create a new
stakeholder, modify or delete an existing stakeholder, or create/modify/delete a stakeholder group:
1. From the Stakeholders tab, Select a name on the left and modify the stakeholder name or group
attributes on the right.
2. There are four buttons on this window:
a. New Create a new stakeholder name or group. A stakeholder group allows the user to
relate more than one stakeholder to an inventory element.
b. Delete Delete a stakeholder name or group designator from the Turbo Architecture
database. This option will delete all associations between this stakeholder (or group of
stakeholders) and any elements that are assigned to it. If the group designation for a group
of stakeholders is deleted, then its element associations are also deleted. However, the
stakeholder names themselves still exist only the group name is gone. It is recommended
that the elements assigned to this stakeholder name or group should be reassigned to
another stakeholder name or group first. To view the element-stakeholder associations in the
easiest way, use the Sort by: Stakeholder option on the the Inventory tab.
c. Apply Applies the changes made to the selected stakeholder name or group to the
temporary file for this database. To make the changes permanent do a File/Save.
d. Cancel Cancel the action. Close the window by selecting another tab or menubar option.
3. A new stakeholder may be created by selecting the New button at the bottom left of the
screen. The name and optional description may then be entered, and Apply or Cancel may be
selected to keep the new name or to cancel the addition.
4. A new stakeholder group may be created by selecting the New button and clicking the
Stakeholder Group checkbox on the right. This name will be marked with a group icon to
separate it from the others in the list. This will create an overall label for all stakeholders
associated with an inventory element, and can be displayed on certain output reports. Diagrams
will include only the group name. Enter the name and description of the new stakeholder group
on the right-hand side of this screen. Several existing stakeholder names may be selected on the
bottom right-hand side of the screen and associated with this group name. Click Apply to
accept the new group or Cancel to cancel the addition. The user is prevented from creating a
group with no associated stakeholders. A stakeholder group name is marked with an icon in the
list of stakeholders on the left, but will not appear in the list on the right one stakeholder group
may not include another stakeholder group. This list is enabled only when working with a
stakeholder group. The right mouse button works as on other windows it expands the list of
stakeholders, then another right click shrinks the list back to its original size.
5. To delete an existing stakeholder or group, select the name of the stakeholder or group from the
list on the left, then click Delete. A verification screen appears asking if you wish to delete the
stakeholder. Click on Yes or No to delete or cancel the operation.
6. To modify an existing stakeholder name or group, select the name on the left, then enter the new
name or (modify the) description on the right. If this is a stakeholder group, the associated
stakeholders in the group may be changed. Click Apply or Cancel.
When the user edits stakeholders on the Stakeholders tab, modifications, additions, or deletions that are
made on this window, then Applied, are immediately reflected in the stakeholders list box on the
Inventory tab.
The user may also create a new stakeholder on the Inventory tab, give it a name and description, and it
will appear in the list in the Stakeholders field on the Inventory tab. In order for it to appear as a new
name on the Stakeholders tab, click on the Autoselect button and the following screen will appear:

Figure 35. Autoselect Stakeholders Window

The options during Autoselect Stakeholders include adding stakeholders that support the inventory,
removing stakeholders from the list that do not have inventory elements associated with them, and a third
option to preserve the stakeholders to stakeholder group assignments. Turbo then presents a screen to
confirm whether to proceed with making the changes it thinks should be made based on the inventory
mappings and the users options as shown below:
Figure 36. Autoselect Stakeholder Selections Recommendations Window

Once the autoselected stakeholders are added to the Stakeholders tab you may then modify it, make it a
group, or associate it with an existing stakeholder group, on the Stakeholders tab. These changes will be
reflected in the stakeholders list box on the Inventory tab.
3.2.2 Rename a Stakeholder

To rename an existing stakeholder name or group designator:
1. From the Stakeholders tab, select the name of the stakeholder or group from the list on the left-
hand side of the window.
2. Edit the Name field on the right-hand side of the window and hit Apply; all references to the
stakeholder name or group also receive this new name.
Stakeholders are stored in the database tables with reference IDs, so you can change its name and it will
be reflected throughout all architectures in the file as this new name. Stakeholders may be renamed only
on the Stakeholders tab. A new name may not be typed into the field on the Inventory tab.

3.3 Inventory Tab

The Inventory tab provides a window where the user may create a new (or view an existing) element, and
view all attributes associated with it, in the open architecture. A new user defined entity, stakeholder, or
project may be created via the pulldown menus or other tabs, and then associated with the inventory
element on the Inventory tab window. Turbo guides the user in characterizing the element in terms of
National ITS Architecture entities (subsystems, terminators) and user defined entities. Entities,
stakeholders, and projects are listed for each element, and items may be added to or deleted from these
lists via the pulldown menus and other tabs. User inputs of multiple instances of a subsystem or
terminator are supported (e.g., two or more Emergency Management Centers in a regions inventory).
If the user performed market package analysis then removed a subsystem associated with an element on
the Inventory tab, architecture flows for this subsystem association will still appear on the Interfaces tab
after a building the architecture. They must be deselected manually on the Interfaces tab if no longer
needed items are only added, never deleted, by the Build option on the Interfaces tab that builds (or
rebuilds) the architecture (more on this in section 3.7.1).
Inventory elements can be one of 3 types: Normal, Instances, or Shared. See section 3.3.2.1 for the
details but briefly
Normal type elements are those that have existed since Turbo has been around. They represent
an ITS or non-ITS element in the inventory for a regional or project architecture. They are
named, associated with a stakeholder, given a status, described, associated with an entity and,
perhaps, to a project.
Instance type elements are used to represent elements that are more detailed versions of other
elements. For example, a higher-level regional architecture may define roadway elements as
simply State Field Equipment but later you may want to define State Highway CCTV Cameras
and State Highway Ramp Meters with different interfaces and requirements at the project level.
Defining an element as an Instance allows you to retain the higher-level associations and be able
to define different details.
Shared elements allow you to reference the fact that some elements may also be defined in other
architectures, e.g. a statewide architecture. The other architectures are listed on the Start tab.
Communications elements provide a way to create an inventory element that may not provide a
transportation related service but does supply important communications services to the region or
project.
3.3.1 Inventory Tab Views

The Inventory tab allows element creation, modification, or deletion. No other supporting windows or
dialog boxes are required. The display of all fields is at least 60 characters wide (the size of each type of
named item in Turbo is listed in section 6.1 which also includes suggestions on naming conventions in
Turbo; the description field is much larger, of course). The tabbed list boxes on the right on the Inventory
tab allow the user to view all Entities (subsystems and terminators) and All Projects or only those that
are related to the current element.
3.3.1.1 Inventory Tab Regional Architecture View

The following are examples of the Inventory tab for Regional Architectures. There are three sort
options, sort by element, stakeholder, and subsystem/terminator, illustrated in these examples. The
next section (3.3.1.2) will show the main features of the screen for Project Architectures.
The next figure shows the inventory for a Regional Architecture with Sort By: Element selected

Figure 37. Inventory Tab for a Regional Architecture, Sorted by Element

The Sort by Element view is the default view for both Regional and Project architectures and starts with
an alphabetical listing of all of the elements in the inventory. Highlighting an element name on the left
brings up its attributes on the right. These are the attributes of an architecture inventory element:
Name
Type: Normal, Instance, Shared, or Communications
Stakeholder
Status: Existing, Planned, <user defined status values>, Not Planned
Description
Subsystem/Terminator mapping, could include a user-defined entity
Project mapping
The element list for a Regional Architecture includes two tabs: Regional Elements (only the elements
included in the region), and All Elements (all elements in all architectures in the database file, including
extra elements that may be included in a Project Architecture but are not found in the regional). When
the regional architecture has no assigned elements, the Inventory tab automatically displays the All
Elements mode. In addition, the display automatically switches to the All Elements mode when the last
element is removed. When an element is removed from a region, the element list is immediately updated
to remove this element.
The check boxes on the left can be used to quickly add/remove elements to/from the currently selected
architecture. The other option to remove it from the architecture is to change its status to Not Planned.
This will remove it from the list of Regional (or Project) elements but it will still be in the list of All
Elements.
The icon between the check box and the Element name indicates the type of element it is, see previous
discussion on Element Types.
The next figure shows the same inventory with Sort By: Stakeholder selected

Figure 38. Inventory Tab for a Regional Architecture, Sorted by Stakeholder

In this view the elements are grouped by the stakeholders and the folder icon is used to represent each
stakeholder that owns one or more elements. The plus and minus symbols may be selected to expand or
contract the list of inventory elements associated with each stakeholder. Selecting the stakeholder name
also expands or shrinks the list of associated element names, but no attributes are displayed on the right-
hand side of the window unless an element has been selected. The same check boxes and element type
icons used on the Sort By Element view are now next to each element when the list is expanded. In the
Regional Elements sub-tab only the stakeholders that have elements in the current architecture will be
listed. Selecting All Elements will list all of the stakeholders that have any elements anywhere in the
database. Once an element is selected the right side of the screen is populated with the same
information as in the Sort By: Element view.
The next figure shows the same inventory list of all elements for a Regional Architecture with Sort By:
Subsystem/Terminator selected. To recap the terminology defined in section 1.3:
Subsystems are parts of the National ITS Architecture. The 22 subsystems encompass all the
functionality of the ITS User Services. They are grouped into four classes: Centers, Field,
Vehicles, and Travelers. Example subsystems are the Traffic Management Subsystem (TMS),
the Vehicle Subsystem (VS), and the Roadway Subsystem (RS). These correspond to the
physical world: respectively traffic operations centers, automobiles, and roadside signal
controllers. Due to this close correspondence between the physical world and the subsystems,
the subsystem interfaces are prime candidates for standardization.
Terminators are physical entities that define the boundary of an architecture. The National ITS
Architecture terminators represent the people, systems, and general environment that interface to
ITS. The interfaces between terminators and the subsystems and processes within the National
ITS Architecture are defined, but no functional requirements are allocated to terminators.
User Defined entities are defined as Extensions of the National ITS Architecture and are created
by Turbo users to characterize a system or type of equipment that is unique to their situation and

important to the regional or project architecture, in the picture above, Flood Monitoring System
is a User Defined entity.
Communications entities are those that only provide communications services (no transportation
related functionality) to the region or project.
Figure 39. Inventory Tab for a Regional Architecture, Sorted by Subsystem/Terminator

The figure above shows the list of all elements for a Regional Architecture, sorted by
Subsystem/Terminator or entities of the architecture. The folder icon is used to represent each entity that
is represented by or mapped to one or more elements.
The plus and minus symbols may be selected to expand or contract the list of inventory elements
associated with each entity. Selecting the entity name also expands or shrinks the list of associated
element names, but no attributes are displayed on the right-hand side of the window unless an element
has been selected. The same check boxes and element type icons used on the other views are now next
to each element when the list is expanded. In the Regional Elements sub-tab only the entities that are
used in the current architecture will be listed. Selecting All Elements will list all of the entities that have
any elements anywhere in the database. Once an element is selected the right side of the screen is
populated with the same information as in the Sort By: Element view.
3.3.1.2 Inventory Main Tab Project Architecture View

The following are examples of the Inventory tab for Project Architectures. Just like the Regional
Architecture, there are three sort options for the inventory tab: Sort by element, stakeholder, and
subsystem/terminator, illustrated in these examples.
The next figure shows the inventory for a Project Architecture with Sort By: Element selected

Figure 40. Inventory Tab for a Project Architecture, Sorted by Element

As with Regional architectures, the Sort by Element view for project architectures is the default view and
starts with an alphabetical listing of all of the elements in the inventory. Highlighting an element name on
the left brings up its attributes on the right. These are the attributes of a project architecture inventory
element:
Name
Type: Normal, Instance, Shared, or Communications
Stakeholder
Status: Existing, Planned, <user defined status values>, Not Planned
Description
Subsystem/Terminator mapping, could include a user-defined entity
The element list for a Project Architecture includes two tabs: Project Elements (only the elements
included in the current project), and All Elements (all elements in the database file). When the project
has no assigned elements, the Inventory tab automatically displays the All Elements mode. In addition,
the display automatically switches to the All Elements mode when the last project element is deleted.
When an element is removed from a project, the project element list is immediately updated to remove
this element.
On the Project architecture Inventory tab, there is no project mapping area on the right side of the screen.
To see if any other projects include an element, switch to the Regional Architecture and select the
element on the Inventory tab.
The check boxes on the left can be used to quickly add/remove elements to/from the currently selected
project architecture. The other option to remove it from the architecture is to change its status to Not
Planned. This will remove it from the list of Project elements but it will still be in the list of All Elements.
The icon between the check box and the Element name indicates the type of element it is, see previous
discussion on Element Types.

The next figure shows the same inventory with Sort By: Stakeholder selected
Figure 41. Inventory Tab for a Project Architecture, Sorted by Stakeholder

In this view the elements are grouped by the stakeholders and the folder icon is used to represent each
stakeholder that owns one or more elements. The plus and minus symbols may be selected to expand or
contract the list of inventory elements associated with each stakeholder. Selecting the stakeholder name
also expands or shrinks the list of associated element names, but no attributes are displayed on the right-
hand side of the window unless an element has been selected. The same check boxes and element type
icons used on the Sort By Element view are now next to each element when the list is expanded. In the
Project Elements sub-tab only the stakeholders that have elements in the current architecture will be
listed. Selecting All Elements will list all of the stakeholders that have any elements anywhere in the
The next figure shows the same inventory list of elements for a Project Architecture with Sort By:
Subsystem/Terminator selected:

Figure 42. Inventory Tab for a Project Architecture, Sorted by Subsystem/Terminator

In this view the elements are grouped by the entities of the architecture. Entities are subsystems or
terminators from the National ITS Architecture or user-defined entities. The folder icon is used to
represent each entity that is represented by or mapped to one or more elements. The plus and minus
symbols may be selected to expand or contract the list of inventory elements associated with each entity.
Selecting the entity name also expands or shrinks the list of associated element names, but no attributes
are displayed on the right-hand side of the window unless an element has been selected. The same
check boxes and element type icons used on the other views are now next to each element when the list
is expanded. In the Project Elements sub-tab only the entities that are used in the current architecture
will be listed. Selecting All Elements will list all of the entities that have any elements anywhere in the
3.3.2 Inventory Tab Basic Operations

The general approach on the Inventory tab is to select an element on the left and the various attributes of
the element are displayed and editable by the user on the right. (This is a consistent theme throughout
the Graphical User Interface for Turbo Architecture.)
The user will be able to redefine element associations by selecting/deselecting subsystems, terminators,
or projects, or changing the primary stakeholder (or stakeholder group) for the Regional or Project
Architecture.
The list of inventory elements may be sorted by element name, stakeholder, or National ITS Architecture
entity, by selecting a radio button at the bottom left of the screen.
When sorted by stakeholder or entity, the plus (+) and minus (-) symbols may be selected to expand or
contract the list of inventory elements associated with each stakeholder or subsystem/terminator. These
symbols are used on various windows in Turbo. Selecting the stakeholder or entity name also expands
or shrinks the list of associated element names, but no attributes are displayed on the right-hand side of
the window unless an element has been selected.

The right-hand controls allow the user to view or update element attributes: stakeholder / entity / project
assignments, status, and element description for the selected element. In this view, only the
stakeholders, projects, and entities (subsystems, terminators, user defined entities) that have been
selected for the element are displayed. The element name may also be changed, which will change the
name in the table on the left. This does NOT create a new element. To create or delete an element,
select the buttons on the bottom left-hand side of the menu (New, Delete).
When either New or Delete is selected, the left-hand menu is disabled and the Apply and Cancel
options are immediately enabled.
GUIDELINE: Note that the New and Delete buttons on the Inventory tab affect all of the
architectures in the database the Regional Architecture and any Project Architectures. This
means that when working with a Project Architecture and you click DELETE you will be deleting it
completely from the file, including removing it from the Regional Architecture. Take special care
when Deleting elements.
The figure below illustrates the popup window that results when the user might enter an existing element
name for a New element. The user may not keep two identically named elements in the inventory. The
user must click OK on this window, then Cancel on the Inventory tab, or pick a new name for the new
element and click Apply on the Inventory tab.
Figure 43. Pop-up after Attempting to Create Identical Element

The Project Elements tab only displays the elements mapped to this project, not all the elements in the
region. An existing element may be selected from either tab, though, and the attributes may be changed
on the right-hand side of the Inventory window.
3.3.2.1 Inventory Element Type

As discussed earlier in section 3.3 an inventory element can be one of 4 types: Normal, Instance, Shared
(Related), or Communications. Most elements in a regional architecture or project architecture will be the
Normal type since they are completely defined within the current architecture as providing or supporting
a transportation service of some kind. An Instance type element is used to depict the relationship
between a higher-level definition and a more specifically defined element. The Shared or related
elements are those that are defined in another architecture file. Communications elements are those,
such as a regional Hub or HiSpeed Backbone, that provide the communications between elements while
not necessarily providing a specific transportation service. This last type is meant for areas where the
choice of Communications technology is a significant component in the evolution of ITS to the region.
In the figure below, an element is being defined for a project architecture to represent the deployment of
Highway Advisory Radios (HAR) by the county. The architects have decided that HAR is just a more
detailed instance of County Field Equipment that was defined at the Regional Architecture level. In the
figure the element Highway Advisory Radio was selected on the left and on the right-side of the screen
the Instance type has been selected, and the pull-down to choose the parent element has been
accessed.

Figure 44. Inventory Tab Creating an Element Instance

The pull-down list of Parent Elements are from the list of All Elements. Choosing any one of the
elements in the inventory will bring up the following window to ask if you want the instance to
automatically take on the other inventory attributes of the parent: description, stakeholder, status, and
entity mapping.
Figure 45. Inventory Tab Inheriting a Parent Elements Attributes

Once you say Yes, edit the other attributes as needed and click Apply. Now notice how the screen has
changed. On the left side of the screen the element that was just changed has a different icon to show
that this element is now an Instance of some other element in the inventory. The attributes on the right
side now show the Instance button selected and the name of the Parent Element is shown. The
attributes of the instance element can also be changed independent of its parent by editing as you would
edit any other element. For example, you may want to revise the description slightly to show what exactly
is different about this instance from its parent. To synchronize other attributes of the instance element,
e.g. its market package mappings, requirements, etc. go to the Tools menu and use the Synchronize
Elements tool. See section 4.3.2 for more information.

Figure 46. Inventory Tab Instance Element

Similarly, for Shared or Related elements a similar process is followed. In the next figure, an element is
being defined for a project architecture to represent the main Freeway Management Center (FMC). In
this case, the architects have decided that they need to capture the fact that the FMC is also part of the
higher-level statewide architecture. The statewide architecture was defined in a separate database. In
the figure the Alfredo County Freeway Management Center element was selected on the left and on the
right-side of the screen the Shared type has been selected, and the pull-down to choose the related
architecture has been accessed to point it to the Alfredo County architecture.
Figure 47. Inventory Tab Creating a Shared Element

The Architecture names in the pull-down list are from the list of Related Architectures on the Start tab,
recall from section 3.1.2. Once you select an architecture from the pull-down, you can edit the other
attributes as needed and click Apply. The icon between the check-box and the name represents the fact
that this element is shared with another architecture. The attributes on the right side show the Shared
type selected and the name of the Related Architecture. The attributes of this can still be changed by
editing as you would edit any other element. For example, you may want to revise the description slightly
to remind users that it is in another architecture and potentially any different interfaces being developed
for this deployment that may differ from the original/related architecture.

Figure 48. Inventory Tab Communications Element

Creating a Communications element for your regional or project architecture may be important to show
stakeholders how a significant investment in networking or communications technology is going to be
related to the Intelligent Transportation System. In the figure above, a New element is created, given a
name, assigned the communications type, and the user has completed a description, checked-off the
appropriate stakeholder, and assigned it to a project(s). Notice the icon between the check-box and the
name is now changed to represent the fact that this element is a communications type element. The
other thing to note here is that the Subsystems/Terminators have been grayed out as a Communications
type element cannot provide transportation functionality.
GUIDELINE: Inventory elements can either be Normal, Instances, Shared, or Communications.
They cannot be both Shared and Normal or Normal and Instances. The pull-down menu forces you
to choose one type. However, the attributes on the Start tab can be edited as necessary no matter
what type is chosen. Instances may need to be edited to show how they differ from their parents
and Shared elements may need to be edited in coordination with the maintainers of the other
architecture.
3.3.2.2 Inventory Stakeholder Mapping

The stakeholder for an element in the architecture is typically the name of a government agency or
company for a private sector enterprise. This part of the Inventory tab uses a pull-down to select a
Stakeholder name from the list entered on the Stakeholder tab, section 3.2. The top of the list has <New
Stakeholder> which, if selected, opens up a window to enter the name and description of a stakeholder
that may not have been added yet on the Stakeholder tab. This pop-up window is shown below:

Figure 49. Inventory Tab New Stakeholder Window

Once you enter the name and an optional description and click OK the stakeholder will be highlighted
back on the Inventory tab and will take affect when Apply is selected. It will also be added to the list of
stakeholders when you go back to the Stakeholder tab.
There can only be one stakeholder for an element; however, if more than one stakeholder will own or
operate an element use the Stakeholder tab to create a Stakeholder Group consisting of more than one
of the individual stakeholders. Then on the Inventory Tab the group name will be listed on the
stakeholder pull-down list along with the other individual stakeholders.
3.3.2.3 Inventory Status Assignment

The status pull-down allows you to assign whether the element is existing or planned or some other user-
defined status. This can be done at the architecture level, meaning that you could have the same
element be Planned for the Regional Architecture but define it more specifically for a project architecture,
e.g. Planned-Phase1 as shown in the excerpt of the Inventory tab below
Figure 50. Inventory Tab Status Value for Current Project
3.3.2.4 Inventory Description Field

The Description field on the Inventory Tab is a text box to allow you to fill in as much information about
the element as you want as much as you can maintain that is. This is typically 2 to 5 lines describing
what the element is, who is building or operating it, and how it will be used. As the architecture changes
over time the descriptions are helpful to understand what is really in the architecture. They should be
written in such a way to be consistent with other architecture documentation.
3.3.2.5 Inventory Entity Mapping

The Entity Mapping area of the Inventory Tab consists of 2 sub-tabs: Selected Subsystems/Terminators
and All Subsystems/Terminators. When the element is first created the All Subsystems/Terminators will
be shown and you can scroll down the list to select one or more entities that best reflect the functional

definition of the element. For instance a bus dispatch facility would most likely be mapped to Transit
Management Subsystem (TRMS). Any user defined entities that were created using the Tool/Add
Entities feature. Once the selections are made and Apply is selected, Turbo will use the mapping to
entities to choose which market packages are likely, which functional areas/requirements to choose, and
which information flows to build.
3.3.2.6 Inventory Project Architecture Assignment

When the Regional Architecture is selected the right side of the Inventory tab includes an area showing
the projects to which this element has been assigned. Use this area to assign or de-assign the element
to one or more projects without having to select each Project Architecture from the Start tab.
GUIDELINE: If a Project Architecture is open, you can select the current project for any
elements created on the Inventory tab using the check boxes on the left. This assignment is done
for you for elements created in the Interview, and for any new element created on the Inventory
tab when you are in the Current Project. If the project is not selected, then the Build option on
the Interfaces tab may not include this element for this project.
3.3.3 Inventory Creating a New Element
Figure 51. Inventory Tab Creating a New Element

In this view, we have selected the New button on the left-hand side of the Inventory window for a
Regional Architecture. The user now needs to enter the appropriate information on the right-hand side of
the window, starting with the element name, type, description, stakeholder, and status. He then makes
the associations to National ITS Architecture subsystems and terminators, and selects the project(s) that
this new element is to connect to.
If working in a Project Architecture, the current project should be selected in order to connect the new
element to the other elements in this project. To connect this element to more than one project go back
to the Start Tab and select the Regional Architecture then select the appropriate project boxes.

After entering the information on the right-hand side of the Inventory window, select Apply to add this
new element to the database, or Cancel to abort the element creation.
3.3.4 Inventory Tab Editing an Element
Figure 52. Inventory Tab Edit

In this view, the user clicked on All Elements within a project architecture and highlighted one of the
projects elements which then brought up the attributes for that element on the right side of the screen in
edit mode. The user can make changes to the selected elements attributes, Apply the changes already
made, or Cancel the changes. While editing one of the fields transitions between tabbed windows of
Turbo are not allowed. The user can change any or all of the attributes and then select Apply to commit
the changes. Selecting Cancel aborts the changes and returns all attributes to their original state. Once
Apply or Cancel is selected, these buttons are disabled until the user makes another change to the
right-hand side attributes of a selected element. The left-hand list of elements is disabled since the user
must choose to Apply or Cancel the changes before moving on. Once Apply or Cancel is selected,
the list of elements is once again enabled as are the other Turbo tabs.
NOTE that if the user is selecting new entities (subsystems, terminators, user defined entities) for an
element, that the software prevents him from assigning discontinued entities to new flows. User defined
entities may be assigned to new elements and flows.
3.3.5 Inventory Tab Deleting an Element

To delete an existing element from the system inventory, first, select the element on the left-hand side of
the Inventory window. Next, select the Delete button. The element associations are listed on the
right, and a confirmation window pops up asking if this is really what you want to do. Select Yes to
actually delete the element (and all of its associations) from the entire database not just the current
architecture, or No to cancel the delete. Deleting a TMC, for instance, connected to 1000 architecture
flows, could destroy a perfectly good Regional Architecture.
To err on the side of safety, the user should save the current architecture before deleting anything.

3.3.6 Inventory Tab Tips

GUIDELINE: On the Inventory tab, the tool forces the user to map every element to an entity,
either to a National ITS Architecture subsystem or terminator, or to a user defined entity.
GUIDELINE: An element is defined as an element/stakeholder name pair. Any of these pairs not
associated with a National ITS Architecture entity (subsystem, terminator) will be able to be
associated with a user defined entity. The status of a selected element may be represented as
existing or planned (or as a local status value). See Section 6.3 for a discussion of how to define
the status of elements, market packages, flows, etc.
GUIDELINE: In mapping the inventory, if there is a TMC (Traffic Management Center) element
defined in the architecture, there should also be other elements in the inventory to connect this to,
such as an ISP (Information Service Provider) or EMC (Emergency Management Center) elements.
The interconnects between the elements and centers on the Interfaces tab will appear correctly if
there is more than one center.
3.3.6.1 View All Available Projects and Entities
Figure 53. Inventory Tab View All Subsystems

All the tabbed list boxes behave the same way. If you right click on the box, it grows to allow additional
entries to be visible. In the figure above, the All Subsystems/Terminators list box has been right clicked
so that a larger number of entities may be seen at one time. This list is scrollable. The user may then
select or deselect subsystems or terminators. Right clicking on the list box again toggles it back to its
original size. Notice that when this larger version of the subsystem/terminator list box is visible, the
description of the selected entity is available at the bottom of the list box. When the box is returned to its
smaller size, the description is no longer visible.
When a Regional Architecture is the current architecture, the projects sub-tabs can also be expanded by
right-clicking.

3.3.6.2 Subsystem Aggregation and Replication

Recall from your training class on Using the National ITS Architecture (or from the architecture CD-ROM
or web site) that the functionality of subsystems can be aggregated together into one physical center or
the functions of one subsystem can be replicated across different physical centers within a region.
GUIDELINE: The same element name may be mapped to two different entities (subsystems,
terminators, or user defined entities). This is not an error.
Big City TMC
State TMC Info. Service Provider

Traffic Mgmt.
Info. Service Provider
Traffic Mgmt.
Emergency Mgmt.
Small Town TMC
Traffic Mgmt .
Figure 54. Subsystem Aggregation and Replication

Aggregation means you can combine the functions of multiple subsystems into one entity, i.e., one
center may be mapped into multiple parts of the National ITS Architecture. There was a discussion
concerning multiple ISPs in Section 3.1.4.9.
A single computer complex may serve both TMS and EM functions. It still has to do the functions of traffic
management and emergency management, but it does not have to be two different centers, two different
computers, or even two different programs.
Replication simply means that a specific implementation of the National ITS Architecture subsystem may
be repeated in different physical locations. That way, regions can have more than one of any given type
of subsystem. As shown in the figure above, the function of the Traffic Management Subsystem (TMS)
has been mapped to 3 different centers in the region: State, Big City, and Small Town.
The Inventory tab in Turbo Architecture supports this process of deciding how to aggregate and replicate
subsystem functions across a region.

Figure 55. The Subsystem Diagram

The figure above shows the top-level physical architecture diagram of the National ITS Architecture,
showing the 22 subsystems and the various communications methods involved when these subsystems
are connected together.
3.3.6.3 Reassigning Element/Stakeholder Names

The user can reassign the element and stakeholder names on the Inventory tab to different regional
subsystems, terminators, and user defined entities, after initially creating the inventory. ITS projects may
be reassigned to a different element, resulting in different associations with regional subsystems,
terminators, and user defined entities. If the user reassigns portions of the Regional Architecture, the tool
will be able to detect if conflicts and discrepancies are created only if projects have been created or
market package analysis has been done. For example, if an element is assigned to one National ITS
Architecture subsystem, then later reassigned to another subsystem, a conflict may have been created. If
that subsystem is tied to a Project Architecture, the user may generate the Regional to Project
Comparison report that will warn him about conflicts between the Regional Architecture and the Project
Architectures in the database file.
The user can also reassign the element and stakeholder names to different project subsystems,
terminators, and user defined entities, after doing the inventory the first time. The user will be able to
reassign the ITS project services (market packages) to different project elements (and indirectly, to
different subsystems, terminators, and user defined entities). If the user reassigns portions of the Project
Architecture, the tool will be able to detect if conflicts and discrepancies are created only if market
package analysis has been done.
By reassigning elements to different National ITS Architecture entities (subsystems, terminators), the
mapping to certain architecture flows has, in essence, been changed as well (selecting entity associations
determines the mapping of flows between elements). The market packages selected should be reviewed
to ensure that the correct mapping to architecture flows will occur (market package selections also result
in numerous flows being mapped between the elements associated with the market packages). The
mappings that are done as a result of selections on the Inventory tab may be different than the mappings

from the Services tab. After building the architecture via the Build option on the Interfaces tab, the
architecture under development and the Interfaces tab may include additional or unexpected flows if the
user has not reviewed and/or changed his selections on the other windows.
It is the user's responsibility to ensure that any reassigning done in the Regional or Project Architecture
does not conflict with the existing National ITS Architecture subsystems, terminators, and architecture
flows, or with any tailoring that may have already been done. Changing the output of preceding steps
may affect the entire architecture. However, Turbo Architecture preserves previous customization, so this
problem should be minimal.
GUIDELINE: The user is allowed to reassign element and stakeholder names only by returning to
the Inventory step. This may not be done on the Interfaces tab. Only the status of architecture
flows, and whether or not a flow or interconnect is included in the architecture, may be changed
during the customization step.

3.4 Services Tab

The Services tab allows the user to associate inventory elements with National ITS Architecture market
packages that represent the range of transportation services that may be provided by a project or region.
When a market package is selected, all information and attributes pertaining to that market package in
the architecture appears on the right-hand side of the window. This includes the element names, project,
and status of the market package, as well as a user defined comment pertaining to the market package
assignments. Instances of market packages can be created to represent the variations that may exist
across a region or among projects in the way in which a service is implemented.
On the Services screen, stakeholders are not associated directly with a market package. They are
associated indirectly via the associations of each stakeholder to the elements on the Inventory tab.
The Services tab may be used in the following situations:
1. Before or after interface customization.
2. In a Project or Regional Architecture, element to architecture flow associations, plus any
customization that may have been done in the Project Architectures, will be maintained.
3. When creating a Project Architecture when a Regional Architecture exists, a set of entities and
flows (perhaps including customization) has already been selected. The Build step on the
Interfaces tab to build the architecture will actually only add new interconnects and architecture
flows that may result from associations made on the Inventory and Services tabs. All
customization is maintained, and no flows are deleted by the Build step. Flows may be
deselected on the Interfaces tab.
4. When creating a Project Architecture when a Regional Architecture does not exist.
The user will be able to select market packages from several different projects and connect them together
in a Regional Architecture. In this way, portions of various Project Architectures may be merged into the
Regional Architecture. This is described in the following sections.
GUIDELINE: A National ITS Architecture market package may be mapped to several different
elements. This is done on the Services tab. For example, three different elements may be mapped
to the Network Surveillance market package.
3.4.1 Basic Operation

The Services tab works in a similar way to the Inventory tab select a market package on the left, and
the various attributes of the market package are displayed and (most are) editable by the user on the
right. Market packages are grouped by the areas of high-level ITS services as in the National ITS
Architecture (http://www.its.dot.gov/arch/arch.htm).
Table 4. ITS Service (Market Package) Areas
Abbreviation ITS Service Area Name
AD Archived Data
APTS Advanced Public Transportation Systems
ATIS Advanced Traveler Information Systems
ATMS Advanced Traffic Management Systems
AVSS Advanced Vehicle Safety Systems
CVO Commercial Vehicle Operations
EM Emergency Management
MC Maintenance and Construction Management
In the next diagram, two elements and one project are associated with market package ATMS07,
Regional Traffic Management.

Figure 56. Services Tab Regional Market Packages View

In the view above, the left-hand frame only shows market packages that the user has selected for the
current architecture (region or project). The user can also view all market packages by selecting the All
Market Packages tab on the left-hand side of the window. The All Market Packages View allows the
user to easily select additional market packages for the region or project.
The left-hand frame includes check-boxes to include or exclude the market package into the current
architecture. Any changes made on the left hand frame in this way must be applied (click Apply) first
before being able to edit any of their attributes on the right.
The right-hand frame includes the market package id, name, and description for the selected market
package as a convenience to the user. These come directly from the National ITS Architecture and may
not be changed. All other fields in the right-hand frame may be changed by the user.
The right-hand controls allow the user to view or update project assignments, element assignments,
status, and comments (e.g., why the market package is or is not appropriate for the region or project) for
the selected market package.
In the regional view above, the selected elements and selected projects are displayed. The user may
deselect any element or project from the list. Displaying all projects or all related elements may be
desirable in order to see all that are available. For elements, the user can click on Regional Elements to
see the list of all elements included in the regional architecture that are appropriate for this market
package and decide whether to include or exclude them. In addition, there may be some that are in
projects but not in the regional architecture that superset list can accessed using the All Elements tab.
Similarly for projects, click All Projects to see the complete list of projects that could be associated with
this market package.
Once the user makes any change to one of the right-hand side controls, the user is given the Apply and
Cancel options. The user can change any or all of the available attributes and then select Apply to

commit the changes to the Turbo Architecture database file. Selecting Cancel aborts the changes and
returns all attributes to their original state. Once Apply or Cancel are selected, they are disabled until
the user makes another change to the right-hand side associations. The left-hand market package list is
disabled since the user must choose to Apply or Cancel the changes before moving on. Once the
user has selected Apply or Cancel, the list of market packages is again enabled.
The Services tab for a Project Architecture is shown below with ATIS01 Broadcast Traveler Information
selected:
Figure 57. Services Tab Project Market Packages View

The Project Market Packages tab shows which market packages are included in the project and the
checkboxes are there to change the mappings if desired. On the left-hand pane there is an icon a blue
circle with a check mark or an X to signify whether the market package is also part of the regional
architecture.
The right side of the screen is also slightly different for a project architecture. The status is the status of
the market package as it pertains to the current project (not the entire database). The elements area now
has tabs for Selected Elements, Project Elements, and All Elements. Notice in the example above that 3
of the elements selected for this market package are labeled as Not in Project. These are inventory
elements that are in the database and can be used to support this market package but they are not
mapped to this project on the Inventory tab. This is OK think of a project that is adding a few cameras
to a larger system where the centers are already deployed.
On the Project Market Packages window an additional area is included above the comment to indicate
whether or not the highlighted market package is part of the regional architecture and if so what the status
of it is in that other architecture.

3.4.2 Market Package Instances
Figure 58. Services Tab Instance of a Market Package

Turbo Architecture allows one or more instances of a market package to be defined for a Regional or
Project Architecture. A market package instance is based on a National ITS Architecture market
package, but the user can specify a meaningful name, description, and specific inventory element and
project associations for the market package instance. For example, several network surveillance market
package instances could be defined, one for each center or agency that provides network surveillance in
a region (see above figure). This is a common strategy for using market package instances create a
market package instance for every agency implementing a particular element or center associated with
the National ITS Architecture market package.
Each market package instance may include its own status and set of element and project associations.
These attributes are independent between market package instances. Market package instances allow
the services that are planned in the region to be identified with better accuracy and fidelity. Market
package instances also provide Turbo Architecture more information that can be used to improve the
interfaces that are selected on the Interfaces tab. NOTE that the user does not have to create market
package instances. Turbo works as in previous versions if the user never creates a Market Package
instance, as described in the previous section.
GUIDELINE: It is fine to use market package instances for some market packages and the general
National ITS Architecture market package for other market packages in your architecture
definition. For example, you might create instances for market packages that are broadly
implemented in the region (e.g., network surveillance) and use the National ITS Architecture
market package where the service is only implemented by a single center. If you decide to use
market package instances, it is good practice to remove all element and project associations from

the related parent market package. This is so the general relationships defined in the parent
market package dont override or negate the specific relationships that are defined in the instance.
In other areas of Turbo Architecture:
Market package instances are available when enabling the market package based filter (see
Section 4.4.1) which provides filtering based on a specific market package instance in the Turbo
Diagrams, Turbo Reports, Interfaces tab, and Standards tab when selected by the user.
Market package instances may also be viewed on the Market Packages report. See Section
4.4.4.
Turbo uses the specific market package instance information entered by the user to determine
the changes that are made to the Interfaces tab by the build algorithm. See Section 3.7.1.
Market package instances are created and deleted using the New and Delete buttons at the lower left
on the Services tab:
New Create an instance of a market package, and assign it to various elements and projects
in the region. First, select a market package from the list on the left. Then select New. The
default name of the market package instance is the name of the selected market package with
(Instance <number>) added and the description is also copied from the original market package.
Edit the name (change the default name if desired), description, and all other attributes as
described above. When the selections are made, click Apply to accept the additions or
changes, or Cancel to abort the change.
Delete Delete an instance of a market package. Select the instance, click Delete (note that
a National ITS Architecture market package cannot be deleted). A popup window asks for
verification. Click OK. The Delete option is only available if a market package instance is
selected.
GUIDELINE: Use market package instance names that are meaningful to you. In most cases, you
will want to change the default names that are provided by Turbo. Remember while picking names
that the market package instances will be sorted alphabetically by name in reports and on other
tabs.
3.4.3 More on the Projects and Elements Lists

Just as discussed concerning on the Inventory tab (section 3.3.6.1), the lists of Elements and Projects
can be expanded on the Services tab by right-clicking anywhere in the list box. The user may then
select or deselect an element or project. Right clicking again toggles it back to the original size.
Now the user can see many more of the available projects or elements that may be mapped to this
market package. The projects or elements that are checked are those that are selected for the current
market package. The selected projects and elements are always displayed at the top of the list in
alphabetical order followed by the other candidates listed in alphabetical order.
GUIDELINE: If working in a Project Architecture, the current project must be selected for the
elements in the project (on the Inventory tab) AND for the market packages associated with this
projects elements. Otherwise, when the Build step is done, all the required flows and
interconnects will not appear in the architecture, on the Interfaces tab, or on the diagrams. The
same is true if deselecting a project. This must be done on both the Inventory and Services tabs.
A project can apply to more than one market package, or to parts of different market packages.
NOTE that the All Elements tab does NOT actually display all elements in the entire architecture. Only
those elements that may be relevant to the selected market package are listed based on the way it is
defined in the national ITS architecture and the way in which the elements are mapped to the National
ITS Architecture entities. This prevents the user from assigning an element to a market package that has
nothing to do with the intended service.

All projects are always displayed as candidates when a list box is right-clicked. For instance, if you select
All Elements for the EM03 Mayday and Alarms Support market package, only elements that are
associated with the subsystems and terminators in EM03 are displayed. A Loops and Controllers
element in your inventory that is associated with the Roadway Subsystem would not be displayed since
the Roadway Subsystem has no association with Mayday and Alarms Support in the National ITS
Architecture. By implementing the software in this way, the user is never given options that would have
no bearing on the architecture that is generated.
3.4.4 More on Market Package Status

The market package status should be reviewed and set for each market package on the Services tab.
The default status is Not Planned, which indicates to Turbo that the related service will not be
implemented in the region or project. The user should change this status to another value that indicates
the timeframe when the service will be implemented. If a market package is left as Not Planned, the
flows associated with this market package will not be added to the Interfaces tab during the Build. This
may or may not be what the user intended. If it is what was intended, these flows may be included in the
architecture later. If this was unintentional, then changing the status of the market package on the
Services tab and re-building will have no affect on these flows (they have already been added, so will not
be added again). The user must change the flow status for each flow (or click the Include box) on the
Interfaces tab. However, changing the status of the market package AND assigning the market package
to this project on the Services tab, THEN re-building, will change these flows to Planned or Existing or
a local status value (and the Include box will be checked) on the Interfaces tab.
GUIDELINE: If a new market package has been selected for this architecture on the Services
tab, and the user simply begins associating elements and projects to it, the status remains
unchanged. The status of a newly selected market package with no previous associations defaults
to Not Planned. This must be changed to Existing, Planned, or a local status, in order for its
flows to actually be included later on the Interfaces tab as part of this project.
GUIDELINE: Often, a market package will only be partially implemented by a region or project. In
general, select the market package if the majority of it will be implemented and leave it out (status
is not planned) if the majority of it will not be implemented. The inventory elements are associated
with National ITS Architecture subsystems and terminators, which determines many architecture
flow and interconnect selections on the Interfaces tab. Selecting a market package simply adds to
the list of flows available for integration during customization. Review the National ITS
Architecture for the list of flows associated with each market package being considered.
One reason Not Planned is available on the Services tab so that the user may enter a comment about
why a particular market package is not going to be used in the Project or Regional Architecture. On the
Interfaces tab, these flows are listed as not included in the project the Include box is not checked for
these flows. These flows may be included later by checking the Include box, and the flow status may be
changed to Existing or Planned or a local status value.
3.4.5 More on Market Packages and Projects

New elements are created via the Interview Dialog or Inventory tab. The Interview makes all the market
package associations that it can based on the information the user gives when answering the questions.
However, additional architecture flows are sometimes required later to enhance an architecture, or to
make it more complete. These may be added to the architecture by selecting a new market package to
add to the architecture.
If elements have been created on the Inventory tab, then one way to add flows to the architecture is to
add market package associations for these new elements. Another way to add flows to the architecture is
to simply make entity (subsystem and terminator) associations on the Inventory tab for the new elements.
This will pull in architecture flow and interconnect associations from the National ITS Architecture for the
new elements.

To add a new market package to an element, go to the Services tab and select the market package.
Check the status (existing, planned, or a local status), then make the element selections. This will
connect these elements together via the flows that will be added to the architecture by the new market
package selection.
In addition, if working in a Project Architecture, you must check the boxes next to the market package(s)
to add these market packages to the project (later, on the Interfaces tab, the Include box will be checked
for these flows). For a Regional Architecture, check the projects whose elements are to be connected by
the new flows. If your database file only includes a Regional Architecture and no projects, then there
would be no project associations for an element or market package. Select Apply or Cancel.
Finally, to add the new market package and its associated flows to the architecture and to the Interfaces
tab for customization, select the Build option on the Interfaces tab to build the architecture. The Build
option and the Interfaces tab (i.e., build and customization) are covered later in this document.

3.5 Ops Concept Tab

An Operational Concept for a Regional ITS Architecture captures each stakeholders current and future
roles and responsibilities in the implementation, operation, and maintenance of the regions
transportation systems. For ITS Projects, the term Concept of Operations may be more familiar but
contains essentially the same elements roles and responsibilities for each of the stakeholders as they
pertain to the major areas of transportation services to be provided. Roles and responsibilities can be
generally defined at a region wide level or they can be service specific (e.g., SDOT operates and
maintains the freeway system and also provides incident images to support incident management).
Roles and responsibilities can also be defined once for a stakeholder group if the same roles and
responsibilities apply to each stakeholder in a stakeholder group.
There are a number of ways in which Operational Concepts can be developed and documented. See the
Regional ITS Architecture Guidance Document for assistance. Certain steps should be followed while
developing the Operational Concepts and building consensus among stakeholders. (This list came from
the guidance document.)
1. Gather existing documents, such as Incident Management Plans, that identify responsibilities in
multi-agency scenarios.
2. Build on the ITS element inventory by identifying the agency or institution that currently
implements, operates, and maintains each inventory element that will support inter-agency or
public/private interfaces. Augment the stakeholder list where necessary.
3. Develop several relevant operational scenarios that require cooperation among a broad array of
stakeholders. Major incidents and special events are good scenarios that involve a majority of
stakeholders.
4. Convene a meeting or workshop where stakeholders can walk through prepared scenarios and
identify current roles and opportunities for enhanced cooperation and integration in the future.
5. Document each stakeholders current and future responsibilities in each scenario.
6. Collect key findings into a high level Operational Concept.
Turbo Architecture provides a flexible user interface to identify the major ITS Areas that should be
captured, assign stakeholders to each of those areas, and then record the Roles and Responsibilities for
each of the stakeholders.
This feature was developed to primarily support Regional ITS Architecture developers who are carrying
out the requirements of the FHWA Rule 940.9(d)3 and FTA Policy 5.d.3. However, this feature can also
be used in Project Architectures to document portions of a Concept of Operations for the project.
3.5.1 Ops Concept Role and Responsibility Areas

The following figure shows the Ops Concept tab where the user enters their Roles and Responsibility
Areas. Turbo provides the user with an Autoselect tool that will build a default set of areas based on
the market packages that have been selected and then presents the user with the list of stakeholders that
are assigned to the appropriate inventory elements. For a new architecture, the users will need to first
document their stakeholders, develop their inventory of elements (with stakeholders assigned), and select
market packages on the Services tab.
The buttons on the bottom allow the user to create New Role and Responsibility Areas or Delete them.
The more experienced user might opt to create his own areas using the New button, instead of using
the architecture defaults that the Autoselect option will provide.
When the user makes changes to the name, description, selected market packages, or selected
stakeholders; the user will need to hit the Apply button to save the changes or Cancel.

This is an example of a Regional Architecture where a role and responsibility area has been selected.
The left hand side of the screen shows the Role and Responsibility Areas that have been added for this
Regional Architecture.
Figure 59. Ops Concept Tab Role and Responsibility Areas

The user can come to the Ops Concept tab and either develop their own areas or let Turbo create a
default list of areas by clicking on the Autoselect button which will bring up the following window.
Figure 60. Autoselect Role and Responsibilities

Options are shown allowing users to decide how much to add to the Ops Concept window new areas,
new stakeholders within the new areas, and any default roles and responsibilities for those new
stakeholders. Based on the market package selections and changes made on the Services tab, Turbo
will then provide a window like the one shown below:
Figure 61. Autoselect Role and Responsibilities

Turbo will fill in the left side of the screen with a list of Role and Responsibility Areas based on the
market package selections. Each area that Turbo adds roughly corresponds to the major Market
Packages or groups of market packages: Traveler Information, Freeway Management, Transit Services,
etc. NOTE that Turbo automatically builds names for the Role and Responsibility Areas that include both
the generic area name (e.g., Parking Management) and the architecture name (e.g., Marinara County).
This allows the same default areas to be used or tailored for both Regional and Project Architectures.
The user can see only the role and responsibility areas included in the current architecture or see all
areas that have been defined in the file using the Regional Areas for a Regional Architecture, Project
Areas for a Project Architecture, or All Areas tabs.
For each Role and Responsibility Area, whether created from scratch or added by Turbo, the user can
edit the Name and Description fields on the right-hand side of the screen.
The RR icon will be displayed over the icon folder if roles and responsibilities have been written for the
stakeholders within that Role and Responsibility Area.
Below the Description of the Role and Responsibility Area, you can associate one or more market
packages with each area. When Turbo adds the areas it will preselect the market packages appropriate
to that area (e.g., ATIS market packages are in the Traveler Information area).
There are 2 Market Package tabs Selected Market Packages and All Market Packages. If the user
wants to add market packages to a Role and Responsibility Area, perhaps in addition to what Turbos
Autoselect picked up, use the All Stakeholders tab to check off any market package in the architecture.
Below the Market Packages list of the Role and Responsibility Area is where stakeholders are mapped
to each area. A default list of possible stakeholders is based on the market packages assigned, the
market package to inventory element associations, and the inventory element to stakeholder associations
created by the user. The user must make these stakeholder assignments based on the needs of the
region or project.
There are 3 Stakeholder tabs Selected Stakeholders, Related Stakeholders, and All Stakeholders.
All Stakeholders shows all stakeholders that are associated with the architecture, e.g., allowing the user
to select other stakeholders that are not on the recommended list. The user may enter more than one
stakeholder for each Role and Responsibility Area. Selected shows the stakeholders that have been
selected for the area. Related shows only the stakeholders that are associated with the selected market
package(s). There are some cases when the Related Stakeholders may be blank because Turbo
cannot determine what the related stakeholders should be. This happens when: 1) the user has not
associated any market packages with the Role and Responsibility Area, and 2) when the user changes
the selected market packages for the region.
Below the Stakeholders list on the Role and Responsibility Area is the project assignment area.
There are 2 Project tabs: Selected and All Projects. This is only visible when a Regional Architecture is
currently selected.

Once the stakeholders have been selected for the Role and Responsibility Areas, the stakeholders
associated with each area are indented under the name of each R&R area. Expand/collapse the display
so that stakeholders are shown/hidden by double clicking on an area or clicking the + and - symbols.
The RR icons show the stakeholders which have Role and Responsibility descriptions.
3.5.2 Defining Stakeholder Roles and Responsibilities

From the list of Role and Responsibility Areas, when the user selects one of the stakeholders from the
indented list on the left side of the window, the right side of the Ops Concept tab changes to show the
Role and Responsibility descriptions for that stakeholder. The following figure shows what happens when
one of the stakeholders is highlighted on the left side of the Ops Concept tab.
Figure 62. Ops Concept Tab Stakeholder Roles and Responsibilities

With the Stakeholder highlighted on the left, enter one or more Role and Responsibilities (R&Rs) for each
stakeholder in each area. The stakeholder description and list of inventory elements may assist the user
in defining the role and responsibility for a stakeholder.
There are two columns to the right of the Roles and Responsibilities:
In Project/Region: When working with the Regional Architecture, the check indicates whether this
particular R&R is included in any project architecture in the file. In a Project it indicates that the
R&R is included in the Regional Architecture. This gives the user an idea that the R&R is used
somewhere else and that any changes made to this R&R may affect other architectures.
Include: indicates that the R&R is in the current architecture. An easy way to use this tool is to
select the All R&Rs sub-tab and check/uncheck the Include boxes to add or remove R&Rs that
apply to this area in your architecture.

Below the text fields for the Role and Responsibilities is a Status box. Here, you can assign a status for
each of R&R entry.
3.5.3 Roles and Responsibilities for Project Architectures

The OpsConcept tab for Project Architectures work a little differently. If you select a R&R area that is part
of the regional architecture and start to make changes to it either adding/removing stakeholders or
adding/removing/editing the text of a role/responsibility the following screen will come up:
Figure 63. Ops Concept Tab Adding a New Roles and Responsibility Area
Turbo will then create a new R&R Area based on the original that was being edited and the new default
name will be the same as the old area with (Copy 1) appended to the name. This allows a project
architecture to define its unique characteristics without affecting other architectures in the file.
One other item to point out on the OpsConcept tab is the field down in the bottom of the screen, it will
normally say Editable meaning that Roles and Responsibilities can be added, edited, deleted but there if
the user is working in a Project Architecture but hasnt yet included an area in the project they will see
Locked as shown in the figure below for any of the Roles and Responsibilities in that area.
Figure 64. Ops Concept Tab Locked Roles and Responsibilities

To unlock them, simply check the box on the left side of the screen to include that R&R area in the
project, click Apply on the lower left, then the R&Rs in that area can be edited for the project. This
function prevents any edits of regional RRs while a project architecture is selected.
3.5.4 Ops Concept Q&As

Here are some tips on how to understand and use the OpsConcept Tab:
From Figure 62. what does the In Project check box mean?
- In Project is checked when one or more projects include the R&R. In this case, the 2 R&Rs
are included in at least one of the Marinara County projects, so the In Project checkboxes
are checked. The reason for showing the regional architect this information is they may want
to know that the edits that they are making to an R&R will impact one or more projects. A
possible point of confusion is that the In Project checkboxes are checked whenever the
R&R is included in a project, even if that R&R is included in a project as part of an R&R Area
that is different from the R&R Area that is currently being edited. It works this way because
edits to the R&R will change the R&R everywhere that it occurs in all projects and in all
R&R Areas. If you want to make a change to an R&R that does not impact other
areas/projects and In Project is checked, then you should make a copy of the R&R and
make your edits in the copy.
Do the checks in the Include column mean that these R&Rs are included for the Marinara
County regional architecture?
- Yes, almost. The Include checkboxes by each of the two R&Rs mean that these R&Rs are
included for that stakeholder in that area in this case Marinara County Department of
Transportation stakeholder for the Traveler Information for Marinara County R&R Area.
Technically, they are not in the architecture until you actually include the Traveler
Information for Marinara County R&R Area in the architecture by checking the checkbox next
to the Traveler Information for Marinara County R&R Area on the left-hand side. When you
include the R&R Area in the regional architecture, you get all the stakeholders and R&Rs
associated with that Area, including the two in question.
From Figure 64. what does the In Region check box mean?
- The In Region column works just like the In Project column discussed above. The In
Region column is checked whenever an R&R is included in the regional architecture, even if
that R&R is included in the regional architecture as part of another R&R Area. The user cant
edit any R&Rs where In Region is checked to prevent the user from editing regional R&Rs
while a project architecture is selected. The checkboxes provide a visual cue about why the
user is prevented from making any edits to these R&Rs.
In both of the figures why are the same R&Rs checked under Include column?
- Include is checked to include an R&R in an R&R Area. The same R&Rs are included in the
R&R Area, regardless of the architecture that is selected. This is why the R&R Include
column is the same, whether Tomato or Marinara is selected. As stated above, you can
choose to include the R&R Area in one or more architectures using the checkboxes next to
each R&R Area on the left hand side of the tab.

3.6 Requirements Tab

The Requirements tab supports the development of a description of the tasks or activities (the functions)
that are performed by each system in the inventory documenting the share of the work that each
system is required to do to provide the ITS services for a region or project. This capability includes
equipment package selection and tailoring (based on market package choices) and also allows tailoring
of the initial functional requirements provided by Turbo. System functional requirements are one of the
required components of a Regional ITS Architecture as identified in FHWA Rule 940.9(d)5 and FTA
Architecture Policy section 5.d.5.
GUIDELINE: Before writing the first functional requirement, determine the appropriate level of
detail for your region or project. Requirements should follow directly from the ITS service
decisions, operational concept and interface choices. Identify which systems need to have
functional requirements defined for instance, systems on the boundary of ITS (e.g., financial
institutions) do not have to be functionally defined.
The Regional ITS Architecture Guidance Document provides some valuable resources in this area,
including recommendations on how to examine your architecture in order to define the architectural
boundary. In general, a Regional ITS Architecture should include functions for ITS systems and should
not include functions for systems on the boundary. Review how the system was mapped to the National
ITS Architecture. Systems that map only to National ITS Architecture terminators may be on the
boundary; systems that map to National ITS Architecture subsystems may be inside the boundary and
include functional requirements.
When first defining requirements for the architecture, the user will be able to select the portions of the
inventory that will be specified with functional requirements (inventory elements that are at the boundary
of the architecture that will not be implemented with ITS projects do not require functional requirements
specifications). The user should build on the existing ITS service (market package) choices and
operation concepts to define the functional requirements, focusing on those with regional implications.
Stakeholders should participate in the functional requirements development so that the functions are
accurately defined and the stakeholders support the requirements that will be levied on their systems.
In Turbo Architecture, the inventory elements that are at the boundary of the architecture that do not
require functional requirements will be designated in reports and diagrams if desired by the user. For the
portions of the inventory that do require functional requirements, tailoring and equipment package
selection is available (based on entity and market package mappings). At the next level of detail, the user
will be able to specify the functional requirements that should be included for each inventory element and
define new requirements beyond those defined in the National ITS Architecture if necessary. Both high-
level (equipment package information only) and detailed (equipment package information and specific
functional requirements) representations will be available in Turbo reports.
3.6.1 Requirements Tab Element View

The Requirements tab identifies the areas of functionality for each element, as well as, the requirements
pertaining to each functional area. The primary (Elements) view of the Requirements tab is shown in
the following figure.
The left side of the screen shows the list of elements from the inventory. The list includes all elements
when a Regional Architecture is selected or only project elements when a Project Architecture is selected.
On this screen elements can fall into one of 3 categories which are represented with the small icons to
the left of the element names. Icons indicate the degree to which functionality has been specified for the
current architecture.
1. The beige rectangle means that no functions have been assigned to the element.
2. The box with the f means that functional areas (equipment packages) have been selected
for this element.
3. The box with the f and a magnifying glass means that functional requirements have been
defined for this element.

Figure 65. Requirements tab Inventory View

This may vary between Regional and Project Architectures in the same file. For example, functions are
not specified for the Event Parking System in this example of the Tomato Project Architecture, but they
probably would be specified in the Regional Architecture in the same file. The same element could have
three levels of detail in three different architectures in the same file. Highlighting one of the elements will
cause an enlarged status icon to be displayed at the top right side of the screen.
The Specify Functionality checkbox allows the user to make a simple yes/no decision on whether
functionality will be specified, allowing basic scope to be established. Checking this box will cause the
Related Functional Areas to be populated based on the inventory elements mapping to National ITS
Architecture entities.
Functional Areas are the Turbo Architecture equivalent of Equipment Packages in the National ITS
Architecture. Functional Areas, or equipment packages, represent a group of similar processes within an
element that contribute to the delivery of a particular ITS service for instance, in order to implement the
Network Surveillance market package, the Roadway subsystem must include the Roadway Basic
Surveillance functional area. In Turbo, the functional areas represent a set of functional requirements
that should be considered. Think of them as building blocks to help you take into account all of the
functions that an element of your inventory will need to support. The user is presented with the list of
functional areas that can be associated with the inventory element based on entity mappings in the
architecture.
On the screen of Related Functional Areas, only functional areas that can be associated with the
element based on entity mapping are shown. The list of functional areas is sorted alphabetically with the
areas that have already been selected at the top. The check boxes allow the user to include/exclude the
functional areas with the element. The choices only affect the currently selected architecture.

Highlighting one of the functional areas will show a brief description of what is included in that area, the
mapping of that element to the National ITS Architecture, and the type National ITS Architecture, or
User Defined. These fields may not be edited.
The Autoselect button will cause another window to appear that selects the functional areas to be
included for each element based on the market package mapping. The Autoselect window is shown in
the next figure.
Figure 66. Requirements Autoselect Window

Options on the Autoselect window allow the user to either run the Autoselect for the current element or
for the entire architecture. The user can also decide whether to add and/or remove functional areas.
Selecting Continue will bring up the results showing all of the recommended changes to your functional
areas and give the user the chance to decide whether or not Turbo should reflect the changes on the
Requirements tab.
At the bottom of the Functional Areas display the Requirements button will bring up another window
that allows the user to select functional requirements that apply to the selected element or functional
area. On this screen, the user may also assign functional requirements to user defined functional areas.
This button is available once functional areas have been selected for the element.
3.6.2 Requirements Tab Functional Areas View

From within the Requirements tab window the user can select the Functional Areas tab on the left side
of the screen and get an indented list of functional areas (i.e., equipment packages) for each entity. Only
functional areas that make sense based on the inventory to entity mapping in the architecture are shown;
e.g. if an architecture does not have anything mapped to a Commercial Vehicle Administration
Subsystem (CVAS) then functional areas for CVAS will not be shown. As in the Elements view, the list
of functional areas is architecture specific. The list is sorted alphabetically for each subsystem and an
icon with a check mark indicates which have already been selected for the current architecture.
As shown in the figure below, icons show the functional areas that have been included in the architecture.
Clicking once on the entity name (or + sign) will cause the list of functional areas underneath to expand
or collapse. Highlighting one of the functional areas will bring up the description, architecture mapping,
and element mapping on the right side of the screen.
The user can click on New at the bottom of the screen to create a User Defined functional area. Then
the user can write a description and map it to an entity. This entity may be a terminator, thus, the user
may create user defined functional areas and requirements (see next section) for a terminator. The user
can also Delete the user defined functional areas. The user will not be allowed to modify or delete
National ITS Architecture Functional Areas. The Related Elements tab shows only those elements that
can be associated with the selected functional area based on the entity mapping.
The Autoselect button on this Functional Areas view works the same as it does from the Elements
view it brings up a window to direct Turbo to automatically select functional areas based on the market
package mapping, either for the element in question or for the entire architecture.

Figure 67. Requirements tab Functional Areas View

As in the Elements view, the Requirements button will bring up another window that allows the user to
select functional requirements that apply to the selected element and functional area. This button is
available when a checked element is highlighted.
3.6.3 Requirements Tab Functional Requirement Selection

From either the Elements View or the Functional Areas view of the Requirements tab, clicking the
Requirements button on the bottom right hand side will bring up the Functional Requirements
Selection screen shown in the figure. These functional requirements have been developed for each
equipment package in the National ITS Architecture to capture the main functions and interface support
that is defined in the process specifications and data flow definitions of the National ITS Architecture.
These requirements provide a good start for the generation of functional requirements for Regional and
Project ITS Architectures.
The user interface allows the user to create their own requirements or to customize the wording of the
provided requirements to suit their own needs. The user may utilize a single requirement for more than
one element. The user may assign user-defined requirements to National ITS Architecture equipment
packages and user defined equipment packages. An inventory element may be designated to have no
defined functional requirements. For example, functional requirements would typically not be specified for
elements at the boundary of the Regional Architecture (e.g., National Weather Service, Adjacent State's
TMC) per the guidance document process. This type of element can be distinguished in the output
diagrams from elements having defined functional requirements.
NOTE that no functional requirements are automatically selected by Turbo. The user must physically
select each of the functional requirements for each inventory element. Their initial status is not planned,
and are not included in the architecture.

Figure 68. Functional Requirements Selection Window

The top left of the figure shows the element in question. The user can use the pull-down to select from
any element in the architecture that has been assigned functional areas (which causes the table to be
regenerated for that element).
The other pull-down at the top of the screen displays the functional area. The user can use the pull-
down to select from any functional area that has been assigned to the current element. The user can
also select All which causes all functional areas and their requirements to be displayed with an
additional column in the table for the functional area.
The Limit and Sort buttons work just as they do on the Interfaces tab.
The columns in the table are described as follows:
Functional Area: Only visible when the pull-down is set to All. This is a read-only column.
Number: Unique number for each requirement within a functional area. Read only but see the
Tailor button below.
Requirement: Requirement text. Read only but can be tailored (see below).
Status: Pull-down menu similar to the Interfaces tab. Default status is automatically selected
when the user clicks on Include.
In Region/Project: Indicates whether this requirement is being used by any other architectures in
the same file.
Include: Check box to include the requirement, similar to the Interfaces tab.
Tailored: Indicates whether the requirement has been created or modified by the user (i.e., user-
defined). Not directly editable.
The New button at the bottom allows the user to create a custom (user defined) requirement. Also, if
the user selects the Tailor button when a National ITS Architecture requirement is selected, Turbo
makes a copy of the requirement for tailoring, and the Type becomes User Defined. Delete is only
available when a tailored, user-defined, requirement is selected. The user is warned before the
requirement is deleted.
Tailoring or creating a new requirement will bring up another window in which the user can edit the
requirement text.

Figure 69. Functional Requirement Tailoring Window

In the Tailored Functional Requirement window, the requirement number is automatically selected by
Turbo to be the next number in sequence. The user can change this but the number must be unique.
The Functional Area is also preselected by Turbo based on where the user was in the Requirements
window. The user may change this to any other functional area that is associated with the element.
The Requirement text can be anything that the user types. The Regional ITS Architecture Guidance
Document has some tips on how to write good functional requirements for ITS architectures. Feel free to
make use of the Tailoring option to edit the default requirements to make them match your needs take
out the phrases that will not apply to your situation, modify the text so that your stakeholders can better
understand some of the terms.
The Applies To choices allow the user to decide whether this tailored requirement will show up on the
lists for other elements. This allows the user to reuse general requirements without cluttering up lists with
specific requirements that only apply to a single element.
The user hits the Apply or Cancel button when they are done and ready to go back to the
Requirements window.
NOTE that Turbo will display a message to the right of the screen when tailoring the text of a National ITS
Architecture requirement to indicate that it has created a copy of the National ITS Architecture
requirement that you can tailor and include in your architecture.

3.7 Interfaces Tab

The Interfaces tab, shown below, allows the user to define the interfaces between the transportation
system elements in the region or project. The two major controls on this tab are 1) the toolbar, which runs
across the top of the tab and includes tools that can be used to control the interface information that is
displayed on the tab, and 2) the interfaces table that makes up the bulk of the tab and allows the user to
review and edit transportation system interfaces for the region or project. These two basic features, along
with the command buttons at the bottom of the tab, are all the tools that are required to define interfaces
for the region or project. The figure below shows the tab when it is first opened, before any interfaces
have been added for the region or project. The various views and customization options are described
later in this section.
Figure 70. Initial Interfaces Tab Architecture Has Not Yet Been Built
3.7.1 Adding Interfaces (Building the Architecture)

When the user first enters the Interfaces tab, no rows will be displayed in the interfaces table as shown in
the previous figure. A build must be performed to add interfaces to the tab. The Build button (the
leftmost button on the toolbar) initiates the build function.
The user may build the architecture:
As soon as he has completed the Interview, or
Skipped the Interview and completed Inventory and Services selections, or
Opened an existing architecture that has, at a minimum, a set of Inventory elements and
Services.
After the initial Build, if the user has made no changes in the Inventory or Services tabs, zero rows will
be generated by a subsequent Build. The user should view (and perhaps modify) the Inventory and
Services tabs before entering the Interfaces tab to build or customize the architecture. If a user defined
flow is created, and no other changes or additions have been made, the Build step will pick up this flow.
The Architecture that is created by the Build function is a set of source elements, destination elements,
and the architecture flows between them. The tool contains logic to create an initial set of

interconnections and corresponding architecture flows based on the market packages selected on the
Services tab and their assignment to elements from the Inventory. In all cases, the set of
interconnections and architecture flows that this logic selects will need to be reviewed and customized by
the user. The Build logic in Turbo Architecture is fairly inclusive. After all, the idea of creating an
architecture is to identify opportunities for integration. This step is necessary in order to populate the
database with the initial selections prior to actual customization. The step of building an uncustomized
architecture is described in more detail in the following sections.
GUIDELINE: The user should repeat the Build step whenever additions are made to the
inventory or market package selections after initial architecture build. Subsequent architecture
builds will make additional flows available for customization on the Interfaces tab.
GUIDELINE: The Build process will only ADD interconnects and architecture flows to the
architecture. It will NOT REMOVE any interconnects or flows, or change the status of a flow on
the Interfaces tab if an element or one of its services was changed on the Inventory or Services
tab. If a Build is done after some customization has taken place, the customization is not undone
by the new Build. In order to remove undesired interconnects or flows (for example, if a market
package has been removed), the user must uncheck the Include box for each interconnect or flow
on the Interfaces tab.
GUIDELINE: Although it wouldn't hurt to do a separate build for every architecture in a file, it is
not absolutely necessary. For instance, consider the case where there is an existing Regional
Architecture and the user wants to build a Project Architecture that is a subset of the Regional
Architecture. The user could go directly to the Interfaces tab (with the Project Architecture
selected), and begin to manually select the interconnects and flows for the project. (The only
requirement is that the user has identified at least the element(s) and services that are associated
with the project. This information is used to determine the set of flows that might apply to the
project on the Interfaces tab.)
To build the uncustomized architecture:
1. Select the Build button at the top of the Interfaces tab.
2. Click Yes or No to view a report comparing the Inventory and Market Package selections
before building the architecture (this report is also available on the list of standard Turbo reports
on the Output pulldown menu, even before a Build is done). Generating this report may take
several minutes for a large architecture. The Build Settings option also allows you to compare
the number of flows that will be added to the Interfaces tab for selection and/or actually added to
the architecture using the various settings, before committing them to the architecture. See
Section 3.7.1.2 for more on Build Settings.
3. If the report was generated in the preceding step, click Exit, or the x in the upper right-hand
corner of the window, to close it. You will be asked if you would like to continue with the Update
to the Interfaces tab, i.e., the Build. Click Yes or No.
a. When the table is displayed, if nothing new has been added to the architecture in the
Inventory or Services tabs, then the Build operation will not display any new flows to be
added to the architecture. However, if a user defined flow or new element (or new market
package association) has been created, and no other changes or additions have been made,
the Build will pick up this (these) flow(s).
b. The first time that a Build is done the entire architecture will be listed in this table.
c. Making a change and running Build again to build the architecture will only display a shorter
list of flows and interfaces in the table for the additions made to the architecture. NOTE
again that no flows will be deleted from the architecture, and customized flows will not be
touched.

4. The table on the Build Interfaces screen is now populated with source element, architecture
flow, destination element, and status columns. The first column states what the suggested action
will be when the user selects the Yes button to build the architecture. The possible actions are
Add to Architecture or Add to Interfaces Tab. These actions are described later in this section.
5. This preview and accept step on the Build Interfaces screen is important since an
uncustomized architecture generation can add thousands of flows to the user's database with the
push of a button. There are ways to minimize the number of flows that are actually generated by
the Build step (see Section 6). By reviewing this screen, the user may identify major problems
during the preview and abort the uncustomized architecture Build.
6. Click the Yes button to actually add the flows to the Interfaces tab and/or the architecture, or
No to cancel the uncustomized architecture generation. If you are testing how many flows will
be selected with each Build Setting, you may wish to build with each setting, then select No to
not save the changes till you are ready, and have decided which Build Setting will work best.
In the simplest scenario, the user completes the Inventory and Market Package choices and then invokes
the Build for the first time. The tool also supports more complex scenarios in which the Build is
invoked more than once for the same architecture. This is necessary, for instance, when new items are
added to the inventory after an architecture has already been built and customized. The user will have to
invoke the Build step again to make the flows that connect the new Inventory items available on the
Interfaces tab. The Build logic is careful not to impact or modify areas that the user has already
customized when subsequent architecture builds are performed.
3.7.1.1 Initial View of the Build Step
Figure 71. Add Interfaces Window

In the Build option on the Interfaces tab, the user steps through the process of generating, reviewing,
and approving, an uncustomized architecture. You will notice that the Build step is a little different from
the other tabs and windows since it does not allow the user to do any data entry.
When the Build option is first selected, the tab is blank and the user is presented with the Add Interfaces
window and a couple of options. First, he may select a setting level, discussed in the next section. Next,
the Turbo architect should select the option to review the reconciliation report that crosschecks the
Inventory and Market Package selections (the title of the report is Inventory to Market Package
Comparison). This explicit recommendation is made because it is easier to fix Inventory and Market
Package selection problems before an uncustomized architecture is generated. If the user selects Yes,
the reconciliation report is displayed. If he selects No, the report is not displayed and the architecture
may be built next.
3.7.1.2 Build Settings

The Build Settings window is displayed when the user chooses the Settings button on the Add
Interfaces window. As shown in the next figure it contains two slider bars to select from different settings
that govern how many interfaces should be included on the Interfaces tab and how many Turbo should go
ahead and select as being included in the current architecture. Those settings will be described next.
There is also an Override option that will also be explained. Together these choices control the number

of flows selected by the Build algorithm, thus allowing the user to control the type of Build that is
performed.
Figure 72. Build Settings Window

The settings for the first slider control how many flows to include on the Interfaces tab and, going from left
to right, include the following:
Only Selected Flows, where flows will only show up on the tab if they have been selected to be
included (given a status of something other than Not Planned) in the current architecture. All
unselected flows will be removed from the display. This is useful to present as clean an
Interfaces tab as possible just show me what I have. On large regional architectures this may
help sort out exactly what you are starting with and can then edit out what you dont need.
Related Flows, where all the flows that are somehow associated with or related to the selected
market packages will be shown on the interfaces tab. This may result in some extra Not Planned
flows being displayed which presents some additional options to consider. The clutter is
minimized in that these extra flows are at least traceable to a service you have already selected.
All Possible Flows, where the most architecture flows will be will be added to the tab this goes
to the National ITS Architecture and pulls out any and all flows that go to or from your elements
based on how they are mapped to National ITS Architecture entities. This may be useful for
smaller architectures where you arent exactly sure what services you need and just what to see
all the possibilities. This is not recommended for a large inventory as it could reach into the tens
of thousands of possible flows.
The settings selected include the following:
Conservative, where fewer architecture flows will be selected for the architecture and the
Interfaces tab. This setting adds flows to the list on the Interfaces tab if they are included in a
market package in the current architecture but they are not actually included in the architecture,
i.e. the status is not planned. If this setting is selected, the Override Previous Builds option is
unavailable.

Moderate, where a medium number of architecture flows will be selected for the architecture and
the Interfaces tab. This selects a flow if BOTH the source and destination elements are mapped
to a market package that includes the flow. The differences between Moderate and
Aggressive are not always easy to see, depending on how extensive the market package to
element mapping is.
Aggressive, where the most architecture flows will be selected for the architecture and the
Interfaces tab. This selects a flow if EITHER the source OR destination element is mapped to a
market package that includes the flow.
Do a Conservative Build after an Import, where the project has been customized and flows deleted.
The user would not want to see these deleted flows re-introduced after Import, which is possible with an
Aggressive Build on the imported architecture. The Conservative or Moderate Build can be used
after the initial Build, when an Aggressive Build would add too many flows to the semi-customized
architecture.
The Turbo Architecture build algorithm at the moderate or aggressive build setting automatically includes
architecture flows in the current architecture only if the flows are included in a selected market package
and the flows connect elements that are included in the same market package instance.
The Override Previous Builds check box is only for regional architectures it will be grayed-out for
project architectures. If this option is turned off, then an Aggressive or Moderate build performed after a
Conservative build will ONLY add in the flows associated with the new element or market package and
not add in all flows ignored by the initial Conservative build. The off setting will also not change flows
already on the Interfaces tab. This is the DEFAULT. If the Override option is turned on, then ALL
corresponding flows for all elements and market packages will be added by a Moderate or Aggressive
build. In addition, the on setting may change flows already on the Interfaces tab from not planned to
another status value). NOTE that the Override option WILL NOT override the settings of any flows that
have been manually tailored.
For example, if you do a Conservative build, add no new elements or market package associations, then
perform an:
Aggressive build without Override Nothing new will be selected by default.
Aggressive build with Override New flows will be selected for inclusion as if the Conservative
build was never performed. New flows added for an unselected interconnect will be Not
Planned.
NOTE that user tailoring is NEVER overridden by the Build, regardless of the option selected.
Subsequent more aggressive builds will only affect changes on the Interfaces tab that are associated with
new inventory, market package choices, and user defined extensions. Every flow associated with an
interconnect is marked by the software when the interconnect is deselected. This prevents interconnects
from being added back in when a more Aggressive build is done after interconnects are tailored.
The Build Settings window also includes OK, Cancel, and Apply options. While changes are
pending on the Build Settings tab, the Yes and No commands on the Add Interfaces window are
disabled so that builds cannot be initiated until a settings change is applied or canceled. The header on
the preview window will indicate the Build Setting as a reminder, e.g. Chicago Architecture Aggressive
Build Results - 132 Flows Added.
To help the user be consistent with their Build strategy, the last build setting in the Turbo Database will
be saved and will be used the next time the user does a Build. NOTE that this approach means that the
default build strategy can change when the user opens a different Turbo database. The settings should
always be reviewed before starting a Build.

3.7.1.3 Reconciliation (Inventory to Market Package Comparison) Report

The figure below shows the report that is previewed when the user has selected Yes to view the report
from the Add Interfaces window.
Figure 73. Inventory to Market Package Comparison Report

This Inventory to Market Package Comparison reviews the market packages that have been selected as
part of the current architecture. It first lists any inventory elements that are part of the inventory but do not
participate, in some way with market packages that were selected. Then for each market package, the
report shows the elements mapped to it from the inventory as well as those that could be mapped to this
market package but werent selected. This report can be used to check the work that had been done
earlier on the Inventory and Services tab. If not satisfied with the findings, the user may close the report
and re-enter the Inventory or Services tabs to modify his selections. Once satisfied the user can close
the report and continue with the Build process.
3.7.1.4 Complete the Build Process

After viewing the reconciliation report and selecting Yes to build the architecture Turbo initiates the Add
Interfaces process, i.e., the Build step, which can take a few seconds or several minutes depending on
the size of the architecture and the speed of the computer. Nothing for the user to do here but wait.
Once the Recommended Interface Updates build screen is populated with flows (see figure below), the
uncustomized architecture Build preview step is complete. All changes that will be made to the
Interfaces tab or actually added to the architecture are presented to the operator. The user may want to
cancel out of the Build process by selecting No if he sees something he does not like (e.g., Turbo
wants to add in 10,000 new flows because too many market packages and/or element to subsystem
associations have been identified). Section 6.10 includes some suggestions for working with large
architectures that try to minimize the number of connections and flows in the architecture.

On this final Build window, the flows are presented in two groups:
1. Those flows that Turbo Architecture thinks are the best fit for the architecture. These flows will be
included in the uncustomized architecture if the user selects Yes to complete the Build step.
The status of these flows will be either existing or planned or a local status value.
2. Other valid architecture flows that the user may also want to consider. The second category of
flows will be made available on the Interfaces tab, but will not be included in the architecture that
is built by the Build step by default. These flows initially appear as Not Planned on the
Interfaces tab. The status of these flows may be changed from Not Planned to another status
value on the Interfaces tab, and the Include box may be checked (to include a flow in the current
Project or Regional Architecture) and added to the architecture there.
If the user selects Yes, the flows are loaded into the Interfaces tab and a message is displayed directing
the user to the Interfaces tab to do architecture tailoring. If the user selects No, the Add Interfaces
window exits and the Interfaces tab is again visible. No new flows or interconnects have been added to
the architecture or to the Interfaces tab.
Figure 74. Recommended Interface Updates
3.7.2 Customizing the Interfaces

You have completed the Build process and built the architecture. Are you done? Well, not really.
Following the Build, you need to decide which interconnects and architecture flows to include in your
architecture, and which to reject. This section describes the process of customizing the interfaces listed
on the Interfaces tab, including the various views, filters, settings, and customization options.

The Interfaces tab allows the user to make architecture flow by architecture flow (or interconnect by
interconnect) changes to Regional and Project Architectures. At this point, after generating an element
inventory and making market package selections, the user should obtain stakeholder input into the
process and determine the interconnects and flows that should be selected or deselected.
3.7.2.1 Introduction to Customizing Your Architecture

Once the uncustomized architecture has been created, the next step in the creation of an architecture is
to customize it. By this we mean adding or deleting source element / architecture flow / destination
element triplets from the architecture. This step is done on the Interfaces tab. This tab allows you to
view your architecture either as a set of interconnects (a list of the elements that interface with each
other) or as a set of architecture flows (exactly what information is exchanged between two elements).
For a large architecture it is usually easier to begin your customization by looking at the interconnects and
deciding which ones belong and which do not. For this reason, the default view shown when you first
enter the Interfaces tab for an architecture is the Interconnect, or Connect, view. Within the same Turbo
session, however, if the view is changed to the Flows view, then this will be the default view if another
architecture or file is opened. Customization may involve changes beyond the Interfaces tab. It may also
mean adding, modifying, or deleting elements or architecture flow definitions themselves. For example,
you may want to add an architecture flow (which is not currently defined) between element A and element
B. This is done via the Tools / Add Flows pulldown on the menubar (see Section 4.3.1.2).
When defining a Project Architecture from an existing Regional Architecture, regional flows may be
selected or deselected for the project (see Section 5.2.2). A comment can be entered on the Interfaces
tab using the Info button to possibly describe the reason for selecting or deselecting certain flows.
Input to customization includes the initial element and stakeholder inventory in terms of National ITS
Architecture entities (subsystems and terminators) and user defined entities, as well as, National ITS
Architecture market packages related to the initial projects and services. From the Build step, the
source element, architecture flow, and destination element are included on the Interfaces tab as
described below. The tool indirectly allows the user to modify the subsystems, terminators, and
architecture flows for the region or project based on the initial subsystem, terminator, and market package
characterizations by selecting or deselecting a flow.
The Interfaces tab includes two views: Connect (showing the interconnections between elements) and
architecture Flows. The user may move from interconnect to flow or from flow to interconnect views
during the customization process.
GUIDELINE: Once the user enters the Interfaces tab and begins to customize the architecture,
he may return to the Inventory or Services tabs to change element/stakeholder mappings and
market package selections. Note again that a new Build will only add new interconnects and flows
from the selections made on these tabs.
3.7.2.2 Interfaces Tab Display Options

On the Interfaces tab window the toolbar at the top allows the operator to control what is displayed in the
main table on the window. The user selects and deselects flows in the table using check boxes at the far
right or by using a pulldown menu that allows changing the status value of each row.

Figure 75. Interfaces Tab Project Architecture with Group Selected

Working from left to right across the toolbar, the following options are available to the user:
1. Element Selection box The user can either view all elements or view the interconnects and
flows for a single element using this selection box.
2. Build This was discussed in the previous section and remains available any time the user
decides to let Turbo analyze the Inventory and Services of the architecture to potentially add
more flows to the architecture.
3. Connect and Flows buttons These buttons allow the user to switch between the Connect
(interconnects) and Flows views. In interconnect view, no architecture flow information is
provided and each check box in the table adds or deletes an entire interconnect (including ALL its
flows) for the current architecture. The user cannot switch between these two views when
changes are pending (changes have been made to the table, but Apply or Cancel have not
been selected). Pending changes must either be applied or canceled. Then, all options and rows
are again available.
4. Group This is a toggle that lets the user view the displayed list with only one element name
listed when an element is used multiple times and sorted alphabetically (see the figure below).
The Group button combines adjacent cells that have the same values in the source and
destination columns which simplifies the display, but makes no other changes (e.g., the number
of rows in the table stays the same.) Notice in the following Flows view of a Project
Architecture, there is an additional column for In Region, meaning that this element has been
selected to be in the Regional Architecture (the project has been Merged into the Regional
Architecture via the Project to Region option on the Start tab, then the architecture was Built).
5. Sort This option allows the user to select the order in which the columns will be sorted. It may
be used to see all instances of a flow, or to list common or similar architecture flows. When the
user has selected a single element from the pulldown list at the top left of the window, there is an
additional sort option for Interconnect sort. This option will sort all flows for an individual
interconnect. For example, flows for Element A to Element B will immediately be followed by
flows for Element B to Element A. In addition, the user may use column headings to control
sorting and sort based on any of the columns displayed. After the user defined sort is applied,

the remaining columns are sorted in the order they are displayed, from left to right. The following
view is for the customize Flows view of a Project Architecture. For the Connect view, the
options to sort by flows are not available.
Figure 76. Interfaces Tab Sort Option

6. Filter This option allows the user to display the list of interconnects or architecture flows using
the same filters selected on the Output => Filtering menubar pulldown menu. This option
enables the output filters so that flows that would be filtered from the diagrams and reports are
filtered in this table. This allows the user to ignore human interface and environmental interfaces,
for instance. See Section 4.4.1 for a discussion of filtering capabilities. Right-click the Filter
option to display the filter settings window.
7. Elements This option limits the displayed list of architecture flows to only the elements listed on
the Element Selection window. This includes the Project Elements and Show All options on
that window. See Section 4.4.2 for a discussion of the element selection option. Right-click the
Elements option to display the element selection window.
8. Limit This option limits the displayed list of architecture flows to only the interconnections or
flows that are present in the current architecture, i.e., the rows selected in the Include column.
After initial customization, the user can use this mode to avoid being bothered by other valid
flows that do not apply to the architecture.
9. New This option lists all new interconnects and architecture flows that have been added to the
architecture by the last Build or by the conversion process from a previous version of Turbo.
The information on this screen may change based on new information. If a new Build has been
done that added a few flows, then these flows will appear if New is selected replacing the data
from a previous Build or from converting this architecture. Previous data will then be available
only on the main lists of interconnections and flows (with the New option turned off).
10. Info This option, available in the Flows view only, displays a window that gives the user more
information about the selected architecture flow. The only editable field is the Comment field.
The flow name, description, associated projects, and whether this flow is in the National ITS
Architecture, is a user defined entity, or is a discontinued flow (for the current version) are also
displayed on this window. The user may add a comment about this flow, why it is planned or not,
the flow's characteristics, or other pertinent information. A project is listed in the Associated
Projects field if the flow is found on the Interfaces tab for a project.

Figure 77. Interfaces Tab Supplemental Flow Information

11. Present This toggle option enables the Interfaces tab to be more visible to group presentations,
such as during a training class, stakeholder presentation, or workshop. The Present option
increases the visible font size by 50%.
The following options appear as additional buttons across the bottom of the Interfaces window. They
may be used to expedite architecture customization by allowing the user to make a global change to all
the Include boxes that are on the Interfaces tab. The user may select or deselect all flows before
customizing the architecture. This is useful, for instance, if the market package selections have resulted
in far too many flows that need to be reviewed. All flows may be turned off and the few required may be
reselected.
1. Select All This option will select all flows on the Interfaces tab, turn on the Include field (the
flow is included in the architecture), and change the Status field to the default or to the last
status selected for that flow (existing, planned, or a local status value). NOTE that the In
Region field remains unchanged. Click Apply to save the changes to the architecture, or
Cancel to abort the changes.
2. Clear All This option is the opposite of Select All, and will deselect all flows on the Interfaces
tab, turn off the Include field (the flow is not included in the architecture), and change the
Status field to not planned. NOTE that the In Region field remains unchanged. Click Apply
to save the changes to the architecture, or Cancel to abort the changes.
NOTE that the Status and Include fields are refreshed while still on the screen before applying the
Select All or Clear All option.
3.7.2.3 Customizing Interconnects

The default Connect view (showing the interconnections between elements) includes all
interconnections (source and destination elements) in the architecture that is currently being customized.
The interconnections were generated during the Build step. The Connect view illustrates the elements
in a directionless manner, unlike the Flows view, where direction is shown.
The Connect view omits the architecture flow column with a corresponding reduction in the number of
rows displayed. Both views are closely related. Making a change to included flows in the Flows view
may change the corresponding interconnect in the Connect view, if no other flows are involved in the
interconnection between the two elements. The reverse is also true deselecting an interconnect is
reflected in the Flows view. For instance, if an interconnect includes many flows, as most do, and the
user needs to eliminate the interconnection between two elements (for example, he is deleting from the
architecture an external ISP that is connected to a TMC), all flows between them must be deselected
(uncheck the Include box) in the Flows view. The Connect view will reflect these changes, and the

interconnect between these two elements is automatically deselected. OR, he may simply deselect the
interconnect in the Connect view and all flows between these two elements are automatically
deselected in the Flows view.
The view displayed below illustrates the interconnections for all elements in a Regional Architecture.
Figure 78. Interfaces tab Interconnects for Regional Architecture

The following view displays the interconnections in a Project Architecture for one element to the rest of
the architecture. On the top left-hand side of the Connect view, the user selects All to view
interconnections for all elements in the architecture, or a single element name from the list of elements
included in the current architecture. The list of interconnects is displayed as a table with the following
headings (the headings are different from the Flows View headings):
Element first element.
Element element interconnected to first element.
Communications what, if any, communications-type element is being assigned to this
interconnect. See Section 3.3.2.1 to recall how they are created on the Inventory Tab.
In Region whether or not the interconnect is included in the Regional Architecture (this
appears only when viewing the Interfaces tab for a Project Architecture).
Include whether or not the interconnect is included in the current architecture.

Figure 79. Project Architecture Interconnects to One Element

For the two element columns, it is implied that the connection is bi-directional. Only one pair of
elements with the direction implied as bi-directional will be shown.
If a few architecture flows have been selected by previous steps (e.g., inventory and market package
selections) for the interconnections on an interface, the tool will display only the interconnections that
include these flows as selected for this interface. The user may select additional interconnects from the
list that appear initially with the Include box unchecked. The safest way to include these
interconnections is to go to the Flows view, select the additional flows you would like to include in the
project as well as their deployment status, then return to the Connect view. These new interconnects
should now be included.
If no flows were selected for an interface by the user's inventory and market package selections (all flows
are listed as not planned, which could happen if a Conservative Build was done, the tool displays all
architecture flows as deselected and the user must select the ones needed for this interface on the
Flows view. On the Connect view, all interconnects are initially listed, but not included. Go to the
Flows view as above and select the flows between elements that should be interconnected. Then return
to the Connect view. OR, select the interconnects on the Connect view (in the Flows view all flows
between these elements will be automatically selected).
Only the architecture flows from market packages that the user selected will be indicated by the tool for
the interconnections of this interface. The user may select additional flows and interconnects from the
displayed lists.
When the user selects or deselects an interconnect and then hits Apply, the architecture is updated in
the following ways:
1. Regional Architecture:
a. Selecting a new interconnect that was not part of the architecture: All valid flows associated
with that interconnect (in both directions) are selected as part of the architecture.
b. Deselecting an interconnect: All flows associated with that interconnect are deselected.
c. Deselecting then selecting an interconnect before clicking Apply results in no change to the
underlying database. This preserves any flow level tailoring that has already been done.

2. Project Architecture:
a. Selecting a new interconnect: If there are architecture flows on the interconnect that are part
of the Regional Architecture, then only those flows are selected as part of the project. If there
are not any Regional Architecture flows on the interconnect, all valid flows on the
interconnect are selected as part of the project.
b. Deselecting an interconnect: All associated architecture flows are deleted from the project
(analogous to Regional Architecture operation above).
c. Deselecting then selecting an interconnect before clicking Apply results in no change to the
underlying database (as described above).
What if the user only wants part of an interconnect? Sometimes in a regional or project architecture, you
only want a portion of an interconnect to be selected, i.e., only certain flows from an interconnect are
required in this architecture. Review the National ITS Architecture CD-ROM for information on the flows
associated with an interconnect (subsystem to subsystem or terminator). This scenario may also be
applied when selecting a Market Package which typically does not include every flow on an interface.
CAUTION: if the Interfaces tab is filtered by market package (or another filter), then you are only seeing
the flows on an interface associated with this market package, not every possible flow on that interface.
You may need to turn off the filters and verify that all of the flows on a particular interconnect are really
what you want.
3.7.2.4 Customizing Flows

The Flows view for the Interfaces tab displays a table that illustrates the Regional and Project
Architecture associations. As in the Connect (interconnects) view, in the box on the upper left-hand side
of the screen a pulldown list of all the elements currently defined in the architecture is displayed. This is
either the list of the project elements for the Project Architecture that is open, or all elements in the
Regional Architecture. The user selects one element or the ALL option. A table is then created with all
the architecture flows into (or out of) the element selected (or with all flows listed).
The Source Element, Architecture Flow, Destination Element, In Region (for Project Architecture only),
Status, and Include, will appear in the table. NOTE that some flows may appear with an asterisk after the
flow name. This indicates that these are discontinued flows from the conversion (see Section 4.1.3).
The default sort for these columns is set based on the following order: Include, In Region, Source
Element, Destination Element, Architecture Flow, and lastly, Status. The sort order may be changed by
selecting the Sort button at the top of the window.
When the user is looking at a Regional Architecture, Included flows are either Existing, Planned, or a
local status value. Conversely, Not Included flows are Not Planned. When a user is looking at a
Project Architecture, Included flows must also be either Existing, Planned, or a local status value.
However, Not Included flows can be any state since the flows may be part of another architecture in the
file. If the Include box is not checked, the status of this flow defaults to Not Planned.
The flow status on the Interfaces tab in the Regional or Project Architecture is set equal to the flow status
that is displayed in the Build step (i.e., the Build option on the Interfaces tab). There is one
EXCEPTION to this. The flow status in the architecture will not be changed if the flow already exists on
the Interfaces tab, and the software determines that some customization work has already been done on
the flow. This exception prevents user customizations from being lost during subsequent builds.
When the Include box is checked, the status is changed from Not Planned to either:
The default status if the user has never manually changed the status for the current flow, or
The last status selected by the user in cases where the user chose to override the default
status before the flow was deselected.
In either case, the user may click on the status field and change it. If you change it to Not Planned, the
Include box is automatically deselected. The last actual deployment status is stored in the database for
all flows. When a flow is selected, this last actual status is displayed on the Interfaces tab. This means
that the user can accidentally toggle the Include box on a flow without inadvertently changing the
deployment status.

The next figure illustrates the architecture flows for all elements in a Regional Architecture.
Figure 80. Architecture Flows for all Elements in a Regional Architecture

The next figure displays the architecture flows in a Project Architecture for one element:
Figure 81. Architecture Flows for One Element in a Project Architecture

NOTE that the columns on the Interfaces tab may be moved or the column width stretched. For instance,
the user may wish to move the Include column next to the Flow Name column when trying to decide
whether or not to deselect a flow.

NOTE that for a Project Architecture, additional flows that are not part of the project will be included on
the Flows view of the Interfaces tab. These additional valid flows are included so that the user can
select additional flows for the project. This may include flows associated with other projects (or the
Regional Architecture) to present all valid flows to the user, giving him the broadest set of choices. The
Limit filter is also available to allow the user to selectively limit the Interfaces tab to the flows that are
selected or directly applicable to the project.
GUIDELINE: A project may apply to more than one market package or to parts of different
market packages. This is accomplished in the customize Flows view of the Interfaces tab by
selecting or deselecting architecture flows connected to this project and element.

3.8 Standards Tab

ITS Standards address interfaces between ITS elements. When stakeholders have reached consensus
on the interfaces (architecture flows) between each pair of elements in the Regional or Project ITS
Architecture, then a set of standards can be identified for many of these flows. A report identifying ITS
Standards supporting regional and national interoperability is a required component of the Regional ITS
Architecture as identified in FHWA Rule 940.9(d)7 and FTA National ITS Architecture Policy Section
5.d.7. The Regional ITS Architecture Guidance Document includes recommendations on how to
approach this topic as it pertains to a Regional Architecture.
The National ITS Architecture maintains a mapping of architecture flows to ITS standards development
activities. Refer to the Standards page of the National ITS Architecture CD-ROM or web site for the latest
mapping between the National ITS Architecture and the ITS standards. Turbo Architecture accesses this
mapping information and makes it available for customization and tailored standards activity reports.
Not every region will use every applicable standard and often local standards will be identified where no
national standard is yet available. To address these needs, Turbo users can select the standards (tailor
the list of standards) that actually will be used in the region so that the Standards Activities report will
more accurately reflect the intent of the region and/or projects. Editing can be done for a region or project
on a standard-by-standard or interface-by-interface basis. Also, users will be able to add user-defined
standards to the list and link the user-defined standards to architecture flows that will be included in the
standards report.
GUIDELINE: Get your architecture to the point where you already have a good understanding of
your requirements and interfaces, i.e. customize the flows first. When you get to this point, gather
the key stakeholders together to make ITS Standards choices that will apply to any architecture in
the region.
The stakeholders should also assess ITS standard maturity and establish agreements for using interim
standards. In building consensus for the standards process, stakeholders should be educated on the
importance of standards, especially with respect to cost, risk, and interoperability issues both within a
region and when connecting to neighboring regions. Regional commitment should be built to deploy ITS
standards-based system interfaces.
In the sections below, you will see how to select the standards that apply to your regional or project
architecture, add comments to the database to explain your selections, create a locally-defined standard
and relate it to your architecture, and customize the ways in which the standards themselves relate to the
interfaces in your architecture. The customization of standards occurs at 3 different levels: standard
(creating custom-designed standards), entity interfaces (selecting which interfaces between the entities of
the national ITS architecture will be mapped to standards in your architectures regional and project
architectures are treated separately), and element interfaces (selecting the actual interfaces between the
elements in your architecture again, regional and project architectures can be customized individually).
More on the entry and customization in the following sections.
3.8.1 Standards Tab Entry

The Standards tab in Turbo Architecture provides the opportunity for the user to decide which of the ITS
Standards activities best apply to their situation. The first screen is shown in the next figure. The user
can use the pull-down at the top left of the screen to select All Standards that are possible from the
architecture flows included in the selected architecture, a Regional Architecture in this case, or just those
that have been associated with the current architecture via the Current Architecture Standards menu
selection.

Figure 82. Standards tab All Standards View

The columns in the All Standards view are defined as follows:
Group: Identifies the items in the list that represent a Group of standards.
Group/Doc ID: Provides the name of the group, if the Group column is checked, or the
document identifier for the standard which comes from either the Standards Development
Organizations (SDOs) when they release their standard, or a user-defined group or standard.
Title: The long name of the group or title of the standard.
SDO: The Standards Development Organization that is responsible for developing, publishing,
and maintaining the standard.
User: Signifies whether this standard is one that has been added by a Turbo user.
In Arch: Says whether that standard has been associated with the current selected Regional or
Project Architecture.
Include: Provides a powerful tool when looking at the All Standards view. With this set of check
boxes the user can decide at a high-level which standards activities should be considered for
selection in the Regional or Project Architectures. This provides users with a way to establish
high-level strategic decisions for their architecture by not including ITS standards that will not be
considered in the architectures. Without having to worry about each flow and whether it will
implement a particular standard, the user can just un-include each appropriate standard from
consideration for all of the flows in the architecture.
The user can change the display of the standards window using the buttons at the top of the screen:
View: Pressing the View button causes the display to either present the list of standards in
terms of the overall Standards list, or Standards by Entity showing the standards mapping by
source entity-architecture flow-destination entity triplet from the National ITS Architecture, or
Standards by Element showing the more specific standards mapping by source element-
architecture flow-destination element triplet based on the inventory of elements and interfaces in
the current regional or project architecture. NOTE that in View => Standards by Entity or
Standards by Element views the pull-down list on the upper left of the screen changes to be able
to quickly select a particular standard or group.
Group: Works like it does on the Interfaces tab, groups cells of the table together that have
identical contiguous content.

Sort: The sort options available on the Standards tab include Group, Group/Doc ID (default);
Include, Title; SDO, Title; Title; User Defined, Title; and Column Sort. As on the Interfaces tab,
with Column Sort just click on any column header and the screen will sort by that column. OR, if
in any other sort mode, click on a column header and the Column Sort option is activated.
Filter: Works when in the Standards by Entity or Standards by Element View. Right-click over
the Filter button to bring up the window to change the filtering selections: Entities, Interconnects,
Flows, or Market Packages. See discussion of Filters in Section 4.4.1.
Limit: As on the Interfaces tab, this will limit the display to just the standards that have been
included.
Info: With one of the standards highlighted, clicking the Info button will display information
describing the standard or group of standards. An example is shown in the figure below.
Present: Makes the characters 50% bigger to make it suitable for engaging in a group discussion
by projecting the Standards screen at a stakeholder meeting.
Figure 83. Standards tab Info Screen

Other options available on the Standards tab include the ability to create New user-defined standards,
Copy or Modify them, or Delete a user-defined standard. For example, a user could use this
capability to map a user-defined ITS Standards Group to the same interfaces that are mapped to the
NTCIP Center-to-Center group. This is not meant to imply that users can define their own ITS standards
but to provide a way to document the fact that some regions have state DOT standards, or standard
practices that will guide the implementation of ITS as much as a standard will. In addition, there are
variations between different versions of a standard. Another reason the user may need to customize the
list of standards is to identify the version or revision number of a standard.
When the user wants to add a New standard and clicks the New button, the user is prompted, Have
you considered other applicable ITS standards? Then the input screen will come up allowing the user to
create a name, Group/Doc ID, assign a Lead SDO either using the pull-down to select one of the

existing organizations or create your own. Document the Type of standard being used from the
pulldown (select Communications Protocol, Message/Data, or Other user entry required), the
Version Number, and a brief Description. The user-defined standards Title, Group/DocID, Lead
SDO, and Type are required entries with the Title and Group/DocID field needing to be unique.
Figure 84. Standards tab New Standards Input

The user may choose to create a Standard Group, checking the Standard Group box and selecting
standards (ITS or user defined standards) from the list at the bottom of the window to associate with this
group. The user may use an existing ITS standards group as a basis for creating a new user-defined
standards group via the Copy option. The user may also enter a compound name (e.g.,
AASHTO/ITE/NEMA) if the standards group is developed by more than one organization. This
information will be displayed from the main Standards screen when the user selects the Info button.
Once the basic information for a new standard is completed Turbo then asks if this standard or group
should be associated with the current architecture. If yes, then another screen is presented to select
which interfaces to assign to this new standard as shown in the figure below.
NOTE that if nothing is done on this Add Standard Entity Triplet Relationships window, and the user
simply Closes the window without making any selections, the new user defined standard may not
appear in the list, but the user may not re-use the Document ID that he selected for this standard. The
standard still exists so the Document ID is already used, even if the standard is not mapped to the current
architecture. Until the user defined standard is mapped to the architecture, it will not be shown in the
Standards tab, Standards View, unless you select All Standards in the pull-down menu.

Figure 85. Standards tab Standards to Interface Relationship

From the Standards tab, the user can modify or delete one of these user defined standards. They can
also Include them in their Regional or Project Architectures.
The Copy button allows the user to take an existing standard and customize the name or description for
their architecture. Effectively, making a user-defined standard or group that is based on a pre-defined
standard or group.
Once the selections for standards has been made for a Regional or Project Architecture, the user can
then make use of the Reporting options available to document the use of ITS Standards in the
architecture.
3.8.2 Modifying a Standard and Its Relationship to the Architecture

To modify the way a standard is defined when in Standards view on the Standards tab:
1. Select View => Standards at the top of the window to view the list by standard name.
2. Select the standard in the list that you wish to modify.
3. Click the Modify button at the bottom of the window.
4. If the standard is user defined, all attribute fields may be modified. If the standard is not user
defined, only the Version and Comment fields may be changed.
5. Click Apply or Cancel to return to the main Standards tab window. To change the flow
associations, switch to Standards by Entity view.
To modify the way architecture flows are associated with a standard use the Standards by Entity view:
1. Select View => Standards by Entity at the top of the window to view the list by entity name.
2. Use New to add entity triplets for either a user-defined or national standard (anything added to a
national standard will appear as a user-defined association), and Delete to remove entity triplets
from a user defined standard. Tailor the entity triplet mappings in this way to create all potential
element triplet mappings that are desired for the user defined standard.
3. Use the Include box to indicate whether a particular set of entity-flow-entity triplets that could be
used in the current architecture will adhere to a particular standard. For example, if a national
standard like NTCIP 1203 for Dynamic Message Signs is listed it includes several different flows.
A region may know ahead of time that it will only be using the 1203 standard to define the
interface for one direction, not both, anytime a dynamic message sign is used. Using the Include

boxes to un-check that mapping will then be reflected anytime that flow appears in the
architecture and will be reflected in the Standards Reports produced for the current architecture.
4. Click Apply or Cancel.
To modify the way a standard is associated with particular element interfaces when in Standards by
Element view:
1. Select View => Standards by Element at the top of the window to view the list by element name.
2. Include or un-include the element triplets to be associated with a selected standard. No other
fields may be modified. Use the Standards by Element view to remove any element triplets that
are not desired. Using the same DMS example as above, instead of saying all DMS in the region
will be done a certain way this allows one particular element in the architecture to be defined
differently than other elements in the architecture.
3. Click Apply or Cancel.
In both the Standards by Entity and the Standards by Element views, select the standard you want to
modify in the upper-left pulldown menu so that only the selected standard associations will be displayed.

3.9 Agreements Tab

Agreements among different stakeholder agencies and organizations are required to realize the
integration shown in the regional or project architecture, and to provide project interoperability. The
stakeholder/agency in charge of the architecture development should ensure that all stakeholders are
aware of the required agreements and their status.
Using the Agreements tab in Turbo Architecture, a list of the required agreements can be compiled, either
agreements already in place or new agreements that are needed. Each agreement will have a user-
supplied number, name, type, description, and status and be related to two or more stakeholders that are
identified in the architecture. Turbo reports will show the list of agreements and (optionally) the specific
relationship of each agreement to the architecture.
Any agreements (existing or new) required for operations, including at a minimum those affecting ITS
project interoperability, utilization of ITS related standards, and the operation of the projects identified in
the Regional ITS Architecture, are required in FHWA Rule 940.9(d)4 and FTA National ITS Architecture
Policy Section 5.d.4.
Each connection between systems in the Regional ITS Architecture represents cooperation between
stakeholders and a potential requirement for an agreement. Of course, this does not mean that hundreds
of connections in the architecture will require hundreds of new agreements. One agreement may
accomplish what is necessary to support many (or possibly even all) of the interfaces identified in the
architecture.
The figure below shows the main user interface for documenting existing or new agreements.
Figure 86. Agreements tab

As shown here, with All Agreements selected, you can select New or Delete at the bottom of the
window to create a new agreement or delete one of the existing agreements. Use the checkboxes on the
extreme left of the screen to quickly associate an agreement with the project.
The left side shows the agreement Number and Title and there are buttons at the bottom to choose
which columns will be shown: Number, Title, or Both. The user may hide either the name or number
column for the displayed agreements. By clicking on the top of each column the window can be sorted by
that column, in either ascending or descending order.
Highlighting one of the agreements will populate the right side of the screen with the information for that
agreement. These attributes may be modified, then Apply or Cancel selected. Clicking the New
button will allow you to start from scratch and fill-in any of the information on the right.
The Status field allows you to pull-down and select from any of the status values that are valid for the
selected architecture.
The Type field is another pull-down that allows you to select from one of the Types that have already
been defined, or you can enter a new Type. Agreement types could include Memorandum of
Understanding, Handshake, Operational, Interagency, Funding, etc. See the Regional ITS
Architecture Guidance Document for more information. Agreements take a long time to execute. Build
consensus early with simple agreements such as MOUs, while final agreements are being developed.
The Description field can include any text to describe the nature of the agreement, who is likely to be
involved, over what time period it is effective, or any other pertinent information.
The Lead Stakeholder (agency) is a pull-down to select from the list of Stakeholders defined on the
Stakeholders tab. There can only be one selected if more than one is really the lead then use the
Stakeholders tab to create a Stakeholder Group. Below the Lead Stakeholder a series of check boxes
provides a way for other stakeholders to be identified.
Finally, the Agreement can be associated with one or more projects that have been defined in this Turbo
database. Right clicking in the Projects area will expand the list to allow the user to view more projects.
Right clicking in the Stakeholders area works the same. Right click a second time to return the list to the
smaller size. (This works in the same way as on other tabs.)
This information can be output using the List of Agreements report that provides a number of sorting
and include option settings.

4 Turbo Menubar
4.1 File Menu
Managing Turbo Architecture database files is done from the File pulldown menu as illustrated below:
Figure 87. File Pull-down Menu

The following sections will explain in detail how to use these menu options.
4.1.1 Creating a New Turbo Architecture Database File

To create a new database file in which new architecture definitions will be stored:
1. On the menubar, select: File => New
2. A new file is now open. NOTE that File => New works as in other Windows applications, i.e.,
the new file is not given a name until exiting from the file or saving the file. The title bar of the
main Turbo Architecture window will indicate that the file is new.
3. After creating a new database file, the user may create or import an architecture, then save the
new file, or exit the tool.
4. The Import option for importing a project architecture into the currently open file is described in
Section 4.1.4.
5. Save and Save As work as in any Windows application and are described in Section 4.1.5.
6. The last 4 files opened by Turbo are listed and can be opened quickly.
7. If Exit is selected and changes to the new file have been made (such as creating an
architecture), a window will appear asking if the user wishes to save the changes made to the
new file. If the user says Yes, the next window will ask to type in the name of the new Turbo
Architecture database file. This file should have the .mdb or .tbo file extension (the default is
tbo). This file name will then appear in the title bar of the Turbo Architecture main window the
next time the file is opened.
4.1.2 Opening an Existing Turbo Architecture Database File

To open an existing Turbo Architecture database file:
1. On the menubar, select: File => Open
2. A window will appear asking the user to select the name of an existing Turbo Architecture
database file. If the database file selected was created with the current version of Turbo, then
this name will appear in the title bar of the Turbo Architecture main window.
3. If the database file was created in an earlier version of Turbo, then the user will be asked to
convert the database, or to open it using the previous version of the National ITS Architecture

(see the next section for a description of the conversion process). The older file is not actually
opened in the previous version of Turbo Architecture.
GUIDELINE: The Turbo Architecture database file is not a distributed file system, so two users
may not update the same architecture within a database file at the same time.
GUIDELINE: If a user needs to browse one architecture while updating another, he may simply
bring up a second Turbo Architecture session, open the database file, and view the appropriate
architecture. It is assumed that he is not trying to edit the same architecture in both sessions. If
two people are editing the same architecture, the database software will only warn them when they
try to save, not when they open the architecture tables. If they have both made changes, the last
one to save is warned that this table has been updated by another user (this is a Microsoft Access
feature, not a feature of Turbo Architecture).
4.1.3 Opening a Prior Release Turbo Database File

This section is only applicable if the user has Regional or Project Architecture that was created using an
older version of Turbo Architecture. If you are a first time user, have just downloaded Turbo, and have no
architectures from a prior release of the tool, then you may skip this section.
The Conversion process migrates existing Regional or Project Architectures and database files created
with prior releases of Turbo up into the current release version. This automated process will not execute
if opening an existing architecture created using the current version of Turbo. The software detects that
an architecture that the user wishes to open was created in a prior release and begins the automated
conversion process. A series of screens is displayed checking off the steps of the process, and asking
the user certain questions. This section describes the Conversion process.
GUIDELINE: An architecture developed with the current Turbo Version IS NOT backwards
compatible with previous versions of Turbo Architecture.
TAKE NOTE:
1. An architecture developed with the current Turbo Architecture Version may only be opened using
that version (and subsequent releases).
2. An older architecture developed with a previous version of Turbo may be opened in the current
Turbo using the conversion process. Once converted to the current version of Turbo, the
converted architecture MAY NOT be re-opened in a previous release version of the tool.
However, the original version of the architecture is still available after performing a conversion
(the user is asked to select a new name for the converted architecture, so the original is not
overwritten described below).
3. The older architecture may be opened (without conversion). This will associate elements in the
architecture with an earlier version of the National ITS Architecture. NOTE that if a previous
version Turbo architecture is opened in this way, that it MAY NOT be opened again in the
previous version of the tool. The architecture has been changed to be able to use the current
version, even though it is associated with a prior release of the National ITS Architecture.
The following are several items of general interest concerning the Conversion process. Following this
section is a discussion of how to use the conversion screens, options, and reports.
Before describing the Conversion process itself, the user should be aware that while there is no
requirement to upgrade the software to the latest version of Turbo Architecture, however, there are
always new features that make it advantageous to upgrade the Turbo Architecture software and existing
Regional and Project databases.
If a customer site has not yet upgraded the Turbo tool from Version 1.0 to 1.1, or from Version 1.1 to 2.0,
etc. Turbo will automatically upgrade a database from any previous version to make it compatible with the
current version. The user will notice an additional dialog box that will be displayed showing that the
earlier version database compatibility upgrade is in progress.

All user-defined extensions will be carried forward into the new version database. In special
circumstances, where a previous user defined entity or flow happens to exactly match a new National ITS
Architecture entity (subsystem, terminator) or flow, the user-defined extension will automatically be
converted to the equivalent National ITS Architecture entity or flow. These are duly noted in the
conversion reports (see the next sections for a discussion of the conversion screens and reports). In
every case, the interfaces defined by the user will be carried forward into the converted database.
During the conversion of a Turbo database, all system tables and configuration information are
maintained. The conversion software copies all user data from source to destination and also copies any
old system data that is referenced in the users architecture. Sometimes one architecture flow is replaced
with another automatically during the conversion.
Turbo will detect when an older architecture is opened and ask the user if he would like to convert the
architecture or simply open it.
If the user chooses to open the older architecture and not convert it, this will associate elements in the
architecture with an earlier version of the National ITS Architecture. Turbo automatically preserves the
original user file. NOTE that if a previous version Turbo architecture database is opened in this way using
the current version of Turbo, that database MAY NOT be opened again in any previous version of the
tool. The underlying tables in the architecture database have been changed just enough to be able to
use the current version of Turbo to view the older architecture, even though it is associated with a
previous release of the National ITS Architecture. You may want to retain a copy of the original file in
case another user still has an older copy of Turbo and wants to continue using it.
For clarification:
Turbo V1.0 and V1.1 were based on V3.0 of the National ITS Architecture.
Turbo V2.0 was based on V4.0 of the National ITS Architecture.
Turbo V4.1 is based on V6.1 of the National ITS Architecture.
If upgrading the tool to the current version of Turbo Architecture, then the question arises of whether to
migrate architectures developed with prior releases. Remember that an architecture created in the
current version of Turbo is not backwards compatible with previous versions of Turbo. The previous
versions of Turbo databases do not allow definition of Regional or Project ITS Architectures based on the
current National ITS Architecture.
Here are some pointers to guide the decisions necessary for a conversion/upgrade:
1. It is recommended that ALL users who are actively working on a particular architecture coordinate
the decision to upgrade to avoid incompatibility issues. The upgrade should be done at the same
time for all architectures and database files within the project, and should be timed so as not to
interfere with the development schedule.
2. If the new features of the National ITS Architecture are not necessary for the current project,
perhaps the upgrade can wait until after the project is completed. However, if the new
architecture features are required in the architectures under development, it is recommended that
the region or project upgrade in order to take advantage of the new features.
3. If the user is in the middle of developing a Regional ITS Architecture, the decision to upgrade to
depends on the situation. While Turbos conversion feature can be run in a few minutes, even for
a large architecture, user decisions made during the conversion and evaluation of the conversion
will take longer. What must be considered is where you are in the process, how the conversion
will impact work products that have already been delivered, and how the conversion will impact
stakeholder reviews and consensus work that has already been performed. Carefully examine
the conversion reports to understand what has changed. Remember that Turbo requires you to
save the converted file to a different name than your original pre-conversion architecture file.
4. If the Regional Architecture has not yet been developed to the point that interfaces have been
reviewed with stakeholders, then it is probably best to convert so the stakeholders invest their

time in reviewing the latest interface options. If the stakeholders have already invested time in
reviewing interfaces, and the architecture is close to final publication, then it is probably best to
wait and address conversion as part of future maintenance activities.
As for the latest version of the National ITS Architecture, go to the National ITS Architecture web site
(http://www.its.dot.gov/arch/arch.htm) for the best source of information on the features of the most recent
3
update and links to the actual architecture files. The web site provides a list of the changes and a list of
all subsystems, terminators, market packages, and architecture flows that were impacted.
Turbo provides special conversion reports that identify all impacts to subsystems, terminators, market
packages, and architecture flows. As part of the conversion process, other reports are available that list
the differences between the previous version architectures and the converted architecture.
4.1.3.1 Conversion from Previous Versions

The user has the ability to convert an existing file developed using a prior release of Turbo, so that it uses
the latest version of the National ITS Architecture. The following details the conversion process:
1. The user begins the conversion process by selecting File => Open for a database file created in
a previous release of Turbo Architecture.
2. Turbo will automatically identify whether file conversion should be considered.
GUIDELINE: Turbo will only begin the conversion once the user has selected a file and confirmed
that a conversion should be performed. The existing database is not replaced or deleted. The user
decides what to name the converted file and where to put the converted file.
In the example below, the file marinara V2.tbo has been selected to be opened and converted to the
current version of Turbo. Either a .mdb or .tbo file could be selected as long as it was built using some
prior version of Turbo architecture. Click Open to open the file and begin the process of determining in
which version it was developed or Cancel to cancel the operation.
Figure 88. Select the Database File to Be Converted

3. Once Turbo has detected that the selected file is from a prior release of Turbo Architecture
(Turbo V2.0 in this example) the next window to appear asks the user whether he would simply

like to open this file, maintaining all previous entities, and architecture flows, or if he would like to
convert the file to the current version of Turbo using the latest National ITS Architecture entities
and flows. The default is Convert.
Figure 89. Convert/Open the Database File Window

This dialog box will be shown to the user every time a file containing older data is opened. This
means that if the user decides not to convert the file, the same dialog box will be shown the next
time the file is opened. This will serve as a constant reminder to the user that the file has not
been converted. If the user selects Cancel, the file is not opened and the user must decide
whether to open another file. He must return to the File => New or File => Open menu to
continue.
4. Select Open File and OK to open the file previously created in Turbo Version 2.0 that is
baselined for National ITS Architecture Version 4.1 using the new Turbo tool.
5. If you wish to convert the file to the current version of Turbo, select Convert File and OK to
begin the conversion. Cancel will cancel the conversion process.
6. After selecting Convert File and OK , the next window asks the user to select a destination file.
The existing Turbo file is NOT replaced. It still exists at the end of the conversion process. Click
Save to begin the conversion process, or Cancel to exit from the process (not from Turbo).
The software will warn the user if an existing file name is selected. If the user selects Cancel
from this dialog box, then the user must decide whether to open another file and will have to
select File => New or File => Open to continue. If the user enters a valid file name and selects
Save, then the conversion process begins. The Save As Type should be .tbo. The new file
can also be placed in a new folder by selecting the icon at the top of the window (this works as in
other Open and Save As windows). Once a file is opened or converted and then saved by the
current version of Turbo, that file can no longer be used by previous versions of Turbo
Architecture.

Figure 90. Select the Destination File for the Conversion

7. The conversion will have to run to completion although the user will be allowed to cancel out at
different points during the process. The user will be kept apprised of the progress and will be
given the option to display, export, and print conversion reports during the conversion. The next
screen reports the conversion progress to the user. As each step in the conversion task list is
completed, it is checked off and the pointer moves to the next step. This progress screen may
look different based on how old the original database is. For example, an architecture developed
using Turbo V3.0 may have customized functional requirements or standards that need to be
included in the conversion. If it was developed using Turbo V2.0 as in our example then the
conversion process will simply skip those steps and not show them on the progress window.

Figure 91. File Conversion Process Steps

8. At the View Reports Step, the user may display certain reports about the conversion, detailing
both the differences in the two files, as well as the differences between the National ITS
Architecture versions. The user may review the changes that have been made during the
conversion and save a record of these changes for future reference. This is the only
opportunity the user will have to view the conversion reports. They may also be printed or
saved. If these reports are needed later, do not delete the original database file in case you need
to run the conversion again in order to see the reports a second time.
NOTE this Turbo Conversion Reports window is loaded with a specialized set of conversion
reports, but it works exactly like the standard Turbo reports windows found under the Output =>
Reports pulldown menu, and offers the same options (see Section 4.4.4). As with the standard
Turbo reports, the conversion report preview window allows the reports to be exported, saved, or
printed. Several reports include settings, such as, displaying the entity, market package, or
architecture flow descriptions. To display a report select the report title and click Preview. The
Save Recordset option is described in the section on standard Turbo reports, as are the options
on the report windows themselves.

Figure 92. Conversion Reports

Figure 93. Conversion Summary Report
Figure 94. Element Mapping Conversion Details Report

Figure 95. Flow Conversion Details Report

NOTE that some flows in the reports may appear with an asterisk after the flow name. This indicates
that these are discontinued flows from the conversion.

Figure 96. Market Package Changes Report

9. The final conversion window asks the user if he wishes to delete discontinued entities and flows
from the original architecture. These are subsystems, terminators, and architecture flows that
have been deleted (perhaps completely deleted, or split into other entities and flows) in the
National ITS Architecture. Select Yes or No.
If discontinued flows are not deleted during the conversion, they will remain in the converted
architecture, and will be marked in the database as discontinued. These flows may be viewed on
the conversion report titled Discontinued Flows. This report can be displayed during the
conversion, or with the other standard Turbo Architecture reports available on the Output =>
Reports pulldown menu. The other standard Turbo reports and diagrams and the Interfaces tab
distinguish between discontinued flows, user defined flows (see User Defined Flows/Entities
report), and National ITS Architecture flows, by using an asterisk for discontinued and National
ITS Architecture flows if the database has been converted. The Info window on the Interfaces
tab will distinguish between the three types of flows. Discontinued flows will not be changed to
user defined flows by the conversion program.

Figure 97. Delete Discontinued Entities and Flows?

10. The Turbo File Conversion process step window remains displayed after the user has selected
to keep or discard discontinued flows, saying that the conversion has completed successfully and
guiding the user to do a Build.
Figure 98. Final Turbo Conversion Window

11. Click OK to complete and exit from the conversion. The converted database is now open and
available for editing.
So, the file has been converted. What now? The user has several options of what to do next:
1. Select new interfaces:
a. Go to the Interfaces tab and do a Build to add interfaces to the existing inventory. It is
recommended that you do a Conservative build as a first step to ensure you have all the
latest flows to choose from.
b. Tailor the converted architecture on the Interfaces tab.
2. Add new National ITS Architecture subsystems, terminators, and flows:
a. Review the Conversion reports that identify new entities, market packages, and interfaces.
b. Add/modify the inventory.
c. Update the entity mappings.
d. Update market package choices.
e. Use The Build option on the Interfaces tab to add new interfaces.
f. Tailor the Interfaces tab.
4.1.3.2 List of Conversion Reports

The reports that may be displayed during the conversion process include the following:
1. Conversion Summary -- This one page report illustrates information about the source and
destination Turbo Architecture files, including version information, source and destination file
names, and a list of the architectures that were converted.
2. Element Mapping Conversion Details This report identifies the changes that were made to the
mapping between elements and entities in the converted architectures. All mappings between
architecture elements and the National ITS Architecture entities (subsystems and terminators) are
listed by the change represented new, modified, replaced, discontinued, including the old and
new entity names where applicable. This report identifies the entities that were added, deleted,
and renamed, along with the user-defined elements that are impacted by the changes.
3. Functional Requirement Conversion Details This report identifies the specific functional
requirements changes that were made to the regional and project architecture. This will identify
whether the requirements were replaced, renumbered, edited, or discontinued. The requirement
changes are grouped by inventory element and functional area. The only setting for this report is
Display Requirement Text. This is a toggle that will turn the text on or off for each requirement
in the report.
4. Flow Conversion Details This report identifies specific architecture flow level changes that were
made to the converted Regional and Project Architectures. This report lists the new architecture
flows between elements, as well as the flows that changed names due to updates in the latest
version of the National ITS Architecture. This report identifies all the architecture flows that were
added, deleted, and renamed by the conversion. This report will vary based on the size of the
original architecture and which version of Turbo was used to develop it. For instance, if it was
generated using V1.0 then this report may be quite large given the large number of changes that
were added in the current update to Turbo. Between the previous and current versions there
were relatively few changes. It shows new flows that were added, existing flows that were
replaced by new flows, and any user defined flows that happened to match new National ITS
Architecture flows and were converted. Discontinued flows will appear in this report as having a
status change.
5. Discontinued Flows This report shows the discontinued architecture flows that are still included
in the converted Regional and Project Architectures. If the user chooses to keep these flows,
they can be edited individually on the Interfaces tab. This report also appears in the list of
standard Turbo Architecture reports. The Interfaces tab lists discontinued flows, user defined
flows, and National ITS Architecture flows, and distinguishes between them by using an asterisk
for discontinued and National ITS Architecture flows if the database has been converted. The

Info window (under Interfaces flows view) also distinguishes between the types of flows.
6. User Defined Flows/Entities This report identifies all user defined entities and flows in the
converted Regional and Project Architectures. This report allows the user to review user defined
entities and flows since some of these could be converted into new National ITS Architecture
entities or flows. Note the last column, where the conversion may actually convert user defined
entities and flows into equivalent National ITS Architecture entities and flows, yielding a user
defined flow that actually consists only of National ITS Architecture elements, but not in a way
defined by the National ITS Architecture.
As an example of this situation, there is a user defined entity or flow that happens to exactly
match a new National ITS Architecture subsystem, terminator, or architecture flow. This will be
rare, but it will come up. For instance, you previously created a user defined entity called Shelter
Providers and a user defined flow for evacuation shelters called shelter information that now
exactly match new entities and flows that were added to the National ITS Architecture. During
the conversion, the software determines that there is a name conflict between the user-defined
and National ITS Architecture flows and entities, and the National ITS Architecture flow or entity
always takes precedence. As a result, users may sometimes see user defined entities or flows
automatically replaced with National ITS Architecture entities or flows with the same name.
Changes are duly noted in the conversion reports.
In this situation, two popup windows will appear during the Convert Entities and Entity Mapping
step of the conversion. The first warns that
A new National ITS Architecture entity has the same name as one or more of your User Defined Entities.
The National ITS Architecture entities will be used. See the Element Mapping Conversion Details report for
more information.
The second, similarly, warns that
A new National ITS Architecture flow has the same name as one or more of your User Defined flows. The
National ITS Architecture flows will be used. See the Flow Conversion Details report for more information.
In the example, this creates an interesting situation where there is a user defined flow: Shelter
Providers => shelter information => Transit Management where the source/destination/flow are
all in the National ITS Architecture, but the overall flow is still user defined because shelter
information actually goes from Shelter Providers to EM and ISP in the current National ITS
Architecture, not to TRMS. The user defined flow shelter information still appears in the list of
flows on the Extend => Flow window. It has picked up a new attribute, Flow Kind, which is set
to National ITS Architecture in this case, because the flow exists in the architecture, but the
interface is different. However, if the user defined flow shelter information had been used in
exactly the same way as in the newest version of the National ITS Architecture, this user defined
flow and its interface (Shelter Providers => shelter information => Transit Management) would
have disappeared from the User Defined Flows window and would exist on the Interfaces tab as
a regular National ITS Architecture flow and interconnect included in the architecture. The Turbo
V2.0 user defined entity Shelter Providers also disappeared following the conversion, and was
replaced by the new National ITS Architecture terminator Shelter Providers.
GUIDELINE: During the conversion from a previous version of a Turbo database, the user may
notice that certain user defined flows from the original architectures now either (1) disappear
altogether from the User Defined Flows window, or (2) do not have all the interfaces defined
from the original file. These flows or interfaces now exist in the newest version of the National
ITS Architecture, so are no longer defined as user extensions. They will appear on the Interfaces
tab because they are still part of the architecture.
7. Version x.y Subsystem and Terminator Changes This report identifies all subsystem and
terminator changes included in the current version of the National ITS Architecture. All entities
are listed by the change represented new, modified, replaced, discontinued, including the old
and new name where applicable. This report is based only on the National ITS Architecture and
thus will be the same for each user who runs it during the conversion. There will be differences
depending on the version from which the starting database was built.

8. Version x.y Market Package Changes This report identifies all Market Package changes
included in the current version of the National ITS Architecture. All Market Packages are listed by
the change represented new, modified, replaced, discontinued, including the old and new name
and Market Package number where applicable. This report is based only on the National ITS
Architecture and thus will be the same for each user who runs it during the conversion. There will
be differences depending on the version from which the starting database was built. The only
setting for this report is Display Descriptions. This is a toggle that will turn the description on or
off for each Market Package in the report.
9. Version x.y Architecture Flow Changes This report identifies all architecture flow changes
included in the current version of the National ITS Architecture. All architecture flows are listed by
the change represented new, modified, replaced, discontinued, including the old and new flow
name where applicable. Also included is the source and destination entity name for each flow.
NOTE that certain discontinued flows have actually been replaced or substituted with other flows.
In some areas of the Architecture, functions or terminators were merged causing old flows to be
merged together into a new flow. See the Conversion Guidelines document for more
information. The only setting for this report is Display Descriptions. This is a toggle that will turn
the description on or off for each architecture flow in the report.
10. Version x.y Functional Requirements Changes This report identifies all Functional
Requirements changes included in the current version of the National ITS Architecture. The
requirements are listed by the functional area they are from and the change represented new,
replaced, edited, renumbered, and discontinued, including the old and new name and number.
This report is based only on the National ITS Architecture and thus will be the same for each user
who runs it during the conversion. The only setting for this report is Display Requirement Text.
This is a toggle that will turn the text on or off for each requirement in the report.
11. Version x.y Standards Changes This report identifies all Standards changes included in the ITS
Standards Mapping that is included with the current version of the National ITS Architecture. The
standards are listed by the change represented new, modified, and discontinued, including the
old and new Standards Development Organization, standard name and document ID. An
asterisk identifies which rows are a group of standards. This report is based only on the National
ITS Architecture and thus will be the same for each user who runs it during the conversion.
4.1.4 Importing an Existing Project Architecture

The following process may be used to import an existing Project Architecture from a second Turbo
Architecture database file (source file) into the open database file (destination file). A Regional
Architecture may be imported from one file into another in the current version of Turbo Architecture (see
Section 3.1.1.7 for information on this procedure it is different from importing a Project Architecture).
Also, a Regional Architecture does not need to exist, or if there is one, it does not need to be opened, in
the destination file before importing a new project into the file.
4.1.4.1 Steps for Importing

Follow these steps to walk through the process of importing a project architecture into your current file:
1. It is a good safety measure to do a Save As of the destination Turbo Architecture database file
prior to importing. This means any work you have done prior to importing is saved. Once an
architecture is imported into this file and saved, it is not possible to back out the import.
2. For a Project Architecture to be imported from the source database file, the project must already
be fully defined in that database file. That is, the Project Architecture to be imported must be
built, via the Build option on the Interfaces tab, so that all elements and architecture flows
appear in the Interfaces tab and are present in the architecture.
3. NOTE: The architecture may have already been customized on the Interfaces tab prior to
Import, or the Turbo Architect may wait until importing the architecture before customizing it in
the new database. If the architecture was customized in the source file, all customization is
imported with the architecture.

GUIDELINE: The user MAY NOT import prior release versions of Regional or Project
Architectures. Only an architecture developed using the current version of Turbo may be
Imported. The Import process will detect if an architecture is included in a file from a
prior release, and tell the user that he must Convert the file up to the current version of
Turbo Architecture, then Import the architecture into the destination file. See Section
4.1.3 for a description of the Conversion process.
4. To import the external Project Architecture into an open database file, on the menubar select
File => Import
Figure 99. Project Architecture Import

5. NOTE that a Regional Architecture does not have to exist in the file that the project is being
imported into. This may be a brand new file without any defined architectures, or a file that
includes other Project Architectures and/or a Regional Architecture as in the above example.
6. A window will appear asking the user to select the name of the Turbo Architecture database file
from which to import the Project Architecture. Select the desired path and file name. Click
Open to open this file.
7. If a user tries to import a prior release architecture, he will see the following message:
Figure 100. Must Convert Old File Before Import

8. Once a valid/current file is selected and opened Turbo will then display the list of Project
Architectures included in that database as shown in the next figure. Select the Project
Architecture to be imported (only one project at a time may be imported). The path name may
also be changed without returning to the previous screen. Click Import (or double click on the
project name) to begin the process.

Figure 101. Import Project Selection

9. If the project name already exists in the destination file, a window will appear stating this. You
must rename the existing project in either the source or the destination file and try the Import
again.
10. The process of Importing a Project is a step-by-step process to analyze each individual set of
architecture objects in the source architecture and decide whether it needs to be imported. Some
of the following screens may not appear if your target file already includes the object.
GUIDELINE: When importing a project Turbo only prompts the user when it actually has to add
new items to the local file during import. For example, it only warns about the elements and
stakeholders that dont already exist in the local file. If all the elements/stakeholders that the
project needs already exist in the local file, then Turbo just quietly maps the existing file objects
to the project without prompting the user. If the local file already includes everything needed for
the imported project, then the only prompt that the user sees will be at the end saying that a
conservative build is needed.
11. The next screen shown below is only displayed if the status values in the imported project do not
match those in the destination file. The user may change these status value mismatches using
the pulldown menus on the right and Continue with the import, or he may Cancel the import at
this point. All the status values that are used in the imported project may be assigned to
inventory elements, flows, or to the project itself in the imported file.
This is Turbos best guess at a mapping, based on the status value names and sort order. This
example is based on a kind of worst-case scenario where a user is trying to import a project with
a rich set of status values into a file that only has the basic Existing/Planned defined. The
algorithm that Turbo uses guesses pretty well in this test case, but this might not always be the
case if the two sets of status values are completely unrelated.

Figure 102. Import Manager Status Values

12. The next screen lists elements that are defined in the project being imported, but not included in
the Regional or Project Architectures in the destination database file. Select Yes to import
these elements, or No to ignore them. Only the elements with unique names are listed in this
window, although ALL elements from this project will appear in the imported project in the
destination file. The elements that already exist in the destination file will continue to have those
elements associations and attributes. If this is not what the user intends in this project, they may
be changed after importing.
Figure 103. Import Manager Elements

13. The next window shown below asks the user if he wishes to add user defined entities that are in
the imported project but not in the destination file. Answer Yes or No. This window will not
appear if there are no user defined entities in the architecture.

Figure 104. Import Manager User Defined Entities

14. The next window shown below asks the user if he wishes to add stakeholders that are in the
imported project but not in the destination file. In this example, one of the projects stakeholders,
State Highway Patrol, already existing in the target database so it was not listed. This window
may also include stakeholder groups. Answer Yes or No.
Figure 105. Import Manager Stakeholders

15. If Operational Concept roles and responsibility areas are included in the file, they will be imported
next. The next figure shows a dialog box asking the user whether to import the areas found in the
file being imported. Any roles and responsibilities in that area that are new will also be imported
along with the new area.

Figure 106. Import Manager Role and Responsibility Areas

16. If Functional Requirements exist in the architecture, they are imported at this point.
17. At this point, a window may appear asking the user if he wishes to add user defined flows that are
in the imported project but not in the destination file. Answer Yes or No. This window will not
appear if there are no user defined flows in the architecture.
Figure 107. Import Manager User Defined Flows

18. The next window asks if it should add the architecture flows (with source and destination
elements) from the project being imported into the Interfaces tab in the destination file. By
selecting Yes, ALL flows in this window are imported.

Figure 108. Import Manager Interfaces Tab Update

19. If Agreements are included in the file, they will be imported next. The next figure shows a dialog
box asking the user whether to import the agreements found in the file being imported.
Figure 109. Import Manager Agreements

20. The following window asks the user if he would like to do a Conservative Build now, at the end
of the Import. If he waits to do this later and forgets, all the not planned flows from the source
project will not show up on the Interfaces tab until the Build is done. However, an Aggressive
Build will add back in any deleted flows (those deselected on the Interfaces tab in the source
project), so the user must do a Conservative Build at some point before adding new elements or
market packages to the project. Select Yes or No. See Section 3.7.1.2 for more information
about the Build Settings.

Figure 110. Import Manager Build the Architecture

21. By selecting Yes, the import process is completed and the destination project is built. No also
completes the import process, but you must do a Build later on the Interfaces tab, using the
Conservative Build setting as described above. You must save the destination (currently open)
database file in order to save the changes from the import. It is recommended that you do this
here. However, see note 1 and 2 under Tips on Importing in section 4.1.4.3. There are some
situations where you may not want to save so quickly.
22. This completes the import of the project. The following screen appears.
Figure 111. Import Successful

23. Finally, the original Import window appears allowing the user to import another project from the
source file into the destination file, or to Close (exit from Import).
The following sections will discuss the rules for importing and give you some additional tips on the proper
use of this capability.
4.1.4.2 Rules of Importing

So you have imported a Project Architecture from one file to another. What actually got imported and
why? (What did Turbo Customs do to your data?) Here's what you imported:
1. The Project Architecture you just imported will be the architecture currently selected in the file.
You can see this by looking at the title bar which will show the architecture currently open in the
file. Take note of this -- to view all data for the Regional Architecture, this architecture must be
opened (selected) specifically by the user. After Import, it is the imported Project Architecture
that is actually open.
2. All the elements in the source Project Architecture may not be imported into the destination file. If
the source project includes inventory elements that are not actually connected into the
architecture, i.e., no architecture flows are connected to these elements on the Interfaces tab

after building the architecture via the Build option on this tab, then these elements are not
imported into the destination file.
3. For each element with a distinct element name the entire set of information was imported
element name, element description, stakeholder, status, and project association.
4. For each element whose name identically matches an element name in the destination file, the
only piece of information always imported is the association with the new project. NOTE that if
the element had a different stakeholder, description, or status than in the destination file, that
information will NOT be imported. [NOTE: detailed technical discussion ahead! Ignore if it does
not interest you. The reason much of the information is not imported is that the import process
checks for element name first, and when it sees a match with an element name in the destination
file it goes no further in its checking. Why dont we check further? Because the tool's underlying
logic uses element id as the primary key for defining elements. If it sees two identical element
names (one in the existing file and one being imported) it assigns the same element id to them
both and hence they must share all other properties. The project identification is a one-to-many
mapping so it can be updated.]
5. Market packages that are associated with the selected project are imported along with the
elements and flows from the project. The market package status is imported under the following
conditions:
a. The market package is associated with the selected project.
b. The market package status in the import file is different than Not Planned.
c. The market package status in the destination file is Not Planned.
6. Under these conditions, the market package status in the destination file will be set to match the
status in the import file. The status in the destination file will never be changed to Not Planned
during Import. The status will also never be changed from/to other status values during Import.
Thus, the market package choices that were made in the destination file are preserved, and any
new market packages that were associated with the imported project are added.
7. A Market Package / Element pair that is selected before Import will always still be selected after
Import. In addition, Market Package / Element selections in the destination file are preserved in
this way. Elements associated with a market package are selected during Import when the
following conditions are met:
a. The market package is associated with the selected project.
b. The element is associated with the selected project.
c. The Market Package / Element pair was selected in the import file.
8. Architecture flows are imported if they are not used in the destination file. What if the flow already
exists? It is assigned to the project being imported. But what about its status?
a. If the status in the destination file is Not Planned, then the import process will give it the
status from the source file.
b. If trying to import a project with a flow that is Existing, but the flow is contained in the
destination file with a status of Planned, for example, the status of the flow will not be
changed in the destination file.
c. Similarly if the imported status is Planned and the status in the destination file is Existing,
the status will remain Existing after Import.
d. A new project association is added on the Inventory tab to the existing Regional Architecture
element that links to this flow.
9. Following the Import, the Interfaces tab will display just the source-flow-destination triplets that
were selected in the original file (but not any of the possible flows or interconnects that were Not
Planned in the original file). In order to add all of the Not Planned flows, the user must run the
Conservative Build step for the imported project either during Import, or manually via the
Build option on the Interfaces tab after the Import. Why would the user want the Not Planned
flows as part of the imported project? Maybe there is more customization of the imported project

planned in the new file, and some of these flows will be required later for additional integration
with the other projects and the Regional Architecture in this file.
NOTE: Flows that the user originally deleted from the project may be reintroduced when an
Aggressive Build is performed on the imported architecture. A Conservative Build may be
done the Build option on the Interfaces tab to prevent deleted flows from being reintroduced into
the architecture by the Build step after the Import. However, if new elements or flows are
added to the architecture once it has been imported and built in the new file, an Aggressive
Build to add ALL the required new flows may also pick up the deleted flows from the original
imported project if the Override Previous Builds setting is selected. To do an Aggressive Build
and not reintroduce the deleted flows, the Override Previous Builds setting should be selected.
In any case, the user should closely review the list of flows that are being added by the Build
option before accepting it. Be aware that if these deleted flows are reintroduced, they should be
deleted again in the imported project.
10. The Interfaces tab for the imported project will preserve all customization that was done in the
source file.
11. GUIDELINE: The Build step to build the architecture following an import may change
the architecture you import. If you Build and notice that flows are being added to the
architecture and being assigned a status value, you can allow the architecture to change, or
cancel out of the Build step, go to the Services tab and deselect either the market
packages assigned to the project imported, or adjust the element assignments. Run the
Build option again on the Interfaces tab and verify only non-planned flows will be added to
the Interfaces tab.
12. If the project has a unique name, it will be imported into the open database file. If the user tries to
import a project that already exists in the destination file, an error message is displayed and the
import is terminated. If the user would like to import a project into a file that already contains a
project of the same name, the user may:
a. Rename the existing project in the destination file to a name that is different from the project
that will be imported, or
b. Rename the project in the source file to a unique name before it is imported.
13. Turbo supports import of project architectures that have local user defined status values.
Conflicts between status values in source and destination Turbo databases during project import
will be identified and displayed to the user. The user may override the custom status values in
the source file with the status values in the destination file.
14. User defined entities and flows may be fully or partially imported into the project. Source and
destination information is imported for user defined flows that are included in the imported project.
NOTE that only source and destinations that are actually associated with the project elements are
included. In some cases, this will result in only part of the user defined flow source and
destination information being imported (if, for instance, the project only maps to a subset of the
source and destination entities). In rare cases, no source or destination information could be
imported (if, for instance, you Build the architecture, then remove the source and destination
entities from the project elements).
The data for this project, subject to the rules above, will then be imported to the destination Turbo
Architecture database file as a new Project Architecture, not yet merged with the Regional Architecture.

4.1.4.3 Tips on Importing

As you can see from the above discussion, the importing of a project into a file can have some
complexity. Below are some of the common issues you may run into, and how to handle them.
1. What if you end up with an imported element that has a slightly different name from one in the
destination file (and you wanted them to be the same)? First, how would you recognize this?
Look at the Inventory tab and see if they show up as two elements. So now what do you do?
Probably the easiest way to fix this is:
a. Do not save the destination file (i.e., throw away your import).
b. Go back to the imported (source) file and change the element name so it matches the
element in the destination file.
c. Re-import the architecture with the matching names.
2. What if you have already saved the destination file (i.e., the import can't be reversed)? The fix is
not quite as simple, but this is what you would do:
a. Identify all the source element / architecture flow / destination element triplets involving the
incorrect element name (the element you imported). You can get a printout of these as part
of the Project Architecture report.
b. Associate the correct name with the imported project, and unassign the imported name with
the project. This may be done on the Inventory tab.
c. Build the architecture via the Build option on the Interfaces tab.
d. On the Interfaces tab, add all flows associated with the correct element, and change to Not
Planned all the flows associated with the incorrect element. If your project was large this
could be a lot of flows. Thats why the first approach is usually easier.
3. What if some information relating to an imported element was lost because it had the same name
as an element in the destination file? Let's consider two cases here.
a. The first is that you want the element names to be the same but want the information from
the imported element. Then go to the Inventory tab, select the element, and change its
description, stakeholder, or status. BUT NOTE: If you do this for the project you imported it
will apply for all architectures in the file (both regional and project). This is a global (file-
wide) change.
b. If you really want two sets of definitions, stakeholders, or status define two elements.
5. Importing just loads the Project Architecture into the destination file. If you want to add this
project to an existing Regional Architecture, or start to create a Regional Architecture with it, you
need to go to the Start tab and run the Project to Region option to merge the Project
Architecture into the Regional Architecture, see Section 3.1.1.8.
4.1.4.4 Reports that Reflect Imported Data

Once the Project Architecture has been imported, the architecture may be opened in the destination file.
All output reports and diagrams are available for this architecture, but the following reports may indicate
specific information regarding the imported data.
1. Inventory report, which shows the elements and the stakeholders associated with them.
2. Stakeholders report, which presents all the stakeholders assigned to the project.
3. Project Architecture report, which is a detailed report of all the elements and architecture flows
in the project, including user defined flows.
4. Region to Project Comparison report, which lists architecture flows that are in the region but not
in the project, as well as flows in the project but not in the region. This report is only available if
there is a Regional Architecture in the file. This report, if displayed immediately after the Import,
will show all new flows that have been imported since none of these new project flows will have
been merged into the Regional Architecture yet. This report should be printed before merging the
project with the Regional Architecture.

5. User Defined Flows/Entities report, which lists the user defined entities and flows and their
associated elements. This report includes all imported user defined entities and flows.
All of these reports are described further in Section 4.4.4.
4.1.5 Saving a Turbo Architecture Database File

The following process may be used to save an open database file and all (updated) architectures
contained in the file:
1. To save an open file, on the menubar, select File => Save. This will overwrite the previous
version of the database in the same directory where it was opened.
2. If what-if scenarios are being tested and several versions (checkpoints) of a database and its
architectures are to be saved, on the menubar, select File => Save As
a. A window will appear asking the user to select the pathname and to type the name of the new
Turbo Architecture database file.
b. This will save the database changes to a new file, and will not save the changes in the old
database file. Either .mdb or .tbo may be used as the file extension. This option is useful
for testing out various ways in which a particular change might be implemented in an
architecture, or for making interim copies of an architecture during development.
3. If the user selects File => Exit without first saving the updated database file, a popup window
will be displayed asking if you want to save your changes, as shown below:
Figure 112. Exit Warning Message

a. In this example, the user may have just forgotten to save and can use this reminder to save
before exiting. However, if the user wasnt satisfied with the changes that had been made
say No and start Turbo over again and reopen the database from a clean copy. The user
may also select Cancel to return to Turbo and continue working.
b. If the database was not changed, or the user selected File => Save already, this popup
window will not appear.
c. If the user selects File => Open or File => New without first saving the updated database
file, the same popup window is displayed unless the database was not changed, or the user
selected File => Save already. Selecting File => Open or File => New to close a
currently open file and open another file will leave the Turbo Architecture session executing.
4. If the user was creating a new database file and had selected the menubar option File => New,
he will be asked to save his work and give the new file a name when he exits from the file.
GUIDELINE: Data is only saved when you choose the Save or Save As options (or when you
exit the file and save). All work you do between saves is put into a temporary file called
turwork<time/date stamp>.mdb. For large architectures, you should also save every so often to a
different filename in case a mistake is made so you can go back to the previous version.
4.1.6 Exiting from a Turbo Architecture Database File

To exit from Turbo Architecture, select File => Exit. If changes made to file have been saved this
command will simply exit from the tool. If changes have not been saved yet, a popup window appears
asking the user to save or cancel his changes.

NOTE: Turbo Architecture generates a temporary file called turwork<time/date stamp>.mdb during the
creation of an architecture. If there was a system crash or runtime error (this should never happen, but
occasionally you may run into this problem), and Turbo exited prematurely, the temporary file may still
exist. The file may have been new, or the user may have been customizing an architecture in an existing
file. When the user tries to reopen it, he may not be able to find the file at all, or all his changes to the old
existing file seem to have disappeared. Look for the temporary file in the Windows temp directory (e.g.
C:\Documents and Settings\<logon id>\Local Settings\Temp). Rename this file to end in .tbo and try
opening it with Turbo Architecture. Your changes should be there. You may then save this temporary file
(File => Save or File => Save As) under whatever name you choose. After finding and saving the
file, exit from Turbo again. If there was a runtime error or system crash, make sure that the Turbo task
has actually ended. To do this, click on CTRL-ALT-DEL, select the Task Manager, and end the
Turbo task if it is still running. If this does not correct the problem, you may need to reboot your
machine.
4.2 Edit Menu

The Edit pulldown includes the cut, copy, and paste functions that work as in other tools.
Figure 113. Edit Pulldown

1. Select a word or phrase (for instance, in the description of an element).
2. Click Cut (to delete the phrase from the selected field and copy it to the clipboard) or Copy (to
copy the phrase elsewhere).
3. Select another element, stakeholder, or similar item that allows a description or comment.
4. Click Paste to insert the phrase in a user editable field.
Keyboard shortcuts also work for these options, similar to other Microsoft tools.
NOTE that these options on the Edit pulldown only work for window fields that may be edited by the
user. You may not select a portion of a report using Edit => Copy to insert into another document. You
must save the entire report to a file, then open and manipulate it in the selected editor. Information for
saving a report in different formats may be found in Section 4.4.4.
4.3 Tools Menu

The figure below shows the Tools pulldown from the Turbo Architecture menubar. The sections that
follow will discuss the tools that can be used to Extend the architecture, Synchronize elements between
architectures, update and create customized status values, and to check the request/response flows.

Figure 114. Tools Pulldown
4.3.1 Extending the Architecture

An item that cannot be represented by a National ITS Architecture entity or architecture flow may be
included in the Regional or Project Architecture as a user defined entity or user defined flow. Any
element not associated with a National ITS Architecture entity can be associated with a user defined
entity in the Regional or Project Inventory. As an example, this feature can be used to capture legacy
transportation systems in their entirety (rather than mapping into the National ITS Architecture). It can
also be used for unique items, such as red-light cameras or flood control, that are not National ITS
Architecture entities.
There are two types of locally defined items:
User defined entity with characteristics similar to a National ITS Architecture subsystem or
terminator, these have flows associated with them and may be mapped to any element in the
architecture.
User defined flow with characteristics similar to a National ITS Architecture flow. A user
defined flow must be hooked to the architecture by establishing relationships with other elements
and entities within the architecture. The user defined entity may be defined first, then the flow
that references it.
GUIDELINE: A user defined flow may be connected to a user defined entity or to a National ITS
Architecture entity (subsystem or terminator). Their names must, however, be distinct and
separate from National ITS Architecture names.
GUIDELINE: User defined entities and flows may be added to an architecture at any time before
or during the customization process, while on any tab. However, in order to see the user defined
flows on the Interfaces tab, a Build must be done to add them to the architecture. These
extensions may then be reassigned or modified on the Interfaces tab. In addition, the user
defined flow must be mapped between various subsystems or terminators that are interconnected
in the National ITS Architecture. This is accomplished by mapping the flow between the new user
defined entity and a different type of National ITS Architecture entity, or another user defined
entity mapped to a different subsystem or terminator.
For example, if the user defined flow is mapped between the TMS and another user defined entity that
happens to be associated with an architecture element that is mapped to the TMS, then this represents a
flow that is internal to that element and the flow will not appear on the Interfaces tab after a Build.
However, if the source or destination entity for the new user defined flow is something other than the
TMS, such as an ISP (which is interconnected to the TMS in the National ITS Architecture), then the new
flow will appear on the Interfaces tab after a Build mapped between TMS and ISP elements.

Remember that when creating locally defined entities and flows that this information is not mapped to any
standards. This mapping may be required and will be a manual process of defining customized
standards and mappings to the user defined flows.
4.3.1.1 User Defined Entities

Create a new user defined entity (i.e., extend the architecture to add a subsystem- or terminator-like
entity) with the following steps:
1. On the menubar, select: Tools => Add Entities
2. The User Defined Entities window is used to create, edit, or delete a user defined entities. Select
New to create a new entity or modify an entity already listed by selecting the name on the left
and changing the appropriate information on the right. There is also a Delete option to delete
an existing user defined entity.
Figure 115. User Defined Entities

3. After selecting New to create a new user defined entity, the screen appears as in the next
figure. Enter the name and description of the user defined entity. The entity may be associated
with existing elements in the architecture. Next, select the Class, Type, and Kind of entity
that is being defined. You may notice that when selecting New, the elements tab switches to
the All Elements tab. The reason that the user cannot switch back to the Related Elements
tab is that there is a change to the related elements that is pending. This change must be applied
before the other tab can be selected. Both tabs are again available when the change is Applied,
i.e., the new entity is saved.

Figure 116. Entering New User Defined Entity

4. Finally, click Apply to create the new user defined entity, or Cancel to cancel the entity
creation. Note the Cancel button switches back to Close (see the next figure).
Figure 117. User Defined Entity Change Applied

5. Click Close to exit from the window, or New or Delete to continue creating or deleting user
defined entities.
6. The Entity Kind buttons on the User Defined Entities window may need some explaining:
When creating a new user defined entity, the Entity Kind is set to User Defined and cannot
be changed.
After converting a Turbo file from a previous release version, certain entities (subsystems and
terminators) in the National ITS Architecture may have been discontinued between versions
of the architecture. These are represented as Discontinued. A user can choose to modify a
discontinued entity. The result is a User Defined entity (the Entity Kind switches from
Discontinued to User Defined when the entity is modified). The entity CANNOT be
changed back to Discontinued. The additional category for user defined flows, National
ITS Architecture (described in the next section), does not appear on the User Defined
Entities window.
All discontinued entities from the conversion that the user wishes to keep are also loaded into
the User Defined Entities window. This gives the user a convenient way to review and
manage all extended entities using the same tool that is used for user defined entities.
7. The Type and Class buttons can be used to help define the new entity. Entities can be
defined by class as Center, Field, Vehicle, or Traveler to indicate where the entity might be found
in the physical world. The entities can also be categorized by Type, such as System, Human,
and Environment to indicate the type of element this is in terms of whether it involves some sort
of electronics, a human operator, or the environment with which the sensors and equipment
interacts. These can then be used when filtering is used to decide which elements to display or
hide in the diagrams and reports. More on filters can be found in section 4.4.1
8. Once the entity is created use the Tools => Add Flows feature described in the next section to
define architecture flows to characterize how that new entity can interact with other entities in the
ITS architecture.
9. Then use the Inventory tab to make additional mappings between elements and the new user
defined entity.
10. Go to the Interface tab and Build the architecture to add the new user defined entity and its
associated elements and architecture flows to the architecture. If no new flows have been
mapped to this user defined entity, nothing will appear in the Build step to be added to the
architecture (or to the Interfaces tab).
11. Use the Connect and Flows views of the Interfaces tab to modify (select or deselect)
interconnections and architecture flows for the new user defined entity.
4.3.1.2 User Defined Flows

The following describes how to add user defined flows that can be used to create customized interfaces
between entities that are already in the National ITS Architecture. User Defined Flows can also be
created to define the interfaces between user defined entities and national entities. Extending the
architecture to add a user defined flow requires that the user enter the flow name and description as well
as the directionality between subsystems, terminators, and user defined entities.
1. On the menubar, select: Tools => Add Flows
2. The User Defined Flows window is used to create, edit, or delete user defined flows. The first
time this screen is displayed for an architecture, there are no existing user defined flows. The
user must define them by selecting the New button. If there are user defined flows already
listed, they may be modified on this window by selecting the flow on the left, and changing the
appropriate information on the right. There is also a Delete option to delete an existing user
defined flow.
3. After selecting New to create a new user defined flow, the screen appears as in the next figure.
Enter the name and description of the user defined flow.

Figure 118. User Defined Flows Window

4. The flow is then assigned Source and Destination entities, either of which may be a subsystem,
terminator, or user defined entity. A user defined flow can connect two user defined entities, a
user defined entity with a National ITS Architecture entity, or two National ITS Architecture
entities. On the Inventory tab, the architecture entities are associated with architecture elements,
so the new user defined flow is indirectly associated with these elements. These are shown later
on the Interfaces screen.
5. The Replaces Flow column is only valid when the user defined flow is between a source and
destination that already have an interface in the architecture. It can be used to provide amore
locally meaningful name to an architecture flow from the National ITS Architecture. For example,
the National ITS Architecture defines an architecture flow from the Maintenance and Construction
Vehicle Subsystem (MCVS) to the Maintenance and Construction Management Subsystem
(MCMS) called maint and constr vehicle operational data. The National ITS Architecture CD-
ROM, the defines this flow as follows:
Data that describes the maintenance and construction activity performed by the vehicle. Operational data
includes materials usage (amount stored and current application rate), operational state of the maintenance
equipment (e.g., blade up/down, spreader pattern), vehicle safety status, and other measures associated
with the operation of a maintenance, construction, or other special purpose vehicle. Operational data may
include basic operational status of the vehicle equipment or a more precise record of the work performed
(e.g., application of crack sealant with precise locations and application characteristics).
There may be a particular project in a region that only wants to focus on instrumenting their
vehicle fleet for better snow removal operations. They could use this feature of Turbo to create a
user defined flow from MCVS to MCMS called plow status and have it replace flow maint and
constr vehicle operational data as shown in the next figure:

Figure 119. User Defined Flows Window Replacing Existing Flow Name
6. The user defined flow may then be associated with all architectures in the database file or with
just one or more architectures for instance it may only be applicable within the context of a
particular project.
7. The Flow Kind attributes may be one of three values:
When creating a new user defined flow, the Flow Kind is set to User Defined and cannot be
changed.
After converting a Turbo file from a previous version, certain flows in the National ITS
Architecture may have been discontinued between versions of the architecture. These are
represented by a Flow Kind called Discontinued, or discontinued flows. A user can choose
to modify a discontinued flow. The result is a User Defined flow (the Flow Kind switches
from Discontinued to User Defined when the flow is modified, and hitting Apply). The
flow CANNOT be changed back to Discontinued or to National ITS Architecture, but the
change may be Canceled if it has not yet been Applied. All discontinued flows from the
conversion that the user wishes to keep are also loaded onto the User Defined Flows
window to give the user a convenient way to review and manage all extended flows using the
same tool that is used for user defined flows. The Build logic will ignore Discontinued
flows and National ITS Architecture information on the User Defined Flows window. Only
user defined flows will be added to the Interfaces tab when the user builds the architecture
following conversion. Not planned unsupported flows will be removed from the Interfaces
tab list during a Build (discontinued entities and flows will not be removed). We do not want
to propagate discontinued flows or non-standard applications of National ITS Architecture
flows on the Interfaces tab.
In certain rare cases, a user may see National ITS Architecture when a user defined entity
or flow in an older architecture now has the exact same name as a new National ITS
Architecture flow or entity. During the conversion, the user defined flow with the duplicate
name is converted to the National ITS Architecture flow as long as the user defined flow is
associated with the same source/destination entity pair as in the current version of the
National ITS Architecture. When this is not the case, the users source/destination
information is retained on the User Defined Flows window. When a National ITS

Architecture flow is selected on the User Defined Flows window, the user cannot convert
the flow to User Defined or alter any other attributes. The Delete button changes to
Remove. When a user removes a flow, the flow is only removed from the User Defined
Flows window, the national flow is still defined in the database and still included on the
Interfaces tab unless the user specifically tailors the flow out. In contrast, when a user
deletes a User Defined or Discontinued flow, it is completely removed from the database.
One way to resolve these identically named flows after the conversion is to simply recreate
the flow in the converted architecture using a different name, on the User Defined Flows
window then remove the original flow. If an old user defined flow name matches a new
National ITS Architecture flow name, the user defined entity connection is maintained and the
user defined flow is labeled with Flow Kind = National ITS Architecture. If the old user
defined entity became a new subsystem or terminator in the new version of the National ITS
Architecture, the user defined entity connection is also maintained and the user defined flow
is labeled with Flow Kind = National ITS Architecture. If the old user defined entity name
matches a new National ITS Architecture entity (subsystem or terminator) name, but old user
defined flow name does not, then it will still be labeled as User Defined.
8. Click Apply to create the new user defined flow, or Cancel. Then, click Close to exit from the
window, or New or Delete to continue creating or deleting user defined flows.
9. Build the architecture using the Build option on the Interfaces tab to add the new user defined
flow and its source and destination elements to the architecture and to the Interfaces tab. The
new user defined flow will appear with the status of the elements to which it is connected. If the
user defined flow appears as not planned, then one or both of the elements to which it is
connected may be associated with a market package that is not planned. A Conservative
Build may also result in the user defined flow being not planned.
Figure 120. Build Step with User Defined Flows

10. Visit the Interfaces tab to review/modify the connections around the new user defined flow. Use
the Flows view of the Interfaces tab to select or deselect the new user defined flows associated
with source and destination elements (indirectly mapped to a new user defined entity).
4.3.1.3 Connecting User Defined Entities to the Architecture

There are several was to add a user defined entity to the Regional or Project Architecture (for example, a
flood monitoring element, or snowplows and maintenance vehicles). First, look at the Inventory tab to
display a list of all existing subsystems and terminators in the architecture. This list also includes user
defined entities that the user has already created. Pick a name not on the list to call the new user defined
entity. Then, define this entity in one of several ways:
If some of the data elements for the new system element exist in the National ITS Architecture,
the user may connect to these subsystems, terminators, and architecture flows for this capability
from the National ITS Architecture. Do a Build in order for the new user defined entities and
flows to appear during the customization step. This allows for reuse of National ITS Architecture
flows. The user may also add additional user defined entities and flows that are not in the
National ITS Architecture during this step.

The user may add a market package, then select certain flows that apply to the new capability,
and add the additional user defined entities and flows that are not in the National ITS
Architecture. Do a Build in order for the new user defined entities and flows to appear on the
Interfaces tab. The tool allows a user defined flow to connect to a National ITS Architecture
subsystem or terminator. However, a National ITS Architecture flow cannot be used in a way that
is inconsistent with the Architecture.
If there are no flows within the National ITS Architecture that match the requirements of the
region or project, the user may add the user defined entities and flows, then Build and
Customize on the Interfaces tab.
It is the user's responsibility to ensure that new locally defined entities (similar to National ITS Architecture
subsystems and terminators) and user defined flows (similar to National ITS Architecture flows) do not
conflict with the existing National ITS Architecture subsystems, terminators, and architecture flows.
4.3.2 Synchronize Elements

The Synchronize Elements tool is used to match up the functional area/requirements and market package
mappings between an inventory parent element and any element instances. The Inventory tab where
element instances are created included an option for the new instance to inherit the attributes of the
parent but that was only the attributes that are available on the Inventory tab. This window is access by
selected Tools => Synchronize Elements from the menu bar as shown below:
Figure 121. Synchronize Elements Window

The user selects the elements to be synchronized: a Parent on the left side and an Element Instance
using the pull-down list on the right. The user can then decide which direction to synchronize the
information with the radio buttons on the bottom-left of the window: either to copy from the instance up to
the parent or the other way around, to copy the parents attributes down to the instance. The user can
also decide if these changes should apply to just the current architecture or to all architectures in the file.
Once the user has made their selections of what to synchronize and selects Continue, Turbo will look at
the following areas to see what, if any, changes are needed: Entity mappings, Functional areas,
Requirements, and Market Packages.
At each step if there are changes to be made, as shown below for Functional Areas, Turbo will show the
user what changes are recommended ask the user whether to make the changes.

Figure 122. Synchronize Elements Functional Areas Dialog

If the user selects Yes Turbo will confirm that the changes were incorporated, as shown below, and
given an opportunity to continue to the next area of synchronization or to close the operation and return to
the Synchronize Elements window.
Figure 123. Synchronize Elements Functional Areas Incorporated

Once Turbo has completed synchronizing the functional areas, requirements, and market package
mappings it will return to the original Synchronize Elements window where another pair can be selected
or select Close to return to the main Turbo screens.
4.3.3 Add/Modify/Delete Local Status Values

This option provides additional status options beyond Existing and Planned that can be assigned by
the user to elements, market packages, roles and responsibilities, requirements, project architectures,
architecture flows, and agreements. Many combinations of status options are possible (Legacy, Existing,
Programmed, Future, Not Planned for example). The user will be allowed to change the status values to
meet local needs. The status names will be used on reports, diagrams, and on the Interfaces tab.
The user might also opt to use user defined status values to support project sequencing (e.g., create
values of Near-Term, Mid-Term, and Long-Term and then assign these status values only to projects).
The window to add, modify, or delete a status value follows. Bring up this Turbo feature via the Tools =>
Update Status pulldown menu. This option allows a region to define up to 8 local status values in near
to long term order that will be available when creating or modifying an architecture component. Status
values are global to all architectures in the file, so the list will be available when working with any of the
regional or project architectures.

Figure 124. Local Status Value Add/Modify/Delete

The initial status values that come with Turbo Architecture are existing, planned (default), and not
planned. The names and descriptions of these values may be changed, but not planned must remain
last even if its name has been changed (the tool will not let this value be reordered). There is a maximum
of 25 characters per name due to space limitations on diagrams and reports.
Status values other than not planned may be reordered (sorted) by selecting the value then clicking on
the re-order up or down arrow on the left. If the top value is selected, only the down arrow is active. If a
middle value is selected, up and down arrows are active. If the last value is selected (even if it has been
renamed from not planned), then no arrows are active. Turbo uses the status value order to determine
overall status in situations where more than one status value applies, determining interconnect status and
the initial architecture flow status during a build.
The default status value may also be changed by checking or unchecking the Make this the default
Status value checkbox on the right. This will be the default status value assigned to inventory elements
and market packages. Only one default value is allowed. Planned is the default status value delivered
with Turbo, but this may be changed. Not planned may not be the default status value.
There are four buttons on this window:
New Create a new local status name. If there are already 8 values listed, this is disabled.
Delete Delete a status value name. If this has been assigned to an architecture component,
then a window will popup telling the user how many items have been assigned to it, and that he
must reassign them before being able to delete this status value.
Apply Save the changes made to the selected status value.
Cancel Cancel the action. This option toggles with Close when no actions are pending.
To create a new status value, select New. Enter the name and optional description of the new status
value on the right-hand side of this screen, select the default checkbox if applicable, then click Apply.
If you wish to cancel this change, select the Cancel button. NOTE that the description field is not listed
in any Turbo report.
To delete an existing status value, select the name of the status value from the list on the left, then click
Delete. If this status value has been assigned to any architecture items Turbo will reassign them to the
next nearer-term status value. A separate window will be shown if the user tried to delete the default
status value, saying that another status value must be made the default before deleting this one.
To modify an existing status value, select the name on the left, then enter the new name or (modify the)
description on the right. The default status may also be changed.

Figure 125. Consolidate Local Status Values

In the example above, the user had been adding status values and then changed one of them to Future.
Turbo sees that Future is already used and asks the user if the two status values should be
consolidated. If the user answers Yes, the Programmed-FY2012+ status will be removed and all
architecture components that have that status will be changed to Future. If the user says No, Turbo
will inform the user that the name is already in use and sends the user back to the Status window to pick
a different name. When the user edits status values on the Status window, modifications, additions, or
deletions that are made on this window Applied, are immediately reflected in the status list box on the
Inventory tab (and all other tabs and windows where available).
4.3.4 Check Request Flows

Selecting Tools => Check Request Flows from the menubar identifies inconsistencies between
request and information flows in the current architecture. There are two possible views of this data.
Request flows can usually be associated with a particular information flow. This capability will allow the
user to view a list of inconsistencies between request flows and information flows that are included in an
architecture and allow Turbo to automatically reconcile the request flows and information flows to remove
identified discrepancies. This tool will possibly save 20% of the time that is normally spent on the
Interfaces tab selecting and customizing architecture flows.
On the Request Flows tab:
The Include and Include All options will add request flows to the current architecture that are
necessary to support the included information flows.
The Remove and Remove All options will remove request flows that are included in the current
architecture but are not required to support information flows.
On the Information Flows tab, just the opposite happens:
The Include and Include All options will add information flows to the current architecture that
are related to the included request flows.
The Remove and Remove All options will remove information flows that are included in the
current architecture but are not required to support request flows.
The Close button exits from this window.
The figure below is an example of the Request Flows tab portion of the Check Request Flows screen
followed by an example of the Information Flows tab.

Figure 126. Check Request Flows Window Request Flows Tab
Figure 127. Check Request Flows Information Flows Tab

4.4 Output Menu

Once you have customized your architecture the development process is really complete. However, it is
important to create outputs that represent the architecture and can serve as vehicles for transferring
information to the stakeholders. The Output pulldown menu allows creation of a wide range of reports,
diagrams, and even web pages pertaining to the architecture created.
Figure 128. Output Menu

The user will be able to print diagrams and reports for a completed or partially defined architecture. The
contents of certain reports may be customize based on the settings described in this section. The
diagrams will include different line styles and highlighting to represent various communications methods,
selected architecture elements, or the status of architecture elements and interfaces. The specific tabular
reports, diagrams, and web pages available are discussed later in this section.
4.4.1 Data Filtering

The user may choose to filter the data that is output on the Interconnect and Architecture Flow
Diagrams, certain reports, the Interfaces tab, and the Standards tab. These data filters will limit the types
of interfaces to be considered, and should be used for large reports and diagrams. The filtered data will
not appear on the diagrams or reports, but is still included in the architecture. The filters may include
such types of data as human interfaces, acknowledgment or request flows, futuristic flows, etc. When the
filters are applied, this data will be filtered out of the diagrams and certain reports.
The filters are identical for reports, diagrams, and the Interfaces and Standards tabs. The filters are
available to the user in several ways. On the menubar, select Output => Filtering. On certain output
reports and diagram windows, and on the tabs, there is a Filters button that provides an alternative way
to access the same window.
There are four types of filtering: Entities, Interconnects, Flows, and Market Packages, and a fifth
tab, Summary, that indicates if any of the filters are selected. The Summary tab is the first tab that the
user sees on the Filters window. Clicking an On/Off field displays the related filter tab. The following
figures illustrate the Summary tab, and the other tabs across the filtering window.

Figure 129. Filters Window Summary Tab

The Entities tab shown in the next figure sets filters that control the elements displayed in reports,
diagrams, and on the Interfaces tab. Class indicates subsystems and Type indicates terminators.
Figure 130. Filtering Entities

The Interconnects tab shown in the next figure sets filters that control the types of interconnects that are
displayed, based on interface type (center to center, center to field, field to vehicle, etc.). All
interconnects are initially selected by default. NOTE that a few of the Traveler interconnects are non-
intuitive, but they do exist in the National ITS Architecture. Traveler to Field includes the Traveler Card to
Parking Management Subsystem (PMS) interface, Traveler to Traveler includes the Traveler Card to
RTS/PIAS interface, and Traveler to Vehicle includes the Traveler Card to Vehicle Subsystem interface.
A few human and physical/environmental interfaces also fall into these categories. In many cases, these
three interconnects will not exist in the Regional or Project Architecture, but if they do, the operator needs
a way to turn them off/on.

Figure 131. Filtering Interconnects

The Flows tab shown in the next figure sets filters that control the architecture flows displayed in reports,
diagrams, and on the Interfaces tab. Deployment status (including user defined status values) and type
of flow may be selected. When no status filter is selected, Turbo includes flows that have not planned
deployment status on the Interfaces tab but not on the reports or diagrams.
Figure 132. Filtering Flows

The Show Futuristic Flows box is normally unchecked so that output reports and diagrams are not
cluttered with flows that are not likely to be implemented for many years. The National ITS Architecture
upon which Turbo is based flags some of the flows as futuristic meaning that it may be a long time
before technology is such that this flow can be implemented.
The Market Packages tab shown in the next figure sets a filter that limits reports, diagrams, and the
Interfaces tab, to a single market package or market package instance, or all market packages may be
displayed (this is the default). This filter creates a market package view of the architecture showing only
the interconnects or flows that are associated with a particular market package on reports, diagrams, and

the Interfaces tab. If the user has created market package instances, then the market package view
allows the user to show only the interfaces associated with a particular market package instance. Market
Package instances are sorted immediately under the associated National ITS Architecture market
package. Developers who use market packages as an entry point to architecture development will
benefit from this view of the architecture since it facilitates tailoring of a particular service area within a
Regional or Project architecture.
Figure 133. Filtering Market Packages

The Filters window may be displayed in a variety of ways, from the Output menubar pulldown, the
Diagrams and Reports windows, and by using the right mouse button on the Filter option on the
Interfaces and Standards tabs. These methods result in the same filters being applied to the reports or
diagrams and on the Interfaces tab. A change to a filter in one place also changes it in the other
windows.
In the above Filtering windows, checking the box will result in the entities, flows, or interconnects being
selected. If the box is not checked, the items of that type will not be shown. Both Apply and OK save
the user filter settings. Apply leaves the window open; OK closes the window. Cancel allows the
user to cancel out of the window without committing any filter changes to the database.
Where multiple filters apply to a single entity or flow, the software will filter pessimistically. That is, if any
filter that the user has selected (by leaving the box unchecked) applies to an entity or flow, then this entity
or flow will not be shown on the tabs, or not appear on a report or diagram. NOTE that this may occur
when filtering all flows except futuristic flows. Futuristic flows may also be filtered since each flow
includes one or more attributes that were being filtered. This may result in zero flows being displayed on
the tabs, reports, and diagrams.
If the cursor is placed over the type of filter, a sentence is displayed with an explanation of the filter type.
This only applies to the tabs, not to the classes, types, or deployments listed.
4.4.2 Element Selection

To control the number of elements displayed on the diagrams, set the element selection for a diagram
(see the next figure).
The element selections are identical for reports, diagrams, and the Interfaces tab. This option is
available to the user in a variety of ways. On the menubar, select Output => Element Selection. On
certain output reports and diagram windows, and on the Interfaces tab, there is an Elements button that
provides this option.

Figure 134. Element Selection Window

The elements and their interconnections that appear on the Interconnect and Flow Diagrams may be
customized in the following manner:
1. To see all elements and all connections between them in the entire architecture, make sure all
element boxes are checked on the Output => Element Selection window. The Select All
option on this window may be used to easily select all elements. Select OK when finished then
select Preview on the diagrams window to view the output.
2. To see only the connections between selected elements, select the Elements button on the
diagrams window then make the appropriate element choices. If many elements need to be
removed from the list, the Clear All option is available. Then select the required elements.
Select OK when finished then select Preview on the diagrams window to view the output. For
instance, using the Marinara County example, to produce a diagram showing just the flows that
go between the Freeway Management Center and the Fire & Rescue Center, then
a. Open the Element Selection window.
b. Select Clear All.
c. Select MCDOT Freeway Management System (BASIL and PINCH) and Saucelito Fire and
Rescue Center.
d. Select OK.
e. From the Diagrams window, select Preview.

MCDOT and State Highway Patrol

Marinara County Freeway
PINCH)
incident response status

remote surveillance control
resource request
resource deployment status
road network conditions
traffic images
incident information
Saucelito Fire Department

Saucelito Fire and Rescue Center
Existing
Planned
Figure 135. Flow Diagram between Two Selected Elements

3. When working with a Project Architecture, the Project Elements option is available. This will
show only the elements that are in the project inventory when a particular project architecture is
selected. For large architectures, it is difficult to tailor project unique elements when all elements
are listed. This option applies to reports, diagrams, and the Interfaces tab. This is not a toggle.
If many elements have already been selected for a diagram or report, be careful not to select the
Project Elements option, because it is not possible to return to the previous list except by using
the Select/Clear All buttons and selecting the required elements.
4. To see all connections in and out of certain selected element(s), as well as the elements that they
are connected to, use the Show All option on the Elements Selection window. Then, select
the desired elements. Preview the diagram. If you are only interested in viewing the
connections between selected elements, turn off the Show All option. If Show All is selected,
all flows associated with the selected elements are included, even if the flows begin or end at an
element that is not selected. This option applies to reports, diagrams, and the Interfaces tab.
Examples of the Show All option:
a. You select one element and Show All. The diagram will display all connections to and from
this element. These are sometimes called Context Diagrams and can be very useful to
show an individual stakeholder how their systems relate to the region. If you turn off Show
All, a popup appears saying that the diagram is blank nothing is displayed.
b. If you select two or more elements and Show All, the diagram will display all connections
between these elements and to and from these elements to other elements in the
architecture. If you turn off Show All, only the connections between the selected elements
are displayed.
5. To see Communications type elements added to an architecture select the Show
Communications Elements checkbox and notice how the screen changes as shown in the next

figure. New rows are added to include the communications elements and a new column is added
to distinguish between the Transportation type elements and the Communications type elements.
Figure 136. Element Selection Window with Communications Elements
NOTE that the Element Selection window will always reflect element names that have been changed on
the Inventory tab, even if the window has not been closed while element names were changed. The
Element Selection window may simply be minimized, then brought back up to refresh the list.

4.4.3 Diagrams
As shown in the figure below, once the user selects Output => Diagrams from the menubar, a main
diagram dialog menu is displayed to the user. From this window, the user can select the type of diagram
to be displayed or printed, the filters to use, the elements to include, the settings to use, and the
resolution to use in saving the images. There is then a button to Preview the diagram and a button to
generate multiple diagrams in a batch process.
Figure 137. Diagrams Window
4.4.3.1 List of Diagrams

There are three types of diagrams that may be displayed or printed by Turbo Architecture:
1. Subsystem Diagram The Subsystem (Communications) Diagram for a region or project illustrates
the methods that are used to communicate between the subsystems selected for that region or
project. These include fixed-point to fixed-point, wide area wireless (mobile), field-vehicle, and
vehicle-to-vehicle communications. Only the National ITS Architecture subsystems and
communications methods appear on this diagram. Terminators do not appear.
2. Interconnect Diagram The Interconnect Diagram for a region or project illustrates the
interconnections between element/stakeholder pairs selected for that region or project. This diagram
captures the physical entity interfaces with a single direction-less line.
3. Flow Diagram The Architecture Flow Diagram for the region or project illustrates the flow of data
between the element/stakeholder pairs selected for the region or project. The flow of data appears as
physical architecture flows (one or many) connecting the elements to each other. The direction of the
flow of data also appears between the architecture flows and the other physical entities.
Three different types of diagrams are available for the Interconnect and Flow diagrams:
Full Architecture Flow or Interconnect Diagram for the region or project.
An Architecture Flow or Interconnect Diagram that illustrates the connections surrounding a
single element/stakeholder, also known as a Context Diagram.
An Architecture Flow or Interconnect Diagram that illustrates the connections between multiple
element/stakeholder pairs.
4.4.3.2 Diagram Preview Options

The Interconnect and Flow diagrams include a feature to display or print a subset of the architecture,
either the interfaces to a single element, or to multiple elements. Displaying thousands of connections
may cause problems, both in the generation of the connections and in the display. The diagrams may be
displayed by selecting Output => Diagrams => <diagram name> => Preview from the menubar.

The various options on the Preview diagram windows include:

1. The diagrams being Previewed (Subsystem, Interconnect, and Flow) may be saved to a file
by selecting File => Save. A popup window asks for the directory and file name where you want
to place the diagram. The file will be saved in EMF (Enhanced Metafile) format, and may be
input to any tool that reads this format (Visio, PowerPoint, etc.). For instance, after saving the
Subsystem Diagram to a file, the diagram may be imported to a graphics editing tool to add
stakeholder names. The user may then wish to add textual comments to the diagram. This may
be done in the saved versions of these diagrams. See Section 0 for a discussion of managing
the image resolution for the saved diagram files.
2. After saving the Interconnect or Flow diagrams to a file, they may be opened from this file in
Turbo Architecture by selecting File => Open on the Preview diagram menubar.
3. The display of the Interconnect and Flow diagrams may be zoomed in or out by using the
Zoom option on the menubar of the Preview diagram windows.
4. The diagrams may be printed to a connected printer by using the Start => Settings => Printers
option to select or set up the printer on your machine. To print the diagram, select File => Print
from any Preview diagram window. The diagram may also be sent to a plotter by choosing a
plotter instead of a printer connected to your workstation.
5. The Preview diagrams may be closed by using the File => Close option on these windows, or
by selecting the x in the upper right-hand corner of the display window.
For information on managing a very large diagram, see Section 6.10.
4.4.3.3 Information in Diagram Element Boxes

The boxes on the Interconnect and Flow diagrams contain the element and stakeholder names. For
Interconnect diagrams, the lines are codified (e.g., solid/dashed and different colors) to distinguish
between the status values of the interconnections. Where an interconnect supports architecture flows
with different status values, the interconnect is identified as the status value that is nearer term (see
Section 4.3.2 for a discussion of creating local status values). Architecture Flow diagrams include
directed architecture flows and are also codified to distinguish between different status values.
A NOTE on the placement of boxes on the Interconnect and Flow diagrams: The diagram layout
algorithm positions the most connected block in the middle and then positions blocks in decreasing
numbers of connections, spiraling outward. This algorithm reduces the number of crossed flows that
would be plotted with an alphabetical order or other ordered diagram layout algorithm.
On the Subsystem Diagram, as shown in the next figure, the user may click on a subsystem and see a
list of all related elements for this subsystem in the region or project. The following diagram includes
related elements for the Parking Management subsystem.

Figure 138. Subsystem Diagram Show Related Elements

The next figure is an example representation of an Architecture Interconnect Diagram pertaining to a
Project Architecture. Your actual output for this type of diagram will, of course, be a function of your
architecture.

Marinara County Department of Tran... Bus Operations Center City Operations Center
TOMATO Event Parking System
GARLIC Information System Marinara County Department of Tran... Marinara County Freeway Saucelito Fire and Rescue Center
TOMATO Regional Traveler Management Center (BASIL and
Information PINCH)
County Traveler Kiosk Network Traffic Channel 72 on cable Planning Data Warehouse
Internet PC Access via the WWW TOMATO Advertisers
Planned
Figure 139. Example Interconnect Diagram

The next figure is an example representation of an Architecture Flow Diagram pertaining to a Project
Architecture. Your actual output for this type of diagram will, of course, be a function of your architecture.

Internet PC Access via the WWW County Traveler Kiosk Network Marinara County Department of Tran...
TOMATO Event Parking System
interactive traveler information

trip plan
traveler profile
traveler request
trip confirmation
trip request
yellow pages request
interactive traveler information
trip plan
traveler request
trip confirmation
trip request
yellow pages request
parking lot data request
parking information
parking information
parking information
Bus Operations Center Marinara County Department of Tran... Planning Data Warehouse TOMATO Advertisers
TOMATO Regional Traveler
Information
transit information request

transit and fare schedules
transit incident information
traveler archive data
archive requests
archive status
travel service information request
travel service reservation request
incident information
road closure information
City Operations Center GARLIC Information System Saucelito Fire and Rescue Center
traveler information for media
Traffic Channel 72 on cable Marinara County Freeway

PINCH)
Existing
Planned
Figure 140. Example Flow Diagram

The next figure is an example representation of an Architecture Flow Diagram pertaining to a Regional
Architecture in which the user has used the Element Selection window to show all interfaces for the
Communications Hub. Your actual output for this type of diagram will, of course, be a function of your
architecture and settings.

Alfredo County Freeway Management MCDOT and State Highway Patrol

Center Marinara County Freeway
PINCH)
flood monitoring system status

traffic information coordination
traffic information coordination
Marinara County Department of Publi...

Marinara County Flood Monitoring CANOLI Communications Hub
System
flood monitoring system status
Planned
Figure 141. Example Flow Diagram with Communications Hub Selected.
4.4.3.4 Diagram Settings

The user may customize the information presented on the Interconnect and Flow diagrams.
Information may be filtered or specific elements selected for the diagrams for the Regional or Project
Architecture. The filters are the same for the Interfaces tab, diagrams, and reports. The shape and color
of the diagram boxes and the line style and color may be changed via the Diagram Settings option. The
Subsystem Diagram may not be customized. For the shapes and lines in the Interconnect and Flow
diagrams, a user may change the appearance of element boxes and the lines representing the status
values.

Figure 142. Diagram Settings Window Shapes

To change the shape of an element box in either the Interconnect or Flow diagram:
1. Select the type of diagram: Interconnect or Flow on the Diagrams window.
2. Select the Settings option.
3. When changes are made to the right-hand side attributes for a shape, they are immediately
displayed in the shapes on the left but are not saved until Apply or OK is selected.
4. On the Shapes tab, the default for Transportation elements with defined functions (see Section
3.6 for a discussion of the Requirements tab) is a rectangle with blue title bar while the default for
Transportation elements with no defined functions is a rounded yellow rectangle with rounded
corners. These can be changed by clicking the radio button for the box on the left and select
from the Shape Style list box on the right. The only supported shape for Communications
elements is a rectangular shape with rounded ends (sausage).
5. The Stakeholder Title checkbox is checked by default for Transportation Elements with defined
functions. If the stakeholder name is not required at the top of the element boxes in the
diagrams, uncheck this box. However, it will then not be possible to recognize the stakeholder
names in the diagrams. When this option is disabled, the stakeholder title bar disappears from
the box on the left and the title frame on the right is disabled.
6. The colors selected for the background and text of the Title and Body of the element boxes in
the diagrams may be changed. Click on the color box and change the color from the palette that
appears. These colors may be changed separately for elements with and without defined
functions as well as communications elements. Select each box on the left and change the
colors on the right.
7. Click OK or Apply to accept the change, or Cancel to abort the change. NOTE that you may
make changes to both shapes and lines before selecting Apply. Close toggles to Cancel
once editing begins.

Figure 143. Diagram Settings Window Lines

To change the line style between element boxes in either the Interconnect or Flow diagram:
1. Select the type of diagram: Interconnect or Flow on the Diagrams window.
2. Select the Settings option.
3. When changes are made to the right-hand side attributes for a line, they are immediately
displayed in the line styles on the left but are not saved until Apply or OK is selected.
4. On the Lines tab, the status values are on the left with a default line style and color on the right.
5. To change a line style or color:
a. Select the status value via the radio buttons on the left (Existing, Planned, or a local status
value created via the Tools => Update Status option on the menubar). Each status value is
represented by a different line style and will be displayed in the diagram legend.
b. Select a line style from the list box pulldown menu on the right.
c. Click on the Line Color box on the right and select a color from the color palette.
6. Click OK or Apply to accept the change, or Cancel to abort the change.
4.4.3.5 Diagrams in Batch Mode

The Batch feature of the Diagrams window, shown below, allows the user to generate many diagrams
with a single command. For example, all interface diagrams or context diagrams for every element may
be printed at once in batch mode or saved based on user specified parameters.
Figure 144. Diagram Batch Processing Print Mode

Figure 145. Diagram Batch Processing Save Mode

To batch generate several Interconnect or Flow diagrams:
1. Select the type of diagram to be batch generated: Interconnect or Flow.
2. Select Filters, Elements, and/or Settings to filter the printed or saved diagrams.
3. Select the Batch option.
4. Click the Elements button to select the inventory elements to be included in the diagrams. See
Section 4.4.2 for a description of this option. These will be the elements that define the context or
interface diagrams to be printed (e.g., how many diagrams will be generated). If all elements are
selected, then there will be a diagram printed for each.
a. For context diagrams, one diagram will be generated for each selected element in the current
architecture.
b. For interface diagrams, one interface diagram will be generated for each interface (element
pair) in the current architecture for each selected element.
5. Specify the type of diagrams to be batch generated.
a. Context Diagrams show the interfaces between one element and all other elements.
b. Interface Diagrams show the interface between a single pair of elements.
c. Market Package Diagrams show the interfaces related to each Market Package or Market
Package Instance.
6. The Status field at the bottom left of the Batch Processing window presents the overall status
of the batch operation.
7. Select Print to print the diagrams. The Batch Processing window is initially presented in its
simplest configuration, for batch printing.
a. Select the Print All option.
b. The Print option will display a Print dialog box listing available printers and on user
command initiate batch printing of all diagrams of the selected type.
c. Select Cancel to abort the batch printing.
8. Select Save to save the diagrams to a file.
a. The Save option allows the user to select (browse for) a directory where the diagrams are to
be stored. The initial default is the Turbo application directory.

b. A Short or Long name style may be selected for the file names of the saved files, or a
Prefix to the long or short names may be entered so that they may be found easily and
distinguished from other file names in the directory.
c. The short names are typically a number (element ids), while the long names represent the
inventory element names in the architecture.
d. All name styles identify whether the file contains a context or interface diagram.
e. The Diagram Size is a user selectable list of sizes of the saved diagrams, discussed further
in the next section.
f. Select the Save All option.
g. The files can be saved in a number of formats including Enhanced Metafile (emf), Graphical
Interchange Format (gif), Joint Photographic Experts Group (jpg), Portable Network Graphics
(png), Tag Image File Format (tif), and Windows Bitmap (bmp).
h. Select Cancel to abort the batch saving.
9. Close closes the Diagram Batch Processing window.
TIP for a large architecture with lots of diagrams create a new folder to store them all in one place. Do
that outside of Turbo before initiating the Batch Diagram operation and then select that Folder under Save
Options.
4.4.3.6 Saved Diagram Size

Before previewing a diagram, the Saved Diagram Size pulldown list is available on the Diagrams
window to improve the legibility of saved Interconnect and Flow diagrams. More complex diagrams
are generated as a proportionally larger size by default. This option provides diagrams that are legible
without scaling, a feature that is most important in scenarios where many diagrams of varying complexity
must be generated.
The user may select from fixed output sizes based on a set number of pixels (computer graphics dots):
600x450, 800x600, 1024x768, 1280x1024. These are suitable for applications where the file is going to
be imported into an application and you need to know the size that the graphic will be. This may not be
suitable for large complex diagrams. Use the scaled output sizes, Small, Medium, Large, to produce
drawings that will increase as needed to fit all of the material, which may be better suited for printing large
drawings on a plotter.

4.4.4 Reports
4.4.4.1 General Information about Reports

As shown below, once the user selects Output => Reports from the main menu, a main report dialog
menu is displayed to the user. From this dialog, one of the available Turbo Architecture reports can be
selected. This window will remain available until the user closes it when finished displaying the reports.
Figure 146. Reports Window

The above figure illustrates the interface for the main Reports Dialog. The dialog box allows the user to
select a report, presents a description of the report in the list box, and allows the selected report to be
tailored using filters and settings, and then previewed. The settings for each report are listed on the right.
The Filters and Elements buttons are selectively enabled only for reports that have these capabilities.
The filters and element selection windows are the same as for the diagrams and the Interfaces tab. The
settings are different for each report, and are explained below in the list of reports. All reports have a
setting where the user may change the report title. For some reports, this is the only setting.
Tabular reports for a Regional or Project Architecture include regional relationships between projects and
summary information pertaining to the regions elements, subsystems, terminators, and architecture
flows. In addition, there are reports that are identical to two of the conversion reports.
Once previewed, the report can be saved or printed. To save a report from the Preview report display
window, use the Export icon (the arrow into envelope) at the top of the window. This option allows
export into many types of formats, such as RTF, Excel, Word for Windows document, or a Paginated
Text file. For a very long report, saving it to a file and using another editor may be preferable to trying to
page through the report while in Turbo Architecture.

There is also an option to save the underlying recordset of the report, which is used to build the report.
This option is provided when the user selects a report and then selects the Save Recordset option on
the report dialog box. This option pops up a window similar to the File => Save As window where the
user will enter the pathname and filename where the recordset will be placed. The report is then written
to a comma-delimited text file that may be input to another tool, such as Excel, and reviewed later. The
text file includes ALL fields in the report, including those that may have been omitted by the settings on
the Reports Dialog window, such as description fields.
NOTE that if a paragraph of text was copied (cut and pasted) from a note, text file, Word document, or the
like, into a description field (architecture, element, stakeholder description), this will create a line feed or
carriage return character at the end of each line. While these extra characters are not visible when
viewing a description field in Turbo, they are not understood when creating a recordset. The resulting text
file, and hence the Excel spreadsheet, may end up with an extra line for every row of text in the file. This
is not what the user intended. These carriage return characters should be deleted from the end of each
line if the description field has been copied in this manner so the recordset will be created correctly.
Four reports may be previewed at a time by selecting each report on the Reports Dialog window, then
the Open option on the Report Preview window to open a new report. (The Report Preview window
options will be described in Section 4.4.4.6.) Each report is displayed via tabs across the Report
Preview window.
Because the Report Preview window is a separate window from the Turbo Main Menu, the Report
Preview window may be hidden behind the Turbo Main Window (if, for instance, you click on the Turbo
Main Window, it will move to the front and hide the Report window that overlaps with it). The Report
Preview window itself is available through the task bar.
The report Preview window is resizable.
The Report Preview window includes the names of the open reports in tabs across the top of the
window. This aids in selecting between several reports that may be open at the same time.
Two copies of the same report type may be displayed with different filter parameters or settings.
The Report Preview window is closed by clicking the x in the top right corner of the window, or
selecting the Exit option. The report window may also be minimized, maximized, or resized on the
screen in the normal way, using the dash and box options in the top right corner of the report window and
the arrows at the edge of the window, respectively.
4.4.4.2 Report Settings

The user may choose to customize the information that is presented on the reports. While the basic
format of each report is fixed, filters and settings are available for certain reports that will limit the data
output on the tabular report generation for the Regional or Project Architecture. These include, for
example, the user selection of subsystems, terminators, and user defined entities and flows, and whether
or not comments applied to an architecture element are to be displayed or printed. The user may also
elect to modify the default title of the report. Once a report is selected and the user is happy with the
various settings and filters, the report can be previewed.
The Filters and Elements options are the same as for the Diagrams window and Interfaces tab. The
Elements Selection window allows the user better control over report content and length. For example,
a standards report could report only the standards associated with a single interface or all interfaces
associated with a single element. If the user enables the element selection filter for reports, inventory
elements will be included in certain Turbo reports only if they are selected on the element selection
window. The Show All Interfaces and Show Communications Elements features on the Element
Selection window also applies to reports if the Elements option is selected.
Settings are available for each report and are listed on the right-hand side of the Reports window.
4.4.4.3 List of Available Reports

Architecture Summary Report listing all projects included in the Regional Architecture, including legacy
systems and other user defined entities. This report presents summary information for all Regional and
Project Architectures that have been defined. This report has settings for displaying the description of

each architecture, displaying elements associated with each project, including entries made in the
Change Log on the Start tab for each architecture, and listing available status values including any local
values that have been created.
Stakeholder Report showing identified stakeholder names, descriptions, and associated elements. If
there is a contact name, it should be included in the description in order to be displayed in the report. The
report includes stakeholder groups. This report has settings for the stakeholder description, listing all
elements associated with the stakeholder, and listing members of a stakeholder group.
Inventory Report presenting all identified inventory elements with associated entities, stakeholders, and
projects, including user defined entities and flows. The Inventory report shows the element inventory for
the selected architecture, either project or regional. If in a Project Architecture, the entire Regional
Architecture inventory does not appear. This report has the following settings:
Sort by element, entity, or stakeholder Sort the report by one of these items inventory element
(default), stakeholder name or group, or National ITS Architecture entity.
Filter by Element Selections If elements have been selected in the Elements selection
option, then this setting toggles to list only those inventory elements selected, or all elements in
the architecture.
Display Element Description A toggle that will turn the description on or off for each inventory
element in the report. The element description will be listed for all elements in the report, even if
the report is for a region and an element has no project association.
Display Element Status A toggle that will turn the status values on or off for each element in
the report.
Display stakeholder or entity Toggles that turn these items on or off in the report.
Display Stakeholder Group Members If a stakeholder group was associated with an inventory
element, its members will be listed if this setting is on.
Display Status Values Legend
Market Packages there are 2 reports describing the Transportation Services included in the regional or
project architecture and their relationship to the Inventory of Elements.
Market Packages Report showing National ITS Architecture market packages and their
selection status related to the initial projects and services. The Market Packages report has
settings for displaying user comments about why a market package was selected or not,
displaying the elements associated with the market package, showing not planned market
packages, and including market package instances. This report will appear differently for
Regional and Project Architectures.
o For a Project Architecture, only the market packages that have been identified for the
project will be listed.
o For the Regional Architecture, all market packages are listed. Some may have a status
of Not Planned, and others will use the status values assigned on the Services tab, with
element associations listed for the market package. The Not Planned market packages
are listed in this report so that the user may determine if the elements and flows for these
services may be required for the architecture at some point in the future. If the user has
entered a comment for a specific market package describing why this service is Not
Planned for the region, this comment will appear in the report.
Inventory to Market Package Comparison Conflict resolution report that compares Inventory
and Market Package selections and identifies possible Inventory and/or Market Package
selection gaps. This report identifies National ITS Architecture entities (and user defined entities)
and inventory elements that are not assigned to any Market Package, and entities and elements
that are not assigned to a Market Package where it is possible to include them. This report has a
setting for including market package instances.
Roles and Responsibilities Report showing the roles and responsibilities, i.e., an operational concept,
based on market package choices defined for the currently selected architecture. The market packages
listed on this report are those associated with the Roles and Responsibilities, not those associated with

the stakeholders listed. This report has settings for sorting by stakeholder name, displaying a description
of the roles and responsibility area, displaying the market packages associated with the area, listing
members of a stakeholder group, and listing available status values.
Functional Requirements Report showing the functional areas and requirements defined for the
currently selected architecture based on the market package choices. The functional areas directly relate
to the Equipment Packages in the National ITS Architecture. This report has settings for displaying a
description of the requirement, displaying the requirements themselves, displaying elements with no
functional areas, and listing available status values.
Interfaces there are 3 reports to show the Interconnects and Architecture flows associated with a
regional or project architecture.
Interconnects Report showing the interconnected elements and their status values for the
interconnects in the current architecture, similar to the Interconnect diagram and the basic
interconnect information provided in the Interfaces tab. The interconnects are non-directional,
e.g., they do not specify the direction that information flows between interconnected elements.
This report will be a tool for systematic development of Regional and Project Architectures. This
report has settings for filtering by elements selected in the Elements Selection window, and
listing available status values.
Regional Architecture Report showing the permutations of subsystem interfaces included and
not included in the architecture, as well as, subsystems, terminators, and architecture flows with
optional designation of project and the elements that exist or are planned for the future. This is a
detailed report of all elements and architecture flows that are included in the Regional
Architecture. This report has the following settings:
o Filter by Element Selections
o Display only the flows in the Regional Architecture Do not include the flows in any
Project Architecture that have not yet been merged into the Regional Architecture.
o Display flow comments Include comments made by the user about a flow, using the
Info button on the Interfaces tab.
o Display Status Values Legend
Project Architecture Report illustrating the mapping of National ITS Architecture subsystems
and architecture flows for the project. The report will list source, architecture flow, and
destination, for the mapping in this table. The report will also show permutations of subsystem
interfaces included and not included in the architecture. This is a detailed report of all elements
and architecture flows that are included in the Project Architecture. This data does not include all
elements and flows in the Regional Architecture. This report has settings for filtering by elements
selected in the Elements Selection window, and listing available status values.
Region to Project Comparison a set of reports to use when analyzing the differences between
architectures within the same file. Conflicts may sometimes arise when a Project Architecture has been
changed and should be reflected in the Regional Architecture. These reports show the differences
between the Regional and Project Architectures. They are not designed to show overlap between the
architecturesonly differences. If a report is empty, then there are no differences between the Regional
and Project Architectures. If there are Project Architectures but no Regional Architecture, or a Regional
Architecture but no projects, then this report will not appear (a message is displayed saying that a
required architecture does not exist).
Compare Inventory Identifies any inventory differences between the regional and project
architectures. The user may include a comparison of Status Values as well.
Compare Services (Market Packages) Identifies any market package differences between the
regional and project architectures. The user may include a comparison of Status Values as well
as element mappings.
Compare Requirements Identifies any requirements differences between the regional and
project architectures. The user may include a comparison of Status Values as well as the
requirement details.

Compare Flows Identifies any interface flow differences between the regional and project
architectures. The user may include a comparison of Status Values.
Compare Standards Identifies any ITS standards differences between the regional and project
architectures. The user may choose to display the flows involved or include the standards that
are in the region but not in a project.
Additional Integration Options there are 2 reports to show the additional interfaces that could be
included in an architecture.
Additional Integration Options Region Report for the Regional Architecture showing the
permutations of subsystem interfaces included and not included in the architecture. This report is
a summary of the integration options identified in the National ITS Architecture that have not been
identified in the Regional Architecture. If a Project Architecture is open and there is no Regional
Architecture in the file, this report is not displayed. If a Project Architecture is open and there is a
Regional Architecture in the file, this report is displayed. This report has settings for filtering by
elements selected in the Elements Selection window, and including comments made by the
user about a flow, using the Info button on the Interfaces tab.
Additional Integration Options Project Report for the Project Architecture showing the
permutations of subsystem interfaces included and not included in the architecture. This report is
a summary of the integration options identified in the National ITS Architecture that have not been
identified in the Project Architecture. If a Project Architecture is open and there is no Regional
Architecture in the file, this report is not displayed. If a Regional Architecture is open and there is
a Project Architecture in the file, this report is displayed. This report has settings for filtering by
elements selected in the Elements Selection window, and including comments made by the
user about a flow, using the Info button on the Interfaces tab.
Standards Activities Report consisting of relationships between ITS Standards activities and applicable
Regional or Project Architecture flows. This report lists all standards activities applicable for the region.
The report includes only National ITS Architecture flows and interfaces used in the Regional and Project
Architectures, not user defined entities and flows added to the architecture to define a local service. The
Standards Activities Report begins with a disclaimer that indicates the initial list of standards provided by
Turbo must be reviewed to determine those standards that are actually suitable for use based on specific
application, development timeframe, and other factors. There are actually two disclaimers, one for
uncustomized lists of standards, and the other for customized lists of standards (from the Standards tab).
Also, the standards group description appears in to the footnote of standards reports that include defined
standards groups. There are three settings for this report (in addition to report title and display filters):
Sort by Flows lists all standards activities applicable for the region, sorted by architecture flow.
The default is to sort by the name of the standard.
Filter by Element Selections
Display Only Standards This will display the list of standards and not include the source or
destination elements and flows to which each standard pertains.
GUIDELINE: The standards identified for each architecture flow should be used as a general
guideline. Each standard is typically comprised of both mandatory and optional elements which
should be reviewed. It is recommended that a communications expert proficient in bandwidth
analysis, performance requirements, and ITS standards options be consulted prior to deployment of
any ITS architecture.
GUIDELINE: As changes are made to the standards mapping in the National ITS Architecture, the
Turbo Architecture Standards Activities report may become outdated. To ensure that the latest
standards are being associated for each architecture flow in a Project or Regional Architecture, it
is recommended that the user view the National ITS Architecture web site.
List of Agreements Report listing the set of Agreements defined on the Agreements tab. These are
agreements between stakeholders or agencies, and are added as attributes of the architecture. Each
agreement is defined by a lead stakeholder, and may include associated stakeholders and projects. This

report has settings for sorting the report in a variety of ways, displaying a description of the agreement,
listing the associated stakeholders and projects, listing members of a stakeholder group and available
status values.
Project Sequencing Report of information about projects in the file in a user selectable sequence order.
If there is a Timeframe defined on the Start tab for the projects, then the list of projects can be sorted by
timeframe. Otherwise, the status values are used in the order that they appear on the Tools/Update
Status window. This report has settings for sorting the report by timeframe if used, displaying a
description of each project, displaying all information on the Start tab about each project, and listing
available status values.
User Defined Flows/Entities Report describing user defined entities and flows that have been locally
defined in the architecture. This report has no settings except report title.
Check Your Architecture is a set of reports to identify inconsistencies and potential error in the current
architecture.
Discontinued Flows Report showing the discontinued architecture flows between elements that
are included in the converted Regional and Project Architectures. This is a report created during
the conversion of an architecture from a previous version of Turbo Architecture. The report is
available during the conversion and from the list of standard Turbo reports.
Unsupported Flows Report identifying Regional and Project Architecture flows that are not
supported by current element to entity mappings in the National ITS Architecture or user defined
flow definitions. This report shows the flows that are ignored by the conversion (i.e., they are
included as is in the converted architecture), but that must be addressed by the user in the
converted architecture. For example, architecture flow ElementA => asset restrictions =>
ElementB would be an unsupported flow unless ElementA is mapped to the Asset
Management terminator and ElementB is mapped to MCMS. Many existing architectures
include these flows on the Interfaces tab because element to entity mappings have changed over
time. As part of the conversion from an older architecture (see Section 4.1.3), unsupported flows
that are not planned are automatically removed.
Unconnected Elements Report identifying the list of inventory elements that are not connected
to any other inventory elements on the Interfaces tab. This report can be used to clean-up an
architecture. Isolated elements could be either deleted, connected, or left alone with a note in the
comment field. This report identifies the problems. It is up to the user to correct them. This
report has settings for displaying a description of each element and listing available status values.
Unconnected Stakeholders Report identifying the list of stakeholders and stakeholder groups
that are not associated to any inventory elements in the architecture. This report can be used to
clean-up an architecture. Stakeholders that are not connected to any element in the inventory
could be removed or connected. This report identifies the problems. It is up to the user to correct
them. This report has settings for displaying a description of each stakeholder and listing
members of a stakeholder group.
Suspicious Information Flow Status Values Report identifying where information flows with older
status go between elements with newer status. This report has a setting to display the available
status values.
Suspicious Functional Requirement Status Values Report identifying functional requirements
with older status than the element providing the function. This report has a setting to display the
available status values.
Suspicious Request / Response Status Values Report identifying request information flows that
have a different status values than a corresponding response flow. This report has a setting to
display the available status values.
Suspicious Project Status Values Report identifying inventory elements, market packages,
functional requirements, and information flows that have newer status values than the current
project architecture. This report has a setting to display the available status values.

4.4.4.4 Example Report

An example of a report follows. Notice the envelope-like icon on the menubar. Click on this icon to
Export the report to another data file. (See the figure below.)
Figure 147. Report with Export Option
4.4.4.5 Scrolling Report Windows

There are several ways to scroll through a report. The reports are displayed using the Crystal Reports
software, a tool that is compatible with Microsoft Access, and displays the report one page at a time. To
get to the next page, use the arrow buttons at the top of the report window, or the First, Previous,
Next, Last buttons across the top of the window. The Page Up and Page Down keys only work on
a single page, not between pages, except as follows. However, there are other ways in which to scroll
through the report:
1. Scroll through the page displayed (single page): The arrow keys on the keypad, Page Up and
Page Down, may be used to scroll through a single page. The Home and End keys may also
be used to scroll to the top and bottom of the page. The report page must be in focus to use
any of these keys, i.e., click the left mouse button anywhere in the report window, then use the
keys. As an accessibility feature, the right arrow or tab keys may be clicked to bring the report
window into focus.
2. Scroll to the next or previous page in the report: The arrow buttons at the top of the report
window may be used to scroll between pages in the report.
3. Scroll to the first or last page in the report: The arrow buttons (with the vertical lines) at the top of
the report window may be used to find the first or last page of a report.

4.4.4.6 Report Window Options

There are several options across the top of the Report Preview window:
1. Open brings back the Reports Dialog window while the Report Preview window remains
displayed. A second report may be displayed by selecting the name of the report, choose some
settings, then click Preview. Up to four reports may be displayed in this manner in the Report
Preview window, in tabs across the top of the window. If four reports are open, the Open
option is grayed out unavailable. Now, you must close one report to be able to open another.
2. Next Report acts as a toggle between the reports that are open on the Report Preview
window. Each time this button is clicked, the next report in the tabs across the top of the window
is displayed. After displaying the last report in the list, the first report is displayed the next time
the Next Report button is selected. The tabs themselves may also be clicked to display the
desired report.
3. First, Previous, Next, Last As discussed above, these scroll between pages of the report.
4. Print This option is used to print the report on an attached printer or network printer. This
option is also launched by the printer icon just above the tabs at the top of the window. The
windows and options displayed by this option are dependent on the printer or network features
installed at the user site.
5. Close Report This option closes the report that is currently open. If there is more than one
report open in tabs across the top of the window, then the report that the user is currently viewing
is closed by this option. The other reports remain open. If this is the last report that is open in the
Report Preview window, the Report Preview window is closed and the Reports Dialog
window is again visible.
6. Save The icon that looks like an envelope with an arrow going into it is for saving the report into
a document format such as Adobe Acrobat (PDF), Rich Text Format (RTF) that can then be
imported into a word processor, or Word for Windows format. NOTE: the Word for Windows
format is based on an early version of Word and may not be compatible with the latest Microsoft
Office suites. If you encounter a problem, check for work-arounds from Microsofts web site.
7. Exit This option exits from the Report Preview window. The window (and all open reports) is
closed no matter how many reports are open. The Reports Dialog window is again visible. The
dialog box is closed by using the Close button.
8. Find feature The binocular icon at the top of the Report Preview window is used to search
the text for a word or phrase in the open page of the report. It only works on the current page.
When the page is changed, the Find feature must be re-launched.
9. Text features on the reports If you click on a line of text with the right mouse button, a box is
placed around it and the options Copy and Freeze Pane appear. Copy acts like a cut and
paste and the text may be pasted into different editors. If pasted into WordPad, it keeps the
format of the text. If pasted into Word, it puts the text in a text box. Freeze Pane places dashed
lines to mark the column and row allowing you to scroll up and down while freezing the rows
above and columns to the left of where you started. Click the right mouse button again to
Unfreeze Pane.
4.4.4.7 Printing a Report or Diagram

On the Output => Reports and Output => Diagrams windows, there is an option to Preview the
report or diagram. This will display a separate window containing the selected report or diagram. The
output may be printed from the Preview window.
On the Diagrams window, there is an option to print from the menubar in the diagram window by
selecting File => Print. The diagram will print on the specified printer/plotter.
On the Report windows, you must select the printer icon or Print option in the menubar on the Preview
screen to print the report.
GUIDELINE: When a report is previewed, the first page is displayed to the user. The report may
be saved to a file to be displayed in some other editor, or printed.

4.4.5 Web Pages

Turbo Architecture provides a tool to automatically create a set of preformatted hypertext (web) pages
that can be used to build a web site to display a regional architecture. This hyperlinked set of web pages
includes pages for each aspect of the regional ITS architecture that is defined in Turbo Architecture
including Stakeholder information, an inventory of transportation systems, services, functional
requirements, interfaces, ITS standards information, and ITS project information. The user has the
capability to customize the pages with their own agency logos, contact information, and can tailor the
content of the pages to meet their needs. For example, the user can tailor out the functional
requirements pages until they have had a chance to complete the requirements for their regional ITS
architecture. When hosted on a web site these pages make the regional ITS architecture definition
available to transportation professionals in an interactive, user friendly format.
GUIDELINE: Turbo can only create web pages for a Regional architecture not a project
architecture. If you select Output/Web Pages when viewing a project architecture a pop-up
window will appear directing you to go back to the Start tab and Select your Regional Architecture
before selecting Output Web Pages.
Once the user selects Output / Web Pages from the menubar a main web page control window
appears to start the Web Page generation process as shown below:
Figure 148. Web Pages Window

The Web Pages window is arranged as follows:
Create the top left area has 3 options to click to create varying levels of detail:
o Top-Level Web pages
o Detailed Web Pages
o Diagrams
This allows the user flexibility in managing how the web pages are built. Early in the life of a
project you may not be ready to show all the details but you want to go ahead and develop the
basic screens so your stakeholders can see what the end product will look like once the details
are done. At this early stage they can still see the basic list of Stakeholders, Inventory, etc.
Later, you can generate the Detailed Web Pages that pull more information out of the Turbo
database, including the pages for each inventory element, services, and interfaces. Lastly, the
Diagrams can be built that bring in all of the context and interface diagrams and attaches them to
the proper place in the hypertext.
Status below the Create area is a status box that tells you what process is being performed.
This is helpful since it may take a while to generate the web pages for a typical architecture. This
will let you know what pages are being built.
Progress colors in the bar below the status window from left to right to represent the overall
progress of the build operation.

Setup button establishes the general settings and preferences for how and where the pages are
built and what they will look like.
Create button initiates the creation of the web pages, pulling in the necessary data from the
Turbo database and putting them into the proper files based on the settings entered during Setup.
View button launches the initial welcome page for your new architecture in your default web
browser (e.g. Microsoft Internet Explorer, Mozilla Firefox)
Close button returns to the main Turbo window
4.4.5.1 Web Page Setup

To start generating web pages, Turbo needs some basic information. Click on Setup from the Web
Pages window and the following screen opens with the following tabs: General, Content, Style, and File
Locations.
Figure 149. Web Page Setup Window

The General Web Page Setup information tab, shown in the figure above, is used to capture information
that applies to all web pages. An essential piece of information is the folder where all the web pages and
supporting files will be saved. Clicking on the Browse button will bring up a windows explorer window to
find and select the folder to use.

If the folder is not empty, Turbo will determine that a new subfolder should be created to keep everything
organized. In that case a popup window will appear once the user hits Apply on the General tab as
shown below:
Figure 150. Web Pages Subfolder Creation Window

The Web Site Title will be included at the top of every web page. In general, users will probably want to
enter the name of their region, e.g. Marinara County in our example; but it could be anything. NOTE
the title is limited to 40 characters to ensure it fits best in most web browsers.
The Extension pulldown allows the user to pick either htm or html or type another extension to use. The
default htm is almost always going to work but some web server environments require a certain extension
which can be selected/entered here.
The Web Site Contact Information area allows the user to include a Name, email address, and phone
number that will appear at the bottom of the main web page. This may be important perhaps putting the
name and contact information for the maintainer of the architecture or a contact for the web administrator
for the agency.

The Content tab of the Setup Window allows the user to select the web pages to be included (defaults to
all). Selecting one of the pages on the left, brings up the information for that page on the right. For
instance, by selecting Scope as shown in the figure the user confirms the scope as entered on the Start
tab in turbo and then can check off the various features to include on the Scope page: Architecture
description, geographic scope, etc.
Figure 151. Web Pages Setup Content Window

Just as on the Inventory and other Turbo screens if the user wants to add a page to be generated with the
web site, click on the All Web Pages tab and use the check boxes to include other pages and hit apply.
Once the user has selected a page on the left, its attributes can be modified on the right.
Web Page Attributes:
Order: changing this will reorder the listing of the pages on the main menu panel for the
architecture pages. For example, if you wanted Stakeholders to come after Inventory you would
change Stakeholders to 4 and Inventory to 3 hitting Apply each time.
Menu name: allows the user to change the name that appears on the main menu panel for the
architecture pages. For example, changing Ops Concept to R&Rs.
Page Title: changes the name that appears at the top of that page.
Overview: is the text that appears at the top of the page.
Use Template box: allows the user to direct Turbo to ignore this text box and pull the information
from the html files that can be edited separately. The File Locations tab would be used to specify
the Template files and where they are located. This advanced feature is described in section
4.4.5.5.

Options: allows the user to specify what exactly is included on each page. In the Scope example
in the figure above, the user may decide to exclude Time Frame or Related Architectures.
The Style tab of the Setup Window allows the user to specify the colors of the background, text, and
other features pertaining to the look-and-feel of the web pages.
Figure 152. Web Pages Setup Style Window

The Select Web Page Area shows what the basic web page will look like based on the colors, graphics,
and fonts selected on the rest of the tab. To change the color of the web page banner, start by clicking
on the top bar of the Web Page area on the left of the window then click the colored box next to
Background and a pop-up screen will appear to change the color. Similarly with the Text color and
borders. To change other areas of the screen like the menu bar, click on the menu area on the left side
and then change the background and text colors on the right.
Use the check box beside Use Background Graphic to include or exclude a background image that
appears in the upper left of the banner/main page. The default image that is provided with Turbo is a
Turbo Icon, but this image should be replaced with a more relevant image by most users. You can find
where this image is stored using the File Locations tab. The graphic extension pull-down allows the user
to change the graphic file format to png, gif, or jpg. Note that png and gif file formats can have a
transparent background which will allow the background color to show through the transparent area of the
image. The options at the bottom allow the user to select how large the web pages should be in terms of
pixels 800 being the default but 1024 and 1280 are also available. The font family can be changed as
well. Arial/Helvetica is the default and should be left as is for most applications.

The 4th tab is the File Locations Tab and is generally for reference purposes except a web administrator
may want to know where the files are located to be able to make specific changes for the environment.
Figure 153. Web Pages Creation File Locations Window

This tab shows where on the computer the web pages, templates, style sheets, and Images are stored.
Most users will not need to use this tab. Refer to the Advanced Users section 4.4.5.5 for more
information.
Now that the Setup is complete, Hit Close to return to the Web Pages window.

4.4.5.2 Web Pages Creation

For the user that is ready to generate the web site, click on the checkboxes on the left one or more
and click Create. The window will update its progress as each page and file is constructed as shown
below.
GUIDELINE: It is recommended that the first time through the web page generation process, you
should create only the Top-Level Web Pages to quickly generate pages that you can review. Make
sure the look and feel is right, then go back and generate the Detailed pages, then go back and add
the Diagrams.
Figure 154. Web Pages Creation Progress Window

At the end of this process, depending on the complexity and size of the architecture you may get
warnings that certain diagrams are too complex. At this point, you may decide to make changes to your
architecture to fix the overly complex diagrams.
For very large architectures (100+ elements) it may take a very long time to generate all of the diagrams.
It may be more efficient to skip the Diagrams step here, run a Batch Diagram generation process (section
4.4.3.5) and then convert them to the format required for the web pages. This is discussed further in the
Advanced topics section 4.4.5.5.
For each area of the web site you create, top-level web pages, detailed web pages, and diagrams, the
status area will indicate what has been completed. Note that if you select more multiple items to be
generated that the status area will only show the status of the last item. Now you can go on to view the
web pages.

4.4.5.3 Web Pages Creation

Once the web pages are generated, click on the View button to launch your default web browser to see
the new web pages as shown below.
Figure 155. Web Pages Viewed in Browser

The next figure shows the Services window for the newly generated Top-Level Web Pages of the
Marinara County ITS architecture. Note that even with just the top-level view you can still see the list of
market packages and their status.
Figure 156. Services (Market Packages) Web Pages Viewed in Browser

You even see hyperlinks for the names indicating a link to a detailed page for that market package.
However, if all you did was create the Top-Level pages clicking on one of those hyperlinks for the market
package name will produce an error that the page could not be found. Once you create the Detailed
Pages, these hyperlinks will then work.
Check to make sure the format and content look right, click through the menubar on the left to see how
the content changes. Depending on the type of changes you are making your next steps will vary.
Formatting Changes: You could decide that you dont like some of the colors, fonts, or other settings and
want to make changes. If so,
Go back to the Web Pages window, select Setup and make the appropriate changes on
either of those tabs.
Close the Setup window and click View to see the affect of the changes made. You do not
need to rerun Create, just View it, because the settings are kept outside the Turbo Database
and the web browser accesses and use the settings without having to regenerate the pages.
Content Changes: If something is wrong with a description or name, or some flows you expected to see
are missing. This may indicate changes that are needed in the Turbo database itself. If so,
Go back into the Turbo tabs and verify the architecture content and make the changes and
apply as needed.
Come back to the Output / Web Pages window and re-Create the pages, either Top-Level,
Detailed, or Diagrams as appropriate.

4.4.5.4 Web Page Layout

This section shows a sample of each web page that the Turbo Web Page generator produces to show the
basic layout and discuss the options for how to view different aspects of your architecture.
4.4.5.4.1 Home Page

The figure below shows the Home or Welcome page for the generated architecture, typically this file
would be the one called index.htm and is the starting page for the web site.
Figure 157. Home Web Page Viewed in Browser

The Home page includes the welcome text introducing the work and the web site. This default paragraph
can be edited on the Setup / Content tab. The contact information at the bottom of the row corresponds
to the information supplied on the Setup / General tab. The date corresponds to the date when the web
pages were generated.

4.4.5.4.2 Scope
The next figure shows the Scope page for the generated architecture. It pulls information from the Start
tab. The user can decide what to include or exclude using the Setup / Content tab.
Figure 158. Scope Web Page Viewed in Browser

4.4.5.4.3 Inventory
The next figure shows the Inventory page for the generated architecture. It pulls information from the
Inventory tab, sorted by Element Name. The user can decide whether to include or exclude the
Descriptions on this top level page or on the detail pages that follow using the Setup / Content tab.
Figure 159. Inventory Web Page Viewed in Browser

4.4.5.4.4 Inventory element detailed page

The next figure shows the Inventory page for a particular element from the generated architecture. It
pulls the Status, Description, Stakeholder mapping, and Entity (called Functionality) mapping from the
Inventory tab. It pulls the interfaces from the Interfaces tab in turbo. The hyperlinks on this page include:
the Stakeholder page mapped to this element,
a description of the functionality to which it is mapped,
a context diagram showing all of the interface flows into and out of this element, and
links to a page for each of the interfacing elements describing the architecture flow definitions, the
status of each, and whether any ITS standards apply
Figure 160. Inventory Element Detailed Web Page Viewed in Browser

In the example above, the PASTA Bus Operations Center is mapped to a Transit Management
subsystem. Clicking that Transit Management hyperlink in this case will display a page that includes the
entity description from the National ITS Architecture, the functional areas (also called Equipment
Packages) to which it was assigned on the Requirements page in Turbo and for each of those Equipment
Packages a table is shown listing the detailed functional requirements selected or written for this element
and their status.

The functionality and entity description page for Transit Management is shown below:
Figure 161. Inventory Element Functionality Web Page Viewed in Browser

If this were mapped to a unique or user defined entity that is not part of the national ITS architecture it
would pull the description from the Tools / Add Entities page in Turbo. There is another way to view
requirements from the Turbo web pages the Requirements page which will be explained later.
The Interface Context Diagram for the selected element is shown below. This corresponds with the
Context Diagrams seen from within Turbo. Recall how the user could Select just one Element and select
Show All to see all of the interfaces to and from that one element. This Context Diagram is the
equivalent to that Show All diagram.
Figure 162. Inventory Element Context Diagram Web Page Viewed in Browser

Next is what happens when you select one of the hyperlinks in the Interfaces To section of the inventory
element detailed page. In our PASTA example, one of the other elements to which it interfaced was the
TOMATO Regional Traveler Information System. Clicking on that hyperlink brings up the screen shown
below:
Figure 163. Inventory Element Interfaces to Other Element Web Page Viewed in Browser
Note the diagram at the top of the page only has the 2 interfacing elements in question. That is followed
by a listing of each of the lines shown in the diagram along with their status value, their description and
another hyperlink to any applicable ITS Standards.

The Applicable Standards for the selected routes flow shown on the element-to-element interfaces
screen above has been selected and is shown in the next figure.
Figure 164. Applicable Standards Web Page Viewed in Browser

4.4.5.4.5 Inventory by Entity Page

Go back to the menubar and click By Entity under Inventory to see the page shown in the next figure.
Figure 165. Inventory by Entity Web Page Viewed in Browser

On this page, the title and paragraph at the top are pulled from the Setup / Content Page and can be
customized as needed. The table is sorted alphabetically by entity name in the first column and all of the
elements associated with each of the entities in the right column. Note this will only list the entities for
which elements have been mapped in the Turbo database. For example there are no Commercial
Vehicles included in the scope of our example Marinara county so those CV related entities are not
shown in the table.
Clicking on any of the elements in that table will bring up the Element page shown previously in Figure
160.

4.4.5.4.6 Inventory by Stakeholder Page

Go back to the menubar and click By Stakeholder under Inventory to see the page shown in the next
figure.
Figure 166. Inventory by Stakeholder Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by stakeholder name in the first column and all
of the elements associated with each of the stakeholders in the right column.
Clicking on any of the elements in that table will bring up the Element page shown previously in Figure
160.

4.4.5.4.7 Stakeholder Page

Go back to the menubar and click Stakeholders to see the page shown in the next figure.
Figure 167. Stakeholders Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by stakeholder name. The user can decide
what to include or exclude using the Setup / Content tab. Note this is pulling information that was entered
on the Stakeholders tab in Turbo. If no description was entered in Turbo, as shown above, that cell will
be blank on the Stakeholders page.

Clicking on any of the stakeholders in that table will bring up the details page for that stakeholder shown
below:
Figure 168. Stakeholder Details Web Page Viewed in Browser

This Stakeholder details page shows the description, any stakeholder Groups it may be associated with,
and Associated Inventory elements. Clicking on a hyperlink under the Included In Groups heading will
bring up the description of that group shown below:
Figure 169. Stakeholder Group Web Page Viewed in Browser

Clicking on any of the elements under the Associated Inventory heading will bring up the Element page
shown previously in Figure 160.

4.4.5.4.8 Services Page

Go back to the menubar and click Services to see the page shown in the next figure.
Figure 170. Services (Market Packages) Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by market package according to the list of
Market Packages included in the regional architecture on the Services tab in Turbo. The Name and
Status column are also shown and are also pulled from the Services Tab in Turbo. For instance, on the
services tab, users can create an instance of a particular package and give it a unique name. These
locally defined names will be listed here in this table as shown in the example above for ATMS01 Network
Surveillance.
The user can decide what to include or exclude using the Setup / Content tab. This includes whether to
include the Unselected Market Packages to give a complete picture, perhaps of what else they could do
with ITS in the future. Or whether to put the descriptions on the Detail pages that follow and whether to
include the selected inventory elements on those pages.

Selecting one of the hyperlink Market Package Names will bring up the details page for that particular
market package or instance as shown below:
Figure 171. Services (Market Packages) Details Web Page Viewed in Browser
The Market Package details pages show the ID-Name, Status, Description, and the Included Elements.
Clicking on any of the elements under the Associated Inventory heading will bring up the Element page

4.4.5.4.9 Ops Concept Page

Go back to the menubar and click Ops Concept to see the page shown in the next figure.
Figure 172. Operational Concept Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by Roles and Responsibilities areas according
to the list included in the regional architecture on the OpsConcept tab in Turbo.

Clicking on one of the hyperlinks for Areas will bring up the description of that area, the stakeholders that
are supporting that area, and a table of Roles and Responsibilities that may have been defined for that
stakeholder/Area:
Figure 173. Roles & Responsibilities Web Page Viewed in Browser

Clicking on any of the stakeholders on the left side of the table will bring up the Stakeholder details page

4.4.5.4.10 Requirements Page

Go back to the menubar and click Requirements to see the page shown in the next figure.
Figure 174. Requirements Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by Subsystem according to the list included in
the regional architecture on the Requirements tab in Turbo for those elements for which functionality has
been defined. Functionality is defined once one or more functional areas are associated with an
element. Additional levels of detail may be added by selecting or writing the actual functional
requirements.
Clicking on one of the Functional Areas on the right side of the window will open up window showing a
description of that functional area, the elements associated with that functionality, and the possible
requirements (shall statements) that could be selected/included as part of that are. This is shown below:

Figure 175. Functional Areas Web Page Viewed in Browser

NOTE that with Functional Requirements there are two different ways to view the data here as part of
the Functional Areas display you see a listing of all possible generic requirements that could be selected
for this area. This provides a way to better understand the type of equipment or product being described
in the mapped element.
The other way to view requirements is to see them by individual element. This method was discussed
and shown previously on Figure 161. In that view, the users can see the just the requirements that pertain
to that particular element as have been selected, customized, or written from scratch and assigned to
that element.

4.4.5.4.11 Interfaces Page

Go back to the menubar and click Interfaces to see the page shown in the next figure.
Figure 176. Interfaces Web Page Viewed in Browser

customized as needed. The user can also decide to include or exclude the Context and Interface
Diagrams on the subsequent details pages. In this Interfaces window the table is sorted alphabetically by
element names according to the list included in the regional architecture on the Interfaces tab in Turbo,
followed by the set of Interfacing Elements for each element and the status of each link.
This page consolidates all of the interfaces for the region into one place. Other ways to find this
information include going through the Inventory tabs to find these same context and individual interface
diagrams.

Selecting one of the Element Names on the Left will bring up a Context diagram for that element i.e.
everything that element is connected to, as shown below.
Figure 177. Interfaces Context Diagram Web Page Viewed in Browser

Go back to the Interfaces screen and select one of the Interfacing Element Names on the Right and it will
bring up a the singular Interface diagram and listing of the flows between those two elements. This was
shown in Figure 163.

4.4.5.4.12 Standards Page

Go back to the menubar and click Standards to see the page shown in the next figure.
Figure 178. Standards Web Page Viewed in Browser

customized as needed. The table is sorted alphabetically by Standards Development Organization
(SDO) and their standards that may be applicable in the regional architecture based on the Standards tab
in Turbo.
Selecting one of the Standard Titles will bring up a window showing the specific interfaces from this
region to which this standard may apply.

Figure 179. Standards Detail Web Page Viewed in Browser

4.4.5.4.13 Agreements Page

Go back to the menubar and click Agreements to see the page shown in the next figure.
Figure 180. Agreements Web Page Viewed in Browser

customized as needed. The user can also decide whether to include the Agreement Number on the Top
Level Page, the descriptions, stakeholders, and projects on the detailed pages.
The table is sorted alphabetically by Agreement Number according to the list included in the regional
architecture on the Agreements tab in Turbo.
Clicking one of the Agreement names brings up the details for that agreement as shown.

Figure 181. Agreements Details Web Page Viewed in Browser

4.4.5.4.14 Projects Page

Go back to the menubar and click Projects to see the page shown in the next figure.
Figure 182. Projects Web Page Viewed in Browser

customized as needed along with deciding what other details to include about the project. The table is
pulled from the Start tab in Turbo.

Selecting one of the Project names hyperlinks will bring up the screen shown below.
Figure 183. Projects Details Web Page Viewed in Browser

This includes the description, status, timeframe from the Start Tab for that Project. It also includes the
assigned stakeholders, included inventory elements and services (market packages), and the assigned
interfaces.
Note that the information on this page is static not hyperlinked to the rest of the web pages. This
provides a simple snapshot of the high level information concerning a project.
If projects are changing much more frequently than the regional architecture is being maintained, the
Setup / content tab should be used to limit the details shown here to just the information not likely to
change between updates of the web site (e.g. general project information associated with the regions
ITS).

4.4.5.5 Advanced Web Page Creation Options

Creating and editing the Web Pages is one thing. The sections above provided a way to generate basic
web-based content for your architecture. That may be all you need to worry about if you are going to
store and publish the web pages on a CD. If, however, you are responsible for creating a set of web
pages that are going to be published via your departments web server out onto the Internet, chances are
that you will be given certain additional requirements to follow.
The steps below walk through a scenario of how a knowledgeable web page designer/editor might use
this tool to build a more sophisticated web site.
The scenario below revolves around Chuck, an IS person who must generate an architecture web site
that integrates with his existing agency web site. He is familiar with HTML and would like to change the
architecture web site styles, colors, and header and footer content to match the agency web site look as
closely as possible and meet minimal agency web site requirements.
In reality, a more typical scenario might include both Chuck and Anne, the agency regional architecture
expert shown on the web pages in the previous sections. Anne built the architecture and generates the
web pages, shows them to Chuck the IS guy, who says there is no way he can host those pages on the
agency site unless they meet the minimal agency site requirements. Anne and Chuck work together to
create something that meets the web site requirements.
Chuck would do many of the same things that Anne did to generate his web site, but we will focus here
only on those more advanced features that he would use to generate user defined pages, generate
custom page headers and footers that are consistent with agency web site requirements, and include a
map graphic on the basic architecture scope web page that Turbo generates. These are some of the
things that an advanced user might want to do to improve the basic set of web pages.
1. Chucks customization work begins on the same Web Setup form that Anne used. Chuck selects
Output=>Web Pages and then selects Setup to open this form.

2. Chuck selects the Content tab and then selects New to create a Documents web page for the
project. In this case, this is an internal web page that Turbo will create with the same menu,
header, and footer as all the other web pages.
Figure 184. Web Page Setup/Content New Internal Page

3. Chuck keeps the standard order number that will place the menu item for the new page at the
bottom of the menu and enters the menu name, page type, title, and enters a few sentences of
content in the overview box. Although Chuck could enter all of the HTML for the page in the
Overview text box, Chuck will almost always want to use another tool to actually create the
HTML. More on that later in this scenario. Chuck selects Apply to save the user defined page.
Behind the scenes, Turbo creates a new template page for the Documents page when Apply is
clicked.

4. Chuck also wants to include a menu entry on every web page that links to his agency home page
because that is one of his agency web site requirements. In this case, he sets the order to 1 to
move the entry to the top of the menu and selects external for the page type since this is an
existing page that Turbo is not creating. As shown, for external pages, Chuck only has to enter
the URL that will be used to access the page. In most cases, this will be an absolute address, but
Chuck is free to enter a relative address. NOTE - It is Chucks responsibility to enter a valid URL
as Turbo does no validation of the entered text.
Figure 185. Web Page Setup/Content New External Page
5. In order to further tailor the basic web pages, Chuck will want to work directly with some of the
web files that Turbo uses. Chuck selects the File Locations tab, which is the users source of
information for all the web-related files that Turbo is using: web pages, templates, style sheets,
and images. When Chuck selects a file type, Turbo provides a description of the file type at the
bottom of the tab.

6. Chuck selects the + to the left of Templates to expand the tree and see all of the templates
files. He then selects the Header template to find out more information about how that particular
template is used in the web page creation process.
Figure 186. Web Page Setup/File Locations Page

7. Chuck edits the header.htm and footer.htm files in the Templates directory so that all the web
pages generated by Turbo will include the agency-standard web page header and footer. The
header and footer that Chuck creates include agency logos and a standard graphic (which may
have a different form factor than the standard banner graphic that Turbo uses), the agency web
site search function, and standard menu entries that the agency would like on each web page.
8. Chuck could also have opted to change the banner.gif image file that is at the top of each
standard Turbo web page if he only wanted to include a region-specific graphic and agency logos
on each page.
9. Chuck also edits scope.htm to include a map of the region, enhancing the standard page that is
created by Turbo.
10. Chuck could also directly edit the Turbo.css style sheet, if for example, he needs to change the
fonts to match a site standard.
11. If at any point, Chucks edits cause problems, Chuck can select Restore Default to restore the
selected file to the default Turbo content. Before overwriting the existing file, Turbo will confirm
that Chuck wants to overwrite his file with the default file.
12. Chuck closes the Web Page Setup form and returns to the Web Pages form.

13. Chuck knows that the fastest way to generate all the diagrams for a web site is to generate all the
diagrams as EMF files and then use a third-party tool to batch convert all the EMF diagrams to
GIF files.
14. For this reason, Chuck only chooses to create all the web pages, not the diagrams on the web
pages form. He selects the two web pages check boxes and then hits Create to create all the
web pages. The agency web site-compatible web pages are generated.
15. Chuck then directly uses the Turbo batch diagram generator to generate all of the diagrams as
EMF files (described in section 4.4.3.5)
TIP: To create the Context Diagrams, use ctx as the prefix and use if as the prefix for the
Interface Diagrams. Both using Short file names.
16. Chuck then uses a shareware utility to convert all of the diagrams into GIF files and load them
into the appropriate subdirectories in the directory tree: \web\images\ifs and
\web\images\context for the interface and context diagrams, respectively.
17. Chuck copies the entire directory tree to his web server and builds links to the new web pages
from his existing agency ITS web page.
4.5 Help Menu

The following help options are available to the user:
1. Contents will display a list of help topics, words, and phrases.
2. About Turbo Architecture will display information about the operating system and version
number of Turbo Architecture, as well as the versions of all National ITS Architecture databases
that are used for this version of Turbo Architecture.
NOTE that on any window, the user may press F1 in order to display the help topics for Turbo. You may
also hover over a highlighted item to receive a short help sentence for that topic.
Figure 187. Help Pulldown
4.5.1 Help Contents

The Help Contents option includes two tabs: Contents and Index.
The Help Contents tab appears as a list of topics. You may double-click on a topic and it will either
open a list of sub-topics below it or open the text for that topic. Double clicking on the topic again toggles
the open topic to closed.
The buttons at the top of the window may be used to Hide the list of contents on the side of the window
to only show the actual content. This button will toggle to Show which can be used to bring the list of
topics back. The Back button works the same as browsing any web page by taking you back to the
previous screen. Use Print to print the help text for a topic. The Options button has several additional
features: Show/Hide Tabs works the same as the Show and Hide buttons, Back/Forward work the same
as the Back and Forward buttons on any web browser, Home takes you back to initial Turbo help page,
Stop will halt the reading and display of a page (this shouldnt be a problem for the Turbo Help menu),
Refresh works like the Refresh button on a web page to re-read the contents to put on the screen for the
topic, Internet Options will bring up the same Internet Options window from your computers browser,
and Print will bring up the Print window like the Print button.

When a subtopic is selected by double clicking, the list of topic areas that will bring up the help text is
then available. Selecting one of these help topics (by clicking on the topic) will bring up a window with the
help text.
If you select the Index tab, a list of additional Help topics appears and you can select an index topic on
the Index Help screen. Click Display to display the text window for that topic, or double click on the
topic in the list to display the text.
4.5.2 Update Turbo

Turbo Architecture software may be updated from time-to-time to incorporate fixes to the software or
provide new functionality. Selecting the Update Turbo option from the Help menu will initiate a process
to query the Turbo Architecture web site to see if there is a new version of the software available and
allow the user to download and install it.
4.5.3 About Turbo Architecture Option

About Turbo Architecture displays information about the Turbo Architecture product, including copyright
information and the version numbers of Turbo and all portions of the National ITS Architecture that are
being used by Turbo.
The system information (System Info option) displays data about your PC and the operating system.
4.5.4 Context Sensitive Help

Function key F1 for each screen in the Interview, tabular windows, and popup windows, displays the help
contents list, from which an index of topics is available. Using F1 to obtain help for a topic will display the
verbose form of help as in the Help Contents, Index, and Find tabs.
Another method of obtaining help for certain topics is to hover the cursor over an option (such as, a tab
option). A short sentence is displayed that explains the option. This is the terse (short) form of context-
sensitive help for this topic.

5 Being a Successful Turbo Architect

This section describes sample processes for using Turbo Architecture to perform the four key capabilities
(see Section 1.4.1) available for creating Regional and Project Architectures. There are many other ways
in which the tool may be used. There may be various iterations of the steps not listed in the sample
processes in this section, such as, repeatedly tailoring and extending (customizing) the architecture,
returning to the first step to reassign some of the inventory or add a new inventory element, customizing a
second time, etc. The usage suggested here is an example only.
5.1 Regional Architecture Step by Step
5.1.1 Create a Regional Architecture

The following describes a sample process for using Turbo Architecture to create a Regional Architecture.
This is not the only possible method for creating Regional Architectures, but is a suggested set of steps.
1. In an open database file, create a new Regional Architecture. Select the Start tab and New
under the Regional Architecture section. Enter a new Regional Architecture name and optional
description. The other fields on this tab are also optional. Click Apply. See Sections 3 and 4
for more information on creating/opening a database file and Regional Architecture.
2. Skip the questionnaire (Interview Dialog) by clicking the Skip Interview button when asked to go
directly to the Tabs to do the data entry.
3. Select the Stakeholders tab. Create new stakeholders, update their description, and create
groups of Stakeholders that may exist in the region. (Section 3.2)
4. Select the Inventory tab. Review the list of elements and their associated stakeholders, entities
(subsystems and terminators), and projects. Add, modify, or delete as necessary. The Inventory
tab is used to map regional elements (systems/centers) and stakeholders to National ITS
Architecture entities (Subsystems and Terminators) to create a Regional Inventory. (Section 3.3)
5. Select the Services tab. Review the list of Market Packages checked and the project, element,
and completion status. Add, modify, or delete as necessary. (Section 3.4) The Services tab is
used to map regional needs to a set of National ITS Architecture Market Packages.
6. If necessary, extend the Regional Architecture by adding User Defined Entities (similar to
Subsystems and Terminators) and Architecture Flows. This may be done via the Tools => Add
Entities or Tools => Add Flows pulldown menu while in any of the tabs, and extensions may be
modified on the Interfaces tab after a Build. It may be easier to add extensions to the
architecture before the first Build, otherwise another Build is required. (Section 4.3.1)
7. It is also possible to create new local status values that will be used throughout Turbo
Architecture. This is done via the Tools => Update Status option. (See Section 4.3.2)
8. Use the Ops Concept tab to document the Roles and Responsibilities for the stakeholders in the
region. The Roles and Responsibilities can be associated with areas of the architecture
pertaining to the services (market package) assignments. (See Section 3.5)
9. Select the Requirements tab to attribute functional areas and functional requirements to the
inventory elements. (See section 3.6)
10. Select the Interfaces tab. (Section 3.7)
a) Select the Build button to build the uncustomized set of interconnects and architecture flows
to be considered.
b) Select the Connect view to display a table of all the possible interconnects based on the
National ITS Architecture and the Elements/Entities and Market Packages selected. The
user checks the interconnects that he wants to see.
c) Select the architecture Flows view. Both the Connect and Flows views display a
pulldown (top left of the window) of all the interconnections (element to element) and
architecture flows currently defined in the Regional Architecture. The user selects one
element (to view the interconnects or flows in and out of only that single element) or the ALL
option (to view all the interconnects and flows in the architecture). A table is then created

with all the architecture flows surrounding the selected element, or all flows listed.
Select/deselect flows for the selected element and assign a status value to each flow. The
architecture flows displayed will be a function of the elements assigned to the National ITS
Architecture entities, the market packages selected, and the interconnects identified.
d) Continue with the architecture Flows view and customize for each flow in the list.
e) The Connect and Flows views are also used to further customize the interconnects and
architecture flows for the user defined entities and flows added to extend the architecture.
14. Select the Standards tab and customize the selections of ITS standards that will be applicable to
the region. (Section 3.8)
15. Select the Agreements tab and create a list of agreements that will support the implementation of
the Regional ITS Architecture. The agreements can include a brief description, the primary and
secondary stakeholders, and the type of agreement. (Section 3.9)
16. Create Outputs. There are many types of diagrams, reports, and even web pages that can be
created and many settings and filters for each. (Section 4.4)
5.1.2 Update an Existing Regional Architecture with a Project Architecture

This section describes a sample process for using Turbo Architecture to add a previously defined Project
Architecture created with Turbo, to a Regional Architecture. This is not the only possible method, but is a
suggested set of steps. This function is required in order to populate the Regional Architecture with the
project data the first time, and regain architecture flow and interconnection consistency between the
Project and Regional Architectures if the project has been customized (after the first Merge). This
option may only be done on the tabbed windows (the Interview Dialog should not be used for this Turbo
Architecture capability it is not available for an existing architecture).
GUIDELINE: If no Regional Architecture exists and the user defines a project, he must then
create a new Regional Architecture and choose to add this project into it. This is not done
automatically by the tool.
1. Open the database file that contains the Regional and Project Architectures.
2. Open the Project Architecture that is to be added to the Regional Architecture.
3. In the Project Architecture, on the Start tab, select Project to Region to merge the project into
the Regional Architecture. See Section 3.1.1.9 for more information on the Merge option.
4. A window will appear that lists the project elements and flows that do not exist in the Regional
Architecture. The user must choose to add them to the Regional Architecture or not.
5. Review the set of changes to the Regional Architecture made by the Merge. Project name to
element associations may need to be changed on the Inventory tab.
6. Create Outputs showing aspects of the updated Regional Architecture.
5.2 Project Architecture Step by Step
5.2.1 Create a Project Architecture when no Regional Architecture Exists

The following describes a sample process for using Turbo Architecture to create a Project Architecture
under the assumption that a Regional Architecture has not previously been created in this database file.
This process may also be used to create a Project Architecture when the file does contain a Regional
Architecture the Regional Architecture will not be used to generate the Project Architecture in this case.
This is not the only possible method for creating Project Architectures, but is a suggested set of steps.
1. In an open database file that may or may not include a Regional Architecture, create a new
Project Architecture. Select the Start tab and New under the Project Architecture section. Enter
a new Project Architecture name and optional description. The other fields on this tab are also
optional. Click Apply. See Sections 3 and 4 for more information on creating/opening a
database file and Project Architecture.

2. Skip the questionnaire (Interview Dialog) by clicking the Skip Interview button when asked.
3. Select the Stakeholders tab to create the list of stakeholders, update their description, and create
groups of Stakeholders that may be involved in the project. (Section 3.2)
4. Select the Inventory tab to create the list of elements and their associated stakeholders, entities
(subsystems and terminators), and projects. Add, modify, or delete as necessary. The Inventory
tab is used to map regional elements (systems/centers) and stakeholders to National ITS
Architecture entities (Subsystems and Terminators) to create a Regional or Project Inventory
(Section 3.3).
5. Select the Services tab to create the list of Market Packages checked and the project, element,
and completion status. Add, modify, or delete as necessary. (Section 3.4) The Services tab is
used to map regional needs to a set of National ITS Architecture Market Packages.
6. If necessary, extend the Project Architecture by adding User Defined Entities (similar to
Entities or Tools => Add Flows pulldown menus while in any of the tabs, and extensions may
be modified on the Interfaces tab after a Build. It may be easier to add extensions to the
architecture before the first Build, otherwise another Build is required. (Section 4.3.1)
7. Use the Ops Concept tab to document the Roles and Responsibilities for the project
stakeholders. The Roles and Responsibilities can be associated with areas of the architecture
pertaining to the services (market package) assignments. (See Section 3.5)
8. Select the Requirements tab to attribute functional areas and functional requirements to the
inventory elements. (See section 3.6)
9. Select the Interfaces tab. (Section 3.7)
a. Select the Build button to build the set of uncustomized interconnects and architecture flows
for the project.
b. Select the Connect view. This displays a table of all the possible interconnects based upon
the National ITS Architecture and the Elements/Entities and Market Packages selected. The
user checks the interconnects that he wants to see.
c. Select the architecture Flows view. Both the Connect and Flows views display a
pulldown (top left of the window) of all the interconnections (element to element) and
architecture flows currently defined in the Project Architecture. The user selects one element
(to view the interconnects or flows in and out of only that single element) or the ALL option
(to view all the interconnects and flows in the architecture). A table is then created with all
the architecture flows surrounding the selected element, or all flows listed. Select/deselect
from the list of flows for the selected element. The architecture flows displayed will be a
function of the elements assigned to the National ITS Architecture entities, the market
packages selected, and the interconnects identified.
d. Continue with the architecture Flows view and customize for each flow in the list.
e. The Connect and Flows views of the Interfaces tab are also used to further customize the
interconnects and architecture flows for the user defined entities and flows added to extend
the Architecture.
10. Select the Standards tab and customize the selections of ITS standards that will be applicable to
the project. (Section 3.8)
11. Select the Agreements tab and create a list of agreements that will support the implementation of
the project architecture. The agreements can include a brief description, the primary and
secondary stakeholders, and the type of agreement. (Section 3.9)
12. Create Outputs. There are many types of diagrams and reports that can be created and many
settings and filters for each. (Section 4.4)

5.2.2 Create a Project Architecture from an Existing Regional Architecture

The following describes a sample process for using Turbo Architecture to create a Project Architecture
under the assumption that a Regional Architecture has previously been created in this database file. This
is not the only possible method, but is a suggested set of steps. This option may only be done on the
tabbed windows (the Interview Dialog should not be used for this Turbo Architecture capability).
1. Open the database file that contains the Regional Architecture. Do not open the Regional
Architecture.
2. Create a new Project Architecture. Select the Start tab and New under the Project Architecture
section. Enter a new Project Architecture name and optional description. The other fields on this
tab are also optional. Click Apply. See Sections 3 and 4 for more information on
creating/opening a database file and Project Architecture.
3. Select Skip Interview in the popup window to create an empty Project Architecture.
4. On the Inventory tab, associate the appropriate elements with this new empty project. Use the
checkboxes down the left side of the screen and click Apply when done. This also associates
entities and stakeholders with this project as they appear on the Inventory tab in the Regional
Architecture.
5. Update the Inventory to add or create any new Element/Stakeholder mappings in the Project
Architecture e.g. new project unique elements, or elements that are instances of regional
elements.
6. On the Services tab, associate market packages from the regional architecture with the current
project architecture by clicking the appropriate check-boxes down the left side of the screen.
Click Apply when done. This also retains the other Regional Architecture associations on this
window.
7. Use the Services tab to add any project-unique Market Packages. Later, the project can be
merged into the Regional Architecture (or merged again, if already merged once), via the Project
to Region option on the Start tab, to recapture architecture flow and interconnection consistency
(needed for the Interfaces tab) between Regional and Project Architectures. Remember that the
project was created from the Regional Architecture, so if no changes are made to the Project
Architecture, it does not need to be merged into the Regional Architecture.
8. If necessary, extend the Project Architecture by adding User Defined Entities (similar to
Entities or Tools => Add Flows pulldown menu while in any of the tabs, and may be modified
on the Interfaces tab after a Build. It may be easier to add extensions to the architecture before
the first Build, otherwise if they are added later, another Build is required.
9. Select the Interfaces tab.
a. Select the Build button to build the uncustomized architecture. The Build step in the
project will preserve any customization that may have been done in the Regional
Architecture.
b. Select the Connect view to display a table of all the possible interconnects based upon the
National ITS Architecture and the Elements/Entities and Market Packages selected. The
user checks the interconnects that he wants to see and clicks Apply to accept these
changes.
c. Select the architecture Flows view. Both the Connect and Flows views display a
pulldown (top left of the window) of all the elements currently defined in the Project
Architecture portions of the Regional Architecture. The user selects one element (to view the
interconnects or flows in and out of only that single element) or the ALL option (to view all
the interconnects and flows in the architecture). A table is then created with all the
architecture flows surrounding the selected element, or all elements listed. Select/deselect
from the list of flows for the selected element. The architecture flows displayed will be a
function of the elements assigned to the National ITS Architecture entities, the market
packages selected, and the interconnects identified. You must also click Apply on this
window to accept any changes.

d. Changes to the project will be reflected in the Regional Architecture (if there are no conflicts),
when this project has been merged (or re-merged) with the Regional Architecture. The
potential conflicts between the Project and Regional Architectures may be viewed in the
Region to Project Comparison, Inventory to Market Package Comparison, and Additional
Integration Options reports for the Regional and Project Architectures. Each conflict must be
resolved.
e. Continue with the architecture Flows view and customize for each flow in the list.
f. Still in the architecture Flows view, select the portions of the Regional Architecture and
National ITS Architecture that should be in the project but are not, based upon the results of
the previous steps. This involves selecting from a list of source element, architecture flow,
and destination element. The subsystems and terminators are implied on the Interfaces tab
by their associations with the elements listed. They can be viewed on the Inventory report.
Each source, architecture flow, and destination triplet may or may not have been assigned a
project designation. Elements of the Regional Architecture not previously identified as
belonging to the project may be selected during this step. These will initially appear with a
flow status of Not Planned.
g. If a user adds elements or flows (and indirectly National ITS Architecture entities) into a
Project Architecture beyond the Regional Architecture, Turbo Architecture will not
automatically update the Regional Architecture with these flows (the flows will appear on the
Interfaces tab as not planned and not included). The user must do this manually by using
the Project to Region option on the Start tab, or by opening the Regional Architecture and
selecting the Include box for each new user defined flow on the Interfaces tab, Flows view.
h. The Connect and Flows views of the Interfaces tab are also used to further customize the
interconnects and architecture flows for the user defined entities and flows added to extend
the architecture.
10. Select the Standards tab and customize the selections of ITS standards applicable to the project.
11. Select the Agreements tab and create a list of agreements that will support the project. The
agreements can include a brief description, the primary and secondary stakeholders, and the type
of agreement.
12. Create Outputs. There are many types of diagrams and reports that can be created and many
settings and filters for each.
5.3 Relationships Between Elements, Stakeholders, and Tabbed Windows

GUIDELINE: The stakeholder associated with an element may determine how that element is
interconnected with other elements on the Interfaces tab and on the Interconnect and Flow
diagrams. Two elements will be connected to each other (in most cases) if the stakeholder is the
same (and the National ITS Architecture subsystems or terminators that the elements are
associated with are connected together), and may or may not be connected if the stakeholder is
different.
Take note of naming conventions of elements and stakeholders, especially if multiple organizations
will be using or defining portions of the complete Regional Architecture. These suggestions will make it
easier to apply Turbo Architecture to your region.
The following discussion involves associations (relationships) between elements and between elements
and stakeholders, and concerns the relationships between the tabbed windows in Turbo. In other words,
changes made on the Inventory tab may or may not be reflected after a Build on the Interfaces tab or on
the diagrams.
On the diagrams, the upper portion of each box displays the stakeholder name, and the lower part of the
box indicates the element name associated with that stakeholder. For example, a user creates two Toll
Collection elements associated with a single stakeholder. These elements both use the Toll
Administration subsystem of the National ITS Architecture. Because the underlying Physical Architecture
includes a terminator called Other Toll Administration, the two toll elements will be connected to each

other. Similarly, if these elements were traffic management elements (centers) they would be connected
to each other because of the underlying National ITS Architecture Physical Architecture (Other Traffic
Management is a terminator, and there is a physical flow that connects the TMS to Other Traffic
Management).
If the user then generates a Traffic Management Center (element) on the Inventory tab (using the same
or a different stakeholder as the two toll elements), then associates this with the Toll Administration and
Traffic Management Subsystems and selects the Regional Traffic Control market package (on the
Services tab), the new traffic element will be connected to each of the two original toll elements after
building the architecture. This also occurs because of the underlying physical connections in the National
ITS Architecture.
If the user then removes the Toll Administration subsystem from the associations for the traffic element on
the Inventory tab, re-building the architecture will make no difference to the Interfaces tab or the
Interconnect diagram. Toll Administration data flows remain connected to this traffic element and are
not removed by re-building. The user must go to the Interfaces tab and uncheck the Include box so that
these flows are no longer connected to the traffic element in the current Project or Regional Architecture.
This also changes the status of these flows to Not Planned. Then, the Interconnect diagram will no
longer connect the traffic element to the two toll elements.
5.4 Mapping between Elements and Entities

The inventory mapping exercise is critical to being able to build the right architecture. Take time to review
the functionality of each of the local elements and develop an understanding, or at least a working
familiarity, with the subsystems and terminators of the National ITS Architecture.
A common mistake is to map a local element to too many of the National ITS Architecture entities. It may
sound like it makes sense to map a lot of different subsystems since it is supporting a lot of activity. For
example, a surveillance camera in a regional architecture has been mapped to Emergency Management
because its supporting emergency response activities but its also in the field so map it to Roadway
subsystem. Complex mappings like this lead to too many requirements being selected, too many flows
being assigned, or too few flows since everything is inside one box. Turbo will catch the times when an
element is mapped to entities of different classes, e.g. field and center, and provide the following warning:
Figure 188. Complex Subsystem/Terminator Mapping

The user can still say yes if it really makes sense for the region or project but this should be reconsidered
before continuing too far into the development process.
5.5 Iterations through Turbo

Certain steps during the architecture creation process do not have to be done in any order. For example,
a user may re-enter the Inventory Generation step (Inventory tab) at any time during the process after
creating the initial element inventory.
Where applicable, the tool will allow iterations in the process of defining a Regional or Project
Architecture. The user may create an inventory of elements associated with subsystems and terminators,
map to market packages, and create an initial list of architecture flows (through the Build step). He may
then reassign an element to a new subsystem (Inventory tab), terminator (Inventory tab), or market
package (Services tab), select other market packages (Services tab), select new architecture flows
(Interfaces tab), or de-select architecture flows (Interfaces tab) from his Regional or Project Architecture.

This is all done on the tabbed windows, after initial architecture selections have been made via the
Interview Dialog.
Where applicable, i.e., where process steps are sequential, if a previous step has not been completed,
the tool will not allow the user to continue until it has completed successfully. This does not apply to the
iterative steps in the process. In most cases, a Build must be done before any outputs can be
generated (reports or diagrams). If there is no data for a report or diagram, then a popup window will
appear saying this. The steps below must be completed before data may be available for these outputs.
If a Build (i.e., the Build option on the Interfaces tab) has not been done, there is no data available for
the Interfaces window, and this table will be blank. The tool finds all situations possible to prevent an
empty window from appearing, or from allowing a user to attempt an option that must be preceded by
some other option.
The following is a list of processes or steps in Turbo Architecture and what prerequisite processes or
steps (if any) are associated with them:
1. The user can characterize market packages before selecting an element inventory (characterizing
subsystems and terminators) in the Regional or Project Architecture. Market packages may be
selected. However, elements must exist in order to associate the market packages to elements,
so after entering new elements on the Inventory tab, you must return to the Services tab to
associate the elements to the selected market packages.
2. The user will be able to return to the Inventory and Services tabs and remove market package
associations (i.e., disassociate them from the architecture) if he has only previewed the
uncustomized architecture in the Build step (before answering Yes to the final question about
adding the flows to the architecture and to the Interfaces tab). After completing the Build, if a
market package association is removed from the architecture, the associated interconnects and
flows must be deselected manually on the Interfaces tab. Build is an additive function it does
not remove anything from previous builds or customization.
3. The customization step for the architecture cannot be executed before subsystems or terminators
(or market packages) have been characterized from the National ITS Architecture. There will be
no source or destination elements, and no architecture flows defined between them.
GUIDELINE: Once the user enters the Interfaces tab and begins to customize the architecture,
he may return to the Services tab to change market package associations, or he may return to the
Inventory tab to change element/stakeholder mappings. A new Build will pick up any new element
and flow selections, but not change his customization.
4. The Extend step to add user defined entities or flows to the architecture cannot be executed
before subsystems, terminators, or market packages have been characterized from the National
ITS Architecture.
5. The Extend step can be executed before or after the customization step. If after, then a Build
should be done before Customize on the Interfaces tab to pick up any new user defined flows.
6. The Merge step (i.e., the Project to Region option on the Start tab) can be executed once a
Project Architecture has been defined in the open database file (Build the project before
Merging it into the Regional Architecture). This step may be used to initially define a Regional
Architecture from an existing Project Architecture. To do this, simply create an empty Regional
Architecture (select Skip the Interview when creating the architecture), and return to the Project
Architecture that is to be merged.
7. The Standards Activities report for the architecture cannot be generated before subsystems,
terminators, or market packages have been characterized from the National ITS Architecture, and
a Build has been completed.
8. The Standards Activities report for the Regional Architecture can be executed before or after the
customization step.
9. The Interconnect Diagram for the architecture cannot be generated before subsystems,
terminators, and market packages have been characterized from the National ITS Architecture.

Architecture flows are required from the Market Package analysis to generate the Interconnect
Diagram.
10. The Interconnect Diagram for the architecture can be generated before the customization or
extend steps.
11. The Flow Diagram for the architecture cannot be generated before subsystems, terminators,
and market packages have been characterized from the National ITS Architecture. Architecture
flows are required from the Market Package analysis to generate the Flow Diagram.
12. The Flow Diagram for the Architecture can be generated before the customization or extend
steps.
13. The Project Inventory based on a Regional Architecture Element Inventory step cannot be
executed before a Regional Architecture has been defined. The Regional Architecture may or
may not include a Project Architecture.
14. The Extend the Project Architecture to include additional parts of an existing Regional
Architecture step for the Project Architecture cannot be executed before subsystems,
terminators, or architecture flows have been selected from an existing Regional Architecture.
15. The Extend beyond the Regional Architecture step for the Project Architecture cannot be
executed before subsystems, terminators, or architecture flows have been selected from an
existing Regional Architecture.
16. The customization step for the Project Architecture cannot be executed before subsystems,
terminators, or market packages have been characterized from the National ITS Architecture or
selected from an existing Regional Architecture.
17. The Extend step for the Project Architecture cannot be executed before subsystems,
terminators, or market packages have been characterized from the National ITS Architecture or
selected from an existing Regional Architecture.
18. The Standards Activities report for the Project Architecture cannot be created if no architecture
flows have been identified from the National ITS Architecture or selected from an existing
19. The Interconnect Diagram for the Project Architecture cannot be generated before subsystems,
terminators, and market packages have been characterized from the National ITS Architecture or
selected from an existing Regional Architecture. Architecture flows are required from the Market
Package analysis to generate the Interconnect Diagram.
20. The Flow Diagram for the Project Architecture cannot be generated before subsystems,
terminators, and market packages have been characterized from the National ITS Architecture or
selected from an existing Regional Architecture. Architecture flows are required from the Market
Package analysis to generate the Flow Diagram.

6 Advanced Topics Design Issues

The issues listed below may not be associated with each other, but should be considered while defining a
Regional or Project Architecture.
6.1 Naming Conventions
6.1.1 General Naming of Turbo Items

GUIDELINE: When using the Interview, a center and its associated elements are generally created
as separate elements mapped to various National ITS Architecture entities. When manually
creating new elements on the Inventory tab, the user should also keep this in mind. For example,
when manually creating an element for traffic management with roadside assets, the element should
be divided into two elements, one for the center mapped to Traffic Management Subsystem
(TMS) and one for the field equipment mapped to Roadside Subsystem (RS). Try to include only one
instance of a subsystem or terminator in an element. An example of element naming could be
Phoenix Freeway Management Center Roadside Elements.
GUIDELINE: It is recommended that a Turbo Architecture database file be named based on the
region name.
GUIDELINE: A naming strategy for all user-entered names (element, stakeholder, user defined
entity/flow, project) should be established before designing the initial architecture in a Turbo
Architecture database file. Names should not be too general. The maximum number of characters
visible inside the list boxes is 60 characters (the list boxes will not include horizontal scroll bars,
but the forward and back arrows may be used to see the beginning to the end of the name).
However, when entering an element or stakeholder name, the user may type up to 200 characters
(element or stakeholder name) on the Inventory tab, and 100 characters in the Interview, and
Turbo Architecture will add the suffix to the element name (see Section 6.1.3 for more information
on naming stakeholders).
Remember that when naming an element, stakeholder, architecture, etc., certain special characters
(ampersand (&), apostrophe (), and quotes ()) may not be used in the name. Turbo will give a warning
message and not allow these names. Blanks, underscores (_), hyphens (-), are all acceptable in a
named item in Turbo Architecture.
Table 5. Maximum Name Sizes in List Boxes
Turbo Architecture Name Item Size (characters)
Element Names 200*
Stakeholder Names 200*
Project Names 100
User Defined Entity Names 100
User Defined Flow Names 100
* Note: Interview questionnaires limit element and stakeholder name entries to 100 characters. To an
element name, Turbo Architecture appends up to a 20-character suffix for equipment types such as
_Kiosks or _Roadside Equipment, making an element name 120 characters max in the Interview.
Nothing is appended to the stakeholder name it remains 100 characters max in the Interview. Once the
Interview step has been completed, these names may be edited to include up to the 200-character limit.

6.1.2 Element Names

GUIDELINE: It is recommended that a Turbo Architecture element be named based on the
stakeholder name.
Recommendation: The element name should begin with the stakeholder name, in an acronym form
perhaps. If this is not acceptable to the stakeholders, then some other naming strategy for both element
and stakeholder names should be established as described above. A naming strategy such as this
greatly simplifies the sorting and searching for the desired elements or interconnects, both on the
Inventory tab and on the Interfaces tab. This also minimizes problems with multiple, similar element and
stakeholder names when doing an Import, for example, if multiple projects need to be merged together
but were developed by different people in multiple databases.
6.1.3 Naming Stakeholders

The primary stakeholder will be the name given when the Create Stakeholder button in the Interview, or
the Stakeholders tab, is selected and the information is typed into the window. There may be many
stakeholders involved with an element, but often only one stakeholder will be responsible for the element.
If there is no single primary agency responsible for the element, the primary stakeholder can be defined
as a stakeholder group. The group can then include all of the associated agencies responsible for the
element.
If the Turbo architect does not wish to create a stakeholder group, multiple stakeholder names and
points of contact information may be added to the architecture in several ways. These stakeholders may
own, operate, or maintain the element, or have various other responsibilities. As an agency coordinating
the efforts of many private and public ITS concerns, listing all the players may be essential.
One method of creating secondary stakeholders is to add the name and contact information as
part of the description of the primary stakeholder.
Another way of naming a secondary stakeholder is to create a compound (or composite)
primary stakeholder name. For example, a primary stakeholder called Oakland City
Government may include two related stakeholders called Marin County Government and Marin
Port Authority. This may be represented as a compound primary stakeholder name: Oakland
City Government_ Marin County Government_ Marin Port Authority. This compound stakeholder
may then be associated with elements dealing with Oakland City Government or the Marin
County Port Authority, possibly using such acronyms as OCG and MCPA to begin the element
names. The maximum number of characters in a stakeholder name is 200. This name may be
copied from the name field into the description field and then be broken apart, adding the
address, contact name, or other information. The Edit => Copy (CTRL+c) and Edit => Paste
(CTRL+v) options on the menubar may be used to copy the names into the description field of the
stakeholder. Remember that the stakeholder name field is simply a text field (as are all other
name fields), so any naming convention that you wish could be used to represent multiple
stakeholders. Make sure to use this naming convention consistently throughout the architectures,
so that the elements that need to be connected via the stakeholders will be correct.
Another method of naming a secondary stakeholder is to create/use a name that reflects the
identities of the stakeholders, such as TRANSGUIDE.
The type of naming convention should be agreed upon at the beginning of the Project or Regional
Architecture definition. The stakeholder and project are assigned to the element on the Inventory tab. It
is not required to enter a stakeholder for each element. The stakeholder name may be listed as
unidentified. The Stakeholders report includes the stakeholder names/groups and descriptions
(including unidentified) and the elements they are associated with.
Remember that the Interconnect and architecture Flow diagrams will only list the primary stakeholder
or stakeholder group in the top of each box. This may be a single name or a compound name, as
described above. In the element boxes on the diagrams, only 34 characters (and ) are visible for the
stakeholder name (unless there are many connections into the box, which is then displayed in a wider
format). Long names are truncated. You can review the description of the stakeholder from the
Stakeholders tab.

6.2 Keeping Project Architectures in Separate Database Files

GUIDELINE: One way to prevent automatic overwriting to the Regional Architecture when changes
are made to the Project Architecture is to keep them in separate Turbo Architecture database
files. Then, when a user is ready, import the project into a destination database file, and merge it
into the Regional Architecture in that file.
GUIDELINE: If a Regional Architecture exists, the Interview Dialog should not be used to create
a Project Architecture from the Regional Architecture. If the user wishes to create a Project
Architecture without the Regional Architecture, a new database file may be created to hold this
new Project Architecture. The Project Architecture may then be created using the Interview
Dialog. The new Project Architecture may be imported later into the other database file, then
merged with the Regional Architecture.
6.3 Status of an Architecture Component

GUIDELINE: The tool requires that an element or market package be exclusively designated with a
deployment status value, even though the element or market package may contain characteristics
(architecture flows) of more than one of these categories. Users must choose the most
appropriate designation.
Some suggestions follow to accomplish this for the case of existing and planned. Similar
recommendations are made if local status values exist if most flows associated with an element are of
one status value, then that element should be designated as that status.
If 90% of the architecture flows associated with an element are designated with a flow status of existing,
and 10% are planned, for example, then the element should be called existing. If the opposite is true,
the element should be called planned. If it is required for the status of the entire element to be
planned, separate elements should be created for existing and planned. This is also true of market
packages - certain architecture flows may be designated as existing while others are still only planned
for the region. However, a new market package may not be created, so the user must determine whether
he wishes to call a market package existing or planned on the Services tab, then select and change
the architecture flows (selected by Turbo Architecture for that market package) on the Interfaces tab to
the modify the status.
There are other ways to decide if an element should be designated as existing or planned. If the
market package, source or destination element, is planned, then the architecture flows will appear as
planned on the Interfaces tab. Otherwise, the flows should be existing. This can be changed later on
the Interfaces tab.
For example, a database file consists of one Regional Architecture and many Project Architectures. If the
source element and destination element for a flow appear in two different projects, the flow can only have
a single status. If the flow status is changed in one project, it is automatically changed in the other
projects and in the Regional Architecture. (This is a file-wide global change.)
Multiple Project Architectures affect the customization of an architecture flow, but the status is file-wide.
The comment that is associated with a flow by using the Info button on the Interfaces tab is also file-
wide. If a flow is adjusted/customized in one project, then this change is reflected in the other Project
Architectures and the Regional Architecture in this database file.
6.4 How the Build Step Selects Architecture Flows

The user may not expect to see certain flows that the Build step might identify based on the users
Inventory and market package selections. For example, consider a small architecture consisting of
Traffic Management Subsystem (TMS), Roadway Subsystem (RS), and Emergency Management (EM)
subsystem elements. Regardless of market package selections, connections between the TMS and EM,
and between the TMS and RS, appear after the Build step since for some interfaces, Turbo uses

stakeholder information to decide the interfaces to include or not include in an architecture. The flows
may show up as not planned on the Interfaces tab.
In addition to using stakeholders and market package selections to determine how to populate the
Interfaces tab, the Turbo Build algorithm uses the specific market package instance information
entered by the user to list additional flows to add to the Interfaces tab.
NOTE that after a conversion of a previous version Turbo database file, the user is prevented by the
software from adding discontinued flows in subsequent builds. The Build step also previews and
removes unsupported and unplanned flows after conversion. Not planned unsupported flows will be
removed from the Interfaces tab during a Build (discontinued entities and flows will not be removed). In
addition, unsupported flows are deleted by the Build if the user deselects a market package. If an
element was mapped to TMS, for example, but is now remapped to Transit Management Subsystem
(TRMS) on the Inventory tab, a Build removes all TMS flows for that element that have not been
selected yet (i.e., that have not been customized). We do not want to propagate discontinued flows or
non-standard applications of National ITS Architecture flows on the Interfaces tab. See Section 4.1.3 for
a discussion of the conversion process and discontinued flows.
Following the Build, the user should run the Unsupported Flows Report. Check this report against the
Interfaces tab if there are flows listed in the report. If there is an unsupported flow on the Interfaces tab
that is listed as existing or planned (or a local status value), these are not removed by the Build logic.
The user has a couple of options in this case:
1. Remove these flows altogether from the Interfaces tab by deselecting them, i.e., make the status
not planned. In many architectures, these flows will no longer be required, so this may be the
preferred option.
2. If the unsupported flow is actually required in the architecture, then the user will need to create a
new user defined flow that connects the two entities together. The entities may be National ITS
Architecture entities, user defined entities, or a combination.
Section 3.7.1 states that the Build step never reselects a previously deselected interconnect. This is
always true in the current version of Turbo except There is still a scenario where the user creates a
new user defined flow that connects entities that are mapped to elements that were manually
disconnected at the interconnect level. When the user does a Moderate or Aggressive Build with this
new user defined flow, it will be added to the architecture by default, which will have the effect of selecting
a previously deselected interconnect. The user can avoid this problem by using a Conservative Build to
add the flow. Also, the user will normally be working at the flow level, not the interconnect level, when
adding after-the-fact user defined flows.
In addition to the above discussion on how the Build selects interconnects and flows in general, some
specific information should be addressed about Project Architectures. The Build step will include a
triplet (source element, architecture flow, destination element) on the Interfaces tab for a Project
Architecture by default when all of the following criteria are satisfied:
1. The architecture flow is included in a market package that is associated with the project.
2. Either the source element OR the destination element is associated with the project.
3. Either the source element OR the destination element is associated with the market package
identified in #1.
4. If the software does permutation filtering on the interface, then the same stakeholder must be
associated with both the source and destination elements.
6.4.1 Project vs. Region Build Selection Process

There are some differences in the way in which information flows are selected depending on whether you
are in a Regional or a Project ITS Architecture.
For a Regional ITS Architecture, Turbo adds the interface if the Source AND Destination are in
the regional inventory.
For a Project ITS Architecture, Turbo adds the interface if the Source OR Destination are in the
project inventory.

The rationale is that the regional ITS architecture inventory of elements tends to be fairly inclusive trying
to capture the entire scope of ITS over the next several (10-20?) years. With that scope in mind, the
Build should only need to worry about the interfaces between elements that are completely within the
scope of the regional architecture. The few exceptions might be particular instances of elements that are
being deployed in a project. Their parent elements are already in the regional level so the Build for the
region does not have to add the instances.
A project, on the other hand, is typically focused only on the elements the systems and equipment
that are being deployed within the scope of that one project. However, that element being deployed may
be connecting back to an existing center element. It is for this reason that the build logic is different for
projects to be able to make the interfaces from the project elements to other elements in the region
visible on the Interfaces tab and available for selection.
Shown below is the inventory screen for a new project within the Marinara county database.
Figure 189. Project Architecture Inventory Screen with an Element Instance

The Environmental Sensor Deployment Project has only one element: MCDOT Environmental Sensor
Stations. Note that it is not included in the regional architecture, just the project architecture. Note also
that the project also only has one Market Package: MC03 Road Weather Data Collection and the only
element assigned to it is the MCDOT Environmental Sensor Stations.
Shown in the next figure is what happens when you do a Build for the Project:

Figure 190. Moderate Build, New Element Part of Project

There is only one element in the project but the Build process looks at the selected market package and
identifies 6 potential flows to or from, in this case, a RS and any TMS or Maintenance & Construction
Management Subsystems (MCMSs). These are still Not Planned at this point since the Moderate Build
option was selected and there was only one element in the market package and project. At least this
way, the Interfaces tab can be used to decide which center this new element should be connected to.
The other option would be to choose the Aggressive Build option and Build will identify the 2 flows
between the roadway subsystem element and the maintenance and construction management
subsystem element as shown below that will then be added to the Interfaces tab with a Status of Planned.
Figure 191. Aggressive Build, New Element Part of Project

Shown below is what happens when you go back to the Regional architecture to do a Build:
Figure 192. Add Interfaces Screen, New Element Not Part of Region
The only change was the addition of a new element but since it is outside the regional architecture (not
checked on the regional inventory screen) there are no interfaces to add to the Regions Interfaces table.

6.5 Managing Subsystem Permutations

When an uncustomized architecture is initially generated in Turbo Architecture, it is possible for all valid
[source element / architecture flow / destination element] triplets for that architecture to be created.
These triplets include all possible permutations of source/destination pairs based on the National ITS
Architecture and will typically number in the thousands for a Regional Architecture. Many of these triplets
will not be selected by the user in the final customized architecture. The task of deselecting possibly
thousands of these irrelevant triplets is very time consuming, but there are a few things that the user may
do to minimize this task.
Turbo Architecture will identify and remove many of these extraneous permutations of subsystem
interfaces. However, the software does not have enough information to generate a perfectly tailored
architecture based on the entity and market package mappings that the user generates. Some must be
removed manually by the user.
Extraneous permutations are defined as sets of interfaces (from those listed below) that do not have the
same stakeholder. Some of the interfaces defined by the architecture rarely span multiple stakeholders.
For example, the TMS to RS interface normally represents intra-agency communications. For these
stakeholder bound interfaces, Turbo Architecture must only select triplets by default that represent
communications between elements that are owned or operated by the same stakeholder.
For example, multiple TMSs and RSs are defined. Turbo Architecture connects each TMS to each RS.
The TMS's and RS's should be paired in sets of two one TMS connected to one RS, per stakeholder.
However, if a user needs to share elements between subsystems, the tool will allow this.
Another permutation example:
A Freeway Management Center is mapped to freeway roadside elements.
A City Traffic Management Center is mapped to city roadside elements.
After initial data entry, all four elements/centers/systems may be connected to each other and must be
corrected.
Some connections are resolved by the tool, where others may be impossible to resolve and will have to
be done manually by the user. The tool will assist the user to the extent possible with resolving
permutations. The user may also view the list of subsystems, terminators, and architecture flows on the
Interfaces tab to determine which were included because of the permutation problem and should be
deleted. The only stakeholder bound interfaces (in the National ITS Architecture) where this applies are:
Table 6. Stakeholder Bound Entity Interfaces Automatically Resolved by Turbo
Commercial Vehicle Subsystem (CVS) to/from Fleet and Freight Management (FMS)
Emergency Management (EM) to/from Emergency System Operator
Emergency Management (EM) to/from Emergency Vehicle Subsystem (EVS)
Remote Traveler Support (RTS) to/from Transit Management Subsystem (TRMS)
Roadway Subsystem (RS) to/from Traffic Management Subsystem (TMS)
Toll Collection Subsystem (TCS) to/from Toll Operator
Traffic Management Subsystem (TMS) to/from Traffic Operations Personnel
Transit Management Subsystem (TRMS) to/from Transit Operations Personnel
Transit Management Subsystem (TRMS) to/from Transit Vehicle Subsystem (TRVS)
NOTE that in order to connect elements associated with these subsystems together, e.g., connect a TMS
element to an RS element, both elements should have the SAME stakeholder name. Whether or not they
have the same stakeholder, initially, these connections will be not planned unless the user selects a
market package to associate with both elements. These elements will both be selected on the Element
Selection list and displayed on the diagrams.

NOTE that Turbo does not use this stakeholder-bound interfaces logic when selecting flows to be
included on the interfaces tab when the intermediate Related Flows include option is selected. All
possible permutations will appear on the interfaces tab for all build options, limited only by market
package choices/associations in the related flows option. However, Turbo does use this stakeholder-
bound interfaces logic when autoselecting flows to be included in the architecture by default in the
moderate and aggressive build settings.
The user should complete the Inventory, select the Services, then Build and customize the architecture
on the Interfaces tab. After these steps, the Regional Architecture, Project Architecture, and
Additional Integration Options reports for both the Regional and Project Architectures may be displayed
that lists the permutations that were created during the initial data entry.
The user Builds the architecture when the system inventory and market package mappings have been
completed to the users satisfaction. This is the only time that the permutation filters will be applied.
Because this generation process is somewhat different between Regional and Project Architectures, the
permutation requirements are addressed differently by the tool in the two cases.
During the customization on the Interfaces tab, the user will be asked for element name with the option
to look at All. All will include a Connect and an architecture Flows view for all interconnections
between elements, and all architecture flows in the architecture. All subsystems may be connected to all
subsystems through the source and destination elements and flows listed. This must be corrected on this
screen. Interconnects may be defined at the element level, e.g., TMC to Field connections.
On the Interfaces tab, it is recommended that the user look at the Connect view first and remove
extraneous permutations there before examining the architecture Flows view and deciding which
architecture flows should be removed. However, if he wishes, he may look at the Flows view first, then
continue with the Connect view. The user will be able to move from interconnect to flow or from flow to
interconnect views during the customization process. See Section 3.7.2 for more information on the
Interfaces tab and for suggestions for maintaining consistency between the interconnects and flows
selected (if a partial interconnect is required).
GUIDELINE: If a stakeholder owns both a TMS and RS element, they probably should be
connected.
6.5.1 Regional Architecture Permutations

As the final step in the uncustomized Regional Architecture generation process in the Build step, the
tool will attempt to deselect all flows that connect different stakeholders on the identified interfaces. This
process does not deselect an architecture flow if it has been manually selected or customized already by
the user. In the general case, this should never occur since this query will be run as part of the
uncustomized architecture generation process.
6.5.2 Project Architecture Permutations

In the uncustomized Project Architecture generation process during the Build step, the valid triplets are
added to the Project Architecture by the tool. Invalid permutations are identified exactly as they were
before, and the entries are deleted from the Project Architecture by the tool. Also, there is no need to
deselect the flows in the Regional Architecture since these flags are not set by default when a new
uncustomized Project Architecture is generated. In this case, the tool will delete the references to
stakeholder spanning flows in the Project Architecture.
6.6 Maintaining Consistency between the Regional and Project Architectures

The steps in the design of a Regional or Project Architecture are not necessarily sequential. The user
may initially create an inventory of elements, mapped to National ITS Architecture subsystems,
terminators, and market packages, and generate an initial list of interconnects and architecture flows (via
the Build step). He may then wish to customize his selections on the Interfaces tab. The user may tailor
the list of interconnects and architecture flows, select or deselect certain flows, or extend the architecture
to include locally defined (user defined) entities and flows. He may also reassign an element to a
different subsystem or terminator, or add an additional subsystem, terminator, or market package

association for an element (via the Inventory and Services tabs). The process will be an iterative one and
will allow this flexibility of design.
The tool will provide some consistency checking (between Regional and Project Architectures through
output reports), but not automatically resolve these conflicts. The user may review several reports to
identify certain types of possible conflict situations in order to improve the consistency in the architecture:
Region to Project Comparison report
Inventory to Market Package Comparison report
Additional Integration Options for Regional and Project reports (these are 2 reports)
Updates to an architecture may be either global or local to the database file. If changes are made on the
Inventory and Services tabs while in a project, these changes will be reflected in the Regional
Architecture, and vice versa. These are changes that are global to the database file. This applies
ONLY to element inventory, entity, project, and status changes on these windows (see the appropriate
sections of this manual for an in-depth discussion of using the various tabs in Turbo).
For changes local to a project, in order to regain consistency of architecture flows and interconnections
between the Project Architectures and the Regional Architecture, such as customization done on the
Interfaces tab in a project, the Project Architecture MUST be merged (or merged again, if previously
done) into the Regional Architecture via the Project to Region option on the Start tab.
Once customization of the architecture takes place, returning to the inventory and market package
analysis will not cause any tailoring to be lost. The Build process is additive and will not change
previous customization when a second Build is done. If the elements or market packages (that result in
architecture flows being added to the architecture) are reassigned or their attributes or associations are
changed on the Inventory or Services tabs after already being customized on the Interfaces tab, then
these changes will not be reflected in the Build. The user must manually deselect interconnects and
flows on the Interfaces tab to reflect the changes made on the Inventory and Services tabs to flows that
have already been customized. This will require some knowledge of the National ITS Architecture (what
flows are actually selected for each market package, and how they connect between subsystems and
terminators in the National ITS Architecture).
NOTE: If flows have been deleted from the Project Architecture, then Project to Region (to merge the
project into the regional) and the Build are not necessary. They will not change the Regional
Architecture. The flows must be deleted manually from the Regional Architecture. The Build option
only adds new elements and flows to the Interfaces tab (for instance, if a new inventory element was
created or a market package was selected), and Project to Region only makes the two architectures
consistent if customization has been done to the project.
GUIDELINE: If an interconnect is selected in the Regional Architecture that is already in the
project, only flows are selected that are in the Regional Architecture. If an interconnect is
removed in the Regional Architecture, it does not affect the Project Architecture.
GUIDELINE: One way to prevent automatic overwriting of the Regional Architecture when changes
are made to the Project Architecture is to keep them in separate Turbo Architecture database
files. Then, when a user is ready, he may import and merge a project into the Regional
Architecture. It may be confusing if the Regional Architecture keeps changing more than one
person may be using the file, updating different projects, and as a result, updating the Regional
Architecture.
In order to maintain consistency between the Regional and Project Architectures, they must be
maintained in the same file. As stated above, certain changes to a project are global to the file, while
customization is not (a second Merge is required, via the Project to Region option on the Start tab). If
the architectures are managed in separate files, then the projects may be re-imported into the Regional
Architecture file. There are issues with managing the architectures this way:
The first Import will import the project names and all elements and their associations, provided
the Regional Architecture in the destination file does not include elements of the same name

(then their associations win, and if the project elements are the ones that are actually required,
then the user will need to update these elements with the associations from the source file).
If the projects are being managed and customized in the separate file, a second Import will be
required to maintain consistency with the Regional Architecture in the other file. However, one of
the projects will need to be renamed, since the project was already imported into the destination
file. Also, the elements will already exist in the destination file, so if some of their associations
have changed in the source file, these will need to be made again in the destination file after the
Import.
The imported projects must finally be merged into the Regional Architecture, and a new Build
performed.
Examples of maintaining consistency between the Regional and Project Architectures:
1. Example 1 (no customization, no merge):
a. Create a Project Architecture with elements to be connected to each other, and participating
in at least on market package together.
b. Build the project via the Build option on the Interfaces tab.
c. The Interfaces tab includes these source and destination elements and their flows provided
that both the source and destination elements are not not planned. Otherwise, the flows
and interconnects are listed as not planned.
d. Create an empty Regional Architecture, skipping the Interview, or open the architecture by
selecting the name on the Start tab if it already exists.
e. Include the elements and market packages from the project into the region using the
Inventory and Services tabs, respectively.
f. The Interfaces tab initially includes the project elements and flows as not planned and not
included in the Regional Architecture.
g. Build the Regional Architecture via the Build option on the Interfaces tab.
h. The Interfaces tab now includes these source and destination elements and their flows, the
same as in the Project Architecture.
2. Example 2 (customize the Project Architecture, merge with Regional Architecture):
a. After following the same steps as above the two architectures are consistent.
b. Open the Project architecture again (by selecting the name on the Start tab).
c. Customize the Project Architecture on the Interfaces tab. Select or deselect certain flows
based on project-specific requirements.
d. Open the Regional Architecture and notice that some of the customization of the Project
Architecture is not yet reflected in the Regional Architecture, while a portion of the
customization may be reflected.
e. Open the Project Architecture.
f. Merge the Project Architecture into the Regional Architecture (Project to Region option on
the Start tab). Now the Project and Regional Architectures are again consistent.
In summary, Adding new flows to an architecture is done in the Project or Regional Architecture. This
may be done on the Inventory tab by associating an element with an entity (subsystem, terminator), or on
the Services tab by selecting a market package and associating it with an element (this will be
decomposed into architecture flows by the Build step). Updating associations is done in the Project
Architecture and may automatically update the Regional Architecture. If a global item, such as a
stakeholder name, is changed in the project, this is automatically reflected in the Regional Architecture. If
a project-specific item, such as a flow inclusion, is added or changed in the project, this does not
automatically update the Regional Architecture, and the project will need to be merged into the Regional
Architecture again via the Project to Region option on the Start tab. Any customization done in the
projects must be merged into the Regional Architecture. These are not global changes. The safest thing
to do when in doubt is to re-merge the Project with the Regional Architecture. Do no try to figure out how
what you changed affected the Regional Architecture, since if you forget that you made a small
customization change, this will not be picked up in the Regional Architecture.

6.7 Multi-Phase Projects

GUIDELINE: The tool supports definition of a multi-phase project where each phase may be
represented as a separate project in the database, or as additions/modifications to the initial
Phase 1 Project Architecture.
6.7.1 Multi-Phase Strategies

A decision should be made at the beginning of a multi-phase project as to the architecture design method
that will be used (separate Project Architectures for each phase, modifications to a single Project
Architecture, or completely separate database files for each phase). Although the tool does not support a
direct project copy capability within a single Turbo Architecture file, through the Import and Project to
Region (Merge) capabilities it will be possible to create projects that build upon each other.
If some users choose one design method and others choose another method, it will be very difficult to
reconcile them near the end of the project design cycle. Making a decision at the beginning is preferable
and less costly than trying to fix it at the end of architecture development. Many people may have a hand
in defining a Project or Regional Architecture. Each Project Architecture may be designed by a different
person, and another person may be in charge of the Regional Architecture that combines the projects, in
a large region. Of course, it is up to the region how the personnel will be assigned to the various
architecture definition tasks.
One type of multi-phase strategy using separate Project Architectures in a single database file, and
National ITS Architecture market packages, may be developed as follows. [There are many ways to
define phases of a project. This is one method.]
Many of the market packages are incremental, such that, beginning with a set of basic market packages
in the first phases of a project, more advanced market packages can be added incrementally based on
early deployments (or phases) using separate Project Architectures that include these basic market
packages. This involves progressive implementation of more aggressive User Services and integration
into state and local planning. In the later phases of a project, inclusion of these more advanced market
packages will result in additional interconnections and architecture flows appearing in the Build step (the
Build option on the Interfaces tab), on the Interfaces tab, and in the architecture.
On the Services tab, a selected market package may have a status of existing, for example, but certain
elements associated with this market package are existing and others are planned, while other
elements have not yet been defined. This is part of the phased implementation. The only way to view the
status of an element is on the Inventory tab. Later phases of the project will require the user to change
the status of certain elements, market packages, or flows.
6.7.2 Market Package Plan

A good idea to begin a phased (progressive) implementation is to develop a Market Package Plan for
the phases of the project. The identification of problems, inventory of regional transportation system
assets, and cultivation of institutional coalition that begin the ITS Planning Process were familiar to the
regional planner before ITS and are largely unaffected by the National ITS Architecture. However, the
National ITS Architecture will aid in the solution to these problems (i.e., acting as a plan), and Turbo
Architecture will aid in the implementation (i.e., a Project or Regional Architecture defines how the plan is
implemented). This process is described in the Market Package document on the National ITS
Architecture CD-ROM and web site, and includes a table that may help in determining the market
packages that should be selected for the particular user need or problem being solved in each phase.
Once the plan has been developed that documents the ITS services that should be deployed in a region,
the regional framework in which these services will be deployed should be defined. The National ITS
Architecture provides a general framework that may be adapted and elaborated into a broad range of
regional transportation system designs. A Regional Architecture is a key product of this process that
begins to overlay major technology and interface choices that are appropriate for the region onto the
more general National ITS Architecture definition. Adoption of a Regional Architecture hinges on
continued coordination and consensus among involved stakeholders. How to arrive at a Regional
Architecture from the various phases of a Project Architecture is described in the following paragraphs.

6.7.3 Multi-Phase Projects in Turbo Architecture

Although there may be other methods to accomplish this within Turbo, this section presents three ways
that a multi-phase project may be represented in Turbo Architecture.
1. Define all phases of a project using a single Project Architecture. This method will maintain
consistency between all phases of the project, but the user may not easily separate the phases
when displaying diagrams or reports. It is also possible to use the Status Values to each phase.
If a single Project Architecture has been used to represent all phases of the project, then this
project may be merged at various times (once at the end of each phase, or whenever is
appropriate) into the Regional Architecture in this database file using the Project to Region
option on the Start tab. In this case, all phases of the project will be combined into single
Subsystem, Interconnect, and Architecture Flow diagrams.
2. Use a separate Project Architecture, identified with separate timeframes on the Start tab to
define each phase of a project. Each project could build on the previous one, but this method
separates the functions of each phase of the project. This method will also maintain consistency
between all phases of the project. This may make it easier to review the diagrams and reports for
each phase of the project. If separate Project Architectures in a single database file have been
used to develop a multi-phase project, they may be combined together using the Project to
Region option on the Start tab into a single Regional Architecture in this file. Each Project
Architecture representing a phase of the project should be merged into the Regional Architecture
at the end of the phase, or whenever is appropriate.
3. Represent each phase of a project using a separate database file. This is not the recommended
method since consistency between different phases of the project will be difficult to maintain
they are combined into a Regional Architecture in a single database at the end of each phase (or
whenever is appropriate). This method could be used for very complex projects when it is
desired to keep each phase completely separate from the other phases. If separate database
files have been used to represent each phase of the project, the Project Architectures in each file
may be combined into a single Regional Architecture by using the File => Import and Project to
Region options. A new database file must be created and the projects from the other files
imported into it, then merged into the new (empty) Regional Architecture in the new file. A
Regional Architecture can be imported into another file in Turbo by first converting it to a Project
Architecture. However, it may be easier to maintain consistency throughout if designing all
phases using Project Architectures, then create the Regional Architecture last to contain all
projects, customizing only the projects. Hence, each diagram and report in this Regional
Architecture may include all elements, interconnects, and flows from all phases of the project. If a
region is defining a Strategic Deployment Plan, Turbo can help by using the timeframe feature.
6.8 Two-Tier Architecture

The most common approach to architecture development using Turbo Architecture is a two-tier
architecture. This approach is described in Section 1.6, where the bottom-up and top-down methods are
discussed. The user may begin by creating Project Architectures that address certain aspects of a
transportation problem or planned ITS projects for a portion of the local region. These projects may later
be combined (using the Project to Region (Merge) option on the Start tab) into a Regional Architecture
that includes the definition of many ITS projects (both planned and existing) for the local region. OR, the
Turbo Architect may begin with the Regional Architecture and break it down into the planned ITS projects
for the region (this method is discussed in Section 5.2.2).
The Regional and Project Architectures may be represented in Turbo Architecture in several ways:
1. In a single database file, include all the Project Architectures and the Regional Architecture,
created by either the top-down or the bottom-up method. This method is the most accurate and
maintains consistency between the architectures, since the system will keep track of problems,
and display warnings, whenever discrepancies between interconnects, flows, elements, etc., are
found. In addition, using a single database file guarantees consistency between the
architectures, in that changes made in the Project Architectures are reflected in the Regional

Architecture (except for customization, which is reflected in the region after merging the project
into the Regional Architecture).
Error! Objects cannot be created from editing field codes.
Figure 193. Two-Tier Architecture Single Database
2. In one database file, create all the Project Architectures. There will be no Regional Architecture
in this file. At the appropriate time, import the Project Architectures into a second database file,
create an empty Regional Architecture, and merge the projects into it. This method is also
accurate, since all the Project Architectures are included in a single file, and the discrepancies
that may arise between projects can be handled easily by Turbo Architecture.
Error! Objects cannot be created from editing field codes.
Figure 194. Two-Tier Architecture Two Databases
3. Use a separate database file for each Project Architecture, and at the appropriate time, import
them into a new database file. Finally, create a new Regional Architecture in this file and merge
the projects into it. This method is the least likely to provide the desired results, as similar
element and stakeholder names will need to be resolved manually after merging the projects
together. This assumes that one project may have used a blank, and another an underscore,
between parts of a name, for example. However, if the naming conventions can be agreed upon
and used consistently in each project, this method has the advantage of keeping the projects
separate so that they do not interfere with each other.
Project 1 Not Yet

Project 5 Merged
Import
Project 2 Project 1
Import Merge
Project 3 Project 2 Merge Regional

Import Architecture
Project 3 Merge
Not Yet
Project 4 Imported
Figure 195. Two-Tier Architecture Multiple Databases
6.9 Three-Tier Architecture

In addition to creating a multi-phase architecture for a project and a two-tier architecture, the region may
wish to represent a three-tiered approach to architecture definition. This may be used to define a
statewide architecture, a corridor architecture, or a larger Regional or City Architecture.
NOTE: This involves using different database files to maintain the various levels of these architectures.
Customizing projects in the lower level databases may cause consistency problems between the projects.
On-going coordination may be an issue, and the reconciliation process (after import) is performed
manually. BE AWARE OF THIS and meet with your stakeholders periodically to minimize coordination
problems. See Steps 7 and 8 below Turbo Architecture at this time does not handle this on-going
coordination between databases. There are a couple of ways to develop a three-tier architecture (for
example, statewide, regional, and project) based on the existing Turbo Architecture tool.
One approach may be carried out as follows and as appears in the next figure:

Not Yet
Corridor Merged
City Merge Project 6
Project 1 Customize Customize
City Merge Corridor

City Merge Regional City
Regional
Project 2 Architecture Project 4
Architecture
Merge
Not Yet Create
City Import Create
Merged Project from Corridor
Project 3 Regional Project from
Project 5 Regional
City
Project 4 Corridor
City Database Corridor Database Project 7
Not Yet Statewide

Merged Project 9 Import
Customize
Statewide
Merge Corridor
Regional
Architecture Project 7
Merge
Statewide
Project 8
Statewide Database
Figure 196. Three-Tier Architecture Customize Regional Architectures

1. The user creates a database file that defines the statewide architecture (e.g., Arizona) as the
2. The Regional Architectures for the regions in the state are represented as projects to the
statewide Regional Architecture, e.g., the statewide Regional Architecture includes multiple
projects that each represent one of the state's regions (e.g., I-40, Phoenix MDI, Tucson, etc.).
3. Each of the projects (representing the regions in the state, such as Corridor Project 7 above)
identified in the statewide Regional Architecture can be imported from separate database files to
represent individual Regional Architectures.
4. Each of the local (city) and corridor (larger region) Regional Architectures can be used to create a
large (customized) Project Architecture for this level of the three-tier architecture. This Project
Architecture is then imported to the next level of architectures (city to corridor projects, or corridor
to statewide projects, for example). This assumes that customization is done in the Regional
Architectures, or if customization is done in the projects, that the projects are merged again into
the Regional Architectures. See the above diagram and Section 6.13 for information on
converting a Regional Architecture into a Project Architecture that may then be imported to the
next higher level database file and merged into the Regional Architecture in that file.
5. The result of this process would be a set of Turbo Architecture database files that together
represent a three-tiered architecture for a state. The statewide architecture file documents the
relationship between statewide and Regional Architectures.
6. A separate architecture file for each region documents the relationship between Regional and
Project Architectures for each local region.
7. This provides part of the desired capability, but does not allow on-going coordination between the
architecture files. On-going coordination would probably require use of the import process to
import changes back from each of the Regional Architecture files into the statewide architecture
file. This function is not currently included in Turbo Architecture. At present, Project
Architectures may be imported, and a Regional Architecture may be imported after converting it
to a project.

8. The reconciliation process (after import) is performed manually.

Because the Import option is only available for Project Architectures, if the following statements are not
true for your architecture, refer to Section 6.13 (you must create a project from the Regional Architecture):
1. If the regions of a state have already been represented by separate files that each contain a
Regional Architecture and several Project Architectures,
2. AND these projects have been merged (using the Project to Region (merge) option on the Start
tab in Turbo) to create the Regional Architecture for each local region,
3. AND the Regional Architecture for the local region has not been customized (all customization
has been done at the project level),
Then each of the separate Project Architectures may be imported into the statewide architecture
database file and merged into the statewide Regional Architecture. This also assumes that:
1. Element and stakeholder names between each of the Project Architectures are unique,
2. Or if they are identical, that they were meant to be that way (i.e., all attributes, entity associations,
architecture flow status, and flow names are the same).
Remember that after the first Import of a Project Architecture, that project name will already be included
in the destination file. One of the projects will need to be renamed before a second Import of that
project may be done. Merge may be performed multiple times for a given project without worrying about
renaming the project or any elements.
A second method of creating a statewide architecture follows. Using this method, a region would
customize the projects to manage a statewide architecture, not customize the Regional Architectures.
This process involves customizing the Project Architectures, and although they may be merged into the
Regional Architectures in their respective databases, the projects themselves are imported to the next
level database, and merged into the next level Regional Architecture.
Customize
Customize Projects
Projects Import City
City Project 1
Merge Project 1 Merge
City Merge Corridor

Regional City City
Merge Import Regional
Architecture Project 2 Project 2
Architecture
Merge
Import
Not Yet City Corridor
Merged Project 3 Project 4
Import
City Database Corridor Database
Customize Import
Projects City
Project 1
Merge
City
Statewide Merge Project 2
Regional
Architecture Merge
Corridor
Project 4
Merge
Statewide
Project 5
Statewide Database
Figure 197. Three-Tier Architecture Customize Project Architectures

6.10 Working with Large Architectures

The following are a few general guidelines for developing large architectures. See the Regional ITS
Architecture Guidance Document for more information about how to develop a Regional Architecture.
Depending on the amount of space, running speed, and other parameters of your machine, VERY large
architectures may begin to degrade the system performance. There are also maintenance issues with
large architectures a region will spend many weeks customizing a very large architecture on the
Interfaces tab. There are ways to minimize the time spent on this tab.
1. The following describes several ways to deal with architectures of many hundreds of
interconnects and thousands of architecture flows.
The Problem: Large architectures (e.g., including more than 50,000 architecture flows) are very
cumbersome to work with in Turbo Architecture. Even simple manipulations on the Interfaces tab
(e.g., switching from Connect to Flows view) cause substantial delays. Performance issues
occur during the Build and Customize steps, and when generating the reports and diagrams.
For instance, the Standards Activities Report may take 20 minutes to generate, and consist of
hundreds of pages. The Interconnect and Flow Diagrams would be difficult to generate
without problems. The scale of architectures of this size makes them unmanageable. If you only
spend 10 seconds reviewing each flow, one person month would be spent on the Interfaces tab
to review and tailor an architecture of 50,000 flows.
Suggested Solution #1: The Turbo Architect should look for ways to reduce
inventory/architecture size by developing general elements that map to many similar local
systems. For example, rather than enumerating the 30 local city police and fire dispatch
operations in a region, one or two elements can be identified that represent (or combine) all 30.
The same may be done for an architecture that includes 20 different TMCs they can be
combined into one or two elements. You really do not want to create a region with a table of
60,000 flows that must be maintained! Diagrams must be filtered to avoid problems building and
displaying the diagram.
GUIDELINE: When working with a large architecture (over 10,000 flows), general elements
should be developed in the inventory that represent large numbers of centers or systems,
such as a single element that combines 20 Traffic Management Centers.
Try to keep inventories less than 100 elements and know there will be trouble if the inventory
exceeds 150 elements. This is an easy rule of thumb to apply but you also have to look at the
mix of elements that are being added (e.g., try not to add more than one roadway element per
center). Architectures that exceed 150 elements and 10,000 flows will be difficult to maintain, not
easily understood by the average stakeholder, and impossible to plan with.
Suggested Solution #2: An addition recommendation is to develop large Regional Architectures
using center subsystems only. These are the primary connections of interest at a regional level.
Vehicle, field, or traveler elements will mostly be connected to a center that has control over
them. With regard to focusing on Center to Center interfaces, there are tools in the National ITS
Architecture that help with this focus, since these also tend to be the regional interoperability
interfaces in the architecture. There are filters to filter out certain types of interconnects, for
example, only view center to center interfaces and filter out the rest. The regional interoperability
class of interfaces also includes other interfaces with regional scope, such as the signal
priority/preemption interfaces that are also good topics for inclusion in the Regional Architecture.
Diagrams must be filtered to avoid problems building and displaying the diagram.
Suggested Solution #3: Large Regional Architectures could be developed using a hierarchical
multi-tiered approach similar to the regional and statewide architecture discussion above.
2. There are also limits to the number of flows that can be represented in and out of an element
box on the Flow Diagram (a large Interconnect Diagram can present the same problem). In
some cases, the element box expands to include all flow connections (typically at the middle of
the diagram, where the boxes with the most connections reside). In other cases (typically at the
edge of the diagram), the boxes do not expand and flows may be dropped, or attached to a single

line. One limit to the number of architecture flows seems to be around 87 flows between
elements.
When these problems begin to occur during the plotting (generation) of large interconnect or flow
diagrams, a message will appear warning the operator that the diagram may contain overflow
errors. The user may either continue to plot the diagram, or abort.
Suggested Workaround #1: If your Interconnect or Flow Diagram runs into a plotting or
connection limit, you should break up the diagram into two or more diagrams using the element
selection and/or filtering options.
Suggested Workaround #2: For better readability of a very large diagram:
The diagrams may be zoomed in or out to see specific areas of the diagram, or the entire
picture.
A plotter may be used to generate diagrams, if available, via the File => Print option on
the diagram window, or saved to a file to be plotted later. This will NOT correct the
diagram problem (where many flows connect to a single line), but you may be able to see
it better than on the screen for a very large diagram where zooming may not be enough.
Suggested Workaround #3: For correcting the plotting problem of a very large diagram: If there is
a display problem on the diagram screen and many letters seem to be run together (e.g., flow
names appear to overlap), the diagram may be saved to a file and imported into Microsoft
PowerPoint. In PowerPoint, select the diagram and ungroup it. The font problem should fix
itself. The font can be resized for better readability. Be aware that when importing the diagram
into PowerPoint, there may be certain lines that must be redrawn or moved, if the diagram in
Turbo contained many plotting problems. When the diagram is ungrouped in PowerPoint, some
additional lines may appear that should be deleted near the element boxes. The architecture flow
names may also appear with boxes around them when printed in black and white. These are
some of the issues to be aware of when converting your Turbo diagrams into PowerPoint. It may
be a lot of work to correct the converted diagram. First, try to filter out elements or flows, or
select fewer elements and their connections prior to generating the diagram in Turbo. If this does
not work, PowerPoint or Visio may be an option. It is suggested that you wait to spend the time
editing the drawing on the final deliverable product so you do not find yourself having to throw
away your work.
3. When working with large architectures, do not define elements for personnel and system
operators since there is no standard for them (example: TMC to Traffic Operations Personnel).
Also, do not define a description field containing single or double quotes since certain export
facilities (from the Turbo reports) or editors may misinterpret these characters.
4. One other item to be aware of when working with large architectures is the size of the temporary
file called turwork<time/date stamp>.mdb that is built by Turbo Architecture when working with
a Project or Regional Architecture grows while working on the architecture. The user file may be
compressed by saving the file. However, the only way to compress the temporary file is to exit
and re-enter Turbo. When a File => Save is done, this temporary file is NOT restored to a small
size. The size of the temporary file is a function of the number of flows in the architecture. There
may not be enough space in your machine to handle a Save of this file. If a message appears
saying Save failed, you must compress this file by closing Turbo, opening the
turwork<time/date stamp>.mdb file in Microsoft Access and using the Tools => Database
Utilities => Compact Database option. This will not be possible if Access is not available on your
PC. For this reason, we have the following guideline:
GUIDELINE: When working with a large architecture, you should Save and Save Often, AND
exit and re-enter Turbo (suggestion every half hour). This will ensure that the temporary file
that is generated during Turbo sessions stays at a manageable size.

6.11 General Issues

GUIDELINE: The user may not change a terminator into a subsystem, or vice versa. This will
conflict with existing National ITS Architecture subsystems or terminators. A user defined entity
may be created if this function is needed.
GUIDELINE: If a user changes any of the database files outside Turbo Architecture, there is no
guarantee that the tool will function properly and generate the same outputs as before. If the user
changes any of the output reports or diagrams outside the tool, then re-enters Turbo, these
changes will not be reflected in Turbo.
See Section 2.4 for a discussion of versions of Microsoft Access that are used with the various releases
of Turbo Architecture, and WHY YOU MUST NOT convert between them. You will lose data in the
Access tables if you do this. This is another reason why Turbo Architecture databases must only be
manipulated and managed by Turbo Architecture. Do not open them in Access.
GUIDELINE: Different Turbo Architecture database files may be used for various versions of a
Regional Architecture to illustrate trends over time.
6.12 Maintenance of Turbo Upgrading to a New Release

Versions 1.0 and 1.1 of Turbo Architecture were based on Version 3.0 of the National ITS
Architecture.
Version 2.0 of Turbo was based on Version 4.0 of the National ITS Architecture.
Now, Version 4.1 of Turbo is based on Version 6.1 of the National ITS Architecture.
As the National ITS Architecture is updated will an upgrade of Turbo Architecture be required? Yes, but
exactly what upgrade to Turbo Architecture will be required is a function of the changes made to the
National ITS Architecture. Visit the National ITS Architecture web site to learn what updates to the
architecture have taken place, and what impacts, if any, this has on Turbo. From time to time there may
also be updates to Turbo that may include things like problem corrections and enhancements.
See Section 4.1.3 for a discussion of the conversion of Turbo databases from previous versions of the
tool. These older databases cannot be imported as is into the current Turbo. They must be converted
first, then imported. During the conversion, the original file is retained, and the converted file is created
as a new Turbo database.
6.13 Converting a Regional Architecture into a Project Architecture

This process to convert a regional architecture into a project architecture may be used in several
instances:
1. Your design was done in the Project Architectures, they were merged together into a Regional
Architecture, and the Regional Architecture was then customized instead of customizing the
projects and merging them again into the Regional Architecture.
2. You are using the suggestions in Section 6.9 for creating a three-tier architecture (for your state,
for example), and need to convert the Regional Architectures at the various local and regional
levels into a project to import to the next higher level.
3. You have a need to import a Regional Architecture into another file.
The following is a suggested method for converting a Regional Architecture into a Project Architecture.
Here the general process is to create a project that includes the entire Regional Architecture so it can be
imported into another file using the Import process described in Section 4.1.4.

1. In the source Turbo database file, create, build, and customize the Regional Architecture that is to
be converted into a project.
2. Do a File => Save to save the original database containing the Regional Architecture.
3. Now, do a File => Save As to create a new copy of the database that will include the rest of
the steps prior to Import. This is explained later on, but it will create a safer environment for the
conversion and import of the Regional Architecture.
4. Create a new, empty project in this file and select Skip Interview. The project must be open in
order to convert the Regional Architecture into it.
5. Select the Region to Project option on the Start tab. This option is not available unless a
Project Architecture is open. As in the next figure, highlight the new Project just created and click
the Region to Project button.
Figure 198. Region to Project Conversion

6. If you are in the new Project Architecture, the regional to project conversion will continue:
Figure 199. Region to Project Conversion Continue

7. The process copies the Regional Architecture into the Project Architecture, and displays the
following window when complete:
Figure 200. Region to Project Conversion Complete

8. The conversion process has placed all Regional Architecture inventory elements in the new
project, associated all market package choices with the new project, and maintained all project-
to-element relationships from the Regional Architecture.
9. At this point, the user should do a File => Save to save the changes to this new (temporary)
database, and to save the new Project Architecture that is to be imported. This new database will
only be used temporarily, to hold the Project Architecture that is the same as the Regional
Architecture. You do not want to overwrite the original file (from step 1) with this change. The
reason is that the new temporary file now contains the Regional Architecture twice: once as the
Regional Architecture and once as a Project Architecture. When the import of this project is
complete (after step 10), the temporary file can be deleted. Any changes to the Regional
Architecture should then be made in the original file (from Step 1), or in the imported project (from
step 7).
10. You have now created a Project Architecture that includes all Regional Architecture information.
11. Open Turbo Architecture and use the Import Process to import the Project Architecture that you
just created into the destination file. Once the project has been imported, it can be Merged (see
Section 3.1.1.8) into the Regional Architecture.
12. Delete the temporary file created in step 3 above.
13. At this point, you will have successfully imported a Regional Architecture from one Turbo
Architecture database into another.

7 Interview Dialog Questions

This section lists the questions that will be presented to the user during the Interview Dialog. These
questions can also be viewed within Turbo by selected the View Questions button, see figure below:
Figure 201. Turbo Interview Window

GUIDELINE: It is recommended that the Interview questions be reviewed by the architecture
design team with potential stakeholder input prior to entering the information into Turbo
Architecture.
Each numbered item below represents a line on the main Interview Window that corresponds to a
particular area of questioning, generally by functions of ITS.
1. Commercial Vehicle Operations
Name Center and Identify Stakeholder Associations
Does your State/Regional CV Administrative Center perform (or plan to perform) electronic
credential administrative services?
Does your project/region have (or plan to have) roadside inspection facilities?
Pick name for Turbo-determined element Inspection Facility
Pick name for Turbo-determined element Commercial Vehicles
Does your inspection facility perform (or plan to perform) electronic screening?
Does your inspection facility exchange (or plan to exchange) safety and/or security
information?
Does your inspection facility involve (or plan to involve) an international border?
Do you perform (or plan to perform) a high speed Weigh-In-Motion service?
Does your inspection facility perform (or plan to perform) HAZMAT detection?
2. Emergency Management
Does the center currently perform (or plan to perform) computer aided dispatch of emergency
vehicles?
Pick name for Turbo-determined element Emergency Vehicles

Does the center receive (or plan to receive) incident data from an arterial, freeway, or transit
center?
Does the center send (or plan to send) incident data to an arterial, freeway, or transit center?
Does the center have (or plan to have) preemption lights for signalized intersections or ramp
meters? If not already defined, pick name for Turbo-determined element Emergency
Vehicles
Does the center monitor (or plan to monitor) the transportation infrastructure (e.g., bridges,
tunnels and management centers) for potential threats using sensors and surveillance
equipment? If not already defined, pick name for Turbo-determined element Security
Monitoring Field Equipment
Does the center remotely control (or plan to remotely control) barrier and safeguard systems
to preclude an incident, control access during and after an incident or mitigate the impact of
an incident? If not already defined, pick name for Turbo-determined element Roadside
Equipment
Does the center monitor (or plan to monitor) public travel-related areas such as transit
stations, transit stops, rest stops, and kiosk locations for potential threats using sensors and
surveillance equipment? If not already defined, pick name for Turbo-determined element
Remote Traveler Support
Does the center use (or plan to use) ITS driver and traveler information systems to alert the
public in emergency situations such as child abductions, severe weather events, civil
emergencies, and other situations that pose a threat to life and property?
Does the center monitor (or plan to monitor) and detect potential, looming, and actual
disasters including natural disasters and technological and man-made disasters (hazardous
materials incidents, nuclear, chemical, biological, and radiological attacks) and notify all
responding agencies of detected emergencies? If not already defined, pick name for Turbo-
determined element Security Monitoring Field Equipment
Does the center support (or plan to support) disaster response and recovery, including
coordination of emergency response plans and resources, damage assessment, service
restoration, and transition back to normal operation?
Does the center support (or plan to support) evacuation of the general public from a disaster
area and manage subsequent reentry to the disaster area using transportation resources?
Does the center provide (or plan to provide) disaster-related traveler information to the
general public, regarding evacuation and reentry information and other information
concerning the operation and availability of the transportation system during a disaster?
3. Electronic Tolling
Pick name for Turbo-determined element Roadside Equipment
Pick name for Turbo-determined element Vehicles
4. Freeway Management
Are real-time traffic data collection technologies used (or planned to be used) on any of your
freeways managed by the Freeway Management Center? If not already defined, pick name
for Turbo-determined element Roadside Equipment
Indicate what is used:
Loop Detectors - If not already defined, pick name for Roadside Elements
Closed Circuit Television - If not already defined, pick name for Roadside Elements
Vehicle Probe Readers - If not already defined, pick name for Roadside Elements
Other (e.g., radar) - If not already defined, pick name for Roadside Elements

Does your Freeway Management Center have (or plan to add) environmental sensor stations
to monitor the environmental conditions? If not already defined, pick name for Turbo-
determined element Roadside Equipment
Does your Freeway Management Center currently distribute (or are there plans to distribute)
information to travelers directly using roadside infrastructure on the freeways? If not already
defined, pick name for Turbo-determined element Roadside Equipment
Dynamic Message Signs (DMS) -- either permanent or portable - If not already
defined, pick name for Roadside Elements
Highway Advisory Radio (HAR) - If not already defined, pick name for Roadside
Elements
In-vehicle Signing - If not already defined, pick name for Roadside Elements
Other - If not already defined, pick name for Roadside Elements
Does your Freeway Management Center operate (or plan to add) ramp meters on freeway
entrances? If not already defined, pick name for Turbo-determined element Roadside
Equipment
Preemption for emergency vehicles? - If not already defined, pick name for Roadside
Elements
Priority for transit vehicles? - If not already defined, pick name for Roadside
Elements
Does your Freeway Management Center operate (or plan to add) lane control devices (e.g.,
changeable overhead directional arrows) on the freeways? If not already defined, pick name
for Turbo-determined element Roadside Equipment
Does your Freeway Management Center disseminate (or plan to disseminate) freeway travel
times, speeds, and conditions information to the public?
Internet Web Page - If not already defined, pick name for User Personal Computing
Devices
Pagers or Personal Data Assistants - If not already defined, pick name for User
Personal Computing Devices
Kiosks - If not already defined, pick name for Kiosks
e-mail or other direct PC communications - If not already defined, pick name for User
In-Vehicle Navigation Systems - If not already defined, pick name for Vehicles
TV (interactive or dedicated Cable) - If not already defined, pick name for Local
Television
Other - If not already defined, pick name for User Personal Computing Devices
Does your Freeway Management Center detect and verify (or plan to detect and verify)
incidents? If not already defined, pick name for Turbo-determined element Roadside
Equipment
Does your Freeway Management Center share (or plan to share) traffic data with another
Freeway Management Center or Arterial Management Center?
Does your Freeway Management Center manage (or plan to manage) HOV lanes?
Does your Freeway Management Center manage (or plan to manage) automatic or remotely
controlled gates or barriers that control access to roadway segments including ramps and
traffic lanes? If not already defined, pick name for Turbo-determined element Roadside
Equipment

5. Maintenance and Construction Operations (MCO)

Does your center manage or dispatch maintenance or construction vehicles? If not already
defined, pick name for Turbo-determined element MCO Vehicles
Does your MCO center have (or plan to have) the capability to track MCO vehicles and other
MCO equipment to ascertain their location? If not already defined, pick name for Turbo-
determined element MCO Vehicles
Does your MCO center have (or plan to have) the capability to automate vehicle maintenance
scheduling and manage both routine and corrective maintenance activities on vehicles and
other MCO equipment? If not already defined, pick name for Turbo-determined element
MCO Vehicles
Does your MCO center currently collect (or plan to collect) road and weather conditions data
from environmental sensors located on or near the roadway? If not already defined, pick
name for Turbo-determined element MCO Field Devices
Does your MCO center receive (or plan to receive) weather information from the National
Weather Service? If not already defined, pick name for Turbo-determined element Weather
Services
Does your MCO center receive (or plan to receive) surface transportation specific weather
information from a Value Added Meteorological Service Provider? If not already defined, pick
name for Turbo-determined element Surface Transportation Weather Service
Does your MCO center use (or plan to use) environmental data or information to detect
environmental hazards such as icy road conditions, high winds, or dense fog?
Do you have (or plan to have) automated roadway treatment systems (de-icing, anti-icing,
etc.)? If not already defined, pick name for Turbo-determined element MCO Field Devices
Does your MCO center perform (or plan to perform) winter road maintenance activities? If
not already defined, pick name for Turbo-determined element MCO Vehicles
Does your MCO center currently provide (or plan to provide) maintenance services such as
landscape maintenance, hazard removal (roadway debris, dead animals), routine
maintenance activities (roadway cleaning, grass cutting), or repair and maintenance of
equipment (both ITS and non-ITS) on the roadway? If not already defined, pick name for
Turbo-determined element MCO Vehicles
Does your MCO center manage (or plan to manage) work zones activities?
Do you control (or plan to control) traffic in work zones through the use of roadside devices
such as dynamic message signs (DMS) or do you monitor (or plan to monitor) traffic in work
zones through the use of devices such as closed circuit television? If not already defined,
pick name for Turbo-determined element MCO Field Devices
Do you currently monitor (or plan to monitor) intrusions into work zones or provide alerts to
field personnel when work zone intrusions occur? If not already defined, pick name for
Turbo-determined element MCO Field Devices
Does your MCO center monitor (or plan to monitor) vehicle speeds in work zones? If not
already defined, pick name for Turbo-determined element MCO Field Devices
Does your MCO center currently share (or plan to share) maintenance and construction
information with other transportation organizations or with organizations that provide traveler
information?
6. Public Transportation
Does your Public Transportation Center manage (or plan to manage) transit vehicles?
Pick name for Turbo-determined element Transit Vehicles


Fixed Route (including Bus Rapid Transit) - If not already defined, pick name for
Transit Vehicles
Rail - If not already defined, pick name for Transit Vehicles
Demand Response - If not already defined, pick name for Transit Vehicles
Flexible Route - If not already defined, pick name for Transit Vehicles
Ferries - If not already defined, pick name for Transit Vehicles
Does your transit element provide (or plan to provide) maintenance of the transit vehicles?
Do you have (or plan to have) an Automated Vehicle Location (AVL) System? If not already
defined, pick name for Turbo-determined element Transit Vehicles
Does your agency have (or plan to have) on board security monitoring systems? If not
already defined, pick name for Turbo-determined element Security Monitoring Field
Equipment. If not already defined, pick name for Turbo-determined element Transit Vehicles
Does your agency monitor (or plan to monitor) public areas (e.g., stops, park & ride lots,
stations)?
Pick name for Turbo-determined element Remote Traveler Support
Does your agency perform security monitoring (or plan to monitor) non- public areas (e.g.
transit yards or other infrastructure)? If not already defined, pick name for Turbo-determined
element Security Monitoring Field Equipment
Does your Public Transportation Center directly or indirectly (i.e., thru another
agency/organization) disseminate (or plan to disseminate) info to the public?
Devices
Display/Audio in Transit Vehicles - If not already defined, pick name for Transit
Vehicles
Electronic Displays/Audio Announcements at Transit Stops and Stations (includes
video monitors) - If not already defined, pick name for Kiosks
Television
Does your Public Transportation Center provide transit trip planning?
Devices
Does your transit element have (or plan to have) an Electronic Fare Payment System (smart
card, swipe card, credit card, etc.)? If not already defined, pick name for Turbo-determined
element Transit Vehicles. If not already defined, pick name for Turbo-determined element
Kiosks

Pick name for Turbo-determined element Traveler Card

Does your transit element share (or plan to share) transit data with a Freeway Management
Center, Arterial Management Center, or other Transit Management Center? If not already
defined, pick name for Turbo-determined element Transit Vehicles
7. Regional Traveler Information
Does your Regional Traveler Information Center use (or plan to use) different technologies to
distribute traveler information to the public?
Devices
Television
Does your Regional Traveler Information Center have (or plan to have) the capability to
provide any of the following information: broadcast data, personalized data, route guidance,
or yellow pages information?
Broadcast of Static or Real-Time Traffic, Transit, or Maintenance and Construction
information
Personalized provision of Traffic, Transit, or Maintenance and Construction
information to users
Route Guidance (either pre-trip or enroute)
Yellow Pages Information or Reservation
8. Arterial / Traffic Management
Does your Arterial or Traffic Management Center control (or plan to control) signalized
intersections?
Closed Loop or Centralized Control - If not already defined, pick name for Roadside
Elements
Real-Time traffic adaptive control such as SCOOT/SCATS or similar - If not already
defined, pick name for Roadside Elements
Signal Preemption for emergency vehicles - If not already defined, pick name for
Roadside Elements
Signal Priority for Transit Vehicles - If not already defined, pick name for Roadside
Elements
Do you have signalized intersections operated by the Arterial Management Center within 200
feet of a highway-rail intersection that currently (or are planned to) adjust signal timing in
response to train crossing to avoid vehicle entrapment, or are interconnected with active

crossing devices? If not already defined, pick name for Turbo-determined element Roadside
Equipment.
Are real-time traffic data collection technologies used (or planned to be used) on any of your
arterials managed by the Arterial or Traffic Management Center?
Loop Detectors that provide volume and speed data at midblock locations (this
excludes actuators on intersection approaches) - If not already defined, pick name
for Roadside Elements
CCTV Cameras - If not already defined, pick name for Roadside Elements
Probe Readers to estimate travel times on arterials - If not already defined, pick
name for Roadside Elements
Does your Arterial or Traffic Management Center distribute (or plan to distribute) information
to travelers directly using roadside media infrastructure on the arterials?
Variable Message Signs on mainline streets - If not already defined, pick name for
Roadside Elements
Highway Advisory Radio (HAR) - If not already defined, pick name for Roadside
Elements
Variable Message Signs controlling parking access - If not already defined, pick
name for Roadside Elements
In-Vehicle Signing transmitter locations - If not already defined, pick name for
Roadside Elements
Does your agency deploy (or plan to deploy) technologies associated with highway-rail
intersections? If not already defined, pick name for Turbo-determined element Roadside
Equipment
Video Surveillance - If not already defined, pick name for Roadside Elements
Electronic Surveillance other than video - If not already defined, pick name for
Roadside Elements
Ability to predict train arrivals electronically - If not already defined, pick name for
Roadside Elements
Electronic Traffic Violator devices - If not already defined, pick name for Roadside
Elements
Does your Arterial or Traffic Management Center have (or plan to add) environmental sensor
stations to monitor the environmental conditions?
Does your Arterial or Traffic Management Center provide (or plan to provide) surface street
travel times, speeds, and conditions information to the public?
Devices
e-mail or other direct PC communications - If not already defined, pick name for
User Personal Computing Devices

Television
Does your Arterial Management Center detect and verify (or plan to detect and verify)
incidents? If not already defined, pick name for Turbo-determined element Roadside
Equipment
Does your Arterial Management Center share (or plan to share) traffic data with another
Freeway Management Center or Arterial Management Center?
Does your Arterial or Traffic Management Center manage automatic or remotely controlled
gates or barriers that control access to roadway segments? - If not already defined, pick
name for Turbo-determined element Roadside Equipment.

8 Guidelines Summary
The following table is comprised of all paragraphs in this document that begin with GUIDELINE.
Table 7. List of Guidelines
Guideline
1. Remember that only a single Turbo Architecture database file and a single architecture in that file
can be opened at any given time in a single session of the Turbo Architecture program. If it is
desired to view two architectures simultaneously, a second session of Turbo Architecture must be
initiated.
2. Turbo Architecture supports Windows 98 Second Edition, 2000, XP, and Vista compatible
databases and operating systems. However, databases designed in various releases of Turbo
Architecture using MS Access 97 and Access 2000 or XP MUST NOT be converted back and forth.
The various versions of MS Access are not compatible with each other, and parts of your Turbo data
will be LOST by doing this.
3. Save your work often. Data is only saved when you choose the Save or Save As options (or
when you exit the file and save). All work you do between saves is put into a temporary file called
turwork<time/date stamp>.mdb. As you work this temporary file grows in size. If you wait too long
to exit and save, this file can grow so large you may not be able to save it. If the tool should fail with
unsaved data, you may be able to partially recover. Look for the temporary file in the Windows
temp directory (C:\Documents and Settings\<logon id>\Local Settings\Temp). Rename this file to
end in .tbo and then try opening it with Turbo Architecture. See the release notes for more hints on
how to correct this problem if it happens.
4. It is strongly recommended that the user be trained in the terminology, relationships, and usage of
the National ITS Architecture. The USDOT offers classes across the country on the architecture.
There is also the National ITS Architecture CD-ROM and web site that may be used as a reference.
The Regional ITS Architecture Guidance Document is also an excellent resource to see how to
apply the National ITS Architecture.
5. During a single Turbo Architecture session, the user will not be able to open more than one
database file at a time for update.
6. Remember that when naming an element, stakeholder, architecture, etc., certain special characters
(apostrophe (), ampersand (&), and quotes ()) may not be used in the name. Turbo will give a
warning message and not allow these names. Blanks, underscores (_), hyphens (-), are all
acceptable in a named item in Turbo.
7. The user will be able to add a comment to each subsystem, terminator, market package, and
architecture flow when it is selected for the Regional or Project Architecture. These comments may
be used to state why a particular element was selected or not for the architecture, or what it will be
used for (for example, if it exists in a Project Architecture that has been added to a Regional
Architecture, but is not needed for the regional). The user may also choose to display these
comments on the tabular output reports.
8. When defining a new Regional or Project Architecture, new users may want to do the initial input
using the Interview Dialog. After the initial interview questions have been completed, the resulting
data may be customized via the tabbed windows. More experienced users may find it easier to skip
the interview and go straight to the tabs.
9. The Interview does not create a complete architecture. The user must enter the Inventory and
Services tabs to add new elements or modify element and architecture flow associations, and
customize the architecture interconnections and flows on the Interfaces tab.

Guideline
10. There are questions pertaining to Traffic included in the Freeway Management and Arterial/Traffic
Management Interview Categories. These include questions about environmental sensor stations,
ramp meters, signal preemption, lane control devices, and Highway Rail Intersection (HRI). The
interview may also be used for collocating elements or centers. This is done by using the interview
to select several aspects of a single center. For example, you may have a center which performs
both Freeway and Arterial Management. To input this information you answer the questions for both
categories. The first time through define the center and stakeholder (for the first category), the
second time through you merely select the same center and stakeholder (they have already been
created).
11. When the user needs to customize the list of subsystems, terminators, and market packages
produced by the interview dialog, add locally defined elements (user defined entities or flows), or
define interconnections, he must exit the interview dialog (never to return, for this architecture, that
is) and enter the tabbed input windows to complete the architecture.
12. If the same stakeholder is used for all TMCs, then ALL permutations of the TMCs and their related
elements will appear. To prevent all of these unwanted interconnections, use separate stakeholders
for each TMC. This will also minimize the TMS (Traffic Management Subsystem) to RS (Roadway
Subsystem) permutations.
13. The Interview assigns a single Roadside Element or user interface element for each center defined.
If the user would like multiple elements (i.e., they would like to call out cameras and DMS separately
because one is currently deployed and one is part of a planned project), then following the Interview
they should go to the Inventory tab and create additional elements with appropriate status.
14. The user may leave the interview by selecting End Interview on most screens. To temporarily exit
click the Quit Interview for Now button in the window that pops up. To return to the interview
where he left off, click the Continue Interview button on the Start tab. Once he has completed the
interview and left by selecting the Exit Interview button, all updates must be made using the tabbed
windows. Updates may only be made on the tabbed windows by exiting from the interview dialog
using the Exit Interview option.
15. If a region includes four Transit Management Centers, and only one does Automatic Vehicle
Location (AVL), for example, then each center must be entered one at a time. Both the interview
dialog and the tabbed windows data input control this data entry by handling a single center/element
at a time. In the Interview, each center must be created separately by answering all the questions
for each new center in a category. One center may not be entered, then copied to create another
center (Turbo Architecture does not currently include a feature to copy an element/center).
16. If a Freeway Management Center performs more than a single function, such as traffic
management, freeway management, and traveler information, then all three interview questions
about these types of centers in the region must be answered with a status other than Not Planned.
There are Interview questions in the Freeway Management category about disseminating
information to the public (traveler information), and sharing traffic data with other freeway or
arterial/traffic management centers. Other Interview categories include similar questions.
17. Note that the New and Delete buttons on the Inventory tab affect all of the architectures in the
database the Regional Architecture and any Project Architectures. This means that when working
with a Project Architecture and you click DELETE you will be deleting it completely from the file,
including removing it from the Regional Architecture. Take special care when Deleting elements.
18. Inventory elements can either be Normal, Instances, Shared, or Communications. They cannot be
both Shared and Normal or Normal and Instances. The pull-down menu forces you to choose one
type. However, the attributes on the Start tab can be edited as necessary no matter what type is
chosen. Instances may need to be edited to show how they differ from their parents and Shared
elements may need to be edited in coordination with the maintainers of the other architecture.

Guideline
19. If a Project Architecture is open, you can select the current project for any elements created on the
Inventory tab using the check boxes on the left. This assignment is done for you for elements
created in the Interview, and for any new element created on the Inventory tab when you are in the
Current Project. If the project is not selected, then the Build option on the Interfaces tab may not
include this element for this project.
20. On the Inventory tab, the tool forces the user to map every element to an entity, either to a National
ITS Architecture subsystem or terminator, or to a user defined entity.
21. An element is defined as an element/stakeholder name pair. Any of these pairs not associated with
a National ITS Architecture entity (subsystem, terminator) will be able to be associated with a user
defined entity. The status of a selected element may be represented as existing or planned (or
as a local status value). See Section 6.3 for a discussion of how to define the status of elements,
market packages, flows, etc.
22. In mapping the inventory, if there is a TMC (Traffic Management Center) element defined in the
architecture, there should also be other elements in the inventory to connect this to, such as an ISP
(Information Service Provider) or EMC (Emergency Management Center) elements. The
interconnects between the elements and centers on the Interfaces tab will appear correctly if there is
more than one center.
23. The same element name may be mapped to two different entities (subsystems, terminators, or user
defined entities). This is not an error.
24. The user is allowed to reassign element and stakeholder names only by returning to the Inventory
step. This may not be done under the Interfaces tab. Only the status of architecture flows, and
whether or not a flow or interconnect is included in the architecture, may be changed during the
customization step.
25. A National ITS Architecture market package may be mapped to several different elements. This is
done on the Services tab. For example, three different elements may be mapped to the Network
Surveillance market package.
26. It is fine to use market package instances for some market packages and the general National ITS
Architecture market package for other market packages in your architecture definition. For example,
you might create instances for market packages that are broadly implemented in the region (e.g.,
network surveillance) and use the National ITS Architecture market package where the service is
only implemented by a single center. If you decide to use market package instances, it is good
practice to remove all element and project associations from the related parent market package.
This is so the general relationships defined in the parent market package dont override or negate
the specific relationships that are defined in the instance.
27. Use market package instance names that are meaningful to you. In most cases, you will want to
change the default names that are provided by Turbo. Remember while picking names that the
market package instances will be sorted alphabetically by name in reports and on other tabs.
28. If working in a Project Architecture, the current project must be selected for the elements in the
project (on the Inventory tab) AND for the market packages associated with this projects elements.
Otherwise, when the Build step is done, all the required flows and interconnects will not appear in
the architecture, on the Interfaces tab, or on the diagrams. The same is true if deselecting a project.
This must be done on both the Inventory and Services tabs. A project can apply to more than one
market package, or to parts of different market packages.
29. If a new market package has been selected for this architecture on the Services tab, and the user
simply begins associating elements and projects to it, the status remains unchanged. The status of
a newly selected market package with no previous associations defaults to Not Planned. This
must be changed to a status value, in order for its flows to actually be included later on the
Interfaces tab as part of this project.

Guideline
30. Often, a market package will only be partially implemented by a region or project. In general, select
the market package if the majority of it will be implemented and leave it out (status is not planned) if
the majority of it will not be implemented. The inventory elements are associated with National ITS
Architecture subsystems and terminators, which determines many architecture flow and interconnect
selections on the Interfaces tab. Selecting a market package simply adds to the list of flows
available for integration during customization. Review the National ITS Architecture for the list of
flows associated with each market package being considered.
31. Before writing the first functional requirement, determine the appropriate level of detail for your
region or project. Requirements should follow directly from the ITS service decisions, operational
concept and interface choices. Identify which systems need to have functional requirements defined
for instance, systems on the boundary of ITS (e.g., financial institutions) do not have to be
functionally defined.
32. The user should repeat the Build step whenever additions are made to the inventory or market
package selections after initial architecture build. Subsequent architecture builds will make
additional flows available for customization on the Interfaces tab.
33. The Build process will only ADD interconnects and architecture flows to the architecture. It will
NOT REMOVE any interconnects or flows, or change the status of a flow on the Interfaces tab if an
element or one of its services was changed on the Inventory or Services tab. If a Build is done
after some customization has taken place, the customization is not undone by the new Build. In
order to remove undesired interconnects or flows (for example, if a market package has been
removed), the user must uncheck the Include box for each interconnect or flow on the Interfaces
tab.
34. Although it wouldn't hurt to do a separate build for every architecture in a file, it is not absolutely
necessary. For instance, consider the case where there is an existing Regional Architecture and the
user wants to build a Project Architecture that is a subset of the Regional Architecture. The user
could go directly to the Interfaces tab (with the Project Architecture selected), and begin to manually
select the interconnects and flows for the project. (The only requirement is that the user has
identified at least the element(s) that are associated with the project. This information is used to
determine the set of flows that might apply to the project on the Interfaces tab.)
35. Once the user enters the Interfaces tab and begins to customize the architecture, he may return to
the Inventory or Services tabs to change element/stakeholder mappings and market package
selections. Note again that a new Build will only add new interconnects and flows from the
selections made on these tabs.
36. A project may apply to more than one market package or to parts of different market packages. This
is accomplished in the customize Flows view of the Interfaces tab by selecting or deselecting
architecture flows connected to this project and element.
37. Get your architecture to the point where you already have a good understanding of your
requirements and interfaces, i.e. customize the flows first. When you get to this point, gather the
key stakeholders together to make ITS Standards choices that will apply to any architecture in the
region.
38. The Turbo Architecture database file is not a distributed file system, so two users may not update
the same Regional Architecture within this database at the same time.
39. If a user needs to browse one architecture while updating another, he may simply bring up a second
Turbo Architecture session, open the database file, and view the appropriate architecture. It is
assumed that he is not trying to edit the same architecture in both sessions. If two people are
editing the same architecture, the database software will only warn them when they try to save, not
when they open the architecture tables. If they have both made changes, the last one to save is
warned that this table has been updated by another user (this is a Microsoft Access feature, not a
feature of Turbo Architecture).

Guideline
40. An architecture developed with Turbo Version IS NOT backwards compatible with previous versions
of Turbo Architecture.
41. Turbo will only begin the conversion once the user has selected a file and confirmed that a
conversion should be performed. The existing database is not replaced or deleted. The user
decides where to put the converted destination file.
42. During the conversion from a previous version of a Turbo database, the user may notice that certain
user defined flows from the original architectures now either (1) disappear altogether from the User
Defined Flows window, or (2) do not have all the interfaces defined from the original file. These
flows or interfaces now exist in the newest version of the National ITS Architecture, so are no longer
defined as user extensions. They will appear on the Interfaces tab because they are still part of the
architecture.
43. The user MAY NOT import prior release versions of his Regional or Project Architectures. Only an
architecture developed using the current version of Turbo may be Imported. The Import process
will detect if an architecture is included in a file from a prior release, and tell the user that he must
Convert the file up to the current version of Turbo Architecture, then Import the architecture into
the destination file. See Section 4.1.3 for a description of the Conversion process.
44. When importing a project Turbo only prompts the user when it actually has to add new items to the
local file during import. For example, it only warns about the elements and stakeholders that dont
already exist in the local file. If all the elements/stakeholders that the project needs already exist in
the local file, then Turbo just quietly maps the existing file objects to the project without prompting
the user. If the local file already includes everything needed for the imported project, then the only
prompt that the user sees will be at the end saying that a conservative build is needed.
45. The Build step to build the architecture following an import may change the architecture you import.
If you Build and notice that flows are being added to the architecture, you can allow the
architecture to change, or cancel out of the Build step, go to the Services tab and deselect either
the market packages assigned to the project imported, or adjust the element assignments. Run the
Build option again on the Interfaces tab and verify only non-planned flows will be added to the
Interfaces tab.
46. Data is only saved when you choose the Save or Save As options (or when you exit the file
and save). All work you do between saves is put into a temporary file called turwork<time/date
stamp>.mdb. For large architectures, you should also save every so often to a different filename in
case a mistake is made so you can go back to the previous version.
47. A user defined flow may be connected to a user defined entity or to a National ITS Architecture
entity (subsystem or terminator). Their names must, however, be distinct and separate from
National ITS Architecture names.
48. User defined entities and flows may be added to an architecture at any time before or during the
customization process, while on any tab. However, in order to see the user defined flows on the
Interfaces tab, a Build must be done to add them to the architecture. These extensions may then
be reassigned or modified on the Interfaces tab. In addition, the user defined flow must be mapped
between various subsystems or terminators that are interconnected in the National ITS Architecture.
This is accomplished by mapping the flow between the new user defined entity and a different type
of National ITS Architecture entity, or another user defined entity mapped to a different subsystem or
terminator.
49. The standards identified for each architecture flow should be used as a general guideline. Each
standard is typically comprised of both mandatory and optional elements which should be reviewed.
It is recommended that a communications expert proficient in bandwidth analysis, performance
requirements, and ITS standards options be consulted prior to deployment of any ITS architecture.

Guideline
50. As changes are made to the standards mapping in the National ITS Architecture, the Turbo
Architecture Standards Activities report may become outdated. To ensure that the latest standards
are being annotated for each architecture flow in a Project or Regional Architecture, it is
recommended that the user view the National ITS Architecture web site.
51. When a report is previewed, the first page is displayed to the user. The report may be saved to a
file to be displayed in some other editor, or printed.
52. Turbo can only create web pages for a Regional architecture not a project architecture. If you
select Output/Web Pages when viewing a project architecture a pop-up window will appear
directing you to go back to the Start tab and Select your Regional Architecture before selecting
Output Web Pages.
53. It is recommended that the first time through the web page generation process, you should create
only the Top-Level Diagrams to quickly generate pages that you can review. Make sure the look
and feel is right, then go back and generate the Detailed pages, then go back and add the
Diagrams.
54. If no Regional Architecture exists and the user defines a project, he must then create a new
Regional Architecture and choose to add this project into it. This is not done automatically by the
tool.
55. The stakeholder associated with an element may determine how that element is interconnected with
other elements on the Interfaces tab and on the Interconnect and Flow diagrams. Two elements
will be connected to each other (in most cases) if the stakeholder is the same (and the National ITS
Architecture subsystems or terminators that the elements are associated with are connected
together), and may or may not be connected if the stakeholder is different.
56. Once the user enters the Interfaces tab and begins to customize the architecture, he may return to
the Services tab to change market package associations, or he may return to the Inventory tab to
change element/stakeholder mappings. A new Build will pick up any new element and flow
selections, but not change his customization.
57. When using the Interview, a center and its associated elements are generally created as separate
elements mapped to various National ITS Architecture entities. When manually creating new
elements on the Inventory tab, the user should also keep this in mind. For example, when manually
creating an element for traffic management with roadside assets, the element should be divided into
two elements, one for the center mapped to Traffic Management Subsystem (TMS) and one for the
field equipment mapped to Roadside Subsystem (RS). Try to include only one instance of a
subsystem or terminator in an element. An example of element naming could be Phoenix Freeway
Management Center Roadside Elements.
58. It is recommended that a Turbo Architecture database file be named based on the region name.
59. A naming strategy for all user-entered names (element, stakeholder, user defined entity/flow,
project) should be established before designing the initial architecture in a Turbo Architecture
database file. Names should not be too general. The maximum number of characters visible inside
the list boxes is 60 characters (the list boxes will not include horizontal scroll bars, but the forward
and back arrows may be used to see the beginning to the end of the name). However, when
entering an element or stakeholder name, the user may type up to 200 characters (element or
stakeholder name) on the Inventory tab, and 100 characters in the Interview, and Turbo Architecture
will add the suffix to the element name. (See Section 6.1.3 for more information on naming
stakeholders.)
60. It is recommended that a Turbo Architecture element be names based on the stakeholder name.

Guideline
61. One way to prevent automatic overwriting to the Regional Architecture when changes are made to
the Project Architecture is to keep them in separate Turbo Architecture database files. Then, when
a user is ready, import the project into a destination database file, and merge it into the Regional
Architecture in that file.
62. If a Regional Architecture exists, the Interview Dialog should not be used to create a Project
Architecture from the Regional Architecture. If the user wishes to create a Project Architecture
without the Regional Architecture, a new database file may be created to hold this new Project
Architecture. The Project Architecture may then be created using the Interview Dialog. The new
Project Architecture may be imported later into the other database file, then merged with the
63. The tool requires that an element or market package be exclusively designated with a status value
even though the element or market package may contain characteristics (architecture flows) of more
than one of these categories. Users must choose the most appropriate designation.
64. If a stakeholder owns both a TMS and RS element, they probably should be connected.
65. If an interconnect is selected in the Regional Architecture that is already in the project, only flows are
selected that are in the Regional Architecture. If an interconnect is removed in the Regional
Architecture, it does not affect the Project Architecture.
66. One way to prevent automatic overwriting to the Regional Architecture when changes are made to
the Project Architecture is to keep them in separate Turbo Architecture database files. Then, when
a user is ready, he may import and merge a project into the Regional Architecture. It may be
confusing if the Regional Architecture keeps changing more than one person may be using the
file, updating different projects, and as a result, updating the Regional Architecture.
67. The tool supports definition of a multi-phase project where each phase may be represented as a
separate project in the database, or as additions/modifications to the initial Phase 1 Project
Architecture.
68. When working with a large architecture (over 10,000 flows), general elements should be developed
in the inventory that represent large numbers of centers or systems, such as a single element that
combines 20 Traffic Management Centers.
69. When working with a large architecture, you should Save and Save Often, AND exit and re-enter
Turbo (suggestion every half hour). This will ensure that the temporary file that is generated
during Turbo sessions stays at a manageable size.
70. The user may not change a terminator into a subsystem, or vice versa. This will conflict with
existing National ITS Architecture subsystems or terminators. A user defined entity may be created
if this function is needed.
71. If a user changes any of the database files outside Turbo Architecture, there is no guarantee that the
tool will function properly and generate the same outputs as before. If the user changes any of the
output reports or diagrams outside the tool, then re-enters Turbo, these changes will not be reflected
in Turbo.
72. Different Turbo Architecture database files may be used for various versions of a Regional
Architecture to illustrate trends over time.
73. It is recommended that the set of Interview questions be reviewed by the architecture design team
with potential stakeholder input prior to entering Turbo Architecture.

Turbo Architecture User&#39;s Manual V41

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Turbo Architecture User&#39;s Manual V41

Uploaded by

Copyright:

Available Formats

National ITS Architecture

Document Revision History

Whats New for Turbo Architecture Version 4.1

March 2009 ii User's Manual

Section 2 Getting Started

Section 3 Turbo Tabs

Section 4 Turbo Menubar

Section 5 Being a Successful Turbo Architect

Section 6 Advanced Topics Design Issues

Section 7 Interview Dialog Questions

Section 8 Guidelines Summary

March 2009 iii User's Manual

March 2009 iv User's Manual

3.6.2 Requirements Tab Functional Areas View 87

March 2009 v User's Manual

6.5 Managing Subsystem Permutations 235

March 2009 vi User's Manual

March 2009 vii User's Manual

Figure 58. Services Tab Instance of a Market Package 75

March 2009 viii User's Manual

Figure 116. Entering New User Defined Entity 144

March 2009 ix User's Manual

Figure 172. Operational Concept Web Page Viewed in Browser 203

March 2009 x User's Manual

March 2009 xi User's Manual

1.1 What is Turbo Architecture?

March 2009 1 User's Manual

1.2 Turbo Architecture Users

March 2009 2 User's Manual

March 2009 3 User's Manual

Figure 1. Element to Entity Relationship

1.4 System Overview

March 2009 4 User's Manual

1.4.1 Turbo Architecture Capabilities

1.4.2 User Scenarios

1.5 What is a Regional Architecture?

1.6 Architecture Definition Approaches

March 2009 5 User's Manual

1.7 Architecture Creation

Turbo Architecture Tool

Figure 2. Turbo Architecture Process

March 2009 6 User's Manual

2.2 Suggestions for Success

2.3 Quick Start

March 2009 7 User's Manual

Figure 3. Turbo Architecture Main Menu

March 2009 8 User's Manual

March 2009 9 User's Manual

2.4 Turbo Architecture and Microsoft Access

2.5 Overview of the Turbo Architecture Software

2.5.1 Installing and Running Turbo Architecture

March 2009 10 User's Manual

2.5.2 Accessing and Using the Sample Marinara Turbo Database

March 2009 11 User's Manual

System Status Center Description

March 2009 12 User's Manual

MCDOT Traveler MCDOT FMC Operations

Figure 4. Example of Marinara County Interconnects

Saucelito Fire Department FMC Operations Staff TOMATO System Users

Marinara County Department of Tran... Traffic Channel 72 on cable

Figure 5. Example of Marinara County Interconnect Diagram from Turbo

March 2009 13 User's Manual

2.6 File Overview

2.7 Accessibility Features of Turbo

Turbo Architecture User's Manual V41

Turbo Architecture User's Manual V41