NO310947B1

NO310947B1 - Procedures and mechanisms for enabling the creation and availability of troubleshooting strategies

Info

Publication number: NO310947B1
Application number: NO19954601A
Authority: NO
Inventors: Michael D Horton; Onofrio Schillaci; Raymond William Rischpater
Original assignee: Harris Corp
Priority date: 1994-11-14
Filing date: 1995-11-14
Publication date: 2001-09-17
Also published as: CN1133522A; AR000109A1; KR960020311A; JPH08265423A; AU704138B2; BR9504950A; NZ280453A; NO954601D0; CA2162763C; NO954601L; AU3777895A; CA2162763A1; KR100395224B1

Abstract

Feilsøkingsmekanisme som inngår i en telefonserviceteknikers bærbare computerenhet, for å gjøre det mulig for en operatør å svare på en "trouble ticket". Ved å analysere flere informasjonskilder, deriblant brukerinnganger fra operatøren, parameterdata som innbefattes i nevnte "trouble ticket", testdata fra gjennomførte lokale tester og f jerntestdata, vil feilsøkingsmekanismen avlede og foreslå en problemavhjelpingsstrategi som synes velegnet.I systemoppbygningen inngår en feilsøkingsbruksinnretning med et tilhørende sett av databaser, hvorav den ene er en kjennskapsdatabase og den annen er en delt parameterdatabase. Kjennskapsdatabasen inneholder regler og statiske parametre som definerer karakteristikkene og virkemåten av bruks innretningen. Regelsettene og informasjonen er spesiell for telefonlinjefeilsøking.Troubleshooting mechanism included in a telephone service technician's laptop computer unit, to enable an operator to respond to a "trouble ticket". By analyzing several sources of information, including user inputs from the operator, parameter data included in the mentioned "trouble ticket", test data from completed local tests and iron test data, the troubleshooting mechanism will divert and suggest a problem-solving strategy that seems suitable. of databases, one of which is a knowledge database and the other is a shared parameter database. The knowledge database contains rules and static parameters that define the characteristics and operation of the operating device. The rule sets and information are specific to telephone line troubleshooting.

Description

Den foreliggende oppfinnelse vedrører fremgangsmåter for henholdsvis opprettelse og tilgjengeliggjøring av en feilsøkingsstrategi i en abonnentlinje, som angitt i innledningen i de selvstendige krav 1 og 8. The present invention relates to methods for respectively creating and making available a troubleshooting strategy in a subscriber line, as stated in the introduction in the independent claims 1 and 8.

Oppfinnelsen vedrører dessuten mekanismer for henholdsvis bærbare testenheter og kommunikasjons- og behandlingsenheter for testing og tilgjengeliggjøring av en feilsøkingsprosess, som angitt i innledningen i de selvstendige krav 4 og 6. The invention also relates to mechanisms for portable test units and communication and processing units respectively for testing and making available a troubleshooting process, as stated in the introduction in the independent claims 4 and 6.

Fremgangsmåtene ifølge oppfinnelsen kjennetegnes ved de trekk som er angitt i karakteristikken i de selvstendige krav 1 og 8. The methods according to the invention are characterized by the features indicated in the characteristics in the independent claims 1 and 8.

Mekanismene ifølge oppfinnelsen er kjennetegnet ved de trekk som er angitt i karakteristikken i de selvstendige krav 4 og 6. The mechanisms according to the invention are characterized by the features indicated in the characteristics in the independent claims 4 and 6.

Den overvåkende kontrollmekanismes testsystems-funksjon som utøves av den innvendige prosessor i opera-tørens håndholdte computerenhet, har som hensikt å gi serviceteknikeren adgang til en brukervennlig, bildebasert testprosess som vil lette operatørens gjennomføring av forskjellige tester på en valgt linje, hvorved operatørens bærbare computer kan samvirke vekselvis med flere typer av eksisterende driftsstøttesystemer, samt danne en plattform for utvekslinger av tilleggsinformasjon. The monitoring control mechanism's test system function, performed by the internal processor in the operator's hand-held computer unit, is intended to give the service technician access to a user-friendly, image-based test process that will facilitate the operator's execution of various tests on a selected line, whereby the operator's laptop can cooperate alternately with several types of existing operational support systems, as well as form a platform for exchanges of additional information.

Oppfinnelsen har formålstjenlig befatning med en spesiell utførelse av en slik overvåkende kontrollmekanisme, som under drift kan analysere flere informasjonskilder, deriblant brukerinnganger fra operatøren, parameterdata i klarereren ("trouble ticket"), testdata innsamlet under gjennomføring av lokale tester, og fjerntestdata (f.eks. fra et mekanisk sløyfetestings-(MLT-)system), og avlede fra disse en feilsøkingsstrategi som vil gjøre det mulig for operatøren hurtig å fastslå årsaken til problemet som forårsaket frembringelsen av nevnte "trouble ticket". The invention is expediently concerned with a particular embodiment of such a monitoring control mechanism, which during operation can analyze several sources of information, including user inputs from the operator, parameter data in the clearer ("trouble ticket"), test data collected during execution of local tests, and remote test data (e.g. eg from a mechanical loop testing (MLT) system), and derive from these a troubleshooting strategy that will enable the operator to quickly determine the cause of the problem that caused the generation of said "trouble ticket".

Systemoppbygningen omfatter fordelaktig et informa-sjonsbehandlingsundersystem, en feilsøkende funksjonsmotor og et tilhørende sett av databaser hvorav den ene er en kjennskaps- eller "erfarings-"database og den annen er en delt parameterdatabase. Kjennskapsdatabasen inneholder j regler og statiske parametre som definerer karakteri- I stikkene og virkemåten av funksjonsmotoren. Regelsettene og informasjonen er brukspesiell, i dette tilfelle tele-fonlinje-feilsøkingspesiell, er opprettet i overens- i stemmelse med en rigorøs diagnose-evaluering av alle mulige problemer som kan oppstå på en linje, de mulige årsaker til slike problemer og anbefalte prosesser for å reparere linjen og derved fjerne feilen. Etter som systemet stilles overfor nye problemegenskaper og avhjelpingsprosesser, oppdateres kjennskapsdatabasen med slik informasjon, for at funksjonsmotoren skal kunne foreta en bedre informert avgjørelse for tilråding av en feilsøk-ingsstrategi . The system structure advantageously comprises an information processing subsystem, a fault-finding function engine and an associated set of databases, one of which is a knowledge or "experience" database and the other is a shared parameter database. The knowledge database contains j rules and static parameters that define the characteristics and operation of the function engine. The rulesets and information are application specific, in this case telephone line troubleshooting specific, created in accordance with a rigorous diagnostic evaluation of all possible problems that may occur on a line, the possible causes of such problems and recommended processes to repair the line and thereby remove the fault. As the system is faced with new problem characteristics and remedial processes, the knowledge database is updated with such information, so that the function engine can make a better informed decision for recommending a troubleshooting strategy.

De data som lagres i den delte database, kan stamme The data stored in the shared database can stem

fra flere ytre kilder og eksempelvis være innsamlet gjJnn-om en automatisk bilutsendings-arbeidsordreprogram-styreranordning, f . eks . en AT&T CAS (craft access system-) anord-ning, teknisk tilgangsnettverk (TAN) eller automatisk from several external sources and, for example, have been collected using an automatic car dispatch work order program control device, e.g. e.g. an AT&T CAS (craft access system) device, technical access network (TAN) or automatic

i in

