PatentDe  


Dokumentenidentifikation DE19755129A1 17.06.1999
Titel Laststeuerung und Überlastschutz für ein Echtzeit-Kommunikationssystem
Anmelder Telefonaktiebolaget L M Ericsson (publ), Stockholm, SE
Erfinder Holmskär, Stig, Karlstad, SE
Vertreter HOFFMANN · EITLE, 81925 München
DE-Anmeldedatum 11.12.1997
DE-Aktenzeichen 19755129
Offenlegungstag 17.06.1999
Veröffentlichungstag im Patentblatt 17.06.1999
IPC-Hauptklasse H04M 3/24
IPC-Nebenklasse H04M 3/42   H04Q 3/545   
Zusammenfassung Zum Erzielen einer Steuerung sämtlicher relevanter Ereignisse in einem Echtzeit-Kommunikationssystem wird ein Lastregulierverfahren für eine Zentraleinheit in diesem Echtzeit-Kommunikationssystem derart vorgeschlagen, daß zumindest ein Job an eine Jobpuffervorrichtung (18) abgegeben wird, die eine vorspezifizierte Speicherkapazität bereitstellt. Ferner werden in der Puffervorrichtung (18) gespeicherte Jobs an eine Bearbeitungsvorrichtung (22) für die weitere Verarbeitung abgegeben. Gemäß der Erfindung wird die in der Puffervorrichtung (18) verfügbare Speicherkapazität dynamisch in Übereinstimmung mit der tatsächlich eingesetzten Jobpufferkapazität nach jedem Lastregulierintervall aktualisiert. Somit ist es möglich, sämtliche Hauptereignisss und Prozesse in dem Echtzeit-Kommunikationssystem zu steuern.

Beschreibung[de]
GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft eine Laststeuerung und einen Überlastschutz für ein Echtzeit-Kommunikationssystem.

HINTERGRUND DER ERFINDUNG

Der Zweck der Laststeuerfunktion besteht im Aufrechterhalten eines hohen Durchflusses von erfolgreich gehandhabten Anrufen während einer Überschreitung der Kapazität in einem Echtzeit-Kommunikationssystem. Dies wird durch Regulierung der angenommenen Anrufintensität erzielt, sowie durch Regulierung der Zahl derjenigen vorliegenden Anrufe, die sich in dem Echtzeit-Kommunikationssystem abkoppeln lassen, und zwar unter Berücksichtigung der Lastsituation eines Zentralprozessors. Die Lastregulierfunktion beeinflußt nicht den Verkehrsablauf in normalen Verkehrssituationen, jedoch ist sie vorgesehen, um das Vorliegen eines außerordentlich hohen Umfangs angeforderter Anrufverbindungen und/oder abzutrennender Anrufe und somit eines Fehlers in dem Echtzeit-Kommunikationssystem zu vermeiden.

Üblicherweise kann ein Anruf in mehrere Jobs unterteilt werden, die von dem Echtzeit-Kommunikationssystem handzuhaben sind.

Da die von dem System gehandhabten Jobanforderungen Echtzeitanforderungen aufweisen können, beispielsweise Wähltonverzögerung und Durchgangsverbindungsverzögerung nach dem ITU-T-Standard, muß das System in der Lage sein, eine Überlastsituation handzuhaben. Überlastsituationen können dann auftreten, wenn mehr Jobs pro Zeiteinheit angeboten werden, als das System handhaben kann. Dies bedeutet, daß das System einer hohen Last ausgesetzt ist und nicht in der Lage ist, sämtliche angebotenen Jobs zu akzeptieren. In anderen Worten kann eine Überlastsituation als ein Spitzenwert angebotener Jobs angesehen werden, der zu lange vorliegt.

Jedoch ist es unabhängig von der Tatsache, daß ein Spitzenwert angebotener Jobs in Abhängigkeit von der Eigenschaft der betrachteten Jobs möglicherweise zu einer Überlast beispielsweise von Jobpuffern führt, nicht zwingend erforderlich, daß das System in dem Maße überlastet ist, daß Echtzeitanforderungen nicht gewährleistet werden können. Andererseits kann die Zahl angebotener Jobs zu einer Überlast des Systems derart führen, daß Echtzeitanforderungen nicht erfüllbar sind, obgleich die Jobpuffer nicht überlastet sind. Hieraus folgt, daß eine Überlastsituation entweder auf die Jobpuffer oder einen Zentraprozessor CP oder auf beide Einheiten gleichzeitig zurückzuführen sein kann.

Ein Beispiel für ein Laststeuer- und Überlastschutzsystem zum Vermeiden einer Überlastsituation ist in den Fig. 32 und 33 gezeigt und beschrieben in Ericsson Review Nummer 3, 1995. Dieses Beispiel betrifft die Laststeuerung und den Überlastschutz eines Zentralprozessors CP zum Handhaben von anrufbezogenen Ereignissen und anderen Datenkommunikationsprozessen in einem SPC-Telefoniersystem. Ein derartiges System ist so entworfen, daß es eine vorgegebene Arbeitslast von Anrufverbindungen und zugeordneten Jobs handhaben kann.

Ein Problem im Zusammenhang mit diesem Kontext besteht beispielsweise darin, wie der Zentralprozessor CP vor einem Leistungseinbruch zu schützen oder ein Systemfehler in dem Fall zu vermeiden ist, in dem der Verkehr intensiver als unter normalen Bedingungen ist. Beispiele für derartige Situationen sind Fernsehbefragungen, bei denen eine große Zahl von Teilnehmern gleichzeitig Anrufe initiiert, die von Gebietsprozessoren RP übertragen werden, oder ferner Netzfehler aufgrund von Spitzenlasten. Werden in derartigen Situationen keine Maßnahmen getroffen, so führt dies ggfs. zu einer erhöhten Dichte und zu einem Überlauf von Jobpuffern JB in denen Jobs in Warteschlangen eingefügt werden. Die Konsequenz wäre ein erneuter Start des Systems und ggfs. eine Unterbrechung der Abtastung externer Anforderungen.

Wie in Fig. 32 gezeigt, ist eine Einheit zum Handhaben von Gebiets- bzw. Ortsprozessoren RPH vorgesehen, die die Signalgebung zu und von den Gebietsprozessoren RP handhaben. Bevor die Einheit zum Handhaben der Gebietsprozessoren RPH irgendwelche externen Signale - beispielsweise Signale der Gebietsprozessoren - an die zugeordneten Jobpuffer in dem Zentralprozessor CP verteilt, wird die Belegungsdichte des Jobpuffers überprüft. Diese Vorgehensweise wird gewählt, um die Jobpuffer nicht durch ein Verteilen von Signalen an die Jobpuffer schneller aufzufüllen, als der Zentralprozessor CP Signale von den Jobpuffern holen und den durch jedes Signal initiierten Job durchführen kann. Sollte dies der Fall sein, so würde die Einheit zum Handhaben der Gebietsprozessoren RPH die Verteilung einzelner Signale an die Jobpuffer JP in dem Zentralprozessor CP solange unterbrechen, bis die Überlastsituation abnimmt.

Ebenso unterbricht die Einheit zum Handhaben der Gebietsprozessoren RPH die Verteilung externer Signale an den Zentralprozessor CP für eine bestimmte Zeit, wenn der Zentralprozessor permanent während einer langen Zeitdauer überlastet ist. Diese Vorgehensweise wird gewählt, damit der Zentralprozessor CP in den Jobpuffern in Warteschlangen eingefügte Jobs holen und durchführen kann, und damit ggfs. die Prozessorüberlastsituation beendet wird.

Demnach führt die Einheit zum Handhaben der Gebietsprozessoren RPH eine autonome Durchlaufsteuerung für externe Signale durch, die zu dem Zentralprozessor CP gelangen, und zwar im Hinblick auf die Jobpufferbelegung, d. h. die Jobpufferlast. In gewissem Umfang ermöglicht die Einheit zum Handhaben von Gebietsprozessoren auch das Vermeiden einer fortdauernden Prozessorüberlast mit langer Dauer, und zwar mittels eines Überlastschutzes (nicht zu verwechseln mit einer Laststeuerung, die im folgenden beschrieben wird).

Ein Signal bzw. mehrere Signale, die in eine Warteschlange bei irgendeinem der Jobpuffer eingereiht sind, werden von dem Betriebssystem des Zentralprozessors CP abgerufen und an die zugeordnete Anwendungssoftware zum Durchführen der entsprechenden Bearbeitung verteilt. Da viele optionale Anwendungen ablaufen können, muß die Laststeuerung in Wechselspiel mit der Anwendungssoftware durchgeführt werden, da lediglich bei der Anwendungssoftware Information über die Art des empfangenen Signals vorliegt, beispielsweise ob es im Zusammenhang mit einem bereits aktivierten Anruf steht, oder mit dem Abtrennen eines Anrufs oder mit einem neuen Anruf, für den ein Prozessorlastanteil anzufordern ist. Beispielsweise kann für Meldungen in einem Dienststeuerpunkt SCP eines intelligenten Netzes Prozessorlast zum Initiieren, Fortführen und Beenden von Meldungen angefordert werden.

Jede Anwendung fordert Prozessorlastkapazität von einer Laststeuerfunktion an. Diese Laststeuerfunktion nützt eine Hierarchie von beispielsweise 16 Anrufpuffern CP, in denen Anforderungen zeitweise gespeichert sind, wenn ihnen nicht Kapazität unmittelbar zugeordnet wird, solange, bis der Anrufaufbau fortgeführt wird. Durch Einsatz mehrerer Puffer ist es möglich, Anrufprioritäten so handzuhaben, daß Anrufanforderungen mit unterschiedlichen Prioritäten in unterschiedlichen Puffern gespeichert sind.

Wie in Fig. 32 gezeigt, wird in dem Fall, in dem eine Anrufanforderung bei der Einheit zum Handhaben der Gebietsprozessoren RPH angelangt, diese analysiert, um denjenigen Jobpuffer JP zu bestimmen, dem sie zuzuordnen ist. Hierbei kann die Anrufanforderung unmittelbar aufgrund unzureichender Pufferkapazität zurückgewiesen werden oder in den festgelegten Jobpuffer plaziert werden.

Die Übertragung von dem Jobpuffer zu dem Zentralprozessor CP wird anschließend bei regulären Intervallen durch Abrufen akzeptierter Jobanforderungen aus den Jobpuffern JP zu dem Zentralprozessor CP durchgeführt. Um zu gewährleisten, daß die auf den Zentralprozessor CP während einer Überlastsituation einwirkende Arbeitslast in der Nähe von dessen Belastbarkeitsgrenze liegt, wird die Zahl abgerufener Jobanforderungen reguliert. Hierbei legt die Regulierung einen oberen Grenzwert für die Zahl der Anforderungen fest, die zu jedem Zeitpunkt abgerufen werden. Diese Grenze wird nochmals während jedem Regulierintervall angeglichen, beispielsweise einmal pro Sekunde. In dem Fall, in dem die Last des Zentralprozessors CP über einem bestimmten systemabhängigen Pegel liegt, wird die maximale Zahl der abgerufenen Anforderungen reduziert. Ferner wird in dem Fall, in dem die Last unterhalb eines systemabhängigen Pegels liegt, die Grenze erneut angehoben. Insgesamt besteht die Aufgabe darin, die Last des Zentralprozessor CP während einer Überlastsituation nahe an der Lastgrenze des Zentralprozessors CP zu führen.

Demnach sind bei der Laststeuerung Mechanismen vorgesehen, um den Durchsatz von angeforderten Jobs mit Echtzeitanforderungen hoch zu halten, bei konstanter oder leicht variierender Überlast. Hierfür wird die Rate reguliert, mit der für neue Anrufe Dienste bereitgestellt werden, und zwar in dem Fall einer hohen Last des Zentralprozessors CP. Hierbei werden insbesondere Jobs im Zusammenhang mit ankommenden Anrufen dann abgewiesen, wenn die Last zu hoch ist. Insgesamt ist der Laststeuermechanismus so entworfen, daß er sich in Situationen robust verhält, die zahlreiche Arten von Überlast an Verkehrsmischtypen aufweisen, damit ein geeigneter Durchsatz aufrecht erhalten wird und kurze Verzögerungen vorliegen, in Übereinstimmung mit dem Telekommunikations-Standardsektor der internationalen Telekommunikationsunion ITU-T.

Die Fig. 33 zeigt typische Laststeuereigenschaften. Das obere Diagramm in Fig. 33 zeigt einen Vergleich des Jobdurchsatz gegenüber dem vorliegenden Verkehr ohne Laststeuerung (gestrichelte Linie) und mit Laststeuerung (durchgezogene Linie). Wie in Fig. 33 gezeigt, erreicht der Durchsatz ohne Laststeuerung schnell einen Pegel von Null in dem Fall, in dem keine Vorsichtsmaßnahmen getroffen werden, wohingehend sich andererseits ein Durchsatz in der Nähe des Maximums aufrecht erhalten läßt. Entsprechend steigt ohne Laststeuerung, wie im unteren Diagramm der Fig. 33 gezeigt, die Verzögerungszeit erheblich an, während sie im Fall der Laststeuerung im wesentlichen konstant ist.

Ein wichtiges Prinzip im Zusammenhang mit der Laststeuerung wird als Rückführung der Überlast bezeichnet (back pressure) und besteht darin, Verkehrsdichte zu den Quellen, die die Überlast erzeugen, zurückzuführen. Allgemein wird Lastrückführung bei Signalgebungsverkehr durch einen Zentralprozessor durchgeführt, der entweder mehr Signale empfängt, als er handhaben kann, oder bei einem Zentralprozessor, der beispielsweise aufgrund eines Staus in anderen Vermittlungen keine Signale übertragen kann. Innerhalb einer bestimmten Vermittlung wird eine Lastrückführung durch Reduzierung der zu einem Zentralprozessor CP geführten Signale erreicht.

Weitere Verfahren sind das Abstandsverfahren (gapping method), bei dem eine begrenzte Zahl von Anforderungen pro Zeiteinheit akzeptiert wird und eine Blockierung erfolgt, bei der alle betroffenen Anforderungen zurückgewiesen werden.

Zudem werden sogenannte Lastschutzmechanismen eingesetzt. Sie dienen zum Schutz des Systems gegenüber einer Überlast von Anrufen aufgrund des Verkehrs, der sich durch die oben erwähnten Laststeuerfunktionen nicht steuern läßt. Ein typisches Beispiel besteht in der schnellen Zunahme der Dichte der Anrufsversuche, auf die die Laststeuerung nicht angepaßt ist. Derartige Situationen führen zu einem unkontrollierten Verlust von Signalen und zur Aktivierung von Wiederherstellungsmechanismen, beispielsweise einem erneuten Start des Systems. Üblicherweise sind Überlastschutzmechanismen so entworfen, daß sie gravierende Überlastbedingungen schnell detektieren und zudem schnell so darauf reagieren, daß Alarmpegel bei bestimmten Puffern aktiviert werden. Das Aktivieren eines Alarmpegels führt zum Reduzieren des Signalflusses zu dem Puffer solange, bis die Pufferbelegung auf einen normalen Pegel zurückkehrt; dies wird auch als Abtast-Stopmechanismus bezeichnet. Eine weitere Option bestünde in dem einfachen Unterbrechen der Übertragung von Jobs aus den Anrufpuffern zu dem Zentralprozessor, bis die Überlastsituation beendet ist.

Jedoch besteht mit den bestehenden und oben beschriebenen Konzepten ein Problem dahingehend, daß Jobs im Zusammenhang mit Anrufunterbrechungen und bestimmten anderen anrufbezogenen Ereignissen nicht reguliert sind. Der Grund hierfür besteht darin, daß momentan davon ausgegangen wird, daß Anrufabtrennvorgänge normalerweise der Intensität der geregelten Anrufaufbaujobs folgen. Es ist zu erwähnen, daß dies lediglich unter normalen Umständen zutrifft, und daß zahlreiche Ereignisse in einem System selbst oder einem Netzwerk vorliegen, die zu erheblichen Irregularitäten führen, beispielsweise bei Anrufabtrennvorgängen und anderen anrufbezogenen Ereignissen.

