Artificial-Intelligence-Based Optimization of the Management of Snow Removal Assets and Resources
MTC Project 3-A
Principal Investigator
M. D. Salim
Associate Professor
University of Northern Iowa
Co-Principal Investigators
Marc A. Timmerman
Assistant Professor
University of Northern Iowa
Tim Strauss
Assistant Professor of Geography
University of Northern Iowa
Michael E. Emch
Assistant Professor of Geography
University of Northern Iowa
Research Assistants
Alvaro Villavicencio and Ayhan Zora
Department of Industrial Technology
University of Northern Iowa
Preparation of this report was financed in part
through funds provided by the U.S. Department of Transportation
through the Midwest Transportation Consortium.
Midwest Transportation Consortium
2901 South Loop Drive, Suite 3100
Ames, IA 50010-8632
Telephone: 515-294-8103
Fax: 515-294-0467
Final Report · October 2002
TABLE OF CONTENTS
Determining the Number of Routes
Testing for Vehicles and Drivers
APPENDIX A. SRAMS User’s Manual: Installing Software and Selecting System-Suggested Routes
APPENDIX B. SRAMS User’s Manual: Manual Route Selection
APPENDIX C. SRAMS User’s Manual: Inventory Analysis
LIST OF FIGURES
Figure 1. General Paradigm of the Expert System for Snowplowing
Figure 3. Basic Knowledge Acquisition and Representation Model
Figure 4. Color-Coded Routes for Priority A
Figure 5. Routes Tab Under Options Menu
Figure 6. The Transportation Tableau
Figure 8. Editing Materials Database
Figure 9. Selection of Organization for Road Identification
Figure 11. Example Window for Asset Management
Figure 12. Selection of Route Creation
Figure 13. Display of Prioritized Route Map
Figure 14. SRAMS Configuration
Figure 15. Example Rule from RuleSet1
Figure 16. Selection of Shapefile
Figure 17. Iowa DOT Priority A Routes Created by SRAMS
Figure 19. Snapshot for Test Case 3
Figure A.1. Install SRAMS Window
Figure A.3. Selecting Weather Conditions
Figure A.4. Weather Conditions Window
Figure A.5. Selecting Route Definition from Run Menu
Figure A.6. Selecting Base Map Database File
Figure A.7. Selecting Route Definition: Manually or Automatically
Figure A.8. Adding Road Information Progress Bar
Figure A.9. Map of the Selected Database File
Figure A.10. Selecting Information Progress Bar
Figure A.11. Creating Routes Progress Bar
Figure A.12. “Routes for Priority A Created” Notice
Figure A.13. Map of Priority A Routes; Priority B Button Activated
Figure A.14. “Routes for Priority B Created” Notice
Figure A.15. Selecting Activated Priority C Button
Figure A.16. “Routes for Priority C Created” Notice
Figure A.17. Selecting Activated Priority D Button
Figure A.18. “Routes for Priority D Created” Notice
Figure A.19. Selecting Save Map Button to Save the Layers Created
Figure A.20. Warning for Map Already Exists
Figure A.21. Warning for Routes Already Exist
Figure A.23. Click Close Button to Exit
Figure B.1. Welcome Window of SRAMS
Figure B.3. Selecting Route Definition from Run Menu to Load the Desired Map File
Figure B.4. Directory Window for User to Select Base Map Shapefile
Figure B.5. Window Locating the Sample Data File
Figure B.6. Selecting Base Map Shapefile
Figure B.7. Select Route Definition: Manually or Automatically
Figure B.8. Adding Road Information Progress Bar
Figure B.9. Route Definition Map
Figure B.10. Example: Selecting a Segment of the Road
Figure B.11. Example: Ending the Route
Figure B.12. Opening Shapefile to Load a Route
Figure B.13. Loaded Route Window
Figure B.14. Are You Sure You Want to Delete the Selected Plink from the List?
Figure B.15. View of the Map after Plink 15081 Is Erased from the Route
Figure B.16. Window After Adding Second Route
Figure C.2. Select Inventory Analysis
Figure C.3. Locate Material.dbf File
Figure C.4. Inventory Analysis Main Window
Figure C.5. Selecting Materials from the Edit Menu
Figure C.6. Materials Form Window
Figure C.7. Adding Material2 and Related Information to Window
Figure C.8. Adding Sand to Material.dbf
Figure C.9. Inventory Analysis Window after Salt and Sand Are Added
Figure C.10. Selecting Salt for Analysis
Figure C.11. Missing Parameters Warning
Figure C.12. Find Optimum Reorder Point Window
Figure C.13. Inventory Optimal Results (Optimum Reorder Points Are Found)
Figure C.14. Window to Select Material to be Modified
Figure C.15. Window to Modify Materials
Figure C.16. Material Sand Removed from Database
LIST OF TABLES
Table 1. Decisions Given by RuleSet
Table 2. Priority Level Criteria for DOT
Table 3. Test Cases for Routes
Table 4. Test Cases for Vehicles and Drivers
Table 5. Actual Iowa DOT Data for Moderate Intensity Snow Removal Operations
Table 6. SRAMS-Generated Data for Moderate Snowfall in Black Hawk County
Table 7. SRAMS-Generated Data for Snow Storm in Black Hawk County
Table 8. Comparative Study Results
ACKNOWLEDGMENTS
This work was funded through a grant from the Midwest Transportation Consortium using funds from the United States Department of Transportation and funds from the University of Northern Iowa.
This report presents the results of research on the development of an intelligent system to integrate a generation of snowplowing routes and the optimization of resource/asset allocation for snow removal. The developed system, known as the snow removal asset management system (SRAMS), is an expert system containing the logical rules and expertise of the Iowa Department of Transportation’s snow removal experts in Black Hawk County, Iowa, and a geographic information system to access and manage road data. The system is implemented on a mid-range PC by integrating MapObjects 2.1 (a geographic information systems package), Visual Rule Studio 2.2 (an artificial intelligence shell), and Visual Basic 6.0 (a programming tool).
The main goal of the study was to build a knowledge-base that allows the Iowa Department of Transportation and other agencies to optimally manage snow removal assets and resources. The SRAMS was designed to be fully interactive and include provisions for entering meteorological observations and field data to refine the snow removal plan. The system is able to run various scenarios and generate prioritized snowplowing routes in visual format, and to optimize the allocation of assets and resources for snow removal. A test of the system reveals an improvement in snowplowing time by 1.9 percent for moderate snowfall and 9.7 percent for snowstorm conditions over the current manual system. Another major benefit of the system is its ability to track inventory of materials such as salt and sand.
This report also documents knowledge acquisition and system design, the algorithms used for optimization, and system validation and field testing. Several appendices with more detailed information are provided at the end of the report.
This report summarizes the results of research on the development of an intelligent snow removal asset management system (SRAMS) to optimize resource allocation. The SRAMS uses MapObjects 2.1, a geographic information system (GIS) package, to access and manage road and bridge data; Visual Rule Studio 2.2, an artificial intelligence (AI) shell, to create a knowledge base; and Visual Basic 6.0, a programming tool, for its user interface.
Keeping roads clear of snow and ice during the winter months is a major expense for many regional and local governments. Thus, there is much interest in the development of analytical tools to support improved resource allocation, since even marginal cost efficiencies can yield very high aggregate benefits. The essential issues to be considered in snow removal are the allocation of personnel resources (drivers, mechanics, supervisors), the distribution of materials (road salt, road sand, other ice/snow removal chemicals), the deployment of equipment (snowplows, dump trucks, supervisor trucks), the observance of financial constraints (salaries, materials, repair costs), and the maximization of overall effectiveness (e.g., minimizing dead-heading or the movement of plows on roads already plowed, ensuring that safety-critical and time-critical roads such as access points to hospitals, schools, and major employers are plowed quickly). Because the movement of assets becomes difficult or impossible once snow has accumulated, a great deal of planning and preparation is needed to ensure that adequate stocks are in place at the right times and in the right places. Prediction focuses on several factors including meteorological data and geographic information. Knowing how much snow is expected and in what time frame is important for allocating resources.
Both a knowledge base and a GIS database were developed to support the SRAMS. In order to build the knowledge base, an advisory board consisting of road maintenance engineers, supervisors, and managers was assembled. Through the knowledge elicitation process, a series of interviews was conducted with local and state winter maintenance personnel on a wide variety of issues related to their snow removal procedures. Personnel from the city, county, and state levels of government were interviewed to consider any difference in standard operating procedures by type of agency or scale of operation. Typical issues discussed during these formal interviews included route prioritization, procedures for managing drivers and vehicles, treatment of the roads with salt and sand, inter-agency and intra-agency communication and coordination, minimum snowfall thresholds to mobilize equipment, and other decision-making procedures related to the management of snow removal assets. The responses were formalized and incorporated into the SRAMS.
The system also required roadway data to support the allocation of routes, drivers, and other resources. For this, a GIS database for all roads in the case study area (Black Hawk County, Iowa) was obtained from the Iowa Department of Transportation (Iowa DOT). This database consisted of a GIS shapefile and several related database files with traffic volumes, roadway inventory information, and other data. The data elements required for the SRAMS were extracted from this database and a new shapefile was generated for incorporation into the system.
This report documents the development of SRAMS and its components. A literature review of the state-of-the-art and practice is provided. The report presents the functional specifications and architecture of the system, followed by a description of the program development, system implementation and testing. Evaluation of field testing and conclusions are included, and future research directions are outlined. Several appendices of more detailed information are also provided.
A considerable amount of literature on transportation asset management has been completed. Recent publications have outlined the general case for applying asset management tools in the transportation construction and infrastructure maintenance industries [11, 12, 15, 29, 47]. Ruben and Jacobs [36] and Spalding [39] have approached asset management problems in transportation from a more applied perspective by exploring the use of asset management for the supply of construction materials. Iraqi et al. [21] have described the implementation of computer resources for construction-site management and applied real-time site-based sensors for monitoring potential construction logistics problems.
A substantial amount of research on the integration of databases and expert systems, the application of GIS in transportation asset management, and basic principles of applying optimization techniques is available. In the area of expert system development, recent papers include the work of Begur et al. [2], who integrated GIS information in the optimization of routing for visiting nurses, and Weigel and Cao [49], who optimized the routing of Sears service vans using operations research methods combined with GIS to save $42 million per year. In the area of municipal public works projects, Tsai and Frost [45] have integrated a GIS database with a knowledge base for toxin remediation, and Kamler and Beckel [23] have illustrated the integration of GIS with other databases for public transport management.
Several agencies’ efforts in implementing transportation asset management systems have been documented recently [9, 30, 40]. In the area of integration of GIS in asset management for public works, relevant works include that of Chang, Lu, and Wei [4] in municipal solid waste removal, Yeh and Tram [51] in electric power delivery, and Taher and Labadie [43] in municipal water distribution. The Federal Highway Administration of the United States Department of Transportation [13] has conducted research to develop programs that are capable of integrating urban planning travel models and GIS packages such as ArcView, AtlasGIS, MapInfo, and Maptitude. Loomis [27] has developed a computerized asset management system integrated with GIS. A paper in this area is that of O’Neil [32], who described the use of GPS in municipal transportation planning.
Several papers have contributed to the literature describing the application of optimization theory to transportation problems, including the work of Powell and Sheffi [34], describing probability techniques of stochastic methods for public transit service optimization, and Hall [16], discussing the generalization of these techniques to study travel times of vehicles. The application of heuristic techniques in optimizing of transportation problems has been reported in many publications [3, 5, 6, 44, 46]. In addition, there have been several studies using AI techniques to optimize transportation problems. For instance, Stiles and Glickstein [42] have described the use of low-level but highly scalable programming elements called “cellular automata” to solve this class of problems, and Kaufman et al. [24] have applied a proprietary IBM software package called “OSL Branch and Bound” to optimize public transit for the city of Sioux Falls, South Dakota. Pattnaik et al. [33] have used genetic algorithms, and Holmes and Jungert [18] have used geometric pattern analysis, to solve similar problems.
As an AI tool, expert systems have been used by several researchers in transportation. For example, Ljunberg [26] has developed an expert system for the selection of deicing material for winter road maintenance. Hung and Jan [19] and Jia [22] implemented knowledge-base techniques for construction problems, and Melhem et al. applied such systems to steel bridge construction [28].
The implementation of an expert system for asset management requires careful consideration and the selection of appropriate algorithms. Sayed and Razavi [38] compared several AI-based algorithms with more traditional mathematical approaches. Cortina and Low [7] developed a computer program, Snowman, for the town of Brighton, New York to improve snowplow routes. Walker [48] discussed advances in materials, application techniques, equipment, and operations, and suggested to maintenance and operations managers that they review new technologies and practices and select methods that are appropriate for their agencies.
With all the literature existing related to transportation asset management and optimization, the use of GIS for planning snowplow routes, expert systems for transportation infrastructure maintenance, the importance of and interest in these topics is evident. Researchers have also discussed the possible use of decision-science tools for optimizing asset management [3, 5]. The software that is developed in this project combines and integrates GIS spatial information, asset, resource, and traffic information in existing databases, and AI decision-science optimization tools to optimally manage assets for snow removal by the Iowa DOT in Black Hawk County.
The provision of snow removal services during winter months on a consistent basis requires informed decision making at a variety of levels, from the planning stages, to the selection of routes and assignment of snowplows and required materials, and finally to operation and maintenance activities. The allocation of resources at each level of the asset management process entails unique considerations, but common issues emerge throughout all levels. In Black Hawk County, individual maintenance stations for the city, county, and state are responsible for snow removal. Currently, snow plans used by maintenance personnel are done manually, and consist of one or more plowing routes. Each route, in turn, consists of one or more segments of roads. City, county, and state personnel use different criteria to prioritize routes (e.g., interstates are assigned priority A by the Iowa DOT). Priority A routes must be cleared before priority B routes, if simultaneous plowing is not possible due to the unavailability of plows, and so on. Once prioritized snow plans are available, snowplows are assigned to the routes, and materials such as salt and sand are allocated, if necessary. During heavy storm events, new snow plans and routes are created that are different from the snow plans for normal snowfall. Decision making for snowplowing problems needs to be agile in its response to unpredictable circumstances such as weather. Most important, snowplowing problems involve large numbers of variables, large numbers of constraints, and complex interactions. As such concerns make snowplowing problems intractable by conventional mathematical optimization and AI techniques, they require novel methods.
Figure 1 shows the general paradigm of the intelligent (expert) system developed for snowplowing. The creation of an expert system begins with a series of detailed interviews of experts in the application area, in this case transportation managers, planners, and engineers. The questioning takes the form of both qualitative discussions and quantitative surveys. Knowledge engineering is the process of analyzing this information and developing a knowledge base. The knowledge base consists of a set, often very large, of predicate-calculus format rules:
Format—
If (input variables ® input tests), then (predicates ® output variables).
Example—
If (climate = torrential rain), then (work location = inside).
Figure 1. General Paradigm of the Expert System for Snowplowing
These predicate-calculus format rules can be used either sequentially or simultaneously, depending on the nature of the knowledge to be implemented. The inference engine portion of the software implements these rules. The implementation can be quite complex as the rules may be interrelated both sequentially and simultaneously in unobvious ways. Clearly, the causality and direction of information flow must be carefully monitored.
The user interface portion of the expert system secures input variable information from the users of the system and delivers output variable instructions to the users. The user interface translates the information content of the output variables into useful formats such as personnel rosters, bills of materials, and route maps for drivers. Special interfaces include connections with GIS databases, asset databases, and material inventory systems. As all of these databases and information streams use different protocols and conventions, exceptional challenges occur for programming the interface and translation engines of this subsystem.
The knowledge acquisition subsystem serves three distinct functions. First, this subsystem allows the knowledge engineers to formulate and enter predicate-calculus based rules. Second, this subsystem implements learning functions. The predicate-calculus based rules are not static, but are dynamically refined and modified to implement new knowledge. The knowledge engineers can use information such as statistical analysis of rule firings to eliminate or inactivate rules. Similarly, problems and suggestions reported by the users can be used to modify and expand the knowledge base. Third, this subsystem serves as a front-end for the knowledge base. It arbitrates queries from the user interface, and secures and delivers information as requested by the system users. As the knowledge base deals exclusively with formal variables and is programmed using Lisp or proprietary AI languages, it is not suitable for direct access by the users. The subsystem uses programming constructs such as menus, radio buttons, and related graphical displays to make the system accessible to non-specialist users.
Figure 2 shows the architecture of the system that was developed. The function of this system is to optimize the allocation of resources for snow removal. Both a knowledge base and a GIS database were developed to support the expert system. The expert system also requires roadway data to support the allocation of routes, drivers, and other resources. For this, a GIS database of all roads in the case study area (Black Hawk County) was obtained from the Iowa DOT. This database consisted of a GIS shapefile and several related database files with traffic volumes, roadway inventory information, and other data. The data elements required for the snow removal management system were extracted from this database and a new shapefile was generated for incorporation into the expert system.
The knowledge base, GIS database, and programming efforts were integrated into an expert system with a user-friendly interface. The interface, created in Visual Basic 6.0, provides a series of features to guide non-expert users in inputting the required information.
The process of knowledge elicitation, sometimes referred to as knowledge acquisition or knowledge engineering, is the most important task in the development of an expert system. This is required to reduce a large body of knowledge to a precise set of facts and rules. The term “knowledge engineer” is used for the person responsible for acquiring knowledge for specific system development. The following is a brief job description for knowledge engineers:
Knowledge acquisition is a bottleneck in the construction of expert systems. The knowledge engineer’s job is to act as a go-between to help an expert build a system. Since the knowledge engineer has far less knowledge of the domain than the expert, however, communication problems impede the process of transferring expertise into a program. The vocabulary initially used by the expert to talk about the domain with a novice is often inadequate for problem solving; thus, the knowledge engineer and expert must work together to extend and refine it. One of the most difficult aspects of the knowledge engineer’s task is helping the expert to structure the domain knowledge, to identify and formalize the domain concepts [17].
Thus, the basic model for knowledge engineering has been that the knowledge engineer mediates between the expert and knowledge base, eliciting knowledge from the expert, encoding it for the knowledge base, and refining it in collaboration with the expert to achieve acceptable performance. Figure 3 shows this basic model with manual acquisition of knowledge from an expert followed by interactive application of the knowledge with multiple clients through an expert system shell:
· The knowledge engineer interviews the expert to elicit his or her knowledge.
· The knowledge engineer encodes the elicited knowledge for the knowledge base.
· The shell uses the knowledge base to make inferences about particular cases specified by clients.
· The clients use the shell’s inferences to obtain advice about particular cases.
Figure 3. Basic Knowledge Acquisition and Representation Model
In order to build the knowledge base, an advisory board consisting of road maintenance managers, supervisors, engineers, and a GIS coordinator was assembled. Several structured interview sessions were held over the course of preparing the knowledge base. Although the development of the system was geared toward the use by Iowa DOT in Black Hawk County, personnel from the city, county, and state levels were interviewed to consider any difference in standard operating procedure by type of agency or scale of operation. In addition, several follow-up interviews were conducted by telephone. Some experts (e.g., the snow removal expert of the Iowa DOT in Waterloo, Black Hawk County) were available for several interviews. In the follow-up interviews, the knowledge engineer summarized what was discussed in the interviews and presented the rules that had been derived. These follow-up interviews eliminated any sort of inconsistencies, misunderstanding, and misrepresentation of the rules. Guidelines for knowledge acquisition are available in many publications [17, 22, 28] and are not reported here. Interviews were tape-recorded and encoded transcripts were used to formalize the knowledge in the form of rules.
The main factors that need to be considered in optimizing the allocation of snow removal assets are (1) annual average daily traffic (AADT), (2) route prioritization, (3) number of lanes, (4) operation time for each vehicle, (5) pavement type (concrete or bituminous), (6) availability of vehicles and drivers, (7) treatment of roads with salt/sand, and (8) minimum snowfall thresholds to mobilize equipment. These factors were identified by the experts during the knowledge elicitation process. On completion of the knowledge elicitation process, the knowledge engineer or the system developer needed to structure the key concepts, rules, and knowledge, and transform them into a representative scheme suitable for the selected AI shell, i.e., Visual Rule Studio 2.2. The knowledge base and sample representation of rules are discussed in more details in the “System Implementation” section of this report.
The main purpose of planning routes for the plows is to remove snow using the least amount of resources such as driver time, plows, sand, and salt. In doing so, it is important to reduce and possibly eliminate “deadhead” travel for snowplow, i.e., travel time without plowing. Since Dijkstra’s shortest path algorithm is well studied and documented, we have selected this algorithm to solve the problem of generating routes [7]. The employment of Dijkstra’s shortest path algorithm ensures minimization of deadhead travel.
Determining the Number of Routes
In the route generation process, priority levels are considered independently. For each priority level, the total plowing time is estimated by using the information available in DOT databases. The number of vehicles to be assigned for each priority level is determined as follows:
,
where N is number of routes, Tp is total estimated plowing time, and Tmax is maximum allowable operation time for each vehicle.
Then the SRAMS determines the actual plowing time for each available snowplow:
,
where Ta is actual plowing time per vehicle.
This is the leveling of load distribution and it is used to ensure distributing the load of snow removal to assigned trucks evenly.
To begin the process, SRAMS looks for segments of roads that are connected to an initial segment defining an edge on the map. These segments are starting points for each priority level in the selected map. Next, all of the segments that are connected to the starting segment are determined and placed in a stack in order of priority. The top one is picked for the process of adding segments. If the connection of segments is finished, SRAMS generates a jump in the route and uses Dijkstra’s shortest path algorithm to determine the next road segments to be added to define a specific route. This continues until the total plowing time of the route exceeds the Ta (actual plowing time).
After defining N routes, SRAMS generates maps with color codes for the easy identification of routes. For example, routes in color codes as shown in Figure 4 was accomplished by creating the following shapefiles:
DOTLAYERA.shp
ROUTE1.shp
ROUTE2.shp
These names are given automatically by the program. Note that the combination of ROUTE1.shp and ROUTE2.shp constitutes DOTLAYERA.shp as presented in Figure 4.
1. A vehicle cannot be assigned to more than one route, and a route cannot have more than one vehicle assigned.
2. A vehicle can be assigned to more that one route. and a route can have more than one vehicle assigned for snowplowing.
These two (1 and 2 above) distinctive optimization problems are known as the Assignment Problem and the Transportation Problem, respectively. The user has control on the SRAMS to decide which type of optimization problem is to be solved. The “Use Vehicle on multiple Routes” field in the Routes tab under the Option menu is specified for this purpose (see Figure 5).
Similarly, if some slack operators are introduced, the same number of routes will not be snowplowed during the operation. The formulization of the assignment problem is as follows:
Minimize 
,
where i = truck; j = route; Cij = total cost per route for the assigned snowplow/vehicle; and Xij = assignment of vehicle i to route j where 0 = not assigned and 1 = assigned.
Constraints:
(For
each vehicle, only one route can be assigned.)
(For
each vehicle, only one route can be assigned.)
The formulization of general transportation problem is as follows:
Minimize 
Constraints:
where Cij = unit cost (dollars/minute) coefficient for ith snowplow working on jth route, Xij = time in minutes that ith snowplow on jth route, Si = the operating time of ith snowplow, and Dj = the required operating time for jth route.
Note that the unit cost (dollars/minute) will not just depend on the route that the vehicle is assigned to. Thus, Ci1 = Ci2 = … = Cin = Ci. The objective function can be simplified as follows:
Minimize 
Usually the transportation problem is set up within the context of a tableau (see Figure 6). Each cell in the tableau represents the allocated time for each vehicle (row) on the route (column). The small box within each cell contains the unit snowplowing cost (Ci) of the vehicle on the route. The last column and the last row represent the allowable operating time for each vehicle and the required plowing time for each route, respectively.
Figure 6. The Transportation Tableau
The stepping-stone solution technique can be used to solve (n x m) transportation problems [9]. Prior to applying this technique, an initial solution must be determined. As Russell and Taylor [37] state, “In a transportation model an initial solution can be found by several alternative methods, including the northwest corner method, the minimum cell cost method, and Vogel’s approximation method.” The Vogel’s approximation method (VAM), which is very well established to find a consistent initial solution for the transportation problem, is selected to be coded for SRAMS. The steps of VAM are given by Russell and Taylor as follows:
1. Determine the penalty cost for each row and column by subtracting the lowest cell cost in the row or column from the next lowest cell cost in the same row or column.
2. Select the row or column with the highest penalty cost.
3. Allocate as much as possible to the feasible cell with the lowest transportation in the row or column with the highest penalty cost.
4. Repeat steps 1, 2, and 3 until all rim requirements have been met.
Once the initial solution is obtained, the stepping-stone method can be employed to find the optimal solution. The summary of the stepping-stone method provided by Russell and Taylor is given below:
1. Determine the stepping-stone paths and cost changes for each empty cell in the tableau.
2. Allocate as much as possible to the empty cells with the greatest net decrease in cost.
3. Repeat steps 1 and 2 until all empty cells have positive cost changes that indicate an optimal solution.
Two main cost categories are considered for SRAMS: operating cost (Coi) and material cost (Cmi).
The unit operating costs of snowplows are entered by the user and stored in the Machine.dbf database. The user can open and edit this database by selecting Vehicles from the Edit menu (see Figure 7). Once the route assignment is accomplished, the operating durations (Toi) for each piece of equipment are determined by the SRAMS. Thus, the total operating cost (TOC) is calculated as follows:
n
TOC = S Coi * Toi where snowplow i = (1,…,n)
i = 1
Similarly, the unit material costs (Cmj) are stored in Material.dbf and can be reached from the Edit menu (see Figure 8). The quantity of material (Qmj) use is determined by adding necessary material for each route, and then the total material cost (TMC) is calculated as follows:
k
TMC = S Cmj * Qmj where material j = (1,…,k)
j = 1
Total cost (TC) = TOC + TMC.
Figure 8. Editing Materials Database
The SRAMS uses the following databases for Black Hawk County: Black_hawk_roads.shp, Dirlane.dbf, Info.dbf, Inventor.dbf, and Traffic.dbf. These database files are available from the Iowa DOT for download over the Internet. Using a common denominator called Mslink for each road segment, all of these five databases were integrated. Black_hawk_roads.shp is a shape file containing a polyline for each road segment so that it can be viewed using many GIS tools. Each shape file is accompanied by two other files with the same file name as the shape file but with the file extensions of .dbf and .shx.
The attributes of the files are as follows:
Shape: Includes polyline for each road segment.
Mslink: Auto increment variable. Key element for linking with databases created by SRAMS.
Jurisdic: Indicates the jurisdictional responsibility for the segment of road.
Stateroute: Indicates whether road is primary, secondary, municipal, or institutional.
Nineoneone: Street name.
Gradesigna: The number of automatic traffic signals at grade intersections in the road segment of road that is being traveled.
Gradestop: The number of stop signs at grade intersections in the road segment being traveled.
Gradeother: The number of intersections in the road segment that is being traveled with no signals or stop signs.
Aadt: This field indicates the AADT on this road segment. This is applicable for primary, secondary, and municipal roads.
Laneleng: Length of a road segment.
Surfwidth: Width of the road.
Citynum: Identifies if road segment is within the city.
Urbanarea: This field identifies if the road segment is within an urban area.
Interstate: Indicates whether or not a road system is classified as an interstate.
Truckrte: Indicates whether or not the road is on a truck route on the primary road system only.
Lanetype1-9: Identifies the type of each lane from the left side of the road segment to the right side. There are nine possible values.
1: Through lane (lane used for traffic continuing in main direction.
2: Climbing lane (lane signed for such use).
3: Right turn lane (lane constructed for right turns only).
4: Left turn lane (Lane constructed for left turns only).
5: Center turn lane (painted lane used by both directions for left turns).
6: Exit lane.
7: Entrance lane.
8: Reversible lanes (electronically controlled lane direction).
9: Other.
Hwyresp: Indicates the level of service provided by the highway. A, B, C or D.
Numlanes: Number of lanes.
Planclass: Five level classification for planning and programming the primary road system.
1: Interstate.
2: Commercial and industrial network.
3: Area development.
4: Access roads.
5: Local service.
Surftype: Type of road surface.
Additional databases are required for the management of resources such as materials, snowplows, and personnel for operating the equipment. As such, three additional databases—Material.dbf, Machine.dbf, and Operator.dbf—are created. If these databases are not available in the same folder of the selected shape file, they will be created automatically by the SRAMS.
The database file Machine.dbf contains information on available snowplows, which includes the following attributes:
Descriptio: String description of the snowplow, which may include brand and general characteristics.
Capacity: Snow removal capacity of the snowplow. It may include cutting width in inches or overall height of the snow removal tool. For this project, the overall height of the removal tool is used.
ID: Represents the license plate of the truck.
Cost: Hourly cost (dollars) of operation of the machine.
Maintenanc: The mileage for equipment maintenance.
Current: Odometer reading prior to assignment of the machine.
Material.dbf incorporates the details of the materials available at the central storage for snow removal. It may include chemicals, sand and other materials. The structure of the database is as follows:
Descript: String description of the chemical/material.
Qty: Available quantity at the central storage facility before the start of the operation.
Cost: Unit cost of the material.
ROP: Reorder point
Units: Units of measure truck as liter, pound, or ton.
Operator.dbf is a database that includes information about the operators who will be assigned to each snowplow. It considers operator preferences. The structure is as follows:
Operator: String containing the name of the human operator.
Pref1: Assignment of the operator to the first preferred machine.
Pref2: Assignment of the operator to the second preferred machine.
Pref3: Assignment of the operator to the third preferred machine.
In order to improve the functionality of the computer program, other databases are created runtime by SRAMS. The controls of these files are not given to the user. These files are listed below:
Station.dbf
Stationd.dbf
Assgdrv.dbf
Assgmach.dbf
DOTLayerA.shp
DOTLayerB.shp
DOTLayerC.shp
DOTLayerD.shp
Map.shp
RouteX.shp where (X = 1 … n: number of routes)
Valmach.dbf
The user interface is the means by which the user and the expert system communicate with each other. Barnett et al. [1] pointed out that, although all computer programs have user interfaces (no matter how primitive), the expert system’s user interface must be extremely sophisticated in order to allow more complicated dialogue between the program and the user. The interface of SRAMS is designed to handle this inevitable sophisticated dialogue easily and intuitively by employing powerful graphical user interface (GUI) components. Several key requirements have particularly shaped the user interface design:
- user control
- flexibility
User control is cited as “good tool” principle number one by Cox and Walker [8]. Galitz [14] has defined it as “feeling in charge” and “feeling that the system is responding to your actions.” Because of the dynamic characteristic of weather conditions and asset allocation, this design principle becomes essential for snow removal problems.
Flexibility is the system’s capability to respond to individual differences in people. In this sense, it contributes to increased user control. SRAMS is designed to support snow removal managers in devising and maintaining snowplow plans for three different organizations: state, county, and city (see Figure 9). Flexibility is required not only to solve the problem at three different levels, but also to serve users with different knowledge, skills, and experience. It should be noted the SRAMS has been developed for Iowa DOT use in Black Hawk County; however, modules for county and city analyses are added for future inclusions in the system.
Figure 9. Selection of Organization for Road Identification
The Design
The general interface organization is around a standard window (see Figure 10) that the user can find in most standard Microsoft Windows menu options. Additional specific menu items are also created to enhance decision making for snow removal. Assets (material, operator, and snowplow) can be analyzed and controlled by a similar window (Figure 11). Data entry by the user is very simple. SRAMS has the flexibility of allowing the user to create routes either manually or automatically. When the user requests a route definition by selecting the proper menu option, the program asks which type of definition is preferred (Figure 12).
Figure 11. Example Window for Asset Management
Figure 12. Selection of Route Creation
In the design of the output screen, the graphical display capabilities of MapObjects 2.1 are used. A legend is provided to the user to enable/disable the display of the route layers as well as control their thicknesses, and colors. In order to manipulate the display of the resulting map, toolbars, scrollbars, and buttons are conveniently provided, as presented in Figure 13.
Figure 13. Display of Prioritized Route Map
SRAMS was implemented by integrating Visual Rule Studio Professional 2.2 (expert system shell) running under Microsoft Windows, Visual Basic 6.0, and MapObjects 2.1 (GIS package). Programs were written in Visual Basic to support the user interface. Visual Rule Studio provides dynamic rule generation and expanded database facilities, and permits the creation of reusable business rule objects. The knowledge base, knowledge acquisition subsystem, and inference engine were all programmed in the proprietary system language used by the Visual Rule Studio expert system shell. MapObjects 2.1, produced by Environmental Systems Research Institute, Inc., was used to sort, format, and import geographical roadway information into the Visual Basic platform to generate road maps, and other graphical outputs for the user interface.
The program runs under the Microsoft Windows environment. At the start of any session, the user is required to select the GIS shapefile for a specific county. Then the program automatically links all of the related GIS databases using the MSLINK field, which has distinctive data for each road segment. The shapefile is displayed as a map using MapObjects. The data for materials, operators, and snowplows/trucks are stored in DBF format, and are retrieved from the databases when needed through the Visual Basic interface. The logic is stored as rule sets in Visual Rule Studio. The Visual Rule Studio is integrated with Visual Basic and can be called up in Visual Basic as an Active Designer. Visual Basic acts as a user-friendly interface. The system configuration is shown in Figure 14.
Figure 14. SRAMS Configuration
Example rules from Visual Rule Studio are shown in Figure 15. Rule sets are located under Active Designers, and can be reached by using object oriented technology. The rule set—namely, RuleSet1—is developed to make the two decisions: “suggstatus” (suggested status) and “expcond” (expected condition). Their possible values are listed in Table 1.
Figure 15. Example Rule from RuleSet1
Table 1. Decisions Given by RuleSet
| suggstatus (suggested status) |
noaction |
no action |
| normalop |
normal operation |
|
| reinforce |
reinforce |
|
| emergency |
emergency |
|
| expcond (expected condition) |
nostorm |
no storm |
| possible |
possible storm |
|
| storm |
storm coming |
In Black Hawk County, plowing starts when there is an accumulation of at least two inches of snow under normal condition, i.e., no stormy or blizzard condition. According to the experts interviewed for establishing the knowledge base, a snowplow can effectively plow 25 miles/lane of a road in an hour under normal conditions. In the case of stormy or blizzard conditions, half of the distance can be plowed, i.e., 12.5 miles/lane/hour. Again, each snowplow is deployed for two consecutive hours for the first time. A decision as to the assignment of the same snowplow for the second time depends on plowing needs and the availability of snowplows for the first time assignment.
To run the program, the user is required to locate and select the shapefile for the county, as shown in Figure 16.
Figure 16. Selection of Shapefile
Once selected, a map displaying the road network in the selected county appears on the screen. The Iowa DOT uses four different priorities for route selection: Priority A, Priority B, Priority C and Priority D. Iowa DOT selection criteria used in prioritizing routes are presented in Table 2.
Table 2. Priority Level Criteria for DOT
| Priority |
Decision Criteria |
| A |
Interstate Industrial commercial network |
| B |
AADT ³ 5,000 vehicles/day |
| C |
5,000 > AADT ³ 2,000 vehicles/day |
| D |
AADT < 2,000 vehicles/day |
Automated generation of two routes (route1 and route2) for Iowa DOT priority A is depicted in Figure 17. Routes for other priorities can be similarly generated. A legend, which enables user to select the desired thickness and color, is provided for the convenience of the user. The system allows either activating or deactivating any route in the display area. For more details, refer to the SRAMS User’s Manual in Appendices A, B, and C.
Figure 17. Iowa DOT Priority A Routes Created by SRAMS
VALIDATION AND FIELD TESTING
The validation of any developed intelligent system is necessary before using the system in real-world applications. In other words, validation is required to ensure the system or model performs with an acceptable level of accuracy. As Knauf et al. [25] have indicated, “Initially, validation efforts were not formal and highly individualized often characterized as a ‘craftsman approach’ which exercised program code against a small set of ad hoc test cases. As modeling efforts grew from rather small projects to more complex endeavors, validation complexities increased. Later, more rigorous validation techniques backed by statistical tests were developed.” Thus, validation is an imperative component of any expert system research and development. Many of the validation techniques currently in use by expert system modelers owe their foundation to early simulation and conventional software developers.
O’Keefe and O’Leary [31] have defined verification and validation as building the system right and building the right system, respectively. Verification provides a firm basis for the question of whether or not a system meets its specifications. In contrast, validation is the process of determining whether the system actually fulfills the purpose for which it was intended. The following section describes the validation of the SRAMS.
Validation of the SRAMS
The validity of an expert system determines the validity of the technical
content of the knowledge represented in the system. That is, to what extent
is the user satisfied with the technical details provided in the system?
To what extent are the utilities provided useful? Knauf et al. [25] propose
a validation methodology with the following steps:
1. Test case generation
Generate and optimize a set of test input combinations that will simulate the inputs to be seen by the system in actual operation.
There are two necessities opposing each other in this step:
a. Coverage: ensuring that all of the possible test cases covered for completeness.
b. Efficiency: minimizing the number of test cases to make the process more practical.
2. Test case experimentation
Since expert systems reproduce human expertise, it is more convenient to employ human opinion when evaluating the correctness of the system’s response. However, human experts may have their bias for or against the process of automation. Thus, the existence of a method is very important to fairly evaluate the correctness of the system’s outputs given imperfect human expertise. Therefore, this step consists of evaluating the test data by an intelligent system as well as by validating experts.
3. Evaluation
In this step, the results of the experimentation step are interpreted and errors recognized by the system are determined, then validity assessments related to the test cases are reported.
4. Validity assessment
Results in the evaluation steps are analyzed and conclusions are made about the validity of the system. The types of the results of this step are listed below:
a. Validities associated with outputs (for potential users).
b. Validities associated with rules (for system developers and knowledge engineers).
c. Validities associated with test cases (for system refinement).
5. System refinement
This step constitutes the improvement of the system as a result of the previous four steps. This leads an improved rule base with respect to the examined test cases and knowledge base in general. Figure 18 provides a flow chart for the SRAMS validation process.
Any engineering product can be tested in one of two ways: (1) black-box testing and (2) white-box testing. Pressman [35] made this assertion and also stated, “White box testing of software is predicated on close examination of procedural detail. Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and/or loops.” Creating test cases for all of the logical paths for even small software can be impractical to manage. The SRAMS is constructed with around 9,000 lines of codes in Visual Basic, excluding the codes for the knowledge base. It can be considered a large piece of software.
Black-box testing is used at the interface to exhibit that software functions are working properly. It is also used to demonstrate that input is appropriately accepted and output is adequately produced, and that integrity of external data is preserved.
Although it seems that white-box testing produces 100 percent correct programs, it is not always practical to consider all logical paths since the number of paths increases exponentially. Thus, black-box testing was employed for the validation of the SRAMS. Testing was conducted in three different categories:
- routes
- vehicles and drivers
- materials
The test cases designed to test SRAMS for routes are given in Table 3.
Table 3. Test Cases for Routes
| Case |
Name |
Description |
| 1 |
No DOT roads |
No entry for “jurisdic“ field in Black_hawk_roads.dbf has a domain value of “1” that is reserved for Iowa DOT roads. |
| 2 |
Only one DOT road |
Only the first record of the entire database has domain value of “1” for the “jurisdic” field. |
| 3 |
One DOT road for each priority level |
Priority A, B, C and D have only one road under Iowa DOT responsibility. |
| 4 |
Multiple roads for each priority level |
Each priority (A, B, C and D) has more than one road under Iowa DOT responsibility. |
Case 1: This case is designed to test the reaction of the SRAMS if no Iowa DOT road is available in the given database. In the SMMS Metadata Report (downloaded from Iowa DOT website) for Iowa, the attribute of “jurisdic” for GIS sources is explained as follows:
Attribute:
Attribute Label: JURISDIC
Attribute Definition: indicates the jurisdictional responsibility for the segment of road
Attribute Definition Source: Iowa DOT Base Record Manual
Attribute Domain Values:
Enumerated Domain:
Enumerated Domain Value: 1 through 8
Enumerated Domain Value Definition:
1 Iowa DOT
2 Iowa DNR
3 Iowa Dept of SS
4 Boards of Regents
5 Federal domain
6 Local
7 Iowa National Guard
8 Other State Lands
Enumerated Domain Value Definition Source: Iowa DOT Base Record
In order to maintain the status of no Iowa DOT roads, all of the enumerated “1” entries for “jurisdic“ field in “Black_hawk_roads.dbf” database were modified to be “6,” which is defined as local roads. A total 1,012 fields (Mslink 14,752 to Mslink 15,763) were modified. The SRAMS has generated the response indicating that there is no Iowa DOT road in the selected database.
Case 2: This case is intended to test the response of the SRAMS, if there is only one road under Iowa DOT responsibility in the given database. The “jurisdic” field of very first record, which is MSLINK=14,752, in the Black_hawk_roads.dbf was changed to “1.” The “jurisdic” fields of remaining records have values other than 1. The SRAMS response was “only one DOT road is available in the database.”
Case 3: Four records (Mslink) are modified to have “jurisdic” field value of “1” as listed below.
Mslink Priority Description
14,752 A Interstate
14,903 B Iowa DOT priority B road
15,465 C AADT = 3,890 (2,000 < 3,890 < 5,000)
15,615 D AADT = 1,160 (1,160 < 2,000)
As depicted in Figure 19, SRAMS has generated four routes for four priority levels.
Figure 19. Snapshot for Test Case 3
Case 4: The original GIS data from the Iowa DOT database, without any modification, is used to test the SRAMS. The system generated all Iowa DOT routes and assigned priority to each route, as expected.
Testing for Vehicles and Drivers
The test cases designed to test SRAMS for vehicles and drivers are given
in Table 4.
Table 4. Test Cases for Vehicles and Drivers
| Case |
# of Vehicles |
# of Drivers |
Description |
| 5 |
0 |
m |
There is no vehicle to be assigned to created routes. |
| 6 |
n |
0 |
There is no driver to be assigned to vehicles. |
| 7 |
n |
m |
n > m |
| 8 |
n |
m |
n = m |
| 9 |
n |
m |
n < m |
Case 5: Machine.dbf file was emptied to ensure that there was no vehicle to be assigned to the generated routes. The system warned that no vehicle was in the database.
Similarly, all other cases (6–9) were tested and the system performed successfully.
Case 10: Material.dbf file was emptied to ensure that there was no material in stock. The system warned that the file was empty. The system also has the ability to provide information on the status of the inventory.
Currently, the Iowa DOT office in Waterloo uses 32 manually created static routes for moderate snow removal operations in Black Hawk County. Precise winter weather terminology used in Arkansas is reported in the literature [50]. In Black Hawk County, Iowa, snow removal experts use somewhat similar terminology to indicate the snowy conditions. These are as follows:
No snow: No new snow expected.
Light flurries: Intermittent light snowfall of short duration with no measurable accumulation.
Moderate intensity: A fall of snow of increased intensity, usually an accumulation of 2 inches or more but less than 4 inches over a 12-hour period.
Heavy snow: Refers to 4 inches or more in a 12-hour period, or 6 inches or more in a 24-hour period.
Snow storm: The following conditions occur for 3 hours or longer: Sustained winds or frequent gusts of 35 mph or greater, and considerable falling and/or blowing snow which frequently reduces visibility to less than 1/4 mile. This is also known as a blizzard condition.
One of the basic requirements of field testing was to gather sufficient data under comparable conditions to detect any meaningful differences between the existing Iowa DOT manual system and the developed SRAMS. Thus, to make comparative measurements in this study, it was necessary to run SRAMS twice, first considering moderate snowfall, and then heavy snow/snowstorm. Iowa DOT data for both cases are available to make comparisons. As mentioned earlier, the Iowa DOT office in Black Hawk County (our test case) uses 32 manually created static routes designated as run number in its data spreadsheet for moderate snowfall. Data for snowplowing operations in Black Hawk County in 1998–1999 is summarized in Table 5. In case of heavy snow or a snowstorm, the number of routes is doubled by the Iowa DOT (i.e., 64 plowing routes) and consequently the commitment of resources (snowplow, operators, time, etc.) is also doubled. As an approximation, the deadhead travel distance is also considered double for this heavy snowy condition compared to the distance for moderate snowfall. There is no method currently in use by the Iowa DOT for tracking actual deadhead travel during a snowstorm or heavy snowfall. The Iowa DOT usually assigns one snowplow per route, which necessitates as many snowplows as the number of routes.
Table 5. Actual Iowa DOT Data for Moderate Intensity Snow Removal Operations in Black Hawk County (1998–1999)
| Plowing Road Length (miles) |
Ramp (miles) |
Total Plowing Length (miles) |
Total time (hour) |
Deadhead Travel Length (miles) |
Deadhead Travel Time (min) |
|
| 701 |
30.5 |
30.5 |
2.0 |
9.6 |
14.4 |
|
| 702 |
30.5 |
30.5 |
2.0 |
9.6 |
14.4 |
|
| 703 |
1.3 |
7.0 |
8.3 |
2.1 |
24.6 |
36.9 |
| 704 |
1.3 |
7.3 |
8.6 |
2.1 |
24.6 |
36.9 |
| 705 |
18.5 |
18.5 |
1.9 |
6.0 |
9.0 |
|
| 706 |
18.5 |
18.5 |
1.9 |
6.0 |
9.0 |
|
| 707 |
0.0 |
4.0 |
4.0 |
1.8 |
20.4 |
30.6 |
| 708 |
22.0 |
22.0 |
1.7 |
14.6 |
21.9 |
|
| 709 |
40.6 |
40.6 |
3.6 |
16.4 |
24.6 |
|
| 710 |
8.6 |
6.4 |
15.0 |
2.3 |
39.4 |
59.1 |
| 711 |
8.6 |
6.4 |
15.0 |
2.3 |
39.4 |
59.1 |
| 712 |
8.0 |
8.0 |
2.3 |
39.4 |
59.1 |
|
| 713 |
30.8 |
30.8 |
1.9 |
2.6 |
3.9 |
|
| 714 |
30.8 |
30.8 |
1.9 |
2.6 |
3.9 |
|
| 715 |
0.0 |
8.0 |
8.0 |
1.8 |
23.0 |
34.5 |
| 716 |
39.4 |
39.4 |
2.5 |
8.6 |
12.9 |
|
| 717 |
25.4 |
25.4 |
2.2 |
20.8 |
31.2 |
|
| 718 |
13.6 |
13.6 |
1.6 |
11.4 |
17.1 |
|
| 719 |
13.6 |
13.6 |
1.6 |
11.4 |
17.1 |
|
| 720 |
19.4 |
19.4 |
1.5 |
2.8 |
4.2 |
|
| 721 |
9.2 |
9.2 |
2.1 |
0.4 |
0.6 |
|
| 722 |
9.2 |
9.2 |
2.1 |
0.4 |
0.6 |
|
| 723 |
13.3 |
13.3 |
2.1 |
5.8 |
8.7 |
|
| 724 |
13.3 |
13.3 |
2.1 |
5.8 |
8.7 |
|
| 725 |
21.0 |
21.0 |
2.2 |
6.0 |
9.0 |
|
| 726 |
21.0 |
21.0 |
1.8 |
6.0 |
9.0 |
|
| 727 |
0.0 |
15.1 |
15.1 |
2.3 |
8.4 |
12.6 |
| 728 |
0.0 |
15.1 |
15.1 |
2.3 |
8.4 |
12.6 |
| 729 |
0.0 |
11.7 |
11.7 |
2.4 |
16.4 |
24.6 |
| 730 |
11.1 |
11.1 |
2.4 |
9.2 |
13.8 |
|
| 731 |
11.1 |
11.1 |
2.2 |
9.2 |
13.8 |
|
| 732 |
11.1 |
11.1 |
2.2 |
9.2 |
13.8 |
|
| Total |
481.7 |
41.9 |
562.7 |
67.2 |
418.4 |
627.6 |
The SRAMS generated data for Black Hawk County is depicted in Table 6 and Table 7 for moderate snowfall and a snowstorm, respectively.
Table 6. SRAMS-Generated Data for Moderate Snowfall in Black Hawk County
| Route |
Effective Plowing Time (min) |
Actual Plowing Length (miles) |
Deadhead Time (min) |
Total Miles (Actual Plowing + Deadhead Travel) |
Priority |
| Route30 |
19.0 |
7.9 |
36.5 |
29.7 |
D |
| Route29 |
52.2 |
19.5 |
100.5 |
74.3 |
D |
| Route28 |
65.8 |
17.7 |
63.9 |
52.4 |
D |
| Route27 |
93.7 |
39.0 |
57.8 |
65.2 |
D |
| Route26 |
75.2 |
15.6 |
113.9 |
41.0 |
D |
| Route25 |
1.5 |
0.6 |
25.5 |
16.4 |
C |
| Route24 |
73.8 |
17.7 |
84.1 |
57.4 |
C |
| Route23 |
67.8 |
21.4 |
92.2 |
71.9 |
C |
| Route22 |
101.2 |
27.7 |
57.2 |
59.3 |
C |
| Route21 |
64.5 |
26.9 |
41.6 |
51.7 |
B |
| Route20 |
93.1 |
22.7 |
39.3 |
43.0 |
B |
| Route19 |
39.2 |
8.8 |
105.5 |
32.5 |
B |
| Route18 |
68.2 |
9.7 |
68.2 |
24.7 |
B |
| Route17 |
51.8 |
13.6 |
78.7 |
36.6 |
B |
| Route16 |
64.4 |
20.8 |
153.4 |
91.9 |
B |
| Route15 |
65.0 |
20.5 |
64.6 |
45.0 |
B |
| Route14 |
27.3 |
6.2 |
101.6 |
29.0 |
B |
| Route13 |
90.3 |
22.6 |
38.3 |
37.6 |
B |
| Route12 |
95.0 |
21.5 |
35.8 |
33.6 |
B |
| Route11 |
99.0 |
24.5 |
30.1 |
33.3 |
B |
| Route10 |
85.0 |
17.1 |
43.9 |
28.2 |
B |
| Route9 |
60.1 |
14.3 |
71.7 |
29.9 |
B |
| Route8 |
97.6 |
19.1 |
31.1 |
30.0 |
B |
| Route7 |
109.7 |
29.9 |
20.8 |
37.7 |
B |
| Route6 |
110.4 |
23.8 |
25.1 |
31.1 |
B |
| Route5 |
65.3 |
11.9 |
66.5 |
25.9 |
B |
| Route4 |
23.5 |
5.9 |
46.6 |
31.6 |
A |
| Route3 |
63.2 |
26.3 |
66.1 |
67.8 |
A |
| Route2 |
94.3 |
35.1 |
39.2 |
53.6 |
A |
| Route1 |
94.7 |
23.1 |
44.5 |
41.7 |
A |
| Total |
2,111.9 |
571.4 |
1,844.3 |
1,303.8 |
— |
Table 7. SRAMS-Generated Data for Snow Storm in Black Hawk County
| Route |
Effective Plowing Time (min) |
Actual Plowing Length (miles) |
Deadhead Time (min) |
Total Miles (Actual Plowing + Deadhead Travel) |
Priority |
||
| Route53 |
19.0 |
4.0 |
43.3 |
29.7 |
D |
||
| Route52 |
68.1 |
14.2 |
125.0 |
87.5 |
D |
||
| Route51 |
98.0 |
14.3 |
33.8 |
29.6 |
D |
||
| Route50 |
73.6 |
10.4 |
62.5 |
44.1 |
D |
||
| Route49 |
69.7 |
13.5 |
60.0 |
41.8 |
D |
||
| Route48 |
125.0 |
26.1 |
8.4 |
28.1 |
D |
||
| Route47 |
63.7 |
9.1 |
121.4 |
41.9 |
D |
||
| Route46 |
94.8 |
8.2 |
33.8 |
20.6 |
D |
||
| Route45 |
51.8 |
9.0 |
122.1 |
56.3 |
C |
||
| Route44 |
86.3 |
8.0 |
46.0 |
27.6 |
C |
||
| Route43 |
60.7 |
6.4 |
70.7 |
38.9 |
C |
||
| Route42 |
87.3 |
16.3 |
47.8 |
45.2 |
C |
||
| Route41 |
95.2 |
15.6 |
87.2 |
66.3 |
C |
||
| Route40 |
107.3 |
12.1 |
22.9 |
18.2 |
C |
||
| Route39 |
22.5 |
4.7 |
61.1 |
47.3 |
B |
||
| Route38 |
90.4 |
18.8 |
51.7 |
47.1 |
B |
||
| Route37 |
84.1 |
12.4 |
49.4 |
38.6 |
B |
||
| Route36 |
116.3 |
13.5 |
14.4 |
17.5 |
B |
||
| Route35 |
35.6 |
4.1 |
107.1 |
37.4 |
B |
||
| Route34 |
93.7 |
9.1 |
35.3 |
21.0 |
B |
||
| Route33 |
58.9 |
6.8 |
84.3 |
22.4 |
B |
||
| Route32 |
98.2 |
4.9 |
62.3 |
17.9 |
B |
||
| Route31 |
79.6 |
10.1 |
74.4 |
29.1 |
B |
||
| Route30 |
51.8 |
7.7 |
77.3 |
29.4 |
B |
||
| Route29 |
49.3 |
8.3 |
81.2 |
33.5 |
B |
||
| Route28 |
62.1 |
8.5 |
158.4 |
84.1 |
B |
||
| Route27 |
78.9 |
15.4 |
52.7 |
38.8 |
B |
||
| Route26 |
84.1 |
10.5 |
44.4 |
29.1 |
B |
||
| Route25 |
61.9 |
7.7 |
81.0 |
27.3 |
B |
||
| Route24 |
83.0 |
10.4 |
51.4 |
22.9 |
B |
||
| Route23 |
96.4 |
9.2 |
34.0 |
18.9 |
B |
||
| Route22 |
90.3 |
10.2 |
44.9 |
20.3 |
B |
||
| Route21 |
106.6 |
12.4 |
26.5 |
20.6 |
B |
||
| Route20 |
106.3 |
13.3 |
32.5 |
24.9 |
B |
||
| Route19 |
91.2 |
11.4 |
38.4 |
26.5 |
B |
||
| Route18 |
88.1 |
11.0 |
46.9 |
29.6 |
B |
||
| Route17 |
67.5 |
8.4 |
68.4 |
35.2 |
B |
||
| Route16 |
31.6 |
3.8 |
97.8 |
27.3 |
B |
||
| Route15 |
32.8 |
2.9 |
109.3 |
27.3 |
B |
||
| Route14 |
94.6 |
8.4 |
34.8 |
21.4 |
B |
||
| Route13 |
107.4 |
9.8 |
21.8 |
18.1 |
B |
||
| Route12 |
102.1 |
17.7 |
28.5 |
29.9 |
B |
||
| Route11 |
126.4 |
15.8 |
13.9 |
19.5 |
B |
||
| Route10 |
120.4 |
12.0 |
22.5 |
17.8 |
B |
||
| Route9 |
93.1 |
8.1 |
44.5 |
18.0 |
B |
||
| Route8 |
66.7 |
6.7 |
66.5 |
20.7 |
B |
||
| Route7 |
59.0 |
8.4 |
60.2 |
44.9 |
A |
||
| Route6 |
50.9 |
10.6 |
78.9 |
63.9 |
A |
||
| Route5 |
78.9 |
16.4 |
55.9 |
48.6 |
A |
||
| Route4 |
81.2 |
16.9 |
48.2 |
42.0 |
A |
||
| Route3 |
91.8 |
15.0 |
39.2 |
33.5 |
A |
||
| Route2 |
100.7 |
12.6 |
30.6 |
26.1 |
A |
||
| Route1 |
88.7 |
10.5 |
44.5 |
29.1 |
A |
||
| Total |
4,223.4 |
571.4 |
3,060.1 |
1,783.6 |
— |
||
A comparison of results between the Iowa DOT’s existing manual system and SRAMS is presented in Table 8.
Table 8. Comparative Study Results
|
Number of Routes |
Total Plowing |
Deadhead Travel |
Total |
|||||
| Distance (miles) |
Time (min.) |
Distance (miles) |
Time (min.) |
Distance (miles) |
Time (min.) |
|||
| Iowa DOT Existing Manual System* |
Moderate intensity |
32 |
562.7 |
3,404.4 |
418.4 |
627.6 |
981.1 |
4,032.0 |
| Snow storm |
64 |
562.7 |
6,808.8 |
836.8 |
1,255.2 |
1,399.5 |
8,064.0 |
|
| SRAMS |
Moderate intensity |
30 |
571.4 |
2,111.9 |
732.4** |
1,844.3 |
1,303.8 |
3,956.2 |
| Snow storm |
53 |
571.4 |
4,223.4 |
1,212.2 |
3,060.1 |
1,783.6 |
7,283.5 |
|
* Data are taken from the Iowa DOT Manual System (Table 5) and include Priority A, B, C and D routes.
** Total deadhead miles for SRAMS solution can be calculated by taking the difference between total miles, 1,303.8 (Table 6), and total effective miles, 5,71.4 (Table 7) = 732.4 miles.
As can be seen in Table 8, for moderate-intensity snow conditions, the Iowa DOT and SRAMS use 32 and 30 routes, respectively. The plowing distance generated by SRAMS is 571.4 miles, whereas the existing Iowa DOT manual system covers 562.7 miles. The exact cause of this small difference (8.7 miles) is not known. However, after running SRAMS and looking at all road segments under Iowa DOT responsibility in Black Hawk County as identified in the existing Iowa DOT road database, it appears that 571.4 is the correct plowing distance. The most important aspect of Table 8 is the total time for plowing and deadhead travel because the cost of many resources is time dependent. For snowfall of moderate intensity, SRAMS-generated routes will require 1.9 percent less time for plowing operations compared to the existing Iowa DOT manual system (4,032 minutes vs. 3,956.2 minutes), as can be seen in Table 8. This is certainly an improvement over the existing system. Even more dramatic improvements for SRAMS are noticeable for snowstorm conditions (9.7 percent).
As mentioned elsewhere in this report, the essential problems to be considered in snow removal are the allocation of personnel resources, the distribution of materials (road salt, road sand, other ice/snow removal chemicals, the deployment of equipment, and the maximization of effectiveness in snow removal (e.g., Priority A roads are plowed quickly). SRAMS is capable of automatically generating snowplow routing based on priority, and also assigning needed resources for snow removal operations. Intermediate database files contain information on the allocation of assets and other parameters such as cost, time, and kilometers (miles) of roads to be plowed. The automatic generation of routes and the assignment of snowplows and operators can be done in less than an hour using SRAMS on mid-end Pentium PCs. In addition, SRAMS is capable of material tracking and inventory analysis.
Because of the applied nature of the project, an advisory committee was consulted throughout the development of SRAMS. To date, presentations have been given at three prestigious international conferences and one paper has been published in a peer-reviewed academic journal:
§ Salim, M., T.R. Strauss, and M. Emch. AGIS-Integrated Intelligent System for Optimization of Asset Management for Maintenance of Roads and Bridges. The Fifteenth International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, IEA/AIE 2002, Cairns, Australia, 2002, pp. 628–37.
§ Salim, M., and M.A.Timmerman. A Communication-Based Paradigm for Construction Asset Management. The Second Worldwide ECCE Symposium on Information and Communication Technology in the Practice of Building and Civil Engineering, Finland, 2001, pp. 55–60.
§ Salim, M., and M.A. Timmerman. Software to Simulate and Optimize Asset Management in Construction and Manufacturing. The Journal of Technology Studies, Vol. 27, No.2, 2001, pp. 64–101.
§ Salim, M., and M.A. Timmerman. Optimization of Construction Logistics Using AI-Based Heuristic Asset Management Tools. The Eighth East Asia-Pacific Conference on Structural Engineering and Construction, Singapore, 2001, pp. 1–6.
The project team will continue to promote technology transfer through the distribution of software and user manuals, meetings with the advisory committee and other winter maintenance personnel, and the development of an educational interactive web site. In addition, the project team will disseminate results through conferences and the academic literature.
This report describes the development of analytical tools in a transportation asset management context through knowledge engineering methods. Specifically, software (SRAMS) was developed to generate prioritized snowplowing routes in color-coded visual format and to manage the allocation of snow removal assets and resources. SRAMS was implemented on a mid-range Pentium personal computer system by integrating a commercial expert system shell (Visual Rule Studio 2.2), a GIS package (MapObjects 2.1), and a programming tool (Visual Basic 6.0). Initial studies reveal that such a system could efficiently be utilized to optimize allocation of assets for plowing snow, especially in the northern part of the United States. Although the case study presented in this report is specific to the allocation of assets/resources for snow removal operations on Iowa DOT roads in Black Hawk County, Iowa, as well as to the concerns of colder climates, the methods may also be employed to other areas of management (e.g., inventory control). SRAMS has the ability to provide on-line information on the status of inventories and to warn users when materials are depleted beyond their re-order level.
Future developments could include the following:
- enhancement of the SRAMS for handling snow removal asset/resource management problems at the county and city levels,
- use of artificial intelligence learning techniques such as genetic algorithms to allow the knowledge base to learn new rules and refine existing rules without manual assistance by the operators,
- implementation of optimization techniques based on knowledge engineering to allow for an improvement in the ratio of costs to benefits of the expert system’s generated asset management plan,
- use of predictive artificial intelligence techniques such as neural networks or fuzzy systems to allow the expert system shell to predict future conditions (e.g., meteorological changes and road conditions) based on current real-time data and stored historical data.
It is hoped that this work will be of interest to a broad audience in the civil engineering research community.
1. Barnett, D., C. Jackson, and J.A. Wentworth. Developing Expert Systems. FHWA-TS-88-022. Federal Highway Administration, U.S. Department of Transportation/Turner-Fairbank Highway Research Center, McLean, Virginia, December 1988.
2. Begur, A.V., D.M. Miller, and J.R. Weaver. An Integrated Spatial DSS for Scheduling and Routing Home-Health-Care Nurses. Interfaces, Vol. 27, July/August 1997, pp. 35–48.
3. Bowerman, R., B. Hall, and P. Calamai. A Multi-objective Optimization Approach to Urban School Bus Routing: Formulation and Solution Method. Transportation Research: Part A, Policy and Practice, Vol. 29B, March 1995, pp. 107–123.
4. Chang, N.B., H.Y. Lu, and Y.L. Wei. GIS Technology for Vehicle Routing and Scheduling in Solid Waste Collection Systems. Journal of Environmental Engineering, Vol. 123, September 1997, pp. 901–910.
5. Chang, S.K., and P.M. Schonfeld. Multiple Period Optimization of Bus Transit Systems. Transportation Research: Part B, Methodology, Vol. 25B, December 1991, pp. 453–78.
6. Chang, S.K., and P.M. Schonfeld. Optimal Dimensions of Bus Service Zones. Journal of Transportation Engineering, Vol. 119, July/August 1993, pp. 567–585.
7. Cortina, R.S., and T.A. Low. Development of New Routes for Snow and Ice Control. Public Works, Vol. 132, No. 9, August 2001, pp. 20–23.
8. Cox, K., and D. Walker. User Interface Design, 2nd ed. Prentice Hall, 1993.
9. DeLaurentiis, J. Building an Asset Management System: The NEIL RTA Experience. Presented at the Fourth National Transportation Asset Management Workshop, Madison, Wisconsin, September 23–25, 2001.
10. Dym, C.L., and R.E. Levitt. Knowledge Based System in Engineering. McGraw-Hill, New York, 1991.
11. Federal Highway Administration. Asset Management: Advancing the State of the Art into the 21st Century Through Public-Private Dialogue. FHWA-RD-97-046. Federal Highway Administration, United States Department of Transportation, Washington, D.C.,1997.
12. Federal Highway Administration. Asset Management Primer. Federal Highway Administration, United States Department of Transportation, Washington, D.C., December 1999.
13. Federal Highway Administration. FHWA Priority Technology Program: Transportation Planning GIS. FHWA-PT-96-IA(01). Federal Highway Administration, United States Department of Transportation, Washington, D.C., 1997.
14. Galitz, W.O. Essential Guide to User Interface Design. John Wiley & Sons, New York, 1997.
15. Gray-Fisher, D. M. Does Asset Management Deserve a Closer Look? Public Roads, Vol. 62, No. 6, May/June 1999, pp. 50–52.
16. Hall, R.W. The Fastest Path Through a Network with Random Time-Dependent Travel Times. Transportation Science, Vol. 20, August 1986, pp. 182–188.
17. Hayes-Roth, F., D.A. Waterman, and D.B. Lenat. Building Expert Systems. Addison-Wesley, Reading, Massachusetts, 1983.
18. Holmes, P.D., and E.R.A. Jungert. Symbolic and Geometric Connectivity Graph Methods for Route Planning in Digitized Maps. IEEE Transaction on Pattern Analysis and Machine Intelligence, Vol. 14, May 1992, pp. 549–565.
19. Hung, S.L., and J.C. Jan. Augmented IFN Learning Model. Journal of Computing in Civil Engineering, Vol. 14, No. 1, January 2000, pp. 15–23.
20. Ioannou, P, and A. Chassiakos. Modeling and Route Guidance of Trucks in Metropolitan Areas. Metrans Transportation Center, 2001.
21. Iraqi, A., R.Z. Morawski, A. Barwicz, and W.J. Bock. Distributed Data Processing for Monitoring Civil Engineering Construction. IEEE Transactions on Instrumentation and Measurement, Vol. 48, No. 3, June 1998, pp. 773–778.
22. Jia, X. Intelligis: Tool for Representing and Reasoning Spatial Knowledge. Journal of Computing in Civil Engineering, Vol. 14, No. 1, January 2000, pp. 51–60.
23. Kamler, B., and M. Beckel. A Magic Bus: Portland’s Mass-Transit System Benefits from GIS/GPS Technology. GeoWorld, Vol. 12, No. 9, September 1999, pp. 44–46.
24. Kaufman, D.E., J. Nonis, and R.L. Smith. A Mixed Integer Linear Programming Model for Dynamic Route Guidance. Transportation Research: Part B, Methodology, Vol. 32B, No. 6, August 1998, pp. 431–440.
25. Knauf, R., K.P. Jantke, A.J. Gonzalez, and I. Philippow. Fundamental Considerations of Competence Assessment for Validation. Proceedings of the Eleventh International Florida Artificial Intelligence Society Conference (FLARS-98), Sanibel Island, Florida, May 1998, pp. 457–461.
26. Ljunberg, M. Expert System for Winter Road Maintenance. Proceedings of the Ninth Maintenance Management Conference, July 16–20, 2000, pp. 167–169.
27. Loomis, R.H. Maryland County Implements Computerized Asset Management System. Public Works, Vol. 131, No. 9, August 2000, pp. 36–40.
28. Melhem, H.G., W.M.K. Roddis, S. Nagaraja, and M.R. Hess. Knowledge Acquisition and Engineering for Steel Bridge Fabrication. Journal of Computing in Civil Engineering, Vol. 10, No. 3, July 1996, pp. 248–257.
29. Nemmers, C. Transportation Asset Management. Public Roads, July/August 1997, pp. 49–52.
30. Novak, K., and J. Nimz. County Creates Transportation Infrastructure Inventory. Public Works, Vol. 129, No. 12, November 1998. pp. 34–35.
31. O’Keefe, R.M., and D.E. O’Leary. Expert System Verification and Validation: A Survey and Tutorial. Artificial Intelligence Review, Vol. 7, 1993, pp. 3–42.
32. O’Neil, W.A. Developing Optimal Transportation Analysis Zones Using GIS. ITE Journal, Vol. 61, December 1991, pp. 33–36.
33. Pattnaik, S.B., S. Mohan, and V.M. Tom. Urban Bus Transit Route Network Design Using Genetic Algorithm. Journal of Transportation Engineering, Vol. 124, No. 4, July/August 1998, pp. 368–375.
34. Powell, W.B., and Y. Sheffi. A Probabilistic Model of Bus Route Performance. Transportation Science, Vol. 17, November 1983, pp. 376–404.
35. Pressman, R.S. Software Engineering: A Practitioner’s Approach, 4th ed. McGraw-Hill, New York, 1997.
36. Ruben, R.F., and R. Jacobs. Batch Contraction Heuristics and Storage Assignment Strategies for Walk/Ride and Pick Systems. Management Science, Vol. 45, No. 4, April 1999, pp. 575–577.
37. Russell, R.S., and B.W. Taylor. Production and Operations Management. Prentice Hall, Englewood Cliffs, New Jersey, 1995.
38. Sayed, T., and A. Razavi. Comparison of Neural and Conventional Approaches to Mode Choice Analysis. Journal of Computing in Civil Engineering, Vol. 14, No. 1, January 2000, pp. 23–31.
39. Spalding, J.O. Transportation Industry Takes the Right-of-Way in Supply Chain. IIE Solutions, Vol. 30, No. 7, July 1998, pp. 24–29.
40. St. Clair, B. WisDOT’s Meta-Manager. Presented at the Fourth National Transportation Asset Management Workshop, Madison, Wisconsin, September 23–25, 2001.
41. Stevenson, W.J. Production/Operations Management, 4th ed. Richard D. Irwin, Inc., Homewood, Illinois, 1993.
42. Stiles, P.N., and I.S. Glickstein. Highly Parallelizable Route Planner Based on Cellular Automata Algorithms. IBM Journal of Research and Development, Vol. 38, March 1994, pp. 167–81.
43. Taher, S.A., and J.W. Labadie. Optimal Design of Water-Distribution Networks with GIS. Journal of Water Resources Planning and Management, Vol. 122, July/August 1996, pp. 301–311.
44. Toth, P., and D. Vigo. Heuristic Algorithms for the Handicapped Persons Transportation Problem. Transportation Science, Vol. 31, February 1997, pp. 60–71.
45. Tsai, Y.C., and J.D. Frost. Using Geographic Information System and Knowledge-Base System Technology for Real-Time Planning of Site Characterization Activities. Canadian Geo Technical Journal, Vol. 36, April 1999, pp. 300–312.
46. Van Oudheusden, D.L., S. Ranjithan, S., and K.N. Singh. The Design of Bus Route Systems: An Interactive Location-Allocation Approach. Transportation, Vol. 14, No. 3, 1987, pp. 253–270.
47. Vanier, J.D. Why Industry Needs Asset Management Tools. Journal of Computing in Civil Engineering, Vol. 15, No. 1, January 2000, p. 35.
48. Walker, D.M. Changing Times for Snow and Ice Control Practice. Public Works, Vol. 131, No. 8, July 2000, pp. 24–31.
49. Weigel, D., and B. Cao. Applying GIS and OR Techniques to Solve Sears Technician-Dispatching and Home-Delivery Problems. Interfaces, Vol. 29, January/February 1999, pp. 112–130.
50. Winter Weather Terminology: Arkansas Weather. www.srh.noaa.gov/lzk/html/win5.htm. National Weather Service. Accessed 2002.
51. Yeh, E.C., and H. Tram. Information Integration in Computerized Distribution System Planning. IEEE Transactions on Power Systems, Vol. 12, May 1997, pp. 1,008–1,013.
APPENDIX A. SRAMS User’s Manual:
Installing Software and Selecting System-Suggested Routes
Installing Software:
1. Turn the computer on, if it is not already on, and start Microsoft Windows. Close all applications that are currently open on the computer.
2. Insert the SRAMS CD-ROM into the computer CD-ROM drive. The CD-ROM automatically starts running and the startup screen appears as below. Follow the instructions on the SRAMS 1.0 Installation CD case for complete installation.
Figure A.1. Install SRAMS Window
Selecting System-Suggested Routes:
1. Run the program by double-clicking the SRAMS.EXE icon.
Figure A.2. SRAMS Main Window
2. Before starting, the creation of routes weather condition should be defined. Click System on the menu bar and select Weather Conditions (see Figure A.3).
Figure A.3. Selecting Weather Conditions
3. The Weather Conditions window will appear as in Figure A.4. After modifying the parameters, click the OK button.
Figure A.4. Weather Conditions Window
4. Click Run on the menu bar and select Route Definition (see Figure A.5).
Figure A.5. Selecting Route Definition from Run Menu
5. Select the map database file Black_Hawk_Roads.shp located in c:\data\blackhawk folder and click Open (see Figure A.6).
Figure A.6. Selecting Base Map Database File
6. Select System Suggest Routes radio button and click OK (see Figure A.7)
Figure A.7. Selecting Route Definition: Manually or Automatically
Note: A progress bar will show the remaining time (see Figure A.8).
Figure A.8. Adding Road Information Progress Bar
7. A map of the selected database file will be shown as in Figure A.9. (The system-suggested route definition includes a map of the entire Black Hawk County, Iowa.)
Figure A.9. Map of the Selected Database File
8. Click Priority A button. After clicking the button you will be prompted by two progress bars: the Selecting Information progress bar (Figure A.10) and the Creating Routes progress bar (Figure A.11), consecutively.
Note: Priority B, Priority C, Priority D, and Save Map buttons are inactive. They will be activated consecutively. For example, Priority B button will be activated after the routes for Priority A are created, and so on.
Figure A.10. Selecting Information Progress Bar
Figure A.11.Creating Routes Progress Bar
9. After segments of road are selected and allocated, a notice will indicate that all of the Priority A routes are created (see Figure A.12). Click OK to continue.
Figure A.12. "Routes for Priority A Created" Notice
10. In Figure A.13, three more layers are added to the map: DOTLAYERA, ROUTE1, and ROUTE2. The DOTLAYERA layer is all of the roads with Priority A under the responsibility of the Iowa DOT. ROUTE1 and ROUTE2 are parts of DOTLAYERA. These layers are saved in the c:\data\blackhawk folder with the name of DOTLAYERA.shp, ROUTE1.shp, and ROUTE2.shp.
Figure A.13. Map of Priority A Routes; Priority B Button Activated
11. Click on the Priority B button to create routes for Priority B. After Selecting Information and Creating Route progress bars similar to the ones in Figures A.10 and A.11, consecutively, the program will prompt the user that routes for Priority B are created (see Figure A.14). Click OK to continue.
Figure A.14. “Routes for Priority B Created” Notice
12. Repeat step 11 for Priority C (Figures A.15 and A.16). Click OK to continue.
Figure A.15. Selecting Activated Priority C Button
Figure A.16. “Routes for Priority C Created” Notice
13. Repeat step 11 for Priority D (Figures A.17 and A.18). Click OK to continue.
Figure A.17. Selecting Activated Priority D Button
Figure A.18. “Routes for Priority D Created” Notice
14. Click Save Map button (Figure A.19) to save all of the routes on your hard drive. Names of the shapefiles will be as follows:
Route layers—ROUTE1.SHP, ROUTE2.SHP, …
Priority layers—DOTLAYERA.SHP, DOTLAYERB.SHP, DOTLAYERC.SHP, DOTALYERD.SHP.
Figure A.19. Selecting Save Map Button
to Save the Layers Created
15. If the files were created before in another run of SRAMS, you will be asked to overwrite (see Figures A.20 and A.21). Click Yes to continue in each case.
Figure A.20. Warning for Map Already Exists
Figure A.21. Warning for Routes Already Exist
16. Click OK to continue (Figure A.22).
Figure A.22. Map Saved Window
17. Click Close button to close system-suggested routes session (see Figure A.23).
Figure A.23. Click Close Button to Exit
APPENDIX B. SRAMS User’s Manual:
Starting SRAMS:
- To run the program, double click on SMARS.EXE icon. The window depicted in Figure B.1 should appear. If this window does not appear check the path from the shortcut icon to the executable file and verify that your Windows operating system is working properly. After a brief time, this window will disappear.
Figure B.1. Welcome Window of SRAMS
- Figure B.2 depicts the main user interface window for the program.
Figure B.2. SRAMS Main Window
- Click Run on the menu bar and select Route Definition to load the road map to the system.
Figure B.3. Selecting Route Definition from Run Menu to Load the Desired Map File
- The directory window in Figure B.4 will appear for the user to select the map shapefile to be opened.
This interface screen uses the usual Windows directory structure to allow the selection of the desired shapefile. In this example, the shapefile Black_Hawk_Roads.shp file is located at c:\data\blackhawkroads (Figure B.5).
Figure B.4. Directory Window for User to Select Base Map Shapefile
- The shapefile is selected by a single-click and use of the Open button or by double-clicking on the file icon (see Figure B.6).
Figure B.6. Selecting Base Map Shapefile
- Two options will be presented as shown in Figure B.7: “Select Routes Manually,” where the user defines routes manually, and “System Suggested Routes,” where the routes are suggested by the software system. Select one of the options and click the OK button to continue. In this example, we will pick Select Routes Manually.
Figure B.7. Select Route Definition: Manually or Automatically
Note: A progress bar will appear showing the remaining time for the task to execute as depicted in Figure B.8.
Figure B.8. Adding Road Information Progress Bar
- Figure B.9 is the route definition map of the selected shapefile. You may use tools to pick road segments manually.
Figure B.9. Route Definition Map
The Toolbar has four tools:
Zoom in (
): Lets you to zoom in any part of the map by selecting a rectangular
area. To select the area click on any point of the map to determine the
upper left corner of the selection area and without releasing the button
drag the mouse to the lower right corner of selection area, then release
the mouse button.
Pan (
): Lets you to move the desired portion of the map by clicking and dragging
the map. Pan works only after you zoom in.
Select (
): Lets you to select the road segment.
Zoom Full Extent (
): Displays entire road map in the window again.
Shape List in this example has only one shapefile—namely, Black_hawk_Roads.shp. This file contains all roads for Black Hawk County, Iowa. When more routes are added, the routes are listed as Route1.shp, Route2.shp, and so forth.
Records on Map is a textbox that has number of records in the map. Each record represents a segment of a road. Each segment of a road is identified as MSLINK (or PLINK). In this example, we have 6,839 records.
Creating a Route:
- To create a route, click on the Start a Route button. A new shapefile will be added to the Shapefile List with the name ROUTE1. You will have to activate the Select button that will also change the cursor to let you know that this feature is in use. Now you can simply click on any of the road segments. That selected segment will flash on the map and also the corresponding plink, number of the road, and the name of the road will be illustrated in three textboxes labeled as “Plink:”, “Road:”, and “Name:”, respectively. If the selected segment is the road segment that you want to add to the route definition, then click on the Add Segment button. If not, you can go ahead and select another segment. All of the segments added to the route will be listed in the Route List. Once you finish the route definition, and then click on the End a Route button.
Example:
- Zoom in on the University Avenue neighborhood as shown in Figure B.10.
- Activate the Select button.
- Click on the segment shown in Figure B.10.
Notice that related information is listed as follows:
Route: 1
Plink: 15763
Name: UNIVERSITY AVE
Notice also that the name of the segment will pop-up when you bring the mouse on the segment even before you click.
Figure B.10. Example: Selecting a Segment of the Road
d. Since this is the segment we want to add, click on the Add Segment button.
e. Note that plink (15763) is added to the list of Route1, and the corresponding segment of the road now has different color.
f. You can select as many segments as you like. Whenever you are finished with the route, you have to press the End a Route button.
Figure B.11. Example: Ending the Route
g. The Route End dialog box will appear. You may press the OK button to end the route selection session. Note that all of the plinks selected for Route1 are the same color.
Loading a Route:
9. To load a route, click on Load Route button. The Open Shapefile Window will appear (Figure B.12). Select Route1.shp from the list and click the Open button. Route1 will be loaded and plinks belonging to Route1 will be listed. The Loaded Route Window as in Figure B.13 will appear.
Figure B.12. Opening Shapefile to Load a Route
Figure B.13. Loaded Route Window
Erasing a Plink from a Route:
10. If it is desired to remove one or more plinks from a route, select a plink from the list of routes and press the Erase Segment button. For this example, let’s select plink number 15081 from the list. You will be asked whether you are sure you want to remove the plink. Press Yes to remove it. The plink number will be erased from the Route1 list, and the corresponding road segment will resume its original color on the map.
Figure B.14. Are You Sure You Want to Delete the Selected Plink from the List?
Figure B.15. View of the Map after Plink 15081 Is Erased from the Route
Adding Another Route to the Map:
11. To add a route to an existing map, click the Start a Route button and follow the same procedure as previously described for adding a route.
Figure B.16. Window After Adding Second Route
12. If you want to more information on this software, please refer to General Help from Help menu.
1. If the program is not already running, run the program by double-clicking the SRAMS.EXE icon. The SRAMS user interface will appear on the screen as depicted in Figure C.1.
Figure C.1. SRAMS Main Window
2. Click the System button on the menu bar and select Inventory Analysis (Figure C.2).
Figure C.2. Select Inventory Analysis
3. Locate the Material.dbf file (see Figure C.3) on your hard disk. If you don’t have this file, SRAMS can create an empty Material.dbf for you.
Figure C.3. Locate Material.dbf file
4. The main window for Inventory Analysis will appear as shown in Figure C.4. There are three main sections that are used to list and manipulate the inventory items. The first section is the window that is used to list all of the materials available in Material.dbf. The second section is Selected Item textbox that depicts the material selected for inventory analysis. The third section is the list of available models for inventory analysis of materials.
Model 1: Items arrive simultaneously and no stock out.
Model 2: Items arrive at rate item/time, and no stock out.
Model 3: Items arrive simultaneously and stock out is allowed.
Model 4: Items arrive at rate item/time, and stock out is allowed.
Figure C.4. Inventory Analysis Main Window
5. Close the Inventory Analysis window by clicking Close button.
Adding New Materials:
6. To add new materials, open the Materials Form by clicking Materials from the Edit menu. (see Figure C.5)
Figure C.5. Selecting Materials from the Edit Menu
- There are seven main fields in the Materials Form window.
Description: A string with maximum length of 25 characters.
Unitary Cost: A number.
Reorder Point: A number.
Unit: A string (ton, lb, and liter are supported).
Quantity: A number (such as 0, 1, 5, 100, 2100, …).
Figure C.6. Materials Form Window
- The other fields are the parameters that should be entered in case of that specific model will be used in analyzing.
9. To add a new material, click the Add button. The buttons at bottom of the window will be replaced with Update and Cancel buttons.
10. Figure C.7 depicts an example of adding data to the material database. When the data are satisfactory, click the Update button. The previous group of buttons will appear again. This way you can add as many items as you prefer by repeating step 9. (see Figure C.8)
Figure C.7. Adding Material2 and Related Information to Window
Figure C.8. Adding Sand to Material.dbf
11. Click the Close button.
Inventory Analysis:
12. Open Inventory Analysis window by repeating the steps from 2 to 4. Added materials Salt and Sand will be listed (see Figure C.9).
Figure C.9. Inventory Analysis Window after Salt and Sand Are Added
13. Click on Salt from the list and it will be depicted in the Selected Item window. Then click the Analyze button (see Figure C.10).
Figure C.10. Selecting Salt for Analysis
14. The following error will prompt up warning that you did not enter necessary parameters for Model 1.
Figure C.11. Missing Parameters Warning
- Follow the steps explained in the next section to modify Inventory Demand, Set Up Cost, Inventory Cost, Working Days per Year, and Lead Time for Model 1. The Find Optimum Reorder Point window will appear (Figure C.12).
Figure C.12. Find Optimum Reorder Point Window
16. Click Find Optimum button. Economic Order Quantity, Economic Reordering Period, Average Stock, and Reordering Point will be calculated as depicted in Figure C.13.
Figure C.13. Inventory Optimal Results (Optimum Reorder Points Are Found)
Modifying Existing Materials:
17. Repeat step 6 to open Material window.
18. To modify the given values for any material, scroll until you find the Material to be modified by using left and right arrow buttons at the bottom of the window. Then click on the Edit button (see Figure C.14).
Figure C.14. Window to Select Material to be Modified
19. The Material window will be converted to edit mode (see Figure C.15). Modify Quantity for Sand from 2,000 to 30,000. Click Update button.
Figure C.15. Window to Modify Materials
20. To remove material from the list, scroll until you find the material to be modified by using left and right arrow buttons, and then click on the Delete button (see Figure C.16).