arbeidsadministrasjonssystem (AWAS), måledata fra det bærbare testutstyr (PTE), eller innmatede data fra brukeren. work administration system (AWAS), measurement data from the portable test equipment (PTE), or input data from the user.

Den feilsøkende funksjonsraotor er operativ for å bruke reglene og parametrene fra kjennskapsdatabasen for å opprette et felt av mulige/sannsynlige feilskapere i forbindelse med eller i tilknytning til et kritisk punkt i et sett av kontrollparametre. De mulige feilskapere i et gitt felt er de som viser ett eller flere symptomer som av-sløres av testparameterverdiene. Ved bruk av testparameterdata i den delte database kan den feilsøkende funksjonsmotor konsentrere feltet av mulige feilskapere til et gradvis mindre antall av muligheter, helt til den mest sannsynlige årsak til problemet er fastslått. The fault finding function rotor is operative to use the rules and parameters from the knowledge database to create a field of possible/probable fault creators in connection with or in connection with a critical point in a set of control parameters. The possible fault creators in a given field are those that show one or more symptoms revealed by the test parameter values. Using test parameter data in the shared database, the fault finding function engine can concentrate the field of possible fault creators to a progressively smaller number of possibilities, until the most likely cause of the problem is determined.

Særlig og fordi den delte database oppdateres dynamisk med testresultatsinformasjon fra målinger som er foretatt på linjen eller fra et brukssystem, vil funksjonsmotoren behandle denne informasjon i overensstemmelse med regelsettet i kjennskapsdatabasen og utelukke, fra feltet av mulige feilskapere, de punkter som ikke lenger har tilstrekkelig nær tilknytning til det kontrollpunkt som er basert på det forhold som spesifiseres av kontroll-modellen. Feltet reduseres til sist til et enkelt, mest sannsynlig feilskaperpunkt som funksjonsmotoren utnytter for frembringelse av en hjelpestrategimelding til operatøren gjennom computerens bildeskjerm. In particular, and because the shared database is dynamically updated with test result information from measurements made on the line or from an application system, the function engine will process this information in accordance with the rule set in the knowledge database and exclude, from the field of possible error creators, the points that are no longer sufficiently close connection to the control point which is based on the relationship specified by the control model. The field is finally reduced to a single, most likely error-creating point which the function engine utilizes to produce an auxiliary strategy message to the operator through the computer's image screen.

I overensstemmelse med den driftsflytsekvens som gjennomføres av feilsøkingsstrategi-utviklingsmekanismen ifølge oppfinnelsen, som skal beskrives, vil teknikeren, når en operatør utsendes til et arbeidssted og oppretter en forbindelse med det nødvendige fjernanlegg, f.eks. en sentral med tilhørende datasenter, nedlaste all tilgjengelig informasjon for den "trouble ticket" som betjenes, og som kan innbefatte utgangen fra anvendt testutstyr, for å opprette parameterdata for den linje som betjenes, som vil gjøre det mulig for funksjonsmotoren å bedømme feilårsaken. In accordance with the operational flow sequence carried out by the troubleshooting strategy development mechanism of the invention to be described, when an operator is dispatched to a work site and establishes a connection with the required remote facility, e.g. a switchboard with an associated data center, download all available information for the "trouble ticket" being serviced, which may include the output from the test equipment used, to create parameter data for the serviced line, which will enable the function engine to judge the cause of the failure.

- I - I

De nedlastede testparameterdata ledsages av en foreskrevet testidentifikasjons-(VER-)kode som assosierer den test som er foretatt av det mekaniske testutstyr, med The downloaded test parameter data is accompanied by a prescribed test identification (VER) code that associates the test performed by the mechanical test equipment with

regelsettet i kjennskapsdatabasen. Når testmålingen og datanedlastingen er fullført, presenteres det for brukeren en skjerm som inneholder en valgmeny som kan innbefatte ytterligere testing av linjen eller andre funksjoner. Idet the rule set in the knowledge database. When the test measurement and data download is complete, the user is presented with a screen containing a selection menu that may include additional testing of the line or other functions. The idea

funksjonsmotoren utvikler en feilsøkingsstrategi basert på en diagnose-evaluering av nevnte "trouble ticket" og tilgjengelige måledata som er lagret i den delte database, vil graden av erfaring eller fagkunnskap hos teknik-eren ikke hindre et vellykket valg av menyposter, for gjennom-føring av oppgaven. the function engine develops a troubleshooting strategy based on a diagnostic evaluation of the aforementioned "trouble ticket" and available measurement data stored in the shared database, the degree of experience or professional knowledge of the technician will not prevent a successful selection of menu items, for the implementation of the task.

Hver menyskjerm inneholder et "hjelp"-bilde. Når dette bilde påkalles, vil funksjonsmotoren fremvise for brukeren en melding som angir resultatene av dens analyse av den i øyeblikket tilgjengelige informasjon i kjennskaps- og den delte database og tilråde hva teknikeren nærmest bør gjøre. Funksjonsmotoren spesifiserer deretter hvilken metode som skal gjennomføres, basert på VER-koden og tilgjengelige testparameterdata. Ut fra den valgte metode vil det fremvises en melding som instruerer brukeren om hva som bør gj øres. Each menu screen contains a "help" image. When this image is invoked, the function engine will present to the user a message indicating the results of its analysis of the currently available information in the familiarity and the shared database and recommending what the technician should do next. The function engine then specifies which method to execute, based on the VER code and available test parameter data. Based on the chosen method, a message will be displayed that instructs the user on what should be done.

Dersom foreløpig informasjon fra nevnte "trouble ticket" og resultatene av de første testmålinger er tilstrekkelige til at funksjonsmotoren skal kunne fastslå årsaken til en feil, frembringes en lokaliserings- og reparasjonsscenariomelding. Funksjonsmotoren er operativ for å koordinere datafangst og analyse, deriblant påkalling av en ytre test funksjon (f .eks. en ordre til DATTjj om å åpne abonnent1injen), og observasjonen eller målingen av linjens reaksjon på den påkalte prosess (f.eks. avles-ing av reaksjonen av et testingshode som overvåke den linje som f.eks. ved krav om at en DATU skal åpne linjen, bør bevirke at testingshodet blir spenningsløst). If preliminary information from the aforementioned "trouble ticket" and the results of the first test measurements are sufficient for the function engine to be able to determine the cause of a fault, a location and repair scenario message is generated. The function engine is operative to coordinate data capture and analysis, including the invocation of an external test function (e.g. an order to DATTjj to open the subscriber line), and the observation or measurement of the line's reaction to the invoked process (e.g. read- ing the reaction of a test head monitoring the line (eg when a DATU is required to open the line, should cause the test head to become de-energized).

Dersom ytterligere testing av linjen er nødvendig, kan en utsendt melding instruere brukeren om igjen å foreta én eller flere ekstra tester. Instruksjonsmeldings- If further testing of the line is necessary, a message sent out can instruct the user to carry out one or more additional tests again. instruction message

I IN

skjermbilder opprettes derfor suksessivt, etter, behov, og brukeren instrueres om å avlede mer informasjon, f.eks. ved bruk av testingshodet, til den feilsøkende funksjonsmotor har konsentrert et felt av mulige årsaker til en sannsynlig enkeltkilde. Den fremviste melding representer-er ikke bare resultatene av funksjonsmotorens analyse av nevnte "trouble ticket" samt test- og parameterdata, men inneholder også praktisk informasjon for teknikeren. Operatøren kan deretter fortsette med gjennomføringen av den foreslåtte korrigeringsprosess, for å rette feilen. Deretter kan linjen testes igjen, for å verifisere reparasj onen. Screen images are therefore created successively, as needed, and the user is instructed to derive more information, e.g. using the test head, until the fault finding function engine has concentrated a field of possible causes to a likely single source. The displayed message represents not only the results of the function engine's analysis of the aforementioned "trouble ticket" as well as test and parameter data, but also contains practical information for the technician. The operator can then proceed with the implementation of the proposed correction process, to correct the error. The line can then be tested again to verify the repair.

