WO2021089295A1 - Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system - Google Patents

Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system Download PDF

Info

Publication number
WO2021089295A1
WO2021089295A1 PCT/EP2020/079069 EP2020079069W WO2021089295A1 WO 2021089295 A1 WO2021089295 A1 WO 2021089295A1 EP 2020079069 W EP2020079069 W EP 2020079069W WO 2021089295 A1 WO2021089295 A1 WO 2021089295A1
Authority
WO
WIPO (PCT)
Prior art keywords
software component
file
execution
software
dependencies
Prior art date
Application number
PCT/EP2020/079069
Other languages
English (en)
French (fr)
Inventor
Udo Schulz
Mouham Tanimou
Joshua-Niclas OERGELE
Micha Muenzenmay
Tobias Krug
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2021089295A1 publication Critical patent/WO2021089295A1/de

Links

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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse

Definitions

  • the present invention relates to a method for managing a software component for a given system.
  • the present invention also relates to a corresponding device, a corresponding computer program and a corresponding storage medium.
  • SW software
  • OTA over-the-air
  • VCG vehicle connectivity gateway
  • vehicle-internal control units can be expanded in this way by features that use existing sensors and actuators for new applications.
  • Corresponding applications can be carried out by the manufacturer or original equipment manufacturer (OEM) an agricultural machine - for example by means of a development kit - and offered on a digital sales platform in the cloud.
  • Conceivable extensions are, for example, advanced telemetry or special agricultural functions such as targeted weed control.
  • DE102015203766A1 discloses a subsystem for a vehicle with a device management client connected via an air interface to a device management server of the backend for exchanging device, vehicle and diagnostic and software update information, one connected via the air interface to a download server of the backend Download client for downloading a software update from the backend into the vehicle, software update clients connected to the download client for applying the software update and a vehicle update client connected to the download client and the software update clients for coordinating the software update.
  • manifest files are also used in computer technology in order to summarize metadata via an archive or another network of other files.
  • Corresponding concepts are used, for example, in the common language infrastructure (CLI) standardized in accordance with ISO / IEC 23271, the Windows operating system, the hypertext markup language HTML5, the Java language environment and various Linux distributions.
  • CLI common language infrastructure
  • US20060206449A1 proposes package management by means of a software package manifest (SPM) for updating embedded systems.
  • SPM software package manifest
  • the container or operating system virtualization which has been common in data center operations for a long time, has recently increasingly found its way into the practice of embedded systems.
  • This method makes it possible to operate several instances of an operating system as so-called guests in isolation from one another on a host system. In this way, the host can use any application encapsulated within such a container.
  • provide a complete runtime environment which may include, for example, dynamic libraries of the programming language used by the respective developer, such as Java, C or Python.
  • this “lightweight” form of virtualization imposes some restrictions on the guests, but has the advantage that all containers are the core of the native operating system
  • the invention provides a method for managing a software component for a given system, a corresponding device, a corresponding computer program and a corresponding storage medium according to the independent claims.
  • This approach aims to describe and define the way in which software components are integrated into their software environment and how they are themselves
  • the manifest of a software component corresponds to the "set of rules" of a service-oriented system architecture.
  • a manifest is therefore a file that contains all static, dynamic and functional information for integrating and executing a software component in a specific software environment. It describes the software component over its entire life cycle: development, testing, storage, deployment, installation, initialization, execution, termination and deinstallation. Compared to the use of static configuration files, which are only used for one phase, this dynamic offers the advantage of increased flexibility.
  • the measures listed in the dependent claims enable advantageous developments and improvements of the basic idea specified in the independent claim. It can thus be provided that dependencies of the software components are also described in the manifest, on the basis of which the target system is then set up for execution.
  • a corresponding embodiment enables the consideration of relationships, service orientation, a control of interpretations of the content as well as the integration of the software component in changeable software environments.
  • Figure 1 shows the flow chart of a method according to a first embodiment.
  • FIG. 2 an exemplary manifest file.
  • FIG. 3 schematically shows a control device according to a second embodiment.
  • FIG. 1 illustrates the basic steps of the method according to the invention, which will now be explained in detail using the example according to FIG.
  • the feature manifest (20) shown there is a specific form of an SPM, contains metadata of the relevant software component or the corresponding feature and can be reproduced in XML as shown in the illustration or retrieved from a database.
  • Further characteristics and features of an SPM include the brand under which the software component is sold, the legal unit to which the software component belongs and an ID for identifying an organizational unit within the system environment according to the invention. Every legal entity has at least one such ID.
  • An ID for identifying a project within the system environment according to the invention is also specified. Such a number can be assigned during development, administration, storage or provision, depending on the embodiment of the invention. Organization and project ID allow a clear identification of software components from different projects.
  • Another consideration is an ID to identify the revision of a software component.
  • the aim is to uniquely identify this with the help of the organization and project ID, so that compatibility checks or the like. can be executed with regard to a specific version of a specific software project of a specific organizational unit.
  • the file (20) also includes a short name of the software component for installation instructions, user interface elements or the like, a verbal description of the software component z. B. as an aid to the end user and the type of component.
  • the software and hardware infrastructure required by the system e.g. B. Docker, a certain operating system kernel with certain modules, libraries, connected hardware such as sensors and actuators, system capabilities such as a real-time clock, CAN alarm function, permanent voltage supply, GPU etc.
  • a memory area is required to transfer outgoing data to the Stream cloud; a corresponding area for input data (landing zone) is generated in each case.
  • Further dependencies (22) relate to the required resources (24) such as RAM, Flash, CPU runtime requirements - if necessary, taking into account real-time targets -, network bandwidth or ports and properties of the container such as name, version, type or path of the initialization script.
  • required resources such as RAM, Flash, CPU runtime requirements - if necessary, taking into account real-time targets -, network bandwidth or ports and properties of the container such as name, version, type or path of the initialization script.
  • the dynamic dependencies are differentiated according to the following list. Contains that Manifest (20) does not provide any information regarding these characteristics, it is assumed that these are not relevant for the software component.
  • the start (25) of the software component can be controlled via the entries in the manifest (20).
  • the aim of this procedure is not to provide specific start commands, but to enable all the dependencies required at runtime to be available before the software component is started and to be checked for compatibility.
  • the data from the manifest (20) are aggregated and transformed into a boot sequence. This tree-like structure is then used to start the system in a coordinated manner.
  • a specific command is also provided to control the software component in the container - if necessary, with dynamic arguments or the like. - to start as well as the basic information as to whether an automatic start of the software component is desired.
  • This software component may, for example, only be started if the software components listed in the manifest (20) have already been started, or all software components listed there may only be started if the software component at hand has already started.
  • Software components can also be specified that are essential for executing the component described in the manifest (20) and must therefore be started before this component. This information is also used to define the boot and shutdown sequence.
  • a further specification allows the following scenario to be taken into account: If the required software component was not started, then neither the present nor other components described in the manifest (20) are started. There is no dependent order for boot or shutdown. A "weaker" specification in this sense indicates that it has no effect if the software component could not be started. Such an indication is thus to be understood as a “recommendation to start”, for example in the case of an application that provides services for filter functions or an optional function that the component does not need to fulfill its critical function.
  • the following case can also be shown in the manifest (20): If the software component was stopped, then another software component is also stopped.
  • a further specification allows that, provided that individual components are started or stopped within a defined grouping or concatenation, a number of other software components are also started or stopped. Conversely, you can specify the other software components with which simultaneous execution is not possible or not intended. The system determines this and prevents the respective execution or initiates a selection, for example through user interaction.
  • the behavior of the software component when it is terminated (26) can be influenced in a corresponding manner.
  • the start order must be reversed.
  • the boot sequence is therefore inverted and thus the tree-like sequence is carried out in the reverse direction.
  • One aim of this convention is to reduce complexity for the developer, which is why no separate entries are currently planned. Should a need arise, specific data for the shutdown process can of course be incorporated.
  • a corresponding module monitors the software components on the basis of their manifests (20) in this regard and, if necessary, gives the system the command to stop the component.
  • the behavior in the event of an error is based on a safety concept. This concerns z.
  • B. the monitoring and response (28) when errors occur in software components and interfaces.
  • an interface class is used for this purpose, on the basis of which a distinction is made between state regulations, operational or information security-relevant, functional or comfort requirements. Further requirements relate to the quality of interface (Qol), which the software component still allows to be valid.
  • Qol quality of interface
  • Another quality measure could be the stability of the interface that supplies the temperature value.
  • a corresponding “set of rules” of priorities, update rates, etc. is established for each interface (29) used by the software component.
  • the set of rules implies a compatible selection logic that the system's message broker must implement on the basis of the manifest (20). If the corresponding set of rules is missing, the selection logic is implemented in the software component and is not necessarily transparent for the message broker.
  • the software component indicates the permitted latency - possibly in the form of a time window - and the required update rate for each interface it uses.
  • specific information of the corresponding manifest (20) is stored in a registry.
  • all information of the manifest i.e. a complete image of the same, can also be stored here. On this one
  • a mixed form of software and hardware can be implemented, for example, in a control device (30), as the schematic illustration in FIG. 3 illustrates.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Verfahren zum Verwalten einer Softwarekomponente für ein vorgegebenes System, gekennzeichnet durch folgende Merkmale: - zumindest eine Einbindung der Softwarekomponente in das System und Ausführung der Softwarekomponente auf dem System werden durch eine gemeinsame Datei (20) beschrieben (11) und - die Einbindung und Ausführung werden durch das System anhand der Datei (20) vollzogen (12).

