Professional Documents
Culture Documents
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 Roadmap
Section 1 Introduction
Description of Turbo Architecture, high level discussion of certain functions of the system, list of
terminology.
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
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
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
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.
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.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
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.
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)
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.
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:
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.
select the Turbo Architecture button, and then select the FAQ options by Turbo release version.
options and architecture development tabs. All features are fully described in subsequent sections of this
document.
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
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
Existing
Planned
The figure below illustrates the File pulldown menu, including the CTRL keyboard shortcuts.
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.
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:
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.
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.
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)
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:
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.
Merge
Project into
Regional
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.
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.
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).
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.
a. View Questions displays the list of Interview questions that will be asked for the selected
category (see the figure below).
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.
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.
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.
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).
ISP
TMS
T M C Elem ent
RT S
T M C Kiosk
Elem ent
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
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
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.
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.
See Section 6.1.3 for suggestions on naming stakeholders in a consistent manner throughout the
architectures in a region.
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.
The next figure shows the same inventory with Sort By: Stakeholder 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.
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.
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.
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.
In the next diagram, two elements and one project are associated with market package ATMS07,
Regional Traffic Management.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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 70. Initial Interfaces Tab Architecture Has Not Yet Been Built
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.
of flows selected by the Build algorithm, thus allowing the user to control the type of Build that is
performed.
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.
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.
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.
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.
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.
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.
The next figure illustrates the architecture flows for all elements in a Regional Architecture.
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.
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.
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.
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.
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:
(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).
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 V3.0 was based on V5.0 of the National ITS Architecture.
Turbo V3.1 was based on V5.1 of the National ITS Architecture.
Turbo V4.0 was based on V6.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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
Existing
Planned
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.
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.
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
Planned
Internet PC Access via the WWW County Traveler Kiosk Network Marinara County Department of Tran...
TOMATO Event Parking System
Bus Operations Center Marinara County Department of Tran... Planning Data Warehouse TOMATO Advertisers
TOMATO Regional Traveler
Information
incident information
road network conditions
road closure information
City Operations Center GARLIC Information System Saucelito Fire and Rescue Center
Existing
Planned
Planned
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.4 Reports
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.
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.
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
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:
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.
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.
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.
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.
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.
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.
The functionality and entity description page for Transit Management is shown below:
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.
Clicking on any of the stakeholders in that table will bring up the details page for that stakeholder shown
below:
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:
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
shown previously in Figure 160.
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:
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.
Selecting one of the Project names hyperlinks will bring up the screen shown below.
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.
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.
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.
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.
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.
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)
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
Subsystems and Terminators) and Architecture Flows. This may be done via the Tools => Add
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)
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.
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.
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
Regional Architecture.
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.
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.
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 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.
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.
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.
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 2 Project 1
Import Merge
Project 3 Merge
Not Yet
Project 4 Imported
Not Yet
Corridor Merged
City Merge Project 6
Project 1 Customize Customize
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
Statewide
Merge Corridor
Regional
Architecture Project 7
Merge
Statewide
Project 8
Statewide Database
Customize
Customize Projects
Projects Import City
City Project 1
Merge Project 1 Merge
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
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.
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.
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.
7. The process copies the Regional Architecture into the Project Architecture, and displays the
following window when complete:
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
Name Center and Identify Stakeholder Associations
Pick name for Turbo-determined element Roadside Equipment
Pick name for Turbo-determined element Vehicles
4. Freeway Management
Name Center and Identify Stakeholder Associations
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
Indicate what is used:
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
Indicate what is used:
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?
Indicate what is used:
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
Personal Computing Devices
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
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?
Indicate what is used:
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
Other - 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?
Indicate what is used:
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
Other - 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
Indicate what is used:
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
Other - 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?
Indicate what is used:
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 Personal Computing Devices
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 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
Regional Architecture.
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.