-
Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen einer Anwendungssoftware. 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 Landmaschinen eingesetzt. Zur telematischen Verbindung zwischen dem die Steuergeräte koppelnden Bussystem und dem Internet (der sinnbildlichen „Cloud“) dient hierbei typischerweise eine Fahrzeugverbindungsschnittstelle (vehicle connectivity gateway, VCG).
-
Jenseits der Wartung und Fehlerbereinigung bereits installierter Software lässt sich der Funktionsumfang fahrzeuginterner Steuergeräte auf diesem Wege um Leistungsmerkmale (features) erweitern, welche vorhandene Sensoren und Aktoren für neue Anwendungsfälle nutzen. Entsprechende Applikationen können durch Hersteller oder Erstausrüster (original equipment manufacturer, OEM) einer Landmaschine - etwa mittels eines Entwicklungskits (development kit) - erstellt und auf einer digitalen Vertriebsplattform in der Cloud angeboten werden. Als denkbare Erweiterungen kommen zum Beispiel fortgeschrittene Telemetrie- oder agrartechnische Spezialfunktionen wie die gezielte Unkrautbekämpfung in Betracht.
-
DE102015203766A1 offenbart ein Teilsystem für ein Fahrzeug mit einem über eine Luftschnittstelle mit einem Gerätemanagement-Server des Backends verbundenen Gerätemanagement-Client zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, einem über die Luftschnittstelle mit einem Download-Server des Backends verbundenen Download-Client zum Herunterladen eines Softwareupdates von dem Backend in das Fahrzeug, mit dem Download-Client verbundenen Softwareupdate-Clients zum Anwenden des Softwareupdates und einen mit dem Download-Client und den Softwareupdate-Clients verbundenen Fahrzeugupdate-Client zum Koordinieren des Softwareupdates.
-
Im Zuge einer unabhängigen Entwicklung findet die im Rechenzentrumsbetrieb bereits seit Längerem übliche Container- oder Betriebssystem-Virtualisierung in jüngerer Zeit vermehrt Eingang in die Praxis der eingebetteten Systeme (embedded systems). Diese Methode erlaubt es, mehrere Instanzen eines Betriebssystems als sogenannte Gäste (guests) isoliert voneinander auf einem Wirtssystem (host) zu betreiben. Auf diese Weise kann der Wirt jeder innerhalb eines solchen Containers gekapselten Anwendung (application, app) eine vollständige Laufzeitumgebung zur Verfügung stellen, die beispielsweise dynamische Bibliotheken der vom jeweiligen Entwickler genutzten Programmiersprache wie Java, C oder Python umfassen mag. Im Gegensatz zur Nutzung eines Hypervisors erlegt diese „leichtgewichtige“ Form der Virtualisierung den Gästen zwar einige Einschränkungen auf, birgt jedoch den Vorteil, dass alle Container den Kern des nativen Betriebssystems - typischerweise Linux, BSD, Solaris oder ein anderes Unix-ähnliches System - gemeinsam nutzen. Die Nutzung von Containern schont somit die knappen Betriebsmittel eingebetteter Systeme.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Bereitstellen einer Anwendungssoftware, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug dieser Lösung liegt in der eröffneten Möglichkeit zur individuellen Erzeugung sowie des Startens, Ausführens und Beendens eines Containers zur Laufzeit auf einem Steuergerät (electronic control unit, ECU). Hierzu wird ein die Anwendungssoftware beschreibendes sogenanntes Manifest, eine ausführbare Programmdatei (Nutzsoftware im Gegensatz zu Software, welche die Infrastruktur darstellt) und ein Containerframework - gegebenenfalls mit Vererbungsmechanismen - verwendet.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass durch die Verwendung von Templates eine Vielzahl von Varianten der Anwendungssoftware auf standardisierte Weise gehandhabt werden. Aus einem solchen Template (nachfolgend: „generischer Container“) wird beim Installationsprozess ein spezifischer Container abgeleitet, dessen Inhalt auf dem Steuergerät ausführbar ist. Da die Erstellung des Containers anhand eines festgelegten Manifests abläuft, können die Eigenschaften des Containers und der dadurch erzeugten Umgebung im Hinblick auf das jeweilige Feature individuell angepasst werden. Beispielsweise können detaillierte Einschränkungen der Zugriffsrechte (Infrastrukturzugriffe, Ports, Schnittstellen, Dateizugriff etc.) realisiert werden.
-
Die Erzeugung des Manifests sowie der zu containerisierenden Daten kann hierbei werkzeugunterstützt durch den Entwickler erfolgen. Letzterem eröffnet sich durch Anpassung des Manifests eine Vielzahl von Konfigurationsoptionen; beispielsweise kann er festlegen ob ein Feature auch Daten zur Laufzeit in einem Unterverzeichnis der Landing Zone ablegen will. Auch Containertechnologie - zu denken ist etwa an die quelloffenen Systeme Docker oder LXC -, Plattform-Struktur und Laufzeitverhalten, etwa Einschränkung oder Zuweisung von Ressourcen, CPU, RAM und I/O werden im Manifest beschrieben, das beispielsweise in einer Auszeichnungssprache wie XML verfasst sein mag.
-
Ein Vorteil der Unterscheidung generischer und spezifischer Container liegt darin, dass die Datenmenge beim Herunterladen (download) verkleinert wird, da auf der ECU bereits ein Template vorhanden ist, welches die wichtigsten Bibliotheken bereits enthält, und somit nur Änderungen komplettiert bzw. aktualisiert werden müssen. Die Erstellung der Container kann zudem in einer Testumgebung erfolgen, in welcher die Funktion der Anwendungssoftware kontrolliert werden kann. Dieser Mechanismus verbessert folglich die Überprüfbarkeit der einzelnen Features unabhängig von deren konkreter Ausgestaltung.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass nach der Inbetriebnahme der Software der generische Container bedarfsweise aktualisiert wird. Der Vorteil hierbei ist, dass die Softwareumgebung der Anwendung gepflegt werden kann, ohne diese selbst auszutauschen.
-
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 dem Verfahren zugrundeliegendes Schalenmodell.
- 3 das Blockdiagramm eines Systems gemäß einer zweiten Ausführungsform.
-
Ausführungsformen der Erfindung
-
1 illustriert die grundlegenden Schritte (1-10) eines erfindungsgemäßen Verfahrens, das nunmehr am Beispiel der Softwareplattform (11) gemäß 2 erläutert sei.
-
Ausgangspunkt des nachfolgend beschriebenen Prozesses ist, dass ein Entwickler eine Anwendungssoftware (16 - 2) entwickeln und auf einem geeigneten Steuergerät bereitstellen möchte. Vorausgesetzt sei hierbei, dass der Entwickler bzw. Designer Zugriff auf einschlägige Tools hat. In Betracht kommen eine proprietäre Integrationsumgebung (A2 - 2) ebenso wie entsprechende Plug-ins für eine integrierte Entwicklungsumgebung wie „Eclipse“.
-
Mittels des gewählten Werkzeuges werden die für das geplante Feature benötigten Benutzer- und Programmierschnittstellen und Metadaten wie IDs, Ressourcenbedarf, Zielmarkt oder Serverstandort spezifiziert (Prozess 1 - 1).
-
Auf dieser Grundlage wird automatisiert ein Programmgerüst (skeleton 15 - 2) mit entsprechender Anwendungsprogrammierschnittstelle (application programming interface, API) generiert (Prozess 2 - 1), welches dem Entwickler in seiner Entwicklungsumgebung als Vorlage dient. Als Arbeitsergebnis kann der Entwickler beispielsweise ein Simulink-Modell, entsprechenden Quell- oder Objektcode oder einen vollständigen Container abliefern. Während Modell und Quellcode weitreichende Rückschlüsse auf die Funktionsweise der Anwendungssoftware (16 - 2) erlauben, erweist sich eine Rückentwicklung von Objektcode oder Container vergleichsweise aufwändig, sodass entsprechende Ausgestaltungen dem geistigen Eigentum des Entwicklers einen gewissen Schutz bieten.
-
Im Anschluss erfolgt ein automatisierter Aufbau der benötigten Wrapper (14 - 2) und Verknüpfung (Prozess 3 - 1) mit dem Skeleton (15 - 2) zu einer ausführbaren Programmdatei (executable). Hierbei kann es sich um eine Binärdatei in Maschinensprache, eine Bytecode-Datei, die direkt oder durch ein Laufzeitsystem ausgeführt werden kann, oder eine Textdatei handeln, die von einer Betriebssystem-Shell interpretiert wird. In diesem Schritt werden zudem die zur Anbindung an etwaige Abstraktionsschichten benötigten Schnittstellen (A1 - 2) generiert und der Programmdatei hinzugefügt.
-
Die ausführbare Programmdatei sowie Manifest und Daten werden anschließend zu einer ZIP- oder anderweitigen Archivdatei paketiert (Prozess 4 - 1). Bei Verwendung von Docker beispielsweise enthält der Ordner „Dockerfolder“ in einer Textdatei namens „Dockerfile“ eine Beschreibung der erforderlichen Laufzeitumgebung, beispielsweise für die Programmiersprache Java. Ein weiterer Ordner, beispielsweise namens „app“, enthält die ausführbare Programmdatei.
-
Die solchermaßen erzeugte Archivdatei wird in der Cloud-Repository gespeichert (Prozess 5 - 1). Dort können weitere Schritte zur Sicherung der Softwarequalität stattfinden, z. B. Cloud-basierte Tests.
-
Die Archivdatei wird aus der Cloud in die Landezone des Zielsteuergerätes oder anderweitigen Zielsystems (18 - 2) geladen (Prozess 6 - 1).
-
Abhängig vom Manifest können für den weiteren Verlauf zwei Fälle unterschieden werden (Prozess 7 - 1): Entweder wird das Paket unmittelbar nach Speicherung in der Landezone automatisch installiert, oder der Benutzer muss die Installation manuell autorisieren.
-
Ungeachtet dieser zwei Varianten gestaltet sich die online auf dem Steuergerät vorgenommene Installation (Prozess 8 - 1) beispielsweise wie folgt: Nach dem Entpacken der gesamten Archivdatei und Parsen des Manifestes werden Feature-spezifische Landezonen angelegt, um die Trennung unterschiedlicher Anwendungen (16 - 2) ohne gegenseitigen Zugriff oder gegenseitige Sichtbarkeit zu gewährleisten. Zudem wird die beispielsweise in der Datei „Dockerfile“ enthaltene Beschreibung geparst. Sodann wird ein Abbild des generischen Containers (12 - 2) angelegt; vorzugsweise wird hierzu eine objektorientierte Containertechnologie mit den ihr eigenen Vererbungsmechanismen verwendet. Wird im Nachhinein der generische Container (12 - 2) angepasst, so übernehmen auf diese Weise alle davon abgeleiteten spezifischen Container (13 - 2) diese Änderung in entsprechender Weise.
-
An dieser Stelle wird der spezifische Container (13 - 2) anhand der geparsten Beschreibung befüllt und angepasst. Ggf. benötigte Bibliotheken sowie der Inhalt des Ordners „app“ mit der ausführbaren Programmdatei werden hierzu in den Container, die Werte des Manifests hingegen in die Registry übertragen, um sie persistent zu speichern.
-
Schließlich wird auf Anforderung des Benutzers zur Ausführung des Containers, etwa mittels einer entsprechenden GUI, über einen Nachrichtenbroker (message broker) wie MQTT oder DDS ein Signal an eine für das Lebenszyklus-Management (life cycle management, LCM) der Anwendungssoftware (16 - 2) zuständige Komponente gesendet. Diese überprüft das Signal und den Zustand der Anwendungssoftware (16 - 2) bzw. des sie umfassenden spezifischen Containers (13 - 2) und sendet ein Signal an einen Ausführungsmanager. Dieser wiederum nimmt den spezifischen Container (13 - 2) in Betrieb und führt die enthaltene Programmdatei an einem vorgegebenen Einsprungspunkt (entry point) aus (Prozess 9 - 1).
-
Basiert die Erzeugung der Container auf einem Vererbungsmechanismus, so können durch Updates der generischen Container (12 - 2) bspw. Bug-Fixes bei Sicherheitsproblemen der Laufzeitumgebung der Anwendungssoftware (16 - 2) vorgenommen werden (Prozess 10 - 1).
-
Dieses Verfahren (1-10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware teilweise in der Cloud (20) und teilweise in einem Steuergerät implementiert sein, wie die schematische Darstellung der 3 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]
