Software Requirements Specification for the Inventory Management and Work Order System December 23, 2002

Prepared by

Table of Contents
1Introduction..................................................................................................................................3 2Graphical User Interface...............................................................................................................4 3Remote User Interface..................................................................................................................5 4GIS Functionality..........................................................................................................................6 5Element.........................................................................................................................................6 6Work Order...................................................................................................................................7 7User..............................................................................................................................................9 8Group............................................................................................................................................9 9On-Call Schedule........................................................................................................................10 10Location....................................................................................................................................10 11Customer...................................................................................................................................11 12Preventive Maintenance Schedule............................................................................................11 13Reports......................................................................................................................................12 14Maintenance Cost Tracking......................................................................................................13 15Appendix A Preliminary List of Subsystem Types and Devices............................................14

Introduction

The Traffic Operations Center seeks a system to aid in effectively and efficiently managing the numerous devices, equipment, and infrastructure for which the TOC is responsible. The TOC currently uses a simple work order database, which holds work orders, but lacks some of the power and flexibility of established commercially available systems. The Inventory and Work Order System has two main functions, which are to: 1. Track inventories and work histories 2. Manage work orders and device failures The past three years of maintaining the ATMS system has taught us several lessons. This experience will help us to identify a system that will accommodate a greater number of needs in our efforts to efficiently manage and maintain these increasingly important systems and services. Several of these lessons are outlined below: Growing System The system we manage and our responsibilities are constantly growing. Since the creation of the Access Work Order Database, its use has greatly expanded beyond its original scope. More than 16,000 work orders have been created for anything from signal repairs to damaged roadway signs to computer errors. From this, we learn that a system we select must be flexible enough to accommodate changes in procedures and structure, and should have the capacity to manage large tables and amounts of data. The asset management system should provide features that record and maintain the information that is determined most critical to a management system. It should also have the ability to customize the system to track additional information as the system expands or priorities change in the future. Failures by Location Frequently, requests are made to see work order histories for specific locations. In the current system, extracting this from work orders is difficult. The work order system should provide the ability to track failures, or work performed by unit type or location with ease. It should be sufficiently flexible to identify locations by either a point (such as an intersection), or a range (such as a stretch of road). To enhance the ability of the system with location type functionality, the new system should have the ability to link to a GIS. This may increase its utility for the operators in locating devices, the management supervisors in planning maintenance activities, and management in using the powerful GIS analysis tools. Failures by Device One feature that we have found a need for is the ability to track the history of a device. The current system cannot provide this. This would provide valuable information on problem devices, and will provide valuable information on the performance of specific devices. Work Order Process Under the current process, the TOC Operators generally create the work orders based on requests or information from many sources, including the public. They print the work orders, and deliver them to the appropriate responsible groups. The group supervisors assign the individual work orders to individuals in their groups, who complete the work orders on paper and return them to the supervisors. The supervisors then return them to the TOC Operators, who transcribe the information from the completed forms into the work order database. Although this process has 3

worked fairly well, it allows many opportunities for errors in the passing on and transcription of information. A system that allows complete electronic assignment of work orders from operators to supervisors to individuals will help to eliminate these holes. Ease of Use One lesson that we have also learned is that for a system to be effective, all users of the system must consistently use it. Although this may sound simple, we have found that if a system is difficult to use and does not provide a direct and visible benefit, some individuals may not use it, or at least will not use it to its maximum effectiveness. Therefore, it is important that the system be intuitive, simple to use, and provide some benefit to all users. The purpose of this document is to provide users and decision makers with a description of needs and requirements. Once these needs are agreed upon, they can also be provided to the vendors of qualifying systems, and will help in deciding on the best system to suit the needs of the TOC. The remainder of the document outlines a general description of the desired functional components of the Inventory Management and Work Order system. Some general field types are used to describe attributes and functions, but specific attributes are called out where emphasized. Exhibit 1 shows a general layout of a suggested system database structure. Each of the tables and terms are described in more detail in each corresponding object description section of the document.

