DE102021124714A1

DE102021124714A1 - Verfahren und system bewegen einer logik eines service zwischen ecosystemen

Info

Publication number: DE102021124714A1
Application number: DE102021124714.4A
Authority: DE
Inventors: Mohamad Chamas; Adnan Bekan; Graham Smethurst
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2021-09-23
Filing date: 2021-09-23
Publication date: 2023-03-23

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren und System zum Bewegen einer Logik eines Service zwischen einem ersten Ecosystem (1) und einem zweiten Ecosystem (2) in einem Netzwerk (4) von Ecosystemen. Jedes Ecosystem umfasst mehrere technische Subsysteme mit jeweils eigener Logik und eigener Datenbasis. Das Verfahren umfasst die Schritte:- Empfangen (S1) einer Anfrage (18) bezüglich eines ersten Service (5) des ersten Ecosystems (1),- Identifizieren (S2) eines zweiten Ecosystems (2) in dem Netzwerk (4), welches Anforderungen des ersten Service (5) erfüllt,- Bewegen (S3; S5) einer ersten Logik (6) des ersten Service (5) des ersten Ecosystems (1) in das zweite Ecosystem (2) oder einer zweiten Logik (10) eines zweiten Service (9) des zweiten Ecosystems (2) in das erste Ecosystem (1).Die erste Logik (6) des ersten Service (5) und/oder die zweite Logik (10) des zweiten Service (9) verwendet ein dem ersten Ecosystem (1) und dem zweiten Ecosystem (2) gemeinsames Datenmodell (13), welches über wenigstens das erste Ecosystem (1) und das zweite Ecosystem (2) verteilt ist und eine Datennachricht auf OSI-Layer 5-7 mit zumindest den Attributen Header mit Feld für Nachricht-ID, Payload mit Feldern für Zeitstempel, Beschreibungszeile, Wert, Einheit, Datentyp und QoS-Attribut umfasst.Das System umfasst eine Quality-of-Service-Koordinationseinheit mit einer Empfangseinheit (14), einer Identifikationseinheit (15) und einer Bewegungseinheit (16) zur Ausführung der Schritte des Verfahrens. Die Erfindung betrifft auch ein Computerprogramm und einen computerlesbaren Datenspeicher.

Description

