Background Most transportation systems have many assets that must be maintained and managed to ensure the proper and safe operation of the system. For example, roadway systems typically include numerous traffic signs, traffic signals, street signs, road lights, pavement, pavement markings, culverts, bridges, etc. Railway systems typically include rails, switches, crossing signs, crossing lights, etc. Waterways systems typically including navigation buoys, navigation lights, locks, etc. Airport systems typically include signs, runway lights, pavement markings on the runway, pavement markings on the tarmac, etc.

Managing these assets has proven to be difficult at best.

A first step in managing the assets of a transportation system is to document the assets of the system, or more generally, create an inventory of the assets of the system.

Without such an inventory, the assets of the transportation system cannot reasonably be managed. To aid in the creation of an inventory of the assets, a number of software programs have been developed. One such program is available from CarteGraph Systems, Inc., located in Dubuque, Iowa. CarteGraph provides several software modules, each directed toward documenting a particular type of asset. One module, having the trade designation"SIGNview,"helps create and maintain an accurate, up-to-date traffic sign management inventory."SIGNview"is equipped with an on-line Federal MUTCD (Manual of Uniform Traffic Control Devices) library, which contains predefined data for all standard sign types. By selecting a sign from the library,"SIGNview automatically records

selected attributes of the sign in the inventory database."SIGNview also allows asset managers to perform simple database queries to select and/or identify various assets within the inventory database.

Another module available from CarteGraph Systems, Inc. has the trade designation "PAVEMENTview."PAVEMENTview helps create and maintain an accurate and up-to- date pavement inventory. An addition module under the trade designation "PAVEMENTview Plus"provides an interface that allows asset managers to create a number of Capital Improvement Planning (CIP) scenarios. For each scenario, multiple "what ifs"can be provided to test the impact of various factors on multi-year, system-wide performance and maintenance decisions. Other modules include those under the trade designation"LIGHTview for inventorying roadway lights,"MARKINGview for inventorying pavement markings,"SIGNALview"for inventorying signal lights, "SEWERview for inventorying storm sewer and sanitary sewer assets, and"WATERview for inventorying water system assets.

While these software packages help in creating inventories, they do not appear to help prioritize or provide efficient inspection and maintenance schedules. Rather, it appears that the inspection and maintenance schedules must be defined globally for all assets in a class. For example, the asset manager may define an inspection schedule for all traffic signs with a 15-year warranty. The inspection schedule may include, for example, an inspection at year 13 and every year thereafter until the sign is deemed to be unacceptable.

Accordingly, a similar inspection schedule must typically be applied to all signs having a similar warranty period, even though the actual lifetime of each sign may be different.

Another limitation of many inventory software programs is that they do little to reduce or remove the workload of the governing authority that is responsible for maintaining the transportation system. It has been found that many highway departments, for example, do not have adequate resources to maintain a rigorous inspection schedule, let alone perform routine maintenance on the assets. Often, highway departments only have sufficient resources to perform the most basic tasks, such as replacing knocked down signs and installing new signs.

Cross-Reference to Related Co-Pending Applications This application is related to co-pending U. S. Patent Application Serial No.

60/155,713, which is incorporated herein by reference.

Summary The present invention provides an efficient method and system for managing assets of a system (e. g. transportation system, factory or industrial system, distribution system, building system, infrastructure system, military system, etc). Included in the present invention is an overall business method for managing the assets of the system. This overall business method streamlines the inspection, maintenance, procurement, and/or installation tasks now performed by the appropriate governing authority. Also included are various methods for automating some of the asset management functions such as creating an inventory of assets, predicting when the assets will fall below a predetermined performance threshold, providing accurate budget estimates, providing automated electronic bid requests, providing electronic work orders, etc. These methods may significantly improve the efficiency of the asset management function.

The present invention is preferably implemented, at least in part, using one or more data processing systems. The data processing systems may be connected via a network, such as a LAN or the World Wide Web (a. k. a."internet"). The inventory of assets is preferably electronically stored on one of the data processing system, and accessed by another data processing system through the network. A software program preferably resides on the same data processing system that stores the inventory of assets.

The software program may include several modules for performing various tasks of the asset management system. A first module is a modeling module. The modeling module preferably models the degradation in performance of selected assets versus time using one or more environmental conditions or parameters, which may include one or more environmental wear conditions. By including the environmental conditions or parameters, the present invention may more accurately identify those assets that are predicted to fall below a predetermined performance threshold at a given point in time.

This may increase the accuracy of any budget estimates created from the inventory of assets, and may optimize the inspection and maintenance schedules.

The modeling module may also include an asset upgrade optimization function.

The asset upgrade optimization function may help a governing authority prioritize asset replacement, preferably by using a number of predetermined factors. For traffic signs of a transportation system, these factors may include, for example, sign type, speed limit, retro- reflectivity, sign obstructions, condition and/or performance of the sign, etc. A weighting may be applied to each of these factors, and a priority level may be determined for each asset by summing the weighted factors. The priority level may be used by the governing authority to determine which assets should be replaced first.

