Automated Repair Service Bureau: System Architecture

System Architecture B y R . L. MARTIN (Manuscript received June 29, 1981) The four main functions being served by the Automated Repair Service Bureau are (i) Customer Line Card Maintenance--a large, complex data base problem; (ii) Trouble-Taking and Tracking--a simple transaction problem; (Hi) Loop Testing--a process-control problem; and (iv) Trouble-History Review--a large, filter, sort, and count report-generation problem. All of these functions were implemented among different computers, which were then networked together to form the full ARSB architecture. This decomposition resulted in an architecture that has been adaptable to Bell Operating Companies' needs over a full decade. I. INTRODUCTION The architecture of a system is the product of the history of the organization which builds it, the present and near-present technology, and the intended application. The architecture of the Automated Repair Service Bureau (ARSB) is the result of several iterations, and many decisions. In retrospect, many of the decisions which we tortured over seem, given that the system works, clear and obvious. Hopefully, our experiences will be useful lessons for other similar developments. After describing the characteristics of the present ARSB architecture and the history which led to it, the major design decisions in its formation will be discussed. This will be followed by a slightly more detailed discussion of the architectures of the subcomponents of the system. 1.1 History The Loop Maintenance Operations System (LMOS), as an operations system for the Repair Service Bureau, was first conceived as a system 1115 in August, 1970, as part of a broad-reaching systems engineering study.