Introduction
Utilities, Telcos, Municipalities and of recent times campus and building managers, have a unique set of requirements when it comes to maintaining detailed records of their asset inventory. Specifically in addition to the normal requirements of existence count and value, the actual disposition and utilization of each asset is also recorded.

History - Post-job recording
The historical approach to Automated Mapping/Facilities Management "AM/FM" was at best fragmentary. The AM part of the equation consisted of paper based Asset registers, which performed the "count" and "value" function, and paper based maps, which showed the disposition and utilization of the assets. History suggests that even in the case of the most diligent organisations, these records were notoriously out of date. The usage of a manual "Post-Job" recording process, guaranteed that there was always a lag directly related to the drafting backlog. The outcomes of such a situation meant that co-ordination was significantly more difficult, consequently, activities such as digging up the road were often handled in a sub-optimal manner.

With the dawning of the computer age came the opportunity to rectify some of the problems of the past, and to introduce some efficiencies to the process through the use of computer based graphics. The first step was the introduction of Computer Aided Drafting (CAD) technology, which provided an increased level of efficiency over the manual drafting approach. This allowed the backlog to be reduced, but the paradigm was still a "Post-Job" recording process.

Contempory approach - Post-design recording
The next step introduced an increased level of sophistication to the process. It introduced the concept of data modelling and opened the way for significantly more flexibility both in the level of detail and possible presentation capabilities. This is largely the technology, which is in place today. There is still a gap between the AM and the FM, this is due to the fact that spatial database technology up until quite recently has only been available in proprietary non relational database form. This has meant that for many organisations there has been at least some level of disconnect between the Asset Database and the Maps showing the facility disposition and utilization. Sometimes the disconnect has been total.

The latest advances in this class of technology have seen a movement towards the all- relational store being commercial off-the-shelf RDBMS products, and the consequent integration of the AM and FM parts of the data management equation. The other major advance introduced with the data modelling approach was the concept of temporal data, with the requirement for Long Transaction support in the application. This allowed utility organisations to capture details of proposed network changes and to publish them before they actually take place, so called "Post- Design" recording. This dramatically improved many of the co-ordination issues of the past, as it was now possible to see the future plans for the network at the time when new work is being planned and so optimize the use of resources associated with implementing network change.

In summary the situation as it exists today is as follows:

AM/FM data held in a common RDBMS
Records of installed plant available almost immediately after job completion
Data recorded before the event (ie immediately after design completed), showing proposed future work
Future overlapping proposals can be stacked showing interdependencies
Ability to generate a Bill of Materials and effort estimates for design projects.

Future - Design time capture
With the state of the art AM/FM data now available and fully described in a detailed data model, the opportunity exists to expand the capabilities of the data collection and maintenance applications to move beyond simply recording data. It is now reasonable to expect the capabilities to be extended to fully support the design process which apart from corrections is the only way this change is introduced. The remainder of this paper examines the nature of the requirements for such a design facility and considers some of the implications of providing such capabilities. The first issue to be dealt with is the fact that the design process is radically different to the capture process, which traditionally mimics the construction process.

The capture process would work in the following order:

Definition of the infrastructure such as manholes and trenches
Definition of the distribution components such as cables and equipment
Assignment of services.

In the case of the design process, the approach is inverted.

Service requirements must be defined

Determine the overall capacity requirements
Dimension of the distribution equipment
Define appropriate infrastructure components

At many points in the design process, there are decision points which can be supported by suitable design support tools such as analysis tools or optimisation tools. For example the placement of expensive amplification equipment must be offset against the cost of providing additional infrastructure equipment in a broad band network design. Suitable analysis tools can simplify the process of developing an optimal design.

Inevitably the process of design is one of stepwise refinement. Certain design decisions need to be deferred until other details are known. For example, the size/capacity of infrastructure components such as ducts cannot be determined until the cable size is known, and in turn size cannot be determined until the full extent of the service delivery requirements are known.

