U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations

Report
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-RD-03-050

Surrogate Safety Measures From Traffic Simulation Models

PDF Version (903 KB)

PDF files can be viewed with the Acrobat® Reader®

6. SSAM Functional Requirements

This section summarizes the functional requirements for the surrogate safety assessment module from the results of the literature and models review. This section has four main subsections:

  1. A brief description of the software requirements development process.
  2. Specification of a concept of operations for the SSAM and the associated use cases.
  3. Mock-ups of the user-interface elements of the SSAM.
  4. The derived functional requirements in a traceability matrix format.

The functional requirements will be the basis for implementing a surrogate safety assessment software module in the future.

Functional Requirements Development Process

A standard software design and development methodology is the Unified Software Development Process. Using this process, the functional requirements for the surrogate safety assessment module will be based on developing use cases. A use case (as defined in the Unified Modeling Language - UML) describes some interaction of an external actor with the system. In this project, the system is the surrogate safety assessment module. An actor is typically a human user, but may also be another software process, such as a traffic simulation model – CORSIM/TSIS (Traffic Software Integrated System), VISSIM, AIMSUN, or an external analysis tool like a spreadsheet or graphing software.

The use cases define what can be done with, or to, the SSAM. Thus, the functional requirements are naturally derived from specifying the use cases. The use cases also provide traceability that all of the functional requirements are covered in the eventual design.

Not every possible use or function of the SSAM software can be envisioned at the beginning of this process. This is another benefit of using the Unified Software Development Process – it is specifically designed to accommodate iterative and incremental development efforts. Hence, every possible consideration is provided to the specification of interfaces that can be extended to allow new and innovative developments to be integrated as the system matures.

There are several key elements of the requirements development process. The first is the concept of requirements layering. This involves the creation of different levels of the requirements documentation where each new level builds more detail upon the foundation of earlier levels. In this project, we identify objectives first as the highest level of requirements. From these objectives and the anticipated concept of operations, we can then develop the high-level use cases. From the use cases and objectives, the functional requirements are then identified (the next level of requirements would be software design requirements, not included in this phase of SSAM development). This process is illustrated in Figure 1.

Click to view alternative text

Figure 1. Requirements development process.

The requirements are listed in a traceability matrix conceptually arranged according to their use case packages. A use case package collects use cases that are related to some common function, such as "installation" or "testing." The purpose of this matrix is to systematically map each requirement through to the design and testing of the system, and identify the priority of each requirement as an essential, important, or simply desirable feature of the eventual system. It is also important to identify requirements that are both measurable and testable. The requirements traceability matrix numbers will be frozen with this submittal. As requirements are added, modified, deleted, etc., the numbering system will remain constant for the purpose of tracking.

System Owner, Users, and Stakeholders

The owner of the SSAM system is FHWA. FHWA has the responsibility for further maintenance and upgrade of SSAM for the benefit of users and other stakeholders. Users of the SSAM software would include traffic safety engineers, traffic simulation analysts, and traffic researchers. Many groups have a stake in the success of the SSAM, including:

  • FHWA—promoting use of traffic simulation models, providing tools for safety analysis, and enhancing decisionmaking for alternative traffic facility designs.
  • DOTs and city traffic managers—including safety analysis in decisionmaking, assessing safety impacts of alternative designs.
  • Traffic analysts—new safety-related analysis services.
  • Traffic model researchers and developers—identification of gaps in traffic models and real driver behaviors, enhanced safety effectiveness research of alternative facility designs.

SSAM Objectives

The objectives of the SSAM system are summarized below:

  • Provide tool for traffic engineers to perform comparative safety analysis.
  • Be compatible with as many traffic simulation models as possible.
  • Use the best possible surrogate measures (i.e., most representative of crash propensity) that are observable in simulation models.
  • Support flexible analysis (e.g., different aggregations of statistics, different visualization types).

Concept of Operation of the SSAM

Traffic engineers, analysts, and planners evaluate design options for intersections, arterials, and networks in simulation codes, such as CORSIM, VISSIM, PARAMICS, AIMSUN, etc. In addition to standard measures of effectiveness, such as total delay, average delay, queue lengths, etc., measures of the relative safety of design alternatives are desired from the simulation results.