Die Erfindung betrifft ein computerimplementiertes Verfahren zum Bewegen einer Logik eines Service zwischen Ecosystemen. Die Erfindung betrifft zudem ein System zur zum Bewegen einer Logik eines Service zwischen Ecosystemen. Die Erfindung betrifft ferner ein Computerprogramm und einen computerlesbaren Datenträger.
Mit zunehmender Vernetzung der Mobilität ist es vermehrt von Interesse, Daten über unterschiedliche miteinander vernetzte Instanzen, Plattformen oder Systemumgebungen, hier Ecosysteme genannt, die jeweils mehrere technische Subsysteme mit eigener Logik und eigener Datenbasis umfassen können, auszutauschen. Aufgrund unterschiedlicher Technologien, auf denen die einzelnen Ecosysteme und/oder Subsysteme aufbauen, ist es bisher nicht möglich, Logiken von Services zwischen Ecosystemen unterschiedlicher Technologien flexibel zu verlagern. Eine solche Verlagerung kann wünschenswert sein, um etwa einen Service eines Ecosystems bzw. dessen Logik auf ein anderes Ecosystem auszulagern, um Ressourcen des einen Ecosystems zu schonen (Relokalisierung des Service). Auch könnte ein defekter Service eines Ecosystems durch einen Service eines anderen Ecosystems, welcher die gleiche Aufgabe wie der defekte Service erfüllen kann, bzw. dessen Logik ersetzt oder instandgesetzt werden (Rekonfiguration des Service).
Mit Data Distribution Service (DDS) der Object Management Group (OMG) ist ein Middleware-Protokoll und API-Standard für datenzentrierte Konnektivität bekannt. In einem verteilten System ist die Middleware eine Software-Schicht, die zwischen dem Betriebssystem und Anwendungen (Applikationen) liegt. DDS ist eine Softwareschicht, welche die Anwendung von Einzelheiten des Betriebssystems, der Netzwerktransport- und Lowlevel-Datenformaten abstrahiert. DDS stellt einen QoS-(Quality-of-Service)-gesteuerten Datenaustausch bereit, bei dem Anwendungen durch Veröffentlichen (publishing) und Abonnieren (subscribing) von Topics, die durch ihren Topic-Namen identifizierbar sind, kommunizieren. Abonnements können Zeit und Inhaltsfilter spezifizieren und nur ein Subset der auf dem Topic publizierten Daten erhalten. Die Datenzentriertheit bei DDS bezieht sich darauf, dass die Middleware weiß, welche Daten sie speichert, und steuert, wie diese Daten zu teilen sind. Dazu sollen alle Nachrichten die Kontext-Informatioen enthalten, die eine Anwendung braucht, um die empfangenen Daten zu verstehen. Die Daten können auch mit flexiblen QoS-Spezifikationen geteilt werden, welche Zuverlässigkeit, Systemgesundheit (liveliness) und Sicherheitsaspekte beinhalten können (https://www.dds-foundation.org/what-is-dds-3/, abgerufen am 15. September 2021).
Aus VSS (Vehicle Signal Specification) ist es bekannt, eine Domänentaxonomie als ein Standard in Fahrzeuganwendungen zu nutzen, um semantisch wohldefinierte Informationen um das Fahrzeug herum zu kommunizieren. Es ist auf Fahrzeugsignale wie etwa Sensoren und Aktuatoren, deren Rohdaten über Fahrzeugbusse bewegt werden, oder Daten eines Infotainment-Systems fokussiert (https://genivi.github.io/vehicle_signal_specification/introduction/overview/, abgerufen am 1. September 2021).
Es ist eine Aufgabe der Erfindung, eine Möglichkeit zu schaffen, Logiken von Services zwischen Ecosystemen unterschiedlicher Technologien flexibel zu verlagern oder zu bewegen. Eine spezielle Aufgabe der Erfindung ist es, eine Möglichkeit zu schaffen, den Service eines Ecosystems bzw. dessen Logik auf ein anderes Ecosystem auszulagern, um beispielsweise Ressourcen des einen Ecosystems zu schonen (Relokalisierung des Service). Eine weitere spezielle Aufgabe der Erfindung ist es, eine Möglichkeit zu schaffen, einen defekten Service eines Ecosystems durch einen Service eines anderen Ecosystems, welcher die gleiche Aufgabe wie der defekte Service erfüllen kann, bzw. dessen Logik zu ersetzen oder instand zu setzen (Rekonfiguration des Service). Dabei ist ein Service eine Softwareeinheit, die vollständig von dem technischen System abstrahiert.
Diese Aufgabe wird wenigstens in Teilaspekten durch ein computerimplementiertes Verfahren mit den Merkmalen des unabhängigen Anspruchs 1, ein System mit den Merkmalen des unabhängigen Anspruchs 13, ein Computerprogramm mit den Merkmalen des unabhängigen Anspruchs 14 und einen computerlesbaren Datenträger mit den Merkmalen des unabhängigen Anspruchs 15 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
Ein Gesichtspunkt der Erfindung ist ein computerimplementiertes Verfahren zum Bewegen einer Logik eines Service zwischen einem ersten Ecosystem und einem zweiten Ecosystem in einem Netzwerk von Ecosystemen, wobei jedes Ecosystem mehrere technische Subsysteme mit jeweils eigener Logik und eigener Datenbasis umfasst, umfassend die Schritte:

- Empfangen einer Anfrage bezüglich eines ersten Service des ersten Ecosystems,
- Identifizieren eines zweiten Ecosystems in dem Netzwerk, welches Anforderungen des ersten Service erfüllt,
- Bewegen einer ersten Logik des ersten Service des ersten Ecosystems in das zweite Ecosystem oder einer zweiten Logik eines zweiten Service des zweiten Ecosystems in das erste Ecosystem,

Das gemeinsame Datenmodell kann ausgebildet sein, Daten von Subsystemen in eine Form zu abstrahieren, welche eine Übertragung zwischen Domänen unterschiedlicher Technologie ermöglicht Das Verteilen des gemeinsamen Datenmodell kann beispielsweise die Schritte aufweisen:

- Bereitstellens des gemeinsamen Datenmodells in dem ersten Ecosystem und dem zweiten Ecosystem, wobei das gemeinsame Datenmodell, und/oder
- Implementieren von Subsystemen und/oder Services in dem ersten Ecosystem und dem zweiten Ecosystem auf der Grundlage des gemeinsamen Datenmodells.

Ein Service beschreibt sich grundsätzlich über die zu transportierenden Daten sowie seine Schnittstelle. Darüber hinaus enthält der Service einen Logikbaustein, hier kurz als Logik bezeichnet, die Datenstruktur sowie deren Werte, die zu einer Funktionalität umzusetzen sind. Eine flexible Verlagerung von Logiken scheitert bisher an Unterschieden in den Technologien der Ecosysteme. Mit der Einführung eines gemeinsamen Datenmodells, auch „Common Data Model“ (CDM) genannt, welches Ecosystem übergreifend vereinheitlicht und auf dessen Basis Services implementiert werden können, haben die Services auf jeder im Netzwerk bekannten und mit dem CDM ausgestatteten Instanz eine ausführbare Grundlage, sodass diese flexibel über Instanzen allokierbar sind und insbesondere rekonfiguriert oder sogar relokalisiert werden können.
In einer Ausführungsform kann vorgesehen sein, dass die erste Logik des ersten Service des ersten Ecosystems in das zweite Ecosystem bewegt wird, um eine Relokalisierung des ersten Service von dem ersten Ecosystem in das zweite Ecosystem durchzuführen. Dabei können Daten aus dem gemeinsamen Datenmodell, die für das Bewegen der ersten Logik und/oder für die Ausführung des ersten Service in dem zweiten Ecosystem benötigt werden, synchronisiert und kontinuierlich aktualisiert werden. Die Ausführung des ersten Service kann auch die Ausführung eines an bestimmte Anforderungen, die in der Anfrage enthalten sein können, angepassten und gegebenenfalls ausgewählten oder reduzierten Funktionsumfang des ersten Service umfassen. Eine solche Relokalisierung kann es unter anderem ermöglichen, den Service eines Ecosystems bzw. dessen Logik auf ein anderes Ecosystem auszulagern, um beispielsweise Ressourcen des einen Ecosystems zu schonen. Eine andere Anwendung kann es ermöglichen, eine Plattform zu schaffen, über welche ein Service verkauft wird oder lizenziert werden kann.
In vorteilhaften Ausgestaltungen kann vorgesehen sein, dass die Ausführung des ersten Service in dem zweiten Ecosystem betreffende Rohdaten des ersten Ecosystems an das zweite Ecosystem übertragen werden.
In einer weiteren Ausführungsform kann vorgesehen sein, dass die zweite Logik des zweiten Service des zweiten Ecosystems in das erste Ecosystem bewegt wird, wobei zum Identifizieren des zweiten Ecosystems in dem Netzwerk zusätzlich zu der Bedingung, dass das zweite Ecosystem die Anforderungen des ersten Service erfüllt, das Identifizieren des zweiten Ecosystems auch dahingehend erfolgt, dass das zweite Ecosystem ein Service-Angebot aufweist, welches eine Funktion des ersten Service in dem ersten Ecosystem ausführen kann, und wobei das Service-Angebot von dem zweiten Ecosystem angefordert wird, dessen zweite Logik daraufhin von dem zweiten Ecosystem in das erste Ecosystem bewegt wird, um eine Rekonfiguration des ersten Service in dem ersten Ecosystem durchzuführen. Dabei können Daten aus dem gemeinsamen Datenmodell, die für das Bewegen der zweiten Logik und/oder für die Ausführung des zweiten Service in dem ersten Ecosystem benötigt werden, synchronisiert und bis zum Abschluss der Rekonfiguration aktualisiert werden. Die Ausführung des zweiten Service kann auch die Ausführung eines an bestimmte Anforderungen, die in der Anfrage enthalten sein können, angepassten und gegebenenfalls ausgewählten oder reduzierten Funktionsumfang des zweiten Service oder des ersten Service umfassen. Durch eine solche Rekonfiguration kann beispielsweise die Logik eines defekten Service durch die Logik eines Service eines anderen Ecosystems zu ersetzen oder zu reparieren.
Das Identifizieren des zweiten Ecosystems kann die Schritte umfassen:

- Prüfen der Anforderungen des ersten Service in der Vielzahl von Ecosystem,
- Bestimmen wenigstens eines Ecosystems der Vielzahl von Ecosystemen als Kandidaten-Ecosystem, wenn das eine Ecosystem die Anforderungen des ersten Service erfüllt, und
- - wenn mehrere Kandidaten-Ecosysteme bestimmt wurden: Auswählen eines Ecosystems als das zweite Ecosystem aus den Kandidaten-Ecosystemen, oder
- - wenn ein einziges Kandidaten-Ecosystem bestimmt wurde: Auswählen des Kandidaten-Ecosystems als das zweite Ecosystem.

Dabei kann das Auswählen aus den mehreren Kandidaten-Ecosystemen die Schritte umfassen:

- Bewerten der mehreren Kandidaten-Ecosystem hinsichtlich Auswahlkriterien, und
- Auswählen desjenigen Kandidaten-Ecosystems als das zweite Ecosystem, welches die Auswahlkriterien am besten erfüllt.

Zum Zweck der Relokalisierung kann das Prüfen der Anforderungen des ersten Service die Prüfung umfassen, ob das eine Ecosystem ein geeignetes Service-Angebot aufweist. Ferner kann das Auswählen aus den mehreren Kandidaten-Ecosystemen die Schritte umfassen:

- Bewerten der Service-Angebote hinsichtlich Auswahlkriterien, und
- Auswählen desjenigen Kandidaten-Ecosystems mit dem Service-Angebot, welches die Auswahlkriterien am besten erfüllt, als das zweite Ecosystem.

In speziellen Ausführungsformen kann vorgesehen sein, dass der erste Service und/oder der zweite Service die Verarbeitung von Sensordaten als Rohdaten umfasst.
In vorteilhaften Ausgestaltungen kann vorgesehen sein, dass die erste Logik und/oder die zweite Logik betreffende Daten über eine Service-Schicht übertragen werden und die Ausführung des ersten Service oder des zweiten Service betreffende Rohdaten über eine Datenschicht übertragen werden.
In vorteilhaften Ausgestaltungen kann vorgesehen sein, dass das Verfahren durch eine das erste Ecosystem und das zweite Ecosystem verbindende Servicequalitäts- oder Quality-of-Service-Koordinationseinheit durchgeführt wird. Ein Quality-of-Service-Konzept beschreibt bisher einige Parameter zur Güte von Daten. Die erfindungsgemäße Quality-of-Service-Koordinationseinheit erweitert die Betrachtungsweise um die Service-Instanz.
Ein weiterer Gesichtspunkt der Erfindung ist System zum Bewegen einer Logik eines Service zwischen einem ersten Ecosystem und einem zweiten Ecosystem in einem Netzwerk von Ecosystemen, wobei jedes Ecosystem mehrere technische Subsysteme mit jeweils eigener Logik und eigener Datenbasis umfasst, umfassend eine Quality-of-Service-Koordinationseinheit mit:

- einer Empfangseinheit zum Empfangen einer Anfrage bezüglich eines ersten Service des ersten Ecosystems,
- einer Identifikationseinheit zum Identifizieren eines zweiten Ecosystems in dem Netzwerk, welches Anforderungen des ersten Service erfüllt, und
- einer Bewegungseinheit zum Bewegen der ersten Logik des ersten Service des ersten Ecosystems in das zweite Ecosystem oder einer zweiten Logik des zweiten Service des zweiten Ecosystems in das erste Ecosystem,

Das System ist insbesondere eingerichtet, um das vorstehend beschriebene Verfahren auszuführen, und kann daher die gleichen Wirkungsweisen und Vorteile aufweisen. Die QoS-Koordinationseinheit ist eine Funktionseinheit, die in der Lage ist, den Kontrakt zwischen verschiedenen Instanzen herzustellen, und besitzt die Mechanismus, zu entscheiden, ob die Instanzen sich

a) kennen/authentifizieren können.
b) die Anforderungen eingehalten werden können.

