System and method for managing remotely and distantly located assets

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This Application for Patent claims the benefit of priority from, and hereby incorporates by reference the entire disclosure of, co-pending U.S. patent application Ser. No. 09/804,909, filed Mar. 13, 2001 and having Publication No. 2001/0037298 published on Nov. 1, 2001, which is a continuation-in-part of U.S. patent application Ser. No. 09/315,071, filed May 19, 1999.

BACKGROUND OF THE INVENTION

[0002] 1. Technical Field of the Invention

[0003] The principles of the present invention are generally directed to an asset management system, and, more specifically, but not by way of limitation, to a system and method using a wireless architecture to communicate with wireless devices associated with the assets.

[0004] 2. Description of Related Art

[0005] The main assets of a business organization include buildings, equipment, people, money and data. Data assets are acquired, used, and maintained in the same manner as any other asset, and might include information regarding the other assets. Such assets can be mobile or fixed, tangible or intangible assets. Fixed assets may include equipment (e.g., manufacturing equipment), buildings, and fixtures. Mobile assets may include battery-powered or unpowered machines, such as forklifts, cars, boats, airplanes, loading equipment, railroad cars, and even small parcels, containers, letters, and even people. It should be understood that fixed and mobile assets may be personal, commercial, and/or military assets. Businesses must “manage” such assets to accomplish their business purposes.

[0006] The management of such assets includes financial, accounting, marketing, and regulatory issues, to name a few, related to the use of such assets for a particular business. Asset management systems facilitate the use of such assets for directing or carrying on such business and, as such, are evaluated in the context of a specific business. For example, package delivery companies are often interested in determining the location of its fleet of trucks so that the package delivery company may easily determine the time of arrival of the trucks. Car rental companies, too, are interested in determining exact locations of their vehicles for inventory purposes. Still yet, warehousing companies are interested in determining locations of particular mobile assets, such as forklifts and containers. Additionally, companies that utilize mobile assets, such as forklifts, are interested in providing access control to the mobile assets so that only those employees authorized to utilize the mobile assets may do so. Thus, asset management systems utilize different databases depending on the nature of the business and industry, which define the data elements for each database. Regardless of the variety of databases, asset management systems require robust communications systems to ensure that all of the data defined by the business is created, stored, processed and updated according to the mandates and specifications of that business.

[0007] Wireless communications systems have permeated all aspects of asset management systems and have become a prevalent tool in a variety of consumer and industrial applications worldwide. Such wireless communications systems include mobile telephones, satellite television, citizen-band radios, remote computer networking, wireless local area networks (LANs), and remote wireless devices. Typically, wireless communications systems, including those for asset management systems, include a central computing system coupled with a wireless infrastructure that communicates with multiple wireless devices associated with specific assets, i.e., an asset communicator. Conventional design methodology for the wireless communications systems requires that the asset communicator have an active communication link through the wireless infrastructure to the central computing system in order to operate and perform functions associated with the asset management system. In other words, without the communication links between the asset communicator, wireless infrastructure, and the central computing system, the asset communicator is either inoperative or not fully operative. Moreover, if either (i) the communication link between the central computing system and wireless infrastructure or (ii) the link between the wireless infrastructure and the asset communicator is not operating properly, many features of the asset communicator become inoperative. A useful asset management system must continue to manipulate the data as described above regardless of the loss or intermittent operation of the communication links and, therefore, requires a wireless communication architecture that facilitates the manipulation of this data. For example, an asset management system for vehicles might include access control data for authorized operators. However, as previously discussed, conventional communications systems utilized for asset management purposes require a communication link be established between the asset communicator and the central computing system. Hence, the asset management system must utilize a wireless communication architecture that is not fully dependent upon instantaneous or active communication between the central computer and the asset communicators.

[0008] As indicated above, asset management systems and their associated wireless communications systems are developed and operated in the context of a specific business to resolve specific business problems. Continuing with the example of a mobile asset or vehicle (e.g. a forklift) and an asset communicator attached to the vehicle that processes access control for the vehicle, a manager of a fleet of vehicles is generally interested in assuring that the vehicles are operated by a group of employees having the approval to do so at certain times of the day and on certain days of the week to generate a list of “approved operators” that have access to a vehicle at a specific time. Thus, the asset management system includes a database of the approved operators that is checked when the operator logs in and starts the vehicle. Because conventional wireless communications systems rely on the communication link between the asset communicator and the central computing system, the database of the approved operators is maintained at the central computing system and accessed in the event of a login request to verify and grant access by the operator.

[0009] In the case of tracking vehicles, the business goal is to determine not only the precise location of the vehicle, but also the route that the vehicle traveled to reach a particular location. Utilizing asset communicators that require an active link between the mobile wireless device and the central computing system becomes problematic for these and other particular business issues due to frequent or infrequent failures of any link between the asset communicator and the central computing system. Because of the communication link failures, essential location data for the assets is lost. Additionally, utilizing a conventional communications system, tracking the traveled route of the asset requires that the asset communicates with the wireless infrastructure at a relatively high frequency so that the central computer system can determine location and path traveled of the asset. This technique of determining position and path traveled, however, presents a significant limitation in terms of system bandwidth and computing capacity. In the case of the asset communicator having global positioning system (GPS) capability, the transmission of position from the asset communicator is still problematic for system bandwidth and, potentially, communication fee-related reasons. If, for example, a communications system utilizes a GPS and cellular combination solution, the cost of continuous communication updates includes a cellular telephone call for each location update.

[0010] One reason for the-high frequency of transmission is due to conventional asset management systems utilizing “dumb” terminals (i.e., asset communicators) that communicate information with the wireless infrastructure and require that the central computing system perform computational duties as the “dumb” terminal does not have decision making capability. Utilizing a “dumb” terminal becomes even more problematic in that if many assets reside in a small area, the communication bandwidth between the mobile wireless devices and the wireless infrastructure is degraded to the point that the business problems, such as access control and position tracking, are simply incapable of truly being solved.

SUMMARY OF THE INVENTION

[0011] To overcome the problems of wireless communications systems being incapable of effectively solving business problems due to, for example, (i) requiring wireless mobile devices to have an active link to both a wireless infrastructure and a central computing system, (ii) utilizing “dumb” terminals having communication capabilities only, and (iii) having the central computing system determine location of the wireless mobile device, a robust wireless communications system has been developed. The robust wireless communications system allows for “intelligent” mobile wireless devices (e.g., asset communicators) to make decisions, typically without interaction with the wireless infrastructure and/or central computing system. By not requiring an active link between the mobile wireless devices and the central computing system via the wireless infrastructure, the system may be utilized to solve business problems that demand real-world flexibility and are substantially fault tolerant.

[0012] The system according to the principles of the present invention provides for information stored by the central computing system to be downloaded to the wireless infrastructure. The wireless infrastructure includes a computing system for maintaining and transmitting the information to the mobile wireless devices. The downloading and transmitting of the information from the central computing system, wireless infrastructure, and mobile wireless device is performed sequentially, but not necessarily simultaneously or even substantially simultaneously. By allowing the wireless infrastructure to maintain and transmit the information without an active link to the central computing system, the robustness of the wireless communications system is increased.

[0013] In the uplink direction, information, such as positioning, time of use, and fuel level, measured by the mobile wireless devices may be stored and processed by the mobile wireless devices until a communication link to the wireless infrastructure becomes established. The uplink information may be stored by the wireless infrastructure until a communication link is established with the central computing system. Also, the data may be determined unnecessary by the mobile wireless device, and may thus be discarded, thereby dramatically eliminating the need for storage or transmission. By providing for sequential, non-simultaneous communication of downlink and uplink information, the information may be maintained within the robust wireless communications system without being affected by system communication failure. The downlink and uplink communication techniques, and the use of intelligent mobile wireless devices allow for many previously insolvable business problems to be solved.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] A more complete understanding of the method and apparatus of the present invention may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:

[0015]FIG. 1 is an exemplary block diagram of a robust wireless communications system for performing asset management according to the principles of the present invention;

[0016]FIG. 2 is a more detailed block diagram of the robust wireless communications system of FIG. 1;

[0017]FIG. 3 is another exemplary block diagram of the robust wireless communications system of FIGS. 1 and 2;

[0018]FIG. 4 is an exemplary interaction diagram for performing downlink and uplink communications between components of the robust wireless communications system of FIG. 3;

[0019]FIG. 5 is an exemplary interaction diagram for performing immediate communications between the components of FIG. 3;

[0020]FIGS. 6A and 6B are exemplary databases operating in the robust wireless communications system of FIG. 3;

[0021]FIG. 7 is an exemplary flow diagram for communicating data in the robust wireless communications system of FIG. 3;

[0022]FIG. 8 is another exemplary flow diagram for communicating data in the robust wireless communications system of FIG. 3;

[0023]FIGS. 9A and 9B are exemplary flow diagrams for performing uplink communication on the robust wireless communications system of FIGS. 3, 4, and <b>6</b>B;

[0024]FIG. 10 is a graphical representation of entities associated with the robust wireless communications system of FIG. 3 and relational databases associated therewith;

[0025]FIG. 11 is an exemplary flow diagram for determining and providing authorization of an asset for an operator utilizing the robust wireless communications system of FIGS. 3, 4, and <b>6</b>A;

[0026]FIG. 12 is an exemplary flow diagram describing altering system parameters for the robust wireless communications system of FIG. 3;

[0027]FIG. 13 is an exemplary flow diagram for the asset communicator to start and stop utilization monitoring as utilized on the robust wireless system of FIGS. 3 and 6B;

[0028]FIG. 14 is an exemplary illustration of a mobile asset having a power monitor for monitoring power usage according to FIG. 13;

[0029]FIG. 15 is an exemplary chart indicating vehicle usage during the course of a 24-hour time period on the robust wireless communications system of FIG. 3;

[0030]FIGS. 16A and 16B represent an exemplary flow diagram for determining and communicating position of an asset utilizing the robust wireless communications system of FIGS. <b>3</b>-<b>5</b> and <b>6</b>B;

[0031]FIG. 17 is an exemplary flow diagram for performing the OSHA compliance utilizing the robust wireless communications system of FIGS. <b>3</b>-<b>5</b>, <b>6</b>A and <b>6</b>B;

[0032]FIG. 18 is an exemplary flow diagram providing a process for performing the two-way messaging on the robust wireless communications system of FIG. 3;

[0033]FIG. 19 is an exemplary flow chart providing a process for measuring battery voltage of an asset utilizing the robust wireless communications system of FIGS. 3, 4, and <b>6</b>B;

[0034]FIG. 20 is an exemplary flow diagram <b>1900</b> providing for a process of changing the battery with a charged battery utilizing the robust wireless communications system of FIGS. <b>3</b>-<b>5</b>, <b>6</b>A, and <b>6</b>B;

[0035]FIG. 21 is a typical working environment for a mobile asset utilizing the robust wireless communications system of FIG. 3 to charge and replace a battery;

[0036]FIG. 22 is a top view of an exemplary mobile asset of FIG. 1 capable of measuring impact of the mobile asset;

[0037]FIG. 23 is an exemplary flow diagram for monitoring of an impact to the mobile asset of FIG. 21;

[0038]FIG. 24 is an exemplary block diagram indicative of a method for managing scheduled maintenance of assets utilizing the robust wireless communications system of FIG. 3 and communication technique of FIG. 4;

[0039]FIG. 25 is an exemplary embodiment of the wireless infrastructure of FIG. 1 for providing wireless communications on a remotely populated fleet of assets, such as railcars; and

[0040]FIG. 26 is an exemplary flow diagram for managing the remotely populated assets utilizing the robust wireless communications system of FIG. 3. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>LIST OF TABLES</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>TABLE 1.</entry><entry>Vehicle Information;</entry></row><row><entry /><entry>TABLE 2.</entry><entry>Operator Information;</entry></row><row><entry /><entry>TABLE 3.</entry><entry>Group Information;</entry></row><row><entry /><entry>TABLE 4.</entry><entry>Vehicle Utilization Information;</entry></row><row><entry /><entry>TABLE 5.</entry><entry>Vehicle Location Information;</entry></row><row><entry /><entry>TABLE 6A.</entry><entry>OSHA Question List Details;</entry></row><row><entry /><entry>TABLE 6B.</entry><entry>Vehicle Profile Information;</entry></row><row><entry /><entry>TABLE 7.</entry><entry>Low Battery Information; and</entry></row><row><entry /><entry>TABLE 8.</entry><entry>Impact Information.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS OF THE INVENTION

[0041] Asset management and tracking has become an important issue for large and small companies due to financial considerations, customer concerns, and governmental regulations, for example. Technology in the fields of information technology (IT) and telecommunications has evolved to enable robust wireless communications to perform asset management, especially in a variety of aspects that solve business problems that do not necessarily require instantaneous or active communication between a central computer and an asset (i.e., mobile or fixed). As even the most stable communications networks tend to fail, depending on the particular asset management application, failure of the communications network may severely disrupt business operations. Additionally, communications networks may be bandwidth and/or cost prohibitive for many asset management applications.

[0042] The principles of the present invention provide for a robust wireless communications system that performs asset management of mobile and/or fixed assets. The robust wireless communications system accounts for network failures and throughput issues by providing intelligence in both the wireless infrastructure and mobile wireless devices (e.g., asset communicators) associated with the assets. By including intelligence in the wireless infrastructure and asset communicators, the assets may remain substantially operational even in the event of a communication link failure between the central computer and the wireless infrastructure and/or between the wireless infrastructure and the asset communicator(s). Additionally, an asset that becomes out-of-range of the wireless infrastructure may still perform intended duties and utilize the associated asset communicator to perform the asset management functions. Furthermore, by incorporating intelligence into the wireless infrastructure and asset communicators, business decisions can be made that are simply not possible without such intelligent devices, often without transmitting any data.

[0043] The robust wireless communications system is capable of distributing downlink data utilized in performing the asset management functionality in a sequential, but not necessarily simultaneous, transmission from the central computing system to the wireless infrastructure and from the wireless infrastructure to the asset communicators. In that regard, and in contrast to traditional wireless communications systems, the asset communicators need not have active links between (i) the central computing system and wireless infrastructure, and (ii) the wireless infrastructure and asset communicators for the data to be downloaded to the asset communicators. Accordingly, the data may be transmitted to the asset communicators by the wireless infrastructure irrespective of the communication link between the central computing system and wireless infrastructure. In the uplink direction, the asset communicators are able to receive data from the asset and/or generate data without an active communication link with either the wireless infrastructure and/or the central computer. Upon the communication link between the asset communicator and wireless infrastructure becoming established, the data may be uploaded to the wireless infrastructure, stored therein, and further uploaded from the wireless infrastructure to the central computing system upon a connection being established thereto.

[0044] To enable synchronization of the downlink and uplink between the central computing system, wireless infrastructure, and asset communicators, transaction codes may be applied to individual datasets or data records. By applying transaction codes that are temporal (i.e., based on time of creation), the synchronization process may be maintained even if a communication failure occurs during synchronization of the data by determining the transaction codes that exist in the different locations, and continuing synchronizing therefrom. On the downlink communication, the transaction code is used to indicate the most up-to-date data. On the uplink communication, the transaction code is used to create a unique key for ensuring the integrity of data such that the order and uniqueness of each dataset is maintained.