The traditional approach to design is to start with an outline sketch and gradually fill in the detail as it becomes known. This means that the supporting software must be capable of accepting sketch level details while still maintaining a level of internal model integrity. For most cases this means maintaining rule sets which are more relaxed during design capture but which can be used to validate more tightly when a user indicates the design is complete. The software needs to support the user by indicating those aspects of the design which have not been fully specified. In this way the designer can work towards a complete solution, with the system providing the necessary integrity rules, but without forcing the designer into a situation where it expects details, which the designer cannot accurately provide, at the current stage of the design.

In effect we need to introduce a new "preliminary design" status, which has a much more forgiving rule set. We also need to provide a new work flow step which allows a designer to upgrade parts of his design proposal from "pre-design" status to "design" status. This step would apply the more rigorous rule sets that would guide the designer to any areas that are incomplete from a design perspective. An example might be an infrastructure component such as a manhole might have a valid size of "undecided" in "pre-design" stage, which would not be an acceptable size in "design" stage. The rule set could identify this case when the designer attempted to upgrade the design and either recommend a valid size, or prompt the designer to provide the necessary size details.

A more supportive approach might be to allow the designer to set the size to "optimal" and have the system choose the best option when the designer indicates that the design is complete. This approach to parametrically specifying components, would free the designer from the meticulous task of ensuring that the correct component was chosen and would allow an approach of "one size fits all" to be followed. So, for example, the designer would simply specify "underground housing" and the system would ultimately choose the optimal size and construction type, based upon its usage context. This concept can be extended to support the introduction of templates and aggregated components, under such arrangements, whole assemblies are introduced, which consist of a large number of standard components, or standard configurations, which self-configure based upon the context in which they are introduced.

The second major difference between capture and design is that in the case of capture, all of the design decisions have already been made, so that there is no need for integrated analysis and design support tools. Where the object of an activity is to capture the details of a network element or set of network elements then it is appropriate to augment many of the capture tools with appropriate design support rules and algorithms. Examples are auto-routing algorithms which take into account available duct capacities, and existing pole runs to assist in cable laying operations.

As well as the analysis tools and auto-routing algorithms etc, significant productivity gains can be achieved simply by tuning the user interface environment to support the design activity. For example:

"Tool Tips" might be modified to reflect information useful to the designer
"Pop-up" windows could be provided with more context driven information and tools
Agents similar to those provided with some office products provide useful context sensitive help
Wizards can be devised to support some of the more complex design tasks

The third major difference between capture and design is the requirement to examine and evaluate alternative designs. This means that the system must support the ability to create a set of alternate design proposals and provide the necessary tools to provide comparative cost analysis for each of the designs. It should also allow the designer to create subsets and supersets from the design proposals to produce new proposals, which incorporate the best aspects of the competing proposals.

Finally, and probably the most difficult challenge, is to provide satisfactory interfaces to the variety of pre-existing analysis tools, which have their own proprietary data structures and operating constraints.

Many of the favourite tools use text-based interfaces so that we are constrained to use batch style interactions with relatively poor integration as a result. The promise of the future is that these tools will be re-engineered to provide COM style interfaces so that they can be more cleanly interfaced from the design application running on the ubiquitous Microsoft desktop.

Conclusion
In summary, if we are to "Capture Network Data by Design" then at least the following capabilities must be built into the design capture software:

A high degree of tolerance for partial definition of the proposed network during design refinement stage.
A deferred validation step which ensures that a design is actually complete and passes all the validation checks when the designer claims it to be complete.
Built in design support and analysis capabilities within the network capture tools to assist the process.
Support for extensive What-If and multiple scenario capabilities within the design tool set.
Ability to "mix and match" the best parts of a number of design proposals into a new "preferred" composite proposal.
Flexible arrangements to allow interfacing to a wide variety of third party analysis and design tools.

As we have seen the technology which supports AM/FM data management has come a long way from the paper and drafting pen days. Clearly there is still much that can be done to empower the users of such systems, and to drive the technology deeper into earlier work flow steps so ensuring that the latest information is corporately available at the earliest possible moment in the cycle.

This approach ensures minimum rework, and maximum availability of the information within the organisation, while providing the maximum level of value-add to assist the users of the system to produce cost effective results.