Ein weiterer Gesichtspunkt der Erfindung ist ein Computerprogramm mit Programmcode, um das oben beschriebene Verfahren durchzuführen, wenn das Computerprogramm auf einem Computer ausgeführt wird. Das Computerprogramm kann eingerichtet werden, um auf einem oder mehreren Prozessoren ausgeführt zu werden, um dadurch das erfindungsgemäße Verfahren auszuführen. Das Computerprogramm kann auf einem oder mehreren Speichermedien gespeichert sein.
Ein weiterer Gesichtspunkt der Erfindung ist ein computerlesbarer Datenträger mit Programmcode eines Computerprogramms, um das oben beschriebene Verfahren durchzuführen, wenn das Computerprogramm auf einem Computer ausgeführt wird.
Weitere mögliche Ausgestaltungen, Weiterbildungen und Implementierungen der Erfindung umfassen auch nicht explizit genannte Kombinationen von zuvor oder im Folgenden bezüglich der Ausführungsbeispiele beschriebenen Merkmale der Erfindung.
Die beiliegenden Figuren sollen ein weiteres Verständnis der Ausführungsformen der Erfindung vermitteln. Sie veranschaulichen Ausführungsformen und dienen im Zusammenhang mit der Beschreibung der Erklärung von Prinzipien und Konzepten der Erfindung. Andere Ausführungsformen und viele der genannten Vorteile ergeben sich im Hinblick auf die Figuren. Es zeigen:

1a ein schematisches Blockdiagramm zur Veranschaulichung eines Systems zum Bewegen einer Logik eines Services zwischen Ecosystemen gemäß einem ersten Ausführungsbeispiel der Erfindung,
1b und 1c jeweils ein schematisches Diagramm zur Veranschaulichung von Schritten zur Ausführung eines Verfahrens zum Bewegen einer Logik eines Services zwischen Ecosystemen, wobei 1b das Verfahren in der Ausprägung einer Relokalisierung gemäß einem zweiten Ausführungsbeispiel der Erfindung zeigt und 1c das Verfahren in der Ausprägung einer Rekonfiguration gemäß einem dritten Ausführungsbeispiel der Erfindung zeigt,
2 ein schematisches Blockdiagramm eines Netzwerks mit Ecosystemen und einer QoS-Koordinationseinheit zur Veranschaulichung von Teilaspekten der Erfindung,
3 ein schematisches Blockdiagramm eines weiteren Netzwerks mit Ecosystemen und einer QoS-Koordinationseinheit zur Veranschaulichung von Teilaspekten der Erfindung,
4 ein schematisches Blockdiagramm eines noch weiteren Netzwerks mit Ecosystemen und einer QoS-Koordinationseinheit zur Veranschaulichung von Teilaspekten der Erfindung,
5 ein schematisches Baumdiagramm zur Veranschaulichung eines vereinheitlichten Datenmodells gemäß der Erfindung,
6 ein schematisches Blockdiagramm mit Ecosystemen zur Veranschaulichung von Aufgaben des vereinheitlichten Datenmodells gemäß der Erfindung,
7 ein schematisches Blockdiagramm eines Netzwerks mit Ecosystemen und einer QoS-Koordinationseinheit zur Veranschaulichung einer beispielhaften Anwendung des erfindungsgemäßen Verfahrens,
8 ein schematisches Blockdiagramm eines Netzwerks mit Ecosystemen und einer QoS-Koordinationseinheit zur Veranschaulichung einer beispielhaften Wirkungsweise der QoS-Koordinationseinheit in dem erfindungsgemäßen Verfahren und/oder System,
9 ein schematisches Ablaufdiagramm zur Veranschaulichung von weiteren Schritten zur Ausführung des erfindungsgemäßen Verfahrens,
10 ein schematisches Blockdiagramm zur Veranschaulichung von beispielhaften Funktionsblöcken der QoS-Koordinationseinheit in dem erfindungsgemäßen Verfahren und/oder System,
11 ein schematisches Blockdiagramm von Elementen des Netzwerks von 8 zur Veranschaulichung einer beispielhaften Publikation von Daten aus dem gemeinsamen Datenmodell zu der QoS-Koordinationseinheit in dem erfindungsgemäßen Verfahren und/oder System,
12 ein schematisches Blockdiagramm von Elementen des Netzwerks von 8 zur Veranschaulichung einer beispielhaften Bereitstellung eines Services zur Relokalisierung und Rekonfiguration mit dem gemeinsamen Datenmodell in dem erfindungsgemäßen Verfahren und/oder System,
13 ein schematisches Blockdiagramm von Elementen des Netzwerks von 8 zur weiteren Veranschaulichung einer beispielhaften Bereitstellung eines Services zur Relokalisierung und Rekonfiguration mit dem gemeinsamen Datenmodell in dem erfindungsgemäßen Verfahren und/oder System.

