Die vorliegende Erfindung bezieht sich auf Verfahren zum Prüfen der Steuersoftware eines Telekommunikationsgerätes mit einer verteilten Steuerung und zusätzlich auf ein Softwareprodukt, einen Speicher und einen Rechner, die seine Umsetzung ermöglichen.

Moderne Telekommunikationsgeräte bestehen normalerweise aus einer Vielzahl von Platinen, in 1 bezeichnet mit SC-1 ... SC-n, die untereinander üblicherweise über einen (in 1 nicht dargestellten) Bus verbunden sind; jede Platine SC erfüllt ihre eigenen Funktionen unabhängig von den anderen und kommuniziert, wenn es aufgrund des Betriebs erforderlich ist, mit den anderen Platinen, wobei dieses Gerät in einem verteilten Betrieb arbeitet.

Alle Telekommunikationsgeräte einer bestimmten Komplexität erfordern ein Steuersystem, das es einem Benutzer ermöglicht, den Status zu überprüfen und den Betrieb zu steuern; natürlich ist es wünschenswert, dass das Steuersystem mit einer anwenderfreundlichen Benutzeroberfläche ausgestattet ist.

Es ist recht häufig so, dass dann, wenn der Betrieb des Gerätes verteilt erfolgt, auch das Steuersystem verteilt arbeitet; typischerweise wird für jede Platine SC des Gerätes ein entsprechendes Steuersubsystem vorgesehen, das im weiteren Verlauf als "gesteuerte Instanz" bezeichnet wird und in 1 mit CO bezeichnet ist.

Unter Bezugnahme auf 1 umfasst en solches verteiltes Steuersystem im Allgemeinen eine steuernde Instanz CE und eine Vielzahl gesteuerter Instanzen CO-1 ... CO-n; die Instanzen sind untereinander verbunden und kommunizieren zum Beispiel über ein Bus-Kommunikationsnetzwerk NW.

Die steuernde Instanz CE besteht aus einer unabhängigen Steuerkarte oder einem Steuerrechner, oft ein PC [Personal Computer]; die steuernde Instanz CE umfasst einen Prozessor mP (oft ein Mikroprozessor) und damit in Kommunikation stehend Speichermittel MM-P und Kommunikationsmittel RT-P; sie führt ihre eigene Steuersoftware aus, die im Wesentlichen den Austausch der Steuerinformationen mit den gesteuerten Instanzen CO durchführt und die Gesamtsteuerung des Gerätes unter anderem in Verbindung mit dem Verhalten des Benutzers durchführt; die steuernde Instanz CE kann auch die Benutzeroberfläche bereitstellen und umfasst zu diesem Zweck eine Ausgabeschnittstelle IU und eine Eingabeschnittstelle II, die beide mit dem Prozessor mP verbunden sind.

Die gesteuerte Instanz CO ist sehr häufig innerhalb der entsprechenden Platine SC des Gerätes realisiert; jede Instanz CO umfasst einen Prozessor mC (oft ein Mikrocontroller) und damit in Kommunikation stehend Speichermittel MM-C, eine Vielzahl von Peripheriegeräten (in 1 zum Beispiel fünf, die mit P-1, P-2, P-3, P-4, P-5 bezeichnet sind) sowie Kommunikationsmittel RT-C; sie führt ihre eigene Steuersoftware aus, die im Wesentlichen den Austausch der Steuerinformationen mit der steuernden Instanz CE durchführt sowie die Steuerung der Platine SC, das heißt, sie erkennt den Status der Platine SC, indem sie von den Peripheriegeräten P liest (in 1 werden nur die Peripheriegeräte P-2 und P-5 gelesen), und sie lenkt den Betrieb der Platine SC, indem sie auf die Peripheriegeräte P schreibt (in 1 wird nur auf den Peripheriegeräten P-1, P-2, P-3 und P-4 geschrieben).

Sowohl die steuernde Instanz als auch die gesteuerten Instanzen können für eine höhere Zuverlässigkeit des Steuersystems redundant sein; zum Beispiel kann die Instanz eine Primäreinheit und eine Reserveeinheit umfassen, die ihren Betrieb aufnimmt, wenn in der Primäreinheit ein Fehler vorliegt.

Die Realisierung eines solchen Steuersystems kann in die folgenden Tätigkeiten unterteilt werden:

• • Definition der Systemanforderungen;
• • Definition der Steuerarchitektur;
• • Entwurf und Entwicklung der Verarbeitungsalgorithmen;
• • Entwurf und Entwicklung der Hardware der steuernden Instanz;
• • Entwurf und Entwicklung der Hardware der gesteuerten Instanzen;
• • Entwurf und Entwicklung der Steuersoftware der steuernden Instanz;
• • Entwurf und Entwicklung of Steuersoftware der gesteuerten Instanzen;
• • Prüfung einzelner Instanzen;
• • Gesamttest des Systems.

Um die Ausführungszeit zu verkürzen, ist es erforderlich, diese Tätigkeiten so weit wie möglich gleichzeitig auszuführen, indem verschiedene Teams von Entwurfsingenieuren eingesetzt werden.