[0045] In the central computing system, datasets may be generated by a supervisor or operator who enters new data or edits existing data to download to the asset communicator(s). The asset communicators operate in an intelligent manner by, in general, forming data records based on events or based on receiving data from an operator interfacing with the asset communicator. One example of an event may include a vehicle operator logging on, performing various duties with the vehicle, and logging off. Upon logging off, because the asset communicator is intelligent, a summary of operational information (i.e., dataset) that a customer desires may be generated, applied a transaction code, and stored on the asset communicator. The dataset, including the associated transaction code, may thereafter be transmitted to the wireless infrastructure and/or be used by the asset communicator to make decisions about future transactions (e.g., re-use of previously entered data, such as an OSHA checklist, for future operator(s)).

[0046] By the asset communicator summarizing the information rather than periodically transmitting the intermittent information to the wireless infrastructure, (i) the asset management may occur without an active communication link between the asset communicator and the wireless infrastructure, (ii) the bandwidth (and potentially communication cost) of the system may be reduced, (iii) the central computing system need not be overloaded with computational responsibilities that the distributed asset communicators are capable of handling, and (iv) the cost of system components (e.g., asset communicators, communication devices, and infrastructure installation costs) may be reduced due to the amount of memory and communication requirements being reduced. Additionally, and more importantly, the robust communications system may solve many business problems that otherwise could not be solved as the asset communicator and system are capable of performing many, if not all, of the intended business functions on future transactions without either (i) a link between the wireless infrastructure and the asset communicator and/or (ii) a link between the wireless infrastructure and the management computer system.

[0047] Robust Wireless Communications System Architecture

[0048]FIG. 1 shows an exemplary block diagram of a wireless communications system <b>100</b><i>a </i>for an asset management system according to the principles of the present invention, and more specifically, but without limitation, an asset management system for managing forklifts <b>105</b><i>a</i>-<b>105</b><i>d </i>(collectively <b>105</b>). The robust wireless communications system <b>100</b><i>a </i>includes at least one local monitor (LM) <b>110</b><i>a</i>-<b>110</b><i>f </i>(collectively <b>110</b>) having a wireless unit operative with a communication range defined by the cells <b>111</b><i>a</i>-<b>111</b><i>f, </i>respectively (collectively <b>111</b>), of various radii, and a management computer network <b>115</b>, configured in a central or distributed processing configuration, coupled to the local monitors <b>110</b> via a local communication link <b>117</b>. For the local monitor to communicate with the management computer network <b>115</b>, communication equipment (see, FIG. 2, units <b>230</b><i>a</i>-<b>230</b><i>c</i>) is utilized.

[0049] The local monitors <b>110</b> may be coupled to the management computer network <b>115</b> as shown by the local monitor <b>110</b><i>a, </i>or indirectly through a local, supervisory computer (not shown) operating as a monitor to the management computer network <b>115</b>. The cells <b>111</b> of the local monitors <b>110</b> may overlap (as shown by the cells <b>111</b><i>d</i>-<b>111</b><i>f</i>) or not (as shown by the cells <b>111</b><i>b</i>-<b>111</b><i>c</i>) depending on the particular business needs and the space to be monitored. When more than one local monitor <b>110</b> is utilized, they may be positioned to cover a larger and/or more asymmetric service area as defined by the particular needs of the business. For example, a multiple cell <b>111</b> structure may be designed to cover all the areas of a manufacturing facility that might be visited by a forklift <b>105</b>, including both permissible and prohibited areas for a particular forklift operator.

[0050] The local monitors <b>110</b> have the ability to use directional antennas, as understood in the art, and/or dynamically change coverage range to cover certain areas. To dynamically change coverage range, the local monitors <b>110</b> may be software controlled to adjust transmission power. In one embodiment, a variable attenuator may be utilized to reduce the amount of output power from a local monitor. The adjustment of coverage range may be utilized to further refine the location of assets. In another embodiment, a local monitor near a door, such as a warehouse loading dock door, may be configured to have a limited communication range for the immediate area in front of the door.

[0051] It should be understood that the wireless architecture between the management computer network <b>115</b> and the local monitors <b>110</b> vary depending on the type of asset being managed for a specific business need. The local monitors <b>110</b> also have data processing and storage capability along with its wireless communication equipment. The local monitors <b>110</b> may also be coupled via a network communication link <b>118</b> to other networks (not shown) such as, for example, the Internet to a webserver <b>119</b> or wireless local area network. The webserver <b>119</b> may be accessed by a customer renting a vehicle or a manager of certain databases in the asset management system to inspect parameters and operating conditions of the system.

[0052] The robust wireless communications system <b>100</b><i>a </i>also includes asset communicators <b>120</b><i>a</i>-<b>120</b><i>d </i>(collectively <b>120</b>), each one associated with a specific asset, and in this embodiment, a forklift <b>105</b><i>a</i>-<b>105</b><i>d, </i>respectively, for communicating with the local monitors <b>120</b> via their associated asset communication links <b>130</b><i>a</i>-<b>130</b><i>d </i>(collectively <b>130</b>), respectively. The asset communication links <b>130</b> may be any form of wireless communication link including, without limitation, cellular, radio frequency (RF) (possibly including adjustable range), wireless Ethernet (i.e., the 802.11b wireless communication standard), paging, satellite, or a combination of any of the foregoing. The asset communicators <b>120</b> also have data processing and storage capability along with their wireless communication equipment.

[0053] In operation, the asset communicators <b>120</b> become active for uplinking or downlinking data when it comes within the range of the cell <b>111</b> of one of the local monitors <b>110</b> to establish the corresponding asset communication link <b>130</b> with the local monitor <b>110</b>. The establishment of the asset communication links <b>130</b> is independent of the local communication link <b>117</b> for any of the local monitors <b>110</b>. Each asset communicator (i) identifies the local monitor(s) <b>110</b> in communication therewith and (ii) determines what, when, and how often to communicate. To identify the local monitor(s) <b>110</b>, the asset communicator <b>120</b> receives identifier(s) associated with the local monitor(s) <b>110</b> and determines the available communication link(s) <b>130</b>. The data being communicated is dependent on the business problems currently being performed by the asset communicators <b>110</b>. When and how often to communicate the data may be determined by current operating conditions and/or predetermined rules and system parameters.

[0054] Data is uplinked or downlinked between one of the asset communicators <b>120</b> and one of the local monitors <b>110</b> only when the corresponding forklift <b>105</b> moves within the range of the cell <b>111</b> of that local monitor <b>110</b>. For example, when a first forklift <b>105</b><i>a </i>moves within the range of the cell <b>111</b><i>b, </i>the asset communication link <b>130</b><i>a </i>is established between the asset communicator <b>120</b><i>a </i>and the local monitor <b>110</b><i>b, </i>whereupon data stored on either one of the devices can be uplinked to, or downlinked from, the other device. A second forklift <b>105</b><i>b </i>might move within the range of the same cell <b>111</b><i>b </i>to establish a similar asset communication link <b>130</b><i>b </i>between its asset communicator <b>120</b><i>b </i>and the same local monitor <b>110</b><i>b. </i>A third forklift <b>105</b><i>d </i>might move within the range of the cell <b>111</b><i>f </i>to establish a first asset communication link <b>130</b><i>d </i>between its asset communicator <b>120</b><i>d </i>and the local monitor <b>110</b><i>f, </i>and then move out-of-range into the range of the cell <b>111</b><i>e </i>as shown by the arrow <b>131</b> to establish a second asset communication link <b>130</b><i>d′</i> at a later time between the asset communicator <b>120</b><i>d′</i> and a second local monitor <b>110</b><i>e. </i>An asset communicator <b>120</b><i>b </i>may have multiple links open simultaneously with different local monitors <b>110</b>, and use the best communication link for both uplink and downlink communications.

[0055] Referring more specifically to the example of a forklift operator above, in the robust wireless communications system <b>100</b><i>a </i>may be a multi-cell system as just described including a database that permits a specific forklift operator to be operating the forklift <b>105</b><i>d </i>in an area covered by the local monitor <b>110</b><i>f, </i>but prohibits the same operator from driving that forklift to another area covered by the local monitor <b>110</b><i>e. </i>This part of the database is stored by the asset communicator <b>120</b><i>d </i>setting forth the permissible and prohibited areas of operation for that operator as soon as she identifies herself by logging-in to start the forklift <b>105</b><i>d. </i>If she drives the forklift <b>105</b><i>d </i>into the range of the cell <b>111</b><i>e, </i>the asset communicator <b>120</b><i>d′</i> may determine its communication link status and communicate the presence and identification of both the forklift and the operator to the local monitor <b>110</b><i>e </i>via the asset communication link <b>130</b><i>d′</i>. The asset communicator <b>120</b><i>d′</i> may take active measures to alert the operator of the location violation and/or disable the forklift. Alternatively or additionally, the data would then be stored in the memory of local monitor <b>110</b><i>e </i>and processed to alert the operator of the violation, shut down the forklift <b>105</b><i>d′</i>, and/or notify a supervisor of the breach by uplinking the data from the local monitor <b>110</b><i>e </i>to the management computer network <b>115</b> via the local communication link (not shown), but only when that local communication link is established. As indicated above, the establishment of the asset communication links <b>130</b> is independent of the local communication link <b>117</b> to the management computer network <b>115</b>. For example, the database could have been updated by the management computer network <b>115</b> to update the database on the local monitor <b>110</b><i>e, </i>but not the asset communicator <b>120</b><i>d, </i>authorizing the operator to be in the area covered by the cell <b>111</b><i>e </i>before the operator entered that area. Upon entering this area, the local monitor <b>110</b><i>e </i>would update the asset communicator <b>120</b><i>d′</i> so that it would not transmit a breach signal to the local monitor <b>110</b><i>e. </i>

[0056]FIG. 2 is a more detailed block diagram of the robust wireless communications system of FIG. 1. The robust wireless communications system <b>100</b><i>c </i>includes the management computer network <b>115</b>, wireless infrastructure <b>202</b>, and asset communicator <b>120</b>. The management computer network <b>115</b> includes a supervisor interface <b>205</b>, database engine <b>210</b>, middleware <b>215</b>, and system administrator interface <b>220</b>. The supervisor interface <b>205</b> is operable to provide a supervisor (e.g., a user or an external computing system operable to perform supervisory functions) of the management computer network <b>115</b> the capability to view data or update data (i.e., create new data, edit existing data, and/or delete existing data) stored in a database. For example, a supervisory user (i.e., supervisor) may use the supervisor interface <b>205</b> to view an asset location report stored in the database, and a supervisory computing device may automatically update a list of employees stored in the database. The database engine <b>210</b> may be any software operable to manage data stored in the database. For example, the database engine <b>210</b> may be a commercial (e.g., Oracles) or non-commercial database engine. The middleware <b>215</b> is software and/or hardware operable to provide communication between the database engine <b>210</b> and wireless infrastructure <b>202</b>. The middleware <b>215</b> may also provide other management or functional operations as understood in the art. The system administrator interface <b>220</b> provides a system administrator the ability to perform a variety of functions in direct communication with the middleware via a communication link <b>222</b>. One function that may be performed by the system administrator interface <b>220</b> includes altering the communication range of one or more local monitors <b>110</b>.

[0057] The wireless infrastructure <b>202</b> includes at least one wireless infrastructure unit <b>225</b>. The wireless infrastructure unit <b>225</b> includes a local monitor <b>110</b>, at least one of which is coupled to a wired communication unit <b>230</b><i>a, </i>a wireless communication unit <b>230</b><i>b </i>(e.g. cellular or wireless LAN), and/or a satellite communication unit <b>230</b><i>c </i>(collectively <b>230</b>) that communicates with the middleware <b>215</b> via the local communication link <b>117</b>. The local monitor <b>110</b> includes a processor for operating a database engine <b>242</b>, which may be the same or similar to the database engine <b>210</b> of the management computer network <b>115</b>, and other software (not shown) that performs specific business functions. The wireless infrastructure unit <b>225</b> further includes a radio frequency (RF) wireless unit <b>235</b>. The RF wireless unit <b>235</b> may include hardware and software for performing wireless communications utilizing any wireless protocol as understood in the art. For example, a wireless Ethernet standard may be utilized by the wireless infrastructure unit <b>225</b> to communicate with the asset communicators <b>120</b> via the asset communication link <b>130</b><i>a. </i>A local monitor <b>110</b><i>a </i>may communicate with another local monitor <b>110</b><i>b </i>via the respective RF wireless units <b>235</b>. Although the local monitor <b>110</b> is shown to be coupled to the communication units <b>230</b> and RF wireless unit <b>235</b>, an alternative embodiment of the local monitor <b>110</b> may include either or both units <b>230</b> and <b>235</b> in the same physical box.

[0058] The asset communicator <b>120</b> includes an RF wireless unit <b>245</b> for communicating with the RF wireless unit <b>235</b> of the wireless infrastructure unit <b>225</b>. Additionally, the asset communicator may include a wired unit (not shown) for direct wire communication with a portable computing system, for example, for downloading to or uploading from the asset communicator <b>120</b>. The asset communicator <b>120</b> further includes a database engine <b>250</b> operable to manage data being collected or received by the asset communicator <b>120</b>. The asset communicator <b>120</b> also contains a computer program on-board to determine what, when, where, and how often to communicate as previously discussed.

[0059] Both the asset communicators <b>120</b> and the wireless infrastructure units <b>225</b> may be considered embedded systems, where an embedded system is defined as a combination of hardware and software that together form a component of a larger system. An example of an embedded system is a microprocessor that controls an automobile engine. Embedded systems are designed to execute without human intervention, and may be required to respond to events in real-time.

[0060] The asset communicator <b>120</b> is coupled to the wireless infrastructure <b>202</b> via the asset communication link <b>130</b><i>a </i>(link A). The wireless infrastructure <b>202</b> is coupled to the management computer network <b>115</b> via the local communications link <b>117</b> (link B). The middleware <b>215</b> is coupled to the database engine <b>210</b> via a communication link <b>255</b> (link C). The database engine <b>210</b> is coupled to the supervisor interface <b>205</b> via a communication link <b>260</b> (link D).

[0061] Traditionally, mobile wireless devices, such as asset communicators, are capable of performing their intended operation by having communication links A, B, and C simultaneously operating. The principles of the present invention, however, allow for the asset communicators <b>120</b> to operate autonomously without having links A, B, and/or C simultaneously operating. As previously discussed, the asset communicator <b>120</b> and wireless infrastructure unit <b>225</b> are intelligent in that they are capable of performing decisions that traditionally only the management computer network <b>115</b> performed.