Element

Location

Subsystem

Preventive Maintenance Schedule

Work Order

User

Agency

Customer

Group

On-Call Schedule

Exhibit 1. Inventory Management and Work Order System General Database Structure

Graphical User Interface

Although user friendly is not easy to define, there are some general guidelines that will be helpful. The end result for the system interface should be that an individual performing maintenance at a location or on a device can quickly update the work order with results or comments while in the field, an operator can quickly create a work order with all required information, and that supervisors and managers can quickly and easily extract, summarize, and report data in many different ways. The user interface should provide the following functionality: 2.1 2.2 Provide simple navigational tools on all forms, with links to other data entry items. Use combination and list boxes generously.

2.3 2.4 2.5

Provide type-ahead functionality on list and combination boxes. Provide search capabilities on appropriate lists. Maintain a balance between the number of windows and the amount of information contained on each window. This will reduce the difficulty of navigation and the amount of information that is required for viewing on a single screen. Have the ability for an administrator to add or eliminate fields, organize the arrangement or tab order on data entry forms. Dynamic forms shall be generated where applicable. An example of this is in the Element object, where each element type can be customized with unique attributes and unique links.

2.6 2.7

Remote User Interface

The system shall provide a simplified user interface for remote users. This interface shall support two modes of operation: Mobile Wireless, and Autonomous Operation, which are described below: 3.1 Mobile Wireless In this mode of operation, a user may have a wireless modem attached to a laptop, giving them a live connection to the UDOT network and access to this system. When calls are received at the TOC, requests should be automatically geo-coded and assigned to the appropriate field personnel for investigation. In the field, truck mounted computers or PDAs should periodically poll the request database, via wireless modem, for new requests. Requests should then be downloaded and investigated, and results will be automatically transmitted back to the server at the TOC. Autonomous Operation In this mode of operation, a user will not have a direct link to the database while in the field. A technician may download their work orders for the day before they go into the field, update them while there, and upload the updated work orders to the central database when they return to the office. 3.2.1 The remote interface must search the TOC database for work orders assigned to a given supervisor. The work orders and associated asset information is then downloaded to the field laptop. When the laptop is returned from the field, it uploads all work order information, including completed and partially completed work orders. Any new work orders are then downloaded to the laptop. Field Technicians should enter data directly in the filed, eliminating double entry problems where field personnel write information down onto paper forms, then re-enter the data into the database back at the TOC. For longer-term work orders, interim status data such as resource use, comments, tasks, etc can be updated for others to use.

3.2

3.2.2

GIS Functionality
4.1 The system shall provide a link to a GIS A GIS will display asset symbols on a map with links to their corresponding database records. This GIS will provide the ability to analyze data based on geographic information, allowing patterns to emerge on a map that may not be as obvious in rows and columns of data. The GIS shall be used to aid users to view element locations graphically, and shall provide GIS tools that will aid in reporting and analysis. Communication Asset information can be shared in a visual format that is often better understood by others including managers and field technicians. Asset Location Finding asset location is often faster and easier with the help of a map. A GIS will link database records directly to images on the map. This can be beneficial if, for example, the approach to a bridge is being widened and all traffic signs need to be temporarily removed and replaced in the proper location. Graphically selecting the assets in question from the maps will automatically display the corresponding records in the asset management system.

4.2 4.3

Element