Im Folgenden werden, sofern nicht anders angegeben, für gleiche und gleichwirkende Elemente gleiche Bezugszeichen verwendet.
1a zeigt ein schematisches Blockdiagramm zur Veranschaulichung eines Systems zum Bewegen einer Logik eines Services zwischen Ecosystemen gemäß einem ersten Ausführungsbeispiel der Erfindung. Ein erstes Ecosystem 1, ein zweites Ecosystem 2 und eine QoS-Koordinationseinheit sind über ein Netzwerk 4 miteinander verbunden. Es können noch weitere Ecosysteme vorhanden sein, die mit drei vertikal angeordneten Punkten symbolisiert sind. Das erste Ecosystem 1 weist einen ersten Service 5 auf und kann weitere Services aufweisen, die mit drei vertikal angeordneten Punkten symbolisiert sind. Der erste Service 5 weist eine erste Logik 6 auf. Das erste Ecosystem 1 kann ferner eine Steuereinheit (CTR) 7 zur Steuerung von Services aufweisen. Das erste Ecosystem 1 kann ferner eine Schnittstelleneinheit (I/O) 8 zur Kommunikation mit dem Netzwerk 4 aufweisen. Das zweite Ecosystem 2 weist einen zweiten Service 9 auf und kann weitere Services aufweisen, die mit drei vertikal angeordneten Punkten symbolisiert sind. Der zweite Service 9 weist eine zweite Logik 10 auf. Das zweite Ecosystem 2 kann ferner eine Steuereinheit (CTR) 11 zur Steuerung von Services aufweisen. Das zweite Ecosystem 2 kann ferner eine Schnittstelleneinheit (I/O) 12 zur Kommunikation mit dem Netzwerk 4 aufweisen. Die Services 5, 9 sind Softwareeinheiten, die vollständig von dem technischen System abstrahiert sind. Der Service können sich über zu transportierende Daten sowie eine Schnittstelle definieren. Die Logiken 6, 10 sind Logikbausteine der Services 5, 9, welche deren Datenstruktur sowie deren Werte zu einer Funktionalität umsetzen können.
Das erfindungsgemäße System macht Gebrauch von einem gemeinsamen Datenmodell 13. Das gemeinsame Datenmodell (CDM für engl. Common Data Model) 13 beschreibt eine Vorgehensweise, Daten eines technischen Systems, in eine einheitliche und technologieunabhängige Form darzustellen, sodass diese auch für andere Domänen übertragbar ist. Die Daten können insbesondere Daten von Services 5, 9 bzw. deren Logiken 6, 10, aber auch von den Services 5, 9 gelieferten oder verarbeiteten Rohdaten verwendeten oder sonstiger zur Ausführung der Services 5, 9 bzw. deren Logiken 6, 10 benötigten Daten umfassen. Weitere Einzelheiten des CDM 13 sind auch weiter unten beschrieben. Das CDM 13 ist über das erste und das zweite Ecosystem 1, 2 und ggf. weitere Ecosysteme verteilt und wird von den Logiken 6, 10 verwendet. Das CDM 13 umfasst, wie später genauer beschrieben und dargestellt wird, eine Datennachricht auf OSI-Layer 5-7 mit zumindest den Attributen Header mit Feld für Nachricht-ID, Payload mit Feldern für Zeitstempel, Beschreibungszeile, Wert, Einheit, Datentyp und QoS-Attribut. Informationen über die Services 5, 9 oder deren Logiken 6, 10 oder zugehörige Daten können über eine solche Datennachricht im Netzwerk 4 übertragen werden und insbesondere von der QoS-Koordinationseinheit 3 verwendet werden, um beispielsweise das erfindungsgemäße Verfahren auszuführen.
Die QoS-Koordinationseinheit 3 weist eine Empfangseinheit 14, eine Identifikationseinheit 15 und eine Bewegungseinheit 16 auf. Die QoS-Koordinationseinheit 3 kann ferner eine Schnittstelleneinheit (I/O) 17 zur Kommunikation mit dem Netzwerk 4 aufweisen. Weitere Funktionseinheiten sowie Untereinheiten der Einheiten 14, 15, 16 sind auch weiter unten beschrieben. Die QoS-Koordinationseinheit 3 wird nachstehend und insbesondere in den Figuren auch als QoS Coordinator oder QoS Manager oder nur QoS bezeichnet oder dargestellt, wobei die Bezeichnungen synonym sind. Die Empfangseinheit 14 ist ausgebildet, um Anfragen bezüglich Services, insbesondere eine Anfrage bezüglich des ersten Service 5 des ersten Ecosystems 1 zu empfangen. Die Identifikationseinheit 15 ist ausgebildet, um ein Ecosystem, insbesondere das zweite Ecosystem 2, welches Anforderungen des ersten Service 5 gemäß der Anfrage erfüllt, in dem Netzwerk 4 zu identifizieren. Die Bewegungseinheit 16 ist ausgebildet, um eine Logik zwischen Ecosystemen, insbesondere die erste Logik 6 des ersten Service 5 des ersten Ecosystems 1 in das zweite Ecosystem 2 oder die zweite Logik 10 des zweiten Service 9 des zweiten Ecosystems 2 in das erste Ecosystem 1 zu bewegen.
1b und 1c zeigen jeweils ein schematisches Diagramm zur Veranschaulichung von Schritten zur Ausführung eines Verfahrens zum Bewegen einer Logik eines Services zwischen Ecosystemen.
Dabei zeigt 1b das Verfahren in der Ausprägung einer Relokalisierung gemäß einem zweiten Ausführungsbeispiel der Erfindung. Dabei fragt ein degradiertes technisches System beim QoS Coordinator 3 nach einem Service an, der eine bestimmte Funktionalität erfüllt. Diese Anfrage 18 wird in vom QoS-Koordinationseinheit 3 empfangen (Schritt S1). Der QoS Coordinator 3 fragt entsprechend einer Discovery in dem Netzwerk 4 nach entsprechenden Services anderer Systeme und identifiziert so das zweite Ecosystem 2, welches Anforderungen des ersten Services 5 des ersten Ecosystems 1 erfüllt (Schritt S2). Ist ein Service gefunden, so wird die erste Logik 6 des ersten Services 5 auf Basis der zu verwendenden Daten und Parameter durch den klassischen Service Provider angeboten und in das zweite Ecosystem bewegt (Schritt S3). Zudem kann eine Zeitspanne für die Aktualisierung der Daten durch das ursprüngliche System spezifiziert werden.
In einem beispielhaften Szenario kann das erste Ecosystem 1 ein Fahrzeug sein und kann das zweite Ecosystem 2 ein Backend des Herstellers sein. Gemäß diesem Szenario muss in dem Fahrzeug während oder nach der Entwicklungszeit, d.h. noch während der Entwicklung oder während das Fahrzeug sich schon beim Kunden befindet, für weitere Updates in einem kontinuierlichen Software-Update-Prozess, wie es ähnlich beispielsweise auch bei Handys der Fall sein kann, Ressourcen eingespart werden wie Speicher oder Prozessortaktung. Gemäß dem erfindungsgemäßen Verfahren kann eine Relokalisierung des Services wie folgt durchgeführt werden:

1. Das Fahrzeug (erstes Ecosystem 1) übermittelt dem Quality of Service Coordinator 3 die Anforderungen des Services in Form von entsprechenden Gütekriterien für die Logik hinsichtlich beispielsweise Laufzeit, Kritikalität, Zuverlässigkeit etc. Das umfasst den Empfang der Anfrage 18 durch die QoS-Koordinationseinheit 3 (Schritt S1).
2. Der QoS Coordinator 3 findet hierfür eine richtige Instanz, hier das BMW Backend als zweites Ecosystem 2. Das entspricht der Identifikation des zweiten Ecosystems 2 (Schritt S2). Bedingung hier: Die Instanz muss für das Fahrzeug authentifizierbar sein, d.h. Fahrzeug kennt das Backend, Smart Home, Smart City...
3. Der QoS Coordinator 3 bewegt die Logik (zweite Logik 6) vom Fahrzeug (erstes Ecosystem 1) ins Backend (zweites Ecosystem 2).

1c zeigt das Verfahren in der Ausprägung einer Rekonfiguration gemäß einem dritten Ausführungsbeispiel der Erfindung. Unter der Relokalisierung wird die Verlagerung eines Services verstanden. Dabei ist die Verlagerung eine neue Instanziierung des originären Services auf ein neues technisches System. Der Logikbaustein bleibt identisch und nutzt die gleichen Daten aus dem CDM 13.
Wie bei der Relokalisierung fragt ein degradiertes technisches System (erstes Ecosystem 1) beim QoS Coordinator 3 nach einem Service an, der eine bestimmte Funktionalität erfüllt. Diese Anfrage 18 wird in vom QoS-Koordinationseinheit 3 empfangen (Schritt S1). Der QoS Coordinator 3 fragt entsprechend einer Discovery in dem Netzwerk 4 nach entsprechenden Services anderer Systeme und identifiziert so das zweite Ecosystem 2, welches Anforderungen des ersten Services 5 des ersten Ecosystems 1 erfüllt (Schritt S2). Ist ein Service gefunden, so sendet die QoS-Koordinationseinheit 3 eine Anfrage 19 an das zweite Ecosystem 2 (Schritt S4). Daraufhin wird die zweite Logik 10 des zweiten Services 9 auf Basis der zu verwendenden Daten und Parameter durch den klassischen Service Provider angeboten und in das erste Ecosystem 1 bewegt (Schritt S5).
In einem bespielhaften Szenario kann das erste Ecosystem 1 ein Smart Home sein, kann das zweite Ecosystem 2 ein Fahrzeug sein und kann der erste Service 5 ein Service zur Temperaturmessung im Bad des Eigenheims sein, und die erste Logik 6 ist der zugehörige Logikbaustein. In diesem Szenario funktioniert die Temperaturmessung im Bad nicht mehr. Scheinbar ist die Logik des Service zur Temperaturmessung im Bad ausgefallen. Da das Fahrzeug und das Smart Home System das gemeinsame Datenmodell 13 teilen, kann das Smart Home die Logik vom Fahrzeug übernehmen. Gemäß dem erfindungsgemäßen Verfahren kann eine Rekonfiguration des Services wie folgt durchgeführt werden.

1. Das Smart Home System als erstes Ecosystem 1 fragt den QoS Coordinator 3 nach einer bekannten Instanz, die die Innentemperatur bereitstellen kann (Empfang der Anfrage 18 in Schritt S1).
2. Der QoS Coordinator 3 findet hierfür eine richtige Instanz im Netzwerk 4, hier das Fahrzeug (Identifikation des zweites Ecosystems 2 in Schritt S2). Dies umfasst das Identifizieren eines entsprechenden Service-Angebots im Fahrzeug.
3. Der QoS Coordinator 3 requestet beim Fahrzeug nach dem Service Angebot der Innentemperatur (Anfrage 19 an zweites Ecosystem 2 in Schritt S4).
4. Der erste Service 5 wird durch Bewegen der zweiten Logik 10 ins Smart Home System rekonfiguriert (Schritt S5).

