EP3799633A1 - Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen - Google Patents

Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen

Info

Publication number
EP3799633A1
EP3799633A1 EP19739893.6A EP19739893A EP3799633A1 EP 3799633 A1 EP3799633 A1 EP 3799633A1 EP 19739893 A EP19739893 A EP 19739893A EP 3799633 A1 EP3799633 A1 EP 3799633A1
Authority
EP
European Patent Office
Prior art keywords
sub
applications
platform
platforms
level
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19739893.6A
Other languages
English (en)
French (fr)
Inventor
Sebastian Meixner
Fei Li
Daniel SCHALL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP3799633A1 publication Critical patent/EP3799633A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/506—Constraint

Definitions

  • the present invention relates to a method under
  • Sub-applications of a specific application on computers of at least two different levels a first level having more computing power than a second level.
  • the method can generally be used where a certain software application can be divided into several sub-applications and these sub-applications by
  • a level is one
  • So-called cloud in German computer cloud or data cloud.
  • the cloud level can consist of several different cloud platforms which are usually offered by different providers.
  • a cloud platform provides IT infrastructure, such as storage space,
  • Cloud platforms have virtually unlimited resources at their disposal, making one Services that are running on a cloud platform can be scaled as desired, in particular expanded.
  • Disadvantages of the cloud level are the lack of confidentiality and the lack of real-time services.
  • the lack of confidentiality is due to the fact that the user is usually not the owner of the cloud platform and therefore has no control over the data in the cloud.
  • Real-time services are hardly possible because data has to be sent from the user to the cloud level and back from the Internet several times, which leads to delays due to the transmission time.
  • edge computing refers to decentralized data processing, especially at the edge of a computer network.
  • Computer applications, data and services are moved from central nodes (data centers) to the outer edges of a network.
  • central nodes data centers
  • the edge level consists of multiple platforms
  • the Edge network is usually - legally and spatially - owned by the user. This ensures confidentiality and the possibility of real-time services, the latter especially when the individual units of the edge are spatially close to one another and are connected to one another by fast network connections.
  • the disadvantage is that the resources of the edge are limited and cannot be expanded at will.
  • Each level can have one or more platforms
  • Microservices are one
  • Amazon Greengrass enables developers to run applications transparently either in the cloud or on Greengrass IoT devices that form an edge platform let what can happen depending on the occasion.
  • the Google Cloud IoT Core and Microsoft Azure IoT Suite also allow Edge and Cloud to be linked.
  • Computers relates to distributing sub-applications of a specific application to computers of at least two
  • each comprising at least one specific platform with a first level (corresponding to the platform (s) of the first level) having more computing power available than a second level (corresponding to the
  • Second level platform (s) It is provided
  • Sub-applications are selected
  • a platform of the first level can in particular be a so-called cloud platform (computer cloud), which is connected to the computer that carries out the method according to the invention via the Internet.
  • a platform of the second level can be a local computer network that is spatially closer to
  • a platform of the second level can therefore be a computer network which is spatially close to the user of the method and which has a shorter data transport from and to
  • the user's computer is allowed as one, especially all, first level platforms.
  • the method according to the invention enables software developers, non-functional requirements and others
  • the software developer can define the non-functional requirements and other boundary conditions for certain individual sub-applications and also see which level and, if applicable, which unit (which computer) of this level
  • a graph database (or graph-oriented database) is a database that uses graphs to be highly networked
  • Such a graph consists of nodes and edges, the connections
  • Both nodes and edges can have properties, so-called properties (e.g. name,
  • the users can then provide a list of sub-applications to be executed and for which an optimized distribution plan should be created.
  • the optimization relates to targets or target functions specified by the user or by the system itself.
  • Dynamic boundary conditions can also be taken into account which are derived from the current state of the system (e.g. availability of memory or computing power).
  • the corresponding process step then consists of the conditions for the application and also for the
  • a condition fulfillment problem is automatically created and solved.
  • the optimized distribution plan is determined using a so-called CSP method.
  • CSP constraint satisfaction problem
  • Condition fulfillment problem is a task where a condition (ie an assignment of variables) is to be found that fulfills all of the conditions (constraints).
  • a constraint satisfaction problem consists of a set of variables, their range of values, and the conditions that create links between the variables, thereby determining which combinations of values of the variables are allowed.
  • a CSP is solved by finding an assignment of the variables that meets all conditions.
  • constraint satisfaction problems require the complete fulfillment of each individual condition. There can be several solutions.
  • the solution of the CSP procedure i.e. the found plan for the distribution of the software (deployment plan) can be released for execution either automatically or manually by the user. The user can see the plan, what this plan
  • a plan once determined, is based on measured values, states and / or
  • Feedback from executing units and / or an alarm is triggered or changed, in particular recalculated and executed, based on the specifications of the user (e.g. events defined by the user).
  • One embodiment of the invention is that the conditions for executing the sub-applications and / or the requirements of the different levels and / or the specific platforms are at least one of the following
  • Sub-applications and / or platforms Regarding the Communication with other sub-applications and / or
  • Scalability means that the application is provided with more resources, i.e. more computing power, more memory or even more computers at all.
  • One embodiment of the invention is that the conditions for executing the sub-applications and / or the requirements of the different levels and / or the
  • Computer units include at least one of the following properties: presence of at least one specific additional hardware and / or software required, in particular in the correct version.
  • the requirements of the different levels can include requirements of the individual computers of the respective level.
  • At least one sub-application is distributed to a specific computer of a specific platform at one level, that is to say assigned to it for execution.
  • the conditions for executing the sub-applications include that certain boundary conditions are determined automatically, based on available information become. For example, it can be provided that two
  • Sub-applications may not be distributed to the same platform or the same computer on a platform.
  • the conditions for executing the sub-applications can generally include that certain sub-applications may not be distributed to the same level, the same platform of a level or the same computer of a platform. This can e.g. Have security reasons.
  • Changing a requirement of the different levels or platforms can change a state (e.g.
  • the change in state or rule can change the price of one or more
  • a rule might be that if the usage of all instances of a sub-application is below or above a certain threshold for a certain time, then the number of instances used should be reduced or increased accordingly. Or a rule can be that high utilization of units in the edge is acceptable as long as the price of computing power in the cloud is above you
  • Another rule can be that the number of instances of a particular one
  • the change in a requirement of the various platforms can be a change in the utilization of a platform or a computer on a platform.
  • At least one condition for executing the sub-applications can be specified by a responsible person, for example the developer.
  • the invention also includes a
  • Corresponding computer program product which in turn comprises commands that cause the computer to execute the program, all the steps of the Execute method according to the invention.
  • Computer program product can be, for example, a data carrier on which a corresponding computer program
  • the computer program can therefore initiate or carry out the following steps:
  • Requirements of the at least one platform of a level are recorded in a database, in particular a graph database (e.g. by input by a user or by reading in data),
  • Sub-applications are selected (e.g. by input by a user or by reading data),
  • Fig. 2 shows a basic architecture for a computer system for
  • Fig. 4 is a graphical representation of the application and its
  • Sub-applications along with a possible level for executing the sub-applications,
  • Fig. 5 is a graphical representation of the edge with the
  • FIG. 1 shows the information flow in a system according to the invention.
  • the sub-applications can be redistributed: by manual intervention by the user, automatically as part of a continuous
  • CI continuous integration
  • CEP complex event processing
  • Fig. 1 shows a MAPE cycle
  • MAPE stands for Monitor-Analyze-Plan-Execute.
  • the monitoring (monitor), letter M in Fig. 1, is in the monitoring phase by means of
  • the callback can be forwarded to the deployment service, for example, which triggers a new distribution.
  • the distribution service calls the distribution planner (Deployment Planner) to collect all the necessary information for calculating an optimized distribution plan, see arrow 2 "Plan Deployment” , This includes the levels or units (allowed platforms) permitted for the sub-applications to be distributed, see arrow 2.1 "Get Allowed Platforms", and the applications currently running, see arrow 2.2 “Get Running Services”.
  • the sub-applications to be distributed are provided by the deployment service or by the developer. Basically, for an application that consists of several sub-applications, all sub-applications should be planned and then only those sub-applications should be redistributed or migrated for which a better unit for execution is found.
  • the app model and the service registry can provide the necessary information.
  • the app model defines how an application can be executed, which one
  • the service registry contains further information on the individual sub-applications, typically their location, their runtime and conditions for their termination.
  • the information is needed to make an optimal one
  • Distribution plan for the given sub-applications create. This distribution plan will be sent to the
  • Distribution Service (Deployment Service) returned, which then takes over the deployment and the
  • a sub-application After a sub-application has been started, it registers with the manager of the units (device manager), who begins to collect measurement values, so-called metrics, of the executing unit, such as CPU utilization and available storage space. These measurements are sent to the manager of the units (device manager), who begins to collect measurement values, so-called metrics, of the executing unit, such as CPU utilization and available storage space. These measurements are sent to the manager of the units (device manager), who begins to collect measurement values, so-called metrics, of the executing unit, such as CPU utilization and available storage space. These measurements are sent to the manager of the units (device manager), who begins to collect measurement values, so-called metrics, of the executing unit, such as CPU utilization and available storage space.
  • Device Manager can preprocess the measurement data and send them to the monitoring unit in a transformed form
  • the monitoring component forwards the data to the complex event processing unit CEP, see arrow 5.1 “Push Events”.
  • the complex event processing unit CEP analyzes the data based on the rules specified by the user and triggers a new distribution the
  • This distribution can, for example, cause the sub-application to be scaled, depending on whether and which rules have been defined.
  • a user could, for example, specify if the use of all instances of a sub-application is below or above a specific time Threshold, then the number of instances used should be reduced or increased accordingly, or a user could determine that high utilization of units in the edge is acceptable as long as the price of computing power in the cloud is above one
  • Sub-applications can also be triggered by the developer if the developer has appropriate instructions in the control unit for the source code version, which in turn the
  • CI pipeline triggers The distribution of the sub-applications can also be started manually by the user if he deems it necessary. This
  • Fig. 2 shows a possible basic architecture of the
  • the architecture includes a cloud-based, open IoT operating system, here called “MindSphere Platform” from Siemens. This is connected to the level of Edge in order to
  • Double arrow “Push Metrics / Receive Events” is shown.
  • FIG. 2 For the sake of clarity, the representation of the basic architecture in FIG. 2 only shows one specific cloud and edge platform. However, the method according to the invention is not restricted to a single platform per level.
  • the cloud-based, open IoT operating system “MindSphere Platform is connected to a further level," MindSphere Apps ", on which other applications of the IoT operating system run, such as root cause analysis (CART)", identification of deviations, e.g. using the isolation forest method (“Outlier Detection (Isolation Forest)”) and an optimization, e.g. using a simplex method or using genetic algorithms
  • the cloud-based, open IoT operating system "MindSphere Platform” comprises general services shown on the left
  • platform services include e.g.
  • Sub-applications have three levels and implement a MAPE cycle.
  • the Deployment Planner level is responsible for calculating an optimal one
  • Program part that serves other programs for the connection to the individual sub-application In this way, a new distribution plan can be created.
  • the user has several options here:
  • the user can only name the sub-applications that he wants to distribute, and otherwise use the predefined models with the predefined target functions.
  • the Users specify their own target function, which is used for
  • Distribution optimization is used. Thirdly, the user can specify his own model for the distribution of the sub-applications.
  • the second level is called "Analysis & Plan Execution” and includes planning and execution. It contains the complex event processing unit CEP and that
  • the second level prepares the data for planning and carries it out
  • Deployment service serves as the entrance to the system.
  • a developer can create a new distribution here
  • the Deployment Service then receives the optimized distribution plan from the Deployment Planner and takes over the actual one
  • Units run by the manager of the
  • the manager of the units also receives (Device Manager) Commands from the Deployment Planner to start or stop certain sub-applications.
  • the sub-applications "Services @ Edge", S2, S4 can be executed in the edge.
  • FIG. 2 On the right in FIG. 2, other cloud applications (Other Cloud Platform) are shown, here on IaaS (Infrastructure as a Service) basis. They include applications for distributed version control of files (Source Code Version Control System), such as Git. When developers make their changes
  • a CI server e.g. from Jenkins
  • a CI server is triggered for continuous integration in order to find out the latest change and then build the application accordingly from the possibly changed sub-applications. If the setup is successful, the resulting software artifacts are combined in one
  • Sub-applications the learner ("Learner") and the evaluator (“Scorer”).
  • the aim is to detect outliers in sensor measured values, such as the engine temperature.
  • Both sub-applications are implemented in the example using the Python programming language. Skicit-learn was used as the library for machine learning, and one for learning the model
  • the learner collects data, stores it locally and trains a machine learning model to detect outliers.
  • the learner regularly re-trains the model to take changing conditions into account.
  • Training intervals when training may have to process quite a bit of data, he becomes a lot for it
  • the evaluator loads available models from the
  • time series disturb see application "Time Series” in FIG. 2
  • time series disturb see application "Time Series” in FIG. 2
  • the evaluation does not need a lot of resources and the models are usually much smaller than the files with the data records. In this respect, the evaluator can be run on units that only have limited resources
  • HAS various usage parameters
  • corer various usage parameters
  • Outlier Detector comprises two sub-applications “Learner” and “Scorer” (HAS "), each of which has usage parameters (" Usage Param. ").
  • These usage parameters in this case” NearRealtime “(" NearRea ... “), ie” almost real time ", can be made available by platforms, here by the edge.
  • the private cloud platform (“Edge Host 1”) provides (“PROVIDES”) variable scaling and confidentiality, as well as RAM, CPU, bandwidth "BANDW ".
  • the deployment planner gathers all the necessary information
  • Platinum or levels, i.e. the private cloud
  • MindSphere MindSphere
  • ElasticScalability scalability
  • the result is transformed, for example in JSON, and sent back to the deployment planner.
  • the result can be a simple assignment that everyone
  • the deployment planner then gets the list of currently running applications, see arrow 2.2 "Get Running Services", creates a file from the data and the dynamic part of a CSP procedure, which is defined here using a corresponding programming language and a corresponding procedure
  • Boundary conditions are defined in a file for the static model.
  • the basic constraints are:
  • the host must provide the required software in the correct version.
  • the dynamic model contains boundary conditions that of
  • Planning can vary from planning to planning, e.g. that certain sub-applications may not be distributed together, i.e. they may not run on the same host.
  • the deployment planner creates a file from its input. If the programming language can only work with integers and matrices, the data from the input must be adapted to the structure of this programming language.
  • the representation of which resources are available on which host / which platform is represented for example, as a matrix (hxr), where h den Represents host / platform and r the resource, and where the number n in position (h, r) indicates how many resources r the host / platform h has.
  • the result of the solution process is one
  • Assignment matrix or data series where the number i at position j indicates that the sub-application j is assigned to the host / platform i, that is to say distributed over it.
  • Allocation matrix or data series is defined by the
  • the deployment planner takes care of the actual distribution of the sub-applications. If the target platform is a cloud platform, one will
  • the deployment planner sends a command to the appropriate manager of the units (device manager), which then loads the software artifact and starts the sub-application.
  • the device manager monitors the sub-application and sends measured values to the quality unit (QoS Watcher, see FIG. 2), which shows the quality of the execution of the
  • the sub-application is monitored and the measured values are forwarded to the complex event processing unit CEP. This concludes the MAPE cycle. Only if the developer himself
  • FIG. 7 shows the integration of the outlier application in the “Fleet Manager” application, which is based on the “MindSphere Platform”. runs, see Fig. 2, and which monitors and controls several motors here.
  • the available views in the "Fleet Manager” are shown on the left in FIG. 7, and the selected view which is created with the aid of the outlier application is shown on the right.
  • the upper curve on the right shows the temporal course (stored in "Time Series") of the Measured values of the temperature of an engine.
  • the lower curve indicates with "1" that there is an outlier, with "0” that there is no outlier.
  • the "Fleet Manager” application can now be used

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)

Abstract

Verteilen von Unteranwendungen einer bestimmten Anwendung auf Rechner von Plattformen zumindest zweier verschiedener Ebenen Die Erfindung betrifft ein Verfahren, unter Verwendung eines Computers, zum Verteilen von Unteranwendungen einer bestimmten Anwendung auf Rechner zumindest zweier verschiedener Ebenen, wobei eine erste Ebene mehr Rechenleistung zur Verfügung hat als eine zweite Ebene. Damit dies automatisiert und nachvollziehbar geplant werden kann, ist vorgesehen, - dass Bedingungen zur Ausführung der Anwendung sowie auch der einzelnen Unteranwendungen in einer Datenbank erfasst werden, - dass den Bedingungen zur Ausführung entsprechende Voraussetzungen der verschiedenen Ebenen, nämlich Voraussetzungen der mindestens einen Plattform einer Ebene, in einer Datenbank erfasst werden, - dass die für die bestimmte Anwendung notwendigen Unteranwendungen ausgewählt werden, - dass aus den Bedingungen für die Anwendung sowie auch für die einzelnen Unteranwendungen und aus den diesbezüglichen Voraussetzungen der verschiedenen Ebenen, nämlich der jeweils mindestens einen Plattform der Ebenen, automatisch ein Bedingungserfüllungsproblem erstellt und gelöst wird, und - dass entsprechend der Lösung des Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen verteilt werden.

Description

Beschreibung
Verteilen von Unteranwendungen einer bestimmten Anwendung auf Rechner von Plattformen zumindest zweier verschiedener Ebenen
GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Verfahren, unter
Verwendung eines Computers, zum Verteilen von
Unteranwendungen einer bestimmten Anwendung auf Rechner zumindest zweier verschiedener Ebenen, wobei eine erste Ebene mehr Rechenleistung zur Verfügung hat als eine zweite Ebene.
Das Verfahren kann generell dort angewendet werden, wo eine bestimmte Software-Anwendung in mehrere Unteranwendungen aufgeteilt werden kann und diese Unteranwendungen von
verschiedenen Rechnern ausgeführt werden, etwa im Bereich der Industrieautomation oder bei Anwendungen für das sogenannte Internet of Things.
STAND DER TECHNIK
Grundsätzlich gibt es zwei verschiedene Ebenen, auf denen Software ausgeführt werden kann. Eine Ebene ist eine
sogenannte Cloud, zu deutsch Rechnerwolke oder Datenwolke. Die Cloud Ebene kann aus mehreren unterschiedlichen Cloud Plattformen bestehen welche üblicherweise von verschiedenen Anbietern angeboten werden. Eine Cloud Plattform stellt IT- Infrastruktur, wie beispielsweise Speicherplatz,
Rechenleistung oder Anwendungssoftware, als Dienstleistung über das Internet zur Verfügung. Cloud Plattformen haben praktisch unbegrenzte Ressourcen zur Verfügung, wodurch man Dienste, die auf einer Cloud Plattform ausgeführt werden, beliebig skalieren, insbesondere erweitern, kann. Nachteile der Cloud Ebene sind fehlende Vertraulichkeit und fehlende Echtzeit-Dienste . Die fehlende Vertraulichkeit ist darin begründet, dass der Anwender meist nicht Besitzer der Cloud Plattform ist und somit keine Kontrolle über seine in der Cloud befindlichen Daten hat. Echtzeit-Dienste sind kaum möglich, da mehrfach Daten vom Anwender über das Internet in die Cloud Ebene und von dort zurück gesendet werden müssen, was jeweils durch die Übertragungszeit zu Verzögerungen führt .
Die zweite Ebene, auf der Software ausgeführt werden kann, wird als Edge bezeichnet, zu deutsch Kante oder Rand. Edge Computing bezeichnet im Gegensatz zum Cloud Computing die dezentrale Datenverarbeitung, insbesondere am Rand eines Rechner-Netzwerks. Computer-Anwendungen, Daten und Dienste werden von zentralen Knoten (Rechenzentren) weg zu den äußeren Rändern eines Netzwerks verlagert. Auch hier ist es möglich, dass die Edge Ebene aus mehreren Plattformen
besteht. Das Netzwerk der Edge befindet sich meist - rechtlich und räumlich - im Besitz des Anwenders. Dadurch ist Vertraulichkeit und die Möglichkeit von Echtzeit-Diensten gegeben, Letzteres insbesondere dann, wenn die einzelnen Einheiten der Edge räumlich nahe zueinander liegen und durch schnelle Netzwerkverbindungen miteinander verbunden sind. Nachteilig ist, dass die Ressourcen der Edge begrenzt sind und nicht beliebig erweiterbar sind.
Jede Ebene kann von einer oder mehreren Plattformen
realisiert werden. Jede dieser Plattformen kann wiederum unterschiedliche funktionale und nichtfunktionale
Anforderungen erfüllen. Will man die Vorteile beider Ebenen kombinieren, müssen
Anwendungen entsprechend in Unteranwendungen, sogenannte Microservices , aufgeteilt werden, welche dann auf einer der beiden Ebenen laufen. Microservices sind ein
Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Unteranwendungen
zusammengesetzt wird, die untereinander mit
sprachunabhängigen Programmierschnittstellen kommunizieren. Die Unteranwendungen sind weitgehend entkoppelt und erledigen jeweils eine kleine Aufgabe. Die Entscheidung, welche
Unteranwendung auf welcher Ebene und weiters auf welcher konkreten Plattform ausgeführt werden soll, ist aufwändig, fehleranfällig und sollte am besten automatisiert erfolgen. Entscheidungskriterien liefern die nichtfunktionalen
Anforderungen (englisch non-functional requirement, NFR) der jeweiligen Unteranwendung, die beispielsweise die
Skalierbarkeit der Anwendung und deren benötigte
Vertraulichkeit enthalten.
Nachdem entschieden worden ist, ob die Unteranwendung in der Cloud oder in der Edge ausgeführt werden soll, kann
entschieden werden, auf welcher konkreten Cloud- oder Edge- Plattform die Unteranwendung ausgeführt werden soll,
basierend auf den Anforderungen der Unteranwendung an deren Zielplattform. Anschließend kann entschieden werden auf welcher Einheit (welchem Host) genau auf dieser Plattform dies geschehen soll, etwa, auf welcher physikalischen Einheit einer Edge Plattform. Der Host muss entsprechende Ressourcen (Software, Werkzeuge, Bibliotheken) in der benötigten Version aufweisen, damit die Unteranwendung richtig ausgeführt werden kann. Weiters muss die Kommunikation zwischen zwei
verschiedenen Plattformen möglich sein, wenn verschiedene, voneinander abhängige Unteranwendungen auf jeweils eine der Plattformen verteilt werden. Die Entscheidung, welche Unteranwendung auf welcher Ebene ausgeführt werden soll, wurde bisher entweder mit
Unterstützung des Anwenders durchgeführt, wie dies beim sogenannten Disnix-System der Fall ist.
Mohamed El Amine Matogui und Sebastien Leriche schlagen in der Veröffentlichung „A middleware architecture for autonomic Software deployment" vor, dass der Anwender Randbedingungen für die Unteranwendungen setzt, die dann in ein sogenanntes Constraint Satisfaction Problem (CCSP) ungeformt werden, ohne dass jedoch bestimmte Abhängigkeiten zwischen benötigter Software berücksichtigt werden. In der Folge wird dann etwaige benötigte Software auf eine Einheit heruntergeladen, was oft nicht wünschenswert ist, wenn nicht genug
Speicherplatz vorhanden ist.
Viele Ansätze, um Cloud und Edge miteinander zu verbinden, finden sich unter dem Schlagwort Fog Computing, siehe etwa „A Survey of Fog Computing: Concepts, Applications and Issues" von Shanhe Yi, Cheng Li und Qun Li, oder "Fog Computing: A Platform for Internet of Things and Analytics" von Flavio Bonomi, Rodolfo Milito, Preethi Natarajan and Jiang Zhu, N. Bessis and C. Dobre . Darunter finden sich Ansätze, wo
Entwickler festlegen, welche Teile der Funktionalität einer Unteranwendung in die Cloud ausgelagert werden können, wenn eine Einheit der Edge überlastet ist. Oder es gibt Ansätze, wo die Prozesse anhand von nichtfunktionalen Anforderungen, wie Vertraulichkeit, immer einer bestimmten Ebene zugeordnet werden müssen.
Amazon Greengrass ermöglicht es Entwicklern, Anwendungen transparent entweder in der Cloud oder auf Greengrass IoT Einheiten, welche eine Edge Plattform bilden, ausführen zu lassen, was anlassbezogen geschehen kann. Auch unter Google Cloud IoT Core und Microsoft Azure IoT Suite erlauben die Verknüpfung von Edge und Cloud.
Keines dieser bisher bekannten Systeme erlaubt es jedoch, die Entscheidungen, welche Unteranwendung auf welcher Ebene und auf welcher konkreten Plattform laufen soll, automatisiert und nachvollziehbar zu planen.
DARSTELLUNG DER ERFINDUNG
Es ist somit eine Aufgabe der Erfindung, ein Verfahren anzugeben, mit welchem die Entscheidungen, welche
Unteranwendung auf welcher Ebene laufen soll, automatisiert und nachvollziehbar geplant werden und dieser Plan
insbesondere auch geändert werden kann.
Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst, welches ein Verfahren unter Verwendung eines
Computers betrifft, zum Verteilen von Unteranwendungen einer bestimmten Anwendung auf Rechner zumindest zweier
verschiedener Ebenen, umfassend jeweils mindestens eine konkrete Plattform, wobei eine erste Ebene (entsprechend die Plattform (en) der ersten Ebene) mehr Rechenleistung zur Verfügung hat als eine zweite Ebene (entsprechend die
Plattform (en) der zweiten Ebene). Dabei ist vorgesehen,
- dass Bedingungen zur Ausführung der Anwendung sowie der einzelnen Unteranwendungen in einer Datenbank, insbesondere einer Graphdatenbank, erfasst werden,
- dass den Bedingungen zur Ausführung entsprechende
Voraussetzungen der verschiedenen Ebenen, nämlich
Voraussetzungen der mindestens einen Plattform einer Ebene, in einer Datenbank, insbesondere einer Graphdatenbank, erfasst werden,
- dass die für die bestimmte Anwendung notwendigen
Unteranwendungen ausgewählt werden,
- dass aus den Bedingungen für die Anwendung sowie auch für die einzelnen Unteranwendungen und aus den diesbezüglichen Voraussetzungen der verschiedenen Ebenen, nämlich der jeweils mindestens einen Plattform der Ebenen, automatisch ein
Bedingungserfüllungsproblem erstellt und gelöst wird, und
- dass entsprechend der Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen verteilt werden.
Eine Plattform der ersten Ebene kann insbesondere eine sogenannte Cloud Plattform (Rechnerwolke) sein, die mit dem Computer, der das erfindungsgemäße Verfahren ausführt, über Internet verbunden ist. Eine Plattform der zweiten Ebene kann ein lokales Rechnernetzwerk sein, das räumlich näher am
Computer liegt, der das erfindungsgemäße Verfahren ausführt. Eine Plattform der zweiten Ebene kann also ein dem Anwender des Verfahrens räumlich nahe liegendes Rechner-Netzwerk sein, das einen zeitlich kürzeren Datentransport vom und zum
Computer des Anwenders erlaubt als eine, insbesondere alle, Plattformen der ersten Ebene.
Beim erfindungsgemäßen Verfahren wird es Software-Entwicklern ermöglicht, nichtfunktionale Anforderungen und andere
Randbedingungen für deren Unteranwendungen vorzugeben, wobei das erfindungsgemäße System einen optimierten Plan zur
Verteilung der Software (deployment plan) bestimmt, nämlich zur Verteilung der Unteranwendungen auf eine von
möglicherweise mehreren Cloud Plattformen oder eine von möglicherweise mehreren Edge Plattformen. Mit einem Werkzeug in Form einer Software kann der Software- Entwickler die nichtfunktionale Anforderungen und anderen Randbedingungen für bestimmte einzelne Unteranwendungen festlegen und auch sehen, welche Ebene und gegebenenfalls welche Einheit (welcher Rechner) dieser Ebene diese
Anforderungen und Randbedingungen unterstützt. Diese Daten werden vorzugsweise in einer graphenorientierten Datenbank (auch als Graphdatenbank genannt) modelliert, wobei für eine bestimmte Unteranwendung geeignete Einheiten (Rechner) durch Traversieren des Graphen rasch und einfach ermittelt werden können .
Eine Graphdatenbank (oder graphenorientierte Datenbank) ist eine Datenbank, die Graphen benutzt, um stark vernetzte
Informationen darzustellen und abzuspeichern. Ein solcher Graph besteht aus Knoten und Kanten, den Verbindungen
zwischen den Knoten. Sowohl Knoten als auch Kanten können Eigenschaften, sogenannte Properties (bspw. Name,
Identifikationsnummer, ...) , besitzen. Graphdatenbanken bieten spezialisierte Graphalgorithmen, um komplizierte
Datenbankabfragen zu vereinfachen. So bieten sie
beispielsweise Algorithmen, um Graphen zu traversieren, d. h. alle direkten und indirekten Nachbarn eines Knotens zu finden, kürzeste Pfade zwischen zwei Knoten zu berechnen, bekannte Graphstrukturen wie beispielsweise Cliquen zu finden oder Hotspots besonders stark vernetzter Regionen im Graph zu identifizieren.
Die Anwender können dann eine Liste von Unteranwendungen liefern, die ausgeführt werden sollen und für welche ein optimierter Plan zur Verteilung erstellt werden soll. Die Optimierung bezieht sich dabei auf vom Anwender oder vom System selbst vorgegebene Ziele bzw. Zielfunktionen. Es können auch dynamische Randbedingungen berücksichtigt werden, die vom momentanen Zustand des Systems abgeleitet werden (z.B. Verfügbarkeit von Speicher oder Rechenleistung).
Weiters kann ein Kompromiss zwischen dem Erfüllungsgrad der nichtfunktionalen Anforderungen und den Kosten für die resultierende Verteilung von Unteranwendungen erreicht werden, wenn die Kosten für Ressourcen in den verschiedenen Cloud Plattformen in die Zielfunktion miteinbezogen werden.
So kann beispielsweise die Ausfallsicherheit einer
Unteranwendung erhöht werden indem mehrere Instanzen verteilt werden, aber nur dann wenn die akkumulierten Kosten für die benötigten Ressourcen in der Cloud unter einem bestimmten Schwellwert bleiben.
Entsprechend kann in einer Ausführungsform der Erfindung vorgesehen sein, dass bei der Erstellung des
Bedingungserfüllungsproblems die Kosten für Ressourcen auf den einzelnen Plattformen berücksichtigt werden. Der
entsprechende Verfahrensschritt besteht dann darin, dass aus den Bedingungen für die Anwendung sowie auch für die
einzelnen Unteranwendungen und aus den diesbezüglichen
Voraussetzungen der verschiedenen Ebenen, nämlich der jeweils mindestens einen Plattform der Ebenen, sowie den Kosten für Ressourcen auf den einzelnen Plattformen automatisch ein Bedingungserfüllungsproblem erstellt und gelöst wird.
Der optimierte Plan zur Verteilung wird erfindungsgemäß mit einem sogenannten CSP Verfahren bestimmt. Ein Constraint- Satisfaction-Problem (CSP; deutsch:
Bedingungserfüllungsproblem) ist eine Aufgabenstellung, wo ein Zustand (d.h. eine Belegungen von Variablen) gefunden werden soll, der alle aufgestellten Bedingungen (Constraints ) erfüllt . Ein Constraint-Satisfaction-Problem besteht aus einer Menge von Variablen, ihren Wertebereichen und den Bedingungen, die Verknüpfungen zwischen den Variablen hersteilen und dadurch festlegen, welche Kombinationen von Werten der Variablen zulässig sind. Ein CSP wird gelöst, indem eine Belegung der Variablen gefunden wird, die allen Bedingungen genügt. Im Unterschied zu anderen Optimierungsproblemen, in denen eine „möglichst gute" Lösung gesucht wird, fordern Constraint- Satisfaction-Probleme eine vollständige Erfüllung jeder einzelnen Bedingung. Es kann dabei durchaus mehrere Lösungen geben .
Die Lösung des CSP-Verfahrens , also der gefundene Plan zur Verteilung der Software (deployment plan) , kann vom Anwender hündisch oder automatisch zur Ausführung freigegeben werden. Der Anwender kann den Plan einsehen, was diesen Plan
transparent für den Anwender macht.
Es kann auch vorgesehen werden, dass ein einmal ermittelter Plan aufgrund von Messwerten, Zuständen und/oder
Rückmeldungen von ausführenden Einheiten und/oder aufgrund von Vorgaben des Anwenders (z.B. vom Anwender festgelegte Ereignisse) einen Alarm auslöst oder geändert, insbesondere neu berechnet und ausgeführt, wird.
Eine Ausführungsform der Erfindung besteht darin, dass die Bedingungen zur Ausführung der Unteranwendungen und/oder die Voraussetzungen der verschiedenen Ebenen und/oder der konkreten Plattformen zumindest eine der folgenden
Eigenschaften umfassen: Zuverlässigkeit, Verfügbarkeit, Skalierbarkeit, Vertraulichkeit, Effizienz, Sicherheit
(Safety) , Verwendbarkeit, Sicherheit (Safety) , Preise für unterschiedliche Ressourcen, Kommunikation mit anderen
Unteranwendungen und/oder Plattformen. Betreffend die Kommunikation mit anderen Unteranwendungen und/oder
Plattformen umfasst dies die Notwendigkeit der Kommunikation mit anderen Unteranwendungen beziehungsweise die Möglichkeit der Kommunikation mit anderen Plattformen. Skalierbarkeit bedeutet, dass der Anwendung bei Bedarf mehr Ressourcen, also etwa mehr Rechenleistung, mehr Speicher oder überhaupt mehrere Rechner zur Verfügung gestellt werden.
Eine Ausführungsform der Erfindung besteht darin, dass die Bedingungen zur Ausführung der Unteranwendungen und/oder die Voraussetzungen der verschiedenen Ebenen und/oder der
konkreten Plattformen und/oder der einzelnen Rechner
(Recheneinheiten) zumindest eine der folgenden Eigenschaften umfassen: Vorhandensein zumindest einer bestimmten zusätzlich benötigten Hard- und/oder Software, insbesondere in der richtigen Version.
Das heißt, dass die Voraussetzungen der verschiedenen Ebenen können Voraussetzungen der einzelnen Rechner der jeweiligen Ebene umfassen. Das heißt wiederum, es können nicht nur die Eigenschaften einer ganzen Ebene oder Plattform, sondern auch - zusätzlich oder alternativ - die Eigenschaften bestimmter Rechner oder Hosts einer Ebene oder Plattform festgelegt werden .
Insbesondere in diesem Fall kann vorgesehen sein, dass entsprechend der Lösung des Bedingungserfüllungsproblems zumindest eine Unteranwendung auf einen bestimmten Rechner einer konkreten Plattform einer Ebene verteilt, also diesem zur Ausführung zugewiesen, wird.
Es kann vorgesehen sein, dass die Bedingungen zur Ausführung der Unteranwendungen umfassen, dass bestimmte Randbedingungen automatisch, basierend auf vorhandener Information ermittelt werden. Zum Beispiel kann vorgesehen sein, dass zwei
Unteranwendungen nicht auf die gleiche Plattform oder den gleichen Rechner einer Plattform verteilt werden dürfen.
Die Bedingungen zur Ausführung der Unteranwendungen können generell umfassen, dass bestimmte Unteranwendungen nicht auf die gleiche Ebene, die gleiche Plattform einer Ebene oder den gleichen Rechner einer Plattform verteilt werden dürfen. Dies kann z.B. Sicherheitsgründe haben.
Es kann auch vorgesehen sein, dass die Bedingungen zur
Ausführung der Unteranwendungen umfassen, dass zwei
verschiedene Unteranwendungen voneinander abhängig sind und wenn sie auf verschiedene Plattformen verteilt werden, die Kommunikation zwischen diesen Plattformen möglich ist.
Es kann vorgesehen sein, dass bei Änderung einer
Voraussetzung der verschiedenen Ebenen bzw. Plattformen das Bedingungserfüllungsproblem geändert und erneut gelöst wird, und entsprechend der neuen Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Ebenen bzw. Plattformen neu verteilt werden .
Die Änderung einer Voraussetzung der verschiedenen Ebenen bzw. Plattformen kann eine Änderung eines Zustands (z.B.
verfügbare Rechenleistung, Speicherverlust, Abschalten einzelner Einheiten der Ebene, Verlust der Datenverbindung) , oder einer Regel einer Plattform oder eines Rechners einer Plattform sein. Die Änderung des Zustands oder einer Regel kann die Änderung des Preises für eine oder mehrere
Ressourcen auf zumindest einer der Plattformen umfassen. Eine Regel kann z.B. lauten, dass wenn die Verwendung aller Instanzen einer Unteranwendung für eine bestimmte Zeit unter oder über einem bestimmten Schwellwert ist, dann soll die Zahl der verwendeten Instanzen entsprechend verringert oder vergrößert werden. Oder eine Regel kann sein, dass eine hohe Auslastung von Einheiten in der Edge annehmbar ist, solange der Preis für Rechenleistung in der Cloud über einem
bestimmten Schwellwert liegt. Eine weitere Regel kann sein, dass die Anzahl der Instanzen von einer bestimmten
Unteranwendungen erhöht wird wenn der Preis für
Rechenleistung in der Cloud einen gewissen Wert
unterschreitet, wodurch mehr Ausfallsicherheit erreicht werden kann.
Insbesondere kann die Änderung einer Voraussetzung der verschiedenen Plattformen eine Änderung der Auslastung einer Plattform oder eines Rechners einer Plattform sein.
Es kann vorgesehen sein, dass zumindest eine Bedingung zur Ausführung der Unteranwendungen durch eine verantwortliche Person, etwa den Entwickler, vorgegeben werden kann.
Eine Ausführungsform der Erfindung besteht darin, dass bei vom Anwender vorgegebenen Ereignissen das
Bedingungserfüllungsproblem geändert und erneut gelöst wird, und entsprechend der neuen Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen neu verteilt werden.
Da das erfindungsgemäße Verfahren auf bzw. mit einem Computer ausgeführt wird, umfasst die Erfindung auch ein
entsprechendes Computerprogrammprodukt, welches wiederum Befehle umfasst, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, alle Schritte des erfindungsgemäßen Verfahrens auszuführen. Das
Computerprogrammprodukt kann beispielsweise ein Datenträger sein, auf welchem ein entsprechendes Computerprogramm
gespeichert ist, oder es kann ein Signal oder Datenstrom sein, der über eine Datenverbindung in den Prozessor eines Computers geladen werden kann.
Das Computerprogramm kann also folgende Schritte veranlassen bzw. selbst durchführen:
- dass Bedingungen zur Ausführung der Anwendung sowie auch der einzelnen Unteranwendungen in einer Datenbank,
insbesondere in einer Graphdatenbank, erfasst werden (z.B. durch Eingabe durch einen Anwender oder durch Einlesen von Daten) ,
- dass den Bedingungen zur Ausführung entsprechende
Voraussetzungen der verschiedenen Ebenen, nämlich
Voraussetzungen der mindestens einen Plattform einer Ebene, in einer Datenbank, insbesondere einer Graphdatenbank, erfasst werden (z.B. durch Eingabe durch einen Anwender oder durch Einlesen von Daten) ,
- dass die für die bestimmte Anwendung notwendigen
Unteranwendungen ausgewählt werden (z.B. durch Eingabe durch einen Anwender oder durch Einlesen von Daten) ,
- dass aus den Bedingungen für die Anwendung sowie auch für die einzelnen Unteranwendungen und aus den diesbezüglichen Voraussetzungen der verschiedenen Ebenen, nämlich der jeweils mindestens einen Plattform der Ebenen, automatisch ein
Bedingungserfüllungsproblem erstellt und gelöst wird, und
- dass entsprechend der Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen verteilt werden.
KURZE BESCHREIBUNG DER FIGUREN Zur weiteren Erläuterung der Erfindung wird im nachfolgenden Teil der Beschreibung auf die Figuren Bezug genommen, aus denen weitere vorteilhafte Einzelheiten und mögliche
Einsatzgebiete der Erfindung zu entnehmen sind. Dabei zeigt
Fig. 1 eine schematische Darstellung des Informationsflusses beim erfindungsgemäßen Verfahren,
Fig. 2 eine Basisarchitektur für ein Computersystem zur
Ausführung des erfindungsgemäßen Verfahrens,
Fig. 3 eine grafische Darstellung zweier Unteranwendungen und deren Bedingungen zur Ausführung,
Fig. 4 eine grafische Darstellung der Anwendung und ihrer
Unteranwendungen, gemeinsam mit einer möglichen Ebene zur Ausführung der Unteranwendungen,
Fig. 5 eine grafische Darstellung der Edge mit deren
Voraussetzungen,
Fig. 6 die Lösung des Bedingungserfüllungsproblems gemäß den
Fig. 4 und 5,
Fig. 7 ein Ergebnis der Ausführung der Anwendung gemäß den
Fig. 4-6.
WEGE ZUR AUSFÜHRUNG DER ERFINDUNG
Fig. 1 zeigt den Informationsfluss in einem erfindungsgemäßen System. Es gibt verschiedene Wege wie eine neue Verteilung der Unteranwendungen erfolgen kann: durch händischen Eingriff des Anwenders, automatisch als Teil einer Continuous
Integration (CI) pipeline oder durch Complex Event Processing (CEP) . Continuous Integration (CI, kontinuierliche oder fortlaufende oder permanente Integration) beschreibt den Prozess des fortlaufenden Zusammenfügens von Unteranwendungen zu einer Anwendung. Weil dies sequentiell erfolgt, spricht man von einer pipeline. Beim Complex Event-Processing (CEP, deutsch komplexe Verarbeitung von Ereignissen) geht es um die Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Ereignisse. Die entsprechenden Methoden und
Werkzeuge verarbeiten Ereignisse, während sie passieren, also kontinuierlich und zeitnah. CEP leitet aus Ereignissen höheres, wertvolles Wissen in Form von sog. komplexen
Ereignissen ab, d. h. Situationen, die sich nur als
Kombination mehrerer Ereignisse erkennen lassen. Um
verschiedenartige Datenströme in Echtzeit zu verarbeiten und die Ereignisse zu extrahieren und zu analysieren, müssen von diesbezüglichen Systemen hohe Lasten verkraftet werden.
Fig. 1 zeigt einen MAPE Zyklus, MAPE steht für Monitor- Analyze-Plan-Execute . Die Überwachung (Monitor), Buchstabe M in Fig. 1, wird in der Überwachungsphase mittels der
"Monitoring Component" durchgeführt, die Analyse (Analyze) , Buchstabe A in Fig. 1, mit Hilfe des Complex Event Processing „CEP" (oder alternativ durch den Entwickler oder Betreiber, „Developer Or Operational Staff") , das Planen (Plan) ,
Buchstabe P in Fig. 1, mittels des Verteilungsplaners
(„Deployment Planner") und die Ausführung (Execute) ,
Buchstabe E in Fig. 1, mit dem Verteilungsservice
(„Deployment Service") .
Das Complex Event Processing erlaubt es, dem Betreiber der Edge (dem sogenannten Performance Engineer oder dem
Operations Manager) bestimmte Regeln für eine bestimmte
Unteranwendung vorzugeben, z.B. dass nur zwei CPU
Belastungsspitzen während einer bestimmten Zeitspanne
auftreten dürfen, oder dass der Speicherverbrauch in einem bestimmten Zeitraum eine bestimmte Schwelle nicht
überschreiten darf. Zusätzlich kann der Betreiber einen
Rückruf (callback) der Unteranwendung vorsehen, wenn diese Regeln ausgelöst werden. Der Rückruf kann beispielsweise an das Verteilungsservice (Deployment Service) weitergeleitet werden, das eine neue Verteilung auslöst. Eine andere
Möglichkeit für einen Rückruf wäre das Versenden einer
Nachricht an eine Person die mit der Überwachung des Systems betraut ist.
Wenn eine Verteilung angestoßen wird, siehe Pfeil 1 „Trigger Deployment", dann ruft das Verteilungsservice (Deployment Service) den Verteilungsplaner (Deployment Planner) auf, auf dass dieser alle notwendigen Informationen zur Berechnung eines optimierten Verteilungsplans sammelt, siehe Pfeil 2 „Plan Deployment". Dies umfasst die für die zu verteilenden Unteranwendungen erlaubten Ebenen bzw. Einheiten (Allowed Platforms) , siehe Pfeil 2.1 „Get Allowed Platforms", sowie die zur Zeit laufenden Anwendungen, siehe Pfeil 2.2 „Get Running Services". Die zu verteilenden Unteranwendungen werden vom Verteilungsservice (Deployment Service) oder vom Entwickler (Developer) zur Verfügung gestellt. Grundsätzlich sollten für eine Anwendung, die aus mehreren Unteranwendungen besteht, alle Unteranwendungen geplant werden und dann nur jene Unteranwendungen anders verteilt oder migriert werden, für die eine bessere Einheit zur Ausführung gefunden wird.
Die dafür nötige Information kann vom App Model und von der Service Registry geliefert werden. Das App Model definiert wie eine Anwendung ausgeführt werden kann, welche
Datenformate sie empfangen und senden kann und welche
Operationen auf Daten sie braucht und zur Verfügung stellt. Die Service Registry enthält weitere Informationen zu den einzelnen Unteranwendungen, typischerweise deren Speicherort, deren Laufzeit und Bedingungen für deren Beendigung.
Die Information wird benötigt, um einen optimalen
Verteilungsplan für die gegebenen Unteranwendungen zu erstellen. Dieser Verteilungsplan wird an das
Verteilungsservice (Deployment Service) zurückgegeben, welches daraufhin das Deployment übernimmt und die
Unteranwendungen an die Manager der Einheiten (Device
Manager) verteilt, siehe Pfeil 3 „Deployment Manager".
Nachdem eine Unteranwendung gestartet worden ist, registriert sie sich beim Manager der Einheiten (Device Manager) , dieser beginnt, Messwerte, sogenannte Metrics, der ausführenden Einheit zu sammeln, wie etwa CPU Auslastung und verfügbarer Speicherplatz. Diese Messwerte werden an die
Überwachungseinheit (Monitoring Component) weitergeleitet, siehe Pfeil 4 „Push Metrics". Der Manager der Einheiten
(Device Manager) kann die Messdaten vorverarbeiten und diese in transformierter Form an die Überwachungseinheit
(Monitoring Component) weiterleiten. Die Überwachungseinheit (Monitoring Component) ihrerseits leitet die Daten an die Complex Event-Processing Einheit CEP weiter, siehe Pfeil 5.1 „Push Events". Die Complex Event-Processing Einheit CEP analysiert die Daten auf Basis der vom Anwender vorgegebenen Regeln und triggert eine neue Verteilung der
Unteranwendungen, wenn nötig, siehe Pfeil 1 „Trigger
Deployment". Diese Verteilung kann zum Beispiel bewirken, dass die Unteranwendung skaliert wird, wobei dies davon abhängt, ob und welche Regeln definiert wurden. Ein Anwender könnte z.B. festlegen, wenn die Verwendung aller Instanzen einer Unteranwendung für eine bestimmte Zeit unter oder über einem bestimmten Schwellwert ist, dann soll die Zahl der verwendeten Instanzen entsprechend verringert oder vergrößert werden. Ein Anwender könnte auch festlegen, dass eine hohe Auslastung von Einheiten in der Edge annehmbar ist, solange der Preis für Rechenleistung in der Cloud über einem
bestimmten Schwellwert liegt. Die Verteilung der
Unteranwendungen kann auch vom Entwickler getriggert werden, wenn dieser entsprechende Anweisungen in der Steuereinheit für die Quellcodeversion einbaut, welche wiederum die
Continuous Integration (CI) Pipeline triggert. Die Verteilung der Unteranwendungen kann auch vom Anwender manuell gestartet werden, wenn dieser es für notwendig erachtet. Dieses
manuelle Starten der Verteilung ist durch Pfeil 5.2 „Observe" dargestellt .
Fig. 2 zeigt eine mögliche Basisarchitektur der
erfindungsgemäßen Lösung.
Die Architektur umfasst ein cloudbasiertes , offenes IoT- Betriebssystem, hier mit dem Namen „MindSphere Platform" von Siemens. Diese ist mit der Ebene der Edge verbunden, um
Messwerte und Ereignisse auszutauschen, was mit dem
Doppelpfeil „Push Metrics/Receive Events" dargestellt ist.
Die Darstellung der Basisarchitektur in Fig. 2 zeigt der Übersicht halber lediglich jeweils eine konkrete Cloud- und Edge-Plattform. Das erfindungsgemäße Verfahren ist allerdings nicht auf eine einzelne Plattform pro Ebene beschränkt.
Das cloudbasierte, offene IoT-Betriebssystem „MindSphere Platform ist mit einer weiteren Ebene, „MindSphere Apps" verbunden, auf der weitere Anwendungen des IoT- Betriebssystems laufen, wie eine Ursachenanalyse für Fehler („Root Cause Analysis (CART)"), eine Identifizierung von Abweichungen, z.B. mittels Isolation Forest Methode („Outlier Detection (Isolation Forest)") und eine Optimierung, z.B. mit Simplexverfahren oder mit genetischen Algorithmen
(„Optimization (GA, Simplex)").
Das cloudbasierte, offene IoT-Betriebssystem „MindSphere Platform" umfasst links dargestellt allgemeine Services
(„Platform Services") , in der Mitte dargestellt das Werkzeug zur automatischen Verteilung der Unteranwendungen und rechts dargestellt die Unteranwendungen „Services@Cloud" , Sl, S2,
S3, die in der Cloud ausgeführt werden können. Die
allgemeinen Services („Platform Services") umfassen z.B.
einen „Fleet Manager" (der es erlaubt die Messwerte, die für Eigenschaften verschiedener Einheiten gesammelt wurden, zu visualisieren) , „Time Series" (eine Einheit zur Aufzeichnung von zeitlich aufeinander folgenden Messwerten) und ein „Asset Management" (der es erlaubt diverse Eigenschaften einer
Gruppe von Einheiten, wie z.B. Motoren, zu definieren) .
Das Werkzeug zur automatischen Verteilung der
Unteranwendungen hat drei Ebenen und setzt einen MAPE Zyklus um. Die Ebene des Verteilungsplaners (Deployment Planner) ist zuständig für die Berechnung eines optimalen
Verteilungsplanes für jede Verteilanfrage. Diese Ebene umfasst das Cloud-Edge-Anwendungsmodell (Cloud Edge App
Model) wo Entwickler ihre Anwendungen gemeinsam mit den nichtfunktionalen Anforderungen (englisch non-functional requirement, NFR) definieren und wo diese Informationen in einer Graphdatenbank gespeichert werden. Eine genauere
Beschreibung des Datenmodells und der Anwendungen dazu folgt noch. Alle laufenden Unteranwendungen werden in der Service Registry registriert. Zusätzlich ist ein Lösungsdienst
(Solver) vorgesehen, der eine Schnittstelle zur
Anwendungsprogrammierung (API, englisch application
programming interface) zur Verfügung stellt, also einen
Programmteil, der anderen Programmen für die Anbindung an die einzelne Unteranwendung dient. Auf diese Weise kann ein neuer Verteilungsplan erstellt werden. Der Anwender hat hier mehrere Möglichkeiten zur Einflussnahme:
Erstens kann der Anwender nur die Unteranwendungen nennen, die er verteilen will, und sonst die vorgegebenen Modelle mit den vorgegebenen Zielfunktionen verwenden. Zweitens kann der Anwender eine eigene Zielfunktion vorgeben, die zur
Optimierung der Verteilung verwendet wird. Drittens kann der Anwender überhaupt ein eigenes Modell zur Verteilung der Unteranwendungen vorgeben.
Die zweite Ebene heißt „Analysis & Plan Execution" und umfasst die Planung und Ausführung, sie enthält entsprechend die Complex Event-Processing Einheit CEP und das
Verteilungsservice (Deployment Service) . Die zweite Ebene bereitet die Daten für die Planung auf und führt die
Verteilung als Resultat der Planung aus. Das
Verteilungsservice (Deployment Service) dient als Eingang zum System. Ein Entwickler kann hier eine neue Verteilung
triggern. Das Verteilungsservice (Deployment Service) erhält dann den optimierten Verteilungsplan vom Verteilungsplaner (Deployment Planner) und übernimmt die tatsächliche
Verteilung .
In der dritten Ebene, dem „Monitoring", sind hier drei
Anwendungen vorgesehen, „QoS Watcher" welcher die Messwerte der Einheiten entgegen nimmt, an das Complex Event Processing weiterleitet und entsprechend der vom Benutzer definierten Regeln Rückrufe ausführt. Die „Metrie Persistence" welche ebenfalls Messwerte von dem „QoS Watcher" erhält und diese in einer Datenbank ablegt. Die „Metrie Visu" (kurz für „Metrie Visualization") welche es erlaubt die von der „Metrie
Persistence" abgelegten Messwerte zu laden und graphisch anzuzeigen .
In der Edge Ebene laufen Einheiten, die den Manager der
Einheiten (Device Manager) beherbergen. Dieser ist
verantwortlich dafür, jene Anwendungen zu überwachen, die auf dem gleichen Host (Rechner) laufen wie er, und Messwerte in die Cloud zu senden. Weiters erhält der Manager der Einheiten (Device Manager) Befehle vom Verteilungsplaner (Deployment Planner) , um bestimmte Unteranwendungen zu starten oder zu stoppen. Die Unteranwendungen „Services@Edge" , S2, S4 können in der Edge ausgeführt werden.
Rechts in Fig. 2 sind andere Cloud-Anwendungen (Other Cloud Platform) darstellt, hier auf IaaS ( Infrastructure as a Service) Basis. Sie enthalten etwa Anwendungen zur verteilten Versionsverwaltung von Dateien (Source Code Version Control System), wie Git. Wenn Entwickler ihre Änderungen an
Anwendungen zur verteilten Versionsverwaltung senden, wird ein CI Server (z.B. von Jenkins) zur Continuous Integration getriggert, um die neueste Änderung herauszufinden und die Anwendung dann entsprechend aus den gegebenenfalls geänderten Unteranwendungen aufzubauen. Ist der Aufbau erfolgreich, werden die resultierenden Software-Artefakte in einem
Artefakt-Speicher (Artifact Store) gespeichert, z.B. in einem JFrog Artifactory. Wenn alle Unteranwendungen erfolgreich zu einer Anwendung zusammengesetzt worden sind, triggert der CI Server eine neue Verteilung (redeployment) der
Unteranwendungen beim Verteilungsservice (Deployment
Service) . Diese Vorgänge zwischen den anderen Cloud- Anwendungen und dem Cloud-Bereich „Mindsphere Platform" sind in Fig. 2 durch den Doppelpfeil „Deployment Trigger / Receive Artifacts" dargestellt.
Zur Illustration des Informationsflusses beim
erfindungsgemäßen Verfahren soll nun anhand der Fig. 3-7 ein kleiner Anwendungsfall vorgestellt werden. Es wurde hier eine Anwendung zum Detektieren von Ausreißern implementiert, die Ausreißer-Anwendung, und zwar mittels zweier
Unteranwendungen, dem Lerner („Learner") und dem Auswerter („Scorer") . Ziel ist es, Ausreißer in Sensor-Messwerten zu detektieren, z.B. der Motortemperatur. Beide Unteranwendungen werden im Beispiel mittels der Programmiersprache Python implementiert. Als Bibliothek für das Machine Learning wurde skicit-learn verwendet, für das Lernen des Modells eine
Isolation Forest Methode.
Der Lerner sammelt Daten, speichert sie lokal und trainiert ein Machine Learning Modell zum Detektieren von Ausreißern. Der Lerner trainiert das Modell in regelmäßigen Abständen neu, um sich verändernde Bedingungen zu berücksichtigen.
Nachdem das Modell trainiert ist, wird es an einem
Speicherort gespeichert, der für beide Unteranwendungen zugänglich ist. Da der Lerner, in Abhängigkeit der
Trainingsintervalle, beim Trainieren möglicherweise ziemlich viele Daten zu verarbeiten hat, wird er dafür viel
Rechenleistung benötigen, zudem kann die Anzahl der Modelle, für welche Daten gesammelt werden müssen, über die Zeit schwanken. Die Skalierbarkeit der Unteranwendung wäre also von Vorteil. Eine zeitnahe oder sogar Echtzeit- Datenverarbeitung für das Modell oder die Datensammlung hingegen ist nicht notwendig.
Der Auswerter lädt auf Anfrage verfügbare Modelle vom
Speicherort und wertet diese aus, d.h. er wendet ein Modell auf einen gegebenen Datensatz an. Er sendet dann den
Datensatz zu einer Zeitserien-Datenbank („time series störe", siehe Anwendung „Time Series" in Fig. 2) und markiert ihn dort als möglichen Ausreißer, je nach Ergebnis der
Auswertung. Zusätzlich retourniert der Auswerter die
Information, ob ein Ausreißer vorliegt, an die anfragende Anwendung. Die Auswertung braucht nicht viele Ressourcen und die Modelle sind meist viel kleiner als die Dateien mit den Datensätzen. Insofern kann der Auswerter auf Einheiten ausgeführt werden, die nur beschränkte Ressourcen zur
Verfügung haben. Andererseits ist es wahrscheinlich, dass die anfragende Anwendung die Information, ob ein Ausreißer vorliegt oder nicht, zeitnahe benötigt, d.h. die Auswertung sollte annähernd in Echtzeit erfolgen.
Beide Unteranwendungen wurden implementiert und im App Model abgespeichert, also deren Anforderungen an Ressourcen,
Software und Verwendung. Dies ist in Fig. 3 dargestellt. Der Lerner („Learner") benötigt („NEEDS") RAM, CPU, Bandbreite „BANDW.." und verschiedene Software wie Python, und hat
(„HAS") verschiedene Verwendungsparameter („Usage Param.") . Gleiches gilt für den Auswerter („Scorer") .
In Fig. 4 ist ersichtlich, dass die Ausreißer-Anwendung „Outlier Detector" zwei Unteranwendungen „Learner" und „Scorer" umfasst (HAS"), die jeweils Verwendungsparameter („Usage Param.") haben. Diese Verwendungsparameter, in diesem Fall „NearRealtime" („NearRea...") , also „annähernd Echtzeit", können von Plattformen zur Verfügung gestellt werden, hier von der Edge .
Es wurden zwei Plattformen (eine für jede Ebene) definiert, auf welche Unteranwendungen verteilt bzw. ausgelagert werden können, nämlich eine private Cloud Plattform und eine Edge Plattform. Die private Cloud Plattform („Edge Host 1") stellt („PROVIDES") variable Skalierung und Vertraulichkeit zur Verfügung, sowie RAM, CPU, Bandbreite „BANDW..." und
verschiedene Software wie Python. Dies ist in Fig. 5
dargestellt .
Der folgende Informationsfluss geht davon aus, dass mit einem MindSphere System gearbeitet wird und dass auf jedem Host (Rechner) , der nicht direkt von einer Plattform verwaltet wird, ein Device Manager ausgeführt wird. Um die Ausreißer- Anwendung zu starten und die Unteranwendungen zu verteilen, muss einfach der entsprechende REST Endpunkt des Verteilungsservice (Deployment Service) aufgerufen werden, mit einer Zuordnung der Namen der Unteranwendungen zu einer ganzen Zahl, welche der gewünschten Anzahl an Instanzen entspricht. Dies entspricht dem Pfeil (1) „Trigger
Deployment" in Fig. 1. Dann ruft das Verteilungsservice
(Deployment Service) den Verteilungsplaner (Deployment
Planner) auf, mit einer Liste der Unteranwendungen, die verteilt werden sollen. Der Verteilungsplaner (Deployment Planner) sammelt alle notwendigen Informationen zur
Berechnung eines optimierten Verteilungsplans, siehe Pfeil 2 „Plan Deployment". Zuerst kontaktiert der Verteilungsplaner (Deployment Planner) das App Model, um die erlaubten
Einheiten (Allowed Platforms) für die benötigten
Unteranwendungen zu finden, siehe Pfeil 2.1 „Get Allowed Platforms" in Fig. 1.
Das interne Resultat des App Model dazu ist in Fig. 6
dargestellt. Es werden die Namen der Unteranwendungen
„Service . name" gelistet, dazu die möglichen Plattformen
(„platforms") bzw. Ebenen, also die private Cloud
(„MindSphere" ) und die Edge, die notwendigen Anforderungen („requirements") bzw. verfügbaren Eigenschaften („provides" ) , wie Skalierbarkeit („ElasticScalability" ) , annähernd
Echtzeit-Datenverarbeitung („NearRealTime" ) und
Vertraulichkeit („Privacy"). In der Spalte „perfectMatch" wird mit „true" (wahr) und „false" (falsch) dargestellt, ob es eine Übereinstimmung von notwendigen Anforderungen und verfügbaren Eigenschaften gibt. In der letzten Spalte
„missing" wird angegeben, welche notwendigen Anforderungen nicht erfüllt sind.
Das Resultat wird transformiert, z.B. in JSON, und an den Verteilungsplaner (Deployment Planner) zurückgesendet. Das Resultat kann eine einfache Zuordnung sein, die jeder
Unteranwendung zu einer Liste von Plattformen zuordnet, auf die sie verteilt werden kann. Dies entspricht der Antwort in Gegenrichtung zu Pfeil 2.1 „Get Allowed Platforms" in Fig. 1.
Der Verteilungsplaner (Deployment Planner) holt anschließend die Liste der zur Zeit laufenden Anwendungen, siehe Pfeil 2.2 „Get Running Services", kreiert aus den Daten eine Datei und den dynamischen Teil eines CSP Verfahrens, das hier mittels einer entsprechenden Programmiersprache definiert und einem entsprechendem Verfahren gelöst wird. Die grundlegenden
Randbedingungen sind in einer Datei für das statische Modell festgelegt. Die grundlegenden Randbedingungen sind:
- kein Host kann Unteranwendungen übernehmen, die seine Ressourcen übersteigen
- alle Unteranwendungen müssen auf genau einen Host
verteilt werden, der auf einer Plattform ist, auf welchen die Unteranwendung verteilt werden darf
- der Host muss die benötigte Software in der richtigen Version zur Verfügung stellen.
Das dynamische Modell enthält Randbedingungen, die von
Planung zu Planung variieren können, z.B. dass bestimmte Unteranwendungen nicht gemeinsam verteilt werden dürfen, also nicht auf dem gleichen Host laufen dürfen.
Der Verteilungsplaner (Deployment Planner) erstellt eine Datei aus seinem Input. Wenn die Programmiersprache nur mit ganzen Zahlen und Matrizen arbeiten kann, müssen die Daten aus dem Input an die Struktur dieser Programmiersprache angepasst werden. Die Darstellung, welche Ressourcen auf welchem Host/welcher Plattform zur Verfügung stehen, wird beispielsweise als Matrix (h x r) dargestellt, wobei h den Host/die Plattform und r die Ressource repräsentiert, und wobei die Zahl n in der Position (h, r) angibt, wie viele Ressourcen r der Host/die Plattform h hat.
Das Ergebnis des Lösungsverfahrens ist eine einzige
Zuordnungsmatrix oder -datenreihe, wo die Zahl i auf Position j aussagt, dass die Unteranwendung j dem Host/der Plattform i zugeordnet, also auf diesen verteilt, wird. Diese
Zuordnungsmatrix oder -datenreihe wird durch den
Verteilungsplaner (Deployment Planner) entsprechend
rückübersetzt und das Ergebnis dem Verteilungsservice
(Deployment Service) zurückgeleitet.
Der Verteilungsplaner (Deployment Planner) kümmert sich um die tatsächliche Verteilung der Unteranwendungen. Wenn die Zielplattform eine Cloud Plattform ist, wird eine
entsprechende Programmbibliothek zur Verteilung verwendet. Wenn die Zielplattform eine Edge Plattform ist, dann sendet der Verteilungsplaner (Deployment Planner) einen Befehl an den entsprechenden Manager der Einheiten (Device Manager) , der dann den Software-Artefakt lädt und die Unteranwendung startet. Der Device Manager überwacht die Unteranwendung und sendet Messwerte zur Qualitätseinheit (QoS Watcher, siehe Fig. 2), welche die Qualität der Ausführung der
Unteranwendung überwacht und die Messwerte an die Complex Event-Processing Einheit CEP weiterleitet. Damit schließt sich der MAPE Zyklus. Nur wenn der Entwickler sich
entscheidet, eine neue Verteilung anzustoßen, oder die
Complex Event-Processing Einheit CEP ein entsprechendes
Ereignis detektiert, dann wird die ganze Kette zur Verteilung der Unteranwendungen wieder gestartet.
Fig. 7 zeigt die Einbindung der Ausreißer-Anwendung in die Anwendung „Fleet Manager", die auf der „MindSphere Platform" läuft, siehe Fig. 2, und die hier mehrere Motoren überwacht und steuert. Links in Fig. 7 sind die verfügbaren Ansichten im „Fleet Manager" dargestellt, rechts ist die ausgewählte Ansicht dargestellt, welche mit Hilfe der Ausreißer-Anwendung erstellt wird. Rechts zeigt die obere Kurve den zeitlichen Verlauf (abgespeichert in „Time Series") der Messwerte der Temperatur eines Motors. Die untere Kurve zeigt mit „1" an, dass ein Ausreißer vorliegt, mit „0", dass kein Ausreißer vorliegt. Die Anwendung „Fleet Manager" kann nun ein
Alarmsignal ausgeben, wenn ein Ausreißer festgestellt wird.

Claims

Patentansprüche
1. Verfahren, unter Verwendung eines Computers, zum
Verteilen von Unteranwendungen einer bestimmten Anwendung auf Rechner zumindest zweier verschiedener Ebenen, umfassend jeweils mindestens eine konkrete Plattform, wobei eine erste Ebene mehr Rechenleistung zur Verfügung hat als eine zweite Ebene, dadurch gekennzeichnet,
- dass Bedingungen zur Ausführung der Anwendung sowie auch der einzelnen Unteranwendungen in einer Datenbank, insbesondere in einer Graphdatenbank, erfasst werden,
- dass den Bedingungen zur Ausführung entsprechende
Voraussetzungen der verschiedenen Ebenen, nämlich
Voraussetzungen der mindestens einen Plattform einer Ebene, in einer Datenbank, insbesondere einer
Graphdatenbank, erfasst werden,
- dass die für die bestimmte Anwendung notwendigen
Unteranwendungen ausgewählt werden,
- dass aus den Bedingungen für die Anwendung sowie auch für die einzelnen Unteranwendungen und aus den
diesbezüglichen Voraussetzungen der verschiedenen Ebenen, nämlich der jeweils mindestens einen Plattform der
Ebenen, automatisch ein Bedingungserfüllungsproblem erstellt und gelöst wird, und
- dass entsprechend der Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen verteilt werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei der Erstellung des Bedingungserfüllungsproblems die Kosten für Ressourcen auf den einzelnen Plattformen berücksichtigt werden.
3. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass die Bedingungen zur Ausführung der Unteranwendungen und/oder die Voraussetzungen der verschiedenen Ebenen und/oder der konkreten Plattformen zumindest eine der folgenden
Eigenschaften umfassen: Zuverlässigkeit, Verfügbarkeit, Skalierbarkeit, Vertraulichkeit, Effizienz, Sicherheit, Verwendbarkeit, Preise für unterschiedliche Ressourcen, Kommunikation mit anderen Unteranwendungen und/oder Plattformen .
4. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass die Bedingungen zur
Ausführung der Unteranwendungen und/oder die
Voraussetzungen der verschiedenen Ebenen und/oder der konkreten Plattformen und/oder der einzelnen Rechner zumindest eine der folgenden Eigenschaften umfassen: Vorhandensein zumindest einer bestimmten zusätzlich benötigten Hard- und/oder Software, insbesondere in der richtigen Version.
5. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass entsprechend der Lösung des Bedingungserfüllungsproblems zumindest eine
Unteranwendung auf einen bestimmten Rechner einer konkreten Plattform einer Ebene verteilt wird.
6. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass die Bedingungen zur
Ausführung der Unteranwendungen umfassen, dass bestimmte Randbedingungen automatisch, basierend auf vorhandener Information ermittelt werden.
7. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass die Bedingungen zur
Ausführung der Unteranwendungen umfassen, dass die
Kommunikation zwischen mindestens zwei voneinander abhängigen Unteranwendungen, die auf mindestens zwei verschiedenen Plattformen verteilt sind, möglich ist.
8. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass bei Änderung einer
Voraussetzung der verschiedenen Plattformen das
Bedingungserfüllungsproblem geändert und erneut gelöst wird, und entsprechend der neuen Lösung des
Bedingungserfüllungsproblems die Unteranwendungen auf Rechner der verschiedenen Plattformen neu verteilt werden .
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Änderung einer Voraussetzung der verschiedenen
Plattformen eine Änderung eines Zustands oder einer Regel einer Plattform oder eines Rechners einer Plattform ist.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Änderung einer Voraussetzung der verschiedenen
Plattformen eine Änderung der Auslastung einer Plattform oder eines Rechners einer Plattform ist.
11. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass zumindest eine Bedingung zur Ausführung der Unteranwendungen durch eine
verantwortliche Person vorgegeben wird.
12. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass bei vom Anwender
vorgegebenen Ereignissen das Bedingungserfüllungsproblem geändert und erneut gelöst wird, und entsprechend der neuen Lösung des Bedingungserfüllungsproblems die
Unteranwendungen auf Rechner der verschiedenen
Plattformen neu verteilt werden.
13. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass zumindest eine Plattform der ersten Ebene eine über das Internet erreichbare
Rechnerwolke ist.
14. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass zumindest eine Plattform der zweite Ebene ein dem Anwender des Verfahrens räumlich nahe liegendes Rechner-Netzwerk ist, das einen zeitlich kürzeren Datentransport vom und zum Computer des
Anwenders erlaubt als eine Plattform der ersten Ebene.
15. Computerprogrammprodukt, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 auszuführen.
EP19739893.6A 2018-07-05 2019-06-25 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen Pending EP3799633A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18181819.6A EP3591525A1 (de) 2018-07-05 2018-07-05 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen
PCT/EP2019/066788 WO2020007645A1 (de) 2018-07-05 2019-06-25 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen

Publications (1)

Publication Number Publication Date
EP3799633A1 true EP3799633A1 (de) 2021-04-07

Family

ID=63047092

Family Applications (2)

Application Number Title Priority Date Filing Date
EP18181819.6A Withdrawn EP3591525A1 (de) 2018-07-05 2018-07-05 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen
EP19739893.6A Pending EP3799633A1 (de) 2018-07-05 2019-06-25 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP18181819.6A Withdrawn EP3591525A1 (de) 2018-07-05 2018-07-05 Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen

Country Status (4)

Country Link
US (1) US20210303363A1 (de)
EP (2) EP3591525A1 (de)
CN (1) CN112639739A (de)
WO (1) WO2020007645A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220116397A1 (en) * 2020-10-12 2022-04-14 Zscaler, Inc. Granular SaaS tenant restriction systems and methods

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143759A1 (en) * 2005-12-15 2007-06-21 Aysel Ozgur Scheduling and partitioning tasks via architecture-aware feedback information
WO2009056371A1 (en) * 2007-10-31 2009-05-07 International Business Machines Corporation Method, system and computer program for distributing a plurality of jobs to a plurality of computers
US8321870B2 (en) * 2009-08-14 2012-11-27 General Electric Company Method and system for distributed computation having sub-task processing and sub-solution redistribution
US9451025B2 (en) * 2013-07-31 2016-09-20 International Business Machines Corporation Distributed storage network with alternative foster storage approaches and methods for use therewith
US10956450B2 (en) * 2016-03-28 2021-03-23 Salesforce.Com, Inc. Dense subset clustering
TWI617982B (zh) * 2016-11-21 2018-03-11 財團法人資訊工業策進會 協助使用者管理軟體容器的計算機裝置與方法
US10951648B2 (en) * 2017-03-06 2021-03-16 Radware, Ltd. Techniques for protecting against excessive utilization of cloud services
CN107959708B (zh) * 2017-10-24 2020-10-13 北京邮电大学 一种基于云端-边缘端-车端的车联网服务协同计算方法与系统

Also Published As

Publication number Publication date
US20210303363A1 (en) 2021-09-30
CN112639739A (zh) 2021-04-09
EP3591525A1 (de) 2020-01-08
WO2020007645A1 (de) 2020-01-09

Similar Documents

Publication Publication Date Title
EP1330685B1 (de) Prüfverfahren und prüfvorrichtung zur inbetriebnahme von mittels einer programmlogik gesteuerten systemen
DE112015004578T5 (de) Datenpipeline für Prozesssteuerungssystemanalyse
DE112020004623T5 (de) Ml-basierte ereignishandhabung
DE102010036511A1 (de) Prozesssteuerungssystem mit integrierten externen Datenquellen
DE112007003612T5 (de) Alarmanalysesystem und Verfahren zur Statistiken über Alarme von einem Prozesskontrollsystem
DE112019003185T5 (de) Automatischer dynamischer diagnoseleitfaden mit erweiterter realität
DE112011103443T5 (de) Intelligente Schnittstelle für ein dezentrales Steuerungssystem
EP2902857B1 (de) Verfahren zur Bereitstellung von Funktionen innerhalb eines industriellen Automatisierungssystems und industrielles Automatisierungsystem
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE102017007054A1 (de) Numerische Steuerung
DE102019001129A1 (de) Numerische Steuervorrichtung
EP3948446A1 (de) Generierung und verteilung von konfigurations-datenstrukturen für steuerungssysteme
DE602004006630T2 (de) Verfahren zur Durchführung eines Softwaredienstes in einer Systemlandschaft
EP3799633A1 (de) Verteilen von unteranwendungen einer bestimmten anwendung auf rechner von plattformen zumindest zweier verschiedener ebenen
DE102019117196A1 (de) Verfahren und vorrichtungen zum konfigurieren von zugriff auf signale von mehrvariablen-feldgeräten
EP3855259B1 (de) Verfahren zur kompatibilitätsprüfung von funktionsmodulen
CH701481B1 (de) Prozessmanagement.
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
WO2020126168A1 (de) Verfahren zur zusammenarbeit von mehreren geräten eines lokalen netzwerks
DE112006002896T5 (de) System und Verfahren zur Weiterleitung von Informationen
DE102017121757A1 (de) Verfahren zur Planung und Steuerung einer logistischen Prozesskette in der Agrarwirtschaft
DE112022000406T5 (de) Überwachen eines allgemeinzustands eines grossen cloud-computing-systems
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
WO2002067151A1 (de) Konfigurator
DE10033812A1 (de) Verfahren zum Erzeugen von Informationsmodellen

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201230

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220916

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED