Telecommunications outside plant management throughout brasil
Geovane Cayres Magalhiies, Ph. D. TELEBRAS / CPqD Rodovia Campinas Mogi-Mirim km 117 CAMPINAS, SP BRASIL 13.088-061 E-mail: geovane@cpqd.br Abstract The development of SAGRE, an outside plant management system, is discussed stressing the lessons learned in the process. In order to satisfy the requirements of the 28 Telebras Operating Companies and to cope with the high demand of telecommunications facilities typical of countries under development, SAGRE had to come out with flexible and innovative solutions that can also be applied to many operating companies around the world. Introduction Telebras (TELECOMUNICACOES BRASILEIRAS S/A) provides, through its 28 regional and one long distance national operating companies, telecommunications services using 15 million accesses. The network records used to be mapped in more than 300.000 large size maps. SAGRE Project, TELEBRAS solution for managing the network outside plant, was introduced at the 1994 AM/FM Conference (Magalhiies, 1994a). SAGRE is a Portuguese acronym for Automated System for Management of Outside Plant. At that time we stressed the objectives for a comprehensive and open system being implemented to meet the requirements of TELEBRAS’s state operating companies. Now, after the conclusion of pilot deployments and with the system operational in almost all of our operating companies, we would like to share with the AM/FM community the lessons we learned in the development process. SAGRE covers the entire life cycle of outside plant management: planning; design; construction; operation and maintenance. SAGRE enables the engineers to plan new expansions and to design the work to be done. It calculates the material and labor needed in each construction step while simultaneously enforces the company engineering standards. It also makes it possible to increase network utilization by finding the best facilities to service each subscriber need. Another significant development resulting from SAGRE is a new paradigm for data conversion, devised in order to speed up and lessen the cost and complexity of this critical process. In the following sections we summarize the lessons we learned in the process of building SAGRE. User Requirements SAGRE development team consisted of system analysts and outside plant engineers. This team was based at the TELEB~S CPqD Research and Development Center backed by several work groups composed of the operating companies’ representatives. It is important to know that the 28 operating companies became part of TELEB~S group after many years of operations had its own practices and methods. Their maps and drawing conventions looked alike but each one had its own special mode of operation. Writing the requirements for such a group was very diflicult. Although these requirements made the development diflicult they contributed to the creation of a very flexible system. Another source of special requirements was the Brasil telecommunications network. Typical of countries under development and due to the lack of investment funds, tariff regulations, and social pressures, the demand for telephone lines is unmet, causing the need for big network expansions. This situation necessitated the fulfillment of two general requirements not common in current outside plant management systems: (a) on-line facilities assignments in-line with the enterprise operations support systems; (b) planning of a big network expansion followed by detailed design for cost effective and timely Construction The first requirement calls for on-line operations in a GIS environment. Traditionally, even in an AM/FM environment, GIS have been used for record keeping and work order processing. In telecommunications this means keeping the records up to the terminal box and leaving the subscriber services and facilities mapping to the legacy mainframe operations support systems. In order to achieve optimum functionality, storing the subscriber’s addresses, all the connectivity mapping, and electronic equipment functionality in the GIS was necessary. The second requirement adds another level of network maintenance. The work order model is fitted for small modifications in a stable network. In developed countries, the network grows with the city. There is a facility for each house and increase in demand is easily solved by small work orders. However, in developing countries, in addition to the small day-to-day changes, there are big expansion projects. We would like to take these projects back into the company database automatically. System Design and Modeling In order to satisfi the needs of 28 operating companies we had to come up with a very flexible system. We modeled the network in the very fine level of detail. A lot of resources and time were spent in the design. We discovered later that this was a wise decision. The telecommunications network is growing fast in complexity due to the massive introduction of fiber and electronics. Our data model can accommodate very complex situations found in existing telecommunications networks. It covers the land base, including the home addresses, the ducts and manhole network, the aerial, buried, and mixed network, the network that runs inside the ducts and man-holes, the air pressure network, electrical protection, and several other details. Wire and fiber connectivity is controlled by the end-user. Each cable segment, equipment, splices, and most other objects of the network can be made connected or not connected resembling real life operation. Connected paths make the telecommunications way of providing services. A complete path can run on several cable segments, enter and exit equipment according to its functionality, from the central office to the subscribers. The application is driven by a data base that describes the data model and the user interface in terms of classes and objects. Evolution and introduction of new objects in new equipment can be accomplished without difficulties. Functionality is provided in three levels. In the first level the operations (facility assignments) oversee the whole area of interest. The second level contains the existing plant database (or databases). The third level contains the projects being carried out on a check-out/check-in basis. Most of the maintenance and design operations use versions to store the proposed work. Microcomputers are the preferred platform in this part of the enterprise for operations level functionality. The other functions are available in RISC workstations for performance reasons. SAGRE is designed to scale online operations and design from very small operating companies to very large ones like the WioPaulo metropolitan area. GIS SAGRE was designed and developed on top of two software platforms commercially available, a relational data base management system and a geographical information system (GIS). The GIS was selected through a formal bid. The bid analyzed many aspects we found important at that time and each software was submitted to a benchmark. There were mandatory and punctuated aspects. One of the mandatory aspects, the relationship of the GIS with commercial data base management systems, proved to be the most important. Now, we can comment about the features we needed more. A sophisticated symbology language capable of deriving symbols and details is a must. AM/FM systems can be made more effective through the wise use of symbology. A client server architecture, version support and check-in/ check-out mechanisms are aspects we needed to be able to fulfill the requirements. Another aspect we can consider now as fundamental is the support for schematics. One aspect we considered very important in the beginning, the support to standard data interchange formats, has not been necessary as we predicted. We suppose this was due to the lack of GIS industry standards, or the absence of data to be interchanged. Countries under development still do not have a tradition in AM/FM systems. We have done extensive data exchange in CAD formats, but a lot of work is usually required to structure these data according to SAGRE needs. We badly need a standard in this area. In spite of requiring from the GIS the support for imaging we have not being able to derive the advertised benefits from its technology. However, imaging is provided in SAGRE. We are fortunate that the GIS we selected remains competitive in this area. Some of our users implement a two-step strategy with regard to imaging, where imaging (AM) comes first and then, ?incrementally, the data is raised to the FM level. SAGRE allows the placement of images in any map or schematic as a background drawing and also to store an image linked to any of its objects, even if they do not have a graphical representation. Also, these images can be checked out and in for integration with other imaging systems. Architecture TELEB~S has developed an integrated operations support system plan and architecture. The plan defines the main sub-systems and databases to fulfill the functional needs of our operating companies. SAGRE follows that plan and architecture. SAGRE architecture is open and built on three layers: user interface, application rules, and GIS database. The database layer is the core of SAGRE, and has been designed using object oriented techniques. The GIS adds greater flexibility and uniformity to this layer because it uses a commercial relational data base management system to store both spatial and nonspatial data, Both interface and application layers are based on object oriented standards. All layers are driven by metadata to encapsulate interface, data base and application objects. This has made possible the development of dynamic user interfaces and operations, whose components are specified at run time (Oliveira 95). The metadata capability accelerated the development by reusing not only code but also design characteristics. The architecture also enabled the derivation of our conversion methodology that collects converted data in an object oriented fashion much like the on-line operations. A major challenge was to reconcile two entirely different user work modes -- operations and design/planning. Most of Operation transactions originate from customer phone calls regarding service repairs and changes. The Design mode comprises long duration activities as opposed to short operational transactions. The engineers interact with the database in order to pose spatial queries that analyze the existing facilities against projected demand for a given region. Design work is conditional and should not affect existing data unti 1the work is constructed. SAGRE must thus be able to support such activity profiles, and the database must consider concurrent access by both maintenance and design/operations teams. To allow integration of these processes, the project had to use check-in/check-out and versioning mechanisms. Besides supporting alternative designs, this allows cooperative work among design and operational teams (Dias 95). Another architectural feature in SAGRE is its ability to integrate a CAD tool into the design process. With this feature, we can start deploying SAGRE with the help of a CAD tool while conversion is taking place. Implementation Although it is very well known that systems like SAGRE take a long time to be implemented, the end users cannot wait for the completion of the whole system. We decided to build a first version after completion of data modeling but with limited functionality. This version had several objectives: (a) to come out with some functionality to satisfy the end users pressure; (b) to test the modeling with real data; (c) to get feedback on the user interface; (d) to start data conversion. This decision proved to be very good. Note that this first version was not a prototype. It had limited functionality but implemented the complete data base structure. Usually, a prototype is constructed and a pilot is made. Sometimes, conversions are made without knowing the final data model causing many problems when trying to save conversion work. This approach also allowed us to modifi the paradigm of data conversion that will be discussed later in this paper. SAGRE first version was the seed for two of its modules, the SAGRE/Records (Gonqalves, 94) and SAGRE/Conversion modules. SAGRE/Records maintains the existing plant database and SAGRE/Conversion implements our conversion methodology and tools. While maintaining the first modules, we started designing and implementing the complete functionality. The data model proved to be very stable but the user interface, as expected, had many problems. We learned that we should have taken more time in the construction of the interfaces. A new interface model was built and the complete system architecture was implemented. A new SAGRE/Records and SAGRE/Conversion, the SAGRE/Administration, SAGRE/Design, and SAGRE/Operations comprise the functionality required for SAGRE (Prezzoto, 95). The high investment we did in modeling the database is paying off gradually. The database is steadily supporting the architectural enhancements being implemented as well as the increase in functionality required by the end users. Also, the databases being constructed with the conversions are coming up with sizes unexpectedly small. We believe this is also due to the GIS data structure. Deployment We learned from the beginning that conversion was the biggest problem to be considered in an AM/FM/GIS system. With the release of SAGRE/Records version 1.0 we started a bid for a pilot conversion. With the help of consultants we knew that doing in-house conversion could be a bad decision. Conversion requires specialized assembly line type of work. The bid called for the traditional conversion approach -- the conversion company would handle the data in our GIS interchange (low level and proprietary) format. We were not satisfied with the situation since the 390?Brazilian conversion market had very little experience with GIS conversion, and in particular, with the GIS we were using. Before the closing date for the bid, we decided to change the format (and the paradigm) of the conversion. We came out with an (land base and outside plant) object oriented format to be handled by SAGRE/Conversion module (Magalhiles, 94b). The methodology and tools we adopted are based on the idea of manipulating the systems objects in the same level of the user interface. For example, to lay an aerial cable segment the user selects the poles, draws the cable path, enters the attribute data, etc., then the conversion data should resemble this mode of operation. The conversion company receives a detailed technical specification on how to read the maps and forms information and translate them into our standard format. Conversion data is input in batches. Each batch is submitted to SAGRE/Conversion module that reads the conversion data, makes the same consistency check performed by SAGRE/Records, resolves the elements continuity problems due to maps boundaries, reports all errors, calculates quality assurance figures, and separates batch into two others -- the set of objects that have been entered correctly and the set that did not enter due to errors. The data allowed into the system may have only layout problems, which is also minimized due to graphical consistency checks. For example, duplicate geometry is not allowed. This pilot conversion was set to provide us with: costs and timing for the Brazilian context; validation of the conversion technical specification; experience with contracting and accepting conversion work; a broader knowledge of the process; levels of quality assurance; qualification of conversion vendors; a real life and complete database representative of our reality for testing and integration of SAGRE modules. The pilot was a success and its pioneer data has helped TELEBRAS to cut significantly the conversion cost and complexity. SAGRE conversion methodology and tools are evolving continuously. Each time a new conversion bid is set improvements are made in order to allow the operating companies to move into SAGRE faster without reducing quality level. Conclusions SAGRE is a system that has pushed AM/FM/GIS into the mainstream of TELEBRAS technology support. The key decision that allowed us to arrive earlier in this status was to develop a system to cover the entire outside plant information life cycle. Also, we had the courage and support to try new technologies and methods that worked well. In this process we took advantage of the cooperative spirit of the AM/FM community by sharing experiences with many users and vendors. Acknowledgments SAGRE is a cooperative effort among TELEB~S R&D Center and the Operating Companies. Our Operating Companies contributed in the developments in many aspects. In particular, they contributed with dedication in the specifications, system testing, prototyping and pilot implementations. In the R&D Center, a group of engineers and system analysts work on SAGRE design and implementation. SAGRE success is owed to all these people. References Magalhiies, G C, 1994, The development open systems for engineering applications: Proceedings of the XVII AM/FM International Conference, AM/FM International, Denver/CO, march 14-17, 1994. Oliveira, J., Cunha, C. and Magalhiies, G. Object model for dynamic visual interfaces construction: Proceedings of the IX Brazilian Symposium on Software Engineering, SBC, Recife/PE, October 3-6, 1995. (in Portuguese language) Dias, E., Granado, S., and Magalh~es, G. The use of versions to enforce consistency in hybrid operations and design environments. Proceedings of the IX Brazilian Symposium on Database, SBC, Recife/PE, October 2-4, 1995. (in Portuguese language) Gonqalves, J. Erhardt, M., Obata, F. and Granado, S. Outside plant records automation: Proceedings of the I Meeting of Telecommunications Networks and Terminal Equipment Quality, Be16m/PA, September 13-15, 1994. (in Portuguese language) Prezzoto, A., Teijero, D. and Obata, F. Telecommunications outside plant design automation: Proceedings of the II International Congress on Information Engineering, University of Buenos Aires, Argentina, November 14-15, 1995. Magalhiies, G., Giglliotti, A., Santos, C., Teijero, D., and Argondizio, E. Data conversion technical specification - TELEB~S proposal - SAGRE Project: Proceedings of GIS Brasil 94, Curitiba/PR, October 17-21, 1994. (in Portuguese language) | ||
|
|