2 zeigt ein schematisches Blockdiagramm eines Netzwerks 4 mit Ecosystemen 21-24 und der QoS-Koordinationseinheit 3 zur Veranschaulichung von Teilaspekten der Erfindung, insbesondere Sicherheitsqualitätsparametern oder QoS-Parametern 25. Das Netzwerk 4 in 2 weist als verbundene Ecosysteme ein Fahrzeug 21, ein Smartphone 22, ein Smart Home 23 und ein City-System 24 auf. Im QoS Coordinator 3 sind die QoS-Parametern 25 für Daten und Services hinterlegt. Die QoS-Parameter 25 können beispielswiese Zuverlässigkeit (Reliabilty), Lebensdauer (Lifespan), Benutzer-/Gruppendaten (User/Group Data), zeit- und inhaltsbasierte Filter (Time & Content Based Filter), Latenz und Priorität (Latency & Priority) umfassen. Die QoS Parameter 25 sind für den QoS Coordinator 3 notwendig, um zu prüfen, ob eine Instanz bzw. ein Ecosystem einen Service oder die zugehörigen Daten nutzen darf oder kann. Ein Beispiel hierfür ist der zuverlässige Aufbau der Kommunikation zwischen zwei Instanzen. Die QoS-Parameter 25 können auch zur Beurteilung, ob ein Ecosystem die Anforderungen des ersten Service 5 des anfragenden ersten Ecosystems 1 erfüllt, verwendet werden. Erfüllen mehrere Ecosysteme die Anforderungen, kann aus diesen Kandidaten-Ecosystemen dasjenige Ecosystem, welches die Anforderungen am besten erfüllt, anhand der QoS-Parameter 25 ausgewählt werden.
3 zeigt ein schematisches Blockdiagramm eines weiteren Netzwerks 4 mit Ecosystemen 21, 23, 24, 31 und der QoS-Koordinationseinheit 3 zur Veranschaulichung von Teilaspekten der Erfindung. Das Netzwerk 4 in 3 weist als verbundene Ecosysteme ein Fahrzeug (Vehicle) 21, ein Smart Home 23, ein Smart City-System 24 und ein Fahrzeug-Backend oder Vehicle Backend 31 auf. Ein Smart Home 23 kann beispielsweise einen KNX Feldbus zur Gebäudeautomatisation mit Sensorik, Aktorik und anderen Subsystemen sein. Das Vehicle Backend 31 gehört zu der Klasse Operator Backend und kann ein Backend eines Herstellers des Fahrzeugs 21, also beispielsweise auch ein Flotten-Backend sein. Die Smart City kann einen Service 32 aufweisen, das Fahrzeug 21 kann einen Service 33 und einen Service 34 aufweisen, und das Smart Home 23 kann einen Service 35 aufweisen. Die Services 32-35 weisen das gemeinsame Datenmodell 13 gemäß vorstehender Beschreibung auf, das über alle Ecosysteme 21, 23, 24, 31 verteilt ist. Der Service 33 und der Service 34 des Fahrzeugs 21 seien defekt. Das Fahrzeug 21 ist daher das erste Ecosystem 1, wobei der Service 33 einerseits und der Service 34 andererseits ein erster Service 5 im Sinne der vorstehenden Beschreibung sind. In jeweiligen Anfragen (Schritt S1) wird bei der QoS-Koordinationseinheit 3 nach passenden Ecosystemen angefragt. Die QoS-Koordinationseinheit 3 identifiziert das Vehicle Backend 31 als geeignetes, zweites Ecosystem 2 für eine Relokalisierung für den Service 34 und identifiziert das Smart Home 23 als geeignetes, zweites Ecosystem 2 für eine Rekonfiguration für den Service 33 mit dem Service 35 als zweitem Service 19. Daraufhin kann die Logik des defekten Service 34 als erste Logik 6 im Sinne der vorstehenden Beschreibung in das Vehicle Backend 31 bewegt werden (Schritt S3) und dort als relozierter erster Service 5* fungieren. Ebenso kann der Service 35 des Smart Home 23 als Service-Angebot angefragt werden (Schritt S4) und dessen Logik als zweite Logik 10 im Sinne der vorstehenden Beschreibung in das Fahrzeug 33 bewegt werden (hier nicht näher dargestellt). Der relozierte erste Service 5* kann den vollständigen oder einen an Bedürfnisse des ersten Ecosystems 1 angepasst, beispielsweise mit einem reduzierten oder ausgewählten Funktionsumfang ausgestattet sein.
4 zeigt ein schematisches Blockdiagramm eines noch weiteren Netzwerks 4 mit Ecosystemen 41-44 und einer QoS-Koordinationseinheit 3 zur Veranschaulichung von Teilaspekten der Erfindung. Hier ist das Netzwerk 4 ein fahrzeuginternes Netzwerk (Vehicle On-Board). Das Netzwerk 4 in 4 weist als verbundene Ecosysteme vier Hochleistungsrechner (High-Processing Computer A-D) 41, 43, 44, 43 auf. Der Hochleistungsrechner A 41 kann einen Service 45 aufweisen, der Hochleistungsrechner D 42 kann einen Service 46 und einen Service 47 aufweisen, und der Hochleistungsrechner C 44 kann einen Service 48 aufweisen. Die Services 45-48 weisen das gemeinsame Datenmodell 13 gemäß vorstehender Beschreibung auf, das über alle Ecosysteme 41-44 verteilt ist. Der Service 46 und der Service 47 des Hochleistungsrechner B 42 seien defekt. Der Hochleistungsrechner B 42 ist daher das erste Ecosystem 1, wobei der Service 46 einerseits und der Service 47 andererseits ein erster Service 5 im Sinne der vorstehenden Beschreibung sind. In jeweiligen Anfragen (Schritt S1) wird bei der QoS-Koordinationseinheit 3 nach passenden Ecosystemen angefragt. Die QoS-Koordinationseinheit 3 identifiziert den Hochleistungsrechner B 43 als geeignetes, zweites Ecosystem 2 für eine Relokalisierung für den Service 47 und identifiziert den Hochleistungsrechner C 44 als geeignetes, zweites Ecosystem 2 für eine Rekonfiguration für den Service 46 mit dem Service 48 als zweitem Service 19. Daraufhin kann die Logik des defekten Service 47 als erste Logik 6 im Sinne der vorstehenden Beschreibung in den Hochleistungsrechner D 42 bewegt werden (Schritt S3) und dort als relozierter erster Service 5* fungieren. Ebenso kann der Service 48 des Hochleistungsrechner C 44 als Service-Angebot angefragt werden (Schritt S4) und dessen Logik als zweite Logik 10 im Sinne der vorstehenden Beschreibung in den Hochleistungsrechner D 42 bewegt werden (hier nicht näher dargestellt).
3 und 4 zeigen somit die Anwendung der Erfindung auf Netzwerke 4 unterschiedlicher Granularität. Die Granularität kann offen oder proprietär, global, regional, gruppenbezogen, lokal bis hin zu abgeschlossenen Einzelsystemen sein.
5 zeigt ein schematisches Baumdiagramm zur Veranschaulichung des vereinheitlichten Datenmodells 13 gemäß der Erfindung, wie auch einen beispielhaften Datensatz 50 für ein Element. Das Datenmodell 13 ist hier für Fahrzeuganwendungen ausgelegt. Das Datenmodell 13 weist Zweige (Branch, mit Kreisen symbolisiert) auf, die jeweils weiter verzweigt sein können. Ein Zweig kann beispielsweise Sensoren (Sensor, mit einem Fünfeck symbolisiert) und Aktuatoren (Actuator, mit einem Stern symbolisiert) aufweisen. Jedes Element kann Attribute (Attribute, mit einem Viereck symbolisiert) aufweisen. Das vereinheitlichte Datenmodell 13 kann dem eingangs beschriebenen VSS entnommen sein, sodass hier auf eine Beschreibung diesbezüglicher Einzelheiten abgesehen wird. Die Beschreibungsform kann auch für Daten in anderen Domänen wie Smart Home Systemen, Städteplanung etc. genutzt werden.
6 zeigt ein schematisches Blockdiagramm mit den bereits beschriebenen Ecosystemen 21, 22, 24, 31 zur Veranschaulichung von Aufgaben des vereinheitlichten Datenmodells gemäß der Erfindung. Die dargestellten Ecosysteme umfassen ein Fahrzeug (Vehicle) 21, ein Smart Home 23, ein Smart City-System 24 und ein Vehicle Backend 31 auf. Das Fahrzeug- bzw. Vehicle Backend 31 kann im Unterschied zum Fahrzeug-Bordnetz des Fahrzeugs 21 eine Anordnung von externen Geräten umfassen, die im Fahrzeug 21 vorhanden sind, es kann auch ein Flotten-Backend umfassen. Jedes Ecosystem 21, 22, 24, 31 weist spezifische Subsysteme 65 auf. Das gemeinsame Datenmodell (CDM) 13 ist auf alle Ecosysteme 21, 22, 24, 31 verteilt. Das CDM 13 kann beispielsweise wie folgt implementiert werden: Über das gemeinsame Datenmodell 13 wird ein Standard definiert, der eine einheitliche Datenbeschreibungsform bereitstellt (Schritt S61). Services 66 werden gegen eine CDM-API entwickelt (Schritt S62). Mit anderen Worten, es wird eine Zugriffsschicht auf das CDM über eine API bereitgestellt. Dadurch können die Services 67 über definierte Aufrufe und Methoden auf die Daten 66 zugreifen bzw. neu setzen. Protokollspezifische und domänenspezifische Daten können in ein standardisiertes Datenformat übersetzt werden (Schritt S63). So können Bewegungsszenarios einschließlich Relokalisierungs- und Rekonfigurationsszenarien über die QoS-Koordinationseinheit 3 (hier nicht dargestellt) über Instanzen hinweg verwirklicht werden.
7 zeigt ein schematisches Blockdiagramm eines Netzwerks 4 mit den bereits beschriebenen Ecosystemen 21, 24, 31 und der QoS-Koordinationseinheit 3 zur Veranschaulichung einer beispielhaften Anwendung des erfindungsgemäßen Verfahrens. Bei dieser Anwendung kann eine Logik eines Reibwertschätzers des Fahrzeug-Ecosystems 21 auf der Basis des CDM 13 beispielsweise in das Smart-City-Ecosystem 24 verlagert werden. Datengüte und Formalismus bleiben gleich. Aus dem Fahrzeug-Backend 31 können durch Smart City 24 beispielsweise historische oder diagnostische Reibwerte zur QoS-Koordinationseinheit 3 abonniert (subskribiert) werden. Bei dieser Anwendung können Daten des Reibwertschätzers auch in einer Reibwertkarte veröffentlicht und in dem Smart City Ecosystem 24 genutzt werden.
8 zeigt ein schematisches Blockdiagramm eines Netzwerks 4 mit den bereits beschriebenen Ecosystemen 21-24, 31 und der QoS-Koordinationseinheit 3 zur Veranschaulichung einer beispielhaften Wirkungsweise der QoS-Koordinationseinheit 3 in dem erfindungsgemäßen Verfahren und/oder System. Über das CDM 13 können Daten 80 abstrahiert werden. Die Daten 80 können beispielsweise Rohdaten sein welche etwa Fahrzeuggeschwindigkeit, GPS-Daten, Status einer Sitzheizung etc. betreffen. Die QoS-Koordinationseinheit 3 weist eine Service-Schicht 81, eine Zugriffsschicht 82 und eine Datenschicht 83 auf. Die Daten 80 können im Zuge einer Logikbewegung wie etwa einer Relokalisierung oder Rekonfiguration eines Service 34 (erster Service 5 des Fahrzeugs 21 als erstem Ecosystem 1) über einen ersten oder Rohdatenpfad 84 in der Datenschicht 83 der QoS-Koordinationseinheit 3 synchronisiert und aktualisiert werden. Über einen zweiten oder Servicedatenpfad 85 der QoS-Koordinationseinheit 3 in der Zugriffsschicht 82 kann ein in dem Service 34 neu erzeugtes Datum 86 in die Datenschicht 83 der QoS-Koordinationseinheit 3 gespeist werden. Über einen dritten oder Service-Pfad 88 in der Zugriffsschicht 82 der QoS-Koordinationseinheit 3 kann die Logik des (ersten) Service 34 (5) zunächst als gehaltene Logik 87 in die Service-Schicht 81 der QoS-Koordinationseinheit 3 bewegt und dann weiter in ein zweites Ecosystem aus den Ecosystemen 22, 23, 24, 31 bewegt werden.
9 zeigt ein schematisches Ablaufdiagramm mit weiteren Schritten zur Ausführung des erfindungsgemäßen Verfahrens. Das Verfahren weist die folgenden Schritte auf:

S90: Ein Service wird auf ein technisches System partitioniert
S91: Die Logik des Services basiert auf den standardisierten Daten des CDM
S1: Anfrage des technisches System an QoS Coordinator bzgl. eines Services
S92: QoS Coordinator führt eine Functional Discovery durch
S93: Über Data Qualifier werden die Rahmenbedingungen des Services geprüft
S94: Operation Manager prüft Anforderung bzgl. Relokalisierung oder Rekonfiguration und triggert diesen
S95: Execution Manager führt Strategie aus, welche wahlweise umfasst:
S3: Service wird vollständig verlagert
S96: Alle Daten aus dem CDM für den entsprechenden Service werden im QoS Coordinator synchronisiert und kontinuierlich aktualisiert oder:
S5: Parameter und Daten des Services werden im neuen techn. System rekonfiguriert
S97: Alle Daten aus dem CDM für den entsprechenden Service werden im QoS Coordinator synchronisiert und nur für einen gewissen Zeitraum bis Abschluss der Rekonfiguration über die Angabe der Lebensdauer (Lifespan) eines Services aktualisiert

Das Verfahren wird im Wesentlichen durch die QoS-Koordinationseinheit 3 ausgeführt oder gesteuert. Die oben genannten Funktionsblöcke werden im Zusammenhang mit der 10 näher erläutert. 10 zeigt ein schematisches Blockdiagramm zur Veranschaulichung von beispielhaften Funktionsblöcken der QoS-Koordinationseinheit 3 in dem erfindungsgemäßen Verfahren und/oder System. Hierzu zählen:

Authentification:: initialisiert Kommunikation zwischen Instanzen und dem QoS Coordinator und prüft die Rechtebedingungen (darf ein Service Daten hier ablegen oder entnehmen oder ein Service an eine andere Instanz rekonfiguriert oder relokalisiert werden?). Dabei wird dieses über ein Whitelist Konzept durchgeführt, d.h. alle bekannten Teilnehmer werden im QoS Coordinator 3 vorgestellt. Dieses kann dynamisch über Laufzeit erweitert werden.
Registry:: Neue Daten aus den einzelnen Instanzen werden hier im QoS Coordinator festgehalten und gespeichert, um zukünftig Aussagen über das Vorhandensein von neuen Daten treffen zu können.
Update und: Synchronization Manager: Diese Komponente innerhalb des QoS Coordinators verwaltet die verschiedenen CDM Versionen und gleicht diese ab in der Form einer
Data Discovery:: Synchronisation. Bei Inkompatibilitäten hinsichtlich eines Service Transfers werden die benötigten Daten aktualisiert. Wenn Daten von einer Instanz gesucht werden, wird innerhalb der Data Discovery eine Suche im Datenraum des QoS Coordinators durchgeführt und rückgemeldet bei Erfolg oder Misserfolg.
Data Qualifier:: Dieser Block prüft bei Vorhandensein von den gesuchten Daten die QoS Parameter, ob diese für die erforderliche Instanz ausreichend sind oder hier ein Gütekriterium verletzt wird.
Functional Discovery:: Die Functional Discovery beruht auf die Suche entsprechender Services bei den verschiedenen Instanzen. Dabei fragt der QoS Coordinator nach der Bereitstellung eines bestimmten Datums wie bspw. Innenraumtemperatur. Der entsprechende Service wird dann diesbezüglich identifiziert und dem QoS Coordinator kommuniziert.
Operation Manager:: Der Operation Manager bereitet den Prozess vor zur Rekonfiguration oder Relokalisierung und setzt die Trigger.
Reconfiguration &: Relocation: Die Funktionsbausteine leiten die entsprechende Strategie der Service Verlagerung bzw. der Bereitstellung der Konfigurationsdaten ein.
Execution Manager:: Ausführungseinheit der Rekonfiguration und Relokalisierung
Interface Handler:: Die Logik wird verlagert, die auf Basis der vereinheitlichen Beschreibungsform der Daten im Common Data Model aufgebaut ist. Allerdings unterscheiden sich die verschiedenen Instanzen in der Ansprechbarkeit der Services aufgrund verschiedener standardisierten Protokolle aus den jeweiligen Domänen. Der Interface Handler ist ein sog. Wrapper, der abhängig von der Domäne die verlagerte Service-Schnittstelle ummantelt mit der domänenspezifischen Protokollstruktur. Beispielsweise kann die Verlagerung eines automotive Services mit einem SOME/IP Protokoll hin zu einem Smart City Brain mit einer neuen Protokollanpassung zu einem http Übetragungsprotokoll einhergehen, um die Kommunikation zwischen QoS Coordinator und Instanz garantieren zu können.
Image Loader:: Die zu verlagernde Logik wird über den QoS in ein Image umgewandelt und dann für ein Upload auf ein anderes technisches System, das den Service zukünftig ausführen wird, installationsfähig vorbereitet.