To streamline the inspection, maintenance, procurement, and/or installation tasks now performed by the governing authority, the present invention contemplates providing a number of methods or modules for soliciting bids and providing work orders. In one embodiment, the governing authority preferably initiates a transaction by submitting a bid request to a bid module. The bid module may create and distribute an electronic bid request to approved vendors. The bid requests preferably include the information required by a vendor to prepare a bid. For example, if the bid request is for a replacement asset, the electronic bid request may include the manufacturing specifications for the replacement asset. After the bid request is distributed, the bid module may receive electronic bids from the vendors. Once one or more of the bids are accepted, a work order module may create a work order authorizing one or more of the vendors to inspect, maintain, manufacture or install the assets. Because the vendors are performing the inspection, maintenance, manufacture and installation of the assets, the resource load on the governing authority may be significantly reduced.

It is also contemplated that the present invention may provide upgrade suggestions for selected assets. For example, if a traffic sign of a transportation system is facing the sun, the present invention may suggest providing an UV protective film over the sign to extend the life of the sign. Likewise, if a traffic sign is being replaced because vandals painted the sign, the system may suggest using a protective film that allows paint to be readily removed. Similarly, if a particular traffic sign has been knocked down several times, the system may suggest moving the sign to another location. For custom designed

signs, and as more fully described below, the system may also suggest font size, font spacing, font color, background color, retro-reflectivity of the reflective sheeting, and other design considerations based on the expected use of the sign.

To help improve the safety of a transportation system, it is contemplated that an accident analysis module may also be provided. The accident analysis module may read an accident database that includes, for example, accident information including the location of accidents on the transportation system. The accident analysis module may identify those assets that may need to be upgraded and/or replaced, and may make suggestions for improving the allocation or placement of assets to help reduce the number of accidents on the transportation system.

A regulatory compliance module may also be provided for checking the compliance of a roadway with predetermined roadway requirements. The Manual of Uniform Traffic Control Devices (MUTCD) provides many of the roadway requirements.

Since the inventory of assets preferably includes a description of the roadway, including the type and location of each of the assets, the regulatory compliance module may compare the roadway requirements (e. g., MUTCD) with the type and location of the assets in the inventory. Any discrepancies may then be reported to the governing authority. Preferably, the regulatory compliance module may also provide suggestions on how to modify the inventory of assets to remove the reported discrepancies. This may include upgrading an asset, moving an asset, providing additional assets, etc.

In some instances, it may be desirable to allow a user to design a custom sign. For example, a municipality may want to design a sign that indicates that the driver is entering or leaving the city limits. To accommodate such a situation, the present invention may provide a graphical user interface that provides a number of questions regarding the use of the custom sign. After the user provides answers to the questions, the present invention may provide a proposed sign design. The user may then accept, modify or reject the proposed sign design. A similar method is disclosed in co-pending U. S. Patent Application Serial No. 60/155,713, which is incorporated herein by reference.

If the user accepts the proposed sign design, the present invention may create a work order for the proposed sign design, and forward the work order to a vendor to

manufacture the sign. If the user modifies the proposed sign design, the modified sign design may be analyzed, and suggestions may be provided for improving the sign design.

It is also contemplated that a user may initially provide a proposed sign design.

The present invention may then include a module that evaluates the proposed sign design and provides a number of suggestions for improving the proposed sign design. The user may then be allowed to accept or reject the suggestions.

It is known that creating an inventory of assets for a transportation system can require significant time and resources. For traffic signage, some of the most difficult data to collect is the reflectivity, color and location of the sign. To help collect this information, the present invention contemplates providing a sensor device (e. g. a hand held sensor device) that includes both a colorimeter for measuring the color of the sign and a reflectometer for measuring the reflectivity of the sign. Preferably, both the color and reflectivity can be measured from a location that is remote from the sign.

To determine the location of the sign, the sensor may include a GPS detector, a distance detector, a direction detector and a processor. The GPS detector preferably detects the GPS coordinates of the sensor. The distance detector detects the distance between the sensor and the sign. The direction detector detects the direction of the sign relative to the sensor. Finally, the processor preferably calculates a GPS offset for the sign relative to the GPS coordinates of the sensor. From the GPS offset, the processor can calculate and display the GPS coordinates of the sign.

These and other parameters for a traffic sign can be coded directly on the sign. In one embodiment, a label is provided, for example, on the back of the sign. The label may identify various parameters of the sign including, for example, the manufacturing date of the sign, the manufacturer of the sign, the substrate material of the sign, the reflective sheeting of the sign, the colors used on the sign, the dimensions of the sign, etc. The label may be a bar code, or some other code that can be electronically or optically read. By providing such a label, the time and resources required to log the necessary data for each sign in the transportation system may be reduced. Preferably, the label is coded and affixed to the sign at the time of manufacture, but can be added later if desired.

Alternatively, the coded information can be integrally incorporated into the sign.

Brief Description of the Drawings Other objects of the present invention and many of the attendant advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof and wherein: Figure 1 is a schematic diagram of an illustrative method of managing a transportation asset system; Figure 2 is a schematic diagram of an illustrative data processing system network used in a preferred embodiment of the present invention; Figure 3 is a table showing an illustrative asset inventory for a transportation system; Figure 4 is a table showing illustrative fields for a traffic sign in the asset inventory of Figure 3; Figure SA is a schematic diagram of a traffic sign with an identification label positioned thereon; Figure 5B is a cross-sectional view of the traffic sign of Figure 5a taken along line B-B; Figure 6 is a block diagram of an illustrative sensor assembly used for remotely detecting a parameter (e. g. the reflectivity, color, and location) of a sign; Figure 7 is a graph showing an illustrative degradation in reflectivity of a reflective sheeting versus time versus UV exposure; Figure 8 is a graph showing the integral of the UV exposure versus time over a several day period; Figure 9 is a graph showing an illustrative degradation in reflectivity of a reflective sheeting versus time versus temperature; Figure 10 is a schematic flow diagram of a first illustrative method of the present invention; Figure 11 is a schematic flow diagram of another illustrative method of the present invention; Figure 12 is a schematic flow diagram of yet another illustrative method of the

