U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations
![]() |
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 ModelsPDF Version (903 KB)
PDF files can be viewed with the Acrobat® Reader® 6. SSAM Functional RequirementsThis 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:
The functional requirements will be the basis for implementing a surrogate safety assessment software module in the future. Functional Requirements Development ProcessA 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. 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 StakeholdersThe 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:
SSAM ObjectivesThe objectives of the SSAM system are summarized below:
Concept of Operation of the SSAMTraffic 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. Figure 2. Event-file-based information flow diagram. Use Case AnalysisThe 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 UsersUse 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.
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 PackagesAs 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. Figure 3. Use case package diagram. INSTALL and UPGRADEThe 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.
CONFIGUREThe 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:
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:
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.
OPERATEThe 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:
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.
ANALYSISUse 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:
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.
REPORTINGFinally, 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.
User Interface Mock-UpsBased 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:
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. 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. 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. 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. 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:
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. Figure 9. Workspace display. Functional RequirementsThe 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:
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.
[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
|