The traffic engineer first enables surrogate safety output in the simulation model of choice and enters any modifications to the default parameters for the surrogate analysis in the input configuration interface for the traffic simulation model. The traffic simulation model is modified by the simulation developer organization so that the input procedure includes these configuration parameters. If the simulation model includes a graphical input editor, configuration of the safety parameters could be integrated into the GUI of the graphical editor. The traffic engineer then runs the simulation model for a number of iterations to obtain surrogate safety output statistics. The output statistics are written by the simulation model to an event file(s). The simulation model exports a separate event file for each iteration, with an appropriate naming convention for importing to the SSAM.

The traffic engineer then launches the stand-alone SSAM application. The simulation scenario file (geometrics, traffic volumes, etc.) is imported to the SSAM application using the standard, common data format supported by the simulation model. The event files are imported into the SSAM and the traffic engineer executes various types of aggregations and analyses, including generating and printing reports, viewing graphical visualizations, and performing comparative analyses with derived statistics. The graphical visualizations might include various types of graphs (scatter, pie chart, time series, three-dimensional), overlays of surrogate statistics on intersection schematics, side-by-side comparisons, and so on. As updates and upgrades are available, the traffic engineer can load the new version of the SSAM software without system administrator assistance. This data-flow process is illustrated in figure 2.

Click to view alternative text

Figure 2. Event-file-based information flow diagram.

Use Case Analysis

The user needs ultimately specify the capabilities of any software system being procured or developed. Use case analysis captures the users’ expectations of the functionality of the system (their needs) and expresses them clearly in terms that software system developers can follow. The use case model is a central part of a requirements document developed within an object-oriented software development process. The use case model emphasizes interfaces and end-to-end functionality within the system by rigorously identifying all system users and the actions they will be able to take. Each use case describes how a system user or an actor would interact with the SSAM software system in each particular case. That is, each use case describes a particular and observable system behavior. These behaviors are then used to develop the detailed software system requirements describing how that behavior is accomplished.

In addition to driving the detailed design of the software, another goal of UML and use case-based design is software module reuse. Many different applications have map interfaces, graphics import, loading files, etc. By identifying common use cases of different software types, those code modules can be built once and reused with minimal modification for a different application at a savings to the customer and reduced total development time.

System Users

Use cases are guaranteed to be observable by the fact that they must be connected to one or more actors. The actors related to the SSAM system are shown in table 7.

Table 7. Use case actors.

Use Case Actor

Description

Simulation Model

The simulation model produces the traffic events and behavior used to derive the surrogate measures of safety.

Traffic Engineer

The traffic engineer runs the simulation model and SSAM to do traffic performance and safety analyses, print reports, set configuration parameters, etc. The SSAM should be designed such that the traffic engineer can install and upgrade the SSAM without system administrator support.

Simulation Model Developer

The simulation model developer updates, modifies, and augments the traffic simulation model to add/change functionality, upgrade the code, fix bugs, etc. As these changes are made, the API for the SSAM may need to be modified/revised.

The following cases are intended to capture the types of interaction that the SSAM system will have with the outside world, based on the user needs, as described briefly in the concept of operations for the SSAM. These cases do not represent the design of the SSAM itself. The use cases only describe the interfaces to the SSAM software and are used to verify that all requirements for the system have been identified, and that all identified requirements have been addressed. The objects identified in the use case analysis are then carried forward to subsequent steps of the object-oriented design process.

Use Case Packages

As illustrated in figure 3, the use cases for SSAM are collected into use case packages. A package is a collection of use cases according to common functions, such as installation, operation, analysis, etc. The arrows between use case packages are intended to indicate relationships between the use cases of the two groups. The following sections briefly discuss each of the use case packages.

Click to view alternative text

Figure 3. Use case package diagram.

INSTALL and UPGRADE

The SSAM software has to be installed on the user’s PC and upgraded as new features are identified and bugs are fixed. Table 8 lists the install and upgrade use cases.

Table 8. Install and upgrade use cases.

Install SSAM software on PC.