Oppfinnelsen er nærmere beskrevet i det etterfølgende i tilknytning til de medfølgende tegninger, hvori: Fig. 1 viser skjematisk den generelle oppbygning av det bærbare telekommunikasjonstestsystem. Fig. 2 viser den fundamentale systemoppbygning ifølge oppfinnelsen, omfattende et informasjonsbehandlingsunder-system, en feilsøkende funksjonsmotor og et tilhørende sett av kjennskaps- og delte parameterdatabaser. Fig. 3 viser skjematisk et felt med punkter som angir mulige årsaker til henholdsvis potensiell forskjellig anomali eller mulige feil som forårsaker det problem som har fremtvunget utviklingen av en "trouble ticket" for en gitt linje som skal testes. Fig. 4 viser respektive trinn i en driftsflytsekvens som anvendes i mekanismen for utvikling av en feilsøk-ingsstrategi, basert på informasjon og reaksjonstesting. Fig. 1 viser skjematisk den generelle oppbygning av et bærbart telekommunikasjons-testsystem som omfatter en håndholdt PC-basert test- og kommunikasjonsenhet 10 hvormed en operatør som er utsendt av et klareringssenter til et servicested, som kan befinne seg i avstand fra en sentral 12 som betjener en linje som skal testes (eller linjer under testing (LUT)) 16, kan kommunisere med sentralen 12 og med et felles testingshode 14 som kan sammenkoples med LUT 16. The invention is described in more detail below in connection with the accompanying drawings, in which: Fig. 1 schematically shows the general structure of the portable telecommunications test system. Fig. 2 shows the fundamental system structure according to the invention, comprising an information processing sub-system, a fault-finding function engine and an associated set of knowledge and shared parameter databases. Fig. 3 schematically shows a field with points that indicate possible causes for respectively potential different anomalies or possible errors that cause the problem that has forced the development of a "trouble ticket" for a given line to be tested. Fig. 4 shows respective steps in an operational flow sequence used in the mechanism for developing a troubleshooting strategy, based on information and reaction testing. Fig. 1 schematically shows the general structure of a portable telecommunications test system comprising a hand-held PC-based test and communication unit 10 with which an operator dispatched by a clearance center to a service location, which may be located at a distance from a central 12 which serves a line to be tested (or lines under test (LUT)) 16, can communicate with the exchange 12 and with a common testing head 14 which can be connected to the LUT 16.

Den overvåkende kontrollmekanismes testsystems-funksjon som utøves av den innvendige prosessor i opera-tørens håndholdte PC-enhet 10, har som hensikt å gi operatøren adgang til en brukervennlig, bildebasert testprosess som vil lette operatørens gjennomføring av ulike tester på en valgt linje. Operatørens bærebare computer er derved i stand til å samvirke vekselvis med flere typer av eksisterende driftsstøttesystemer og å danne en plattform for utvekslinger av tilleggsinformasjon. The monitoring control mechanism's test system function, which is performed by the internal processor in the operator's hand-held PC unit 10, aims to give the operator access to a user-friendly, image-based test process that will facilitate the operator's execution of various tests on a selected line. The operator's portable computer is thereby able to interact alternately with several types of existing operational support systems and to form a platform for exchanges of additional information.

I dette øyemed og gjennom et kompaktfølsomt (eksempelvis pennberøringsstyrt) videoskjermpanel 15 og et tilhørende tastbord 17 i den håndholdte computerenhet 10 kan operatøren selektivt påkalle én eller flere testprosesser som representeres av et sett analyse- og test-funksjonstilknyttede bilder. Som reaksjon på disse valg vil den innvendige kontrollprosessor i enheten 10 gjennom-føre kommunikasjons- og signalbehandlingsprosesser i tilknytning til en identifisert test. Testingshodet 14 fore-tar korrekt datafangst på ordre fra den personlige computerenhet 10, deriblant utførelse av funksjonstester. Testingshodet 14 og den håndholdte PC-enhet 10 kan utvides med innpluggingskort og programvare for sammenkopling med kommunikasjonslenker av flere forskjellige typer. To this end and through a compact sensitive (for example pen touch controlled) video display panel 15 and an associated keyboard 17 in the hand-held computer unit 10, the operator can selectively call up one or more test processes which are represented by a set of analysis and test function-related images. In response to these choices, the internal control processor in the unit 10 will carry out communication and signal processing processes in connection with an identified test. The testing head 14 correctly captures data on orders from the personal computer unit 10, including performance of function tests. The test head 14 and the handheld PC unit 10 can be expanded with plug-in cards and software for interfacing with communication links of several different types.

For kommunisering med et fjernt nettverksanlegg (sentral 12 eller datasenter 18 i tilknytning til sentralen 12) innbefatter operatørens computerenhet 10 et sender/ For communication with a remote network facility (switchboard 12 or data center 18 in connection with the switchboard 12) the operator's computer unit 10 includes a transmitter/

mottaker-grensesnitt som også er forbundet med et kommunikasjons- og signalbehandlingsundersystem i teknikerens servicevogn eller -bil 20. Kommunikasjons- og signal-behandlingsundersystemet i bilen forbinder i sin tur operatørens håndholdte enhet 10 med det fjerne nettverksanlegg gjennom en trådløs kortavstandslenke eller gjennom en ekstra reservekabellenke. De respektive kommunikasjoner er grensesnitt-tilpasset i en operatørs bærbare enhet og et bil-undersystem. receiver interface which is also connected to a communication and signal processing subsystem in the technician's service van or car 20. The communication and signal processing subsystem in the car in turn connects the operator's handheld device 10 to the remote network facility through a short-range wireless link or through an additional backup cable link . The respective communications are interfaced in an operator's wearable device and a car subsystem.

Operatøren kan være utstyrt med en taleaktivisert, trådløs hjelpe-hodetelefon for overføring av trådløse taleforbindelser med den håndholdte computerenhet. En slik trådløs hodetelefon kan anvendes sammen med den håndholdte computer og testingshodet, for gjennomføring av automatiske tester, hvorved en hørbar klar/ikke-klar indikasjon av testresultatene fremføres for operatøren. The operator may be equipped with a voice-activated, wireless auxiliary headset for transmitting wireless voice connections with the handheld computing device. Such a wireless headset can be used together with the hand-held computer and the testing head, for carrying out automatic tests, whereby an audible clear/not clear indication of the test results is presented to the operator.