Um die Prüfaktivitäten der einzelnen Instanzen gleichzeitig zu entwickeln, ist es erforderlich, das Verhalten der anderen Instanzen zu simulieren; im Allgemeinen erfolgt ihr Entwurf, ihre Entwicklung und ihre Prüfung nämlich nicht für das komplette System.

Üblicherweise entwickelt jedes Team von Entwurfsingenieuren einen für seine Zwecke geeigneten Simulator; im Allgemeinen sind dies Software-Simulatoren.

Dieser Ansatz ist unwirtschaftlich und riskant; unwirtschaftlich, weil der auf diese Weise entwickelte Simulator im Allgemeinen nicht für andere Projekte weiterverwendet werden kann; riskant, weil es sehr schwierig ist, sicher zu sein, dass der Simulator das Verhalten der anderen Instanzen exakt bzw. korrekt simuliert.

Eine Vorrichtung zur Überprüfung von Zielsoftware, die in einen Zielrechner geladen wird, ist aus US-A-5022028 bekannt. Die Vorrichtung umfasst Kommunikations- und Überwachungsschaltungen, die in einen Zielrechner und in einen Hostrechner eingefügt werden, welcher so programmiert ist, dass er den Betrieb von Prüfungen der Zielsoftware über die Kommunikations- und Überwachungsschaltungen lenkt. Die Kommunikations- und Überwachungsschaltungen übertragen externe Stimuli auf eine Weise, die kein unerlaubtes Eindringen darstellt, an die Zielsoftware. Die Kommunikations- und Überwachungsschaltungen erfassen auch die Ausgangsdaten der Zielsoftware zum Vergleich mit im Hostrechner gespeicherten Bezugsdaten. Die externen Stimuli, einschließlich der Prüfanweisungen, können entweder in einer manuellen Aufzeichnungssitzung aufgezeichnet oder sie können im Hostrechner generiert werden. In ähnlicher Weise können die Ausgangsbezugsdaten der Zielsoftware entweder im Hostrechner generiert oder in einer manuellen Sitzung aufgezeichnet werden.

Gegenstand der vorliegenden Erfindung ist die Bereitstellung eines Verfahrens zum Prüfen der Steuersoftware eines Telekommunikationsgerätes, welches nicht die oben erwähnten Probleme aufweist.

Dieses Ziel wird im Wesentlichen durch die Verfahren erreicht, welche die jeweils in den Ansprüchen dargelegten Funktionalitäten aufweisen, und weitere vorteilhafte Aspekte der vorliegenden Erfindung sind in den abhängigen Ansprüchen dargelegt.

Die Grundidee der vorliegenden Erfindung besteht darin, eine Software einzusetzen, die dafür geeignet ist, das Verhalten einer allgemeinen Instanz des Steuersystems zu simulieren, und die für eine Spezialisierung auf der Grundlage von Spezialisierungsinformationen geeignet ist, welche für das Steuersystem kennzeichnende Daten und Beziehungen spezifizieren.

Eine solche Idee ist praktisch durchführbar, da es möglich gewesen ist, ein Modell zu finden, welches auf verteilte Steuersysteme für Telekommunikationsgeräte anwendbar ist. Die verschiedenen Steuersysteme unterscheiden sich nach ihrer Modellierung in einer begrenzten Zahl von Parametern; diese Parameter können durch eine einfache Sprache beschrieben werden, die von der Simulationssoftware interpretiert werden kann.

Die vorliegende Erfindung kann generell auf Telekommunikationsgeräte angewendet werden, und diese Anwendung ist besonders vorteilhaft für Sendeeinrichtungen wie Richtfunksysteme.

Zu einer bestimmten Familie oder Generation von Richtfunksystemen gehören nämlich Geräte, die eine gemeinsame Technologie besitzen, die sich jedoch erheblich durch den Anwendungstyp unterscheiden, und daher nicht nur aufgrund der Anzahl, sondern auch der Struktur und des Betriebs der Platinen, die ihre Komponenten bilden. Deshalb weisen ihre Steuersysteme erhebliche Unterschiede auf, und die Möglichkeit, bereits entwickelte Simulatoren erneut zu verwenden, ist äußerst begrenzt.

Die vorliegende Erfindung wird dank der nachfolgenden Beschreibung klarer ersichtlich werden, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist, auf denen:

1 das stark vereinfachte Blockdiagramm eines Telekommunikationsgerätes darstellt, in dem das Steuersystem besonders in Erscheinung tritt;

2 das Blockdiagramm einer Instanz eines mit einem Rechner verbundenen Steuersystems gemäß der vorliegenden Erfindung darstellt, um die Prüfung der Steuersoftware durchzuführen; und

3 das Blockdiagramm einer Simulationssoftware gemäß der vorliegenden Erfindung darstellt.

Bevor die detaillierte Beschreibung der Erfindung vorgenommen wird, ist es wichtig, das Modell zu beschreiben, das die Grundlage für die Möglichkeit ihrer Ausführung bildet.

Die vorliegende Erfindung ist nicht auf das Modell beschränkt, das weiter unten beschrieben wird; es ist nämlich möglich, viele Modelle zu ermitteln, die dem vorliegenden Modell ähnlich sind und die auf Steuersysteme für Geräte Anwendung finden, und [es ist möglich] die Verfahren der vorliegenden Erfindung sogar dann zu nutzen, wenn das Steuersystem von einem dieser ähnlichen Modelle modelliert wurde.

