-
Die vorliegende Erfindung betrifft ein Verfahren zum Prüfen der Kompatibilität zwischen einer Anwendungssoftware und einer mobilen Arbeitsmaschine. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Hinlänglich bekannt sind Verfahren zum Verteilen oder Aktualisieren von Software (SW) über eine - mitunter als „Luftschnittstelle“ (over the air, OTA) bezeichnete - drahtlose Datenschnittstelle. Gattungsmäßige Verfahren finden Anwendung sowohl auf Anwendungssoftware (SOTA) als auch auf eingebettete Systemsoftware (firmware, FOTA).
-
Nach dem Stand der Technik werden FOTA und SOTA beispielsweise zur Aktualisierung der Steuergeräte vernetzter Kraftfahrzeuge und mobiler Arbeitsmaschinen eingesetzt. Zur telematischen Verbindung zwischen dem die Steuergeräte koppelnden Bussystem und dem Internet (der sinnbildlichen „Cloud“) dient hierbei typischerweise eine Fahrzeugverbindungsschnittstelle (vehicle connectivity gateway, VCG).
-
Jenseits der Wartung und Fehlerbereinigung bereits installierter Software lässt sich der Funktionsumfang fahrzeuginterner Steuergeräte auf diesem Wege um Leistungsmerkmale (features) erweitern, welche vorhandene Sensoren und Aktoren für neue Anwendungsfälle nutzen. Entsprechende Applikationen können durch Hersteller oder Erstausrüster (original equipment manufacturer, OEM) einer mobilen Arbeitsmaschine - etwa mittels eines Entwicklungskits (development kit) - erstellt und auf einer digitalen Vertriebsplattform in der Cloud angeboten werden. Als denkbare Erweiterungen kommen zum Beispiel fortgeschrittene Telemetrie- oder agrartechnische Spezialfunktionen wie die gezielte Unkrautbekämpfung in Betracht.
-
DE102015203766A1 offenbart ein Teilsystem für ein Fahrzeug mit einem über eine Luftschnittstelle mit einem Gerätemanagement-Server des Backends verbundenen Gerätemanagement-Client zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, einem über die Luftschnittstelle mit einem Download-Server des Backends verbundenen Download-Client zum Herunterladen eines Softwareupdates von dem Backend in das Fahrzeug, mit dem Download-Client verbundenen Softwareupdate-Clients zum Anwenden des Softwareupdates und einen mit dem Download-Client und den Softwareupdate-Clients verbundenen Fahrzeugupdate-Client zum Koordinieren des Softwareupdates.
-
In Anlehnung an die im Schiffsverkehr seit Jahrhunderten genutzten Ladungsmanifeste werden auch in der Computertechnik sogenannte Manifest-Dateien verwendet, um Metadaten über ein Archiv oder einen anderweitigen Verbund weiterer Dateien zusammenzufassen. Entsprechende Konzepte finden zum Beispiel Anwendung in der gemäß ISO/IEC 23271 standardisierten gemeinsamen Sprachinfrastruktur (common language infrastructure, CLI), dem Windows-Betriebssystem, der Hypertext-Auszeichnungssprache HTML5, der Java-Sprachumgebung sowie verschiedenen Linux-Distributionen.
US20060206449A1 beispielsweise schlägt zur Aktualisierung eingebetteter Systeme eine Paketverwaltung mittels eines Softwarepaket-Manifests (SPM) vor.
-
DE102018205872A1 offenbart ein Verfahren zur Erzeugung eines digitalen Zwillings (digital twin) beispielsweise einer Maschine, bei welchem anhand eines Metamodells Beschreibungsdaten erzeugt werden, die Eigenschaften von digitalen Daten enthalten. Weiterhin werden Kommunikationsinformationen erstellt. Zur Erzeugung des digitalen Zwillings werden die Beschreibungsdaten, die Kommunikationsinformationen und eine Bezeichnung der Maschine zusammengefügt.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Prüfen der Kompatibilität zwischen einer Anwendungssoftware und einer mobilen Arbeitsmaschine, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Die vorgestellte Lösung ermöglicht es, ohne reale Systemhardware und -umgebung eine erfindungsgemäße Kompatibilitätsprüfung im Voraus, also vor der mit einer realen Implementierung, Verteilung oder Aktualisierung der Software verbundenen Änderung der funktionalen Gegebenheiten durchzuführen.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann eine vorwärts gerichtete (ex ante) Perspektive vorgesehen sein, aus welcher der Design- und Entwicklungsaufwand von Software reduziert werden kann, indem z. B. virtuell Kompatibilitäten geprüft oder Umgebungsmodelle mit geringem Aufwand entwickelt werden. Die Qualität der Anwendungssoftware steigt auf diese Weise, da die Datengrundlage und damit zugrundeliegende Prämissen (insb. im Design und Entwicklungsprozess verwendet) auf Realdaten basieren, die effizient durch den Abbildungsmechanismus des digitalen Zwillings erhoben werden bzw. an einem zentralen Ort in der Cloud abgelegt sind. Ermöglicht wird auf diesem Wege auch eine Unterstützung des Installationsvorgangs, von für die Anwendungssoftware relevanter Hardware (im Allgemeinen Maschinenperipherie) auf Zielmaschinen sowie von Anwendungssoftware selbst, auf den unterschiedlichen Zielsteuergeräten.
-
Gemäß einem weiteren Aspekt kann eine rückwärts gerichtete (ex post) Perspektive vorgesehen sein, aus welcher z. B. Diagnose, Problemanalyse und Kompatibilitätsprüfung nach der Verteilung/Inbetriebnahme (i.d.R. Installation) der Anwendungssoftware erfolgen und die mobile Arbeitsmaschine abhängig vom Ergebnis etwa einer Wartung oder Nachrüstung (retrofit) unterzogen wird. Auf diese Weise kann der digitale Zwilling in allen Lebensphasen der Anwendungssoftware zum Einsatz kommen, etwa wenn iterative bzw. wiederkehrende sowie aufeinander aufbauende Aktivitäten notwendig sind, bei denen entweder die Datengesamtheit aller im Feld befindlichen Maschinen eine Rolle spielt (Felddaten) oder das individuelle Gerät mit seinen Bibliotheken, Schnittstellen etc. beim Betrieb verwaltet werden muss. Dies ist bspw. bei der Installation neuer, ggf. erweiternder Anwendungssoftware dahingehen relevant, da sich diese (oder genutzte Ressourcen/Bibliotheken) gegenseitig beeinflussen und/oder bedingen und/oder gegenseitig ausschließen können.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass anhand dieser Datengesamtheit an der mobilen Arbeitsmaschine vorgenommene Konfigurationsänderungen erkannt und in der Cloud in Gestalt einer Änderungshistorie fortgeschrieben werden. Insbesondere bei vielfältigen Leistungsmerkmalen vereinfacht der Twin so das Variantenmanagement und dient zugleich als Referenzzustand der Software-Konfiguration auf dem Steuergerät, was wiederum Fehlerbehebung, Kundendienst und die Prüfung der Systemintegrität und Kompatibilität - etwa anhand eines digitalen Fingerabdrucks (fingerprint) - mit externen Sensoren und anderen Anbau- oder Peripheriegeräten und somit letztlich die Nutzung der Maschine durch den Nutzer erleichtert.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
- 2 schematisch ein Rechenzentrum gemäß einer zweiten Ausführungsform.
-
Ausführungsformen der Erfindung
-
Der digitale Zwilling beruht auf einer Abfrage des vorliegenden, realen Systems sowie der Generierung eines Abbildes (Modells) auf verschiedenen Abstraktionsebenen. In Betracht kommt etwa eine Liste der implementierten Leistungsmerkmale und Systemkomponenten sowie eine Zielsystembeschreibung, beispielsweise im Hinblick auf angeschlossene Sprühgeräte (sprayer; fachsprachlich: „Spritzen“) für Pflanzenschutzmittel. Eine derartige Beschreibung kann etwa anhand von Versionsnummer, Konfiguration, verfügbaren Schnittstellen oder Fingerprint (vgl. Hashwert, digitale Signatur) erfolgen, welcher etwa aus Signalen, Signaltypen (analog/digital) und -auflösungen oder deren Kombination gebildet werden mag. Ebenfalls denkbar ist ein Abbild der tatsächlichen Software, der Konfigurationen, Applikationsdaten etc.
-
Der digitale Zwilling kann auch auf der Abstraktionsebene der Systemarchitektur des Nachrüstsatzes (feature enabling kit, FEK bzw. notwendiger Maschinenperipherie) erzeugt werden, um das Steuergerät in seiner Gesamtheit zu betrachtet, welches auch mehrere - etwa verteilte oder vernetzte - Controller oder RAM umfassen kann. Zu denken ist schließlich an ein System-Architekturmodell des gesamten Kontexts, bestehend aus Maschine, Systemkomponenten, Steuergeräten, Sensoren, Sprayern etc.
-
Diese Abbildungen (Modelle) werden vorzugsweise in einer Cloud gespeichert und können aus verschiedenen Sichten ausgewertet oder anderweitig verarbeitet werden. Die zugrundeliegenden Daten selbst sind nicht der digitale Zwilling; letzterer eröffnet vielmehr eine oder mehrere Sichten (Komponentensicht, Usersicht, Marktsicht usw.) auf die zugrundeliegende Datenmenge bzw. das sich aus den Daten ergebende Modell. Jede Sicht ist hierbei für eine bestimmte Fragestellung oder Zielsetzung - z. B. Phase des Entwicklungsprozesses - einschlägig.
-
Im Folgenden wird die Erfindung anhand der allgemein bekannten und anerkannten Lebenszyklusphasen Entwurf (design, 11), Entwicklung (development, 12), Verteilung (deployment, 13), Betrieb (operations, 14) und Wartung (service, 15) aus verschiedenen Perspektiven, mit unterschiedlichen Aufgabenschwerpunkten und anhand mehrerer Fragestellungen vorgestellt (siehe 1). Ein Ziel der Verwendung digitaler Zwillinge besteht hierbei darin, einen realitätsnahen, wahlweise iterativen oder wiederholbaren Entwicklungsprozess (Konzept, Implementierung, Test usw.) zu unterstützen. Dies erlaubt gleichsam eine „Virtualisierung“ des Entwurfs-, Entwicklungs- und Verteilungsprozesses der Anwendungssoftware sowie deren Betriebes (14) im Feldeinsatz (16).
-
Den Ausgangspunkt für den Entwurf (11) bildet eine abstrakte Problembeschreibung, Funktionsidee oder Erkenntnisse aus einer Datenanalyse im Hinblick auf Korrelationen, Häufigkeiten usw., z. B. zum Erkennen von Unkraut und dessen Bespritzen unter Meidung der Nutzpflanze. In dieser Designphase wird eine Umgebung benötigt, die Plausibilisierung von Anforderungen und Grobdesign auf höherer Abstraktionsebene ermöglicht. Der digitale Zwilling bietet hierzu verschiedene Modelle - z. B. I/O-Modelle von Software, Hardware und anderen Systemkomponenten - und Sichten der Umgebung an, welche das Design der neuen Idee unterstützen.
-
Für ein Sprühsystem beispielsweise kommt eine Umgebung mit den Referenzmodellen für Steuergerät, Kamera, Spritze, Traktor, Pflanze (Bilder etc.) usw. mit optionaler Umgebungssimulation, z. B. für einen bestimmten Tankinhalt, in Betracht. Anschließend erfolgt die Systembeschreibung der neuen Idee mit ihren Systemgrenzen durch Dekomposition oder Zerlegung - ggf. wird hierdurch eine andere Abstraktionsebene betrachtet - in ein überlagertes Systemmodell (Systemumfeld bzw. Umgebung) mit Interaktionen über Schnittstellen, Kommunikationsbeziehungen und Datenströmen. Hierdurch lassen sich auch Wirkketten realisieren.
-
Nun lassen sich Modellkonflikte z. B. auf Basis von I/O-Modellen finden, wenn z. B. unplausible I/O-Kombinationen auftreten, konträre Steuersignale verwendet oder über- bzw. unterbestimmte Regelungssysteme entworfen wurden. Abschließend könnten bereits Vergleiche mit anderen Systembeschreibungen z. B. verschiedener Entwicklerteams oder Lieferanten im Hinblick auf Kompatibilität, Gleichteile, Varianten usw. mit dem Ziel erfolgen, gemeinsame Module im Sinne einer Plattform zu identifizieren. Dies ist bereits ein erster Entwurf von Wirkketten, welcher in der nachfolgend beschriebenen Entwicklung (12) weiter detailliert wird. Eine Übergabe von Entwurf (11) an Entwicklung (12) kann z. B. in Form einer Funktionsbeschreibung erfolgen.
-
Die vorstehend beschriebenen Modelle können auf realen Messdaten oder theoretisch ermittelten physikalischen Daten beruhen. Das konkrete Modell der Umgebung der zu entwickelnden Anwendungssoftware ergibt sich zum Beispiel aus Schnittstellen. Weiterhin ist beispielsweise ein gesamtes „Umgebungsmodell“ wünschenswert, um Signalketten zu schließen. Dieses kann im ungünstigsten Fall (worst case) die gesamte Umwelt abbilden, ist typischerweise jedoch abhängig von den verwendeten Schnittstellen - etwa den für den Regler-Entwurf (11) relevanten Pfaden - modular aufgebaut. Einzelne Module können sich auf die jeweils unterschiedlichen, zugrundeliegenden Referenzmodelle beziehen, z. B. eines für FEK, Sensor, Traktor, Spritze etc. Gegebenenfalls sind auch andere Module verwendbar, zum Beispiel standardisierte Schnittstellen, mit deren Hilfe verschiedenartige Simulationssoftware gekoppelt werden kann (functional mock-up interface, FMI), oder in MATLAB Simulink eingebundene Verhaltensmodelle. Im Kontext z.B. der digitalen Landwirtschaft (smart farming) umfassen diese Modelle insb. auch I/O- und andere Schnittstellen der Zielmaschine, die ggf. mit einem physikalischen Modell verarbeitet werden können. Das Modell liefert zudem die für das jeweilige Leistungsmerkmal im Entwicklungsschritt notwendigen Abhängigkeiten, insbesondere weitere Leistungsmerkmale, Bus- oder anderweitige Schnittstellen, externe Sensoren, Aktoren etc., die sich aus den I/O-Anforderungen des Leistungsmerkmales oder der Komponente ergeben.
-
Die Modelle und Schnittstellen zwischen diesen können sich dabei auf unterschiedliche Abstraktionsebenen beziehen. Hierbei sind auch gemischte Simulationsumgebungen (model in the loop, MiL; software in the loop, SiL; processor in the loop, PiL; hardware in the loop, HiL) denkbar.
-
Eine agrartechnische Anwendungssoftware könnte sich etwa auf den folgenden Anwendungsfall beziehen: Der Landwirt steht beim Feldeinsatz (16) seiner Maschine vor der Aufgabe, Beikräuter zu bekämpfen. Ein Inhaltsanbieter (content provider) möchte die Maschine um eine Softwarefunktion ergänzen, die den Landwirt bei dieser Bekämpfung unterstützt, indem sie Beikräuter erkennt und fallweise mit deren Behandlung reagiert. Dazu wird das Sprayermodell, das Kameramodell, das Traktormodell und das Umwelt- oder anderweitige Streckenmodell verwendet. Ein Modell weist hierbei einen Ein- und Ausgang auf; unterschieden wird z. B. zwischen Verhaltens- und Beschreibungsmodell.
-
Ein Designer weiß zunächst nur, welche Informationen, Peripheriegeräte etc. er verwenden möchte: Geschwindigkeit, Bild, etc. Erfindungsgemäß werden ihm daher diejenigen Modelle angeboten, deren Schnittstellen er benötigt. Die Kenntnis dieser Modelle ist für ihn von Bedeutung, da er die erforderlichen Modelle ggf. parametrieren muss.
-
Im Hinblick auf die Funktionssicherheit kann bereits im Zuge dieses Entwurfes (11) abgeschätzt oder gar bestimmt werden, was zulässig ist, wann dies eintreffen und wie dies erkannt werden kann sowie wo die kritischen Stellen in der Wirkkette und wo Redundanzen und/oder Plausibilisierungen notwendig sind.
-
Ein weiteres Ziel des vorgeschlagenen Verfahrens (10) ist die Unterstützung der Entwicklung (12) der Anwendungssoftware oder der Gesamtheit oder einzelner Teile von Funktions-, Software- und Hardware-Komponenten anhand des Entwurfes (11). Für eine virtuelle Entwicklung (12) ohne physikalischen Zugriff auf die Zielmaschine in einem iterativ validierenden und verifizierenden Prozess im Wechsel von Entwurf (11) und Entwicklung (12) werden ggf. Felddaten benötigt, um anhand von Messergebnissen und eines identifizierten datengetriebenen oder parametrierten physikalischen Verhaltensmodells die Softwarekomponente bestmöglich an ihre funktionale (relevante) Umgebung anzupassen bzw. zu testen, simulieren und freizugeben.
-
Hinsichtlich der Umgebung oder Umgebungsmodelle sind zudem Vererbungsmechanismen bzgl. der Art der Eigenschaften denkbar. Dies kann auch in Wechselwirkung mit Aufteilungen in verschiedene Varianten (Variantenbaum etc.) treten (horizontale Betrachtung, Varianz auf der jeweiligen Abstraktionsebene). In einem entsprechenden Variantenbaum sind den Kanten und Knoten konkrete Beziehungen der Knoten und Parameter zugeordnet. Hierbei kann sich wiederum eine Varianz im Parametersatz ergeben, z. B. aufgrund von Abnutzung, Alterung, Fertigungstoleranz etc. des betreffenden Bauteils.
-
Ebenfalls vorstellbar ist, dass Neukunden, die eine eigene Anwendungssoftware entwickeln möchten, ein kundenneutraler und lauffähiger Mindestumfang zur Verfügung gestellt werden kann. Dieser enthält Basisfunktionalitäten, die allen Maschinen einer ggf. generischen Klasse - etwa im Hinblick auf verwendete Schnittstellen und Baujahr - gleichartiger Maschinen gemein sind. Auf diese Weise wird eine Rückfallebene oder Ausgangsbasis geschaffen, auf die sich die Entwicklung (12) aus funktionaler Sicht stets beziehen kann. Dieser Softwarestand kann als funktional ausgereift und auf jedem der Klasse zugrundeliegenden Steuergerät verwendbar angenommen werden. In diesem Referenzzustand weist ein System keine funktional differenzierenden Dienst- oder anderweitige Leistungsmerkmale Dritter auf, kann aber auf deren Anforderung beispielsweise zum Zwecke der Fehlerbehebung aktualisiert oder weiterentwickelt werden. Für das durch seine Lauffähigkeit und einen Mindestfunktionsumfang definierte Grundverhalten des Systems reichen zum Beispiel Nachrichtenbroker, Integrations-Rahmenwerk, Abstraktionsschicht und Zeitraster, wobei letzteres durch den Kunden im Manifest individuell geändert werden kann.
-
Die Vorteile einer solchen Entwicklung (12) bestehen insbesondere darin, dass aufbauend auf den Ergebnissen des Entwurfes (11) in Form eines Schnittstellenmodells und resultierender Ein-/Ausgaben nun das dynamische Verhalten (Regelstrecke) im Hinblick auf Auflösung, Latenz sowie Rückkopplungen, Quer- und anderweitige Wirkungen auf der Regelstrecke entwickelt und Regressionstests desselben ausgeführt werden können. Durch dieses Vorgehen wird zudem das Risiko gesenkt, Personen, die Maschine oder andere Gegenstände im Rahmen von Tests - z. B. bei der Betrachtung von Randbereichen (hohe Drehzahlen etc.) - zu verletzen bzw. beschädigen. Virtuell sind dabei alle denkbaren Zustände der Regelstrecke verwendbar - auch solche, die in der Realität wegen des damit verbundenen Aufwandes selten oder gar nicht getestet werden können.
-
Insbesondere bei einer hohen Varianz der Zielmaschinen mit Sensoren, Aktoren etc. wären erschöpfende Testmaßnahmen mit realen Maschinen sowie deren sämtlichen Konfigurationsmöglichkeiten nicht realisierbar; anhand der unterschiedlichen digitalen Zwillinge und deren Sichten können diese jedoch automatisiert werden. Im Sinne eines Ökosystem-Gedankens können hierbei Schnittstellenanbieter (interface provider) Modelle ihrer Komponenten zur Verfügung stellen bzw. anhand der Felddaten ihre Komponenten optimieren.
-
Auf diese Weise werden auch Vorhersagen bzgl. eines funktional erwarteten Verhaltens oder die Simulation bestimmter Geschäftsfälle (business cases) möglich. Hierzu wird das Grobmodell oder der Entwurf (11) anhand realer Daten im Hinblick auf das erwartete Systemverhalten betrachtet. Die Ergebnisse der Simulation können sodann mit aufgezeichneten Messwerten abgeglichen werden, etwa zum Testen oder Bewerten der gemäß einem neuen Algorithmus tatsächlich ausgebrachten und aufgezeichneten Menge eines Saatgutes. Der zugrundeliegende Geschäftsfall lässt sich durch diesen Abgleich validieren.
-
Auch eine Teilautomatisierung der Entwicklung (12) ist denkbar: So lassen sich etwa bereits vor dem Feldeinsatz (16) mathematische Verfahren wie z.B. Neuronalen Netze trainieren, physikalische Funktionen parametrisieren, Lern- und Adaptionsverfahren lernen und adaptieren und Funktionen initialisieren. Die Benutzererfahrung (user experience) wird durch die mögliche Fernunterstützung beim ersten Versuch bzw. im Fall von Störung oder Wartung (15) verbessert. Vorteile ergeben sich auch im Hinblick auf die Partitionierung von Softwarekomponenten und deren Zuweisung an verschiedene Steuergeräte (electronic control units, ECUs) mit Kommunikationsbeziehungen auf Ausführungseinheiten wie VCG, ECU, virtueller Maschine, Hypervisor, Backend, intelligentem Sensor oder Aktor. Eine Integration von kundenspezifischen Testszenarien - z. B. durch Auswahl dezidierter Messprotokolle - und Modellen in die bereits vorhandene Infrastruktur ist ebenfalls möglich. In Betracht kommt schließlich eine SiL- oder anderweitige Simulation anhand des digitalen Zwillings, sodass Software bereits im Labor geprüft werden kann.
-
Wie bereits erläutert sind für die Nutzung des digitalen Zwillings immer dessen Sichten relevant: Ein Softwareentwickler beispielsweise will den Nutzen einer Anwendungssoftware und des ihr zugrundeliegenden Geschäftsfalles bewerten, deren Anwender prüfen, ob dieser Nutzen diese Kosten rechtfertigt. Bei Kenntnis der realen bzw. zu verändernden Maschine oder eines entsprechenden Systems kann auch geprüft werden, welche der zur Auswahl stehenden Software- oder Hardwarekomponenten - gemäß funktionaler Anforderungen, Ziele oder Leistungskennzahlen (key performance indicators, KPls) wie Genauigkeit, Kosten, Investition oder Performance - am besten geeignet sind.
-
Die Aufgaben des digitalen Zwillings bei der Verteilung (13) der Anwendungssoftware auf Hardware in sich ändernden, inhomogenen Integrationsumgebungen gestalten sich vielfältig. Die Freigabe etwa einer SOTA kann in der Regel nicht pauschal erfolgen, da die Maschinen im Feldeinsatz (16) verändert worden sein könnten und die Gefahr eines unvorhersehbaren, zerstörerischen oder auf andere Weise unsicheren Verhaltens der Maschine besteht. In diesem Fall bildet der digitale Zwilling der betroffenen, individualisierten Maschine idealerweise diese Veränderungen ab und ermöglicht so eine Installation von neuer oder erweiterter Anwendungssoftware ohne unerwünschte Rückwirkung auf das Verhalten des Zielsystems.
-
Der digitale Zwilling bildet hierzu die ggf. veränderte Maschine, deren FEK oder Software ab und erlaubt es im Falle erwarteter Rückwirkungen abzuschätzen, ob diese im Rahmen der Anforderungen noch zulässig sind. Zur Prüfung der SOTA, z. B. zur Aktualisierung einer Schnittstelle bei neuem Leistungsmerkmal der Maschine, dienen die Aufzeichnungen der im Vorfeld der Verteilung (13) durchgeführten Tests als Grundlage für Simulationen und Tests nach Entwurf (11) und Entwicklung (12). Hieraus lässt sich eine Prognose für neue Leistungsmerkmale dezidierter Maschinen nach der eigentlichen Entwicklung (12) der betreffenden Anwendungssoftware ableiten.
-
Eine entsprechende Prüfung der wechselseitigen Kompatibilität zwischen Anwendungssoftware und Maschine lässt sich anhand folgenden konkreten Beispiels nachvollziehen: Ein Landwirt kann im Rahmen einer präfunktionalen Kompatibilitätsprüfung über eine Backend-Anwendung testen, ob die Software mit der Konfiguration seiner Maschine funktioniert, deren digitaler Zwilling in der Cloud (17) existiert. In diesem Rahmen können bereits statische und dynamische Abhängigkeiten und Kompatibilitäten anhand der Daten der digitalen Zwillinge - z. B. die Abarbeitungsreihenfolge im Hinblick auf eine mögliche Systemblockade (deadlock) oder zirkuläre Referenzen - geprüft oder die resultierende Auslastung der Systemressourcen abgeschätzt werden, bevor die Software zum ersten Mal auf dem konkreten Steuergerät oder der damit ausgestatteten Maschine installiert wird. Dies wiederum ermöglicht eine vereinfachte Freigabe von Funktionalitäten unabhängig vom Steuergerät z. B. in der Cloud (17), da die funktionale Kompatibilität mit sich verändernden Systemteilen wie Mechanik und anderer Hardware (etwa einer dynamisch veränderlichen Sensorschnittstelle oder eines geänderten Zugriffes auf selbige) sowie Software einschließlich deren Komponenten im Sinne einer postfunktionalen Kompatibilitätsprüfung sichergestellt werden kann.
-
Auch die vor der Verteilung (13) im Sinne einer präfunktionalen Kompatibilitätsprüfung abzuschätzende funktionale Kompatibilität der Software mit der Zielmaschine kann nicht nur deren Typ und Klasse, sondern etwa die tatsächliche reale Konfiguration der Maschine, deren Version und nachträgliche spezielle Veränderungen berücksichtigen.
-
Sichergestellt werden kann auf diesem Wege auch die funktionale Sicherheit, indem Szenarien geprüft werden, die zu sicherheitskritischen Situationen führen könnten. Dies erweist sich als besonders hilfreich, da der Stand der Sicherheitstechnik und die darauf basierenden gesetzlichen Anforderungen in diesem Bereich sich kontinuierlich weiterentwickeln.
-
Schließlich lässt sich im Vorfeld der Verteilung (13) einer neuen Anwendungssoftware sicherstellen, dass deren alte Kernfunktion erhalten bleibt und somit eine Abwärtskompatibilität gewährleistet werden kann.
-
Mit der Erkennung von unplausiblen Signalmustern z. B. in der Integrationsschicht durch Abgleich mit anderen Sensoren, Prozessen etc. wird anhand von Korrelationen und Kreuzkorrelationen eine logische Verknüpfung zur Arbeitsmaschine mit Werkzeug und Umgebung oder zum Arbeitsprozess und zum funktionalen Verhalten ermöglicht. Daraus lassen sich Fehler im System - etwa im Hinblick auf Sensoren, Aktoren und deren Steuerung, Software, die Mechanik oder andere Aspekte der Maschine - sowie Veränderungen außerhalb des Systems ableiten. Die beschriebene Erkennung eröffnete auch eine Vorausschau im Hinblick auf die Frage, ob trotz oder gerade wegen der Veränderung das tatsächliche System mit neuen oder alten Komponenten wieder bzw. immer noch funktionieren wird. Es kann schließlich analysiert werden, ob sich im System etwas unzulässig geändert hat. Sowohl bei der präfunktionalen als auch bei der postfunktionalen Kompatibilitätsprüfung kann ein Ergebnis darin bestehen, dass ggf. Funktionalitäten abgeschaltet oder neue Software heruntergeladen werden muss, z. B. für entsprechende Erweiterungsschnittstellen (plug-ins).
-
Im Betrieb (14) werden die Daten insbesondere zur Laufzeit der mobilen Arbeitsmaschine gesammelt und ggf. aggregiert, damit z. B. der digitale Zwilling überhaupt entwickelt werden kann bzw. dessen Sichten ableitbar sind. Die Grundstrukturen für einzelne Sichten (z. B. Kompatibilitätsprüfungen) können auch ohne diese Daten entwickelt werden, bspw. wenn lediglich Konfigurationen oder statische Sichten notwendig sind. Die Datenerfassung dient auch dazu, dass die Modelle hinsichtlich ihres I/O-Verhaltens (sowohl kausal als auch in Korrelation) verwendet werden können und eine Prüfung daraufhin vorgenommen werden kann, welche Maschinen welche bestimmte Anwendungssoftwareunterstützen. Eine Aggregation kann nach definierten Regeln maschinenübergreifend sämtliche Merkmale einzelner Twins oder konsistente Sichten eines Twins betreffen. Ihr Ergebnis kann durch eine Metanalyse dazu verwendete werden, Gleichteile bzw. typische Varianten zu identifizieren und diese bspw. im Entwurf (11) zu verwenden. Zudem können anhand der aggregierten Felddaten, welche das gemessene I/O-Verhalten der gesamten Varianz an Maschinen abbildet, Verwendungsnachweise erbracht, Entscheidungen getroffen oder zumindest unterstützt und varianten- und versionsübergreifende Analysen der Softwarequalität angefertigt werden. Dies ermöglich eine Restrukturierung der Software, um deren Qualitätsminderung (quality degradation) entgegenzuwirken.
-
Beispielsweise weist ein typischer Sprayer, welcher für die digitale Landwirtschaft geeignet ist, ein bestimmtes Aussehen auf und wird mit bis zu 50 Abschnitten (sections) auf einer Fläche von 100 ha bis 200 ha eingesetzt. Das Referenzmodell sollte so konfigurierbar sein, dass sich alle im Feldeinsatz (16) befindlichen Zielvarianten abbilden lassen und für eine Validierung im Rahmen von Entwurf (11) und Entwicklung (12) zur Verfügung stehen. Ein weiteres Anwendungsbeispiel stellt die statische oder dynamische Bestimmung eines Wartbarkeitsindex von Anwendungssoftware dar.
-
Veränderungen der Systemumwelt seit der Installation können dynamisch zur Laufzeit erfasst werden. Diese Erfassung ermöglicht eine permanente Prüfung und Aktualisierung des digitalen Zwillings, d. h. jedes Steuergerät hat einen „eigenen“ digitalen Zwilling aus einer vom Design abhängigen Sicht einschließlich einer Änderungshistorie, beispielsweise:
- 1. Aktualisierungslauf am 24.11.2006
- 2. Aktualisierungslauf am 26.03.2018
- 3. Aktualisierungslauf am 01.07.2019
-
Hieraus folgt ein Abgleich des Fingerprints, um zu prüfen, ob sich seit der letzten Prüfung die Umgebung geändert hat und hieraus einen Indikator dafür abzuleiten, ob sich etwas am System - ggf. fehlerhaft - verändert hat.
-
Der beschriebene Abgleich erweist sich auch für die Diagnose und nachfolgend beschriebene Wartung (15) als wichtig. Eine Änderung des I/O-Verhaltens ließe sich als Hinweis auf Unstimmigkeiten an der Umgebung deuten, die Vermerke im Fehlerspeicher bezüglich einer ggf. missbräuchlichen Verwendung etc. begründen könnten.
-
Verändert sich etwas an der Systemkonfiguration, insbesondere der installierten Software, oder das gesamte System, so werden, sofern die Änderung bzgl. des neuen Systemzustandes beabsichtigt ist - etwa bei beabsichtigter Änderung der Hardware, Software, Konfiguration, angeschlossenen Maschinen etc. -, die korrespondierenden digitalen Zwillinge bzw. Sichten ggf. mit Änderungshistorie aktualisiert bzw., wenn dies erstmalig geschieht, überhaupt erst generiert. Lässt sich anhand des Fingerprints hingegen eine Änderung vermuten, die auf externe Einflüsse wie Defekt oder Verschleiß zurückzuführen ist, so wird eine Fehlerbehandlung eingeleitet. Nicht nur der digitale Zwilling, sondern auch der lokal auf dem Steuergerät ermittelte Fingerprint ist somit zu betrachten: Dieser liefert ein Abbild der I/O-Signalmuster unterschiedlicher Signalarten auf verschiedenen Bussen des Steuerungssystems. Deshalb werden Signalmuster mit den vorgesehenen und korrekten Funktionen aufzeichnet und zusammen mit dem digitalen Zwilling gesichert. Die Aufzeichnungen dienen als Grundlage für Simulation und Test, um sowohl Funktionsänderungen zu prüfen als auch um Veränderungen der Ein- oder Ausgabe des Systems festzustellen.
-
Bei einer Abweichung des aktuellen vom lokal oder in der Cloud (17) zuvor abgespeicherten Fingerprint ist eine von der Verbindung zur Cloud (17) abhängige Ereignisbehandlung (event handling) vorgesehen: Besteht die Verbindung, so wird unter Zuhilfenahme bestimmter Algorithmen die Funktionsfähigkeit geprüft und das Steuergerät oder bestimmte Funktionen desselben gegebenenfalls für die Benutzung temporär gesperrt oder nach der Prüfung wieder freigegeben. Besteht hingegen keine Verbindung, so kann anhand einer internen Positivliste (whitelists) geprüft werden, ob die Veränderung im Sinne der Funktionsfähigkeit unkritisch ist. Lässt sich dies nicht bestätigen, so wird das Gerät temporär gesperrt, bis eine Verbindung zum Backend in der Cloud (17) besteht und dann wie oben verfahren werden kann.
-
Der Fingerprint sowie die Positivliste sind Teil des digitalen Zwillings und sollten entsprechend der Leistungsmerkmale und entsprechender Manifeste aktualisiert werden. Der digitale Zwilling kann hierbei als eine abgeglichene und ggf. validierte Referenzkonfiguration dienen, um bspw. feststellen zu können, ob seit der letzten Aktualisierung beabsichtigte Funktionsänderungen und insbesondere -erweiterungen stattgefunden haben und somit gültig sind. Denkbar ist auch, dass das System des Twins regelmäßig mit entsprechenden Routinen auf Integrität und Plausibilität geprüft wird. Neben der Aufzeichnung der aktuellen Konfiguration und des durch Felddatenerfassung ermittelten Status - z. B. im Hinblick auf Start- und Abbruchshäufigkeit bestimmter Funktionen oder Diagnose auf verschiedenen Ebenen des Systems, Subsystems oder der Funktion - können auch die angeschlossenen Maschinen (Anbaugeräte) sowie deren zeitliche Veränderung (Historie) vermerkt werden.
-
Im Fehlerfall können durch Analyse der digitalen Zwillinge aus relevanten Sichten Fehlermuster erkannt werden und entsprechende Handlungsanweisungen oder -optionen für Service und Wartung (15) - etwa ein Austausch von Sensoren - angeboten werden. Denkbar ist hierbei auch eine automatisierte Fehlerabwicklung, bei der die notwendigen Behebungsschritte automatisiert entwickelt werden. Letztere können beispielsweise eine Auswahl vordefinierter Maßnahmen, Vorschläge für Nutzer, Entwickler etc. und die Definition neuer Maßnahmen mittels künstlicher Intelligenz (KI) umfassen. Bei entsprechend identifizierten Fehlerszenarien können diese ggf. auf allen ebenfalls betroffene Maschinen automatisch präventiv behoben werden, oder die entsprechenden Datensätze werden zumindest in einer Datenbank abgelegt und für zukünftige Diagnosen vorgehalten. Eine erkennbare, in diesem Fall durch den Endnutzer herbeigeführte Veränderung des Systems mag beispielsweise darin bestehen, dass ein Landwirt einen Sensor entfernt und dessen Anschluss permanent mit dem Pluspol der Starterbatterie (fachsprachlich: „Dauerplus“) verbindet. Beim Eingehen einer diesbezüglichen Fehlermeldung werden der Fingerprint und digitale Zwilling auf Plausibilität geprüft.
-
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Rechenzentrum (20) in der Cloud (17) implementiert sein, wie die schematische Darstellung der 2 verdeutlicht.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102015203766 A1 [0005]
- US 20060206449 A1 [0006]
- DE 102018205872 A1 [0007]