The Element should be at the heart of the inventory tracking system. An element can be any item that is tracked, such as electronic equipment, hardware signs, or other inventory items. An element is generally associated with a location, but will have its own history. Work orders that are created for a location can also be associated with an element. For example, if a work order is called in for a flashing intersection, the technician may associate that work order with the faulty controller that caused the intersection to flash. This way, although the technician may replace the faulty controller, the failure information will be associated with the intersection for future inquiries, and with the device for its history. A preliminary list of Elements and Subsystems is provided in Appendix A. 5.1 Attributes As a minimum, the Element shall be provided the following attributes or attribute categories: 5.1.1 Equipment Identification Attributes: The system shall have the ability to link specified identification attributes into other tables. Examples of these include manufacturers, vendors, makes, and models, as the user defines. Parent Element Linked to another element. Element Type the system shall provide the ability to classify or categorize each element by an element type or subsystem. For example, a cabinet may be of type Ramp Meter, or CCTV, etc.

5.1.1.1

5.1.1.2 5.1.1.3

5.1.2

Location linked to the location table.

5.1.3

Unique Attributes Each element type shall not only have all attributes outlined in this section, but will also be configurable with additional attributes unique to that device type. Unique Links Similar to Unique Attributes, the element of each element type shall be provided with the ability to configure additional definable Unique Links to other objects. Responsible Agency and Group aids in reporting and provides links to the on-call technicians. Bar-Code Scanner The system shall have the ability to utilize a bar-code scanner system. Once a bar code has been scanned, the system should automatically display the corresponding record from the database. Digital Photos Digital cameras are now being used for inventory and inspection records. Inspectors use digital images to visually record condition, damage and deterioration of assets like bridges, roads, etc. In addition to providing a text record, a picture of a sign and its surrounding can be attached to the record can be a guard against liability claims.

5.1.4

5.1.5 5.1.6

5.1.7

Work Order
A work order is the method of providing the history of work by location, element, group, date, or other parameters. It provides a means to record maintenance or inquiry requests, activities, problems, and problem resolution. The system shall provide tools to create, assign, and update work orders. 6.1 Work Order Process: 6.1.1 Work Order Creation: The system shall provide a Call Taking interface for work order creation initiated by a call from the public. The Call Taking Function will provide the operator with a question list, which will remind an operator of the detailed questions to ask a member of the public when taking information. The Call Taking Function shall integrate the geo-coding and map display capabilities. This will help determine the callers location and proximity to infrastructure features and other open work orders nearby, other enterprise-wide GIS data and service requests can be displayed. This should allow a user to assign multiple callers to an open service request, and will help to eliminate duplicate requests for the same issue. Log caller information.

6.1.1.1

6.1.1.1.1

6.1.1.1.2

6.1.1.1.3

6.1.1.1.4 6.1.1.1.5 6.1.1.1.6 6.1.1.1.7 6.1.1.1.8 6.1.1.1.9 6.1.1.2

Enter problem information. Automatically locate the problem address on a map display. Open requests can be viewed in a list and a map display. New calls can be attached to existing open requests. Requests can be searched using information such as Request ID, Caller information. Request ID, caller information, Dates and Time, Status, and Personnel.

The system shall also provide a simple work order creation screen, intended to allow any user to create a work order without going through the Call Taking Interface questions. The system shall provide an interface to allow other applications to automatically create a work order based on a failure detected by that system.

6.1.1.3

6.1.2

Work Order Assignment Once a work order has been assigned to a group, the group supervisor shall be provided with an interface to assign it to an individual technician, or to re-assign the work order to another group. The system shall provide a simple method for grouping related work orders. For example, if individual problems arise periodically, and are saved until a specific time when a crew will address all of them at once, there should be simple method to combine these work orders into individual tasks on the same work order. An example of when this would be useful is in the case of detector failures. As these are discovered, they are entered into the work order database. Crews are dispatched periodically to repair a number of detectors at once. We should have the ability to give them a simple list of locations, without giving them a stack of individual work orders.

6.1.2.1

6.1.2.2

6.1.3

Work Order Modification Users shall be provided with the ability to modify work orders from workstations or remotely, as described in Section 3.

6.1.3.1 6.2

Work Orders shall be provided with the following attributes or attribute categories. 6.2.1 Initiation Attributes including creation information, user information, and customer information, work order type.

6.2.2 6.2.3

