DE3879072T2

DE3879072T2 - Expertsystem zur Verarbeitung von Fehlern in einem Multiplex-Kommunikationssystem.

Info

Publication number: DE3879072T2
Application number: DE88112991T
Authority: DE
Inventors: Mark Edward Clark; Richard George Greever; Larry John Schmier; Jerome Dale Wong
Original assignee: Rolm Systems
Current assignee: Siemens Communications Inc
Priority date: 1987-10-05
Filing date: 1988-08-10
Publication date: 1993-10-07
Anticipated expiration: 2008-08-11
Also published as: JPH01243653A; EP0310785A3; EP0310785A2; US4881230A; EP0310785B1; DE3879072D1

Description

Die vorliegende Erfindung betrifft im allgemeinen Verbesserungen der Fehlerbehandlung in einem Multiplex- Kommunikationssystem und insbesondere die Verwendung eines Expertensystems mit Verfahren zur Kennzeichnung einer aus fallenden Einheit einer Vermittlung, das Durchlaufen eines Entscheidungsbaums zur Wahrnehmung funktionierender Glieder der Vermittlung, die Kennzeichnung jeder fehlerhaften Austauscheinheit und das Umgehen des Problems.

Beschreibung des Standes der Technik

In den letzten Jahren hat als Reaktion auf die Forderungen nach erhöhter Flexibilität in der Datenkommunikation eine bedeutende Erweiterung des Einsatzes von Kommunikationsmultiplexern stattgefunden. Mit steigender Aufwendigkeit dieser Systeme und ihrer engeren Einbindung in die täglichen Betriebsabläufe konnten Ausfälle im Kommunikationssystem immer weniger hingenommen werden, wodurch sich die Bedeutung der Fehleranalysefunktion erhöhte.
Die Fehleranalysefunktion wurde durchgeführt, indem ein Techniker eine Gerätefehlertabelle durchsah und die wichtigen Informationen aus der großen Menge ungeordneter Daten in der Fehlertabelle aussortierte. Oft ergab sich die Notwendigkeit, zusätzliche Prüfungen zur genaueren Lokalisierung des Problems von Hand aufzurufen. Die Wirksamkeit dieses Ansatzes war von der Kompetenz des Technikers und seinen Erfahrungen abhängig. Als Provisorium war dieser Weg zwar wirkungsvoll, war aber als Dauerlösung zu unbestimmt.
Ein weiterer Weg zur Verbesserung der Verfügbarkeit des Kommunikationssystems bediente sich redundanter Steuerwerke. Durch eine Umschaltung zum anderen Steuerwerk ergab sich durch die redundanten Steuerwerke die Möglichkeit einer schnellen Wiederherstellung nach einem Fehler in einem der Steuerwerke. Eines der mit diesem Weg verbundenen Probleme betraf den kurzen Zeitraum zwischen dem Ausfall und der Wiederherstellung des zweiten Steuerwerks. Während dieser Zeit trat eine Datenstörung auf.
Während eines Ferngesprächs war dies zwar nur eine Unannehmlichkeit; während einer Datenverbindung wurde dadurch aber häufig die Kommunikationsübertragung beendet. Aufgrund dieser Beendigung mußte die Kommunikationsverbindung wieder hergestellt werden und die Datenübertragung wiederholt werden. Bei vielen Anwendungen wie beispielsweise Bankgeschäften ist eine solche Dienstgüteverschlechterung unannehmbar, da eine fehlerlose Übergabe jeder Nachricht von wesentlicher Bedeutung ist.
Die Benutzung von Expertensystemen zur Diagnose von Patienten in der Medizin ist heute weit verbreitet. Bei diesen Systemen muß der Benutzer jedoch im Gegensatz zu der automatischen Erfassung der Informationen große Informationsmengen eingeben, die den Patienten beschreiben. Auch muß der Benutzer zur Benutzung des Systems als Arzt ausgebildet sein. Der Durchschnittstechniker wäre nicht in der Lage, das System wirkungsvoll zu nutzen. Dieses Thema wird eingehender in dem von M.J. Coombs herausgegebenen Buch mit dem Titel "Developments in Expert Systems", veröffentlicht von der Academic Press (1984), und insbesondere in dem Kapitel mit dem Titel "Strategic Explanations For A Diagnostic Consultation System" von Diane Hasling et al., Heuristic Programming Project, Computer Science Department, Stanford University, besprochen.
Ein Beispiel für Prüfsysteme findet sich in US- Patent Nr. 4 601 032 an Robinson, Ausgabedatum 15. Juli 1986 und US-Patent Nr. 4 649 515 an Thompson et al., Ausgabedatum 10. März 1987. In diesen Patenten werden Verfahren zur Fehlersimulierung und Prüfung von digitalen Schaltungen und Prozeßsteuerungs-, Sensorsystemen besprochen. In den letzteren kommt ein Satz Regeln zum Einsatz, die auf einen Anreiz von Außensensoren reagieren, um eine Wissensdatenbank zur Bestimmung der Reaktion auf ein Problem und Ausgabe von Informationen, die einen Benutzer zur Problemlösung führen sollten, zu durchsuchen.
Zusätzliche Beispiele von Expertensystemen zur Entscheidungsfindung auf der Grundlage einer Wissensdatenbank sind in US-Patent Nr. 4 595 982 an Burt, Ausgabedatum 17. Juli 1986 und US-Patent Nr. 4 648 044, 3. März 1987 offenbart. Die in diesen Patenten beschriebenen Programme treten mit dem Benutzer in dialogartige Wechselwirkung, um ihn zu einer Antwort auf seine Probleme zu führen. In dem Werkzeug sind Fragenerstellung, Überprüfung der Zulässigkeit der Reaktion, Erklärung der Reaktionen und die Fähigkeit zur Fehlersuche in der Wissensdatenbank enthalten.
Obwohl diese Patente verschiedene Expertensysteme beschreiben, fehlt ihnen die Möglichkeit dazu, Expertensystemverfahren zur Kennzeichnung ausfallender Einheiten in einem Kommunikationsmultiplexer, zum Durchlaufen eines Entscheidungsbaumes zur Erkennung von funktionierenden Gliedern der Vermittlung, zur Kennzeichnung jeder fehlerhaften Einheit und zur Umgehung des Problems einzusetzen.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist daher eine Aufgabe dieser Erfindung, ein Verfahren bereit zustellen, mit dem Probleme in einem Kommunikations-Multiplexsystem erfaßt werden können.
Es ist eine weitere Aufgabe der Erfindung, die aus fallende Komponente des Kommunikations-Multiplexsystems mit einem Expertensystem zu lokalisieren.
- Es ist eine weitere Aufgabe der Erfindung, Entscheidungsbäume in einem Expertensystem zur weiteren Verfeinerung der Kennzeichnung der ausfallenden Komponente, Eliminierung aller funktionierenden Einheiten der Komponente, Lokalisierung der bestimmten ausfallenden Austauscheinheit und Durchführung zusätzlicher Diagnosen, um sicherzustellen, daß keine Außenfehler von anderen Aspekten des Systems den Ausfall bewirken, und Darstellung einer detaillierten Nachricht in natürlicher Sprache für den Bediener einzusetzen.
Ein weiteres Ziel der Erfindung ist es, dem Bediener eine vorgeschlagene Handlung zur Fehlerbehebung bereitzustellen.
Erfindungsgemäß werden diese Tasken durch intermittierende Prüfung der verschiedenen Funktionseinheiten eines Multiplexkommunikationssystems zur Kennzeichnung aller ausfallenden Einheiten gelöst. Nach Erkennung einer aus fallenden Einheit wird eine zusätzliche Entscheidungsbaumverarbeitung durchgeführt, um Probleme zu eliminieren, die durch andere Betriebsmittel und Fehleranalyseversuche zur Lokalisierung des Problems auf eine einzige Austauscheinheit verursacht werden.
Abschließend wird zur Führung eines Bedieners zur Korrektur eines Problems eine Nachricht in einer natürlichen Sprache zur Anzeige gebracht.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Die obenstehenden und weitere Aufgaben, Merkmale und Vorteile der Erfindung werden nachstehend anhand der Zeichnungen eines bevorzugten Ausführungsbeispiels der Erfindung näher beschrieben. Es zeigen:
Figur 1 eine Darstellung der Hardwareumgebung einer Unterzentrale nach dem Stand der Technik;
Figur 1a eine Darstellung der Hardwareumgebung der besten Betriebsart der Erfindung;
Figur 1b eine Darstellung der Zentraleinheit- Baugruppenträgersteckplätze des Zentralsteuerungsbaugruppenträgers der besten erfindungsgemäßen Betriebsart;
Figur 1c eine Darstellung der Zeitmultiplex- Baugruppenträgersteckplätze der besten erfindungsgemäßen Betriebsart;
Figur 2 ein Hardware-Blockschaltbild der verbes serten Diagnosekarte;
Figur 3 eine die P2-Steckerstifte der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 4 eine zusätzliche P2-Steckerstifte der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 5 eine zusätzliche P2-Steckerstifte der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 6 eine die P3-Steckerstifte der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 7 eine die Sendebefehle der verbesserten Diagnosekarte enthaltende Tabelle;
Figur 8 eine zusätzliche Sendebefehle der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 9 eine bitweise Abbildung des Binärmusters nach u-Kennlinie der verbesserten Diagnosekarte;
Figur 10 eine bitweise Abbildung des Statusbefehls der verbesserten Diagnosekarte;
Figur 11 eine die Empfangsbefehle der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 12 eine zusätzliche, die Empfangsbefehle der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 13 eine bitweise Abbildung des Datenformats für den Sende- und Empfangsdatenbefehl der verbesserten Diagnosekarte;
Figur 14 eine die Sende- oder Empfangsdaten nach u-Kennlinie für die verbesserte Diagnosekarte beschreibende Tabelle;
Figur 15 eine die linearen 12-bit-Sende- oder Empfangs-Datenbefehle der verbesserten Diagnosekarte beschreibende Tabelle;
Figur 16 eine die von der verbesserten Diagnosekarte unterstützten Prüfungen beschreibende Tabelle;
Figur 17 eine Prüfungsdaten und eine Beschreibung der Prüfungen, denen die Daten auf der verbesserten Diagnosekarte zugeordnet sind, angebende Tabelle;
Figur 18 eine zusätzliche, die Prüfungsdaten und eine Beschreibung der Prüfungen, denen die Daten auf der verbesserten Diagnosekarte zugeordnet sind, angebende Tabelle;
Figur 19 eine die Prüfungstabelleneinträge und eine Beschreibung der Prüfungen, denen die Einträge auf der verbesserten Diagnosekarte zugeordnet sind, angebende Tabelle;
Figur 20 eine die Bitkombinationen und eine Beschreibung der Prüfungen, denen die Bitkombinationen auf der verbesserten Diagnosekarte zugeordnet sind, angebende Tabelle;
Figur 21 eine die Prüfparameter für die analoge 8-Kanal-Telefonschnittstelle auf der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 22 eine die Prüfparameter für die 8-Kanal- MWL-Leitungsschnittstelle auf der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 23 eine die Prüfparameter für die direkte 4-Kanal-Verbindungsleitungsschnittstelle der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 24 eine die Prüfparameter für die 8-Kanal- Durchwahl-Verbindungsleitungsschnittstelle der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 25 eine die Prüfparameter der 8-Kanal- Querverbindungsleitungsschnittstelle des öffentlichen Netzes der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 26 eine die Prüfparameter der 8-Kanal-OPS- Leitungsschnittstelle der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 27 eine die 4-Draht-Querverbindungsleitungsschnittstelle der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 28 eine die Prüfparameter des Vierer-MFV- Registers (analoge Prüfschleife) der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 29 eine die Prüfparameter des Vierer-MFV- Registers - Taste "1" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 30 eine die Prüfparameter des Vierer-MFV- Registers - Taste "2" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 31 eine die Prüfparameter des Vierer-MFV- Registers - Taste "5" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 32 eine die Prüfparameter des Vierer-MFV- Registers - Taste "9" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 33 eine die Prüfparameter des Vierer-MFV- Registers - Taste "0" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 34 eine den ersten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "N&sup0;" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 35 eine den zweiten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "2" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 36 eine die Prüfparameter des Vierer-MFV- Registers - Taste "9" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 37 eine die Prüfparameter des Vierer-MFV- Registers - Taste "5" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 38 eine die Prüfparameter des Vierer-MFV- Registers - Taste "1" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 39 eine die Prüfparameter des Vierer-MFV- Registers - Taste "D" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 40 eine die Prüfparameter des Drehgebers der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 41 eine die Prüfparameter des Drehwählerregisters der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 42 eine die Prüfparameter der Konferenzbrücke der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 43a eine den ersten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "*" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 43b eine den zweiten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "*" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 43c eine den dritten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "*" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 43d eine den vierten Teil der Prüfparameter des Vierer-MFV-Registers - Taste "*" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 44 eine die Prüfparameter des Tongebers - Taste "1" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 45 eine die Prüfparameter des Tongebers - Taste "2" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 46 eine die Prüfparameter des Tongebers - Taste "5" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 47 eine die Prüfparameter des Tongebers - Taste "9" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 48 eine die Prüfparameter des Tongebers - Taste "0" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 49 eine die Prüfparameter des Tongebers - Taste "N&sup0;" - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 50 eine die Prüfparameter des Tongebers - interner Wählton - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 51 eine die (doppelten) Prüfparameter des Tongebers - Prüfton - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 52 eine die Prüfparameter des Tongebers - Pause - der verbesserten Diagnosekarte anzeigende Tabelle;
Figur 53 ein Hardware-Blockschaltbild des erfindungsgemäßen Systems;
Figur 54 ein Beispiel eines Dialogs einer Fehleranalyseanzeige;
Figur 55 ein Beispiel eines Fehleranalyseberichts;
Figur 56 ein Beispiel für Fehleranalysemeldungen für Austauscheinheiten;
Figur 57 eine Liste von für Fehleranalyseverarbeitung typischen vorgeschlagenen Handlungen und Kommentaren;
Figur 58 eine Erläuterung des Entscheidungsbaumschemas der Logikdiagramme;
Figur 59 ein schematisches Logikdiagramm des Entscheidungsbaumes der generischen Analyse;
Figur 60 ein schematisches Logikdiagramm des Entscheidungsbaumes der RLI-Sprachanalyse;
Figur 61 eine Fortsetzung des schematischen Logikdiagramms des Entscheidungsbaumes der RLI-Sprachanalyse;
Figur 62 ein schematisches Logikdiagramm der Cypress-Analyse;
Figur 63 ein schematisches Logikdiagramm des Entscheidungsbaumes des Datenkommunikationsmoduls;
Figur 64 ein schematisches Logikdiagramm des Entscheidungsbaumes der Datenstreckenschnittstelle;
Figur 65 ein schematisches Logikdiagramm des Entscheidungsbaumes der modifizierten Kartenanalyse;
Figur 66 ein schematisches Logikdiagramm des Entscheidungsbaumes der Analyse "Anstehende Meldung";
Figur 67 ein schematisches Logikdiagramm des Entscheidungsbaumes der Analyse "Neue Querverbindungsleitung";
Figur 68 ein schematisches Logikdiagramm des Entscheidungsbaumes analoges Zeitmultiplex, Host zum Speichersystem und zurück;
Figur 69 eine Darstellung der Datenstruktur der Datenbank für aus fallende Betriebsmittel;
Figur 70 eine Darstellung der Datenstruktur Informationsstruktur Liste aus fallender Betriebsmittel;
Figur 71 eine Darstellung der Nutzdatenstruktur Protokoll ausfallender Betriebsmittel;
Figur 72 eine Darstellung einer mit ausfallenden Betriebsmitteln verknüpften Liste von Kanalausfällen;
Figur 73 eine Darstellung einer ausfallende Betriebsmittel verknüpfenden Struktur;
Figur 74 eine Hardwarefehlertabellenanzeige für das vorige Drehwählerregister;
Figur 75 eine Hardwarefehlertabellenanzeige für die vorige CO-Verbindungsleitung;
Figur 76 ein Flußdiagramm der Task THRESHOLD_ALARMS_CHECK(),
Figur 77 ein Flußdiagramm der Task CHECK_OOSTHRESH(); und
Figur 78 ein Flußdiagramm der Task CHECK_THRESHOLD_ALARMS().

Einführung

In der folgenden Offenbarung wird eine Methode und eine Hardwareumgebung zum Einsatz eines Expertensystems zur Bereitstellung von Fehleranalyse und Berichtigung in einem Kommunikations-Multiplexsystem beschrieben, die höhere Verfügbarkeit und erhöhten Datendurchsatz bieten.
Erfindungsgemäß wird ein Satz Prüfungen auf jedem Kanal durchgeführt, um sicherzustellen, daß jeder korrekt funktioniert, die Quelle von Hardwareausfällen wird lokalisiert und entsprechende Korrekturmaßnahmen werden angegeben. Der Satz Prüfungen ist von der Betriebsmittelart abhängig. Besteht ein geprüftes Betriebsmittel einer der vorgeschriebenen Prüfungen nicht, wird mittels Fehleranalyse versucht, die Fehlerursache auf eine bestimmte Austauscheinheit zu lokalisieren. Dies wird durch zusätzliche Prüfungen erreicht.
Mit Fehleranalyse wird auch sichergestellt, daß die Ergebnisse jeder Prüfung korrekt und wiederholbar sind. Jedesmal, wenn eine Prüfung nicht bestanden wird, wird eine Anzahl Prüfungen durchgeführt, um sicherzustellen, daß der Kanal die einzige Fehlerursache ist.
Um sicherzustellen, daß alle Informationen über Ausfälle durch Fehleranalyse geprüft werden, werden alle von Systemintegrität gemeldeten Fehler vor Eintragung in die Hardware-Fehlertabelle durch Fehleranalyse verarbeitet.
Jeder durch Fehleranalyse in der Hardware-Fehlertabelle protokollierte Fehler enthält ein Feld für vorgeschlagene Handlungen. Die vorgeschlagene Handlung wird angezeigt, wenn von einem Benutzer detaillierte Fehlerinformationen angefordert werden.

Hardwareumgebung

Die bevorzugte Ausführungsform dieser Erfindung wird in einer digitalen Multiplex-Kommunikationsumgebung einer Unterzentrale beschrieben. Figur 1 zeigt eine der bevorzugten Ausführungsform gleichende Hardwareumgebung nach dem Stand der Technik, in der die mit der Unterzentrale ROLM CBX II 9000 des Standes der Technik verbundene Rechnersteuereinrichtung dargestellt wird. Die Hardware besteht aus dem redundanten Speicher 10, einem gemeinsamen geschalteten E/A-Bus (ISB) 20, verschiedenen Schnittstellenkarten 30, der Diskettenoption 40 und redundanten Steuerwerken 50. Über die Knotenzwischenleitung Inter-Node-Link (INL) wird auch ein Zusatz für einen abgesetzten Knoten bereitgestellt. Eine mehr ins einzelne gehende Besprechung der Hardwareumgebung ist in dem von der ROLM-Corporation 1986 veröffentlichten ROLM CBX II 9000 Business Communications System enthalten.
In den Figuren 1A, 1B, 1C und 1D wird die beste Betriebsweise der Hardware fiir die Ausführung des Erfindungsgegenstandes dargestellt. Figur 1A zeigt die erfindungsgemäße Disposition der Baugruppenträger. Etage eins 51 ist eine Zentralsteuerungsetage in einem redundanten Systemschrank oder eine weitere Zeitmultiplexkartenetage in einem nicht redundanten Systemschrank. Etage zwei 52 ist iznmer eine Zentralsteuerungsetage. Etagen drei 53 und vier 54 sind immer Zeitmultiplexkartenetagen. Bei 55 werden Luftkühlanlagen und redundante Stromversorgungen zur Wärmeableitung und Bereitstellung von Systemstrom bereitgestellt.
Figur 1B zeigt die ZE-Etagensteckplätze der Zentralsteuerungsetage 52. Nach der Darstellung gibt es Speicherkarten 60, den Steuerwerksatz 61, gemeinsame Eingangs-/Ausgangs-(E/A) Hardware 62 und Diskettenlaufwerke 63. Die Steuerwerkkarten enthalten die Mikroprozessoren, auf denen die Fehleranalysesoftware abläuft. Zusätzlich gibt es eine Zentralsteuerungsgrundplatine 64, mit der die Speicherkarten 60, der Steuerwerksatz 61 und die gemeinsame E/A-Hardware 62 mit dem Systembus verbunden werden. Die Zentralsteuerungsgrundplatine 64 wird dazu benutzt, die andere Zentralsteuerungsgrundplatine von der redundanten Zentralsteuerungsetage 51 und die Zeitmultiplexetagen 53 und 54 miteinander zu verbinden.
Figur 1C zeigt die Zeitmultiplexetagenkarten. Die verlängerten Karten passen in die bei 65 gezeigten Steckplätze. Mit den anderen Zeitmultiplexkarten werden die Steckplätze bei 68 belegt. Steckplatz 70 ist für den Netz-Etagenmonitor Line Shelf Monitor (LSM) reserviert, mit dem die Stromversorgung überwacht wird und der die Sicherungen enthält. Wenn von LSM ein Stromversorgungsausfall oder Sicherungsausfall erkannt wird, wird dies durch eine einen Überwachungsfehler meldende Fühlerschaltung der Fehleranalyse gemeldet. Von der Fehleranalyse werden dann bestimmte Entscheidungsbäume ausgewertet, um Handlungsvorschläge zu erstellen.

Hardwarebeschreibung

Die folgende Hardwarebeschreibung bezieht sich auf Figur 1D. Die Hardware ist eine funktionsmäßige Darstellung der bevorzugten Ausführungsform.

EINZELKNOTENKOMMUNIKATION

Knotenstellen stellen die modularen Bausteine des Systems der Unterzentrale dar. Jeder Knoten kann als unabhängiges Telekommunikationssystem arbeiten und besteht aus dem Zeitmultiplex-Koppelnetz, Steuerwerken, Schrank und Stromversorgung und Schnittstellenkarten. Ein Einzelknotensystem kann von einem auf fünf Geräteschränke erweitert werden, um bis zu 2000 Leitungen aufzunehmen.
Die Unterzentrale CBX ist ein digitales Vermittlungssystem, in dem Zeitmultiplex (TDM) und Pulskodemodulation (PCM) zur Unterstützung einer Vielzahl von Sprach, Daten- und Sonderanwendungen eingesetzt werden. Die Steuerungsintelligenz wird in jedem Knoten von einem 32- Bit-Prozessor und Direktzugriffsspeicher (RAM) bereitgestellt.

Zeitmultiplex

In dem Multiplexverfahren wird ein einziger Kommunikationskanal dazu benutzt, mehrere Sprach- und/oder Datenübertragungen gleichzeitig zu führen. Über Zeitmultiplex wechselt die Kanalnutzung zwischen Benutzern oder zwischen Systemfunktionen, wobei jedem nacheinander ein kleiner Anteil der Kanalzeit (ein Zeitschlitz) zugeteilt wird. Der Kanal ist scheinbar für jede einzelne Übertragung reserviert, führt aber aufgrund seiner hohen Geschwindigkeit viele Übertragungen gleichzeitig durch.

Pulskodemodulation

Als 1975 die erste CBX ausgeliefert wurde, war ROLM industrieweit die erste Firma, die PCM-Technik einsetzte. PCM ist das Verfahren, in dem analoge Tonwellen von Gesprächen abgetastet, in Digitalsignale übersetzt, über das TDM-Netz transportiert und in Analogsignale verwandelt werden. In der CBX werden Sprachsignale 8000mal pro Sekunde abgetastet. Die Abtastwerte werden in 8-Bit-Binärworte umgewandelt, die über den Datenbus übertragen werden.
In diesem Kapitel werden die vier Hauptbestandteile eines Einzelknoten-Kommunikationssystems beschrieben. Sie werden in der folgenden Reihenfolge dargestellt:
* TDM-Koppelnetz
* Computer-Zentralsteuerung
* Schrankausstattung und Stromversorgung
* TDM-Schnittstellen zu Sprach-, Daten-, Leitungs- und sonstigen Betriebsmitteln

TDM-KOPPELNETZ: BUS

Grob umrissen stellt der Bus das gesamte TDM- Koppelnetz dar. Mit ihm werden die vom Steuerwerk hergestellten Verbindungen aufrechterhalten, und er leitet Informationen zwischen der Zentralsteuerungselektronik und den Fernsprechern, Endgeräten und Verbindungsleitungen weiter. Über den Bus findet die knoteninterne Kommunikation statt.
Der Bus ist ein paralleler einseitig gerichteter 16-Bit-Bus mit einer Kapazität von 295 Megabit pro Sekunde (Mb/s). Er bietet 1152 Zweiweg- oder Voll-Duplex- Kommunikationskanäle, von denen 928 für Sprach-/Datenverkehr verfügbar sind. Die übrigen Kanäle werden von dem System für verschiedene Steuerfunktionen wie die Herstellung von Telefonanzeigen benutzt.

TDM-Netz

Die Hauptbestandteile der knoteninternen Kommunikation sind in der TDM-Netzsteuergruppe enthalten. Diese Gruppe besteht aus:
* Etagen-Bus 84
* Etagen-Etagen-Bus 85
* Erweiterungskarten 80
* TDM-Steuerungskarten

Etagenbus 84

Auf der Rückseite jeder TDM-Etage befindet sich ein auf der TDM-Rückwand implementierter Etagenbus 84. Der Etagenbus 84 ermöglicht Kommunikation innerhalb einer Etage. Auf jedem TDM-Baugruppenträger ist eine Erweiterungskarte 80 in jeden Etagenbus 84 einsteckbar. Die Erweiterungskarten 80 stellen die Schnittstelle zwischen dem Etagenbus 84 und dem Etagen-Etagen-Bus (ISB) dar.
Die gesamte auf dem Etagenbus 84 verfügbare Bandbreite beträgt 74 Mb/s. Jeder Etagenbus 84 umfaßt einen zweiseitig gerichteten 16-Bit-Datenbus, einen 10-Bit-Adreßbus und eine "Freigabe"-Leitung zu jeder Karte. Mit der Freigabe-Leitung erübrigt sich die Notwendigkeit, jede Karte mit einer besonderen Etagenadresse zu konfigurieren, so daß Schnittstellenkarten jeden Steckplatz im Baugruppenträger belegen können. Zusätzlich wird mit der Freigabeleitung die Adreßdekodierung vereinfacht und damit die Zuverlässigkeit erhöht.

Etagen-Etagen-Bus 85

Der ISB, ein Bestandteil der firmeneigenen Bus- Struktur, trägt die Kommunikation zwischen Etagen über ein an der TDM-Steuerungskarte (TC 81) und den Erweiterungskarten 80 auf jeder Etage befestigtes Flachbandkabel.
Mit dem ISB wird eine Datenrate von 295 Mb/s über zwei einseitig gerichtete Busse unterstützt: den Quellenbus 87 und den Zielbus 86.

Erweiterungskarten

Wenn ein System mit redundanten Steuerwerken ausgestattet ist, sind auch die Erweiterungskarten (expander cards) 80 redundant. Wenn eine Zentralsteuerungsseite des Schrankes aktiv ist, ist eine der Erweiterungskarten 80 im Gebrauch, während die redundante (passive) Zentralsteuerungsseite und andere Erweiterungskarte 80 darauf warten, aktiv zu werden.
Auf jeder Erweiterungskarte 80 befindet sich eine Verbindungstabelle für alle Sprach- und Datenverbindungen, die ihre Etage beeinflussen. Damit wird etageninterne Bandbreite für Rufdaten freigegeben, so daß für die zur Verbindungsherstellung benötigten Adresseninformationen keine Bandbreite belegt wird.
Die Erweiterungskarten Expander 80, die TDM- Steuerungskarte TC 81 und die Umkehrkarte Turnaround 82 bedienen sich zur Taktung des Busverkehrs des (auf der Karte Turnaround 82 befindlichen) Bus-ISB-Taktes. Damit wird die korrekte Taktbeziehung zwischen den auf dem Bus durchlaufenden Daten und den Taktimpulsen aufrechterhalten. Darüber hinaus sendet die Umkehrkarte auch zu Beginn jedes Abtastintervalls einen Impuls aus. Durch den Impuls wird die Erweiterungskarte 80 veranlaßt, wieder bei dem ersten Eintrag in der Verbindungstabelle zu beginnen.

TDM-Steuerungskarte

Mit der Karte Bus TC 81 wird die Steuerwerk_ISB- Schnittstellenkommunikation überwacht. Die Karten TC 81 sind in den Zentralsteuerungsetagen im Schrank 1 eines CBX-Knotens aufgenommen. Die Karte TC 81 ist verantwortlich für die drei folgenden Tätigkeiten: Laden und Nachweisen der Verbindungstabelle auf jeder Karte Expander 80; Konfigurieren der Hardware für die Karte Turnaround 82 und InterNode Link (INL) 83; und die Kommunikation mit den verschiedenen Leitungskartengruppen. Die Karte TC 81 bearbeitet bis zu 12 Mb/s Steuerinformationen.
Die Karte TC 81 meldet ihre Tätigkeiten mittels eines Bussteuerfeldes. Steuerungspakete enthalten Adressierungs-, Steuerungs- und Dateninformationen zum Laden der Erweiterungskarten-Verbindungstabellen und Ablesen des Zustandes von Leitungskarten.
Die Karte TC 81 unterhält einen Kommunikationsweg zwischen den beiden Enden einer Sprach- oder Datenverbindung. Über die Karte TC 81 vermittelt das Steuerwerk digitalisierte Signale, indem es sie eindeutigen Zeitschlitzen auf dem ISB-Bus zuweist. Der Bus bedient sich TDM-Verfahren, wodurch Sprach- und Datenübertragungen gleichzeitig in großer Menge auf dem ISB-Bus geführt werden können.

Umkehrkarte

Wie ihr Name schon andeutet, werden mit der Umkehrkarte Turnaround 82 die Busdaten gewendet. Von der Erweiterungskarte Expander 80 in der Sendekartenetage wird ein Datenwort auf den Quellenbus 87 gegeben. Das Datenwort läuft nach rechts, bis es auf die Umkehrkarte Turnaround 82 trifft, die das Wort aufnimmt und zum Zielbus 86 weitersendet ("es wendet"). Das Wort wird dann von der Erweiterungskarte Expander 80 an der Zieletage eingefangen und zu der entsprechenden Karte weitergeschickt.
Der Vorteil der Verwendung der Umkehrkarte ist, daß in einem einzelnen Zeitschlitz zum Zielbus 86 und der Empfangskarte weiterübermittelte Information sich vollständig von der in diesem Zeitschlitz vom Quellenbus 87 und der Sendekarte empfangenen Information unterscheiden kann. Damit wird die Verkehrsleistung der Zentrale verdoppelt, indem zwei Knoten-Knoten-Gespräche in einem einzigen Zeitschlitz auf dem Bus stattfinden können.
Zum weiteren Verständnis dieses Vorgangs kann man sich vorstellen, daß ein Gespräch an Fernsprechern mit Verbindungen im Knoten A stattfindet. Vom System wird ein Sprachabtastwert auf dem Quellenbus 87 des Knotens A übertragen, und der Abtastwert trifft auf die Umkehrkarte Turnaround 82, von der dieser Abtastwert auf den Zielteil desselben Busses gebracht wird. Damit ist der Zeitschlitz des Zielteils des Busses des Knotens A frei geworden.
Die Karte Turnaround 82 kann nunmehr diesen leeren Zeitschlitz mit einem Sprachabtastwert vom anderen Ende des Gesprächs füllen. Auf diese Weise können die Signale von beiden Enden des Gesprächs gleichzeitig denselben Zeitschlitz belegen.

Systemtakt

Mit dem Systemtakt wird in jedem Knoten eines Mehrknoten-CBX-Systems die Zeitgebung für das TDM-Netz über die Karte Turnaround 82 bereitgestellt. Damit wird auch der INL-83-Betrieb zwischen Knoten synchronisiert. Dieser Takt kann seinen Ursprung im eigenen internen System haben oder er kann von einer externen T1-Schnittstellenleitung synchronisiert sein. Der Systemtakt entspricht der Schicht 4 des Netzsynchronisationsplans von Bell.

Buskapazität

Mit dem neuen Bus erlangt die CBX 2304 Zeitschlitze pro Knoten. Die Bandbreite ist ein Maß der Sprach- und Daten-Verkehrsleistung in der CBX. Die Taktgeschwindigkeit auf der 16-Bit-parallelen Rückwand des Busses beträgt 18,432 MHz. Die Gesamtbandbreite des Systems beträgt daher 18,432 Megahertz/Sekunde x 16 Bit/Hertz = 294,912 Mb/s.
In Kommunikationskanälen ausgedrückt, sieht das so aus: da die Abtastrate der Unterzentrale CBX 8 kHz beträgt, entspricht die Bandbreite in beiden Richtungen eines Kommunikationskanals der 16-Bit-Rückwand
8000 Abtastwerte/Sekunde x 16 Bits/Abtastwert = 128 000 b/s (128 kb/s).
Die Gesamtbandbreite in einem Knoten mit dem Bus beträgt daher 1152 Kanäle x 128 kb/s x 2 Verbindungen/Vollduplexkanal = 294.912 Mb/s in jedem Knoten. Die Gesamtbandbreite für ein 15-Knoten-System mit Bus beträgt daher
15 Knoten x 295 Mb/s/Knoten = 4,425 Gb/s (bzw. 4.425.000.000 b/s).

COMPUTER-ZENTRALSTEUERUNG

Die CBX bietet den Vorteil einer Computer-Zentralsteuerung. Mit den gespeicherten Programmen der Computer-Zentralsteuerung ist es leicht, Merkmale entsprechend den Geschäftserfordernissen zu aktualisieren. Das Ergebnis ist eine größere Flexibilität und Verringerung der Kosten für die Hinzufügung von Merkmalen und anderen Änderungen, die in der Zukunft vorgenommen werden können.
Mit der Computer-Zentralsteuerungsgruppe werden alle Tätigkeiten im CBX-System gelenkt. Mit einer Einknoten-CBX werden 1 oder 2 Zentralsteuerungsetagen unterstützt. Etage 2 des Schrankes 1 wird immer mit einer Computer-Zentralsteuerungsgruppe belegt. Um die Verlaßlichkeit in kritischen Anwendungen oder größeren Systemen zu erhöhen, kann in der Etage 1 eine zweite bzw. redundante Zentralsteuerungsgruppe untergebracht werden.
Diese Gruppen bestehen aus:
* Steuerwerk
* Speicher
* TDM-Steuerkarte
* Diskettenlaufwerke
* Festplattenlaufwerk (nur Etage)
* Peripheriegerätesteuerung
* E/A-Karten
* Diagnosekarten
* Steuerungspaket-Netzschnittstelle (nur Mehrknoten)

Steuerwerk

Das Steuerwerk 9000 ist ein 32-Bit-Prozessor, der in der CBX eingesetzt wird. Er ist eine ROLM-Firmenkonstruktion mit leistungsfähiger schneller Bit-Slice- Technik und einem firmeneigenen Befehlssatz von ROLM. Mit einer Einzelknotenkonfiguration werden 7500 bis 11 000 Belegungsversuche (BHCA - Busy Hour Call Attempts) unterstützt; d.h. die Gesamtzahl von Verbindungsherstellungsversuchen während der Stunde, während der die CBX den meisten Verkehr führt. In einem redundanten System ist der das System steuernde Prozessor der aktive Prozessor; der andere ist der Ersatzprozessor. Von beiden Prozessoren kann eine Ersatz-Zentralsteuerung bereitgestellt werden, um zu vermeiden, daß ein Ausfall der aktiven Zentralsteuerung den Systembetrieb unterbricht. Vom aktiven Prozessor werden dauernd Neuinformationen wie Übertragungen und Änderung, Sprechstellen- Kurzwahlinformationen wie auch Gesprächszustandinformationen zum Ersatzcomputer übertragen. Bei einer Umschaltung vom aktiven Computer enthält daher der Ersatzcomputer stets laufende Informationen bezüglich des Systemzustands.
Alle 24 Stunden findet (gewöhnlich spät abends) eine systematische Umschaltung vom aktiven zum passiven Steuerwerk statt, um die Betriebsbereitschaft des Ersatzsteuerwerks sicherzustellen. Diese Redundanz hat einen praktisch unterbrechungsfreien Systembetrieb zur Folge.

Speicher

Zur Speicherung der gesamten Systemsoftware werden in der CBX RAM-Speicher benutzt. Im Speicher eingespeichert befinden sich die Systembetriebssoftware, systemspezifische Konfigurationsparameter und Betriebsdaten. Jeder Prozessor kann auf bis zu vier Speicherkarten zugreifen. Auf jeder Speicherkarte werden 1 Million Speicherworte aufgenommen, wobei jedes Wort aus 16 Bit plus 6 Fehlerkorrekturkode-(ECC)Bit besteht. ECC (Error Correcting Code) ist ein Verfahren aus der Computerindustrie und verbessert die Genauigkeit, mit der Informationen im Systemspeicher aufbewahrt werden. Durch selbständige Erkennung und Korrektur aller Einbitfehler im Speicher und Erkennung der meisten Mehrbitfehler wird dank ECC die Wahrscheinlichkeit eines Systemausfalls aufgrund eines fehlerhaften Speicherbauteils minimalisiert. Systeme mit redundanten Prozessoren sind in der Lage, Mehrbitfehler zu erkennen und selbsttätig zum redundanten Rechner umzuschalten. Darüber hinaus werden Fehler von einem Hardwareregister auf der Speicherkarte in eine Tabelle eingetragen, um die Wartung zu unterstützen.
Der Hauptvorteil der ECC liegt in der Beseitigung von "weichen Fehlern", die zahlreiche Kundendienstbesuche zur Folge haben können. Weiche Fehler sind intermittierende Fehlfunktionen, gewöhnlich von kurzer Dauer und geringer Häufigkeit, die sich aus der Ausführung spezifischer Datenmuster, der Raumtemperatur oder statischer Elektrizität zufolge ergeben können. Weiche Fehler können ein unregelmäßiges Systemverhalten verursachen und das Kundendienstpersonal dazu zwingen, Stunden mit der Suche nach einem Fehler, der vielleicht gar nicht existiert, zu verschwenden. Mit der Fehlererkennungs- und Korrekturfähigkeit werden die Verläßlichkeit des CBX- Systems verbessert und unnötige Stunden empirischer Fehlersuche eliminiert.

Erweiterter Kommunikationsrechner

Der erweiterte Kommunikationsrechner (ECP - Enhanced Communications Processor) ist ein Prozessor auf zwei Karten, mit dem ein schnellerer Datenverbindungsaufbau, eine Basis für zukünftige Datenprodukte und Anwendungen, und eine wirkungsvollere Nutzung der CBX-Steuerwerke geboten wird. Mit dem ECP werden die Datenverbindungsaufbaumeldungen vom CBX-Steuerwerk heruntergeladen. Außerdem ermöglicht er den Verbindungsaufbau mit der Baudrate des rufenden Geräts. Das erleichtert die Nutzung populärer Kommunikationspakete auf PC-Grundlage, die einen automatischen Datenverbindungsaufbau erlauben. Der ECP wird von den Vorschalt-Datenkarten (DFE - Data Front End) unterstützt, die in TDM-Etagen aufgenommen sind.

PLATTENSYSTEME

Die auf der Etage 2 untergebrachten Peripheriegeräte bestehen aus zwei 3,5 Zoll-Disketten mit 1,44 Mb und einer 5,25-Zoll-Festplatte mit 40 Mb und einer Peripheriegerätesteuerungskarte (PDC - peripheral device controller). Am rechten Ende des Baugruppenträgers befinden sich die Plattenbaugruppen. Von IBM werden die CBX- Systemsoftware, Release 9004.3, und Diagnoseprogramme auf Disketten bereitgestellt. Auf dem Diskettensystem sind Urladersoftware (IPL - Initial Program Load), eine Sicherungskopie der gegenwärtigen Anlagendatenbank und Softwareaktualisierungen (neue Softwarefreigaben) gespeichert.
Der Urlader IPL ist ein "Kaltstart"-Programm, mit dem Informationen von einer Diskette in den Arbeitsspeicher des Systems eingeladen und danach in die 40 Mb-Festplatte eingeschrieben werden. Das Urladen wird bei Installierung eines Systems am Standort eines Kunden von IBM-Technikern durchgeführt. Auf dem Festplattensystem befinden sich Plattenspeichermedien, die von der Umwelt abgeschlossen sind, um einen hohen Grad an Verläßlichkeit zu bieten. Die Festplatte enthält das Betriebssystemprogramm. Außerdem besitzt sie genügend Speicherkapazität für gewisse Sprach- und Datenanwendungen zur Speicherung von Informationen auf Echtzeitbasis. Beispielsweise sind auf der Festplatte Konfigurationstabellen, Übertragungen, Addierungen und Änderungen (MAC - Moves, Adds and Changes) und erzwungene Berechtigungskode (FAC - Forced Authorization Codes) enthalten. Mit einer Festplatte wird schnellerer Zugriff zur Unterstützung von Konfiguration und Übertragung und Änderung bereitgestellt, als mit Disketten zur Verfügung steht.
Mit der automatischen Programmladesoftware (APL - Automatic Program Load) wird das Betriebssystemprogramm überwacht. Nach einem 20 Minuten an Wechselstromnetzen überschreitenden Stromausfall (die maximale Zeitspanne, für die der Speicher von der Notbatterie unterhalten wird, bis die Stromversorgung wiederhergestellt ist), wird das Systemprogramm automatisch von der APL von der Festplatte neu geladen. Vorher wird der Speicherinhalt im RAM-Speicher aufbewahrt. Für Gleichstromsysteme ist APL nur dann notwendig, wenn das System den Batterie- Betriebsstrom verliert (ein seltener Vorfall).

DIAGNOSEKARTEN

Diagnosekarten (die Systemüberwachungskarte (SMC - System Monitor Card) und die redundante Etagenüberwachung (RSM - Redundant Shelf Monitor) sind in den Zentralsteuerungsbaugruppenträgern untergebracht.

Systemüberwachungskarte

Die Systemüberwachungskarte SMC (System Monitor Card) bietet Sicherungs-/Schaltkreis-Alarmmeldung, Software-Alarmmeldung, Temperatur-Alarmmeldung, Stromausfallerkennung und Gleichspannungsüberwachung. Diese Schaltkarte belegt einen Steckplatz im Zentralsteuerungsbaugruppenträger (Etage 2) in sowohl redundanten als auch nichtredundanten Konfigurationen.
Stromausfallanzeige-LED auf der SMC leuchten bei Spannungsabfall auf. Mit LED wird auch eine hohe Temperatur signalisiert. Sicherungsalarmschaltungen erzeugen bei Fehlfunktion einer Sicherung sowohl optische als auch akustische Alarmsignale. Elektrische Schnittstellen auf der SMC können von Außensystemen wie einer Netzkontrollzentrale (NCC - Network Control Center) überwacht werden. Über diese Schnitt stellen wird das NCC-Personal davon informiert, daß in einem Knoten ein spezifisches Problem aufgetreten ist.

Überwachung der redundanten Etage

Die Überwachung der redundanten Etage (RSM - Redundant Shelf Monitor) liefert Zustandsmeldungen über den Zustand der Zentralsteuerungsetage für die SMC. In den Modellen 50 und 70 ist eine RSM-Karte im Baugruppenträger der redundanten Prozessoren (Etage 1) aufgenommen.

Überwachung der örtlichen Etage

Auf jedem TDM- oder INL-83-Baugruppenträger sitzt eine Überwachung der örtlichen Etage (LSM - Local Shelf Monitor). Diese LSM überwachen den Zustand der TDM- Etagenstromversorgung und Temperatur und informieren die SMC über Probleme.

E/A-Anschlüsse

Die E/A-Schnittstelle wird von zwei E/A-Anschlußkarten, dem Wartungsanschluß (SMP - Service Maintenance Port) und dem seriellen Vierer-E/A-Anschluß bereitgestellt.

Wartungsanschluß

Der Wartungsanschluß (SMP - Service Maintenance Port) stellt eine 4-Kanal-Wartungsschnittstelle dar, die im Zentralsteuerungs-Baugruppenträger 2 aufgenommen ist. Zwei der vier Anschlüsse auf der SMP-Karte sind dauerhaft dem Systemendgerät und dem Systemmodem zugewiesen.
Die zwei verfügbaren Anschlüsse unterstützen:
* Endgeräte für automatische Anrufverteilung
* Datenstrecke für Systemverwaltung
* Gesprächsdatenerfassungslistenvorrichtung

Vierfacher serieller E/A-Anschluß

Auf Etage 2 im geschalteten E/A-Bus befindlich, stellt die vierfache serielle E/A-Karte Quad Serial I/O eine Kartenoption zur Erhöhung der von einem System unterstützbaren Anzahl Vorrichtungen dar. Die vierfache serielle E/A-Karte unterstützt vier Vorrichtungen für Merkmale wie erweiterte Verkehrsberichte (Expanded Traffic Reports), Statistiken über automatische Anrufverteilung (ACD - Automatic Call Distribution) und MAX. Die vierfache serielle E/A-Karte unterstützt folgende RS-232- C-Vorrichtungen nach ASCII, die mit Datenbitraten von bis zu 9,6 kB/s laufen:
* Modem
* Drucker oder nur-Ausgabe-Vorrichtungen
* Lader oder nur-Eingabe-Vorrichtungen
* "Intelligente" und "nichtintelligente" Endgeräte
* Endgeräte für automatische Anrufverteilung
* Schnittstelle zum Prozessor für die PhoneMail- Anwendung

SCHRANKAUSSTATTUNG UND STROMVERSORGUNG

Ein Knoten besteht aus einem bis fünf zusammengeschalteten Geräteschränken. Die maximale Einzelknoten- Konfiguration umfaßt 5 Schränke und insgesamt 20 Baugruppenträger. Von vorn gesehen, befindet sich der Schrank 1 links mit Etagen 1 bis 4. Als nächster kommt der Schrank 2 mit Etagen 5 bis 8, und Schrank 5 befindet sich ganz rechts mit Etagen 17 bis 20.
Baugruppenträger enthalten drei Gerätekategorien: Computer-Zentralsteuerung: TDM-Schnittstellenkarten für Leitungs-, Daten- oder Verbindungsleitungsschnittstellen; und INL 83 für Konten-Knoten-Kommunikation von Sprachund Dateninformationen.
Eine mehr ins einzelne gehende Besprechung der bevorzugten Betriebsweise ist im System Service Manual von ROLM, ROLM Corporation, Oktober 1987, enthalten.
Eine der Karten, die einen TDM-Steckplatz 68 der obenbeschriebenen TDM-Etage in Figur 1C belegt, ist die neue verbesserte Diagnosekarte Advanced Diagnostics. Ein Blockschaltbild der Karte wird in Figur 2 dargestellt. Zur Steuerung der verbesserten Diagnosekarte (ADC - Advanced Diagnostics card) und Logikverarbeitung wird ein Z80-Mikroprozessor 100 benutzt. Die Tasken, die die Fehleranalyse ermöglichende Logik implementieren, führen Befehle auf der ADC-Karte aus. Die ADC-Karte wird von vielen der in der detaillierten Analyse der Entscheidungsbaumverarbeitung beschriebenen Prüfungen benutzt. Die Überwachungstasklogik läuft auf einem der Steuerwerke in der CBX ab. Der Zeitmultiplexpuffer 110 stellt die Schnittstelle zwischen der ADC und dem TDM-Datenbus 140 dar. Es kommen zwei Datenaustauscharten vor: Prüfung und Steuerung. In der Zustandssteuerung 120 und den Signalverarbeitungsschnittstellen (SPI - Signal Processing Interfaces) 130 werden ankommende Signale gefiltert, eine Korrelation der Signale durchgeführt und eine Bitmusteranalyse der verschiedenen Karten in der CBX durchgeführt. Mit der ADC können auch Mehrfachfunktionen erzeugt werden und Sinuswellen, Rechteckwellen, Dreieckwellen, stückweise Linearfunktionen, Rauschen, digitale Bitmuster und Kombinationen aller dieser produziert werden.

ADC-Architektur

Die verbesserte Diagnosekarte (ADC) wird zur Erzeugung und Verarbeitung von Prüfdaten benutzt. Die Karte ist ein Mehrfunktionsgenerator, der Sinuswellen, Rechteckwellen, Dreieckwellen, stückweise lineare Funktionen, Rauschen und Kombination aller dieser sowie für Bitmusteranalyse geeignete digitale Prüfmuster erzeugen kann.
Darüber hinaus stellt die Karte eine flexible Analysevorrichtung dar. Mit ihr können ankommende Signale gefiltert, Effektivwertschätzungen durchgeführt, Korrelation hergestellt und Bitmusteranalyse ausgeführt. Sie kann damit als ein Generator zur Prüfung von Registerkarten, als Empfänger zur Prüfung von Senderkarten und als Sender und auch Empfänger zur Prüfung von Karten, mit denen eine Vollduplexverbindung hergestellt werden kann, benutzt werden.

Funktionsweise

Die Figur 2 zeigt ein Blockschaltbild der Karte. Sie besteht aus drei Hauptbereichen: der Zeitmultiplex- (TDM)Puffer, die Z80-Steuerung und der Signalverarbeitungsteil.

TDM-Puffer

Der TDM-Puffer stellt die Schnittstelle zwischen der ADC-Karte und dem TDM-Datenbus dar. Daten vom Bus werden in den Puffer eingeschrieben und von der ADC-Karte ausgelesen. Daten von der ADC-Karte werden in den Puffer eingeschrieben und vom TDM-Bus ausgelesen.
Es können zweierlei Datenaustauscharten vorkommen: Prüfung und Steuerung. Prüfsignale bestehen aus zum Prüfen einer anderen Karte benutzten Signalen zu und von der ADC. Beispielsweise würde man beim Prüfen eines MFV- Registers eine MFV-Ziffer von der ADC senden. Zur Steuerung gehören Befehle von der und Reaktionen auf die on- line-Software. Beispielsweise wäre ein typischer Befehl "Run MFV-Register-Prüfung" und eine typische Reaktion wäre "Prüfung abgeschlossen". Prüfdaten werden im fortlaufenden Feld der Verbindungstabelle ausgetauscht, während Befehle und Reaktionen im Direktfeld vorkommen.

Z80-Steuerung

Zur Steuerung der ADC-Karte wird der Z80-Mikroprozessor benutzt. Er akzeptiert Befehle von der Software, stellt die Signalprozessoren zur Durchführung der befohlenen Handlungen ein und meldet die Ergebnisse der Prüfungen an die Software. Der Z80 wird durch Direktfeldbefehle von der Software unterbrochen und ist von Dauerfeldverbindungen unbeeinflußt.

Signalverarbeitungsteil

Die eigentliche Signalverarbeitung wird größtenteils durch die drei NEC-Bausteine DP7720 Signal Processing Interface (SPI) durchgeführt. Diese Bausteine sind speziell für Signalverarbeitungsanwendungen ausgelegt. Einer der SPI-Bausteine ist der Signalerzeugung, einer der Signalerkennung und einer der Steuerung zugeordnet.
Daten werden zwischen den SPI-Bausteinen und dem Anschluß 1 des TDM-Puffers durch die SPI-Steuerung übertragen. Vom Anschluß 1 wird der SPI-Steuerung die nächst höhere Priorität nach einer Übertragung zum TDM- Bus erteilt. Die SPI-Steuerung ist eine ROM-gesteuerte Zustandsmaschine. Sie ist in der Lage, 256 Worte im TDM- Puffer-RAM zu adressieren. Auch kann sie die einzelnen RESET- und INTERRUPT-Leitungen auf jedem SPI-Baustein steuern. Sie kann sowohl bedingte als auch unbedingte Sprungbefehle ausführen, hat einen Befehlszyklus von einer Mikrosekunde und wird von einem 16-MHz-Takt angesteuert, der auch zum Ansteuern der 8-MHz-Takte für die SPI-Bausteine und den Steuerungsprozessor benutzt wird.

Schalter und Leuchtdioden

Auf der ADC-Karte befindet sich eine rote LED. Wenn diese leuchtet, zeigt das an, daß die Karte von der Systemsoftware stillgelegt (DOWNed) worden ist. Die LED leuchtet auch, wenn die Versorgungsschnur an die Karte angeschlossen ist. Auf der Karte befinden sich keine Schalter.

Stecker-Anschlußbelegungen

Für den Verkehr mit dem TDM-Bus benutzt die ADC- Karte den Stecker P2. Von den +5V- und +15V-Stiften des Steckers P2 bezieht die Karte auch ihren Strom. Der Stecker P3 wird von der Versorgungsschnur benutzt. Die Stecker P1, P4 und PS sind nicht im Gebrauch.

Steckverbinder

Die Figuren 3, 4 und 5 zeigen die Stiftnummern, Signalnamen, Quellen, Ziele und Funktionen des Steckers P2. In Figur 6 wird das gleiche für den Stecker P3 dargestellt.

Sendebefehle

In den Figuren 7 und 8 werden die Sendebefehl-Bitanordnungen, Mnemonik und Funktionen dargestellt. Es folgt eine Besprechung der einzelnen Befehle.

(0 010 0.00 000) X0ADC - Sendeanreiz 1

Mit dem Befehl Transmit 0 (X0ADC) wird von der ADC-Karte fortlaufend ein Anreiz erzeugt. Der Anreiz kann je nach Prüfung die Summe einer von sieben verschiedenen Eingaben (Sinuswelle, Rauschen usw.) sein. Ausgabe entsprechend u-Kennlinie siehe X1ADC.

(0 010 0.00 010) X1ADC - Sendeanreiz 1

Mit dem Befehl Transmit 1 (X1ADC) wird von der ADC-Karte fortlaufend ein Anreiz nach u-Kennlinie erzeugt. Der Anreiz kann je nach Prüfung die Summe einer von sieben verschiedenen Eingaben (Sinuswelle, Rauschen usw.) sein. Ausgabe nach linearer Kennlinie siehe X0ADC.

(0 010 0.00 100) X2ADC - Sendeanreiz 2

Mit dem Befehl Transmit 2 (X2ADC) wird von der ADC-Karte fortlaufend ein Anreiz erzeugt. Der Anreiz kann je nach Prüfung die Summe einer von sieben verschiedenen Eingaben (Sinuswelle, Rauschen usw.) sein. Die X2ADC ist eine zweite Summe ähnlich X0ADC, mit der ein zweiter Anreiz erzeugt werden kann. Ausgabe nach u-Kennlinie siehe X3ADC.

(0 010 0.00 110) X3ADC - Sendeanreiz 2 u-Kennlinie

Mit dem Befehl Transmit 3 (X3ADC) wird von der ADC-Karte fortlaufend ein Anreiz nach u-Kennlinie erzeugt. Der Anreiz kann je nach Prüfung die Summe einer von sieben verschiedenen Eingaben (Sinuswelle, Rauschen usw.) sein. Die X3ADC ist eine zweite Summe nach u-Kennlinie ähnlich X1ADC, mit der ein zweiter Anreiz erzeugt werden kann. Ausgabe nach linearer Kennlinie siehe X2ADC.

(0 010 0.00 111) TDMW - Transmit Digital Milliwatt

Mit dem Befehl Transmit Digital Milliwatt (TDMW) wird von der ADC-Karte fortlaufend das digitale Milliwatt-Muster erzeugt. Das Binärmuster nach u-Kennlinie für diese Prüfung ist in Figur 9 dargestellt.

(0 010 0.01 000) X4ADC - Ausgabe Transmit FIR

Mit dem Befehl Transmit 4 (X4ADC) wird die Ausgabe der FIR-Stufe an den TDM-Bus angelegt. Dieses Signal ist hauptsächlich für Diagnosezwecke (zur Überprüfung des FIR-Frequenzganges) gedacht. Damit kann die ADC- Karte jedoch als digitale Filterstufe benutzt werden. Ausgabe nach u-Kennlinie siehe X5ADC.

(0 010 0.01 010) X5ADC - Ausgabe Transmit FIR u-Kennlinie

Mit dem Befehl Transmit 5 (X5ADC) wird die Ausgabe der FIR-Stufe nach u-Kennlinie an den TDM-Bus angelegt. Dieses Signal ist hauptsächlich für Diagnosezwecke (zur Überprüfung des FIR-Frequenzganges) gedacht. Damit kann die ADC-Karte jedoch als Digitalfilter benutzt werden. Ausgabe nach linearer Kennlinie siehe X4ADC.

(0 010 0.01 011) TZSC - Transmit Z80 Status and Clear

Mit dem Befehl Transmit Z80 Status and Clear (TZSC) wird das Z80-Statusregister ausgelesen und danach das Register auf nur Nullen gelöscht. Bezugnehmend auf Figur 10 ist das höchstwertige Bit (MSB) auf eins gesetzt, wenn der Z80 belegt ist. Das CKSM-Bit ist auf 1 gesetzt, wenn die Prüftabelle im RAM-Speicher einen Prüfsummenfehler enthält. Der Z80 überprüft fortlaufend die Prüftabelle durch Durchführung einer Prüfsumme zur Sicherstellung, daß die Tabelle nicht verfälscht worden ist. Das CRJT-Bit ist auf 1 gesetzt, um anzuzeigen, daß ein RTESTN-Befehl zurückgewiesen worden ist. Der zurückgewiesene Befehl kann mit dem TREJCMD-Befehl nachgelesen werden. Ein Befehl wird aus folgenden Gründen zurückgewiesen: (1) Es wurde eine nichtimplementierte Prüfnummer angefordert. (2) Der Z80 ist bereits mit einer anderen Prüfung belegt. (3) Eine Prüftabelle von 0 wurde für eine Prüfung angegeben, die eine Prüftabelle erfordert. Eine Prüftabelle von nicht null wurde angegeben, und die Prüftabelle ist nicht geladen, oder die Prüftabelle enthält einen Prüfsummenfehler.
Das Bit DONE wird auf 1 gesetzt, wenn eine Prüfung vollendet ist. Bei Beginn der nächsten Prüfung wird es auf null gelöscht. Das Bit WARM wird auf eins gesetzt, wenn der Z80 eine (von dem Softwarebefehl WRST eingeleitete) warme Rücksetzung durchführt. Das Bit COLD wird auf 1 gesetzt, wenn der Z80 eine (durch einen Befehl DOWN, Systemnormalisierung oder Versorgungsschnur eingeleitete) kalte Rücksetzung durchführt. Es ist beachtenswert, daß bei einem laufenden Test nur der TZS-Befehl zur Abfrage des BUSY-Bit benutzt werden sollte. Der TZSC- Befehl bewirkt eine Unterbrechung am Z80, und die Prüfungsergebnisse können bei Empfang zu vieler Unterbrechungen ungültig werden.

(0 010 0.01 100) TZS - Transmit Z80 Status

Mit dem Befehl Transmit Z80 Status (TZS) wird das Z80-Statusregister ohne Löschen des Registers ausgelesen. Bezugnehmend auf Figur 10 ist das BUSY-Bit auf 1 gesetzt, wenn der Z80 mit einem Prüfungsablauf beschäftigt ist. Das Bit CKSM ist auf 1 gesetzt, wenn die Prüfungstabelle im RAM-Speicher einen Prüfsummenfehler enthält. Der Z80 überprüft fortlaufend die Prüftabelle durch Durchführung einer Prüfsumme zur Sicherstellung, daß die Tabelle nicht verfälscht worden ist. Das CRJT-Bit ist auf 1 gesetzt, um anzuzeigen, daß ein RTESTN-Befehl zurückgewiesen worden ist. Der zurückgewiesene Befehl kann mit dem TREJCMD- Befehl nachgelesen werden. Ein Befehl wird aus folgenden Gründen zurückgewiesen: (1) Es wurde eine nichtimplementierte Prüfnummer angefordert. (2) Der Z80 ist bereits mit einer anderen Prüfung belegt. (3) Eine Prüftabelle von 0 wurde für eine Prüfung angegeben, die eine Prüftabelle erfordert. Eine Prüftabelle von nicht 0 wurde angegeben, und die Prüftabelle ist nicht eingeladen, oder die Prüftabelle enthält einen Prüfsummenfehler. Das Bit DONE ist bei Abschluß einer Prüfung auf eins gesetzt. Es wird bei Beginn der nächsten Prüfung auf null gelöscht. Das Bit WARM ist auf 1 gesetzt, wenn der Z80 eine (von dem Softwarebefehl WRST eingeleitete) warme Rücksetzung durchführt. Das Bit COLD ist auf 1 gesetzt, wenn der Z80 eine (von einem DOWN-Befehl, Systemnormalisierung oder Versorgungsschnur eingeleitete) kalte Rücksetzung durchführt.

(0 010 0.01 101) TZD - Transmit Z80 Data

Mit dem Befehl Transmit Z80 Data (TZD) werden die Datenergebnisse von den Prüfungen zum TDM-Bus gesendet. Information über die Daten siehe einzelne Prüfungen. In Transmit Z80 Data Count Out (TZDCO) ist eine Zählung der Anzahl von auf die Ausgabe wartenden Datenworten enthalten. Mit dem Beginn einer neuen Prüfung werden alle verbleibenden Datenworte verworfen.

(0 010 0.01 110) TZDP - Transmit Z80 Data Permanent

Mit dem Befehl Transmit Z80 Data Permanent (TZDP) werden die Z80-Ausgabedaten zum TDM-Bus gesandt. Dieser Befehl ist bei Herstellung einer Permanentfeldverbindung zu benutzen.

(0 010 0.01 111) TZDCO - Transmit Z80 Data Count

Mit dem Befehl Transmit Z80 Data Count Out (TZDCO) wird der Zählstand der ausgabebereiten Worte zum TDM-Bus gesandt. Bei Beendung einer Prüfung werden die Daten über TZD für die Ausgabe bereitgestellt, und der Zählstand der auszugebenden Datenworte wird hier geladen, mit jeder Ausführung eines TZD-Befehls wird der Zählstand um eins erniedrigt, bis er null erreicht.

(0 010 0.10 001) TZDCI - Transmit Z80 Data Count In

Mit dem Befehl Transmit Z80 Data Count In (TZDCI) wird der Zählstand der noch vom TDM-Bus auf zunehmenden Worte abgesandt. Bei Beginn einer Prüfung wird damit die erforderliche Zählung gesetzt, und wenn der Zählstand null erreicht, beginnt die Prüfung.

(0 010 0.11 000) TSPED0 - Transmit Speek Data 0

Der Befehl Transmit Speek Data 0 (TSPED0) ist Teil der SPI-Überwachung. Im Zusammenhang mit dem Befehl RSPEA0 kann jeder Platz im SPI-RAM-Speicher zum TDM-Bus übertragen werden. Mit dem RSPEA0-Befehl sollte die Speicherplatzadresse vor Aus lesen der Daten mit TSPED0 geladen worden sein. Es ist beachtenswert, daß dieser Befehl für Off-line-Benutzung bestimmt ist.

(0 010 0.11 001) TREJCMD - Transmit Rejected Command

Mit dem Befehl Transmit Rejected Command (TREJCMD) wird die letzte mit RTESTN angegebene Prüfnummer, die von der ADC-Karte zurückgewiesen wurde, gesandt. Bei Zurückweisung des Befehls RTESTN wird das Bit Command Reject (CRJT) im TZSC/TZS-Register gesetzt.

(0 010 0.11 010) TSPED1 - Transmit Speek Data 1

Der Befehl Transmit Speek Data 1 (TSPED1) ist Teil der SPI-Überwachung. Im Zusammenhang mit einer voreingestellten Adresse (spoked address) kann jeder Speicherplatz im RAM der Steuer-SPI zum TDM-Bus hinaus übertragen werden. Es ist beachtenswert, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

(0 010 0.11 100) TSPED2 - Transmit Speek Data 2

Der Befehl Transmit Speek Data 2 (TSPED2) ist Teil der SPI-Überwachung. Im Zusammenhang mit einer voreingestellten Adresse (spoked address) kann jeder Speicherplatz im RAM der Erzeugungs-SPI zum TDM-Bus hinaus übertragen werden. Es ist beachtenswert, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

(0 010 0.11 101) TPD - Transmit Peek Data

Mit dem Befehl Transmit Peek Data (TPD) kann jeder Speicherplatz im Z80-RAM zum TDM-Bus hinaus übertragen werden. Die Adresse des gewünschten RAM-Speicherplatzes wird mit dem Befehl RPA gesetzt.

(0 010 0.11 110) TSPED3 - Transmit Speek Data 3

Der Befehl Transmit Speek Data (TSPED3) ist Teil der SPI-Überwachung. Im Zusammenhang mit einer voreingestellten Adresse (spoked address) kann jeder Speicherplatz im RAM der Erkennungs-SPI zum TDM-Bus hinaus übertragen werden. Es ist beachtenswert, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

(1 111 1.XX XXX) TCID - Transmit Card ID

Mit dem Befehl Transmit Card IDentification (TCID) kann die On-line-Software die Kartenart und Revisionsnummer der ADC-Karte überprüfen. Der Befehl ergibt folgende Informationen: (a) Feld Card ID: Ein Wert von 00011010 (hexadezimal 1A) bedeutet eine ADC-Karte. (b) Card Revision Number: In diesem Feld wird die Karten- Revisionsnummer angezeigt.

Empfangsbefehle

Die Adreßbus-Adressen, Kürzel und Funktionen der Empfangsbefehle sind in Figuren 11 und 12 dargestellt. Untenstehend folgt eine Beschreibung jedes Befehls und seiner Funktion.

(0 000 0.00 000) R0ADC - Receive Sample Input Word 1

Mit dem Befehl Receive 0 (R0ADC) wird eine TDM- Dauerverbindung zur ADC-Karte für die Aufnahme von Daten (FIR-Eingabe, Signatur durch Probeeingabe) zur Auswertung hergestellt.

(0 000 1.XX XXX) DOWN - Cold Reset to Card

Der Befehl DOWN ist die Softwareversion von System Normalize (SYN), nur blockiert er Datenübertragung auf den TDM-Datenbus und läßt die LED Down aufleuchten.

(0 000 0.00 010) R1ADC - Receive Sample Input Word 2

Der Befehl Receive 1 (R1ADC) ist eine weitere Eingabe für den Empfang von Daten. Einzelheiten siehe R0ADC.

(0 001 1.XX XXX) UP - Return Card to TDM Data Bus

Mit dem Befehl UP können Daten auf den TDM- Datenbus übertragen und die LED DOWN gelöscht werden.

(0 000 0.01 101) RZD - Receive Z80 Data

Der Befehl Receive Z80 Data (RZD) wird dazu benutzt, zur ADC-Karte übertragene Daten wortweise aufzunehmen. Es ist beachtenswert, daß mit dem RZD-Befehl eine Unterbrechung am Z80 bewirkt wird. Wenn er im selben Rahmen wie ein anderer Befehl, der den Z80 unterbricht (z.B. der TDMW-Befehl), benutzt wird, können Daten verlorengehen

(0 000 0.01 110) RZDP - Receive Z80 Data Permanent

Der Befehl Receive Z80 Data Permanent (RZDP) wird dazu benutzt, zur ADC-Karte übertragene Daten wortweise im permanenten Feld aufzunehmen. Es ist beachtenswert, daß mit dem RZDP-Befehl keine Unterbrechung am Z80 bewirkt wird.

(0 000 0.01 111) RTESTN - Receive Test Number

Mit dem Befehl Receive Test Number (RTESTN) wird eine Prüfnummer und eine Tabellennummer zum Z80 weitergegeben.

(0 000 0.10 001) WRST - Warm Reset

Mit dem Befehl Warm Reset (WRST) initialisiert der Z80, als wenn ein System Normalize (SYN) empfangen worden wäre. Der einzige Unterschied zwischen Cold Reset und Warm Reset besteht darin, daß ein Warm Reset von Software und ein Cold Reset von Hardware (d.h. SYN) eingeleitet wird.

(0 000 0.10 010) RSTR - Receive SPI Start

Mit dem Befehl Receive SPI Start (RSTR) und Daten, die nicht null sind, wird die nächste SPI-Task in der Tasken-Warteschlange gestartet. Es ist beachtenswert, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

(0 000 0.10 011) RSTOPT - Receive Stop Test

Mit dem Befehl Receive Stop Test (RSTOPT) wird eine laufende Prüfung gestoppt. Er muß zum Anhalten der Dauer-Sinusprüfung benutzt werden. Er kann zum Abbrechen aller anderen Prüfungen benutzt werden. Es ist beachtenswert, daß von einer abgebrochenen Prüfung keine Ergebnisse erhalten werden.

(0 000 0.10 100) RSPEA0 - Receive Speek Address 0

Mit dem Befehl Receive Speek Address 0 (RSPEA0) wird die Speek-Adresse in den SPI-Speicher eingeschrieben. Die adressierten Daten können über den Befehl TSPED0 ausgelesen werden. Es ist beachtenswert, daß dieser Befehl zur Off-line-Verwendung bestimmt ist. Er muß in zwei aufeinanderfolgenden Direktfeldern abgesandt werden, und vor Ablauf eines Rahmens können keine Daten ausgelesen werden.

(0 000 0.10 101) LOADTBL - Load Test Table

Mit dem Befehl Load Test Table (LOADTBL) wird die ROM-Prüftabelle in RAM einkopiert, als wenn sie von On- line-Software heruntergeladen worden wäre. Die Testtabelle in ROM kann weniger aktuell sein als die, die von der On-line-Software heruntergeladen wurde. Dieser Befehl sollte nur für Fehlersuche und nicht als Ersatz für Herunterladen benutzt werden. Dieser Befehl ist zur Off-line-Verwendung bestimmt.

(0 000 0.10 110) RSPOD0 - Receive Spoke Data 0

Der Befehl Receive Spoke Data 0 (RSPOD0) ist Bestandteil der SPI-Überwachung. Mit diesem und dem Befehl RSPOA0 können wir jeden Speicherplatz im SPI-RAM von der TDM-Steuerung aus beschreiben. Mit RSPOD0 erhält die ADC-Karte die einzufügenden (spoked - SPI poked) Daten. Vor Einladen der Daten mit RSPOD0 sollte RSPOA0 mit der Adresse eingeladen worden sein. Der Befehl RSPOD0 ist zur Off-line-Verwendung bestimmt.

(0 000 0.11 000) RSPOA0 - Receive Spoke Address 0

Mit dem Befehl Receive Spoke Address 0 (RSPOA0) wird die Spoke-Adresse in den SPI-Speicher eingeladen, damit die RSPOD0-Daten eingefügt werden können. Dieser Befehl ist zur Off-line-Verwendung bestimmt. Er muß in zwei aufeinanderfolgenden Direktfeldern abgesandt werden, und keine Daten können vor Ablauf eines Rahmens ausgelesen werden.

(0 000 0.11 001) RUSA - Receive User Subroutine Address

Mit dem Befehl Receiver User Subroutine Adress (RUSA) kann mit einem TDM-Befehl ein Benutzer-Unterprogramm aufgerufen werden. Die weitergegebenen Daten werden in den Taskzähler eingeladen und werden daher zur Unterprogrammadresse. Das Benutzer-Unterprogramm wird durch ein RET (Rücksprung vom Unterprogramm) im Z80-Kode abgeschlossen.

(0 000 0.11 010) RSPOD1 - Receive Spoke Data 1

Mit dem Befehl Receive Spoke Data 1 (RSPOD1) werden Daten in die Steuer-SPI eingefügt. Datenformat siehe RSPOA0. Dieser Befehl ist zur Off-line-Verwendung bestimmt.

(0 000 0.11 011) RPD - Receive Poke Data

Mit dem Befehl Receive Poke Data (RPD) kann jede Stelle im Z80-Adreßraum modifiziert werden. Die einzuschreibenden Daten werden aus diesem Befehl entnommen, und die Adresse wird dem vorhergehenden RPA-Befehl entnommen.

(0 000 0.11 100) RSPOD2 - Receive Spoke Data 2

Mit dem Befehl Receive Spoke Data 2 (RSPOD2) werden Daten in die Generier-SPI eingeführt. Datenf ormat siehe RSPOA0. Es ist zu beachten, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

(0 000 0.11 101) RPA - Receive Peek/Poke Address

Der Befehl Receive Peek/Poke Address (RPA) dient einem doppelten Zweck, da er die Adresse für beide Befehle TPD und RPD liefert.

(0 000 0.11 110) RSPOD3 - Receive Spoke Data 3

Mit dem Befehl Receive Spoke Data 3 (RSPOD3) werden Daten in die Erkennungs-SPI eingefügt. Datenformat siehe RSPOA0. Es ist zu beachten, daß dieser Befehl zur Off-line-Verwendung bestimmt ist.

Datenformate (Sende- und Empfangsdaten)

In Figur 13 wird das sechzehn-Bit-Muster dargestellt, das für alle Sende- und Empfangsdatenanweisungen benutzt wird. In Figuren 14 und 15 werden die alternativen Muster gezeigt, die für die Daten nach u-Kennlinie und die linearen zwölf-Bit-Datenübertragungen und -empfänge benutzt werden. Es ist zu beachten, daß das Raster für Direktfeldbefehle und alle Befehle, die den ADC-Steuerrechner unterbrechen (Befehle, bei denen das niedrigstwertige Bit gesetzt ist) einen Rahmen beträgt.

Beschreibungen der Prüfungen

In Figur 16 wird eine Beschreibung der verschiedenen Prüfnummern und eine kurze Beschreibung ihrer Funktionen geboten. Eine allgemeine Beschreibung des Formats wird zur Beschreibung der Funktionsweise jeder Prüfung und der erwarteten Wechselwirkung der On-line- Software mit der ADC bei Durchlaufen der Prüfung benutzt. Nach dem Beschreibungsteil wird jeder der weiteren Teile in der zeitlichen Abfolge seiner Ausführung aufgeführt. Auf On-line-Softwareaktionen wird mit SW Bezug genommen, und auf die ADC-Aktionen wird mit ADC Bezug genommen.
SW-Verbindungen sind die von der On-line-Software vor Prüfungsbeginn herzustel lenden TDM-Verbindungen.
Der SW-Vorprüfungsteil ist der von der On-line- Software zum Starten der Prüfung zu benutzende Befehl RTESTN. Sollte die ADC-Karte bei Empfang von RTESTN mit einer Prüfung beschäftigt sein oder die Prüfnummer ungültig sein, so wird das Bit COMMAND REJECT in den TZSC/TZS-Statusworten gesetzt und die angeforderte Prüfnummer in TREJCMD sichergestellt.
Der ADC-Vorprüfungsteil ist die von der ADC-Karte vor Prüfungsbeginn durchgeführte Initialisierung. Im allgemeinen wird das BUSY-Bit gesetzt. Dieses Bit wird nach Vollendung der Prüfung gelöscht. Um zu bestimmen, wann die Prüfung beendet ist, kann dieses Bit von On- line-Software abgefragt werden. Sollten Parameterworte auf zunehmen sein, so wird die Wortzahl in TZDCI eingeladen. Mit jedem Empfang eines Wortes über den Befehl RZD wird TZDCI um eins erniedrigt. Wenn TZDCI einen Zählstand null erreicht, beginnt die Ausführung der Prüfung. Während der Durchführung einer Prüfung sollte nur der TZS-Befehl zur Abfrage des BUSY-Bits benutzt werden. Der Befehl TZSC bewirkt eine Unterbrechung am Z80-Mikroprozessor auf der ADC-Karte, und die Prüfungsergebnisse können, wenn Z80 zu viele Unterbrechungen empfängt, ungültig werden.
Der SW-Parametereingabeteil ist das Format aller zusätzlichen Parameter, die ggf. von On-line-Software zur ADC-Karte zu senden sind. Die Worte werden mit dem RZD- Befehl geladen.
Der Ausführungsteil beschreibt die von der ADC- Karte zur Ausführung der Prüfung durchgeführten Aktionen.
Der ADC-Nachprüfungsteil beschreibt die von der ADC-Karte nach Ablauf einer Prüfung durchgeführten Aktionen. Im allgemeinen wird TZD mit dem ersten Resultatausgabewort beladen. TZDCO wird mit der Anzahl verfügbarer Resultatausgabeworte beladen. Danach wird das BUSY- Bit gelöscht, und das DONE-Bit gesetzt.
Der SW-Nachprüfungsteil beschreibt die von der On-line-Software nach Ablauf der Prüfung durchzuführenden Aktionen.
Der SW-Resultatausgabeteil beschreibt das Format der Resultatausgabe von der ADC-Karte. Die Resultate werden mit dem TZD-Befehl ausgelesen. TZDCO zeigt an, wieviele Worte verfügbar sind. Es ist nicht notwendig, alle Worte auszulesen. Sollten mehr als TZDCO-Worte ausgelesen werden, wird das von TZD empfangene Muster das in Figur 9 dargestellte digitale Milliwattmuster sein.

Test 1 Load Tabel Data:

damit wird eine Prüftabelle von der Systemsoftware in den ADC-RAM heruntergeladen.
SW Connections: keine benötigt.
SW-Vorprüfung: 0001H zu RTESTN, Start Test-Nummer 1. NNNNH zu RZD erstes Wort (d.h. Wortzählung) der Prüftabelle zum Z80.
ADC-Vorprüfung:
8 XXXH zu TZSC setzen Busy
8XXXH zu TZS setzen Busy
CCCCH to TZDCI laden Anzahl übriger auszulesender Worte.
SW-Parametereingabe: Beschreibung der herunterzuladenden Tabellen siehe Figur 19.
Ausführung: Die On-line-Software beendet das Herunterladen der Tabelle, indem sie ein Wort (maximal einmal pro Rahmen) zu RZD sendet. Die ADC-Karte liest ein Wort für jeden RZD-Befehl und erniedrigt den Zählstand in TZDCI, bis der Zählstand null erreicht.
ADC-Nachprüfung:
0XX4H zu TZSC löschen Busy und setzen Done
0XX4H zu TZS löschen Busy und setzen Done
Der Z80 erstellt eine Prüfsumme der heruntergeladenen Tabelle. Bei falscher Prüfsumme wird XX8XH in TZSC und TZS geODERt.
SW-Nachprüfung: keine
SW-Resultatausgabe: keine
Test 2 Analoge Prüfschleife/Kanalprüfung: überprüft alle Analogkarten. Es werden vier Messungen durchgeführt: Verstärkung, Verzerrung, Ruhegeräusch und Nebensprechen. In der Prüftabelle werden sowohl Toleranz- als auch Fehlergrenzen angegeben. Die Verstärkung und Verzerrung werden mit einer Datenmenge berechnet. Es werden zwei Töne 128 Millisekunden lang erzeugt. Einer liegt auf 305 Hz und der andere auf 2992 Hz. Die Prüfkarte wird in den Analog-Prüfschleifenmodus versetzt, und die zurückgeschleiften Daten werden zurück zur ADC gesandt. Für jeden Empfangston wird eine Korrelation durchgeführt, um die Verstärkung jedes Tons zu messen. Verzerrung wird durch Berechnung des Verhältnisses des Empfangstonpegels zur Gesamtempfangsleistung gemessen.
Ruhegeräusch wird durch 128 Millisekunden Pausenübertragung zur Prüfkarte und Messung der Leistung des rückgeschleiften Signals nach Durchlaufen eines nach C-Kennlinie gewichteten Filters gemessen.
Nebensprechen wird durch 128 Millisekunden Übertragung der zwei Töne zum Nebensprecherkanal gemessen. Für jeden von dem Prüfkanal empfangenen Ton wird zum Messen des Pegels jedes Signals, das vom Nebensprechkanal hinüberstreut, eine Korrelation durchgeführt.
SW-Verbindungen:
X1ADC ==> Prüfkanal
X3ADC ==> Kanal für Nebensprechen
R0ADC < == Prüfkanal (analoge Prüfschleife gewählt)
SW-Vorprüfung: TT02H zu RTESTN Start Test-Nummer 2 (TT zeigt auf Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZSC setzen Busy
8XXXH zu TZS setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC fährt Kanalprüfung.
ADC-Nachprüfung:
BBBBH zu TZD laden erstes Resultatausgabewort
0009H zu TZDCO laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC löschen Busy und setzen Done
0XX4H zu TZS löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Resultatausgabe:
Wort 1: Fehler Toleranz Pegel Ton Toleranz Signal/Leistungsverhältnis Toleranz Ruhegeräusch Toleranz Nebensprechen Fehler Pegel Ton Fehler Signal/Leistungsverhältnis Fehler Ruhegeräusch Fehler Nebensprechen
Wort 2: gemessener Pegel Ton 1 in dB*128.
Wort 3: gemessener Pegel Ton 2 in dB*128.
Wort 4: berechnete Gesamt-Tonleistung in dB*128.
Wort 5: gemessener effektiver Leistungspegel in dB*128.
Wort 6: berechnetes Pegelverhältnis Gesamttonleistung/Effektivleistung in dB*128.
Wort 7: gemessener Pegel Ruhegeräusch-Effektivleistung in dB*128.
Wort 8: gemessener Nebensprechpegel Ton 1 in dB*128.
Wort 9: gemessener Nebensprechpegel Ton 2 in dB*128.
Test 3 Digitale Prüfschleifenprüfung (8 Bit): bietet eine 8-Bit-, nach u-Kennlinie kodierte digitale Prüfschleifenüberprüfung. Sie erzeugt ein digitales Muster, das ein Mehrfrequenzsignal darstellt. Das digitale Muster wird zum Prüfkanal gesendet, und die empfangenen Prüfschleifendaten werden mit einer Signaturauswertung eingesammelt. Die berechnete Signatur wird mit einer Tabelle gültiger Signaturen bzw. Bitkombinationen verglichen, um nachzuweisen, daß keine Fehler aufgetreten sind.
Um Kanäle mit unterschiedlichen Laufzeiten zu berücksichtigen, enthält die Tabelle gültige Signaturenwerte für Laufzeiten von 0 bis 6 Rahmenperioden. Um sicherzustellen, daß alle alten Daten aus dem Laufzeitschlauch verschwunden sind, wird das digitale Muster eine Zeit lang vor Beginn der Signaturauswertung übertragen.
Auch wird ein 1-kHz-Ton erzeugt, der zu einem anderen Kanal übertragen werden kann, um zu überprüfen, ob Nebensprechprobleme bestehen.
SW-Verbindungen:
X1ADC ==> digitaler 8-Bit-Prüfkanal
X3ADC ==> digitaler 8-Bit-Nebensprechkanal
R0ADC < == digitaler 8-Bit-Prüfkanal (Prüfschleife gewählt)
SW-Vorprüfung:
TT03H zu RTESTN Start Test-Nummer 3 (TT zeigt auf Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZSC setzen Busy
8 XXXH zu TZS setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC fährt Prüfschleifenprüfung.
ADC-Nachprüfung:
BBBBH zu TZD laden erstes Resultatausgabewort
0002H zu TZDCO laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC löschen Busy und setzen Done
0XX4H zu TZS löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Ergebnisausgabe:
Wort 1 wird zur Fehlermeldung benutzt. Bei gesetztem höchstwertigem Bit ist in der Rückschleifenprüfung ein Fehler aufgetreten.
Mit Wort 2 wird die errechnete Signaturauswertung rückgemeldet. LAUFZEIT SIGNATUR Anmerkung: Bei einer Verzögerung von 10 oder 11 wird ein unbelegter TDM-Kanal oder eine nicht der u-Kennlinie entsprechende Kodierung angenommen.
Test 4 Tongeberprüfung: bestätigt, daß die vom Tongeber gesendeten Töne korrekt sind. Zur Überprüfung, daß jeder Ton des Paares vorhanden ist und über einem Mindestpegel liegt, werden zwei gleichzeitige Korrelationen durchgeführt. Zur Überprüfung, daß keine anderen Frequenzen vorhanden sind (was bei zu hohen Verzerrungen der Fall sein würde), wird eine Gesamtleistungsmessung durchgeführt.
SW-Verbindungen: R0ADC - Geprüfter Tongeberkanal
SW-Vorprüfung: TT04H zu RTESTN - Start Test-Nummer 4 (TT zeigt Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZCS - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC fährt Tonkorrelationen.
ADC-Nachprüfung:
BBBBH zu TZD - laden erstes Resultatausgabewort
0004H zu TZDCO - laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Resultatausgabe:
Wort 1 Fehler
Bit 6 - Amplitudenfehler Ton 1.
Bit 7 - Amplitudenfehler Ton 2.
Bit 8 - Gesamtleistungsfall.
Wort 2 - gemessener Pegel Ton 1 in dB*128.
Wort 3 - gemessener Pegel Ton 2 in dB*128.
Wort 4 - gemessener effektiver Leistungspegel in dB*128.
Test 5 MFV-Registerprüfung: bestätigt, daß die MFV-Karte Mehrfachfrequenzen nach EIA-464-Spezifikationen erkennen kann. Die ADC-Karte wird zur Erzeugung einer Serie von Mehrfachfrequenzen benutzt, die zur MFV-Karte übertragen werden. Die Eigenschaften der Töne werden in einer Tabelle angegeben, die sowohl gültige als auch ungültige Töne enthält. Darüber hinaus sendet die ADC-Karte auch Wählton zur Bestätigung, daß Töne in der Gegenwart von Wählton erkannt werden können. Während der Übertragung der Töne muß der Puffer auf der MFV-Karte von der Systemsoftware-Prüftask ausgelesen werden, um zu bestätigen, daß die gültigen Töne erkannt werden und die ungültigen Töne unberücksichtigt bleiben.
SW-Verbindungen:
X1ADC ==> MFV-Prüfkanal
X3ADC ==> MFV-Nebensprechkanal
SW-Vorprüfung: TT05H zu RTESTN - Start Test-Nummer 5 (TT zeigt auf Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC sendet Tonfolge.
ADC-Nachprüfung:
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung
MFV-Prüfkanal auslesen, um zu bestätigen, daß nur die Ziffern 1, 2, 5, 9, 0 und Nº und keine anderen Ziffern empfangen worden sind.
Verbindungen aufheben.
Ausgabe: keine

Test 6 Drehgeber-Prüfung

In dieser Prüfung wird der Drehgeber durch Messen der Periode der gesendeten Ein- und Aus-Impulse bewertet. Die Prüfung beginnt mit dem Anlegen einer Tabelle im Speicher, die die Zeitdauer für jeden empfangenen Impuls enthält. Diese Tabelle wird mit der Tabelle erwarteter Impulsperioden verglichen. Jeder Eintrag in der erstellten Tabelle enthält eine Zählung der Anzahl Rahmen, für die sich der Impuls im Ein- oder Aus-Zustand befand. Bei Zustandswechsel des Impulses wird ein neuer Eintrag begonnen. Wenn die Länge eines Impulses 16384 Rahmen (2,048 Sekunden) überschreitet, wird die Tabellenerstellung abgeschlossen und ein Eintrag null zum Tabellenende hinzugefügt.
Der Ein- oder Aus-Zustand eines Impulses wird durch Betrachten des Wählimpulszustands (Bit 1) in dem vom Drehgeber in einem Dauerfeld empfangenen Datenwort bestimmt. Wenn der Impulszustand derselbe wie der vorhergehende Zustand ist, wird der Tabelleneintrag erhöht. Wenn sich der Impulszustand geändert hat, wird ein Neueintrag begonnen. In der erstellten Tabelle werden maximal 255 Einträge zusätzlich des null-Wortes am Ende aufgenommen.
Das Format der Tabelle erwarteter Impulsperioden gleicht dem der erstellten Tabelle. Zur Minimalisierung der Tabellengröße kann jedoch ein spezielles Steuerwort benutzt werden. Das Steuerwort wird durch Setzen des oberen Bytes auf Hex 'FF' angegeben. Das untere Byte enthält eine Zählung. Wenn die Zählung null beträgt, wird der entsprechende Eintrag in der erstellten Tabelle ohne Überprüfung übersprungen. Dies ist für Perioden nützlich, die unbestimmt sind, wie die Zwischenwahlzeit. Eine Zählung, die nicht null ist gibt an, daß die folgenden zwei Impulsperioden für Zählungszeiten sein sollten.
Zum Beispiel würde:
0FF05H
480
320
angeben, daß fünf Ein-/Ausimpulse mit einer Impulszeit von 60 Millisekunden und einer Pausenzeit von 40 Millisekunden für jeden Impuls empfangen werden sollten. Die Tabelle erwarteter Perioden wird wie die erstellte Tabelle mit einem null-Wort abgeschlossen.
SW-Verbindungen:
RZDP < == Drehgeber-Prüfkanal
R0ADC < == Drehgeber-Nebensprechkanal
SW-Vorprüfung:
TT06H zu RTESTN - Start Test-Nummer 6 (TT zeigt auf Prüftabelle). Ziffernabgabe durch Drehgeber auslösen.
ADC-Vorprüfung:
8XXXH zu TZSC setzen Busy
8XXXH zu TZS setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC sammelt Ziffern und wertet sie aus.
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0001H zu TZDCO - laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Resultatausgabe:
Wort 1 Fehler
Wenn Wort 1 nicht null ist, dann gibt der Inhalt von Wort 1 an, welcher Übergang nicht übereinstimmte.
Test 7 Drehwählerregisterprüfung: mit dieser Prüfung wird bestätigt, daß die Drehwählerregisterkarte Wählimpulse erkennen kann, die den in den Drehwählerregistern ERS und IRS angegebenen Eigenschaften entsprechen.
Wählimpulse werden durch Umschalten des Wählimpulszustands (Bit 1) in dem in einem Dauerfeld übertragenen Datenwort zum Drehwählerregister übertragen. Die Sollperiodentabelle gibt an, wie oft das Bit umzuschalten ist.
Die Sollperiodentabelle enthält zwei Arten von Einträgen. Mit einem Eintrag wird die Zeitdauer für einen Ein- oder Ausimpuls angegeben. Die Zeitdauer wird in Einheiten der Rahmenperiode (125 Mikrosekunden) angegeben. Die andere Eintragsart ist ein Befehlswort, mit dem ein Block von Periodenworten zurückgeschleift werden kann. Damit kann die Tabellengröße reduziert werden. Die Übertragung der Ziffer '5' würde beispielsweise nur 3 Worte erfordern. Mit den ersten zwei Worten würde die Ein- und Aus-Zeit angegeben und mit dem dritten Wort würde angezeigt, daß die ersten zwei Worte 5mal zu wiederholen sind. Die Sollperiodentabelle wird mit einem Hex-Wort '8000' abgeschlossen.
SW-Verbindungen:
TZDP ==> Drehwählerregister-Prüfkanal
X0ADC ==> Drehwählerregister-Nebensprechkanal
SW-Vorprüfung: TT07H zu RTESTN - Start Test-Nummer 7 (TT zeigt auf Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC sendet Drehwählerfolge.
ADC-Nachprüfung:
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Drehwählerregister-Prüfkanal auslesen, um zu bestätigen, daß nur die Ziffern 5 und 0 und keine anderen Ziffern empfangen worden sind. Verbindungen aufheben.
SW-Ergebnisausgabe: keine
Test 8 Konferenzbrücke: überprüft die Konferenzbrücke mit einer Signaturauswertung und einer Korrelation. In den Prüfkanal wird ein Einzelton mit 1008 Hz eingegeben, und in die anderen drei Kanäle einer Viererkonferenz wird ein Mehrfrequenzton von 305/2992 Hz eingegeben. Der Pegel des Mehrfrequenzsignals wird geändert, um die Konferenzbrücke zur Bereichsveränderung von 0 dB auf -3, -6, -12 und dann zurück auf -3 dB zu zwingen. In jedem Verstärkungsbereich wird eine Signatur entnommen und mit der in der Prüftabelle enthaltenen richtigen Signatur verglichen. An dem Prüfkanal wird eine Korrelation durchgeführt, um zu bestätigen, daß das Empfangssignal keinen 1008-Hz-Ton enthält. Bei Vorhandensein von 1008 Hz wird ein Nebensprechfehler angezeigt.
SW-Verbindungen:
R1ADC < == Teilnehmer D
R1ADC < == Teilnehmer C
R1ADC < == Teilnehmer B
R0ADC < == Teilnehmer A
X1ADC ==> Teilnehmer A
X3ADC ==> Teilnehmer B
X3ADC ==> Teilnehmer C
X3ADC ==> Teilnehmer D
An der Nebensprech-Konferenzbrücke alle Kanäle mit R1ADC und X1ADC verbinden.
SW-Vorprüfung:
TT08H zu RTESTN Start Test-Nummer 8 (TT zeigt auf Prüftabelle)
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC führt die Konferenzbrückenprüfung aus
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0001H zu TZDCO - laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Resultatausgabe:
Wort 1 Fehler
Bit 7 Signaturfehler, 0 dB-Prüfung
Bit 6 Signaturfehler, -3 dB-Prüfung
Bit 5 Signaturfehler, -6 dB-Prüfung
Bit 4 Signaturfehler, -12 dB-Prüfung
Bit 3 Signaturfehler, -3 dB-Prüfung (positiv)
Bit 0 Nebensprechfehler

Test 10 Frequenzprüfung

Die ADC-Karte mißt die Frequenz des ankommenden Signals, indem sie die Anzahl positiver Nulldurchgänge in zwei Sekunden zählt und durch Abfragen des Ein-/Aus- Leistungsverhältnisses auf Belegt prüft.
SW-Verbindungen:
RZDP < == Prüfsignal
SW-Vorprüfung:
00AH zu RTESTN - Start Test-Nummer 10
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC führt Prüfung durch.
ADC-Nachprüfung:
BBBBH zu TZD - löschen Resultatausgabewort
0001H zu TZDCO - laden Anzahl Resultatausgabeworte
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben.
SW-Resultatausgabe:
Messung Wort 1: enthält die Fequenz des Signals in Hz. Wenn das MSB auf '1' gesetzt ist, dann wurde ein Signal Belegt erkannt. Das Ein-/Aus-Leistungsverhältnis des Signals liegt zwischen 40% und 60%.
Test 11 Prüfton senden und Frequenz messen: Es wird ein 1004 Hz-Prüfton bei -3 dB erzeugt, durch Zählen der Anzahl von positiven Nulldurchgängen in zwei Sekunden die Frequenz der ankommenden Signale gemessen und durch Betrachten des Ein/Aus-Leistungsverhältnisses auf Belegt geprüft.
SW-Verbindungen:
X1ADC ==> Prüfkanal
RZDP < == Prüfsignal
000BH zu RTESTN - Start Test-Nummer 11
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: ADC fährt diese Prüfung. Zwischen dem Beginn des Prüftons und dem Messen des Prüfsignals liegt eine Verzögerung von einer Sekunde.
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0001H zu TZDCO - laden Anzahl von Resultatausgabeworten
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben
SW-Resultatausgabe:
Messung Wort 1: enthält die Frequenz des Signals in Hz. Wenn das MSB auf '1' gesetzt ist, dann wurde ein Signal Belegt erkannt. Das Ein-/Aus-Leistungsverhältnis des Signals liegt zwischen 40% und 60%.

Test 12 Selbstprüfung:

Mit dieser Task wird bestätigt, daß die ADC-Karte richtig funktioniert. Die Eingabe und Ausgabe zur ADC- Karte wird durch Auslesen eines fünf-Wort-Musters aus dem Eingabepuffer und Senden eines fünf-Byte-Musters zum Ausgabepuffer überprüft. Der Z80 bestätigt, daß das richtige Muster empfangen worden ist, und die On-line- Software muß bestätigen, daß das richtige Muster abgegeben wurde.
Der Z80-RAM wird durch Einschreiben und Auslesen eines bekannten Musters überprüft. Der Z80-ROM wird durch Berechnen seiner Prüfsumme und Vergleichen derselben mit der Sollprüfsumme überprüft. Die heruntergeladene Prüftabelle wird ebenfalls mittels ihrer erwarteten Prüfsumme überprüft. Die SPI-Schnittstellen werden durch Durchführung ihrer internen Selbstprüfungen und Überprüfung der Ergebnisse überprüft.
SW-Verbindungen: keine
SW-Vorprüfung:
000CH zu RTESTN - Start Test-Nummer 12
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
0005H zu TZDCI - laden der Anzahl von benötigten Parametereingabeworten
SW-Parametereingabe:
Fünf Worte zu RZD, eins pro Rahmen:
AAAAH
5555H
CCCCH
3333H
FFFFH
Ausführung: Die ADC-Karte führt die interne Selbstprüfung durch.
ADC-Nachprüfung:
BBBBH zu TZD - löschen Resultatausgabewort
0006H zu TZDCO - laden Anzahl Resultatausgabeworte
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: überprüfen, daß das richtige Prüfmuster von der ADC empfangen worden ist.
SW-Resultatausgabe:
Wort 1 Fehler
Bit 15 - Eingabeparameter-Ladezeit abgelaufen
Bit 14 - Eingabemuster falsch
Bit 11 - ROM-Prüfsummenfehler
Bit 10 - RAM-Prüfungsfehler
Bit 9 - Prüftabellen-Prüfsummenfehler
Bit 7 - Steuer-SPI fehlerhaft
Bit 6 - Erstellungs-SPI fehlerhaft
Bit 5 - Erkennungs-SPI fehlerhaft
Wort 2 - FFFFH
Wort 3 - 3333H
Wort 4 - CCCCH
Wort 5 - 5555H
Wort 6 - AAAAH
Test 13 Sinuswellenprüfung: damit wird eine Sinuswelle mit vorgegebener Frequenz und Pegel erzeugt. Außerdem wird damit ein Rücksignal empfangen, gef iltert und gemessen. Die Messung findet nicht statt, bis ein Signal von mindestens -50 dB mit der angegebenen Frequenz erfaßt worden ist oder 3 Sekunden vergangen sind. Bei einer ausgewählten Frequenz von null beginnt die Messung nach der angegebenen Zeit.
SW-Verbindungen:
X1ADC ==> Prüfkanal
R0ADC < == Prüfkanal
SW-Vorprüfung:
000DH zu RTESTN - Start Test-Nummer 13
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXxH zu TZS - setzen Busy
0003H zu TZDCI - laden Anzahl von benötigten Parametereingabeworten.
SW-Parametereingabe:
Wort 1 FFSSH
FF - Filterauswahl
00 kein Filter
01 Filter mit C-Kennlinie
02 Filter mit flacher Kennlinie bis 3 kHz
SS - Startzeit
00 Sofortstart
NN Start nach NN*32 Millisekunden
Wort 2 Pegel als dB*10. Beispiele:
001FH
+3,1 dB
0000H
0,0 dB
FFFFH
-0,1 dB
FD45H
-69,9 dB
Wort 3 Frequenz als NNNNH*0,122070313 Hz. Beispiele:
09C0H
304,6875 Hz
DFC0H
2992,1875 Hz
Ausführung: Die ADC führt die Prüfung durch.
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0002H zu TZDCO - laden Anzahl Resultatausgabeworte
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben
SW-Resultatausgabe:
Wort 1 erkannter Pegel in dB*10
Wort 2 übriger Rest nach Berechnung des erkannten Pegels. Bereichsobergrenze ist +3276. Bereich Mitte ist 0. Bereich Untergrenze ist -3276.
Test 14 Sinuswellenprüfung (Dauerprüfung): damit wird eine Sinuswelle mit angegebener Frequenz und Pegel erzeugt. Auch wird damit ein Rücksignal empfangen, gefiltert und gemessen. Die Messung findet erst statt, wenn ein Signal von mindestens -50 dB mit angegebener Frequenz erfaßt worden ist oder 3 Sekunden vergangen sind. Bei einer ausgewählten Frequenz von null beginnt die Messung nach der angegebenen Zeit.
Die Sinuswelle wird nach Vollendung der Messung weiterhin erzeugt, bis ein Befehl RSTOPT empfangen wird. Diese Prüfung ist mit Test 13 identisch, benötigt aber RSTOPT zum Abschließen der Prüfung.
SW-Verbindungen:
X1ADC ==> Prüfkanal
R0ADC < == Prüfkanal
SW-Vorprüfung:
000EH zu RTESTN - Start Test-Nummer 14
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
0003H zu TZDCI - laden Anzahl von benötigten Parametereingabeworten.
SW-Parametereingabe:
Wort 1 - FFSSH
FF - Filterauswahl
00 kein Filter
01 Filter mit C-Kennlinie
02 Filter mit flacher Kennlinie bis 3 kHz
SS - Startzeit
00 Sofortstart
NN Start nach NN*32 Millisekunden
Wort 2 Pegel als dB*10. Beispiele:
001FH
+3,1 dB
0000H
0,0 dB
FFFFH
-0,1 dB
FD45H
-69,9 dB
Wort 3 - Frequenz als NNNNH*0,122070313 Hz. Beispiele:
09C0H
304,6875 Hz
5FC0H
2992,1875 Hz
Ausführung: Die ADC führt die Prüfung durch.
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0002H zu TZDCO - laden Anzahl Resultatausgabeworte
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben
25 SW-Resultatausgabe:
Wort 1 erkannter Pegel in dB*10
Wort 2 übriger Rest nach Berechnung des erkannten Pegels. Bereichsobergrenze ist +3276. Bereich Mitte ist 0. Bereich Untergrenze ist -3276.
Test 15 Digitale Prüfschleifenprüfung (16 Bit): Mit dieser Prüfung wird eine digitale 16 Bit-Prüfschleifenüberprüfung ermöglicht. Er erzeugt ein Pseudozufallsmuster, das zu dem Prüfkanal gesandt und in einer Matrix gespeichert wird. Die ankommenden Daten werden mit den in der Matrix gespeicherten Daten verglichen. Eine Zählung der Anzahl von Übereinstimmungsfehlern zwischen den erzeugten Daten und den ankommenden Daten findet statt.
Während des Anlaufens wird die Verzögerung zwischen den erzeugten Daten und den ankommenden Daten durch Warten auf Übereinestimmung der ankommenden mit dem ersten Wort in der Matrix erzeugter Daten bestimmt. Diese Verzögerung wird für die restliche Prüfung benutzt. Enthalten die ankommenden Daten eine Null (Hex 'FFE3'), so wird diese unberücksichtigt gelassen und zählt nicht als Fehler.
SW-Verbindungen:
X0ADC ==> digitaler 16 Bit-Prüfkanal
X2ADC ==> digitaler 16 Bit-Nebensprechkanal
RZDP < == digitaler 16 Bit-Prüfkanal (Prüfschleife gewählt)
SW-Vorprüfung:
000H zu RTESTN - Start Test-Nummer 15
ADC-Vorprüfung:
8XXXH zu TZSC - setzen Busy
8XXXH zu TZS - setzen Busy
SW-Parametereingabe: keine
Ausführung: die ADC führt die Prüfschleifenprüfung durch.
ADC-Nachprüfung:
BBBBH zu TZD - laden Resultatausgabewort
0003H zu TZDCO - laden Anzahl der Resultatausgabeworte
0XX4H zu TZSC - löschen Busy und setzen Done
0XX4H zu TZS - löschen Busy und setzen Done
SW-Nachprüfung: Verbindungen aufheben
SW-Resultatausgabe:
Wort 1 - Fehler - enthält Anzahl fehlerhafter Worte.
Fehler erkannt oder empfangene Daten niemals gleich Ausgabedaten.
Wort 2 - Anzahl von empfangenen Nullen.
Wort 3 - Anzahl Rahmenverzögerungen zwischen abgehenden und ankommenden Daten.

Definition der Prüftabelle

Die in Figur 17 und Figur 18 dargestellte Zusammenfassung der Prüftabelle zeigt den Hexadezimalwert in dem Format, in dem sie zum RTESTN-Befehl weitergegeben wird. Das höchstwertige Byte ist die Tabellennummer und das niedrigstwertige Byte ist die Prüfnummer, unter der die Tabelle benutzt wird. Die Beschreibung ist der von den Hexadezimaldaten auf gerufene bestimmte Test. Die Summe der Prüfsumme und aller Byte in der Prüftabelle muß gleich null sein. Die Summierung wird mit 16 Bit-Rechnung durchgeführt.

Prüftabellenformat

In Figur 19 wird das Format der Prüftabelle, und wo sich Informationen befinden, dargestellt. Das Tabelleneintragsfeld ist der Relativzeiger in die Tabelle, wo die im Beschreibungsfeld beschriebene Information gefunden werden kann.

Empfohlene Prüfwerte

In Figur 20 werden die erwarteten Signaturen für verschiedene Rahmenverzögerungen angegeben. Die Signaturen werden empirisch berechnet. Die Tabelle wird mit einem Wort Null abgeschlossen.

Analogkarten

In diesen Tabellen werden die benötigten Eigenschaften für die verschiedenen Analogkarten angegeben. Die Amplitude der erzeugten Prüftöne wird berechnet als: (10**((DB-3,17)/20))*32768,
wobei DB die Sollamplitude in dB ist und die maximale DB 3,169735 beträgt. Die Amplitudengrenzen für die Meßpegel werden berechnet als: DB*128, wobei DB die Sollamplitude in dB ist.
Jede Tabelle enthält Grenzen für Grenzwert und Fehlerhaft. Alle Messungen, die außerhalb der Grenzwert-Grenzen liegen, bewirken, daß die entsprechenden Grenzwertbit im Resultatwort gesetzt werden. Alle Messungen, die außerhalb der Grenzen für Fehlerhaft liegen, bewirken, daß die entsprechenden Grenzwert- und Fehlerhaft-Bit im Resultatwort gesetzt werden.
Die in jeder Tabelle angegebenen Parameter sind: 1) zu erzeugende Mehrfrequenzamplitude: damit wird die Amplitude der zwei Töne, die zu der analogen Prüfkarte gesandt werden, angegeben. Dieser Pegel sollte allgemein -6,0 dB betragen, um dem in den digitalen prüfschleifenprüfungen benutzten Pegel zu entsprechen. Die DID-Karte besitzt jedoch eine hohe analoge Prüfschleifenverstärkung, und ein Satz Töne mit -6,0 dB würde die Karte in Sättigung treiben. 2) Maximaler Tonpegel und minimaler Tonpegel: beide von der Analogkarte zurückgeschleiften Töne müssen mit ihrem Pegel zwischen diesen zwei Grenzen liegen, um die Prüfung zu bestehen. Diese Nummern sind so zu wählen, daß die gewünschte maximale Verstärkungsänderung berücksichtigt wird. 3) Minimales Signal/Leistungsverhältnis: dies ist der Unterschied zwischen dem Gesamtleistungspegel der zwei Töne und der von der Analogkarte zurückgeschleiften Gesamtleistung. Bei einer idealen Karte würde die Gesamtleistung die Summe der zwei Töne betragen. Die Gesamtleistung würde durch alle zusätzlichen Geräusche oder Verzerrungen erhöht werden. Diese Nummer ist so zu wählen, daß die gewünschte maximale Verzerrung berücksichtigt wird. Das gemessene Signal/Leistungsverhältnis muß größer als der angegebene Grenzwert sein, um die Prüfung zu bestehen. 3) Maximales Ruhegeräusch: das von der Analogkarte empfangene, nach C-Kennlinie gewichtete Ruhegeräusch muß unter diesem Wert liegen, um die Prüfung zu bestehen. 4) Maximales Nebensprechen: beide der von der Analogkarte in dem Prüfkanal empfangenen Töne, die von dem Nebensprechkanal hinübergekoppelt worden sind, müssen im Pegel unter diesem Wert liegen, um die Prüfung zu bestehen.
In den unten aufgeführten Figuren werden der Tonpegel und die Eigenschaften der folgenden Analogkarten beschrieben: Figur 21 - 8-Kanal-Analogtelefonschnittstelle, Figur 22 - 8-Kanal-MWL-Leitungsschnittstelle, Figur 23 - direkte 4-Kanal-Verbindungsleitungsschnittstelle, Figur 24 - 8-Kanal-Durchwahl-Verbindungsleitungsschnittstelle, Figur 25 - 8-Kanal-Querverbindungsleitungsschnittstelle im öffentlichen Netz, Figur 26 - 8-Kanal-OPS-Leitungsschnittstelle, Figur 27 - 4-Draht- Querverbindungsleitungsschnittstelle, Figur 28 - Vierer- MFV-Register (analoge Prüfschleife).

Vierer-MFV-Register (Töne)

In Figur 29 - 39 sind Tabellen enthalten, die die Reihe von Tönen angeben, die zur Vierer-MFV-Karte übertragen werden. Für jeden Mehrfrequenzton wird folgendes angegeben: 1) Frequenz für jeden Ton, berechnet als:
DF*65536/8000, wobei DF die Sollfrequenz in Hz ist und die maximale DF 4000 beträgt. Die Amplitude für jeden Ton wird berechnet als:
(10**((DB-3,17)/20))*32768, wobei DB die Sollamplitude in dB ist und die maximale DB 3,169735 beträgt. Die Ein- und Aus-Zeit für jeden Mehrfrequenzton wird berechnet als:
MS/0,125, wobei MS die Sollzeit in Millisekunden und die maximale MS 8191,875 beträgt.

Drehgeber

Figur 40 enthält eine Tabelle, die die Reihe von Ein- und Aus-Impulsen angibt, die von der Drehgeberkarte empfangen werden sollten. Jedes Wort ist entweder ein Steuerwort oder ein Periodenwort.
Ein Steuerwort enthält ein oberes Byte mit hexadezimal 'FF'. Das untere Byte enthält eine Zählung, wieviele Male die folgenden zwei Worte zu wiederholen sind. Mit einer Zählung null wird angegeben, daß eine Zeitdauer nicht zu berücksichtigen und nicht zu prüfen ist.
Ein Periodenwort gibt die Länge des Ein- bzw. Aus-Impulses an und wird berechnet als:
MS/0,125, wobei MS die Sollzeit in Millisekunden ist und die maximale MS 2048 beträgt. Das Tabellenende wird mit einem Wort null angegeben. Die maximale zulässige Anzahl von Ein- und Aus-Impulsen ist 255.

Drehwählerregister

Die Tabelle in Figur 41 gibt die Reihe der Ein- und Aus-Impulse an, die zur Drehwählerregisterkarte gesandt werden. Jedes Wort ist entweder ein Befehlswort oder ein Periodenwort. Ein Befehlswort besitzt ein MSB '1'. Es gibt zwei Befehlswortarten:
1) Ein Befehlswort mit gesetztem Bit 14 (d.h. hexadezimal '4000') gibt einen Schleifenbefehl an. Das untere Byte enthält die Schleifenzieladresse. Dieses Byte ist vorzeichenerweitert und zur laufenden Adreßstelle in der Tabelle hinzugefügt, um auf den Schleifenanfang zu zeigen. Die niedrigeren 6 Bit des oberen Bytes enthalten eine Zählung, wieviele Male die Schleife auszuführen ist.
2) Ein Befehlswort, in dem Bit 14 auf '0' gesetzt ist, gibt das Tabellenende an. Ein Periodenwort gibt die Länge des Ein- oder Aus-Impulses an und wird berechnet als:
MS/0,125, wobei MS die Sollzeit in Millisekunden ist und die maximale MS 2048 beträgt.
Das erste Periodenwort in der Tabelle entspricht einem Einhängeimpuls. Jedes Periodenwort danach wechselt zwischen den Schluß und Beginnzuständen, nur hat das einem Schleifenbefehlwort folgende Periodenwort denselben Zustand wie das dem Schleifenbefehlwort vorangehende Periodenwort.
Um Verwirrung zu vermeiden, sollte jede Schleife nur eine geradzahlige Anzahl von periodenworten enthalten, und das dem Schleifenbefehlwort folgende Periodenwort sollte als Fortführung des letzten Impulses in der Schleife betrachtet werden.

Konferenzbrücke

Figur 42 enthält eine Tabelle, die die von der Konferenzbrückenprüfung erwarteten Ergebnisse angibt. Die Ergebnisse werden wie folgt angegeben:
1) Das erste Wort gibt den maximalen in dem Prüfkanal zulässigen Nebensprechpegel an, berechnet als:
DB*128, wobei DB die zulässige Amplitude in dB ist.
2) Die übrigen Worte geben die erwarteten Bitkombinationen für verschiedene Verstärkungspegel der Konferenzbrücke an. Die Bitkombinationen werden empirisch berechnet.

Vierer-MFV-Register (PhoneMail)

Figuren 43 bis 45 enthalten Tabellen, die die Tonreihe angeben, die bei Prüfung der Betriebsart "PhoneMail&registered." zur Vierer-MFV-Karte gesandt werden. Das Format der Tabelle ist dasselbe wie das der Vierer-MFV-Tabelle.

Tongeber

Figuren 46 bis 54 enthalten Tabellen, die die benötigten Eigenschaften der vom Tongeber abgegebenen Töne angeben. Für jede Mehrfrequenztabelle werden folgende angegeben:
1) Die Fequenz jedes Tones wird berechnet als:
RF*65536/8000, wobei RF die Sollfrequenz in Hz ist und die maximale RF 4000 beträgt. Die minimale Sollamplitude für jeden Ton wird berechnet als:
DB*128, wobei DB die Sollamplitude in dB ist. Die maximale zulässige Leistung wird berechnet als:
DB*128, wobei DB die zulässige Leistung in dB ist.

ADC-Steuerprogramm

Die Fehleranalysetasken laufen auf dem aktiven Prozessor der Unterzentrale ab; die ADC-Karte wird jedoch zur Durchführung der Prüfungen der Unterzentralenkarten wie oben beschrieben benutzt. Alle Fehleranalysetasken, die die ADC-Karte benutzen, müssen anfänglich für die Vorverarbeitung DXXXPR_CME() von der aufrufenden Task abrufen. Die Abruffolge ist: DXXXPR_CME(). Zusätzlichmuß die Adresse von DXXPR_CME() mit allen anderen für die Prüfung benötigten Parametern in das mit PRE_PROC bezeichnete Eintragsglied des Prüfungsverzeichnisses eingeschrieben werden.
Nach Abschluß der Vorverarbeitung ist die Aufruffolge für den Abruf einer Prüfung wie folgt:
ERR=ADC_DRIVER( LOGICAL_ADC_TEST_NUM,
CUT_LTID_PTR,
XMIT_DTAT_PTR,
SCAN_BUFFER_PTR); wobei die Parameter folgende Funktionen ausüben:
LOGICAL_ADC_TEST_NUM - die Nummer der auszuführenden ADC-Prüfung. Die Prüfungen und ihre Nummern wurden weiter oben besprochen.
CUT_LTID_PTR - die Adresse der Kennummer für den Prüfkanal.
XMIT_DATA_PTR - die Adresse des die Angabedaten enthaltenden Puffers, sofern solche von der angegebenen Prüfung benötigt werden. Bei unbenutztem Zeiger wird dieser auf NULL gesetzt.
SCAN_BUFFER_PTR - das Datenfeld, das die Ergebnisse der Prüfung aufnimmt.
Nach Aufruf von ADC_DRIVER übernimmt die aufrufende Task die Steuerung, bis die Task vollständig abgelaufen ist oder ein Abbruch stattfindet. Einige Prüfungen beziehen ihre Ergebnisse von der Ereignis- Warteschlange nach Rückkehr der Task ADC_DRIVER().

Zustände des ADC-Steuerprogramms

Das ADC-Steuerprogramm ist eine zustandsgesteuerte Task. Die logische Prüfungsnummer wird als Index in einer Tabelle benutzt, die Zustandsfolgesegmente enthält. Jedes Segment entspricht einer vollständigen Prüfung. Es folgt eine Liste der benutzten Zustände:
ADC_XMIT_TEST, Anzahl der Datenworte - überträgt die ADC-Prüf- und Tabellennummern. Die Prüfnummer wird von einer Tabelle erhalten, die auch durch die logische Prüfnummer indexiert wird. Die angegebene Anzahl Datenworte wird dann zur ADC übertragen.
ADC_XMIT, Anzahl der Datenworte - dieser Zustand funktioniert genau wie der Zustand ADC_XMIT_TEST, nur wird keine Prüfnummer zur ADC übertragen.
ADC_SCAN, Puffergröße - liest die Ergebnisse einer Prüfung in den mit dem Parameter IN_DATA angegebenen Puffer zurück.
ADC_DRIVER() ist über die Anzahl der zum Auslesen verfügbaren Worte informiert, da diese während des vorherigen Zustands SPG_WAIT aufgenommen wurden. Die Anzahl der eigentlich ausgelesenen Worte ist die geringere von entweder der Puffergröße oder der Anzahl von auf der ADC verfügbaren Worten.
ADC_WAIT - dieser Zustand wartet, bis die Busy- Anzeige ADC gelöscht ist. Bleibt sie in diesem Zustand länger als zehn Sekunden, so bricht das Steuerprogramm seinen Lauf mit einer Fehleranzeige der Zeitabschaltung der ADC ab. Die Zeitüberwachung wird von der ADC-Karte durchgeführt.
ADC_CONN Verbindungsart, 1 Weg zur ADC - Verbindungsart ist entweder FEP_SI_CONN_1 oder FEP_SI_CONN_2. Bei Angabe von FEP_SI_CONN_1 muß eine 1-Weg-Verbindung zur ADC geliefert werden, wobei TRUE eine Einweg-Verbindung zu ADC anzeigt und FALSE eine Einweg-Verbindung von der ADC-Karte zur Vorrichtung anzeigt. 1-Weg zur ADC muß bei an-deren Verbindungsarten ausgelassen werden.
ADC_BREAK_CONN - unterbricht die im Zustand ADC_CONN hergestellte Verbindung.
ADC_EXIT - Verlassen der Zustandsmaschine.
ADC_NOP - in diesem Zustand geschieht nichts. Er ist nur zur Fehlersuche und zum Flicken bestimmt.
Besitzt eine Zustandsfolge mehr als einen XMIT- Zustand, so müssen die Daten für jeden Zustand in Reihenfolge im XMIT_DATA_PTR-Puffer erscheinen, damit die Zustände auf sie zugreifen können.

AUSLEGUNG DES ADC-STEUERPROGRAMMS

Diese Task ist die Einsprungstelle für Prüfungen, die die ADC-Karte für die Ausführung der Prüfung benutzen. Das Steuerprogramm initialisiert die ADC, stellt alle erforderlichen Verbindungen her, wartet, bis die ADC fertig ist und liest die Resultate aus. Die Task leitet die Kennzeichnung der ADC-Karte von den Begleitparametern ab und ruft zur Prüfungsdurchführung ADC_DRIVER_IN() auf.ADC_DRIVER_IN()
Mit dieser Task werden die eigentlichen in der Beschreibung ADC_DRIVER beschriebenen Prüfungen durchgeführt; sie wird jedoch aus dem Fehleranalysekode oder direkt aus dem Monitorprogramm aufgerufen. Die Task validiert zuerst die Taskennummer. Danach benutzt sie die Testnummer als Index in eine Tabelle, um die ADC-Testnummer und das Zustandsfolgesegment für die Prüfung zu erhalten. Abschließend wird eine Schleife durchgeführt, die die in dem Zustandsfolgesegment angezeigten Zustände durchschreitet, bis der Zustand ADC_EXIT erreicht ist.
Für die Zustände ADC_XMIT_TEST, ADC_XMIT und ADC_SCAN überprüft die Task die laufende TCB, um zu bestimmen, ob eine Prüfung bereits aktiv ist. Bei einer aktiven Prüfung ruft die Task zur Durchführung der Funktionen TEST_CALLS_FEP() auf. Ansonsten ruft sie zur Durchführung der Funktionen die neue Task CMNDS_TO_FEP() auf. Mit dieser Prozedur werden Funktionen wie das Beladen der ADC-Karte während der Systeminitialisierung und bei Wiederanläufen erleichtert.

SPG INIT

Diese Task wird von der Diagnoseüberwachungstask nach einer Systeminitialisierung oder einem Wiederanlauf aufgerufen. Die Task durchsucht die Liste gemeinsamer Einrichtungen für alle ADC-Karten und lädt jede einzelne herunter. Von der Task wird der ADC-Eintrag des Verzeichnisses für gemeinsame Einrichtungen abgefragt, bis er initialisiert ist. Danach werden für jede ADC im Verzeichnis gemeinsame Einrichtungen die einzelnen Testparameter geladen. Dies geschieht durch Aufrufen von ADC_DRIVER_IN() für jede Prüfung. Danach wird das ADC- Statuswort gelesen, um zu überprüfen, ob die Prüfsumme das richtige Resultat ergab und die Karte zufriedenstellend läuft.

Hardwareumgebung für die Fehleranalyse

In Figur 43 wird die Hardwareumgebung dargestellt, in der die Fehleranalyseverarbeitung abläuft. Der Nebenstellenknoten 210 ist über eine Querverbindungsstrecke mit einem anderen Nebenstellenknoten 220 verbunden. Zusätzlich kann der Nebenstellenknoten 210 auch mit einem Personal Computer (PC) 220 verbunden sein, der als Systemanzeige für den zugehörigen Drucker 230 wirkt. Der Nebenstellenknoten 10 und der Nebenstellenknoten 20 gleichen der in Figur 1 beschriebenen rechnergesteuerten Nebenstellenanlage. Jeder Nebenstellenknoten hat, wie in Figur 2 beschrieben und dargestellt, mindestens eine ADC- Karte.

Phasen der Fehleranalyse

Fehleranalyse besteht aus drei Hauptphasen. Diese Phasen treten während der Verarbeitung von Prüfergebnissen in Reihenfolge auf. Während der Verarbeitung eines gegebenen Prüfungsergebnisses kann die Verarbeitung je nach Zustand der Analyse durch alle Phasen weiterlaufen oder nicht. Diese drei Phasen sind wie folgt:
1) Generische Prüfung: In dieser Phase wird das Ergebnis einer einzelnen Prüfung auf Ausfall validiert indem sichergestellt wird, daß auf dem Etagenverbindungsbus (ISB - intershelf bus) keine Hintergrundfehler bestanden. Der ISB ist der Datenbus für Sprach- und Datenkommunikationen in jedem Knoten.
2) Detailanalyse: diese Phase besteht aus spezifischen Entscheidungsbäumen für jede geprüfte Kartenart. Mit diesen Entscheidungsbäumen werden erforderliche Zusatzprüfungen identifiziert und die Schlußfolgerungen von diesen Prüfungen verarbeitet, um die Probleme zu identifizieren und die Prüfungsergebnisse anzuzeigen. Jede der in dieser Phase ausgeführte Prüfung muß zuerst die generische Prüfphase durchlaufen.
3) Prüfungsanalyse: diese Phase besteht aus mehreren Grundprüfungen, um nachzuweisen, daß ein Fehler dem geprüften Kanal zuschreibbar ist. Diese Phase wird nur dann ausgeführt, wenn in der Detailanalysephase ein Fehler vorkommt. Mit dieser Prüfung würde vermieden werden, daß die Ausfall-Schlußfolgerung durch eine aus fallende Erweiterungskarte oder verbesserte Diagnosekarte (ADC) dem Prüfkanal zugeschrieben wird.
Durch die Systemfühlerschaltungen erkannte Fehler werden etwas anders gehandhabt. Durch Fühlerschaltungen erkannte Fehler überspringen die generische Prüfungsphase und gehen direkt zur Detailanalysephase. Durch Fühlerschaltungen erkannte Fehler benutzen ihre eigenen Bäume für den bestimmten gemeldeten Fehler. Diese Fühlerschaltungsbäume bewirken die Ausführung der bestimmten Prüfungsbäume für die Karte.

Generische Prüfung

In der generischen Prüfung wird nachgewiesen, daß das gegenwärtig abgearbeitete Prüfungsergebnis von ISB- Fehlern unbeeinflußt ist. Sollte das empfangene Prüfungsergebnis einen Fehler anzeigen, wird der ISB-Fehler durch Fehleranalyse überprüft, um sicherzustellen, daß die Prüfungsergebnisse nicht durch den ISB beeinflußt wurden. Bei Erkennung von ISB-Fehlern wird die Prüfung wiederholt, und nach ihrer Vollendung wird mit Fehleranalyse auf ISB-Fehler nachgeprüft, die die Ergebnisse beeinflußt haben könnten. Mit diesem Prüfen wird fortgefahren, bis ein sauberes Ergebnis erhalten wird, oder bis die Prüfung dreimal wiederholt worden ist. Diese Grenze ist aufgestellt worden, da die Möglichkeit besteht, daß die ISB- Fehler durch die gegenwärtige Prüfung verursacht werden. Ohne die Beschränkung auf drei Prüfungen wäre es nicht möglich, andere Prüfungen auszuführen. Bei einem von ISB- Fehlern unbeeinflußten Prüfungsergebnis wird dieses zur nächsten Fehleranalysephase weitergegeben. Alle von ISB- Fehlern beeinflußten Resultate werden verworfen. Zusätzlich wird, wenn alle Prüfungsergebnisse von ISB-Fehlern beeinflußt sind, die Fehleranalyse dieses Ausfalls abgebrochen, und Zwischenergebnisse werden verworfen.

Detailanalyse

In der Detailanalyse werden Probleme durch Durchlaufen von Entscheidungsbäumen für eine bestimmte Kartenart auf eine bestimmte Austauscheinheit lokalisiert. Jede Prüfung entlang des Pfades des Baumes wird einmal durchlaufen, um zu bestimmen, welcher Pfad als nächstes verfolgt wird. Die Entscheidungsbäume deuten an, welche Zusatzprüfungen zum Erlangen einer Schlußfolgerung auszuführen sind, und welche Schlußfolgerung auf Grundlage der Prüfungsergebnisse zu ziehen ist. Diese Ebene umfaßt folgende Entscheidungsbaumarten:
Generische Analyse wird dann benutzt, wenn für einen bestimmten Test kein anderer spezifischer Baum existiert.
Mit RLI-Sprachanalyse werden Probleme auf eine Telefonkarte oder eine Sprechstellenvorrichtung lokalisiert.
Mit Cypress-Analyse werden Probleme entweder auf die RolmPhone RLI-1/2-Karten oder die Cypress-Sprechstellenvorrichtung lokalisiert.
Mit DCM-Analyse werden Probleme entweder auf eine Telefonkarte oder ein Datenkommunikationsmodul lokalisiert.
Mit DLI-Analyse werden Probleme entweder auf eine Datenleitungsschnittstellenkarte oder eine Datenendgeräte-Schnittstellenvorrichtung lokalisiert.
Mit modifizierter Kartenanalyse werden Probleme entweder auf eine CODEC-Karte oder eine Schnittstellenkarte lokalisiert.
"Nachricht wartet"-Analyse gleicht der modifizierten Kartenanalyse, nur kann man damit auch zum Telefon lokalisieren, wenn sie die Lampenprüfung nicht besteht.
Mit ATI-Kartenanalyse können Probleme hinsichtlich der ATI-Karte lokalisiert werden.
Mit Querverbindungsleitungsanalyse werden Probleme entweder zur neuen Querverbindungsleitungsschnittstellenkarte oder zu einer Verbindungsleitung lokalisiert.
Mit den Entscheidungsbäumen wird sichergestellt, daß alle notwendigen Prüfungen, mit denen eine Vorrichtung als betriebsfähig erklärt wird, gefahren werden. Wenn in einer der erforderlichen Prüfungen ein Fehler auftritt, wird der Baum verfolgt, um zu versuchen, den Fehler auf eine Austauscheinheit zu lokalisieren. In Figuren 62 bis 71 ist die schematische Logik für die Detailanalyse-Entscheidungsbäume dargestellt. Es ist zu bemerken, daß ein Entscheidungsbaum selbst bei Nichtauftreten eines Fehlers verfolgt wird, um sicherzustellen, daß alle notwendigen Prüfungen zur Sicherstellung der Funktionsfähigkeit des geprüften Kanals gefahren werden. Die bei erfolgreichem Bestehen aller Prüfungen erlangte Schlußfolgerung ist einfach "Kanal Gut".

Merkmale eines Entscheidungsbaums

Am Baum ist jeder Knoten, wie in Figur 58 dargestellt, entweder ein Prüfungsknoten 1000, ein Aktionsknoten 2000 oder ein Schlußfolgerungsknoten 3000. An einem Prüfungsknoten 1000 steht ein F für einen Fehler-Zweig oder ein P für einen Bestanden-Zweig. Allen Testknoten ist implizit, daß die angegebene Prüfung die generische Prüfungsphase auf dem Prüfkanal durchläuft. Ein Aktionsknoten 2000 ist einfach ein Ereignis, das als Ergebnis einer Prüfung eintritt. Er erscheint als Textbeschreibung des Ereignisses in einem Kasten 2000. Den Aktionsknoten 2000 ist implizit die Durchführung einer Fehleranalysefunktion, ehe zum nächsten Knoten fortgeschritten wird. Den Schlußfolgerungsknoten 2000 ist implizit, daß eine Schlußfolgerung erlangt worden ist, und daß im Baum keine Knoten mehr zu besuchen sind. Sie sind, anders gesagt, Abschlußknoten, die die Vollendung der Fehleranalyse anzeigen.
Prüfungsknoten besitzen zwei mögliche Ausgangszweige, die bestanden oder nicht bestanden werden. In Abhängigkeit von den Ergebnissen der Prüfungen verfolgt die Tasklogik einen der zwei Zweige zum nächsten Zweig. Randergebnisse von den Einzelprüfungen werden bei Durchlaufen der Entscheidungsbäume als Fehler behandelt. Wenn eine Schlußfolgerung "Ausfall" erlangt wird, aber die Formulierung dieser Schlußfolgerung durch die Fehleranalyse durch nichts Schlimmeres als ein Randwert- Prüfungsergebnis bewirkt wurde, wird die Schlußfolgerung nicht zur Außerbetriebnahme des Prüfkanals benutzt.
Auf jeder Kanalart, für die nur eine Prüfung gefahren werden muß und deren einzige Austauscheinheit die Einzelkarte ist, auf der sie aufgenommen ist, braucht nur ein aus der einen Prüfung bestehender Einknoten- Entscheidungsbaum, wie in Figur 59 dargestellt, durchlaufen zu werden. Die Schlußfolgerung auf dem Fehler-Zweig ist, die Karte auszutauschen. In Figuren 68 bis 78 wird das Logikprogramm für jeden der Entscheidungsbäume im Fehleranalysesystem dargestellt. Die Entscheidungsbäume umfassen eine Sammlung der drei Bäume zur Beschreibung der Fehleranalyselogik.

Prüfungsanalyse

Mit der Task Prüfungsanalyse wird nachgewiesen, daß die zugehörige Erweiterungskarte funktioniert, daß die Kartenkennung(en) korrekt ist/sind, und daß die ADC- Karte für Prüfungszwecke betriebsfähig ist. Prüfungsanalyse wird nach Erreichen eines Fehler-Schlußfolgerungsknotens durch die Detailanalyseprüfungen aufgerufen. Vor Aufrufen der Prüfungsanalyse wird eine Überprüfung durchgeführt, um zu bestimmen, ob von der Fehleranalyse für diesen Kanal ein vorheriger Fehler protokolliert worden ist. Bei Protokollierung eines vorherigen Fehlers und identischen Schlußfolgerungen wird die Prüfungsanalysephase übersprungen, um redundante Prüfungen derselben fehlerhaften Hardware zu vermeiden.
Es gibt vorbestimmte Entscheidungsbäume, die zur Prüfung jeder dieser Komponenten aufgerufen werden. Die erste Prüfung ist die Erweiterungskarten-Übertragungswiederholungsprüfung. Damit wird die Erweiterungskarte geprüft, um die Etage zu bestimmen, in der der Prüfkanal aufgenommen ist. Bei Nichtbestehen der Erweiterungskartenprüfung werden die Erweiterungskartenprüfergebnisse in der Hardwarefehlertabelle protokolliert. Das Feld für vorgeschlagene Handlung in der Hardwarefehlertabellendatenstruktur wird gesetzt, um anzuzeigen, daß die Erweiterungskarte auszutauschen ist. Die entsprechende Umschaltlogik existiert in der Erweiterungskartenprüfung. Zusätzlich wird ein Eintrag in die Hardwarefehlertabelle eingeschrieben, der die ursprüngliche Prüfkanalnummer andeutet, und in das Feld für vorgeschlagene Handlung zur Anzeige, daß die Prüfung aufgrund eines Erweiterungskartenproblems nicht bestanden worden ist.
Zusätzlich wird damit angezeigt, daß der Prüfkanal jedesmal, wenn die Erweiterungskarte ausfällt, außer Dienst genommen werden kann. Selbst bei einer Umschaltung ist keine weitere Analyse erforderlich, da das Problem voll diagnostiziert worden ist.
Bei bestandener Erweiterungskartenprüfung wird die Kartenkennungsprüfung für zum Prüfkanal gehörige Karten ausgeführt. Wenn die Kartenkennungsprüfung nicht bestanden wird, kann keine weitere Analyse durch die Fehleranalyse versucht werden. Die Task erstellt eine Fehleraufzeichnung in der Prüfkanaldatenstruktur und setzt die Datenstruktur des Feldes "vorgeschlagene Handlung", um die vom Bediener durchzuführende entsprechende Handlung anzuzeigen. Mit dieser Nachricht wird angezeigt, daß der Bediener eine Karte austauschen soll. Zusätzlich wird der Prüfkanal außer Dienst genommen.
Bei Bestehen der Kartenkennungsprüfung wird eine Überprüfung durchgeführt, ob während der Detailanalyse gefahrene Prüfungen eine ADC-Karte erforderten. Wenn eine ADC-Karte benötigt wurde, dann wird an der benutzten ADC- Karte während der Detailanalysephase eine Selbstprüfung durchgeführt. Dieselbe ADC-Karte wird für alle durch die Detailanalyse gefahrene Prüfungen benutzt. Mit dieser Prüfung wird die ADC-Karte als mögliche Fehlerquelle ausgeschaltet. Bei Nichtbestehen der ADC-Selbstprüfung werden alle Zwischenergebnisse verworfen, und für die Analyse wird kein Resultat protokolliert. Vor Abschließen wird von der Fehleranalyse die erste Prüfung des ADC-Analyseentscheidungsbaums für die versagende ADC aufgerufen. Mit dieser Aktion wird normale Prüfungsplanung und komplette Fehleranalyse aufgerufen.
Wenn die ADC-Karte die Prüfung bestanden hat oder, wenn keine ADC-Karte verwendet wurde, die Kartenkennungsprüfung bestanden worden ist, wird die Vorrichtung geprüft, um festzustellen, ob alle andere Kanäle auf der Karte außer Betrieb sind, und wenn dieser der Fall ist, wird die Karte initialisiert. Mit dieser Handlung wird die gegenwärtige Analyse nicht geändert; zukünftige Prüfungen dieser Karte können jedoch die Analyse gegebenenfalls bestehen. Zusätzlich wird in der Fehleranalysedatenstruktur ein Eintrag erstellt, um die Prüfungsergebnisse anzuzeigen. Abschließend wird bei Erreichen einer Fehler-Schlußfolgerung die Fehleranalysedatenstruktur in die Hardwarefehlertabelle eingeschrieben, und die Prüfung wird für den Prüfkanal wiederholt, um zu versuchen, wiederholbare Ergebnisse zu erhalten.

Prüfungszwischenergebnisse

Während der Analyse eines gegebenen Kanals werden die Zwischenergebnisse jeder Prüfung aufgezeichnet. Danach werden bei Erhalt einer Schlußfolgerung die Zwischenergebnisse zur Aktualisierung bestehender einzelner Fehlerauf zeichnungen als Fixpunkte in die Hardwarefehlerdatenbank eingegeben. Bei Aufzeichnung eines einzelnen Fehler-Ergebnisses und Nichtvorhandensein eines Hardwarefehlerdatenbankdatensatzes dafür wird kein neuer Datensatz erstellt. Wenn von einem Benutzer eine Einzelprüfung mit dem Befehlszeilen-Interpretierprogramm (CLI - command line interpreter) gefahren worden ist und ein Fehlersatz für die Prüfung erstellt worden ist, aktualisiert dieser bei Wiederholung der Prüfung weiterhin denselben Datensatz.

Fehleranalyse für abgesetzte Knoten

Die Fehleranalyse besitzt die Fähigkeit, Prüfungen an abgesetzten Knoten durchzuführen. Mit einer Prozedur werden Prüfungen geplant und der Prüfkanal überprüft, um zu bestimmen, ob er sich in einem abgesetzten Knoten befindet. Wenn die Prüfung an einem abgesetzten Knoten durchgeführt wird, wird der Fehleranalysetask im abgesetzten Knoten eine Nachricht übermittelt. Die Prüfung wird im abgesetzten Knoten geplant, Ausführung läuft über die generische Prüfungsphase, und die Ergebnisse werden der örtlichen Fehleranalysetask zurückgemeldet.

Internes Steuerprogramm

Mit dem internen Steuerprogramm wird die erste in der Analyse für jede geprüfte Kartenart benutzte Prüfung geplant. Danach werden von der Fehleranalyse zur Planung des entsprechenden Satzes von Zusatzprüfungen Entscheidungsbäume für die Prüfkarte benutzt. Sollte Fehleranalyse nicht zur Verfügung stehen, werden alle anstehenden Prüfungen für einen gegebenen Kanal vor Fortschreiten zum nächsten Kanal in Reihenfolge vom internen Steuerprogramm ausgeführt.

Vorgeschlagene Handlung zur Abnahme von Kanälen

Ein bedeutendes Merkmal der Erfindung ist die Anwendung von Expertensystemverfahren auf das Kommunikations-Multiplexsystem. Eines dieser Verfahren ist die Benutzung von Entscheidungsbäumen zur Lokalisierung von Fehlern im System. Ein weiterer wesentlicher Aspekt der Erfindung ist die Fähigkeit, Prüfungen an Fehlern nach ihrer Lokalisierung zu wiederholen. Mit der Erfindung wird eine Reihe von Prüfungan an fehlerhaften Karten durchgeführt, und die Karte jedesmal dann in Dienst genommen, wenn sie die Prüfungen meherere Male nacheinander besteht. Das Feld "vorgeschlagene Handlung" in der Fehlerdatenstruktur wird beibehalten; jedoch wird der Kopfteil abgeändert, um anzuzeigen, daß diese Handlung bereits korrigiert worden ist.

Analyse kann nicht vollendet werden

Mit der Fehleranalyse werden mehrfache Prüfungen zur Problemlokalisierung ausgeführt, während der Kanal weiterhin Fernsprechverarbeitung durchführt. Die Vollendung einer Einzelprüfung kann jedoch durch andere Systemprobleme verhindert werden. Sollte dies eintreten, werden Analyseunterbrechungen und alle einzelnen Prüfergebnisse gemeldet und als Einzelergebnisse in der Hardwarefehlertabelle protokolliert.

Fehlersatzprioritäten

Einzelne Systemintegritätsprüfungen besitzen von vornherein zugewiesene Prioritäten, die für jede Prüfung aufgestellt werden. Da die Fehleranalyse mehrfache Prüfungen durchführt, ist es notwendig, bei der Zuweisung von Fehlersatz-Prioritäten Regeln für die Analyse festzulegen. Es wird die folgende Liste von Regeln benutzt: 1) Kanalfehlern wird die Priorität der einzelnen ausgeführten Kanalprüfung mit der höchsten Priorität, die Fehler im Kanal erkannt hat, zugewiesen. 2) Kartenfehlern wird die Priorität der einzelnen ausgeführten Karten-Pegelprüfung mit der höchsten Priorität, die Fehler in der Karte erkannt hat, zugewiesen. Bei nicht bestandener Kartenpegelprüfung wird die Kanalpegelpriorität protokolliert. 3) Toleranzfehler werden als Ausnahme protokolliert. 4) Vorübergehende Fehler (Fehler, die korrigiert werden) behalten ihre ursprüngliche Priorität in der Hardwarefehlertabelle, entsprechende Systemealarme werden jedoch abgeschaltet.

Nichtwiederholbare Ergebnisse

Wenn eine bestimmte von der Detailanalyse benutzte Prüfung intermittierende Resultate ergibt, gibt es unterschiedliche Schlußfolgerungen von der Detailanalyse. Um diese Möglichkeit zu berücksichtigen, wird bei jeder Aktualisierung eines Fehleranalysesatzes der vorherige Schlußfolgerungssatz für Vergleichsprüfungszwecke sichergestellt. Mehrfache Schlußfolgerungssätze können auf diese Weise durch einen Fixpunkt festgehalten werden. Für eine gegebene Kanalart werden die Schlußfolgerungssätze auf Grundlage der Länge des physikalischen Weges zu der bestimmten Austauscheinheit, der sie entsprechen, priorisiert. Bei einem kurzen Weg, beispielsweise auf einer Erweiterungskarte, besitzt der Schlußfolgerungssatz eine hohe Priorität. Bei einem langen Weg, beispielsweise einer Fernsprechvorrichtung, ist die Priorität niedriger.
Jedesmal, wenn eine einen Fehler anzeigende Schlußfolgerung erhalten wird, enthält der fehlerhafte Knoten einen Zeiger zu einer alternativen Schlußfolgerung. Die alternative Schlußfolgerung gleicht der primären Schlußfolgerung; sie enthält jedoch zusätzliche prüfende und/oder auszutauschende Posten. In manchen Fällen ist die Alternative gleich der Primärlösung. Sowohl die Alternative als auch die Primärlösung teilen sich dieselbe Schlußfolgerungspriorität.
Bei nicht übereinstimmenden Fehler-Schlußfolgerungssätzen im Fehlersatz, wenn der Fehlersatz aufgelistet ist, wird die alternative Schlußfolgerung des Schlußfolgerungsknotens mit der höchsten Priorität mit einer zusätzlichen Nachricht aufgelistet, die anzeigt, daß zu unterschiedlichen Zeiten unterschiedliche Schlußfolgerungen erlangt worden sind, dies aber die wahrscheinlichste Schlußfolgerung ist. Dies geschieht, da eine zeitweilig aus fallende Komponente Fehler in stromabwärtigere Komponenten einführen kann. Die Komponente auf dem kürzesten physikalischen Weg ist daher die verdächtigste.

Benutzerschnittstelle

Das Befehlleitungs-Interpretierprogramm (CLI) ist eine Softwareeinrichtung, mit der eine berechtigte Einzelperson sich bei dem Kommunikationssystem anmelden und Systembefehle ausführen kann. Wenn das CLI für Prüfungen benutzt wird, die Informationen nach Kartenart anfordern, wird eine Nachricht angezeigt, die andeutet, welche Prüfung läuft, und bei Vollendung der Prüfung werden dem Benutzer die Ergebnisse angezeigt. Die möglichen Prüfungsergebnisse sind "Prüfung bestanden", "Randwert" oder "Fehler". In Figur 54 wird ein Beispiel eines Prüfungsergebnisses gezeigt.

Auflisten von Hardwarefehlern

Zum Auflisten der Ergebnisse der Fehleranalyse und Zusammenfassung des empfohlenen Kommentars und der vorgeschlagenen Handlungen wird ein Protokoll bereitgestellt. Ein Musterprotokoll wird in Figur 55 gezeigt. In dem Protokoll wird eine Zusammenfassung der Fehlerinformation so aufgelistet, daß die entsprechenden Informationen deutlich übermittelt werden.

Architektur der Fehleranalyse

Die Prozedur ERR_POST_PROCESS ist die Task, die die Ergebnisse der Prüfungen und Fühlerschaltungen verarbeitet und die Hardwarefehlertabelle fortschreibt. Die Prüfungsergebnisse werden als verkettete Liste an ERR_POST_PROCESS weitergegeben, wobei jeder Eintrag ein einzelnes Prüfungsergebnis darstellt. Um die Fehleranalysefunktion durchzuführen und die Einträge zur Protokollierung in der Hardwarefehlertabelle zurückzumelden, ist ERR_POST_PROCESS zum Aufrufen der Task ERROR_ANALYSIS ausgelegt.
ERROR_ANALYSIS besteht aus drei Phasen und einer Initialisierungsphase. In der ersten, also der Initialisierungsphase, wird ein Zeiger (Adresse) zum Eintrag in der Fehleranalysedatenbank für die Analyse abgerufen oder, wenn keiner existiert, ein Ersteintrag erstellt. In der zweiten Phase, der generischen Prüfung, wird bestimmt, ob die gemeldeten Ergebnisse durch ISB-Fehler beeinflußt werden und, sollte dies der Fall sein, die Prüfung für Wiederausführung umgeplant. In der dritten Phase, der Detailanalyse, werden die für die Fehlerart spezifischen Entscheidungsbäume durchlaufen. In der vierten Phase, der Prüfungsanalyse, wird nachgewiesen, daß der Fehler nicht das Ergebnis von nicht mit der geprüften Vorrichtung in Zusammenhang stehenden Hardwareausfällen war.
Der Mechanismus, mit dem die Prüfungsergebnisse korreliert werden und bestimmt wird, ob sie zu ignorieren oder in eine weiterführende Analyse aufgenommen werden sollten, ist die "Prüffolge". Mit einer Prüffolge von null werden Ergebnisse identifiziert, die eine Analyse einleiten.
Die einleitende Prüffolge wird durch das Steuerprogramm durchgeführt. Eine Prüffolge von NULL wird dazu benutzt, ein Prüfungsergebnis anzuzeigen, das von der Fehleranalyse zu ignorieren ist. Eine Prüffolge von nicht null oder NULL zeigt ein Ergebnis an, das als Teil einer weiterführenden Analyse erzeugt worden ist.
In der Hardwarefehlertabelle existieren sowohl einzelne Prüfungsergebnisse als auch Fehleranalyseergebnisse. Es ist von Bedeutung, daß, wenn eine Einzelprüfung als Teil der Fehleranalyse durchgeführt wird, die einzelnen Prüfungsfehlersätze aktualisiert werden. Um dies zu erreichen, werden alle Prüfungszwischenergebnisse zur Task ERR_POST_PROCESS weitergegeben, die den Status aller möglicherweise bestehenden einzelnen Fehlersätze aktualisiert. Wenn sie noch nicht bereits bestehen, werden durch die Zwischenergebnisse keine Fehlersätze erstellt. Es werden nur bestehende Datensätze fortgeschrieben.
Die Fehleranalysedatenbank besteht aus einer verketteten Liste von kopfartigen Einträgen. Jeder Kopfteileintrag enthält allgemeine Informationen über die von ihm dargestellte bestimmte Analyse. Außerdem enthält der Kopfeintrag einen Zeiger auf eine Liste von Prüfungsergebnissen. Das erste Prüfungsergebnis ist ein Datensatz, der zur Protokollierung des Fehleranalysefehlers erstellt wird. Die übrigen Prüfungsergebnisse sind die Prüfungszwischenergebnisse, die als Teil der Analyse erstellt werden.
Die Entscheidungsbäume sind als ein Satz Knoten definiert. Jede Karte hat ihren eigenen Entscheidungsbaum. Mit jedem Monitorfehler wird eine Analyse mit ihrem eigenen Entscheidungsbaum eingeleitet. Jeder Knoten eines Entscheidungsbaumes besteht aus irgendeiner durchzuführenden Aktion, einigen zugehörigen Parametern und einem Relativzeiger zum nächsten Knoten im Entscheidungsbaum, je nachdem, ob die angegebene Aktion "bestanden" oder "nicht bestanden" ergibt.
Um auf die Kopfteile der Entscheidungsbäume zu zeigen, werden zwei Datenstrukturen benutzt. Eine dieser Strukturen wird zur Fehlerüberwachung benutzt und nach Fehlernummer indexiert. Die andere Struktur besteht für regelmäßige Prüfungen und wird nach Kartenart indexiert. Beide Strukturen sind einander gleich und beide enthalten einen Indexwert und einen Zeiger zum Kopf des entsprechenden Entscheidungsbaumes.

Fehleranalyse-Initialisierung

Die Verarbeitung der Fehleranalyse-Initialisierung wird auf Grundlage der Art von Testergebnissen durchgeführt. Die Fehleranalyse trifft auf drei Arten von Prüfungsergebnissen:
1) Ergebnisse, die zum ersten Mal in die Fehleranalyse kommen.
2) Ergebnisse, die Teil einer laufenden Analyse bilden.
3) Ergebnisse, die nicht durch Fehleranalyse zu bearbeiten sind.
Die Ergebnisarten werden durch ein Prüfungsfolgefeld im Prüfungsergebnissatz identifiziert. Eine Prüfungsfolge NULL deutet ein Ergebnis an, das zum ersten Mal in die Fehleranalyse eingebracht wird und durch Fehleranalyse zu bearbeiten ist. Eine Prüfungsfolge NULL bedeutet ein Ergebnis, das nicht durch Fehleranalyse zu bearbeiten ist. Alle sonstigen Prüfungsfolgen deuten ein Ergebnis an, das Teil einer laufenden Analyse ist.
Mit jeder Einleitung einer Analyse (es wird eine Prüfungsfolge null empfangen) wird der Analyse eine eindeutige Prüfungsfolge zugewiesen, ein Datensatz zur Meldung des Fehleranalyseprüfungsergebnisses wird zugeordnet, und es wird ein Eintrag in der Fehleranalysedatenbank zugeordnet. Wenn als Teil einer Analyse nachfolgende Prüfungen durchgeführt werden, wird die Prüfungsfolge der Analyse als Teil des Auftragssatzes weitergegeben. Beim Eingang der neuen Prüfungsergebnisse verknüpft die Prüfungsfolge das Ergebnis mit der bestimmten Analyse, mit der sie verbunden ist.
Der einzige Umstand, durch den die Prüfungsfolge auf NULL gesetzt wird, ist eine Anforderung über die CLI durch durch ein prüfungsspezifisches Kürzel anstelle eines allgemeinen Kürzels für Karten. Die Ergebnisse von einer Prüfungsfolge NULL werden zu ERR_POST_PROCESS zur Protokollierung in der Hardwarefehlertabelle zurückgegeben.
Der Initialisierungsvorgang besteht aus Suchen nach dem Datensatz in der Fehleranalysedatenbank für die gegenwärtig ablaufende Analyse. Sollte die Analyse gerade beginnen, so wird zur Aufzeichnung von Informationen für spätere Meldung eine Prüfungsfolge erstellt.
Eine Analyse wird auf Grundlage eines Erstprüfungsfehlers eingeleitet. Es wird jeweils nur eine Analyse für einen bestimmten Erstprüfungsfehler und ein bestimmtes Kanalpaar bearbeitet. Sollte eine Analyse bereits für einen bestimmten Kanal und Kennzeichenprüfung in Gang sein, wird keine neue Analyse durch das neue Ergebnis eingeleitet. Dieser Zustand sollte bei den meisten Prüfungen nicht eintreten, ist aber sehr wahrscheinlich bei der Überwachungsergebnissen.

Generische Prüfung

Jedes durch Fehleranalyse bearbeitete Prüfungsergebnis wird in der generischen Prüfungsphase bearbeitet. Dazu gehören sowohl Erstprüfungsergebnisse und Prüfungsergebnisse, die einen Teil einer laufenden Analyse bilden. Die einzigen Ergebnisse, die nicht in dieser Prozedur bearbeitet werden, sind Überwachungsergebnisse. Mit der generischen Prüfungsphase wird die Integrität der Ergebnisse sichergestellt, indem mit ISB-Problemen verbundene Störungen beseitigt werden.
Zur Bestimmung, ob die Ergebnisse durch ISB- gebundene Probleme beeinflußt worden sind, wird eine globale Markierung benutzt. Wenn die ISB-Fühlerschaltung einen ISB-Paritätsfehler erkennt, wird die globale Markierung gesetzt. Die globale Markierung wird von der generischen Prüfungstask geprüft, um zu bestimmen, ob während der Prüfung ein ISB-Fehler auftrat. Bei gesetzter Markierung werden die gegenwärtigen Ergebnisse verworfen und die Prüfung neu angesetzt. Dieser Vorgang wird bis zu dreimal wiederholt. Bei fortwährenden ISB-Fehlern wird die gegenwärtige Analyse abgebrochen und kein Fehler protokolliert. Dies geschieht, weil die ISB-Fühlerschaltung einen zu protokollierenden Paritätsfehler auslöst.
Die Ergebnisse der letzten durchgeführten Handlung sind in einem Datensatz in der Fehleranalysedatenbank enthalten. Wenn ein Prüfungsergebnis nicht durch ISB-Probleme beeinflußt wird, wird dieses Feld aktualisiert, um ein Bestehen oder Nichtbestehen der Prüfung anzuzeigen. Randwertergebnisse werden für Fehleranalysezwecke als Fehler behandelt. Danach wird das einzelne Prüfungsergebnis nicht mehr benötigt. Alle erforderlichen Informationen werden entnommen und in die Fehleranalysedatenbank eingeschrieben. Das einzelne Prüfungsergebnis wird in die Fehleranalysedatenbank eingeschrieben, bis die Analyse vollständig ist oder abgebrochen wird. Bei erfolgreicher Vollendung der Analyse werden die Ergebnisse zur Task ERR_POST_PROCESS weitergegeben. Im Prüfungsfolgefeld zeigen die Einzelfehler an, daß sie das Ergebnis der Fehleranalyse darstellen und bewirken nicht die Erstellung eines Fehlersatzes, wenn noch kein Fehler-Satz besteht. Bei Analyseabbruch wird das Prüfungsfolgefeld auf NULL geändert, ehe es zum ERR_POST_PROCESS zurückgegeben wird. Durch das Prüfungsfolgefeld NULL werden Einzelfehlersätze erstellt, wenn diese noch nicht bestehen.

Detailanalyse

Mit jeder Kartenart ist ein Detailanalyse-Entscheidungsbaum verbunden. Mit jedem Überwachungsfehler kann auch ein Detailanalyse-Entscheidungsbaum verbunden sein. Die Zeiger auf diese Entscheidungsbäume sind in zwei Tabellen enthalten. Die eine Tabelle wird nach Kartenart indexiert, während die andere nach Überwachungsfehlernummer indexiert wird.
Überwachungsergebnisse durchsuchen die Überwachungstabelle nach Fehlernummer, um zu bestimmen, welcher Entscheidungsbaum zu benutzen ist. Wenn kein Entscheidungsbaum gefunden wird, wird keine Detailanalyse für den Überwachungsfehler durchgeführt. Der Überwachungsfehler wird zu ERR_POST_PROCESS zurückgegeben, um in der Hardwarefehlertabelle als Einzelfehler protokolliert zu werden.
Prüfungen durchsuchen den Kartenartbaum, um zu bestimmen, welcher Entscheidungsbaum zu benutzen ist. Wenn kein Entscheidungsbaum gefunden wird, wird für die Kartenart keine Detailanalyse durchgeführt, die Analyse wird abgebrochen, und in der Hardwarefehlertabelle wird ein Einzelfehler protokolliert.
Die Fehleranalysedatenbank enthält die laufende Adresse für den Entscheidungsbaum. Bei Durchlaufen des Baumes wird die gegenwärtige Adresse mit dem Erreichen jedes neuen Knotens aktualisiert. Das bedeutet, daß die oben beschriebenen Tabellen nicht mit jedem Einstieg in diese Prozedur durchsucht werden müssen, sondern nur bei dem Ersteinstieg.
Jeder Entscheidungsbaum besteht aus einem Satz Knoten. Diese Knoten besitzen zwei Teile, von denen einer dann zu benutzen ist, wenn das vorherige Ergebnis ein Bestanden-Ergebnis war und der andere dann, wenn das vorherige Ergebnis ein Nicht Bestanden- oder Randwert- Ergebnis war. Jeder dieser Teile enthält die durchgeführte Funktionsart, einige funktionsspezifische Parameter und die relative Stelle des nächsten Knotens im Entscheidungsbaum.

Prüfungsanalyse

In der Prüfungsanalysephase wird nachgewiesen, daß die zugehörige Erweiterungskarte funktioniert, daß die Kartenkennung der geprüften Karte gültig ist, und daß die ADC-Karte, wenn benutzt, in Ordnung ist. Sollte für den aktuellen Kanal bereits ein Fehleranalyse-Fehlersatz bestehen und alle vorgeschlagenen Handlungen in der Fehlersatz-Vorgeschichte der eben in der Detailanalyse erhaltenen vorgeschlagenen Handlung entpsrechen, so wird die Prüfungsanalysephase übersprungen.
Die Prüfungsanalysephase ist als ein Satz Entscheidungsbäume implementiert. Es gibt einen Entscheidungsbaum für den allgemeinen Fall, einen für die Analyse einer Erweiterungskarte, einen für die Analyse einer ADC-Karte und einen für die Analyse eines Kartenkennungsfehlers.

Bearbeitung der Entscheidungsbäume

Zur Auswertung der Entscheidungsbäume wird ebenfalls eine Task benutzt. Diese Task wird von den beiden Phasen, Detailanalyse und Prüfungsanalyse, zur Bearbeitung ihrer Entscheidungsbäume benutzt. Jeder Knoten des Entscheidungsbaumes hat eine Funktion und Zeiger zum Nächstknoten im Baum, je nachdem, ob die durchgeführte Funktion ein Ergebnis Bestanden oder Nicht Bestanden ergibt. Jede Funktion ist als Kodesegment in einer Fallanweisung implementiert. Die Kodesegmente werden mittels Funktionsnummer ausgewählt.
Für jede durchgeführte Funktionsart wird ein Fallanweisungs-Kodesegment geschrieben, um die Funktionslogik in den Entscheidungsbaum einzubauen. Alle neuen, für zukünftige Entwicklungen benötigten Funktionen werden dadurch hinzugefügt, daß ein Entscheidungsbaum mit die neue Logik implementierendem Fallanweisungskode implementiert wird. Das einzige Erfordernis für neue Logik ist, daß sie ein Ergebnis Bestanden oder Nicht Bestanden ergibt, damit der Entscheidungsbaum weiterhin mit der eingebauten neuen Logik durchlaufen werden kann.

Die Architektur im einzelnen

Zum Steuern der Bearbeitung in der Fehleranalyse verfolgen die internen Tasken Konventionen für Rückkehrzustände. Die Konventionen sind unten umrissen.
PROCEED - mit diesem Rückkehrzustand wird angedeutet, daß die nächste Phase der Fehleranalysebearbeitung stattfinden soll. Die Phasen umfassen: initialisieren, generische Prüfung, Detailanalyse, Prüfungsanalyse und Fehleranalyseintegrität.
GET_NEXT_ENTRY - mit diesem Rückkehrzustand wird angedeutet, daß die Fehleranalyse zur Erfassung des nächsten Prüfungsergebnisses von der Eingabewarteschlange zu ERR_POST_PROCESS() zurückkehren soll. Dieser Zustand wird dann gesetzt, wenn ein interner Fehler auftritt, oder er kann das Ergebnis normaler Verarbeitung sein.
GET_NEXT_NODE - dieser Zustand wird von dem Entscheidungsbaum-Bearbeitungskode benutzt. Damit wird angedeutet, daß die Bearbeitung zum nächsten Knoten im Entscheidungsbaum fortschreiten soll. Die Entscheidungsbaum-Bearbeitung steuert mit einer Kombination dieser Zustände die Logikbearbeitung der Fehleranalyse.
Es ist eines der Ziele der Fehleranalyse, sicherzustellen, daß Kanäle nicht als fehlerhaft gemeldet werden, wenn die Störung von einem anderen Hardwarelement verursacht wird. Eine der Vorgangsweisen, mit denen die Fehleranalyse diesen Vorgang durchführt, ist durch Prüfen zur Bestimmung, daß während des Ablaufes einer Einzelprüfung keine Fehler auf dem ISB oder damit verbundenen Komponenten auftraten.
Gegenwärtig läuft eine mit ISB-Scanner bezeichnete Task alle 500 Millisekunden ab, um auf mehreren Hardwareelementen auf Paritätsfehler zu prüfen und zwar auf den Erweiterungskarten, dem Quellenbus, den Sendeund Empfangskarten (X/R), sofern vorhanden, und allen anderen mit dem Bus verbundenen Karten, die Paritätsprüfungen benutzen. Bei Auftreten von Fehlern werden diese in den entsprechenden Systemintegrität-Datenbanken protokolliert.
Zur Erkennung von ISB-Fehlern wird der folgende Ansatz benutzt:
1) Es wird eine neue Globalstruktur definiert, TIME_LAST_ISB_ERROR. Während eines Restarts oder FINIT wird die Globalstruktur auf die aktuelle Zeit initialisiert.
2) Wenn der ISB-Scanner einen Fehler erkennt, der ein Prüfungsergebnis beeinflussen kann, wird diese Struktur mit der aktuellen Systemzeit aktualisiert.
3) Wenn die Systemintegrität dabei ist, eine neue Prüfung zu fahren, wird die aktuelle Systemzeit in der Fehleranalyse-Datenbankstruktur sichergestellt.
4) Bei Vollendung einer Systemintegritätsprüfung wird der Auftragssatz überprüft, um zu bestimmen, ob alle Ergebnisse der Prüfung Bestanden zeigen.
5) Bei Nichtbestehen eines der Ergebnisse wird eine Überprüfung durchgeführt, um zu bestimmen, wann der ISB-Scanner zuletzt vor Auftragsbeginn einen Fehler erkannt hatte. Wenn ein Fehler erkannt wird, wird ein neuer Globalzeiger TCB_WAITING_FOR_ISB_SCANNER mit dem aktuellen Tasksteuerblock (TCB - task control block) geschrieben. Die Task wird dann 1 Sekunde lang der Verzögerungswarteschlange zugewiesen. Damit kann der ISB- Scanner seine Funktion vollenden und alle Ergebnisse melden. Diese Prozedur ist notwendig, um sicherzustellen, daß eine Prüfung vollendet wird, ohne daß der ISB-Scanner dabei gelaufen ist. Zusätzlich ist es möglich, daß selbst wenn der ISB-Scanner während der Prüfung gelaufen ist, ein ISB-Fehler nach Scannerlauf aber vor Prüfungsende auftreten kann.
6) Bei Vollendung eines Abfragezyklus stößt der ISB-Scanner die mit TCB_WAITING_FOR_ISB_SCANNER angezeigte Task an. Durch Verfolgen dieser Prozedur wird durch die wartende Task keine zusätzliche Zeit auf die ISB- Scannerergebnisse verschwendet.

ADC-Verwaltung

Aus Gründen der Wiederholbarkeit erfordert die Fehleranalyse, daß während jeder Analyse dieselbe ADC- Karte für alle Prüfungen benutzt wird, und deshalb wird zur Verfolgung der ADC ein zusätzlicher Mechanismus eingesetzt. Gegenwärtig muß jede Prüfung, die gemeinsame Einrichtungen während der Prüfung erfordert, einen Zeiger auf die Task DXXXPR_CME() in ihrem Prüfungsverzeichnissatz haben. CME bezieht sich auf gemeinsame Einrichtungen wie Tonregister und sonstige gemeinsame Betriebsmittel für das gesamte System, im Gegensatz zu einer bestimmten Nebensteile. Kurz vor Ansetzen der Prüfung wird diese Task zur Zuweisung der angeforderten Art gemeinsamer Einrichtungen aufgerufen. Mit der Task wird der nächste verfügbare Gerätekanal der angegebenen Art (ADC) zugewiesen. Die Task führt folgende Funktionen aus:
1) Die Prüfungsfolgenummer wird aus dem Auftrags-Satz entnommen und es wird damit ein Fehleranalysedatenbanksatz erhalten. Das beruht auf der Annahme, daß vor Aufrufen von PRE_TEST() ein Fehleranalysesatz für diesen Auftrag erstellt worden ist.
2) Wenn die Kennzeichnungsnummer im Fehleranalysesatz NULL ist, so weist die Verarbeitung die nächste verfügbare ADC-Karte zu.
3) Die zugewiesene ADC-Kennzeichnungsnummer wird in das Kennzeichnungsnummernfeld im Fehleranalysesatz eingegeben.
4) Wenn die Kennzeichnungsnummer im Fehleranalysesatz nicht null ist, dann wurde eine ADC bereits von einer früheren Prüfung benötigt.
5) Zuweisen der vorher benutzten ADC. Wenn ein Fehleranalysedatenbankeintrag zuerst zugewiesen wird, wird die Kennzeichnungsnummer auf NULL gesetzt. Wenn sie bei Erreichen der Prüfungsanalysephase immer noch null ist, dann wurde von keinen Prüfungen eine ADC benötigt.

Mehrfache Knoten

Es gibt gewisse Situationen, in denen die Fehleranalyse eine Prüfung an einem Knoten aufrufen muß, der nicht der aktuelle Knoten ist. Dies findet folgendermaßen statt:
1) An dem Punkt in der Diagnoseüberwachung, an dem eine Prüfung laufen soll, wird die Knotennummer des zu prüfenden Kanals überprüft.
2) Wenn dies der aktuelle Knoten ist, wird die Ortsprüfung ausgeführt.
3) Wenn dies nicht der aktuelle Knoten ist, wird eine Nachricht mit einer Kopie des ursprünglichen Prioritätswarteschlangensatzes, die die örtliche Prüfungsfolgenummer enthält und den örtlichen Auftragssatz löscht, zum angegebenen Knoten gesandt.
4) Durch den Schritt 3 wird im abgesetzten Knoten eine Systemintegritäts-Prozeßservertask eingeleitet.
5) Durch die Systemintegritätstask wird ein Prioritätswarteschlangensatz mit einer Prüfungsfolge und Auftragsknotennummer vom Ursprungsknoten erstellt.
6) Es wird eine Fehleranalysedatenbanksatz dafür erstellt und die abgesetzte Prüfungsfolge und Knotennummer werden in Sonderfeldern im Datensatz abgelegt.
7) Bei Meldung der Erstergebnisse der Fernprüfung wird von der Fehleranalyse die Tatsache vermerkt, daß der Ursprungsknoten nicht der aktuelle Knoten ist, und den Fernprüfungs-Entscheidungsbaumindex durchsucht, um den für die Detailanalyse zu benutzenden Baum auszuwählen.
8) Danach fährt die Fehleranalyse mit der normalen Bearbeitung bis zum Punkt der Fehlerprotokollierung fort.
9) Wenn die Pseudoformulare der Fehleranalyse von der Fehleranalyse zu ERR_POST_PROCESS() zurückgegeben werden, wird die Prüfungsfolgenummer des Ursprungsknotens über der örtlichen während der Analyse benutzten eingefügt.
10) An der Stelle in ERR_POST_PROCESS(), wo ein neuer Fehlersatz protokolliert wird, wird das Pseudoformular untersucht, um den Meldeknoten zu bestimmen.
11) Wenn er sich im gegenwärtigen Knoten befindet, wird er in die Hardware-Fehlerdatenbank eingefügt.
12) Wenn er sich nicht im gegenwärtigen Knoten befindet, wird eine Nachricht mit einer Kopie des Pseudoformulars zum angegebenen Knoten übermittelt.
13) Im Ursprungsknoten bewirkt die Nachricht die Erstellung einer Prozeßservertask zum Aufnehmen des Pseudoformulars.
14) Mit dieser Task wird der Pseudoformula- Datensatz auseinandergenommen und die entsprechenden Informationen zur Task SI_REPORT_STATUS() weitergegeben.
15) Das Pseudoformular enthält die Ursprungs- Prüfungsfolgenummer, die zur Zurückleitung der Ergebnisse zum entsprechenden Fehleranalyse-Entscheidungsbaumknoten benutzt wird, der auf dieses Ergebnis wartet.

Entscheidungsbaumknoten

Die Hauptfunktion von Entscheidungsbaumknoten besteht zwar darin, die Prüfungen zu einem erfolgreichen Abschluß zu bringen, aber zur Realisierung und Unterstützung aller von der Fehleranalyse benötigten Tasken werden verschiedene Sonderfunktionen benötigt. Es folgt eine Liste der unterschiedlichen Knotenarten:
Prüfung - Ausführen der angegebenen Prüfung und Auf zeichnen, ob die Prüfung bestanden oder nicht bestanden worden ist.
Einleiten der Analyse - damit wird die Erstprüfung von den Entscheidungsbäumen für die mit dem gemeldeten Überwachungsfehler verbundene Kartenart angesetzt. Die so erstellte Analyse läuft mit einem von der laufenden Überwachungsanalyse getrennten Ende ab. Dieser Knoten wird auf mit Überwachungsfehler verbundenen Detailanalyse-Entscheidungsbäumen benutzt.
Prüfen vorliegender Ergebnisse - dieser Knoten gleicht dem Prüfungsknoten, nur wird in Wirklichkeit keine Prüfung ausgeführt. Mit dem Knoten sollen Ergebnisse von Prüfungen bearbeitet werden, die bei jedem Ablauf mehrfache Ergebnisse melden. Mit diesem Knoten wird das nächste Fehler-Pseudoformular in der Warteschlange für die laufende Analyse bearbeitet und bestimmt, ob die Prüfung bestanden oder nicht bestanden worden ist. Die Prüfungsnummer im Knoten wird außer acht gelassen.
Schlußfolgerung - mit diesem Knoten wird die für den Fehler vorgeschlagene Handlung in den Datensatz des Fehleranalyse-Pseudoformulars eingegeben. Bei vorgeschlagener Handlung "Kanal Bestanden" wird keine Bearbeitung durchgeführt. Das Pseudoformular wird anfangs auf einen Zustand "Bestanden" gesetzt. Zusätzlich wird mit diesem Knoten die Baumbearbeitung abgeschlossen und ein Fortschreiten der Analyse zur nächsten Phase oder zur Beendigung bewirkt.
Erweiterungskarte prüfen - benutzt die Kennzeichnungsnummer der geprüften Karte zur Kennzeichnung der richtigen Erweiterungskarte. Danach wird die angegebene Prüfung an der Erweiterungskarte ausgeführt.
CME prüfen - benutzt die Kennzeichnung des CME- Feldes zum Durchführen der angegebenen Prüfung. Dieses Feld wird zum Prüfen der ADC-Karte während der Prüfungsanalyse benutzt. Wenn das Kennzeichnungsnwnmernfeld NULL enthält, wird einfach ein Bestanden-Ergebnis zurückgegeben, womit angedeutet wird, daß von keiner der Prüfungen gemeinsame Einrichtungen benutzt worden sind.
Karten-Kennzeichnung - führt an allen für den Prüfkanal benötigten Karten eine Karten-Kennzeichnungsüberprüfung durch. Bei korrekten Kartenkennzeichnungen zeigt es das Ergebnis "Bestanden" an. Ansonsten wird ein Ergebnis "Nicht Bestanden" angezeigt.
Anstoßen - mit diesem Knoten wird ein neuer Fehleranalysevorgang eingeleitet. Der letzte durch die Fehleranalyse bearbeitete Fehlersatz wird von der Prozeßliste eingegeben, die Prüfungsfolge wird auf null gesetzt, und die Prozedur SI_REPORT_RESULTS() wird aufgerufen. Der Anstoß wird in der Prüfungsanalyse zum Starten der Fehleranalyse benutzt, wenn eine Komponente, die nicht die gegenwärtig analysierte ist, als fehlerhaft erkannt wird, wie beispielsweise eine aus fallende Erweiterungskarte oder ADC-Karte.
Abbrechen - mit diesem Knoten werden alle mit der gegenwärtigen Prüfungs folge verbundenen Fehleranalysesätze gelöscht. Er meldet GET_NEXT_ENTRY; damit wird der Fehleranalyse angedeutet, den nächsten Datensatz in der Datenbank zu benutzen.
Leerknoten - der Grundeintrag der Prüfungsanalyse-Entscheidungsbäume. Da die Zweige Bestanden/Nicht Bestanden des Grundeintrages die einzigen bearbeiteten sind, wird der Leerknoten für den ersten Prüfungsknoten des Prüfungsanalysebaums aufgestellt, damit man zum zweiten Knoten gelangen und eine Prüfung durchführen kann.
Aussteigen - mit diesem Knoten wird die Entscheidungsbaumbearbeitung abgeschlossen. Er meldet stets PROCEED und bewirkt, daß die Fehleranalyse zur nächsten Phase fortschreitet oder abgeschlossen wird.
Überwachung Bestehend - gleicht Prüfung Bestehend, wird aber für Überwachungsfehler benutzt.

Entscheidungsbaum-Datenbank

Man kann sich die Entscheidungsbaum-Datenbank als dreistuf ig vorstellen:
Erstindex - dieser wird dazu benutzt, auf Grundlage der Prüfungsnummer, der Kartenart und ob die Analyse von einem anderen Knoten aus angefordert wurde, den zu benutzenden Baum auszuwählen.
Baumstruktur - diese besteht aus den Knoten und Zweigen für entweder Bestanden oder Nicht Bestanden. Einige Knoten besitzen nur einen Ausstiegszustand. Bei Kodierung dieser Struktur sind die Zweige Bestanden und Nicht Bestanden einander gleich.
Knotendeskriptoren - es gibt je nach Knotenart unterschiedliche Knotendeskriptorstrukturen. Einige Knotendeskriptoren werden von mehr als einem Knoten benutzt, wenn die von jedem benutzten Informationen identisch sind.

Interne Merkmale der Datenbank

Fehlerdatenbankindizes - die Datenbank hat drei Indizes. Einer ist nach Kartenart, einer nach Kartenart für Fernknotenanalyse und einer nach Überwachungsfehlernummer. Die zwei Kartenartindizes sind Listen der folgenden Struktur:

Kartenartindex (abgesetzt und örtlich)

STRUCT EA_CARD_TYPE_INDEX(
INT EA_CTI_TYPE;
POINTER STRUCT EA_DT_NODE
EA_CTI_NODE);
Das Zugriffsverfahren benutzt die oben gebotene Struktur zur Durchführung von sequentiellen Suchvorgängen nach Karteninformationsart. Das Ende der Dateimarkierung ist ein Knotenzeiger NULL, so daß, wenn eine Struktur mit einem Knotenzeiger NULL erreicht wird, eine Suche mit "Kein Eintrag Gefunden" abschließt.
Jedes Überwachungsfehler-Indexfeld besitzt folgende Struktur:
Überwachungsartindex (abgesetzt und örtlich)
STRUCT EA_MON_INDEX(
INT EA_ALTERNAT_TYPE;
INT EA_MON_ERROR;
INT EA_CTI_TYPE;
POINTER STRUCT EA_DT_NODE
EA_MON_NODE);
Einträge NULL sind nur als Ende von Knotenzeigern zulässig. Das Zugriffsverfahren besteht aus einer schlüsselsequentiellen Suche mit einer Fehlernummer als Schlüssel. Wenn eine Struktur mit einem Knotenzeiger NULL erreicht wird, wird die Suche mit "Kein Eintrag Gefunden" abgeschlossen.

Baumstruktur

Jeder Entscheidungsbaum ist ein Datenfeld mit folgenden Strukturen:
Knotenstrukturen:
STRUCT EA_DT_NODE(
INT EAN_TYPE;
Zeiger zum Knotendeskriptor:
POINTER INT EAN_DESC
Relativzeiger zum nächsten Knoten bei Bestehen dieses Knotens:
BYTE EAN_PASS_NODE,
Relativzeiger zum nächsten Knoten bei Nichtbestehen dieses Knotens:
EAN_FAIL_NODE);

Literale für Knotenarten

Die Anzahl von Knoten in einem Entscheidungsbaum ändert sich mit dem Analyseaufwand. Die Literale für die unterschiedlichen Knotenarten werden unten aufgeführt:
LITERAL EANT_TEST(0), Prüfknoten
EANT_INITIATE(1), Erstanalyseknoten
EANT_TEST_EXIST(2), Knoten für bestehende Ergebnisse
EANT_CONCLUSION(3), Schlußfolgerungsknoten
EANT_TEST_EXPANDER(4), Prüferweiterungskartenknoten
EANT_TEST_CME(5), Prüfknoten CME
EANT_CARD_ID(6), Kartenkennungsknoten
EANT_KICKOFF(7), Anstoßknoten
EANT_RETURN(8), Wiederholungsknoten
EANT_ABORT(8), Abbrechungsknoten
EANT_DUMMY(10), Leerknoten
EANT_EXIT(11); Ausstiegsknoten

Knotendeskriptoren

Bei den folgenden Strukturen handelt es sich um die Knotendeskriptoren für die Knotenarten, die sie benötigen. Der Schlußfolgerungsknoten wird als Beispiel benutzt, jedoch enthalten alle Prüfungs-, Einleitungs-, Erweiterungskarten- und CME-Knoten ähnliche Strukturen für ihre Deskriptorenfelder.
STRUCT EAND_CONCLUSION(
BYTE EAD_CONC_PRI;
INT EAD_CONC_SA, vorgeschlagene Handlung &
EAD_CONC_ALT_SA); alternative Handlung

Datenstrukturen im einzelnen

Es folgen Beispiele von Entscheidungsbaum-Datenstrukturen für einen Überwachungsfehler und eine Kartenprüfung. Der Überwachungs-Entscheidungsbaum nimmt auf den anderen Baum Bezug. Die Logik der Indextabellen wird in den in Figuren 62 bis 71 dargestellten schematischen Logikdiagrammen beschrieben. STATIC STRUCT EA_DT_NODE MON_TREE_RLC(3) Knotenart Deskriptor Relativzeiger Bestanden Relativzeiger Nicht Bestanden STATIC STRUCT EA_DT_NODE RLI_a nalysis(16) Knotenart Deskriptor Relativzeiger Bestanden Relativzeiger Nicht Bestanden

Datenstruktur Schlußfolgerung

Es folgen die von den Schlußfolgerungsknoten oben benötigten Schlußfolgerungsdeskriptoren.
STATIC STRUCT EAND_CONCLUSION
PASSED_CONC(
0, Priorität frei
SA_TEST_PASSED, besonderer Handlungsvorschlag
SA_TEST_PASSED), alternative Handlung
- REPLACE_RLI1(
- 0, höchste Priorität
SA_REPLACE_RLI1, Nachricht mit vorgeschlagener Handlung
SA_REPLACE_RLI1), Alternative dafür
REPLACE_RP(
1, niedrigere Priorität als RLI-1
SA_REPLACE_RP, Telefon auflegen
SA_REPLACE_RP_PLUS), Zusatzinformationen
REPLACE_ALL(
2, niedrigste Priorität
SA_REPLACE_RLI_ALL, alles versuchen
SA_REPLACE_RLI_ALL); Alternative dafür
Für Beispiele zusätzlicher möglicher Handlungsnachrichten, die benutzt werden, siehe Figur 60 und 61. Die Struktur ist flexibel genug, um jede Hardwarekonfiguration zu unterstützen, die für Kommunikationsnachrichtenübermittlung oder sonstige Datenverarbeitungsaktivitäten benutzt werden können. Die Bäume werden wie oben beschrieben durchlaufen.

Taskauslegung

EA_TEST_GENERIC

Mit EA_TEST_GENERIC wird sichergestellt, daß eine nichtbestandene Prüfung nicht aufgrund von Fehlern auf dem ISB nicht bestanden wird. Alle vom ISB-Scanner gemeldeten Fehler werden als Grund zum Verwerfen der aktuellen Prüfungsergebnisse Nicht Bestanden erachtet. Die Task wird durch folgenden Taskenaufruf aufgerufen: EA_TEST_GENERIC(POINTER STRUCT EA_DB_ENTRY PREC);
Eingaben: PREC - POINTER STRUCT EA_DB_ENTRY, ein Zeiger zum aktuellen Fehleranalyse-Datenbankeintrag. Meldungen: PROCEED - keine ISB-Fehler, Fortfahren mit Analyse, oder GET_NEXT_ENTRY - Prüfungswiederholung erforderlich, da ISB-Fehler aufgetreten sind.
Wenn das Feld EA_TEST_RESULT des Fehleranalyse-Datenbanksatzes bestanden ist, wird einfach PROCEED gemeldet. Danach wird der Zeiger des aktuellen Pseudoformular-Datensatzes geholt. Wenn das Kennzeichenprüfungsfeld anzeigt, daß dies ein Überwachungsfehler ist oder das Fehlernummernfeld größer als 1 ist, wird PROCEED gemeldet. Dies geschieht, da Überwachungsfehler nicht wiederholt werden können. Fehlernummern größer als 1 deuten auch an, daß eine Einzelprüfung mehr als ein Ergebnis meldet und daher keine Nachprüfung auf ISB- Fehler erforderlich ist, da sie bereits bei Meldung des ersten von mehreren Ergebnissen überprüft worden sind.
Danach wird der Zeitstempel in der Fehleranalyse-Datenbank mit der globalen Variablen TIME_LAST_ISB_ERROR verglichen. Wenn seit Beginn der letzten Prüfung kein ISB-Fehler aufgetreten ist, wird PROCEED gemeldet. Bei Auftreten eines ISB-Fehlers seit Beginn der letzten Prüfung wird das letzte Pseudoformular in der Liste verworfen.
Danach wird die maximale Anzahl von vollendeten Versuchen der Durchführung der Prüfung mit sauberem Resultat geprüft, und wenn diese einen vom Benutzer definierten Standard überschreitet, wird die Task ABORT_ERROR_analysis() aufgerufen, um anzuzeigen, daß alle Zwischenergebnisse zu protokollieren, aber keine neuen Fehlersätze zu erstellen sind. Bei Nichtüberschreiten des Grenzwertes wird die Task SCHEDULE_TEST() mit derselben Prüfungskennzeichnung aufgerufen. In beiden Fällen meldet die Task GET_NEXT_ENTRY, da keine weitere Bearbeitung notwendig ist.

EA_GET_RECORD

Dies ist eine Universaltask, die als Eingabe eine Prüfungsfolgenummer erwartet und den Fehleranalyse- Datenbanksatz entsprechend der Prüfungsfolgenummer abgibt. Die Nachricht dient als Führung für den Systemanalytiker, damit er auf Probleme reagieren oder feststellen kann, daß das Problem gelöst ist. Zum Aufrufen der Task wird folgender Aufruf getätigt:
EA_GET_RECORD(INT TEST_SEQUENCE;
POINTER STRUCT
EA_DB_ENTRY PPREC);
TEST_SEQUENCE ist eine einfache Ganzzahl zur Identifizierung des bestimmten Fehleranalyse-Datenbanksatzes. Die Task meldet PPREC, die Adresse des Fehleranalysesatzes, die der angegebenen Prüfungsfolge entspricht. Wenn kein Datensatz gefunden wird, meldet PPREC einen Zeiger NULL.
Die Tasklogik führt folgende Aktionen durch: Durchführen einer linearen Durchsuchung der Fehleranalysedatenbank, um Datensätze zu finden, deren Prüfungsfolgenummer TEST_SEQUENCE entspricht, PPREC auf dessen Adresse setzen und NOERR melden. Ansonsten wird, wenn TEST_SEQUENCE gleich null ist, NULL oder keine Übereinstimmung gefunden wird, PPREC auf NULL gesetzt und NO_MATCH zurückgemeldet.

CHECK_ISB_ERRORS

Diese Task wird von TEST_EXEC() aus aufgerufen, wenn ein Zustand Nicht Bestanden von einer Prüfung zurückgemeldet wurde. Sie wird nach DEALLOC_RESOURCES() aufgerufen, da sie in den Wartezustand versetzt werden kann. Außerdem wird sie aufgerufen, bevor der Steuerzustand TEST_EXEC TCB auf IDLE gesetzt wird. Sie überprüft, ob der ISB-Scanner seit Beginn dieser Prüfung einen Fehler erkannt hat, und wenn ein Fehler erkannt worden ist, läuft sie ab und springt zurück. Wenn kein Fehler erkannt worden ist, geht die Task in den Wartezustand und wartet mit dem Rückspringen, bis der ISB-Scanner wieder läuft. Die Task wird durch folgenden Aufruf aufgerufen:

CHECK_ISB_ERRORS();

Die Logik dieser Task beginnt damit, daß das Prüfungsfolgefeld im aktuellen Auftragssatz in einem Aufruf zur Task EA_GET_RECORD() benutzt wird, um den Fehleranalysesatz zu erhalten. Das Feld EA_TIME im Fehleranalysesatz wird mit dem letzten Mal, als der ISB- Scanner einen Fehler erkannt hat, verglichen, um zu bestimmen, ob seit Beginn des Auftrages ein Fehler erkannt worden ist, der aktuelle TCB wird in der globalen Variablen TCB_WAITING_FOR_ISB_SCANNER abgelegt, und die Task wird eine Sekunde lang in die Verzögerungswarteschlange verlegt, um einen Zeitablauf abzuwarten. Wenn der ISB-Scanner seit Auftragsbeginn einen Fehler erkannt hat, dann springt der Auftrag einfach zurück.

ISB_FINISHED_SCAN

Diese Task wird vom ISB-Scanner aus aufgerufen, nachdem er einen vollen Abfragezyklus vollendet hat. Diese Task bestimmt, ob eine Task auf das Abfrageende wartet und stößt sie bei Abfragevollendung an. Sie wird wie unten dargestellt auf gerufen.

ISB_FINISHED_SCAN();

Es finden folgende Aktionen statt: wenn TCB_WAITING_FOR_ISB_SCAN NULL ist, dann rückspringen. Wenn es nicht null ist und sich der TCB in der Verzögerungswarteschlange befindet, dann diesen mit WHYSCHED von REQUEST in die Abfertigungswarteschlange setzen. Danach TCB_WAITING_FOR_ISB_SCAN auf NULL setzen.

ISB_ERROR_TIME_STAMP

Diese Task wird jedesmal dann vom ISB-Scanner aus aufgerufen, wenn ein Fehler eintritt, der das Ergebnis einer Systemintegritätsprüfung beeinflussen kann. Um Zeit zu sparen, wird nur ein Zeitstempel pro Abfragedurchlauf benutzt. Es wird daher eine globale Variable TIME_STAMP_ERROR dazu benutzt, zu entscheiden, ob es notwendig ist, GET_BIN_TIME nochmals in diesem Durchlauf auf zurufen. Diese Variable wird am Anfang jedes Abfragedurchlaufs auf Falsch gesetzt. Die Task wird mit folgendem Funktionsaufruf aufgerufen:

ISB_FINISHED_SCAN();

Die Task prüft TIME_STAMP_ERROR; wenn dies wahr ist, dann springt die Task zurück. Wenn TIME_STAMP_ERROR nicht wahr ist, dann wird von der Task GET_BIN_TIME() aufgerufen und die Ergebnisse in die globale Struktur TIME_LAST_ISB_ERROR eingesetzt. Danach setzt die Task TIME_STAMP_ERROR auf WAHR und springt zurück.

PROCESS_TREE

Mit dieser Task werden die Entscheidungsbäume ausgewertet. Bei ihrem Aufruf enthält der angegebene Fehleranalyse-Datenbankeintrag einen Zeiger auf den aktuellen bearbeiteten Knoten. Es wird einer von zwei Knoten des Entscheidungsbaums auf Grundlage der letzten im Datenbankeintrag enthaltenen Prüfungsergebnisse ausgewählt. Beispiele von Entscheidungsbäumen und der ihnen zugehörigen Logik sind in Figuren 62 bis 71 enthalten. Die Task wird durch folgenden Aufruf aufgerufen: PROCESS_TREE(POINTER STRUCT EA_DB_ENTRY PREC);
Die einzige Eingabe in die Tasklogik ist ein Zeiger auf den aktuellen bearbeiteten Fehleranalysedatenbankeintrag. Die Task meldet eine Markierung "Bearbeitung Fortsetzen" oder eine Markierung GET_NEXT_ENTRY, womit angedeutet wird, daß zusätzliche Bearbeitung für den Entscheidungsbaum notwendig ist oder der nächste Eintrag für zusätzliche Bearbeitung geholt werden soll. Die Tasklogik erhält die aktuelle Knotenadresse von dem angegebenen Fehleranalysedatenbanksatz. Danach setzt er eine örtliche Zustandsvariable auf NEXT_NODE. Als nächstes bildet er eine Schleife und führt folgende Schritte durch, solange die Zustandsvariable auf NEXT_NODE gesetzt ist.
Wenn das letzte Ergebnisfeld des Datenbanksatzes bestanden ist, den Relativzeiger Bestanden des aktuellen Knotens auf die Adresse der aktuellen Knotenadresse setzen. Sonst den Relativzeiger Nicht Bestanden zur aktuellen Knotenadresse hinzuaddieren. Danach den Datenbanksatz auf diese neue Adresse aktualisieren. Unter Verwendung der Knotenart zur Auswahl der aufzurufenden Knotenbearbeitungstask fortfahren. Jede der Knotenbearbeitungstasken wird mit einem Zeiger auf den aktuellen Datenbanksatz aufgerufen. Zusätzlich meldet jede Knotenverarbeitungstask den nächsten Zustand. Die möglichen Zustände sind:
PROCEED: Bearbeitung dieses Baumes beendet. Daher weiter mit nächster Phase.
GET_NEXT_NODE: weiter zum nächsten Knoten im Entscheidungsbaum auf Grundlage des Ergebnisfeldes im Datenbanksatz.
GET_NEXT_ENTRY: Bearbeitung dieses Baumes unterbrechen, um auf die Ergebnisse zu warten. Weiter mit Bearbeitung der Ergebnisse für andere ablaufende Analyse. Einige der Knoten benötigen keine Bearbeitung, da sie den gegenwärtigen Zustand modifizieren. Diese Knoten und der neue von ihnen gesetzte Zustand sind wie folgt
KNOTENNAME ZUSTAND GEMELDET
Bestehende Ergebnisse prüfen GET_NEXT_ENTRY
Leerknoten GET_NEXT_NODE
Ausstieg PROCEEDPROCESS_TEST_NODE
Diese Task wird durch PROCESS_TREE() aufgerufen und bearbeitet Entscheidungsbaum-Prüfungsknoten. Sie wird aufgerufen durch:
PROCESS_TEST_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Als Eingaben erfordert die Task: PREC, die auf die Fehleranalyse-Datenbankstruktur für die aktuelle Analyse zeigt. Die Task meldet: GET_NEXT_ENTRY, was der nächste für diese Knotenart zulässige Zustand ist. Die Tasklogik erhält die Prüfungskennzeichnung vom aktuellen Knoten, setzt einen Auftragssatz in die Prioritätswarte-Schlange für die Prüfung auf Grundlage der geprüften Kennzeichnungsnummer und meldet GET_NEXT_ENTRY.

PROCESS_INITIATE_analysis_NODE

Diese Task wird durch PROCESS_TREE() aufgerufen und verarbeitet Einleitungs-Analyseknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_INITIATE_analysis_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Als Eingabe erfordert die Task: PREC, was auf die Fehleranalyse-Datenbankstruktur für die aktuelle Analyse zeigt. Diese Task meldet: GET_NEXT_NODE, was der nächste Zustand für diese Knotenart ist, da es unnötig ist, Ergebnisse abzuwarten. Die Tasklogik erhält die Prüfungskennzeichnung durch Inspizieren des Entscheidungsbaumes für die den aktuellen Fehler wiederholende Kartenart. Eine Auftragsaufzeichnung wird in die Prioritätswarteschlange für die Prüfung eingesetzt, die die geprüfte Kennzeichnungsnummer mit einer Prüfungsfolge von null in Bezug bringt und GET_NEXT_NODE zurückmeldet.

PROCESS_CONCLUSION_NODE

Diese Task wird von PROCESS_TREE() aus aufgerufen und bearbeitet den Schlußfolgerungsknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_CONCLUSION_NODE(POINTER STRUCT EA_DB_ENTRY);
Es wird angenommen, daß PREC beim Aufrufen der Task einen Zeiger auf den Fehleranalysedatenbanksatz enthält. Die Task erhält einen Zeiger auf den Fehleranalyse-Pseudoformularsatz und setzt die aktuelle Knotennummer in den Pseudoformularsatz ein, um Bearbeitung für die Schlußfolgerung zu initialisieren. Danach wird ein dem Knoten entsprechender 16 Bit-Wert durch Abziehen der Adresse aller Baumtabellen von der Adresse des aktuellen Knotens berechnet. Dann kopiert die Task die Schlußfolgerungs-Deskriptorinformation, die die Schlußfolgerungspriorität und die zwei vorgeschlagenen Handlungsindizes enthält, in den Pseudoformularsatz.
Wenn die vorgeschlagene Handlung im Schlußfolgerungsdeskriptorkanal Bestanden ist, dann wird das Feld TEST_STATUS des Fehleranalyse-Pseudoformulars auf Bestanden gesetzt. Ansonsten bleibt es unmodifiziert. Es wird PROCEED zurückgemeldet, um die Fehleranalyse zu zwingen, zur nächsten Analysephase fortzuschreiten.

PROCESS_TEST_EXPANDER_NODE

Diese Task wird durch PROCESS_TREE() aufgerufen. Sie bearbeitet Erweiterungskartenprüfungsknoten. Die Task wird mit folgendem Aufruf aufgerufen:
PROCESS_TEST_EXPANDER_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Bei der Task wird angenommen, daß PREC auf die Fehleranalyse-Datenbankstruktur für die laufende Analyse zeigt. Die Task meldet GET_NEXT_ENTRY, was auf den nächsten Zustand für diese Knotenart initialisiert ist, um sicherzustellen, daß die nächste angegebene Prüfung ausgeführt wird.
Die Tasklogik erhält die Prüfungskennzeichnung vom aktuellen Knoten und benutzt die Kennzeichnungsnummer des geprüften Kanals, um die Kennzeichnungsnummer für die Erweiterungskarte zu bilden. Danach setzt sie einen Auftragssatz in die Prioritätswarteschlange für die der Kennzeichnungsnummer der Erweiterungskarte entsprechende Prüfung. Die Task meldet GET_NEXT_ENTRY.

PROCESS_TEST_CME_NODE

Diese Task wird durch PROCESS_TREE() aufgerufen. Sie bearbeitet CME-Prüfungsknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_TEST_CME_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Bei der Task wird angenommen, daß PREC auf die Fehleranalysedatenbankstruktur für die laufende Analyse zeigt. Die Task meldet GET_NEXT_ENTRY, was auf den nächsten Knoten für diese Knotenart initialisiert wird, um sicherzustellen, daß die nächste angegebene Prüfung ausgeführt wird.
Die Tasklogik erhält die Prüfungskennzeichnung vom aktuellen Knoten und benutzt die Kennzeichnungsnummer des geprüften Kanals, um die Kennzeichnungsnummer für die Erweiterungskarte zu bilden. Danach setzt sie einen Auftragssatz in die Prioritätswarteschlange für die der Kennzeichnungsnuxnmer des Feldes EA_CME_LTID entsprechende Prüfung. Die Task meldet GET_NEXT_ENTRY.

PROCESS_CARDID_NODE

Diese Task wird durch PROCESS_TREE() aufgerufen. Sie bearbeitet Kartenkennungsknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_CARDID_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Bei der Task wird angenommen, daß PREC auf die Fehleranalyse-Datenbankstruktur für die laufende Analyse zeigt. Die Task meldet GET_NEXT_ENTRY, was auf den nächsten Zustand für diese Knotenart initialisiert ist, um sicherzustellen, daß die nächste angegebene Prüfung ausgeführt wird.
Die Tasklogik ruft CARD_ID_DISTRICT() mit der Kennzeichnungsnummer des geprüften Kanals auf. Wenn die Kartenkennzeichnung aller geprüften Karten zufriedenstellend ist, dann wird das letzte Ergebnisfeld des Fehleranalyse-Datenbankeintrags auf "Bestanden" gesetzt, und wenn nicht, wird es auf "Nicht Bestanden" gesetzt. Es wird GET_NEXT_NODE gemeldet.

PROCESS_KICKOFF_NODE

Diese Task wird durch PROCESS_TREE() aufgerufen und bearbeitet Anstoßknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_KICKOFF_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Bei der Task wird angenommen, daß PREC auf die Fehleranalyse-Datenbankstruktur für die laufende Analyse zeigt. Die Task meldet GET_NEXT_NODE, was auf den nächsten Knoten für diese Knotenart initialisiert wird, um sicherzustellen, daß die nächste angegebene Prüfung ausgeführt wird.
Die Tasklogik entfernt das letzte Pseudoformular aus der Fehleranalyse-Datenbankliste und setzt das Prüffolgefeld auf null. Danach ruft sie mit diesem Pseudoformular SI_REPORT_RESULTS() und meldet GET_NEXT_NODE.

PROCESS_ABORT_NODE

Diese Task wird mit PROCESS_TREE() aufgerufen und bearbeitet Abbruchknoten. Sie wird mit folgendem Aufruf aufgerufen:
PROCESS_ABORT_NODE(POINTER STRUCT EA_DB_ENTRY PREC);
Bei der Task wird angenommen, daß PREC auf die Fehleranalyse-Datenbankstruktur für die laufende Analyse zeigt. Die Task meldet GET_NEXT_NODE, was auf den nächsten Knoten für diese Knotenart initialisiert wird, um sicherzustellen, daß die nächste angegebene Prüfung ausgeführt wird.
Die Tasklogik ruft EA_ABORT_analysis auf, gibt den spezifischen Fehleranalyse-Datenbanksatz weiter, ruft mit diesem Pseudoformular SI_REPORT_RESULTS() auf und meldet GET_NEXT_NODE.

SI_PROCESS_SERVER

SI_PROCESS_SERVER ist die Systemintegritätstask, die Nachrichten von anderen Knoten empfängt. Als Reaktion auf den Empfang einer Nachricht setzt die Task entweder einen Auftrag in die Prioritätswarteschlange ein oder meldet Fernergebnisse in der örtlichen Hardwarefehlerdatenbank.
Diese Task wird interaktiv zur Bearbeitung von Nachrichten bei deren Ankunft aufgerufen. Die Tasklogik reagiert auf eine ankommende Nachricht durch Aufnahme des ersten Byte, Aufnahme der übrigen Nachricht und nachfolgende Bearbeitung derselben. Das erste Byte wird zur Identifizierung der angeforderten Funktion benutzt. Die zwei Funktionen sind Fernauftrag oder Fernergebnisse. Mit dem ersten Byte wird auch die Länge der Transaktion angegeben. Eine Fernauftragsfunktion wird durch Prüfen der Prüffolgenummer vom Ursprungsknoten und Bestimmen, ob sie NULL ist, bearbeitet. Wenn sie nicht NULL ist, dann wird dafür ein Fehleranalyse-Datenbanksatz erstellt und in diesen die Prüffolge- und Knotennummer des Ursprungsknotens eingeschrieben. Die Prüffolgenummer des örtlichen Knotens wird für Fehleranalysebearbeitung benutzt. Danach wird ein Prioritätswarteschlangensatz erstellt und in diesen die angeforderte Kennzeichnungsnummer, Prüfungskennzeichnung, örtliche Folgenummer (oder NULL) und Ursprungsknotennummer eingeschrieben.
Wenn die Funktion "Fernergebnisse" ist, dann wird von der Tasklogik SI_REPORT_RESULTS mit der zeitweiligen Kopie des empfangenen Fehlersatzes aufgerufen. Sollte es Probleme geben, wird zum Ursprungsknoten NAK zurückgemeldet; ansonsten wird eine ACK-Nachricht übermittelt, um den Empfang und die Einleitung der angeforderten Funktion zu melden. Die Task wird mit einem EXIT-Aufruf beendet.

Verwaltungsprogramm für aus fallende Betriebsmittel

Funktionsbeschreibung

Das Verwaltungsprogramm für aus fallende Betriebsmittel (Failing Resource Manager) nimmt ein ausfallendes Betriebsmittel nach zwei aufeinanderfolgenden Ausfällen außer Betrieb. Dies wird auch "weiche Außerbetriebnahme eines Betriebsmittels" genannt, da der Außerbetrieb- Zustand ein von der Software auferlegter Zustand ist. Zu jedem aus fallenden Betriebsmittel gehörige Informationen werden in der Tabelle ausfallender Betriebsmittel (FRT - failing resource table) abgelegt.
Zugriff auf das aus fallende Betriebsmittel durch die Telefonsoftware wird verhindert, indem überprüft wird, daß dieses Betriebsmittel einen Außerbetriebszustand aufweist. Vom FRM wird dann ein außer Betrieb befindliches Betriebsmittel in den Betrieb zurückgeführt, wenn es wiederholt seine Prüfungen mehrere Male nacheinander (Vorgabewert 3mal) besteht.
Die Tasken des Verwaltungsprogramms für ausfallende Betriebsmittel stehen in Wechselwirkung mit den Fehleranalysetasken und den Schwellwertalarmtasken, indem sie sich Informationen über die Hardwarefehlertabelle (ERRH - Hardware Error Table) und die Tabelle ausfallender Betriebsmittel (FRT - Failing Resource Table) teilen.
Mit jeder Änderung wird jede FRT fortgeschrieben. Auch führt das Verwaltungsprogramm für aus fallende Betriebsmittel Prioritätsprüfung nach System Restart durch oder schaltet zur Reserve-CPU.
Um defekte Einrichtungen im Auge zu behalten, wird eine Datenbank für aus fallende Betriebsmittel gepflegt. Die Datenbank wird mit FRT bezeichnet und von den anderen mit Fehleranalyse verbundenen Tasken gemeinsam benutzt. Die Hardware-Fehlertabelle ist die Datenbank, in der Fehleranalyseergebnisse für die Betriebsmittel abgelegt werden.
Die ERRH wird zur Verfolgung der Vorgeschichte eines Betriebsmittels und Erhöhung des Schweregrades eines Aus falls auf Grundlage der Vorgeschichte des Betriebsmittels benutzt. Ein Ausfall wird als Ausnahme und zwei aufeinanderfolgende Ausfälle als Warnung angesehen. Beispiele für aus fallende Betriebsmittel umfassen gemeinsame Einrichtungen und schnittstellenkanäle.
Der Zustand, mit dem ein defektes Betriebsmittel daran gehindert wird, Fernsprechdienste zu beeinflussen, ist der Außerbetrieb-Zustand. Das Gegenstück zu dem obigen Zustand ist Wieder in Betrieb genommen, was eintritt, wenn ein vordem ausfallendes Betriebsmittel wieder in den normalen Systembetrieb zurückgeführt wird.

Detaillierte Funktionsweise Einführung

Die folgende Beschreibung der jeweiligen Tasken enthält eine Besprechung der detaillierten Funktion der vom Verwaltungsprogramm aus fallender Betriebsmittel eingesetzten Tasken. Im ersten Teil wird die Verwaltung eines aus fallenden Kanals oder einer aus fallenden Karte beschrieben. Danach werden die Restart-/Umschalttasken beschrieben. In den nächsten Abschnitten wird beschrieben, wie das Verwaltungsprogramm aus fallender Betriebsmittel mit den Fehleranalysetasken und den Schwellwertalarmtasken in Verbindung steht. Abschließend werden die Wiederherstellungsfähigkeiten beschrieben.

Verwaltung ausgefallener Betriebsmittel

Wenn durch Fehleranalyse ein einzelner Kanalausfall erkannt wird, wird das Verwaltungsprogramm ausfallender Betriebsmittel davon benachrichtigt. Es fordert die Fehleranalysetask auf, das Betriebsmittel nochmal zu prüfen, um die Gültigkeit der Prüfung sicherzustellen. Damit soll nachgewiesen werden, daß dies nicht ein intermittierender Fehler ist. Zur Verfolgung des Kanalausfalls wird ein Eintrag in die FRT eingeschrieben. Vor Außerbetriebnahme des Betriebsmittels wird das Verwaltungsprogramm für Schwellwertalarme angestoßen, um Erlaubnis für die Außerbetriebnahme anzufordern. Die Schwellwertalarme benutzen Informationen in der FRT zur Bestimmung der Gesamtzahl oder eines Prozentsatzes der Betriebsmittel, die gegenwärtig außer Dienst sind. Die resultierende Zahl wird dazu benutzt zu bestimmen, ob diese schlechten Betriebsmittel einen Neben- oder einen Hauptalarm verursacht haben. Weitere Informationen über Schwellwertalarme sind in dem Abschnitt Schwellwertalarme zu finden.
In der Annahme, daß es ausreichend restliche Betriebsmittel gibt, wird das Betriebsmittel außer Dienst genommen, und der Eintrag in der FRT wird aktualisiert, um die Herausnahme widerzuspiegeln. Nach Außerdienstnahme des Betriebsmittels wird dieselbe Reihe von Prüfungen mehrere Male durchgeführt, bis das Betriebsmittel dreimal besteht oder als katastrophal fehlerhaft angesehen wird. Wenn das ausfallende Betriebsmittel das erste Mal besteht, werden die Prüfungen noch zweimal wiederholt und das Betriebsmittel wieder in Dienst genommen, wenn es die Prüfungen drei aufeinanderfolgende Male besteht.
Bei Wiederinbetriebnahme des Betriebsmittels wird die Schwellwertalarmsoftware über eine Aktualisierung der FRT über die Wiederinbetriebnahme des aus fallenden Betriebsmittels informiert.

Mehrere ausfallende Kanäle auf einer Schnittstellenkarte

In der obigen Beschreibung wurde das Szenario eines einzelnen vom Verwaltungsprogramm aus fallender Betriebsmittel verwalteten Kanals beschrieben. Sollte eine ganze Schnittstellenkarte defekt sein, so werden alle Kanäle auf dieser Karte schließlich mit der Fehleranalyse einen Fehler registrieren.
Ein wirkungsvoller Ansatz zur Lösung dieser Art von Problem ist oftmals die Außerdienstnahme einer ganzen Karte und darauffolgende Wiederinbetriebnahme, was als Kartenrücksetzung bezeichnet wird, anstelle einer Einzelbehandlung jedes Kanals. Bei Wiederinbetriebnahme der Karte werden die Einzelkanäle neu für Fehleranalyse programmiert. Wenn alle Kanäle die Prüfungen drei aufeinanderfolgende Male nach Rücksetzung der Karte bestehen, werden sie wieder in Dienst genommen. Sollte die Karte jedoch intermittierende Ausfälle erfahren, so könnten die Kanäle schließlich wieder versagen. In diesem Fall wird der Zyklus wiederholt, und die Kartenrücksetzung könnte unendlicher Schleifenbildung unterworfen sein. Um diese Art von Schwierigkeit zu vermeiden, ist jeder Karte eine Grenze von drei Rücksetzungsdiensten gesetzt. Die Rücksetzungsdienste werden mit einer Kartenrücksetzungsdatenbank verfolgt.

Löschen eines Eintrags aus fallender Betriebsmittel

Es gibt drei Situationen, in denen ein Eintrag in der FRT gelöscht wird:
1) Wenn das von diesem Datensatz betroffene Betriebsmittel nach dreimaligem aufeinanderfolgendem Bestehen von Fehleranalyseprüfungen wieder in Betrieb genommen wird;
2) wenn der Eintrag in der ERRH (Hardwarefehlertabelle) gelöscht wird; und
3) wenn ein Betriebsmittel von FEP-Scannern wieder in Betrieb genommen wird.

Anschluß an die Fehleranalyse

Von den Tasken des Verwaltungsprogramms ausfallender Betriebsmittel werden die Fehleranalyseergebnisse ausgewertet und es wird bestimmt, wann ein Betriebsmittel außer Betrieb oder in Betrieb genommen werden soll. Darüber hinaus ist das Verwaltungsprogramm ausfallender Betriebsmittel für die Behandlung von Fehlern verantwortlich, die von einem einzelnen Kanal oder einer Kartenfehlfunktion herrühren. Mit dem Verwaltungsprogramm ausfallender Betriebsmittel werden auch Fehlfunktionen und das Funktionieren des Betriebsmittels durch Einsatz der Fehleranalysetasken nachgewiesen. Die Tabellen ERRH und FRT werden zur Koordinierung der Nahtstelle zwischen den zwei Taskenmengen eingesetzt.
Die Fehleranalyseergebnisse werden in der ERRH abgelegt. Bei Empfang eines Fehleranalyseergebnisses eines Betriebsmittels wird vom Verwaltungsprogramm aus fallender Betriebsmittel die Vorgeschichte des Betriebsmittels untersucht, um zu bestimmen, ob das Betriebsmittel weitere Analyse benötigt (um das aktuelle Ergebnis zu bestätigen). Bei Bestätigung eines defekten Betriebsmittels wird das Betriebsmittel vom FRM außer Betrieb genommen. Ein Eintrag wird in die FRT getätigt, und der Außerbetrieb-Zustand wird auch in der ERRH aktualisiert. Mit anderen Worten, es besteht stets ein Datensatz ausfallender Betriebsmittel in der FRT, der mit einem Fehleranalysesatz in der ERRH in Verbindung steht.

Anschluß an Schwellwertalarme

Vom Verwaltungsprogramm ausfallender Betriebsmittel werden Informationen für die Tasken der Schwellwertalarme (TA - threshold alarms) bereitgestellt, so daß die Ausfallalarme von Betriebsmitteln mit TA klassifiziert werden können. Die zwei durch den FRM gegebenen Informationen sind die Aktualisierungszählung (FR_UPDATE_COUNT) und der Datensatzstatus (FR_RECORD_STATUS).
Vom FRM wird der Wert von FR_UPDATE_COUNT einer Kartenart jedesmal dann um eins erhöht, wenn der Ausfallalarm der Kartenart aktualisiert werden muß. TA wird dann angestoßen, wenn von ihm eine FR_UPDATE_COUNT von nicht null beobachtet wird. Nach Auswertung des Ausfallalarms der Kartenart wird von TA die FR_UPDATE_COUNT erniedrigt.
FR_RECORD_STATUS ist ein Feld in der Tabelle ausfallender Betriebsmittel. Dieses Statusfeld wird vom FRM als Mittel zur Benachrichtigung von TA, daß dieser Datensatz gelöscht oder aktualisiert werden muß, aktualisiert.
Als Reaktion auf die vom FRM bereitgestellte Information wird vom TA durch Überprüfung des Außerbetriebnahme-Schwellwerts bestimmt, ob ein Betriebsmittel außer Betrieb genommen werden kann.

Modifizierung bei Fehlerprioritätssteigerung

Priorisierung von Fehlern ermöglicht die Klassifizierung von Fehlern nach Schweregrad. Von der Fehleranalyse werden zwei Prioritätskategorien benutzt. Ein Wert von 1 bis 150 wird als Hauptfehler angesehen, während ein Wert von 151 bis 246 als linder Fehler erachtet wird. Zusätzlich wird ein Wert von 247 bis 250 als Warnung betrachtet; ein Wert von 250 bis 260 wird als Ausnahme angesehen. Innerhalb der Warnungs-Fehlerkategorie bestehen wie unten gezeigt weitere Unterteilungen. Warnungsprioritäten Fehlerarten Kartenkennzeichnungsfehler noch keine Zuweisung Karte für gemeinsame Einrichtungen Verbindungsleitungskarte Datenkarte Leitungskarte gemeinsame Einrichtungen Verbindungsleitungskanal Datenkanal Leitungskanal
Der Bereich für die Ausnahmekategorie ist wie folgt unterteilt: Ausnahmeprioritäten Fehlerarten gemeinsame Einrichtungen Verbindungsleitungskarte/-kanal Datenkarte/-kanal Leitungskarte/-kanal

Datenbank für aus fallende Betriebsmittel

Die Datenbank für aus fallende Betriebsmittel ist ein zusammenhängender dynamischer Speicherbereich mit relevanten Informationen für alle ausfallenden Betriebsmittel. Sie wird bei Restart bewahrt und redundant gespeichert. Im wesentlichen ist sie in drei getrennte Teile aufgeteilt:
1) Mit Organisationsinformationen wird der Index des nächsten verfügbaren Datensatzes ausfallender Betriebsmittel gewartet. Dieser Index wird als Kopfteil für eine Liste freier Datensätze aus fallender Betriebsmittel benutzt.
2) Mit dem Kartenlistenfeld wird den Schwellwertalarmen schnellerer Zugriff auf alle zur selben Kartenart gehörende Datensätzen ausfallender Betriebsmittel gewährt. Anders ausgedrückt sind die Datensätze aus fallender Betriebsmittel nach Kartenarten gruppiert. Jedes Element im Kartenlistenfeld enthält einen Index zu dem den ersten aus fallenden Kanal für diese Kartenart darstellenden Kartensatz in der Tabelle ausfallender Betriebsmittel.
3) Die Tabelle ausfallender Betriebsmittel (FRT - Failing Resource Table) ist ein Datenfeld, in dem die ausfallenden Betriebsmittel aufgezeichnet sind. Es besteht aus 301 Datensätzen. (Die Größe dieser Tabelle ist willkürlich, weil man in Wirklichkeit nicht weiß, wieviele ausfallende Kanäle es gibt. Beispielsweise können sich für das Courtesy Down Map, in dem bis zu 288 vorsichtshalber außer Betrieb genommene Kanäle gespeichert werden, 300 Datensätze als mehr als ausreichend erweisen.) Der 301. Datensatz ist eine als Begrenzung für die Liste freier Datensätze und alle Kartenlisten benutzte Leermarkierung.

STRUCT FR DB

Figur 69 ist eine Darstellung der Datenstruktur der Tabellen ausfallender Betriebsmittel. Die Tabelle aus fallender Betriebsmittel steht in einem zusammenhängenden Speicherbereich des Systemprozessors. Etikett 900 zeigt den die Adresse des nächsten, für die Tabelle frei verfügbaren Datensatzes enthaltenden Datensatz an. Etikett 1000 zeigt den Bereich an, in dem das Kartenlistenfeld FR_CR_LIST() steht. Jede Karte wird mit folgender Struktur beschrieben:
FR_CR_LIST_INFO

FR_CR_LIST (N);

Das Kartenlistenfeld wird durch obige Struktur beschrieben, wobei N die aktuelle benutzte Liste ist. Etikett 1010 zeigt den Nutzbereich FR_RECORD() an, der mit Tabelle ausfallender Betriebsmittel (FRT - Failing Resource Table) bezeichnet wird. Er umfaßt 300 Datensätze, die den Zustand der verschiedenen Betriebsmittel des Systems anzeigen.
Figur 70 ist eine Darstellung der Datenstruktur für die Kartenlisteninformation aus fallender Betriebsmittel FR_CR_LIST_INFO. Die Datenstruktur wird durch FR_CR_LIST() am Etikett 1000 der Figur 69 zur Definition jedes Datensatzes benutzt. Etikett 1015 zeigt den Ort von FR_FIRST_IDX an, der einen Index zum Datenfeld FR_RECORD() enthält, wo der erste ausfallende Kanal einer bestimmten Kartenart eingetragen ist. Etikett 1020 zeigt den Ort van FR_COUNT an, nämlich die Anzahl von Datensätzen ausfallender Betriebsmittel, die alle zur selben Kartenart gehören. Etikett 1030 zeigt den Ort von UPDATE_CR_LIST an, ein Bit, das dazu benutzt wird, den Schwellwertalarmen anzuzeigen, daß die Alarmkategorie noch einmal berechnet werden muß.

Struktur von FR INFO

In jedem Datensatz aus fallender Betriebsmittel in der Tabelle ausfallender Betriebsmittel wird der Dienstzustand eines aus fallenden Kanals abgelegt und verfolgt, von wem die Anforderung einer "weichen" Außerbetriebnahme eingeleitet worden ist. Figur 71 ist der Quellkode für die Datenstruktur jedes Datensatzes von FR_INFO 2000. Etikett 2010 zeigt FR_LTID an, die Kennzeichnungsnummer des ausfallenden Kanals. Etikett 2020 zeigt FR_CR_TYPE an, d.h. die Kartenart dieses Kanals. Etikett 2030 zeigt FR_TRK_OR_DATA - GRP an, was nur anwendbar ist, wenn die Kartenart entweder eine Verbindungsleitungs- oder Datenkartenart ist. Bei einer Verbindungsleitung enthält dieses Feld die Verbindungsleitungskodenummer. Bei einer Datenkartenart enthält dieses Feld die Datengruppennummer. Etikett 2040 zeigt FR_LAST_UPDATE_BY an, womit die letzte stattfindende Operation gespeichert wird, entweder: FR_UPDATE_BY_TEST, FR_UPDATE_BY_MON, FR_UPDATE_BY_FEP, FR_UPDATE_BY_EXC oder FR_UPDATE_BY_RR.
Etikett 2050 zeigt FR_RECORD_STATUS an, der einer der folgenden ist: TA_UPDATE_NEEDED, TA_UPDATE_DONE oder TA_UPDATE_CLEAR. Damit wird der aktuelle Status des Datensatzes aufgezeichnet. Es gibt Fälle, in denen zwar ein Datensatz zum Löschen bereitsteht, aber die Alarmkategorie des Betriebsmittels noch nicht von Schwellwertalarmen neu kalkuliert werden konnte (aufgrund einer FEP- Anforderung zur Wiederinbetriebnahme des Kanals). Dieses Feld besitzt daher einen Zustand im "TA_UPDATE_CLEAR". Wenn die Task Schwellwertalarme schließlich dazu kommt, die Alarmkategorie für dieses Betriebsmittel neu zu bewerten, löscht sie auch diesen Eintrag.
Etikett 2060 zeigt FR_CHANNEL_STATE an, was den Betriebszustand des Kanals reflektiert: "außer Betrieb", "in Betrieb" oder "bereitstehend weich außer Betrieb genommen". Etikett 2070 zeigt FR_VOICE_OR_DATA an, was entweder eine Sprach- oder Datenkanalart ist. Dieses Feld ist nur auf ROLMphone-Schnittstellenkarten anwendbar. Etikett 2080 zeigt FR_ASSOC_ERRH an, eine Bitmarkierung, die zwischen den Werten 0 und 1 umschaltet. Wenn das Bit auf (1) gesetzt ist, bedeutet das, daß der Kanal von ERRH weich außer Betrieb genommen ist. Wenn es gelöscht ist (0), deutet das an, daß ERRH den Kanal wieder in Betrieb nehmen will. Etikett 2090 zeigt FR_ASSOC_OTHER an, eine Markierung, deren Funktion FR_ASSOC_ERRH gleicht. Wenn entweder vom FEP-Scanner oder von der Bearbeitung eines Ausnahmetabellenfehlers eine Kanalzustandsanforderung kommt, wird dieses Bit beeinflußt. Ein Kanal kann nicht wieder in Betrieb genommen werden, wenn nicht beide Bit FR_ASSOC_ERRH und FR_ASSOC_OTHER gelöscht sind.
Etikett 2100 zeigt FR_RR_NEEDED an, eine Markierung, die anzeigt, daß der mit FR_RECORD verbundene Kanal als erster nach einem Restart oder einer Umschaltung geprüft wird. Dies ist ein Mittel zur Prioritätsprüfung an außer Betrieb befindlichen Kanälen als Teil unseres Wiederherstellungsprogramms nach einem Restart. Etikett 2110 zeigt FR_NEXT_IDX an, was den Index des nächsten ausfallenden Kanals derselben Kartenart enthält. Dieses Feld enthält den Index des Leermarkierungssatzes, wenn sich der Datensatz am Ende der Liste befindet.
Konzeptionell kann man die Datensätze ausfallender Betriebsmittel als (durch die Indizes) einfach in die Tabelle ausfallender Betriebsmittel gebundene Listen betrachten. Jede Liste der Datensätze stellt eine Sammlung ausfallender Kanäle dar, die zur selben Kartenart gehören. Die Datensätze innerhalb einer Kartenliste sind in steigender Reihenfolge sortiert. Mit einer getrennten Liste werden alle unbenutzten Datensätze ausfallender Betriebsmittel miteinander verbunden, um eine freie Liste zu bilden. In Figur 72 wird die ATI-Kartenart dazu benutzt, darzustellen, wie drei ausfallende ATI-Kanäle einfach miteinander verbunden sind. Figur 72 zeigt die Informationsstruktur 3000 FE_CR_LIST, die hierarchisch über den Datensatz am Etikett 3010 mit den Datensätzen bei 3020, dem ersten ausfallenden Kanal, und Datensatz 3030, ein weiterer ausfallender Datensatz, verbunden ist. Der Datensatz bei 3040 wiederum ist mit dem Datensatz bei 3030 und dem freien Datensatz bei 3050 verbunden. Auf diese Weise wird eine verknüpfte Liste aus fallender Kanäle und ein Zeiger zum nächsten freien Kanal gebildet.

Kartenfehlerdatenbank

Um zu vermeiden, daß eine Karte zu oft rückgesetzt wird (aufgrund des mehrfachen Auftretens eines Kartenfehlers), ist es notwendig, bei jedem Kartenrücksetzen einen Zeitstempel zu erhalten. Beträgt der Unterschied zwischen der Zeit der letzten Rücksetzung einer Karte und der aktuellen Zeit weniger als 5 Minuten, dann wird die Anforderung eines Kartenrücksetzens verweigert. Darüber hinaus wird ein Zähler benötigt, so daß nach dreimaligem Rücksetzen der Karte nachfolgende Kartenrücksetzungen ebenfalls verweigert werden. Untenstehend wird eine Kartenrücksetz-Datenstruktur mit einer Beschreibung ihrer Funktion geboten.
STRUCT FR_CARD_RESET (
STRUCT SI_LTID FR_CR_LTID;
INT FR_CR_RESET_TIME (TVECT);
NIB FR_CR_RESET_COUNT )
FR_CR_LTID ist die LTID der Karte, wo ein Kartenfehler aufgetreten ist. Das Kanalfeld der LTID ist immer die erste Kanalnummer für diese Karte (z.B. es gibt * Kanäle pro ATI-Karte. Ist die erste Karte eines ATI- Bereichs rückzusetzen, ist das Kanalfeld in FR_CR_LTID 0. Es ist 8, wenn auf der zweiten ATI-Karte eine Kartenrücksetzung durchzuführen ist.)
FR_CR_RESET_TIME ist ein ganzzahliges Datenfeld mit der absoluten Systemzeit der letzten Rücksetzung einer Karte. Es wird mit jeder Kartenrücksetzung aktualisiert.
FR_CR_RESET_COUNT ist ein Tetradenzähler, der die Zeit einer Kartenrücksetzung verfolgt. Der Maximalwert für diesen Zähler ist drei.
Die Kartenfehlerdatenbank ist ein Datenfeld mit 30 Elementen. Es steht im dynamischen Speicherbereich. Es wird mit Restart aufbewahrt, aber nicht redundant erhalten. Die Feldgröße ist 30 * 6 = 180 Worte.
Jeder Datensatz hat eine Lebensdauer von 4 Stunden. Diese Lebensdauer ist willkürlich gesetzt.

Anforderungswarteschlange für allgemeine Zwecke

Um die Durchführung von Kartenrücksetzungen in der FEP-Umgebung zu vermeiden, wird von der Managementsoftware für aus fallende Betriebsmittel nicht das DOWN- und UP-Paket ausgegeben. Statt dessen erstellt sie einen zeitweiligen Datensatz und speichert die Karten-LTID im Datensatz. Die Task DOWN_MAINT ist für den Zugriff auf diese Kartenrücksetzungsanforderung verantwortlich und führt die eigentliche Kartenrücksetzung durch.
Wie schon erwähnt, wird an ein weich außer Betrieb genommenes ROLMphone, das ein "Einschalte"- Ereignis sendet, eine Sonderbehandlung angelegt. Nach "weicher" Inbetriebnahme wird eine Fehleranalyseprüfung angesetzt. Fehleranalyseprüfungen werden auch dann angesetzt, wenn von den Eingabe- und Ausgabe-Scannern des ROLMphones ein Ereignis "zu viele Ereignisse" erkannt wird.
Dargestellt wird nun die Strukturdefinition eines Anforderungsdatensatzes für allgemeine Zwecke zur Aufzeichnung einer Anforderung "Kartenrücksetzung", einer Anforderung "Kanal-Wiederprüfung" vom Scanner oder einer Anforderung "weiche" Außerbetriebnahme oder "weiche" Inbetriebnahme, die vom FEP eingeleitet wird:
STRUCT FR_MISC_REQ(
POINTER STRUCT FR_MISC_REQ
NEXT_FR_MISC_REQ_PTR,
PREV_FR_MISC_REQ_PTR;
STRUCT SI_LTID_FR_MISC_REQ_LTID;
INT FR_MISC_REQ_CR_TYPE;
BYTE FR_REQUEST_FUNC;
FR_WHO_REQUEST );
(a) NEXT_FR_MISC_REQ_PTR ist die Adresse zum nächsten Anforderungsdatensatz.
(b) PREV_FR_MISC_REQ_PTR ist die Adresse zum vorhergehenden Anforderungsdatensatz in der Liste.
(c) FR_MISC_REQ_LTID ist die LTID, an die die FR_REQUEST_FUNCtion anzulegen ist.
(d) FR_MISC_REQ_CR_TYPE ist die Kartenart der LTID. Diese Information wird für die Wiederprüfungsanforderungen benötigt.
(e) FR_REQUEST_FUNC ist die Funktionsart der Anforderung:
FR_CARD_RESET_REQ,
FR_RPI_FLOOD_RETEST_REQ,
FR_RPI_PWR_ON_RETEST_REQ,
FR_CHANNEL_SDOWN_REQ,
FR_CHANNEL_SUP_REQ,
FR_RETRY_CME_SDOWN_REQ,
FR_CLR_CME_SDOWN_REQ,
FR_RPI_ERR_RETEST_REQ.
(F) FR_WHO_REQUEST ist zur Kennzeichnung, wer (SI, FEP, usw.) die spezifische Anforderung einleitet.
Um diese Anforderungssätze für allgemeine Zwecke in die Warteschlange einzureihen und daraus herauszunehmen, werden die Standard-Dienstprogramme LINK() und UNLINK() benutzt. Zu der Datei DOWN_DYNAMIC werden zwei globale Eingaben als Kopf- und Endzeiger zu den Kartenrücksetzsätzen hinzugefügt. Figur 73 enthält eine Darstellung der von ihnen bereitgestellten Verknüpfungen.

Globale Daten für Restart

Wiederherstellung für aus fallende Betriebsmittel

Zur Unterstützung des Restart-Wiederherstellungsschemas für aus fallende Betriebsmittel werden zwei Variablen benötigt:
INT FR_RR_RETEST_DONE: diese Variable ist auf wahr gesetzt, wenn alle Datensätze für aus fallende Betriebsmittel, die mit der Restart-Wiederherstellung markiert sind, die Prozedur für Wiederprüfung durchlaufen haben. Andererseits ist diese Variable auf Falsch gesetzt, wenn noch weitere "markierte" Datensätze ausfallender Betriebsmittel zu verarbeiten sind.
INT FR_RR_NEXT_IDX: diese Variable enthält einen Index zu einem Datensatz in der Tabelle aus fallender Betriebsmittel. Dieser Datensatz wird als nächster von der Task PICK_RE_RECORD() für Wiederprüfung ausgewählt. Sein Wert beträgt NULL, wenn FR_RR_RETEST_DONE auf WAHR gesetzt ist.

Änderung der Fehlerparameter-Datenbanken

Es ist absehbar, daß wir bei Protokollierung gewisser Fehlerarten einige Fernsprechbetriebsmittel u.U. nicht weich außer Betrieb nehmen wollen, da sie möglicherweise nicht die Dienstgüte beeinflussen. Andererseits möchten wir diese Fehler protokolliert sehen, und ihre Fehlerprioritäten sollen steigen, wenn der Schwellwert NICHT BESTANDEN (Fehlerzahl) erreicht ist.
Die Datei TSPARM_DB.sp enthält verschiedene Datenbanken für von den Systemintegritätsprüfungen, den Überwachungen und den FEP-Scannern protokollierten Fehlern. Jeder Datensatz stellt einen eindeutigen Fehler dar und besteht aus den Prioritäten erster Stufe und manchmal zweiter Stufe für diesen Fehler sowie den Schwellwerten PASSED/UP und FAILED/DOWN für diesen bestimmten Fehler.
Diese Datei setzt eine Markierung in jeden Fehlerparametersatz ein. Wenn diese Markierung "Do_Not_Soft_Down" gesetzt ist, bedeutet das, daß die weiche Außerbetriebnahme eines Betriebsmittels verboten ist, selbst wenn der Schwellwert FAILED (NICHT BESTANDEN) überschritten worden ist.
Untenstehend wird die Datenstruktur für diese Fehlerparametersätze in der Datei TSPARM_DB geboten:
STRUCT ALL_ERR_PARM ( INT CRTYPE, MARKER,
PRIOR, UPTHRESH, DNTHRESH, CHAN_WARNING,
CARD_WARNING, DO_NOT_SDOWN );
CRTYPE ist die Kartenart des Betriebsmittels. MARKER deutet die Art des Fehlerparametersatzes an, entweder Überwachung oder Prüfung. PRIOR ist die Fehlerpriorität erster Stufe. UPTHRESH und DNTHRESH sind die hohen und niedrigen Schwellwerte für das Betriebsmittel. CHAN_WARNING ist die Kanalfehlerpriorität zweiter Stufe. CARD_WARNING ist die Kartenfehlerpriorität zweiter Stufe. DO_NOT_SDOWN ist ein besonderer Datensatz, der anzeigt, daß keine weiche Außerbetriebnahme (soft_down) zulässig ist.

Programmauslegung

Funktionsbeschreibung RE RETEST CHECK()

Hierbei handelt es sich um das Hauptsteuerprogramm für die Prozedur FR_MANAGEMENT(). Mit gegebenem aktuellem Prüfungsergebnis (im Pseudofehlerformular) und der Vorgeschichte (in dem Fehlerbereich) eines Kanals analysiert dieses Dienstprogramm die Information und entscheidet, ob der Kanal wieder zu prüfen ist. Wenn erneute Prüfung nicht erforderlich ist, benutzt sie die Prüfinformationen und die UP- und DOWN-Schwellwerte zur Bestimmung, ob ein Kanal wieder in Betrieb genommen oder aus dem Betrieb entfernt werden muß. Außerdem prüft sie, ob ein Kartenfehler erkannt worden ist, und gibt diese Beobachtung an FR_MANAGEMENT() weiter.

Aufrufschnittstelle

Sie wird in STUFF_POCKET() aufgerufen, was durch ERR_POST_PROCESS() aufgerufen wird. Diese Programm wird nur dann ausgeführt, wenn es auf dem aktiven Prozessor abläuft.
PARAMETER: - Zeiger zur Pseudofehlerinformation, - Zeiger zum Fehlerbereich, - Prüfungsergebnis (TEST_PASSED oder TEST_FAILED), - neuer aktueller Status des Fehlerbereichs, - voriger aktueller Status des Fehlerbereichs, - Anforderungsart, Zeiger zum Kanal-Dienstzustand (zu aktualisieren) (UP, RESTORED, DOWN, NULL für keine Änderung),
- Zeiger zu einem Wort, das anzeigt, ob die Fehlerpriorität hinauf- oder herabgesetzt werden soll.

RÜCKMELDUNG: - NOERR

Programmauslegung

1) Hierher zurückkehren, wenn diese Prozedur vom Reserveprozessor aufgerufen wird.
2) Die (örtliche) Markierung RE_TEST auf FALSCH initialisieren. Einen örtlichen Zähler auf 0 für die Anzahl Prüfungswiederholungen setzen. Den Dienstzustand auf "NULL" initialisieren.
3) Prüfen, ob der Pseudofehler durch Fehleranalyse formattiert ist. Eine örtliche Markierung CARD_ERR setzen, die dann den Wert des Kartenfehlerbits im Pseudofehler enthält.
4) Wenn TANDEX_FLAG FALSCH ist und der Fehler ein Überwachungsfehler (Format 9) ist, eine örtliche Markierung OK_TO_SDOWN auf WAHR setzen, wenn die Kartenart eine der folgenden ist: CR_ETI, CR_RPI, CR_CYP oder CR_DIS.
5) Wenn das Prüfungsergebnis TEST_PASSED ist:
Wenn dies das erste Bestanden nach einer Reihe von Ausfällen ist, ist die Nicht-Bestanden-Strähne unterbrochen. Markierung RE_TEST auf WAHR setzen und die Anzahl Prüfungswiederholungen auf 2. Weiter zu Schritt 6.
Wenn die Fehlervorgeschichte andeutet, daß dies nicht das erste Erfolgsereignis ist, prüfen, ob der Schwellwert UP (PASSED) überschritten worden ist. Wenn der Schwellwert UP noch nicht überschritten worden ist, zur aufrufenden Routine zurückkehren. Wenn TANDEM_FLAG FALSCH ist und OK_TO_SDOWN FALSCH ist, zur aufrufenden Routine zurückkehren. Wenn TANDEN_FLAG WAHR ist, aber dies nicht ein Fehleranalyse-Fehlerbereich ist, zum Aufrufenden zurückkehren.
Bei Erreichen des UP-Schwellwertes FR_MANAGEMENT() aufrufen, um Wiederinbetriebnahme des Kanals anzufordern, wenn er gegenwärtig außer Dienst ist (ERST == DOWNED). Wir die Anforderung gewährt, den Dienstzustandparameter auf "RESTORED" aktualisieren. Weiter zu Schritt 7.
6) Wenn das Prüfungsergebnis TEST_FAILED ist:
Überprüfen, ob dies der erste Ausfall nach einer Reihe von Bestanden ist. Wenn die Bestanden-Strähne unterbrochen ist, die Markierung RE_TEST auf WAHR und die Anzahl Prüfungswiederholungen auf 1 setzen. Weiter zu Schritt 7.
Prüfen, ob der Schwellwert DOWN (FAILED) überschritten worden ist. Wenn nicht, zur aufrufenden Routine zurückkehren.
Wenn TANDEM_FLAG FALSCH ist und OK_TO_SDOWN FALSCH ist, zur aufrufenden Routine zurückkehren. Wenn TANDAM_FLAG WAHR ist und der Fehlerbereich nicht durch Fehleranalyse formattiert ist, zum Aufrufenden zurückkehren.
Bei Erreichen des Schwellwertes DOWN und nicht gesetzter Markierung DONT_SDOWN im Pseudofehlerformular, und das ERST-Feld im Fehlerbereich meldet, daß der Kanal noch in Betrieb ist, dann FR_CHANGE_CHANNEL_STATE() aufrufen, um Kanalaußerbetriebnahme anzufordern. Wir die Anforderung gewährt, den Außerbetriebparameter auf "DOWNED" aktualisieren.
7) Wenn die Markierung RE_TEST WAHR ist, prüfen, ob alle folgenden Zustände gelten:
- TANDEM_FLAG ist WAHR,
- Fehleranalyse ist freigegeben,
- dies ist ein Fehleranalyse-Fehlerbereich, und
- es handelt sich nicht um einen von der CLI eingeleiteten Auftrag,
SCH_ERR_ANALYSIS() aufrufen, um Fehleranalyse zur Wiederprüfung des Kanals anzusetzen.
8) Rückmelden NOERR.

FR MANAGEMENT()

Funktionsbeschreibung

Bei gegebener LTID eines Kanals und zu setzendem Dienststatus ruft diese Prozedur FR_CHANGE_CHANNEL_STATE() auf, um den Dienstzustand des Kanals (außer Betrieb oder in Betrieb) zu ändern. Wenn der Kanal jedoch ein PhoneMail-Kanal ist, werden alle Anforderungen zur Änderung des Kanaldienststatus unberücksichtigt gelassen.
Diese Prozedur ist auch für das Rücksetzen einer Karte verantwortlich. Diese Routine liefert ein Argument, das der aufrufenden Prozedur gestattet anzuzeigen, daß ein Kartenfehler aufgetreten ist. Bei keiner Anzeige des Auftretens eines Kartenfehlers wird im Fall der weichen Außerbetriebnahme eines Kanals eine Sonderprüfung durchgeführt. Wenn alle Kanäle auf der Karte (auf der sich der eben weich außer Betrieb genommene Kanal befindet) weich außer Betrieb genommen sind, wird die Karte rückgesetzt, und alle Kanäle für diese Karte werden neu zur Prüfung angesetzt.

Aufrufschnittstelle

Diese Routine ersetzt die Prozeduren TRY_CARD_DOWN() und TRY_CARD_UP(). Sie wird durch die neue Prozedur FR_RETEST_CHECK() aufgerufen. Sie wird anstelle von DOWN_UP_CHANNEL() von den FEP-Scannern oder der fehlerbearbeitenden Software der Ausnahmetabelle aufgerufen.

PARAMETER:

- Zeiger zur Kanal-LTID,
- Kartenart,
einzustellender Dienstzustand,
- Anforderer (Systemintegrität, FEP...),
- Markierung, Kartenfehler
- Markierung sperren OK,
- Zeiger zum resultierenden Dienstzustand.

RÜCKMELDUNGEN:

- NOERR (Anforderung für Dienstzustandsänderung durchgeführt)
- FAILED (der Anforderung kann nicht stattgegeben werden)
- CANT_COMPLETE (unterwartete Unterbrechung) Programmbeschreibung
1) Parameter initialisieren, SERVICE_STATUS auf NULL (für keine Änderung).
2) Wenn TANDEM_FLAG FALSCH ist, weiter, wenn Kartenart des Kanals CR_RPI, CR_CYP, CR_TRUNK, CR_DIS und CR_T1D3 und CR_ETS ist.
Rückmelden CANT_COMPLETE, wenn die Kartenart keine der obigen ist.
3) Wenn die Kartenart eine der folgenden ist:
CR_RPI, CR_RLC1V oder CR_RLC1, den TCN-Datensatz des Kanals suchen. Wenn Kanalart des TCN-Satzes zeigt, daß dies ein PhoneMail-Kanal ist (CH_VPC), CANT_COMPLETE rückmelden.
4) FR_CHANGE_CHANNEL_STATE() aufrufen zur Aktualisierung der Tabelle aus fallender Betriebsmittel und Durchführung der notwendigen Dienstzustandsänderung.
5) Wenn TANDEM_FLAG FALSCH ist, nicht zum nächsten Schritt fortschreiten.
6) Bei nicht gesetzter Markierung Kartenfehler überprüfen, ob ein Kanal eben weich außer Betrieb genommen worden ist, und ob alle Kanäle auf der Karte bereits weich außer Betrieb genommen worden sind. In diesem Fall sollte die Karte rückgesetzt werden. Markierung Kartenfehler auf WAHR setzen.
7) Bei Markierung Kartenfehler WAHR, einen zeitweiligen Kartenrücksetzanforderung-Satz in die Warteschlange einsetzen, so daß die Task DOWN_MAINT später die Durchführung der Kartenrücksetzoperation durchführen kann.
8) Zur aufrufenden Prozedur zurückkehren.

FR CHANGE CHANNEL STATE ()

Funktionsbeschreibung

Mit dieser Prozedur wird der der gegebenen Kanal- LTID entsprechende Datensatz aus fallender Betriebsmittel gefunden. Sie informiert die Software für Schwellwertalarme, die Alarmkategorie für die Art ausfallenden Betriebsmittels neu zu berechnen. Sie aktualisiert den Datensatz aus fallender Betriebsmittel dementsprechend in Abhängigkeit von der benötigten Kanalzustandsänderung. Danach ruft sie zum Setzen/Rücksetzen des Zustandsbits DOWN_UP_CH() mit einer Funktion Weichaußerbetriebnahme oder Weichinbetriebnahme auf, so daß verschiedene Anwendungen darüber informiert sind, ob ein Kanal für den Dienst verfügbar ist oder nicht.

Aufrufschnittstelle

Diese Routine wird vom FR_MANAGEMENT() aus aufgerufen.

PARAMETER:

- Zeiger zur LTID,
- Kartenart,
- zu setzender Betriebszustand (außer Betrieb, in Betrieb)
- Anforderer (Systemintegrität, FEP-Scanner),
- Markierung In Betrieb halten,
- Markierung sperren OK,
- Zeiger zum resultierenden Betriebszustand.

RÜCKMELDUNG:

- NOERR (Anforderung für Betriebszustandsänderung fertig)
- FAILED (der Anforderung kann nicht stattgegeben werden)
- CANT_COMPLETE (unerwartete Unterbrechung)

Programmbeschreibung

1) Parameter einleiten, Markierung CARD_RESET auf FALSCH.
2) Aufrufen FR_RECORD_UPDATE() mit einer Funktion "aktualisieren" zum Suchen eines Datensatzschlüssels mit der LTID in der Tabelle ausfallender Betriebsmittel. Wenn der Datensatz nicht gefunden wird, erstellt FR_RECORD_UPDATE() einen neuen Eintrag.
3) Bei keinen Fehlerrückmeldungen für FR_UPDATE_UPDATE() überprüfen, ob der Kanal sich bereits in dem Zustand befindet, in den er geändert werden soll. Wenn dies der Fall ist, den resultierenden Zustand in den Parametern auf den bestehenden Betriebszustand aktualisieren. Aus diesem Programm ausspringen und NOERR melden.
4) FR_RECORD_REPLACE() aufrufen, um das Datensatz-Zustandsfeld TA_UPDATE_NEEDED zuzuweisen. (Dies wirkt als Semaphor.)
5) LOGICAL_UPDATE() aufrufen zur Aktualisierung der Tabelle aus fallender Betriebsmittel auf der redundanten Seite.
6) Die Markierung Sperren OK weitergeben und Schwellwertalarme aufrufen, um Erlaubnis zur Änderung des Kanalzustandes anzufordern. Bei Nichtgewährung der Erlaubnis nur dann eine Ausnahme machen, wenn der FEP-Scanner die Kanalzustandsänderung anfordert (eine Markierung REQUEST_GRANTED auf FALSCH setzen).
7) Wenn Schwellwertalarme anzeigen, daß Sperrung(en) stattgefunden hat (haben) (wo Sperrung OK ist), FR_RECORD_UPDATE() mit einer Funktion "aktualisieren" aufrufen, um den Datensatz wieder zu finden/erstellen, sollte der Datensatz während des Sperrzustandes gelöscht werden.
8) Wenn Schwellwertalarm anzeigt, daß die Alarmberechnung vollendet ist, das Datensatzzustandsfeld auf "TA_UPDATE_DONE" rücksetzen.
9) Den Datensatz aktualisieren. Wenn der Kanal wieder in Betrieb zu nehmen ist, andere Quellen aber glauben, daß dieser Kanal außer Betrieb bleiben soll, die Markierung REQUEST_GRANTED auf FALSCH setzen.
10) Sollte der Zustandsänderungsanforderung stattgegeben werden, DOWN_UP_CH() aufrufen, um die Außerbetriebnahme oder Inbetriebnahme des Kanals tatsächlich durchzuführen.
11) Wenn DOWN_UP_CH() anzeigt, daß der neue Zustand des Kanals Erwartet Weiche Außerbetriebnahme ist und er eine gemeinsame Einrichtung darstellt, FR_MISC_REQ_INSERT() aufrufen, um die Anforderung Weich außer Betrieb genommen später nochmal zu versuchen. Wenn DOWN_UP_CH() anzeigt, daß die Anforderung weich in Betrieb genommen oder weich außer Betrieb genommen ordnungsgemäß bearbeitet wird, dann vorsichtshalber FR_MISC_REQ_INSERT() aufrufen, um alle Anforderungen "Weich Außer Betrieb genommen erneut versuchen" für diesen Kanal abzubrechen.
12) Wenn der Kanal wieder in Betrieb genommen werden soll und der Datensatzstatus "TA_UPDATE_DONE" ist, dann FR_RECORD_UPDATE() mit einer Funktion "Löschen" aufrufen, so daß der Datensatz gelöscht wird. Ansonsten muß der Datensatzstatus "TA_UPDATE_NEEDED" sein. Den Datensatzstatus auf "TA UPDATE_CLEAR" setzen, um Schwellwertalarmen zu signalisieren, den Datensatz bei Neuberechnung der Alarmkategorie zu löschen.
13) LOGIGAL_UPDATE() aufrufen, um die Reserveseite wieder zu aktualisieren.
14) Abschließend zur aufrufenden Prozedur zurückkehren.

SCH ERR ANALYSIS()

Funktionsbeschreibung

Mit gegebener LTID einer Karte versucht diese Prozedur, Fehleranalyseprüfungen auf einem bestimmten Kanal oder auf allen Kanälen für eine Karte anzusetzen.

Aufrufschnittstelle

Dieses Unterprogramm wird durch FR_RETEST_CHECK() aufgerufen, wenn es Fehleranalyseprüfungen für einen bestimmten Kanal neu ansetzen möchte. Außerdem wird es von FR_PROCESS_MISC_REQ() nach Durchführung einer Kartenrücksetzungsoperation aufgerufen, so daß alle Kanäle auf der rückgesetzten Karte neu geprüft werden können.

PARAMETER:

- Zeiger zur LTID,
- Kartenart,
- Markierung, die anzeigt, ob die gesamte Karte geprüft werden muß,
- Anzahl Prüfungswiederholungen.

RÜCKMELDUNG:

- NOERR
- CANT_COMPLETE

Programmbeschreibung

1) CRTY_TO_CIDX() aufrufen, um die Kartenart zum "Karteninformationsindex" umzuwandeln.
2) Diesen Indexwert zu EA_DISABLED_FOR_CARD() weitergeben, um zu überprüfen, ob Fehleranalyse für diese Kartenart gesperrt ist.
3) Bei gesperrter Fehleranalyse für diese Kartenart, CANT_COMPLETE rückmelden.
4) Wenn die gesamte Karte geprüft werden muß, CHANNEL_RANGE_FOR_CARD() aufrufen, um den Bereich der durch die Karte dargestellten Kanalnummer zu bekommen. Wenn nicht, diesen Schritt überspringen.
5) INSERT_PRI_Q() aufrufen, um Fehleranalyseprüfungen auf dem Kanal (den Kanälen) anzusetzen.
6) Wenn von INSERT_PRI_Q() aus ein Fehler gemeldet wird, CANT_COMPLETE melden.
7) NOERR rückmelden.

FR PROCESS MISC REQ()

Funktionsbeschreibung

Mit diesem Unterprogramm wird jeder Kartenrücksetzanforderungssatz, Anforderungssatz weicher Außerbetriebnahme, Anforderungssatz weicher Inbetriebnahme oder Anforderungssatz für Kanalwiederprüfung in der Anforderungswarteschlange für allgemeine Zwecke bearbeitet. Für eine Kartenrücksetzanforderung baut sie einen Kartenfehlereintrag im Kartenfehler-Datenfeld mit der Karten-LTID als Schlüssel. Sie ruft FR_SEND_CE_RESET_PACKET() auf, um ein Befehlspaket DOWN und UP zu der Karte, auf der Kartenfehler vorgekommen, zu senden. Bei erfolgreicher Rücksetzoperation ruft sie SCH_ERR_ANALYSIS() auf, um Fehleranalyse auf allen Kanälen der Karte anzusetzen.
Für eine Anforderung weicher Außerbetriebnahme oder weicher Inbetriebnahme ruft sie FR_MANAGEMENT() auf, um den Dienstzustand des Kanals zu ändern. Wenn dies ein Anforderungssatz für Kanalwiederprüfungen ist, ruft diese Prozedur einfach SCH_ERR_ANALYSIS() auf, um Fehleranalyseprüfungen auf dem in der Anforderung angegebenen Kanal anzusetzen.

Aufrufschnittstelle

Diese Prozedur wird von DOWN_MAINT() aus aufgerufen, das unter der Task DOWN_MAINT abläuft.
PARAMETER: keine.

RÜCKMELDUNG:

- NOERR

- CANT_COMPLETE

Programmbeschreibung

1) Auf die Kartenrücksetz-Anforderungsliste zugreifen. Wenn sie leer ist, aus dieser Routine ausspringen.
2) Jede Anforderung durchlaufen, bis keine Kartenrück- setzungen anfordernden Einträge mehr vorhanden sind. Die laufende Kartenrücksetzanforderung aus der Liste ausbinden.
3) Wenn dies eine Kanalneuprüfungsanforderung ist, SCH_ERR_ANALYSIS() aufrufen, um Fehleranalyseprüfungen für den bestimmten Kanal im Datensatz anzusetzen.
4) FR_MANAGEMENT() aufrufen, wenn dies eine Anforderung für weiche Außerbetriebnahme oder weiche Inbetriebnahme ist.
5) Wenn dies eine Kartenrücksetzungsanforderung ist:
Eine Karteninformation erstellen und initialisieren, die im Datenfeld FR_CR_ERROR aufgezeichnet wird, wenn noch keine besteht.
Überprüfen, ob dies das erste Vorkommnis eines Kartenausfalls ist (der Kartenrücksetzzähler würde auf 0 stehen). Wenn nicht, dann überprüfen, ob seit der letzten Kartenrücksetzung mehr als 5 Minuten vergangen sind. Wenn noch keine 5 Minuten vergangen sind, dann diese Kartenrücksetzungsanforderung freigeben und Schritt 2 wiederholen.
FR_SEND_CR_RESET PACKET() aufrufen, um ein Paket DOWN und UP zur aus fallenden Karte zu senden und die notwendige Umkonfigurierung für die Kanäle auf der Karte durchzuführen.
Die aktuelle Zeit im Karteninformationssatz im Kartenfehlerfeld ablegen.
Bei Rückmeldung eines schlechten Rückmeldekodes vom FR_SEND_CR_RESET_PACKET(), was anzeigt, daß die Karte nicht umkonfiguriert worden ist, diese Kartenrücksetzungsanforderungssätze freigeben und Schritt 2 wiederholen.
SCH_ERR_ANALYSIS() aufrufen, um Fehleranalyse- Prioritätsprüfung für alle Kanäle einzusetzen, die zu der eben rückgesetzten Karte gehören.
6) Den Anforderungssatz Wiederprüfung oder Kartenrück-Setzung freigeben und Schritt 2 wiederholen.
FR SEND CR REST PACKET()

Funktionsbeschreibung

Mit diesem Unterprogramm werden die Befehle/Freigaben DOWN und UP in einem Einzelpaket einer angegebenen Karte gesandt. Je nach Kartenart muß dieses Unterprogramm gegebenenfalls eine Konfigurationstask für diese Karte einleiten oder nicht.

Aufrufschnittstelle

Dieses Unterprogramm wird von FR_PROCESS_MISC_REQ() aus aufgerufen.

PARAMETER:

- Zeiger zur LTID,
- Zeiger zur Kartenrücksetzungsmarkierung (zu aktualisieren).

RÜCKMELDUNG:

- NOERR (wenn alles gut abläuft),
- FAILED (es ist etwas geschehen).

Programmbeschreibung

1) Den Bereich LTID durch Aufrufen von DIST_TO_HWMAP_LTID() zu einer Hardware-Abbildungs- LTID umwandeln. FALSCH als die CODEC_FLAG zum Unterprogramm weitergeben, so daß der logische Steckplatz der Schnittstellenkarte zurückgemeldet wird.
2) FORM_UNIV_CMD_ENABLE() aufrufen, um sowohl eine Freigabe DOWN als auch eine Freigabe UP durch Bezugnahme auf die logische Hardware-Abbildungs.- LTID zu bilden.
3) Ein Paket über GET_TDM_PACKET() beschaffen, um das Kartenrücksetzpaket zur angegebenen Karte zu senden.
5) Wenn die Kartenart der eben rückgesetzten Karte TTI ist, PROCESS_TTI_UP() aufrufen, um den Abschluß der TTI-Konfigurationsherunterladung abzuwarten.
6) Bei Kartenart ADG, ADG_CONTROLLER() zur Initialisierung der Karte aufrufen.
7) Bei Kartenart T1D3, PROCESS_CLI_T1D3() aufrufen, um die T1-Download-Task einzuleiten und die Taktquelle zu aktualisieren. Eine Markierung zu PROCESS_CLI_T1D3() weitergeben, um Druckanweisungen von DOWNLOAD_TI() zu unterdrücken. (DOWNLOAD_T1() sperrt)!
8) Bei einer ROLMphone-Schnittstellenkarte und Rückmeldung von DATA_EXIST durch RPD_EXIST(), DOWN_UP_RPD() aufrufen, um die Datenleitung in Betrieb zu nehmen "up" und/oder Cypress in Betrieb zu nehmen ("up").
9) NOERR rückmelden, wenn von der Konfigurations- Fernladeroutine kein Fehler zurückgemeldet wird. Ansonsten FAILED rückmelden.

FR CR ERR CLEAR()

Funktionsbeschreibung

Mit diesem Unterprogramm werden alle Kartenrücksetzungssätze im Datenfeld FR_CARD_ERROR(), die älter als vier Stunden seit der letzten Kartenrücksetzung sind, gelöscht.

Aufrufschnittstelle

Dieses Unterprogramm wird in Fünf-Minutenabständen durch die Task DOWN MAINT aufgerufen.
PARAMETER: keine.
RÜCKMELDUNGEN: GOOD.

Programmbeschreibung

1) Das gesamte Datenfeld FR_CARD_ERROR() durchlaufen und für jeden nicht freien Datensatz:
2) die aufgezeichnete Zeit mit der Systemzeit vergleichen. Wenn der Unterschied zeigt, daß der Datensatz vier Stunden alt oder älter ist, den Datensatz löschen.

CHANNEL RANGE FOR CARD()

Funktionsbeschreibung

Bei gegebener LTID wird mit diesem Unterprogramm der Ort der Karte in seinem Bereich bestimmt. Es kann dann den von der Karte dargestellten Bereich von Kanalnummern bestimmen.
Beispielsweise wird LTID 00/020209 in einem TTI- Bereich an dieses Unterprogramm weitergegeben. Es zeigt an, daß der TTI-Kanal (9) die dritte Karte im Bereich ist. Es gibt vier Kanäle auf einer TTI-Karte, und der Kanalnummernbereich der dritten Karte in einem TTI- Bereich beträgt daher 8 bis 11.
In diesem Unterprogramm wird angenommen, daß der LTID-Parameter gültig ist.

Aufrufschnittstelle

Dies ist ein Dienstprogramm, das für jedes Unterprogramm bereitgestellt wird, das den logischen Kanalbereich einer Schnittstellenkarte in einem Bereich bestimmen muß. Diese Routine wird in Datei SI_TUIL02.sp definiert.

PARAMETER:

- Zeiger zur LTID
- Zeiger zum unteren Kanalbereich (zu aktualisieren),
Zeiger zum höheren Kanalbereich (zu aktualisieren).

RÜCKMELDUNG:

- NOERR

Programmbeschreibung

1) Kartenart durch Aufrufen von GET_CARD_TYPE() bestimmen.
2) Mit der Kartenart als Index in das Verbindungsdatenverzeichnis CONN_DATA_DIR() die Anzahl von Kanälen pro Karte (C_CHNLS-Feld) bestimmen. (Der Wert sei n).
3) Das Kanalfeld in der LTID-Struktur sei c.
4) Ein RelatiWert x wird durch die Kanalnummer geteilt durch die Anzahl Kanäle erhalten (x: = c/n).
5) Der niedrigere Kanalbereich ist das Produkt von n mal x.
6) Der höhere Kanalbereich ist das Ergebnis von (n * (x=1) - 1).

PHONEMAIL CHANNEL EXISTS()

Funktionsbeschreibung

Bei gegebener LTID eines Fernsprechkanals oder dem Endgerätekonfigurations-(TCN)-Datensatz für diesen Kanal bestimmt diese Prozedur, ob dieser Kanal ein PhoneMail-Kanal ist.

Aufrufschnittstelle

Dieses Unterprogramm ist jedesmal vor Aufrufen von ACTIVATE_RPI_CHANNEL() zur Aktivierung/Deaktivierung oder Inbetriebnahme/Außerbetriebnahme eines ROLMphone- Kanals auf zurufen. Wenn es sich um einen PhoneMail-Kanal handelt, ist ACTIVATE_RPI_CHANNEL() nicht auf zurufen. Dieses Unterprogramm steht in Datei SI_UTIL02.sp.

PARAMETER:

- Zeiger zur LTID,
- Zeiger zum TCN-Satz für diesen Kanal.

RÜCKMELDUNGEN:

- TRUE (1) /? ja, dies ist ein PhoneMail-Kanal
- FALSE (0) /? kein PhoneMail-Kanal

Programmbeschreibung

1) Bei zweitem Parameter gleich NULL, ERP_TERMINAL_CNFG() zum Finden der TECN für die LTID aufrufen. FALSCH rückmelden, wenn ein Fehlerkode rückgemeldet wird.
2) Mit der TCN das Kanalartenfeld TCN_RPS_TYP mit dem Literalwert von CH_VPS vergleichen. Sind sie identisch, WAHR (TRUE) rückmelden.
Wenn nicht, FALSCH (FALSE) rückmelden.

FR RESTART RECOVERY

Funktionsbeschreibung

Mit dieser Prozedur werden die Wiederherstellungshandlungsposten für die Tabelle ausfallender Betriebsmittel in den Fällen von Haupt-Restarts und -Umschaltungen ausgeführt
Bei einem Haupt-Restart oder einer Hauptersatz-Schaltung wird dieses Unterprogramm jeden in der Tabelle aus fallender Betriebsmittel aufgezeichneten Kanal weich wieder außer Betrieb nehmen. Dies geschieht, da die Statusbit (z.B. DND, Nachricht wartet, softDown) einiger Betriebsmittel (z.B. Verbindungsleitungen) bei Restarts ausgelöst werden. Nachdem der Kanal wieder weich außer Betrieb genommen ist, wird der Datensatz markiert, so daß der Kanal des Datensatzes geprüft wird.
Nach einer Ersatzschaltung durchläuft diese Prozedur auch die Tabelle ausfallender Betriebsmittel. Sie löscht die FR_ASSOC_OTHER-Bit in jedem Datensatz, wenn FR_CR_TYPE nicht eine Verbindungsleitungs-Kartenart anzeigt. Wenn das Bit FR_ASSOC_ERRH ebenfalls null ist, wird der mit diesem Datensatz verbundene Kanal wieder in Betrieb genommen.

Aufrufschnittstelle

Dieses Unterprogramm wird von DOWN_MAINT() aus aufgerufen, wenn die Task DOWN_MAINT angestoßen worden ist, und erkennt, daß ein Restart oder eine Ersatzschaltung stattgefunden hat.

PARAMETER:

- Restartart (SYN Restart oder Ersatzschaltung)
RÜCKMELDUNGEN: NOERR

Programmbeschreibung

1) Initialisieren FR_RR_RETEST_DONE auf FALSCH, und FR_RR_NEXT_IDX auf 0.
2) Alle Datensätze in der Tabelle ausfallender Betriebsmittel durchlaufen.
3) Wenn der Datensatz nicht leer ist und eine Ersatzschaltung eintritt und die Übertragungsart nicht eine Verbindungsleitungskartenart ist, dann das Bit FR_ASSOC_OTHER löschen. Wenn FR_ASSOC_ERRH bereits gelöscht ist, FR_MANAGEMENT() aufrufen, um den Kanal wieder in Betrieb zu nehmen, und weiter zu schritt 2.
4) Wenn vom Kanalzustand angezeigt wird, daß der Kanal außer Betrieb ist, DOWN_UP_CH() aufrufen, um den Kanal wieder weich außer Betrieb zu nehmen.
Die Markierung RR_RR_NEEDED auf WAHR (TRUE) setzen, um anzuzeigen, daß dieser Kanal aufgrund von Restart oder Ersatzschaltung neu geprüft werden muß.
5) Von Schritt 2 an wiederholen.

Funktionsbeschreibung

Wenn erkannt wird, daß die Hardwarefehlertabelle verstümmelt ist, wird sie gelöscht. Mit dieser Prozedur wird jeder Datensatz aus fallender Betriebsmittel identifiziert, der mit einem Hardwarefehlereintrag bei Verstümmelung von ERRH verbunden ist. Sie löscht das Bit FR_ASSOC_ERRH. Wenn der Datensatz nach Abtrennung vom ERRH von anderen Quellen von Anforderungen weicher Außerbetriebnahmen befreit wird, wird der im Datensatz implizierte Kanal wieder in Betrieb genommen.

Aufrufschnittstelle

Sie wird durch REINIT_ERRH_AND_ASSOC_SI() aufgerufen, das von INTEG_INIT() aufgerufen wird.
PARAMETER: keine.
RÜCKMELDUNGEN: NOERR

Programmbeschreibung

1) Die Tabelle ausfallender Betriebsmittel durchlaufen.
2) Wenn der Datensatz nicht leer ist, das Feld, das anzeigt, daß ein ERRH-Eintrag mit diesem Datensatz verbunden ist, löschen.
3) Wenn keine weitere Anzeige besteht, daß dieser Datensatz durch andere Quellen weich abgeschaltet wurde, FR_MANAGENENT() aufrufen, um den Kanal wieder in Betrieb zu nehmen. FR_MANAGEMENT() anweisen, nicht zu sperren.
4) Rückmelden NOERR.

LU FR RECORD SLAVE()

Funktionsbeschreibung

Dies ist das abhängige Unterprogramm, das die Datenbank aufallender Betriebsmittel auf der Reserveseite fortschreibt. Wenn bei einer Ersatzschaltung wartende Anforderungen für logische Aktualisierungen auf der vormals aktiven Seite bestehen, werden diese nicht von dieser Prozedur bearbeitet, sondern verworfen.

Aufrufschnittstelle

Sie wird durch PROCESS_RDNT_MSG() aufgerufen, das unter der _IOBUS_IN()-Task läuft.

PARAMETER:

- Operationsart A:
(FR_OPR_UPDATE - protokolliert einen Eintrag in der Tabelle ausfallender Betriebsmittel,
FR_OPR_CLEAR - löscht einen Eintrag von der Tabelle ausfallender Betriebsmittel).
- Zeiger zum Datenpuffer,
- Größe des Datenpuffers.

RÜCKMELDUNGEN:

- NOERR

Programmbeschreibung

1) Wenn dies die aktive Seite ist, nicht fortfahren, sondern NOERR melden. Damit wird die Anforderung einer logischen Aktualisierung abgeworfen.
2) Wenn die Operationsart FR_OPR_UPDATE ist, FR_RECORD_UPDATE () aufrufen mit der Aktualisierungsfunktion zum Eintragen eines Datensatzes in die Tabelle ausfallender Betriebsmittel.
3) Wenn die Betriebsart FR_OPR_CLEAR ist, FR_RECORD_UPDATE_() zum Löschen des angegebenen Datensatzes aufrufen.

PICK FR RECORD()

Funktionsbeschreibung

Diese Prozedur durchläuft die Tabelle ausfallender Betriebsmittel und wählt einen Datensatz ausfallender Betriebsmittel aus, der durch die Task FR_RESTART_RECOVERY() markiert ist. Wenn ein solcher Datensatz besteht, kann er den Auftragssatz initialisieren. Wenn alle "markierten" Datensätze bearbeitet worden sind (keine Einträge mehr), wird ein Fehler zurückgemeldet.

Aufrufschnittstelle

Die Routine wird durch SEARCH_RQ() aufgerufen, das unter der DM-Task läuft. Sie wird vor Auswahl einer internen Prüfung, aber nach jeglichen angesetzten Aufträgen von CLI oder Fehleranalyse aufgerufen.
PARAMETER: keine.

RÜCKMELDUNGEN:

- NOERR
- RTN_NOTEST /? kann keinen gültigen Datensatz finden

Programmbeschreibung

1) FR_RR_NEXT_IDX als nächsten Index zu dem zu verarbeitenden Datensatz ausfallender Betriebsmittel holen.
2) Bei einem Index von NULL (d.h. keine Datensätze mehr zu verarbeiten), initialisiert FR_RR_RETEST_DONE neu auf WAHR, Rückmeldung RTN_NOTEST.
3) Bei einem leeren Datensatz FR_RR_NEXT IDX um 1 erhöhen und von Schritt 1 an wiederholen. (Ein örtlicher Zähler verfolgt, wieviele Male er Schritt 1 wiederholt, wenn der Zählerstand 50 überschreitet, RTN_NOTEST rückmelden.)
4) Prüfen, ob der Kanalzustand im Datensatz Außer Betrieb ist und gleichzeitig das Bit FR_RR_NEEDED gesetzt ist; den Auftragssatz initialisieren.
5) Das Bit FR_RR_NEEDED löschen und FR_RR_NEXT_IDX um 1 erhöhen.
6) Rückmelden NOERR.

PRINT SDOWN RECORD()

Funktionsbeschreibung

Mit diesem Unterprogramm werden alle weich außer Betrieb genommenen Kanäle, die in der Tabelle ausfallender Betriebsmittel aufgezeichnet sind, formattiert und angezeigt.

Aufrufschnittstelle

Wenn ein Benutzer den Befehl "LIST DOWN" eingibt, wird PRINT_MAPS() aufgerufen, das wiederum PRINT_SDOWN_RECORD() aufruft.
PARAMETER: keine.

RÜCKMELDUNGEN:

- NOERR

Programmbeschreibung

1) Dieses Unterprogramm durchläuft das Datenfeld FR_CR_LIST und druckt alle außer Betrieb befindlichen Kanäle (LTIDs) und ihre Kanalarten in der Reihenfolge ihrer Kartenarten.

FR-Datenbank-Zugriffsfunktionen

FR RECORD CREATE()

Funktionsbeschreibung

Mit dieser Prozedur wird ein freier Eintrag in der Tabelle ausfallender Betriebsmittel gefunden und die unterschiedlichen Zähler für organisatorische Zwecke aktualisiert. Sie initialisiert auch die neuen Datensätze.
Wenn die Tabelle voll ist, wird ein Fehler zurückgemeldet. Wenn ein freier Eintrag gefunden wird, gibt sie den Index zurück zur aufrufenden Routine.

Aufrufschnittstelle

Sie wird durch FR_RECORD_UPDATE() aufgerufen.

PARAMETER:

- Zeiger zur LTID für das aus fallende Betriebsmittel,
- Kartenart,
- Zeiger zu einem ganzzahligen Index (zu aktualisieren),
- Anforderungsart (SI oder FEP-Scanner).

RÜCKMELDUNG:

- GOOD (wenn alles gutgeht)
- DB_FULL (wenn kein freier Eintrag mehr verfügbar ist).

Programmbeschreibung

1) Wenn FR_NEXT_FREE_IDX NULL ist, rückmelden DB_FULL.
2) FR_NEXT_FREE_IDX von der Datenbank ausfallender Betriebsmittel als Index zum neuen Eintrag holen.
3) Diesen neuen Eintrag initialisieren.
4) Diesen unter Benutzung des Kartenartparameters als Index in die Liste zu FR_CR_LIST() hinzufügen. Die Index-Querverweise auflösen.
5) FR_NUM_ENTRIES um 1 erhöhen.
6) Wenn der Index des neuen Eintrags größer als FR_MAX_IDX_USED ist, diesen Zähler mit dem Indexwert aktualisieren.
7) Den nächsten verfügbaren leeren Datensatz finden und den Index FR_NEXT_FREE_IDX zuweisen. Wenn kein leerer Datensatz besteht, FR_NEXT_FREE_IDX auf NULL aktualis ieren.
8) NO_ERR rückmelden.

FR RECORD FIND()

Funktionsbeschreibung

Bei gegebener LTID eines aus fallenden Betriebsmittels bestimmt diese Prozedur, ob in der Tabelle ausfallender Betriebsmittel ein Eintrag zu der LTID paßt. Sie kann als Funktion zum Prüfen von Duplikaten benutzt werden.

Aufrufschnittstelle

Sie wird durch FR_RECORD_UPDATE() und FR_RECORD_CLEAR() aufgerufen.

Programmbeschreibung

1) Den Index auf NULL initialisieren.
2) Mit der Kartenart als Index, die erste Indexform FR_CR_LIST(index) holen. Wenn der erste Index NULL ist, NO_MATCH zurückmelden.
3) Jeden zur selben Kartenart gehörenden FR_RECORD unter Benutzung des Parameters LTID als Schlüssel durchlaufen. Wenn eine Übereinstimmung gefunden wird, den Indexzeiger aktualisieren und GUT rückmelden.
4) Alle Datensätze derselben Kartenart sind durchsucht, NO_MATCH rückmelden.

FR RECORD CLEAR()

Funktionsbeschreibung

Bei gegebenem Index des FR-Datensatzes in der FR- Tabelle initialisiert diese Prozedur wieder den Datensatz, damit er wie ein freier Eintrag aussieht. Außerdem erniedrigt sie die Zähler in der Datenbank für organisatorische Zwecke.

Aufrufschnittstelle

Sie wird durch FR_RECORD_UPDATE() aufgerufen.

PARAMETER:

- Index des zu löschenden Datensatzes ausfallender Betriebsmittel,
- Kartenart.

RÜCKMELDUNG:

- GOOD
- NO_MATCH

Programmbeschreibung

1) FR_RECORD_FIND() aufrufen, um den von der Kartenliste zu löschenden Datensatz zu finden.
2) Wenn der Datensatz nicht gefunden wird, NO_MATCH rückmelden.
3) Wenn der Datensatz mit LTID als Schlüssel gefunden wird, FR_NUM_ENTRIES um 1 erniedrigen. Mit dem durch FR_RECORD_FIND() zurückgemeldeten Index, wenn FR_NEXT_FREE_IDX größer als der Index ist, den Index FR_NEXT_FREE_IDX zuweisen.
4) Jeden Index-Kreuzverweis in der Kartenliste entfernen.
5) BLKMV() aufrufen, um den gesamten Datensatz auf NULL zu initialisieren.
6) GOOD zurückmelden.

FR RECORD UPDATE()

Funktionsbeschreibung

Diese Prozedur bedient sich der verschiedenen vorher beschriebenen Zugriffsroutinen zur Durchführung unterschiedlicher Aktualisierungsfunktionen.

Aufrufschnittstelle

Sie wird durch FR_MANAGEMENT() aufgerufen.

PARAMETER:

- Funktionsart: UPDATE, REPLACE, FIND & DELETE.
- Zeiger auf LTID,
- Kartenart,
- Zeiger auf FR_RECORD (zu aktualisieren), (gilt für Funktionen UPDATE, REPLACE & FIND)
- angefordert durch (z.B. SI, FEP), **
- Kanalzustand, **
- Datensatzzustand **
- Übertragsart
- Zeiger auf den Index (wenn gefunden) (wenn nicht gefunden NULL).

RÜCKMELDUNG:

- GOOD (wenn Übereinstimmung gefunden)
- NO_MATCH (wenn nicht gefunden)

PARAMETER:

- Zeiger zur LTID,
- Markierung zur Anzeige, welche Fehlerart **
auf null zu setzen ist: SET_ASSOC_ERRH,
CLEAR_ASSOC_ERRH,
SET_ASSOC_OTHER,
CLEAR_ASSOC_OTHER.
(Mit ** markierte Felder sind nur anwendbar auf UPDATE- und REPLACE-Funktionen. Wenn in keinem Feld eine Änderung erforderlich ist, wird ein NULL-Wert weitergegeben).

RÜCKMELDUNGEN:

- System-Rückmeldekode von den Zugriffsfunktionen.

Programmbeschreibung

1) Wenn die Funktion DELETE ist, FR_RECORD_CLEAR() aufrufen. Zum Aufrufenden zurückkehren.
2) FR_RECORD_FIND() aufrufen, um den durch die LTID- Schlüssel markierten Datensatz zu finden. Es wird eine Indexnummer x zurückgemeldet.
3) Wenn der Datensatz gefunden ist, die Adresse von FR_RECORD(x) holen und den vierten Parameter aktualisieren.
4) Wenn die Funktion FIND ist, zum Aufrufenden zurückkehren.
5) Wenn die Funktion REPLACE ist und der Datensatz nicht gefunden wird, zum Aufrufenden zurückkehren.
6) Wenn die Funktion UPDATE ist und der Datensatz nicht gefunden wird, FR_RECORD_CREATE() aufrufen, um einen neuen Eintrag zu holen. Wenn ein Fehler zurückgemeldet wird, aus diesem Unterprogramm ausspringen.
7) Die Struktur jedes Feldes, das aktualisiert oder ausgetauscht werden muß, analysieren und das Feld mit dem neuen Wert dementsprechend zuweisen.
8) NO_ERR rückmelden.
- GOOD
- NO_MATCH
Die nächsten zwei Zugriffsprogramme werden im Interesse des Projektes Schwellwertalarme bereitgestellt. In beiden Fällen wird die Adresse eines FR_RECORD zum Aufrufenden zurückgemeldet, damit die Information im Datensatz gelesen werden kann.

FR RECORD FIND FIRST()

Funktionsbeschreibung

Bei gegebener Kartenart findet dieses Dienstprogramm den ersten Datensatz aus fallender Betriebsmittel für diese Kartenart. Wenn drei Keine Ausfallenden Kanäle sind, die zu dieser Kartenart gehören, wird ein Rückmeldekode Schlecht zum Aufrufenden zurückgemeldet.

Aufrufschnittstelle

PARAMETER:

- Kartenart,
- Zeiger auf den Indexwert des ersten Datensatzes aus fallender Betriebsmittel für diese Kartenart (zu aktualisieren, wenn gefunden),
- Zeiger auf den ersten Datensatz aus fallender Betriebsmittel für diese Kartenart (zu aktualisieren, wenn gefunden).

RÜCKMELDUNGEN:

- NOERR (gefunden)
- EMPTY (es gibt keinen aus fallenden Kanal für diese Kartenart)

Programmbeschreibung

1) Unter Benutzung der Kartenart als Index in das Kartenlistenfeld FR_CR_LIST(), den ersten Indexwert holen.
2) Bei einem Index NULL, EMPTY zurückmelden.
3) Wenn nicht, dann auf das Datenfeld FR_RECORD() mit dem Index zugreifen.
4) Den Index und die Adresse für den ersten ausfallenden Kanal als den Inhalt laden, auf den die zweiten bzw. dritten Parameter gezeigt haben.

FR RECORD FIND NEXT()

Funktionsbeschreibung

Bei gegebener Adresse für einen FR_RECORD wird die Adresse des nächsten Datensatzes in derselben Kartenliste zum Aufrufenden zurückgemeldet.

Aufrufschnittstelle

PARAMETER:

- Adresse eines Datensatzes FR_INFO,
- Zeiger auf den Index des nächsten Datensatzes (zu aktualisieren),
- Zeiger zur Adresse des nächsten Datensatzes (zu aktualisieren).

RÜCKMELDUNGEN:

- NOERR (gefunden)
- NONE_LEFT (Ende der Kartenliste)
- CANT_COMPLETE

Programmbeschreibung

1) Die Adresse des Datensatzes FR_INFO validieren, um zu sehen, ob der Zeiger innerhalb der Grenze des Datenfeldes FR_RECORD() liegt. Wenn der Zeiger schlecht ist, CANT_COMPLETE rückmelden.
2) Den nächsten Indexwert vom FR_INFO-Datensatz holen und damit das nächste aus fallende Betriebsmittel derselben Kartenart erfassen.
3) Bei einem nächsten Index NULL, es gibt keine Datensätze ausfallender Kanäle für die Kartenart mehr, NONE_LEFT zum Aufrufenden zurückmelden, Kontrolle dem nächsten Indexwert und der Adresse des nächsten Datensatzes über die Parameter zurückgeben.

Schwellwertalarme

EINFÜHRUNG

Die Tasken Schwellwertalarme sind verantwortlich für die Berechnung des Prozentsatzes oder der wirklichen Anzahl von Betriebsmitteln, die ausgefallen sind, und des Prozentsatzes oder der wirklichen Anzahl von Betriebsmitteln, die außer Betrieb sind. Die Anzahl und der Prozentsatz von Betriebsmitteln, die ausgefallen und außer Betrieb sind, werden für zweierlei Zwecke benutzt. Die Ausfallsmenge wird dazu benutzt, das Kundendienstpersonal darauf aufmerksam zu machen, daß eine kritische Menge eines Betriebsmittels defekt ist. Außerdem wird ein Eintrag in der Hardwarefehlertabelle protokolliert, der die ausgefallene Art und den ausgefallenen Prozentsatz des Betriebsmittels anzeigt. Der zweite Zweck ist die Verwaltung der Entfernung von Betriebsmitteln durch den Manager ausfallender Betriebsmittel (FRM). Ein Kanal kann von der Software nicht außer Betrieb genommen werden oder weich außer Betrieb genommen werden, wenn eine kritische Menge dieses Betriebsmittels bereits außer Betrieb ist.

Funktionsübersicht

Schwellwerte ausgefallener Kanäle

In der Hardwarefehlertabelle sind zwei Arten von Einträgen zur Behandlung von Situationen definiert, die bei Ausfall eines kritischen Schwellwertes eines Betriebsmittels entstehen. Wenn ein Betriebsmittel einen Schwellwert überschreitet, wird einer dieser Einträge in der Tabelle protokolliert. Die zwei Kategorien sind Haupt- und Nebenalarme. Sie beruhen auf der Strenge des Schwellwertes.
Die Anzahl ausgefallener Betriebsmittel wird durch Auslesen von Datensätzen in der Tabelle ausfallender Betriebsmittel (FRT) berechnet. Die FRT enthält nur die ausgefallenen Kanäle. Es ist von Bedeutung, daß, wenn ein Techniker physisch eine Karte außer Betrieb nimmt, dies nicht in dieser Tabelle erscheint. Ein Kanal wird nur dann als ausgefallen erachtet, wenn er in dieser Tabelle erscheint. So zählen hart oder vorsichtshalber außer Betrieb genommene Betriebsmittel nicht für die Schwellwerte ausgefallener Kanäle.

Außerbetrieb-Schwellwert

Ein Teil der Verantwortlichkeit des Managers ausfallender Betriebsmittel (FRM) ist es, Kanäle in und außer Betrieb zu nehmen. Der FRM nimmt keinen Kanal außer Betrieb, wenn der Außer-Betrieb-Schwellwert überschritten worden ist. Zu dieser Regel gibt es eine Ausnahme. Wenn der Fehler von einem Scanner gemeldet wird, wird der Kanal ungeachtet des Außer-Betrieb-Schwellwertes außer Betrieb (OOS - out of Service) genommen. FRM wartet, bis die Schwellwertalarme melden, ob ein Kanal außer Betrieb genommen werden kann oder nicht. Ein anderer Grund ist, daß in manchen Fällen ein Scanner einen Kanal zwangsweise außer Betrieb nehmen muß, um zu vermeiden, daß das System mit Fehlern überflutet wird. Da es notwendig sein kann, daß Schwellwertalarme gesperrt werden und ein Scanner keine Sperrungen tolerieren kann, wird von Schwellwertalarmen stets zugelassen, daß ein Kanal durch einen Scannerausfall außer Betrieb genommen wird.
Die Anzahl von OOS-Kanälen wird durch Beobachtung der FRT bestimmt. Jeder Datensatz in dieser Tabelle enthält ein Feld, das anzeigt, ob der Kanal in oder außer Betrieb ist. Ein Kanal wird als OOS erachtet, wenn er in der Tabelle erscheint und dieses Feld auf OOS gesetzt ist. Es ist zu bemerken, daß harte oder vorsichtshalber außer Betrieb genommene Betriebsmittel nicht für den OOS- Schwellwert zählen, da sie nicht in der FRT protokolliert sind.

Knoten-Schwellwerte

Einige Betriebsmittel werden knotenweise überprüft, während andere vom System überwacht werden. Angenommen beispielsweise, eine Vermittlung besitzt drei Knoten und jeder Knoten hat sechzehn Drehwählerregisterkanäle. Drehwählerregister werden knotenweise überprüft. Kanal 9, 5 und 2 sind in Knoten 1, 2 bzw. 3 ausgefallen. Im Knoten 1 wird ein Hauptalarm (56%) protokolliert, im Knoten 2 ein Nebenalarm (31%) und im Knoten 3 (12%) kein Alarm protokolliert. Die verschiedenen Betriebsmittel, die knotenweise überprüft werden, werden untenstehend mit ihren entsprechenden Schwellwerten aufgeführt. KNOTEN-BETRIEBSMITTEL BETRIEBSMITTEL HAUPT NEBEN Drehwählerregister Drehgeber MFV-Register Konferenzbrücken Verbesserte Diagnosekarten Tongeber Datenvorrechner Leitungen (Teilnehmeranschlußschnittstellen, Telefone, usw.) Ursprungs-Datenvorrichtungen ANMERKUNG: A, B, C und D sind konfigurierbare Systemparameter. Die Bereiche von A, B, C und D und Vorgabewerte sind: BEREICH VORGABE
Leitungen und Ursprungsdaten-Schaltanschlüsse sind etwas ungewöhnlich. Ihre Haupt- und Nebenschwellwerte sind konfigurierbar, und ihre OOS-Schwellwerte sind der Vorgabewert ihrer Haupt-Schwellwerte.
Es ist darauf hinzuweisen, daß die OOS-Schwellwerte für ADCs und DFEs 100% betragen. Damit kann das System alle dieser Betriebsmittel außer Dienst nehmen. Wir möchten nicht, daß durch eine schlechte ADC-Karte ein anderes Stück Hardware als fehlerhaft erklärt wird.

Globale Schwellwerte

Globale Betriebsmittel werden etwas anders überwacht. Als erstes wird die Menge ausgefallener oder außer Betrieb befindlicher Betriebsmittel im Gesamtsystem mit der Gesamtmenge im gesamten System verglichen, um zu bestimmen, ob ein Schwellwert überschritten worden ist.
Ein anderer Unterschied besteht darin, daß globale Betriebsmittel nur nach Daten- oder Verbindungsleitungsgruppe überprüft werden. Beispielsweise wird die Anzahl aus fallender Verbindungsleitungen in der Verbindungsleitungsgruppe CO1 im ganzen System nur mit der Gesamtzahl Verbindungsleitungen in Verbindungs leitungsgruppe C01 und nicht der Gesamtzahl aller Verbindungsleitungen im System verglichen. Schließlich wird, wenn ein Haupt- oder Nebenschwellwert überschritten worden ist, ein Fehler in allen Knoten anstelle nur in einem Knoten protokolliert.
Angenommen beispielsweise, in einem Dreiknoten-System sind die Vorgabewerte für die Haupt- und Nebenalarmschwellwerte gewählt worden. In jedem Knoten gibt es in der Verbindungsleitungsgruppe C01 zehn Verbindungsleitungen, also systemweit insgesamt 30 Verbindungsleitungen in der Verbindungsleitungsgruppe C01. Vier, drei und neun Verbindungsleitungen in der Verbindungsleitungsgruppe C01 sind in Knoten 1, 2 bzw. 3 ausgefallen. So sind insgesamt sechzehn Verbindungsleitungen in der Verbindungsleitungsgruppe C01, (53%) ausgefallen. In allen drei Knoten wird ein Hauptalarm protokolliert.
Untenstehend werden die global überprüften verschiedenen Betriebsmittel mit ihren entsprechenden Schwellwerten aufgeführt. Globale Betriebsmittel BETRIEBSMITTEL HAUPTALARM NEBENALARM VERBINDUNGSLEITUNGEN ANTWORTENDE DATENANSCHLÜSSE ANMERKUNG: M, N und P sind nach Verbindungsleitungsgruppe konfigurierbar. Ihre gültigen Bereiche und Vorgabewerte sind: BEREICH VORGABEWERT ANMERKUNG: X, Y und Z sind nach Datengruppe konfigurierbar. Ihre gültigen Bereiche und Vorgabewerte sind: BEREICH VORGABEWERT
Es ist zu bemerken, daß die Vorgabewerte für die Hauptschwellwerte und die OOS-Schwellwerte die gleichen sind. Wenn die konfigurierbaren Parameter geändert werden, werden die vorher in der Hardwarefehlertabelle protokallierten Einträge nicht verändert.

Fehleranzeigen

Haupt-Schwellwertalarme besitzen eine Priorität von 150, und Nebenschwellwertalarme besitzen eine Priorität von 180. In Figur 74 wird eine Hardwarefehlertabellenanzeige für das vorige Drehwählerregisterbeispiel dargestellt. Es ist von wesentlicher Bedeutung, daß die angezeigten Informationen in einer natürlichen Sprache dargestellt werden, die leicht von einem Bediener zu deuten ist. Figur 75 ist eine Hardwarefehlertabellenanzeige für das vorige CO-Verbindungsleitungsbeispiel. Die letzte Nachricht in jeder Anzeige ist eine Zusammenfassung der Informationen für das bestimmte Betriebsmittel.
Andere Systemintegritäts-(SI-)Fehler erfordern, daß ein Betriebsmittel eine Prüfung X aufeinanderfolgende Male besteht (wobei X von dem Betriebsmittel abhängig ist), ehe sein Zustand auf BESTANDEN geändert wird. Der Zustand des Haupt- oder Nebenalarmfehlers wird jedoch sofort, nachdem es das erste Mal bestanden hat (d.h. X = 1) auf BESTANDEN geändert. Um zu bestehen, muß die Menge ausgefallener Betriebsmittel unterhalb des Schwellwertes für dieses bestimmte Betriebsmittel liegen.

Anstehende weiche Außerbetriebnahme (PSD)

Wenn ein Kanal vom FRM nicht weich außer Betrieb genommen werden kann, da er gegenwärtig belegt ist, setzt er dessen Zustand auf Anstehende Weiche Außerbetriebnahme. Von den Schwellwertalarmen werden alle Kanäle mit diesem Zustand als außer Betrieb erachtet.

Entwurfsübersicht

THRESHOLD_ALARMS_CHECK() wird vom FRM aufgerufen, wenn ein Eintrag in der Tabelle aus fallender Betriebsmittel hinzuzufügen, zu löschen oder zu aktualisieren ist. In Figur 76 wird ein Flußdiagramm der Task gezeigt. Die Steuerung springt mit einer Prüfung ein, ob der OOS- Schwellwert zu überprüfen ist und FRM eine Sperrung tolerieren kann, wie in Entscheidungsblock 9000 angezeigt. Im Funktionsblock 9001 wird CHECK_OOSTHRESH() aufgerufen. Von CHECK_OOSTHRESH() werden Daten zurückgemeldet, die anzeigen, ob der Kanal außer Dienst genommen werden kann, und es erkennt, ob der Kanal bereits gesperrt ist, wie im Funktionsblock 9002 angezeigt. Danach wird _CHECK_TRHESHOLD_ALARMS(), wie im Funktionsblock 9004 dargestellt, aufgerufen. Wenn der FRM jedoch keine Sperrung tolerieren kann, werden die Rückdaten so gesetzt, daß sie anzeigen, daß der Kanal außer Betrieb genommen werden kann, aber daß er nicht gesperrt worden ist, wie im Funktionsblock 9005 angezeigt, und Steuerung wird an Funktionsblock 9003 übergeben, um _CHECK_THRESHOLD_ALARMS() auf zurufen und letztlich zur aufrufenden Task zurückzukehren, wie im Funktionsblock 9004 angezeigt.
Eine weitere Task wird dazu benutzt, um aufgrund seines OOS-Schwellwertes zu bestimmen, ob ein Kanal außer Betrieb genommen werden kann. Diese Task ist CHECK_OOSTRHESH(), und ihre Logik ist schematisch in dem in Figur 77 dargestellten Flußdiagramm dargestellt. Im Entscheidungsblock 9010 springt die Steuerung ein und bestimmt mit einer Sofortprüfung, ob das Betriebsmittel global zu überprüfen ist oder nicht. Wenn ja, dann benutzt der Funktionsblock 9011 eine Kommunikationsexekutive (COMEX) mit der Fähigkeit, mit den anderen Knoten zu verkehren. Im Funktionsblock 9011 wird COMEX über _SI_COMMAND_SERVER() aufgerufen, Funktionsblock 9012. _SI_COMMAND_SERVER() steht im abgesetzten Knoten. Er entschlüsselt die ankommenden Informationen und unternimmt auf Grundlage der Nachrichtenart die entsprechende Handlung. In diesem Fall ruft er Funktionsblöcke 9013 und 9015 auf, um die Gesamtmenge von Kanälen für eine Kartenart bzw. die Anzahl von außer Betrieb befindlichen Kanälen für diese Kartenart zu bestimmen. Diese Zahlen werden mittels COMEX zurück zum anfordernden Knoten gesandt. Die Ergebnisse werden zusammenaddiert und zu COMPARE_OOS_THRESH() weitergegeben, Funktionsblock 9016.
Wenn dies ein Knotenbetriebsmittel ist, ruft Funktionsblock 9010 Funktionsblöcke 9018 und 9019 auf. Diese bestimmen die Gesamt-Kanalzahl für eine Kartenart und die Anzahl von außer Betrieb befindlichen Kanälen für eine Kartenart im Ortsknoten. Die Steuerung wird dann COMPARE_OOS_THRESH() übergeben, Funktionsblock 9016. Mit COMPARE_OOS_THRESH() wird bestimmt, ob der OOS-Schwellwert bei Außerbetriebnahme des Kanals überschritten wird. Diese Schlußfolgerung wird zum FRM zurückgemeldet.
Die Task _CHECK_THRESHOLD_ALARMS() ist im wesentlichen mit der Überprüfung der Schwellwerte nach Aktualisierung der Tabelle ausfallender Betriebsmittel beschäftigt. Im Flußdiagramm der Figur 78 wird die Logik für diese Task gezeigt. Die Steuerung springt am Funktionsblock 9020 ein, der die nächste zu aktualisierende Kartenart bestimmt. Danach wird die Task CHECK_THRESHOLDS() bei 9022 aufgerufen, um jeden der Schwellwerte für die bestimmte Kartenart zu überprüfen.
Am Funktionsblock 9024 wird TA_UPDATE_FR_TABLE aufgerufen, um die Tabelle aus fallender Betriebsmittel (FRT) zu aktualisieren. Er bestimmt, ob irgendwelche Einträge in der FRT zu aktualisieren oder zu löschen sind. Wenn ja, dann muß die Reserve-CPU informiert werden. Mit LOGICAL_UPDATE (), das am Funktionsblock 9026 aufgerufen wird, wird ein Mechanismus für die Aktualisierung von Datenbanken in der Reserve-CPU bereitgestellt. Danach wird vom Funktionsblock 9028 bestimmt, ob weitere Kartenarten zu aktualisieren sind. Wenn ja, dann kehrt die Steuerung zum Funktionsblock 9020 zurück. Damit wird fortgefahren, bis keine weiteren Aktualisierungen erfordende Kartenarten im FRT bestehen. Die Steuerung wird dann dem Funktionsblock 9029 übergeben. _CHECK_THRESHOLD_ALARMS() schließt sich selbst bis zum weiteren Aufruf ab.
Vom FRM werden zwei Datenstrukturen unterhalten, die von Schwellwertalarmen benutzt werden müssen. Die erste FR_CR_LIST() ist ein auf Kartenart basierendes Datenfeld. In diesem Datenfeld befindet sich ein Index zum ersten Datensatz ausfallender Betriebsmittel der Übertragsart, der Anzahl Datensätze für die Kartenart und der Anzahl Datensätze für diese Kartenart, die durch Schwellwertalarme zu aktualisieren sind (FR_UPDATE_COUNT).
Die zweite Datenstruktur ist die eigentliche FRT. Diese Tabelle enthält einen Datensatz für jeden ausfallenden Kanal im System. Eines der Felder in jedem Datensatz ist das Statusfeld. Es kann einen von drei möglichen Werten besitzen: TA_UPDATE_DONE (Schwellwertalarm ist für diesen Datensatz beendet). TA_UPDATE_DONE (dieser Kanal wird zugefügt und Schwellwertalarme muß ablaufen), oder TA_UPDATE_CLEAR (dieser Kanal wird gelöscht und Schwellwertalarme muß ablaufen).
Die Prozedur TA_UPDATE_FR_TABLE() ist für die Unterhaltungen des Statusfeldes im Datensatz ausfallender Betriebsmittel und FR_UPDATE_COUNT in FR_CR_LIST_() verantwortlich (aus der Sicht von Schwellwertalarmen). Sie hat vier Hauptzwecke. Der erste besteht im Löschen von allen Einträgen, die nicht mehr gültig sind (ihr Zustand ist TA_UPDATE_CLEAR)
Sie ist auch für die Aktualisierung des Statusfeldes im Datensatz aus fallender Betriebsmittel auf TA_UPDATE_DONE verantwortlich, nachdem Schwellwertalarme fertig ist.
Damit wird auch FR_UPDATE_COUNT mit jeder Veränderung das Statusfeldes erniedrigt. FR_CHANGE_CHANNEL_STATE() ist für die Erhöhung der Zählung vor Aufruf von THRESHOLD_ALARMS_CHECK() verantwortlich. Damit wird abschließend die Reserveseite aktualisiert, wenn eines der obigen Ereignisse stattgefunden hat.

Falsche Kartenarten

Bei einer integrierten Sprach- und Datenkarte, wo Sprache und Daten im selben Kanal anstehen, muß Schwellwertalarme den Unterschied zwischen Sprach- und Datenausfällen kennen. Bei Eintreten eines Sprachausfalls wird dieser unter der Kartenart CR_RPVOICE in die FRT eingesetzt. Bei einem Datenausfall wird dieser unter der Kartenart CR_RPDATA in die FRT eingesetzt.

Kartengruppen

Jede auf Schwellwerte zu überwachende Kartenart wird einer Kartengruppe zugewiesen. Jede Kartenart gemeinsamer Einrichtungen besitzt ihre eigene Kartengruppe. Verbindungsleitungskartenarten werden der Verbindungsleitungskartengruppe zugewiesen. Gleichermaßen werden Daten- und Leitungskartenarten der Datenkartengruppe bzw. der Leitungskartengruppe zugewiesen.

PROGRAMMAUSLEGUNG

ÜBERPRÜFUNG SCHWELLWERTALARME

Funktionsbeschreibung

Mit dieser Prozedur wird CHECK_OOSTHRESH() aufgerufen, wenn vom FRM Sperrungen toleriert werden können, und danach _CHECK THRESHOLD ALARMS() aufgerufen.

Aufrufschnittstelle

Dieses Unterprogramm wird durch FR_CHANGE_CHANNEL_STATE() aufgerufen und besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer (sofern vorhanden)
OOS_FLAG - den OOS-Schwellwert prüfen
CHANNEL_STATE - aktueller Zustand des Kanals (in Betrieb, außer Betrieb, oder Anstehend Weiche Außerbetriebnahme)
CAN_TAKE_OOS - Kanal kann außer Betrieb genommen werden (Zeiger zu Rückdaten)
Wenn Rückmeldungen, dann entweder GOOD oder FAILED.

Programmbeschreibung

1) Wenn die Karte nicht auf Schwellwertalarme zu überwachen ist (d.h. diese Karte einer Kartengruppe zugewiesen ist), ist zur aufrufenden Prozedur zurückzumelden, daß der Kanal nicht außer Betrieb genommen werden kann. Dies sollte nie geschehen.
2) Wenn die Markierung OOS_FLAG anzeigt, daß der OOS- Schwellwert zu überprüfen ist, CHECK_OOSTHRESH() aufrufen. Mit dieser Routine wird bestimmt, ob der Kanal außer Betrieb genommen werden kann oder nicht.
3) Ansonsten die Rückdaten setzen, um anzuzeigen, daß der Kanal außer Betrieb genommen werden kann.
4) Überprüfen, ob _CHECK_THESHOLD_ALARMS() gegenwärtig hervorgebracht worden ist (d.h. PTCB_THESHOLD nicht gleich NULL ist). Wenn nicht, und wenn dies der aktive Prozessor ist, SPAWN_TCB(), PUT_DISPQ() und SHIELD_TCB() aufrufen, um _CHECK_THESHOLD ALARMS() hervorzubringen, zu planen bzw. zu schützen. Diese Task überprüft die Schwellwerte ausgefallener Kanäle und ermöglicht es gleichzeitig dem FRM, ohne Sperren fortzufahren, wenn dies nicht zulässig ist.
5) Zurück zu FR_CHANGE_CHANNEL_STATE().
CHECK OOSTHRESH()

Funktionsbeschreibung

Mit diesem Unterprogramm wird bestimmt, ob der OOS-Schwellwert für eine gegebene Kartenart/Verbindungsleitungs- oder Datengruppe überschritten worden ist.

Aufrufschnittstelle

Dieses Unterprogramm wird durch THRESHOLD_ALARMS_CHECK() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Ordnungsnummer für Verbindungsleitungs- oder Datengruppe
CHANNEL_STATE - der aktuelle Zustand des Kanals (IS, OOS oder PSD)
CAN_TAKE_OOS - ob der Kanal außer Betrieb (OOS) genommen werden kann (Rückdaten)
Es meldet entweder GOOD oder FAILED zurück.

Programmbeschreibung

1) GET_CGRP_PERCENT() aufrufen, um zu bestimmen, ob diese Kartengruppe nach eigentlicher Zahl oder Prozentsatz zu überwachen ist.
2) GET_CGRP_GLOBORNOD() aufrufen, um zu bestimmen, ob diese Kartengruppe nach Knoten oder nach System zu überwachen ist.
3) Wenn das Betriebsmittel global zu überwachen ist, REMOTE_CMMD() mit dem Parameter von -REMOTE_TOT_FAIL_OOS aufrufen (zur Bestimmung der Gesamtzahl von Kanälen und der Anzahl von OOS- Kanälen für dieses Betriebsmittel).
4) Ansonsten FIND_NUM_OOS_CH() aufrufen, um die Anzahl von OOS-Kanälen zu bestimmen. Wenn der Kanal gegenwärtig in Betrieb ist, denselben zur Anzahl von OOS- Kanälen hinzufügen.
5) Wenn der Kanal nach Prozentsatz zu überwachen ist, FIND_NUM_CH() aufrufen, um die Gesamtzahl von Kanälen zu bestimmen. Den Prozentsatz berechnen.
6) GET_MJ_MN_OOS_THRESH() aufrufen, um den OOS-Schwellwert zu bestimmen.
7) Wenn der Prozentsatz oder die eigentliche ausgefallene Anzahl oberhalb des OOS-Schwellwertes liegen, *CAN_TAKE_OOS auf FALSCH setzen.
8) (GOOD) rückmelden.

FIND NUM CH()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Gesamtzahl von Kanälen für eine gegebene Kartenart, Verbindungsleitungs- oder Datengruppe bestimmt.

Aufrufschnittstelle

Dieses Unterprogramm wird durch _CHECK_THRESHOLD_ALARMS() und FIND_REMOTE_TOT_FAIL_OOS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Ordnungszahl für Verbindungsleitungsgruppe oder Datengruppe
RET_DATA - Zeiger auf Rückdaten (Gesamtzahl von Kanälen)
Mit diesem Unterprogramm wird entweder GOOD oder FAILED rückgemeldet.

Programmbeschreibung

1) GET_CGRP() aufrufen, um die Kartengruppe zu bestimmen, zu der diese Kartenart gehört.
2) Bei einer Verbindungsleitung, *RET_DATA auf TPTR- > INFO(GRP).ALL_TKS setzen.
3) Bei einem antwortenden Datenschaltanschluß, DX_NUM_DATA_LINES() aufrufen, um die Leitungszahl in der Gruppe zu bestimmen.
4) Ansonsten FIND_NUM_CH_FOR_CARTY() aufrufen.
5) (GOOD) rückmelden.

DX NUM DATA LINES()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Leitungszahl in einer Datengruppe im Gesamtsystem gefunden.

Aufrufschnittstelle

Dieses Unterprogramm wird durch FIND_NUM_CH() aufgerufen. Es besitzt folgende Parameter:
GRP - Ordnungsnummer der Datengruppe
RET_DATA - Zeiger auf die Anzahl von Datenleitungen

Programmbeschreibung

1) DX_SEARCH_GRPSTATUS() aufrufen, um einen Zeiger zur Gruppenelement-Datenbank abzurufen.
2) Weiter bei einem guten Rückmeldewert. Ansonsten (FAILED) rückmelden.
3) Innerhalb der Gruppenelement-Datenbank DX_GRPMEM_DB befindet sich ein Zeiger (GM_MEMBER_LIST) auf verknüpfte Blöcke von acht Datenleitungsnummern, die zur Datengruppe gehören.
4) Innerhalb von GM_MEMBER_LIST.GM_DLUNB(I) überprüfen, wo I anfänglich auf null gesetzt ist. Wenn nicht gleich NULL, NUM_LINES um 1 erhöhen.
5) I erhöhen.
6) Wenn I größer als NUN_SUBGRPMEMS-1 ist, Zeiger zum nächsten Block von Datenleitungsnummern abrufen. Ansonsten zu Schritt 4) zurückschleifen.
7) Wenn der Zeiger zum nächsten Block der Datenleitungsnummern nicht gleich NULL ist, mit dem neuen Nummernblock zu Schritt 4) zurückschleifen.
8) Ansonsten soll der Zeiger NULL sein. *RET_DATA auf NUM_LINES setzen.
9) (GOOD) rückmelden.

FIND NUM FAIL OOS CH()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Anzahl ausfallender und außer Betrieb befindlicher Kanäle für eine gegebene Kartenart, Verbindungsleitungs- oder Datengruppe gefunden.

Aufrufschnittstelle

Dieses Unterprogramm wird durch _CHECK_THRESHOLD_ALARMS(), CHECK_THESHOLDS() und FIND_REMOTE_TOT_FAIL_OOS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
NUM_FAIL - Zeiger zur Anzahl ausfallender Kanäle (Rückdaten)
NUM_OOS - Zeiger zur Anzahl von OOS-Kanälen (Rückdaten)
Rückmeldung entweder GOOD oder FAILED.

Programmbeschreibung

1) FIND_FIRST_CRED_IN_GRP() aufrufen.
2) FR_RECORD_FIND_FIRST() aufrufen, um den ersten Eintrag in der FRT für diese Kartenart zu finden.
3) FRM_TA_IS_CH_FAIL_OOS() aufrufen, um zu bestimmen, ob dieser Kanal für die ausfallenden und außer Betrieb-Gesamtzahlen zu zählen ist.
4) Bei ausfallendem Kanal, *NUM_FAIL erhöhen.
5) Wenn der Kanal außer Betrieb oder PSD ist, *NUM_OOS erhöhen.
6) FR_RECORD_FIND_NEXT() aufrufen, um den nächsten Datensatz in der FR-Tabelle für diese Kartenart zu holen. Bei Vorhandensein eines anderen Datensatzes zu schritt 3) schleifen.
7) FIND_NEXT_CRD_IN_GRP() aufrufen. Bei Vorhandensein einer anderen Karte in der Gruppe, TIME_SLlCE() aufrufen und zu Schritt 2) schleifen.
8) Zurück zur aufrufenden Prozedur.

GET MJ MN OOS THRESH()

Funktionsbeschreibung

Mit diesem Unterprogramm werden die Haupt-, Neben- und OOS-Schwellwerte für eine gegebene Kartenart/Verbindungsleitungs- oder Datengruppe rückgemeldet.

Aufrufschnittstelle

Dieses Unterprogramm wird durch CHECK_OOSTHRESH() und CHECK_THESHOLDS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
PMJ_THRESH - Hauptschwellwert (Zeiger zu Rückdaten)
PMN_THRESH - Nebenschwellwert (Zeiger zu Rückdaten)
POOS_THRESH - OOS-Schwellwert (Zeiger zu Rückdaten)
Mit diesem Unterprogramm wird FAILED, CANT_COMPLETE oder GOOD rückgemeldet.

Programmbeschreibung

1) GET_CGRP() aufrufen, um die Kartengruppe für diese Kartenart zu bestimmen.
2) Bei einer Verbindungsleitung, GET_TRGP_RCD() aufrufen, um den Datensatz der Verbindungsleitungsgruppe zu holen. Die Schwellwerte für diese Vebindungsleitungsgruppe setzen.
3) Bei einem antwortenden Datenanschluß, DX_SEARCH_GRPSTATUS() aufrufen, um einen Zeiger auf die Gruppenstatus-Datenbank zu holen. Die Schwellwerte für diese Datengruppe setzen.
4) Bei einem Ursprungs-Datenanschluß, GET_CGRP_THRESHS() aufrufen, um den OOS-Schwellwert zu holen. Die Haupt- und Neben-Schwellwerte auf die Werte in der Konfiguration setzen.
5) Bei einer Leitung GET_CGRP_THRESHS() aufrufen, um den OOS-Schwellwert zu holen. Die Haupt- und Nebenschwellwerte auf die Werte in der Konfiguration setzen.
6) Ansonsten GET_CGRP_THRESHS() aufrufen, um alle Schwellwerte zu holen.
7) Zurück zur aufrufenden Prozedur.

FIND REMOTE TOT FAIL OOS()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Gesamtzahl von Kanälen, die Anzahl von ausgefallenen Kanälen und die Anzahl von außer Betrieb befindlichen Kanälen für eine gegebene Kartenart, Verbindungsleitungsgruppe oder Datengruppe bei Anforderung von einem anderen Knoten gefunden. Es übermittelt das Ergebnis zum anfordernden Knoten.

Aufrufschnittstelle

Dieses Untergrogramm wird durch _SI_COMMAND_SERVER() aufgerufen. Es besitzt folgende Parameter:
PORT - COMEX-Anschluß, zu dem Daten zurückzusenden sind
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
Seine Zurückmeldung zur aufrufenden Prozedur ist GOOD.

Programmbeschreibung

1) FIND_NUM_CH() zur Bestimmung der Gesamtzahl von Kanälen aufrufen.
2) FIND_NUM_FAIL_OOS_CH() zur Bestimmung der Anzahl ausfallender und außer Betrieb befindlicher Kanäle aufrufen.
3) SEND_MSG() aufrufen, um das Ergebnis zum anfordernden Knoten zu ubermitteln.
4) (GOOD) rückmelden.

CHECK THRESHOLD ALARMS()

Funktionsbeschreibung

Diese Task wird zur Überwachung der Schwellwertalarme benutzt, wenn die Tabelle ausfallender Betriebsmittel geändert wird, oder nach einem Restart. Damit wird sichergestellt, daß sich in der FRT keine Ungereimtheiten befinden.

Aufrufschnittstelle

Diese Task wird entweder von THRESHOLD_ALARMS_CHECK() oder INTEG_INIT() aus aufgerufen. Sie endet mit ihrem Abschluß.
Diese Task benutzt einen privaten Pufferbereich. Der Ablauf ist mit Priorität 6 geplant.

Programmbeschreibung

1) FRM_FIND_TA_CRD_TO_UPDATE() aufrufen, umdienächste Kartenart zu bestimmen, die durch Schwellwertalarme zu aktualisieren ist. Wenn keine andere zu aktualisierende Kartenart gefunden wird, zu Schritt 8) weiterspringen
2) Ansonsten CHECK_THRESHOLDS() aufrufen, um zu bestimmen, ob Haupt- oder Nebenschwellwerte überschritten worden sind.
3) TA_UPDATE_FR_TABLE() zur Aktualisierung der Tabelle aus fallender Betriebsmittel aufrufen.
4) TIME_SLICE() aufrufen, um zeitweilig Pause zu machen.
5) GET_CGRP() aufrufen, um zu bestimmen, ob dies ein Leitungskanal ist. Wenn ja, CHECK_THRESHOLD() und TA_UPDATE_FR_TABLE() nochmals aufrufen, nur diesmal für eine Datenleitung. Es ist leider nicht immer möglich, die beiden zu unterscheiden, weshalb diese Sonderprüfung durchgeführt werden muß.
6) Nochmals TIME_SLICE() aufrufen, um sicherzustellen, daß der Prozessor nicht unnötig belegt wird.
7) Zu Schritt 1) zurückschleifen.
8) Bei Erreichen des Schrittes sind bei dem letzten Durchlaufen der Tabelle aus fallender Betriebsmittel keine Änderungen durchgeführt worden. Der gesamte Inhalt sollte aktuell sein. PTCB_THRESHOLD auf NULL Setzen und EXIT() zum Abschalten der Task aufrufen.

CHECK THRESHOLDS()

Funktionsbeschreibung

Diese Prozedur wird dazu benutzt, zu überprüfen, ob der Betrag eines ausgefallenen Betriebsmittels oberhalb eines gewissen Schwellwertes liegt. Bei Überschreiten entweder eines Haupt- oder Nebenschwellwertes wird der entsprechende Fehler in der Hardwarefehlertabelle protokolliert.

Aufrufschnittstelle

Dieses Unterprogramm wird durch _CHECK_THESHOLD_ALARMS() aufgerufen und besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
Die Rückmeldung ist entweder GOOD oder FAILED

Programmbeschreibung

1) GET_CGRP_PERCENT() aufrufen, um zu bestimmen, ob diese Karte nach eigentlicher Anzahl oder Prozentsatz zu überwachen ist.
2) GET_CGRP_GLOBORNOD() aufrufen, um zu bestimmen, ob diese Karte nach Knoten oder nach System zu überwachen ist.
3) Wenn das Betriebsmittel global zu überwachen ist, REMOTE_CMMD() mit einem Parameter von REMOTE_TOT_FAIL_OOS aufrufen (zur Bestimmung der Gesamtzahl von Kanälen und der Anzahl von ausgefallenen Kanälen für dieses Betriebsmittel).
4) Ansonsten FIND_NUM_FAIL_OOS_CH() zur Bestimmung der für diese Kartenart ausgefallenen Kanäle aufrufen.
5) Bei Überwachung der Kartenart nach Prozentsatz, FIND_NUM_CH() zur Bestimmung der für diese Kartenart ausgefallenen Anzahl von Kanälen aufrufen.
6) Gegebenenfalls den Prozentsatz berechnen.
7) GET_MJ_MN_OOS_THRESH() zur Bestimmung der Haupt- und Nebenschwellwerte t=für diese Kartenart/Verbindungsleitungs- oder Datengruppe aufrufen.
8) Bestimmen, ob einer dieser Schwellwerte überschritten worden ist.
9) SI_REPORT_THRESH_ALARMS() aufrufen, um alle in der Hardwarefehlertabelle anwendbaren Schwellwertalarme zu protokollieren und/oder löschen.
10) Wenn- dieses Betriebsmittel global zu überwachen ist, REMOTE_CMMD() mit dem Parameter REMOTE_LOGERR zur Aktualisierung der anderen Knoten aufrufen.
11) NEXT_TASK() aufrufen, um eine Pause zu machen.
12) Zur aufrufenden Prozedur zurückkehren.

SI REPORT THRESH ALARMS()

Funktionsbeschreibung

Dieses Unterprogramm ist für die Protokollierung und das Löschen von Schwellwertalarmeinträgen in der Hardwarefehlertabelle verantwortlich.

Aufrufschnittstelle

Dieses Unterprogramm wird durch CHECK_THRESHOLDS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
MJ - Hauptalarm-Status
MN - Nebenalarm-Status
AMT - Betrag des ausgefallenen Betriebsmittels

Programmbeschreibung

1) GET_CGRP() aufrufen, um die Kartengruppe für diese Kartenart abzurufen.
2) Bei einem Leitungskanal die Kartenart für den Fehlerbereich auf CR_LINE setzen.
3) Bei einem Datenanschluß die Kartenart auf den Fehlerbereich CR_DATA setzen.
4) SI_REPORT_STATUS() zweimal aufrufen. Einmal für den Hauptalarmstatus und einmal für den Nebenalarmstatus.
5) Wenn der Hauptalarmstatus FAILED ist, SI_REPORT_STATUS mit einem Ergebnis Bestanden für den Nebenalarm aufrufen, um ihn von der Hardwarefehlertabelle zu löschen.
6) (GOOD) rückmelden.

TA UPDATE FR TABLE()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Tabelle ausfallender Betriebsmittel (FRT) für eine gegebene Kartenart/Verbindungsleitungs- oder Datengruppe fortgeschrieben.

Aufrufschnittstelle

Dieses Unterprogramm wird durch _CHECK THRESHOLD_ALARMS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
Die Rückmeldung ist GOOD.

Programmbeschreibung

1) FIND_FIRST_CRD_IN_GRP() für die Kartenart aufrufen. Mit dieser Task wird die erste Kartenart in der CRD- Kartengruppe bestimmt
2) Weiter, wenn es in dieser Kartengruppe noch Karten gibt. Ansonsten zu Schritt 8) springen.
3) FR_RECORD_FIND_FIRST() aufrufen, um den ersten Datensatz in der FRT für diese Kartenart zu finden.
4) FRM_TA_FIND_FR_UPDATE_COUNT() aufrufen, um zu bestimmen, ob noch weitere Datensätze für diese Kartenart zu aktualisieren sind. Wenn nicht, dann Schleife bilden, um die nächste Kartenart in der Kartengruppe zu finden.
5) FR_RECORD_FINE_NEXT() aufrufen, ehe es möglich ist, den aktuellen zu löschen. Sollten wir ihn zuerst löschen, würde es keinen Weg geben, den nächsten Datensatz zu finden.
6) Sollte es erforderlich sein, diesen Datensatz zu aktualisieren, TA_UPDATE_FR_RECORD() aufrufen.
7) Den zu betrachtenden Datensatz auf den zwei Schritte höher gefundenen setzen. Zu Schritt 4) schleifen.
8) FIND_NEXT_CRD_IN_GRP() aufrufen, um die nächste Karte in der Kartengruppe zu bestimmen.
9) TIME_SLICE() aufrufen, um eine Pause zu machen und den Prozessor nicht unnötig zu belegen. Zu Schritt 3) schleifen.
10) Zur aufrufenden Prozedur zurückkehren.

FRM FIND TA CRD TO UPDATE()

Funktionsbeschreibung

Mit diesem Unterprogramm wird bestimmt, ob irgendwelche Einträge in der Tabelle ausfallender Betriebsmittel durch Schwellwertalarme zu aktualisieren sind. Wenn ja, wird damit die Kartenart und Verbindungsleitungs- oder Datengruppen-Ordnungsnummer dieses Eintrages zurückgemeldet.

Aufrufschnittstelle

Dieses Unterprogramm wird mit TA_UPDATE_FR_TABLE() aufgerufen. Es besitzt folgende Parameter:
CARTY - Kartenart (Zeiger auf Rückdaten)
GRP - Verbindungsleitungs- oder Datengruppe (Zeiger auf Rückdaten)
Rückmeldung FAILED oder GOOD.

Programmbeschreibung

1) Bestimmen, ob noch weitere Kartenarten zu betrachten sind (d.h. die letzte betrachtete war niedriger als die größte im System). Weiter, wenn noch mehr Kartenarten existieren und noch keine gefunden worden ist. Ansonsten zu Schritt 7) springen.
2) FRM_TA_FIND_FR_UPDATE_COUNT() aufrufen, um zu bestimmen, ob für diese Kartenart zu aktualisierende FRT-Datensätze bestehen.
3) Wenn für diese Kartenart Datensätze bestehen, FR_RECORD_FIND_FIRST() aufrufen, um den ersten Datensatz für diese Kartenart abzurufen.
4) Weiter, wenn für diese Kartenart noch Datensätze übrig sind und wir noch keinen zu aktualisierenden gefunden haben. Ansonsten zu Schritt 7) springen.
5) Sollte dieser Datensatz durch Schwellwertalarme zu aktualisieren sein, die Rückdaten dementsprechend setzen. Ansonsten RE_RECORD_FIND_NEXT() aufrufen, um den nächsten FR-Datensatz für diese Kartenart abzurufen.
6) Zu Schritt 4) schleifen.
7) Zur aufrufenden Prozedur zurückkehren.

TA UPDATE FR RECORD()

Funktionsbeschreibung

Mit diesem Unterprogramm wird ein Datensatz in der FR-Tabelle je nach seinem aktuellen Status aktualisiert. Sie aktualisiert ihn entweder oder löscht ihn. Darüber hinaus aktualisiert sie logisch den Reserveprozessor.

Aufrufschnittstelle

Dieses Unterprogramm wird mit TA_UPDATE_FR_TABLE() aufgerufen. Es besitzt folgende Parameter:
PREC - Zeiger auf den FR-Datensatz
Die Rückmeldung dieses Unterprogramms ist GOOD.

Programmbeschreibung

1) Wenn der Zustand des Datensatzes TA_UPDATE_CLEAR ist, LOGICAL_UPDATE() zur Aktualisierung der Reserveseite aufrufen. Dies ist vor Löschen des Datensatzes notwendig. Danach FR_RECORD_UPDATE() zum diesseitigen Löschen des Datensatzes aufrufen.
2) Wenn der Zustand des Datensatzes TA_UPDATE_NEEDED ist, FR_RECORD_UPDATE() aufrufen und danach LOGICAL_UPDATE().
3) Zur aufrufenden Prozedur zurückkehren.

FRM TA FIND FR UPDATE COUNT()

Funktionsbeschreibung

Mit diesem Unterprogramm wird auf die FR-Tabelle zugegriffen und die FR_UPDATE_COUNT für eine gegebene Kartenart abgerufen.

Aufrufschnittstelle

Dieses Unterprogramm wird mit FRM_FIND_TA_CRD_TO_UPDATE() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
NUM LEFT - die zu aktualisierende Datensatznummer (Zeiger auf Rückdaten)
Die Rückmeldung dieses Unterprogramms ist GOOD.

Programmbeschreibung

1) *NUM_LEFT auf die FR_UPDATE_COUNT für diese Kartenart setzen (d.h. FR_CR_LIST(CRD) FR_UPDATE_COUNT).
2) Zur aufrufenden Prozedur zurückkehren.

FRM TA IS CH FAIL OOS()

Funktionsbeschreibung

Mit diesem Unterprogramm wird bestimmt, ob ein Kanal für die Gesamtsumme aus fallender Kanäle zu zählen ist, und die Gesamtsumme von außer Betrieb befindlichen Kanälen. Es stellt zuerst sicher, daß dieser Kanal nicht aus der FR-Tabelle zu löschen ist. Danach stellt es sicher, daß die Verbindungsleitungs-/Datengruppen entsprechend übereinstimmen.

Aufrufschnittstelle

Dieses Unterprogramm wird mit FIND_NUM_FAIL_OOS_CH() aufgerufen. Es besitzt folgende Parameter:
PREC - Zeiger auf den FR-Datensatz
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
CH_FAILING - ob der Kanal als ausfallend zu zählen ist (Zeiger auf Rückdaten)
CH_OOS - ob der Kanal als OOS zu zählen ist (Zeiger auf Rückdaten)
Die Rückmeldung dieser Routine ist GOOD.

Programmbeschreibung

1) Bei einem Datensatzzustand TA_UPDATE_CLEAR den Kanal nicht zählen. Zu Schritt 3) springen.
2) Bei einem GRP-Parameter NULL oder gleich der Gruppe im Datensatz *CH_FAILING auf WAHR setzen. Bei einem Kanalzustand OOS oder PSD *CH_OOS auf WAHR setzen.
3) Zur aufrufenden Prozedur zurückkehren.

FIND FIRST CRD IN GRP()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die ersten Kartenart in der Kartengruppe einer gegebenen Kartenart zurückgemeldet.

Aufrufschnittstelle

Dieses Unterprogramm wird mit TA_UPDATE_FR_TABLE() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
FIRSTCRD - Zeiger auf erste Kartenart in Kartengruppe von CRD (Rückdaten)

Programmbeschreibung

1) FIND_GRP() aufrufen, um beginnend mit der ersten Karte im System die nächste Karte in der Gruppe zu finden.
2) Zur aufrufenden Prozedur zurückkehren.

FIND NEXT CRD IN GRP()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die nächste Kartenart in einer Kartengruppe gefunden.

Aufrufschnittstelle

Es wird mit TA_UPDATE_FR_TABLE() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
NEXTCRD - Zeiger auf die nächste Kartenart in der Kartengruppe der CRD (Rückdaten)

Programmbeschreibung

1) Anfangskarte auf CRD plus 1 setzen.
2) FIND_GRP() aufrufen, um beginnend mit der direkt der aktuellen Karte folgenden die nächste Karte in der Gruppe zu finden.
3) Zur aufrufenden Prozedur zurückkehren.

FIND GRP()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die nächste Karte in der Gruppe der gegebenen Karte gefunden.

Aufrufschnittstelle

Dieses Unterprogramm wird mit FIND_FIRST_CRD_IN_GRP() und FIND_NEXT_CRD_IN_GRP() aufgerufen. Es besitzt folgende Parameter:
CRD - gegebene Kartenart
CRD_TO_START - Anfangskartenart
NEXTCRD - Zeiger auf die nächste Karte in der Kartengruppe (Rückdaten)
Mit diesem Unterprogramm wird FAILED, GOOD oder NONE_LEFT zurückgemeldet.

Programmbeschreibung

1) GET_CGRP() zur Bestimmung der in Frage stehenden Kartengruppe aufrufen.
2) Sollten keine Kartenarten mehr im System sein, zu Schritt 6) springen.
3) GET_CGRP() für die Kartenart, die sich in dieser Kartengruppe befinden kann, aufrufen.
4) Bei Übereinstimmung der Kartengruppen von Schritten 1) und 3) ist die nächste Karte gefunden. Rückdaten setzen und GOOD rückmelden.
5) Zur Überprüfung die nächste Karte erhöhen und zu schritt 2) zurückschleifen.
6) NONE_LEFT zurückmelden.

GET CGRP()

Funktionsbeschreibung

Mit diesem Unterprogramm wird die Kartengruppe für eine bestimmte Kartenart gefunden.

Aufrufschnittstelle

Dieses Unterprogramm wird mit FIND_NUM_CH(), GET_MJ_MN_OOS_THRESH(), _CHECK_THRESHOLD_ALARMS(), SI_REPORT_THRESH_ALARMS(), FIND_GRP(), GET_CGRP_THRESHS(), GET_CGRP_GLOBORNOD() und GET_CGRP_PERCENT() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
CRDGRP - Zeiger auf die Kartengruppe (Rückdaten)
Mit diesem Unterprogramm wird FAILED oder GOOD zurückgemeldet.

Programmbeschreibung

1) Sicherstellen, daß die Kartenart gültig ist (d.h. CRD < = größte im System). Wenn nicht, FAILED zurückmelden.
2) Die Kartengruppe auf die im Datenfeld CARTY_TO_GRP für diese Karte bezeichnete Gruppe setzen.
3) Wenn die Kartengruppe ein Ursprungs-Datenanschluß ist und die Datengruppen-Ordnungsnummer nicht NULL ist, die Kartengruppe auf einen antwortenden Datenanschluß setzen.
4) (GOOD) zurückmelden.

GET CGRP THRESHS()

Funktionsbeschreibung

Mit diesem Unterprogramm werden die nichtkonfigurierbaren Haupt-, Neben- und OOS-Schwellwerte für eine gegebene Kartenart zurückgemeldet.

Aufrufschnittstelle

Dieses Unterprogramm wird mit GET_MJ_MN_OOS_THRESH() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
MAJOR - Hauptschwellwert (Zeiger auf Rückdaten)
MINOR - Nebenschwellwert (Zeiger auf Rückdaten)
OOS - Außerbetrieb-Schwellwert (Zeiger auf Rückdaten)
Damit wird GOOD oder FAILED zurückgemeldet.

Programmbeschreibung

1) GET_CGRP() zur Bestimmung der Kartengruppe für diese Kartenart aufrufen.
2) Einen Zeiger auf die Kartengruppen-Datenbank für diese Kartengruppe holen.
3) Die Schwellwerte auf die entsprechenden Felder in der Datenbank setzen.
4) Zur aufrufenden Prozedur zurückkehren.

GET CGRP GLOBORNOD()

Funktionsbeschreibung

Mit diesem Unterprogramm wird rückgemeldet, ob eine Kartenart mittels Knoten oder mittels System zu überwachen ist.

Aufrufschnittstelle

Dieses Unterprogramm wird mit CHECK_OOSTHRESH() und CHECK_THRESHOLDS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitungs- oder Datengruppen- Ordnungsnummer
GLOBORNOD - global oder mit Knoten überwacht (Zeiger auf Rückdaten)
Mit diesem Unterprogramm wird GOOD oder FAILED zurückgemeldet.

Programmbeschreibung

1) GET_CGRP() zur Bestimmung der Kartengruppe für diese Kartenart aufrufen.
2) Einen Zeiger auf die Kartengruppen-Datenbank für diese Kartengruppe abrufen.
3) Die Rückdaten entsprechend dem Wert des Feldes GLOBORNOD in der Datenbank setzen.
4) Zur aufrufenden Prozedur zurückkehren.

GET CGRP PERCENT()

Funktionsbeschreibung

Mit diesem Unterprogramm wird bestimmt, ob eine Karte nach Prozentsatz oder wirklicher Nummer zu überwachen ist.

Aufrufschnittstelle

Dieses Unterprogramm wird mit CHECK_OOSTHRESH() und CHECK_THRESHOLDS() aufgerufen. Es besitzt folgende Parameter:
CRD - Kartenart
GRP - Verbindungsleitung oder Datengruppe
PERCENT - Überwachung nach Prozentsatz oder wirklicher Nummer (Zeiger auf Rückdaten)
Mit diesem Unterprogramm wird GOOD oder FAILED zurückgemeldet.

Programmbeschreibung

1) GET_CGRP() zur Bestimmung der Kartengruppe für diese Kartenart aufrufen.
2) Einen Zeiger auf die Kartengruppen-Datenbank für diese Kartengruppe abrufen.
3) Die Rückdaten entsprechend dem Wert des PERCENT- Feldes in der Datenbank setzen.
4) Zur aufrufenden Prozedur zurückkehren.

KARTENGRUPPEN-DATENSTRUKTUREN

Kartenart auf Kartengruppe

Mit den folgenden Strukturen wird eine Kartenart auf ihre Kartengruppe abgebildet:
A) STRUCT CTOG (NIB CTOG_GRP);
B) STRUCT CTOG CARTY_TO GRP (NUNBER_OF_CARD_TYPES)( Erweiterungskarte Kodierer Dekodierer Konferenzbrücke Tongeber AFACTS-Superkarte Drehgeber Drehwählerregister Vierer-MFV-Register

Kartengruppe auf Schwellwerte

Mit dieser Struktur wird eine Kartengruppe auf ihre Schwellwerte abgebildet. ANMERKUNG: NL entspricht einem Null-Wert.

Claims

1. Verfahren zur Fehleranalyse in einem System, wobei das System eine Mehrzahl von Betriebsmitteln mit austauschbaren Einheiten, eine Anzeige, einen Prozessor, und Speichermittel zum Speichern von Entscheidungsbäumen, Datenstrukturen und Fehleranalysetasken aufweist, wobei die Betriebsmittel eine Diagnosekarte mit einem Prozessor und Speichermitteln zum Speichern von Betriebsmittelanalysetasken und Kommunikationsbetriebsmittel enthalten, dadurch gekennzeichnet, daß es folgende Schritte umfaßt:

(a) intermittierendes Prüfen der besagten Betriebsmittel, indem die besagten Fehleranalysetasken eine Kartenanalysetask auf der besagten Diagnosekarte zum Prüfen auf einen Fehler in den besagten Kommunikationsbetriebsmitteln im besagten System aufrufen;

(b) Erkennen eines Fehlers und Aufrufen einer geeigneten Fehleranalysetask zum Bearbeiten des besagten Fehlers;

(c) Bearbeiten des besagten Fehlers durch die besagte geeignete Fehleranalysetask zum Lokalisieren des besagten Fehlers auf eine austauschbare Einheit durch automatisches Durchlaufen der besagten Entscheidungsbäume;

(d) Einschreiben von Daten zur Aufzeichnung des besagten Fehlers in der besagten Datenstruktur in den besagten Speicher des besagten Systems; und

(e) Anzeigen einer auf dem besagten Fehler beruhenden Nachricht auf der besagten Anzeige des besagten Systems.

2. Verfahren zur Fehleranalyse nach Anspruch 1, dadurch gekennzeichnet, daß der besagte Schritt des automatischen Durchlaufens der besagten Entscheidungsbäume den Schritt des Identifizierens eines bestimmten zu durchlaufenden Entscheidungsbaumes auf Grundlage eines Kommunikationsbetriebsmittels enthält.

3. Verfahren zur Fehleranalyse nach Anspruch 1, dadurch gekennzeichnet, daß der besagte Schritt des automatischen Durchlaufens der besagten Entscheidungsbäume den Schritt des Identifizierens von zusätzlichen zu durchlaufenden Entscheidungsbäumen enthält, um alle anderen Fehler außer dem besagten Fehler in der besagten austauschbaren Einheit zu eliminieren.

4. Verfahren zur Fehleranalyse nach Anspruch 1, dadurch gekennzeichnet, daß der besagte Schritt des automatischen Durchlaufens der besagten Entscheidungsbäume folgende Schritte enthält:

(a) Prüfen der besagten Kommunikationsbetriebsmittel in einer vorbestimmten Folge auf Grundlage des besagten Fehlers, um eine vorläufige Schlußfolgerung zu ziehen;

(b) Analysieren der besagten vorläufigen Schlußfolgerung;

(c) Durchführen einer weiteres Prüfen und Analysieren umfassenden Handlung zur Verfeinerung der besagten vorläufigen Schlußfolgerung;

(d) Beenden, wenn die besagte Handlung eine abschließende Schlußfolgerung erreicht.

5. Verfahren zur Fehleranalyse nach Anspruch 1, dadurch gekennzeichnet, daß der besagte Schritt des Anzeigens einer Nachricht auf Grundlage des besagten Fehlers auf der besagten Anzeige des besagten Systems folgende Schritte umfaßt:

(a) Formatieren der besagten Daten in eine Nachricht in natürlicher Sprache; und

(b) Anzeige der besagten Nachricht in natürlicher Sprache auf der besagten Anzeige.

6. Verfahren zur Fehleranalyse nach Anspruch 5, dadurch gekennzeichnet, daß es weiterhin den Schritt des Anzeigens einer Nachricht mit einer vorgeschlagenen Handlung auf der besagten Anzeige umfaßt.

7. Verfahren zur Fehleranalyse nach Anspruch 1, dadurch gekennzeichnet, daß die besagten Fehleranalysetasken von Hand aufgerufen werden.

8. Vorrichtung zur Fehleranalyse in einem System mit einer Mehrzahl von Kommunikationsbetriebsmitteln mit austauschbaren Einheiten, einer Anzeige, einem Prozessor und Speichermitteln zum Speichern von Datenstrukturen, Entscheidungsbäumen und Fehleranalysetasken, dadurch gekennzeichnet, daß sie umfaßt:

(a) Mittel zum Prüfen der besagten Mehrzahl von Kommunikationsbetriebsmitteln durch eine Fehleranalysetask zum Erkennen eines Fehlers in einem Kommunikationsbetriebsmittel in dem besagten System und Erzeugen eines einen Fehler anzeigenden Signals;

(b) Mittel zum Erkennen des besagten den besagten Fehler anzeigenden Signals und Aufrufen einer geeigneten Fehleranalysetask zum Diagnostizieren des besagten Fehlers;

(c) Mittel zum Lokalisieren des besagten Fehlers auf die besagten austauschbaren Einheiten durch automatisches Durchlaufen der besagten Entscheidungsbäume;

(d) Mittel zum Einschreiben von den besagten Fehler in der besagten Datenstruktur aufzeichnenden Daten in den besagten Speicher des besagten Systems; und

(e) Mittel zum Anzeigen einer auf dem besagten Fehler beruhenden Nachricht auf der besagten Anzeige des besagten Systems.

9. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin Mittel zur Identifizierung eines jeden der besagten Entscheidungsbäume, die zum Prüfen des besagten Kommunikationsbetriebsmittels geeignet sind, enthält.

10. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin Mittel zum Identifizieren von zusätzlichen zu durchlaufenden Entscheidungsbäumen umfaßt, um alle Fehler außer dem besagten Fehler in dem besagten Kommunikationsbetriebsmittel zu eliminieren.

11. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin Mittel zur Bereitstellung eines Entscheidungsbaumes für jedes der besagten Kommunikationsbetriebsmittel umfaßt.

12. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin umfaßt:

(a) Mittel zum Prüfen des besagten Systems in einer vorbestimmten Folge auf Grundlage des besagten Fehlers, um eine vorläufige Schlußfolgerung zu ziehen;

(b) Mittel zum Analysieren der besagten vorläufigen Schlußfolgerung;

(c) Mittel zum Durchführen einer weiteres Prüfen und Analysieren umfassenden Handlung zur Verfeinerung der besagten vorläufigen Schlußfolgerung; und

(d) Mittel zum Beenden, wenn die besagte Handlung eine Schlußfolgerung erreicht.

13. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin umfaßt:

(a) Mittel zum Formatieren der besagten Daten in eine Nachricht in natürlicher Sprache; und

(b) Anzeigen der besagten Nachricht in natürlicher Sprache auf der besagten Anzeige.

14. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, weiterhin dadurch gekennzeichnet, daß sie Mittel zur Anzeige einer Nachricht mit einer vor geschlagenen Handlung umfaßt.

15. Vorrichtung zur Fehleranalyse in einem System nach Anspruch 8, dadurch gekennzeichnet, daß sie weiterhin Mittel zum Aufrufen der besagten Fehleranalysetasken von Hand umfaßt.