Ressourcen-Optimierer für Software-Ökosysteme

Auf dem Gebiet der Digitaltechnik und bei der Verwendung von elektronischen Systemen ist es ein wichtiges Ziel, die verfügbaren Ressourcen, optimiert einzusetzen und bedarfsgerecht zu verteilen. Dies trifft auf integrierte Schaltkreise (in- tegrated circuits, IC) ebenso zu, wie auf andere elektronische Systeme, etwa Betriebssysteme. Beispielsweise muss auch die elektronische Schaltung eines programmierbaren Bausteins, wie eines Field Programmable Gate Arrays (FPGA) so programmiert werden, dass die erforderliche Performance der Schaltung eingehalten werden kann.

Dieselben Anforderungen gelten auch für Software-Ökosysteme bzw. Ecosystems (im Folgenden: SECOs) . Gemäß einer Definition können SECOs charakterisiert werden als eine Ansammlung von Software Produkten, die gegebene Abhängigkeiten untereinander aufweisen (D.G. Messerschmitt and C. Szyperski, Software ecosystem: understanding an indispensable technology and in- dustry, MIT Press Books, 1, 2005) . Diese Systeme haben den Anspruch, unterschiedlichste Applikationen von unterschiedlichen Anbietern auf einer gemeinsamen Plattform (gekennzeichnet durch gemeinsame APIs, Bibliotheken und/oder gemeinsam genutzte Hardware-Ressourcen) und einer gemeinsamen technolo- gischen Basis mit einer Referenzarchitektur betreiben zu können. Insbesondere müssen die Hardware Ressourcen, wie z.B. der Prozessor (CPU) oder die Gruppe von Prozessoren oder Speicherbausteine abhängig von den Anforderungen der jeweiligen Applikation aus der Menge von Applikationen zugewiesen werden.

Ein übliches Anwendungsszenario in einem SECO-System ist das Deployment von einer Vielzahl von unterschiedlichen Applikationen auf derselben physikalischen Hardware. Dabei haben die Applikationen jeweils neben den inhaltlichen, funktionalen Anforderungen auch so genannte nicht-funktionale Anforderungen (non- functional requirements , NFR) , wie z.B. die Performance . „

Im Stand der Technik kann ein wirklich paralleler Betrieb aller Applikationen, bei dem sämtliche Applikations- Anforderungen (insbes. an die Performance) jederzeit eingehalten werden, in der Regel nicht garantiert werden, da die exakten Nutzungsmuster und/oder Ressourcen-Bedarfe der einzelnen Applikationen nicht bekannt sind oder nicht gesamtheitlich verrechnet werden. Zudem können im Stand der Technik die Ressourcen nicht während der Laufzeit und somit nicht dynamisch zugewiesen werden, was eine Möglichkeit zur Zuweisung von während der Laufzeit frei werdenden Ressourcen, und somit prinzipiell zusätzlichen Ressourcen, ungenutzt lässt.

Im Stand der Technik sind grundsätzlich zwei Prinzipien zur Zuweisung von Ressourcen bekannt. Nach einem ersten Ansatz wird eine Menge von Hardware Ressourcen für eine Menge von Applikationen bereitgestellt, ohne dass die Performance- Vorgaben der Applikationen für die Auswahl der Ressourcen berücksichtigt werden. Dies geht mit dem Nachteil einher, dass tendenziell eher hohe Hardware-Kosten beim Aufsetzen des Systems anfallen und weiterhin auch höhere Entwicklungskosten, da die Entwicklung auf Basis der bestehenden, eingeschränkten Hardware ausgeführt werden muss (und nicht umgekehrt, was die Entwicklung vereinfachen würde) . Gemäß einem zweiten Ansatz wird eine dedizierte Hardware Ressource für jeweils eine Applikation reserviert. Dies ist jedoch mit dem Nachteil verbunden, dass die Ressourcen nicht oder nur selten bedarfsgerecht ausgelegt sind, sondern entweder über- oder unterdimensioniert sind, da der aktuelle Bedarf der Applikation bei der Reservierung der Ressourcen nicht berücksichtigt worden ist.

Es besteht nun die Aufgabe, die Zuweisung von in einem SECO (also einem SECO System) verfügbaren Ressourcen auf die Menge der Applikationen derart auszuführen und zu steuern, dass eine bedarfsgerechte und für die Gesamtheit der Menge der Applikationen optimierte Verteilung der Ressourcen auch bei zur Laufzeit veränderten Bedingungen gewährleistet werden kann. Dabei ist es wichtig, dass nicht nur eine Applikation, deren Ressourcenverbrauch und deren NFR-Bedingungen berücksichtigt werden, sondern dass dies gesamtheitlich für die ganze Menge der Applikationen berechnet wird. Dabei sollen die verfügbaren Ressourcen auf dem Ziel -System bzw. auf der Ziel -Hardware als Konfigurationsvorgabe ebenso verrechnet werden, wie das Performance-Verhalten jeder der beteiligten Applikationen unter Beachtung der verfügbaren Ressourcen. Diese Information soll in Form einer Ressourcen-Kosten-Funktion (resource-cost function, RCF-Funktion) verrechnet werden.

Diese Aufgabe wird durch die beiliegenden nebengeordneten Patentansprüche gelöst, insbesondere durch ein computerimplementiertes Verfahren, durch einen Ressourcenoptimierer, ein Steuerungsmodul und SECO-System mit einem solchen Steuerungs- modul sowie durch ein Computerprogrammprodukt.

Im Folgenden wird die Erfindung anhand des Verfahrens beschrieben. Hierbei erwähnte Ausführungsformen, alternative Lösungen, weitere Merkmale und Vorteile sind ebenso auch auf die anderen Lösungen der vorstehend genannten Aufgabe zu übertragen (also auf das Computerprogrammprodukt und auf das Steuerungsmodul) . Demnach können auch die Unteransprüche, die zum Verfahren formuliert und beschrieben sind, auch auf die Anordnung und das Computerprogrammprodukt zu übertragen sein und umgekehrt. Dabei sind die jeweiligen funktionalen Merkma- le des Verfahrens durch entsprechende Mikroprozessormodule oder Hardwaremodule implementiert, die dazu ausgebildet sind, die jeweilige Funktionalität zu übernehmen.