[0062]FIG. 3 is another exemplary block diagram of the robust wireless communications system of FIGS. 1 and 2. The management computer network <b>115</b> includes a management computing system <b>302</b> having a processor <b>304</b> coupled to a memory <b>306</b>, I/O device <b>308</b> and storage device <b>310</b>. The storage device <b>310</b> may include one or more databases <b>312</b><i>a, </i><b>314</b><i>a, </i>and <b>316</b><i>a, </i>for example. The databases <b>312</b><i>a</i>-<b>316</b><i>a </i>may be used to store various data associated with performing asset management. The databases may operate as relational databases in that each database may have corresponding or associated data elements with one or more other databases. For example, multiple databases may have a vehicle number so that any data associated with the vehicle number in either database may be related utilizing the database engine <b>210</b>.

[0063] The management computing system <b>302</b> may further be coupled to the supervisor interface <b>205</b> via the communication link <b>260</b> (link D), and the system administrator interface <b>220</b> via the communication link <b>222</b>. The supervisor interface <b>205</b> and system administrator interface <b>220</b> may be utilized to interact with the management computing system to modify and view the data stored in the databases <b>312</b><i>a</i>-<b>316</b><i>a. </i>The supervisor <b>205</b> and system administrator <b>220</b> interfaces may utilize the same processor <b>304</b> as the management computing system <b>302</b>.

[0064] The processor <b>304</b> may execute the database engine <b>210</b> and middleware <b>215</b>. Alternatively, the database engine <b>210</b> may be executed on a different processor in conjunction with the storage device <b>310</b>. In that regard, the storage device <b>310</b> may be external from the management computing system <b>302</b> and be formed of one or more storage devices. The storage devices <b>310</b> may be a magnetic and/or optical disk, or be of another memory device type, such as random access memory.

[0065] The management computing system <b>302</b> may further be coupled by the local communication link <b>117</b>, which includes communication link <b>117</b><i>a, </i>network <b>117</b><i>b </i>(e.g., the Internet), and communication link <b>117</b><i>c. </i>The webserver <b>119</b> may be coupled to the network <b>117</b><i>b </i>via the network communication link <b>118</b>. The wireless infrastructure <b>202</b><i>a </i>may be coupled to the network <b>117</b><i>b </i>via communication link <b>117</b><i>c, </i>and include a local monitor <b>110</b> that includes a processor <b>318</b> coupled to a memory <b>320</b>, I/O unit <b>322</b>, and storage device <b>324</b>. The storage device may be internal or external from the local monitor <b>110</b>, and be utilized to store databases <b>312</b><i>b, </i><b>314</b><i>b, </i>and <b>316</b><i>b. </i>The databases <b>312</b><i>b</i>-<b>316</b><i>b </i>may be replicated from the databases <b>312</b><i>a</i>-<b>316</b><i>a. </i>The processor <b>318</b> may execute the local monitor database engine <b>242</b> that operates to maintain the replicated databases <b>312</b><i>b</i>-<b>316</b><i>b. </i>As indicated by the dashed lines, the local monitor may be maintained in a facility <b>326</b> that the operator of the facility utilizes to perform asset management for mobile and/or fixed assets.

[0066] The local monitor <b>110</b> may be coupled to the RF wireless unit <b>235</b> via a wired or wireless communication link (not shown), thereby forming a wireless infrastructure unit <b>225</b><i>a. </i>A second wireless infrastructure unit <b>225</b><i>b </i>formed of a local monitor <b>110</b> and RF wireless unit is also utilized to communicate with assets <b>105</b> on the premises. The wireless infrastructure units <b>225</b><i>a </i>and <b>225</b><i>b </i>communicate with asset communicators <b>120</b><i>g </i>and <b>120</b><i>h </i>associated with mobile assets <b>105</b><i>g </i>and <b>105</b><i>h </i>(e.g., forklifts).

[0067] The asset communicator <b>120</b><i>g </i>includes the RF wireless unit <b>245</b> coupled to a processor <b>328</b>. The processor <b>328</b> may further be coupled to a memory device <b>330</b>, keypad <b>332</b>, display <b>333</b>, and input/output (I/O) unit <b>334</b>. The memory <b>330</b> may be random access memory, flash memory, or programmable read-only memory as understood in the art. Alternatively, the memory <b>330</b> may be a magnetic or optical disk. The memory <b>330</b> may be operable to store databases <b>312</b><i>c, </i><b>314</b><i>c, </i>and <b>316</b><i>c. </i>

[0068] The I/O unit <b>334</b> may include receiving and/or transmitting devices, and be coupled to power, sensors, or other input and output devices (not shown). The I/O unit <b>334</b> of the asset communicator <b>120</b> may receive power from a power source, such as a battery, located on the asset <b>105</b> or from a battery coupled to the asset communicator <b>120</b>. The decision as to whether to receive power from an internal (e.g., battery of asset communicator <b>120</b>) and/or external power source (e.g., battery of asset <b>105</b>, wall power, etc.) may be based on the application that the asset communicator is being utilized. For example, if the asset communicator <b>120</b> is being used for tracking a forklift, it may be appropriate to draw power from the forklift. If, however, the asset communicator <b>120</b> is being used for tracking a parcel, then a battery of the asset communicator <b>120</b> is used to provide power as, in general, a parcel does not have a battery. It should be understood that a battery may be included with the asset communicator <b>120</b> and be utilized as a backup power supply as understood in the art upon the asset communicator <b>120</b> losing power from the asset <b>105</b>. The sensors may include temperature, current, voltage, impact, motion, pressure, weight, or any other such electronic sensors. Input devices may include barcode scanners, proximity card readers, magnetic card readers, and other biometric reading devices. The output devices may include relays, switches, lights, sirens, horns, or any other electronic output device. The RF wireless unit <b>245</b> may further be coupled to an antenna <b>336</b>.

[0069] The size, structure, and configuration of the asset communicator <b>120</b> may be dependent upon the environment and asset <b>105</b> that the asset communicator <b>120</b> is associated. For example, if the asset communicator <b>120</b> is utilized in an industrial or outdoor environment, then a heavy duty housing being substantially water resistant may be used. If, however, the asset communicator <b>120</b> is utilized to perform parcel tracking, then the size, weight, thickness, and flexibility, for example, is an issue. In such a case, the asset communicator <b>120</b> may be constructed of multiple circuit boards. In one embodiment, three circuit boards having minimal dimensions (e.g., one-by-two inches) may be coplanar and coupled via a flexible, flat cable and/or circuitry having transmission lines for communicating data between the circuit boards. By using the flexible, flat cable, the asset communicator <b>120</b> is capable of being bent without breaking during shipping of the parcel. Additionally, the circuitry on the circuit boards may be coated with a durable, compressible material, such as rubber, to prevent damage to the circuitry and to reduce stresses on the circuit boards during shipping of the parcel. A battery may further be coupled to the asset communicator <b>120</b> via the cable to provide power to the circuit board and allow for replacement. It should be understood that while the size, structure, and configuration of the asset communicator may vary, the functionality of the asset communicator <b>120</b> remains substantially the same.

[0070] In operation, the management computing system <b>302</b> may operate as a central computing system for the robust wireless communications system <b>100</b><i>c. </i>An operator of the supervisor interface <b>205</b> may view or update (i.e., create, edit, or delete) information or data stored in the database(s) <b>312</b><i>a</i>-<b>316</b><i>a </i>utilizing the database engine <b>210</b>. For each addition, edit, or deletion, a transaction code (see FIG. 4) is associated with the data, thereby forming a data record or dataset, which is stored in a database <b>312</b><i>a, </i>for example. The management computing system <b>302</b>, utilizing the database engine <b>210</b> and middleware <b>215</b>, communicates the data stored in the database <b>312</b><i>a </i>utilizing the I/O unit <b>308</b> in data packets <b>338</b><i>a</i>-<b>338</b><i>b </i>over the network <b>117</b><i>b </i>to specified local monitors <b>110</b> based on business functions being performed and current communication links. For example, a text message may be transmitted to only the local monitor <b>110</b> in communication with the asset communicator <b>105</b><i>g </i>as determined by the middleware <b>215</b> in conjunction with the database engine <b>210</b>. As another example, a broadcast text message may be transmitted to all local monitors <b>110</b> servicing asset communicators <b>120</b>.

[0071] The local monitor <b>110</b>, utilizing the database engine <b>240</b>, stores the data in the database <b>312</b><i>b, </i>if necessary, to replicate the database <b>312</b><i>a. </i>By replicating the database <b>312</b><i>a </i>in the local monitor <b>110</b>, it is possible for the local communication link <b>117</b> to fail and the local monitor <b>110</b> to operate independently. The data stored in the local monitor <b>110</b> may thereafter be transmitted or broadcast the data temporally to the asset communicators <b>120</b><i>g </i>and <b>120</b><i>h </i>operating in the range of the RF wireless units <b>235</b><i>a </i>and/or <b>235</b><i>b. </i>While the local monitor <b>110</b> is storing the data for further communication, the local monitor <b>110</b> may determine that the data becomes obsolete before communicating the data to asset communicator(s) <b>120</b>. Such a situation may occur upon (i) the data becoming expired or out-of-date (e.g., notification for scheduled maintenance becoming past due), (ii) the data being superseded by newer data (e.g., work instructions being modified by the supervisor), or the data becoming irrelevant (e.g., text message having utility for a duration of five minutes), for example. If the data becomes obsolete, the local monitor <b>110</b> may simply not communicate and/or delete the data being stored therein.

[0072] An asset communicator <b>120</b><i>g </i>that receives the data via data packets <b>338</b><i>a</i>-<b>338</b><i>b </i>may determine that the data is associated with the particular asset communicator <b>120</b> by identification of a data field, and store the data in a database <b>312</b><i>c. </i>The database <b>312</b><i>c </i>is a subset of the data stored in the databases <b>312</b><i>a </i>and <b>312</b><i>b. </i>In other words, the data stored by the management computing system <b>302</b> is communicated to the local monitor <b>110</b>, stored therein for an indefinite period of time, and transmitted from the local monitor <b>110</b> to all asset communicators <b>120</b> in range thereof, if needed. The asset communicators <b>120</b> are intelligent and capable of parsing the received data to determine the data associated therewith. Therefore, the databases <b>312</b><i>c</i>-<b>316</b><i>c </i>are subsets of the databases <b>312</b><i>a</i>-<b>316</b><i>a </i>and <b>312</b><i>b</i>-<b>316</b><i>b. </i>It should be understood that each asset communicator <b>120</b> may receive and store data in similarly configured databases.

[0073]FIG. 4 is an exemplary interaction diagram <b>400</b> for performing downlink and uplink communications between components of the robust wireless communications system of FIG. 3. The three associated databases <b>312</b><i>a, </i><b>312</b><i>b, </i>and <b>312</b><i>c </i>are indicated by the vertical lines. Additionally, time increases down the vertical lines. Data communicated between the computer system database <b>312</b><i>a </i>and local monitor database <b>312</b><i>b </i>in the downlink direction is transmitted over the local communication link <b>117</b>. The data is communicated in a data packet <b>338</b>, which may include control data <b>402</b><i>a </i>and data <b>404</b><i>a </i>and datasets stored in the databases <b>312</b><i>a</i>-<b>316</b><i>a, </i>for example. The data <b>404</b><i>a </i>includes a transaction code (TC₁) <b>406</b><i>a. </i>As understood in the art, the control data <b>402</b><i>a </i>is associated with data communicated via data packets <b>338</b> as part of a data communication protocol. Acknowledgement packets <b>407</b> may be used to ensure that the downlink data is successfully replicated as determined by the local monitors <b>110</b> utilizing a checksum or other data verification technique as understood in the art. The acknowledgement <b>407</b> may occur upon completion of all data being transmitted from the computer system database <b>312</b><i>a </i>to the local monitor database <b>312</b><i>b </i>to minimize network bandwidth requirements.

[0074] Upon the data being successfully received by the local monitor database <b>312</b><i>b, </i>the data is stored for an unspecified period of time ΔT_D. At some random or non-random time T₂, the data may be read and transmitted from the local monitor <b>110</b> via data packet <b>338</b><i>x </i>to an area or cell <b>111</b> that the local monitor <b>110</b> services. As indicated, the control data <b>402</b><i>b, </i>data <b>404</b><i>b, </i>and transaction code <b>406</b><i>b </i>may be different than the control data <b>402</b><i>a, </i>data <b>404</b><i>a, </i>and transaction code <b>406</b><i>a </i>due to (i) the time delay between T₁and T₂, and (ii) new data received by the computer system database <b>312</b><i>a </i>not having been transmitted to the local monitor database <b>312</b><i>b. </i>An acknowledgement packet <b>408</b> may be used to confirm the receipt of the data packet <b>338</b><i>x </i>depending upon whether confirmation is desired for a particular business function. For example, if a text message is transmitted to a particular asset communicator <b>120</b><i>g, </i>then the acknowledgement <b>408</b> is desirable. Alternatively, if a broadcast text message is transmitted to all asset communicators <b>120</b>, then an acknowledgement is not necessary. Ultimately, however, the data from the computer system database <b>312</b><i>a </i>is transmitted and may be stored in the asset communicator database <b>312</b><i>c. </i>While the data communicated across the communication links <b>117</b> and <b>130</b> may be transmitted sequentially (i.e., first across the local communication link <b>117</b> and second across the asset communication link <b>132</b>), the data need not be communicated simultaneously across the communication links <b>117</b> and <b>130</b>. Upon the data being received by the asset communicator database <b>312</b><i>c, </i>an acknowledgment <b>408</b> may be communicated back to the local monitor database <b>312</b><i>b, </i>and the data <b>404</b><i>b </i>may be deleted therein. By deleting the data <b>404</b><i>b </i>within the local monitor database <b>312</b><i>b, </i>repetitive transmission of the data <b>404</b><i>b </i>may be eliminated.

[0075] With regard to uplinking, upon the asset communicator <b>120</b> collecting and storing the data in the asset communicator database, the asset communicator <b>120</b> may perform the uplink communication <b>400</b><i>b </i>from the asset communicator database <b>312</b><i>c </i>to the local monitor database <b>312</b><i>b. </i>At T₃, a data packet <b>338</b><i>y, </i>including control data <b>410</b><i>a </i>and data <b>412</b><i>a </i>associated with a transaction code (TC₂) <b>414</b><i>a, </i>is transmitted from the asset communicator database <b>312</b><i>c </i>to the local monitor database <b>312</b><i>b. </i>If there is sufficient storage capacity, the data <b>412</b><i>a </i>is stored by the local monitor database <b>312</b><i>b </i>for an indefinite period of time ΔT_U, and an acknowledgement <b>409</b> is sent to the asset communicator. This time period ΔT_Umay extend for a minimal duration or any duration of time until the local communication link <b>117</b> becomes operational or active. Once the acknowledgement <b>409</b> is received, the asset communicator <b>110</b> may delete the data packet <b>338</b><i>y </i>from its memory. If there is not sufficient storage capacity in the local monitor <b>312</b><i>b, </i>the asset communicator <b>110</b> continues to store or transmit the data <b>338</b><i>y </i>to another local monitor database <b>312</b><i>b. </i>At time T₄, the data <b>412</b><i>b, </i>including transaction code <b>414</b><i>b, </i>is transmitted from the local monitor database <b>312</b><i>b </i>to the computer system database <b>312</b><i>a </i>via data packet <b>338</b><i>z. </i>An acknowledgment <b>416</b> may be communicated back to the local monitor database <b>312</b><i>b </i>from the computer system <b>312</b><i>a </i>so that (i) the local monitor database <b>312</b><i>b </i>does not continue to communicate the data <b>412</b><i>b </i>to the computer system database <b>312</b><i>a, </i>and (ii) the data may be deleted from the local monitor database <b>312</b><i>b. </i>The control data <b>402</b><i>a, </i><b>402</b><i>b, </i><b>410</b><i>a, </i>and <b>410</b><i>b </i>may include authentication and/or encryption data to ensure validity and security of communications to protect confidential information. It should be understood that in both the downlink <b>400</b><i>a </i>and uplink <b>400</b><i>b </i>communications that additional acknowledgment from the local monitor database <b>312</b><i>b </i>may be communicated back to both the computer system database <b>312</b><i>a </i>and the asset communicator database <b>312</b><i>c </i>to notify each to stop communicating the information associated with the particular transaction codes transmitted.

