DE102015207570A1

DE102015207570A1 - Ressourcen-Optimierer für Software-Ökosysteme

Info

Publication number: DE102015207570A1
Application number: DE102015207570.2A
Authority: DE
Inventors: Dimitar Dimitrov; Johannes Kupser; Maximilian Neundorfer; Michael Pönitsch; Andreas Schönberger
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2015-04-24
Filing date: 2015-04-24
Publication date: 2016-10-27
Also published as: WO2016169828A1

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren, einen Ressourcenoptimierer (RO), ein SECO-System mit einem Ressourcenoptimierer (RO) und ein Computerprogrammprodukt zur Zuweisung von in einer SECO-Plattform auf dem Gebiet des schienengebundenen Verkehrswesens verfügbaren Hardware Ressourcen (HW) auf eine Menge von Applikationen (A), wobei die Zuweisung auf Basis einer Ressourcen-Kosten-Funktion erfolgt und unter Einhaltung von nicht-funktionalen Bedingungen (NFR) für die jeweiligen Applikationen (A).

Description

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 (integrated 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 industry, MIT Press Books, 1, 2005). Diese Systeme haben den Anspruch, unterschiedlichste Applikationen von unterschiedlichen Anbietern auf einer gemeinsamen Plattform (gekennzeichnet durch gemeinsame APls, Bibliotheken und/oder gemeinsam genutzte Hardware-Ressourcen) und einer gemeinsamen technologischen 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 Steuerungsmodul 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 Merkmale 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, performance-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 erfassten, 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 implementiert 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 physikalische 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 werden. 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 Produkt und ein System zur optimierten und bedarfsgerechten Zuweisung von Hardware Ressourcen auf eine Menge von Applikationen zur Laufzeit, die in einem SECO-System bereitgestellt werden sollen.
Die Erfindung transformiert Input-Datensätze in Allokationsdaten. Die Allokationsdaten können insbesondere Angaben umfassen, 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 Performance 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 Applikationen 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-, Konfigurations- und/oder Überschuss-Allokationsverfahren automatisch 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 Betriebssystembefehls, 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 Technologie bereitgestellt werden können und damit unabhängig davon sein, ob das Betriebssystem z.B. PikeOS, ein anderes echtzeitfähiges Betriebssystem oder Linux ist. Vorzugsweise wird die Erfindung als Virtualisierungslösung mit LinuX Containers bereitgestellt, das mehrere voneinander isoliert laufende Linux-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 Bordnetzversorgung 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 Ressourcen 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 dedizierte 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 implementiert 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 Applikationen zur Auswahl von zu deployenden Applikationen, so dass sichergestellt werden kann, dass eine Ausführbarkeit für alle Applikationen unter Einhaltung der nicht-funktionalen 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 beinhaltet:

– 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 Ressourcenverbrä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 Input-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 Allokationsoptimierungsverfahren 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 erfassten 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 Einhaltung 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 Ressourcen 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 Laufzeit 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 Aufgabenlösung 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:
1 eine Übersicht über ein beispielhaftes SECO-System im Rahmen einer bevorzugten Ausführungsform der Erfindung,
2 eine schematische Darstellung eines Ressourcenoptimierers im Rahmen eines SECO-Systems,
3 eine alternative Ausführungsform der Erfindung zur Einbindung des Ressourcenoptimierers,
4 ein Ablaufdiagramm gemäß einem Verfahren nach einer bevorzugten Ausführungsform der Erfindung und
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 1 näher erläutert.
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 (A1, 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 physikalischen Ressourcen für die Applikationen A ist ein Ressourcenoptimierer RO vorgesehen.
Wie in 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 ausfü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 zugewiesen 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.
3 zeigt eine Ausführungsform der Erfindung, bei der der Ressourcenoptimierer RO als separates Modul der SECO-Plattform hinzugeschaltet werden kann. Die Allokationsfunktion und die Konfigurationsentscheidung werden dann zwar ebenfalls 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 Applikationen 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 Applikationsszenarios (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 diskreten 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 Allokationsdaten 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 sogenannten 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 2 angedeutet, werden für jede Applikation A zumindest das Performance-Engineering-Tripel 12 und die nicht-funktionalen 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, Konfigurations-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 Allokationsdaten 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 verweigert 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 Applikationen 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 Neuverteilung 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 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 zugewiesen 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 direkt 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.
5 zeigt schematisch den Aufbau eines Ressourcenoptimierers 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 einen Ü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 Ressourcenoptimierers RO festgestellt wurde, dass die Applikationen 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 erfindungsgemäßen Verfahrens anhand einer Pseudocode-Beschreibung erläutert.
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 werden:
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 Ressourcen 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 Beispiele vom Fachmann abgeleitet werden können, ohne den Schutzumfang der Erfindung zu verlassen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

D.G. Messerschmitt and C. Szyperski, Software ecosystem: understanding an indispensable technology and industry, MIT Press Books, 1, 2005 [0002]

Claims

Verfahren zur bedarfsgerechten und ganzheitlichen Allokation von einer Menge von in einem SECO-System verfügbaren physikalischen Ressourcen (HW) auf eine Menge von Applikationen (A), die in dem SECO-System für einen Parallelbetrieb zu deployen sind, umfassend folgende Verfahrensschritte: – Erfassen von Input-Datensätzen (1) zur Spezifikation von einem ersten Parametersatz, umfassend nicht-funktionale Anforderungen (NFR) für jede der Applikationen (A) – Anwenden eines Konfigurationsverfahrens (3) zur Konfiguration der physikalischen Ressourcen (HW), so dass die Applikationen (A) die erfassten, nicht-funktionalen Anforderungen (NFR) einhalten und/oder so wenig wie möglich der physikalischen Ressourcen (HW) verbrauchen – Berechnen und Bereitstellen von Allokationsdaten (5), umfassend einen Allokationsbefehl mit der die verfügbaren physikalischen Ressourcen (HW) zur Laufzeit in Abhängigkeit von den mittels des Konfigurationsverfahrens (3) konfigurierten physikalischen Ressourcen (HW) der Menge von Applikationen (A) zugewiesen werden.
Verfahren nach Anspruch 1, bei dem das SECO-System ein verkehrstechnisches SECO-System ist.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Konfigurationsverfahren (3) ein Einlesen von Konfigurationsanforderungen zur Konfiguration der physikalischen Ressourcen (HW) und/oder ein Berechnen von einer Anzahl von benötigten physikalischen Ressourcen (HW) pro Applikation (A) umfasst.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren den zusätzlichen Verfahrensschritt umfasst, der insbesondere vor der Anwendung des Konfigurationsverfahrens (3) ausgeführt wird: – Anwenden eines Selektionsverfahrens (2) auf die Menge der Applikationen (A) zur Auswahl von zu deployenden Applikationen, so dass sichergestellt werden kann, dass eine Ausführbarkeit für alle Applikationen (A) unter Einhaltung der nicht-funktionalen Anforderungen (NFR) sichergestellt werden kann.
Verfahren nach dem vorstehenden Anspruch 4, bei dem das Selektionsverfahren (2) prioritätsbasiert ist, indem den Applikationen (A) jeweils Prioritäten zugewiesen werden und/oder anzahlbasiert ist, so dass eine maximale Anzahl von Applikationen (A) deployed wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren den zusätzlichen Verfahrensschritt umfasst, der insbesondere nach der Anwendung des Konfigurationsverfahrens (3) ausgeführt wird: – Anwenden eines Überschuss-Allokationsverfahrens (4) zur Bestimmung einer Allokationssteuerungsmaßnahme, die definiert, wie nicht benötigte physikalische Ressourcen (HW) auf die Menge der Applikationen (A) zugewiesen werden sollen.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der erste Parametersatz umfasst: – Angaben über zumindest ein Applikationsszenario – Angaben über ein Lastmodell des Applikationsszenarios und/oder – Normierte Ressourcenverbräuche.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Erfassen der Input-Datensätze zur Spezifikation eines zweiten Parametersatzes bestimmt ist, der zumindest einen der folgenden Datensätze umfasst: – Performance-Anforderungen – Konfigurations-Anforderungen und/oder – Verfügbare physikalische Ressourcen (HW), insbesondere Hardware-Ressourcen.
Verfahren nach dem vorstehenden Anspruch 8, bei dem die Allokationsdaten (AD) derart berechnet werden, dass die Konfigurations-Anforderungen und/oder die Performance-Anforderungen bei den erfassten verfügbaren physikalischen Ressourcen (HW) für alle Applikationen (A) gleichzeitig eingehalten werden.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren zur Installation eines SECO-Systems verwendet wird und bei dem die berechneten Allokationsdaten (AD) zumindest den folgenden Datensatz umfassen: – Eine Mindestanzahl von benötigten physikalischen Ressourcen (HW).
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren zur Steuerung eines bereits installierten SECO-Systems mit gegebenen physikalischen Ressourcen (HW) verwendet wird und bei dem die berechneten Allokationsdaten (AD) zumindest den folgenden Datensatz umfassen: – Einen Betriebsdatensatz, der angibt, ob die Menge der Applikationen (A) bei den verfügbaren physikalischen Ressourcen (HW) unter Einhaltung der nicht-funktionalen Anforderungen (NFR) parallel betrieben werden kann und/oder – Einen Allokationsbefehl, der angibt, welche und wie viele physikalische Ressourcen (HW) der jeweiligen Applikation (A) aus der Menge der Applikationen zur Verfügung gestellt werden müssen.
Verfahren nach einem der vorstehenden Ansprüche, bei dem vor einer Installation des SECO-Systems oder vor einer Konfiguration eines bestehenden SECO-Systems automatisch eine Warnmeldung ausgegeben wird, falls die berechneten Allokationsdaten (AD) kennzeichnen, dass die verfügbaren physikalischen Ressourcen (HW) zum parallelen Betrieb der Applikationen (A) nicht ausreichen.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren zusätzlich folgenden Verfahrensschritte umfasst: – Allokation der physikalischen Ressourcen auf die Menge der Applikationen (A) anhand der berechneten Allokationsdaten (AD) zum Betrieb des SECO-Systems.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Verfahren für alle Applikationen (A) zentral auf dem SECO-System ausgeführt wird.
Ressourcenoptimierer (RO) zur bedarfsgerechten und ganzheitlichen Allokation von einer Menge von in einem SECO-System verfügbaren physikalischen Ressourcen (HW) auf eine Menge von Applikationen (A), die in dem SECO-System für einen Parallelbetrieb zu deployen sind, umfassend: – Eine Input-Schnittstelle (I) zum Erfassen von Input-Datensätzen zur Spezifikation von zumindest einem ersten Parametersatz, umfassend nicht-funktionale Anforderungen für jede der Applikationen – Einen Konfigurator (K), der zur Anwendung eines Konfigurationsverfahrens (3) zur Konfiguration der physikalischen Ressourcen (HW) bestimmt ist, so dass die Applikationen (A) die erfassten, nicht-funktionalen Anforderungen (NFR) einhalten und/oder so wenig wie möglich der physikalischen Ressourcen (HW) verbrauchen – Einem Prozessor (P), der zum Berechnen und Bereitstellen (5) von Allokationsdaten (AD) bestimmt ist, wobei die Allokationsdaten (AD) einen Allokationsbefehl umfassend, mit dem die verfügbaren physikalischen Ressourcen (HW) zur Laufzeit in Abhängigkeit von den mittels des Konfigurators (K) konfigurierten physikalischen Ressourcen (HW) der Menge von Applikationen (A) zugewiesen werden.
Ressourcenoptimierer (RO) gemäß vorstehendem Anspruch, der zusätzlich einen Selektor (SL) und/oder einen Überschuß-Allokator (UEA) umfasst.
SECO-System mit einem Steuerungsmodul (S) zur bedarfsgerechten und ganzheitlichen Allokation von einer Menge von in dem SECO-System verfügbaren physikalischen Ressourcen (HW) auf eine Menge von Applikationen (A), die in dem SECO-System für einen Parallelbetrieb zu deployen sind, wobei das Steuerungsmodul (S) einen Ressourcenoptimierer (RO) gemäß Anspruch 15 oder 16 umfasst.
Computerprogrammprodukt, das in einen internen Speicher eines digitalen Computers eines SECO-Systems 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.