Wie oben in bezug auf die Fig. 32 dargestellt, besteht eine Option zum Schützen des Zentralprozessors CP gegenüber Überlast darin, die Belegung der Jobpuffer JP zu begrenzen und die Abgabe neuer Jobs an den Zentralprozessor CP zu stoppen. Jedoch führt dies lediglich zu einem Schutz gegenüber extern initiierten Jobs und lediglich bis zu einem bestimmten Umfang. Ferner bleibt bei dieser Vorgehensweise unberücksichtigt, daß sogenannte Ausdehnungsfaktoren (extension facts) für Signale im Zusammenhang mit unterschiedlichen Jobs existieren, d. h. der Umfang der tatsächlich genützten Kapazität bei einem Jobpuffer variiert, sobald ein Job zu dem Jobpuffer zugelassen ist. Lediglich die Zahl der zu dem Jobpuffer zugelassenen Jobs wird gesteuert. Dies kann zu einer erheblichen Überlast bei dem Jobpuffer dann führen, wenn Signale mit hohen Ausdehnungsfaktoren betroffen sind. Dies führt zu einem anderen Nachteil dahingehend, daß die Jobpuffer eine große zusätzliche Kapazität aufweisen müssen, um mit einer möglichen Signalvervielfachung, einem Aufteilen der Signale und einer Signaldatenexpansion umgehen zu können.

Eine weitere momentan eingesetzte Option besteht in dem Einsatz der Jobpuffer-Belegungsgrenze, bei der die Last der Regulierfunktion für den Zentralprozessor CP die Verteilung neuer Anrufverbindungsanforderungen sowie anderer Jobanforderungen stoppt. Jedoch ist es hierbei nicht möglich, einen Einfluß auf beispielsweise Anrufabtrennvorgänge und andere anrufbezogene Jobs zu nehmen, und allgemeiner auf Jobs, die keinen Zugriff auf die Prozessorlast auf diesen Reguliermechanismus durchführen.

Für nicht regulierte Jobs besteht ein anderes Verfahren im Aufteilen dieser Jobs auf unterschiedliche Phasen, damit die Last gleichmäßig verteilt wird. Während dieses einfache statistische Verfahren für bestimmte einfache System ausreicht, ist es in großen, komplexen Systemen nicht zuverlässig genug.

Anhand der obigen Ausführungen zeigt sich, daß bei wachsenden Systemen und zunehmender Komplexität die Anforderung für die Koordination zwischen Jobs im Zusammenhang mit anrufbezogenen Ereignissen, Wartungsereignissen und anderen möglichen Ereignissen zunimmt. Zudem wird die Aufgabe schwieriger, einen Überblick über unterschiedliche Funktionen zu gewinnen und Ereignisse vorherzusagen, die gleichzeitig auftreten können, miteinander wirken und zu störenden Überlastsituationen führen können, was zu einer erhöhten Verdichtung der Jobpuffer des Zentralprozessors führt.

ZUSAMMENFASSUNG DER ERFINDUNG

Im Hinblick auf die obigen Ausführungen besteht die Aufgabe der Erfindung in der Erzielung einer Steuerung sämtlicher relevanter Ereignisse in einem Echtzeit-Kommunikationssystem.

Gemäß einem ersten Aspekt der Erfindung wird diese Aufgabe gelöst durch ein Lastregulierverfahren für eine Zentraleinheit in einem Echtzeit-Kommunikationssystem, enthaltend die Schritte: Abgeben zumindest eines Jobs an eine Puffervorrichtung, die eine vorspezifizierte Pufferkapazität bereitstellt, Abgeben des in der Puffervorrichtung gespeicherten Jobs an eine Bearbeitungsvorrichtung für die weitere Bearbeitung, und dynamisches Aktualisieren der verfügbaren Pufferkapazität der Puffervorrichtung entsprechend der tatsächlich verwendeten Jobpufferkapazität nach jedem Lastregulierintervall.

Ein wichtiger Vorteil des erfindungsgemäßen Verfahrens besteht darin, daß es möglich ist, eine Steuerung sämtlicher relevanter Ereignisse und Prozesse in dem Echtzeit-Kommunikationssystem durchzuführen. Zudem ist der Steuermechanismus nicht auf das Systemniveau beschränkt, sondern kann in gewissem Umfang auch auf eine Anwenderfunktion verteilt werden. Zusätzlich ermöglicht der Wirkungsgrad des Lastregulierverfahrens einen geringen zusätzlichen Aufwand innerhalb des Echzeit-Kommunikationssystems, was bisher eines der Argumente gegen die Regulierung beispielsweise der Anrufabtrennvorgänge darstellt.

Zudem ergibt sich im Fall normaler Betriebsbedingungen durch das erfindungsgemäße Lastregulierverfahren keine Verzögerung bei einer Zuführung von Anforderungen.

Weiterhin wird gemäß einem zweiten Aspekt der vorliegenden Erfindung diese Aufgabe erzielt durch ein Lastregulierverfahren für eine Zentraleinheit in einem Echtzeit-Kommunikationssystem, enthaltend die Schritte: Abgeben zumindest eines Jobs an eine Puffervorrichtung, die eine vorspezifizierte Pufferkapazität für jede von mehreren Jobdurchführungs-Prioritätsebenen bereitstellt, Abgeben der in der Puffervorrichtung gespeicherten Jobs an eine Bearbeitungsvorrichtung für die weitere Bearbeitung jeweils entsprechend der Jobdurchführungs-Prioritätsebene, Unterbrechung einer Arbeitseinheit auf einer unteren Jobdurchführungs-Prioritätsebene, falls ein Job auf einer höheren Jobdurchführungs-Prioritätsebene an die Puffervorrichtung abgegeben wird, Durchführen einer dynamischen Steuerung der Last der Berechnungsvorrichtung durch Senden eines Schleifensignals (loop signal) an eine niedrigere Prioritätsebene, wenn die belegte Jobpufferkapazität die maximal verfügbare Jobpufferkapazität auf einer höheren Prioritätsebene erreicht, und Wiederaufnahme der Bearbeitung von Jobs auf der höheren Prioritätsebene, wenn eine Bestätigung auf dieser Ebene nach der Bearbeitung des Schleifensignals auf der unteren Prioritätsebene empfangen wird.

Neben den oben im Zusammenhang mit dem ersten Aspekt der Erfindung erläuterten Vorteilen ist es gemäß dem zweiten Aspekt der Erfindung möglich, zwischen der Priorität unterschiedlicher unterbreiteter Jobs bzw. Prozeßvorgänge zu unterscheiden und eine Regulierung hierfür zu erzielen.

Ferner erlaubt der Schleifensignal-Sendemechanismus gemäß der vorliegenden Erfindung eine sehr wirksame dynamische Steuerung der Prozessorlast. Der Grund hierfür besteht darin, daß sobald ein Schleifensignal zu einer niedrigeren Ebene in dem Fall gesendet wird, in dem die maximal verfügbare Kapazität auf einem höheren Level beansprucht ist, und sobald die Bestätigung der Bearbeitung dieses Schleifensignals auf der höheren Ebene erneut auf der oberen Prioritätsebene empfangen wird, dies einen klaren Hinweis dahingehend darstellt, daß die Gesamtkapazität auf der höheren Ebene erneut verfügbar ist. Deshalb muß nicht auf den Start eines neuen Regulierintervalls gewartet werden, sondern die Bearbeitung kann auf der höheren Ebene unmittelbar nach Empfang der Bestätigung von der unteren Ebene wieder aufgenommen werden. Dies ermöglicht eine dramatische Verbesserung des Systemwirkungsgrads.

Gemäß einem dritten Aspekt der Erfindung wird die Aufgabe der vorliegenden Erfindung gelöst durch eine Lastreguliereinheit für ein Echtzeit-Kommunikationssystem, enthaltend: eine Puffervorrichtung zum Bereitstellen von Pufferkapazität für Jobs, die in dem Echtzeit-Kommunikationssystem zu verarbeiten sind, eine Bearbeitungsvorrichtung zum Handhaben der an die Puffervorrichtung abgegebenen Jobs, und eine Lastreguliervorrichtung zum dynamischen Angleichen der verfügbaren Pufferkapazität der Puffervorrichtung in Übereinstimmung mit der tatsächliche belegten Jobpufferkapazität bei Beginn jedes Lastregulierintervalls.

Gemäß dem dritten Aspekt der Erfindung lassen sich dieselben Vorteile wie bei dem ersten Aspekt der Erfindung erzielen. Ferner steht gemäß diesem dritten Aspekt die Zahl der zu dem Zentralprozessor zugelassenen Jobs, die pro Lastregulierintervall durchzuführen sind, im Zusammenhang mit der verfügbaren Jobpufferkapazität, anstelle direkt durch eine Prozessorlastregulierfunktion geregelt zu werden, wie im Stand der Technik. Hierbei wird lediglich eine bestimmte Zahl von Jobs pro Lastregulierintervall dem Zentralprozessor ausgehend von dem Jobpuffer zugeführt. Demnach wird der Zentralprozessor gegenüber einer Überlast bedingt durch eine Maximalzahl von Ereignissen oder durch unvorhergesehene Wechselwirkungen zwischen zwei oder mehreren unterschiedlichen Ereignissen geschützt, die beide jeweils andernfalls zu einer Pufferüberlastung und einer Prozessorüberlastung führen würden, derart, daß diese beiden Störungen im Ergebnis zu einer erheblichen Systemfehlfunktion führen würden.

Ferner wird gemäß einem vierten Aspekt der vorliegenden Erfindung die oben beschriebene Aufgabe gelöst durch eine Lastreguliereinheit für ein Echtzeit-Kommunikationssystem, enthaltend: eine Puffervorrichtung zum Bereitstellen von Pufferkapazität für mehrere Jobdurchführungs-Prioritätsebenen, eine Berechnungsvorrichtung zum Handhaben der an die Puffervorrichtung abgegebenen Jobs, und eine Lastregulierverfahren ausgebildet zum Abgeben eines Jobs an die Puffervorrichtung gemäß der jeweiligen Jobdurchführungs-Prioritätsebenen und der der Jobdurchführungs-Prioritätsebene zugeordneten Pufferkapazität, Senden eines Schleifensignals an eine niedrigere Prioritätsebene, wenn die in der Puffervorrichtung belegte Pufferkapazität auf der höheren Prioritätsebene die maximal verfügbare Pufferkapazität erreicht, und Wiederaufnahme der Bearbeitung von Jobs auf der höheren Prioritätsebene, wenn bei Bearbeitung des Schleifensignals auf der unteren Prioritätsebene eine Bestätigung an die höhere Prioritätsebene gesendet wird.

Somit weist jede Prioritätsebene in der Lastreguliereinheit seinen eigenen Jobpuffer für auf dieser Prioritätsebene zu unterbreitende Jobs auf. Dies ermöglicht eine Unterscheidung der Prioritäten unterschiedlicher Jobs, die üblicherweise mit gleicher Priorität betrachtet wurden. Zudem läßt sich die Prozessorlast indirekt über die Zeit verteilen und minimieren, gemäß den Sicherheitsredundanzen des Systems. Zudem wird jede möglicherweise auftretende Überlastsituation schnell und wirksam gehandhabt.

Ferner ist die Jobpufferkapazität-Lastregulierung nicht auf eine spezifische Prioritätsebene beschränkt, sondern sie kann alternativ oder zusätzlich auf eine oder mehrere Prioritätsebenen angewandt werden. In einem derartigen Fall ist die Jobpufferkapazität-Lastfunktion an die Unterschiede im Hinblick auf die Echtzeitanforderungen angepaßt.

Gemäß einer bevorzugten Ausführungsform der Erfindung kann eine Anwenderfunktion anzeigen, daß es sich um eine vom Typ handelt, bei dem die gesamten Anforderungen zu erfüllen sind oder bei dem Anforderungen soweit möglich zu erfüllen sind.

Hierbei wird im Rahmen der Erfindung die Tatsache berücksichtigt, daß bei bestimmten Jobs mit hohen Echtzeitanforderungen im Hinblick auf die Prozessorlast Nachteile dann auftreten, wenn die zugeordneten Anforderungen für Jobpufferkapazität in dem Fall in Warteschlangen eingereiht werden, in dem keine Jobpufferkapazität verfügbar ist. Somit ist gemäß dieser bevorzugten Ausführungsform der Erfindung die Jobpufferkapazitäts-Lastfunktion so ausgebildet, daß eine Anwenderfunktion anzeigen kann, daß ihre zugeordnete Anforderung für Jobpufferkapazität nicht in eine Warteschlange eingereiht werden kann, sondern entweder zu bestätigen oder sofort abzuweisen ist. Weiterhin läßt sich eine Jobpufferkapazitäts-Lastfunktion so modifizieren, daß verfügbare Kapazität in einem speziellen Jobpufferkapazitäts-Regulierintervall überschrieben wird, in Abhängigkeit von der Prozessorlastsituation derart, daß eine Jobpufferkapazität einer derartigen Anforderung aus der verfügbaren Jobpufferkapazität zugeordnet wird. Dies ist aufgrund der ausreichenden groß bemessenen Redundanzkapazität bei der Jobpufferkapazität möglich.

Ferner wird gemäß einer weiteren, zusätzlichen bevorzugten Ausführungsform der vorliegenden Erfindung die verfügbare Jobpufferkapazität am Beginn jedes Lastregulierintervalls erneut berechnet.

Somit ermöglicht die Berechnung der verfügbaren Jobpufferkapazität mit jedem Lastregulierintervall oder -teilintervall die Anpassung der vorhergehenden Schätzung an die momentan tatsächlich vorliegende Jobpufferbelegung. Dies ermöglicht die erneute Zuordnung einer zu großzügig abgeschätzten Jobpufferkapazität zu Beginn jedes Zeitintervalls derart, daß das dynamische Anpassen der verfügbaren Pufferkapazität zu einer erhöhten Nutzung verfügbarer Ressourcen führt.

Ferner werden gemäß einer weiteren, zusätzlichen bevorzugten Ausführungsform der Erfindung auch kritische Überlastsituationen überwacht. Insbesondere läßt sich die unterste Prioritätsebene überwachen, um jede kritische Verzögerung der Ausführungsform so zu detektieren, daß es möglich ist, die Durchführung von Jobs auf höheren Prioritätsebenen spontan zu reduzieren oder zu stoppen. Demnach ist es möglich, die Durchführungsrate auf höheren Prioritätsebenen abzusenken, um die Durchführung von Jobs auf unteren Prioritätsebenen bei kritischen Überlastsituationen zu ermöglichen.

Ferner kann gemäß einer anderen, bevorzugten Ausführungsform der Erfindung eine Interrupt von dem Betriebssystem im Fall einer hohen Jobpufferlast empfangen werden.

Somit wird im Rahmen der vorliegenden Erfindung auch eine Betriebssystemdetektion einer hohen Jobpufferlast geschaffen. Insbesondere kann im Rahmen der vorliegenden Erfindung das Betriebssystem einen störenden Anstieg der Jobpufferbelegung unmittelbar detektieren. Es kann anschließend den Lastreguliermechanismus gemäß der Erfindung anstoßen, um unmittelbar zu reagieren, beispielsweise um verfügbare Jobpufferkapazität zu löschen, an unterschiedliche Anwender verteilte Jobpufferkapazität zu löschen und sämtliche neue Jobanforderungen zu sperren. Dieses Merkmal der Erfindung ermöglicht eine noch leistungsfähigere und flexiblere Steuerung der verfügbaren Jobpufferkapazität. Zudem wird jede Systemfehlfunktion unmittelbar zu Beginn vermieden.

Ein weiteres Merkmal der vorliegenden Erfindung besteht in dem simultanen Einsatz der oben beschriebenen Regulierschritte bei mehreren Prioritätsebenen oder bei unteren Prioritätsebenen. Werden die Reguliermerkmale bei einer unteren Prioritätsebene, beispielsweise einer C-Prioritätsebene, eingesetzt, so sind sie an die Unterschiede im Hinblick auf die Echtzeitbedingungen anzupassen. Hierbei ist es erforderlich, Jobpufferkapazität solange zu belegen, bis der Job beendet ist, und anschließend kann die Kapazität von der Regulierfunktion erneut vergeben werden. Dies bedeutet auch, daß der Umfang der verteilten Jobpufferkapazität anzugleichen ist.

Es ist zu erwähnen, daß die Regulierfunktionalität gemäß der Erfindung nicht nur für zuvor nicht geregelte Funktionen einzusetzen ist. Im Gegensatz hierzu können gemäß der vorliegenden Erfindung auch bisher regulierte Funktionen mit hohen Signaldaten-Expansionsfaktoren betrachtet werden, beispielsweise ein Job, der zu mehreren Jobs oder Prozessen führt, was für eine bessere Steuerung erforderlich ist.

BESCHREIBUNG DER ZEICHNUNGEN

Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun unter Bezug auf die beiliegende Zeichnung beschrieben; es zeigen:

Fig. 1 eine Struktur eines Echtzeit-Kommunikationssystems und des Signalflusses während des Anrufaufbaus;

