WO2016020076A1 - Verfahren und serverarchitektur zur steuerung von diensten in einer middleware für eine vereinfachte kommunikation zwischen auf autonomen rechnern verteilten, bei der middleware registrierten oder zu registrierenden anwendungen technischer systeme - Google Patents

Verfahren und serverarchitektur zur steuerung von diensten in einer middleware für eine vereinfachte kommunikation zwischen auf autonomen rechnern verteilten, bei der middleware registrierten oder zu registrierenden anwendungen technischer systeme Download PDF

Info

Publication number
WO2016020076A1
WO2016020076A1 PCT/EP2015/060276 EP2015060276W WO2016020076A1 WO 2016020076 A1 WO2016020076 A1 WO 2016020076A1 EP 2015060276 W EP2015060276 W EP 2015060276W WO 2016020076 A1 WO2016020076 A1 WO 2016020076A1
Authority
WO
WIPO (PCT)
Prior art keywords
middleware
program module
applications
registered
calculation
Prior art date
Application number
PCT/EP2015/060276
Other languages
English (en)
French (fr)
Inventor
Sebastien ANDREO
Regine Meunier
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2016020076A1 publication Critical patent/WO2016020076A1/de

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/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the invention relates to a method for controlling services in a middleware for a simplified commu ⁇ nication between distributed on autonomous computers in the middleware registered or registered applications of technical systems according to the preamble of Patentanspru ⁇ ches 1 and a server architecture for controlling Services in a middleware for a simplified communication zwi ⁇ rule on autonomous computers distributed in the middleware registered or registered applications of technical systems according to the preamble of claim 10.
  • Middleware refers to a special computer soft ⁇ ware that for other software applications services for Provision ⁇ tion that goes out ⁇ over the services of an operating ⁇ . These services allow easier Kommunikati ⁇ on between applications REGIST Center at the middleware. The complexity of these applications and their different protocols are hidden from each other. Therefore, you can call a middleware as a distribution platform (see htt: // de.wikipedia.org/wiki/ Middleware in the version of 10.06.2014).
  • the applications that use the middleware for communication can not provide their own tasks at this time, or only to a limited extent.
  • these applications may have Service Level Agreements (SLAs) that guarantee very short downtime for certain tasks.
  • SLAs Service Level Agreements
  • the services of the middleware used for the basic functionality of the registered applications may vary from application to application.
  • a technical system with applications that register with a middleware is a network for the provision and consumption of renewable energy, in which both energy suppliers and energy consumers are associated.
  • the integrated in the network wind turbines offer a "Web Service Interface", which is used to Administrati ⁇ on the wind turbines and the supply of weather data on mounted on the wind turbines sensors.
  • SCADA Supervisory Control and Data Acquisition
  • Another application involved in the composite could be e.g. an eCar application.
  • the present invention is not limited to the abovementioned technical system with the aforementioned applications, but can readily also for any other technical systems, such as those in the field of industrial automation, medical technology, power engineering in other fields than the above explained wind turbine scenario, the digital information and communication technology, etc., are applied.
  • the above-indicated "middleware" -Pro blematik belongs to the prior art, for example a Lö ⁇ sungsansatz consisting of a middleware installation program which generates an implementation plan and for com- plex middleware configurations is used.
  • This implementation plan is created on the basis of imple ⁇ extension options, which has set an administrator.
  • the implementation plan determines the order of starting the components of a middleware (cf.
  • estEn. tml So the administrator has the ability to set options so that the middleware runs in total as quickly as possible high ⁇ .
  • the information about the middleware services first required in emergency situations is not explicitly mentioned here, since the applications do not log on to these requirements.
  • the implementation plan is not dynamically changed when a new application is registered, possibly with different requirements for its basic functionality.
  • the object on which the invention is based is to specify a method and a server architecture for controlling services in a middleware for simplified communication between applications of technical systems distributed on autonomous computers registered or to be registered in the middleware, in which or at in case of an interruption of the simplified communication of the applications in the middleware and consequent downtimes of basic functionalities of the applications as well as with a subsequent resumption or restart of the simplified communication of the applications optimizing start-up times and restoring the basic functionalities of the applications.
  • the idea underlying the invention is that in the control of services in a middleware for simplified communication between distributed on autonomous computers, registered in the middleware or regist- rations applications of technical systems
  • a starting order for starting the middleware components is calculated using a calculation rule created on the basis of the prioritization of the middleware services and service attributes as input parameters, and
  • the service-specific middleware components are started according to the calculated start order.
  • middleware for this are corresponding program modules - a registration program module for storing and dispensing by registered or to be registered applications each application-related basic functions benötig ⁇ th and prioritized services middleware,
  • the middleware can use, for example, a protocol for nego ⁇ development of the allocation of resources to applications, such as "SNAP: A protocol for negotiating service level ag- reements and coordinating resource management in distributed system" (see.
  • the type of control proposed according to the idea underlying the invention allows applications that register with the middleware to specify a prioritization of the services of the middleware. This prioritization can be chosen in such a way that the basic functionality of the application is restored as quickly as possible (Stw.: Short anal time).
  • the type of control in the middleware (e.g., by the program modules specified in claim 10) allows, with the aid of a calculation rule, to extract from the indications of all registered applications the required services and corresponding service attributes, e.g. as a fixed characteristic of the service associated Service Level Agreements (SLAs), calculated as input parameters for the calculation rule, an optimal order of providing the services of the middleware and derived therefrom an optimal order of startup of the components of the middleware.
  • SLAs Service Level Agreement
  • the calculation rule is executed as a parameterizable rule (claim 2) or is parameterizable (claim 11).
  • the parameterability of the calculation rule also allows the input parameters to be weighted for the calculation of the start order (claims 3 and 12). The weighting is preferably carried out by the administrator or operator of the middleware (claims 7 and 16).
  • Starting order for starting the middleware components is dynamically calculated (claims 4 and 13), to measure a Wiederan ⁇ running the middleware and / or shutting down and restarting the middleware in terms of minimal downtime of the basic functionality of just registered applications measure ⁇ gebat improve.
  • the type of control of services in the middleware for the simplified communication between the formers on autonomous accounting distributed registered with the middleware or to be registered applications may also be further improved by the startup sequence for starting the Midd ⁇ leware components on the Basis of analyzed monitoring Data is calculated at least from one of preceding restarts the middleware and the shut down and restart the middleware, wherein the monitoring data includes the Sin ⁇ ne a "learning calculation instruction" corresponding measurement values for making a connection between appli ⁇ applications / application scenarios and success of the calculation rule (Claims 8 and 17).
  • the results of the analysis can be used to improve future or later than ⁇ tere recalculations of the starting order of the service when starting up the middleware.
  • Another optional measure to improve the way in which the services in the middleware are controlled for the simplified communication between the applications registered or to be registered with the middleware is that the start order for starting the middleware components is increased the basis of analyzed business monitoring data, in particular costs due to SLA violation, is calculated (claims 9 and 17). These costs are e.g. agreed and actual costs for Service Level Agreement breaches that are required to recalculate the
  • a server architecture based on a server (“1 server solution”) according to claim 18 (see FIGURE 1) in which the middleware with all the program modules is fully integrated in the server or the server architecture and
  • a server architecture based on two servers (“2-server solution”) according to claim 19 (see FIGURE 2) in which the Server architecture is divided into two parts, a first server and a second server, wherein the first server contains the registration program module, the service attributes program ⁇ module, the memory program modules and the calculation program module that does not belong to the middleware, currency ⁇ rend the second server contains the boot program module, wel ⁇ ches is integrated into the middleware and the middleware such as ⁇ derum is integrated in the second server.
  • the first server is a separate machine on which the mentioned program modules run.
  • the ⁇ ser server is then responsible for generating the starting order of the middleware components and not necessarily affected by a failure of the designated second server middleware server in which the middleware is integrated.
  • FIGURE 1 "1 server solution” for the control of services in a middleware for a simplified communication between distributed on autonomous computers, registered in the middleware or to register applications of technical systems
  • FIGURE 2 "2 server solution” for the control of Services in a middleware for simplified communication between distributed on autonomous computers, registered in the middleware trated or registered applications of technical systems.
  • FIG. 1 shows a server architecture SVA based on the "1 server solution” for the control of services DI in a middleware MW for a simplified communication between applications AW of a technical system distributed on autonomous computers and registered with the middleware MW.
  • the middleware MW of this "1 server solution” is preferably fully integrated into the server architecture SVA.
  • a service is a functionality that is offered to the outside by the middleware MW and that is realized by middleware components within the middleware MW.
  • middleware MW Several services of the middleware MW can use the same middleware components.
  • an application is another type of software that uses the services of the middleware MW.
  • the technical system with the associated applications can e.g. a network for the provision and consumption of regenerative energies with a "Supervisory Control and Data Acquisition (SCADA)" application, an eCar application, etc.
  • SCADA Supervisory Control and Data Acquisition
  • Wind turbines offer a "web service interface" for the administration and delivery of weather data via attached sensors.
  • For monitoring the windmills is e.g. the aforementioned SCADA application (cf.
  • middleware MW shuts down or ⁇ must be driven forth, it is most important for the wind turbines to synchronize back in time to ensure that all financial data contained correct time stamp. This is done using a middleware time-sync service. This applies to all wind turbines. That is, as long as only the wind turbines high priority Log on services are the components of the middleware MW that allow the "time-sync" service to boot first. Other services of middleware MW, such as storage, message
  • Filtering or protocol adapters are not necessary for the emergency functions of the wind turbine and their components can therefore be started up downstream.
  • a new application is integrated into the network, new priorities may arise. If e.g. If the mentioned eCar application is involved, then this could have the highest priority to recharge power as soon as possible. It would specify the middleware service to authorize the highest priority load. The middleware service to participate in the voltage regulation of the entire network is required with lower priority.
  • the middleware also referred to as a distribution platform, is a special computer / server software, which provides for other software applications services available and preference ⁇ , according to the FIGURE 1 runs on a server or computer.
  • the middleware also referred to as a distribution platform, is a special computer / server software, which provides for other software applications services available and preference ⁇ , according to the FIGURE 1 runs on a server or computer.
  • the software-technical distribution platform the
  • Middleware MW has a program program module R-PM, which the applications AW for the registration of them for application-related basic functionalities and priori- use services.
  • the registration program module R-PM provides a means of communicating with the user applications so that they can communicate their priorities for services. It saves the priorities assigned by the user.
  • the first application AW1, the third application AW3, and the fourth application AW4 have each issued a service prioritization.
  • the first service Dil and then the fifth service DI5 are needed first.
  • the two ⁇ te application AW2 has no explicit service prioritization.
  • the third application AW3, first the first service Dil, then the seventh service DI7 and finally the eighth service DI8 are needed again.
  • the fourth application QW4 has defined the service prioritization according to the order from the drit ⁇ th service DI3, the seventh and eighth service DI7 DI8 service.
  • the respective prioritized services DI are stored in this registration program module R-PM and then in connection with the calculation of a start order from the components of the middleware MW (hereinafter referred to as middleware components or FIG. 1 as MW components designated).
  • the middleware components are software building blocks inside the middleware MW that are needed to realize the services of the middleware.
  • middleware components there is also middleware components that advertising directly addressed by any service to, but are needed in total for the functionality of Middlewa ⁇ re MW.
  • the middleware components are in the FIGURE 1, in contrast to the various program modules, such as the above-mentioned registration program module R-PM to re ⁇ tration of the prioritized services that is not explicitly represented in FIG.
  • the program modules represented are software modules that implement a self functionali ⁇ ty and differ in this respect from the middleware components.
  • the calculation of the starting order of the middleware components takes place in a specially provided calculation program module B-PM, in which the calculation of the starting order is implemented.
  • this computation program module B-PM receives as input for the calculation of the start order attributes, eg fixed properties, of the services DI which are in one
  • Service attributes program module D-PM are stored.
  • the calculation ⁇ sem program module PM B communicates ⁇ so well with the registration program module R-PM and with the service attributes program module D-PM.
  • Service attribute includes, for example, a "Service Level Agreement (SLA)" as an integral part of the service DI.
  • SLA Service Level Agreement
  • the storage of these service attributes in the service attributes program module D-PM is preferably carried out by the administrator or operator of the middleware MW. It is alternatively also possible that the service attributes from another server or computer-ter automatically by means of a software stored on this program in the service attributes program module D-PM vomit ⁇ chert.
  • the calculation program module B-PM With the service attributes and the information for prioritizing the middleware services, the calculation program module B-PM now determines the starting order of the middleware components.
  • the calculation program module B-PM forms together with the registration program module R-PM and the
  • Molecularattribute program module D-PM a data processing functional unit and creates on the basis of genann ⁇ th input parameters a calculation rule, with which the starting order is calculated.
  • the implementation of the Be ⁇ accounting regulations receives as input parameters the priorities and values of such variables, the fixed properties of services (service attributes) encode, eg height of a penalty for SLA violation. From this, they calculated a Start Herbertnfol ⁇ ge of middleware components, from which then ultimately gives a sequence in which the services of the middleware are available again.
  • the start order sequence is preferably calculated once after all applications AW have registered with the middleware.
  • the rule is preferential ⁇ as a configurable rule in the input parameters are weighted for cargo ⁇ bill the startup sequence. This weighting of the input parameters of the calculation rule is preferably carried out by the administrator or operator of the middleware.
  • the calculation program module B-PM provides a way in the form of a ⁇ input means, which are preferably embodied as software and how the middleware components are not shown ex- plicitly in FIGURE 1, for communication with the governments ⁇ rator or operator.
  • the starting order for starting the middleware components is calculated dynamically.
  • the boot order for starting the middleware components is recalculated each time a new application registers with the middleware MW or an application logs out of the middleware MW.
  • the start program module S-PM which forms a flow-controlling functional unit with the calculation-Pro ⁇ program module PM B is configured so that the service-specific middleware components are ge ⁇ starts according to the calculated startup sequence.
  • the start program module S-PM is thus a program module which effectively starts the middleware services in the calculated sequence when the middleware MW is restarted.
  • the calculation program module B-PM start order for updating the calculation result ⁇ ses for the access at least one of later re-runs the middleware MW and the subsequent shutdown and restart the middleware MW in a first memory program module SP1-PM stored, which is the input side associated with the calculation program module B-PM.
  • the calculation can be additionally analyzed by the administrator, in addition to the fixed properties of the applications, the prioritizations and the weighting of the administrator
  • This analysis program module A-PM performs measurements on service usage by the applications, the conditions of middleware recovery (e.g., selected boot order), and their results (e.g., restart times).
  • incurred costs may also be incurred by violations of SLAs (by the administrator or by a business system, such as another server or computer) and stored.
  • the analysis program module A-PM is to output side associated with the Be ⁇ calculation program module B-PM to form the data processing function unit such that the actual computation program module B-PM, the startup sequence for starting the Midd- leware components additionally on the basis of analyzed monitoring data calculated, include the monitoring data in the sense of "learning calculation instruction" corresponding measurement values for making a connection between the at ⁇ applications or application scenarios and the success of the calculation rule.
  • the monitoring data or the corresponding measured values result from previous restarts of the middleware MW and the shutdown and restart of the middleware MW and are stored in a second memory program module SP2-PM, which is assigned on the input side to the analysis program module A-PM. stored.
  • further data can be used to optimize the calculation of the starting order of the middleware components.
  • data may be, for example, business monitoring data stored in a third memory program module SP3-PM.
  • the third memory program module SP3-PM like the second memory program module SP2-PM, is assigned to the analysis program module A-PM in the same way.
  • Business ⁇ economic monitoring data are, for example, data that specify the costs by a "Service Level Agreement" violation.
  • This data is preferably provided by the administrator or Operator of the middleware entered into the third memory program module SP3-PM.
  • FIGURE 2 shows a rating based on the "two-server solution" Ser ⁇ ver drawur SVA for the control of services DI in a middleware MW for a simplified communication between distributed on autonomous computers in the middleware MW registered applications AW a technical system.
  • a service is a functionality that is offered to the outside by the middleware MW and that is implemented within the middleware MW by means of middleware components.
  • middleware MW can use the same middleware components.
  • an application is another type of software that uses the services of the middleware MW.
  • the technical system with the associated applications can e.g. again a network for the provision and consumption of renewable energy with a "Supervisory Control and Data Acquisition (SCADA)" application, an eCar application, etc., in which both energy suppliers and energy consumers are connected.
  • SCADA Supervisory Control and Data Acquisition
  • the e.g. wind turbines integrated into the network offer a "web service interface" for the administration and delivery of weather data via attached sensors.
  • For monitoring the windmills is e.g. the aforementioned SCADA application (cf.
  • middleware MW shuts down or has to be shut down
  • Other services of middleware MW such as storage, message
  • Filtering or protocol adapters are not necessary for the Notfallfunktio ⁇ nen of the wind turbine and its components can therefore be raised downstream.
  • a new application is integrated into the network, new priorities may arise. If e.g. If the mentioned eCar application is involved, then this could have the highest priority to recharge power as soon as possible. It would specify the middleware service to authorize the highest priority load. The middleware service to participate in the voltage regulation of the entire network is required with lower priority.
  • the middleware also referred to as a distribution platform, is a special computer / server software, which provides for wider at ⁇ software applications services available and overall the FIGURE 2 Gurss preferably back to a server or computer is running.
  • the server architecture SVA is divided in two parts into a first server SV1 and a second server SV2, the middleware MW with the middleware components functioning as a software-technical distribution platform only in FIG the second server SV2 is integrated, while the first server SV1 has no middleware components, but exclusively other software components, as described below contains.
  • the middleware components are software building blocks inside the middleware MW that are needed to realize the services of the middleware. In addition to these aforementioned services middleware components there is also middleware components that are directly addressed by any service, but are needed in total for the functionality of Middlewa ⁇ re MW.
  • the middleware components are not explicitly illustrated in FIGURE 2 in FIGURE 2, unlike various program modules discussed below.
  • the program modules represented are software modules that implement a self-contained functionality and ⁇ divorced this respect by the middleware components.
  • a registration program module R PM is implemented, the use of the applications for the AW Regis Trie ⁇ tion of the services required of them and for application-related Basisfunktionalitä ⁇ th prioritized.
  • the registration program module R-PM provides a way to communi ⁇ cation with user applications that enable them to submit their priorities for services. It stores the priorities transmitted by the applications.
  • the third application AW3 and the fourth application AW4 each have issued a service prioritization.
  • the first application AW1 did not specify explicit service prioritization.
  • the second service becomes DI2 first and then the fourth service DI4 needed.
  • the third application AW3, first the first service Dil, then the third service DI3 and finally the fifth service DI5 are needed.
  • the fourth application AW4 has set the service prioritization according to the order of the sixth service DI6, the seventh service DI7, and the ninth service DI9.
  • the respective prioritized services DI are stored in this registration program module R-PM and then in connection with the calculation of a start order of the components of the middleware MW (hereinafter referred to as middleware components or FIG. 2 as MW components designated).
  • the calculation of the start order of the middleware components also takes place on the first server SV1 in a specially provided calculation program module B-PM, in which the calculation of the start order is implemented.
  • ⁇ ses calculation program module B-PM receives in addition to the prioritization of services DI by the applications AW by a Divattribu- te program module D-PM attributes, including fixed attributes, the service DI, in a Service attributes program module D-PM are stored.
  • the calculation ⁇ voltage program module PM B communicates both with the registration program module R-PM and with the service attributes program module PM D-.
  • a typical service attribute includes, for example, a "Service Level Agreement (SLA)" as an integral part of the service DI.
  • SLA Service Level Agreement
  • the storage of these service attributes in the Felat ⁇ tribute program module D-PM is preferably carried out by the ad ⁇ ministrator or operator of the middleware MW.
  • the service attributes are automatically stored by another server or computer by means of a software program stored thereon in the service attributes program module D-PM.
  • the calculation program module B-PM With the service attributes and the information for prioritizing the middleware services, the calculation program module B-PM now determines the starting order of the middleware components.
  • the calculation program module B-PM forms thereby together with the registration program module R-PM and the
  • Felattribute program module D-PM a data processing functional unit and creates on the basis of genann ⁇ th input parameters a calculation rule, with which the starting order is calculated.
  • the implementation of the Be ⁇ accounting regulations receives as input parameters the priorities and values of such variables, the fixed properties of services (service attributes) encode, eg height of a penalty for SLA violation. From this it calculates a start order of the middleware components, which ultimately results in a sequence in which the services of the middleware are available again.
  • the calculation of the starting order takes place vorzugswei- se even after all applications AW have registered with the Middlewa ⁇ re.
  • the rule is preferential ⁇ as a configurable rule in the input parameters are weighted for cargo ⁇ bill the startup sequence.
  • This weighting of the input parameters of the calculation rule is preferably carried out by the administrator or operator of the middleware.
  • the calculation program module B-PM provides a way in the form of a ⁇ input means, which are preferably embodied as software and how the middleware components are not shown ex- plicitly in FIGURE 1, for communication with the governments ⁇ rator or operator.
  • the starting order for starting the middleware components is calculated dynamically.
  • the boot order for starting the middleware components is recalculated each time a new application registers with the middleware MW or an application logs out of the middleware MW.
  • the start program module S-PM the server across forms a ablaufsteu ⁇ ernde functional unit with the calculation program module B-PM, is designed such that the service-specific middleware components are started according to the calculated startup sequence.
  • the start program module S-PM is thus a program module that effectively starts the middleware services in the calculated sequence when the middleware MW is restarted.
  • calculation program module B-PM start order for updating the calculation result ⁇ ses for access at least one of later restarts the middleware MW and later shutdown and restart the middleware MW in a first Memory program module SP1 PM stored, which is the input side associated with the calculation program module B-PM.
  • the calculation can be additionally analyzed by the administrator, in addition to the fixed properties of the applications, the prioritizations and the weighting of the administrator
  • This analysis program module A-PM carries out measurements with respect to the service usage by the applications, the conditions of performed middleware restarts (eg selected boot sequence) and their results (eg with regard to restart times). Furthermore, optionally incurred costs can also be entered by violations of SLAs (by the administrator or by a business management system, eg a further server or computer) and stored.
  • the analysis program module A-PM is to output side associated with the Be ⁇ calculation program module B-PM to form the schwverone- the functional unit such that the actual computation program module B-PM, the startup sequence for starting the Midd- leware components in addition to the Based on the analyzed monitoring data calculated, the monitoring data in the sense of the "learning calculation rule" corresponding measured values for establishing a relationship between the appli ⁇ tions or application scenarios and the success of the calculation rule include.
  • the monitoring data or the corresponding measured values result from previous restarts of the middleware MW and the shutdown and restart of the middleware MW and are in a second
  • Memory program module SP2-PM which is assigned on the input side to the analysis program module A-PM, stored.
  • further data can be used to optimize the calculation of the starting order of the middleware components.
  • data may be, for example, business monitoring data stored in a third memory program module SP3-PM.
  • the third memory program module SP3-PM like the second memory program module SP2-PM, is assigned to the analysis program module A-PM in the same way.
  • Business monitoring data are, for example, data that the
  • This data is preferably entered by the administrator or operator of the middleware into the third memory program module SP3-PM. Alternatively, however, it is also possible for these data to be automatically stored by another server or computer in the third memory program module SP3-PM by means of a software program stored thereon .
  • the service attributes program module D-PM and the memory program modules SP1-PM, SP2-PM, SP3-PM are also preferably located on or in the first server SV1 implemented.
  • Monitoring data includes, in order to optimize the recovery of the Middle ⁇ ware in terms of minimum downtime Basisfunktiona ⁇ formality of the currently registered applications. This makes it possible for the first time, for example
  • SLAs Service Level Agreements

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

Um Dienste (DI, DI1...DI9) in einer Middleware (MW) für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware (MW) registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) technischer Systeme so zu steuern, dass bei einer Unterbrechung der vereinfachten Kommunikation der Anwendungen (AW, AW1...AW4) in der Middleware (MW) und dadurch bedingte Ausfallzeiten von Basisfunktionalitäten der Anwendungen sowie bei einer anschließenden Wiederaufnahme bzw. Neustart der vereinfachten Kommunikation der Anwendungen (AW, AW1...AW4) Anlaufzeiten und die Wiederherstellung der Basisfunktionalitäten der Anwendungen (AW, AW1...AW4) optimiert werden, wird es vorgeschlagen, dass - die vereinfachte Kommunikation der Anwendungen mit Hilfe von dienstspezifischen Middleware-Komponenten der Middleware (MW) ausgeführt wird, - die registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) jeweils für anwendungsbezogene Basisfunktionalitäten benötigte Dienste (DI1, DI5; DI1, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; DI1, DI3, DI5; DI6, DI7, DI9) der Middleware priorisieren, - mit einer auf der Basis der Priorisierung der Middleware-Dienste (DI1, DI5; DI1, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; DI1, DI3, DI5; DI6, DI7, DI9) und Dienstattributen als Inputparameter erstellten Berechnungsvorschrift eine Startreihenfolge zum Starten der Middleware-Komponenten berechnet wird und - die dienstspezifischen Middleware-Komponenten entsprechend der berechneten Startreihenfolge gestartet werden.

Description

Beschreibung
Verfahren und Serverarchitektur zur Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen technischer Systeme
Die Erfindung bezieht sich auf ein Verfahren zur Steuerung von Diensten in einer Middleware für eine vereinfachte Kommu¬ nikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen technischer Systeme gemäß dem Oberbegriff des Patentanspru¬ ches 1 und eine Serverarchitektur zur Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwi¬ schen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen technischer Systeme gemäß dem Oberbegriff des Patentanspruches 10. Mit Middleware bezeichnet man eine spezielle Computer Soft¬ ware, die für andere Softwareanwendungen Dienste zur Verfü¬ gung stellt, die über die Dienste eines Betriebssystems hin¬ ausgehen. Diese Dienste erlauben eine einfachere Kommunikati¬ on zwischen Anwendungen, die sich bei der Middleware regist- rieren. Die Komplexität dieser Anwendungen und ihrer unterschiedlichen Protokolle werden voreinander versteckt. Daher kann man eine Middleware auch als Verteilungsplattform bezeichnen (vgl. htt : //de . wikipedia . org/wiki /Middleware in der Version vom 10.06.2014).
Aufgrund technischer Probleme im technischen System kann es vorkommen, dass eine Middleware heruntergefahren und neu ge¬ startet werden muss. Die Anwendungen, die die Middleware zur Kommunikation verwenden, können in dieser Zeit ihre eigenen Aufgaben gar nicht oder nur eingeschränkt zur Verfügung stellen. Diese Anwendungen haben jedoch möglicherweise "Service- Level-Agreements (SLAs)", die eine sehr kurze Ausfallzeit für bestimmte Aufgaben garantieren. Typischerweise handelt es sich um Aufgaben, die für eine Basisfunktionalität wichtig sind. Es kann sehr teuer oder unmöglich sein, die Middleware und die Hardware, auf der sie läuft, durch Replikation von Softwaremodulen oder durch redundante Hardware oder sehr performante Hardware so zu konzipieren, dass ihre Anlaufzeit so kurz ist, dass die SLAs der registrierten Anwendungen erfüllt werden können. Die Dienste der Middleware, die für die Basisfunktionalität der registrierten Anwendungen gebraucht werden, können von Anwendung zu Anwendung unterschiedlich sein.
Ein technisches System mit Anwendungen, die sich bei einer Middleware registrieren, ist beispielsweise ein Verbund zur Bereitstellung und zum Verbrauch regenerativer Energien, in dem sowohl Energieanbieter als auch Energieverbraucher zusammengeschlossen sind. Die in den Verbund integrierten Windräder bieten ein "Web Service Interface", das zur Administrati¬ on der Windräder und zur Lieferung von Wetterdaten über an den Windrädern angebrachte Sensoren benutzt wird. Zum
Monitoring der Windräder wird z.B. ein "Supervisory Control and Data Acquisition (SCADA) "-Anwendung eingesetzt (vgl.
htt : //de . wikipedia . org/wiki/SCADA in der Version vom
27.05.2014) . Eine weitere Anwendung, die in den Verbund eingebunden wird, könnte z.B. eine eCar-Anwendung sein.
Die vorliegende Erfindung ist aber nicht auf das vorstehend genannte technische System mit den genannten Anwendungen beschränkt, sondern kann ohne Weiteres auch für beliebig andere technische Systeme, so z.B. solche im Bereich der Industrie- Automatisierung, der Medizintechnik, der Energietechnik auf anderen Feldern als dem vorstehend erläuterten Windradszenario, der Digitalen Informations- und Kommunikationstechnik etc., angewandt werden. In Bezug auf die vorstehend angedeutete "Middleware"-Pro- blematik gehört zum Stand der Technik beispielsweise ein Lö¬ sungsansatz bestehend aus einem Middleware-Installations- programm, das einen Implementierungsplan erzeugt und für kom- plexe Middleware-Konfigurationen verwendet wird. Dieser Implementierungsplan wird auf der Grundlage von Implementie¬ rungsoptionen erzeugt, die ein Administrator festgelegt hat. Der Implementierungsplan bestimmt die Reihenfolge des Star- tens der Komponenten einer Middleware (vgl.
http : / /pic . dhe . ibm . com/infocenter/tivihelp/v32rl/index . j sp?to pi c=
estEn . tml ) . Der Administrator hat also die Möglichkeit, Optionen so zu setzen, dass die Middleware insgesamt möglichst schnell hoch¬ fährt. Die Informationen über die in Notfallsituationen zuerst benötigten Middleware-Dienste gehen hier jedoch nicht explizit ein, da die Anwendungen diese Anforderungen nicht anmelden. Insbesondere wird der Implementierungsplan nicht dynamisch geändert, wenn eine neue Anwendung - mit möglicherweise anderen Anforderungen für ihre Basisfunktionalität - registriert wird. Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein Verfahren und eine Serverarchitektur zur Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen techni- scher Systeme anzugeben, bei dem bzw. bei der bei einer Unterbrechung der vereinfachten Kommunikation der Anwendungen in der Middleware und dadurch bedingte Ausfallzeiten von Basisfunktionalitäten der Anwendungen sowie bei einer anschließenden Wiederaufnahme bzw. Neustart der vereinfachten Kommu- nikation der Anwendungen Anlaufzeiten und die Wiederherstellung der Basisfunktionalitäten der Anwendungen optimiert werden .
Diese Aufgabe wird ausgehend von dem im Oberbegriff des Pa- tentanspruchs 1 definierten Verfahren durch die im Kennzei¬ chen des Patentanspruches 1 angegebenen Merkmale gelöst. Darüber hinaus wird die Aufgabe ausgehend von der im Oberbe¬ griff des Patentanspruchs 10 definierten Serverarchitektur durch die im Kennzeichen des Patentanspruches 10 angegebenen Merkmale gelöst.
Die der Erfindung zugrundeliegenden Idee besteht darin, dass bei der Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu regist- rierenden Anwendungen technischer Systeme
- die vereinfachte Kommunikation der Anwendungen mit Hilfe von dienstspezifischen Middleware-Komponenten der Middleware ausgeführt wird,
- die registrierten oder zu registrierenden Anwendungen je- weils für anwendungsbezogene Basisfunktionalitäten benötigte
Dienste der Middleware priorisieren,
- mit einer auf der Basis der Priorisierung der Middleware- Dienste und Dienstattributen als Inputparameter erstellten Berechnungsvorschrift eine Startreihenfolge zum Starten der Middleware-Komponenten berechnet wird und
- die dienstspezifischen Middleware-Komponenten entsprechend der berechneten Startreihenfolge gestartet werden.
In der Middleware sind hierfür entsprechende Programmmodule, - ein Registrier-Programmmodul zum Speichern und Ausgeben von durch die registrierten oder zu registrierenden Anwendungen jeweils für anwendungsbezogene Basisfunktionalitäten benötig¬ ten und priorisierten Diensten der Middleware,
- ein Berechnung-Programmmodul zum Berechnen einer Startrei- henfolge zum Starten der dienstspezifischen Middleware- Komponenten, das eingabeseitig mit dem Registrier-Programmmodul und einem Dienstattribute-Programmmodul eine datenve¬ rarbeitende Funktionseinheit bildet und
- ein Start-Programmmodul, das mit dem Berechnung-Programm- modul eine ablaufsteuernde Funktionseinheit bildet, vorhanden
(vgl. Anspruch 10) Die Middleware kann beispielsweise ein Protokoll zur Verhand¬ lung der Zuteilung von Ressourcen zu Anwendungen verwenden, wie z.B. "SNAP: A protocol for negotiating Service level ag- reements and coordinating resource management in distributed Systems" (vgl.
http://citeseerx.ist.psu. edu/viewdoc/summary?doi=l 0.1.1.135.4 561 ) . In diesem Fall kann die Art der Steuerung erweitert werden, um auch für die Zuteilung der Ressourcen eine Berechnung zu erstellen, die auf die Anforderungen der Basisfunkti- onalität der Anwendungen Rücksicht nimmt.
Fazit : Die gemäß der der Erfindung zugrundeliegenden Idee vorgeschlagene Art der Steuerung erlaubt Anwendungen, die sich bei der Middleware registrieren, eine Priorisierung der Dienste der Middleware anzugeben. Diese Priorisierung kann so gewählt werden, dass die Basisfunktionalität der Anwendung schnellstmöglich (Stw.: kurze Analaufzeit) wieder hergestellt wird. Die Art der Steuerung in der Middleware (z.B. durch die im Anspruch 10 angegebenen Programmmodule) ermöglicht, dass mit Hilfe einer Berechnungsvorschrift aus den Angaben aller registrierten Anwendungen bezüglich der benötigten Dienste und korrespondierender Dienstattribute, z.B. als feste Eigenschaften der Dienste zugeordneter Service Level Agreements (SLAs) , als Inputparameter für die Berechnungsvorschrift eine optimale Reihenfolge des Zur-Verfügung-Stellens der Dienste der Middleware berechnet und daraus eine optimale Reihenfolge des Hochfahrens der Komponenten der Middleware abgeleitet bzw. bestimmt wird. Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Die Berechnungsvorschrift wird als parametrierbare Vorschrift ausgeführt (Anspruch 2) oder ist parametrierbar (Anspruch 11) . Dadurch kann die Steuerung der Dienste in der Middleware für die vereinfachte Kommunikation zwischen den auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen flexibler gestaltet wird. Die Parametrierbarkeit der Berechnungsvorschrift ermöglicht es zudem, dass für die Berechnung der Startreihenfolge die Inputparameter gewichtet werden können (Ansprüche 3 und 12) . Die Gewichtung wird dabei vorzugsweise vom Administrator bzw. Operator der Middleware vorgenommen (Ansprüche 7 und 16) .
Darüber hinaus besteht die zweckmäßige Option, dass die
Startreihenfolge zum Starten der Middleware-Komponenten dyna- misch berechnet wird (Ansprüche 4 und 13) , um einen Wiederan¬ lauf der Middleware und/oder das Herunterfahren und Neustarten der Middleware in Bezug auf minimale Ausfallzeiten der Basisfunktionalität der gerade registrierten Anwendungen ma߬ geblich zu verbessern.
In diesem Zusammenhang ist es auch sinnvoll, dass, wenn sich eine neue Anwendung in bzw. bei der Middleware registriert oder sich eine Anwendung aus der Middleware abmeldet, die Startreihenfolge zum Starten der Middleware-Komponenten neu berechnet wird (Ansprüche 5 und 14) . Damit ist gewährleistet, dass die Middleware die Zeit, die die Anwendungen brauchen, bis ihre Basisfunktionalitäten wieder zur Verfügung stehen, immer optimiert. Weiterhin ist es von Vorteil, die berechnete Startreihenfolge zur Aktualisierung des Ergebnisses der Berechnung zu speichern, damit zumindest bei einem von späteren bzw. zukünfti¬ gen) Wiederanläufen der Middleware und dem späteren bzw. zukünftigen Herunterfahren und Neustarten der Middleware auf das aktualisierte Ergebnis der Berechnung zugegriffen werden kann (Ansprüche 6 und 15) .
Die Art der Steuerung der Dienste in der Middleware für die vereinfachte Kommunikation zwischen den auf autonomen Rech- nern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen kann außerdem noch dadurch verbessert werden, indem die Startreihenfolge zum Starten der Midd¬ leware-Komponenten auf der Basis von analysierten Monitoring- Daten zumindest aus einem von vorausgegangenen Wiederanläufen der Middleware und dem Herunterfahren und Neustarten der Middleware berechnet wird, wobei die Monitoring-Daten im Sin¬ ne einer "lernenden Berechnungsvorschrift" entsprechende Messwerte zum Herstellen eines Zusammenhangs zwischen Anwen¬ dungen/Anwendungsszenarien und Erfolg der Berechnungsvorschrift beinhalten (Ansprüche 8 und 17) .
Hierbei handelt es sich um optionale Maßnahme, bei der vor- zugsweise Messungen zur Nutzung von Diensten der Middleware und zu WiederanlaufSzenarien erfolgen (Monitoring) , die anschließend gespeichert und analysiert werden. Die Ergebnisse der Analyse können verwendet werden, um zukünftige bzw. spä¬ tere Neuberechnungen der Startreihenfolge der Dienste beim Hochfahren der Middleware zu verbessern.
Eine weitere optionale Maßnahme die Art der Steuerung der Dienste in der Middleware für die vereinfachte Kommunikation zwischen den auf autonomen Rechnern verteilten, bei der Midd- leware registrierten oder zu registrierenden Anwendungen zu verbessern, besteht darin, dass die Startreihenfolge zum Starten der Middleware-Komponenten auf der Basis von analysierten betriebswirtschaftlichen Monitoring-Daten, insbesondere Kosten durch SLA-Verletzung, berechnet wird (Ansprüche 9 und 17) . Bei diesen Kosten handelt es sich z.B. um vereinbarte und tatsächlich angefallene Kosten für Verletzungen von Service Level Agreements, die für die Neuberechnung der
Startreihenfolge herangezogen werden. Die in den Ansprüchen 10, 15 und 17 angegebenen Programmmodule können auf zwei verschiedene Arten realisiert werden (An¬ sprüche 18 und 19) :
- Einer Serverarchitektur basierend auf einem Server ("1- Server-Lösung") gemäß Anspruch 18 (vgl. FIGUR 1) bei dem die Middleware mit all den Programmmodulen vollumfänglich in der Server bzw. die Serverarchitektur integriert ist und
- einer Serverarchitektur basierend auf zwei Server ("2- Server-Lösung") gemäß Anspruch 19 (vgl. FIGUR 2) bei der die Serverarchitektur zweiteilig, in einen ersten Server und einen zweiten Server, unterteilt ist, wobei der erste Server das Registrier-Programmmodul , das Dienstattribute-Programm¬ modul, die Speicher-Programmmodule und das Berechnung-Pro- grammmodul enthält, welche nicht zur Middleware gehören, wäh¬ rend der zweite Server das Start-Programmmodul enthält, wel¬ ches in die Middleware integriert ist und die Middleware wie¬ derum in dem zweiten Server integriert ist. Bei der "2-Server-Lösung" ist der erste Server eine separate Maschine auf der die genannten Programmmodule ablaufen. Die¬ ser Server ist dann für die Generierung der Startreihenfolge der Middleware-Komponenten verantwortlich und von einem Ausfall des als zweiten Servers benannten Middleware-Servers , in dem die Middleware integriert ist, nicht unbedingt betroffen.
Bei der "1-Server-Lösung" laufen alle Programmmodule auf dem gleichen Server und können vorzugsweise als Teile der Middle¬ ware selbst realisiert werden. In dem Fall müssen die Pro- grammmodule bei einem Ausfall der Middleware vor den von ihr verwalteten Diensten der Middleware wieder gestartet werden. Die hierfür benötigte Kommunikation kann z.B. über TCP/IP erfolgen . Weitere Vorteile der Erfindung ergeben sich aus der nachfol¬ genden Beschreibung eines Ausführungsbeispieles der Erfindung anhand der FIGUREN 1 und 2. Dies zeigen:
FIGUR 1 "1-Server-Lösung" für die Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen technischer Systeme FIGUR 2 "2-Server-Lösung" für die Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware regis- trierten oder zu registrierenden Anwendungen technischer Systeme .
FIGUR 1 zeigt eine auf der "1-Server-Lösung" basierende Ser- verarchitektur SVA für die Steuerung von Diensten DI in einer Middleware MW für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware MW registrierten Anwendungen AW eines technischen Systems. Die Middleware MW dieser "1-Server-Lösung" ist vorzugsweise voll- umfänglich in die Serverarchitektur SVA integriert.
Ein Dienst ist in diesem Zusammenhang eine Funktionalität, die von der Middleware MW nach außen angeboten wird und die innerhalb der Middleware MW durch Middleware-Komponenten rea- lisiert wird. Dabei können mehrere Dienste der Middleware MW die gleichen Middleware-Komponenten nutzen. Im Unterschied dazu ist eine Anwendung eine andere Art von Software, die die Dienste der Middleware MW nutzt. Das technische System mit den zugeordneten Anwendungen kann z.B. ein Verbund zur Bereitstellung und zum Verbrauch regenerativer Energien mit einer "Supervisory Control and Data Acquisition ( SCADA) "-Anwendung, eine eCar-Anwendung etc.
sein, in dem sowohl Energieanbieter als auch Energieverbrau- eher verbunden sind. Die z.B. in den Verbund integrierten
Windräder bieten zur Administration und Lieferung von Wetterdaten über angebrachte Sensoren ein "Web-Service-Interface" an. Zum Monitoring der Windräder kommt z.B. die erwähnte SCADA-Anwendung (vgl.
http://de.wikipedia.org/wiki/Supervisory Control and Data Acq uisition in der Version vom 27.05.2014) zum Einsatz.
Für den Fall, dass die Middleware MW herunterfährt oder her¬ untergefahren werden muss, ist es für die Windräder am wich- tigsten, sich wieder zeitlich zu synchronisieren, damit alle Meldedaten richtige Zeitstempel enthalten. Dafür wird ein "time-sync"-Dienst der Middleware verwendet. Dies gilt für alle Windräder. D.h. solange nur die Windräder hochprioritäre Dienste anmelden, sind die Komponenten der Middleware MW, die den "time-sync"-Dienst ermöglichen, zuerst hochzufahren. Andere Dienste der Middleware MW, wie Storage, Message
Filtering oder Protocol Adapter sind für die Notfallfunktio- nen des Windrades nicht notwendig und ihre Komponenten können daher nachgelagert hochgefahren werden.
Wenn in den Verbund eine neue Anwendung eingebunden wird, können sich neue Prioritäten ergeben. Wenn z.B. die erwähnte eCar-Anwendung eingebunden wird, dann könnte diese als höchste Priorität haben, so schnell wie möglich wieder Strom zu laden. Sie würde den Middleware-Dienst zur Autorisierung des Ladevorgangs mit höchster Priorität angeben. Der Middleware- Dienst zur Teilnahme an der Spannungsregelung des gesamten Netzes wird mit geringerer Priorität benötigt.
Dies ist ein Beispielszenario, das beliebig erweitert, verän¬ dert oder komplett modifiziert werden kann. So lässt sich ein entsprechend modifiziertes Szenario auf völlig andere technische Systeme mit anderen Anwendungen vor¬ stellen, für das die in der FIGUR 1 dargestellte Middleware- Konzeption zur Dienst-Steuerung seine Gültigkeit behält. In dem Beispiel gemäß der FIGUR 1 sind in der Middleware MW z.B. vier Anwendungen - eine erste Anwendung AW1, eine zweite Anwendung AW2, eine dritte Anwendung AW3 und eine vierte An¬ wendung AW4 - registriert. Die Dienste DI, die in der Middle¬ ware MW durch diese Anwendungen AW1 ... AW4 genutzt werden kön- nen, sind erste bis neunte Dienste Dil ... DI9. Die Middleware, auch als Verteilungsplattform bezeichnet, ist eine spezielle Computer/Server-Software, die für andere Softwareanwendungen Dienste zur Verfügung stellt und gemäß der FIGUR 1 vorzugs¬ weise auf einen Server bzw. Computer läuft. In dieser Funkti- on als softwaretechnische Verteilungsplattform weist die
Middleware MW ein Registrier-Programmmodul R-PM auf, das die Anwendungen AW für die Registrierung der von ihnen für anwen- dungsbezogene Basisfunktionalitäten benötigten und priori- sierten Dienste nutzen. Das Registrier-Programmmodul R-PM stellt eine Möglichkeit zur Kommunikation mit den Nutzeranwendungen zur Verfügung, damit diese ihre Prioritäten für Dienste übermitteln können. Er speichert die von den Anwen- düngen übermittelten Prioriäten.
Von denen in der FIGUR 1 dargestellten Anwendungen AW1 ... AW4 haben die erste Anwendung AW1, die dritte Anwendung AW3 und die vierte Anwendung AW4 jeweils eine Dienst-Priorisierung abgegeben. Für die erste Anwendung AW1 wird zuerst der erste Dienst Dil und dann der fünfte Dienst DI5 benötigt. Die zwei¬ te Anwendung AW2 hat keine explizite Dienst-Priorisierung angegeben. Bei der dritten Anwendung AW3 wird zuerst wieder der erste Dienst Dil, dann der siebte Dienst DI7 und abschließend der achte Dienst DI8 benötigt. Die vierte Anwendung AW4 hat die Dienst-Priorisierung gemäß der Reihenfolge aus dem drit¬ ten Dienst DI3, dem siebten Dienst DI7 und dem achten Dienst DI8 festgelegt. In diesem Registrier-Programmmodul R-PM wer¬ den die jeweils priorisierten Dienste DI gespeichert und dann im Zusammenhang mit der Berechnung einer Startreihenfolge von den Komponenten der Middleware MW (im folgenden als Middlewa- re-Komponenten oder in der FIGUR 1 als MW-Komponenten bezeichnet) ausgegeben. Die Middleware-Komponenten sind Softwarebausteine im Inneren der Middleware MW, die gebraucht werden, um die Dienste der Middleware zu realisieren. Neben diesen von Diensten angesprochenen Middleware-Komponenten gibt es auch Middleware- Komponenten, die von keinem Dienst direkt angesprochen wer- den, aber doch insgesamt für die Funktionalität der Middlewa¬ re MW nötig sind. Die Middleware-Komponenten sind in der FIGUR 1 im Unterschied zu den diversen Programmmodulen, z.B. das vorstehend erwähnte Registrier-Programmmodul R-PM zur Re¬ gistrierung der priorisierten Dienste, nicht explizit in der FIGUR 1 dargestellt. Die dargestellten Programmmodule sind auch Softwarebausteine, die eine abgeschlossene Funktionali¬ tät realisieren und unterscheiden sich diesbezüglich von den Middleware-Komponenten . Die Berechnung der Startreihenfolge der Middleware-Kompo- nenten erfolgt in einem dafür speziell vorgesehenen Berechnung-Programmmodul B-PM, in dem die Berechnung der Startrei- henfolge implementiert ist. Als Input für die Berechnung der Startreihenfolge erhält dieses Berechnung-Programmmodul B-PM neben der Priorisierung der Dienste DI durch die Anwendungen AW von einem Dienstattribute-Programmmodul D-PM Attribute, z.B. feste Eigenschaften, der Dienste DI, die in einem
Dienstattribute-Programmmodul D-PM gespeichert sind. Zu die¬ sem Zweck kommuniziert das Berechnung-Programmmodul B-PM so¬ wohl mit dem Registrier-Programmmodul R-PM als auch mit dem Dienstattribute-Programmmodul D-PM. Zu einem typischen
Dienstattribut zählt z.B. ein "Service Level Agreement (SLA)" als fester Bestandteil des Dienstes DI. Die Abspeicherung dieser Dienstattribute in das Dienstattribute-Programmmodul D-PM erfolgt vorzugsweise durch den Administrator bzw. Operator der Middleware MW. Es ist alternativ aber auch möglich, dass die Dienstattribute von einem anderen Server oder Compu- ter mittels eines auf diesem gespeicherten Softwareprogramm automatisch in das Dienstattribute-Programmmodul D-PM gespei¬ chert werden.
Mit den Dienstattributen und den Informationen zur Priori- sierung der Middleware-Dienste ermittelt das Berechnung- Programmmodul B-PM nun die Startreihenfolge der Middleware- Komponenten. Das Berechnung-Programmmodul B-PM bildet dabei zusammen mit dem Registrier-Programmmodul R-PM und dem
Dienstattribute-Programmmodul D-PM eine datenverarbeitende Funktionseinheit und erstellt dabei auf der Basis der genann¬ ten Inputparameter eine Berechnungsvorschrift, mit der die Startreihenfolge berechnet wird. Die Implementierung der Be¬ rechnungsvorschrift erhält als Inputparameter die Prioritäten und die Werte solcher Variablen, die feste Eigenschaften der Dienste (Dienstattribute) kodieren, z.B. Höhe einer Strafe bei SLA-Verletzung . Daraus berechnet sie eine Startreihenfol¬ ge der Middleware-Komponenten, woraus sich dann letztendlich eine Reihenfolge ergibt, in der die Dienste der Middleware wieder zur Verfügung stehen.
Die Berechnung der Startreihenfolge erfolgt dabei vorzugswei- se einmal, nachdem sich alle Anwendungen AW bei der Middleware registriert haben. Die Berechnungsvorschrift ist vorzugs¬ weise eine parametrierbare Vorschrift, bei der für die Be¬ rechnung der Startreihenfolge die Inputparameter gewichtet werden. Diese Gewichtung der Inputparameter der Berechnungs- Vorschrift wird vorzugsweise vom Administrator bzw. Operator der Middleware vorgenommen. Zu diesem Zweck bietet das Berechnung-Programmmodul B-PM eine Möglichkeit in Form von Ein¬ gabemittel, die vorzugsweise als Software ausgestaltet sind und wie die Middleware-Komponenten in der FIGUR 1 nicht ex- plizit dargestellt sind, zur Kommunikation mit dem Administ¬ rator bzw. Operator.
Um die Startreihenfolge immer den gegebenen Bedingungen anzupassen, ist es von Vorteil, wenn die Startreihenfolge zum Starten der Middleware-Komponenten dynamisch berechnet wird. Darüber hinaus wird die Startreihenfolge zum Starten der Middleware-Komponenten immer dann neu berechnet, wenn sich eine neue Anwendung bei der Middleware MW registriert oder sich eine Anwendung aus dem Middleware MW abmeldet. Ist die Startreihenfolge in dieser Weise von dem Berechnung-Pro¬ grammmodul B-PM berechnet worden, so wird von dem Berechnung- Programmmodul B-PM als Output ein Steuerbefehl an ein Start- Programmmodul S-PM adressiert, mit dem das Start-Programm¬ modul S-PM das Starten der Middleware-Komponenten veranlasst. Das Start-Programmmodul S-PM, das mit dem Berechnung-Pro¬ grammmodul B-PM eine ablaufsteuernde Funktionseinheit bildet, ist so ausgestaltet, dass die dienstspezifischen Middleware- Komponenten entsprechend der berechneten Startreihenfolge ge¬ startet werden. Bei dem Start-Programmmodul S-PM handelt es sich somit um ein Programmodul, das die Middleware-Dienste in der berechneten Reihenfolge beim Wiederanlauf der Middleware MW effektiv startet. Zusätzlich als bevorzugte Ausgestaltung (optionales Feature) wird die von dem Berechnung-Programmmodul B-PM berechnete Startreihenfolge zur Aktualisierung des Berechnungsergebnis¬ ses für den Zugriff zumindest bei einem von späteren Wieder- anläufen der Middleware MW und dem späteren Herunterfahren und Neustarten der Middleware MW in einem ersten Speicher- Programmmodul SP1-PM gespeichert, das dazu eingabeseitig dem Berechnung-Programmmodul B-PM zugeordnet ist. Darüber hinaus kann die Berechnung außer von den festen Eigenschaften der Anwendungen, den Priorisierungen und der Gewichtung des Administrators zusätzlich von analysierten
Monitoring-Daten abhängen. Um die Berechnung der Startreihenfolge von Middleware-Kompo- nenten in dem Berechnung-Programmmodul B-PM deshalb noch wei¬ ter zu optimieren, ist in der Middleware MW ein Analyse- Programmmodul A-PM zum Analysieren von Monitoring-Daten vorhanden .
Dieses Analyse-Programmodul A-PM führt Messungen bezüglich der Dienstnutzung durch die Anwendungen, der Bedingungen durchgeführter Wiederanläufe der Middleware (z.B. gewählte Startreihenfolge) und deren Ergebnisse (z.B. in Bezug auf Wiederanlaufzeiten) durch.
Weiterhin können optional auch angefallene Kosten durch Verletzungen von SLAs eingegeben (durch den Administrator oder durch ein betriebswirtschaftliches System, z.B. einen weite- ren Server bzw. Computer) und gespeichert werden.
Es analysiert die Messungen der Dienstnutzung und der durch SLA Verletzungen entstandenen Kosten. Die Ergebnisse der Analyse werden zusätzlich zu den oben beschriebenen Inputparame- tern an die Berechnungsvorschrift in dem Berechnung-Programmmodul B-PM übergeben. Durch die Analyse von vergangenen Wiederanläufen wird also die Berechnungsvorschrift in Bezug auf ihren Erfolg optimiert. In diesem Fall handelt es sich um ei- ne "lernende Berechnungsvorschrift". Auch in diesem Fall ist es wiederum möglich, dass der Administrator bzw. Operator auf die Gewichtung der verschiedenen Inputparameter innerhalb der Berechnungsvorschrift Einfluss nehmen kann.
Damit die ganzen Monitoring-Daten laufend für das Analyse- Programmodul A-PM zur Verfügung stehen sind in der Middleware MW ein oder mehrere Speicher-Programmodule zur Speichung von Monitoring-Daten vorhanden.
Das Analyse-Programmmodul A-PM ist dazu ausgabeseitig dem Be¬ rechnung-Programmmodul B-PM zur Bildung der datenverarbeitenden Funktionseinheit derart zugeordnet, dass das Berechnung- Programmmodul B-PM die Startreihenfolge zum Starten der Midd- leware-Komponenten zusätzlich auf der Basis der analysierten Monitoring-Daten berechnet, wobei die Monitoring-Daten im Sinne der "lernenden Berechnungsvorschrift" entsprechende Messwerte zum Herstellen eines Zusammenhangs zwischen den An¬ wendungen bzw. Anwendungsszenarien und dem Erfolg der Berech- nungsvorschrift beinhalten. Die Monitoring-Daten bzw. die entsprechenden Messwerte ergeben sich dabei aus vorausgegangenen Wiederanläufen der Middleware MW und dem Herunterfahren und Neustarten der Middleware MW und sind in einem zweiten Speicher-Programmmodul SP2-PM, das eingabeseitig dem Analyse- Programmmodul A-PM zugeordnet ist, abgespeichert.
Neben den Monitoring-Daten, die im Sinne der "lernenden Berechnungsvorschrift" entsprechende Messwerte umfassen, können auch weitere Daten zur Optimierung der Berechnung der Start- reihenfolge der Middleware-Komponenten herangezogen werden. Solche Daten können z.B. betriebswirtschaftliche Monitoring- Daten sein, die in einem dritten Speicher-Programmmodul SP3- PM gespeichert sind. Das dritte Speicher-Programmmodul SP3-PM ist dabei wie das zweite Speicher-Programmmodul SP2-PM einga- beseitig dem Analyse-Programmmodul A-PM zugeordnet. Betriebs¬ wirtschaftliche Monitoring-Daten sind z.B. Daten, die die Kosten durch eine "Service Level Agreement"-Verletzung angeben. Diese Daten werden vorzugsweise vom Administrator bzw. Operator der Middleware in das dritte Speicher-Programmmodul SP3-PM eingegeben. Es ist alternativ aber auch möglich, dass diese Daten von einem anderen Server oder Computer mittels eines auf diesem gespeicherten Softwareprogramm automatisch in das dritte Speicher-Programmmodul SP3-PM gespeichert wer¬ den .
FIGUR 2 zeigt eine auf der "2-Server-Lösung" basierende Ser¬ verarchitektur SVA für die Steuerung von Diensten DI in einer Middleware MW für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware MW registrierten Anwendungen AW eines technischen Systems. Ein Dienst ist in diesem Zusammenhang eine Funktionalität, die von der Middleware MW nach außen angeboten wird und die in- nerhalb der Middleware MW durch Middleware-Komponenten realisiert wird. Dabei können mehrere Dienste der Middleware MW die gleichen Middleware-Komponenten nutzen. Im Unterschied dazu ist eine Anwendung eine andere Art von Software, die die Dienste der Middleware MW nutzt.
Das technische System mit den zugeordneten Anwendungen kann z.B. wieder ein Verbund zur Bereitstellung und zum Verbrauch regenerativer Energien mit einer "Supervisory Control and Data Acquisition ( SCADA) "-Anwendung, eine eCar-Anwendung etc. sein, in dem sowohl Energieanbieter als auch Energieverbraucher verbunden sind. Die z.B. in den Verbund integrierten Windräder bieten zur Administration und Lieferung von Wetterdaten über angebrachte Sensoren ein "Web-Service-Interface" an. Zum Monitoring der Windräder kommt z.B. die erwähnte SCADA-Anwendung (vgl.
http://de.wikipedia.org/wiki/Supervisory Control and Data Acq uisition in der Version vom 27.05.2014) zum Einsatz.
Für den Fall, dass die Middleware MW herunterfährt oder her- untergefahren werden muss, ist es für die Windräder am wichtigsten, sich wieder zeitlich zu synchronisieren, damit alle Meldedaten richtige Zeitstempel enthalten. Dafür wird ein "time-sync"-Dienst der Middleware verwendet. Dies gilt für alle Windräder. D.h. solange nur die Windräder hochprioritäre Dienste anmelden, sind die Komponenten der Middleware MW, die den "time-sync"-Dienst ermöglichen, zuerst hochzufahren. Andere Dienste der Middleware MW, wie Storage, Message
Filtering oder Protocol Adapter sind für die Notfallfunktio¬ nen des Windrades nicht notwendig und ihre Komponenten können daher nachgelagert hochgefahren werden.
Wenn in den Verbund eine neue Anwendung eingebunden wird, können sich neue Prioritäten ergeben. Wenn z.B. die erwähnte eCar-Anwendung eingebunden wird, dann könnte diese als höchste Priorität haben, so schnell wie möglich wieder Strom zu laden. Sie würde den Middleware-Dienst zur Autorisierung des Ladevorgangs mit höchster Priorität angeben. Der Middleware- Dienst zur Teilnahme an der Spannungsregelung des gesamten Netzes wird mit geringerer Priorität benötigt.
Dies ist ein Beispielszenario, das beliebig erweitert, verän¬ dert oder komplett modifiziert werden kann.
So lässt sich ein entsprechend modifiziertes Szenario auf völlig andere technische Systeme mit anderen Anwendungen vor¬ stellen, für das die in der FIGUR 2 dargestellte Middleware- Konzeption zur Dienst-Steuerung seine Gültigkeit behält.
In dem Beispiel gemäß der FIGUR 2 sind in der Middleware MW z.B. wieder vier Anwendungen - eine erste Anwendung AWl, eine zweite Anwendung AW2, eine dritte Anwendung AW3 und eine vierte Anwendung AW4 - registriert. Die Dienste DI, die in der Middleware MW durch diese Anwendungen AWl ... AW4 genutzt werden können, sind wieder erste bis neunte Dienste Dil ... DI9. Die Middleware, auch als Verteilungsplattform bezeichnet, ist eine spezielle Computer/Server-Software, die für an¬ dere Softwareanwendungen Dienste zur Verfügung stellt und ge- mäß der FIGUR 2 vorzugsweise wieder auf einen Server bzw. Computer läuft. Im Unterschied zu der Serverarchitektur SVA in der FIGUR 1 ist die Serverarchitektur SVA in der FIGUR 2 zweiteilig, in einen ersten Server SV1 und einen zweiten Server SV2, unterteilt, wobei die Middleware MW mit den Middleware-Komponenten in ihrer Funktion als softwaretechnische Verteilungsplattform nur in dem zweiten Server SV2 integriert ist, während der erste Server SV1 keine Middleware-Komponenten aufweist, sondern ausschließlich andere Softwarebausteine, wie nachfolgend beschrieben, enthält.
Die Middleware-Komponenten sind Softwarebausteine im Inneren der Middleware MW, die gebraucht werden, um die Dienste der Middleware zu realisieren. Neben diesen von Diensten angesprochenen Middleware-Komponenten gibt es auch Middleware- Komponenten, die von keinem Dienst direkt angesprochen werden, aber doch insgesamt für die Funktionalität der Middlewa¬ re MW nötig sind. Die Middleware-Komponenten sind in der FIGUR 2 im Unterschied zu diversen nachfolgend erläuterten Programmmodulen nicht explizit in der FIGUR 2 dargestellt. Die dargestellten Programmmodule sind auch Softwarebausteine, die eine abgeschlossene Funktionalität realisieren und unter¬ scheiden sich diesbezüglich von den Middleware-Komponenten.
In dem ersten Server SV1 ist ein Registrier-Programmmodul R- PM implementiert, das die Anwendungen AW für die Registrie¬ rung der von ihnen für anwendungsbezogene Basisfunktionalitä¬ ten benötigten und priorisierten Dienste nutzen. Das Registrier-Programmmodul R-PM stellt eine Möglichkeit zur Kommuni¬ kation mit den Nutzeranwendungen zur Verfügung, damit diese ihre Prioritäten für Dienste übermitteln können. Er speichert die von den Anwendungen übermittelten Prioriäten.
Von denen in der FIGUR 2 dargestellten Anwendungen AW1 ... AW4 haben nur die zweite Anwendung AW2, die dritte Anwendung AW3 und die vierte Anwendung AW4 jeweils eine Dienst-Priorisie- rung abgegeben. Die erste Anwendung AW1 hat keine explizite Dienst-Priorisierung angegeben. Für die zweite Anwendung AW2 wird zuerst der zweite Dienst DI2 und dann der vierte Dienst DI4 benötigt. Bei der dritten Anwendung AW3 wird zuerst der erste Dienst Dil, dann der dritte Dienst DI3 und abschließend der fünfte Dienst DI5 benötigt. Die vierte Anwendung AW4 hat die Dienst-Priorisierung gemäß der Reihenfolge aus dem sechs- ten Dienst DI6, dem siebten Dienst DI7 und dem neunten Dienst DI9 festgelegt. In diesem Registrier-Programmmodul R-PM wer¬ den die jeweils priorisierten Dienste DI gespeichert und dann im Zusammenhang mit der Berechnung einer Startreihenfolge von den Komponenten der Middleware MW (im folgenden als Middlewa- re-Komponenten oder in der FIGUR 2 als MW-Komponenten bezeichnet) ausgegeben.
Die Berechnung der Startreihenfolge der Middleware-Kompo- nenten erfolgt ebenfalls auf dem ersten Server SV1 in einem dafür speziell vorgesehenen Berechnung-Programmmodul B-PM, in dem die Berechnung der Startreihenfolge implementiert ist. Als Input für die Berechnung der Startreihenfolge erhält die¬ ses Berechnung-Programmmodul B-PM neben der Priorisierung der Dienste DI durch die Anwendungen AW von einem Dienstattribu- te-Programmmodul D-PM Attribute, z.B. feste Eigenschaften, der Dienste DI, die in einem Dienstattribute-Programmmodul D- PM gespeichert sind. Zu diesem Zweck kommuniziert das Berech¬ nung-Programmmodul B-PM sowohl mit dem Registrier-Programmmodul R-PM als auch mit dem Dienstattribute-Programmmodul D- PM. Zu einem typischen Dienstattribut zählt z.B. ein "Service Level Agreement (SLA)" als fester Bestandteil des Dienstes DI . Die Abspeicherung dieser Dienstattribute in das Dienstat¬ tribute-Programmmodul D-PM erfolgt vorzugsweise durch den Ad¬ ministrator bzw. Operator der Middleware MW. Es ist alterna- tiv aber auch möglich, dass die Dienstattribute von einem anderen Server oder Computer mittels eines auf diesem gespeicherten Softwareprogramm automatisch in das Dienstattribute- Programmmodul D-PM gespeichert werden. Mit den Dienstattributen und den Informationen zur Priorisierung der Middleware-Dienste ermittelt das Berechnung- Programmmodul B-PM nun die Startreihenfolge der Middleware- Komponenten. Das Berechnung-Programmmodul B-PM bildet dabei zusammen mit dem Registrier-Programmmodul R-PM und dem
Dienstattribute-Programmmodul D-PM eine datenverarbeitende Funktionseinheit und erstellt dabei auf der Basis der genann¬ ten Inputparameter eine Berechnungsvorschrift, mit der die Startreihenfolge berechnet wird. Die Implementierung der Be¬ rechnungsvorschrift erhält als Inputparameter die Prioritäten und die Werte solcher Variablen, die feste Eigenschaften der Dienste (Dienstattribute) kodieren, z.B. Höhe einer Strafe bei SLA-Verletzung . Daraus berechnet sie eine Startreihenfol- ge der Middleware-Komponenten, woraus sich dann letztendlich eine Reihenfolge ergibt, in der die Dienste der Middleware wieder zur Verfügung stehen.
Die Berechnung der Startreihenfolge erfolgt dabei vorzugswei- se einmal, nachdem sich alle Anwendungen AW bei der Middlewa¬ re registriert haben. Die Berechnungsvorschrift ist vorzugs¬ weise eine parametrierbare Vorschrift, bei der für die Be¬ rechnung der Startreihenfolge die Inputparameter gewichtet werden. Diese Gewichtung der Inputparameter der Berechnungs- Vorschrift wird vorzugsweise vom Administrator bzw. Operator der Middleware vorgenommen. Zu diesem Zweck bietet das Berechnung-Programmmodul B-PM eine Möglichkeit in Form von Ein¬ gabemittel, die vorzugsweise als Software ausgestaltet sind und wie die Middleware-Komponenten in der FIGUR 1 nicht ex- plizit dargestellt sind, zur Kommunikation mit dem Administ¬ rator bzw. Operator.
Um die Startreihenfolge immer den gegebenen Bedingungen anzupassen, ist es von Vorteil, wenn die Startreihenfolge zum Starten der Middleware-Komponenten dynamisch berechnet wird. Darüber hinaus wird die Startreihenfolge zum Starten der Middleware-Komponenten immer dann neu berechnet, wenn sich eine neue Anwendung bei der Middleware MW registriert oder sich eine Anwendung aus dem Middleware MW abmeldet. Ist die Startreihenfolge in dieser Weise von dem Berechnung-Pro¬ grammmodul B-PM berechnet worden, so wird von dem Berechnung- Programmmodul B-PM als Output ein Steuerbefehl an ein auf bzw. in dem zweiten Server SV2 implementiertes Start-Pro- grammmodul S-PM, das in die Middleware MW integriert ist, adressiert, mit dem das Start-Programmmodul S-PM das Starten der Komponenten der Middleware MW auf dem zweiten Server SV2 veranlasst. Das Start-Programmmodul S-PM, das mit dem Berech- nung-Programmmodul B-PM serverübergreifend eine ablaufsteu¬ ernde Funktionseinheit bildet, ist so ausgestaltet, dass die dienstspezifischen Middleware-Komponenten entsprechend der berechneten Startreihenfolge gestartet werden. Bei dem Start- Programmmodul S-PM handelt es sich somit um ein Programmodul, das die Middleware-Dienste in der berechneten Reihenfolge beim Wiederanlauf der Middleware MW effektiv startet.
Zusätzlich als bevorzugte Ausgestaltung (optionales Feature) wird die von dem Berechnung-Programmmodul B-PM berechnete Startreihenfolge zur Aktualisierung des Berechnungsergebnis¬ ses für den Zugriff zumindest bei einem von späteren Wiederanläufen der Middleware MW und dem späteren Herunterfahren und Neustarten der Middleware MW in einem ersten Speicher- Programmmodul SP1-PM gespeichert, das dazu eingabeseitig dem Berechnung-Programmmodul B-PM zugeordnet ist.
Darüber hinaus kann die Berechnung außer von den festen Eigenschaften der Anwendungen, den Priorisierungen und der Gewichtung des Administrators zusätzlich von analysierten
Monitoring-Daten abhängen.
Um die Berechnung der Startreihenfolge von Middleware-Kompo¬ nenten in dem Berechnung-Programmmodul B-PM deshalb noch wei¬ ter zu optimieren, ist in der Middleware MW ein Analyse- Programmmodul A-PM zum Analysieren von Monitoring-Daten vorhanden .
Dieses Analyse-Programmodul A-PM führt Messungen bezüglich der Dienstnutzung durch die Anwendungen, der Bedingungen durchgeführter Wiederanläufe der Middleware (z.B. gewählte Startreihenfolge) und deren Ergebnisse (z.B. in Bezug auf Wiederanlaufzeiten) durch. Weiterhin können optional auch angefallene Kosten durch Verletzungen von SLAs eingegeben (durch den Administrator oder durch ein betriebswirtschaftliches System, z.B. einen weite¬ ren Server bzw. Computer) und gespeichert werden.
Es analysiert die Messungen der Dienstnutzung und der durch SLA Verletzungen entstandenen Kosten. Die Ergebnisse der Analyse werden zusätzlich zu den oben beschriebenen Inputparame- tern an die Berechnungsvorschrift in dem Berechnung-Programm- modul B-PM übergeben. Durch die Analyse von vergangenen Wiederanläufen wird also die Berechnungsvorschrift in Bezug auf ihren Erfolg optimiert. In diesem Fall handelt es sich um ei¬ ne "lernende Berechnungsvorschrift". Auch in diesem Fall ist es wiederum möglich, dass der Administrator bzw. Operator auf die Gewichtung der verschiedenen Inputparameter innerhalb der Berechnungsvorschrift Einfluss nehmen kann.
Damit die ganzen Monitoring-Daten laufend für das Analyse- Programmodul A-PM zur Verfügung stehen sind in der Middleware MW ein oder mehrere Speicher-Programmodule zur Speichung von Monitoring-Daten vorhanden.
Das Analyse-Programmmodul A-PM ist dazu ausgabeseitig dem Be¬ rechnung-Programmmodul B-PM zur Bildung der datenverarbeiten- den Funktionseinheit derart zugeordnet, dass das Berechnung- Programmmodul B-PM die Startreihenfolge zum Starten der Midd- leware-Komponenten zusätzlich auf der Basis der analysierten Monitoring-Daten berechnet, wobei die Monitoring-Daten im Sinne der "lernenden Berechnungsvorschrift" entsprechende Messwerte zum Herstellen eines Zusammenhangs zwischen den An¬ wendungen bzw. Anwendungsszenarien und dem Erfolg der Berechnungsvorschrift beinhalten. Die Monitoring-Daten bzw. die entsprechenden Messwerte ergeben sich dabei aus vorausgegangenen Wiederanläufen der Middleware MW und dem Herunterfahren und Neustarten der Middleware MW und sind in einem zweiten
Speicher-Programmmodul SP2-PM, das eingabeseitig dem Analyse- Programmmodul A-PM zugeordnet ist, abgespeichert. Neben den Monitoring-Daten, die im Sinne der "lernenden Berechnungsvorschrift" entsprechende Messwerte umfassen, können auch weitere Daten zur Optimierung der Berechnung der Startreihenfolge der Middleware-Komponenten herangezogen werden. Solche Daten können z.B. betriebswirtschaftliche Monitoring- Daten sein, die in einem dritten Speicher-Programmmodul SP3- PM gespeichert sind. Das dritte Speicher-Programmmodul SP3-PM ist dabei wie das zweite Speicher-Programmmodul SP2-PM einga- beseitig dem Analyse-Programmmodul A-PM zugeordnet. Betriebs- wirtschaftliche Monitoring-Daten sind z.B. Daten, die die
Kosten durch eine "Service Level Agreement"-Verletzung angeben. Diese Daten werden vorzugsweise vom Administrator bzw. Operator der Middleware in das dritte Speicher-Programmmodul SP3-PM eingegeben. Es ist alternativ aber auch möglich, dass diese Daten von einem anderen Server oder Computer mittels eines auf diesem gespeicherten Softwareprogramm automatisch in das dritte Speicher-Programmmodul SP3-PM gespeichert wer¬ den . Auf bzw. in dem ersten Server SV1 sind neben dem Registrier- Programmmodul R-PM und dem Berechnung-Programmmodul B-PM auch vorzugsweise das Dienstattribute-Programmmodul D-PM und die Speicher-Programmmodule SP1-PM, SP2-PM, SP3-PM implementiert. Insgesamt zeichnen sich die beiden vorstehend beschriebenen Server-basierten Middleware-Konzeptionen dadurch aus, dass jede Konzeption dynamisch die priorisierten Anforderungen der registrierten oder zu registrierenden Anwendungen bezüglich der benötigten Dienste der Middleware zur Ausübung ihrer Ba- sisfunktionalität berücksichtigt und dabei optional
Monitoring-Daten einbezieht, um den Wiederanlauf der Middle¬ ware in Bezug auf minimale Ausfallzeiten der Basisfunktiona¬ lität der gerade registrierten Anwendungen zu optimieren. Dadurch ist es überhaupt erst möglich, dass beispielsweise
"Service Level Agreements (SLAs)" der Anwendungen eingehalten werden und hierfür nur ein geringer Aufwand an Hardware und anderen teuren Maßnahmen für die Middleware erforderlich ist.

Claims

Patentansprüche
1. Verfahren zur Steuerung von Diensten (DI, DI1...DI9) in einer Middleware (MW) für eine vereinfachte Kommunikation zwi- sehen auf autonomen Rechnern verteilten, bei der Middleware (MW) registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) technischer Systeme - insbesondere "Supervisory Control and Data Acquisition (SCADA) "-Anwendung und eCar- Anwendung in einem Verbund zur Bereitstellung und zum Ver- brauch regenerativer Energien, in dem sowohl Energieanbieter als auch Energieverbraucher zusammengeschlossen sind -, bei dem mit dienstspezifischen Middleware-Komponenten der Middleware (MW) die vereinfachte Kommunikation der Anwendungen (AW, AW1...AW4) ausgeführt wird,
dadurch gekennzeichnet, dass
zur Steuerung der Dienste (DI, DI1...DI9) für die vereinfachte Kommunikation
(a) die registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) jeweils für anwendungsbezogene Basisfunktiona- litäten benötigte Dienste (Dil, DI5; Dil, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; Dil, DI3, DI5; DI6, DI7, DI9) der Middleware (MW) priorisieren,
(b) mit einer auf der Basis der Priorisierung der Middleware- Dienste (Dil, DI5; Dil, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; Dil, DI3, DI5; DI6, DI7, DI9) und Dienstattributen als Input- parameter erstellten Berechnungsvorschrift eine Startreihenfolge zum Starten der Middleware-Komponenten berechnet wird, insbesondere einmal nachdem sich alle Anwendungen (AW,
AW1...AW4) registriert haben,
(c) die dienstspezifischen Middleware-Komponenten entsprechend der berechneten Startreihenfolge gestartet werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
die Berechnungsvorschrift als parametrierbare Vorschrift aus¬ geführt wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, d a s s
für die Berechnung der Startreihenfolge die Inputparameter gewichtet werden.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass
die Startreihenfolge zum Starten der Middleware-Komponenten dynamisch berechnet wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass
wenn sich eine neue Anwendung (AW) bei der Middleware (MW) registriert oder sich eine Anwendung (AW) aus der Middleware (MW) abmeldet, die Startreihenfolge zum Starten der Middlewa¬ re-Komponenten neu berechnet wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass
die berechnete Startreihenfolge zur Aktualisierung des Ergeb¬ nisses der Berechnung für den Zugriff zumindest bei einem von späteren Wiederanläufen der Middleware (MW) und dem späteren Herunterfahren und Neustarten der Middleware (MW) gespeichert wird .
7. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass
die Gewichtung der Inputparameter der Berechnungsvorschrift vom Administrator/Operator der Middleware (MW) vorgenommen wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass
die Startreihenfolge zum Starten der Middleware-Komponenten auf der Basis von analysierten Monitoring-Daten zumindest aus einem von vorausgegangenen Wiederanläufen der Middleware (MW) und dem Herunterfahren und Neustarten der Middleware (MW) berechnet wird, die im Sinne einer "lernenden Berechnungsvor- schrift" entsprechende Messwerte zum Herstellen eines Zusam¬ menhangs zwischen Anwendungen/Anwendungsszenarien und Erfolg der Berechnungsvorschrift beinhalten.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass
die Startreihenfolge zum Starten der Middleware-Komponenten auf der Basis von analysierten betriebswirtschaftlichen
Monitoring-Daten, insbesondere Kosten durch SLA-Verletzung, berechnet wird.
10. Serverarchitektur (SVA) zur Steuerung von Diensten (DI, DI1...DI9) in einer Middleware (MW) für eine vereinfachte Kom¬ munikation zwischen auf autonomen Rechnern verteilten, bei der Middleware (MW) registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) technischer Systeme- insbesondere "Supervisory Control and Data Acquisition (SCADA) "-Anwendung und eCar-Anwendung in einem Verbund zur Bereitstellung und zum Verbrauch regenerativer Energien, in dem sowohl Energie- anbieter als auch Energieverbraucher zusammengeschlossen sind -, die der Middleware (MW) zugeordnet ist, die mit dienstspe¬ zifischen Middleware-Komponenten die vereinfachte Kommunikation der Anwendungen (AW, AW1...AW4) ausführt,
gekennzeichnet zur Steuerung der Dienste (DI, DI1...DI9) für die vereinfachte Kommunikation durch
(a) ein Registrier-Programmmodul (R-PM) zum Speichern und Ausgeben von durch die registrierten oder zu registrierenden Anwendungen (AW, AW1...AW4) jeweils für anwendungsbezogene Ba¬ sisfunktionalitäten benötigten und priorisierten Diensten (Dil, DI5; Dil, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; Dil, DI3, DI5; DI6, DI7, DI9) der Middleware (MW),
(b) ein Berechnung-Programmmodul (B-PM) zum Berechnen einer Startreihenfolge zum Starten der dienstspezifischen Middleware-Komponenten, das eingabeseitig mit dem Registrier-Pro- grammmodul (R-PM) und einem Dienstattribute-Programmmodul (D- PM) eine datenverarbeitende Funktionseinheit bildet und der¬ art ausgestaltet ist, dass mit einer auf der Basis der
Priorisierung der Middleware-Dienste (Dil, DI5; Dil, DI7, DI8; DI3, DI7, DI8 : DI2, DI4; Dil, DI3, DI5; DI6, DI7, DI9) und Dienstattributen als Inputparameter erstellten Berechnungsvorschrift eine Startreihenfolge zum Starten der Middle¬ ware-Komponenten berechnet wird, insbesondere einmal nachdem sich alle Anwendungen (AW, AW1...AW4) registriert haben,
(c) ein Start-Programmmodul (S-PM) , das mit dem Berechnung- Programmmodul (B-PM) eine ablaufsteuernde Funktionseinheit bildet und derart ausgestaltet ist, dass die dienstspezifi¬ schen Middleware-Komponenten entsprechend der berechneten Startreihenfolge gestartet werden.
11. Serverarchitektur (SVA) nach Anspruch 10, dadurch gekennzeichnet, dass
die Berechnungsvorschrift parametrierbar ist.
12. Serverarchitektur (SVA) nach Anspruch 11, dadurch gekennzeichnet, dass
die aus dem Berechnung-Programmmodul (B-PM) mit dem Regist- rier-Programmmodul (R-PM) und dem Dienstattribute- Programmmodul (D-PM) gebildete datenverarbeitende Funktions¬ einheit derart ausgestaltet ist, dass für die Berechnung der Startreihenfolge die Inputparameter gewichtet werden.
13. Serverarchitektur (SVA) nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, dass
die aus dem Berechnung-Programmmodul (B-PM) mit dem Regist- rier-Programmmodul (R-PM) und dem Dienstattribute-Programmmodul (D-PM) gebildete datenverarbeitende Funktionseinheit derart ausgestaltet ist, dass die Startreihenfolge zum Star- ten der Middleware-Komponenten dynamisch berechnet wird.
14. Serverarchitektur (SVA) nach einem der Ansprüche 10 bis 13, dadurch gekennzeichnet, dass
die aus dem Berechnung-Programmmodul (B-PM) mit dem Regist- rier-Programmmodul (R-PM) und dem Dienstattribute-Programmmodul (D-PM) gebildete datenverarbeitende Funktionseinheit derart ausgestaltet ist, dass wenn sich eine neue Anwendung (AW) bei der Middleware (MW) registriert oder sich eine An- wendung (AW) aus der Middleware (MW) abmeldet, die Startrei¬ henfolge zum Starten der Middleware-Komponenten neu berechnet wird .
15. Serverarchitektur (SVA) nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, dass
ein erstes Speicher-Programmmodul (SP1-PM) vorhanden ist, das die berechnete Startreihenfolge zur Aktualisierung des Ergeb¬ nisses der Berechnung für den Zugriff zumindest bei einem von späteren Wiederanläufen der Middleware (MW) und dem späteren Herunterfahren und Neustarten der Middleware (MW) speichert.
16. Serverarchitektur (SVA) nach Anspruch 12, dadurch gekennzeichnet, dass
das Berechnung-Programmmodul (B-PM) Eingabemittel aufweist, über die vom Administrator/Operator der Middleware (MW) die Gewichtung der Inputparameter der Berechnungsvorschrift vorgenommen wird.
17. Serverarchitektur () nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, dass
ein Analyse-Programmmodul (A-PM) zum Analysieren von
Monitoring-Daten,
( i ) dem eingabeseitig ein zweites Speicher-Programmmodul (SP2-PM) zur Abspeicherung von Monitoring-Daten zumindest aus einem von vorausgegangenen Wiederanläufen der Middleware und dem Herunterfahren und Neustarten der Middleware (MW) zugeordnet ist, ausgabeseitig dem Berechnung-Programmmodul (B-PM) zur Bildung der datenverarbeitenden Funktionseinheit derart zugeordnet ist, dass das Berechnung-Programmmodul (B-PM) die Startreihenfolge zum Starten der Middleware-Komponenten zusätzlich auf der Basis der analysierten Monitoring-Daten berechnet, die im Sinne einer "lernenden Berechnungsvorschrift" entsprechende Messwerte zum Herstellen eines Zusammenhangs zwischen Anwendungen/Anwendungsszenarien und Erfolg der Berechnungsvorschrift beinhalten und/oder
( ii ) dem eingabeseitig ein drittes Speicher-Programmmodul (SP3-PM) zur Abspeicherung von betriebswirtschaftlichen Monitoring-Daten, insbesondere Kosten durch SLA-Verletzung, zugeordnet ist, die insbesondere vom Administrator/Operator der Middleware (MW) in das Speicher-Programmmodul () abgelegt werden, ausgabeseitig dem Berechnung-Programmmodul (B-PM) zur Bildung der datenverarbeitenden Funktionseinheit derart zugeordnet ist, dass das Berechnung-Programmmodul (B-PM) die Startreihenfolge zum Starten der Middleware-Komponenten zusätzlich auf der Basis der analysierten Monitoring-Daten berechnet .
18. Serverarchitektur (SVA) nach einem der Ansprüche 10 bis 17, dadurch gekennzeichnet, dass
in dieser die Middleware (MW) vollumfänglich integriert ist.
19. Serverarchitektur (SVA) nach einem der Ansprüche 10 bis 17, dadurch gekennzeichnet, dass
diese zweiteilig, in einen ersten Server (SV1) und einen zweiten Server (SV2), unterteilt ist, wobei der erste Server (SV1) das Registrier-Programmmodul (R-PM) , das Dienstattribu- te-Programmmodul (D-PM) , die Speicher-Programmmodule (SP1-PM, SP2-PM, SP3-PM) und das Berechnung-Programmmodul (B-PM) ent¬ hält, welche nicht zur Middleware (MW) gehören, während der zweite Server (SV2) das Start-Programmmodul (S-PM) enthält, welches in die Middleware (MW) integriert ist.
PCT/EP2015/060276 2014-08-04 2015-05-11 Verfahren und serverarchitektur zur steuerung von diensten in einer middleware für eine vereinfachte kommunikation zwischen auf autonomen rechnern verteilten, bei der middleware registrierten oder zu registrierenden anwendungen technischer systeme WO2016020076A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014215317.4 2014-08-04
DE102014215317.4A DE102014215317A1 (de) 2014-08-04 2014-08-04 Verfahren und Serverarchitektur zur Steuerung von Diensten in einer Middleware für eine vereinfachte Kommunikation zwischen auf autonomen Rechnern verteilten, bei der Middleware registrierten oder zu registrierenden Anwendungen technischer Systeme

Publications (1)

Publication Number Publication Date
WO2016020076A1 true WO2016020076A1 (de) 2016-02-11

Family

ID=53059122

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/060276 WO2016020076A1 (de) 2014-08-04 2015-05-11 Verfahren und serverarchitektur zur steuerung von diensten in einer middleware für eine vereinfachte kommunikation zwischen auf autonomen rechnern verteilten, bei der middleware registrierten oder zu registrierenden anwendungen technischer systeme

Country Status (2)

Country Link
DE (1) DE102014215317A1 (de)
WO (1) WO2016020076A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007101590A1 (de) * 2006-03-03 2007-09-13 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur erstellung eines optimierten ablaufplans für ein zeitgesteuertes verteiltes rechnersystem
US7389410B1 (en) * 2005-07-13 2008-06-17 Symantec Corporation Automatically deriving order of initialization for computing services across multiple computing systems
WO2014039921A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Infrastructure for providing cloud services

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7389410B1 (en) * 2005-07-13 2008-06-17 Symantec Corporation Automatically deriving order of initialization for computing services across multiple computing systems
WO2007101590A1 (de) * 2006-03-03 2007-09-13 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur erstellung eines optimierten ablaufplans für ein zeitgesteuertes verteiltes rechnersystem
WO2014039921A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Infrastructure for providing cloud services

Also Published As

Publication number Publication date
DE102014215317A1 (de) 2016-02-04

Similar Documents

Publication Publication Date Title
DE102012003242A1 (de) Verfahren zum ausfallsicheren Betreiben eines Prozesssteuersystems mit redundanten Steuereinrichtungen
DE102018116554A1 (de) Computersystem-Infrastruktur sowie Verfahren zum Hosten einer Anwendungssoftware
EP1634176B1 (de) Clusteranordnung für dezentrale lastverteilung
DE102011107646A1 (de) Verfahren und System zur dynamischen Verteilung von Programmfunktionen in verteilten Steuerungssystemen
WO2007101485A1 (de) Verfahren zur übertragung von programmaktualisierungen für programmgesteuerte einrichtungen in einem kommunikationsnetz
EP3855259B1 (de) Verfahren zur kompatibilitätsprüfung von funktionsmodulen
WO2016020076A1 (de) Verfahren und serverarchitektur zur steuerung von diensten in einer middleware für eine vereinfachte kommunikation zwischen auf autonomen rechnern verteilten, bei der middleware registrierten oder zu registrierenden anwendungen technischer systeme
WO1990002996A1 (de) Betriebsprogramm für eine datenverarbeitungsanlage
AT523586A1 (de) Verfahren zur zumindest teilweise dezentralen Berechnung des Gesundheitszustandes von mindestens einer Windkraftanlage
DE112013006756T5 (de) Kommunikations-, Steuervorrichtung und Programm
DE102004011201B4 (de) Verfahren zum Management und zur Überwachung des Betriebs mehrerer in wenigstens ein Kommunikationsnetz eingebundener verteilter Hard- und/oder Softwaresysteme sowie System zur Durchführung des Verfahrens
WO2002071223A1 (de) Fehlertolerante rechneranordnung und verfahren zum betrieb einer derartigen anordnung
EP1289095A1 (de) Elektroenergieregelungssystem und Verfahren zum Einstellen elektrischer Zustandsgrössen und/oder Parameter in einer Stromleitung
EP4104422A1 (de) Integrieren einer maschine in ein bestehendes distributed ledger netzwerk
DE102009008033B3 (de) Versorgung von energietechnischen Objekten mit Energie verschiedener Energiearten
LU101163B1 (de) Verfahren und Vorrichtungen für eine Lastzuweisung und Überwachung für eine zuzuweisende versorgungssicherheitskritische Ressource in einem Netzwerk
DE10123822A1 (de) Einrichtung zur Verwaltung einer Dienstverbindung zwischen einem Clientprozess mit einer Single-Thread-Bibliothek und einem Serverprozess
EP3942766A1 (de) Verfahren und vorrichtungen für eine lastzuweisung und überwachung für eine zuzuweisende versorgungssicherheitskritische ressource in einem netzwerk
DE60315264T2 (de) Durch timebox angesteuertes scheduling von softwarekomponenten in hard-echtzeitsystemen
WO2008012301A2 (de) Verfahren zum ausführen eines dienstes in einem dezentralen datennetz
DE102016000213A1 (de) Steuersystem mit Funktion zur Optimierung der Steuersoftware einer numerischen Steuerung gemäß einem Bearbeitungsprogramm
EP2178267B1 (de) Verfahren zur Ausführung von Diensten in einem dezentralen Datennetz
EP2010974B1 (de) Engineeringsystem und verfahren zur projektierung eines automatisierungssystems
EP2597570B1 (de) Clusteranordnung für Dezentrale Lastverteilung
DE102004017698A1 (de) SCADA-System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15721251

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15721251

Country of ref document: EP

Kind code of ref document: A1