Upgrade SSAM software to new version.

CONFIGURE

The SSAM software will have many parameters to configure that allow the user to visualize the analysis and customize the analysis results. Some of these data would be best imported from the simulation application(s) itself (e.g., "import traffic-stream data") using a common file format such as Traffic Model Markup Language (TMML[1]). If this is not possible, the data could be configured manually by the user. The data required to adequately analyze the traffic situation includes:

  • Network geometry—number of lanes in each direction, turning pockets, driveways, etc.
  • Traffic-stream data—volume of traffic in each direction, change in the volumes over the simulation period.
  • Intersection control data—how many phases, actuated or nonactuated, phase durations, etc.
  • Driver behavior data—aggressiveness distribution, gap-acceptance criteria, etc.

In addition to configuring the details of the intersection and conditions being analyzed, the SSAM software should have features and functions that are configurable by the user. For example, the user should be able to:

  • Select the icons that are used to represent each type of conflict from a library of icon types, e.g., stars for rear-end events, circles for crossing events, squares, sunbursts, etc.
  • Select the colors for conflict event characteristics from among various palettes, e.g., red is high severity, yellow is medium severity, green is low severity.
  • Select the output variables or summary statistics that will appear in an output table, graph, or intersection graphic, e.g., "show me all rear-end conflict events where the speed differential was greater than 25 mi/h (56.25 m/s) occurring in the rightmost lane of all approaches between 7 a.m. and 8 a.m. of the analysis period."
  • Save a set or sets of configuration parameters in workspace variables for retrieval at a later time——so the user can rerun a particular analysis for a particular scenario with new data, or apply the same configuration settings to a new scenario.

Configurability of colors, icons, etc. are generally available "off-the-shelf" in standard graphics libraries provided by the system software manufacturer.

It would also be useful if the user could calibrate the parameters of the SSAM from field data automatically though the software by importing field data, or visualizing field data on the same graphs, charts, and graphics as the simulated data.

Table 9 lists the use cases for configuration of the SSAM software.

Table 9. Configure use cases.

Configure network geometry.

Import network geometry.

Configure surrogate model parameters.

Configure summary measure parameters.

Configure analysis parameters.

Configure reporting/output parameters.

Configure graphic display.

Save configuration settings.

Calibrate surrogate parameters from field data.

Configure intersection control details.

Import intersection control details.

Configure traffic-stream data.

Import traffic-stream data.

Configure driver behavior parameters.

Import driver behavior parameters.

Configure color definitions.

Configure icon definitions.

 

OPERATE

The use cases in the Operate package are mostly general/generic features of the SSAM software that might be most similar to other applications, such as the traffic simulation software itself, such as:

  • Importing data from files.
  • Selecting background graphics.
  • Selecting measures from a list.
  • Zooming and panning the display(s).
  • Selecting a particular output type.
  • Selecting a particular data point and getting additional details.
  • Starting and stopping the software.

These functions and features are typically found on buttons and/or drop-down menus of the software that then might launch additional windows with more detailed functions (such as found in the analysis use case package). The use cases for Operate are listed in table 10.

Table 10. Operate use cases.

Import event file.

Import event file batch.

Import intersection graphic.

Import network graphic.

Pan network display.

Pan close-up display.

Zoom network display.

Zoom closeup display.

Start SSAM.

Quit SSAM.

Select intersection for graphic display.

Obtain user help.

Select intersection for detailed display.

Select surrogate for display on graphic.

Select graphic type.

Select aggregation type.

Get details for particular data point.

Display field data on graphic.

ANALYSIS

Use cases in the Analysis package are the core features of the SSAM software. All of the other use case packages are built to support these core features for analyzing the surrogate safety data from the traffic simulation models. These analyses are probably best run in a comparative way, since the essential information is more likely found in the differences between the results for two scenarios, rather than in the absolute results for a particular scenario. For example, an analysis might be described as the following:

"Show me all rear-end conflict events with a speed differential greater than 25 mi/h (56.25 m/s) that occurred between 7 a.m. and 8 a.m. on all approaches in the rightmost lane. Show intersection design A with circle icons and intersection design B with triangle icons. Let the color of the icons indicate the TTC of the conflict event – red for a TTC less than 0.5 s, yellow for a TTC between 1.0 s and 0.5 s, and green for a TTC between 1.0 s and 1.5 s. Put those icons geo-located on a satellite photo of the current intersection design A."

Analysis use cases include, for example:

  • Sorting tables by a particular table element.
  • Filtering results by ranges of a particular element.
  • Calculating summary measures, such as weighted combinations of total numbers of different types of conflict events— "conflict indices."
  • Calculating and visualizing distributions of events.
  • Calculating and visualizing distributions of the differences of events produced by alternative designs.

Distributional analysis is very important in studies involving simulations because of the stochastic nature of the data. A lot of information also is thrown away by simply comparing average values of two or more alternatives. Some previous work in safety analysis has proposed distributional analysis for severity of conflict events (83). However, analysts must be more sophisticated to interpret distributional data or the software will require additional functionality to "auto-analyze" distributional results. Distributional comparisons are discussed further in the Interface Mock-Ups section of this report. Table 11 lists the Analysis use cases.

Table 11. Analysis use cases.

View network summary display.

View graphical closeup display.

View differences of design A and B.

Filter display on event type.

Compare surrogate data to field data.

Compare intersection design A to designs B,…,N.

Compare intersection design A to B.

Sort table by column.

Filter display by surrogate range.

Calculate summary measure.

REPORTING

Finally, the SSAM software must have use cases describing how the output of the software is transferred to other formats, either printing or saving the results to a standard file format. Table 12 lists the use cases for the Reporting package.

Table 12. Reporting use cases.

Export graphic display to file.

Export report/table to file.

Print a graphic display.

Print a report/table.

User Interface Mock-Ups

Based on the use cases identified in the previous section, some user interface mock-up screens are presented to direct thinking about functionality, additional features, and the complexity involved in designing the SSAM module as an external software system. The SSAM software would notionally be comprised of:

  • Main program- and network-level view(s).
  • Intersection-level view(s).
  • Tabular view(s).
  • Graph/chart view(s).
  • Distribution comparison view(s).

Figures 4 through 9 illustrate samples of what these screens might look like in the eventual SSAM tool. Figure 4 shows the main screen. A number of drop-down menus are available for use to load scenario files, perform analysis steps, set configuration parameters, launch sub-displays for intersection graphics, charts, etc., and get user help. A display of the traffic network being analyzed is shown in the main display. The network display could show conflict event data, both summaries and individual geo-referenced event icons.

Click to view alternative text

Figure 4. Main application with network-level display.

Figure 5 illustrates a notional intersection close-up display. The user could click on individual conflict event icons and get the associated details data in the information box on the left side. The graphic could be zoomed and panned to focus on different parts of the figure. Different surrogate measures could be selected from the menu boxes to change the representation for the color and shape of the icons. Buttons for toggling display of certain conflict event types (shown on the left-hand side of the graphic as pairs of rectangles with arrows indicating direction of travel) might be provided for the user to focus on a particular event class.

Click to view alternative text

Figure 5. Intersection close-up window.

Figure 6 illustrates a tabular display. The user would be able to add columns, delete columns, filter columns on different measures, and configure default column settings from the drop-down menus. The user could save a particular tabular view to a file for printing or embedding in a report, or some other post-processing with a tool such as a spreadsheet or graphing software.

Click to view alternative text

Figure 6. Table display.

Figure 7 shows a graph display. Graph-drawing modules can typically be found in off-the-shelf software libraries. The user would be able to add series, delete series, scale the x,y axes, set configuration parameters, etc. from the drop-down menus. Perhaps the x,y variables could be selectable from a drop-down menu for quick trend analysis. Similar functionality is being developed for HUTSIM (e.g., figure 7 from (39) illustrates a graphical display of TTC and PET versus speed for a particular analysis scenario) in the SINDI project.

Click to view alternative text

Figure 7. Graph display.