Servicebilens kommunikasjons- og signalbehandlingsundersystem 22 innbefatter en batteriholder/ladestasjon 24, en skriver 26, et trådløst langavstands-grensesnitt 28 og en nettverkbetjener 29. Batteriholderen/ladestasjonen 24 er anordnet for å oppta og oppbevare den håndholdte computerenhet 10, slik at denne kan forankres og lagres, og dens tilhørende strømkilde (batteripakke) opplades, når den ikke er i bruk. Skriveren 26 benyttes for utskriving av forskjellige testresultater eller annen informasjon. Det trådløse langavstands-grensesnitt 2 8 danner en trådløs inngang til trådløse langavstands-service, mens nettverk-bet j eneren 29 innbefatter en fil-betjener for ekstra behandlingsstrøm og elektronisk datalagring. Nettverk-bet jeneren 2 9 er operativ for gjennom-føring av hjelpe-databehandlingsprosesser på ordre fra computerenheten 10. The service vehicle's communication and signal processing subsystem 22 includes a battery holder/charging station 24, a printer 26, a wireless long-distance interface 28 and a network operator 29. The battery holder/charging station 24 is arranged to receive and store the hand-held computer unit 10, so that it can be docked and is stored, and its associated power source (battery pack) is charged when not in use. The printer 26 is used for printing various test results or other information. The wireless long-distance interface 28 forms a wireless entrance to wireless long-distance service, while the network server 29 includes a file server for additional processing power and electronic data storage. The network bet generator 2 9 is operational for carrying out auxiliary data processing processes on orders from the computer unit 10.

I sentralen 12 inngår typisk en omkopler 31, test-ingsanordninger 33 og en linjekondisjoneringsanordning 35, såsom en direkte tilgangtestenhet (DATU) eller et transmisjonskondisjoneringssystem (SASS). Testanordningene 33 kan opprette et grensesnitt med forskjellige driftsstøtte-systemer i datasenteret 18, f.eks. en servicebil-tidsklar-erer, en ytteranleggsregistreringsdatabase, automatiske testsystemer og elektroniske nettverksskjema. Linje-kondensjoneringsanordningen (eksempelvis DATU eller SASS) 35 i sentralen 12 gjør det mulig for operatøren selektivt å gjennomføre et antall tester av en linje, ved påkalling av spesielle nøkkelkombinasjoner (sekvenser) fra et standard-telefontestsett. The exchange 12 typically includes a switch 31, testing devices 33 and a line conditioning device 35, such as a direct access test unit (DATU) or a transmission conditioning system (SASS). The test devices 33 can create an interface with various operational support systems in the data center 18, e.g. a service car timetable, an outpost registration database, automatic testing systems and electronic network charts. The line condensing device (eg DATU or SASS) 35 in the exchange 12 enables the operator to selectively carry out a number of tests of a line, by invoking special key combinations (sequences) from a standard telephone test set.

Under gjennomføringen av en test ved hjelp av testingshodet 14 vil operatøren personlige computerenhet 10 motta de målte data fra testingshodet og bearbeide disse, for å omforme måleresultatene til brukbar parameter-informasjon. Informasjonen forbindes deretter med betjen-ingsbilens kommunikasjonsundersystem 22, slik at passende kommandoer kan fremføres til en linjekondisjoneringsanordning eller et automatisk testutstyr i sentralen 12. During the execution of a test using the testing head 14, the operator's personal computer unit 10 will receive the measured data from the testing head and process this, in order to transform the measurement results into usable parameter information. The information is then connected to the service car's communication subsystem 22, so that appropriate commands can be forwarded to a line conditioning device or automatic test equipment in the central 12.

I et ikke-begrensende eksempel på svar på en "trouble ticket" som er utsendt fra et klareringssenter og inneholder en kundes service-fordring, fungerer systemet •ifølge fig. 1 som følger. Etter å være utsendt til et testingssted (ved bruk av servicebilene 20) kopler operatøren testingshodet 14 sammen med linjen 16 under testing. Ved bruk av den bærbare computerenhet 10 oppretter teknikeren deretter forbindelser med testingshodet 14 og, gjenn-om kommunikasjonsundersystemet 22 i bilen 20, med sentralen, slik at én eller flere tester av linjen kan foretas. In a non-limiting example of a response to a "trouble ticket" that is issued from a clearinghouse and contains a customer's service claim, the system works according to fig. 1 as follows. After being dispatched to a testing location (using the service vehicles 20), the operator connects the testing head 14 to the line 16 during testing. When using the portable computer unit 10, the technician then establishes connections with the testing head 14 and, through the communication subsystem 22 in the car 20, with the central office, so that one or more tests of the line can be carried out.

Etter at teknikeren har sammenkoplet testingshodet 14 med linjen under testing, blir testingsbruksprogrammet i den håndholdte computerenhet 10 operativt for fremvising av bilder i forbindelse med de respektive testprosesser for evaluering av LUT ved hjelp av den kontaktfølsomme computerbildeskjerm 15. Som svar på at serviceteknikeren velger en ønsket testfunksjon, vil programmet i computerenheten 10 vekselvis frembringe ytterligere menyer hvorigjennom operatøren spesifiserer flere valg for definering av de nødvendige parametre for gjennomføring av den valgte test. Basert på operatørens valg vil computerenheten 10 samle og overføre en melding til testingshodet 14 og til sentralen 12, for fastlegging av den eller de tester som skal utføres og parametrene i tilknytning til disse tester. After the technician has connected the test head 14 to the line under test, the test user program in the hand-held computer unit 10 becomes operative to display images in connection with the respective test processes for evaluating the LUT by means of the touch-sensitive computer image display 15. In response to the service technician selecting a desired test function, the program in the computer unit 10 will alternately produce additional menus through which the operator specifies several options for defining the necessary parameters for carrying out the selected test. Based on the operator's choice, the computer unit 10 will collect and transmit a message to the testing head 14 and to the central 12, for determining the test(s) to be performed and the parameters associated with these tests.

Med henblikk på en valgt test vil testingshodet måle linjens reaksjon på én eller flere opprettede tilstander på linjen og oversende testreaksjonsdata tilbake til computerenheten 10 for innføring i lageret og analyse i overensstemmelse med en på stedet-test eller et linje-analyseprogram. Basert på resultatene av den behandlende informasjon kan operatøren styre testutstyret for gjennom-føring av én eller flere ytterligere tester, til linjen er fullstendig testet. For a selected test, the test head will measure the line's response to one or more established conditions on the line and transmit test response data back to computer unit 10 for entry into storage and analysis in accordance with an on-site test or a line analysis program. Based on the results of the processing information, the operator can control the test equipment to carry out one or more additional tests, until the line is fully tested.

Innen den nye og forbedrede automatiske feilsøkings-mekanisme ifølge oppfinnelsen beskrives detaljert, bør det påpekes at oppfinnelsen først og fremst vedrører det som i realiteten er et innbefattet informasjonsbehandlingsunder-system, og et tilhørende sett av databaser for anvendelse i det overvåkende kontroilprogram i den ovennevnte opera-tørs bærbare computerenhet. En av disse databaser er en kjennskaps- eller "erfarings"-database som inneholder regler og statiske parametre som anvendes av informasjonsbehandlingsundersystemet for definering av dets karakteristikker og virkemåter. Den andre database er en delt database hvori råparameterdata i tilknytning til linjen under testing lagres. Informasjonsbehandlingsundersystemet ifølge oppfinnelsen danner derfor i realiteten en feil-søkende funksjonsmotor med kunstig intelligens, som utnytter kjennskaps- og erfaringsreglene i kjennskapsdatabasen, for å evaluere de data som er lagret i den delte database, for å finne et anbefalt handlingsforløp som gjør det mulig for operatøren å løse det problem som presenteres på nevnte "trouble ticket". Before the new and improved automatic fault finding mechanism according to the invention is described in detail, it should be pointed out that the invention primarily relates to what is in reality an included information processing sub-system, and an associated set of databases for use in the monitoring control program in the above-mentioned opera - dry laptop device. One of these databases is a knowledge or "experience" database that contains rules and static parameters used by the information processing subsystem to define its characteristics and operations. The second database is a shared database in which raw parameter data associated with the line under testing is stored. The information processing subsystem according to the invention therefore in reality forms a fault-finding function engine with artificial intelligence, which utilizes the knowledge and experience rules in the knowledge database, to evaluate the data stored in the shared database, to find a recommended course of action that makes it possible for the operator to solve the problem presented on the aforementioned "trouble ticket".