Gemäß einem ersten Aspekt bezieht sich die Erfindung auf ein computerimplementiertes Verfahren zur optimierten, perfor- mance-abhängigen und bedarfsgerechten Allokation von einer Menge von verfügbaren Ressourcen auf eine Menge von Applikationen, die in einem SECO-System als Zielsystem deployed sind oder werden und dort parallel betreibbar sein sollen, umfassend folgende Verfahrensschritte:

- Erfassen von Input-Datensätzen zur Spezifikation von einem ersten Parametersatz, umfassend nicht-funktionale Anforderungen für jede der Applikationen.

- Anwenden eines Konfigurationsverfahrens zur Konfiguration der Ressourcen und zur Berechnung einer Anzahl von benötigten Ressourcen in Abhängigkeit von den erfass- ten, nicht-funktionalen Anforderungen der jeweiligen Applikation - Berechnen und Bereitstellen von Allokationsdaten und Verteilen der Ressourcen auf Basis der Allokationsdaten auf die Menge der Applikationen.

Das Verfahren ist in der Regel computerimplementiert. Dabei kann es sein, dass bestimmte Verfahrensabschnitte als Teil einer Mikroprozessorlösung und somit fest verdrahtet sind, während andere Abschnitte des Verfahrens als Software ausgebildet sind. In diesem Fall wären nur einzelne Abschnitte oder Teile des Verfahrens softwareimplementiert. In der Regel sind alle oder ausgewählte Abschnitte des Verfahrens binär codiert oder sie liegen in digitaler Form vor. Dabei können alle oder einzelne Abschnitte des Verfahrens als Quellcode (Source Code) , als bereits fertig kompilierter Code (Maschinencode) oder als interpretierter Code (z.B. in den

Interpretersprachen Python, PHP, Ruby) bereitgestellt werden oder mittels eines Interpreters (z.B. Jit-Compilers) interpretiert werden. Für die Durchführung des erfindungsgemäßen Verfahrens und der weiter beanspruchten Produkte ist es unerheblich, in welcher Programmiersprache (z.B. C++, Java, Perl oder PHP etc.) die Software vorliegt. Wesentlich ist, dass die Software als Teil eines technischen Systems in das technische Gerät unmittelbar eingebunden ist und dort zur Steuerung von Zuweisungen technischer Ressourcen dient. Die Teile des erfindungsgemäßen Verfahrens, die als Software implemen- tiert sind, können Teil eines sogenannten „embedded Systems" sein, das in das umgebende technische System, z.B. in ein Zuginformationssystem oder in ein Verkehrsleitsystem eingebettet ist und mit diesem in Wechselwirkung steht.

Im Folgenden werden die Begrifflichkeiten dieser Anmeldung näher erläutert.

Ein Ecosystem kann auf einer verteilten Plattform aufgebaut sein und umfasst unabhängige und interagierende Applikationen, die auf derselben physikalischen Hardware bzw. teilweise denselben Hardwareressourcen deployed sind. Dabei sollen die Applikationen unter Einhaltung der Performance Anforderungen für das gesamte Ecosystem parallel betrieben werden können. Bei den Ressourcen handelt es sich um Hardware Ressourcen, wie Prozessoren/CPUs, Prozessorkerne, Speicher bzw. Speicherbausteine, Datenträger, Schnittstellen, insbesondere für Netzzugriffe und Speicherzuordnungen oder um weitere physika- Iisehe Produkte.

Der Input-Datensatz und/oder die Allokationsdaten sind digitale Daten, die in unterschiedlichen Formaten verarbeitet und transferiert werden können. Es kann sich um mehr-komponentige elektronische Datensätze handeln. Ein normierter Ressourcenverbrauch ist der Verbrauch von

Hardware Ressourcen bezogen auf eine wohldefinierte Standardhardware .

Das erfindungsgemäße Allokationsverfahren kann für zwei unterschiedliche Aspekte eingesetzt werden. Zum Einen kann es zur effizienten und bedarfsgerechten Planung und Auslegung eines neu zu erzeugenden SECO-Systems verwendet werden, insbesondere um die zur Ausführung der Applikationen minimal benötigten Ressourcen zu berechnen. Auf Basis der so ermittelten Ressourcendaten kann das SECO-System dann ausgelegt wer- den. Zum Anderen kann das Allokationsverfahren bei bereits aufgesetzten SECO-Systemen angewendet werden, um zu entscheiden, ob eine Menge von Applikationen bei den jeweils vorhandenen Hardware Ressourcen gleichzeitig betrieben werden kann unter vollständiger Erfüllung aller Performance Anforderungen oder ob ausgewählten Applikationen in ihrer derzeitigen Form das Deployment verweigert werden sollte, um die sozusagen „restliche Menge" von Applikationen optimiert ausführbar zu halten. Darüber hinaus kann berechnet werden, welche und wie viele Ressourcen den einzelnen Applikationen zur Verfügung gestellt werden sollen.

Bei den nicht-funktionale Anforderungen, die für jede der Applikationen erfasst werden, handelt es sich vorzugsweise um Anforderungen hinsichtlich der Performance.

Die Erfindung betrifft somit ein Verfahren, ein Software Pro- dukt und ein System zur optimierten und bedarfsgerechten Zuweisung von Hardware Ressourcen auf eine Menge von Applikati- onen zur Laufzeit, die in einem SECO-System bereitgestellt werden sollen.

Die Erfindung transformiert Input-Datensätze in Allokations- daten. Die Allokationsdaten können insbesondere Angaben um- fassen, ob eine Menge von Applikationen auf der jeweiligen

Hardware mit den entsprechenden Konfigurationen deployed werden kann. Bei den Input-Datensätzen handelt es sich Hardware- Informationen, insbesondere die verfügbaren System Ressourcen, die Applikationen und deren RCF-Funktionen und Perfor- mance Zielvorgaben und Konfigurationsdaten.

Das erfindungsgemäße Verfahren und System implementiert eine Menge von Algorithmen, um eine Gesamtverteilung zu berechnen. Die Gesamtverteilung umfasst eine Allokation von allen in der SECO verfügbaren Ressourcen auf alle benötigten Applikationen im Parallelbetrieb und damit auf die Gesamtheit der Applikationen. Es erfolgt somit keine Allokation oder Zuweisung von Ressourcen für eine einzelne Applikation für sich separat, wie im Stand der Technik, sondern es wird die gesamte Menge der Applikationen und die gesamte Menge der in dem SECO- System verfügbaren Ressourcen verrechnet. Aufgrund dieser gesamtheitlichen Überalles-Zuweisungsstrategie können für die gesamte Menge der Applikationen bessere Allokations- und Performanceergebnisse erzielt werden.

Das erfindungsgemäße Verfahren und System wird bevorzugt als Qualitätsinstanz in Form eines Zusatzmoduls direkt in dem

SECO-System betrieben, um beispielsweise bei einem bestehenden SECO-System die Kundenzufriedenheit bei der Verfügbarkeit der angeforderten Ressourcen sicherzustellen. In dieser Ausführungsform der Erfindung wird das Verfahren für alle Appli- kationen zentral auf dem SECO-System ausgeführt. Dies hat den Vorteil, dass die Input-Datensätze ohnehin für alle Applikationen vorhanden sind und nicht von anderen Einheiten angefordert und zusätzlich eingelesen werden müssen. In einer alternativen Ausführungsform der Erfindung ist es auch möglich, das erfindungsgemäße Verfahren und System auf Seiten eines Applikationsanbieters bzw. einer Applikation und somit client-seitig und dezentral anzuwenden, damit dieser seinen Ressourcenbedarf klar planen und steuern kann. In diesem Fall ist es vorgesehen, dass zwischen der SECO-Plattform und der Client-Instanz der Applikation ein Datenaustausch vorgesehen ist, damit der Client die notwendigen Informationen, insbesondere über die Verfügbarkeit der physikalischen Ressourcen erhält.

In einer bevorzugten Ausführungsform der Erfindung werden die Allokationsdaten automatisch ohne Verarbeitung von Nutzerbefehlen berechnet. Insbesondere werden das Selektions-, Konfi- gurations- und/oder Überschuss-Allokationsverfahren automa- tisch ausgeführt. Damit kann das Zuweisungsverfahren effizient und unabhängig von der Notwendigkeit von Benutzereingaben ausgeführt werden.

Die Allokationsdaten umfassen einen Allokationsbefehl . Der Begriff „Allokationsbefehl " ist hier nicht im Sinne eines Be- triebssystembefehls , z.B. in Linux, zu verstehen, sondern als übergeordneter Befehl, der zwar die verfügbaren Ressourcen den Applikationen zuweist, der aber unabhängig von dem jeweiligen Betriebssystem ist. Somit soll der Allokationsbefehl erfindungsgemäß unabhängig von der zugrundeliegenden Techno- logie bereitgestellt werden können und damit unabhängig davon sein, ob das Betriebssystem z.B. PikeOS, ein anderes echt- zeitfähiges Betriebssystem oder Linux ist. Vorzugsweise wird die Erfindung als Virtualisierungslosung mit LinuX Containers bereitgestellt, das mehrere voneinander isoliert laufende Li- nux-Systeme auf einem einzigen Host ermöglicht.

Die bevorzugte Anwendung der Erfindung betrifft ein SECO- System für das schienengebundene Verkehrswesen. Bei diesem verkehrstechnischen SECO-System sind die Applikationen z.B. im Bereich der Antriebssysteme, Fahrwerke und Bordnetzversor- gung angeordnet. Sie können Verkehrsleitapplikationen, Verkehrsüberwachungsapplikationen, Fahrgastüberwachungsapplikationen, umfassend eine videosignalbasierte Überwachung oder weitere Applikationen für das öffentliche Transportwesen umfassen. In einer alternativen Ausführungsform der Erfindung kann das SECO-System auf das Gebiet der industriellen Fertigung, der Energieerzeugung und des Managements von technischen Systemen oder für medizintechnische Anlagen angewendet werden . Gemäß einer weiteren Ausführung der Erfindung umfasst das Konfigurationsverfahren ein Einlesen von Konfigurationsanforderungen über eine Input-Schnittstelle . Die Konfigurationsanforderungen dienen zur Konfiguration der physikalischen Res- sourcen und/oder zum Berechnen von einer Anzahl von benötigten physikalischen Ressourcen pro Applikation. Die Konfigurationsanforderungen können entweder in dem ersten Parametersatz enthalten sein oder sie können als zusätzliche Daten separat eingelesen werden. Das Konfigurationsverfahren dient zum Berechnen der entsprechenden Ressourcenkonfigurationen bei den erfassten Eingangsdaten in Bezug auf die Applikation und/oder das SECO-System. Hier kann eingestellt werden, dass die Applikationen-Ressourcen-Zuweisung derart erfolgt, dass eine hohe Performanz für eine oder ausgewählte Applikationen bereitgestellt werden kann. Dabei kann ein Konfigurationsverfahren zur Anwendung kommen, nach dem die Ressourcen für jeweils eine Applikation so lange hinzugefügt bzw. erhöht werden, bis ein Grenz-Performance-Gewinn steigt oder zumindest einen konfigurierbaren Prozentsatz (z.B. 10%) des maximalen Grenz- Performance-Gewinns aufweist. Ebenso kann es konfiguriert werden, dass grundsätzlich nur eine minimale Anzahl von Ressourcen verbraucht werden soll. Weiterhin kann es konfiguriert werden, dass alle oder ausgewählte Applikationen dedi- zierte Performanz -Zielvorgaben erreichen können. Diese können als Input-Datensatz , beispielsweise in den NFR-Bedingungen festgelegt sein. Darüber hinaus kann die Ressourcenkonfiguration so gewählt werden, dass vorkonfigurierte hohe Performanz -Vorgaben gemäß den NFR-Bedingungen eingehalten werden. Das Konfigurationsverfahren kann in einem Konfigurator imple- mentiert sein und ausgeführt werden.