[0076] The communication technique of FIG. 4 is realizable because of the intelligence built into both the local monitor <b>110</b> and asset communicator <b>120</b>. And, because of the communication technique, the robust communications system <b>100</b><i>c </i>is capable of handling and solving many business problems involved in managing assets remotely.

[0077]FIG. 5 is an exemplary interaction diagram <b>500</b> for performing immediate communications between the components of FIG. 3. A downlink communication <b>500</b><i>a </i>and uplink communication <b>500</b><i>b </i>are shown for the paging communications that may be utilized on the robust wireless communications system <b>100</b><i>c. </i>For the downlink communication, at time T₅, a data packet <b>338</b><i>m </i>may be communicated between the computer system database <b>312</b><i>a </i>and local monitor database <b>312</b><i>b, </i>and include control data <b>502</b> and data <b>504</b> associated with transaction code (TC₃) <b>506</b>. Upon the local monitor database <b>312</b><i>b </i>receiving the data packet <b>338</b><i>m, </i>an acknowledgement signal <b>507</b><i>a </i>may be communicated back to the computer system database <b>312</b><i>a </i>for verification purposes. The local monitor database <b>312</b><i>b </i>may operate as a pass-through to the asset communicator database <b>312</b><i>c </i>in the immediate communication mode. Alternatively, the local monitor <b>110</b> may not store the data in the local monitor database <b>312</b><i>b. </i>In other words, there is little or no delay for the data being communicated from the computer system database <b>312</b><i>a </i>to the asset communicator database <b>312</b><i>c. </i>Accordingly, the data communicated from the local monitor database <b>312</b><i>b </i>to the asset communicator database <b>312</b><i>c </i>is the same or substantially similar data packet <b>338</b><i>m </i>including the control data <b>502</b>, data <b>504</b>, and transaction code (TC₃) <b>506</b>. An acknowledgement signal <b>507</b><i>b </i>may be communicated from the asset communicator <b>120</b> back to the local monitor <b>110</b> upon receipt of the data packet <b>338</b><i>m </i>by the asset communicator database <b>312</b><i>c. </i>

[0078] Similarly, the uplink communication <b>500</b><i>b </i>in the immediate communication mode transmits data at time T₆from the asset communicator database <b>312</b><i>c </i>to the computer system database <b>312</b><i>a </i>with a minimal amount of delay via the local monitor database <b>312</b><i>b. </i>The data may be communicated in a data packet <b>338</b><i>n, </i>which includes control data <b>508</b> and data <b>510</b> associated with a transaction code (TC₄) <b>512</b>. The data packet <b>338</b><i>n </i>is thereafter communicated from the local monitor database <b>312</b><i>b </i>to the computer system database <b>312</b><i>a </i>with minimal or no alterations or delay. Acknowledgement signals <b>514</b><i>a </i>and <b>514</b><i>b </i>may be communicated from the local monitor <b>110</b> to the asset communicator <b>120</b> and from the management computing system <b>302</b> to the local monitor <b>110</b>, respectively, upon receipt of the data packets <b>338</b><i>n. </i>As understood in the art, the immediate communication mode may operate similar to conventional wireless data communication techniques as understood in the art utilizing any communication standard thereof.

[0079] Data Synchronization

[0080]FIGS. 6A and 6B are exemplary databases operating in the robust wireless communications system of FIG. 3. FIG. 6A illustrates the downlink functionality of the robust communications system <b>100</b><i>d. </i>As shown, the management computing system <b>302</b> includes the storage device <b>310</b> and databases <b>312</b><i>a, </i><b>314</b><i>a, </i>and <b>316</b><i>a </i>(databases A, B, and C). To indicate the database that a dataset is associated, a transaction type specifier may be included with each dataset. The transaction type specifier (e.g., “collision”, “low battery”, “location”, and “text message response”) may be utilized to differentiate different dataset types communicated to the asset communicator <b>120</b>. The transaction code associated with each dataset may be included to indicate the most up-to-date data from the associated database. The data stored in the databases <b>312</b><i>a</i>-<b>316</b><i>a </i>may be transmitted to the local monitor <b>110</b> while the local communication link <b>117</b> is established. The local monitor <b>110</b> stores the data on the storage device <b>324</b> in databases (A′-C′) <b>312</b><i>b</i>-<b>316</b><i>b. </i>While databases <b>312</b><i>b</i>-<b>316</b><i>b </i>are intended to be replicas of the databases <b>312</b><i>a</i>-<b>316</b><i>a, </i>it may not be possible to have exact replicas at any given point in time due to the local communication link <b>117</b> or other hardware or software failures during operation and/or synchronization of the data between the management computing system <b>302</b> and local monitor <b>110</b>. Additionally, depending on the application and type of data, a complete replication of the databases <b>312</b><i>a </i>and <b>312</b><i>b </i>may not be needed.

[0081] Generally, the local monitor <b>110</b> communicates the data stored in the databases <b>312</b><i>b</i>-<b>316</b><i>b </i>in a broadcast fashion (i.e., without regard to asset communicators <b>120</b> in the broadcast area of the local monitor <b>110</b>). Alternatively, the local monitor <b>110</b> may broadcast to only those asset communicators <b>120</b> that have registered with the local monitor <b>110</b> upon being within broadcast range. However, by broadcasting a data without regard to asset communicators <b>120</b> in the broadcast area, the bandwidth of the broadcast may be increased due to the acknowledgement <b>408</b> not needing to be transmitted and received, and the broadcast process may be simplified. It should be understood that the data communicated via the asset communication link <b>130</b> is made from each of the databases <b>312</b><i>b</i>-<b>316</b><i>b, </i>and may be performed in a temporal order based on transaction codes associated with the datasets stored in the databases <b>312</b><i>b</i>-<b>316</b><i>b. </i>

[0082] Each asset communicator <b>120</b><i>a</i>-<b>120</b><i>c </i>receives the data broadcast from the local monitor <b>110</b>. Each asset communicator <b>120</b><i>a</i>-<b>120</b><i>c </i>parses the data received and stores only the data associated therewith as determined by the contents of the data (e.g., mobile asset identifiers and transaction codes). Once the asset communicator <b>120</b> has received a dataset having a particular transaction code, the asset communicator <b>120</b> does not store a dataset having a transaction code indicating that the dataset is not up-to-date. As shown, the databases <b>312</b><i>c</i>-<b>316</b><i>c </i>are indicated as being databases A″, B″, and C″ to indicate that the data stored in the databases is a subset of the databases (A′-C′) <b>312</b><i>b</i>-<b>316</b><i>b. </i>It should be understood that although the data is indicated as being stored in three databases, other embodiments may use one or other numbers of databases for performing particular functions on the robust wireless communications system <b>100</b><i>d. </i>It should further be understood that the asset communicators <b>120</b> may receive all communicated data from the databases A′, B′, and C′ and store all of the data in databases A″, B″, and C″. However, such a communication technique may be problematic in terms of storage capacity in the asset communicators <b>120</b> depending on the volume of data located in the databases A′, B′, and C′.

[0083]FIG. 6B is the uplink representation for the robust wireless communications system <b>100</b><i>d. </i>As indicated, each asset communicator <b>120</b> forms a database (X) <b>605</b><i>a, </i><b>605</b><i>b, </i>and <b>605</b><i>c. </i>The databases <b>605</b><i>a</i>-<b>605</b><i>c </i>may be utilized for storing location or utilization information particular to each of the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c. </i>A transaction type specifier, transaction code, and asset number, may be included in each dataset. The transaction code may be utilized along with the asset number to form a unique dataset key. The transaction type specifier, again, is utilized to identify the database that the dataset is associated. When the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>are individually in range of the local monitor <b>110</b>, the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>may transmit the data stored in the databases <b>605</b><i>a</i>-<b>605</b><i>c </i>to the local monitor <b>110</b> via the asset communication link <b>130</b>. The data is stored in the database (X′) <b>605</b><i>d. </i>The local monitor <b>110</b> communicates an acknowledgment to the asset communicator <b>120</b><i>a </i>indicating that the data was received by the local monitor <b>110</b>. The asset communicator <b>120</b><i>a </i>thereafter does not continue transmitting that particular dataset associated with the particular transaction code. The data may remain stored on the asset communicator <b>120</b><i>a, </i>but is eventually overwritten with new data or used for future calculations.

[0084] The local monitor <b>110</b> may thereafter transmit the data stored in the database <b>605</b><i>d </i>to the management computing system <b>302</b>. The data may be stored in the database (X″) <b>605</b><i>e </i>via the local communication link <b>117</b>. Although the data is intended to be replicated between databases (X) <b>605</b><i>d </i>and <b>605</b><i>e, </i>due to the local communication link <b>117</b> and the hardware/software operation of the local monitor <b>110</b> and the management computing system <b>302</b>, the databases may not be synchronized at all points in time as the database <b>605</b><i>d </i>continues to receive data from the asset communicators <b>120</b>.

[0085] In the event that the local communication link <b>117</b> becomes disabled, the local monitor <b>110</b> maintains the data stored in the database <b>605</b><i>d </i>without transmitting to the management computing system <b>302</b>. As the database <b>605</b><i>d </i>fills up and eventually becomes full, a message is communicated to the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>in the broadcast area of the local monitor <b>110</b> indicating that the local monitor <b>110</b> may no longer receive data from the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>due to a temporary memory full condition. If any of the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>are within range of another local monitor <b>110</b>, then the data may be transmitted to the other local monitor <b>110</b>. Because the asset communicators <b>120</b><i>a</i>-<b>120</b><i>c </i>are intelligent, the asset communicators may be configured to transmit the data to the local monitor <b>110</b> over incremental periods of time (e.g., 30 seconds, 1 minute, 5 minutes, 30 minutes, etc). And, if the asset communicators <b>120</b> are unable to transmit the data to a local monitor <b>110</b> due to communication problems or simply being out-of-range, the asset communicators <b>120</b> are capable of storing the data for many months due to the ability of the asset communicators <b>120</b> to summarize and consolidate, or purge the data being collected based on business rules. In addition, intelligent wireless communication techniques, such as re-transmissions, frequency hopping, communication back-off (i.e., reducing communication rate based on communication failure), and communication termination also may be used to improve communication link and system-wide communication. Upon an asset communication link <b>130</b> being re-established with the local monitor <b>110</b> by the asset communicators <b>120</b>, all the backlogged data may thereafter be transmitted to the local monitor <b>110</b>.

[0086]FIG. 7 is an exemplary flow diagram for communicating data in the robust wireless communications system of FIG. 3. The process starts at step <b>702</b>. At step <b>704</b>, data associated with an asset is stored in a central location. Updated data may be received at the central location at step <b>706</b>. At step <b>708</b>, an identifier is applied to the updated data to form a dataset. At step <b>710</b>, the dataset may be stored at the central location.

[0087] The central location may transmit the dataset to a distribution channel via a first communication link at step <b>712</b>. At step <b>714</b>, the dataset is stored along the distribution channel. At step <b>716</b>, the dataset is transmitted to the asset via a second communication channel independent of the first communication link being simultaneously established. The process ends at step <b>718</b>.

[0088]FIG. 8 is another exemplary flow diagram <b>800</b> for communicating data in the robust wireless communications system of FIG. 3. The process starts at step <b>802</b>. At step <b>804</b>, sets of data are stored temporally by a computing system. At step <b>806</b>, the most recent set of data communicated to a wireless infrastructure is determined. One method to determine the most recent set of data communicated (and stored) is to transmit a query to the wireless infrastructure <b>202</b>. Based on the most recent set of communicated data, more recently stored data by the computing system is determined at step <b>808</b>. At step <b>810</b>, the more recently stored data is communicated to the wireless infrastructure <b>202</b>. At step <b>812</b>, the communicated data is stored in the wireless infrastructure <b>202</b>. The process ends at step <b>814</b>.

[0089]FIGS. 9A and 9B (collectively FIG. 9) illustrate exemplary flow diagrams <b>900</b><i>a </i>and <b>900</b><i>b </i>for performing uplink communication on the robust wireless communications system of FIGS. 3 and 6B. The process starts at step <b>902</b>. At step <b>904</b>, data associated with an asset <b>105</b> is received by an asset communicator <b>120</b>. The data may be measured by sensors located on the asset <b>105</b> or may be data entered by an operator of the asset communicator <b>120</b>. The data may also include location data or data created through the receipt of wireless data. At step <b>906</b>, an identifier, such as a transaction code, is applied to the data. The identifier may be temporal in relation to identifiers associated or applied to other data received by the asset communicator <b>120</b>. The identifier may be a transaction code having an indicator associated with the asset communicator <b>120</b>. At step <b>908</b>, the data and identifier are stored as a dataset.

[0090] At step <b>910</b>, a determination is made as to whether a wireless link is established between the asset communicator <b>120</b> and wireless infrastructure <b>202</b>. If an asset communication link <b>130</b> is currently established between the asset communicator <b>120</b> and the wireless infrastructure <b>202</b>, then the dataset is transmitted to the wireless infrastructure <b>202</b> at step <b>912</b>. Otherwise, the process returns to step <b>904</b>, and the asset communicator <b>120</b> continues to receive and collect data associated with the asset <b>105</b> by the asset communicator <b>120</b>. At step <b>914</b>, the asset communicator receives an acknowledgment that the dataset was received by the wireless infrastructure <b>202</b>, and the asset communicator discontinues transmitting the dataset at step <b>916</b>.

[0091] At step <b>918</b>, a determination is made as to whether a local communication link is established between the wireless infrastructure <b>202</b> and a management computing system <b>302</b>. If a local communication link <b>117</b> is established, and, if the dataset must be transmitted to the management computing system, then the dataset is transmitted from the wireless infrastructure unit <b>225</b> to the management computing system <b>302</b> at step <b>920</b>. Otherwise, the data is stored or maintained by the wireless infrastructure <b>202</b> until the local communication link <b>117</b> is re-established. The process ends at step <b>922</b>.

[0092] Asset Management Applications Utilizing Robust Wireless Communications System Architecture

[0093] The following applications to provide various asset management functions utilize the robust wireless communications system as discussed hereinabove. Depending upon the particular application and business problem being solved, the communication techniques of FIGS. 4 and 5 are utilized to communicate data within the system.