Unter Bezugnahme auf 1 umfasst ein Steuersystem eines Gerätes eine steuernde Instanz CE und eine Vielzahl von gesteuerten Instanzen CO-1 ... CO-n.

Ein Gerät sendet und empfängt sowohl intern als auch extern physikalische Signale unterschiedlicher Art: optische und elektrische, analoge und digitale, ... . Durch die Gesamtheit aller dieser Signale wird das Gerät spezialisiert. Die Steuerung des Gerätes entspricht der Steuerung seiner Signale; im Allgemeinen ist es nicht notwendig und/oder möglich, alle Signale zu steuern, und deshalb ist die Steuerung auf eine Untermenge von ihnen begrenzt, die als steuerbare physikalische Signale bezeichnet werden.

Den steuerbaren Signalen des Gerätes entsprechen die steuerbaren physikalischen Daten des Gerätes; eine solche Konvertierung wird von den Peripheriegeräten P des Steuersystems ausgeführt; je nach Signal und demzufolge auch je nach den relevanten Daten hat das Peripheriegerät die Aufgabe, die Daten zu lesen und das Signal zu generieren oder das Signal zu erkennen und die Daten zu generieren. Das Steuersystem ist daher an erster Stelle durch seine steuerbaren physikalischen Daten gekennzeichnet.

Jede gesteuerte Instanz CO umfasst eine bestimmte Anzahl von Peripheriegeräten P, die den steuerbaren physikalischen Daten zugeordnet sind. Die gesteuerte Instanz CO ist daher durch ihre steuerbaren physikalischen Daten gekennzeichnet, von denen jeder einzelne Datenwert durch eine bestimmte Anzahl von Parametern wie Typ und Größe gekennzeichnet ist.

Die gesteuerte Instanz CO führt den Austausch ihrer steuerbaren physikalischen Daten mit der steuernden Instanz CE durch. Die gesteuerte Instanz CO ist daher ferner durch die Nutzung von Beziehungen gekennzeichnet, die spezifizieren, welche steuerbaren physikalischen Daten dafür geeignet sind, von der gesteuerten Instanz CO gesendet zu werden (das heißt, die zum „Fluss von SET" gehören und daher als „physikalische Daten von SET" bezeichnet werden), und welche der steuerbaren physikalischen Daten dafür geeignet sind, von der gesteuerten Instanz CO empfangen zu werden (das heißt, die zum „Fluss von GET" gehören und daher als „physikalische Daten von GET" bezeichnet werden).

Das Steuersystem kann auch steuerbare logische Daten verarbeiten; sie stellen eine für den Benutzer am besten geeignete Ansicht des Gerätes dar, die von mehreren Konstruktions- und Implementierungsdetails des Gerätes unabhängig ist; die steuerbaren logischen Daten hängen mit den steuerbaren physikalischen Daten durch (manchmal sehr komplexe) Assoziationsbeziehungen zusammen, die für das Steuersystem kennzeichnend sind.

Die steuernde Instanz CE tauscht die physikalischen Daten mit allen gesteuerten Instanzen CO des Steuersystems aus; zusätzlich kann sie die physikalischen Daten in Übereinstimmung mit den Assoziationsbeziehungen mit den eventuellen logischen Daten verknüpfen. Die steuernde Instanz CE kann daher durch ihre steuerbaren logischen Daten und ihre Assoziationsbeziehungen gekennzeichnet werden.

Die im vorliegenden Modell berücksichtigten Datentypen sind:

ALARM: Feld von einem Bit, das den Status eines Alarms angibt;

STATUS: Feld von einem oder mehreren Bit, das einen genau definierten Status des Gerätes angibt (dauerhaft oder vorübergehend);

MEASURE: Feld von im Allgemeinen mehreren Bit, das das Ergebnis einer aktiven Messung angibt; wenn die Messung nicht aktiv ist, enthält es das Ergebnis der zuletzt ausgeführten Messung;

VALUE: Feld von einem oder mehreren Bit, das permanente Konfigurationswerte des Gerätes angibt;

CONTROL: Feld von einem oder mehreren Bit, das eine Anforderung der manuellen vorübergehenden Zwangssteuerung von Werten oder spezifischen Funktionalitäten des Gerätes angibt;

ECHO: Feld von im Allgemeinen einem Bit, das das Vorhandensein einer im Gange befindlichen spezifischen manuellen Zwangssteuerung angibt;

IMPULSIVE: Feld von im Allgemeinen einem Bit, das ein Synchronisationsereignis angibt, um auf Anforderung automatische Funktionalitäten zu aktivieren;

CRITERION: Feld von im Allgemeinen einem Bit, das ein Ereignis angibt, das von den Statusalgorithmen als sich entwickelnder Schlüssel verwendet wird;

COMMAND: Feld von im Allgemeinen einem Bit, das den Status eines Peripheriegerätes angibt, im Allgemeinen zur Überwachung verwendet.