Tegningene som viser oppfinnelsen, omfatter bare disse spesielle detaljer i en praktisk funksjonsmessig gruppering. The drawings showing the invention include only these particular details in a practical functional grouping.

Fig. 2 viser den fundamentale systemoppbygning, omfattende et informasjonsbehandlende undersystem, en feil-søkende funksjonsmotor 41 og et tilhørende sett av databaser 43 og 45. Databasen 43 er en kjennskaps- eller "erfårings"-database som inneholder regler og statiske parametre som definerer funksjonsmotorens 41 karakteristikker og virkemåte. Fig. 2 shows the fundamental system structure, comprising an information processing subsystem, a fault-finding function engine 41 and an associated set of databases 43 and 45. The database 43 is a knowledge or "experience" database that contains rules and static parameters that define the function engine's 41 characteristics and mode of operation.

Regelsettene og informasjonen som er lagret i databasen 45, er bruksspesiell, i dette tilfelle telefonlinje-feilsøkingsspesiell og opprettet i overensstemmelse med en streng diagnose-evaluering av alle mulige problemer som kan forekomme på en linje, de mulige kilder til slike problemer og anbefalte prosesser for reparering av linjen og derved fjerning av feilen. Videre og etter som systemet erfarer nye problemattributter og avhjelpingsprosesser i tilknytning til disse problemer, oppdateres kjennskapsdatabasen med denne informasjon, for at funksjonsmotoren skal kunne foreta en bedre informert avgjørelse for tilråding av en feilsøkingsstrategi. The rulesets and information stored in the database 45 are application specific, in this case telephone line troubleshooting specific, and created in accordance with a rigorous diagnostic evaluation of all possible problems that may occur on a line, the possible sources of such problems, and recommended processes for repairing the line and thereby removing the fault. Furthermore, as the system experiences new problem attributes and remedial processes in connection with these problems, the knowledge database is updated with this information, so that the function engine can make a better informed decision for recommending a troubleshooting strategy.

Databasen 4 5 er en delt database hvori det lagres parameterdata i tilknytning til linjen under testing. Slike data kan stamme fra forskjellige ytre kilder, såsom data innhentet gjennom en arbeidsordre-programstyreranord-ning 51 (f.eks. den tidligere omtalte AT&T CAS-(craft access system-)anordning, tekniker-tilgangsnettverk (TAN) eller automatisk arbeidsadministrasjonssystem (AWAS)), testutstyr fra bærbart testutstyr (PTE) eller innmatede data fra brukeren) , måledata fra det bærbare testutstyr (PTE) 52 eller fra brukeren 53. The database 4 5 is a shared database in which parameter data is stored in connection with the line under testing. Such data may originate from various external sources, such as data obtained through a work order program management device 51 (eg, the previously discussed AT&T CAS (craft access system) device, technician access network (TAN), or automatic work administration system (AWAS) )), test equipment from portable test equipment (PTE) or input data from the user), measurement data from the portable test equipment (PTE) 52 or from the user 53.

Funksjonsmotoren 41 utnytter kjennskaps- og erfaringsreglene i kjennskapsdatabasen 43 for evaluering av rådataene i den delte database 45, med henblikk på et anbefalt handlingsforløp for operatøren, slik at denne kan løse problemet som presenteres på nevnte "trouble ticket". I dette øyemed benyttes en funksjonsmotor 41 som leveres The function engine 41 utilizes the knowledge and experience rules in the knowledge database 43 for evaluating the raw data in the shared database 45, with a view to a recommended course of action for the operator, so that he can solve the problem presented on the aforementioned "trouble ticket". For this purpose, a function motor 41 is used which is supplied

av Stanford University, Palo Alto, Cal., under betegnelsen "The Coarse Program Model", som ved anvendelse av reglene og parametrene i kjennskapsdatabasen 43, oppretter et felt av mulige, sannsynlige feilårsaker i forbindelse med eller i tilknytning til et kritisk punkt for et sett av kontrollparametre. De mulige feilårsaker i et gitt felt er de som kjennetegnes ved ett eller flere symptomer som avsløres av testparameterverdiene. Ved anvendelse av testparameterdata som er innført i den delte database 45 og som er avledet fra en ytre kilde f .eks. et linjemålings-testingshode, eller innført eksempelvis av serviceteknikeren, vil funksjonsmotoren 41 konsentrere feltet av mulige feilårsaker til et gradvis mindre antall, helt til den mest sannsynlige årsak til problemet er fastslått. of Stanford University, Palo Alto, Cal., under the designation "The Coarse Program Model", which, by applying the rules and parameters of the knowledge database 43, creates a field of possible, probable causes of failure in connection with or adjacent to a critical point for a set of control parameters. The possible causes of failure in a given field are those characterized by one or more symptoms revealed by the test parameter values. When using test parameter data that is entered in the shared database 45 and that is derived from an external source, e.g. a line measurement testing head, or introduced for example by the service technician, the function engine 41 will concentrate the field of possible error causes to a progressively smaller number, until the most likely cause of the problem is determined.

Denne prosess er illustrert skjematisk i fig. 3 som viser et felt av punkter pl, p2, p3, .... , pn som angir mulige feilårsaker i forbindelse med henholdsvis forskjellig potensiell anomali eller feilkilder som er årsak til det problem som har fremtvunget utviklingen av en "trouble ticket" for en gitt linje som skal testes. I.det ikke-begrensende eksempel ifølge fig. 3 har punktet pl tilknytning til en jordingsfeil, punkt p2 tilknytning til en krysskopling til et arbeidende par og punkt p3 tilknytning til en åpen linje. This process is illustrated schematically in fig. 3 which shows a field of points pl, p2, p3, .... , pn which indicate possible error causes in connection with different potential anomalies or error sources which are the cause of the problem which has forced the development of a "trouble ticket" for a given line to be tested. I. the non-limiting example according to fig. 3, point pl is connected to an earth fault, point p2 is connected to a cross connection to a working pair and point p3 is connected to an open line.

Fordi databasene som anvendes av den feilsøkende funksjonsmotor, er oppdatert med nyere informasjon, og særlig fordi den delte database 45 oppdateres dynamisk med testresultatinformasjon, avledet fra målinger som er foretatt på linjen eller fra et brukssystem, såsom data som er avledet eksempelvis fra det bærbare testutstyr, vil funksjonsmotoren 41 behandle denne informasjon i overensstemmelse med regelsettet i kjennskapsdatabasen og utelukke fra feltet av mulige feilårsaker de punkter som ikke lenger er tilstrekkelig nært knyttet til kontrollpunktet som er basert på det forhold som er spesifisert av kontroll-modellen. Dette felt reduseres til sist til et enkelt punkt som angir den mest sannsynlige feilårsak og som anvendes av funksjonsmotoren 41 for å frembringe en avhjelpingsstrategimelding til operatøren gjennom computerbildeskj ermen. Because the databases used by the fault-finding function engine are updated with newer information, and in particular because the shared database 45 is dynamically updated with test result information, derived from measurements made on the line or from a utility system, such as data derived for example from the portable test equipment , the function engine 41 will process this information in accordance with the rule set in the knowledge database and exclude from the field of possible error causes those points which are no longer sufficiently closely linked to the control point which is based on the relationship specified by the control model. This field is finally reduced to a single point indicating the most likely cause of failure and which is used by the function engine 41 to produce a remedial strategy message to the operator through the computer screen.

