-
Die vorliegende Erfindung betrifft ein Verfahren zum Anpassen einer Softwareanwendung. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
DE102017204212A1 offenbart ein Verfahren zum Verwalten von Applikationen für Fahrzeuge mittels eines Back-Ends, bei welchem Ressourcenangebote der Fahrzeuge und Anforderungsprofile der Applikationen auf dem Back-End hinterlegt werden, dort ein Fahrzeug unter den hinterlegten Fahrzeugen identifiziert sowie ein Abgleich der Ressourcenangebote des Fahrzeuges gegen die Anforderungsprofile durchgeführt und schließlich eine anhand des Abgleiches unter den Applikationen ausgewählte Applikation vom Back-End an das Fahrzeug übertragen wird.
-
DE102006016039A1 betrifft ein Kommunikationssystem, insbesondere für ein Kraftfahrzeug, mit einer Übertragungsstrecke, über die mehrere logische Verbindungen realisiert werden können, wobei die Übertragungsstrecke mindestens zwei Teilstrecken mit jeweils begrenzter Übertragungskapazität umfasst, mit mehreren lokalen Kommunikationsverwaltungen, wobei jede der lokalen Kommunikationsverwaltungen jeweils einer der mindestens zwei Teilstrecken zugeordnet ist und jeder der auf der zugeordneten Teilstrecke realisierten logischen Verbindungen eine bestimmte Übertragungskapazität zuweist, und mit einer globalen Kommunikationsverwaltung, welche ausgelegt ist, die Zuweisung von Übertragungskapazitäten durch die lokalen Kommunikationsverwaltungen nach einem vorgegebenen Schema zu koordinieren.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Anpassen einer Softwareanwendung, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Der erfindungsgemäße Ansatz fußt hierbei auf der Erkenntnis, dass eine Softwarekomponente bzw. -anwendung (application, app) gewisse Anforderungen an ein Netzwerk stellt, die eingehalten werden sollten, um ihre ordnungsgemäße Funktion - bei hinreichender Leistung bzw. Dienstgüte (quality of service, QoS) und ggf. unter Einhaltung anderweitiger Betriebsbedingungen - zu gewährleisten. Hierzu können bestimmte QoS-Parameter von der Applikation an das Netzwerkmanagement übergeben werden, welches die Einhaltung dieser Parameter sicherstellt. Dies kann einmalig im Rahmen der Planung geschehen oder in dynamischen und insbesondere softwaredefinierten Netzen (softwaredefined networks, SDN) auch zur Laufzeit der Applikation. In diesem Fall ist der Informationsfluss herkömmlicherweise von der Funktion bzw. Anwendung zum Netzwerkmanagement gerichtet: Eine Anwendung stellt „harte“ Anforderungen, und diese sind vom Netzwerkmanagement in Gänze umzusetzen oder abzulehnen. In dynamischen Netzwerken, z. B. in Fahrzeugen oder in der Industrieautomatisierung, ändern sich die zur Verfügung stehenden Ressourcen aber häufig mit dem Betriebszustand. Zudem sind viele Applikationen prinzipiell in der Lage, in Abhängigkeit zur Verfügung stehender Ressourcen auf unterschiedlichen Dienstgüteniveaus (service levels) ordnungsgemäß zu funktionieren: Eine Videokamera kann z. B. bei Bedarf mit geringerer Auflösung und Datenrate senden. Diagnosefunktionen im Fahrzeug, die Informationen zur Fehlersuche (debugging) oder Daten zum Flottenlernen (fleet learning) erfassen, können im Wesentlichen beliebige Datenraten verwenden, ohne die Fahrfunktionen zu beeinflussen, solange die Busse im Fahrzeug nicht überlastet werden.
-
Das vorgeschlagene Verfahren beruht in anderen Worten auf der Einsicht, dass Netzwerkressourcen im Fahrzeug herkömmlicherweise statisch konfiguriert und zum Zeitpunkt der Herstellung in ihrer Zuteilung festgelegt werden. Dies beinhaltet im Falle bestimmter Übertragungsverfahren, z. B. einer CAN-Kommunikation (controller area network, CAN), auch die Priorisierung der Nachrichten untereinander. Eine dynamische (Re-)Konfiguration ist in solchen konventionellen Rechnernetzen in der Regel nicht vorgesehen. In dynamischen Netzen hingegen ist die Kommunikation zwischen Anwendung und Netzwerkmanagement beschränkt: QoS-Anforderungen seitens der Anwendung können vom Netzwerkmanagement entweder umgesetzt oder abgelehnt werden. Die Anwendung verfügt hierbei über keinerlei Erkenntnisse hinsichtlich des Netzes, und ein Aushandeln beispielsweise der Datenauflösung ist nicht vorgesehen.
-
Die erfindungsgemäße Lösung trägt ferner dem Umstand Rechnung, dass in für die Betriebssicherheit (safety) kritischen Anwendungen möglicherweise verschiedenen Klassen von Datenflüssen (flows) vorkonfiguriert sind. Im Kontext zeitkritischer Vernetzung (time-sensitive networking, TSN) kann eine Trennung der Ressourcen über einen Scheduling-Mechanismus wie den sogenannten Time-Aware Shaper nach IEEE 802.1Qbv erfolgen. Wenn Apps verschiedenen Flüssen dynamisch zugeordnet werden, stehen bei hoher Netzwerkauslastung möglicherweise keine Ressourcen mehr zur Verfügung, welche die optimale Dienstgüte gewährleisten könnten. Damit kann in klassischen Systemen eine Funktion gar nicht genutzt werden. Es sind zwar Applikationen - zum Beispiel Videostreaming mit DASH - bekannt, die sich in nicht zentral gesteuerten Netzen auf eine veränderte Betriebssituation einstellen und z. B. bei verminderter Bandbreite auf einen Modus mit geringerer Datenrate zurückgreifen. Diese Applikationen reagieren aber erst, nachdem es bereits zu Fehlern wie Paketverlusten oder Zeitüberschreitungen (timeouts) gekommen ist, während eine Ausführungsform der Erfindung eine sozusagen proaktive Anpassung erlaubt.
-
Eine Ausführungsform der Erfindung erweitert hierzu den Informationsaustausch zwischen dem SDN-Controller und den Applikationen: Eine gleichsam „SDN-bewusste“ App kann vom Controller Teilinformationen über den Zustand des Rechnernetzes empfangen, z. B. die zur Verfügung stehende Bandbreite oder Latenzen der Verbindung zu bestimmten Kommunikationspartnern. Auf Grund dieser Informationen kann die App ihr Dienstgüteniveau derart anpassen, dass ein maximaler Nutzen erzielt wird, ohne die Netzwerkinfrastruktur zu überlasten. Eine erfindungsgemäße App stellt also nur QoS-Anforderungen an das Netz, die erfüllt werden können. Zudem kann die Ressourcennutzung zur Laufzeit situationsabhängig angepasst werden. Insgesamt erlaubt dieses Vorgehen eine bessere Ausnutzung der etwa in einem Fahrzeug zur Verfügung stehenden Bandbreite.
-
Ein Vorzug dieser Lösung liegt darin, dass der Controller, anstatt die Bandbreite einer Anwendung über eine Infrastruktur-Komponente zu begrenzen, die geänderte Bandbreitenzuweisung auf höheren Abstraktionsschichten vornehmen kann. Während etwa eine externe Bandbreitenbegrenzung in einer Infrastruktur-Komponente bei Protokollen wie UDP ohne Flusskontrolle bestimmte Funktionen wie das Videostreaming durch das Verwerfen von Paketen erheblich stören oder deren Nutzung unmöglich machen kann, weiß die vorliegende Lösung dies zu verhindern. Die Anwendung passt ihre Anforderungen hierzu den verfügbaren Ressourcen - z. B. durch eine geeignete Auflösung von Bild- oder Video-Daten oder Anpassung der Zykluszeiten - an und vermeidet hierdurch eine Überlastung, bevor diese entsteht. Die Ressourcen im Netz werden so besser ausgenutzt.
-
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.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Blockdiagramm eines Rechnernetzes.
- 2 das Flussdiagramm eines erfindungsgemäßen Verfahrens.
- 3 bis 5 detaillierte Sequenzdiagramme des Verfahrens.
-
Ausführungsformen der Erfindung
-
1 illustriert beispielhaft eine mögliche Netzwerkarchitektur und beinhaltet folgende Elemente: einen SDN Controller (1), verschiedene Infrastrukturkomponenten - z. B. Ethernet-Switches (2, 3) sowie CAN-Weiterleitungsgeräte (forwarding devices, FD) oder Router (7, 8, 10) -, Netzwerkknoten (4, 5, 9, 12, 14) und Apps (6, 11, 13, 15). Hierbei ist zu beachten, dass der SDN-Controller (1) nicht zwangsweise ein eigenständiges Element sein muss, sondern beispielsweise auch Teilelement eines anderen Bausteins oder auf mehrere Elemente verteilt sein kann. Im Rahmen der vorliegenden Ausführungsform kooperieren SDN-Controller (1), Infrastrukturkomponenten (31) und Apps (6, 11, 13, 15).
-
2 zeigt beispielhaft den Ablauf einer Konfiguration: Zu Beginn des Ablaufs fordert eine App beim SDN-Controller (1 - 1) Kommunikationsressourcen an (21). Der SDN-Controller (1) prüft daraufhin, ob die angefragten Ressourcen im Rahmen der derzeitigen Konfiguration zur Verfügung stehen (22). Im Folgenden kann es zu einer Verhandlung bzgl. der gewährten Ressourcen zwischen dem SDN-Controller (1) und der App kommen (23). Mit Abschluss dieser Verhandlung kann das System auf die neuen Kommunikationsbeziehungen vorbereitet werden: Hierzu werden - gesteuert durch den SDN-Controller (1) - sowohl die Konfiguration der Infrastrukturkomponenten (2, 3, 7, 8, 10 - 1) als auch die der App angepasst (24). In einem abschließenden Schritt (25) wird der Kommunikationsbetrieb im Rechnernetz (10) mit der neuen Konfiguration aufgenommen.
-
3 zeigt den Ablauf nochmals im Detail und weist potenzielle Alternativen aus. Hierbei wird zwischen den drei bereits genannten Einheiten unterschieden: dem SDN-Controller (1), den Infrastrukturkomponenten - hier vereinfacht als Gruppe (31) zusammengefasst - sowie der App (32). Der Ablauf beginnt damit, dass der SDN-Controller (1) die Infrastrukturkomponenten (31) initial konfiguriert (33), um den Netzwerkbetrieb zu beginnen. Im weiteren Verlauf überwacht (36) der SDN-Controller (1) den Kommunikationsverkehr und fragt hierzu auch aktuelle Statusinformationen von den einzelnen Elementen (31) der Netzwerkinfrastruktur ab (37).
-
Im Weiteren sind in 3 drei Varianten (41, 42, 43) dargestellt, gemäß denen die App (32) ihre Einbindung in das Kommunikationsnetz (10 - 1) initiieren kann.
-
Eine erste Variante (41) zeigt den einfachen Positiv-Fall: Die App (32) fordert Kommunikationsressourcen an (21), was den SDN-Controller (1) dazu veranlasst, eine Prüfung (22) daraufhin vorzunehmen, ob die gewünschten Kommunikationsressourcen in der derzeitigen Konfiguration noch frei sind. Im positiven Falle berechnet der SDN-Controller (1) eine neue Konfiguration und stellt die betroffenen Infrastrukturkomponenten (31) auf diese um (24). Im nächsten Schritt informiert der SDN-Controller (1) die anfragende App (32) von der Zuteilung (45) der Ressourcen, sodass diese mit der Kommunikation beginnen kann.
-
Eine zweite Variante (42) betrifft den Fall, dass die gewünschten Ressourcen nicht zur Verfügung gestellt werden können. Auch hier fordert die App (32) zunächst Ressourcen beim SDN-Controller (1) an (21), welcher die Verfügbarkeit dieser Ressourcen prüft (22). Da diese im vorliegenden Fall jedoch nicht vollständig zur Verfügung stehen (51), berechnet der SDN-Controller (1), welche Rest-Ressourcen verfügbar sind und stellt der App (32) diese Information zur Verfügung (56). Die App (32) prüft nun ihrerseits (47), ob sie auch mit diesen beschränkten Ressourcen ihre Funktion oder zumindest eine reduzierte Teilfunktion erfüllen kann. Ist dies der Fall, so stellt die App (32) eine neue Anfrage unter Angabe der reduzierten Ressourcenanforderung (21). Auch diese Anfrage (21) wird vom SDN-Controller (1) geprüft (22) und führt dazu, dass eine neue Netzwerkkonfiguration berechnet und die Infrastrukturkomponenten (31) auf diese umgestellt werden (24). Abschließend informiert der SDN-Controller (1) die anfragende App (32) von der Zuteilung (45) der Ressourcen, sodass diese App (32) ihre Funktionalität aktivieren kann.
-
Eine dritte Variante (43) betrifft den Fall, dass die von der App (32) gewünschten Ressourcen nicht vollumfänglich zur Verfügung stehen. Hier umfasst die Anfrage (21) der App (32) an den SDN-Controller (1) eine priorisierte Liste von für die App (32) akzeptablen Ressourcen-Sets. Dabei enthält das Ressourcen-Set mit der höchsten Priorität üblicherweise alle für einen uneingeschränkten Vollbetrieb der App (32) notwendigen Ressourcen, während niedriger priorisierte Ressourcen-Sets lediglich eine Teilfunktionalität der App (32) erlauben. Im nächsten Schritt prüft (22) der SDN-Controller (1) die Verfügbarkeit von Ressourcen und wählt (44) das am höchsten priorisierte, darstellbare Ressourcen-Set (55) der Anfrage aus. Unter Nutzung des ausgewählten Ressourcen-Sets berechnet der SDN-Controller (1) eine neue Netzwerkkonfiguration und stellt die Infrastrukturkomponenten (31) auf diese um (24). Abschließend informiert der SDN-Controller (1) die App (32) von der Zuteilung (45) des gewählten Ressourcen-Sets (55), woraufhin diese den Betrieb (25 - 2) - zumindest im technisch möglichen Teilumfang - aufnehmen kann.
-
Die 4 und 5 zeigen Rekonfigurationen, welche als Reaktion auf bestimmte Ereignisse (49) eingeleitet werden. Hierbei stellt der in 4 dargestellte Ablauf die Reaktion eines Systems gemäß der zweiten Variante (42 - 3) dar, der in 5 dargestellte Ablauf dagegen jene eines System gemäß der dritten Variante (43 - 3) dar.
-
In 4 beginnt der Ablauf mit dem Eintreten eines vorgegebenen Ereignisses (49). Dieses kann beispielsweise dadurch verwirklicht sein, dass das Monitoring-System ein vom Plan abweichendes Kommunikationsverhalten feststellt, ein Angriffserkennungssystem (intrusion detection system, IDS) einen Angriff detektiert oder ein Teilsystem ausfällt. Im Falle des Eintretens eines solchen Ereignisses (49) überprüft (22) der SDN-Controller (1) die zur Verfügung stehenden Ressourcen erneut. Ergibt diese Prüfung (22) eine eingeschränkte oder anderweitig veränderte Ressourcenverfügbarkeit (51) für eine oder mehrere Apps, so informiert der SDN-Controller (1) die betroffene App (32) von der Rücknahme der Ressourcenzuweisung (46). Diese stellt daraufhin ihren Betrieb (25 - 2) vorrübergehend ein und sendet eine erneute Anfrage (21) an den SDN-Controller (1), welche dieser abermals überprüft (22). Bei hinreichender Deckung des Ressourcenbedarfes berechnet der SDN-Controller (1) eine neue Netzwerkkonfiguration, stellt die Infrastruktur auf diese um (24) und informiert die App (32) von der Zuteilung (45). Auch die App (32) rekonfiguriert (24) sich daraufhin und nimmt ihre (Teil-)Funktionalität wieder auf (50).
-
Gemäß der in 5 dargestellten Alternative beginnt der Ablauf mit den gleichen Schritten wie in 4, also der Überprüfung (22) der zur Verfügung stehenden Ressourcen in Reaktion auf ein die Rekonfiguration (24) auslösendes Ereignis (49). Da dem SDN-Controller (1) in diesem Fall jedoch die für die App (32) akzeptablen Ressourcen-Sets bereits bekannt sind, kann dieser direkt das am höchsten priorisierte Ressourcen-Set (55), welches derzeit verfügbar ist, für die App (32) auswählen (44). Abschließend informiert der SDN-Controller (1) die App (32) von der Zuteilung (45) der Ressourcen. Die App (32) nimmt daraufhin eine Rekonfiguration (24) vor und startet ihre (Teil-)Funktion neu (50).
-
Dieses Verfahren (20, 30) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert 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 102017204212 A1 [0002]
- DE 102006016039 A1 [0003]