In einer bevorzugten Ausführungsform der Erfindung umfasst das Verfahren zumindest einen der folgenden zusätzlichen Verfahrensschritte :

- Anwenden eines Selektionsverfahrens auf die Menge der Ap- plikationen zur Auswahl von zu deployenden Applikationen, so dass sichergestellt werden kann, dass eine Ausführbarkeit für alle Applikationen unter Einhaltung der nichtfunktionalen Anforderungen sichergestellt werden kann. Das Selektionsverfahren wird insbesondere dann angewendet, falls nicht sichergestellt werden kann, dass auch alle Applikationen sicher ausführbar sind. In diesem Fall müssen eine oder mehrere Applikation von der SECO-Plattform entfernt werden, um die Ausführbarkeit der anderen Applikationen sicherstellen zu können. Bei der Auswahl der verbleibenden und zu deployenden Applikationen können unterschiedliche, konfigurierbare Selektionsstrategien zum Einsatz kommen. Das Selektionsverfahren wird insbesondere vor der Anwendung des Konfigurationsverfahrens ausgeführt. Das Selektionsverfahren kann prioritätsbasiert sein, indem den Applikationen jeweils Prioritäten zugewiesen werden. Die Applikationen werden auf Basis der ihnen zugewiesenen Prioritäten sortiert und mit Ressourcen versorgt, solange bis alle Ressourcen aufgebraucht sind. Alternativ kann es anzahlbasiert sein, so dass eine maximale Anzahl von Applikationen auf dem SECO-System als Zielsystem deployed werden kann. Das Selektionsverfahren kann in einem Selektor ausgeführt werden.

- Anwenden eines Überschuss-Allokationsverfahrens zur Bestimmung einer Allokationssteuerungsmaßnahme , die definiert, wie nicht benötigte physikalische Ressourcen auf die Menge der Applikationen zugewiesen werden sollen. Das Überschuss-Allokationsverfahren wird insbesondere nach der Anwendung des Konfigurationsverfahrens ausgeführt. Dabei kann es eingestellt werden, wie die nicht-benötigte Ressourcen gleichmäßig auf alle oder ausgewählte Applikationen verteilt werden. Es kann auch eingestellt sein, dass die überschüssigen Ressourcen (die nicht benötigten) gemäß der erfassten Priorität der Applikationen auf diese zugewiesen werden. Auch kann es eingestellt werden, dass die überschüssigen Ressourcen überhaupt nicht verteilt werden, um diese sozusagen für Notszenarien oder für Applikationen, die zu einem späteren Zeitpunkt dem SECO hinzugefügt werden verfügbar zu halten. Das Überschuss- Allokationsverfahren kann in einem Überschuss-Allokator ausgeführt werden.

Als Minimalanforderung umfasst der erste Parametersatz ein sogenanntes Performance-Engineering-Tripel . Dieses beinhal- - Angaben über ein Applikationsszenario . Dazu werden die Applikation und ihr Laufzeitverhalten analysiert. Alle kritischen Anwendungsfälle werden identifiziert und dann durch entsprechende Sensoren zur Erfassung von Messsignalen vermessen. Dabei handelt es sich beispielsweise um Fälle, in denen ein außergewöhnlich hoher Ressourcenverbrauch (z.B. an Prozessorleistung oder an Speicher oder an Datenübertragungsbandbreite etc.) oder eine

konfigurierbare Schwelle übersteigende Latenzwerte zu erwarten sind. Soll z.B. ein Videostream von einer Fahrgastüberwachungskamera auf ein Display übertragen werden, so kann es aufgrund der begrenzten Bandbreite und/oder der Datenmenge zu kritischen Latenzen und insgesamt zu einem kritischen Applikationsszenario kommen.

- Angaben über ein Lastmodell des Applikationsszenarios. Dies umfasst beispielsweise Angabe über das charakteristische Nutzungsprofil, d.h. dem Zeitverlauf der Nutzungsintensität ausgedrückt z.B. in Berechnungen pro Minute. Z.B. kann aus den automatischen Berechnungen eine Grafik erzeugt werden, die den Ressourcenverbrauch einer verkehrstechnischen Anwendung zeigt, die zu diskreten Ereignissen, wie dem Erreichen eines Bahnhofs, einen hohen Ressourcenbedarf hat, aber nicht während z.B. der Fahrt.

- Normierte Ressourcenverbräuche . Die erfassten Ressourcen- verbräuche der Applikationen werden normiert, um sie für die Optimierung bzw. Allokation vergleichbar zu machen. Die normierten Verbräuche beziehen sich auf den Bedarf bei einer wohldefinierten Hardware bzw. an festgelegten physikalischen Ressourcen.

In einer Weiterbildung der Erfindung ist das Erfassen der In- put-Datensätze zur Spezifikation eines zweiten Parametersatzes bestimmt, der zumindest einen der folgenden Datensätze umfasst :

- Performance-Anforderungen,

- Konfigurations-Strategien und/oder

- Verfügbare physikalische Ressourcen, insbesondere

Hardware-Ressourcen . Damit kann das erfindungsgemäße Allokationsoptimierungsver- fahren noch flexibler ausgeführt werden, indem zusätzliche Eingangsgrößen getrennt von dem ersten Parametersatz erfasst werden und diese zudem getrennt von dem ersten Parametersatz erfasst werden können. Die Allokationsdaten werden dann derart berechnet, dass die Konfigurations-Anforderungen und/oder die Performance-Anforderungen bei den jeweils aktuell erfass- ten verfügbaren physikalischen Ressourcen für alle Applikationen - also für die Gesamtheit der Menge aller Applikationen - gleichzeitig eingehalten werden. Die Konfigurations- Strategien können auch Konfigurations-Anforderungen umfassen. Gemäß einem Aspekt werden die Konfigurations-Strategien vom Anwender bestimmt und machen bestimmte Konfigurationseinstellungen erforderlich. Letztere werden als Konfigurations- Anforderungen zur weiteren Berechnung berücksichtigt.