Unter den Peripheriegeräten, die diese Daten handhaben, können wir die folgenden erwähnen: Digital-Analog-Umsetzer, Analog-Digital-Umsetzer, Puffer, Schieberegister, kombinierter Sender-Empfänger-Baustein für asynchrone Datenübertragung (UART), Zähler, Codierer, Decodierer, Zwischenspeicher (Latch), Operationsverstärker, RAM-Speicher, EEPROM-Speicher.

Die steuerbaren physikalischen oder logischen Daten sind in Registern organisiert, die alle dieselbe Größe haben (z. B. 32, 48 oder 64 Bit). Deshalb ist jeder Datenwert durch die Kennnummer des Registers, in dem er enthalten ist, durch seine Position innerhalb des Registers und durch seine Größe identifiziert; zusätzlich kann es Datenanzeigeattribute geben, zum Beispiel „Hilfe zum Datenwert" (eine Text-Zeichenfolge, die die Bedeutung und/oder die Verwendung des Datenwertes spezifiziert) und die „Farbe des Datenwerts" (eine Zahl).

Jedes Bit jedes Registers benötigt einen Anfangswert, der dem Bit zugewiesen werden muss, wenn das Steuersystem seinen Betrieb aufnimmt.

Das vorliegende Modell reduziert die gesamte Steuerung auf die folgenden zehn (elementaren) Steueraktionen:

AKTION 1: Erkennung der gesteuerten Instanzen CO, die Teil des Steuersystems sind, durch die steuernde Instanz CE.

AKTION 2: Erkennung der physikalischen Daten von GET und SET jeder gesteuerten Instanz CO durch die steuernde Instanz CE.

AKTION 3: Vorbereitung der physikalischen Daten von GET durch die steuernde Instanz CE durch Assoziation der logischen Daten.

AKTION 4: Schreiben der physikalischen Daten von GET in die gesteuerten Instanzen CO durch die steuernde Instanz CE.

AKTION 5: Übertragung der physikalischen Daten von GET von der steuernden Instanz CE an die gesteuerten Instanzen CO über ein geeignetes Kommunikationsprotokoll.

AKTION 6: Schreiben in die Peripheriegeräte durch die gesteuerten Instanzen CO aufgrund der neuen Werte der empfangenen physikalischen Daten von GET.

AKTION 7: Kontinuierliches Lesen aus den Peripheriegeräten durch die gesteuerten Instanzen CO und entsprechendes Schreiben der neuen physikalischen Daten von SET in die steuernde Instanz CE durch die gesteuerten Instanzen CO.

AKTION 8: Übertragung der physikalischen Daten von SET von den gesteuerten Instanzen CO an die steuernde Instanz CE über ein geeignetes Kommunikationsprotokoll.

AKTION 9: Vorbereitung der logischen Daten durch die steuernde Instanz CE durch Verknüpfung mit den physikalischen Daten.

AKTION 10: Zugriff auf logische oder physikalische Daten.

Diese Steueraktionen des Systems entsprechen: Steueraktionen, die nur Bedienoberfläche Instanz CE ausgeführt werden; Steueraktionen, die von einer oder mehreren gesteuerten Instanzen CO ausgeführt werden; Steueraktionen, die von der steuernden Instanz CE und von einer oder mehreren gesteuerten Instanzen CO ausgeführt werden.

Die zehn Aktionen sollen nachfolgend in der Weise, in der sie in dem vorliegenden Modell implementiert sind, kurz erklärt werden.

Die steuernde Instanz CE sendet an die gesteuerten Instanzen CO einen Identifizierungsruf. Die gesteuerten Instanzen antworten, indem sie ihre eigene Kennnummer und eventuell weitere Informationen wie Code, Typ und Funktion der Platine, welche die Aufgabe der Steuerung innehaben, sowie ihre Hardware- und Softwareversion senden.

Die steuernde Instanz CE startet eine Sende-Übergabe-Phase mit allen identifizierten gesteuerten Instanzen CO.

Auf Anforderung senden die gesteuerten Instanzen CO an die steuernde Instanz CE die Kennnummern, Typen, Größen und die Zugehörigkeit zum Fluss (von GET oder SET) aller ihrer physikalischen Daten.

Auf eine weitere Anforderung hin senden die gesteuerten Instanzen CO an die steuernde Instanz CE die Istwerte aller physikalischen Daten von SET.

Bei jeder Veränderung der logischen Daten ermittelt die steuernde Instanz CE die eine oder mehrere Assoziationsbeziehung bzw. -beziehungen, an der bzw. denen die logischen Daten beteiligt sind, sie interpretiert sie und aktualisiert den Wert der physikalischen Daten von GET, die von der Beziehung betroffen sind.

Bei jeder Veränderung der physikalischen Daten von GET in der steuernden Instanz CE ermittelt die steuernde Instanz CE, welche gesteuerte Instanz oder welche gesteuerten Instanzen die physikalischen Daten von GET nutzen, und „schreibt" die physikalischen Daten von GET in die gesteuerte Instanz CO durch Auslösen von AKTION 5.

Die steuernde Instanz CE sendet ein Register an eine gesteuerte Instanz CO, wobei ein Kommunikationsprotokoll des Netzwerks NW verwendet wird.