Bisher beschreibt ein Quality of Service eine Parameter zur Güte von Daten. Die erfindungsgemäße QoS-Koordinationseinheit erweitert die Betrachtung um die Service-Instanz und mach so das erfindungsgemäße Verfahren das erfindungsgemäße System möglich. Die QoS-Koordinationseinheit 3 kann zentralisiert oder verteilt implementiert sein.
11 zeigt ein schematisches Blockdiagramm von Elementen des Netzwerks 4 von 8 zur Veranschaulichung einer beispielhaften Publikation von Daten aus dem gemeinsamen Datenmodell zu der QoS-Koordinationseinheit 3 in dem erfindungsgemäßen Verfahren und/oder System. Dabei wird auch die Bewegung von durch den ersten Service 5 neu erzeugte Daten 86 über den zweiten Pfad 85 aus 8 veranschaulicht. Das City Brain 24 in 11 ist mit City 24 in 2 oder 6, Smart City 24 in 3 oder 7, City Backend 24 in 8 identisch.
12 zeigt ein schematisches Blockdiagramm von Elementen des Netzwerks 4 von 8 zur Veranschaulichung einer beispielhaften Bereitstellung eines ersten Services 5 zur Relokalisierung und Rekonfiguration mit dem gemeinsamen Datenmodell in dem erfindungsgemäßen Verfahren und/oder System. Dabei wird auch die Synchronisation und Aktualisierung von Daten 80 des ersten Ecosystems 1 über den ersten Pfad 84 aus 8 und die Bewegung des ersten Service 5 über den dritten Pfad 88 veranschaulicht.
13 zeigt ein schematisches Blockdiagramm von Elementen des Netzwerks 4 von 8 zur weiteren Veranschaulichung einer beispielhaften Bereitstellung eines Services zur Relokalisierung und Rekonfiguration mit dem gemeinsamen Datenmodell in dem erfindungsgemäßen Verfahren und/oder System. Im Unterschied zu der Anwendung in 11, wo GPS-Daten verwendet werden, wird hier eine Straßenbeschaffenheit auf der Basis eines beliebigen GNSS (Globales Navigationssatellitensystem) zur Verfügung gestellt.
Fahrzeugdaten können durch das CDM 13 abstrahiert und übertragen werden. Die Übertragung der Daten und Bewegung von Logiken kann auf OSI Layer 5-7 erfolgen. Gemäß 11-13 kann auch von sogenannten „Access Methods“ Gebrauch gemacht werden. Methoden sind Zugriffs- und Angebotsmechanismen, um auf Services du Daten zugreifen zu können. Ein Beispiel für eine solche Methode ist das „Fire & Forget“.
Obwohl die Erfindung im Detail durch bevorzugte Ausführungsbeispiele näher illustriert und erläutert wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Es ist daher klar, dass eine Vielzahl von Variationsmöglichkeiten existiert. Beispielhaft genannte Ausführungsformen stellen nur Beispiele dar, die nicht in irgendeiner Weise als Begrenzung etwa des Schutzbereichs, der Anwendungsmöglichkeiten oder der Konfiguration der Erfindung aufzufassen sind. Vielmehr versetzen die vorhergehende Beschreibung und die Figurenbeschreibung den Fachmann in die Lage, die beispielhaften Ausführungsformen konkret umzusetzen, wobei der Fachmann in Kenntnis des offenbarten Erfindungsgedankens vielfältige Änderungen beispielsweise hinsichtlich der Funktion oder der Anordnung einzelner, in einer beispielhaften Ausführungsform genannter Elemente vornehmen kann, ohne den Schutzbereich zu verlassen, der durch die Ansprüche und deren rechtliche Entsprechungen, wie etwa weitergehenden Erläuterungen in der Beschreibung, definiert wird.
Die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, beispielsweise das System mit seinen Komponenten wie in 1a dargestellt, können auch bei anderen Ausführungsformen der Erfindung, z. B. bei den erfindungsgemäßen Verfahren wie in 1b, 1c dargestellt, vorhanden sein, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet. Obwohl in Ausführungsbeispielen nur eine Auswahl von Ecosystemen gezeigt und beschrieben ist, können alle in der Anmeldung gezeigten oder beschriebenen Ecosysteme einmal oder mehrfach in jedem in der Anmeldung gezeigten oder beschriebenen Netzwerk 4 vorhanden sein, sofern es nicht explizit anders beschrieben ist oder technisch ausgeschlossen ist. Jedes in der Anmeldung gezeigte oder beschriebene Ecosystem kann je nach Anwendung erstes Ecosystem 1 oder zweites Ecosystem 2 sein. Jeder in der Anmeldung gezeigte oder beschriebene Service kann je nach Anwendung erster Service 5 oder zweiter Service 9 sein. Jede in der Anmeldung gezeigte oder beschriebene Funktionseinheit kann, sofern nicht zwingend einer anderen Komponente zugeordnet, in der Quality-of-Service-Koordinationseinheit 3 implementiert sein. Die Erfindung kann auch für Bewegungen von Logiken zu anderen Zwecken als zur Relokalisierung oder Rekonfiguration von Services anwendbar sein.
Soweit ein Fahrzeug beschrieben wird, umfasst der Begriff PKW, LKW, Busse, Wohnmobile, Krafträder, etc., die der Beförderung von Personen, Gütern, etc. dienen. Insbesondere umfasst der Begriff Kraftfahrzeuge zur Personenbeförderung. Ergänzend oder alternativ kann das Hybrid- oder Elektrofahrzeug gemäß Ausführungsformen ein reines Elektrofahrzeug (BEV) oder ein Plugin-Hybridfahrzeug (PHEV) sein. Es können jedoch auch andere Antriebsformen verwendet werden, beispielsweise in Form eines diesel- oder benzin- oder flüssiggas- oder brennstoffzellenbetriebenen Fahrzeugs. Das Fahrzeug kann auch in Form eines Schienenfahrzeugs vorliegen. Das Fahrzeug kann mit einem oder mehreren anderen Fahrzeugen und/oder einem Backend vernetzt sein. Die Art der Vernetzung kann drahtlos über Funk, WLAN, LTE, GSM oder über einen anderen drahtlosen Übertragungsstandard wie Bluetooth etc. erfolgen.

Claims