Figure 8 illustrates an important component of the SSAM analysis software. The distribution visualization window would allow the user to compare derived statistics of two (or more) design alternatives without having to dump the results to a file and then post-process the data with a tool such as a spreadsheet. Distribution types could be selectable by the user, or the SSAM could analyze the data and suggest a distribution type based on the best fit to the data (or a general-purpose distributional type could be used with parameters calibrated to the data, e.g., beta distributions can take on almost any shape with the appropriate parameters). For example:

  • The user might want to compare the TTC distributions (a histogram of all of the collected TTC values) from two design alternatives for a particular intersection approach (83).
  • The user might want to compare the distributions of the total number of rear-end conflict events for 10 iterations of the simulation for a particular approach to 2 different intersection design alternatives.
Click to view alternative text

Figure 8. Distribution comparison display.

Figure 9 shows a mock-up of a user’s workspace using the SSAM tool, including the simulation model window, SSAM main window, two intersection close-up windows, a parameters configuration window, and a distribution display window. It is important to note that a full-featured tool of this type would require considerable design and development effort. The tool should be planned in stages.

Click to view alternative text

Figure 9. Workspace display.

Functional Requirements

The SSAM functional requirements are expressed as a series of "shall" statements that describe the system functionality and are derived from the use cases identified in the previous section. Each requirement is categorized and prioritized according to the features that are mandatory, important, or desirable.

Mandatory requirements are features or functionalities that must be provided by the SSAM software/system to fulfill the core mission of SSAM to provide surrogate safety analyses from traffic simulation models. The software will not be acceptable unless the mandatory requirements are met.

Important requirements are features or functionalities that could be included in the SSAM software system to enhance the functionality of SSAM and would result in a more complete product, but may not be, for example, required by the system software in its initial implementation. These features and functions would be expected functions, but might not be included until the next version.

Desirable requirements are features or functionalities that would be worthwhile to have in the initial implementation, but describe features or functionalities that are not essential to performing the core mission. These features might enhance usability, provide additional output formats (e.g., graphics, charts, reports), or provide additional user configurability.

In this section, "the system" refers to the SSAM software system. The following subsections identify the key functional requirements for SSAM according to the use case packages. The matrix identifies:

  1. Requirement number.
  2. Requirement category and subcategories.
  3. Requirement text.
  4. Requirement rating (mandatory, important, desirable).
  5. Comments.

The requirements traceability matrix numbers will be frozen with this submittal. For the purpose of tracking, any action such as adding, modifying, or deleting a requirement will not affect the numbering of the other requirements.

REQUIREMENT NUMBER

CATEGORY

DESCRIPTION

PRIORITY

COMMENTS

1.

INSTALL

SSAM shall be installable on a PC, MacintoshTM, or UnixTM-based computer.

MANDATORY

 

1.1

INSTALL: automation

SSAM shall be installed by an automated process.

IMPORTANT

e.g., Windows 2000TM InstallShieldTM

Installation of SSAM shall be possible without system administrator assistance.

IMPORTANT

 

2.

UPGRADE

SSAM shall be upgradable by an automated process.

MANDATORY

e.g., patch via Compact-Disk(CD)

Upgrade to SSAM shall not require changes to simulation model.

IMPORTANT

 

3.

CONFIGURE: categories

SSAM shall be configurable. Configurable features of SSAM shall include:

   

3.1

 

Surrogate measure thresholds,

MANDATORY

e.g., TTC < 1.0 s versus 1.5 s

3.2

 

Surrogate summary measure definitions,

MANDATORY

e.g., weighted sums of total surrogates – "intersection conflict index"

3.3

 

Section bin definitions,

MANDATORY

e.g., how many length regions to divide an approach into, how many time bins to divide each measure into (0.0-0.5, 0.5-1, 1-1.5) versus (0-0.25, 0.25-0.5, 0.5-0.75, 0.75-1), etc.

3.4

 

Measure color indications,

IMPORTANT

e.g., red, yellow, green versus 5-10 shades of one color

3.5

 

Event-type icons,

IMPORTANT

e.g., stars, circles, boxes, points

3.6

 

Analysis parameters,

MANDATORY

 

3.7

 

Graphic display parameters.

IMPORTANT

 

3.8

CONFIGURE: simulation characteristics

SSAM shall allow user to record characteristics of a simulation, including:

   