Driftsflytsekvensen hos en mekanisme for opprettelse av en f eilsøkingsstrategi basert på informasjon og reaksjonstesting i overensstemmelse med en utførelsesform av oppfinnelsen, er vist i fig. 4 og beskrevet i det etter-følgende. Når en abonnent eller kunde oversender en servicefordring til et automatisk reparasjonsserviceanlegg The operational flow sequence of a mechanism for creating a troubleshooting strategy based on information and reaction testing in accordance with an embodiment of the invention is shown in fig. 4 and described in the following. When a subscriber or customer submits a service request to an automatic repair service facility

vil bestyreren på reparasjonsanlegget bekrefte mottakelsen °9 opprette en "trouble ticket". En operatør sendes deretter ut til et spesielt sted hvor linjen som forårsaket det rapporterte problem, kan testes og betjenes. the manager at the repair facility will confirm receipt °9 create a "trouble ticket". An operator is then dispatched to a special location where the line causing the reported problem can be tested and serviced.

Etter å ha ankommet til arbeidsstedet og opprettet en forbindelse med det nødvendige fjernanlegg (sentral med tilhørende datasenter) gjennom de trådløse eller trådover-førende kommunikasjonsundersystemer i den bærbare computerenhet og servicebil, som beskrevet i den ovennevnte Horton et al-søknad vil teknikeren, i trinn 4 01, nedlaste enhver tilgjengelig informasjon for nevnte "trouble ticket" som behandles. After arriving at the work site and establishing a connection with the required remote facility (switchboard with associated data center) through the wireless or wired communication subsystems of the portable computing unit and service vehicle, as described in the above Horton et al application, the technician will, in steps 4 01, download any available information for said "trouble ticket" being processed.

I denne første prosess inngår vanligvis bruken av en arbeidsordre-styreranordning, f.eks. den ovennevnte CAS-anordning, og det kreves at operatøren bruker testutstyr, f.eks. et SASS-transmisjonskondisjoneringssystem eller en direkte-tilgangstestenhet (DATU) for å opprette preliminære parameterdata for linjen som betjenes, for at den feilsøkende funksjonsmotor skal kunne vurdere feilårsaken. This first process usually involves the use of a work order management device, e.g. the above CAS device, and the operator is required to use test equipment, e.g. a SASS transmission conditioning system or a direct access test unit (DATU) to create preliminary parameter data for the line being served in order for the fault finding function engine to assess the fault cause.

Hvis preliminær informasjon fra nevnte "trouble ticket" og resultatene av de første testingsmålinger er tilstrekkelige, til at funksjonsmotoren skal kunne bestemme årsaken til en feil, lages en lokaliserings- og reparasjonsscenariomelding. Funksjonsmotoren er operativ for koordinering av datainnsamlingen, ved å påkalle en ytre testfunksjon med etterfølgende analyse, ved obser-vering eller måling av linjens reaksjon på den påkalte prosess. Funksjonsmotoren kan eksempelvis frembringe en instruksjon som krever at DATU-35 åpner abonnetlinjen 16. Den avleser deretter svaret fra det bærbare testutstyr (testingshodet 14) på den påkalte stimulus fra DATU. I eksempelet for åpning av abonnent1injen må den avleste utgangsspenning fra det bærbare testutstyr 14 være null. Funksjonsmotoren avgjør deretter hva som nærmest må gjøres, basert på den overvåkte PTE-utgang. If preliminary information from the aforementioned "trouble ticket" and the results of the first test measurements are sufficient for the function engine to be able to determine the cause of a fault, a location and repair scenario message is created. The function engine is operational for coordinating the data collection, by invoking an external test function with subsequent analysis, by observing or measuring the line's reaction to the invoked process. The function engine can, for example, generate an instruction that requires the DATU-35 to open the subscriber line 16. It then reads the response from the portable test equipment (testing head 14) to the called stimulus from the DATU. In the example for opening the subscriber line, the read output voltage from the portable test equipment 14 must be zero. The function engine then determines what needs to be done next, based on the monitored PTE output.

Måledataene som er avledet fra testutstyret, ned-lastes i trinn 402 i den delte database 45. Selve testparameterdataene ledsages av en foreskrevet VER-kode som knytter testen som er utført av det mekaniske testutstyr, til regelsettet i kjennskapsdatabasen. Når testings-målingen og datanedlastingen er fullført, fremvises for brukeren et skjermbilde som inneholder en valgmeny som kan innbefatte ytterligere testing av linjen, eller andre funksjoner. Idet funksjonsmotoren 41 er operativ for opprettelse av en feilsøkingsstrategi basert på en diagnose-evaluering av nevnte "trouble ticket" og tilgjengelige måledata som er lagret i den delte database, vil graden av erfaring eller fagkunnskap hos teknikeren ikke være til hinder for et vellykket valg av menyposter, for gjennom-føring av oppgaven. Mens en meget erfaren operatør hurtig kan velge den hensiktsmessige testingsfunksjonsmenypost for den forhåndenværende "trouble ticket", vil anvendelsen av den feilsøkende funksjonsmotor gjøre det mulig å lede en mindre fagkyndig person gjennom en feilrettingssekvens. The measurement data derived from the test equipment is downloaded in step 402 into the shared database 45. The test parameter data itself is accompanied by a prescribed VER code that links the test performed by the mechanical test equipment to the rule set in the knowledge database. When the testing measurement and data download is complete, the user is presented with a screen that contains a selection menu that may include further testing of the line, or other functions. As the function engine 41 is operational for creating a troubleshooting strategy based on a diagnostic evaluation of said "trouble ticket" and available measurement data stored in the shared database, the degree of experience or professional knowledge of the technician will not be an obstacle to a successful choice of menu items, for carrying out the task. While a highly experienced operator can quickly select the appropriate test function menu item for the trouble ticket at hand, the use of the troubleshooting function engine will allow a less skilled person to be guided through a troubleshooting sequence.

I dette øyemed innbefatter hver menyskjermavbilding et "hjelp"-bilde. Når "hjelp"-bildet er påkalt (ved at operatøren trykker en penn mot den kontakt føl somme bildeskjerm i computerenheten.) vil funksjonsmotoren i et trinn 4 03 fremvise for brukeren en melding som indikerer resultatene av analysen av den i øyeblikket tilgjengelige informasjon i kjennskapsdatabasen og den delte database og tilråde hva teknikeren deretter bør gjøre. For dette for-mål og som svar på teknikerens påkalling av "hjelp"-bildet, vil funksjonsmotoren i et trinn 404 ekstrahere den VER-kode som er nedlastet i den delte database. I et neste trinn 405 påpekes momentant hvilken metode som skal utøves, basert på VER-koden. Ut fra den valgte metode fremvises en melding som gir brukeren instruksjon om hva som bør gjøres. To this end, each menu screen image includes a "help" image. When the "help" image is invoked (by the operator pressing a pen against the touch-sensitive image screen in the computer unit.) the function engine will in a step 4 03 present to the user a message indicating the results of the analysis of the currently available information in the knowledge database and the shared database and advise what the technician should do next. For this purpose and in response to the technician's invocation of the "help" image, the function engine will in a step 404 extract the VER code downloaded into the shared database. In a next step 405, it is momentarily pointed out which method is to be performed, based on the VER code. Based on the selected method, a message is displayed that gives the user instructions on what should be done.