Computerimplementiertes Verfahren zum Bewegen einer Logik eines Service zwischen einem ersten Ecosystem (1) und einem zweiten Ecosystem (2) in einem Netzwerk (4) von Ecosystemen (21, 22, 23, 24, 31, 41, 42, 43, 44), wobei jedes Ecosystem (21, 22, 23, 24, 31, 41, 42, 43, 44) mehrere technische Subsysteme mit jeweils eigener Logik und eigener Datenbasis umfasst, umfassend die Schritte: - Empfangen (S1) einer Anfrage (18) bezüglich eines ersten Service (5) des ersten Ecosystems (1), - Identifizieren (S2) eines zweiten Ecosystems (2) in dem Netzwerk (4), welches Anforderungen des ersten Service (5) erfüllt, - Bewegen (S3; S5) einer ersten Logik (6) des ersten Service (5) des ersten Ecosystems (1) in das zweite Ecosystem (2) oder einer zweiten Logik (10) eines zweiten Service (9) des zweiten Ecosystems (2) in das erste Ecosystem (1), wobei die erste Logik (6) des ersten Service (5) und/oder die zweite Logik (10) des zweiten Service (9) ein dem ersten Ecosystem (1) und dem zweiten Ecosystem (2) gemeinsames Datenmodell (13) verwendet, welches über wenigstens das erste Ecosystem (1) und das zweite Ecosystem (2) verteilt ist und eine Datennachricht auf OSI-Layer 5-7 mit zumindest den Attributen Header mit Feld für Nachricht-ID, Payload mit Feldern für Zeitstempel, Beschreibungszeile, Wert, Einheit, Datentyp und QoS-Attribut umfasst.
Das computerimplementierte Verfahren nach Anspruch 1, wobei die erste Logik (6) des ersten Service (5) des ersten Ecosystems (1) in das zweite Ecosystem (2) bewegt wird (S3) und Daten aus dem gemeinsamen Datenmodell (13), die für das Bewegen der ersten Logik (6) und/oder für die Ausführung des ersten Service (5) in dem zweiten Ecosystem (2) benötigt werden, synchronisiert und kontinuierlich aktualisiert werden (S96), um eine Relokalisierung des ersten Service (5) von dem ersten Ecosystem (1) in das zweite Ecosystem (2) durchzuführen.
Das computerimplementierte Verfahren nach Anspruch 1 oder 2, wobei die Ausführung des ersten Service (5) in dem zweiten Ecosystem (2) betreffende Rohdaten (70) des ersten Ecosystems (1) an das zweite Ecosystem (2) übertragen werden.
Das computerimplementierte Verfahren nach Anspruch 1, wobei die zweite Logik (10) des zweiten Service (9) des zweiten Ecosystems (2) in das erste Ecosystem (1) bewegt wird (S5) und zum Identifizieren des zweiten Ecosystems (2) in dem Netzwerk (4) zusätzlich zu der Bedingung, dass das zweite Ecosystem (2) die Anforderungen des ersten Service (5) erfüllt (S4), das Identifizieren des zweiten Ecosystems (2) auch dahingehend erfolgt, dass das zweite Ecosystem (2) ein Service-Angebot aufweist, welches eine Funktion des ersten Service (5) in dem ersten Ecosystem (1) ausführen kann, und das Service-Angebot als der zweite Service(9) von dem zweiten Ecosystem (2) angefordert wird (S4), dessen zweite Logik (10) daraufhin von dem zweiten Ecosystem (2) in das erste Ecosystem (1) bewegt wird, um eine Rekonfiguration des ersten Service (5) in dem erste Ecosystem (1) durchzuführen.
Das computerimplementierte Verfahren nach Anspruch 4, wobei Daten aus dem gemeinsamen Datenmodell (13), die für das Bewegen der zweiten Logik (10) und/oder für die Ausführung des zweiten Service (9) in dem ersten Ecosystem (1) benötigt werden, synchronisiert und bis zum Abschluss der Rekonfiguration aktualisiert werden (S97).
Das computerimplementierte Verfahren nach einem der vorstehenden Ansprüche, wobei das Identifizieren (S2) des zweiten Ecosystems (2) die Schritte umfasst: - Prüfen der Anforderungen des ersten Service (5) in der Vielzahl von Ecosystemen (21, 22, 23, 24,31, 41, 42, 43, 44), - Bestimmen wenigstens eines Ecosystems der Vielzahl von Ecosystemen (21, 22, 23, 24, 31, 41, 42, 43, 44) als Kandidaten-Ecosystem, wenn das eine Ecosystem die Anforderungen des ersten Service (5) erfüllt, und - wenn mehrere Kandidaten-Ecosysteme bestimmt wurden: Auswählen eines Ecosystems als das zweite Ecosystem (2) aus den Kandidaten-Ecosystemen, oder - wenn ein einziges Kandidaten-Ecosystem bestimmt wurde: Auswählen des Kandidaten-Ecosystems als das zweite Ecosystem (2).
Das computerimplementierte Verfahren nach Anspruch 6, wobei das Auswählen aus den mehreren Kandidaten-Ecosystemen die Schritte umfasst: - Bewerten der mehreren Kandidaten-Ecosystem hinsichtlich Auswahlkriterien (25), und - Auswählen desjenigen Kandidaten-Ecosystems als das zweite Ecosystem (2), welches die Auswahlkriterien (25) am besten erfüllt.
Das computerimplementierte Verfahren nach Anspruch 6 oder 7, soweit auf Anspruch 4 oder 5 rückbezogen, wobei das Prüfen der Anforderungen des ersten Service (5) die Prüfung umfasst, ob das eine Ecosystem ein geeignetes Service-Angebot aufweist.
Das computerimplementierte Verfahren nach Anspruch 8, wobei das Auswählen aus den mehreren Kandidaten-Ecosystemen die Schritte umfasst: - Bewerten der Service-Angebote hinsichtlich Auswahlkriterien (25), und - Auswählen desjenigen Kandidaten-Ecosystems mit dem Service-Angebot, welches die Auswahlkriterien (25) am besten erfüllt, als das zweite Ecosystem (2).
Das computerimplementierte Verfahren nach einem der vorstehenden Ansprüche, wobei der erste Service (5) und/oder der zweite Service (9) die Verarbeitung von Sensordaten als Rohdaten (70) umfasst.
Das computerimplementierte Verfahren nach einem der vorstehenden Ansprüche, wobei die erste Logik (6) und/oder die zweite Logik (10) betreffende Daten über eine Service-Schicht (81) übertragen werden und die Ausführung des ersten Service (5) und/oder des zweiten Service (9) betreffende Rohdaten über eine Datenschicht (83) übertragen werden.
Das computerimplementierte Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren durch eine das erste Ecosystem (1) und das zweite Ecosystem (2) verbindende Quality-of-Service-Koordinationseinheit (3) durchgeführt wird.
System zum Bewegen einer Logik eines Service zwischen einem ersten Ecosystem (1) und einem zweiten Ecosystem (2) in einem Netzwerk (4) von Ecosystemen (21, 22, 23, 24, 31, 41, 42, 43, 44), wobei jedes Ecosystem (1, 2) mehrere technische Subsysteme mit jeweils eigener Logik und eigener Datenbasis umfasst, umfassend eine Quality-of-Service-Koordinationseinheit (3) mit: - einer Empfangseinheit (14) zum Empfangen einer Anfrage (18) bezüglich eines ersten Service (5) des ersten Ecosystems (1), - einer Identifikationseinheit (15) zum Identifizieren eines zweiten Ecosystems (2) in dem Netzwerk (4), welches Anforderungen des ersten Service (5) erfüllt, und - einer Bewegungseinheit (16) zum Bewegen der ersten Logik (6) des ersten Service (5) des ersten Ecosystems (1) in das zweite Ecosystem (2) oder einer zweiten Logik (10) des zweiten Service (9) des zweiten Ecosystems (2) in das erste Ecosystem (1), wobei die erste Logik (6) des ersten Service (5) und/oder die zweite Logik (10) des zweiten Service (9) ein dem ersten Ecosystem (1) und dem zweiten Ecosystem (2) gemeinsames Datenmodell (13) aufweist, welches über wenigstens das erste Ecosystem (1) und das zweite Ecosystem (2) verteilt ist und eine Datennachricht auf OSI-Layer 5-7 mit zumindest den Attributen Header mit Feld für Nachricht-ID, Payload mit Feldern für Zeitstempel, Beschreibungszeile, Wert, Einheit, Datentyp und QoS-Attribut umfasst.
Computerprogramm mit Programmcode, um das Verfahren nach einem der Ansprüche 1 bis 12 durchzuführen, wenn das Computerprogramm auf einem Computer ausgeführt wird.
Computerlesbarer Datenträger mit Programmcode eines Computerprogramms, um das Verfahren nach einem der Ansprüche 1 bis 12 durchzuführen, wenn das Computerprogramm auf einem Computer ausgeführt wird.