Gemäß einem Aspekt ist es vorgesehen, dass das Verfahren iterativ angewendet wird. Dabei kann auch bei Hinzukommen neuer Applikationen die bereits berechnete Konfiguration bei der Berechnung der Allokationsdaten berücksichtigt werden. Die Performance-Anforderungen und die Konfigurations- Anforderungen werden dann nicht nochmals neu erfasst, sondern es kann auf die bereits eingelesenen Werte zurückgegriffen werden .

Gemäß einem ersten Aspekt kann das Verfahren zur Installation - also bei Auslegung oder Planung - eines SECO-Systems verwendet werden. Dann umfassen die berechneten Allokationsdaten zumindest eine Mindestanzahl von benötigten physikalischen Ressourcen .

Gemäß einem zweiten Aspekt kann das Verfahren zur Steuerung eines bereits installierten SECO-Systems mit gegebenen physikalischen Ressourcen verwendet werden. In diesem Fall umfassen die berechneten Allokationsdaten zumindest einen Betriebsdatensatz, der angibt, ob die Menge der Applikationen bei den verfügbaren physikalischen Ressourcen unter Einhai - tung der nicht-funktionalen Anforderungen parallel betrieben werden kann und/oder einen Allokationsbefehl , der angibt, welche und wie viele physikalische Ressourcen der jeweiligen Applikation aus der Menge der Applikationen zur Verfügung gestellt werden müssen.

In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass insbesondere zeitlich vor einer Installation des SECO-Systems oder vor einer Konfiguration eines bestehenden SECO-Systems automatisch eine Warnmeldung ausgegeben wird, falls die berechneten Allokationsdaten kennzeichnen, dass die verfügbaren physikalischen Ressourcen zum parallelen Betrieb der Applikationen nicht ausreichen. Üblicherweise umfasst das Verfahren nicht nur die Ausgabe der Allokationsdaten, die dann zentral und client-seitig verwendet werden können, sondern die Allokationsdaten werden auch zur tatsächlichen physikalischen Zuweisung der physikalischen Ressourcen auf die Menge der Applikationen zum Aufsetzen bzw. zum Betrieb des SECO-Systems verwendet.

Die Aufgabe wird weiterhin gelöst durch ein Steuerungsmodul zur bedarfsgerechten und ganzheitlichen Allokation von einer Menge von in einem SECO-System verfügbaren physikalischen Ressourcen auf eine Menge von Applikationen, die in dem SECO- System für einen Parallelbetrieb zu deployen sind, umfassend:

- Eine Input-Schnittstelle zum Erfassen von Input- Datensätzen zur Spezifikation von zumindest einem ersten Parametersatz, umfassend nicht-funktionale Anforderungen für jede der Applikationen

- Einen Konfigurator, der zur Anwendung eines Konfigurationsverfahrens zur Konfiguration der physikalischen Ressourcen bestimmt ist, so dass die Applikationen deren erfasste, nicht-funktionale Anforderungen einhalten und/oder so wenig wie möglich der physikalischen Res- sourcen verbrauchen

- Einem Prozessor, der zum Berechnen von Allokationsdaten und zum Bereitstellen derselben bestimmt ist, wobei die Allokationsdaten einen Allokationsbefehl umfassend, mit dem die verfügbaren physikalischen Ressourcen zur Lauf- zeit in Abhängigkeit von den mittels des Konfigurators konfigurierten physikalischen Ressourcen der Menge von Applikationen zugewiesen werden. Das Steuerungsmodul wird vorzugsweise innerhalb des SECO- Systems betrieben und ist auf diesem ausgebildet. Der

Konfigurator und der Prozessor sind separate bzw. verteilte computer-basierte Instanzen. Alternativ können diese jedoch auch aus dem Steuerungsmodul ausgelagert werden. Des Weiteren können sie als eine kombinierte Einheit bereitgestellt werden .

Eine weitere Aufgabenlosung wird durch ein Computerprogramm und ein Computerprogrammprodukt bereitgestellt, das in einen internen Speicher eines digitalen Computers geladen werden kann und Softwareroutinen umfasst, mit denen die Schritte des Verfahrens gemäß den vorstehenden Verfahrensansprüchen ausgeführt werden, wenn die Softwareroutinen auf dem digitalen Computer ausgeführt werden.

Die oben beschriebenen Merkmale, bevorzugten und alternativen Ausführungsformen, Eigenschaften und Vorteile der Erfindung werden im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen zu lesen sind, näher erläutert. Dabei zeigen:

Figur 1 eine Übersicht über ein beispielhaftes SECO-System im Rahmen einer bevorzugten Ausführungsform der Erfindung,

Figur 2 eine schematische Darstellung eines Ressourcenopti - mierers im Rahmen eines SECO-Systems ,

Figur 3 eine alternative Ausführungsform der Erfindung zur

Einbindung des Ressourcenoptimierers ,

Figur 4 ein Ablaufdiagramm gemäß einem Verfahren nach einer bevorzugten Ausführungsform der Erfindung und

Figur 5 eine schematische Darstellung eines Ressourcenoptimierers gemäß einer bevorzugten Ausführungsform der Erfindung .

Im Folgenden wird das grundlegende System zur Implementierung des erfindungsgemäßen computerimplementierten Verfahrens zur Steuerung einer SECO-Ressourcenallokationsoptimierung anhand von Figur 1 näher erläutert .

Figur 1 zeigt auf schematische Weise ein SECO-System (Software ECOsystem) , das auf das Gebiet des schienengebundenen Transportwesens angewendet werden soll. Dabei soll eine Menge von Applikationen A (AI, A2 , A3,..An) als Zielsystem deployed werden, die auf derselben Hardware HW (HW1, HW2 , HW3,...HWn) laufen und dieselben physikalischen Ressourcen nutzen. Zur Allokation der Hardware Ressourcen HW oder der weiteren phy- sikalischen Ressourcen für die Applikationen A ist ein Res- sourcenoptimierer RO vorgesehen.

Wie in Figur 2 gezeigt, kann der Ressourcenoptimierer RO auch Bestandteil eines umfassenderen Steuerungsmoduls S sein, das der SECO-Plattform zugeschaltet ist. Das Steuerungsmodul S kann in dieser Ausführungsform der Erfindung noch weitere Funktionen übernehmen, wie z.B. die Einhaltung von