Fig. 2 unterschiedliche Arten von Software-Signalen, die in dem in Fig. 1 gezeigten Echtzeit-Kommunikationssystem eingesetzt werden;

Fig. 3 die Struktur von Software-Anwendungseinheiten, die in dem in Fig. 1 gezeigten Echtzeit-Kommunikationssystem ablaufen;

Fig. 4 unterschiedliche Hierarchieebenen für Anwendungen, die in dem in Fig. 1 gezeigten Echtzeit-Kommunikationssystem ablaufen;

Fig. 5 einen Abriß einer Jobdurchführung für Anwendungen, die auf unterschiedlichen Prioritätsebenen in dem in Fig. 1 gezeigten Echtzeit-Kommunikationssystem ablaufen;

Fig. 6 ein Blockschaltbild der Zentraleinheit des Echtzeit-Kommunikationssystems mit einer Lastreguliereinheit gemäß der vorliegenden Erfindung;

Fig. 7 ein detaillierteres Blockschaltbild der Lastreguliereinheit gemäß der vorliegenden Erfindung;

Fig. 8 ein Flußdiagramm gemäß dem grundlegenden Betrieb der in Fig. 7 gezeigten Lastreguliereinheit;

Fig. 9 ein Beispiel für die Vorbereitung jedes Betriebsintervalls der Lastreguliereinheit gemäß der Erfindung;

Fig. 10 ein Beispiel für die Vorbereitung jedes Teilintervalls für den Betrieb der Lastreguliereinheit gemäß der Erfindung;

Fig. 11 einen Überblick für die Handhabung der Anforderungen während eines Teilintervalls durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 12 eine Bestätigung einer Anforderung während eines Teilintervalls durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 13 das Einfügen in eine Warteschlange einer Anforderung während eines Teilintervalls durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 14 den Prozeß zum Abrufen von Anforderungen aus der Warteschlange während eines Teilintervalls durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 15 ein detaillierteres Flußdiagramm des in Fig. 14 dargestellten Prozesses;

Fig. 16 die dynamische Steuerung der Prozessorlast durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 17 ein Flußdiagramm gemäß der dynamischen Prozessorlastregulierung durch die Prozessorlasteinheit gemäß der Erfindung;

Fig. 18 die Initialisierungsschritte für jedes Teilintervalls, die von der Lastreguliereinheit gemäß der Erfindung ausgeführt werden;

Fig. 19 ein detaillierteres Flußdiagramm für die Begrenzung von Jobs während der Initialisierung eines Teilintervalls nach Fig. 18;

Fig. 20 die Bewertung der Jobpufferlasten während der Initialisierung eines Teilintervalls nach Fig. 18;

Fig. 21 das Flußdiagramm zum Abrufen von in einer Warteschlange eingefügten Anforderungen währen der Initialisierung eines Teilintervalls nach Fig. 18;

Fig. 22 ein Beispiel für die Regulierung einer Prozessorlast durch die Lastreguliereinheit gemäß der Erfindung;

Fig. 23 ein Flußdiagramm für die Regulierung der Prozessorlast gemäß den in Fig. 22 dargelegten Prinzipien;

Fig. 24 ein detaillierteres Flußdiagramm für die in Fig. 23 dargelegte Überwachung der Prozessorlast;

Fig. 25 einen Überblick über die Kopplung zwischen der Überwachung der Prozessorüberlast und der Jobpufferkapazitätsregulierung;

Fig. 26 eine Aufteilung einer verfügbaren Pufferkapazität in mehrere Anwenderspeicherbereiche;

Fig. 27 die Initialisierung der Pufferkonfigurierung während des Systemanlaufs;

Fig. 28 ein detaillierteres Flußdiagramm für die Berechnung anwenderspezifischer Jobpuffer-Speicherbereiche;

Fig. 29 die Fortführung der Berechnung nach Fig. 28;

Fig. 30 die Fortführung der Berechnung nach Fig. 29;

Fig. 31 die Detektion einer hohen Pufferlast auf Betriebssystemebene;

Fig. 32 ein Blockdiagramm für die Laststeuerung eines Zentralprozessors in einem Echtzeit-Kommunikationssystem gemäß dem technologischen Hintergrund der Erfindung;

Fig. 33 den Durchsatz und die Verzögerungseigenschaften im Zusammenhang mit dem in Fig. 32 gezeigten Funktionsblock.

BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN

Im folgenden wird eine Ausführungsform eines Echtzeit-Kommunikationssystems beschrieben, das der vorliegenden Erfindung entspricht. Üblicherweise basiert ein derartiges Echtzeit-Kommunikationssystem auf dem Konzept der Signalgebung, und ferner auf Programmstatements im Hinblick auf Signale, sowie dem Adressieren des Programmspeichers und den Rückgriff auf Jobpuffer.

Ein derartiges Echtzeit-Kommunikationssystem gemäß der Erfindung und eine typische Prozeßabfolge für einen Anrufaufbau wird unter Bezug auf die Fig. 1 beschrieben.

Wie in Fig. 1 gezeigt, hebt ein Teilnehmer einen Hörer ab, und diese Aktion wird durch eine Leitungsschnittstellenschaltung (line interface circuit) LIC detektiert. Hierbei werden alle Hardware-Einrichtungen oft und regelmäßig durch einfache Mikroprozessoren abgetastet, die als Einrichtungsprozessoren (device processors) DP bezeichnet werden. Ferner werden die Einrichtungsprozessoren DP in der Leitungsschnittstellenschaltung LIC durch Gebietssoftware (regional software) LIR abgetastet. Zum Herstellen einer Verbindung mit einer Vermittlung überträgt die Gebietssoftware die Information "Hörer auf Haken" an eine Zentralsoftware (central software) LIU, die eine kombinierte Verbindungsstelle CJ informiert. Die kombinierte Verbindungsstelle CJ initiiert bei dem Verbindungsterminal JT die Reservierung eines Kanals durch den Gruppenschalter für diesen Anruf. Der nächste Schritt besteht im Herausfinden der Tatsache, ob dem Teilnehmer irgendwelche Einrichtungen zugeordnet sind. Diese Information wird in dem Block Teilnehmerkategorien SC gespeichert.

Bei der Schnittstelle zwischen der Gebietssoftware LIR und der Zentralsoftware ist Prozessorlastkapazität für den Zentralprozessor CP in der kombinierten Verbindungsstelle CJ erforderlich. Wird diese Anforderung zurückgewiesen, so wird der Regionalsoftware LIR eine Rückweisungsmeldung zugeführt, und die Signalgebung bei dem Zentralprozessor CP im Zusammenhang mit dem initiierten Kommunikationsprozeß stoppt anschließend.

Somit wird die Kommunikation zwischen unterschiedlichen Funktionseinheiten mittels einzelner Signale durchgeführt. In anderen Worten ausgedrückt, entspricht, wie in Fig. 2 gezeigt, ein Signal üblicherweise einem Sprung von einem Funktionsblock zu einem anderen. Alle Signale zwischen unterschiedlichen Funktionsblöcken A, B werden von und zu ihrer jeweiligen Zentralsoftware LIU gesendet. Die Signale zwischen unterschiedlichen kombinierten Verbindungsstelle CJ werden als CP-CP-Signale bezeichnet. Ferner werden Signale von einer Gebietssoftware LIR zu der zugeordneten Zentralsoftware LIU als RP-CP-Signale bezeichnet, und entsprechend werden Signale von der Zentralsoftware LIU zu der Gebietssoftware LIR als CP-RP-Signale bezeichnet. Ferner wird ein Signal definiert durch seine Signalbeschreibung, in der die Zahl der Signaldaten, der Signaltyp oder Zweck des Signals, usw. festgelegt sind. Somit gibt es eine Signalbeschreibung für jedes Signal.

Wie in den Fig. 2 und 3 gezeigt, dienen Signale üblicherweise zum Verbinden bzw. Koppeln unterschiedlicher Anwendungen, die beispielsweise auf unterschiedlichen Knoten des Echtzeit-Kommunikationssystems laufen. Die meisten Signale stehen im Zusammenhang mit einem Sprung von einem Signalsendebefehl in einem Programm zu einem Signalempfangsbefehl in einem anderen Programm. Dies impliziert, daß ein Programm niemals vom Beginn zum Ende ausgeführt wird, sondern üblicherweise von einem Signalempfangsbefehl, normalerweise ENTER, zu einem Signalsendebefehl, normalerweise SEND, gefolgt von dem EXIT-Befehl. Mit dem EXIT-Befehl wird das momentane Programm verlassen und das Betriebssystem übernimmt die Koordination.

Hierbei wird im folgenden die Programmfolge zwischen dem ENTER-Befehl und dem EXIT-Befehl als Unterprogramm bezeichnet. Gemäß dem in Fig. 3 gezeigten Beispiel wird in einem Fall, in dem das Signal 3 eingegeben und das Signal 4 gesendet wird, der Programmbefehl CUSELESS = 0 niemals durchgeführt.

Während der Übertragung von Signalen in dem Echtzeit-Kommunikationssystem werden üblicherweise Verzögerungen auftreten. Der Grund hierfür besteht darin, daß die kombinierte Verbindung CJ üblicherweise mehrere Anrufe gleichzeitig handhabt, während der zugeordnete Zentralprozessor CP lediglich ein einziges Programm zu einem Zeitpunkt durchführen kann. Demnach ist es offensichtlich, daß das Signal irgendwo in eine Warteschlange eingereiht werden muß. Dies erfolgt jeweils durch Einsatz von Jobpuffern und Jobtabellen für Zeitwarteschlangen. Ferner sind aufgrund der Tatsache, daß einige Signale wichtiger sind als andere, unterschiedliche Jobpuffer mit unterschiedlichen Prioritäten vorgesehen. Ein Beispiel besteht in der Einführung von vier unterschiedlichen Jobpuffern, die jeweils durch A, B, C und D benannt sind, mit A als höchster Priorität.

Wie in Fig. 4 gezeigt, sind üblicherweise mehrere Jobpuffer für CP-CP und RP-CP-Signale vorgesehen. Diese werden beispielsweise Jobpuffer JBA, JBB, Jobpuffer JBC und Jobpuffer JBD genannt, derart, daß der Jobpuffer JBA derjenige mit der höchsten Priorität ist.

Üblicherweise wird der Jobpuffer JBA durch das Betriebssystem für dringende Aufgaben und für bevorzugte Verkehrsdaten eingesetzt. Ferner wird der Jobpuffer JBB zum Handhaben sämtlicher anderer Telefonverkehrsdaten eingesetzt, und der Jobpuffer JBC dient für die Handhabung der Eingabe/Ausgabe. Schließlich wird der Jobpuffer JBD zum Durchführen von Selbsttestaufgaben eingesetzt. Hierbei entsprechen die Jobpuffer unterschiedlichen Prioritätsebenen, und die Prioritätsebene dieses Signals wird in dessen Signalbeschreibung spezifiziert. Eine Möglichkeit besteht dann, bei jedem Puffer das first in/first out-Prinzip so anzuwenden, daß die ältesten Jobs als erstes durchgeführt werden.

Neben den Jobpuffern wird auch eine in Fig. 4 gezeigte Jobtabelle eingesetzt, die Jobs aufnimmt, die zu kurzen periodischen Intervallen durchzuführen sind, beispielsweise das Inkrementieren der Takte für die Zeitüberwachung. Da die Jobtabelle Jobs enthält, die bei kurzen periodischen Intervallen durchzuführen sind, empfängt die Jobtabelle ein Takt-Interruptsignal (clock interrupt signal) CIS, das von der Systemhardware zum Erzielen einer schnellen Durchführung der in der Jobtabelle gespeicherten Jobs gesendet wird. Somit kann die Jobtabelle zum Initiieren der Handhabung der Jobs eingesetzt werden, die in den Jobpuffern JBA bis JBD gespeichert sind.

Durch Einsatz der oben beschriebenen Systemarchitektur, sowie der Klassifikation der Signale und der Pufferstruktur wird die Handhabung in dem Echtzeit-Kommunikationssystem wie folgt durchgeführt.

Im folgenden ist ein Job definiert als fortlaufende Sequenz von Befehlen, die in dem Prozessor durchgeführt werden. Ein Job beginnt mit einem ENTER-Befehl für ein Puffersignal, und er endet mit einem EXIT-Befehl, der auf das Senden eines oder mehrerer Puffersignale folgt, wie unter Bezug auf die Fig. 3 erläutert. Bei jedem Job können direkte, einzelne und kombinierte Befehle so eingesetzt werden, daß ein Job nicht auf eine CP-Software-Anwendung begrenzt ist und daß mehrere Anwendungen im Zusammenhang mit einem Job stehen können.

In Abhängigkeit von dem Zweck und den Zeitanforderungen der Jobs werden diese bestimmten Prioritätsebenen zugeordnet, so wie in Fig. 4 gezeigt. Die durch ein periodisches Jobtabellensignal initiierten Aufgaben nützen die Verkehrshandhabungsebene THL1, JBA-Signale nützen die Verkehrshandhabungsebene THL2, JBB-Signale nützen die Verkehrshandhabungsebene THL3, JBC-Signale nützen die Basisebene BALI, und JBD-Signale nützen die Basisebene 2 BAL2. Somit weist die Jobtabelle eine höhere Priorität als alle Jobpuffer auf. Ferner weist der Jobpuffer JBA eine höhere Priorität als der Jobpuffer JBB auf, usw.

Das in Fig. 4 gezeigte Taktinterruptsignal CIS wird alle zehn Millisekunden gesendet, und es unterbricht und aktiviert die Programmdurchführung. Das CIS-Signal bestimmt das primäre Intervall des Zentralprozessors CP. Erreicht das Taktinterruptsignal CIS die Jobtabelle, so wird es abgetastet, und Arbeitseinheiten werden aktiviert. Anschließend werden die Jobs in den Jobpuffern im Zusammenhang mit den Arbeitseinheiten in der Reihenfolge der Priorität durchgeführt.

Ferner wird dann, wenn ein neuer Job in einen Jobpuffer eingefügt wird, ein Interruptsignal an die entsprechende Prioritätsebene gesendet. Hat der momentan von dem Zentralprozessor bearbeitete Job eine geringere Prioritätsebene, so wird dieser Job ebenfalls unterbrochen. Hierbei werden Interruptsignale vom JBA, JBB und JBC selbst zwischen zwei aufeinander folgenden Taktinterruptsignalen CIS erkannt. Beispielsweise muß dann, wenn ein Job auf der C-Ebene vorliegt und ein Interruptsignal von der A-Ebene kommt, dieser Interrupt nicht bis zum nächsten Taktinterruptsignal warten, sondern er kann unmittelbar durchgeführt werden.

Die Beziehung zwischen der programmebenen Priorität, dem Inhalt der Jobtabelle und dem Jobpuffer sowie den Jobtypen ist in Fig. 5 gezeigt, und kann wie folgt zusammengefaßt werden:

Ein typischer Ablauf der Jobdurchführung gemäß den oben erläuterten Regeln verläuft wie in Fig. 5 gezeigt. Hier wird ein Job auf einer D-Ebene dann durchgeführt, wenn das Taktinterruptsignal CIS ankommt. Der Job auf der D-Ebene wird unmittelbar unterbrochen, und die Jobtabelle wird abgetastet. Während dem Abtasten liegen zwei Taktinterruptsignale vor, eines von der C-Prioritätsebene und das andere von der B-Prioritätsebene. Nach dem Abtasten der Jobtabelle wird der Job der B-Prioritätsebene gehandhabt, da er die höhere Priorität aufweist. Auf die Arbeitseinheit der B-Prioritätsebene folgt dann der Wartejob auf der Job auf der C-Prioritätsebene, und anschließend kann der Job auf der D-Prioritätsebene seine Durchführung wieder aufnehmen, da keine anderen Jobs warten.

Eine kurze Zeit später wird der Job der D-Prioritätsebene erneut durch ein ankommendes Interruptsignal bei der B-Prioritätsebene unterbrochen. Während der Durchführung auf der B-Prioritätsebene kommt ein anderes Interruptsignal bei der A-Prioritätsebene an. Hierbei muß der Job auf der A-Prioritätsebene warten, bis der Job bei der B-Prioritätsebene abgeschlossen ist. Auf den Job bei der A-Prioritätsebene folgt ein Job auf der C-Prioritätsebene, der selbst wiederum durch einen Job auf der B-Prioritätsebene mit höherer Priorität unterbrochen wird. Schließlich wird der Job bei der C-Prioritätsebene durch ein anderes ankommendes Signal bei der A-Prioritätsebene unterbrochen. Während der Durchführung dieses Jobs bei der A-Prioritätsebene wird das Taktinterruptsignal CIS empfangen.