[0094] Relational Database Configuration

[0095]FIG. 10 is a graphical representation <b>1000</b> of entities associated with a robust wireless communications system based on that of <b>100</b><i>c </i>of FIG. 3, and relational databases associated therewith. The information associated with the entities are utilized to provide access control and authorization for operators to utilize the assets <b>105</b>. Four entities, including vehicles <b>1005</b>, operators <b>1010</b>, groups <b>1015</b>, and authorizations <b>1020</b> are linked together by relational databases (V, O, G). A vehicle (V) database links the vehicle <b>1005</b> and group <b>1015</b> entities. An operator (O) database links the operator <b>1010</b> and group <b>1015</b> entitles. And, a group (G) database links the authorization <b>1020</b> and group <b>1015</b> entities. Each of these databases (i.e., V, O, and G) may be generated and maintained in the management computer network <b>1005</b> by a supervisor utilizing the supervisor interface <b>205</b>. As understood in the art, each of the databases includes information associated with the particular entities of which the databases are associated.

[0096] TABLES 1, 2, and 3 hereinafter provide exemplary information stored in the vehicle, operator, and group databases, respectively. As shown in TABLE 1, each dataset includes a transaction code, group identification (ID), and vehicle number. For each dataset, the transaction code is incremented based on the number of updates to the vehicle database. The group identifier associated with a particular vehicle is indicative of a particular group of operators or employees who have access rights to operate the vehicle. For example, a group may be defined as a shipping department or group identified with a head of a department. For example, vehicle number “372A7C” may be operated by any member associated with the group “A4”, which may represent the shipping department. As indicated by the asterisk behind each vehicle number, the vehicle number information is not stored in the asset communicator databases <b>312</b><i>c, </i>for example, as the vehicles need not utilize such information. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Vehicle Information</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91PT" align="center" /><colspec colname="2" colwidth="35PT" align="center" /><colspec colname="3" colwidth="91PT" align="center" /><tbody valign="top"><row><entry>Transaction Code</entry><entry>Group ID</entry><entry>Vehicle Number</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>0173842</entry><entry>A4</entry><entry>372A7C*</entry></row><row><entry>0173843</entry><entry>A4</entry><entry>382B2G*</entry></row><row><entry>0173844</entry><entry>A5</entry><entry>382B2G*</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry namest="1" nameend="3" align="left"><!--footnotes removed--></entry></row></tbody></tgroup></table></tables>

[0097] TABLE 2 includes datasets having operator (employee) number, password/PIN, and group ID data elements. As indicated, the group ID's match the group ID's provided in the vehicle database of TABLE 1. For example, group “A5” is associated with operator number “00050” has a password of “871734”. As indicated in TABLE 1, operator “00050” may have access to vehicle “382B2G”. Each dataset stored in the operator database also includes a transaction code. As shown, the transaction codes for the operator database are independent of the transaction codes for the vehicle database (TABLE 1). <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Operator Information</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="35PT" align="center" /><colspec colname="4" colwidth="56PT" align="center" /><tbody valign="top"><row><entry /><entry /><entry>Operator</entry><entry /><entry /></row><row><entry /><entry>Transaction</entry><entry>(Employee)</entry><entry>Password/</entry></row><row><entry /><entry>Code</entry><entry>Number</entry><entry>PIN</entry><entry>Group ID</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>0024187</entry><entry>03421</entry><entry>781242</entry><entry>A4</entry></row><row><entry /><entry>0024188</entry><entry>00050</entry><entry>871734</entry><entry>A5</entry></row><row><entry /><entry>0024189</entry><entry>00279</entry><entry>473892</entry><entry>A4</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0098] TABLE 3 is the group database that provides authorization based on various parameters for the groups to utilize the vehicles associated therewith. The group database includes group ID (to provide relation to TABLES 1 and 2), days, times, and locations. Again, a transaction code is associated with each dataset for synchronization purposes within the different databases (e.g., databases <b>312</b><i>a, </i><b>312</b><i>b, </i>and <b>312</b><i>c</i>). As shown, members of group “A4” are authorized to operate vehicles between Monday and Friday during the hours of 8:00 a.m. to 5:00 p.m., (i.e., 0800-1700) in locations “L8” and “L17”. It should be understood that while multiple databases may be utilized to form relations between the data (e.g., group information database provides a relationship between the operator and vehicle information databases), that less-relational databases (e.g., each operator and vehicle pair may be stored in one database) may be utilized to perform the same or similar functionality. However, the use of relational databases allows the system to (i) limit the amount of data communicated across the communication links <b>117</b> and <b>130</b>, and (ii) simplify the process of associating vehicles and operators. For example, if a new vehicle is added to a fleet of vehicles, then the supervisor may simply add the vehicle to a group rather than having to assign individual operators to the vehicle directly. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 3</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Group Information</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="84PT" align="left" /><colspec colname="1" colwidth="133PT" align="center" /><tbody valign="top"><row><entry /><entry>Authorization</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="42PT" align="center" /><colspec colname="3" colwidth="35PT" align="left" /><colspec colname="4" colwidth="49PT" align="center" /><colspec colname="5" colwidth="49PT" align="left" /><tbody valign="top"><row><entry>Code</entry><entry>Group ID</entry><entry>Days</entry><entry>Times</entry><entry>Locations</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>0047184</entry><entry>A4</entry><entry>Mon-Fri</entry><entry>0800-1700</entry><entry>L8, L17</entry></row><row><entry>0047185</entry><entry>A5</entry><entry>Mon-Sat</entry><entry>1500-2300</entry><entry>L9, L17, L20</entry></row><row><entry>0047186</entry><entry>A6</entry><entry>Sun-Thu</entry><entry>2300-0700</entry><entry>L3, L8, L19</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0099] The information stored in the databases may be generated, edited, and/or deleted by an operator of the supervisor interface <b>205</b>, and may be maintained by the database engine <b>210</b>. For each creation, edit, and deletion, a transaction code may be assigned thereto. Alternatively, a time-stamp may be assigned to the information. However, by utilizing a transaction code, memory requirements may be reduced. The databases may be maintained separately or integrated into a single database as understood in the art. The datasets stored in the databases are thereafter downloaded from the management computer network <b>115</b> to the wireless infrastructure unit <b>225</b> and, ultimately, the asset communicators <b>120</b> as discussed with regard FIGS. 3 and 6A.

[0100] The asset communicators <b>120</b> in the cell <b>111</b> of the local monitor <b>110</b> of the wireless infrastructure unit <b>225</b> receive each dataset that is transmitted from the wireless infrastructure unit <b>225</b>. However, the asset communicators <b>120</b> parse the datasets received from the wireless infrastructure <b>120</b> based on vehicle number, as understood in the art. For example, from the vehicle database (TABLE 1), vehicle number “372A7C” receives the information associated with transaction code “0173842” having a group identifier of “A4”. Any data record thereafter received being associated with group identifier “A4” is received and stored and/or updated by the vehicle “372A7C”. For example, from the operator database (TABLE 2), transactions “0024187” and “0024189”, and information associated therewith are stored by the asset communicator <b>120</b>. Additionally, from the group database (TABLE 3), the dataset having transaction code “0047184” is stored and/or updated in the asset communicator <b>120</b>.

[0101] Once the asset communicators are updated by the datasets received, operators of the assets <b>105</b> may only access the asset communicators <b>120</b> and utilize the vehicles associated therewith by having their operator number and password accepted by the asset communicator <b>120</b>. In other words, a potential operator unauthorized to access the asset <b>105</b> is unable to start the asset <b>105</b> if not authorized by a supervisor of the asset <b>105</b> by downloading access data to the asset <b>105</b> to provide access rights for the potential operator.

[0102] Because the asset communicator <b>120</b> is intelligent and unrequired to have access to the management computer network <b>115</b>, an asset <b>105</b> that does not have a communication link to the wireless infrastructure unit <b>225</b> and management computer network <b>115</b> still is operable by an operator. Therefore, the utilization of the assets <b>105</b> is unaffected by communication outages and out-of-range situations for the assets <b>105</b> to be operated. Thus, a robust wireless communication and asset management system is provided.

[0103] Also, since the intelligent asset communicator <b>120</b> may have a user interface, including a keypad <b>332</b> and display <b>333</b>, an authorized operator can directly modify the authorization database stored on the asset communicator using the keypad and display. For example, an authorized operator may permit another operator to use the asset <b>105</b> by typing the identification number of the other operator directly into the asset communicator <b>120</b>.

[0104] In addition to the access control allowing an operator to turn on the asset, the access control also allows for turning off the asset based on location and time. Because the asset communicator <b>120</b> is intelligent, the asset communicator does not shut down the asset while in use and in motion, for example. Rather, the asset communicator <b>120</b> determines when a “significant” stop has occurred (e.g., the vehicle has stopped for a predetermined period of time), and the asset <b>105</b> is disabled by the asset communicator <b>120</b>.

[0105] In addition to the asset communicator <b>120</b> being capable of taking action based on access control, the asset communicator <b>120</b> and/or wireless infrastructure device <b>225</b> may provide access to unauthorized operators based on business rules. For example, if the asset <b>105</b> becomes out-of-range for an extended period of time, the asset communicator <b>120</b> may provide access to a select number or any operator as the asset communicator <b>120</b> may consider that a communication problem exists (e.g., receiver failure). In the case of the wireless infrastructure device <b>225</b> not receiving communications from the management computing system <b>302</b> over an extended period, the wireless infrastructure device <b>225</b> may discontinue broadcasting data as it may be assumed that some or all of the data stored by the wireless infrastructure device <b>225</b> is invalid.

[0106] To summarize the access control process, FIG. 11 is an exemplary flow diagram for determining and providing authorization of an asset for an operator utilizing the robust wireless communications system of FIGS. 3 and 6A. The process starts at step <b>1102</b>. At step <b>1104</b>, an operator identifier is received via at least one of a variety of input devices, including, but not limited to, a keypad <b>332</b>, card reader, memory chip reader, barcode scanner, wireless receiver, and biometric scanner. It should be understood that a password may also be received depending upon the business and/or security requirements. At step <b>1106</b>, a group identifier associated with the operator identifier is determined utilizing the database(s) stored in the asset communicator <b>120</b>. A determination is made at step <b>1108</b> as to whether the operator is authorized to utilize the asset based on the group identifier. At step <b>1110</b>, a determination is made as to whether authorization to the asset <b>105</b> is granted based on the group, time of day, day of week, and/or location, for example. If authorization is granted, then the process ends at step <b>1112</b>. Otherwise, the process returns to step <b>1104</b> to receive a new operator identifier.

[0107] Distributed Wireless System Behavior Control

[0108] The robust wireless communications system <b>100</b><i>c </i>may have system behavior altered in a distributed manner. The system parameters may be utilized to control a wide variety of functions of the wireless infrastructure unit <b>225</b> and asset communicators <b>120</b>. In general, a generic wireless communications system may be provided to a customer, and the customer may alter the system parameters to customize the system according to desires and needs.

[0109]FIG. 12 is an exemplary flow diagram <b>1200</b> describing altering of system parameters for the robust wireless communications system of FIG. 3. The process starts at step <b>1202</b>. At step <b>1204</b>, the wireless infrastructure unit <b>225</b> receives altered system behavior parameters. The system behavior parameters may include data transmission rates, access control rules, screen behavior, keypad behavior, power modes, and scheduling of communication, for example. The system parameters may be utilized in the wireless infrastructure unit <b>225</b> for communicating to the asset communicators <b>120</b> or may be downloaded to the asset communicators <b>120</b> utilizing the communication technique of FIG. 4 to alter operational behavior. The changes may affect different asset communicators differently, unless a universal command is desired.

[0110] At step <b>1206</b>, an identifier is applied to the altered system behavior parameter(s) to form a dataset. As discussed with regard to the databases, the identifier may be a transaction code utilized to indicate a temporal relationship between edits made to other system behavior parameters. The dataset may be stored in a system behavior parameter database on the management computer network <b>115</b> and downloaded to the wireless infrastructure unit <b>225</b> as discussed hereinabove. At step <b>1208</b>, the dataset is transmitted to the asset communicators <b>120</b> for altering operational behavior of the asset communicator(s) <b>120</b>. It should be understood, however, that the system behavior parameters may be directed toward the wireless infrastructure unit <b>225</b> and not the asset communicators <b>120</b>, and therefore are not communicated to the asset communicators <b>120</b>. The process ends at step <b>1210</b>.

[0111] To alter the system behavior parameters, the system administrator interface <b>220</b> may be utilized rather than the supervisor interface <b>205</b>. By utilizing the system administrator interface <b>220</b>, a system administrator, who does not perform supervisory duties over the assets <b>105</b> or operators, is able to make the changes to the system parameters for controlling functionality of the wireless infrastructure unit <b>225</b> and asset communicators <b>120</b>.

[0112] A general concept that the robust wireless communications system <b>100</b><i>c </i>is capable of providing is the ability to perform actions based on business rules being violated. A supervisor may define business rules that, upon being violated by an asset, operator, supervisor, supervisory computer, for example, trigger one or more events by at least one component of the system. And, because each of the components (e.g., management computing system <b>302</b>, wireless infrastructure device <b>225</b>, and asset communicator <b>120</b>) are capable of making decisions, one or more of the components, individually or in combination, are capable of triggering event(s). For example, if a forklift <b>105</b> enters an unauthorized area of a facility, the associated asset communicator <b>120</b> may (i) shut down the forklift <b>105</b>, and (ii) communicate a message to the wireless infrastructure device <b>225</b>, which, in turn, may command all or some forklifts <b>105</b> in the area to be shut down. Additionally, the message may be received by the management computing system <b>302</b> and a system-wide message may be communicated to some or all asset communicators <b>120</b>. And, because the asset communicator <b>120</b> is capable of making decisions, actions may be taken independent of the communication link <b>130</b> being established. It should be understood that the business rules may be varied depending on the system requirements, business functions being solved, and creativity of the system operators.

[0113] Vehicle Utilization Monitoring