present invention; Figure 13 is a schematic flow diagram of another illustrative method of the present invention; Figure 14 is a schematic flow diagram of yet another illustrative method of the present invention; Figure 15 is a schematic flow diagram of another illustrative method of the present invention; Figure 16 is a schematic flow diagram of another illustrative method of the present invention; Figures 17A-17B show a schematic flow diagram of yet another illustrative method of the present invention; and Figure 18 is a schematic flow diagram of yet another illustrative method of the present invention.

Detailed Description of the Preferred Embodiments Figure 1 is a schematic diagram of an illustrative overall method for managing the assets of a system (e. g. transportation systems, factory or industrial systems, distribution systems, building systems, infrastructure systems, military systems, etc.). A first step in managing the assets of a system is to document the assets, or more generally, create an inventory of the assets of the system. Without such an inventory, the assets of the system cannot reasonably be managed. The inventory of assets is generally shown at 100.

Preferably, the inventory of assets 100 includes several fields describing each of the assets.

For example, for a traffic sign of a transportation system, the inventory of assets 100 may include one or more of the sign type (designation and description), the sign colors, the substrate material, the sheeting type, the dimensions, the blue prints, the manufacturing date of the sign, a digital picture of the sign, the post type, the geographic location of the sign, the orientation of the sign relative to the sun, various road parameters such as the speed limit near the sign, etc. An illustrative asset inventory for a transportation system is shown in Figure 3, and illustrative entries for a traffic sign are shown in Figure 4.

Likewise, for an infrastructure system such as a power grid system, the inventory of assets

100 may identify, for example, each power line, transformer, substation, etc, including details of each asset.

A modeling and asset upgrade block 112 is provided for analyzing the asset inventory 100. A primary function of the asset upgrade block 112 is to model the degradation in performance of selected assets and make suggestions when each of the assets should be upgraded or replaced. To accurately model the degradation of he assets, asset upgrade block 112 may read certain environmental conditions stored in the inventory of assets 100. Alternatively, or in addition, the asset upgrade block 112 may read certain environmental conditions or parameters from an environmental condition file 116, as shown. The environmental conditions may include any environmental condition that the asset is exposed to including, for example, one or more of the temperature, humidity, precipitation, UV exposure, etc., at various geographic locations. For assets where wear may effect the performance of the asset, such as pavement of pavement markings, the environmental conditions may also include selected environmental wear conditions such as the number of vehicles traveling over the pavement per day/month/year at various geographic locations. By correlating the geographic location of an asset with the environmental conditions in the environmental conditions file 116, the environmental conditions at the asset can be determined.

The modeling and asset upgrade block 112 preferably models the degradation in performance of selected assets versus time using one or more of the environmental conditions in the environmental conditions file 116. For a traffic sign of a transportation system, for example, the modeling and asset upgrade block 112 may model the degradation in performance parameters such as reflectivity, color, de-lamination, etc., all of which may be effected by the environmental conditions as further described below with respect to Figures 7-9. For assets such as pavement, the modeling and asset upgrade block 112 may model the degradation in performance parameters such as skid resistance, cracking, etc., all of which may be effected by the environmental conditions of the pavement including the environmental wear conditions.

By including the environmental conditions in the analysis, the asset upgrade block 112 may more accurately identify those assets that are predicted to fall below a predetermined performance threshold at a given point in time. Those assets that are

identified may be considered for an upgrade or replacement. By more accurately identifying the performance of the assets, the modeling and asset upgrade block 112 may increase the accuracy of any budget estimates created from the inventory of assets, and may optimize the inspection and maintenance schedules.

It is contemplated that the governing authority may produce inspection and maintenance schedules by identifying those assets that are predicted to fall below a predetermined performance threshold in a specified period of time. Likewise, it is contemplated that the governing authority may select one or more of the assets for replacement by identifying those assets that are predicted to fall below a predetermined performance threshold in a specified period of time, or by selecting individual assets while browsing or viewing the inventory. In the latter case, the user may, for example, identify an individual sign that is known to be knocked down for replacement. In either case, once the assets are selected for inspection, maintenance or replacement, a work order may be created authorizing a vendor to perform the desired work. Once the assets are upgraded or replaced, the asset inventory 100 is preferably updated via the database management block 106.

The modeling and asset upgrade block 112 may further include an asset upgrade optimization function. The asset upgrade optimization function may help a governing authority prioritize asset replacement, preferably by using one or more predetermined factors. For traffic signs of a transportation system, the predetermined factors may include, for example, sign type, speed limit, retro-reflectivity, sign obstructions, condition and/or performance of the sign, etc. A weighting may be applied to each of these factors, and a priority level may be determined for each asset by summing the weighted factors.

The priority level may be used by the governing authority to determine which assets should be replaced first.

It is contemplated that the modeling and asset upgrade block 112 may also receive upgrade or replacement requests from an accident analysis block 120. The accident analysis block 120 may read an accident database 122 that includes, for example, accident information including the location of accidents on or around the system. The accident analysis block 120 may first identify the accident locations of most concern by performing a statistical analysis on the accident database 122 to determine which locations have, for