Dennoch muß die Bearbeitung der Jobtabellensignale solange warten, bis die A-Prioritätsebene abgeschlossen ist. Entsprechend sind die periodische Verzögerungszeit für die Jobtabellen-Arbeitseinheiten normalerweise nicht zu 100% genau eingehalten.

Im folgenden wird die in Fig. 6 gezeigte Lastreguliereinheit gemäß der vorliegenden Erfindung auf Basis der Systemarchitektur und der oben erläuterten Prinzipien erläutert.

Die Zentraleinheit des Echtzeit-Kommunikationssystems weist Komponenten ähnlich zu den in Fig. 32 gezeigten auf. Insbesondere enthält die Zentraleinheit einen Gebietsprozessor zum Handhaben der Schnittstelle zwischen der Jobpuffereinheit JP und dem Gebietsprozessor RP zum Betreiben entfernt gelegener Positionen (regional processorhandler) RPW. Hier sind Hauptverbindungsleitungen 10-1 und 10-2 an der Einheit zum Handhaben des Gebietsprozessors RPH angeschlossen, und ferner sind die Gebietsprozessoren mit diesen Hauptverbindungsleitungen 10-1, 10-2 jeweils über Verbindungen 12, 14, . . ., 16 verbunden. Wie unter Bezug auf Fig. 32 erläutert, kann die Einheit zum Handhaben der Gebietsprozessoren Anrufpuffer zum Durchführen einer Prioritätshandhabung bei den Anrufen aufweisen, die in der Zentraleinheit empfangen werden. Da die Funktionalität dieser Komponenten im Vergleich zum Stand der Technik im wesentlichen unverändert ist, werden sie hier nicht erläutert.

Wie in Fig. 6 gezeigt, betrifft die vorliegende Erfindung hauptsächlich die Verbindung zwischen dem Zentralprozessor 22 und dem Jobpuffer 18. Insbesondere ist gemäß der vorliegenden Erfindung eine Lastreguliereinheit 20 vorgesehen, die sowohl mit dem Zentralprozessor 22 als auch der Jobpuffereinheit 18 über eine Steuerverbindung 24 verbunden ist.

Eine detailliertere Darstellung der Lastreguliereinheit ist in Fig. 7 gezeigt. Insbesondere enthält die Lastreguliereinheit 20 eine Jobpuffer-Steuereinheit 26, eine Zentralprozessor-Überlasteinheit 28 und eine Anlaufeinheit 30. Die Funktionalität der Jobpuffer-Steuereinheit 26 besteht in der Regulierung entweder der Akzeptanzrate für extern empfangene Anrufe oder im Durchführen der internen Pufferverwaltung bei den mehreren Puffern JBA, JBB, JBC, wie in Fig. 6 gezeigt. Ferner besteht die Funktionalität der Zentralprozessor-Überlasteinheit 26 in der Überwachung der Lastbedingung der Zentralprozessor 22 zum Erzielen eines optimalen Einsatzes der durch diesen Prozessor bereitgestellten Verarbeitungskapazität. Schließlich ist die Anlaufeinheit 30 vorgesehen, um die Steuerung des Systems während des Anlaufens am unmittelbaren Beginn des Betriebs durchzuführen.

Wie in Fig. 8 gezeigt, führen die Jobpuffer-Steuereinheit 26, die Zentralprozessor-Überlasteinheit 28 und die Anlaufeinheit 30 eine wechselwirkende Durchführung von Prozeßschritten aus. Im Schritt S8-1 führt die Anlaufeinheit 30 die Funktionen zum Eintritt in den Normalbetrieb durch. Weiterhin sind nach Fig. 8 zwei Abfrageschritte S8-2 und S8-6 vorgesehen. Der erste wird zum Überprüfen des Ablaufs eines Intervalls durchgeführt, und der zweite wird zum Überprüfen des Ablaufs eines Teilintervalls durchgeführt. Es ist zu erwähnen, daß jedes Intervall mehrere Teileintervalle enthält.