Die gesteuerte Instanz CO empfängt das Register von der steuernden Instanz CE, wobei ein Kommunikationsprotokoll des Netzwerks NW verwendet wird.

Beim Empfang eines Registers von der steuernden Instanz CE ermittelt die gesteuerte Instanz CO die empfangenen physikalischen Daten von GET, aktualisiert die Daten mit einem neuen Wert und schreibt sie in die relevanten Peripheriegeräte entsprechend den Modalitäten, die von diesen Peripheriegeräten gefordert werden.

Jede gesteuerte Instanz CO liest regelmäßig mit einer für jedes Peripheriegerät charakteristischen Periode die physikalischen Daten von SET aus den relevanten Peripheriegeräten entsprechend den Modalitäten, die von diesen Peripheriegeräten gefordert werden, aktualisiert die Daten, die einen neuen Wert haben, und „schreibt" sie in die steuernde Instanz CE, indem AKTION 8 ausgelöst wird, wobei eine Priorität bezüglich der Periode gilt, die für die Daten kennzeichnend ist.

Die gesteuerte Instanz CO wählt ein an die steuernde Instanz CE zu sendendes Register basierend auf der Priorität aus.

Die gesteuerte Instanz CO sendet das Register an die steuernde Instanz CE, wobei ein Kommunikationsprotokoll des Netzwerks NW verwendet wird.

Die steuernde Instanz CE empfängt das Register von der gesteuerten Instanz CO, wobei ein Kommunikationsprotokoll des Netzwerks NW verwendet wird.

Beim Empfang eines Registers von einer gesteuerten Instanz CO ermittelt die steuernde Instanz CE die empfangenen physikalischen Daten von SET, aktualisiert die Daten, die einen neuen Wert haben, [sowie] die eine oder mehrere Assoziationsbeziehung bzw, -beziehungen, an denen die physikalischen Daten beteiligt sind, interpretiert sie und aktualisiert die logischen Daten.

Ausführung von Lese- oder Schreib-Softwareanforderungen logischer oder physikalischer Daten, je nachdem, welches zutrifft, durch die steuernde Instanz CE.

Mit dem oben beschriebenen Modell (oder mit ähnlichen Modellen) ist es möglich, das gesamte Steuersystem eines elektronischen Gerätes zu modellieren, insbesondere das verteilte Steuersystem eines Telekommunikationsgerätes.

Dieses Modell (oder ein ähnliches Modell) kann in vorteilhafter Weise auch während der Entwurfsphase des Steuersystems genutzt werden, insbesondere dann, wenn die Detailspezifikationen der Steuersoftware definiert werden. Die Nutzung dieses Modells während der Entwurfsphase hat im Allgemeinen Einfluss auf die Struktur und den Betrieb der entwickelten Software.

Jedes Team von Entwurfsingenieuren sollte für den Entwurf einer Instanz die Spezifikationen verwenden, die sich auf die in seinen eigenen Zuständigkeitsbereich fallende Instanz beziehen, und die Spezifikationen, die sich auf die anderen Instanzen beziehen, zum Prüfen der entwickelten Software.

Diese Erfindung wird nachfolgend unter Bezugnahme auf 1, 2 und 3 beschrieben; eine solche Bezugnahme ist nicht als Einschränkung zu verstehen.

Das Prüfen der Steuersoftware einer gesteuerten Instanz CO dient dazu, den korrekten Betrieb der Steuersoftware im Hinblick auf vier Hauptaspekte zu kontrollieren:

• – die Verwaltung der Peripheriegeräte dieser gesteuerten Instanz;
• – die physikalischen Ebenen des Kommunikationsprotokolls;
• – die logischen Ebenen des Kommunikationsprotokolls;
• – die Ausführung der Steueraktionen.

Ein erstes Verfahren gemäß der vorliegenden Erfindung zum Prüfen der Steuersoftware von einer der gesteuerten Instanzen CO-1 ... CO-n umfasst die Schritte des:

• a) Aktivierens einer solchen gesteuerten Instanz CO und Ausführens der zu prüfenden Steuersoftware;
• b) Anordnens und Aktivierens eines Rechners EL, der mit Kommunikationsmitteln RT-E ausgestattet ist, welche in der Lage sind, mit einer solchen gesteuerten Instanz CO zu kommunizieren;
• c) Ermittelns der steuerbaren physikalischen Daten, die für eine solche gesteuerte Instanz CO kennzeichnend sind;
• d) Ermittelns der Nutzungsbeziehungen, die für eine solche gesteuerte Instanz CO kennzeichnend sind und die spezifizieren, welche physikalischen Daten dafür geeignet sind, von der Instanz CO gesendet zu werden, und welche physikalischen Daten dafür geeignet sind, von der Instanz CO empfangen zu werden;
• e) Ladens des Rechners EL mit einer Simulationssoftware, die dazu geeignet ist, das Verhalten einer allgemeinen gesteuerten Instanz zu simulieren;
• f) Lieferns von Spezialisierungsinformationen an die Simulationssoftware, die die ermittelten physikalischen Daten und die ermittelten Nutzungsbeziehungen spezifizieren; und
• g) Ausführens der auf der Basis dieser Spezialisierungsinformationen spezialisierten Simulationssoftware.