konfigurierbaren Qualitätslevels . In einer Basis-Version wird nur geprüft, ob die Gesamtheit aller Applikationen bei den jeweils erfassten nicht-funktionalen Bedingungen sicher aus- führbar ist. In komplexeren Versionen der Erfindung kann das Steuerungsmodul S des Weiteren dazu ausgelegt sein, die Einhaltung von Qualitätslevels dahingehend zu prüfen, indem z.B. bestimmte Prioritäten bei der Allokation berücksichtigt werden. Die Prioritäten sind den jeweiligen Applikationen A zu- gewiesen worden und kennzeichnen, mit welcher Rangfolge eine erste Applikation Ax gegenüber einer zweiten, anderen Applikationen Ay bei einem Ressourcenkonflikt auf der SECO- Plattform bedient werden soll. Zusätzlich können in weiteren Stufen noch weitere Qualitätsanforderungen konfiguriert und überprüft werden.

Figur 3 zeigt eine Ausführungsform der Erfindung, bei der der Ressourcenoptimierer RO als separates Modul der SECO- Plattform hinzugeschaltet werden kann. Die Allokationsfunkti - on und die Konfigurationsentscheidung werden dann zwar eben- falls zentral ausgeführt und nicht lokal auf den einzelnen Clients, aber nicht unmittelbar auf der SECO-Plattform selbst, sondern in einem diesem zugeschalteten Modul. Dies kann je nach Implementierung die Auswechselbarkeit und die Flexibilität des Systems erleichtern.

Grundsätzlich benötigt der Ressourcenoptimierer RO Input- Datensätze. Die Input-Datensätze werden für jede der Applika- tionen A benötigt und umfassen ein sogenanntes Performance- Engineering-Tripel 12. Die Input-Datensätze beinhalten:

- Angaben über zumindest ein identifiziertes kritisches Applikationsszenario

- Angaben über ein Lastmodell des jeweiligen Applikations- Szenarios (diese können z.B. grafisch repräsentiert sein mit einer Funktion, die die Anzahl der Berechnungen pro Minute pro Zeiteinheit angibt. Die Grafik kann im Fall einer verkehrstechnischen Anwendung aus den erfassten Messwerten erzeugt werden und repräsentieren, dass zu diskre- ten bzw. bestimmten Ereignissen ein hoher Ressourcenverbrauch vorliegt. Dies kann z.B. beim Einfahren in einen Bahnhof der Fall sein, während zu den üblichen Fahrtzeiten nur ein geringer Ressourcenverbrauch besteht) und/oder

- Normierte Ressourcenverbräuche . Der Ressourcenoptimierer RO benötigt zur Berechnung der Allo- kationsdaten AD das Performance Verhalten jeder Applikation A aus der Menge der Applikationen unter bestimmten Ressourcenvorgaben bzw. bei den in dem SECO-System verfügbaren (beschränkten) Ressourcen. Diese Information ist einer so- genannten Ressourcen-Kosten-Funktion (resource cost function) RCF enthalten. Aus diesen RCF Daten und unter Berücksichtigung der NFR-Anforderungen berechnet der Ressourcenoptimierer RO automatisch eine optimierte Allokationsstrategie für die Gesamtheit aller Applikationen A. Des Weiteren werden die nicht-funktionalen Anforderungen

(non- functional requirements , NFR) 14 für jeweils eine Applikation A erfasst. Diese umfassen insbesondere Performance Daten .

Wie in Figur 2 angedeutet, werden für jede Applikation A zu- mindest das Performance-Engineering-Tripel 12 und die nichtfunktionalen Performance Anforderungen 14 erfasst. Darüber hinaus werden aus dem SECO-System direkt plattform- spezifische Messwerte und Parameter 16 abgelesen, wie z.B. die derzeitig eingestellten Ressourcenbegrenzungen für z.B. die Ressourcen: CPU, RAM, Disk-IO, Netzbandbreite etc. Die Ausprägung der jeweiligen Ressourcen kann ebenfalls erfasst und verrechnet werden, wie z.B. die CPU-Architektur (Einkern- , Mehrkernsysteme etc . ) .

In einer weiteren Ausführungsform der Erfindung können die Input-Datensätze noch weitere Daten umfassen, nämlich Performance-Anforderungen der jeweiligen Applikationen A, Konfigu- rations-Anforderungen und eine Konfigurationsstrategie (z.B. Hohe Performanz für ausgewählte Applikationen A oder minimale Performanz für alle Applikationen unter Einhaltung der konfigurierten NFR-Bedingungen) und/oder auf dem SECO-System verfügbare physikalische Ressourcen, insbesondere Hardware- Ressourcen HW.

Als Ergebnis bzw. Ausgabe des Ressourcenoptimierers RO wird ein Allokationsdatensatz AD bereitgestellt. Die Allokations- daten umfassen eine Angabe, wieviel Hardware Ressourcen HW mindestens vorhanden sein müssen, dass die NFR-Bedingungen für eine gegebene Anzahl von Applikationen A eingehalten werden können. Des Weiteren umfasst der Allokationsdatensatz AD eine Angabe, ob eine Menge von Applikationen A bei gegebenen Hardware Ressourcen HW gleichzeitig betrieben werden können oder, ob ausgewählten Applikationen A der Deployment verwei- gert werden sollte, um die anderen Applikationen A ausführbar zu halten. Der Allokationsdatensatz AD enthält auch Angaben, welche und wie viele Ressourcen HW den einzelnen Applikationen A zur Verfügung gestellt werden sollen. Bei dieser Angabe bzw. der zugrundeliegenden Berechnung werden immer alle Ap- plikationen A, also stets die Gesamtheit der Applikationen A, berücksichtigt. Mit dem Allokationsdatensatz AD wird somit eine Allokationsstrategie oder Zuweisungsstrategie definiert, welche Applikationen aus der Menge der Applikationen, welche Ressourcen des SECO-Systems erhalten. Dabei kann eine Neuver- teilung gemäß den Allokationsdaten AD notwendig sein, also eine Umverteilung einer bestehenden Zuweisung. Ebenso ist es möglich, dass die bestehende Zuweisung beibehalten wird