Demnach wird der Betrieb der Lastregeleinheit 20 entsprechend mehreren Zeitskalen durchgeführt, die jeweils längeren oder kürzeren Teilintervallen entsprechend den unterschiedlichen Regulierschritten entsprechen. In anderen Worten ausgedrückt, werden bestimmte Regulierschritte öfter als andere Regulierschritte durchgeführt. Hierbei betrifft die innere Schleife die Teilintervalle und die Handhabung neuer ankommender Anforderungen entsprechend dem Schritt S8-5. Solange des Teilintervall nicht abgeschlossen ist (vgl. Schritt S8-6, werden diese ankommenden Anforderungen durch die Lastreguliereinheit 20 gehandhabt.

Jedoch wird jedesmal nach dem Ende eines derartigen Teilintervalls im Schritt S8-2 überprüft, ob ein größeres Teilintervall mit beispielsweisen 25 Teilintervallen à 40 Millisekunden abgeschlossen ist. Wird diese Abfrage bejaht, so wird das nächste Intervall im Schritt S8-3 vorbereitet. Dieser Schritt dient zum Durchführen von Regulierschritten, die im folgenden beschrieben werden. Ist jedoch dieses Intervall nicht abgeschlossen, oder anders ausgedrückt, in dem Fall, in dem beispielsweise 25 Zeitintervalle nicht nacheinander durchgeführt wurden, werden lediglich die Schritte zum Vorbereiten des nächsten Zeitintervalls im Schritt S8-4 durchgeführt.

Wie in Fig. 9 gezeigt, wird der Betrieb der Lastregeleinheit 20 somit anhand unterschiedlicher Zeitskalen durchgeführt, die über Intervalle und Teilintervalle spezifiziert sind und im Zusammenhang mit unterschiedlichen Echtzeitanforderungen für den Systembetrieb stehen. Wie im folgenden gezeigt, ermöglicht diese wechselwirkende Durchführung von Regulierschritten einen sehr wirksamen Schlitz gegen Überlast des Signalprozessors 22 und der Jobpuffer JBA, JBB, JBC, . . . in der Jobpuffereinheit 16.

Die Fig. 9 zeigt das Konzept, das den Regulierschritten zugrundeliegt, die bei jedem Intervall von beispielsweise einer Sekunde durchgeführt werden, vgl. Schritt S8-3 in Fig. 8. Dieser Schritt beruht auf dem Konzept der Anrufsakzeptanzgrenze (call acceptance limit), nachdem die Zahl der der Zentraleinheit zum Durchführen eines Diensts zugeführten Anrufe begrenzt ist. Wie in Fig. 9 gezeigt, steht diese Anrufakzeptanzgrenze CAL im Zusammenhang mit der Prozessorlast.

Insbesondere fordert am Ende jedes Intervalls die Lastreguliereinheit 20 den Wert der Prozessorlast der vorhergehenden Intervalle an. Die Lastreguliereinheit 20 nützt diese Lastwerte über die vorhergehenden beispielsweise fünf Intervalle zum Berechnen und Aktualisieren der Anrufsakzeptanzgrenze für das nächste Intervall.

Insbesondere wird die gesamte Prozessorlast durch Gewichtung der Prozessorlastwerte für die letzten fünf Intervalle berechnet, beispielsweise entsprechend





In dem Fall, in dem der Wert PL zwischen der oberen Grenze PLmax und der unteren Grenze PLmin liegt, bleibt der Wert von CAL für das nächste Intervall unverändert. Liegt jedoch der Wert von PL oberhalb der oberen Grenze PLmax, so wird die Anrufsakzeptanzgrenze CAL folgendermaßen verringert



CAL ←(FR.α)/100 (2)



FR ist hierbei die Zahl der während des vorhergehenden Intervalls angenommenen Anforderungen, und α ist ein anwendungsabhängiger Verringerungsfaktor. Bei gewöhnlichem Verkehrsmix nimmt der empfohlene Wert von α einen Wert von 98 an.

Zudem darf der Wert der Anrufsakzeptanzgrenze CAL nicht unter einem Minimalwert CALmin absinken, der durch Befehl festgelegt ist. Dieser Minimalwert CALmin wird benützt, um die Reservierung einer bestimmten Menge der Prozessorkapazität für die Anrufhandhabung zu gewährleisten. Fällt ein Wert der Größe PL unter die untere Grenze PLmin, so wird die Anrufakzeptanzgrenze CAL erhöht entsprechend





β ist ein Parameter mit einem empfohlenen Wert von 660.

Weiterhin soll der Wert der Anrufaktzeptanzgrenze CAL nicht über einen Maximalwert von CALmax ansteigen, der ebenfalls durch einen Parameter verändert wird. Die maximale Anrufsakzeptanzgrenze CALmax wird auf einen Wert gesetzt, der erheblich höher als die Kapazität des Zentralprozessors 22 ist. Somit können kurze Spitzenwerte bei den Anrufeinläufen akzeptiert werden, und ist die Ankunftsintensität lediglich während einer kurzen Zeitperiode hoch, so besteht keine Anforderung zum Abweisen von Anrufen, da genügend Prozessorkapazität zur Verfügung stehen wird.

Insgesamt zeigt die Fig. 9 die während dem Schritt S8-3 getroffenen Maßnahmen zum Spezifizieren der Maximalzahl der während jedes Teilintervalls akzeptierten Anforderungen, die während mehrerer Teilintervalle konstant gehalten wird und lediglich für jedes Intervall aktualisiert wird. Neben dieser Regulierung der externen Anrufsakzeptanzgrenze CAL, wird im folgenden die interne Pufferverwaltung entsprechend dem in Fig. 8 gezeigten Schritt S8-4 im Zusammenhang mit der Fig. 10 erläutert.

Wie bereits oben erläutert, wird durch die vorliegenden Erfindung eine Lösung geschaffen, bei der die Zahl der zugelassenen Jobs im Zusammenhang mit der Jobpufferkapazität der unterschiedlichen Jobpuffer JBA, JBB, JBC, . . . steht. Demnach werden anstelle der Regulierung der fraglichen Jobs durch eine Prozessorlastregulierung wie im Stand der Technik diese Jobs völlig anders durch die Jobpufferkapazität geregelt. Hierbei wird lediglich ein bestimmter Umfang der Jobs zu dem Zentralprozessor in jedem Zeitpunkt durchgelassen.

Das auf der Jobpuffer-Durchlaufsteuerung basierende Verfahren schützt die Zentraleinheit vor einer Überlast durch Massenereignisse oder eine unvorhergesehene Wechselwirkung zwischen unterschiedlichen in der Zentraleinheit ablaufenden Prozessen, d. h. Ereignissen, die letztendlich zu einer Pufferüberfüllung und erheblicher Fehlfunktion führen könnten. Weiterhin ermöglicht dieses Regulierverfahren die Verteilung der Kapazität bzw. in einem gewissen Sinne auch die Lastregulierung derart, daß die Überlast minimiert ist.

Wie in Fig. 10 gezeigt, basiert die Lastregulierung der vorliegenden Erfindung in einem System mit unterschiedlichen Prioritätsarbeitsebenen A, B, C, . . ., derart, daß jeder Ebene ein eigener Jobpuffer JBA, JBB, JBC, . . . zugeordnet ist. Hierbei unterbricht ein Job auf einer höheren Prioritätsebene auf der beispielsweise eine Datenverarbeitungsaufgabe durchgeführt wird, einen Job auf einer niedrigeren Prioritätsebene, wie oben detailliert beschrieben. Beispiele für die Prioritätsebene in der Reihenfolge von der höchsten zu der niedrigsten sind:

Prioritätsebene A

Diese Prioritätsebene wird nicht für normale Funktionen eingesetzt, sondern beispielsweise für das Betriebssystem bei einer Fehlfunktion.

Prioritätsebene B

Diese Arbeitsebene wird für die tatsächliche Anwendung eingesetzt, beispielsweise den Telefonieverkehr oder die Datenverarbeitungskommunikation.

Prioritätsebene C

Dies ist die Ebene für Betriebs- und Wartungsfunktionen, beispielsweise für Eingabe/Ausgabe-Funktionen wie die Schnittstelle zwischen Anwender und Maschine, die Ausgabe von datenverarbeitungsbezogenen Daten, beispielsweise Telefoniegebührendaten, usw.

Prioritätsebene D

Diese niedrigste Prioritätsebene wird beispielsweise für routinemäßige Wartungsfunktionen eingesetzt.

Es ist deutlich, daß die Folge der oben dargelegten Prioritätsebenen A bis D lediglich als Beispiel anzusehen sind und nicht als die vorliegende Erfindung begrenzend einzuschätzen sind.

Wie in Fig. 10 gezeigt, ist die Lastreguliereinheit 20 gemäß der vorliegenden Erfindung derart ausgebildet, daß sie den Durchlauf der Jobs in den Jobpuffern JBA, JBB, JBC beim Beginn jedes Teilintervalls reguliert. Hierbei sollte jede durch die Lastreguliereinheit 20 regulierte Funktion einen Teil der Jobpufferkapazität beanspruchen. Gemäß der Erfindung wird die für jede Prioritätsebene zur Verfügung stehende Jobpufferkapazität dynamisch für jedes Teilintervall in Abhängigkeit von der momentan eingesetzten Jobpufferkapazität zugeordnet.

Zudem ermöglichen die Warteschlangen qa, qb, qc, . . . das Einfügen von Anforderungen von Warteschlangen in dem Fall, daß die für ein bestimmtes Teilintervall zur Verfügung stehende Kapazität nicht ausreicht. Ist wieder Jobpufferkapazität verfügbar, so wird den in der Warteschlange eingereihten Anforderungen Jobpufferkapazität zugeordnet, und sie können anschließend mit kurzer Verzögerung durchgeführt werden, ohne daß jedoch Information im Hinblick auf die regulierten Funktionen verloren geht.

Im folgenden werden mehr Details im Hinblick auf die Berechnung der Jobpufferkapazität für jedes Teilintervall unter Bezug auf die Fig. 10 beschrieben.

Der erste zu Beginn jedes Teilintervalls von der Lastreguliereinheit 20 zu betrachtende Punkt besteht in der maximal verfügbaren Jobpufferkapazität. Diese maximale Jobpufferkapazität entspricht der maximalen Zahl von Jobs, die einem Jobpuffer zugeordnet werden können. Sie ist begrenzt durch die Jobpuffergröße, die für bei Bedarf Jobpufferkapazität anfordernde Funktionen vorgesehen sind, sowie für Funktionen, die einen sogenannten Kapazitätsspeicherbereich vorab vor dem Start des Betriebs des gesamten Systems anfordern. Hierbei sollte jeder Jobpufferkapazität beanspruchende Job innerhalb der möglichen Grenzen bleiben, unabhängig davon, ob mehrere Jobs parallel durchgeführt werden oder nicht. Hierzu ist die von einem Job genützte Jobpuffergröße begrenzt durch die Größe der maximalen Datensignalexpansion, die bei dem Job zu jedem beliebigen Zeitpunkt in dem Jobpuffer auftreten kann:



Maximal verfügbare Pufferkapazität = (Größe, die von Funktionen mit verteilter Speicherbereichskapazität benützt wird + Größe, die von Funktionen benützt wird, die Jobpufferkapazität bei Bedarf anfordern)/(maximale Größe, die von einem einzigen Job benützt wird) (4).

Wie anhand von Gleichung (4) zu ersehen ist, wird die maximale Jobpufferkapazität für jedes Teilintervall als obere Grenze für Anforderungen festgelegt, die während dem nachfolgenden Teilintervall zugelassen werden können. Ferner wird gemäß der vorliegenden Erfindung bei jedem Teilintervall die verfügbare Jobpufferkapazität wie folgt berechnet:



Verfügbare Kapazität = (Größe, die durch Funktionen mit verteilten Speicherbereichskapazität eingesetzt wird + Größe, die durch Funktionen eingesetzt wird, die bei Bedarf Jobpufferkapazität anfordern - momentane Pufferbelegung)/(maximale Größe, die von einem einzigen Job benutzt wird) (5).

Diese Gleichung (5) verdeutlicht einen wichtigen Aspekt der vorliegenden Erfindung. Insbesondere die Berechnung der verfügbaren Jobpufferkapazität bei jedem Teilintervall ermöglicht die Angleichung der vorhergehenden Schätzung an die tatsächlich vorliegende momentane Pufferbelegung. Die Wirkung dieser Vorgehensweise ist in Fig. 10 gezeigt, bei der beispielsweise die Linie A der Schätzung der verfügbaren Jobpufferkapazität für ein Teilintervall entspricht und der gestrichelte Bereich b der tatsächlich in diesem Teilintervall eingesetzten Jobpufferkapazität entspricht. Wie in Fig. 10 gezeigt, kann eine Überschätzung vorliegen, die während des nachfolgenden Teilintervalls korrigierbar ist. Somit ermöglicht die dynamische Anpassung der verfügbaren Jobpufferkapazität eine erhöhte Ausnutzung der verfügbaren Ressourcen.

Es ist zu erwähnen, daß gemäß der Erfindung Jobpufferkapazität nicht nur für Funktionen reserviert ist, die entweder bei Bedarf eine verteilte Speicheraufteilung der Jobpufferkapazität anfordern, sondern auch für Anrufbelegungen und andere Ereignisse in dem Echtzeit-Kommunikationssystem, die gemäß der Prozessorlast geregelt sind. Ferner sind Jobpufferkapazitäten auch für nicht regulierte Funktionen vorgesehen, und üblicherweise wird aus Vereinfachungsgründen davon ausgegangen, daß sie gleich zu der oben erwähnten ist. In der Praxis kann sie von den Möglichkeiten des entworfenen Echtzeit-Kommunikationssystems bestimmt sein.

Weiterhin kann eine zusätzliche (nicht gezeigte) Jobpufferkapazität als Sicherheitskapazität vorgesehen sein, die zwischendurch anläßlich regulärer, normaler und anormaler Lastspitzen als zusätzliche Reserve für die von der Lastreguliereinheit 20 an sich durchgeführte Lastregulierfunktion eingesetzt werden kann.

Im folgenden wird die dynamische Angleichung der verfügbaren Kapazität beschrieben, oder in anderen Worten, die unterschiedlichen Schritte der fensterorientierten Durchlauf-Laststeuervorgehensweise gemäß der Erfindung, und zwar unter Bezug auf die Fig. 11 bis 15.

Wie in Fig. 11 gezeigt, werden Anforderungen für Jobpufferkapazität durch die Lastreguliereinheit 20 gemäß der Erfindung in jedem Zeitpunkt innerhalb des Zeitintervalls durchgeführt, das unter Bezug auf die Fig. 10 erläutert ist. Wird eine derartige Anforderung an die Lastreguliereinheit 20 übertragen, so besteht der erste Schritt S11-1 in der Klassifizierung dieser Anforderung. Die Bedeutung dieses Schritts besteht darin, daß Anforderungen für Jobpufferkapazität sich in zwei Arten von Anforderungen klassifizieren lassen, d. h. "soweit verfügbar" und "Anforderung ohne Abstriche" bzw. "Gesamtanforderung". In dem ersten Fall wird die Anforderung akzeptiert, wenn die angeforderte Kapazität voll verfügbar ist, und in diesem Fall wird die Anforderung unmittelbar bestätigt. Falls die volle Jobpufferkapazität nicht verfügbar ist, wird eine Anforderung vom Gesamtanforderungstyp zurückgewiesen.

Im Gegensatz hierzu wird eine Anforderung vom Typ "soweit verfügbar" auch dann bestätigt, wenn die volle angeforderte Jobpufferkapazität nicht verfügbar ist. Lediglich, wenn überhaupt keine Kapazität verfügbar ist, wird die Anforderung in eine Warteschlange entsprechend der Jobpriorität eingefügt. Hier wird dann, wenn ein Job in eine Warteschlange eingefügt wird, jede verfügbare Jobpufferkapazität blockiert, um zu erzwingen, daß nachfolgende Jobanforderungen ebenfalls in die Warteschlange eingefügt werden, so daß die Jobdurchführung und die Prioritätsreihenfolge aufrecht erhalten werden. Beispielsweise sollte die Durchführung eines nachfolgenden Jobs, der lediglich eine geringe Jobpufferkapazität anfordert, solange nicht zugelassen werden, solange einem Job mit der gleichen oder höheren Priorität in einer Warteschlange ausreichend Kapazität zugeordnet ist.

In dem Fall, in dem auch die Warteschlange des Jobpuffers im Zusammenhang mit einer speziellen Anforderung ausgeschöpft ist, wird die Anforderung für Jobpufferkapazität letztendlich zurückgewiesen und es liegt dann an der Anwenderfunktion zu entscheiden, ob der/die Job(s) intern in eine Warteschlange innerhalb der Anwenderfunktion einzufügen sind oder überhaupt nicht mehr weiterbehandelt wird. Jedoch sind Jobs wie beispielsweise Anrufbeendigung selbstverständlich in eine Warteschlange einzufügen.

Auf der Grundlage der oben erläuterten Prinzipien zeigt Fig. 11 eine detailliertere Darstellung der Abfolge der unterschiedlichen Schritte. Nach der Klassifizierung einer Anforderung im Schritt S11-1 wird im Schritt S11-2 bestimmt, ob genug Jobpufferkapazität für eine unterbreitete Anforderung zur Verfügung steht oder nicht. Ist dies der Fall, so wird die Anforderung bestätigt, Schritt S11-3, und im folgenden wird die verfügbare Jobpufferkapazität gemäß der Formel (5) erneut berechnet, wie oben dargelegt. Andernfalls wird dann, wenn im Schritt S11-2 bestimmt wird, daß nicht genügend Jobpufferkapazität zur Verfügung steht, die jeweilige Anforderung im Schritt S11-6 in eine Warteschlange eingereiht. Hier ist zu erwähnen, daß nach dem Stand der Technik das Einfügen von Anforderungen in eine Warteschlange bedeutet, daß keine weitere Jobpufferkapazität zur Verfügung steht und somit keine weiteren Jobs dem Jobpuffer zugeführt werden, bis zum Ende des Teilintervalls.

Im Gegensatz hierzu verfolgt die vorliegende Erfindung eine vollständig andere Vorgehensweise mit dem Ziel, die Akzeptanz unterbreiteter Jobs unmittelbar dann wieder aufzunehmen, sobald Jobpufferkapazitäten wieder zur Verfügung stehen. Die Grundidee dieser Vorgehensweise, die in Fig. 10 dargestellt ist, besteht im Setzen einer Referenzmarke, die als Schleifensignal bezeichnet wird, bei einer niedrigeren Prioritätsebene, und zwar sobald keine weitere Jobpufferkapazität auf der höheren Prioritätsebene zur Verfügung steht. Anschließend wird die Verarbeitung von Jobs fortgesetzt und ggfs. geht die Bearbeitung zu der unteren Ebene über und erfaßt das zuvor auf dieser Prioritätsebene gespeicherte Schleifensignal. Bei Detektion dieses Schleifensignals erfolgt eine Bestätigung zu der höheren Prioritätsebene, wodurch die Bearbeitung zu der höheren Prioritätsebene zurückkehrt.

Hier war eine Voraussetzung für die Verarbeitung auf der unteren Ebene, daß alle Jobs auf der höheren Ebene vorab durchgeführt wurden, was bedeutet, daß bei Empfang der Bestätigung auf der höheren Ebene bekannt ist, daß die volle Prozessorkapazität erneut zur Verfügung steht, so daß zusätzliche Anforderungen auf dieser Ebene unterbreitet werden können.

Der Hauptvorteil dieser Vorgehensweise besteht darin, daß die Akzeptanz weiterer Anforderungen nicht bis zum Ende des zugeordneten Teilintervalls verschoben wird, sondern daß sie von der tatsächlichen Lastsituation abhängt. Dies ermöglicht eine signifikante Zunahme der Akzeptanzrate für ankommende Jobanforderungen und somit auch des Wirkungsgrads der Zentraleinheit. Weitere Details im Hinblick auf das Senden der Schleifensignale werden detailliert nachfolgend unter Bezug auf die Fig. 16 erläutert.

Wie in Fig. 11 gezeigt, wird nach Schritt S11-5 ein solches Schleifensignal auch dann gesendet, wenn keine Jobpufferkapazität nach der Akutalisierung der Jobpufferkapazität im Schritt S11-4 zur Verfügung steht. Die Bedeutung des Schritts S11-5 besteht darin, daß die Lastreguliereinheit 20 gemäß der Erfindung nicht nur das Einfügen von Anforderungen in eine Warteschlange bis zum Initiieren des Schleifensignalmechanismus abwartet, sondern bereits die zugeordneten Schritte unmittelbar dann durchführt, wenn das Einfügen von Anforderungen in eine Warteschlange zu erwarten ist.

Die Fig. 12 betrifft in dem in Fig. 11 gezeigten Schritt S11-3, d. h. die Bestätigung unterbreiteter Anforderungen. Wie bereits oben dargelegt, wird zu Beginn die Art der Anforderungen in einem Schritt S11-1 abgefragt. In dem Fall, in dem die Anforderung vom Typ "soweit verfügbar" ist, wird die angeforderten Jobpufferkapazität oder soweit diese verfügbar ist im Schritt S11-2 bestätigt, und der Prozeßablauf schreitet mit dem Schritt S11-4 fort, wie in Fig. 11 gezeigt.

Andernfalls, d. h. wenn die Anforderung vom Typ "Gesamtanforderung ist zu erfüllen" ist, wird die angeforderte Kapazität mit der verfügbaren Jobpufferkapazität im Schritt Schritt S12-3 verglichen. Wird die Abfrage bejaht, so wird die angeforderte Kapazität im Schritt S12-4 bestätigt, und anschließend schreitet der Prozeßablauf wieder mit dem in Fig. 11 gezeigten Schritt S11-4 fort. Andernfalls, wird die Anforderung vom Typ "Gesamtanforderung ist zu erfüllen" im Schritt S12-5 in eine Warteschlange eingefügt, und hierauf wird ein Schleifensignal zu einer niedrigeren Ebene gemäß dem Schritt S12-6 gesendet. Wie oben dargelegt, erlaubt das Senden des Schleifensignals in diesem Schritt S12-6 die Wiederaufnahme der Annahme von Anforderungen, sobald die vollständige Kapazität auf der höheren Prioritätsebene erneut verfügbar ist, wie oben dargelegt.

Die Fig. 13 zeigt Details des Einfügens einer Anforderung in eine Warteschlange gemäß dem in Fig. 11 gezeigten Schritt S11-6 und dem in Fig. 12 gezeigten Schritt S12-5.

Hierbei wird im Schritt S13-1 die Prioritätsebene einer Anforderung zunächst bestimmt. Anschließend folgt im Schritt S13-2 die Abfrage, ob die Warteschlange der zugeordneten Prioritätsebene angefüllt ist oder nicht. Ist dies nicht der Fall, so wird die Anforderung in die Warteschlange im Schritt S13-3 eingefügt. Andernfalls wird die Anforderung im Schritt S13-4 dem anfordernden Teilnehmer zurückgewiesen, und im Schritt S13-5 wird ein Zähler für abgewiesene Anforderungen inkrementiert. Hier kann der Zählwert als Hinweis auf einer Überlast in dem System benutzt werden. Schließlich wird im Schritt S13-6 die verbleibende Jobpufferkapazität gelöscht, um eine Situation zu vermeiden, bei der Jobs, die lediglich einen geringen Umfang der Jobpufferkapazität anfordern, zugelassen werden nachdem vorher eine Jobanforderung dem Teilnehmer zurückgewiesen wurde.

Die Fig. 14 zeigt einen Überblick über eine Situation, bei der eine Anforderung nicht in eine Warteschlange eingefügt ist, sondern von einer Warteschlange geholt wird, nachdem Jobpufferkapazität erneut bei einer bestimmten Prioritätsebene für die Durchführung verfügbar ist. Diese Situation kann dann auftreten, wenn alle Jobs unterhalb einer bestimmten Prioritätsebene durchgeführt sind und anschließend die Verarbeitung zu der Prioritätsebene zurückkehrt, bei der Anforderungen zwischendurch in eine Warteschlange eingefügt wurden, wie in Schritt S14-1 gezeigt. Ein anderer Fall besteht darin, daß eine Zeitperiode, während der der Zentralprozessor 22 unter Überlastbedingung betrieben wurde, verstrichen ist und nun Prozessorkapazität erneut für die weitere Handhabung von Anforderungen zur Verfügung steht. In beiden Fällen wird zu Beginn eine Referenz im Schritt S14-2 darhingehend gesetzt, daß nun die volle Jobpufferkapazität verfügbar ist. Anschließend werden in Warteschlange eingefügte Anforderungen in den verfügbaren Jobpuffer im Schritt S14-3 geholt. Ist die Kapazität verteilt, so erfolgt im Schritt S14-4 eine Abfrage zum Überprüfen, ob ein Schleifensignal zum Anzeigen eines derartigen vollständigen Zugriffs auf die Kapazität zu der unteren Ebene zu senden ist oder nicht. Ist dies nicht der Fall, so wird ein Signal im Schritt S14-5 gesendet.

Die Fig. 15 zeigt weitere Details des Schritts S14-3 zum Holen von in Warteschlange eingefügten Anforderungen. Zu Beginn wird im Schritt S15-1 geprüft, ob überhaupt Anforderungen in die Warteschlange eingefügt sind oder nicht. Ist dies der Fall, so wird eine Anforderung tatsächlich von der Warteschlange in Schritt S15-2 geholt, und anschließend wird im Schritt S15-3 die für diese Anforderung erforderliche Kapazität mit der verfügbaren Kapazität verglichen. Falls die verfügbare Kapazität nicht die Plazierung der Anforderung in dem Jobpuffer auf der entsprechenden Prioritätsebene erlaubt, wird die geholte Anforderung erneut in der Warteschlange gemäß dem Schritt S15-4 plaziert. Ferner wird die verbleibende Pufferkapazität im Schritt S15-5 gelöscht, um das Positionieren einer weiteren Anforderung in dem Jobpuffer zu vermeiden, wie bereits oben erläutert.

Ist andererseits genügend Kapazität für eine ausgelesene Anforderung verfügbar, wird diese Anforderung dem anfordernden Teilnehmer im Schritt S15-6 bestätigt, und anschließend wird die verbleibende verfügbare Jobpufferqualität im Schritt S15-7 berechnet. Schließlich wird im Schritt S15-8 überprüft, ob Jobpufferkapazität übrig bleibt oder nicht. Falls dies nicht der Fall ist, wird das Auslesen von in der Warteschlange abgelegten Anforderungen beendet. Andernfalls kehrt der Ablauf zurück zu dem Schritt S15-1, um zu bestimmen, ob zusätzliche Anforderung in der Warteschlange eingefügt sind oder nicht.

Oben wurden zwei wichtige Aspekte der Erfindung beschrieben. Der erste besteht in dem dynamischen Angleichen der verfügbaren Jobpufferkapazität zu der momentan belegten Jobpufferkapazität. Wie unter Bezug auf die Fig. 11 dargelegt, ermöglicht dies den optimalen Einsatz der gesamten verfügbaren Jobpufferkapazität. Ferner führt diese Vorgehensweise nicht zu einer Entscheidung zwischen Anrufanforderungen und zugeordneten Anforderungen wie Anrufbeendigungen. Dies ermöglicht den Schutz der Zentraleinheit gegenüber zuvor nicht kontrollierten Überlastsituationen, die sich beispielsweise aus Massenereignissen ergeben. Ferner zeigt der unter Bezug auf die Fig. 13 bis 15 erläuterte Warteschlangenmechanismus, daß Anforderungen während eines Zeitintervalls nicht verloren gehen, da Anforderungen in eine Warteschlange eingefügt und nicht unmittelbar zurückgewiesen werden, wenn nicht genügend Jobpufferkapazität zur Verfügung steht. Dieses Merkmal ermöglicht eine signifikante Leistungssteigerung der Zentraleinheit, da durch die Aufnahme einer Anforderung in eine Warteschlange der Prozeßablauf auch während eines Zeitintervalls so wieder aufgenommen werden kann, daß die Anforderung zum Warten auf den Beginn eines anderen Teilintervalls und zum erneuten Unterbreiten der Anforderungen für den Zentralprozessor 22 absolut ist. In anderen Worten ausgedrückt bedeutet dies, daß sobald Jobpufferkapazität wieder für die in der Warteschlange eingereihten Anforderungen zur Verfügung steht, diese unmittelbar in den Jobpuffer übertragen werden, also vor dem Ende eines Regulierteilintervalls, so daß sie ohne weitere Verzögerung durch den Zentralprozessor 22 verarbeitet werden können.

Die Fig. 16 zeigt einen anderen Basismechanismus der vorliegenden Erfindung, mit dem sich eine dynamische Laststeuerung des Zentralprozessors 22 erzielen läßt. Zum Erklären dieses Mechanismus wird davon ausgegangen, daß mehrere Jobpuffer in der Jobpuffereinheit 16 vorgesehen sind und beispielsweise eine Lastreguliereinheit 20 so ausgebildet ist, daß sie die Last auf einer höheren Ebene steuert, die in Fig. 16 in dem oberen Teil gezeigt ist. Ferner zeigt die Fig. 16 auf der linken Seite die Zahl der aktiven Jobs jeweils auf der höheren und unteren Ebene, und auf der rechten Seite den Umfang der verfügbaren Jobpufferkapazität jeweils auf der höheren und unteren Ebene.

Wie im linken Teil der Fig. 16 gezeigt und bereits oben dargelegt, wird dann, wenn die Lastreguliereinheit 20 der Erfindung mehrere höhere Ebenen handhabt, die Verarbeitung der Anforderungen zwischen unterschiedlichen Prioritätsebenen gewechselt. Demnach geht dann, wenn die Zahl der aktiven Jobs auf der höheren Ebene ggfs. zu Null wird, die Verarbeitung zu einer niedrigeren Ebene gemäß der gestrichelten Linie 32 über. Hier wird die Verarbeitung in Abhängigkeit von den Anforderungen in dem Jobpuffer fortgeführt, und sie kehrt ggfs. zu der höheren Ebene zurück, falls weitere Anforderungen ggfs. auf dieser höheren Prioritätsebene empfangen wurden.

Der rechte Teil der Fig. 16 zeigt, wie im Rahmen der vorliegenden Erfindung dieser Grundmechanismus zum Erzielen einer dynamischen Laststeuerung des Zentralprozessors 22 ausgenützt wird.

Hierfür wird gemäß der vorliegenden Erfindung das Konzept des Schleifensignals und der Bestätigung eingeführt, auf das bereits oben Bezug genommen wurde. Hier ist der relevante Aktionspunkt während eines Teilintervalls derjenige Zeitpunkt te, wenn die Kapazität des Jobpuffers erreicht wird. Üblicherweise werden in einer solchen Situation keine weiteren Anforderungen zu dem Jobpuffer in irgendeiner Weise zugelassen, so daß lediglich nach dem Beginn des nächsten Teilintervalls die normale Bearbeitung auf dieser höheren Prioritätsebene fortgesetzt wird.

Im Gegensatz hierzu wird gemäß der vorliegenden Erfindung ein Schleifensignal 34 an die untere Ebene gesendet und in dem Jobpuffer auf dieser unteren Ebene empfangen. Da dieses Schleifensignal 34 lediglich eine Referenz darstellt, erfordert es nur einen geringen Umfang der verfügbaren Jobpufferkapazität auf der unteren Prioritätsebene, wie bei 36 und 38 in dem unteren Teil der Fig. 16 gezeigt.

Ferner wird, wie auf der linken Seite der Fig. 16 gezeigt, der Prozeßablauf anschließend auf der höheren Prioritätsebene fortgesetzt, bis die Zahl der aktiven Jobs ggfs. einen Wert von Null im Zeitpunkt t0 erreicht, und der Prozeßablauf wird dann auf der niedrigeren Prioritätsebene fortgesetzt. Mit Fortschreiten des Prozeßablaufs auf dieser niedrigeren Prioritätsebene wird ggfs. das zuvor gesendete Schleifensignal bearbeitet, wie bei 38 gezeigt. Wird das Schleifensignal auf der niedrigeren Prioritätsebene im Zeitpunkt ta bearbeitet, so ist hierdurch klar, daß keine Jobs auf der höheren Prioritätsebene bearbeitet werden, und demnach ist die Prozessorkapazität auf der höheren Prioritätsebene erneut verfügbar. Anschließend kann jede in eine Warteschlange eingefügte Anforderung ausgelesen und bestätigt werden, solange Kapazität zur Verfügung steht, wie unter Bezug auf die Fig. 14 und 15 dargelegt. Wird mehr Pufferkapazität angefordert als verfügbar ist, so wird erneut das Schleifensignal zu der niedrigeren Prioritätsebene gesendet.

Insgesamt kann der Prozeßablauf auf der höheren Ebene zur Zeit ta wieder aufgenommen werden, bei der die Bestätigung auf der höheren Prioritätsebene empfangen wird. Hierbei liegt die Zeit ta deutlich vor dem Ende des Teilintervalls, so daß in einem extremen Fall im Rahmen der Erfindung die volle Bearbeitungskapazität gemäß einem vollständigen Teilintervall gewonnen wird, da die Bearbeitung nicht unmittelbar dann gestoppt wird, wenn die maximale Kapazität eines Jobpuffers in einem Zeitpunkt t1 während der Bearbeitung in einem Teilintervall erreicht wird.

Die Fig. 17 zeigt die Hauptschritte des Schleifensignalgebungsmechanismus gemäß der vorliegenden Erfindung. Im Schritt S17-1 wird eine Abfrage durchgeführt, ob Jobpufferkapazität verfügbar ist oder nicht. Ist dies nicht der Fall, so wird ein Schleifensignal zu der niedrigeren Prioritätsebene im Rahmen des Schritt S17-2 gesendet. Ferner wird eine Markierung zum Anzeigen eines gesendeten Schleifensignals im Schritt S17-3 gesetzt, die nachfolgend als Statusanzeige benützt werden kann.

Während Jobs auf der höheren Prioritätsebene Echtzeitanforderungen aufweisen können, beträgt die Dauer unterbreiteter Jobs möglicherweise mehrere Teilintervalle in Abhängigkeit davon, welcher Art die von Jobs sind und wie die momentane Lastsituation ist. Hierbei könnte der Fall vorliegen, daß bei einzelnen Jobs die vorhergesehene Signalexpansion nicht eingetreten ist, d. h. die Signalmultiplikation und/oder Datenexpansion, für die Jobpufferkapazität bereitgestellt ist. Gemäß der Erfindung stellt dies jedoch kein Problem dar, da die Jobpufferbelegung bei jedem Teilintervall überprüft wird und jede mögliche Überschreitung der Zahl der unterbreiteten Jobs sich immer deutlich innerhalb des bereitgestellten Redundanzrahmens beispielsweise für normale Fluktuationen halten sollte. Sollten dennoch einige störende Situationen auftreten, so sind für deren Handhabung Schutzmechanismen vorgesehen, beispielsweise auf Betriebssystemebene, wie detaillierter nachfolgend beschrieben wird.

Während der Normalbetrieb der Lastregeleinheit 20 gemäß der vorliegenden Erfindung oben unter Bezug auf die Fig. 9 bis 17 beschrieben wurde, dient die folgende Beschreibung der Erläuterung des Schritts zum Vorbereiten des nächsten Teilintervalls gemäß dem in Fig. 8 gezeigten Schritt S8-4. Diese Erläuterung erfolgt unter Bezug auf die Fig. 18 bis 21.

Wie in Fig. 18 gezeigt, beginnt die Vorbereitung jedes Teilintervalls mit einer Abfrage im Schritt S18-1, ob eine Begrenzung der Jobs durch die Teilnehmer gefordert ist oder nicht. Ist dies der Fall, so wird eine Überwachung zum Begrenzen der Jobs im Schritt S18-2 durchgeführt, der detaillierter unter Bezug auf die Fig. 19 beschrieben wird. Andernfalls wird im Schritt S18-3 eine momentan Last des Jobpuffers überprüft, und die verfügbare Jobpufferkapazität wird unter Einsatz der oben erläuterten Formel (5) im Schritt S18-4 berechnet. Schließlich werden in Warteschlangen abgelegte Anforderungen in dem Jobpuffer im Schritt S18-5 ausgelesen, und anschließend werden in der Warteschlange abgelegte Anforderungen für die Prozessorlast im Schritt S18-6 ausgelesen.

Die Fig. 19 zeigt ein Flußdiagramm gemäß der Überwachung oder Begrenzung von Jobs, auf die in Fig. 18 im Schritt S18-2 Bezug genommen wird. Wie in Fig. 19 gezeigt, wird diese Überwachung im wesentlichen durch Einsatz eines Zählers durchgeführt, der dynamisch an die Zahl der unterbreiteten Jobs im Schritt S19-1 angeglichen wird. Ferner erfolgt im Schritt S19-2 eine Abfrage, ob eine Zeitperiode für die Jobbegrenzung abgelaufen ist oder nicht, und gegebenenfalls wird im Schritt S19-3 die Überwachung zum Begrenzen der Jobs gestoppt.

Die Fig. 20 zeigt eine weitere Erläuterung des in Fig. 18 gezeigten Schritts S18-3, d. h. der Überprüfung der Last der Jobpuffer. Hierbei wird anfänglich die tatsächliche Jobpufferbelegung im Schritt S20-1 bewertet, und anschließend folgt im Schritt S20-2 eine Abfrage, ob die Last bei irgendeiner der Prioritätsebenen zu hoch ist. Ist dies der Fall, so wird die von dem vorhergehenden Teilintervall verbleibende Jobpufferkapazität gelöscht, und anschließend wird in den Schritten S20-4 und S20-5 ein Schleifensignal zu der unteren Prioritätsebene gesendet, gemäß den oben unter Bezug auf die Fig. 16 dargelegten Prinzipien.

Dies bedeutet, daß die oben für die dynamische Steuerung der Prozessorlast erläuterten Schritte, wie in Fig. 16 gezeigt, auch unmittelbar am Beginn eines Teilintervalls gestartet werden können, und nicht nur während des Verlaufs eines derartigen Teilintervalls. Zusätzlich erfolgt im Schritt S20-6 eine Abfrage, ob die Überlastbedingung eine kritische Überlastbedingung ist. Ist dies der Fall, so wird vorab zugewiesene Jobpufferkapazität oder in äquivalenter Weise die verteilte vollständige Kapazität für sämtliche Teilnehmer gelöscht. Insgesamt ermöglicht die in Fig. 20 gezeigte Abfolge der Prozeßschritte das Erzielen eines genau definierten Anfangszustands am Beginn eines Teilintervalls, so daß der oben erläuterte Normalbetrieb auf der Grundlage geeignet bestimmter Randbedingungen startet.

Die Fig. 21 zeigt weitere Details des in Fig. 18 gezeigten Schritts S18-5, der im Zusammenhang mit dem Auslesen der in der Warteschlange vorliegenden Anforderungen in den Jobpuffer zu Beginn jedes Teilintervalls steht. Zu Beginn wird im Schritt S21-1 bestimmt, ob irgendwelche Anforderungen in der Warteschlange überhaupt vorliegen, und ist dies der Fall, so werden diese Anforderungen im Schritt S21-2 ausgelesen. Anschließend erfolgt im Schritt S21-3 eine Abfrage, ob die angeforderte Jobpufferkapazität niedriger oder gleich der verfügbaren Jobpufferkapazität ist. Ist dies der Fall, so wird im Schritt S21-4 die angeforderte Jobpufferkapazität bestätigt, und die verbleibende Jobpufferkapazität wird reduziert, entsprechend den oben erläuterten Prinzipien und der Gleichung (5). Ferner wird im Schritt S21-5 die Zahl der während dieses Teilintervalls zulässigen Prozessorkapazitätsbelegungen in Abhängigkeit von dem Umfang der bestätigten Pufferkapazität verringert.

Wird jedoch im Schritt S21-3 bestimmt, daß die angeforderte Jobpufferkapazität größer als die verfügbare Jobpufferkapazität ist, so wird im Schritt S21-3 in der zugeordneten Warteschlange ersetzt, und gegebenenfalls verbleibende Jobpufferkapazität wird gelöscht bzw. rückgesetzt. Zusätzlich wird der oben erläuterte Schleifensignal-Sendemechanismus gemäß der vorliegenden Erfindung in den Schritten S21-7 und S21-8 durchgeführt. Hierbei wird dann, wenn der Umfang der in der Warteschlange vorliegenden Anforderungen oberhalb einer kritischen Grenze liegt, die Initialisierungsroutine einen EXIT-Schritt durchführen, d. h. die betreffende Anwenderfunktion verlassen.

Bisher wurden sämtliche Schritte im Zusammenhang mit der Lastregulierung durch die Lastreguliereinheit 20 gemäß der vorliegenden Erfindung unter Bezug auf die Fig. 8 bis 21 erläutert. Jedoch ist, wie im folgenden gezeigt, die Lastreguliereinheit 20 nicht nur auf die Steuerung des Betriebs der Jobpuffereinheit 16 begrenzt, sondern sie wirkt auch auf den Betrieb des Zentralprozessors 22 ein.

Hier kann bei Prozessorüberlast gemäß dem Fall, bei dem die Dauer der Jobdurchführung auf höheren Prioritätsebenen zu lange dauert, die Lastreguliereinheit 20 auch zum Begrenzen der Durchführung der Jobs durch den Zentralprozessor 22 eingesetzt werden. Zudem kann auch die unterste Prioritätsebene überwacht werden, um jede kritische Verzögerung der Ausführung zu detektieren. Somit ist es möglich, die Durchführung von Jobs auf höheren Prioritätsebenen spontan zu reduzieren oder zu stoppen. Demnach kann die Durchführungsrate auf höheren Prioritätsebenen reduziert werden, damit Jobs auf niedrigeren Prioritätsebenen in kritischen Überlastsituationen durchgeführt werden können.

Die Fig. 22 zeigt Details einer derartigen Prozessorlastregulierung. In den obigen Ausführungen sind die üblichen Teilintervalle für die Jobpuffersteuerung gezeigt. Wie in Fig. 22 gezeigt, erfolgt die Prozessorlastregulierung anhand einer anderen Zeitskala von beispielsweise 100 Millisekunden im Fall einer Dauer der Teilintervalle von 40 Millisekunden. Ferner wird die Prozessorlastregulierung durch Modifizierung der Meldungszahl erzielt, die während jedes Zeitintervalls ausgelesen werden, d. h. der Meldungsbearbeitungsrate.

Hier fordert die Lastreguliereinheit 20 beispielsweise immer nach 100 Millisekunden den Wert der Prozessorlast während des vorhergehenden Prozessorlast-Steuerintervalls an, und sie nützt den Nutzwert zum Berechnen eines durchschnittlichen Meßlastwertes während einer längeren Zeitperiode, dem sogenannten Lastüberwachungsintervall. Am Ende jeder langen Zeitperiode berechnet die Lastreguliereinheit 20 die durchschnittliche Last anhand der durchschnittlich gemessenen Last und der durchschnittlichen Last während der vorhergehenden längeren Zeitperiode. Liegt die durchschnittliche Last oberhalb der Zielgrenze für die Prozessorlast, die durch einen Parameter definiert ist, so wird die Meldungsbearbeitungsrate für die nächste längere Zeitperiode abgesenkt. Hier wird die neue Meldungsbearbeitungsrate so gesetzt, daß die durchschnittliche Zahl ausgelesener Meldungen pro Sekunde während der letzten längeren Zeitperiode gemäß der folgenden Formel verringert wird:



MPR=A.(1-0,01) (6)



A stellt die durchschnittliche Zahl der ausgelesenen Meldungen während der letzten längeren Zeitperiode dar.

Liegt die Prozessorlast zwischen der unteren und oberen Prozessorlastgrenze, so wird die Meldungsbearbeitungsrate nicht verändert. Liegt schließlich die durchschnittliche Last unterhalb der unteren Prozessorlastgrenze, so wird die Meldungsbearbeitungsrate gemäß folgender Formel angehoben:





AL ist die durchschnittliche Last.

Zudem liegt ein Maximalwert und ein Minimalwert für die Meldungsbearbeitungsrate vor. Der Maximalwert liegt so, daß er zu keiner einschränkenden Wirkungen bei normalen Lastsituationen führt. Ferner wird die Minimalwert zum Steuern des für die Meldungsbearbeitung reservierten Umfangs der Prozessorkapazität eingesetzt. Deshalb läßt sich in Situationen mit großer Last aufgrund einer starken Betriebs- und Wartungsaktivität ein minimaler Durchsatz gewährleisten.

Wie in Fig. 22 gezeigt, ist der oben erläuterte Basismechanismus für die Prozessorlastregulierung mit der Jobpufferregulierung verzahnt, unter erneutem Einsatz des Schleifensignal-Sendemechanismus gemäß der vorliegenden Erfindung. Hier kann bei Beginn eines Prozessorlast-Steuerintervalls ein Schleifensignal zu der unteren Prioritätsebene zum Anzeigen des Starts der Überwachung der Prozessorlast gesendet werden. Anschließend wird die Bearbeitung der Jobs auf der höheren Prioritätsebene fortgesetzt, und gegebenenfalls wird eine Bestätigung dieses Schleifensignals erneut von der unteren (untersten) Prioritätsebene empfangen. In diesem Zeitpunkt wird die Überwachung der Prozessorüberlastdauer rückgesetzt, da der Übergang von der unteren Prioritätsebene ein Ende der Überlastdauer anzeigt.

Die Fig. 23 zeigt einen detaillierten Überblick für die Überwachung des Prozessorüberlaufs. Im Schritt S23-1 wird zunächst die Prozessorlast für das letzte Prozessorlast-Steuerintervall gelesen. Anschließend wird im Schritt S23-2 diese Last zu der akkumulierten Last addiert. Ferner erfolgt im Schritt S23-3 eine Abfrage, ob die Zeit zum erneuten Berechnen der Parameter für die Prozessorlastregulierung verstrichen ist. Ist dies der Fall, so werden die Prozessorlast-Regulierparameter unter Einsatz der Formeln (6) und (7), die oben angegeben sind, erneut berechnet. Andernfalls geht die Prozedur unmittelbar zu dem Schritt S23-5 über, entsprechend einer Abfrage, ob die Prozessorüberlast während einer vorspezifizierten Dauer vorgelegen ist. Ist dies der Fall, so findet im Schritt S23-3 die Durchführung der Überwachung statt.

Die Fig. 24 zeigt die Durchführung der Überwachung gemäß dem Schritt S23-3 auf einer detaillierteren Ebene. Anfänglich wird im Schritt S24-1 überprüft, ob die Überwachung der Überlastdauer bereits gestartet ist. Ist dies nicht der Fall, so wird eine Referenzmarkierung entsprechend der Überwachung der Überlastdauer im Schritt S24-2 gesetzt, und anschließend wird ein Schleifensignal zu einer niedrigeren oder der niedrigsten Prioritätsebene im Schritt S24-3 zum Überwachen der abgelaufenen Überlastdauer gesendet. Zeigt die Abfrage im Schritt S24-1, daß die Überwachung der Überlastdauer bereits begonnen hat, so wird eine zusätzliche Abfrage im Schritt S24-4 durchgeführt, um zu bestimmen, ob die Überlastdauer kritisch ist. Ist dies der Fall, so wird im Schritt S24-4 eine unmittelbare Reaktion initiiert. Insbesondere werden Jobpuffer- und Prozessorkapazitätsanforderungen momentan blockiert, und der Start einer Überwachung für die Jobbegrenzung wird initiiert.

Wie in den Fig. 22 und 25 gezeigt, basiert die Kopplung der Prozessorüberlastüberwachung der Jobpufferkapazitätsregulierung auch auf dem Schleifensignal-Sendemechanismus gemäß der vorliegenden Erfindung, und sie enthält drei Schritte, Empfangen des Schleifensignals auf einer niedrigeren oder der niedrigsten Prioritätsebene, Schritt S25-1, Überwachung der Prozessorlast bis zu einem Ablauf der Überlastdauer, Schritt S25-2, und Fortführung von Job auf höheren Prioritätsebenen, Schritt S25-3.

Insgesamt erfolgt eine Wechselwirkung der Jobpufferkapazitätregulierung mit der Prozessorlastregulierung, d. h. gemäß der vorliegenden Erfindung erfolgt eine Wechselwirkung zuvor nicht geregelter Funktionen miteinander zum Erzielen einer Kontrolle über die Jobpuffer-Lastsituation.

Der letzte Aspekt der Erfindung betrifft die Startphase der Zentraleinheit am unmittelbaren Beginn des Betriebs. Während des Anlaufens der in Fig. 6 gezeigten Zentraleinheit hat der Anwender die Option, die Art des Jobpuffereinsatzes zu spezifizieren. Ein bevorzugter Einsatz gemäß der Erfindung ist in Fig. 26 gezeigt, und er betrifft verteilte Jobpufferkapazitäts-Speicherbereiche.

Hier wird im Rahmen der vorliegenden Erfindung die Tatsache ausgenützt, daß zwei Arten von Anwenderfunktionen vorliegen, die Jobpufferkapazität anfordern, d. h. Anwenderfunktionen mit nicht regulären Anforderungen für die Jobpufferkapazität und Anwenderfunktionen mit regulären Anforderungen für die Jobpufferkapazität. Die erstere kann beispielsweise eine Wartungsfunktion sein, die Jobpufferkapazität bei jedem besonderen Ereignis anfordert und diese Jobpufferkapazität dann benützt, wenn es erforderlich ist. Die letzteren Funktionen sind Teilnehmerfunktionen, die spezifische Jobs durchführen, beispielsweise fortlaufendes Abtrennen eines Anrufs. Diese Teilnehmerfunktionen erfordern einen bestimmten Umfang der Jobpufferkapazität an, der nicht direkt genützt werden kann, sondern lediglich bei Bedarf. Wird die gesamte Jobpufferkapazität wie der Speicherbereich A-1 für den Teilnehmer A eingsetzt, so wird ein neuer Speicherbereich A-2 für denselben Teilnehmer A angefordert und diesem zugeordnet. Diese Art von Teilnehmerfunktion wird als Funktion mit Speicherbereich mit verteilter Jobpufferkapazität bezeichnet.

Somit minimiert bei der vorliegenden Erfindung die Möglichkeit zum Verteilen von Jobpufferkapazität die zusätzliche Last. Die Größe der verteilten Jobpufferkapazität, die eine Teilnehmerfunktion anfordern kann, hängt von der Zahl der Teilnehmerfunktionen ab. Jedoch kann es auch erforderlich sein, die Größe dieser verteilten Jobpufferkapazität auf einen Maximalwert in Abhängigkeit von der Anwendung zu begrenzen. Ferner führt das Merkmal der verteilten Jobpufferkapazität auch dazu, daß die gesamte eingesetzte Kapazität potentiell das Zweifache der maximal verfügbaren Kapazität beträgt, d. h. der maximal verfügbaren Kapazität, die belegt werden kann plus der maximalen verteilten Kapazität. Natürlich stellt dies kein Problem dar, jedoch muß die Zentraleinheit an diese Option angepaßt sein.

Ferner sollte zum Erzielen einer Gesamtkontrolle der Zahl der Jobs und der Prioritätsebenen dieser Jobs bei kritischen Systemereignissen die Lastreguliereinheit 20 der vorliegenden Erfindung in der Lage sein, die gesamte an die Teilnehmer verteilte Jobpufferkapazität rückzusetzen, wie oben dargelegt. Dies dient zum Vermeiden der Tatsache, daß die verteilte Jobpufferkapazität eingesetzt wird und das Risiko einer potentiellen Überlastsituation erhöht, und zudem dazu, daß bei Teilnehmerfunktionen das Anfordern neuer Kapazität erzwungen wird.

Die Fig. 27 zeigt weitere Details zum Verarbeiten während der Systemanlaufphase. In einem Schritt S27-1 werden Teilnehmerberichte über die Teilnehmer-Jobpufferkapazitätsfunktion empfangen. Anschließend erfolgt im Schritt S27-2 eine Abfrage zum Spezifizieren der Art des Jobpufferkapazitäts-Einsatzes, d. h. jeweils normaler oder verteilter Einsatz. Im ersten Fall wird im Schritt S27-3 die Teilnehmerreferenz gespeichert, und eingesetzte Prioritäten und Vorgabewerte für erforderliche Kapazitäten werden in einer (nicht gezeigten) Normaltabelle gespeichert. Im zweiten Fall werden im Schritt S27-4 ebenfalls Teilnehmerreferenzen gespeichert, und Teilnehmerprioritätsebenen sowie erforderliche Jobpufferkapazitäten werden in einer (nicht gezeigten) Teilnahmetabelle gespeichert.

Ferner zeigt Fig. 28 die Berechnung der Jobpuffer-Speicherbereiche. Hierbei wird im Schritt S28-1 anfänglich überprüft, ob Teilnehmerunterbreitungsdaten gelesen sind. Ist dies nicht der Fall, so endet die Berechnung der Jobpuffer-Speicherbereiche. Andernfalls werden im Schritt S28-2 Teilnehmerabgabedaten gelesen. Anschließend wird im Schritt S28-3 überprüft, ob irgendeine spezifizierte Kapazitätsanforderung vorliegt. Ist dies nicht der Fall, so wird im Schritt S28-4 der Teilnehmer für normale Anforderungen erfaßt und markiert, und die Prozedur kehrt zu dem Schritt S28-1 zurück. Andernfalls wird der Teilnehmer entsprechend vorspezifizierten Anforderungen erfaßt und markiert. Anschließend wird im Schritt S28-6 überprüft, ob die vorspezifizierte Anforderung größer als die maximal zulässige vorspezifizierbare Anforderung ist. Ist dies nicht der Fall, so wird im Schritt S28-7 die vorspezifizierte Anforderung dem Zähler für spezifische Speicherbereiche hinzugefügt. Andernfalls wird die maximal zulässige vorspezifizierbare Anforderung dem Zähler für spezifische Speicherbereiche zugefügt, und ein neuer Wert wird für den entsprechenden Teilnehmer markiert. Weiterhin wird ein Alarm initiiert, zum Anzeigen der Tatsache, daß die vorspezifizierte Anforderung die maximal zulässige Obergrenze überschreitet.

Die Fig. 29 betrifft die Fortführung der Berechnung der Jobpuffer-Speicherbereiche gemäß Fig. 28. Hier wird im Schritt S29-1 die verbleibende Jobpufferkapazität entsprechend folgender Gleichung berechnet:



Verbleibender Speicherbereich = gesamter Speicherbereich - vorspezifizierter Speicherbereich.

Anschließend wird im Schritt S29-2 die Berechnung der Speicherbereichkapazität pro Teilnehmer mit normalen Anforderungen auf der Basis der verbleibenden Speicherbereichs und der Zahl der Teilnehmer bestimmt. Anschließend erfolgt im Schritt S29-3 eine Abfrage, ob der normale Jobpufferkapazität-Speicherbereich niedriger als ein vorspezifiziertes Minimum ist. Ist dies der Fall, so wird im Schritt S29-4 ein Alarm initiiert. Hiernach wird im Schritt S29-5 der Jobpufferkapazitäts-Speicherbereich für alle normalen Teilnehmer markiert.

Die Fig. 30 zeigt den letzten Schritt während des Systemanlaufs, d. h. die Verteilung der Jobpufferkapazität unterschiedlicher Teilnehmerfunktionen, und entspricht einer Fortsetzung der Fig. 29. Hier wird zunächst im Schritt S30-1 überprüft, ob irgendein Jobpufferkapazitäts-Speicherbereich zu verteilen ist, und wenn dies der Fall ist, wird im Schritt S30-2 der verteilte Jobpufferkapazitäts-Speicherbereich dem zugeordneten Teilnehmer angezeigt.

Zusätzlich zu dem Normalbetrieb der Lastreguliereinheit 20, zu der Initialisierung eines Lastregulierteilintervalls und zu dem oben beschriebenen Anlauf wird gemäß der vorliegenden Erfindung auch eine Betriebssystemdetektion einer hohen Jobpufferlast geschaffen, wie im folgenden erläutert.

Insbesondere kann das Betriebssystem unmittelbar einen störenden Anstieg der Jobpufferbelegung detektieren. Das Betriebssystem fordert dann die Lastreguliereinheit auf, unmittelbar zu reagieren, d. h. die verfügbaren Jobpufferkapazität rückzusetzen, die an unterschiedliche Teilnehmer verteilte Jobpufferkapazität rückzusetzen und jedwede neue Jobanforderung zu sperren. Derartige Anforderungen können im Zusammenhang mit allen Regulierfunktionen stehen, beispielsweise auch mit der Belegung von Prozessorlast.

Fig. 31 zeigt die Schritte, die zum Durchführen der Betriebssystemdetektion einer hohen Jobpufferlast erforderlich sind. Gemäß dem Schritt S31-1 empfängt im Fall einer hohen Jobpufferlast die Lastreguliereinheit 20 gemäß der vorliegenden Erfindung einen Interrupt von dem Betriebssystem in jedem Zeitpunkt des Betriebs. Anschließend wird im Schritt S31-2 jede verfügbare Jobpufferkapazität und jeder verteilte Speicherbereich der Jobpufferkapazität für alle Teilnehmer rückgesetzt. Anschließend werden im Schritt S31-3 die Jobpufferkapazität- und Prozessorlast-Belegungen spontan so blockiert, daß die hohe Belegung der Jobpufferkapazität reduziert wird. Eine weitere Maßnahme besteht darin, im Schritt S31-4 die Überwachung der Jobbegrenzung zu starten. Anschließend erfolgt im Schritt S31-5 eine Abfrage, welche Prioritätsebene des Jobpuffers tatsächlich überlastet ist. In den Schritten S31-6 und S31-7 wird anschließend die jeweilige Überlastüberwachung beispielsweise jeweils auf der C- und D-Ebene durchgeführt.

Insgesamt ermöglicht dieses Merkmal der Erfindung eine noch leistungsfähigere und flexiblere Steuerung der verfügbaren Jobpufferkapazität. Ferner wird jede Systemfehlfunktion unmittelbar am Beginn vermieden, wodurch Wiederherstellmechanismen erheblich vereinfacht werden.

Ferner wird im Rahmen der vorliegenden Erfindung die Tatsache berücksichtigt, daß es für bestimmte Funktionen mit hohen Echtzeitanforderungen nachteilig ist, wenn ihre Anforderung für Jobpufferkapazität in eine Warteschlange in dem Fall eingereiht wird, in dem keine Jobpufferkapazität verfügbar ist. Diese Funktionen können anzeigen, daß die Anforderung nicht in eine Warteschlange eingefügt werden kann, sondern entweder zu bestätigen oder zurückzuweisen ist. Es ist auch möglich, die verfügbare Jobpufferkapazität in Abhängigkeit von der Lastsituation und abhängig jeweils von dem nachfolgenden Regulierintervall oder den nachfolgenden Regulierintervallen zu überschreiben. Dieses Merkmal ist aufgrund der hohen Sicherheitsredundanzvorgabe bei der Handhabung der Jobpufferkapazität gemäß der vorliegenden Erfindung möglich.

Zudem kann die vorliegende Erfindung einfach zum Regulieren des Signaldurchlaufs von den Gebietsprozessoren zu dem Zentralprozessor 22 eingesetzt werden, obgleich die vorliegende Erfindung allgemein unter Bezug auf sämtliche Ereignisse beschrieben wurde, die in der in Fig. 6 gezeigten Zentraleinheit auftreten. Liegt eine große Zahl von Gebietsprozessoren vor, so wird die Regulierung gemäß der vorliegenden Erfindung nicht Signal für Signal durchgeführt, sondern unterschiedlich zum Schutz gegenüber Prozessorüberlast anstelle der Pufferüberlast angewandt. Ein Beispiel besteht darin, daß die Gebietsprozessoren eine Zulassung zum Fortführen der Signalgebung zu dem Zentralprozessor bei regulären Intervallen anfordern. Falls die Bestätigung übermäßig aufgrund der hohen Last des Zentralprozessors 22 verzögert ist, muß der Gebietsprozessor RP das Senden der Signale begrenzen oder stoppen. Somit ermöglicht die vorliegende Erfindung, daß die zentrale Regulierfunktion diese von den Gebietsprozessoren ausgehende Signalgebung bei extremen Lastsituationen durchführt.

Weiterhin kann die vorliegende Erfindung zum Ersetzen momentaner Regulierverfahren ohne die Nachteile dieser Verfahren, jedoch mit sämtlichen oben beschriebenen Vorteilen eingesetzt werden. Ein Beispiel besteht in der Handhabung der Lastzuordnung für unterschiedliche Anwendungsmodule in der Zentraleinheit, was im Zusammenhang mit dem Stand der Technik ein Problem darstellt.


Anspruch[de]
  1. 1. Lastregulierverfahren für eine Zentraleinheit in einem Echtzeit-Kommunikationssystem, enthaltend die Schritte:
    1. a) Abgeben zumindest eines Jobs an eine Puffervorrichtung (18), die eine vorspezifizierte Pufferkapazität bereitstellt,
    2. b) Abgeben des in der Puffervorrichtung (18) gespeicherten Jobs an eine Bearbeitungsvorrichtung (22) für die weitere Bearbeitung, und
    3. c) dynamisches Aktualisieren der verfügbaren Pufferkapazität der Puffervorrichtung (18) entsprechend der tatsächlich verwendeten Jobpufferkapazität nach jedem Lastregulierintervall.
  2. 2. Lastregulierverfahren für eine Zentraleinheit in einem Echtzeit-Kommunikationssystem, enthaltend die Schritte:
    1. a) Abgeben zumindest eines Jobs an eine Puffervorrichtung (18), die eine vorspezifizierte Pufferkapazität für jede von mehreren Jobdurchführungs-Prioritätsebenen (A, B, C, D) bereitstellt,
    2. b) Abgeben der in der Puffervorrichtung gespeicherten Jobs an eine Bearbeitungsvorrichtung (22) für die weitere Bearbeitung jeweils entsprechend der Jobdurchführungs-Prioritätsebene,
    3. c) Unterbrechung einer Arbeitseinheit auf einer unteren Jobdurchführungs-Prioritätsebene, falls ein Job auf einer höheren Jobdurchführungs-Prioritätsebene an die Puffervorrichtung (18) abgegeben wird,
    4. d) Durchführen einer dynamischen Steuerung der Last der Berechnungsvorrichtung (22) durch
      1. d1) Senden eines Schleifensignals an eine niedrigere Prioritätsebene, wenn die belegte Jobpufferkapazität die maximal verfügbare Jobpufferkapazität auf einer höheren Prioritätsebene erreicht, und
      2. d2) Wiederaufnahme der Bearbeitung von Jobs auf der höheren Prioritätsebene, wenn eine Bestätigung auf dieser Ebene nach der Bearbeitung des Schleifensignals auf der unteren Prioritätsebene empfangen wird.
  3. 3. Lastregulierverfahren nach Anspruch 2, dadurch gekennzeichnet, daß die verfügbare Jobpufferkapazität mit Anforderungen aufgefüllt wird, die auf der oberen Prioritätsebene in einer Warteschlange eingefügt sind, sobald die Bearbeitung auf der höheren Prioritätsebene wieder aufgenommen wird.
  4. 4. Lastregulierverfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, daß bei jeder Prioritätsebene nach jedem Lastregulierintervall die verfügbare Jobpufferkapazität dynamisch gemäß der tatsächlich verwendeten Jobpufferkapazität aktualisiert wird.
  5. 5. Lastregulierverfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Lastregulierverfahren auch die Regulierung der Prozessorüberlast in dem Fall umfaßt, in dem die Dauer der Jobdurchführung auf den höheren Prioritätsebenen zu lange dauert.
  6. 6. Lastregulierverfahren nach Anspruch 5, dadurch gekennzeichnet, daß die Lastregulierung des Prozessors und die Lastregulierung des Jobpuffers (18) durch Empfangen eines Schleifensignals auf einer unteren oder der untersten Prioritätsebene (S25-1) durchgeführt wird, sowie dem anschließenden Überwachen der Prozessorlast bis zu dem Verstreichen einer Überlastdauer (S25-2) und schließlich durch Fortführen der Jobs auf einer höheren Prioritätsebene (S25-3)
  7. 7. Lastregulierverfahren nach Anspruch 6, dadurch gekennzeichnet, daß die Überwachung der Prozessorlast folgende Schritte enthält:
    1. a) Lesen der Prozessorlast für das letzte Prozessorlast-Überwachungsintervall (S23-1),
    2. b) Akkumulieren der gelesenen Prozessorlast zu der vorher akkumulierten Prozessorlast (S23-2),
    3. c) erneutes Berechnen der Lastregulierparameter (S23-4), und
    4. d) Durchführen der Überwachung der Prozessorlast (S23-6) im Fall daß die Prozessorüberlast während einer festgelegten Zeitdauer fortdauert (S23-5).
  8. 8. Lastregulierverfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt (S23-4) zum erneuten Berechnen der Lastregulierparameter so angepaßt wird, daß die Meldungsbearbeitungsrate MPR gemäß



    MPR=A.(1-0,01)



    angepaßt wird, derart, daß A die durchschnittliche Zahl von Meldungen darstellt, die während des letzten Prozessorlast-Regulierintervalls in dem Fall ausgelesen wurden, in dem die Prozessorüberlast länger als eine vorspezifizierte Zeitperiode vorlag.
  9. 9. Lastregulierverfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt (S23-4) zum erneuten Berechnen der Lastregulierparameter so angepaßt ist, daß die Meldungsbearbeitungsrate gemäß





    modifiziert wird, derart, daß AL die durchschnittliche Last in dem Fall darstellt, in dem die durchschnittliche Prozessorlast unter eine vorspezifizierte untere Prozessorlastgrenze abfällt.
  10. 10. Lastregulierverfahren nach Anspruch 8, dadurch gekennzeichnet, daß der Schritt (S23-6) zum Überwachen der Prozessorlast den Schritt zum momentanen Blockieren des Jobpuffers und von Prozessorkapazitätsanforderungen (S24-5) in dem Fall enthält, in dem die Prozessorüberlastdauer kritisch wird.
  11. 11. Lastregulierverfahren nach einem der Ansprüche 5 bis 10, dadurch gekennzeichnet, daß das Prozessorlast-Überwachungsintervall unterschiedlich von dem für die Regulierung der Jobpuffernutzung vorab spezifizierten Lastregulierintervall gewählt wird.
  12. 12. Lastregulierverfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, daß ein Schritt (S18-4) zum Vorbereiten jedes Lastregulierintervalls vorgesehen wird, der die folgenden Teilschritte aufweist:
    1. a) Überwachung zum Begrenzen der Jobs (S18-2),
    2. b) Überprüfen der Last der Puffervorrichtung (S18-3),
    3. c) Berechnen der verfügbaren Jobpufferkapazität (S18-4),
    4. d) Auslesen jedweder Anforderungen in einer Warteschlange in die Puffervorrichtung (S18-5), und
    5. e) Auslesen jedweder Prozessorlast-Belegungen in einer Warteschlange (S18-6).
  13. 13. Lastregulierverfahren nach Anspruch 12, dadurch gekennzeichnet, daß der Schritt zum Überwachen der Begrenzung der Jobs (S18-2) ferner die Schritte zum Setzen eines Zählers zum Bewerten der Begrenzungsperiode der Jobs (S19-1) und zum Beenden der Überwachung (S19-3) im Fall des Verstreichens der Zeitperiode zum Begrenzen der Jobs (S19-2) umfaßt.
  14. 14. Lastregulierverfahren nach Anspruch 12, dadurch gekennzeichnet, daß der Schritt zum Überprüfen der Last der Puffervorrichtung die folgenden Teilschritte enthält:
    1. a) Überprüfen der Puffervorrichtungsbelegung (S20-1), und
    2. b) Rücksetzen der verbleibenden Jobpufferkapazität in dem Fall, in dem die Last für irgendeine der Prioritätsebenen zu hoch ist (S20-1, S20-3) und Senden des Schleifensignals an eine untere Ebene nach dem Rücksetzen der verbleibenden Jobpufferkapazität (S20-4, S20-5).
  15. 15. Lastregulierverfahren nach Anspruch 12, dadurch gekennzeichnet, daß der Schritt zum Überprüfen der Last der Puffervorrichtung (S18-3) ferner der Schritt zum Rücksetzen der verteilten Jobpufferkapazität für sämtliche Teilnehmer (S20-7) im Fall einer kritischen Last (S20-6) umfaßt.
  16. 16. Lastregulierverfahren nach Anspruch 12, dadurch gekennzeichnet, daß der Schritt zum Berechnen der verfügbaren Jobpufferkapazität (S18-4) gemäß



    Verfügbare Kapazität = (Größe, die von Funktionen mit Speicherbereichen mit verteilter Kapazität benützt wird + Größe, die von Funktionen benützt wird, die Jobpufferkapazität bei Bedarf anfordern - momentane Pufferbelegung)/(maximal von einem einzigen Job eingesetzte Größe)



    durchgeführt wird.
  17. 17. Lastregulierverfahren nach Anspruch 12, dadurch gekennzeichnet, daß der Schritt zum Auslesen jedweder in der Warteschlange vorliegender Anforderungen in die Puffervorrichtung (S18-5) die folgenden Teilschritte enthält:
    1. a) Überprüfen, ob Anforderungen in eine Warteschlange eingefügt sind (S21-1) und Auslesen derartiger Anforderungen (S21-2),
    2. b) Durchführen der Abfrage, ob die für die ausgelesenen Anforderungen erforderliche Jobpufferkapazität niedriger als die verfügbare Jobpufferkapazität ist (S21-3),
    3. c) Bestätigen der ausgelesenen Anforderung und Reduzierung der verbleibenden Jobpufferkapazität (S21-4), wenn die Abfrage im Schritt b) bestätigt wird, und
    4. d) erneutes Einfügen der Anforderung in die Warteschlange und Rücksetzen gegebenenfalls verbleibender Jobpufferkapazität (S21-6), wenn die Abfrage im Schritt b) verneint wird.
  18. 18. Lastregulierverfahren nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, daß der Schritt zum Abgeben von Jobs an die Puffervorrichtung (18) (Schritt a), Ansprüche 1, 2) in die folgenden Teilschritte unterteilt wird:
    1. a) Klassifizierung des Anforderungstyps gemäß "soweit verfügbar" oder "Gesamtanforderung ist zu erfüllen" (S11-1, S12-1),
    2. b) Vergleichen der angeforderten Jobpufferkapazität mit der verfügbaren Jobpufferkapazität (S11-2),
    3. c) Bestätigen der Anforderungen (S11-3) und Aktualisieren der Jobpufferkapazität (S11-4), wenn die Abfrage im Schritt b) bejahend ist, und
    4. d) Einfügen der Anforderungen in zugeordnete Warteschlangen (qa, qb, qc; S11-6), wenn die Abfrage im Schritt b) negativ ist.
  19. 19. Lastregulierverfahren nach einem der Ansprüche 2 bis 18, dadurch gekennzeichnet, daß ein Schleifensignal zu einer niedrigeren Ebene gesendet wird, wenn nicht genügend Jobpufferkapazität vorliegt (S11-5) oder eine Anforderung in eine Warteschlange eingefügt wird (S11-6).
  20. 20. Lastregulierverfahren nach Anspruch 18, dadurch gekennzeichnet, daß der Schritt zum Bestätigen einer Anforderung ferner einen Abfrageschritt (S12-3) aufweist, wenn die Anforderung vom Typ "Gesamtanforderung ist zu erfüllen" ist, und zwar dahingehend, ob die angeforderte Jobpufferkapazität kleiner oder gleich der verfügbaren Jobpufferkapazität ist, um die Anforderung in die Warteschlange einzufügen (S12-5), wenn dies nicht der Fall ist.
  21. 21. Lastregulierverfahren nach Anspruch 18, dadurch gekennzeichnet, daß der Schritt zum Einfügen einer Anforderung in eine Warteschlange ferner folgende Teilschritte enthält:
    1. a) Überprüfen, ob die Warteschlange vollständig gefüllt ist (S13-2),
    2. b) Einfügen der Anforderung in die Warteschlange, wenn genügend Warteschlangenkapazität zur Verfügung steht (S13-3), und
    3. c) Abweisen der Anforderung, wenn nicht genügend Jobkapazität zur Verfügung steht (S13-4, S13-5).
  22. 22. Lastregulierverfahren nach einem der Ansprüche 18 bis 20, dadurch gekennzeichnet, daß ferner ein Schritt zum Auslesen von in den Warteschlangen abgelegten Anforderungen vorgesehen wird, und zwar bei Bestätigung eines Schleifensignals von einer unteren Prioritätsebene (S14-1, Fig. 16).
  23. 23. Lastregulierverfahren nach Anspruch 22, dadurch gekennzeichnet, daß der Schritt zum Auslesen von Anforderungen aus den Warteschlangen (S14-3) ferner enthält:
    1. a) einen Schritt zum Vergleichen der Jobpufferkapazität mit der verfügbaren Jobpufferkapazität (S15-3) beim Auslesen des angeforderten Jobs,
    2. b) Bestätigen des angeforderten Jobs, wenn genügend Jobpufferkapazität zur Verfügung steht (S15-6), und
    3. c) erneutes Plazieren des angeforderten Jobs in der Warteschlange (S15-4), wenn die angeforderte Jobpufferkapazität größer als die verfügbare Jobpufferkapazität ist.
  24. 24. Lastregulierverfahren nach einem der Ansprüche 1 bis 23, dadurch gekennzeichnet, daß beim Anlaufen des Echtzeit-Kommunikationssystems ein Teilnehmerbericht über den Einsatz der Jobpufferkapazität empfangen wird (S27-1), und anschließend der Teilnehmerbericht entweder als Normaltyp (S27-3) oder als Typ mit verteilter Zuordnung (S27-4) gespeichert wird.
  25. 25. Lastregulierverfahren nach Anspruch 24, dadurch gekennzeichnet, daß beim Anlaufen des Echtzeit-Kommunikationssystems Jobpuffer-Speicherbereiche auf der Basis der Teilnehmerabgabedaten berechnet werden (S28-2).
  26. 26. Lastregulierverfahren nach einem der Ansprüche 1 bis 25, dadurch gekennzeichnet, daß auch ein Schritt (S31-1) zum Empfangen eines Betriebssysteminterrupts im Fall einer hohen Jobpufferlast vorgesehen wird.
  27. 27. Lastregulierverfahren nach Anspruch 26, dadurch gekennzeichnet, daß im Fall des Empfangs eines Interrupts von dem Betriebssystem die verfügbare Jobpufferkapazität und die Prozessorlast-Belegungen momentan blockiert werden (S31-3) und eine Überwachungsperiode für eine Jobbegrenzung gestartet wird (S31-4).
  28. 28. Lastreguliereinheit für ein Echtzeit-Kommunikationssystem, enthaltend:
    1. a) eine Puffervorrichtung (18) zum Bereitstellen von Pufferkapazität für Jobs, die in dem Echtzeit-Kommunikationssystem zu verarbeiten sind,
    2. b) eine Bearbeitungsvorrichtung (22) zum Handhaben der an die Puffervorrichtung (18) abgegebenen Jobs, und
    3. c) eine Lastreguliervorrichtung (20, 26) zum dynamischen Angleichen der verfügbaren Pufferkapazität der Puffervorrichtung (18) in Übereinstimmung mit der tatsächliche belegten Jobpufferkapazität bei Beginn jedes Lastregulierintervalls.
  29. 29. Lastreguliereinheit für ein Echtzeit-Kommunikationssystem, enthaltend:
    1. a) eine Puffervorrichtung zum Bereitstellen von Pufferkapazität für mehrere Jobdurchführungs-Prioritätsebenen (A, B, C, D),
    2. b) eine Berechnungsvorrichtung (22) zum Handhaben der an die Puffervorrichtung (18) abgegebenen Jobs, und
    3. c) eine Lastreguliereinheit (20, 26) ausgebildet zum
      1. c1) Abgeben eines Jobs an die Puffervorrichtung (18) gemäß der jeweiligen Jobdurchführungs-Prioritätsebenen und der der Jobdurchführungs-Prioritätsebene zugeordneten Pufferkapazität,
      2. c2) Senden eines Schleifensignals an eine niedrigere Prioritätsebene, wenn die in der Puffervorrichtung (18) belegte Pufferkapazität auf der höheren Prioritätsebene die maximal verfügbare Pufferkapazität erreicht, und
      3. c3) Wiederaufnahme der Bearbeitung von Jobs auf der höheren Prioritätsebene, wenn bei Bearbeitung des Schleifensignals auf der unteren Prioritätsebene eine Bestätigung an die höhere Prioritätsebene erfolgt.
  30. 30. Lastreguliereinheit nach Anspruch 28 oder 29, dadurch gekennzeichnet, daß sie ferner eine Zentralprozessor-Überlastvorrichtung (28) zum Überwachen der Lastbedingung der Prozessorvorrichtung (22) zum Erzielen eines optimalen Einsatzes der Prozessorkapazität enthält.
  31. 31. Lastreguliereinheit nach einem der Ansprüche 28 bis 30, dadurch gekennzeichnet, daß sie ferner eine Anlaufeinheit (30) zum Steuern des Echtzeit-Kommunikationssystems während des Anlaufs des Betriebs enthält.
  32. 32. Lastreguliereinheit nach einem der Ansprüche 28 bis 31, dadurch gekennzeichnet, daß eine Warteschlangenvorrichtung (qa, qb, qc) für jede Jobdurchführungs-Prioritätsebene (A, B, C) vorgesehen ist.
  33. 33. Lastreguliereinheit nach einem der Ansprüche 28 bis 32, dadurch gekennzeichnet, daß die Puffervorrichtung so ausgebildet ist, daß sie einen Jobpufferkapazität-Speicherbereich (a-1, a-2, b-1, c-1, c-2) für jede der mehreren Teilnehmerfunktionen bereitstellt.
  34. 34. Lastreguliereinheit nach einem der Ansprüche 28 bis 33, dadurch gekennzeichnet, daß sie zum Durchführen eines Lastregulierverfahrens nach einem der Ansprüche 1 bis 27 ausgebildet ist.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com