example, the highest accident rates. The accident analysis block 120 may then analyze the condition and type of the assets near the identified accident locations, and may suggest an upgrade or replacement of certain assets.

For a transportation system, the accident analysis block 120 may suggest increasing the reflectivity of selected signs, or increasing the skid resistance of the pavement at certain locations, etc. These suggestions may be provided to the modeling and asset upgrade block 112, as shown. The accident analysis block 120 may also suggest providing additional assets, such as additional signage, additional traffic signals, more pavement markings, flashing warning lights, more guard rails, etc. As such, the accident analysis block 120 may provide a traffic engineering function. The suggested improvements to the asset inventory may be provided by an inventory improvement block 130. If the additional assets are approved and installed, the asset inventory 100 is preferably updated via the database management block 106.

A regulatory compliance block 102 may also be provided for checking the compliance of a system with applicable requirements. The compliance block 102 preferable reads the applicable requirements from a requirements file 104. For a transportation system, the roadway requirements may correspond to, for example, the requirements specified in the Manual of Uniform Traffic Control Devices (MUTCD).

Since the asset inventory 100 may include a description of the system, including the type and location of each of the assets, the compliance block 102 may compare the applicable requirements (e. g., MUTCD) in the requirements file 104 with the type and location of the assets in the asset inventory 100. Any discrepancies may be reported. Preferably, the compliance block 102 may also provide suggestions on how to modify the asset inventory 100 to remove the reported discrepancies. This may include upgrading one or more of the assets, moving some of the assets, providing additional assets, or making some other change. If changes are made to the assets, the asset inventory 100 is preferably updated via the database management block 106.

Finally, a financing block 136 is preferably provided. Financing block 136 may provide suggestions on where to obtain financing or grants to make the suggested changes to the asset inventory 100. There are various state and federal funding programs that are available for upgrading and/or replacing certain assets such as transportation assets. The

financing block 136 may identify one or more of these funding sources to help fund the desired changes. Alternatively, or in addition, the financing block 136 may help identify a source for leasing the assets, rather than purchasing the assets.

Figure 2 is a schematic diagram of an illustrative data processing system network used in a preferred embodiment of the present invention. It is contemplated that the present invention may be implemented, at least in part, using one or more data processing systems. In a preferred embodiment, the present invention is implemented using the World Wide Web (a. k. a."internet"). A local server 150 may store the asset inventory 100 on a disk 152 or the like. The local server may also execute one or more software programs for accepting user input, performing desired processing tasks, and providing a response. The asset inventory 100 and the one or more software programs may be maintained from a local data processing system 156, which may be either directly or indirectly coupled to the local server 150 via interface 158.

As is common, the local server may communicate with one or more remote servers, such as remote server 162. Remote users may then access the local server 150 via the remote server 162. Typically, the remote users interface with the remote server 162 via one or more remote data processing systems 160,170 and 172 using dial-up or direct connections 164,174 and 176. The remote server 162 is typically not directly coupled to the local server 150, but rather is connected through a web of servers each identified by a DNS address. By providing the appropriate web address, the remote users can access and control the one or more software programs on the local server 150. The one or more software programs running on the local server 150 may implement the modeling and asset upgrade block 112, accident analysis block 120, inventory improvement block 130, compliance block 102, data management block 106 and/or financing block 136 described above with respect to Figure 1.

Preferably, the user is allowed to browse or view the asset inventory 100 from one or more of the remote graphical user interfaces 160,170 or 172. The geographic location of each asset is preferably displayed by overlaying a multiple layered inventory map on a standard Geological Information Survey (GIS) map. The user may view the information or fields that correspond to a particular asset by simply selecting the asset.

To produce inspection, maintenance or replacement schedules, the user may initiate an asset upgrade function or sub-routine on the local server 150, which identifies those assets that are predicted to fall below a predetermined performance threshold in a specified period of time. The asset upgrade function preferably uses one or more environmental conditions or variables to model the degradation in the performance of the asset. In a preferred embodiment, the user may specify both the performance threshold and the time window.

Because the performance parameters are modeled using environmental conditions or variables, the inspection and maintenance schedules may be more accurate. Also, more accurate budget estimates can be provided. Budget estimates are often of prime importance to many governing authorities, as it is not uncommon for a governing authority to experience wide variations in the cost of inspecting and maintaining their assets from year to year. To assist in managing these budgetary variations, the present invention may allow the governing authority (e. g., municipality or company) to input various performance threshold levels into the modeling module and various time windows. Using the results provided by the modeling module, the governing authority might better predict and manage the costs associated with maintaining the assets of the system.

Regardless of how the assets are selected, a bid request generator may automatically create bid requests for the work to be performed. Preferably, the governing authority initiates a transaction by submitting a bid request to a bid request generator module. The bid request generator module then preferably electronically creates bid request for selected approved vendors. The bid requests are then posted, for example, on a web page of local server 150. Alternatively, the bid requests may be created and forwarded to approved vendors by e-mail, fax, U. S. Mail or any other delivery method.

The bid requests preferably include information extracted from selected fields of the inventory database. In a bid request for the manufacturing of a traffic sign, the bid request may include several fields that are extracted from the asset inventory include the type (designation and description), colors, substrate material, sheeting type, dimensions, blue prints, post type, and/or a digital picture of the sign.