Problem Description Attributes including location, and a verbal description of the problem. Work Order Numbering The Asset Management software should automatically assign a unique work order number for all types of work orders. Legacy work order numbers should be retained by putting the data in a custom field of the work order. Work orders, including numbers, are not deleted from the system when a work order is cancelled. Problem Tracking Attributes including status, assignments, action taken, and assignment and repair dates. Additional Associations these additional fields will allow a work order to be associated to several elements or locations.

6.2.4 6.2.5

User

The system shall be provided with functionality to identify work orders, updates, assignments, and all other system functions by user. 7.1 Each user will have the following attributes: 7.1.1 7.1.2 7.1.3 7.1.4 User Identification fields to identify this unique user. Contact Information. Assignment Information these fields will identify which group and agency this individual is assigned to, or what role they play. User Rights this set of allowable actions attributes will allow a userdefinable set of rights for each individual user, by user type, by location, or by agency. Rights shall include view, read, modify, and delete. User Status Active The user is currently active in the system. Retired The user is no longer active in the system. These will be retained in the user list, however, to maintain the integrity of the database.

7.1.5

7.1.5.1 7.1.5.2

Group

The group shall be used for maintenance groups, operators, dispatchers, or management and administrative groups. Group assignments will be used to assign work orders, to determine oncall schedules, and to filter reports. 8.1 The Group object shall have the following attributes: 8.1.1 8.1.2 Group Name. Associated Agency from a table of Agencies. 9

8.1.3

Supervisor Linked to a User.

On-Call Schedule
The system should have a method for keeping on-call schedules. This will allow an operator to quickly contact the on-call individual in the event of a failure requiring immediate attention during non-working hours, by identifying the location or device. 9.1 The on-call schedule will provide the following functions: 9.1.1 9.1.2 On-Call Technician (from the User table). Group a group on-call technician may override the agency on-call technician. This will allow larger agencies (like UDOT) to have a technician for a specific area or device type. Reporting and Data Entry The on-call module will be provided with a unique reporting and data entry screen, which will allow a user to view the schedule based on agency, group, day, week, or month. The user should be allowed to both edit and print the schedule from this screen based on this criteria.

9.1.3

10 Location
The GIS component of the system shall help ensure consistency in reporting information by location. The Location module should have the following characteristics. 10.1 10.2 10.3 10.4 10.5 Elements may be located in field locations, warehouses, lab, individual offices, vehicles, or users (non-stationary location). The location object contains several attributes, but not all are required fields. Where elements are placed linearly (such as from and to on a highway), two locations must be selected to describe it correctly. The location shall support GIS location requirements. The location shall support street name, address fields, coordinate fields, state route numbers, and mileposts. UDOT has done extensive work to correlate these various naming conventions. The system shall be able to incorporate and stay coordinated with UDOTs location databases. The location shall support highway names and reference posts numbers. Global Positioning System (GPS) receivers During the initial collection of asset location, the system should have the capability to use GPS receivers to gather accurate coordinate location data and to collect other attribute information. A GPS receiver provides information for projecting the asset location onto a GIS base map.

10.6 10.7

10

11 Customer
Keeping a database of customers and their contact information provides there are several convenience benefits to keeping a customer database, including fast retrieval of customer information for repeat calls, as well as other customer satisfaction calls. In addition, the system should: 11.1 Provide retrievable customer information from the work order creation form. In this way, a user does not have to provide all of their information each time they call. Permit a user to view all work orders called in by that a customer once that customer has been identified. Once a customer has been identified. In this way, a customer who has called in multiple times on the same work order can quickly be given the status of the work order. A user should be able to add an additional note that the caller has checked on the work without creating a duplicate work order.

11.2

12 Preventive Maintenance Schedule