Description

Beschreibung
Titel
Verfahren und Vorrichtung zum Verwalten einer Softwarekomponente für ein vorgegebenes System
Die vorliegende Erfindung betrifft ein Verfahren zum Verwalten einer Softwarekomponente für ein vorgegebenes System. 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“ ( overthe 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.
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.
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 Verwalten einer Softwarekomponente für ein vorgegebenes System, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
Dieser Ansatz strebt eine Beschreibung und Definition der Art und Weise an, wie Software- Komponenten in ihre Software-Umgebung eingebunden sind und sich
- z. B. im Hinblick auf Start, Stopp, Ressourcen und Fehlerfall - zeitlich zu verhalten haben. Diese Informationen beziehen sich gleichermaßen auf statische, dynamische und funktionale Beziehungen und Elemente. Das Manifest einer Software- Komponente entspricht dabei dem „Regelwerk“ einer serviceorientierten Systemarchitektur.
Ein Manifest ist somit eine Datei, die alle statischen, dynamischen und funktionalen Informationen zur Einbindung und Ausführung einer Software- Komponente in einer bestimmten Software-Umgebung enthält. Es beschreibt dabei die Software- Komponente über ihren gesamten Lebenszyklus hinweg: Entwicklung, Prüfung, Speicherung, Verteilung ( deployment ), Installation, Initialisierung, Ausführung ( execution ), Beendigung und Deinstallation. Im Vergleich zur Verwendung statischer Konfigurationsdateien, welche lediglich für eine Phase verwendet werden, bietet diese Dynamik den Vorteil erhöhter Flexibilität. 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, auch Abhängigkeiten der Softwarekomponente im Manifest zu beschreiben, anhand derer das Zielsystem sodann für die Ausführung eingerichtet wird. Eine entsprechende Ausführungsform ermöglich die Berücksichtigung von Beziehungen, Service-Orientierung, eine Steuerung von Interpretationen des Inhaltes sowie die Einbindung der Software- Komponente in veränderliche Softwareumgebungen.
Kurze Beschreibung der Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
Figur 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
Figur 2 eine beispielhafte Manifest-Datei.
Figur 3 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform. Ausführungsformen der Erfindung
Figur 1 illustriert die grundlegenden Schritte des erfindungsgemäßen Verfahrens, welches nunmehr anhand des Beispiels gemäß Figur 2 im Einzelnen erläutert sei. Das dort dargestellte Feature- Manifest (20) ist eine konkrete Ausprägung eines SPM, enthält Metadaten der betreffenden Softwarekomponente bzw. des entsprechenden Features und kann abbildungsgemäß in XML wiedergegeben oder aus einer Datenbank abgerufen werden. Weitere Kennzeichen und Merkmale eines SPM umfassen die Marke, unter der die Software- Komponente vertrieben wird, die rechtliche Einheit, der die Software- Komponente gehört sowie eine ID zur Identifizierung einer Organisationseinheit innerhalb der erfindungsgemäßen Systemumgebung. Jede Rechtseinheit hat mindestens eine solche ID. Angegeben wird ferner eine ID zur Identifizierung eines Projekts innerhalb der erfindungsgemäßen Systemumgebung. Eine derartige Nummer kann abhängig von der Ausführungsform der Erfindung während Entwicklung, Verwaltung, Speicherung oder Bereitstellung vergeben werden. Organisations- und Projekt-ID erlauben eine eindeutige Identifizierung von Software- Komponenten aus unterschiedlichen Projekten.
Zu denken ist weiterhin an eine ID zur Identifizierung der Revision einer Software- Komponente. Ziel ist die eindeutige Identifizierung ebendieser unter Zuhilfenahme von Organisations- und Projekt-ID, sodass Kompatibilitätsprüfungen o. Ä. im Hinblick auf eine spezifische Version eines spezifischen Softwareprojekts einer spezifischen Organisationseinheit ausgeführt werden können.
Die Datei (20) umfasst ferner einen Kurznamen der Software- Komponente für Installationshinweise, Benutzerschnittstellen- Elemente o. Ä., eine verbale Beschreibung der Software- Komponente z. B. als Hilfestellung für den Endanwender sowie den Typ der Komponente. Unterschieden werden könnten beispielsweise eigenständige Anwendungen (Apps), Hilfsanwendungen, Datenbanken, Ertragskarten- oder Schlagkarten sowie allgemeine Software- Komponenten mit Infrastrukturcharakter wie Integrationsbibliotheken. Auch Veröffentlichungsdatum, Autoren sowie ein Vermerk, ob die Installation der Software- Komponente automatisch oder manuell erfolgt, kommen in Betracht.
Neben diesen Verwaltungsdaten (21) beschreiben weitere Daten im Manifest (20) das Ausführungs- und anderweitige zeitliche und funktionale Verhalten der Software- Komponente, etwa Abhängigkeiten (22) der Merkmale bzw. der Software- Komponente in verschiedenen Dimensionen. Eine solche „statische“ Abhängigkeit (23) zu anderen Software- Komponenten könnte zum Beispiel darin bestehen, dass ein Feature l:m Ausgangssignale von l:n anderen Features benötigt. Die Ausdrücke „l:m“ bzw. „l:n“ bezeichnen hierbei das Ergebnis einer Funktion als Input für die Funktion des nachfolgenden Features im Sinne einer signalflussorientierten Wirkkette. Berücksichtigung finden ferner zwingende Abhängigkeiten zu anderen Softwarekomponenten, deren Aktivierung sowie das Verhalten für den Fall, dass die Aktivierung einer anderen Software- Komponente fehlschlägt. Zudem wird die Reihenfolge bestimmt, etwa das Stoppen der einen Software- Komponente, wenn die andere Software- Komponente auch gestoppt wurde. Daneben kann angegeben werden, dass eine andere Software- Komponente nicht zwingend benötigt wird.
Erfasst wird auch die seitens des Systems benötigte Software- und Hardware- Infrastruktur, z. B. Docker, ein bestimmter Betriebssystemkern mit bestimmten Modulen, Bibliotheken, angeschlossene Hardware wie Sensoren und Aktuatoren, Systemfähigkeiten wie eine Echtzeituhr, CAN-Weckfunktion, Dauerspannungsversorgung, GPU etc. Zudem kann vermerkt werden, ob ein Speicherbereich benötigt wird, um ausgehende Daten in die Cloud zu streamen; ein entsprechender Bereich für Eingangsdaten {landing zone) wird in jedem Fall erzeugt.
Denkbar sind auch Abhängigkeiten von Features, Untermerkmalen, Libraries oder APIs. Diese Abhängigkeiten beziehen sich nicht notwendigerweise auf die gesamte Software- Komponente im Sinne einer Blackbox, sondern auf spezifische Anteile dieser Komponente wie bestimmte APIs (z. B. „SetSectionValve“) oder bestimmten Leistungsmerkmale einer Software- Komponente wie die Überwachung eines Sensorsignals, Überprüfung der funktionalen Sicherheit oder korrekte Ansteuerung eines Aktuators. Diese Informationen werden insbesondere bei der Erstellung der Container herangezogen, um eine entsprechende Laufzeitumgebung der Softwarekomponente zur Verfügung zu stellen.
Weitere Abhängigkeiten (22) betreffen die benötigten Ressourcen (24) wie RAM, Flash, CPU-Laufzeitbedarf - ggfs, unter Berücksichtigung von Echtzeitzielen -, Netzwerkbandbreite oder Ports sowie Eigenschaften der Container wie Name, Version, Typ oder Pfad des Initialisierungsskripts.
Im Gegensatz zu den statischen Charakteristika werden die dynamischen Abhängigkeiten entsprechend folgender Aufzählung unterschieden. Enthält das Manifest (20) hinsichtlich dieser Charakteristika keine Angaben, so wird angenommen, dass diese nicht relevant für die Software- Komponente sind. So lässt sich beispielsweise der Start (25) der Software- Komponente über die Eintragungen im Manifest (20) steuern. Das Ziel dieses Vorgehens ist nicht etwa, spezifische Startkommandos bereitzustellen, sondern zu ermöglichen, dass alle zur Laufzeit notwendigen Abhängigkeiten vor dem Start der Software- Komponente bereits verfügbar sind und auf Kompatibilität geprüft werden können. Hierzu werden die Daten aus dem Manifest (20) aggregiert und in eine Bootsequenz transformiert. Diese baumartige Struktur wird dann zum koordinierten Start des Systems herangezogen. Vorgesehen ist auch ein spezifisches Kommando, um die Software- Komponente im Container - ggfs, mit dynamischen Argumenten o. Ä. - zu starten sowie die grundlegende Information, ob ein automatischer Start der Software- Komponente gewünscht ist.
Weitere Startabhängigkeiten können vielfältiger Natur sein: Die vorliegende Software- Komponente darf beispielsweise nur gestartet werden, wenn die im Manifest (20) aufgeführten Software- Komponenten bereits gestartet sind, oder alle Software- Komponenten, die dort aufgeführt sind, dürfen nur gestartet werden, wenn die vorliegende Software- Komponente bereits gestartet ist.
Ebenso lassen sich Software- Komponenten angeben, die für eine Ausführung der im Manifest (20) beschriebenen Komponente unerlässlich sind und daher vor dieser Komponente gestartet werden müssen. Diese Angabe wird darüber hinaus für die Festlegung der Boot- und Shutdown-Sequenz genutzt.
Eine weitere Angabe erlaubt die Berücksichtigung des folgenden Szenarios: Wurde die erforderliche Software- Komponente nicht gestartet, dann werden sowohl die vorliegende als auch weitere im Manifest (20) beschriebene Komponenten nicht gestartet. Hierbei gibt es keine abhängige Reihenfolge für Boot oder Shutdown. Eine in diesem Sinne „schwächere“ Angabe signalisiert, dass es keinen Einfluss hat, wenn die Software- Komponente nicht gestartet werden konnte. Eine derartige Angabe ist somit gleichsam als „Empfehlung zum Starten“ zu verstehen, etwa im Falle einer Anwendung, die Services für Filterfunktionen oder eine optionale Funktion bereitstellt, welche die Komponente nicht zur Erfüllung ihrer kritischen Funktion benötigt. Auch der folgende Fall lässt sich im Manifest (20) abbilden: Wurde die Software- Komponente gestoppt, dann wird auch eine andere Software- Komponente gestoppt. Eine weitere Angabe gestattet es, dass, sofern innerhalb einer definierten Gruppierung oder Verkettung einzelne Komponenten gestartet oder gestoppt werden, eine Reihe anderer Software- Komponenten ebenfalls gestartet bzw. gestoppt wird. Umgekehrt kann angegeben werden, mit welchen anderen Softwarekomponenten eine zeitgleiche Ausführung nicht möglich oder gewollt ist. Dies stellt das System fest und unterbindet die jeweilige Ausführung bzw. initiiert eine Auswahl beispielsweise durch eine Nutzerinteraktion.
In entsprechender Weise lässt sich das Verhalten der Softwarekomponente bei ihrer Beendigung (26) beeinflussen. Hierzu ist die Startreihenfolge umzukehren. Für das geordnete Herunterfahren des Systems wird die Boot-Sequenz daher invertiert und somit der baumartige Ablauf in rückwärtiger Richtung ausgeführt. Ein Ziel dieser Konvention ist die Reduktion von Komplexität für den Entwickler, weshalb derzeit keine separaten Eintragungen vorgesehen sind. Sollte ein Bedarf entstehen, so können selbstverständlich für den Shutdown-Vorgang spezifische Daten eingearbeitet werden.
Zur Fehlererkennung (27) kann beschrieben sein, welche Umstände dazu führen, dass ein Fehlerfall erkannt wird. Ein entsprechendes Modul überwacht die Software- Komponenten anhand ihrer Manifeste (20) in dieser Hinsicht und erteilt dem System ggf. den Befehl zum Stoppen der Komponente. Das Verhalten im Fehlerfall richtet sich nach einem Sicherheitskonzept. Dies betrifft z. B. die Überwachung und Reaktion (28) beim Auftreten von Fehlern bei Software- Komponenten und Schnittstellen. Hierzu dient insbesondere eine Interface- Klasse, anhand derer zwischen staatlichen Regularien, betriebs- oder informationssicherheitsrelevanten, funktionalen oder Komfortanforderungen unterschieden wird. Weitere Anforderungen betreffen die Dienstgüte ( quality of interface, Qol), welche die Softwarekomponente noch als gültig zulässt. In Betracht kommt ferner eine semantische Güte der erforderlichen Sensordaten, etwa die Genauigkeit einer Temperaturangabe. Ein weiteres Gütemaß könnte die Stabilität der Schnittstelle darstellen, die den Temperaturwert liefert. Mittels weiterer Angaben im Manifest (20) wird zu jeder von der Softwarekomponente verwendeten Schnittstellen (29) ein entsprechendes „Regelwerk“ an Prioritäten, Aktualisierungsraten, etc. festgelegt. In diesem Fall impliziert das Regelwerk eine kompatible Auswahllogik, die der Nachrichtenbroker des Systems anhand des Manifests (20) implementieren muss. Fehlt das entsprechende Regelwerk, so ist die Auswahllogik in der Softwarekomponente implementiert und nicht notwendigerweise transparent für den Nachrichtenbroker.
Des Weiteren gibt die Softwarekomponente zu jeder von ihr verwendeten Schnittstelle die zugelassene Latenz - ggf. in Form eines Zeitfensters - und geforderte Aktualisierungsrate an. Beim Installationsprozess der Software- Komponenten werden dezidierte Informationen des entsprechenden Manifests (20) in einer Registry abgespeichert. Je nach verfügbaren Speicherressourcen können an dieser Stelle auch sämtliche Informationen des Manifests, also ein vollständiges Abbild desselben, abgelegt werden. Auf diesem
Wege liegen für die Ausführung wichtige Informationen unmittelbar den betroffenen Systemkomponenten vor. Beispiele für solche unabdingbaren Informationen, die auch nach der Initialisierung benötigt werden, sind Abhängigkeiten (22), Fehlerreaktion (28) und benötigte Ressourcen (24). Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer
Mischform aus Software und Hardware beispielsweise in einem Steuergerät (30) implementiert sein, wie die schematische Darstellung der Figur 3 verdeutlicht.

Claims

Ansprüche
1. Verfahren zum Verwalten einer Softwarekomponente für ein vorgegebenes System, gekennzeichnet durch folgende Merkmale:
- zumindest eine Einbindung der Softwarekomponente in das System und Ausführung der Softwarekomponente auf dem System werden durch eine gemeinsame Datei (20) beschrieben (11) und
- die Einbindung und Ausführung werden durch das System anhand der Datei (20) vollzogen (12).
2. Verfahren nach Anspruch 1, gekennzeichnet durch folgende Merkmale:
- die Datei (20) enthält die Softwarekomponente betreffende Verwaltungsdaten (21) und
- das Verwalten der Softwarekomponente auf dem System erfolgt anhand der Verwaltungsdaten (21).
3. Verfahren nach Anspruch 1 oder 2, gekennzeichnet durch folgende Merkmale:
- die Datei (20) beschreibt Abhängigkeiten (22) der Softwarekomponente und
- das System wird anhand der beschriebenen Abhängigkeiten (22) für die Ausführung eingerichtet, gegebenenfalls unter Zuhilfenahme weiterer Dateien (20).
4. Verfahren nach Anspruch 3, gekennzeichnet durch mindestens eines der folgenden Merkmale:
- die Abhängigkeiten (22) umfassen statische Abhängigkeiten (23) und
- die Abhängigkeiten (22) umfassen Abhängigkeiten von Betriebsmitteln (24) des Systems.
5. Verfahren nach einem der Ansprüche 1 bis 4, gekennzeichnet durch folgende Merkmale:
- die Datei (20) beschreibt ein Verhalten der Softwarekomponente bei der Ausführung (25) und Beendigung (26) und
- die Ausführung (25) und Beendigung (26) werden durch das System anhand des beschriebenen Verhaltens koordiniert.
6. Verfahren nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgende Merkmale:
- die Datei (20) beschreibt eine Erkennung (27) etwaiger Laufzeitfehler der Softwarekomponente und
- die Datei (20) beschreibt eine durch das System einzuleitende Reaktion (28) auf die Laufzeitfehler.
7. Verfahren nach einem der Ansprüche 1 bis 6, gekennzeichnet durch folgende Merkmale:
- die Datei (20) beschreibt von der Softwarekomponente verwendete Schnittstellen (29) und
- während der Ausführung (12) vermittelt das System über die Schnittstellen (29) ausgetauschte Nachrichten.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass vor der Laufzeit bzw. Ausführung sich ausschließende Zugriffe und/oder Ausführungen aus einer Mehrzahl von Dateien (20) identifiziert und Konflikte gegebenenfalls aufgelöst werden.
9. Computerprogramm, welches eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 8 auszuführen.
10. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 9 gespeichert ist.
11. Vorrichtung (30), die eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 8 auszuführen.
PCT/EP2020/079069 2019-11-06 2020-10-15 Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system WO2021089295A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019217057.9 2019-11-06
DE102019217057.9A DE102019217057A1 (de) 2019-11-06 2019-11-06 Verfahren und Vorrichtung zum Verwalten einer Softwarekomponente für ein vorgegebenes System

Publications (1)

Publication Number Publication Date
WO2021089295A1 true WO2021089295A1 (de) 2021-05-14

Family

ID=72944138

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/079069 WO2021089295A1 (de) 2019-11-06 2020-10-15 Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system

Country Status (2)

Country Link
DE (1) DE102019217057A1 (de)
WO (1) WO2021089295A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10467025B2 (en) * 2016-01-15 2019-11-05 Google Llc Managing delivery of code and dependent data using application containers

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7440980B2 (en) * 2001-04-03 2008-10-21 Qnx Software Systems Gmbh & Co. Kg Computer file management system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10467025B2 (en) * 2016-01-15 2019-11-05 Google Llc Managing delivery of code and dependent data using application containers

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "ClickOnce Deployment Manifest", 4 November 2016 (2016-11-04), XP055765201, Retrieved from the Internet <URL:https://docs.microsoft.com/en-us/visualstudio/deployment/clickonce-deployment-manifest?view=vs-2019> [retrieved on 20210114] *
ANONYMOUS: "Deploying with Application Manifests", 21 September 2018 (2018-09-21), XP055765197, Retrieved from the Internet <URL:https://web.archive.org/web/20180921034814/https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#multi-apps> [retrieved on 20210114] *

Also Published As

Publication number Publication date
DE102019217057A1 (de) 2021-05-06

Similar Documents

Publication Publication Date Title
DE102005014273B4 (de) Vergleich von Schnittstellen zwischen Softwarekomponenten
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
EP2620871A2 (de) Verfahren zur Konfiguration eines BIOS in einem Computersystem sowie Computerprogrammprodukt
DE112021005674T5 (de) Verfahren und system für eine zugriffssteuerung in einer versionsgesteuerten konfiguration eines datenverarbeitungs-clusters
DE102014210854A1 (de) Computerimplementiertes Verfahren und Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme sowie Rechneranlage und ein Computerprogramm mit Programmcode zur Durchführung des Verfahrens
EP3977668B1 (de) System zur erzeugung von kryptografischem material
DE112017003052T5 (de) Steuerungssystem mit einer verteilten dienstorientierten Architektur
DE102018206762A1 (de) Feature-Development-Framework und Feature-Integration-Framework zum Implementieren physikalischer Funktionsfeatures in einem Zielgerät
WO2021089310A1 (de) Verfahren und vorrichtung zum verwalten von zugriffen mehrerer softwarekomponenten auf softwareschnittstellen
WO2021089295A1 (de) Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
WO2021089296A1 (de) System zum austausch von nachrichten durch eine anwendungssoftware
DE102008048862A1 (de) Testmodul und Verfahren zum Testen einer O/R-Abbildungs-Middleware
DE102008022132A1 (de) Verfahren zum Konfigurieren einer Testeinrichtung, Testverfahren und Testeinrichtung
WO2021089308A1 (de) System zum steuern einer maschine
DE102019217044A1 (de) System zum Steuern einer Maschine
DE102019217058A1 (de) Verfahren und Vorrichtung zum Bereitstellen einer Anwendungssoftware
DE102021202133A1 (de) Verfahren, Vorrichtung und Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Steuergerät
WO2014173505A1 (de) Verfahren zur gewährleistung der funktionsfähigkeit eines technischen systems im hinblick auf dessen konfiguration im rahmen einer installation bzw. beseitigung von komponenten
WO2022117306A1 (de) Verfahren zum bereitstellen von programmdaten aus einer datenbank
DE102022203325A1 (de) Verfahren zur Überprüfung der Ausführbarkeit einer Softwareanwendung
EP2927811B1 (de) Verfahren zur Steuerung eines automatisierten Ablaufs
DE102022112550A1 (de) Verfahren zum Anpassen einer Funktionalität einer Softwareapplikation an eine für die Ausführung der Funktionalität verfügbare Hardwareausstattung eines Kraftfahrzeugs sowie computerlesbares Speichermedium und Computersystem
DE102022204016A1 (de) Verfahren zum Erzeugen eines Softwaregerüsts
WO2022184781A1 (de) Verfahren zum betreiben einer recheneinheit

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20793325

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20793325

Country of ref document: EP

Kind code of ref document: A1