After viewing or receiving the bid requests, the approved vendors may then provide bids in response to the bid requests. The bids are preferably received electronically, and

stored on the local server 150. It is contemplated, however, that the bids may be received by any delivery method. After the bids are reviewed, one or more of the vendors may be selected to perform the work. To authorize the work, a work order generator creates one or more work orders. Like the bid requests above, the work orders preferably include information extracted from selected fields of the inventory database. In a work order for the manufacture of a traffic sign, the fields that are extracted may include the type (designation and description), colors, substrate material, sheeting type, dimensions, blue prints, post type, and/or a digital picture of the sign. Once created, the work orders are preferably forwarded to the appropriate vendors by e-mail, fax, U. S. Mail or any other delivery method. Alternatively, the work orders may be posted on a web site.

In some cases, multiple work orders may be generated, each authorizing different vendors to perform different tasks. For example, one work order may be provided to a first vendor to manufacture the asset, and another work order may be provided to a second vendor to install the asset. Once the assets are upgraded or replaced, the asset inventory is preferably updated via a database management function or sub-routine.

The asset upgrade function may also receive upgrade or replacement requests from an accident analysis function. The accident analysis function may read an accident database stored on disk 152. The accident database may include, for example, accident information including the location of accidents on or around the system. The accident analysis function may first identify the accident locations of most concern by performing a statistical analysis on the accident database to determine which locations have, for example, the highest accident rates. The accident analysis function may then analyze the condition of the assets near the identified accident locations, and suggest the upgrade or replacement of certain assets. For a transportation system, for example, the accident analysis function may suggest increasing the reflectivity of selected signs or increasing the skid resistance of the pavement at certain locations, etc. Likewise, for an infrastructure system such as a power grid system, the accident analysis function may suggest increasing the shielding or safe zone around certain assets such as power lines or transformer stations, moving certain assets, upgrading certain assets, etc.

The accident analysis function may also suggest providing additional assets. For a transportation system, this may include providing additional signage, additional traffic

signals, more pavement markings, flashing warning lights, more guard rails, etc. As such, the accident analysis function may provide a system engineering function. The suggested improvements to the asset inventory may be provided to an inventory improvement function. If the additional assets are approved and installed, the asset inventory is preferably updated via the database management function.

A regulatory compliance function may also be provided for checking the compliance of a system with applicable requirements. The compliance function preferable reads the applicable requirements from a requirements file. This file may, if desired, be stored on disk 152. For a transportation system, the requirements file may include the applicable roadway requirements, such as the requirements specified in the Manual of Uniform Traffic Control Devices (MUTCD). Since the asset inventory preferably includes a description of the system, including the type and location of each of the assets, the compliance function may compare the applicable system requirements (e. g., MUTCD) with the type and location of the assets in the asset inventory. Any discrepancies may be reported to the governing authority via one of the graphical user interfaces on remote data processing systems 160,170 or 172. Preferably, the compliance function may also provide suggestions on how to modify the asset inventory to remove the reported discrepancies.

This may include upgrading one or more assets, moving assets, providing additional assets, or making some other change. If changes are made to the assets, the asset inventory is preferably updated via the database management function previously described.

Finally, a financing function may be provided. The financing function may provide suggestions on where to obtain financing or grants to make the suggested changes to the asset inventory. There are various state and federal funding programs that are available for upgrading and/or replacing many assets, including transportation assets. The financing function may identify one or more of these funding sources to help fund the desired changes. The financing function may also identify possible sources for leasing the assets, if desired.

Figure 3 is a table showing an illustrative asset inventory for a transportation system. The asset inventory is generally shown at 200 and includes a first column 202, a second column 204 and a number of third columns 206 generally designated as"Other Parameters". The first column 202 identifies each of the assets in the transportation

system. For example, a stop sign is designated at row 210, and a section of roadway is designated at row 214. The second column 204 indicates the asset location. The asset location is preferably designated by GPS coordinates, but may be any type of location designation. The stop sign 210 has a location designated by GPS coordinates 212.

Likewise, the roadway 214 has a location designated by several GPS coordinates, each providing a point along a line extending through the center of the roadway.

The"Other parameters"column 206 designates various parameters relevant to each asset. For example, the roadway section 214 has a parameter 218 that indicates whether the roadway is a two-lane or four-lane road. The roadway 214 also includes a parameter 220 that specifies the width of the roadway, a parameter 224 that identifies the pavement type and/or condition, and a parameter 226 that designates the skid resistance of the pavement. The parameters shown in the asset inventory of Figure 3 are only illustrative. It is contemplated that other parameters may be provided for each asset.

Figure 4 is a table showing illustrative fields that may be included in the asset inventory of Figure 3 for a traffic sign. The diagram is generally shown at 240. A first entry may include the sign type, as shown at 242. The sign type preferably indicates whether the sign is a stop sign, a yield sign, a street name sign, etc. Other parameters that relate to the sign type include the size or dimension, the color, the sign code, the substrate type, the manufacturer of the sign, the reflective sheeting type, and the ink type.

A second entry may include the age of the sign, as indicated at 244. The age of the sign may include the date the sign was manufactured and/or installed. Another entry may include the reflectivity of the sign as of a particular date, as shown at 246. The reflectivity value preferably is a known or measured reflectivity value rather than a predicted reflectivity value. Yet another entry may include the blue prints for the sign. The blue prints (which preferably include a digital object oriented file) preferably include the layout of the sign, including the location of any graphics or text, the materials used in constructing the sign, a digital photograph of the sign, etc.