[0114] The robust wireless communications system <b>100</b><i>b </i>provides the ability to perform vehicle utilization monitoring in an event driven manner due to the asset communicators <b>120</b> being intelligent (i.e., having an on-board processor and associated software). Vehicle utilization relates to how the vehicle is utilized as attributed to an operator, for example. Other associated parameters, such as location, shift, etc., may be utilized. TABLE 4 provides an exemplary dataset of utilization parameters for the asset <b>105</b> that are measured using sensors in combination with the asset communicator <b>120</b> and associated software. It should be understood that the parameters are exemplary and that others may be utilized depending on the particular asset associated with the asset communicator <b>120</b>. For example, a fixed asset utilizes different parameters than a mobile asset <b>105</b>, and different mobile asset types may have different parameters. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 4</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Vehicle Utilization Information</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>Segment Number</entry></row><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Vehicle Number</entry></row><row><entry /><entry>Start Time</entry></row><row><entry /><entry>End Time</entry></row><row><entry /><entry>Operator ID</entry></row><row><entry /><entry>Log-out Method</entry></row><row><entry /><entry>Global Motion Time</entry></row><row><entry /><entry>Global Engine Idle Time</entry></row><row><entry /><entry>Session Motion Time</entry></row><row><entry /><entry>Session Lift Time</entry></row><row><entry /><entry>Session Engine Idle Time</entry></row><row><entry /><entry>Session Number of Impacts</entry></row><row><entry /><entry>Current Fuel Level</entry></row><row><entry /><entry>Current Odometer Reading</entry></row><row><entry /><entry>Battery ID</entry></row><row><entry /><entry>Session Number of Starts/Stops</entry></row><row><entry /><entry>Battery Level</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0115] The vehicle utilization monitoring according to the principles of the present invention is event driven. One <b>5</b> embodiment utilizes the events of an operator logging on and logging off of the asset communicator <b>120</b>. FIG. 13 is an exemplary flow diagram <b>1300</b> for the asset communicator to start and stop utilization monitoring as utilized on the robust wireless system of FIGS. 3 and 6B (uplink). The process <b>10</b> starts at step <b>1302</b>. At step <b>1304</b>, an event start is received an operator logging onto the asset communicator <b>120</b>. At step <b>1306</b>, data counters are initialized for the particular operator. The asset communicator <b>120</b> may (i) record lifetime or global counters, such as motion time and engine idle time, for the asset <b>105</b>, and (ii) reset or initialize session counters, such as motion time, lift time, engine idle time, number of impacts, number of starts, and battery level.

[0116] At step <b>1308</b>, data is collected by the asset communicator <b>120</b> for at least the global and session counters. At step <b>1310</b>, the collected data is accumulated. In accumulating the data, both raw data and summary data based on the raw data may be generated. At step <b>1312</b>, a determination may be made as to whether an event stop has occurred. The event stop may be initiated by the operator logging off of the asset communicator <b>120</b>. Alternatively, an event start and stop may be generated by a predetermined time period, such as a 24-hour time period (i.e., at midnight), so as to generate utilization data for each and every time period. Additionally, in the case of the asset communicator <b>120</b> becoming idle, the event start is triggered from a logout and event stop is triggered from a logon. If an event stop has not occurred, then the process continues to collect data at step <b>1308</b>. Otherwise, at step <b>1314</b>, the collected data is stored for the global and/or session counters. As discussed in relation to FIG. 6B, a transaction type specifier and transaction code may be included in the dataset. It should be understood that other information may be collected and stored by the asset communicator <b>120</b> based on the same or different events. At step <b>1316</b>, the stored data may be communicated from the asset communicator <b>120</b> to the wireless infrastructure <b>202</b> using the process of FIG. 9. The process ends at step <b>1318</b>.

[0117] By summarizing the information based on events, the asset communicator <b>120</b> may operate independent of the wireless infrastructure <b>202</b> and management computer network <b>115</b>. In other words, the asset communicator <b>120</b> need not have an active communication link with the wireless infrastructure <b>202</b> to perform its intended business function, thereby providing for a more robust asset management system. Additionally, by having the asset communicator <b>120</b> being able to perform its own monitoring (i.e., not merely transmitting the information to the wireless infrastructure in a “blind” manner), the amount of data communicated to the wireless infrastructure is greatly reduced. Moreover, because the asset communicator <b>120</b> summarizes the information collected during the session for the operator, the information becomes more useful in terms of monitoring and tracking the asset <b>105</b> as utilized by the particular operator. The summary data may also be stored in the asset communicator <b>120</b> as discussed with regard to the operation of the robust wireless communications system <b>100</b><i>b </i>until the asset communicator <b>120</b> forms an active asset communication link <b>130</b> with the wireless infrastructure <b>202</b>. It should be understood that because the asset communicator <b>120</b> is capable of performing its own monitoring that the process of creating data is independent of the process of transmitting data, which, again, allows the asset communicator <b>120</b> to operate independent of the wireless infrastructure <b>202</b> and management computer network <b>115</b>. Also, data can be used to affect future decisions, like whether or not OSHA needs to be entered by next operator.

[0118] Asset Power Monitoring

[0119]FIG. 14 is an exemplary illustration <b>1400</b> of a mobile asset <b>105</b> having a power monitor for monitoring power usage according to FIG. 13. By wirelessly monitoring power usage over time, trend analysis and real-time monitoring of battery levels may be performed to provide a supervisor with visibility regarding battery operation and realization. As shown, the mobile asset <b>105</b> includes the asset communicator <b>120</b> coupled thereto. The mobile asset <b>105</b> further includes a battery <b>1405</b> coupled to a motor <b>1410</b> for driving the mobile asset <b>105</b>. A power sensor <b>1415</b>, which may be either voltage or current, is coupled to terminals <b>1417</b><i>a </i>and <b>1417</b><i>b. </i>One or more lines <b>1420</b> may couple the power sensor <b>1415</b> to the asset communicator <b>120</b> that, in turn, converts an analog voltage or current into a digital value indicative of the voltage level of the battery <b>1405</b>. Alternatively, an analog to digital conversion unit (not shown) may be electrically coupled between the power sensor <b>1415</b> and asset communicator <b>120</b>.

[0120] The asset power monitoring may further include in-line, tap-in, and contactless current and voltage sensors affixed to different parts of the mobile asset <b>105</b> and connected via a cable to a logic board (not shown), which may or may not be part of the asset communicator <b>120</b>. Currents may be converted to voltages by utilizing either a remote sensor or a converter, as understood in the art, located on the logic board. The logic board converts the incoming voltage level to digital data. The asset communicator may use configurable settings, such as filter time and voltage conversion factors, to determine, based on the digital data, the meaning of the incoming signals. To set or change the configurable settings, manual, automatic, or event triggered processes may be utilized. Typically, filtering may be utilized to filter the data over a period of time, and compare the data to a threshold level. The sensor data may be combined or utilized individually by the logic board to monitor the utilization of the mobile asset <b>105</b>. Upon the battery level dropping below the threshold level, an indicator, such as a visual or audible signal, may be provided by the asset communicator <b>120</b>.

[0121] As in the case of vehicle utilization, the power information may be stored by the asset communicator <b>120</b> and communicated to the wireless infrastructure <b>202</b> using the communication technique of FIG. 9. Additionally, the power information may be event driven in that the data is determined based on an operator logging on and logging off of the asset communicator <b>120</b>. A transaction type specifier and transaction code may be applied to the power information based on the events. It should be understood that the process for communicating power usage data of the mobile asset <b>105</b> may be the same or similar to that of the FIG. 13. Alternatively, communicating power usage data of the mobile asset <b>105</b> may be the same or similar to that of FIG. 16.

[0122] By monitoring the battery, a supervisor may determine how well a battery is operating based on historical data. The supervisor also may be able to determine misuse or disuse of the battery by an operator if the battery is being charged too soon or being charged too late. In other words, if a battery is being prematurely charged or being “deep” discharged, the battery may become damaged and the supervisor may be able to disrupt such practices by the offending operator(s). Because the asset communicator <b>120</b> is intelligent, the asset communicator <b>120</b> may be able to actively control improper practices. The battery usage may be monitored over time based on utilization of the assets <b>105</b> to determine whether the battery is operating properly based on usage.

[0123] Asset Monitoring Analysis

[0124] A desire of any asset or fleet supervisor is to have aggregate information about the assets and have all information about the fleet or groups/segments of the fleet without gaps in the information. Because the asset communicators <b>120</b> are capable of generating and storing information without having an active asset communication link <b>130</b> to the wireless infrastructure unit <b>225</b>, utilization data of the assets are collected without having gaps in the information. And, because the asset communicators <b>120</b> store the information based on events until an active asset communication link <b>130</b> is established, information for the asset is not lost. In other words, the supervisor at some point in time has utilization information for all assets in the fleet at any given point in time. The supervisor interface <b>205</b> may execute a software program, such as the database engine <b>210</b>, that accesses the databases <b>312</b><i>a</i>-<b>316</b><i>a, </i>for example, and generates aggregate information. For example, a supervisor may desire to know the number of vehicles being utilized on each hour during the course of a particular day.

[0125]FIG. 15 is an exemplary chart <b>1500</b> indicating vehicle usage during the course of a 24-hour time period on the robust wireless communications system of FIG. 3. As indicated, an aggregate of vehicles in use are provided during the course of the day. At 2:00 p.m. (i.e., hour 14), 93 vehicles were in use. As expected, the vehicles being utilized simultaneously during first shift are more than those being utilized during second and third shifts.

[0126] The combination of time and utilization from every vehicle in the fleet may be used to make numerous determinations about vehicle fleet utilization both real-time and historically. It should be understood that the utilization information of the assets may be based on any of the utilization information generated and stored by the asset communicator <b>120</b>. Accordingly, the information is uploaded from the asset communicator <b>120</b> to the wireless infrastructure unit <b>225</b> and the management computer network <b>115</b> according to FIG. 4. Such information may include in-use/unassigned, motion/idle, speed, etc. Because the utilization information is collected and accumulated, and/or summarized based on time, vehicle, and/or operator, a wide variety of aggregate data may be generated by the supervisor. The robust wireless communications system <b>100</b><i>c </i>may further be utilized to determine the total number of different vehicle used each day, the maximum number of simultaneous vehicles used by group, and the total number of vehicles used by the group. It should be understood that other aggregate data may be collected and processed. The functional utility of the system is achieved by the fact that data collection is automated and wirelessly communicated.

[0127] Asset Location Monitoring

[0128] Another application that may be utilized on the robust wireless communications system <b>100</b><i>c </i>is asset location monitoring. Because the asset communicator <b>120</b> is intelligent, the asset communicator <b>120</b> is capable of determining its own location based on signal(s) received by the asset communicator <b>120</b>. By having the asset communicators <b>120</b> determine their own locations or positions, the computations are distributed to the asset communicators <b>120</b>, which reduces computational requirements for the management computing network <b>115</b> and bandwidth requirements for the robust wireless communications system <b>100</b><i>c. </i>

[0129] The signal(s) that are received by the asset communicators <b>120</b> may be either terrestrial or satellite based. In the case of a terrestrial signaling system, the asset communicators <b>120</b> may receive signals from multiple local monitors <b>110</b> and perform a triangulation computation as understood in the art. In one embodiment, an averaging algorithm as understood in the art may be utilized to correlate the percentage of messages received over time from a local monitor <b>110</b> with relative distances. In other words, if the asset communicator <b>120</b> receives transmissions from one local monitor <b>110</b> during every transmission, and from another local monitor <b>110</b> during half of the transmissions, then the asset communicator <b>120</b> determines that it is closer to the first local monitor <b>110</b> by an approximate percentage. The asset communicator may use configurable settings, such as filter time and conversion factors, to determine, based on the data, the meaning of the incoming signals. To set or change the configurable settings, manual, automatic, or event triggered processes may be utilized. The combination of the signals received from multiple local monitors with a current motion status of the asset communicator <b>120</b> also may be used to determine the location of the asset <b>105</b> (e.g., if the asset is not moving, the asset communicator knows that the RF readings cannot show the asset moving). In the case of utilizing satellite communication, a positioning system, such as the global positioning system (GPS), may be utilized. Other techniques, such as signal strength, direction finding, and dead-reckoning, may also be utilized by the asset communicator to determine location.

[0130]FIG. 16 represents an exemplary flow diagram <b>1600</b> for determining and communicating position of an asset utilizing the robust wireless communications system of FIGS. <b>3</b>-<b>5</b> and <b>6</b>B. The process starts at step <b>1602</b>. At this point, two processes operate in parallel (i.e., location determination and location transmission processes).

[0131] At step <b>1604</b>, communications signal(s) are received by a mobile wireless device <b>120</b>. The mobile wireless device <b>120</b> calculates the position of the associated asset <b>105</b> at step <b>1606</b>. Information, such as motion/idle status, odometer/compass (e.g., dead-reckoning as understood in the art), or other sensory data, also may be utilized in calculating the position of the asset. At step <b>1608</b>, the position of the asset <b>105</b> is updated in the mobile wireless device <b>120</b>.

[0132] At step <b>1610</b>, a determination is made as to whether the asset is in motion. If the asset is in motion, then at step <b>1612</b>, a wait time is set to n-seconds. Otherwise, at step <b>1614</b>, if the asset is idle, the wait time is set to m-seconds. At step <b>1616</b>, the position of the asset, as determined at step <b>1608</b>, is stored by the mobile wireless device <b>120</b> in a location database as provided in TABLE 5. <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 5</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Vehicle Location Information</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>Transaction Type Specifier</entry></row><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Vehicle Number</entry></row><row><entry /><entry>Driver ID</entry></row><row><entry /><entry>Current Location Start Time</entry></row><row><entry /><entry>Current Time</entry></row><row><entry /><entry>Location Reading</entry></row><row><entry /><entry>Engine State</entry></row><row><entry /><entry>Battery Level</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0133] TABLE 5 is an exemplary list of data elements stored in an asset location database on the asset communicator <b>120</b>. As shown, a transaction type specifier, transaction code, vehicle number, driver ID, current location start time, current time, location readings, engine state, and battery level may be stored in the asset location database. Additionally, the vehicle location information may include a utilization status of the vehicle. In one embodiment, the current driver ID may itself provide the utilization status, whereby if the current driver ID is not specified (e.g., −1), then the vehicle is identified as being unutilized. Each time that location of the asset is stored, a transaction code may be assigned to form a dataset. And, by associating asset location with vehicle number and driver ID, the supervisor of the robust wireless communications system may determine an operator utilizing a particular vehicle at any given point in time or determine the location of vehicles that are unutilized at any given point in time.

[0134] The data of TABLE 5 is communicated from the mobile wireless device <b>120</b> to the wireless infrastructure <b>202</b> at step <b>1618</b> as provided by the communication process of FIGS. 6B and 9. In other words, the position data may be stored by the mobile wireless device <b>120</b> for an indefinite period of time based on the communication link status with the wireless infrastructure <b>202</b>, thereby providing for a substantially continuous position tracking system. The process ends at step <b>1620</b>. As shown, the location determination process is continuous (i.e., after step <b>1608</b>), and the location communication process repeats upon storage of the position data at step <b>1616</b>.

[0135] The wait times for an asset that is idle or stationary may be set to a very long time period (e.g., once per hour), and an asset that is in motion may have a shorter wait time, such as once per two seconds, for example. Alternatively, wait time may be independent of motion status of the asset. The wait times are system parameters that may be altered by the system administrator. It should be understood that in the event that an operator logs into the mobile wireless device <b>120</b>, that the wait time may be automatically updated such that the mobile wireless device <b>120</b> determines its position at the shorter wait time (i.e., higher frequency rate). It should also be understood that the storage of the position of the asset in the mobile wireless device <b>120</b> of step <b>1616</b> may be performed based on the wait time. By storing the location information at lower frequency rates, the memory of the mobile wireless device <b>120</b> is less apt to be filled during periods of the asset <b>105</b> being idle. Also, because the asset communicator <b>120</b> is continuously determining its location, if the associated asset <b>105</b> moves to a specific area, such as cell <b>111</b>, between intervals, the asset communicator <b>120</b> may communicate or take other actions, such as shutting down the asset <b>105</b>. For example, if a forklift enters a classified area of a factory (regardless of the wait time), the asset communicator <b>120</b> may shut down the forklift and communicate an alert message to the supervisor.