(keep) oder dass die Verteilung auf Basis der eingelesenen Prioritäten erfolgt. In Figur 4 ist ein Ablauf gemäß einer bevorzugten Ausführungsform der Erfindung dargestellt. Nach dem Start des Systems, werden in Schritt 1 die Input-Datensätze eingelesen, unter anderem um die nicht -funktionalen Anforderungen NFR zu bestimmen.

In Schritt 2 wird ein Selektionsverfahren angewendet, um die als Zielsystem zu deployenden Applikationen zu bestimmen. Dabei werden die verfügbaren Hardware Ressourcen HW und die Einhaltung der nicht -funktionalen Anforderungen NFR für jede der Applikationen A berücksichtigt.

In Schritt 3 wird ein Konfigurationsverfahren angewendet, bei dem die physikalischen Ressourcen HW so konfiguriert werden, dass die Applikationen A die erfassten, nicht-funktionalen Anforderungen NF) einhalten und/oder so wenig wie möglich der physikalischen Ressourcen HW verbrauchen.

In Schritt 4 wird ein Überschuss-Allokationsverfahrens zur Bestimmung einer Allokationssteuerungsmaßnahme ausgeführt, die definiert, wie nicht-benötigte physikalische Ressourcen HW auf die Menge der Applikationen A in ihrer Gesamtheit zu- gewiesen werden sollen.

In Schritt 5 werden die Allokationsdaten berechnet und bereitgestellt. Das Bereitstellen kann eine Ausgabe an die Client-Instanzen umfassen oder die Ausgabe auf einem Display eines Steuerungsmoduls S. Aus den Allokationsdaten können di- rekt Befehle zum Aufsetzen und Deployen der SECO-Plattform abgeleitet werden. Nach Schritt 5 kann das Verfahren ereignisbasiert (also bei Eintreten von vorkonfigurierbaren Ereignissen, wie z.B. bei Hinzukommen von weiteren, neuen Applikationen A und/oder Ressourcen HW) iterativ zum Einsatz kommen, etwa vor einer anstehenden Aktualisierung der SECO-Plattform, oder es kann beendet werden.

Figur 5 zeigt schematisch den Aufbau eines Ressourcenoptimie- rers RO gemäß einer bevorzugten Ausführungsform der Erfindung. Er umfasst die Input-Schnittstelle I zum Einlesen der Daten, einen Konfigurator K und einen Prozessor P zur Berechnung der Allokationsdaten AD. In Weiterbildungen umfasst der Ressourcenoptimierer RO zusätzlich einen Selektor SL und ei- nen Überschuß-Allokator UEA. Der Selektor SL ist zur

Auführung des Selektionsverfahrens 2 bestimmt, während der Überschuß-Allokator UEA zur Ausführung des Überschuss- Allokationsverfahrens 4 bestimmt ist. In einer vorteilhaften Ausführungsform der Erfindung kann der Ressourcenoptimierer RO noch einen Applikationskollektor AC umfassen, der alle diejenigen Applikationen A von dem Zielsystem entfernt, für die aufgrund von Berechnungen des Res- sourcenoptimierers RO festgestellt wurde, dass die Applikati- onen die für sie definierten NFR-Bedingungen nicht erfüllen können .

In einer komplexeren Weiterbildung der Erfindung können auch parallel mehrere Konfigurationen vorgehalten werden, von denen in einem Zeitintervall jeweils nur eine aktiviert ist. Damit kann z.B. abgebildet werden, dass unterschiedliche Betriebsmodi für das System vorgehalten werden können, wie z.B. einen Fahrgastbetrieb, einen Wartungsbetrieb und einen

Dienst- oder Sonderfahrtenbetrieb.

Im Folgenden wird der Allokationsalgorithmus des erfindungs- gemäßen Verfahrens anhand einer Pseudocode-Beschreibung erläutert .

Input :

A : = Menge der Anwendungskandidaten

HWR := Hardware-Ressourcen (Core 4), enthält RP (Resource Priority) , Priorität zwischen den Ressourcen (gegeben durch Reihenfolge)

NFRi ; i elementOf |A| := Non- functional Requirements der Anwendungen über Index i

RCFi ; i elementOf |A| := Resource-Cost-Functions

CFGS := Strategien für die Auswahl der Anwendungen

SelektionsStrategien :

Max-Apps = Maximiere die Anzahl der Anwendungen, die hinzugefügt werden

Priority = Füge Anwendungen in der Reihenfolge der angegebe- nen Prioritäten hinzu

Konfigurationsstrategien :

High-Performance = Füge Anwendungen nur dann hinzu, wenn Ressourcen bis zum Sättigungspunkt bereitgestellt werden können mit Sättigungspunkt = Ressourcenzuweisung für die der Grenz - nutzen < x% (z.B. 10%) des maximalen Grenznutzens.

Max-NFRs = Füge Anwendungen nur dann hinzu, wenn eine dedi- ziert angegebene HighPerf-NFR erreicht werden kann

Min-Resources = Füge Anwendungen dann hinzu, wenn wenigstens die Min-NFRs eingehalten werden können

CFGP := Verteilungs-Strategie für die Bestimmung der Konfiguration nach Auswahl der Anwendungen:

DISTRIBUTE = Verteile die Ressourcen gleichmäßig auf alle ausgewählten Anwendungen

DISTRIBUTE-PRIORITY = Verteile die Ressourcen im Verhältnis der Prioritäten auf alle ausgewählten Anwendungen

KEEP = Verteile die Ressourcen nicht

b := Pufferparameter (Zusätzliche prozentuale Ressourcenzu- Weisung als Puffer, damit Ungenauigkeiten in den RCFs ausgeglichen werden können, also eine Art Sicherheitszuschlag) Output :

AS := Menge der gewählten Anwendungskandidaten

CAS := Ressourcen-Assignments der gewählten Anwendungskandi - daten

main :

// NFR-Check: Füge Anwendungen nur dann hinzu, wenn NFRs überhaupt eingehalten werden können

AS = {}

A = A \ {Ai; für Ai werden die MIN-NFRs nicht eingehalten} stratAnw := gewählte Anwendungsstrategie

// Auswahl vornehmen