3.8.1

 

Traffic network geometrics,

IMPORTANT

e.g., approach lanes, turning-pocket lengths, intersection widths

3.8.2

 

Intersection controller characteristics,

IMPORTANT

 

3.8.3

 

Traffic-stream characteristics,

IMPORTANT

e.g., approach volumes, turning percentages

3.8.4

 

Driver behavior characteristics.

IMPORTANT

e.g., gap-acceptance criteria, aggressiveness distribution

3.9

CONFIGURE: import

SSAM shall automatically import characteristics of a simulation, including:

   

3.9.1

 

Traffic network and intersection geometrics,

DESIRABLE

 

3.9.1.1

 

Geometrics shall be imported from an industry-standard definition file

DESIRABLE

e.g., TMML

3.9.2

 

Intersection controller characteristics,

DESIRABLE

 

3.9.2.1

 

Intersection controller characteristics shall be imported from an industry-standard definition file

DESIRABLE

e.g., TMML

3.9.3

 

Traffic-stream characteristics,

DESIRABLE

 

3.9.3.1

 

Traffic-stream characteristics shall be imported from an industry-standard definition file

DESIRABLE

e.g., TMML

3.9.4

 

Driver behavior characteristics,

DESIRABLE

 

3.9.4.1

 

Driver behavior characteristics shall be imported from an industry-standard definition file.

DESIRABLE

e.g., TMML

3.10

CONFIGURE: accessibility

Configurable characteristics of SSAM shall be accessible to user without developer intervention.

IMPORTANT

 

3.11

CONFIGURE: save

SSAM shall save configuration settings, including:

   

3.11.1

 

Default settings,

MANDATORY

At least one set of settings should be retained so that when software is restarted, user does not have to reconfigure everything all over again.

3.11.2

 

User-definable sets of configuration settings,

DESIRABLE

 

3.11.2.1

 

User-defined configuration sets shall be loadable from files,

DESIRABLE

 

3.11.3

 

Current work-space state,

DESIRABLE

In case the program hangs or user’s computer crashes, user does not have to reconfigure everything all over again.

3.11.3.1

 

Work spaces (project definitions) shall be able to be switched by user without quitting and restarting software.

DESIRABLE

e.g., like the way TSIS works with multiple scenarios open at the same time

4.

OPERATE

SSAM shall be executable by user. Commands shall include:

   

4.1

OPERATE: start

Starting the application, including:

   

4.1.1

 

From PC start menu,

MANDATORY

 

4.1.2

 

From desktop icon,

IMPORTANT

 

4.1.3

 

Automatically as a component of an existing traffic simulation tool.

DESIRABLE

 

4.2

OPERATE: stop

User shall be able to quit the SSAM application from user interface.

MANDATORY

 

4.3

OPERATE: help

Help shall be available to user, including:

   

4.3.1

 

How to operate all controls,

IMPORTANT

 

4.3.2

 

Interpretation of terminology,

IMPORTANT

 

4.3.3

 

Guidelines for application of the statistical methodology,

DESIRABLE

e.g., number of simulation iterations for meaningful analysis, how to compare distributions with T-test, etc.

4.3.4

 

Sample scenarios with associated analyses.

DESIRABLE

 

4.4

OPERATE: filter

User shall be able to filter displays by:

   

4.4.1

 

Event type,

IMPORTANT

 

4.4.2

 

Surrogate measure severity,

IMPORTANT

 

4.4.3

 

Surrogate measure type.

IMPORTANT

 

4.5

OPERATE: get details

User shall be able to view the details of a particular conflict event.

MANDATORY

 

4.6

OPERATE: load results

User shall be able to load the results of a base case.

MANDATORY

e.g., all subsequent design options are compared to the baseline case

4.6.1

 

Base case shall include multiple iterations of a simulation.

MANDATORY

An "iteration" of a simulation is the same conditions simulated with a different random number seed. A "case" is a particular design or traffic scenario.

4.6.2

 

SSAM shall automatically determine how many simulation iterations will be loaded for a given case.

IMPORTANT

It depends on the format of the event file(s) how the SSAM software will determine how many runs are included. It may have to be manually determined.