Dieses erste Verfahren ist besonders gut für die Prüfung der ersten beiden Aspekte geeignet.

Ein sehr einfaches Verfahren zur Bereitstellung der Simulationssoftware mit umgekehrten Nutzungsbeziehungen besteht darin, die nicht umgekehrten Nutzungsbeziehungen zusammen mit einer Zusatzinformation bereitzustellen, die der Simulationssoftware mitteilt, dass eine Umkehrung durchgeführt werden muss.

Wenn die Simulationssoftware zum Simulieren des Verhaltens nur der gesteuerten Instanzen geeignet ist, kann eine solche Zusatzinformation auch weggelassen werden, wenn die Simulationssoftware so angeordnet ist, dass sie immer eine Umkehrung der Nutzungsbeziehungen durchführt; in diesem Fall findet die Spezialisierung teilweise vor dem Laden der Simulationssoftware statt.

Ein zweites Verfahren gemäß der vorliegenden Erfindung zum Prüfen der Steuersoftware von einer der gesteuerten Instanzen CO-1 ... CO-n umfasst die Schritte des:

• a) Aktivierens einer solchen gesteuerten Instanz CO und Ausführens der zu prüfenden Steuersoftware;
• b) Anordnens und Aktivierens eines Rechners EL, der mit Kommunikationsmitteln RT-E ausgestattet ist, welche in der Lage sind, mit einer solchen gesteuerten Instanz CO zu kommunizieren;
• c) Ermittelns der steuerbaren physikalischen Daten, die für eine solche gesteuerte Instanz CO kennzeichnend sind;
• d) Ermittelns der Nutzungsbeziehungen, die für eine solche gesteuerte Instanz CO kennzeichnend sind und die spezifizieren, welche physikalischen Daten dafür geeignet sind, von der Instanz CO gesendet zu werden, und welche physikalischen Daten dafür geeignet sind, von der Instanz CO empfangen zu werden;
• e) Ladens des Rechners EL mit einer Simulationssoftware, die dazu geeignet ist, das Verhalten einer allgemeinen gesteuerten Instanz zu simulieren;
• f) Lieferns von Spezialisierungsinformationen an die Simulationssoftware, die die ermittelten physikalischen Daten und die ermittelten Nutzungsbeziehungen spezifizieren, jedoch in umgekehrter Kommunikationsrichtung; und
• g) Ausführens der auf der Basis dieser Spezialisierungsinformationen spezialisierten Simulationssoftware.

Gemäß diesem zweiten Verfahren ist es möglich, weitere Schritte bereitzustellen des:

• h) Ermittelns der steuerbaren logischen Daten, die für die steuernde Instanz CE kennzeichnend sind; und
• i) Ermittelns der Assoziationsbeziehungen, die für die steuernde Instanz CE kennzeichnend sind und die den Zusammenhang zwischen physikalischen und logischen Daten spezifizieren;

Dieses zweite Verfahren ist besonders gut für die Prüfung der letzten beiden Aspekte geeignet.

Beide Verfahren können nacheinander angewendet werden: Zuerst wird das erste Verfahren angewendet, um alles festzustellen, was die Verwaltung der Peripheriegeräte und die physikalischen Ebenen des Kommunikationsprotokolls betrifft, und später wird das zweite Verfahren angewendet, um alles festzustellen, was die logischen Ebenen des Kommunikationsprotokolls und die Ausführung der Steueraktionen betrifft.

Das Prüfen der Steuersoftware der steuernden Instanz CE dient dazu, den korrekten Betrieb der Steuersoftware im Hinblick auf drei Hauptaspekte zu kontrollieren:

• – die physikalischen Ebenen des Kommunikationsprotokolls;
• – die logischen Ebenen des Kommunikationsprotokolls;
• – die Erzeugung von Steueraktionen als Folge der Befehle des Benutzers.

Ein drittes Verfahren gemäß der vorliegenden Erfindung zum Prüfen der Steuersoftware einer steuernden Instanz umfasst die Schritte des:

• a) Aktivierens der steuernden Instanz CE und Ausführens der zu prüfenden Steuersoftware;
• b) Anordnens und Aktivierens eines Rechners EL, der mit Kommunikationsmitteln RT-E ausgestattet ist, welche in der Lage sind, mit der steuernden Instanz CE zu kommunizieren;
• c) Ermittelns der steuerbaren physikalischen Daten, die für alle gesteuerten Instanzen CO-1 ... CO-n kennzeichnend sind;
• d) Ermittelns der Nutzungsbeziehungen, die für alle gesteuerten Instanzen CO-1 ... CO-n kennzeichnend sind und die spezifizieren, welche physikalischen Daten dafür geeignet sind, von jeder gesteuerten Instanz CO gesendet zu werden und welche physikalischen Daten dafür geeignet sind, von jeder gesteuerten Instanz CO empfangen zu werden;
• e) Ladens des Rechners EL mit einer Simulationssoftware, die dazu geeignet ist, das Verhalten einer allgemeinen gesteuerten Instanz zu simulieren;
• f) Lieferns von Spezialisierungsinformationen an die Simulationssoftware, welche die Vereinigungsmenge der ermittelten physikalischen Daten und die Vereinigungsmenge der ermittelten Nutzungsbeziehungen spezifizieren; und
• g) Ausführens der auf der Basis dieser Spezialisierungsinformationen spezialisierten Simulationssoftware.