Nærmere bestemt og i et trinn 406 fremvises for brukeren en instruksjonsmelding i tilknytning til den valgte metode. Hvis f.eks. den preliminære informasjon fra nevnte "trouble ticket" og resultatene av de første MLT-målinger er tilstrekkelige til å angi feilårsaken, kan det avgis en lokaliserings- og reparasjonsscenariomeldling. Hvis derimot ytterligere testing av linjen er nødvendig, vil den fremviste melding instruere brukeren om igjen å foreta én eller flere ekstra testinger. Hjelpe/instruk-sjonsmeldinger gjengis nemlig suksessivt og etter behov på bildeskjermen, og brukeren får instruksjon om å avlede More specifically and in a step 406, an instruction message is presented to the user in connection with the selected method. If e.g. the preliminary information from said "trouble ticket" and the results of the first MLT measurements are sufficient to indicate the cause of the failure, a location and repair scenario message can be issued. If, however, further testing of the line is required, the displayed message will instruct the user to again carry out one or more additional tests. Help/instruction messages are displayed successively and as needed on the image screen, and the user is instructed to divert

ytterligere informasjon, f.eks. ved bruk av testingshodet, helt til den feilsøkende funksjonsmotor har konsentrert et felt av mulige feilårsaker til en enkelt sannsynlig feilkilde. additional information, e.g. using the test head, until the fault-finding function engine has concentrated a field of possible failure causes into a single likely source of failure.

Hvis det f .eks. antas at den ovennevnte og gjentatte målings- og evalueringsprosess har fastslått at feilårsaken er en jordingsfeil, kan følgende melding fremvises: "MLT har fastslått en jordingsfeil. Feil av denne type oppstår for det meste i nedgravde kabler. Benytt en jordingsfeil-lokalisator og en jordgradientramme for lokalisering av feilen. Blottlegg kabelen i feilpunktet og repa-rer kabelen." Foruten å gjengi resultatene av funksjonsmotorens analyse av nevnte "trouble ticket" og testparameterdataene, tjener denne melding også til å gi teknikeren praktisk informasjon (ved å bekrefte et valg som er foretatt av en fagkyndig operatør eller ved å over-føre til arbeidsstedet instruksjon til en mindre fagkyndig person) . Operatøren kan deretter fortsette med å gjennom-føre den foreslåtte korreksjonsprosess, for å rette feilen. Når dette er fullført, kan linjen atter testes, for å verifisere reparasjonen. If it e.g. assuming that the above and repeated measurement and evaluation process has determined that the fault cause is a ground fault, the following message may be displayed: "MLT has determined a ground fault. Faults of this type occur mostly in buried cables. Use a ground fault locator and a ground gradient frame for locating the fault. Expose the cable at the fault point and repair the cable." Besides reproducing the results of the function engine's analysis of said "trouble ticket" and the test parameter data, this message also serves to provide the technician with practical information (by confirming a choice made by a skilled operator or by transferring to the workplace instructions to a less expert person). The operator can then proceed to carry out the proposed correction process to correct the error. Once this is complete, the line can be retested to verify the repair.

Det fremgår av den ovenstående beskrivelse, at ved å innføye feilsøkingsmekanismen ifølge oppfinnelsen i en telefonserviceteknikers bærbare computerenhet, økes mulig-heten for en operatør som er utsendt til et servicested for hurtig å avhjelpe et problem i en "trouble ticket" uansett graden av fagkyndighet hos servicetekniker. Ved å analysere flere informasjonskilder, deriblant brukerinnganger fra operatøren, parameterdata som innbefattes i utsendingen ("trouble ticket"), testdata fra gjennomfør-ingen av lokale tester og fjerntestdata (fra eksempelvis et mekanisk sløyfetestings (MLT-) system) kan feilsøkings-mekanismen ifølge oppfinnelsen hurtig avlede og foreslå for teknikeren en problem-avhjelpingsstrategi som er såvel deterministisk nøyaktig og instruktiv. It is clear from the above description that by inserting the troubleshooting mechanism according to the invention into a telephone service technician's portable computer unit, the possibility is increased for an operator who is dispatched to a service point to quickly remedy a problem in a "trouble ticket", regardless of the level of expertise of service technician. By analyzing several sources of information, including user inputs from the operator, parameter data included in the dispatch ("trouble ticket"), test data from the execution of local tests and remote test data (from, for example, a mechanical loop testing (MLT) system), the fault finding mechanism according to the invention quickly derive and propose to the technician a problem-remediation strategy that is both deterministically accurate and instructive.

I en telefonserviceteknikers bærbare computerenhet inngår en feilsøkingsmekanisme som vil gjøre det mulig for en operatør å svare på en "trouble ticket". Ved analysering av flere informasjonskilder, deriblant brukerinnganger fra operatøren, kan parameterdata i nevnte "trouble ticket", testdata fra gjennomførte, lokale tester og fjerntestdata vil feilsøkingsmekanismen avlede og foreslå en problem-avhjelpingsstrategi som viser seg nøyaktig. I systemoppbygningen inngår en feilsøkende funksjonsmotor og et tilhørende sett av databaser hvorav én er en kjennskapsdatabase og den annen en delt parameterdatabase. Kjennskapsdatabasen inneholder regler og statiske parametre som definerer funksjonsmotorens karakteristikker og virkemåte. Disse regelsett og informasjonen er spesiell for telefonlinje-feilsøking. A telephone service technician's laptop device includes a troubleshooting mechanism that will enable an operator to respond to a "trouble ticket". By analyzing several sources of information, including user inputs from the operator, parameter data in the aforementioned "trouble ticket", test data from completed local tests and remote test data, the troubleshooting mechanism can derive and propose a problem-remedial strategy that proves to be accurate. The system structure includes a fault-finding function engine and an associated set of databases, one of which is a knowledge database and the other a shared parameter database. The knowledge database contains rules and static parameters that define the function engine's characteristics and operation. These rulesets and information are specific to telephone line troubleshooting.

Claims

1. Procedure for creating, for an operator, a troubleshooting strategy that will give the operator an indication of the likely cause of a problem in a subscriber line and propose a process for solving the problem, characterized by process steps that include: (a) application of a communication - and processing unit with which an operator who may be dispatched to a service location at a distance from a telephone exchange serving said subscriber line, can communicate with a test system in the telephone exchange and with a testing head that can be connected to the subscriber line, where the communication and processing unit has an input/output device with a visual image screen through which input information from the operator is transformed into prescribed control signals and transmitted to the test system, and through which information related to the test system's operation is presented to the operator, and (b) application in the communication and processing unit of an information processing and troubleshooting function ons engine with a connected first and second database, where the first database is a knowledge database containing rules and static parameters that define the function engine's characteristics and operation, and the second database is a shared database for storing parameter data in connection with one or more tests that have been carried out on the line, and the troubleshooting function engine is operative to perform a diagnostic evaluation of data in the shared database in accordance with the rule set stored in the knowledge database, and to produce a proposed solution to the problem in said line, which will direct the operator to remove the fault, whereby the function engine is operative to perform a diagnostic evaluation of several possible problems that may occur on said line, possible causes of these possible problems and recommended processes for repairing the line.