4.6.3

 

Results file format shall be a standardized data exchange technology format.

MANDATORY

e.g., XML extension of TMML

4.6.3.1

 

Results file shall contain a header. Header shall contain:

MANDATORY

 

4.6.3.1.1

 

Date of analysis,

MANDATORY

For tracking

4.6.3.1.2

 

Time of analysis,

MANDATORY

For tracking

4.6.3.1.3

 

ID of analyst,

MANDATORY

For tracking

4.6.3.1.4

 

Comments on analysis (if any).

MANDATORY

 

4.7

OPERATE: load comparison

SSAM shall allow user to load a comparison case.

IMPORTANT

e.g., alternative intersection design, different volume scenario, different controller phasing or pattern, etc.

4.7.1

 

Multiple comparison cases shall be allowed simultaneously.

IMPORTANT

 

4.7.2

 

Number of multiple comparison cases shall be, at minimum, 99 cases.

DESIRABLE

 

5.

ANALYSIS

SSAM shall allow user to perform surrogate safety analyses.

   

5.1

ANALYSIS: summary measures

User shall be able to compute a summary, aggregate surrogate measure by:

   

5.1.1

 

Approach,

MANDATORY

 

5.1.2

 

Movement,

MANDATORY

 

5.1.3

 

Phase,

IMPORTANT

 

5.1.4

 

Location,

MANDATORY

 

5.1.5

 

Intersection,

MANDATORY

 

5.1.6

 

Time period,

IMPORTANT

 

5.1.7

 

User-definable formula.

DESIRABLE

e.g., weighted sums of total conflict events "intersection index" comparison measures

5.1.8

 

Summary measures shall include statistics across simulation runs.

MANDATORY

 

5.2

ANALYSIS: differences

SSAM shall display comparative results from the base case and the comparison case.

IMPORTANT

 

5.2.1

 

Comparative results shall be displayable on all graphic formats.

DESIRABLE

 

5.2.2

 

Comparative results shall be available in tabular format.

DESIRABLE

e.g., table could be composed of the differences between design alternatives, rather than the totals for each – software could compute the subtractions for user

6.

DISPLAY

SSAM shall allow user to display results, including:

   

6.1

DISPLAY: tables

Summary tables,

MANDATORY

 

6.1.1

 

Summary tables shall have a default set of column elements.

MANDATORY

e.g., conflict type, TTC, approach number, lane number, etc.

6.1.1.2

 

Multiplesets of default column combinations shall be supported.

IMPORTANT

 

6.1.2

 

User shall be able to sort summary tables by column.

IMPORTANT

Typical feature of off-the-shelf table libraries.

6.1.3

 

Summary tables columns shall be selectable from any state variable returned in the event record.

DESIRABLE

 

6.2

DISPLAY: graphics

Graphics, including:

   

6.2.1

 

x-y plots,

IMPORTANT

 

6.2.1.1

 

Plots shall be configurable by user.

MANDATORY

e.g., ticks, scale, bounds, marker types, legend, etc. – typical features of plot libraries

6.2.1.2

 

Plots shall support more than one series per plot.

MANDATORY

 

6.2.2

 

Charts,

IMPORTANT

e.g., pie chart, bar graph, etc.

6.2.2.1

 

Charts shall be configurable by user.

MANDATORY

e.g., colors, scale, bounds, marker types, legend, etc. – typical features of chart libraries

6.2.3

DISPLAY: graphics: overhead intersection graphics

Overhead intersection graphics,

MANDATORY

 

6.2.3.1

 

Overhead intersection graphics shall be able to be launched from the network graphic display.

DESIRABLE

 

6.2.3.2

 

Background graphics shall be imported, including:

MANDATORY

Intersection schematics, overhead photos

6.2.3.2.1

 

Vector-based intersection drawings,

MANDATORY

e.g., Windows metafile (WMF)

6.2.3.2.2

 

Overhead intersection images.

MANDATORY

e.g., Graphics Interchanage File (GIF), .JPG (Joint Photographers Group)

6.2.3.2.3

 

Intersection schematics shall be geo-reference-able for alignment with background images.

