-
Die vorliegende Erfindung betrifft ein Verfahren zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Hinlänglich bekannt sind Verfahren zum Verteilen oder Aktualisieren von Software (SW) über eine - mitunter als „Luftschnittstelle“ (over the air, OTA) bezeichnete - drahtlose Datenschnittstelle. Gattungsmäßige Verfahren finden Anwendung sowohl auf Anwendungssoftware (SOTA) als auch auf eingebettete Systemsoftware (firmware, FOTA).
-
Nach dem Stand der Technik werden FOTA und SOTA beispielsweise zur Aktualisierung der Steuergeräte (electronic control units, ECUs) vernetzter Kraftfahrzeuge und Landmaschinen eingesetzt. Zur telematischen Verbindung zwischen dem die Steuergeräte koppelnden Bussystem und dem Internet (der sinnbildlichen „Cloud“) dient hierbei typischerweise eine Fahrzeugverbindungsschnittstelle (vehicle connectivity gateway, VCG).
-
Jenseits der Wartung und Fehlerbereinigung bereits installierter Software lässt sich der Funktionsumfang fahrzeuginterner Steuergeräte auf diesem Wege um Leistungsmerkmale (features) erweitern, welche vorhandene Sensoren und Aktoren für neue Anwendungsfälle nutzen. Entsprechende Applikationen können durch Hersteller oder Erstausrüster (original equipment manufacturer, OEM) einer Landmaschine - etwa mittels eines Entwicklungskits (development kit) - erstellt und auf einer digitalen Vertriebsplattform in der Cloud angeboten werden. Als denkbare Erweiterungen kommen zum Beispiel fortgeschrittene Telemetrie- oder agrartechnische Spezialfunktionen wie die gezielte Unkrautbekämpfung in Betracht.
-
DE102015203766A1 offenbart ein Teilsystem für ein Fahrzeug mit einem über eine Luftschnittstelle mit einem Gerätemanagement-Server des Backends verbundenen Gerätemanagement-Client zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, einem über die Luftschnittstelle mit einem Download-Server des Backends verbundenen Download-Client zum Herunterladen eines Softwareupdates von dem Backend in das Fahrzeug, mit dem Download-Client verbundenen Softwareupdate-Clients zum Anwenden des Softwareupdates und einen mit dem Download-Client und den Softwareupdate-Clients verbundenen Fahrzeugupdate-Client zum Koordinieren des Softwareupdates.
-
Im Zuge einer unabhängigen Entwicklung findet die im Rechenzentrumsbetrieb bereits seit Längerem übliche Container- oder Betriebssystem-Virtualisierung in jüngerer Zeit vermehrt Eingang in die Praxis der eingebetteten Systeme (embedded systems). Diese Methode erlaubt es, mehrere Instanzen eines Betriebssystems als sogenannte Gäste (guests) isoliert voneinander auf einem Wirtssystem (host) zu betreiben. Auf diese Weise kann der Wirt jeder innerhalb eines solchen Containers gekapselten Anwendung (application, app) eine vollständige Laufzeitumgebung zur Verfügung stellen, die beispielsweise dynamische Bibliotheken der vom jeweiligen Entwickler genutzten Programmiersprache wie Java, C oder Python umfassen mag. Im Gegensatz zur Nutzung eines Hypervisors erlegt diese „leichtgewichtige“ Form der Virtualisierung den Gästen zwar einige Einschränkungen auf, birgt jedoch den Vorteil, dass alle Container den Kern des nativen Betriebssystems - typischerweise Linux, BSD, Solaris oder ein anderes Unix-ähnliches System - gemeinsam nutzen. Die Nutzung von Containern schont somit die knappen Betriebsmittel eingebetteter Systeme.
-
Logische Berührungspunkte in einem solchen System werden gemeinhin als Softwareschnittstellen oder softwareseitige Datenschnittstellen bezeichnet und ermöglichen den Austausch von Befehlen sowie Daten zwischen verschiedenen Prozessen und Softwarekomponenten. Neben nur zur Kommunikation benutzten, datenorientierte Schnittstellen sind funktionale Schnittstellen bekannt, welche die primär beteiligten Softwarekomponenten synchronisieren oder unterstützen. Manche Schnittstellen ermöglichen gar eine Interprozesskommunikation (interprocess communication, IPC) in verteilten Systemen. Dem Fachmann bekannte IPC-Schnittstellen dieser Gattung umfassen beispielsweise RPC, DCOM, RMI oder Nachrichtenbroker wie CORBA oder den in der Telemetrie genutzten MQTT.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug dieser Lösung liegt im verbesserten Schnittstellenhandling in sich dynamisch verhaltenden Systemen, sodass eine Ressourcensteuerung und die Gewährleistung eines erwarteten Systemverhalten (z. B. hinsichtlich funktionaler Regelstrecken und des damit verbundenen Regelverhaltens) auch im Hinblick auf funktionale Sicherheit erfolgt.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass die zeitliche Zuteilung des Zugriffs von Softwarekomponenten auf Softwareschnittstellen anhand übergeordneter Systemziele optimiert wird. Eine entsprechende Ausführungsform erlaubt beispielsweise die Optimierung und Orchestrierung von Schnittstellenanfragen anhand einer Berechnung von Bandbreitenbedarf (Zugriffen pro Zeiteinheit), Zugriffsdauer, Prioritäten, Echtzeitzielen und Aktualisierungsraten. Dies umfasst auch die Verwaltung von Schnittstellen hinsichtlich deren Arbitrierung und Verfügbarkeit, also die Vermittlung (brokering) zwischen Schnittstellenangebot und Nachfrage. Der geschätzte Bandbreitenbedarf entspricht der Summe aller in den Manifesten der einzelnen Softwarekomponenten definierten Schnittstellenanforderungen und ist auch bezogen auf die Systemmorphologie, bei einer Ventilsteuerung z. B. die Anzahl vorhandener Magnetventile. Es handelt sich bei diesem Bedarf lediglich um eine vorläufige Schätzung insofern, als sie Veränderungen, Nutzerinteraktion und andere Ereignisse zur Laufzeit naturgemäß nicht berücksichtigt. Bei über die Grundfunktionen hinausgehendem Schnittstellenbedarf weiterer optionaler Funktionen wird geprüft, ob dieser unter den geforderten Echtzeitbedingungen erfüllt werden kann. Diese Prüfung erfolgt beispielsweise anhand eines Gütemaßes, das ausgehend vom ursprünglichen Laufzeitverhalten einen gewissen Zeitrasterverlust zulässt.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
- 2 das dynamische Verhalten zweier exemplarischer Softwarekomponenten.
- 3 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.
-
Ausführungsformen der Erfindung
-
Die Begriffe „Services“ und „Schnittstellen“ werden im Folgenden teilweise synonym verwendet, da über gewisse Schnittstellen unter Austausch von Daten entsprechende Services abgewickelt bzw. bereitgestellt werden.
-
Im Rahmen einer erfindungsgemäßen Systemarchitektur für Steuerungsprogramme dient dieses Verfahren der Kommunikation zwischen verschiedenen Softwarekomponenten einschlägiger Systeme. Der hierzu genutzte Nachrichtenbroker verwendet hierzu einschlägige Anwendungsprogrammierschnittstellen (application programming interfaces, APIs) und ist ständig aktiv, soweit das unterliegende Betriebssystem es erlaubt. Der Nachrichtenbroker kann mithilfe unterschiedlicher Technologien implementiert werden, darunter MQTT oder DDS.
-
Der Nachrichtenbroker wird zu diesem Zweck so konfiguriert, dass gegenseitiger Zugriffsschutz gewährleistet ist. Jedem Steuerungsprogramm ist hierzu beispielsweise ein eigener Namensraum zugewiesen. Der Nachrichtenbroker besitzt einen generischen Teil sowie an das jeweilige Zielsystem angepasste Konfigurationen hinsichtlich Sichtbarkeit etc. Beispielsweise können hierzu beim Installationsprozess Teile des Manifests in einer Registry abgelegt werden, auf deren Basis in einem gesonderten Teil des Installationsvorgangs eine Konfiguration des Nachrichtenbrokers online auf einer ECU mit und/oder ohne Internet generiert wird. Diese Konfiguration würde im Rahmen einer weiteren Installation oder Veränderung eines Steuerungsprogrammes ständig erneuert, insbesondere bei dessen Deinstallation mit und/oder ohne Internetverbindung.
-
Die Kommunikation zwischen den besagten APIs erfolgt ausschließlich über den Nachrichtenbroker. Dabei lassen sich anhand der Modellierung von Daten und Kontrollfluss drei Arten der Kommunikation unterscheiden. Diese von einer Abstraktionsschicht der Systemarchitektur vorgesehenen Kommunikationstypen und die konkrete Umsetzung der zunächst abstrakt definierten Kommunikation werden durch den Nachrichtenbroker übermittelt. Differenziert werden hierbei Art, Inhalt, Anzahl und Kombinationen von Schnittstellen bzw. deren Services sowie Funktions- und Datensicherheit des Kommunikationskanales. Zudem lässt sich die Kommunikationsart anhand der unterstützten Zugriffsmethoden, Ereignisse (events) und anderweitiger Parameter, z. B. einer Applikationsrate, charakterisieren.
-
1 illustriert ein Verfahren (10) der Zugriffsverwaltung durch einen erfindungsgemäßen Nachrichtenbroker. Den Ausgangspunkt für die folgenden Betrachtungen bildet das Erfordernis einer Softwarekomponente, auf eine bestimmte Softwareschnittstelle zuzugreifen.
-
In einer ersten Phase (Prozess 11) wird anhand der im jeweiligen Manifest definierten Anforderungen an die Softwareschnittstellen die zeitliche Zuteilung der Softwarekomponenten an die Softwareschnittstellen statisch berechnet. Dies kann bereits während der Entwicklung geschehen. Im Manifest der betreffenden Komponente sind hierzu deren Anforderungen an Typ (Klasse), Anzahl (Wertebereich), Reaktionszeiten, Ausführungsmodell (synchron oder asynchron), Diagnose und Protokollierung (logging) sowie Sicherheitsziele spezifiziert. Etwaige Beschränkungen der Ressourcen oder Leistung werden vorher dem Entwickler mitgeteilt; denkbar ist auch eine entsprechende Budgetierung. Die vorgegebene Latenz kann hierbei veränderlich und zum Beispiel von der Geschwindigkeit des Arbeitsprozesses oder der Maschinenfahrgeschwindigkeit usw. abhängig sein.
-
Eine entsprechende Berechnung (11) kann auch während der Installation auf dem Zielsystem erfolgt. Die Daten der Manifeste werden hierzu aggregiert, korreliert, plausibilisiert, analysiert oder anderweitig weiterverarbeitet und angelegt bzw. abgelegt. In diesem Schritt wird festgestellt, falls beispielsweise drei Services - ggf. zum gleichen Zeitpunkt mit den gleichen Güteanforderungen für den ungünstigsten Fall (worst case) - auf dieselbe Schnittstelle zugreifen möchten. Vorzugsweise erfolgt eine rechteorientierte Zugriffssteuerung, die Lese- und Schreibrechte unterscheidet. Das in bzw. durch eine Cloud erstellte, und auch im Steuergerät verfügbare, Gesamtmanifest setzt den Nachrichtenbroker von derartigen Rechten in Kenntnis und erlaubt ein Abonnement von Schnittstellen, das nach deren Benutzung abgerechnet wird (pay per use).
-
Anschließend wird optional anhand von Teilnehmern nach dem Stand der Technik bekannter Busse oder Kommunikationsprotokolle, z.B. von ISOBUS-Teilnehmern wie einer Feldspritze oder sonstiger bekannter Systeme, die Zuordnung von Anforderungen und Ressourcen vorgenommen. Hieraus ergeben sich Bedarfe nach Ressourcenverwaltung, Ressourcenaus- bzw. -belastung, Bandbreite zum Beispiel des ISOBUS-Systems etc.
-
Diese statische Analyse (11) kann in der Regel keine Änderungen zur Laufzeit und deren Rückwirkung auf Funktionen berücksichtigen - zu denken ist etwa an Regelkreise, Rückwirkung des Systems bzw. der Regelstrecke oder Lernfunktionen -, da zum Zeitpunkt der statischen Betrachtung nicht das Laufzeitverhalten der Steuerungsprogramme und ihrer Services abgeschätzt werden kann. 2 verdeutlicht diese Problematik anhand einer ersten zyklischen Botschaft (21) mit hohen Anforderungen an die Einhaltung des Taktes und einer zweiten zyklischen Botschaft (22) mit geringeren Anforderungen an die Antwortzeit. Angesichts des möglichen Konfliktes zwischen den Botschaften (21, 22) wird die zweite Botschaft (22) vorgezogen. Betrachtet man die Abstände zwischen den einzelnen Botschaften (21 bzw. 22), so wird deutlich, dass deren Frequenzen innerhalb der zulässigen Toleranz schwanken.
-
In einer zweiten Phase (Prozess 12) wird daher angesichts des beobachteten und/oder simulierten und/oder prognostizierten Laufzeitverhaltens der Softwarekomponenten deren Zuteilung fortlaufend, beispielsweise nach einem ggf. simulierten oder prognostizierten sogenannten Beobachter-Muster, optimiert. Diese Optimierung (12) der Ressourcenverteilung setzt voraus, dass die durch die Manifeste definierten Anforderungen hinreichende Freiräume bei der Ressourcenbelegung und -auslastung gewähren, z. B. durch die Angabe von Intervallen anstelle fester Werte für Jitter, Rechenraster und Reaktionszeiten. Innerhalb der auf diesem Wege gesetzten Grenzen kann das System die Zuteilung selbstständig zur Laufzeit bestimmen und anpassen.
-
Für eine derartige Optimierung (12) werden zunächst die Freiheitsgrade des Optimierers bestimmt, welche die Grenzen des Lösungsraumes vorgeben. Anhand übergeordneter Systemziele lässt sich nunmehr eine Kostenfunktion definieren. In Betracht kommen beispielsweise Reaktionszeiten, Betriebssicherheit, Verschleiß, Energieverbrauch oder Betriebskosten (die maximale Prozessgeschwindigkeit ergibt sich aus der Abtastrate des Systems und beeinflusst die Arbeitsdauer).
-
Der Optimierungsalgorithmus sucht den solchermaßen abgegrenzten Lösungsraum nach - im Sinne der Kostenfunktion - optimalen Lösungen ab. Abhängig vom Lösungsraum können bestimmte Algorithmen nicht terminieren und somit keine Lösung finden. (In diesem Fall werden Nutzer und Entwickler über die zur Laufzeit erkannte Inkompatibilität der Konfiguration informiert.) Bei Terminierung des Algorithmus liefert dieser ein lokales oder globales Optimum, das eine bestmögliche zeitliche Verteilung der Ressourcenzugriffe angibt.
-
Im Rahmen einer modularen und serviceorientierten Systemarchitektur erfüllt der Nachrichtenbroker weitere Funktionen. Hierzu zählen An- und Abmeldung der Services, welche durch eine Middleware oder von den in Containern betriebenen Steuerungsprogrammen bereitgestellt werden. Dadurch werden Austauschbarkeit, Veränderung und Ersetzung von Services zur Laufzeit ohne Neustart ermöglicht.
-
Auf Seiten des Erzeugers (Senders) und Verbrauchers (Empfängers) der Daten sind hierbei unterschiedliche Gestaltungen denkbar, ohne den Rahmen der Erfindung zu verlassen.
-
Beispielsweise meldet eine Komponente, welche einen Service anbieten möchte, dem Nachrichtenbroker im Wege einer Bekanntgabe (advertising), dass der - durch gewisse Metainformationen beschriebene - neue Service von ihr bereitgestellt werden kann. Der Nachrichtenbroker kann diesen Service dann anderen Komponenten bekannt machen. Im Rahmen eines Anmeldemechanismus werden die dem Manifest entnommenen Metainformationen der Services vom Nachrichtenbroker ausgewertet und die konkrete Kommunikationsinfrastruktur hinsichtlich Nutzdaten (payload), Kanal, Routing-ID etc. für den anbietenden Service initialisiert. Diese Initialisierung schließt eine Prüfung daraufhin ein, ob die betreffende Information gemäß Manifest angeboten werden darf. Der gemäß dem Beobachter-Muster als Subjekt (publisher) fungierende Sender übermittelt die (Nutz-)Daten und stellt damit die Informationen der beworbenen Services auch tatsächlich bereit. Diese werden in einer entsprechenden Registry hinterlegt.
-
Zum Zwecke der Dienstauffindung (discovery) registriert sich jede Komponente, die als Beobachter (subscriber) einen Service gleichsam „abonnieren“ möchte, beim Nachrichtenbroker. Die Komponente erhält Rückmeldung darüber, ob entsprechende Services verfügbar sind, ohne die abonnierte Information selbst zu erhalten. Bestimmte Services sind möglicherweise zwar verfügbar, dürfen von der nachfragenden Komponente jedoch nicht genutzt werden.
-
Bieten mehrere Services oder mehrere Instanzen desselben Service den gleichen Inhalt (topic) an, so kann das beobachtende Steuerprogramm nach der Discovery die für es relevanten Instanzen auswählen. Diese Auswahl kann nach einer im Steuerprogramm selbst implementierten Vorschrift oder einer in dessen Manifest hinterlegten Regel erfolgen, gemäß derer der Nachrichtenbroker die relevante Instanz selbsttätig bestimmt.
-
Ist ein Empfänger nicht auf die Namen einer Information oder eines Service festgelegt, so können durch die Bezeichnung der Inhalte mittels eines geeigneten Platzhalters (wildcard) alle beim Nachrichtenbroker registrierten Services abgerufen werden, auf welche die Abfrage zutrifft. Anhand dieser Trefferliste kann der Empfänger entscheiden, welche Services er abonnieren möchte. Die Ergebnisse einer in diesem Sinne unspezifischen Discovery können für verschiedene Empfänger angesichts verschiedener Zugriffsrechte unterschiedlich ausfallen.
-
Die solchermaßen aufgefundenen Services können nun in Anspruch genommen werden. Hierzu erhält der Empfänger bei jeder Änderung des beobachteten Objektes eine diesbezügliche Meldung (push notification) oder dessen aktuellen Inhalt (push-update notification). Die Meldung, dass neue Daten vorliegen, kann hierbei an Bedingungen geknüpft sein. Diese können äußere Umstände - z. B. zeitliche Aspekte wie die Aktualität des jeweiligen Datums oder der Zustand von Steuerprogramm, Aktor, Sensor oder System - oder die geänderten Daten selbst betreffen, die etwa durch Wertintervalle, statistische oder anderweitige mathematische Funktionen eingeschränkt werden können.
-
In Betracht kommt ebenfalls eine Umsetzung des Beobachter-Musters, bei welcher der Verbraucher gemäß vorgegebenen Regeln selbstständig die Informationen der Services beim Nachrichtenbroker abruft. Hinsichtlich des oben beschriebenen Routingprozesses und der Ausgestaltung des Kommunikationskanals - insbesondere bezüglich der Erstellung und Bekanntgabe der Services - lassen sich dynamisches und statisches Routing unterscheiden, wobei auch Mischformen denkbar sind. Ein statisches Routing kann zum Zeitpunkt der Entwicklung (Routing-ID im Quellcode), Übersetzung (Variable im Quellcode, die bei der Übersetzung definiert wird), Verteilung (offline erstellte Konfigurationsdatei) oder des Urladens (online erstellte Konfigurationsdatei) festgelegt werden. Eine Discovery ist in diesem Fall entbehrlich.
-
Beim dynamischen Routing wird der spezifische Service dem Verbraucher erst zur Laufzeit bekannt gemacht. Im Rahmen der vorangehenden Implementierung ist lediglich eine generische Beschreibung des Service bekannt. Erst nach der Discovery liegt dem Verbraucher eine Routing-ID vor, unter welcher dessen Daten verfügbar sind.
-
Wie 3 verdeutlicht, müssen Erzeuger (31) und Verbraucher (32) bestimmter Inhalte nicht zeitgleich aktiv sein, ein Erzeuger (31) benötigt also nicht zwingend einen aktiven Verbraucher (32) und umgekehrt, da der Broker (30) die vermittelten Informationen zwischenspeichern kann. Gibt beispielsweise ein Erzeuger (31) dem Broker (30) die Bereitstellung des Inhaltes „Drehzahl“ bekannt (41) und quittiert der Broker (30) dies als zulässig (42), so kann der Erzeuger (31) den entsprechenden Service anmelden (43), woraufhin der Broker (30) dem erzeugten Inhalt beispielsweise das MQTT-Topic „Auto\Motor\Drehzahl_l“ zuweist. Eine Discovery (45) zum Thema „Drehzahl“ durch den Verbraucher (32) liefert die Auskunft (46), dass die Drehzahl unter den Topics „Auto\Motor\Drehzahl_I“ sowie „Auto\Motor\Drehzahl_geglaettet“ verfügbar ist. Veröffentlicht (47) der Erzeuger (31) nun beispielsweise unter dem Topic „Auto\Motor\Drehzahl -l“ den Wert 1199 min-1 und abonniert (48) der Verbraucher (32) das Topic „„Auto\Motor\Drehzahl_geglaettet‟, so meldet der Broker (30) letzterem das einschlägige Ereignis „1200 min-1“ (49).
-
Ein solcher asynchroner Nachrichtenaustausch kann unterschiedlichen Regeln folgen, die im Steuerungsprogramm selbst implementiert oder in dessen Manifest definiert sein können. Beispielsweise können Löschung von Nachrichten und Freigabe der durch diese gebundenen Ressourcen nach Überschreiten einer gewissen Anzahl, bei Auslastung des hierzu genutzten Nachrichtenpuffers, Zeitüberschreitung (timeout) oder ausdrücklichem Verwerfen durch den Nutzer, etwa bei einer erneuten Anmeldung, erfolgen. Stellt etwa der Erzeuger (31) nacheinander 40 Datensätze mit jeweils eigenem Zeitstempel im Rahmen eines Service bereit, so kann der Verbraucher (32) diese Daten auch später, nachdem der Erzeuger (31) nicht mehr verfügbar ist, abrufen und wahlweise entsprechend deren Zeitstempel auswerten.
-
Auch die Abmeldung von Softwarekomponenten wird vom Nachrichtenbroker (30) verwaltet und durchgeführt. Je nach Dringlichkeit lassen sich verschiedene Wege der Abmeldung unterscheiden. Ist etwa ein Steuerprogramm wegen Absturz oder aus unbekannten Gründen unvermittelt ausgefallen und der von ihm erbrachte Service nicht mehr verfügbar, ohne dass der Nachrichtenbroker (30) diesen Ausfall vorbereiten konnte, so bedingt diese Lage eine sofortige Abmeldung. Bemerkt der Nachrichtenbroker (30) indes, dass ein Service nicht mehr funktionssicher bereitgestellt wird, so wird dieser Service bzw. das ihn erbringende Steuerprogramm zwangsweise abgemeldet. Ist schließlich ein verwendeter Service nicht mehr aktuell, und ein Steuerprogramm initiiert die Abmeldung des Service, so kann diese Abmeldung planmäßig erfolgen.
-
Abhängig vom auslösenden Ereignis läuft der Abmeldeprozess folgendermaßen ab: Der Nachrichtenbroker (30) steuert die Kommunikation und führt das Routing durch. Erkennt der Nachrichtenbroker (30), dass ein Service nicht mehr verfügbar ist, keine zufriedenstellenden Informationen bereitstellen kann oder in absehbarer Zeit nicht mehr verfügbar sein wird und wann dieser ggfs. wieder verfügbar sein könnte, so werden etwaige betroffene Verbraucher (32) benachrichtigt und entsprechende Maßnahmen eingeleitet. Die sich aus den Maßnahmen ergebenden Eingriffe können verschiedene Dimensionen betreffen. Beispielsweise müssen weitere, abhängige Services planmäßig abgemeldet werden, falls keine Ersatzservices verfügbar sind. Falls ein Ersatzservice verfügbar ist oder verfügbar gemacht werden kann, muss das Routing vom deaktivierten zum ersetzenden Service umgeschaltet werden. Hierbei sind jedoch etwaige Mindestanforderungen der Verbraucher (32) an die Dienstgüte (quality of service, QoS) zu berücksichtigen. Diese Berücksichtigung und die Einleitung weiterer Maßnahmen bei Bedarf obliegen ebenfalls dem Nachrichtenbroker (30).
-
Wird ein Service heruntergefahren oder ist aus anderen Gründen nicht mehr verfügbar, so löscht der Nachrichtenbroker (30) ihn aus der Liste verfügbarer Services in der Registry. Die damit verbundenen Ressourcen und ggf. dynamisch erzeugte Metadaten zur einmaligen Benutzung (one-time use) wie Zertifikate, IDs oder Passwörter verlieren dabei ihre Gültigkeit. Um für andere Softwarekomponenten wieder gleichsam „sichtbar“ zu werden, muss sich der gelöschte Service erneut registrieren und die oben genannten Metadaten beziehen.
-
Alternativ entscheidet jedes Steuerungsprogramm eigenverantwortlich, welche Services und welche Service-Instanzen es nutzt. Das Routing ergibt sich bei einer entsprechenden Ausführungsform zwangsläufig aus dieser Entscheidung. Der Erzeuger (31), welcher einen Service abmelden möchte, benachrichtigt den Nachrichtenbroker (30) mit einem Signal, welches die Abmeldung des Service in einer bestimmten Zeit anzeigt. Dieser wiederum benachrichtigt alle Steuerungsprogramme, die als Verbraucher (32) auftreten, über die anstehende Abmeldung des Service und versetzt sie in die Lage, sich bei Bedarf für einen geeigneten Ersatzservice aus der Registry anzumelden und somit ein neues Routing aufzubauen. Sollte kein Ersatzservice zur Verfügung stehen und erkennt der Nachrichtenbroker (30) anhand der aggregierten Information der Manifeste, dass ein Steuerungsprogramm daher nicht mehr lauffähig ist, so leitet er mittels der zuständigen Systemkomponenten eine geordnete Beendigung des betreffenden Steuerungsprogrammes ein.
-
Um die Informationssicherheit der Services hinsichtlich Datenintegrität, -authentizität, -sichtbarkeit und -lesbarkeit zu gewährleisten und eine Überlastung der Komponenten durch für sie irrelevante Bekanntgaben zu vermeiden, kann deren Sichtbarkeit auf Basis einer anhand der Manifeste erstellten Positivliste (whitelist) gesteuert werden. Alternativ kann beispielsweise eine Negativliste (blacklist) ausgeschlossener Services verwendet werden. Zur Verbesserung der Informationssicherheit kommt weiterhin eine Transportverschlüsselung der Datenübertragung zwischen Nachrichtenbroker (30) und Softwarekomponenten in Betracht. Die ausgetauschten Inhalte können unabhängig von der Transportschicht ihrerseits verschlüsselt sein.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102015203766 A1 [0005]
