DE102019206923B3 - Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur - Google Patents

Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur Download PDF

Info

Publication number
DE102019206923B3
DE102019206923B3 DE102019206923.1A DE102019206923A DE102019206923B3 DE 102019206923 B3 DE102019206923 B3 DE 102019206923B3 DE 102019206923 A DE102019206923 A DE 102019206923A DE 102019206923 B3 DE102019206923 B3 DE 102019206923B3
Authority
DE
Germany
Prior art keywords
application
application server
input data
time
app
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102019206923.1A
Other languages
English (en)
Inventor
Wolfgang Theimer
Jithin Reju
Rolf Schuster
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Priority to DE102019206923.1A priority Critical patent/DE102019206923B3/de
Priority to US15/930,087 priority patent/US11363120B2/en
Priority to KR1020200056472A priority patent/KR102287566B1/ko
Priority to CN202010401676.7A priority patent/CN111930494A/zh
Application granted granted Critical
Publication of DE102019206923B3 publication Critical patent/DE102019206923B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/502—Proximity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Ausführen einer Anwendung (APP) auf einer verteilten Systemarchitektur (100), aufweisend: einen, insbesondere mobilen, Anwendungs-Client (10) zum Empfangen von Eingangsdaten und zum Bereitstellen von Ausgangsdaten (f(t)) basierend auf bearbeiteten Eingangsdaten, einen lokalen Anwendungs-Server (21) am Anwendungs-Client (10) und mindestens einen entfernten Anwendungs-Server (22) zum Empfangen von Eingangsdaten von dem Anwendungs-Client (10), zum Bearbeiten von Eingangsdaten für den Anwendungs-Client (10) und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client (10), und einen Anwendungs-Manager (30) zum Zuordnen der Anwendung (APP) zu dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22). Hierzu ist es erfindungsgemäß vorgesehen, dass das Verfahren folgende Schritte aufweist:- Bestimmen einer ersten Umlaufzeit (RTT1) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server (21),- Bestimmen einer zweiten Umlaufzeit (RTT2) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server (22),- Bestimmten einer Toleranzzeit (Δtmax) zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung (APP),- Vergleichen der ersten Umlaufzeit (RTT1) und der zweiten Umlaufzeit (RTT2) mit der Toleranzzeit (Δtmax),- Zuordnen der Anwendung (APP) zu dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) in Abhängigkeit von dem Vergleich.

Description

  • Die Erfindung betrifft ein Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur nach dem Oberbegriff eines unabhängigen Verfahrensanspruches sowie eine entsprechende verteilte Systemarchitektur nach dem Oberbegriff eines unabhängigen Systemanspruches.
  • Mit dem Aufkommen der mobilen Kommunikation und des Cloud Computing ist es nicht mehr erforderlich, dass die Verarbeitung von Daten für Anwendungen auf einem mobilen Gerät selbst, bspw. einem Fahrzeug oder einer anderen Benutzervorrichtung, stattfindet. Aufgrund der höheren Rechenleistung kann es vorteilhaft sein, entfernte Ressourcen, wie z. B. Cloud-Ressourcen und/oder Edge-Cloud-Ressourcen, für die Verarbeitung von Daten zu nutzen, auch wenn die Kommunikation mit den entfernten Ressourcen Zeit und Energie benötigt. Der Benutzer muss dabei entscheiden, ob das lokale Computing auf dem mobilen Gerät selbst, z.B. in einem Fahrzeug, genutzt wird oder ob die Berechnung auf einem mobilen Edge-Server in der Nähe des mobilen Geräts oder in einem Cloud-Rechenzentrum weiter weg vom mobilen Gerät durchgeführt wird. Diese Entscheidung sollte möglichst automatisch erfolgen, um den Benutzerkomfort nicht zu beeinträchtigen. Zudem muss bei mobilen Geräten eine Übergabe zwischen den benachbarten Edge-Servern während der Bewegung der mobilen Geräte möglichst automatisch erfolgen.
  • Eine Einbeziehung von Netzwerken in Cluster-Umgebungen ist im Allgemeinen aus der Schrift Xiao Qin et al.: „Communication-Aware Load Balancing for Parallel Applications on Clusters“, In: IEEE Transactions on Computers, Vol. 59, Jan. 2010, pp. 42 - 52 bekannt.
  • Derzeit werden Anwendungen nach ihrer Priorisierung entweder einem lokalen Anwendungs-Server oder einem entfernten Anwendungs-Server zugeordnet, wie dies die Druckschrift EP 3 425 873 A1 beispielhaft zeigt. Dabei werden Anwendungen als zeitkritisch oder normal eingestuft. Gemäß der Priorisierung kriegen sie eine feste Zuordnung zum lokalen oder entfernten Anwendungs-Server. Eine solche Zuordnung ist jedoch starr und unflexibel, was zu Komforteinbußen bei mobilen Anwendungen führen kann.
  • Die Aufgabe der Erfindung ist es daher, ein verbessertes Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur bereitzustellen. Insbesondere ist es die Aufgabe der Erfindung, ein Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur zur Verfügung zu stellen, welches eine flexible, anpassungsfähige und komfortable Zuordnung von Anwendungen an verfügbare Ressourcen innerhalb der verteilten Systemarchitektur ermöglicht. Zudem ist es die Aufgabe der Erfindung, eine entsprechende verteilte Systemarchitektur bereitzustellen.
  • Die erfindungsgemäße Aufgabe wird durch ein Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur mit den Merkmalen des unabhängigen Verfahrensanspruches, insbesondere aus dem kennzeichnenden Teil, gelöst. Zudem wird die erfindungsgemäße Aufgabe durch eine entsprechende verteilte Systemarchitektur mit den Merkmalen des unabhängigen Systemanspruches, insbesondere aus dem kennzeichnenden Teil, gelöst. In den abhängigen Ansprüchen sind bevorzugte Weiterbildungen der Erfindung aufgeführt. Merkmale, die zu den einzelnen Erfindungsaspekten offenbart werden, können in der Weise miteinander kombiniert werden, dass bezüglich der Offenbarung zu den Erfindungsaspekten der Erfindung stets wechselseitig Bezug genommen wird bzw. werden kann.
  • Die Erfindung stellt ein Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur bereit, aufweisend:
    • - einen, insbesondere mobilen, Anwendungs-Client (z. B. in einer Benutzervorrichtung, bspw. in einem mobilen Gerät, Mobiltelefon, Smartphone, Laptop, Fahrzeug-Steuergerät, Navigationseinheit, Infotainmentsystem usw.) zum Empfangen von Eingangsdaten (bspw. Sensordaten) und zum Bereitstellen von Ausgangsdaten (bspw. Aktuatoreinstellungen) basierend auf bearbeiteten Eingangsdaten,
    • - einen lokalen Anwendungs-Server (lokale Recheneinheit) am Anwendungs-Client und mindestens einen entfernten Anwendungs-Server (Cloud-Server sowie ein oder mehrere Edge-Cloud-Server) zum Empfangen von Eingangsdaten von dem Anwendungs-Client, zum Bearbeiten von Eingangsdaten für den Anwendungs-Client und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client sowie
    • - einen Anwendungs-Manager (lokales Steuergerät) zum Zuordnen der Anwendung (bzw. zumindest einer Rechenaufgabe zum Bearbeiten von Eingangsdaten für die Anwendung) zu dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server.
  • Hierzu ist es erfindungsgemäß vorgesehen, dass das Verfahren folgende Schritte aufweist:
    • - Bestimmen einer ersten Umlaufzeit zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server (und ggf. zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client),
    • - Bestimmen einer zweiten Umlaufzeit zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server (und ggf. zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client),
    • - Bestimmen einer, insbesondre maximal zulässigen, Toleranzzeit zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung (und ggf. zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client),
    • - Vergleichen der ersten Umlaufzeit und der zweiten Umlaufzeit mit der Toleranzzeit,
    • - Zuordnen der Anwendung zu dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server in Abhängigkeit von dem Vergleich.
  • Die Erfindung erkennt dabei, dass alle Anwendungen unterschiedlich sind. Sie haben unterschiedliche Geschwindigkeiten und unterschiedliche (zulässige und/oder tolerierbare) Reaktionszeiten, je nach Art der erforderlichen Bearbeitung bzw. Berechnung. Die Erfindung gilt vorteilhafterweise für alle Bereiche, in denen die lokal verfügbaren Rechenressourcen begrenzt sind. Einige der Anwendungen umfassen Automotive, Drohnen, kognitive Anwendungen usw. Die Ergebnisse der Bearbeitung auf entfernten Anwendungs-Servern, wie z. B. auf einem zentralen Cloud-Server und/oder auf einem oder mehreren Edge-Cloud-Servern, sind grundsätzlich besser als die der lokalen Berechnung, da die Hardware-Ressourcen auf entfernten Anwendungs-Servern besser sind, wobei die lokalen Rechenressourcen zumeist begrenzt sind.
  • Der Erfindungsgedanke liegt dabei darin, dass es für alle Arten von Anwendungen möglich ist, eine Toleranzzeit zum Empfangen und zum Bearbeiten von Eingangsdaten oder anders ausgedrückt einen Latenzschwellenwert bzw. eine Umlaufzeit (sog. Round-Trip-Zeit, RTT) als Übergabekriterium zu verwenden, um die effizienteste Berechnungsumgebung für die konkrete Anwendung auszuwählen. Die Toleranzzeit bzw. die Umlaufzeit oder die Round-Trip-Zeit ist die Dauer, von der das lokale Gerät (d. h. Anwendungs-Client) eine Anforderung, umfassend Sensor-Rohdaten (d. h. Eingangsdaten), an einen verfügbaren Anwendungs-Server (lokal oder entfernt) sendet, bis hin zum Empfang der berechneten Ergebnisse von dem Anwendungs-Server. Die Toleranzzeit bzw. die Umlaufzeit beinhaltet somit die Wartezeit (sog. Latenz) und die Rechenzeit am verfügbaren Anwendungs-Server. Im Rahmen der Erfindung ist die explizite Berücksichtigung des Durchsatzes innerhalb des Netzwerkes nicht erforderlich, damit die Übergabe-Entscheidung getroffen werden kann, da diese Information in der Toleranzzeit bereits abgebildet ist. Die Toleranzzeit bzw. die Umlaufzeit ist ein einfacher einzelner Parameter, den der Entwickler bei dem Entwickeln einer Anwendung einstellen kann. Im Rahmen der Erfindung ist es möglich, die Toleranzzeit bzw. die Umlaufzeit als einen statischen oder als einen adaptiven Schwellenwert einzustellen, darauf wird im Nachfolgenden im Einzelnen Bezug genommen. Die Dynamik der Anwendung kann im Rahmen der Erfindung einmalig vor dem Start und/oder während der Laufzeit der Anwendung gemessen werden, woraufhin die Toleranzzeit adaptiv geändert werden kann. Langsame Änderungen in der Anwendung können im Rahmen der Erfindung zu hohen Schwellenwerten führen, während schnelle Änderungen in der Anwendung zu niedrigeren Schwellenwerten führen können. Im Rahmen der Erfindung kann weiterhin die Benutzererfahrung und/oder die von der Anwendung definierten Qualitätskriterien beim Bestimmen der Toleranzzeit berücksichtigt werden.
  • Die verteilte Systemarchitektur im Rahmen der Erfindung basiert auf drei Säulen:
    • - Der Anwendungs-Client fungiert im Rahmen der Erfindung als ein Frontend. Er liest Eingangsdaten (bspw. Sensorinformationen) aus und stellt Ausgangsdaten (bspw. Stellgliedausgänge) zur Verfügung.
  • Dabei kann der Anwendungs-Client als eine Mensch-Maschine-Schnittstelle, sog. HMI, betrachtet werden. Die Anwendungs-Client weist ein lokal verfügbares Rechengerät (lokaler Anwendungs-Server) auf, auf dem die Anwendung ablaufen kann.
  • Der Anwendungs-Server (lokal oder entfernt) ist ein Rechenmodul zur Verarbeitung von Eingangsdaten (bspw. von Sensoren) und zum Ausgeben von bearbeiteten Eingangsdaten, bspw. in Form von Ausgangsdaten (bspw. Stellwerte für korrespondierende Aktoren).
  • Der Anwendungs-Server kann lokal dort vorgesehen sein, wo sich der Anwendungs-Client befindet. Es kann auch auf einen Edge-Cloud-Server oder in ein größeres Rechenzentrum in der Cloud verschoben werden. Im Rahmen der Erfindung kann der Anwendungs-Server mindestens einen lokalen Anwendungs-Server sowie mehrere entfernte Anwendungs-Server aufweisen. Die mehrere entfernte Anwendungs-Server können wiederum mehrere (auch wechselnde) Edge-Cloud-Server und mindestens einen zentralen Cloud-Server umfassen.
  • Der Anwendungs-Manager ist eine Einheit, die basierend auf den erfindungsgemäßen Regeln bzw. auf dem erfindungsgemäßen Verfahren entscheidet, wo die Eingangsdaten bearbeitet werden.
  • Ferner kann die Erfindung bei einem Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur vorsehen, dass die Anwendung dem lokalen Anwendungs-Server zugeordnet wird, wenn die erste Umlaufzeit unterhalb der Toleranzzeit liegt. Vorteilhafterweise kann die Anwendung erfolgreich direkt auf dem lokalen Anwendungs-Server ausgeführt werden, wenn die erste Umlaufzeit die Toleranzzeit nicht überschreitet.
  • Weiterhin kann die Erfindung bei einem Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur vorsehen, dass die Anwendung dem mindestens einen entfernten Anwendungs-Server zugeordnet wird, wenn die zweite Umlaufzeit unterhalb der Toleranzzeit liegt. Hierbei kann die Anwendung dem mindestens einen entfernten Anwendungs-Server zugeordnet werden, wenn die erforderliche Wartezeit und die Bearbeitungszeit auf dem mindestens einen entfernten Anwendungs-Server im Rahmen der zweiten Umlaufzeit die Toleranzzeit nicht überschreitet.
  • Des Weiteren kann die Erfindung bei einem Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur vorsehen, dass das Zuordnen der Anwendung dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server in Anhängigkeit von mindestens einer Bedingung durchgeführt wird, wenn die erste Umlaufzeit und die zweite Umlaufzeit unterhalb der Toleranzzeit liegen. Mithilfe der Bedingung kann eine Zuordnung bei den Fällen durchgeführt werden, wenn beide oder mehrere Anwendungs-Server die bearbeiteten Eingangsdaten innerhalb der Toleranzzeit bereitstellen können.
  • Zudem ist es denkbar, dass die mindestens eine Bedingung mindestens eine folgende Information umfassen kann, wie: Benutzerpräferenzen, Erfahrungsdaten und/oder Anwendungs-Performance. Z. B. ist es denkbar, dass die entfernte (Edge-)Cloud-Lösung bevorzugt werden kann, wenn beide oder mehrere Anwendungs-Server die bearbeiteten Eingangsdaten innerhalb der Toleranzzeit bereitstellen können.
  • Im Rahmen der Erfindung ist es außerdem möglich, dass die Toleranzzeit einen statischen Schwellenwert umfasst. Somit kann die Toleranzzeit einmalig und/oder mit wenig Aufwand, bspw. von einem Anwendungs-Entwickler, bestimmt werden.
  • Ferner kann die Erfindung vorsehen, dass der statische Schwellenwert als ein Mittelwert von der ersten Umlaufzeit und der zweiten Umlaufzeit für eine Vielzahl an Anfragen zum Bearbeiten von Eingangsdaten ermittelt wird. Somit kann ein plausibler Schwellenwert zum Bestimmen der Toleranzzeit aus einer Vielzahl von Anfragen berechnet werden.
  • Weiterhin ist es im Rahmen der Erfindung denkbar, dass der statische Schwellenwert durch eine Vermessung der verteilten Systemarchitektur bestimmt wird. Somit kann ein plausibler Schwellenwert zum Bestimmen der Toleranzzeit für die jeweilige verteilte Systemarchitektur berechnet werden, auch wenn die Vermessung nur einmal durchgeführt wird.
  • Des Weiteren ist es im Rahmen der Erfindung denkbar, dass beim Bestimmen des statischen Schwellenwerts die Dynamik von Ausgangsdaten berücksichtigt wird. Hierbei kann die Dynamik von Ausgangsdaten innerhalb (nur) einer Toleranzzeit untersucht werden, um eine funktionale Mittelung von Ausgangsdaten zu berücksichtigen.
  • Zudem ist es denkbar, dass der statische Schwellenwert einmalig für die Anwendung bestimmt wird. Auf diese Weise kann der Rechenaufwand zum Bestimmen der Toleranzzeit gering gehalten werden.
  • Im Rahmen der Erfindung ist es außerdem möglich, dass die Toleranzzeit einen adaptiven, insbesondere zeitabhängigen, Schwellenwert umfasst. Auf diese Weise ist es möglich, die Toleranzzeit in Abhängigkeit von aktuellen Begebenheiten automatisch zu aktualisieren, die Veränderungen in den Ausgangsdaten sowie die Geschwindigkeit der Veränderung der Ausgangsdaten umfassen können.
  • Ferner kann die Erfindung vorsehen, dass beim Bestimmen des adaptiven Schwellenwerts die Dynamik von Ausgangsdaten berücksichtigt wird. Somit kann die Geschwindigkeit der Veränderung der Ausgangsdaten berücksichtigt werden. Somit kann die Erfindung dem Umstand Rechnung tragen, dass langsame Änderungen in der Anwendung zu hohen Schwellenwerten führen können, und dass schnelle Änderungen in der Anwendung zu niedrigeren Schwellenwerten führen können.
  • Weiterhin ist es im Rahmen der Erfindung denkbar, dass der adaptive Schwellenwert dynamisch bei der Ausführung der Anwendung angepasst wird. Somit kann der adaptive Schwellenwert regelmäßig im Laufe der Zeit aktualisiert werden.
  • Des Weiteren kann die Erfindung bei einem Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur vorsehen, dass beim Zuordnen der Anwendung dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server bevorzugt ein adaptiver Schwellenwert im Rahmen der Toleranzzeit berücksichtigt wird, wenn die Anwendung eine dynamische Anwendung ist, und/oder wenn sich die Ausgangsdaten schneller verändern als ein bestimmter Schwellenwert. Mithilfe des Schwellenwertes kann eine einfache Regel festgelegt werden, wann der adaptive Schwellenwert bevorzugt wird, bzw. ab wann die Geschwindigkeit der Veränderung der Ausgangsdaten hoch genug ist, sodass sich die Berechnung des adaptiven Schwellenwertes lohnt.
  • Zudem kann die Erfindung bei einem Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur vorsehen, dass beim Zuordnen der Anwendung dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server bevorzugt ein statischer Schwellenwert im Rahmen der Toleranzzeit berücksichtigt wird, wenn die Anwendung eine statische oder eine sich im Wesentlichen langsam verändernde Anwendung ist, und/oder wenn sich die Ausgangsdaten langsamer verändern als ein bestimmter Schwellenwert. Somit kann bei sich eher langsam ändernden Anwendungen die Rechenkapazität zum Bestimmen der Toleranzzeit reduziert werden.
  • Außerdem stellt die Erfindung eine verteilte Systemarchitektur bereit, aufweisend: einen, insbesondere mobilen, Anwendungs-Client zum Empfangen von Eingangsdaten und zum Bereitstellen von Ausgangsdaten basierend auf bearbeiteten Eingangsdaten, einen lokalen Anwendungs-Server am Anwendungs-Client und mindestens einen entfernten Anwendungs-Server zum Empfangen von Eingangsdaten von dem Anwendungs-Client, zum Bearbeiten von Eingangsdaten für den Anwendungs-Client und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client, und einen Anwendungs-Manager zum Zuordnen einer Anwendung dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server. Hierzu ist es erfindungsgemäß vorgesehen, dass der Anwendungs-Manager dazu ausgeführt ist:
    • - eine erste Umlaufzeit zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server zu bestimmen,
    • - eine zweite Umlaufzeit zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server zu bestimmen,
    • - eine Toleranzzeit zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung zu bestimmen,
    • - die erste Umlaufzeit und die zweite Umlaufzeit mit der Toleranzzeit zu vergleichen,
    • - die Anwendung dem lokalen Anwendungs-Server oder dem mindestens einen entfernten Anwendungs-Server in Abhängigkeit von dem Vergleich zuzuordnen.
  • Mithilfe der erfindungsgemäßen verteilten Systemarchitektur werden die gleichen Vorteile erreicht, die oben im Zusammenhang mit dem erfindungsgemäßen Verfahren beschrieben wurden. Auf diese Merkmale wird vorliegend vollumfänglich Bezug genommen.
  • Vorteilhafterweise kann der Anwendungs-Manager speziell dazu ausgeführt sein, ein Verfahren ganz oder zum Teil durchzuführen, welches wie oben beschrieben ablaufen kann.
  • Im Rahmen der Erfindung ist es denkbar, dass der Anwendungs-Client in einer Benutzervorrichtung, einem mobilen Gerät, einem Smartphone, einem Laptop und/oder einem Fahrzeug vorgesehen ist.
  • Weitere, die Erfindung verbessernde Maßnahmen werden nachstehend mit der Beschreibung der bevorzugten Ausführungsbeispiele der Erfindung anhand der Figuren näher dargestellt.
  • Dabei können die in den Ansprüchen und in der Beschreibung erwähnten Merkmale jeweils einzeln für sich oder in beliebiger Kombination erfindungswesentlich sein. Dabei ist zu beachten, dass die Figuren nur einen beschreibenden Charakter haben und nicht dazu gedacht sind, die Erfindung in irgendeiner Form einzuschränken. Es zeigen:
    • 1 eine schematische Darstellung einer verteilten Systemarchitektur in Rahmen der Erfindung,
    • 2 ein Diagramm zum Vergleichen einer ersten Umlaufzeit und einer zweiten Umlaufzeit mit einer Toleranzzeit,
    • 3 eine Abhängigkeit zwischen einer gemittelten Geschwindigkeit der Änderung der Ausgangsdaten und der Toleranzzeit,
    • 4 eine Geschwindigkeit der Änderung der Ausgangsdaten in Abhängigkeit von der Zeit, und
    • 5 eine Anwendungs-Performance in Abhängigkeit von der Umlaufzeit.
  • In den nachfolgenden Figuren werden für die gleichen technischen Merkmale auch von unterschiedlichen Ausführungsbeispielen die identischen Bezugszeichen verwendet.
  • Die 1 zeigt eine beispielhafte verteilte Systemarchitektur 100 in Rahmen der Erfindung. Die verteilte Systemarchitektur 100 weist folgende drei Elemente auf:
    • - einen, insbesondere mobilen, Anwendungs-Client 10 (z. B. in einer Benutzervorrichtung 101, wie bspw. in einem mobilen Gerät, Mobiltelefon, Smartphone, Laptop, Fahrzeug-Steuergerät, Navigationseinheit, Infotainmentsystem usw.) zum Empfangen von Eingangsdaten (bspw. Sensordaten) und zum Bereitstellen von Ausgangsdaten f(t) (bspw. Aktuatoreinstellungen) basierend auf bearbeiteten Eingangsdaten,
    • - einen lokalen Anwendungs-Server 21 (lokale Recheneinheit) am Anwendungs-Client 10 und mindestens einen entfernten Anwendungs-Server 22 (Cloud-Server sowie ein oder mehrere Edge-Cloud-Server) zum Empfangen von Eingangsdaten von dem Anwendungs-Client 10, zum Bearbeiten von Eingangsdaten für den Anwendungs-Client 10 und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client 10 sowie
    • - einen Anwendungs-Manager 30 (lokales Steuergerät) zum Zuordnen einer Anwendung APP zu dem lokalen Anwendungs-Server 21 oder dem mindestens einen entfernten Anwendungs-Server 22.
  • Die Erfindung sieht ein Verfahren zum Ausführen einer Anwendung APP auf einer verteilten Systemarchitektur 100 gemäß der 1 vor, das folgende Schritte aufweist:
    • - Bestimmen einer ersten Umlaufzeit RTT1 zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server 21,
    • - Bestimmen einer zweiten Umlaufzeit RTT2 zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server 22,
    • - Bestimmen einer, insbesondre maximal zulässigen, Toleranzzeit Δtmax zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung APP,
    • - Vergleichen der ersten Umlaufzeit RTT1 und der zweiten Umlaufzeit RTT2 mit der Toleranzzeit Δtmax,
    • - Zuordnen der Anwendung APP (bzw. zumindest einer Rechenaufgabe zum Bearbeiten von Eingangsdaten) für die Anwendung APP dem lokalen Anwendungs-Server 21 oder dem mindestens einen entfernten Anwendungs-Server 22 in Abhängigkeit von dem Vergleich.
  • Zum Ausführen des erfindungsgemäßen Verfahrens ist insbesondere der Anwendungs-Manager 30 ausgebildet.
  • Der lokale Anwendungs-Server 21 kann sich am Anwendungs-Client 10 befinden, insbesondere innerhalb der Benutzervorrichtung 101.
  • Es kann auch auf einen Edge Cloud Server oder in ein größeres Rechenzentrum in der Cloud verschoben werden. zeigt die Kommunikation zwischen einem Anwendungsclient und Manager und dem Anwendungsserver, der lokal oder in der Cloud ausgeführt werden kann.
  • Die Edge-Infrastruktur 102 kann den mindestens einen entfernten Anwendungs-Server 22, umfassend einen zentralen Cloud-Server sowie einen oder mehrere Edge-Cloud-Server, aufweisen.
  • Wie es die 1 zeigt, werden die vom Anwendungs-Client 10 an den lokalen Anwendungs-Server 21 sowie an den mindestens einen entfernten Anwendungs-Server 22 gesendeten Eingangsdaten als Rohdaten mit einem Index i fortlaufend nummeriert. Dieser Index wird zusammen mit den eigentlichen Eingangsdaten an den jeweiligen Anwendungs-Server 21, 22 gesendet und auch der Antwort des jeweiligen Anwendungs-Servers 21, 22 hinzugefügt. Dieser Mechanismus stellt sicher, dass der Anwendungs-Client 10 die Antwortzeiten Δtci, Δtli verschiedener Anwendungs-Server 21, 22 für die gleiche Eingabe vergleichen kann.
  • Der Anwendungs-Client 10 kann die Umlaufzeiten RTT1, RTT2 des lokalen Anwendungs-Servers 21 (ti+Δtli) und des entfernten Anwendungs-Servers 22 in der (Edge-)Cloud (ti+Δtci) messen und vergleichen.
  • Jede Anwendung hat eine bestimmte Frist, nämlich die erfindungsgemäße Toleranzzeit Δtmax, die angibt, wann die Bearbeitung der Eingangsdaten auf dem jeweiligen Anwendungs-Server 21, 22 spätestens abgeschlossen werden muss, damit dieser Anwendungs-Server 21, 22 zum Ausführen einer Rechenaufgabe für die Anwendung APP in Frage kommt.
  • In der 2 werden die Umlaufzeiten RTT1, RTT2 für eine Rechenaufgabe mit der Indexnummer i aus der lokalen Antwortzeit Δtli oder der (Edge-)Cloud-Antwortzeit Δtci mit der Toleranzzeit Δtmax verglichen. Die Umlaufzeiten RTT1, RTT2 enthalten dabei die Kommunikationsverzögerung und die Rechenzeit auf dem jeweiligen Anwendungs-Server 21, 22.
  • Wenn beide Antwortzeiten Δtli, Δtci unter der Toleranzzeit Δtmax liegen, kann der Anwendungs-Manager 30 beide Laufzeitumgebungen bzw. beide Anwendungs-Server 21, 22 frei wählen.
  • Ferner könnte mindestens eine Bedingung vorgesehen sein, auf Grund welcher der eine oder der andere Anwendungs-Server 21, 22 bevorzugt wird. Bspw. kann die mindestens eine Bedingung eine Verwendung des mindestens einen entfernten Anwendungs-Servers 22 (Cloud-Server oder Edge-Cloud-Server) vorsehen, wenn die erste Umlaufzeit RTT1 und die zweite Umlaufzeit RTT2 unterhalb der Toleranzzeit Δtmax liegen. Weiterhin ist es denkbar, dass die mindestens eine Bedingung mindestens eine folgende Information umfassen kann, wie z. B.: Benutzerpräferenzen, Erfahrungsdaten und/oder Anwendungs-Performance q(Δtruntime).
  • Bspw. kann die mindestens eine Bedingung in der Situation gemäß der 1 vorsehen, dass der mindestens eine entfernte Anwendungs-Server 22 bevorzugt wird, wenn die zweite Umlaufzeit RTT2 (bzw. Fernreaktionszeit) nicht länger als die erste Umlaufzeit RTT1 (bzw. lokale Reaktionszeit) ist. Grundsätzlich ist ein lokales Computing am lokalen Anwendungs-Server 21 die einzig sinnvolle Wahl, wenn die Fernreaktionszeit die Toleranzzeit Δtmax überschreitet. Ebenso ist nur Remote-Computing auf dem mindestens einen entfernten Anwendungs-Server 22 möglich, wenn die lokale Reaktionszeit länger als die Toleranzzeit Δtmax ist. Wenn beide Umlaufzeiten RTT1, RTT2 länger als die Toleranzzeit Δtmax sind, kann die Rechenaufgabe für die Anwendung APP nicht in Echtzeit übernommen werden.
  • Die erfindungsgemäße Idee liegt dabei darin, die Toleranzzeit Δtmax zu verwenden und mit den Umlaufzeiten RTT1, RTT2 zu vergleichen. Darauf aufbauend wird eine Entscheidung für die Verwendung des jeweiligen Anwendungs-Servers 21, 22 getroffen.
  • Im Rahmen der Erfindung kann die Toleranzzeit Δtmax einen statischen Schwellenwert umfassen. Die Methodik zur Berechnung des statischen Schwellenwertes der Toleranzzeit Δtmax wird im Folgenden erläutert.
  • Die erste Methode zur Berechnung des statischen Schwellenwertes kann dann realisiert werden, wenn dem Entwickler die verteilte Systemarchitektur 100, umfassend den lokalen Anwendungs-Server 21 und die Edge-Infrastruktur 102, zum Vermessen zur Verfügung steht. Bei dieser Methode wird die Anwendung APP nach deren Entwicklung zweimal auf dieser verteilten Systemarchitektur 100 für eine definierte Folge von Eingangsdaten ausgeführt. Im ersten Lauf wird die Anwendungsberechnung auf der Benutzervorrichtung 101 vollständig durchgeführt und die Edge-Infrastruktur 102 nicht verwendet. Im zweiten Lauf wird die Anwendungsberechnung in der Edge-Infrastruktur 102 durchgeführt und die Rechenressourcen der Benutzervorrichtung 101 werden nicht verwendet. In beiden Durchgängen wird die gleiche Reihenfolge der Eingangsdaten verwendet. Die Umlaufzeiten RTT1, RTT2 der Eingangsdaten wird für eine Vielzahl an Anfragen für beide Läufe gemittelt. Dieser Wert wird dann als statischer Schwellenwert der Toleranzzeit Δtmax definiert. Die Gleichung ist wie folgt dargestellt: Δ t m a x = 1 2 N ∑ i = 0 N ( Δ t c i + Δ t l i ) ,
    Figure DE102019206923B3_0001
  • N ist dabei die Anzahl an Anfragen, die in der Reihenfolge an die Anwendungs-Server 21, 22 gesendet wurden.
  • Die obige Methode ist ein sicherer Ansatz zum Bestimmen des statischen Schwellenwertes, da sie auf den tatsächlichen Umlaufzeiten RTT1, RTT2 basiert, die von der verteilten Systemarchitektur 100 aufgezeichnet wurden.
  • Eine andere Methode könnte jedoch bevorzugt werden, wenn der Entwickler keinen Zugriff auf die verteilte Systemarchitektur 100 hat.
  • Eine zweite Methode könnte auf der Grundlage der Dynamik der zugrunde liegenden Anwendung APP basieren. Ohne Einschränkung der Anwendbarkeit werden ein oder mehrere Schlüsselparameter der Anwendung APP als eine Funktion f(t) der Zeit t beschrieben, die die Ausgangsdaten f(t) abbilden. Je schneller sich diese Funktion f(t) ändert, desto kürzer ist die tolerierbare Umlaufzeit RTT1, RTT2. Der Anwendungsentwickler kann dabei eine maximal tolerierbare Abweichung als Schwellenwert Δfmax dieser Funktion f(t) angeben, die den tolerierbaren Wert der Toleranzzeit Δtmax bestimmt. Ein statischer Schwellenwert von Δtmax kann dann berechnet werden, wie es in der folgenden Gleichung dargestellt ist: Δ t m a x = ( k / | f ˙ m e a n | ) ,
    Figure DE102019206923B3_0002
    k ist dabei eine Konstante und gibt die maximal zulässige Abweichung der Anwendung APP im Vergleich zu der vom Entwickler angegebenen Basislinie an. Die Anwendung APP berechnet eine Funktion f(t), deren Dynamik durch ihre Ableitung ḟ(t) geschätzt werden kann. ḟmean ist der Mittelwert der Änderungsrate der Anwendungsfunktion f(t). Die Basislinie ist die Ausgabesequenz, die die Anwendung APP für die bereitgestellte Eingabemeldesequenz in einem idealen Szenario bereitstellen sollte (keine Netzwerklatenz, Rechenverzögerungen usw.). Die zweite Methode ist für einen Entwickler einfacher, da er keinen Zugriff auf die Edge-Infrastruktur 102 für die Parameterwerte haben muss.
  • Ferner kann die Erfindung vorsehen, dass die Toleranzzeit Δtmax einen adaptiven, insbesondere zeitabhängigen, Schwellenwert umfassen kann.
  • Für einige Anwendungen APP kann die maximal zulässige Toleranzzeit Δtmax statisch sein. In vielen Fällen ist die maximal zulässige Toleranzzeit Δtmax nicht statisch und variiert als eine Funktion der Zeit t. In diesen Fällen kann eine automatische bzw. adaptive Anpassung der Toleranzzeit Δtmax vorteilhaft sein. Wird eine Anwendung APP als eine Funktion f(t) der Zeit t beschrieben, so wird deren Dynamik durch ihre Ableitung ḟ(t) dargestellt. Wenn die Funktion f(t) langsam variiert (d.h., die erste Ableitung f(t) ist nahe null), genügt auch eine langsame Antwort des jeweiligen Anwendungs-Servers 21, 22, um der Funktion f(t) innerhalb einer bestimmten Fehlergrenze zu folgen. Der Anwendungsentwickler kann hierbei eine tolerierbare Abweichung Δfmax der Funktion f(t) definieren, die nicht überschritten werden darf, wenn der jeweilige Anwendungs-Server 21, 22 eine Umlaufzeit-Verzögerung einführt. Das Verhältnis zwischen der maximal zulässigen Änderung Δfmax der Funktion f(t) und der entsprechenden maximal zulässigen Toleranzzeit Δtmax als Reaktionszeit ergibt sich aus der folgenden Gleichung: Δ f m a x = | f ˙ m e a n | Δ t m a x .
    Figure DE102019206923B3_0003
  • Siehe hierzu die 3.
  • Ferner zeigt die 4, wie der Mittelwert der Ableitung ḟ(t) im Intervall der Länge Δtmax zwischen Anfrage und Antwort ist. Praktisch kann der Mittelwert f'mean der Änderungsrate der Anwendungsfunktion f(t) durch Messungen aus einem längeren Intervall approximiert und mit einem gleitenden Durchschnittsansatz angepasst werden. Der adaptive Schwellenwert der Toleranzzeit Δtmax (t) kann berechnet werden als: Δ t m a x ( t ) = Δ f m a x / | f ˙ m e a n ( t ) | .
    Figure DE102019206923B3_0004
  • Die minimale Änderungsrate bestimmt im Rahmen der Erfindung eine maximal zulässige Reaktionszeit (vgl. die 3). Der Wert von Δtmax (t) wird auf einen Maximalwert begrenzt, der auf einem für Mittelwert ḟmean zulässigen Minimalwert basiert (vgl. die 4). Ein praktisches Beispiel für eine Anwendung APP bzw. eine Funktion f(t) im Sinne der Erfindung, die nicht nur eine skalare Funktion ist, sondern auch eine Vektorfunktion sein kann, kann die Verfolgung von Fahrzeugobjekten in einem Fahrerassistenzsystem sein. Für die Verfolgung wird ein Maximum an einem tolerierbaren Abstand zwischen einem verfolgten Objekt und dem Fahrzeug angegeben werden. Die Abweichung wird dann in eine maximal tolerierbare Umlaufzeit umgewandelt, um den Fehler innerhalb der zulässigen Grenzen zu halten.
  • Ein Gesamtqualitätsmaß für die Anwendungsleistung ist die Anwendungs-Performance q(Δtruntime), z.B. wie gut ein Objekt im vorherigen Beispiel verfolgt werden kann. Sie kann erstellt werden, indem die tatsächliche Umlaufzeit RTT1, RTT2 (im Beispiel der 5 als Δtruntime bezeichnet) aus der ausgewählten Laufzeitumgebung (Benutzervorrichtung 101 und die Edge-Infrastruktur 102) auf einen Qualitätswert zwischen 0% und 100% abgebildet wird, wie dies in der 5 zu sehen ist. Die Leistungsqualität für ein Fenster von N+1-Messungen, das von der Zeit t(n-N) bis zur aktuellen Zeit tn reicht, kann als Durchschnitt über alle Einzelmessungen berechnet werden: Q ( t n ) = 1 N + 1 ∑ i = n − N n q ( Δ t r u n t i m e ( t i ) )
    Figure DE102019206923B3_0005
  • Zusammenfassend stellt die Erfindung mehrere Vorteile bereit:
    • - Die Verwendung der Toleranzzeit Δtmax für die Umlaufzeit RTT1, RTT2 als einziger Parameter für die Entscheidung, welcher Anwendungs-Server 21, 22 verwendet wird, erleichtert das Leben eines Entwicklers erheblich. Der Entwickler braucht dabei nur einen einzigen Parameter einstellen.
    • - Gemäß einem statischen Ansatz wird die Umlaufzeit RTT1, RTT2 mit einem statischen Schwellenwert der Toleranzzeit Δtmax verglichen, um zwischen den Anwendungs-Servern 21, 22 zu entscheiden, während im adaptiven Ansatz die Umlaufzeit RTT1, RTT2 mit einem dynamischen Schwellenwert der Toleranzzeit Δtmax verglichen wird, um sich zwischen den Anwendungs-Servern 21, 22 zu entscheiden.
    Der adaptive Ansatz ist effektiver als der statische Ansatz, wenn die richtigen Werte für die maximal tolerierbare Abweichung als Schwellenwert Δfmax gewählt werden. Die Abweichungen werden reduziert, gleichzeitig wird die Auslastung der Edge-Infrastruktur 102 im Falle der Adaption erhöht.
    Wenn die Werte von Δfmax kleiner als ein minimaler Schwellenwert sind, ist der statische Ansatz in Bezug auf Abweichungen und Ausnutzung der Edge-Infrastruktur 102 besser als der adaptive Ansatz. Daher sollte die Wahl des adaptiven Ansatzes anwendungsspezifisch sein und von der vom Entwickler erlaubten Anwendungsabweichung Δfmax abhängen.
  • Die voranstehende Beschreibung der Figuren beschreibt die vorliegende Erfindung ausschließlich im Rahmen von Beispielen. Selbstverständlich können einzelne Merkmale der Ausführungsformen, sofern es technisch sinnvoll ist, frei miteinander kombiniert werden, ohne den Rahmen der Erfindung zu verlassen.
  • Bezugszeichenliste
    • 100
    verteilte Systemarchitektur
    101
    Benutzervorrichtung
    102
    Edge-Infrastruktur
    10
    Anwendungs-Client
    21
    lokaler Anwendungs-Server
    22
    entfernter Anwendungs-Server
    30
    Anwendungs-Manager
    APP
    Anwendung
    RTT1
    erste Umlaufzeit
    RTT2
    zweite Umlaufzeit
    i
    Index, Zähler
    t
    Zeit
    ti
    Anfragezeit
    Δtci
    Antwortzeit
    Δtli
    Antwortzeit
    Δtmax
    Toleranzzeit
    Δt
    Zeitdifferenz
    f(t)
    Funktion für die Ausgangsdaten
    ḟ(t)
    Geschwindigkeit der Änderung der Ausgangsdaten
    ḟmax
    maximale Geschwindigkeit
    ḟmean
    gemittelte Geschwindigkeit
    q(Δtruntime)
    Anwendungs-Performance
    Δtruntime
    Umlaufzeit

Claims (14)

  1. Verfahren zum Ausführen einer Anwendung (APP) auf einer verteilten Systemarchitektur (100), aufweisend: einen, insbesondere mobilen, Anwendungs-Client (10) zum Empfangen von Eingangsdaten und zum Bereitstellen von Ausgangsdaten (f(t)) basierend auf bearbeiteten Eingangsdaten, einen lokalen Anwendungs-Server (21) am Anwendungs-Client (10) und mindestens einen entfernten Anwendungs-Server (22) zum Empfangen von Eingangsdaten von dem Anwendungs-Client (10), zum Bearbeiten von Eingangsdaten für den Anwendungs-Client (10) und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client (10), und einen Anwendungs-Manager (30) zum Zuordnen der Anwendung (APP) zu dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22), dadurch gekennzeichnet, dass das Verfahren folgende Schritte aufweist: - Bestimmen einer ersten Umlaufzeit (RTT1) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server (21), - Bestimmen einer zweiten Umlaufzeit (RTT2) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server (22), - Bestimmten einer Toleranzzeit (Δtmax) zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung (APP), - Vergleichen der ersten Umlaufzeit (RTT1) und der zweiten Umlaufzeit (RTT2) mit der Toleranzzeit (Δtmax), - Zuordnen der Anwendung (APP) zu dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) in Abhängigkeit von dem Vergleich, wobei die Umlaufzeit (RTT1, RTT2) als eine Dauer vom Senden einer Anforderung, umfassend die Eingangsdaten, an einen verfügbaren Anwendungs-Server (21, 22) bis zum Empfang der berechneten Ergebnisse von dem verfügbaren Anwendungs-Server (21, 22) bestimmt wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Anwendung (APP) dem lokalen Anwendungs-Server (21) zugeordnet wird, wenn die erste Umlaufzeit (RTT1) unterhalb der Toleranzzeit (Δtmax) liegt, und/oder dass die Anwendung (APP) dem mindestens einen entfernten Anwendungs-Server (22) zugeordnet wird, wenn die zweite Umlaufzeit (RTT2) unterhalb der Toleranzzeit (Δtmax) liegt.
  3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Zuordnen der Anwendung (APP) dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) in Anhängigkeit von mindestens einer Bedingung durchgeführt wird, wenn die erste Umlaufzeit (RTT1) und die zweite Umlaufzeit (RTT2) unterhalb der Toleranzzeit (Δtmax) liegen.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die mindestens eine Bedingung mindestens eine folgende Information umfassen kann, wie: Benutzerpräferenzen, Erfahrungsdaten und/oder Anwendungs-Performance (q(Δtruntime)).
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Toleranzzeit (Δtmax) einen statischen Schwellenwert umfasst.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der statische Schwellenwert als ein Mittelwert von der ersten Umlaufzeit (RTT1) und der zweiten Umlaufzeit (RTT2) für eine Vielzahl an Anfragen zum Bearbeiten von Eingangsdaten ermittelt wird, und/oder dass der statische Schwellenwert durch eine Vermessung der verteilten Systemarchitektur (100) bestimmt wird.
  7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass beim Bestimmen des statischen Schwellenwerts die Dynamik von Ausgangsdaten (f(t)) berücksichtigt wird, und/oder dass der statische Schwellenwert einmalig für die Anwendung (APP) bestimmt wird.
  8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Toleranzzeit (Δtmax) einen adaptiven, insbesondere zeitabhängigen, Schwellenwert umfasst.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass beim Bestimmen des adaptiven Schwellenwerts die Dynamik von Ausgangsdaten (f(t)) berücksichtigt wird, und/oder dass der adaptive Schwellenwert dynamisch bei der Ausführung der Anwendung (APP) angepasst wird.
  10. Verfahren nach Anspruch 5 oder 8, dadurch gekennzeichnet, dass beim Zuordnen der Anwendung (APP) dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) bevorzugt ein adaptiver Schwellenwert im Rahmen der Toleranzzeit (Δtmax) berücksichtigt wird, wenn die Anwendung (APP) eine dynamische Anwendung ist, und/oder wenn sich die Ausgangsdaten (f(t)) schneller verändern als ein bestimmter Schwellenwert (Δfmax).
  11. Verfahren nach Anspruch 5 oder 8, dadurch gekennzeichnet, dass beim Zuordnen der Anwendung (APP) dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) bevorzugt ein statischer Schwellenwert im Rahmen der Toleranzzeit (Δtmax) berücksichtigt wird, wenn die Anwendung (APP) eine statische oder eine sich im Wesentlichen langsam verändernde Anwendung ist, und/oder wenn sich die Ausgangsdaten (f(t)) langsamer verändern als ein bestimmter Schwellenwert (Δfmax).
  12. Verteilte Systemarchitektur (100), aufweisend: einen, insbesondere mobilen, Anwendungs-Client (10) zum Empfangen von Eingangsdaten und zum Bereitstellen von Ausgangsdaten (f(t)) basierend auf bearbeiteten Eingangsdaten, einen lokalen Anwendungs-Server (21) am Anwendungs-Client (10) und mindestens einen entfernten Anwendungs-Server (22) zum Empfangen von Eingangsdaten von dem Anwendungs-Client (10), zum Bearbeiten von Eingangsdaten für den Anwendungs-Client (10) und zum Zurücksenden von bearbeiteten Eingangsdaten an den Anwendungs-Client (10), und einen Anwendungs-Manager (30) zum Zuordnen einer Anwendung (APP) zu dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22), dadurch gekennzeichnet, dass der Anwendungs-Manager (30) dazu ausgeführt ist: - eine erste Umlaufzeit (RTT1) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem lokalen Anwendungs-Server (21) zu bestimmen, - eine zweite Umlaufzeit (RTT2) zum Empfangen und zum Bearbeiten von Eingangsdaten auf dem mindestens einen entfernten Anwendungs-Server (22) zu bestimmen, - eine Toleranzzeit (Δtmax) zum Empfangen und zum Bearbeiten von Eingangsdaten für die Anwendung (APP) zu bestimmen, - die erste Umlaufzeit (RTT1) und die zweite Umlaufzeit (RTT2) mit der Toleranzzeit (Δtmax) zu vergleichen, - die Anwendung (APP) dem lokalen Anwendungs-Server (21) oder dem mindestens einen entfernten Anwendungs-Server (22) in Abhängigkeit von dem Vergleich zuzuordnen, wobei die Umlaufzeit (RTT1, RTT2) als eine Dauer vom Senden einer Anforderung, umfassend die Eingangsdaten, an einen verfügbaren Anwendungs-Server (21, 22) bis zum Empfang der berechneten Ergebnisse von dem verfügbaren Anwendungs-Server (21, 22) bestimmt wird.
  13. Verteilte Systemarchitektur (100) nach Anspruch 12, dadurch gekennzeichnet, dass der Anwendungs-Manager (30) dazu ausgeführt ist, ein Verfahren nach einem der vorhergehenden Ansprüche 1 bis 11 auszuführen.
  14. Verteilte Systemarchitektur (100) nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass der Anwendungs-Client (10) in einer Benutzervorrichtung (101), einem mobilen Gerät, einem Smartphone, einem Laptop und/oder einem Fahrzeug vorgesehen ist.
DE102019206923.1A 2019-05-13 2019-05-13 Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur Active DE102019206923B3 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102019206923.1A DE102019206923B3 (de) 2019-05-13 2019-05-13 Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur
US15/930,087 US11363120B2 (en) 2019-05-13 2020-05-12 Method for running an application on a distributed system architecture
KR1020200056472A KR102287566B1 (ko) 2019-05-13 2020-05-12 분산 시스템 아키텍처에서 애플리케이션을 실행하기 위한 방법
CN202010401676.7A CN111930494A (zh) 2019-05-13 2020-05-13 用于在分布式系统架构上执行应用的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019206923.1A DE102019206923B3 (de) 2019-05-13 2019-05-13 Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur

Publications (1)

Publication Number Publication Date
DE102019206923B3 true DE102019206923B3 (de) 2020-08-13

Family

ID=71739318

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019206923.1A Active DE102019206923B3 (de) 2019-05-13 2019-05-13 Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur

Country Status (4)

Country Link
US (1) US11363120B2 (de)
KR (1) KR102287566B1 (de)
CN (1) CN111930494A (de)
DE (1) DE102019206923B3 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019206923B3 (de) * 2019-05-13 2020-08-13 Volkswagen Aktiengesellschaft Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur
EP3879796B1 (de) * 2020-03-13 2024-02-21 Apple Inc. Auswahl eines kantenanwendungsservers
KR102418059B1 (ko) * 2020-12-08 2022-07-06 현대오토에버 주식회사 차량의 이종 제어기간 통신 응답시간 추정 장치 및 방법
DE102022203945A1 (de) * 2022-04-22 2023-10-26 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren für eine Konfiguration in einem Netzwerk

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3425873A1 (de) * 2017-07-05 2019-01-09 Wipro Limited Verfahren und system zur verarbeitung von daten in einer umgebung des internets der dinge (iot)

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026425A (en) * 1996-07-30 2000-02-15 Nippon Telegraph And Telephone Corporation Non-uniform system load balance method and apparatus for updating threshold of tasks according to estimated load fluctuation
US9137324B2 (en) * 2002-04-10 2015-09-15 International Business Machines Corporation Capacity on-demand in distributed computing environments
US20040001476A1 (en) * 2002-06-24 2004-01-01 Nayeem Islam Mobile application environment
US7331048B2 (en) * 2003-04-04 2008-02-12 International Business Machines Corporation Backfill scheduling of applications based on data of the applications
WO2005024780A2 (en) * 2003-09-05 2005-03-17 Grody Stephen D Methods and apparatus for providing services using speech recognition
US7707288B2 (en) * 2005-01-06 2010-04-27 International Business Machines Corporation Automatically building a locally managed virtual node grouping to handle a grid job requiring a degree of resource parallelism within a grid environment
US7548977B2 (en) * 2005-02-11 2009-06-16 International Business Machines Corporation Client / server application task allocation based upon client resources
US7877517B2 (en) * 2005-11-09 2011-01-25 International Business Machines Corporation Determining whether to compress data transmitted over a network
JP2008009865A (ja) * 2006-06-30 2008-01-17 Yokogawa Electric Corp 分散コンピュータシステム
US20090327495A1 (en) * 2008-06-27 2009-12-31 Oqo, Inc. Computing with local and remote resources using automated optimization
US9311158B2 (en) * 2010-09-03 2016-04-12 Adobe Systems Incorporated Determining a work distribution model between a client device and a cloud for an application deployed on the cloud
TWI470567B (zh) 2012-02-03 2015-01-21 Univ Nat Chiao Tung 考慮耗時與耗電的卸載運算量的決策方法與運算系統
US20140095695A1 (en) 2012-09-28 2014-04-03 Ren Wang Cloud aware computing distribution to improve performance and energy for mobile devices
JP5987181B2 (ja) * 2013-02-07 2016-09-07 株式会社日立製作所 分散処理システム及び分散処理システムの管理方法
US20150006620A1 (en) * 2013-06-27 2015-01-01 Applied Materials, Inc. Scalable manufacturing facility management system
KR102173107B1 (ko) * 2013-12-11 2020-11-02 삼성전자주식회사 클라우드 서버 기반 영상 처리 방법, 단말 및 시스템
US9250914B2 (en) * 2013-12-20 2016-02-02 Intel Corporation Method and apparatus for selecting cache locality for atomic operations
US9513941B2 (en) * 2014-09-17 2016-12-06 International Business Machines Corporation Codeless generation of APIs
CN105704181A (zh) 2014-11-26 2016-06-22 国际商业机器公司 管理移动设备中的任务的方法和装置
US10666534B2 (en) * 2015-06-29 2020-05-26 Citrix Systems, Inc. Systems and methods for measuring round trip time in network devices between the device and an endpoint
WO2017112866A1 (en) * 2015-12-23 2017-06-29 Idac Holdings, Inc. Methods of offloading computation from mobile device to cloud
US10291494B2 (en) * 2016-04-20 2019-05-14 Cisco Technology, Inc. Distributing data analytics in a hierarchical network based on computational complexity
US10375644B2 (en) * 2017-02-16 2019-08-06 At&T Intellectual Property I, L.P. Method and apparatus for optionally running mobile applications locally or virtually
US10565464B2 (en) * 2017-12-21 2020-02-18 At&T Intellectual Property I, L.P. Adaptive cloud offloading of mobile augmented reality
US10776236B1 (en) * 2018-04-16 2020-09-15 Parallels International Gmbh Transferrable containerized applications for remote-access client-server environments
CA3057032C (en) * 2018-09-28 2023-03-21 Element Ai Inc. System and method for managing network resources
US20200195731A1 (en) * 2018-12-12 2020-06-18 Sichuan University Lccs system and method for executing computation offloading
DE102019206923B3 (de) * 2019-05-13 2020-08-13 Volkswagen Aktiengesellschaft Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3425873A1 (de) * 2017-07-05 2019-01-09 Wipro Limited Verfahren und system zur verarbeitung von daten in einer umgebung des internets der dinge (iot)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Xiao Qin et al.: Communication-Aware Load Balancing for Parallel Applications on Clusters. In: IEEE Transactions on Computers, Vol. 59, Jan. 2010. pp. 42 - 52 *
Xiao Qin  et al.: Communication-Aware Load Balancing for Parallel Applications on Clusters. In: IEEE Transactions on Computers, Vol. 59, Jan. 2010. pp. 42 - 52

Also Published As

Publication number Publication date
US20200366760A1 (en) 2020-11-19
US11363120B2 (en) 2022-06-14
KR102287566B1 (ko) 2021-08-10
KR20200131178A (ko) 2020-11-23
CN111930494A (zh) 2020-11-13

Similar Documents

Publication Publication Date Title
DE102019206923B3 (de) Verfahren zum Ausführen einer Anwendung auf einer verteilten Systemarchitektur
DE112013004098B4 (de) Verwalten eines Daten-Cache für ein Computersystem
DE112021003908T5 (de) Föderales maschinenlernen durch verwenden von ortsabhängigem hashing
DE112020004651T5 (de) Multi-tenant-etl-ressourcenaufteilung
DE112020006047T5 (de) Steuern von transaktionsanforderungen zwischen anwendungen und servern
DE102022101068A1 (de) Absichts-basierte dynamische northbound-anwendungsschnittstelle
DE102017123055A1 (de) Slave-Vorrichtung
DE102023005039A1 (de) Verfahren und System zur Vorhersage der Batteriedegradation eines Fahrzeugs mittels Federated Learning
DE102018006332A1 (de) Verfahren zum Ermitteln von Ampelschaltzeiten
DE112012005046T5 (de) Koordinieren von Schreiboperationsabfolgen in einem Datenspeichersystem
DE112022001303T5 (de) Intelligente identifizierung einer ausführungsumgebung
DE112015007097B4 (de) Übertragungssteuervorrichtung, Fahrzeug und Übertragungssteuerverfahren
DE102013223022A1 (de) Vorhersage der Signale einer Ampel
EP3878157B1 (de) Anpassen einer software-anwendung, die auf einem gateway ausgeführt wird
DE102021107787A1 (de) Dynamische Dienstqualitätssteuerung für Kraftfahrzeug-Ethernet
EP3396919A1 (de) Verfahren zur datenübertragung von einem gerät an ein datenverwaltungsmittel, vermittlungseinheit, gerät und system
DE112020006904T5 (de) Inferenzvorrichtung, Aktualisierungsverfahren und Aktualisierungsprogramm
DE102019213562A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug
DE102020206788A1 (de) Aufteilung von Funktionen auf fahrzeuginterne und fahrzeugexterne Rechensysteme
DE102019200732A1 (de) Verfahren zum Filtern von Fahrzeug-zu-X Nachrichten, Fahrzeug-zu-X-Kommunikationsvorrichtung und computerlesbares Speichermedium
EP1047990B1 (de) Vorrichtung und verfahren zur steuerung von prozessen auf einem computersystem
WO2018141435A1 (de) Verfahren und vorrichtung zum zuweisen von geräteressourcen
DE102012214500B4 (de) Zustandsbasierte Planung, Absicherung und Management von Ressourcen einer Datennetzstruktur
EP2188948B1 (de) Verfahren zum rechnergestützten bestimmen einer steuerungsgrösse, steuerung, regelsystem und computerprogrammprodukt
DE102022127847A1 (de) System und Verfahren für cloud-koordinierte Fahrzeugdatensammlung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final