DESIRABLE

 

6.2.3.2.4

 

Background graphics shall be able to be rotated for geo-reference.

DESIRABLE

 

6.2.3.3

 

Overhead intersection graphics shall be able to be panned by user.

IMPORTANT

 

6.2.3.4

 

Overhead intersection graphics shall be able to be zoomed by user.

IMPORTANT

 

6.2.3.5

 

Zoom and pan settings shall be retained for print/save.

DESIRABLE

 

6.2.3.6

 

Multiple overhead intersection graphics shall be viewable simultaneously.

MANDATORY

 

6.2.3.7

 

Conflict events shall be viewable on intersection graphics.

MANDATORY

 

6.2.3.7.1

 

Conflict events shall be placed with geo-referenced coordinates.

IMPORTANT

Some simulations do not support Geographic Positioning System (GPS)-type vehicle tracking yet.

6.2.4

DISPLAY: graphics: network graphics

Traffic network graphics.

DESIRABLE

 

6.2.4.1

 

Overhead intersection graphics displays shall be able to be launched from the network graphic display.

DESIRABLE

 

6.2.4.2

 

Background graphics shall be imported, including:

MANDATORY

Intersection schematics, overhead photos

6.2.4.2.1

 

Vector-based network drawings,

MANDATORY

e.g., WMF

6.2.4.2.2

 

Overhead network images.

MANDATORY

e.g., GIF, JPG

6.2.4.2.3

 

Network schematics shall be geo-reference-able for alignment with background images.

DESIRABLE

 

6.2.4.2.4

 

Background graphics shall be able to be rotated for geo-reference.

DESIRABLE

 

6.2.4.3

 

Network graphics shall be able to be panned by user.

IMPORTANT

 

6.2.4.4

 

Network graphics shall be able to be zoomed by user.

IMPORTANT

 

6.2.4.5

 

Zoom and pan settings shall be retained for print/save.

DESIRABLE

 

6.2.4.6

 

Multiple network graphics shall be viewable simultaneously.

MANDATORY

 

6.2.4.7

 

Conflict events shall be viewable on intersection graphics with geo-referenced coordinates.

MANDATORY

 

6.2.5

DISPLAY: graphics: distribution displays

Distribution displays, including:

IMPORTANT

 

6.2.5.1

 

Configurable distribution types.

DESIRABLE

e.g., normal, beta, uniform

7.

REPORTS

SSAM shall allow user to produce reports of results, including:

   

7.1

REPORTS: print

User shall be able to print results. Print shall include:

MANDATORY

 

7.1.1

 

Graphics displays,

MANDATORY

 

7.1.2

 

Tables.

MANDATORY

 

7.1.3

 

Print shall support standard Windows 2000 print utilities.

MANDATORY

 

7.2

REPORTS: save

User shall be able to save results to a file. Results shall include:

MANDATORY

 

7.2.1

 

Saving graphics displays to a common file format,

MANDATORY

e.g., JPG, GIF, WMF; at minimum, user can alt-printscrn the window

7.2.2

 

Saving tables to a common file format.

MANDATORY

e.g., comma-delimited text

8.

DEVELOPMENT

SSAM shall be developed using:

   

8.1

 

Object-oriented methods,

MANDATORY

 

8.2

 

Standard, off-the-shelf graphical user interface elements,

MANDATORY

 

8.3

 

Open-standard software component libraries,

IMPORTANT

e.g., plot tools, pan/zoom controls, button libraries, etc.

8.4

 

Independent modules with documented interfaces,

MANDATORY

 

8.5

 

Portable language for cross-platform compatibility.

MANDATORY

See requirement 1.1, installation.


[1] TMML is a proposed standard by K. Courage and S. Washburn at the University of Florida based on XML (extensible markup language). The encoding standard is based on the TSDD (Traffic Software Data Dictionary) data elements principally intended to support exchange of data between traffic engineering software without re-encoding the data. The standard is focused currently on the description of facilities. back

 

Previous | Table of Contents | Next

Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000
Turner-Fairbank Highway Research Center | 6300 Georgetown Pike | McLean, VA | 22101