[0136] OSHA Compliance

[0137] The robust wireless communications system <b>100</b><i>c </i>provides for OSHA compliance with regard to the vehicle safety checklist information at the vehicle to keep an automatic record of safety checklists and identify safety issues. The asset communicators <b>120</b> allow checklist information to be customized by vehicle, and allows for the information to be updated wirelessly and automatically. The wireless communicator <b>120</b> allows an operator to answer the OSHA questions (e.g., operational status of a vehicle) independent of the asset communicator <b>120</b> being in active communication with the wireless infrastructure <b>202</b>. In other words, the OSHA related questions may be answered when out-of-range of the wireless infrastructure and the answers may be communicated with the wireless infrastructure <b>202</b> upon the asset communicator <b>120</b> re-establishing a communication link with the wireless infrastructure <b>202</b>.

[0138] The OSHA compliance system is bi-directional in that downlink and uplink communication is utilized to provide the questions and receive the responses. A supervisor may utilize the supervisor interface <b>205</b> to (i) generate lists of OSHA questions and possible responses, and (ii) associate each asset with the appropriate list of OSHA questions. TABLE 6A contains the specific OSHA questions and possible responses for each question list. Each asset may be associated with the appropriate list of OSHA questions using the data in TABLE 6B. As shown in TABLE 6B, the vehicle profile information may include vehicle type, vehicle number, and question list number, for example. Additionally, a transaction code may be stored with each dataset as entered and/or amended for the OSHA questions list details and vehicle OSHA question list information. And, because the database is relational, the questions may be specifically targeted toward a vehicle type and/or vehicle number. <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 6A</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>OSHA Question List Details</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row><entry /><entry>Transaction Type Specifier</entry></row><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Question List Number</entry></row><row><entry /><entry>Question Number</entry></row><row><entry /><entry>Question Text (e.g., “Horn operational?”)</entry></row><row><entry /><entry>Response Text (e.g., “Yes”, “No”)</entry></row><row><entry /><entry>Response Severity (e.g., “Normal”, “Critical”)</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0139]<tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 6B</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Vehicle Profile Information</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>Transaction Type Specifier</entry></row><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Vehicle Number</entry></row><row><entry /><entry>Vehicle Type</entry></row><row><entry /><entry>Question List Number</entry></row><row><entry /><entry>Impact Threshold</entry></row><row><entry /><entry>Low Battery Threshold</entry></row><row><entry /><entry>Vehicle Specific Behavior</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0140] On the downlink side, once the OSHA question databases are formed, the datasets may be downloaded to asset communicators <b>120</b> utilizing the robust wireless communications system and download protocol of FIGS. 4 and 6A for synchronization of the OSHA question list for the asset communicators <b>120</b>. Each asset communicator <b>120</b> stores the OSHA questions of TABLE 6A associated with the question list number of TABLE 6B associated with the vehicle number and/or vehicle type. If the question list number is updated for the asset communicator <b>120</b> associated with a particular vehicle number/vehicle type, then the asset communicator <b>120</b> updates and/or replaces the OSHA questions with the updated set of questions associated with the updated question list number.

[0141] The uplink communication follows the protocol of FIGS. 4 and 6B for performing synchronization of the responses from operators answering the OSHA questions. Again, upon the asset communicator <b>120</b> establishing a communication link to the wireless infrastructure <b>202</b>, the dataset stored by the asset communicator <b>120</b> are transmitted from the asset communicator <b>120</b> to the wireless infrastructure <b>202</b>. The supervisor may utilize the supervisor interface <b>205</b> to review and monitor results of the OSHA questions.

[0142]FIG. 17 is an exemplary flow diagram <b>1700</b> for performing the OSHA compliance utilizing the robust wireless communications system of FIGS. 3, 6A and <b>6</b>B. The process starts at step <b>1702</b>. At step <b>1704</b>, an authorized operator identifier is received by the asset communicator <b>120</b>. At step <b>1706</b>, question(s) related to operational status of the mobile asset <b>105</b> may be prompted independent of an active asset communication link <b>130</b> between the asset communicator <b>120</b> and wireless infrastructure unit <b>225</b>. Additionally, the asset communicator may use previously stored responses to the OSHA questions to limit the prompting of questions. For example, depending on the OSHA requirements, the checklist only may be required for every new operator, once per shift, once per every 24 hours, etc. Also, the OSHA questions may be prompted having a predetermined duration between each prompt to encourage an operator to properly inspect the asset <b>105</b> rather than simply assuming the answer. Therefore, because the asset communicator <b>120</b> is intelligent and is capable of storing data therein, OSHA compliance may be performed in accordance with specifications of a given business. Therefore, the asset communicator <b>120</b> may not prompt questions for answers if not required at that time. Additionally, based on certain conditions (e.g., mileage) of the asset <b>105</b>, a different checklist may be prompted on the asset communicator <b>120</b>. At step <b>1708</b>, responses to the questions are received by the asset communicator <b>120</b>. The responses may be entered using a keypad, touch screen, or verbal input (if the asset communicator <b>120</b> utilizes voice recognition software), for example. At step <b>1710</b>, the responses to the questions are stored by the asset communicator <b>120</b>. The responses may be communicated at step <b>1712</b> using the communication technique of FIG. 9. At step <b>1714</b>, the process ends.

[0143] In addition to the questions being answered by the operator, different questions may be associated with different levels of severity as defined in TABLE 6A. The levels of severity may be determined by system parameters maintained by a supervisor. Upon a question being answered in a certain way, different results may occur. For example, if the answer to the question of whether the headlights are working is negative, then the asset communicator may perform an immediate action in shutting down the associated mobile asset <b>105</b> or performing another action such as entering a low-speed mode or turning on a siren or light. A less immediate action may result in an event occurring based on a particular answer. For example, a negative response to the question of whether the headlights work may result in an e-mail, page, or other notification being communicated to the management computer network <b>115</b> to indicate that maintenance is required for the particular mobile asset to which the asset communicator <b>120</b> is coupled.

[0144] Still yet, because the components (e.g., management computing system <b>302</b>, wireless infrastructure device <b>202</b>, and asset communicator <b>120</b>) of the robust wireless communications system <b>100</b><i>c </i>are each capable of making decisions, any of the components individually or combined may determine that responses to the OSHA questions have not been answered in a timely manner (i.e., a business rule has been violated). If such an event occurs, action may be taken by one or more of the components. For example, if a response to an OSHA question or questions is not received by an asset communicator <b>120</b>, then the asset communicator <b>120</b> may shut down the vehicle, notify the supervisor of the non-responsive operator, and/or generate a visual and/or audible display, such as a light or siren. Additionally, the management computing system <b>302</b> may communicate a message to all or some of the assets <b>105</b> that prevents the non-responsive operator from having access thereto. Additionally, the supervisor may receive a message, page, or e-mail indicating the non-responsiveness of the operator.

[0145] Two-Way Text Messaging

[0146] Two-way text messaging may be utilized on the robust wireless communications system of <b>100</b><i>c </i>in accordance with the communication technique of FIGS. 4, 6A, <b>6</b>B, and <b>9</b>. As suggested, the two-way text messaging is both a downlink and uplink communication technique that allows a message to be communicated to any vehicle, operator, group, or all assets. Each message may be associated with a set of responses communicated therewith. The receiver of the message may select one or more responses and communicate the responses back to the issuer of the message. Status information, such as time of receipt, time that the message is read, time of each response, and time when message is deleted, may also be communicated to the issuer. Two-way text messaging further may be used to set work instructions or other dispatch information to an operator of the asset <b>125</b>. One exemplary use of two-way messaging includes warehouse management instructions. Additionally, the two-way text messaging may be used for the operator to communicate responses to the supervisor issuing the messages. While two-way text messaging may be performed utilizing the robust wireless communications system <b>100</b><i>c, </i>one-way text messaging or paging may also be performed on the system. As understood in the art, one-way text messaging does not require that information be communicated back to the device that issues the one-way text message.

[0147]FIG. 18 is an exemplary flow diagram <b>1800</b> providing a process for performing the two-way messaging on the robust wireless communications system <b>100</b><i>c. </i>The process starts at step <b>1802</b>. At step <b>1804</b>, a text message is received via the downlink communication process of FIG. 6A. The mobile wireless device <b>120</b> only stores text messages associated with the vehicle number, current operator, or group identifier. All broadcast text messages are stored. Other related message status information, such as time of receipt, may be stored. At step <b>1806</b>, the message is prompted on the mobile wireless device <b>120</b> on the display <b>333</b> independent of an active communication link between the mobile wireless device <b>120</b>. Typically, an operator uses the keypad <b>332</b> and display <b>333</b> to read the contents of the text message and view the optional responses. The time that the text message is read may additionally be stored. At step <b>1808</b>, the operator may respond to the text message, and the response and other related message status information may be stored at step <b>1810</b>. The operator may respond multiple times to the same text message. Additionally, actions may be executed by the mobile wireless device <b>120</b> based on the response(s) to the text messages. For example, a response to a text message may cause the mobile wireless device <b>120</b> to shut off the associated asset. At step <b>1812</b>, the stored data is communicated using the communication technique of FIG. 9. Once the responses and status data are stored in the management computing system database <b>312</b><i>a, </i>a supervisor may view the data using the supervisor interface <b>205</b>.

[0148] Battery Monitoring and Charging

[0149] A battery monitoring and charging application is capable of utilizing the robust wireless communications system <b>100</b><i>c. </i>Two concepts exist for the battery monitoring, including: (i) notification to the operator that the battery voltage level is low, and (ii) notification as to (a) which charger to mount the battery and (b) which charged battery to install in the asset.

[0150] Regarding the first concept (i.e., notification to the operator of low battery voltage), the battery monitoring and charging application provides information to an operator of a vehicle to which a battery is coupled, and utilizes both the downlink and uplink aspects of the robust wireless communications system <b>100</b><i>c. </i>Additionally, the communication techniques of FIGS. 4, 5, <b>6</b>A, and <b>6</b>B may be utilized.

[0151] In the downlink direction, the supervisor may set a low threshold value, such as 10.7 volts, for the battery voltage by utilizing the supervisor interface <b>205</b>. The low threshold value is a system parameter that is downloaded to the asset communicator <b>120</b> using data from TABLE 6B and the downlink techniques of FIG. 4.

[0152] Referring now to FIG. 19, an exemplary flow chart <b>1900</b> provides a process for measuring battery voltage of an asset utilizing the robust wireless communications system of FIGS. 3 and 6B. The process starts at step <b>1902</b>. At step <b>1904</b>, a voltage level of a battery utilized by the asset is measured. The voltage level may be measured by the asset communicator <b>120</b> or by an external measuring device. Further, the voltage level may be measured at the battery or remotely (i.e., at another location within the asset and electrically coupled to the battery).

[0153] At step <b>1906</b>, a dataset, including a voltage level and identifier (e.g., vehicle identifier) of the asset, is formed based on the threshold voltage level being surpassed. Additionally, the dataset may include data elements provided in TABLE 7, including a transaction code that is temporal with respect to other related datasets, transaction type specifier, event time, driver ID, asset assignment status, battery threshold, and location reading. A visual and/or audible indicator may be used to notify the operator of the vehicle that the battery level is low. The operator may respond to the indicator utilizing the process of FIG. 20, discussed hereinafter. The dataset is stored at step <b>1908</b>, and communicated at step <b>1910</b> in accordance with the communication technique of FIG. 9. The process ends at step <b>1912</b>. <tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 7</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Low Battery Information</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry>Transaction Type Specifier</entry></row><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Vehicle Number</entry></row><row><entry /><entry>Event Time</entry></row><row><entry /><entry>Driver ID</entry></row><row><entry /><entry>Assignment Status</entry></row><row><entry /><entry>Battery Level</entry></row><row><entry /><entry>Battery Threshold</entry></row><row><entry /><entry>Location Reading</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0154] Referring now to FIG. 20, an exemplary flow diagram <b>2000</b> provides for a process of changing the battery with a charged battery utilizing the robust wireless communications system of FIGS. <b>3</b>-<b>5</b>, <b>6</b>A, and <b>6</b>B. The process starts at step <b>2002</b>. The operator of the asset <b>105</b> issues a notice to the asset communicator <b>120</b>, utilizing the keypad <b>332</b>, for example, that the associated battery should be changed with a charged battery. A message may be communicated from the asset communicator <b>120</b> to the management computing system <b>302</b> using the immediate messaging technique of FIG. 5. At this point, the management computing system may determine the appropriate replacement battery and charging station for the discharged battery to be placed. At step <b>2004</b>, a message or notice may be received by the asset communicator <b>120</b> from the management computing system <b>302</b> using the immediate messaging technique of FIG. 5. The message may include: (i) replace battery, (ii) specific battery charger to mount the discharged battery, and (iii) specific charged battery to install into the asset <b>105</b>.

[0155] Referring now to FIG. 21, a typical working environment <b>2100</b> is provide for a mobile asset <b>105</b> utilizing the robust wireless communications system of FIG. 3. As shown, the mobile asset <b>105</b> includes the asset communicator <b>120</b> and a battery <b>2105</b><i>a </i>for operating the mobile asset <b>105</b>. Upon the operator receiving the message via the asset communicator <b>120</b>, the operator removes the battery <b>2105</b><i>a </i>and replaces it with a charged battery, such as a charged battery <b>2105</b><i>b </i>or <b>2105</b><i>c </i>mounted on a battery charger station <b>2110</b> as indicated by the message. The battery charger station <b>2110</b> may include a battery voltage monitor device (not shown) as understood in the art to monitor battery voltage of the batteries being charged. A local monitor <b>110</b> may be coupled to the battery voltage monitor device to communicate status of batteries being charged to the management computer network <b>115</b> so that the management computer network <b>115</b> may maintain the status of all batteries being utilized by the assets <b>105</b>.

[0156] Referring again to FIG. 20, at step <b>2006</b>, the battery <b>2105</b><i>a </i>is mounted to the battery charger specified by the message. At step <b>2008</b>, the charged battery <b>2105</b><i>b, </i>for example, indicated by the message is installed into the mobile asset <b>105</b>. The asset communicator <b>120</b> further may prompt the operator to verify that the battery is successfully changed as instructed. If the operator is unable to change the battery as instructed, then the operator may override the instructions by entering (i) which battery charger station the discharged battery was placed, (ii) which charged battery was placed into the mobile asset <b>105</b>, and/or (iii) a message indicating other occurrences in changing the battery. A swap confirmation message may be stored by the asset communicator <b>120</b> and communicated to the wireless infrastructure <b>202</b> using the communication technique of FIG. 9. The process ends at step <b>2010</b>.

[0157] Impact Monitoring