1. Fall: Prioritäten-basiert :

A = sort (A) ; sort ( ) erzeugt Reihenfolge der Anwendungen gem. Priorität

foreach (a in A) :

HWAssign_a = getBaseAssignment (a, stratAnw);

if (HWAssign_a subSetof HWRes) :

AS = AS union {a} ;

HWRes = HWRes \ HWAssign_a* (1+b) ;

eise :

siehe 2. Fall

2. Fall: Maximal -Anzahl -basiert :

SUPER_A = Menge aller Sortierungen von A

foreach(e in SUPER A) : e_tmp = list()

foreach (a in e) :

HWAssign_a = getBaseAssignment (a, stratAnw);

if (HWAssign_a* (1+b) subSetof HWRes) :

e_tm . append (a)

HWRes = HWRes \ HWAssign_a* (1+b) ;

eise :

# ResConf for maximum Performance of application does not fit on the given hardware anymore

# Next application may fit, therefore no break- Statement here ...

e = e_tmp

Select e mit |e| maximum in SUPER_A und Summe der Anwendungsprioritäten maximal

// Konfiguration festlegen

1. Fall: DISTRIBUTE

numberOfApps = | e |

dist = HWRes / (1+b)

for a in AS :

a.resConfig += (dist / numberOfApps) * (1+b);

HWRes = HWRes \ (dist / numberOfApps) * (1+b) ;

2. Fall: DISTRIBUTE-PRIORITY

sumOfPrios = AS . sumPrios ( )

dist = HWRes / (1+b)

for a in AS :

a.resConfig += (a .prio/sumOfPrios) * dist * (1+b);

HWRes = HWRes \ (a .prio/sumOfPrios) * dist * (1+b) ;

3. Fall: KEEP

echo "The following resources have been left untouched: " + HWRes

return e

def getBaseAssignment (Anwendung a, Anwendungsstrategie stratAnw) :

retVal = null;

switch (stratAnw) :

case : High-Perf-Saturation

retVal = _High-Perf-Saturation (a) ;

case: High-Perf-NFR

retVal = _High-Perf-NFR (a) ;

case: Min-Res retVal = _Min-Res(a);

return retVal ;

def _High-Perf-Saturation (Anwendung a) :

resConf = findMinResConf (a, high_perf_nfr=False) ;

maxMB = computeMBmax (a) // Compute the max. marginal benefit

(Mehrdimensionale Funktion!!)

changed = true;

while (changed)

changed = false;

for (val in adj acentValues (resConf) ) : // Annahme:

adj acentValues ordnet die Nachbarwerte (val sind Performance- Metriken) der gegebenen Ressourcenkonfiguration resConf so, dass die RP respektiert wird (> anstatt >=)

if (val > maxMB * x/100 | | val < maxMB.val) // der zweite Operand deckt den Fall ab, dass der maximale Grenznutzen noch nicht erreicht wurde

resConf = val . resConf ;

changed = true;

return resConf;

def _High-Perf-NFR (Anwendung a) :

return findMinResConf (a, high_perf_nfr=True)

def _Min-Res (Anwendung a) :

return findMinResConf (a, high_perf_nfr=False)

def findMinResConf (Anwendung a, boolean high_perf_nfr) :

retVal = null;

for nfr in a.NFRs: // Find the minimum resource requirement to fulfil _all_ NFRs

minResConf = getMinReq (nfr, high_perf_nfr) // Do this based on the resource priority RP

if minResConf > retVal:

retVal = minResConf

return retVal ;

def getMinReq (NFR nfr, boolean high_perf_nfr) :

ResConf rc = new ResConf ()

// Find lowest resource requirements to meet NFR (Matchen von nfr.value (oder nfr.value_hp wenn high_perf_nfr==True) auf nfr . rcf)

if ( ! high_perf_nfr)

rc.cpu = rcf (CPU, nfr.value);

rc.mem = rcf (MEM, nfr.value); rc.network = rcf (NETWORK, nfr.value);

rc.disklO = rcf(DiskIO, nfr.value);

eise

rc.cpu = rcf (CPU, nfr . value_hp) ;

rc.mem = rcf (MEM, nfr . value_hp) ;

rc.network = rcf (NETWORK, nfr . value_hp) ;

rc.disklO = rcf(DiskIO, nfr . value_hp) ;

return rc ;

Wichtig ist, dass für jede Applikation zumindest zwei Input- Datensätze erfasst werden: Zum Einen die nicht-funktionalen

Bedingungen NFR und zum Anderen die Ressourcen-Kosten Funktion RCF. Diese Daten werden dem Ressourcenoptimierer RO zugeführt, der auf Basis dieser und ggf. noch weitere Daten eine Allokationsstrategie zur Verteilung der verfügbare Ressourcen auf die Applikationen berechnen kann oder einliest und - auf eine Verifikationssignal eines Anwenders hin - auch unmittelbar durch entsprechende Allokationsbefehle und -maßnahmen ausführt .

Zusammenfassend kann die Erfindung wie folgt beschrieben wer- den:

Mit der Erfindung wird es möglich, in einer SECO-Plattform verfügbare physikalische Ressourcen unter Beachtung von nicht-funktionalen Bedingungen für die jeweiligen Applikationen und unter Beachtung einer Konfigurationseinstellung auf eine Menge von Applikationen zu verteilen, so dass die Performance des gesamten Systems einstellbare Performanz- Zielvorgaben erfüllt.

Die Erfindung ist grundsätzlich nicht auf eine bestimmte Klasse oder einem bestimmten Typ von physikalischen Ressour- cen beschränkt. Des Weiteren kann sie neben SECO-Systemen für den schienengebundenen Verkehr auch auf andere technischen Systeme angewendet werden. Der Ressourcenoptimierer RO kann zusätzlich noch weitere Funktionalitäten aufweisen. In diesem Zusammenhang ist darauf hinzuweisen, dass der Grundgedanke der Erfindung nicht auf die vorstehend beschriebenen Beispiele beschränkt ist und ebenso Varianten der offenbarten Bei- spiele vom Fachmann abgeleitet werden können, ohne den Schutzumfang der Erf indung zu verlassen .