Another entry in the asset inventory may identify the geographic location of the sign, as shown at 250. The geographic location is preferably identified using GPS coordinates. In addition to providing the geographic location, the asset inventory may include an entry that designates the general orientation of the sign, as shown at 252. The

general orientation of the sign may indicate, for example, the direction that the sign faces, including whether the sign points towards or away from the sun. This information can be used to model the degradation in reflectivity of the sign, as described above.

Another entry in the asset inventory may be the specific orientation of the sign, as shown at 254. The specific orientation of the sign may indicate the location of the sign relative to the roadway, the relative placement of the sign on a multi-sign post, etc.

Yet another entry in the asset inventory may be data relating to a previous visual inspection of the sign, as shown at 256. An inspector may indicate if there is any damage or wear on the sign, the general condition of the sign, the legibility of the sign, and/or any other special features of the sign. Finally, the asset inventory may include an entry that indicates the ownership of the sign, as shown at 258.

Figure SA is a schematic diagram of a sign having an identification label 266 positioned on or in the sign. The sign is generally shown at 260 and includes a sign plate 262 and a post 264. Figure 5B is a cross-sectional view of the sign in Figure SA taken along lines 5B-5B. The sign is shown having a substrate 220 and a reflective coating 272.

The identification label 266 is preferably positioned on the back surface of the substrate 270, as shown. The identification label 266 is preferably a bar code or some other code that can be electronically or optically read. The label may have a separate substrate, such as a sticker, or may simply be ink applied directly to the substrate of the sign plate 262.

Alternatively, or in addition, the identification label 266 may be an"invisible"marking, such as an UV or IR marking. Finally, it is contemplated that the identification label 266 may be on the front, back or integral with the sign.

It is contemplated that a number of parameters relating to the construction of the sign may be coded on the identification label 266. For example, the identification label may identify the manufacturing date of the sign, the manufacturer of the sign, the substrate material of the sign, the reflective sheeting of the sign, the colors used on the sign, the dimensions of the sign, etc. By providing such an identification label, the time and resources required to log the necessary data for each sign may be reduced. Preferably, the identification label is coded and affixed to the sign at the time of manufacture, but can be added later if desired.

Figure 6 is a black diagram of an illustrative sensor assembly (e. g. hand held sensor assembly) used for remotely detecting the reflectivity, color and location of a sign. It is known that creating an inventory of assets for a transportation system can require significant time and resources. For traffic signage, some of the most difficult data to collect is the reflectivity, color and location of the sign. To help collect this information, the sensor device of Figure 6 is provided. The sensor device is generally shown at 290, and preferably includes both a colorimeter 292 for measuring the color of the sign 296 and a reflectometer 294 for measuring the reflectivity of the sign 296. Preferably, both the color and reflectivity can be measured from a location that is remote from the sign. This can be accomplished, for example, by directing a beam of light 298 toward the sign 296.

The reflectometer 294 may include a light sensor for measuring the percentage of light that is reflected back. This measurement will typically depend on the distance the sensor device 290 is from the sign 296. Accordingly, a distance detector 302 may also be provided, as further described below. To determine the color of the sign, the colorimeter may sense the wavelength of the light that is reflected back.

To determine the location of the sign, the sensor device 290 may include a GPS detector 300, a distance detector 302, a direction detector 304 and a processor 308. The GPS detector 300 preferably detects the GPS coordinates of the sensor device 290. The distance detector 302 detects the distance between the sensor device 290 and the sign 296.

The direction detector 304 detects the direction to the sign 296 relative to the sensor device 290.

The processor 308 may take the measurements from the distance detector 302 and the direction detector 304 and calculate a GPS offset for the sign 296 relative to the GPS coordinates of the sensor device 290. Adding the GPS offset to the GPS coordinates provided by the GPS detector 300, the processor can calculate the GPS coordinates of the sign 296 and display the coordinates on display 310. It is contemplated that the sensor may include an output port 312 for downloading the reflectivity, color and GPS coordinates of the sign 296 to a data processing system, and eventually to the asset inventory.

Figure 7 is a graph showing an illustrative degradation in reflectivity of a reflective sheeting versus time versus UV exposure. The graph is generally shown at 410, and

includes time along the x-axis and reflectivity along the y-axis. At time t=0, the reflectivity of the sheeting is high, as shown at 412. After time t=0, however, the reflectivity of the sheeting tends to degrade.

Line 414 shows the degradation in reflectivity versus time with a high UV exposure, such as when the sheeting is exposed to direct sun light. Line 416 shows the degradation in reflectivity versus time with a relatively low UV exposure, such as when the sheeting is exposed to sun through thick clouds. Alternatively, line 414 may represent the degradation in reflectivity versus time for a sign that faces away from the sun, while line 416 may represent the degradation in reflectivity versus time for a sign that is facing the sun.

A minimum acceptable reflectivity threshold is shown at 420. As can be seen, the time required for a sign that is exposed to many sunny days (such as in Phoenix, Arizona) to reach the minimum reflectivity threshold 420 is much shorter than the time required for a sign that is exposed to many cloudy days (such as in Seattle, Washington). Likewise, the time required for a sign that is facing the sun to reach the minimum reflectivity threshold 420 is much shorter than is the time required for a sign that is facing away from the sun.