Gemäß diesem dritten Verfahren simuliert die Simulationssoftware eine virtuelle gesteuerte Instanz, die die Vereinigungsmenge aller gesteuerten Instanzen CO-1 ... CO-n des Steuersystems ist.

Gemäß diesem dritten Verfahren können die Ausführung der zu prüfenden Steuersoftware und die Ausführung der Simulationssoftware jeweils auf der Hardware der steuerndem Instanz CE beziehungsweise auf einem Rechner EL stattfinden. Dieser erste Fall ist für die Prüfung im Hinblick auf alle Aspekte geeignet.

Gemäß diesem dritten Verfahren können die Ausführung der zu prüfenden Steuersoftware und die Ausführung der Simulationssoftware auf demselben Rechner erfolgen, und die Kommunikation zwischen den Softwaremodulen kann ausschließlich über Softwareprotokolle erfolgen. Dieser zweite Fall ist besonders gut für die Prüfung des letzten Aspekts geeignet, da der Simulator mit der steuernden Instanz ohne Nutzung des Kommunikationsprotokolls des Steuersystems kommuniziert, sondern mit Hilfe der (standardmäßigen und zuverlässigen) Kommunikationsprozeduren zwischen auf demselben Rechner residenten Prozessen/Tasks.

Beide Prüfbedingungen können nacheinander angewendet werden: Zuerst wird nur ein Rechner eingesetzt, um alles festzustellen, was die Generierung von Steueraktionen betrifft, und später werden zwei Rechner eingesetzt, um alles festzustellen, was das Kommunikationsprotokoll betrifft.

Die Simulationssoftware kann als ein einziges Programm entwickelt werden. Doch es ist vorteilhafter, dass die in diesen Verfahren eingesetzte Simulationssoftware modular aufgebaut ist und jedes Softwaremodul ausschließlich einzelnen Funktionen der Software zugeordnet ist.

Bei der Beschreibung der Simulationssoftware wird in besonderer Weise auf 3 Bezug genommen, die das Blockdiagramm einer Ausführungsform der Simulationssoftware gemäß der vorliegenden Erfindung darstellt; ein Benutzer der Simulationssoftware wird mit U bezeichnet; mit DF und DL werden die physikalischen bzw. die logischen Daten bezeichnet, die kennzeichnend für die Instanz sind, welche die Simulationssoftware simuliert, genauer gesagt die von diesen Daten belegten Speicherbereiche.

Die Spezialisierung sowohl des einen Programms als auch der verschiedenen Module kann auf zwei Weisen erfolgen: Entweder dadurch, dass die Spezialisierungsinformationen nur einmal (typischerweise während der Initialisierungsphase) berücksichtigt und (vollständig) ausgeführt werden, oder dadurch, dass die Spezialisierungsinformationen dann, wenn dies angefordert wird (während der gesamten Ausführung der Simulationssoftware) berücksichtigt, interpretiert und (innerhalb der Grenzen des Erforderlichen) ausgeführt werden.

Für alle diese drei Verfahren kann die Simulationssoftware vorteilhafterweise mit einem Benutzeroberfläche-Softwaremodul MSI ausgestattet werden, das dafür geeignet ist, das Schreiben und/oder Lesen der physikalischen und/oder logischen Daten durch den Benutzer U zu ermöglichen. Auf diese Weise kann der Benutzer ohne weiteres die Simulationsstrategie festlegen, indem er die Steuerung des Status und/oder die Überprüfung des Betriebs des Gerätes und/oder seiner Platinen auswählt, was das Gegenteil dessen ist, was während des Standardbetriebs geschieht, aber auch die Überprüfung des Status und/oder die Steuerung des Betriebs des Gerätes und/oder seiner Platinen, wie es während des Standardbetriebs geschieht.

Dieses Benutzeroberfläche-Softwaremodul kann dafür geeignet sein, auf der Grundlage der physikalischen und/oder logischen Daten spezialisiert zu werden, die an die Simulationssoftware nach ihrer Aktivierung geliefert werden. Das Benutzeroberfläche-Softwaremodul MSI kann die gegebenenfalls vorhandenen Anzeigeattribute der Daten nutzen. Auf diese Weise wird die Benutzung der Benutzeroberfläche einfacher.

Dank des oben beschriebenen Modells ist gezeigt worden, wie es möglich ist, dass das Steuersystem physikalische Daten handhabt, die zu einer vorher festgelegten und begrenzten Anzahl von Typen und Größen gehören. Die drei erwähnten Verfahren können vorteilhafterweise von diesem Merkmal des Steuersystems Gebrauch machen, indem sie vorsehen, dass die Simulationssoftware in der Lage ist, physikalische Daten zu handhaben, die diese Merkmale aufweisen; dadurch wird in der Tat die Datenverwaltung vereinfacht.