The preventive maintenance portion of the system will automatically generate work orders based on a user defined maintenance schedule. The Asset Management system should allow both scheduled and cyclical work orders to be created and managed. The labor, material and equipment tracks both estimated and actual costs. The software should use projected start and finish dates to schedule a work order. 12.1 12.2 An interface to input Preventive Maintenance Schedule parameters will be provided. A user shall have the ability to schedule maintenance by: 12.2.1 Recurring date every December the 15th. 12.2.2 Periodic time frame i.e. every 3 months. 12.2.3 Conditional time frame i.e. 4 months after the most recent maintenance was completed. 12.3 Preventive maintenance schedules shall be able to be defined for one or more of the following categories: 12.3.1 Element Type. 12.3.2 Location. 12.3.3 Area. 12.3.4 Individual Element. 12.4 Each of the categories listed in section 12.3 shall be hierarchical. The schedule for an individual element shall take priority over a schedule for the element type. 11

12.5

If a schedule applies to a category (section 12.3) of both higher and low priority, a user may specify that one or all category schedules apply to the category of higher priority. The resulting functionality will allow a Preventive Maintenance Work Order to be generated by any of the defined schedules. A method to view work orders that will be generated by the Preventive Maintenance Schedule shall be provided. 12.6.1 The schedule shall have the following characteristics: 12.6.1.1 The ability to be filtered by: Date Range. Group. Preventive Maintenance Category. Element Type. Location. Element.

12.6

12.6.1.1.1 12.6.1.1.2 12.6.1.1.3 12.6.1.1.4 12.6.1.1.5 12.6.1.1.6 12.6.1.2 12.6.1.3

A function to print the schedule. A distinction showing which Preventive Maintenance Category Schedule from which the work order was generated.

13 Reports
13.1 The system shall provide a means to query and report data. 13.1.1 The user shall have the ability to define standard reports and allow the user to input query parameters. (i.e. a report where the user inputs the begin and end dates). 13.1.2 The system shall allow tables to be exported to a common text file type, such as comma delimited. In this way, a user can import these tables into another application for other user-defined or proprietary reports as needed. 13.1.3 Maintenance History The software should maintain an integrated database of maintenance history. The Asset Management software should be feature based, meaning that work orders are associated with a feature or associated device in the GIS. A large degree of flexibility in searching work orders is required, so a user can search for any combination of features or related devices a user has identified. These searches should also have the ability to incorporate any set of database attributes. For example, a user needs to identify all traffic signals in a specific UDOT region. The GIS tools can identify all signals that fall within the region of interest. The software work order search tool should be used to further

12

refine the search by selecting only those signals that had a flash work order performed in a given date range. Search results can be highlighted on the map and listed in tabular format. Tabular result listings can contain any number of database items such as ids, dates of work, key personnel, and so forth. Similar searches can be performed for preventive, construction, and unscheduled maintenance. In addition to the search engine, the inventory of any given feature or device will list all past, present, and scheduled work for that feature. Any given work order in the list can be viewed.

14 Maintenance Cost Tracking

Tracking maintenance costs is an important component of the Department of Transportation. Therefore, the system shall provide time and cost tracking functionality. This will allow supervisors and managers to analyze current practices and to track and manage the costs of specific types of maintenance. The tracking shall include cost information for equipment, parts and materials, and personnel.

13

15 Appendix A Preliminary List of Subsystem Types and Devices

*Subsystem Types Ramp Meter Traffic Monitoring Station Closed Circuit Television Variable Message Sign Weight-in-Motion Road-Weather Information System Traffic Signal Highway Advisory Radio Communications Hub Communications Network? **Device Types Controller Conflict Monitor (MMU or CMU) Bus Interface Unit (BIU) Pre-emption Unit Trailblazer VMS Variable Message Sign Fiber Modem Other Modem ADPRO CCTV Unit PTZ Unit Cabinet WIM device Pavement Sensor Temperature/Relative Humidity Gauge Anemometer Precipitation Sensor HAR Flashing Sign Solar Panel HAR Transmitter Hub Communications Equipment

14