Depending on the environmental conditions, such as the number of cloudy days and the number of sunny days, the actual degradation in reflectivity of a sign will likely reside somewhere in area 418. To provide a more accurate prediction of the actual reflectivity of a sign versus time, the present invention contemplates providing a model that accepts, for example, the number of cloudy days, the number of sunny days, and/or the facing direction of the sign. With this information, the model may provide a more accurate prediction of the actual reflectivity of the sign, such as shown at 422.

Figure 8 is a graph showing the UV exposure versus time over a several day period, along with the integral of the UV exposure. The chart is generally shown at 430.

The UV exposure experienced during a first day is shown at 432. The first day is shown as a sunny day. The UV exposure experienced during the first night is shown at 434. As can be seen, the UV exposure may be negligible during the nighttime hours. The UV exposure experienced during a second day is shown at 436. The second day is shown as sunny during approximately the first half of the day, with clouds rolling in during the second half of the day. The UV exposure during the second night is again shown to be negligible. The

UV exposure during the third day is shown at 442. The third day is shown beginning cloudy, but ending sunny.

To model the cumulative UV exposure of a sign in such an environment, the UV exposure during each of the first, second, and third days may be integrated, as shown at 430. The area 460 represents the integral of the UV exposure across days one, two and three. It is contemplated that in some embodiments, it is this cumulative UV exposure that may be used to model the degradation in reflectivity of a sign.

Figure 9 is a chart similar to Figure 7, but shows the reduction in reflectivity versus time versus temperature. Again, at time t=0, the reflectivity of the sheeting is high, as shown at 470. However, like above, the reflectivity tends to degrade over time, and in this case the amount of degradation is dependent on the temperature. A first line 472 shows the degradation in reflectivity versus time at a temperature of-10° F [-23° C]. Line 474 shows the degradation in reflectivity versus time at a temperature of 140° F [60° C]. To provide a more accurate prediction of the actual reflectivity of a sign versus time, the present invention contemplates providing a model that accepts, for example, the temperature at or near the geographic location of the sign. With this information, the model may provide a more accurate prediction of the actual degradation of the reflectivity of the sign, such as shown at 480. While Figures 9-11 show the degradation of reflectivity of a reflective sheeting over time under UV exposure and temperature, a similar approach may be applied to numerous other performance parameters of an asset (e. g., color and de- lamination for a sign, skid resistance for pavement, etc.), and over a wide variety of environmental conditions or parameters. Preferably, the model uses historical averages for selected environmental conditions or parameters at a general geographic location, such as at a city where the asset is located.

Figure 10 is a flow diagram of an illustrative method of the present invention, wherein the asset inventory includes one or more environmental conditions or parameters for selected assets. The flow diagram is generally shown at 360. An asset inventory is provided at 364. The asset inventory preferably identifies one or more environmental conditions or parameters for selected assets. The environmental conditions or parameters may include the geographic location of the asset, the direction of the asset relative to the sun, etc.

A model is also provided at 366 for modeling the degradation of at least one asset performance parameter using at least one of the environmental conditions or parameters stored in the asset inventory. Illustrative asset performance parameters may include reflectivity, color, de-lamination, etc. Using the model and the inventory of assets, step 368 predicts when a particular asset performance parameter will fall below a predetermined performance threshold. This is preferably accomplished by applying at least one of the environmental conditions or parameters to the model.

Step 370 identifies those assets that have an asset performance parameter that is predicted to fall below the predetermined performance threshold within a predetermined time period. In a preferred embodiment, a user may specify the predetermined performance threshold and/or the predetermined time period.

Figure 11 is a flow diagram of another illustrative method of the present invention, wherein one or more environmental conditions or parameters are provided separately from the asset inventory. The flow diagram is generally shown at 380. Step 384 provides an inventory of assets. Step 386 models the degradation in performance of selected assets versus time. The modeling step 386 accepts environmental conditions or parameters 388 via interface 389. The environmental conditions or parameters may include, for example, the temperature, humidity, UV exposure, etc. Step 390 identifies those assets that are predicted to fall below a predetermined performance threshold at a given point in time.

Once determined, step 392 reports the identified assets to the user, typically through a graphical user interface.

Step 394 allows the user to authorize which of the identified assets are to be inspected, maintained, upgraded or replaced. Step 396 creates a work order for the assets authorized for inspection, maintenance, upgrade or replacement. Step 398 sends the work order to a vendor to perform the work. If the asset is to be replaced, the work order preferably includes the manufacturing specifications for the asset.

Figures 12-18 provide a number of illustrative methods in accordance with the present invention. These methods are meant to only be illustrative, and in many cases, many of the steps may be eliminated and/or additional steps may be added.

Figure 12 is a flow diagram of an illustrative method including the step of automatically creating a work order for inspection, maintenance, upgrades or replacement

of assets. The flow diagram is generally shown at 490. Step 494 provides an inventory of assets in a computer readable form. Step 496 allows the user to browse the inventory of assets from one or more graphical user interfaces. Step 498 allows the user to select one or more assets for inspection, maintenance, upgrade or replacement via the graphical user interface. Step 500 provides suggestions to the user for product upgrades to selected assets. Step 502 creates a work order for the assets selected by the user for inspection, maintenance, upgrade or replacement. The work order is preferably in electronic form.

