• No results found

Chapter 5 : Application Support for Field Workers

5.3 Application Components

5.3.4 Additional Modules

The modules described in the previous sections have covered the most important collaborative tools within the application prototype. The remaining modules offer less significant tools such as remote access to legacy applications and asynchronous communication facilities (e.g. E-mail and job dispatching).

5.3.4.1 Remote Database Access Module

The remote database access module is a more traditional client-server tool which provides access to a simple database server which may be running on some remote host. The module was designed to demonstrate that applications running on mobile machines can interwork with existing database engines running on legacy systems within the established infrastructure, thereby proving the feasibility of access in the field to customer and resource databases (and further demonstrating the interoperability aspects of the work).

The remote database access module is a non-collaborative tool. While multiple users may be running the module simultaneously and each effecting queries to the remote database server, there are no facilities for sharing the query results between group members. However, it would not be difficult to allow the results of the query to be transferred to one of the other tools such as the E-mail module (see below) for dissemination to other engineers.

5.3.4.2 E-mail Module

The E-mail module permits the sharing of multimedia MIME messages [Borenstein,93] between users of the prototype application. The E-mail module is the only part of the application which has not been engineered as an RM-ODP compatible object in its own right (i.e. no interface is offered to applications running on the local or remote hosts). The lack of integration is purely due to time constraints within the MOST project: it was recognised as being more important to be able to demonstrate the mobile E-mail concept rather than spend additional time on an integral solution.

In essence, the system consists of an elm mail browser front-end which is supported by an RM-ODP compatible module in place of the SMTP daemon. The new module uses platform invocations to provide the mail transport mechanism rather than SMTP. This strategy avoids the need to use a mobile IP implementation or make any modifications to the mailer. The E-mail system could be extended to include a gateway object within the fixed infrastructure which transferred platform invocations containing E-mail messages to the standard mail daemon (and vice versa). Such an object would permit the global Internet E-mail system to interwork with the prototype’s E-mail tool.

5.3.4.3 Job Dispatch System

The job dispatch module is designed to provide field engineers with a convenient mechanism for receiving work instructions and reporting job completion to the job issuer. The module is designed to provide functionality analogous to the paper based record system currently in use within the utilities companies. The job dispatch module, like the remote database module, is non-collaborative. Jobs are destined for a particular field engineer who may then, at their discretion, share information with their colleagues. However, the original engineer to whom the job was sent remains accountable for the completion of the job.

In addition to detailed instructions on the nature and location of a job, the system allows map and schematic references to be included with the instruction. The references can be imported into the GIS module so that the field engineer can view the job location in precise detail. An annotated instruction is inherently more precise than verbally delivered instructions from the control centre via the PMR system.

The job dispatch module relies on the same ODP transport service as the E-mail system for the reliable transmission of the job dispatch records.

5.3.4.4 Lightning Warning Service

The final module to consider in this chapter is the lightning warning service module. Lightning location is of vital importance to field workers in the electricity utility companies for a number of reasons. Firstly, since a large quantity of repair work is as a direct result of storm damage (in general) and lightning (in particular), knowing of the impending approach of a storm can allow the utility company to make strategic decisions about power routing and manpower in advance of a potential power outage. Secondly, where a field engineer is required to repair or service equipment, particularly if it is overhead or pylon mounted, knowing of the impending approach of lightning could potentially avoid life threatening situations.

The lightning warning service module is essentially a client front-end to a central service known as the National Lightning Flash Location System [Morgan,91] developed by the MOST project partners, EA Technology Limited. The service is a collation point for information from a number of listening posts established all over the U.K. By tuning in to the 800MHz frequency band, each listening post is able to detect the electromagnetic pulses generated by lightning strikes. The information is collated from a number of sites and triangulated to precisely locate each strike (the more sites involved, the more precise the location fix). The resulting lightning strike information (position and time of strike) is coordinated at a central site where it can be used to supply interested clients. Service subscribers receive strike reports at a rate of up to 5 strikes per second (40 strikes per second can be recorded centrally for later analysis). Subscribers normally run client software which overlays the strike information on a map of the British isles (see figure 5.12).

The lightning warning service module allows engineers to enter their location (a postcode is sufficiently accurate); the module registers with a remote server on the fixed network. The remote server parses the lightning strike information looking for incidences of lightning within a specified bound of its client engineers. Should lightning encroach within the threshold the engineer’s module is called-back (via the registered interface) to inform the engineer of the approaching danger.