2. Method in accordance with claim 1, characterized in that the data stored in the shared database includes data collected through one or more work order program management devices, measurement data from the portable test equipment and input data from the operator, where test parameter data as is stored in the shared database has a test identification code that links a test carried out by the test equipment with a rule set in the knowledge database, whereby the fault finding function engine in reaction to this develops a fault finding strategy based on a diagnostic evaluation of a "trouble ticket" which reports said problem and the measurement parameter data stored in the shared database.

3. Method in accordance with claim 1 or 2, characterized in that the fault-finding function engine is operative to produce on the image screen a prescribed symbol which, when invoked by the operator, causes the function engine to display a message indicating the results of said analysis of the i currently available information in the knowledge database and in the shared database, and suggests to the operator a course of action that will solve the problem.

4. Supervisory control mechanism included in a portable in test unit used by an operator for testing a communication line, characterized by an information processing and troubleshooting function engine with a connected first and second database, where the first database is a knowledge database containing rules and static parameters that define the function engine's characteristics and operation, and the second database is a shared database for storing parameter data in connection with one or more tests carried out on the aforementioned line, where the fault-finding function engine is operational for analyzing several sources of information, including user inputs from the operator, parametric data which is part of a problem clarification, test data from carried out local tests and remote test data, and for deriving from these a fault-finding strategy that is output to the operator, so that he can locate the cause of a problem which leads to the creation of the problem clarification, whereby the rules and the static parameters that define the function engine's characteristics and operation have been created in accordance with a diagnostic evaluation of several problems that may occur on said line, the possible causes of these problems and recommended processes for solving the problem.

5. Supervisory control mechanism in accordance with claim 4, characterized in that the fault-finding function engine is operative to apply the rules and parameters in the knowledge database, for the creation of a field of possible/probable error causes which have a connection or connection to a critical point in a set of control parameters and using the test parameter data in the shared database, repeatedly concentrating the field of possible causes to a gradually decreasing number, until a most probable cause of the problem is determined, whereby the fault finding function engine applies the point indicating the most probable cause of failure, for issuing a remedial strategy message to the operator, and where the test parameter data stored in the shared database has a test identification code that associates a test, performed with the test equipment, with a rule set in the knowledge database and the fault finding function engine in response creates a fault finding strategy based on a diagnostic evaluation of a “trou ble ticket" reporting the problem and the measured parameter data stored in the shared database, and the troubleshooting function engine is operative to display, on the image screen, a prescribed symbol which, when invoked by the operator, causes the function engine to display a message indicating the results of the function engine's analysis of the currently available information in the knowledge database and the shared database and suggests, to the operator, a course of action that will solve the problem, preferably with the function engine operational to make a diagnostic evaluation of several possible problems that may occur on the line, possible causes of these problems and recommended processes for repairing the line.

6. Mechanism that enables an operator's communications and processing unit to make available, to an operator deployed to a service location remote from a telephone plant serving a subscriber line, a troubleshooting process by which the operator can locate and remedy the probable cause of a problem in the subscriber line, characterized in that the communication and processing unit is operative to communicate with a test system in the telephone system and with a testing head that can be connected to the subscriber 1 injen, where the communication and processing unit has an input/output device with a visual image screen, with which the input information from the operator is transformed into prescribed control signals and transmitted to the test system, and with which information related to the operation of the test system is presented to the operator, and where the mechanism comprises an information processing fault-finding function engine which is connected to a first and a second database, where the the first database is a knowledge database containing rules and static parameters that define the function engine's characteristics and operation, and the second database is a shared database for storing parameter data in connection with one or more tests carried out on the line, and the fault-finding function engine is operational for to carry out a diagnostic evaluation of data in the shared database in accordance with the rule set stored in the knowledge database and to display a message containing a process proposed to be carried out by the operator, for locating and solving the problem in the subscriber line, and where data is stored in the shared database, includes data received from one or more work order management user programs, measurement data from the portable test equipment and input data from the operator.

7. Mechanism in accordance with claim 6, characterized in that the test parameter data stored in the shared database has a test identification code that associates a test, carried out by the test equipment, with a rule set in the knowledge database and the fault-finding function engine, in response to the performed testing, creates a troubleshooting strategy based on a diagnostic evaluation of a "trouble ticket" reporting the problem and the measurement parameter data stored in the shared database, and where the troubleshooting function engine is operative to display, on the image screen, prescribed symbols such as, when invoked by the operator, results in a message indicating the results of the function engine's analysis of currently available information in the knowledge database and the shared database and suggests, for the operator, a course of action that will solve the problem on the subscriber's side.

8. Method of making available, to an operator deployed to a service location remote from a telephone plant serving a subscriber line, a troubleshooting strategy that gives the operator an indication of the probable cause of a problem in the subscriber line and suggests a process which can solve the problem, characterized by process steps comprising: (a) equipping the operator with a communication and signal processing unit with which the operator can communicate with the telephone system and with test equipment which can be connected to the subscriber line and which includes an input/output device with a visual image screen with which -time information from the operator is transformed into prescribed signals and transmitted to a test system in the telephone system, and with which information related to the test system's operation is presented to the operator, as the test system is operative for received command signals from the operator unit and for transmitting prescribed test stimuli to the subscriber line, in the subscriber line's response to these is measured by the test equipment, and (b) application in the operator unit of an information processing and troubleshooting function engine with connected first and second databases, where the first database is a knowledge database containing rules and static parameters that define the function engine's characteristics and operation, and the second database is a shared database for storing parameter data in connection with one or more tests carried out on the line, and where the fault-finding function engine is operative to carry out a diagnostic evaluation of data in the shared database in accordance with the set of rules stored in the knowledge database, by coordinating the test system's transmission of a stimulus to the subscriber line and analyzing the test system's output at said stimulus and indicating the proposed solution to the problem in the subscriber line, which will direct the operator to remove the fault, and where the test unit preferably comprises a direct access test unit.

9. Method in accordance with claim 8, characterized in that the direct access test unit is designed to respond to commands from the operator unit and to transmit audio messages and thereby enable the operator to control the operation of the direct access test unit and consequently test the subscriber line, where commands are transformed into tone signals and sent to the direct access test unit, and where information related to the operation of the direct access test unit is presented to the operator of the display screen, the displayed information being updated alternately in response to one or more inputs from the operator through the operator unit, regardless of whether the direct access test unit emits audio messages, and where the function engine is operative to cause a menu of various tests that can be carried out on the subscriber line of the test system to be displayed on the image screen in response to information, where a demand for this has been displayed, has been entered through the operator unit's input/output ng device, whereby the function engine is operative to cause this menu of various tests that can be performed on the subscriber line of the test system to be displayed simultaneously on the image screen, while audio messages in connection with various testing functions that can be performed by the test system are created sequentially, and the function engine is preferably operative for to carry out a diagnostic evaluation of several possible problems that may occur on the line, possible causes of the possible problems and recommended processes for repairing the line, whereby the stored data in the shared database includes data obtained through one or more work order management user programs, measurement data from the test equipment and input data from the operator.

10. Method in accordance with claim 8 or 9, characterized in that the test parameter data stored in the shared database has a test identification code that associates a test, carried out by the test equipment, with a set of rules in the knowledge database whereby the fault-finding function engine, in response, creates an error - search strategy based on a diagnostic evaluation of a "trouble ticket" reporting the problem and the data parameter measurement stored in the shared database, and where the fault finding function engine is operative to produce, on the image screen, a prescribed symbol which , when invoked by the operator, causes the function engine to display a message indicating the results of the function engine's analysis of the currently available information in the knowledge base and the shared database and suggests, to the operator, a course of action that will solve the problem.