Step 504 sends the work order to a vendor to perform the desired work. The work order may be sent by e-mail, fax, U. S. Mail or any other delivery method. Finally, step 506 updates the asset inventory to include any upgraded or replacement assets after the work has been completed by the vendor.

Figure 13 is a flow diagram of yet another illustrative method including the steps of extracting manufacturing specifications from the asset inventory and providing the manufacturing specifications along with the work order. The flow diagram is generally shown at 520. Step 524 stores an inventory of assets in a computer readable form. The inventory of assets preferably includes selected manufacturing specifications for each of the assets. Step 526 identifies one or more of the assets for replacement. Step 528 extracts the selected manufacturing specifications from the inventory for those assets identified for replacement. Step 530 creates a work order for manufacturing selected assets identified for replacement. The work order preferably includes the extracted manufacturing specifications for the assets identified for replacement. Step 532 sends the work order to a vendor for manufacturing of the selected assets. The work order preferably is sent in electronic form such as by e-mail or fax, but may be delivered by any delivery method.

Step 534 updates the inventory to include the replacement asset after the replacement asset has been installed.

Figure 14 is a flow diagram of yet another illustrative method including the steps of creating electronic bid requests for soliciting bids from approved vendors. The flow diagram is generally shown at 550. Step 554 stores an inventory of assets in a computer readable form. The inventory of assets preferably includes selected manufacturing specifications for each of the assets. Step 556 identifies one or more of the assets for replacement. Step 558 extracts the selected manufacturing specifications from the

inventory for those assets identified for replacement. Step 560 creates electronic bid requests for selected assets identified for replacement. The bid requests preferably include the extracted manufacturing specifications for the selected assets identified for replacement. Step 562 allows one or more vendors to view the electronic bid requests.

This may be accomplished in any number of ways including posting the bid requests on a web site, or delivering the bid requests to approved vendors by e-mail, fax, U. S. Mail or some other delivery method. Step 564 accepts bids, preferably in electronic form, from those vendors that choose to provide a bid. Step 566 electronically authorizes one or more of the vendors to manufacture the replacement assets.

Figure 15 is a flow diagram of another illustrative method including the steps of using accident data to suggest changes to the asset inventory to reduce the number of accidents on the system. The flow diagram is generally shown at 580. Step 584 stores an inventory of assets in a computer readable form. The inventory preferably includes the type and location of each of the assets. Step 586 provides accident data for at least part of the transportation system. The accident data preferably identifies the location of each of the accidents. Step 588 identifies the assets near the location of selected accidents. Step 590 suggests changes to the inventory of assets to reduce the number of accidents.

Figure 16 is a flow diagram of another illustrative method including the step of comparing the asset inventory with predetermined requirements to determine the compliance of the asset inventory with the requirements. The flow diagram is generally shown at 600. Step 604 provides an inventory of assets of the system (e. g. of a roadway).

The inventory preferably includes a description of the system, and the type and location of each of the assets of the system. Step 606 stores the inventory in a computer readable form. Step 608 stores a number of predefined requirements of the system in a computer readable form. Step 610 compares the predetermined requirements with the type and location of the assets stored in the asset inventory. Preferably, the predetermined requirements are compared with the type and location of the assets stored in the asset inventory using a computer program residing on one or more data processing systems.

Step 612 reports selected discrepancies between the predetermined requirements of the system and the type and location of the assets in the asset inventory. Step 614 suggests how to modify the inventory of assets to remove selected reported discrepancies.

Figures 17A-17B show a flow diagram of an illustrative method for helping a user design a custom sign. The flow diagram is generally shown at 630. Step 634 provides a number of questions regarding the use of the custom sign, preferably via a graphical user interface. Step 636 receives answers to the number of questions. Step 638 provides a proposed sign design based on the answers provided by the user. Step 642 allows the user to accept, modify or reject the proposed sign design.

If the user rejects the proposed sign design, control is passed to step 646, and the algorithm is exited at step 647. If the user chooses to modify the proposed sign design, control is passed to step 648. Step 648 allows the user to edit the proposed sign design.

Once the proposed sign design is edited, step 650 provides a number of suggestions for improving the sign design. The user can either accept or reject each of the suggestions.

Once each of the suggestions is accepted or rejected, control is then passed to step 652.

Referring back to step 642, if the user accepts the proposed sign design, control is given to step 652. Step 652 creates a work order for the proposed sign design. Step 656 sends the work order to a vendor for manufacturing the proposed sign design. Step 658 updates the inventory to include the proposed sign design, if desired.

Figure 18 is a flow diagram of yet another method for helping a user design a custom sign. The flow diagram is generally shown at 670. Step 674 accepts a proposed sign design from the user. Step 676 analyzes the proposed sign design and provides a number of suggestions for improving the proposed sign design. Step 678 allows the user to accept or reject each of the suggestions provided by step 676. If the user accepts one of the suggestions, control is given to step 682, wherein a corresponding change is made to the proposed sign design. If the user rejects a suggestion, control is given to step 680, wherein the proposed sign design is not changed. Once all the suggestions are either accepted or rejected by the user, control is given to step 684 via path 686. Step 684 creates a work order for the proposed sign design. Step 688 sends the work order electronically to a vendor to manufacture the proposed sign design.

Having thus described the preferred embodiments of the present invention, those of skill in the art will readily appreciate that the teachings found herein may be applied to yet other embodiments within the scope of the claims hereto attached.