[0158]FIG. 22 is a top view of an exemplary mobile asset <b>105</b> capable of measuring impact of the mobile asset <b>105</b>. To measure impact, impact sensors <b>2202</b><i>x </i>and <b>2202</b><i>y </i>(e.g., accelerometers) are mounted to the mobile asset <b>105</b> and electrically coupled via the wires <b>2204</b> to the asset communicator <b>120</b> associated with the mobile asset <b>105</b>. As shown, the impact sensor <b>2202</b><i>x </i>is oriented in the x-axis direction, and the impact sensor <b>2202</b><i>y </i>is oriented in the y-axis direction. By utilizing multiple sensors having different axes of orientation, the asset communicator <b>120</b> is capable of receiving impact signals from the impact sensors <b>2202</b><i>x </i>and <b>2202</b><i>y, </i>and determining the level, duration, waveform, and angle of impact. It should be understood that the axes of orientation for the sensors <b>2202</b><i>x </i>and <b>2202</b><i>y </i>may be different and that the asset communicator <b>120</b> may be programmed to compute the level and angle of impact based on the orientations as understood in the art. It should be further understood that other impact sensors may be oriented in different orientations (e.g., z-axis) and utilized to measure impacts from different directions (e.g., vertical).

[0159]FIG. 23 is an exemplary flow diagram <b>2300</b> for monitoring for an impact to the mobile asset <b>105</b> of FIG. 22. The process starts at step <b>2302</b>. At step <b>2304</b>, an impact between the mobile asset <b>105</b> and another object occurs, and impact signals having different axes of orientation are received. The impact sensors <b>2202</b><i>x </i>and <b>2202</b><i>y </i>may be position, velocity, acceleration, force, and/or impact sensors. The signals generated from the impact sensors <b>2202</b><i>x </i>and <b>2202</b><i>y </i>may provide parameters to the asset communicator <b>120</b> for computing the g-force of impact or any other relevant impact parameter, including duration, waveform, and profile of impact, which may be utilized to distinguish a true impact from a bump.

[0160] At step <b>2306</b>, the time of receipt of the impact signals are determined. In the case of utilizing the impact information to alert a rescuer, for example, the time of receipt of the impact may be important in terms of rescue efforts. The time may also be critical in replaying the historical locations of assets at the time of the impact. At step <b>2308</b>, the level and angle of the impact may be determined based on the impact signals. The angle of impact may be computed by a software program operating in the asset communicator <b>120</b> or management computing system <b>302</b>, where the software program may convert the impact levels received in Cartesian coordinates (i.e., x,y values) to polar coordinates (i.e., r,θ values) to produce magnitude and angle of impact as understood in the art. At step <b>2310</b>, information of the impact, including time, impact level, impact duration, impact profile, and impact angle, may be stored as a dataset. The process ends at step <b>2312</b>.

[0161] TABLE 9 provides an exemplary list of parameters that may be stored with the dataset in an impact database. As discussed with regard to the robust wireless communications system <b>100</b><i>c, </i>a transaction code may be generated and stored with the dataset. Because the asset communicator <b>120</b> has other various pertinent information for impact analysis, such as driver ID, assignment status of the mobile asset <b>105</b>, impact threshold (system parameter), engine state, and location, other relevant information may be included on the dataset. Of course, any other data stored or determinable by the asset communicator <b>120</b> may be included in the dataset. <tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 8</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Impact Information</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>Transaction Code</entry></row><row><entry /><entry>Vehicle Number</entry></row><row><entry /><entry>Event Time</entry></row><row><entry /><entry>Driver ID</entry></row><row><entry /><entry>Assigned?</entry></row><row><entry /><entry>Impact Level</entry></row><row><entry /><entry>Impact Angle</entry></row><row><entry /><entry>Impact Thresholds</entry></row><row><entry /><entry>Engine State</entry></row><row><entry /><entry>Location Reading</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0162] The dataset may be communicated from the asset communicator <b>120</b> to the wireless infrastructure unit <b>225</b> using the communication technique of FIG. 9. Because impact of a mobile asset <b>105</b> may involve personal injury, real-time communication may be important, so the immediate communication technique of FIG. 5 may be utilized to inform authorities. Receipt of the page by the management computer system <b>115</b> may trigger a notification to local authorities via a paging message, e-mail, or telephone call. An impact may be considered a violation of a business rule and trigger one or more events, such as preventing the operator involved in the impact from accessing the same or other vehicles. The asset communicator may also (i) shut down the vehicle, (ii) put the vehicle into a creeper mode so that vehicle may be moved if necessary, but not used as normal, or (iii) turn on a signal such as a light or siren. The dataset may provide the supervisor or authorities with information for reconstruction of the impact. For example, if a collision occurs between two monitored assets, then the cause of the collision may be determined by the data generated from both asset communicators <b>120</b>. One scenario may include an unutilized vehicle recording an impact with a vehicle that is being driven by an identified operator.

[0163] Maintenance Monitoring

[0164] Scheduled maintenance of assets, including both fixed and mobile assets, may be managed by utilizing the robust wireless communications system <b>100</b><i>c. </i>The management computing system <b>302</b> may predetermine, forecast, or project an expiration date for a scheduled maintenance for the -assets being managed by the management computing system <b>302</b> based on historical utilization information. Assets may also be scheduled based on responses from OSHA questions or by the asset communicator <b>120</b> sensing maintenance problems with the asset <b>105</b>. Maintenance events also may be scheduled manually, such as by a maintenance supervisor. To determine the expiration date, the management computing system <b>302</b> may inspect the vehicle utilization information of TABLE 4 as stored in a database <b>312</b>, for example, and extrapolate future utilization of the asset <b>105</b>. Additionally, software may track global parameters for the assets <b>105</b> to determine the expiration date for the scheduled maintenance. Such global parameters may include mileage and hours of use, motion, and lift time, for example, as well as calendar time since last maintenance. Additionally, the system may prioritize based on scheduled maintenance discrepancies between the projected and scheduled maintenance times.

[0165]FIG. 24 is an exemplary block diagram <b>2400</b> indicative of a method for managing scheduled maintenance of assets. The process starts at step <b>2402</b>. At step <b>2404</b>, schedule maintenance due for an asset by a predetermined expiration date is determined. The determination may be made manually or automatically. At step <b>2406</b>, a message is communicated to the asset using the communication technique of FIG. 9 to indicate that the scheduled maintenance is due by the predetermined expiration date. The message may be generated manually by a supervisor or automatically by the management computing system <b>302</b>. In one embodiment, the message is transmitted to the asset communicator <b>120</b> via a paging message to ensure that the asset communicator <b>120</b> receives the message with an appropriate amount of time to have the scheduled maintenance performed on the asset.

[0166] At step <b>2408</b>, an operator of the asset is notified of the scheduled maintenance by communicating the message to the operator at the asset via the asset communicator <b>120</b>. The notification may be in the form of a visual display or an audible message. The process ends at step <b>2410</b>.

[0167] The predetermined expiration date is a mandatory date for which maintenance is to be performed on the asset. In other words, the predetermined expiration date is the date by which the asset must be brought into a maintenance center, or a maintenance worker comes to the asset to perform the maintenance. Upon the asset having the scheduled maintenance performed, the asset communicator <b>120</b> and/or the management computing system <b>302</b> may be updated wirelessly. And, the asset communicator <b>120</b> may communicate with an on-board computer, such as an automobile computer, to assist with the diagnostics. If, however, the scheduled maintenance is not performed on the asset before the end of the predetermined expiration date, then the asset communicator <b>120</b> may disable, put into creeper mode, and/or disable certain features (e.g., lift). At this point, only an authorized user, such as a supervisor or maintenance personnel, may access the asset communicator <b>120</b> and operate the asset.

[0168] Indirect Communications System

[0169] Fleet management and tracking of vehicles, railcars, and trucks, for instance, may be a difficult venture due to situations of remote distribution of the assets. Additionally, due to system coverage constraints, it is possible that various assets within a fleet rarely or never come within range of a local monitor <b>110</b>. For example, railcars often times do not come within a certain minimum range of a station for an asset communicator <b>120</b> to form an asset communication link <b>130</b> with a local monitor <b>110</b> located at the station. As another example, large automobile lots may preclude asset communicators <b>120</b> mounted to automobiles located at the back of the parking lot from maintaining an active asset communication link <b>130</b> with the wireless infrastructure unit <b>225</b>, thereby preventing updating of the databases within the asset communicator <b>120</b> during potentially long periods of time. Additionally, certain wireless infrastructure units <b>225</b> may not include a communication unit <b>230</b><i>a, </i><b>230</b><i>b, </i>or <b>230</b><i>c. </i>In such a case, the wireless infrastructure unit <b>225</b> communicates with at least one other wireless infrastructure unit <b>225</b> in order to indirectly communicate with the management computing system <b>302</b>. For these and other reasons, an alternative embodiment of the robust wireless infrastructure <b>100</b><i>c </i>is provided.

[0170]FIG. 25 is an exemplary embodiment of a wireless infrastructure <b>100</b><i>e </i>consistent with that of FIG. 1 for providing wireless communications on a remotely populated fleet of assets <b>2500</b>, such as railcars. As shown, the assets include a locomotive <b>105</b><i>g </i>and attached railcars <b>105</b><i>h</i>-<b>105</b><i>k, </i>and railcars <b>1051</b> and <b>105</b><i>m</i>-<b>105</b><i>n </i>unattached to the locomotive <b>105</b><i>g. </i>While the railcars <b>105</b><i>h</i>-<b>105</b><i>k </i>may be within wireless communication range of the station <b>2502</b> and the local monitor <b>110</b>, the railcars <b>105</b><i>l</i>-<b>105</b><i>n </i>are unable to form a wireless communication link with the local monitor <b>110</b>. However, it should be understood that the asset communicator/local monitor pair <b>120</b>/<b>110</b> may perform the same or similar functionality as the local monitor <b>110</b> having its databases (e.g., <b>312</b><i>b, </i><b>314</b><i>b, </i>and <b>315</b><i>b</i>) being updated via the local monitor <b>110</b>. It should be further understood that the hardware of the local monitor <b>110</b> may be substantially the same as asset communicator <b>120</b>.

[0171] Coupled to the locomotive <b>105</b><i>g </i>is an asset communicator/local monitor pair <b>120</b>/<b>110</b>, which is a device that performs both asset communicator <b>120</b> and local monitor <b>110</b> functions. Alternatively, only a local monitor may be deployed on the locomotive or key communication point. By including a local monitor <b>110</b> with the locomotive <b>105</b><i>g, </i>the asset communicator/local monitor pair <b>120</b>/<b>110</b> may operate as a mobile local monitor, and communicate with asset communicators <b>120</b> that are unable to communicate directly with the local monitor <b>110</b> mounted to the station <b>2502</b>. Alternatively, the asset communicator/local monitor pair <b>120</b>/<b>110</b> may be two or more devices coupled via a wired or wireless communication link.

[0172] The asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>may operate in a “repeater” mode, where the asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>are capable of communicating through each other. In operating in the repeater mode, the asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>are capable of transmitting and receiving the information stored in their respective databases. The asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>may communicate directly with the asset communicator/local monitor pair <b>120</b>/<b>110</b> to form an asset communication link <b>130</b><i>e </i>or with another asset communicator (e.g., between asset communicators <b>120</b><i>h </i>and <b>120</b><i>i</i>) to form an asset communication link <b>130</b><i>f. </i>Asset communicator <b>1201</b> is shown to be attempting a transmission of data with potential asset communication links <b>130</b><i>e/f. </i>By having the asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>communicating the data between each other and/or eventually to the asset communicator/local monitor pair <b>120</b>/<b>110</b>, the data generated in the asset communicators <b>120</b><i>h</i>-<b>120</b><i>n </i>eventually is capable of reaching the management computing system <b>302</b> via the local monitor <b>110</b>.

[0173] The robust wireless communications system <b>100</b><i>e </i>is capable of determining the number of existing assets <b>105</b> operating on the system <b>100</b><i>e </i>without having direct communication links to each asset <b>105</b> (i.e., without complete coverage). Additionally, the system <b>100</b><i>e </i>may be able to determine the relative distances of the asset <b>105</b> from a local monitor <b>110</b>. To determine the relative distances, an algorithm may be utilized to determine the number of “hops”, where the number of hops refers to the number of intermediary links between the asset communicator <b>105</b><i>i </i>and the local monitor <b>110</b>, which is three in this case. To determine the number of hops, each asset communicator <b>120</b> may perform a query to determine if a direct communication link <b>130</b><i>i </i>to a local monitor <b>110</b> may be established. If so, then the number o/f hops is determined to be one. Otherwise, upon a communication link <b>130</b><i>e </i>between the asset communicator <b>120</b><i>h </i>and the asset communicator/local monitor pair <b>120</b>/<b>110</b>, the asset communicator <b>120</b><i>h </i>determines that the number of hops is two by adding one to the number of hops returned by the asset communicator/local monitor pair <b>120</b>/<b>110</b>. The process may repeat for each of the asset communicators <b>120</b><i>i, </i><b>120</b><i>j, </i>and <b>120</b><i>k, </i>for example. It should be understood that the algorithm may be performed in other ways, but that the functionality should produce the same or similar results.

[0174]FIG. 26 is an exemplary flow diagram <b>2600</b> for an indirect uplink communication with remotely populated assets utilizing the robust wireless communications system <b>100</b><i>e </i>according to FIG. 3. The process starts at step <b>2602</b>. At step <b>2604</b>, data is generated at a first mobile wireless device, such as the asset communicator <b>120</b><i>n. </i>The data may be stored at the first mobile wireless device until a wireless communication link is established with a second mobile wireless device or remote local monitor. At step <b>2606</b>, the data is transmitted from the first mobile wireless device to the second mobile wireless device. Again, the data may be stored at the second mobile wireless device or remote local monitor until a wireless communication link is established with a third mobile wireless device or local monitor. At step <b>2608</b>, the data is transmitted from the second mobile wireless device to the local monitor, where the local monitor may be mounted to a mobile asset or fixed to a structure. Accordingly, the data may be in the form of datasets, and have transaction codes associated with each dataset as per the uplink communication technique of FIG. 9. As the datasets are communicated throughout the network of mobile wireless devices and remote local monitors, the transaction codes may be used to identify the temporal relationship between datasets produced by a mobile wireless device. It should be understood that the data may be communicated, in either the uplink or downlink direction, between any two mobile wireless devices without either of the mobile wireless devices having a wireless communication link to any other mobile wireless device or local monitor <b>110</b>.

[0175] To avoid having endless loops of data communicating amongst the asset communicators <b>120</b>, an algorithm is provided. The algorithm utilizes a listing of asset communicators <b>120</b> or remote local monitors through which the data has passed. An asset communicator <b>120</b> or remote local monitor does not send data through any asset communicator already in the list. The asset communicators choose a nearby asset communicator <b>120</b> or remote local monitor that is deemed ‘closer’ to the local monitor <b>110</b>, where ‘closer’ indicates that fewer communication ‘hops’ are required to reach the local monitor <b>110</b>.

[0176] The previous description is of a preferred embodiment for implementing the invention, and the scope of the invention should not necessarily be limited by this description. The scope of the present invention is instead defined by the following claims.