-
Die Erfindung betrifft ein Verfahren zum Erstellen eines Konfigurationsdatensatzes für ein Kraftfahrzeug mittels einer elektronischen Recheneinrichtung gemäß dem geltenden Patentanspruch 1. Ferner betrifft die Erfindung eine elektronische Recheneinrichtung.
-
Aus dem Produktionsmanagement sind bereits Systeme bekannt, bei welchen logische Bedingungen implementiert werden können, die beispielsweise Sonderausstattungscodes kombinieren und zu Booleschen Ausdrücken führen. Dies wird verwendet, um Software auf beispielsweise Steuergeräten derart zu parametrisieren, damit diese auf die entsprechende Produktvariante bezogen auf Faktoren wie Hardware-Voraussetzungen, Marktvorgaben, Kundenpräferenzen oder dergleichen korrekt eingehen können. Das zentrale Element dieser Steuerung sind die entsprechenden Sonderausstattungscodes. Sonderausstattungscodes repräsentieren Ausstattungsmerkmale und Kundenfunktionssicht. Die logischen Bedingungen werden zu einer Regel durch eine Verknüpfung mit einem Konfigurationselement. Hier werden zum Beispiel definiert, welche Variantenkonfigurationsdaten basieren auf dem Kontext des gegebenen Fahrzeugs beziehungsweise dessen Ausstattung gesetzt werden müssen. Beispielsweise kann die E-Call-Funktion genannt werden, welche über eine Telefonnummernkonfiguration verfügen muss, und diese Telefonnummer ist wiederum von Land zu Land unterschiedlich.
-
Die
WO 2015 165 486 A1 betrifft ein Verfahren zur rechnergestützten Analyse eines Modells zur Beschreibung mehrerer Varianten eines technischen Systems, wobei durch das Modell digital basierend auf einer Spezifikation Komponenten des technischen Systems variabel definiert werden. Es wird das Modell in einem Term einer Prädikatenlogik gewandelt und dieser Term wird mittels eines SMT-Solvers verarbeitet, der die in dem Modell enthaltenen Varianten zumindest zum Teil ermittelt und ausgibt.
-
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren sowie eine elektronische Recheneinrichtung zu schaffen, mittels welchem generisch eine Erstellung eines Konfigurationsdatensatzes realisiert werden kann.
-
Diese Aufgabe wird durch ein Verfahren sowie durch eine elektronische Recheneinrichtung gemäß den unabhängigen Patentansprüchen gelöst. Vorteilhafte Ausgestaltungsformen sind in den Unteransprüchen angegeben.
-
Ein Aspekt der Erfindung betrifft ein Verfahren zum Erstellen eines Konfigurationsdatensatzes für ein Kraftfahrzeug mittels einer elektronischen Recheneinrichtung. Es erfolgt das Bereitstellen einer Vielzahl von Umgebungsparametern für den Konfigurationsdatensatz mittels der elektronischen Recheneinrichtung. Es werden die Umgebungsparameter mittels Boolescher Ausdrücke zu einem Konfigurationsparameter verknüpft. Es wird der Konfigurationsparameter mit einem Konfigurationswert zu zumindest einem ersten Konfigurationsregelwerk verknüpft. Es erfolgt das Erzeugen des Konfigurationsdatensatzes in Abhängigkeit von zumindest dem ersten Konfigurationsregelwerk.
-
Insbesondere ist somit eine elektronische Recheneinrichtung beziehungsweise ein System beschrieben, das den größtmöglichen Nutzen aus modernen Software-Engineering-Methoden zieht, um ein System zur Verwaltung logischer Bedingungen für jede Art von Anwendungsfall zu schaffen. Diese logischen Bedingungen können erstellt, kombiniert, neu geordnet, umstrukturiert und gelöscht werden. Die Bedingungen können dabei zum einen innerhalb von Entscheidungen, zum anderen innerhalb von Regeln oder anderen Systemen eingesetzt werden.
-
Im ersten Fall können die Ausgabedaten der Entscheidungen mit Semantik belegt werden. Die Semantik der Eingabedaten sind jedoch in beiden Fällen völlig außerhalb des Anwendungsbereichs dieser erfindungsgemäßen Gedanken, um eine möglichst generische Lösung für jede Art von Anwendungsfall zu bieten. Dies ist notwendig, um die sehr große Produktvarianz von komplexen Endprodukten mit vielfältigen Hardware-Varianten in Einklang zu bringen mit den ebenso vielfältigen Software- und Funktionsvarianten, die sowohl in den Systemen der Produktionsinstanzen als auch in den entsprechenden Backend-Systemen dieser vernetzten Produkte vorherrschen. Ebenso können dabei anwender- beziehungsweise kundenspezifische Einstellungspräferenzen mit berücksichtigt werden, um ein möglichst individuelles Kundenerlebnis zu ermöglichen. Insbesondere ist dies im Bereich der Automobilindustrie anwendbar - auf diesen Anwendungsfall werden sich die weiteren Beispiele beziehen. Das vorgestellte Konzept ist jedoch auf andere Industrie- und Produktionskategorien anwendbar, die auf vernetzte, komplexe Systeme, insbesondere so genannte loT (Internet of Things)-Systeme aufbauen.
-
Insbesondere ist es somit vorgesehen, dass die Umgebungsparameter, welche auch als Environments bezeichnet werden, die entsprechenden Zustände der Umgebung beschreiben, die zutreffen können oder nicht. Ein einfaches Environment sind beispielsweise die Sonderausstattungscodes. Die Sonderausstattungscodes, wie die gemäß dem Stand der Technik der genutzt werden, sind eine Art von den Umgebungsparametern. Zu beachten ist dabei, dass die Menge gültiger Sonderausstattungscodes von Baureihe zu Baureihe unterschiedlich sein können, somit sind die Sonderausstattungscodes Umgebungsparameter nochmals pro Baureihe gruppiert. Durch das Konzept der Umgebungsparameter ist es möglich, weitere Domänen und Mengen von Eingabeparametern in die Lösung einzubinden, die unabhängig von den Sonderausstattungscodes sind. Dies ist ein wesentlicher Bestandteil für die Erreichung eines generischen Konzepts, der in unterschiedlichen Anwendungsbereichen angewendet werden kann.
-
Des Weiteren können Bedingungen in weiteren Bedingungen referenziert und damit logisch verknüpft werden. Damit werden Abstraktions- und Wiederverwendungsmöglichkeiten geschaffen, die einen wesentlichen Vorteil gegenüber dem Stand der Technik darstellen.
-
Um die Wiederverwendung von existierenden, sich aber unter Umständen weiterentwickelnden Bedingungen strukturiert verwalten zu können, werden die Bedingungen jeweils mit einer Zustandsmaschine und einem Versionsverwaltungssystem ausgestattet.
-
Diese Bedingungssprache umfasst insbesondere Boolesche Ausdrücke, die die Umgebungsparameter miteinander verknüpfen. Wird eine Bedingung, insbesondere ein Boolescher Ausdruck in der Bedingungssprache, mit einem Konfigurationswert in Bezug gesetzt, so spricht man von einem einfachen Konfigurationsregelwerk. Von einem vollständigen Konfigurationsdatensatz spricht man, wenn alternative Konfigurationswerte zueinander in Bezug gesetzt werden, so dass einzelne Bedingungen in so genannten Entscheidungen referenziert werden. Eine Entscheidung wird von mindestens zwei Bedingungen definiert, welcher konkreter Konfigurationswert gesetzt werden muss, wenn die jeweiligen zugeordneten Bedingungen wahr werden. Die Entscheidung kann dabei praktisch unendlich viele weitere Bedingungen referenzieren. Somit kann eine Kaskade von Bedingungen erstellt werden, die in der Reihenfolge ihres Vorkommens innerhalb der Entscheidung nach und nach ausgewertet werden. Sobald die erste Bedingung wahr wird, bricht die Ausführung der Kaskade ab. Sind alle Bedingungen mit falsch ausgewertet, so gibt es immer einen Standardwert im „Andernfalls“-Zweig, der dann als Konfigurationswert zurückgegeben wird. Auch die Entscheidungen sind wie die Bedingungen jeweils mit einer Zustandsmaschine und einem Versionsverwaltungssystem ausgestattet.
-
Der große Vorteil dieser Entscheidungen liegt darin, dass die Autoren bei der Erstellung dieser Regeln analog der sequentiellen Logik in einer Programmiersprache denken und die Regeln erstellen können. Zudem kann zur Laufzeit unter Umständen Rechenzeit gespart werden, wenn die Regelauswertung früh abbricht. Dann muss nicht die gesamte Regel als solche ausgewertet werden.
-
Die Kombination eines Ausdrucks der Bedingungssprache plus eines oder mehrerer Konfigurationswerte wird als Konfigurationsregel bezeichnet. Dies wird überall dort verwendet, wo Software-Installationen konkrete Parametrisierungswerte benötigen, um ihren bestimmungsgemäßen Zweck zu erfüllen. Sie können jedoch auch beispielsweise zur Konkretisierung von Abhängigkeiten zwischen zwei Software-Modulen oder zwischen Software- und Hardware-Modulen eingesetzt werden. Ein weiterer Anwendungsbereich ist die Konkretisierung der Auswahl von Software-Artefakten innerhalb eines Software-Releasepakets, um von so genannten 150 Prozent-Paketen, die für eine Menge von Zielsystemen Alternativen enthalten, zu so genannten 100 Prozent-Paketen zu kommen, die zielsystemindividuell die genau passenden Software-Module beinhalten.
-
Die Gesamtmenge aller Konfigurationsregelwerke, Konfigurationswerte, Bedingungen, Entscheidungen wird in einem Autorensystem verwaltet. Nach einem erfolgreich ausgeführten Freigabeprozess stehen die davon betroffenen Artefakte dieses Autorensystems in einem Ausführungssystem zur Verfügung. Sobald die Environments innerhalb eines Kontextes eines Zielsystems wie einem Kraftfahrzeug aktiviert wurden, können diese auf die vorliegend freigegebenen Konfigurationsregeln angewendet und somit die konkreten Konfigurationen für dieses Kraftfahrzeug ermittelt werden.
-
Somit ermöglicht dieses Konzept, dass sowohl für Konfigurationsanwendungen gemäß dem Stand der Technik als auch neuer Anwendungsfälle für Konfigurationen gleichermaßen von einer gemeinsamen Datenbasis von Bedingungen profitieren, die Wiederverwendungs- und Abstraktionsmechanismen ermöglichen. Ferner ist ein so genanntes „Single Point of Truth“-Prinzip umsetzbar, das geschäftsrelevantes Fachwissen in Logikbedingungen abbildet und auf vielfältige Weise abfragbar macht.
-
Gemäß einer vorteilhaften Ausgestaltungsform wird bei dem Umgebungsparameter eine Baureihe des Kraftfahrzeugs berücksichtigt.
-
Ebenfalls vorteilhaft ist, wenn in Abhängigkeit von einem ausgewählten ersten Umgebungsparameter ein zweiter Umgebungsparameter bereitgestellt wird.
-
Ein weiterer Aspekt der Erfindung betrifft eine elektronische Recheneinrichtung zum Erstellen eines Konfigurationsdatensatzes für ein Kraftfahrzeug, wobei die elektronische Recheneinrichtung zum Durchführen eines Verfahrens nach dem vorhergehenden Aspekt ausgebildet ist. Insbesondere wird das Verfahren mittels der elektronischen Recheneinrichtung durchgeführt.
-
Vorteilhafte Ausgestaltungsformen des Verfahrens sind als vorteilhafte Ausgestaltungsformen der elektronischen Recheneinrichtung anzusehen. Die elektronische Recheneinrichtung weist dazu gegenständliche Merkmale auf, wie beispielsweise Prozessoren, oder integrierte Schaltkreise, um ein Verfahren gemäß dem vorhergehenden Aspekt durchzuführen.
-
Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungsbeispiele sowie anhand der Zeichnungen. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung genannten und/oder in den Figuren alleine gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
-
Dabei zeigen:
- 1 ein schematisches Blockdiagramm gemäß einer Ausführungsform des Verfahrens; und
- 2 ein weiteres schematisches Blockdiagramm gemäß einer weiteren Ausführungsform des Verfahrens.
-
In den Figuren sind gleiche oder funktionsgleiche Elemente mit den gleichen Bezugszeichen versehen.
-
1 zeigt ein schematisches Blockdiagramm gemäß einer Ausführungsform des Verfahrens. Insbesondere ist beispielsweise eine elektronische Recheneinrichtung 10 rein schematisch dargestellt. Die elektronische Recheneinrichtung 10 ist zum Erstellen eines Konfigurationsdatensatzes 12 für beispielsweise ein nicht dargestelltes Kraftfahrzeug ausgebildet. Hierzu werden eine Vielzahl von Umgebungsparametern 14, so genannte Environments, bereitgestellt. Es erfolgt dann das Verknüpfen der Umgebungsparameter 14 mittels Boolescher Ausdrücke zu einem Konfigurationsparameter 16. Es erfolgt dann das Verknüpfen des Konfigurationsparameters 16 mit einem Konfigurationswert 18 zu zumindest dem ersten Konfigurationsregelwerk. Es erfolgt dann das Erzeugen des Konfigurationsdatensatzes 12 in Abhängigkeit von zumindest dem ersten Konfigurationsregelwerk.
-
Die 1 zeigt ferner eine Autorenumgebung 20 sowie einen Bedingungsspeicher 22. Ferner ist innerhalb eines Applikationskontextes 24 eine Erzeugungsumgebung 26 sowie ein Applikationsartefakt 28 gezeigt. Die Umgebungsparameter 14 sowie die Konfigurationsparameter 16 befinden sich folgend insbesondere in einem Variantenraum 30.
-
Weiterhin zeigt die 1 eine Laufzeitumgebung 32, bei welchen Attribute 34 des speziellen Kraftfahrzeugs an einen Konfigurationsarbeiter 36 übergeben werden. Ferner wird der Konfigurationsdatensatz 12 ebenfalls an den Konfigurationsarbeiter 36 übergeben.
-
Ferner ist ein System 38 gezeigt, welches insbesondere kraftfahrzeugintern ausgebildet ist. Hierbei können individuelle Konfigurationen für die entsprechende Applikation innerhalb des Kraftfahrzeugs bereitgestellt werden, was durch den Block 40 dargestellt ist. Ferner ist im Block 42 die Applikationsinstanz in der entsprechenden Version dargestellt.
-
Insbesondere ist somit eine generische Darstellung des Konzepts dargestellt. Mit der Applikation 28 wird in dem Block 26 die Software für die Applikation 28 entwickelt und daraus das Artefakt in eine Version gebaut. Dieses Artefakt wird in das System 38 als Zielinstanz installiert und dort ausgeführt. Dort wird die Instanz in der Version zur Ausführung gebracht. Damit nun die für das Zielsystem die instanzpassende Konfiguration erstellt und dorthin gesendet werden kann, sind weitere folgende Funktionsschritte notwendig.
-
In der Autorenumgebung 20 werden alle notwendigen Elemente zusammengebracht, die zur Bestimmung des Konfigurationsdatensatzes 12 später in der Laufzeitumgebung 32 sind. Im Variantenraum 30 der Applikation 28 in der Version beispielsweise V1 sind sowohl alle möglichen Konfigurationswerte 18 als auch alle möglichen Umgebungsparameter 14 hinterlegt. Nun wird eine Menge von Konfigurationsregeln definiert, die den Inhalt der Konfiguration der Applikation 28 in der entsprechenden Version bestimmen. Dabei können Bedingungen aus der Datenbank dem Bedingungsspeicher 22 verwendet werden, die jedoch für den aktuellen Variantenraum 30 gültig sein müssen. Dabei ist vor allem darauf zu achten, dass die Umgebungsparameter 14 kompatibel sind. Hierfür wird das Konzept des Bedingungstyps eingeführt.
-
Sobald nun die Menge von Konfigurationsregeln, also der Konfigurationsdatensatz 12, für die Applikation 28 in der entsprechenden Version vollständig und korrekt ist, können diese für die Laufzeitumgebung 32 freigegeben werden. In der Laufzeitumgebung 32 wird der Konfigurationsarbeiter 36 angefragt, um die Konfigurationsdatensätze 12 für das System 38 und die Applikationsinstanz in der entsprechenden Version auf Basis der aktuellen Umgebungsparameter 30 und der Menge von dem Konfigurationsdatensatz 12 zu generieren. Diese Konfiguration kann schließlich dann in dem System 38 zur Konfiguration der Applikationsinstanz angewendet werden.
-
Insbesondere zeigt somit die 1 einen Gesamtüberblick für den Anwendungsfall Steuergeräte-Software als Applikation in einer speziellen Version. Hier ist insbesondere der generische Mechanismus für die Variantencodierung in diesem Beispiel insofern anwendbar, dass lediglich die Bedingungen von einem Typ beispielsweise für Sonderausstattungscodes zugelassen sind.
-
Damit ist es möglich, dass sich dieses Konzept nahtlos in bestehende Systeme integrieren lässt, welche dem Stand der Technik entsprechen. Diese nutzen als Ausgangspunkt den Variantenraum 30, die Diagnosebedatung aus beispielsweise ODX, und liefern an einem Endpunkt, insbesondere dem System 38, Variantencodierservice-Aufrufe, die dem UDS-Protokoll entsprechen.
-
Als Beispiel für die Autorenumgebung 20 kann die Steuergeräte-Software genannt werden, beziehungsweise dafür bereits im Stand der Technik bekannte Diagnosesystemwelt, mit entsprechender Variantencodierung. Der Variantenraum 30 für die Steuergeräte-Software in einer entsprechenden Version enthält die kompletten möglichen Konfigurationswerte 18 der Steuergeräte-Variante des Steuergeräts. Diese Datei ist ein Extrakt aus der gesamten Diagnosebedatung aus der entsprechenden Datei für das Steuergerät, ebenfalls in der entsprechenden Version. Diese Datei muss zur vorliegenden Version für die Steuergeräte-Software passen. Im unteren Bereich wird das Konzept des Bedingungstyps (Condition Type) eingeführt. In der einfachsten Ausbaustufe und aus Kompatibilitätsgründen zum Stand der Technik beschränkt sich der Bedingungstyp eins ausschließlich auf die Verwendung von Sonderausstattungscodes als Umgebungsparameter 16. Dabei ist es wichtig zu beachten, dass sich die zulässigen Sonderausstattungscodes unter Umständen zwischen den verschiedenen Baureihen unterscheiden können. Somit muss eine korrekte Zuordnung von Sonderausstattungscodes, dessen Bedatung und der entsprechenden Baureihe gewährleistet sein. Damit sind alle möglichen Umgebungsparameter 14 für den Variantenraum 30 von dem Steuergerät definiert, und der Bedingungstyp ist auf Typ eins festgelegt. Damit ist es auch nur möglich, in der Menge der Konfigurationsregeln den Bedingungstyp eins zu nutzen. Ebenso ist die Menge der möglichen verwendeten Bedingungen auf diejenigen vom Bedingungstyp eins eingeschränkt.
-
Die Liste der Bedingungstypen kann beliebig lang sein - in diesem Beispiel sind die Bedingungstypen zwei und drei jeweils eine Erweiterung des Bedingungstyps eins, um Bedingungen, die sich zusätzlich auf technische Merkmale beziehen beziehungsweise auf technische Merkmale und andere Attribute beziehen. Somit ist es möglich, dass sich Bedingungen vom Typ zwei auf Bedingungen vom Typ eins beziehen, umgekehrt ist dies nicht möglich. Des Weiteren ist es möglich, dass sich Bedingungen vom Typ drei auf Bedingungen vom Typ eins oder zwei beziehen. Die jeweilige umgekehrte Verwendung ist nicht möglich. Somit ist es beispielsweise möglich, dass eine Bedingung vom Typ eins „Nordamerika“: „USA“ oder „Kanada“ beinhaltet und vollständig aus Sonderausstattungscodeelementen besteht, während eine weitere Bedingung vom Typ zwei wie folgt aussieht: „Variante 1 eine Wasserpumpe“: „Nordamerika“ und „Stromaufnahme = 2 Ampere“. Wobei in diesem Beispiel der Wert „Stromaufnahme = 2 Ampere“ ein technisches Merkmal eines Bauteils, wie in diesem Fall eine Wasserpumpe, sein kann, der zum Auswertezeitpunkt logisch war oder falsch liefern muss.
-
Somit ist es möglich, das Konzept der Umgebungsparameter 14 so weiter auszubauen, dass jegliche Attribute, die logisch auswertbar sind, als Eingabegröße in diesem Konzept anwendbar sind. Die einzige Bedingung ist, dass diese zum Auswertezeitpunkt der Bedingung auch auswertbar sind, das heißt die Laufzeitumgebung muss zu jeder Zeit eine eindeutige Antwort auf die Auswertung dieser Bedingung erzeugen können.
-
2 zeigt ein weiteres schematisches Blockdiagramm gemäß einer Ausführungsform des Verfahrens. Insbesondere ist in 2 die Beschreibung eines Konfigurationsdatensatzes 12 bestehend aus einer Bedingung gezeigt. Der Bedingungsspeicher 22 weist insbesondere eine erste Bedingung 44 sowie eine zweite Bedingung 46 auf. Beispielsweise kann die erste Bedingung 44 in einer ersten Version 50 sowie in einer zweiten Version 48 bereitstehen. Die zweite Bedingung 46 kann in einer ersten Version 56, in einer zweiten Version 54 sowie in einer dritten Version 52 vorhanden sein. Ferner weist auch der Konfigurationsdatensatz 12 eine Bedingung 58 auf.
-
Insbesondere ist somit ein detaillierter Einblick in einen beispielhaften Konfigurationsdatensatz 12 gezeigt, der sich auf den Variantenraum 30 beispielsweise in der Version 1 bezieht. Im Detail bezieht sich dies auf einen bestimmten Datensatz der ODX-Bedatung und einer bestimmten Steuergeräte-Variante. Dieser Konfigurationsdatensatz 12 ist mit einer eindeutigen Referenz auf einen bestimmten Konfigurationswert 18 verknüpft. In diesem Beispiel ist der Konfigurationswert 18, dass Meaning Z1 im Fragment Y des darüberliegenden Strukturelements Segment X. Auf dieser Strukturebene der Segmente befinden sich auch die Abstraktionsebene der ODX-Dienste. Dieses Beispiel zeigt, dass der Konfigurationsdatensatz 12 die Bedatung 2 in der Version 2.1.0 liefert, was vorliegend insbesondere durch den Block 52 dargestellt ist. Diese Bedingung ist mit drei Blöcken übereinander dargestellt, welche exemplarisch drei aufeinander folgende Versionsstände dieser Bedingung repräsentieren sollen. Beispielsweise hat die Bedingung 2 in der Version 2.1.0, insbesondere wie durch den Block 52 dargestellt, den Inhalt „ECE“ oder „USA“ und „AMG:V2.0.0“. Dies bedeutet, wenn der Sonderausstattungscode ECE oder USA gesetzt ist und zusätzliche Bedingung AMG in der Version 2.0.0 wahr ist, dann wird diese Bedingung 2 auch wahr. Dieses Beispiel beinhaltet eine Wiederverwendung einer weiteren Bedingung mit dem Titel AMG, und zwar genau in der Version 2.0.0, was vorliegend durch den Block 48 dargestellt ist. In früheren Versionen der Bedingung wurde die AMG-Bedingung in der Version 1.0.0 referenziert, was vorliegend durch den Block 50 dargestellt ist. Die frühere Version der Bedingung 2 ist auch weiterhin gültig, jedoch hat sich die AMG-Bedingung weiterentwickelt, und darauf bezieht sich auch die Version 2.1.0 der Bedingung 2, also der Block 52. Somit ist sichergestellt, dass jeder eingefrorene und freigegebene Stand der Autorenumgebung zu jeder Zeit stabil unverändert bleibt. Dies ist insbesondere wichtig, um parallel laufende Entwicklungen für unterschiedliche Generationen von Applikationen und deren Verwendung in unterschiedlichen Baureihen ohne Querabhängigkeit realisieren zu können.
-
Die Referenzen auf Konfigurationswerte 18 sind agnostisch gegenüber der Domäne in dieser Bedingung eingesetzt. Diese Art von Konfigurationsregel wird auch als kurze Konfigurationsregel bezeichnet.
-
Alternativ kann auch anstelle der Bedingung gemäß dem Block 58 auch eine Entscheidung gefällt werden. Beispielsweise kann hier die Entscheidung gegenüber der einfachen Bedingung in dem Block 58 darlegen, dass, wenn die Bedingung 2 nicht wahr wird, auf jeden Fall eine eindeutige Referenz auf einen Konfigurationswert 18 zurückgeliefert wird. In diesem Beispiel ist dieser Konfigurationswert 18 das Meaning Z2 im Strukturelementfragment Y des darüberliegenden Strukturelements Segment X. Die Referenzen auf Konfigurationswerte 18 sind agnostisch gegenüber der Domäne, in der diese Entscheidung eingesetzt wird.
-
Bezugszeichenliste
-
- 10
- elektronische Recheneinrichtung
- 12
- Konfigurationsdatensatz
- 14
- Umgebungsparameter
- 16
- Konfigurationsparameter
- 18
- Konfigurationswert
- 20
- Autorenumgebung
- 22
- Bedingungsspeicher
- 24
- Applikationskontext
- 26
- Erzeugungsumgebung
- 28
- Applikation
- 30
- Variantenraum
- 32
- Laufzeitumgebung
- 34
- Attribut
- 36
- Konfigurationsarbeiter
- 38
- System
- 40
- individuelle Konfiguration
- 42
- Applikationsinstanz
- 44
- erste Bedingung
- 46
- zweite Bedingung
- 48
- Block
- 50
- Block
- 52
- Block
- 54
- Block
- 56
- Block
- 58
- Block
-
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
-