In diesem Fall kann die Simulationssoftware in der Anfangsphase der Spezialisierung vorteilhafterweise insbesondere die physikalischen Daten DF in Registern RF-1, RF-2, RF-3 ... RF-i zusammenfassen, die alle dieselbe Größe besitzen. Auf diese Weise wird der Austausch der Steuerinformationen einfacher, da er auf gleichen Registern basiert und nicht auf Daten, die ein unterschiedliches Format aufweisen.

Dessen ungeachtet ist es für die Einheitlichkeit der Datenverarbeitung vorteilhaft, auch die logischen Daten DL in Registern RL-1, RL-2 ... RL-j zusammenzufassen, die alle dieselbe Größe besitzen, welche der Größe der Register RF der physikalischen Daten DF entspricht.

Dank des oben beschriebenen Modells ist gezeigt worden, wie es möglich ist, dass das Steuersystem die Steuerung eines Gerätes mit Hilfe einer zuvor festgelegten und begrenzten Anzahl von Aktionstypen des Steuersystems durchführt.

Die drei oben beschriebene Verfahren können vorteilhafterweise von diesem Merkmal des Steuersystems Gebrauch machen, indem sie vorsehen, dass die Simulationssoftware ein Anwendungs-Softwaremodul MSA umfasst, das in der Lage ist, Steueraktionen A-1, A-2, A-3, A-4 ... A-k der Instanzen in einer zuvor festgelegten und begrenzten Anzahl auszuführen; dadurch wird die Software in der Tat vereinfacht und ist leichter zu prüfen.

Die in den drei Verfahren eingesetzten Simulationssoftwaremodule können vorteilhafterweise ein Kommunikations-Softwaremodul MSC umfassen, das dafür geeignet ist, die Kommunikation mit anderen Steuerinstanzen CE, CO zu handhaben; die Kommunikationsaspekte der Simulationssoftware können nämlich separat geprüft werden, und zusätzlich wird es einfacher, die Simulationssoftware entsprechend unterschiedlicher Kommunikationstypen (sowohl unter physikalischen als auch logischen Gesichtspunkten) anzupassen, die in Steuersystemen und unterschiedlichen Geräten oder während der Phasen unterschiedlicher Tests genutzt werden.

Die Simulationssoftwaremodule, die in den drei oben beschriebenen Verfahren genutzt werden, sehen eine Spezialisierung vor; in dieser Hinsicht ist es vorteilhaft, dass diese Verfahren ein Interpretations-Softwaremodul MSS umfassen, das dafür geeignet ist, die Spezialisierungsinformationen zu lesen, sie zu interpretieren und die Spezialisierung zu veranlassen.

Ein solches Modul MSS kann nur einmal während der Anfangsphase in Betrieb sein oder es kann, was vorteilhafter ist, während der gesamten Ausführung der Simulationssoftware aktiv bleiben; in diesem letztgenannten Fall ist es vorteilhaft, vorzusehen, dass dann, wenn ein der Spezialisierung unterliegender Betrieb erforderlich ist, das Modul MSS einbezogen wird, welches die Spezialisierungsinformationen interpretiert und die erforderliche Spezialisierung des Betriebs festlegt.

In 3 ist das Modul MSS durch kurze gestrichelte Linien mit den Modulen MSI und MSA sowie mit den physikalischen Daten DF und den logischen Daten DL verbunden, und zwar, um lediglich anzugeben, dass die letztgenannten eine Spezialisierung durch das Modul MSS erfordern; das Diagramm in 3 beabsichtigt nicht, zu spezifizieren, wie diese Spezialisierungsphase stattfindet.

Die oben beschriebenen Prüfverfahren sehen für ihre Umsetzung die Nutzung entsprechender Simulationssoftwareprodukte vor; auch diese Softwareprodukte fallen in den Geltungsbereich der vorliegenden Erfindung.

Diese Simulationssoftwaremodule werden im Allgemeinen in die magnetischen oder optischen oder auf Halbleitern basierenden Speicher für Rechner geladen; auch diese Speicher fallen in den Geltungsbereich der vorliegenden Erfindung.

Unter Bezugnahme auf 2 betrifft die vorliegende Erfindung schließlich auch einen Rechner EL zum Prüfen der Steuersoftware von Steuersystemen eines Telekommunikationsgerätes durch die oben erwähnten Verfahren, umfassend mindestens:

• • einen Prozessor P-E;
• • Speichermittel MM-E; und
• • Kommunikationsmittel RT-E für die Kommunikation mit den Instanzen CE und/oder CO des Steuersystems;

Die Speichermittel MM-E umfassen im Allgemeinen sowohl Halbleiterspeichergeräte als auch eine oder mehrere magnetische und/oder optische Speicherplatten.

In 2 ist der Rechner EL mit einer Instanz CE oder CO des Steuersystems über ein Kabel CV verbunden. In der Instanz CE, CO sind ein allgemeiner Prozessor PP, einige allgemeine Speichermittel MM und allgemeine Kommunikationsmittel RT dargestellt.

Aus dem Beschriebenen wird klar ersichtlich, dass die vorliegende Erfindung Prüfwerkzeuge und Verfahren von großer Flexibilität und einfacher Anwendung bereitstellt, die auch sehr komplexe Prüfungen ermöglichen.