IATM : ISDN Automatic Test Manager

Back to Products

5. IATM external interfaces

7.4. IATM Exchange Fault Information view

This illustrates browser view showing EFI information. Note that this requires EFI to be fed into the IATM system from an external source. Tools exist to cross-reference this data to open fault reports.

7.5. Browser pane showing routiner information

"Routiner" allows directory numbers to be registered for checking against network alarms. The existence of a network alarm will cause the routiner entry to change colour and then a man can check the severity of the alarm and trigger the raise of an ISDN fault report if required.

7.6. Browser pane showing active "MSO"

It has been found from experience that often the customer fault report arrives in advance of the network alarm information. (Partly due to the route by which a network alarm can travel and the threshold settings inherent in triggering an alarm). The "MSO" (Major Service Outage) tool is an innovative tool that monitors fault reports coming from specific exchange areas. When the rate of fault reports breaches thresholds, the system marks each fault report as being part of a "suspected MSO". It is then up to a manual user to confirm the MSO. All current "suspected MSO" fault reports and all future fault reports from that exchange are then changed to have a "confirmed MSO" status. The robotic scripts are constructed so that it a job is marked as a "confirmed MSO", it is passed directly to the manual IATM users (via the "Task Browser". IATM then has bulk-tools for automatic re-testing, update, dispatch and closure of these fault reports.

The illustrated graph indicates the frequency of customer fault reports for a specific exchange.

7.7. Browser pane showing ISDN2 test script process control tables

IATM ISDN (ISDN2 and ISDN30) automatic rules encapsulate a complex process hand-tailored to match BT ISDN "expert diagnostic test officer" fault diagnostics. Without these rules it would be impossible for IATM to achieve the high level of automation of all BT ISDN fault reports.  The techniques for capturing and implementing these rules has been developed continuously since IATM's start in 1995. Because of City Computing's continuous involvement with this process, City Computing are the authors, maintainers and custodians of the test script documents on BT's behalf (ISDN2 for example is defined in a 90 page document with 25 flowcharts and 74 tables). The process represents the direct experience of 15 expert diagnostic test officers and BT process designers.

The screen-shot below illustrates the ISDN2 set of tables dictating the automatic diagnostic process. These tables can be manipulated as required by privileged users by means of the "Task Browser" interface.

Sample table editor form for one of the DC test based tables.

The tables exist in sets with a full revision history. This allows privileged members of the workforce to set rules on a day-by-day basis – for instance to use when the workload is high or when the workload is light. This allows the automation to handle a greater quantity of the workload when the men are busy or pass more to the manual diagnostics when workload is light.

8. Conclusion

IATM has fulfilled the customer’s requirements and is able to auto-dispatch 80% of ISDN faults.  To achieve this IATM uses access to structured fault reports, network alarms, ISDN diagnostic tools and infrastructure to dispatch engineers to appropriate locations. The rules by which IATM operates are flexible, extensible and are endorsed and understood by the expert diagnostic test officers. City Computing has been instrumental in capturing and structuring the expertise of ISDN diagnostic test officers – helping to unify best practice and ensuring that the expertise is retained and distributed. IATM forms a partnership with the users by means of the task-browser interface – the users and automatic processes interact on a common pool of fault reports, working side by side, each aware of the activities of the other. In this way the activities of both halves are reinforced and enhanced. IATM has allowed BT to co-ordinate fault information in new ways (EFI alongside customer fault reports), be proactive towards their customers and operate several technical centres in a co-ordinated way.
The software is modular, extensible, flexible and resilient.

The user interface has proved to be popular, readily understandable and able to  accommodate changing business requirements. Performance and handling statistics provided by IATM have proved valuable tools for identifying weaknesses and delays in the fault-repair process.

Since the start of IATM, the "Task Browser", IATM server and automation techniques have been successfully applied to many other areas of work (for example switchboard diagnostics, circuit provisioning and analogue private circuit testing). This has capitalised on the investment made in the technology and has made the possibility of a completely unified view within a single desktop application achievable.

previous page