-
Die Erfindung betrifft ein Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek.
-
In der Präsentation https://www.oica.net/wp-content/uploads/The-future-UN-Regulationson-Cybersecurity-and-SW-updates-PSA-Group-Kai-Frederik-ZASTROW.pdf (abgerufen am 27.07.2021) wird beschrieben, wie ein Beurteilungsprozess durchgeführt werden kann, um zu entscheiden, ob und inwieweit ein geplantes Softwareupdate bestehende Zertifizierungsumfänge in Fahrzeugen betrifft.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein neuartiges Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek anzugeben.
-
Die Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek mit den Merkmalen des Anspruchs 1.
-
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
-
In einem Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek werden erfindungsgemäß einem Fahrzeugtypbibliothek-Autorensystem mittels künstlicher Intelligenz Lösungsvorschläge zum Aufbau und/oder zur Weiterentwicklung der Fahrzeugtypbibliothek unterbreitet. Die künstliche Intelligenz wird dabei insbesondere aus bestehenden Datenquellen gespeist. Das Fahrzeugtypbibliothek-Autorensystem wird insbesondere von Domänenexperten geführt, welche die Fahrzeugtypbibliothek in einem Autorenprozess erstellen und pflegen.
-
Das Fahrzeugtypbibliothek-Autorensystem weist insbesondere eine Ontologie auf, welche ein Domänenwissen in strukturierter Form semantisch korrekt abbildet. Insbesondere erfolgt in einem Fahrzeugtypbibliothek-Freigabeprozess eine Verifizierungsanfrage bezüglich einer neuen Version der Fahrzeugtypbibliothek an einen Produktvariantensetverifikationsservice, wobei dem Produktvariantensetverifikationsservice Produktvariantensetverifikationsregeln bereitgestellt und von diesem angewendet werden, wobei ein positives Verifikationsergebnis an das Fahrzeugtypbibliothek Autorensystem übermittelt und die neue Version der Fahrzeugtypbibliothek für ein Fahrzeugtypbibliothek Laufzeitsystem freigegeben wird.
-
Die Erfindung ermöglicht es, dass aufgrund der heutigen Dokumentationssilos in den Domänen Hardware und Software und der unzureichenden expliziten Dokumentation von Softwarefunktionen, insbesondere auch aufgrund fehlenden Zugriffs auf den Sourcecode, es trotzdem sukzessive möglich wird, diese Dokumentationsbasis mit vertretbarem menschlichem Pflegeaufwand teilautomatisiert zu erreichen. Damit wird die Kernforderung von SUMS-Regularien (SUMS=Software Update Management System) erreicht und somit auch eine bessere Ausgangsbasis für weitere Analysen und Qualitätssicherungsmaßnahmen geschaffen, die zur Beschleunigung der Entwicklungszeiten bei gleichzeitiger Qualitätssteigerung führen.
-
Die UN-R 156 (SUP - Software update process) Regularie schreibt Automobilherstellern vor, das bereits erwähnte sogenannte Software Update Management System (SUMS) aufzubauen und einzuführen, um Softwareupdates (Over-The-Air und in Werkstätten) ihrer Fahrzeugflotten im Feld planbarer und transparenter zu machen. Dafür ist es notwendig, ein Datenmodell für das Gesamtsystem „vernetztes Fahrzeug“ zu haben, um daraus die Abhängigkeiten und Auswirkungen auf die Ausgangsprodukte bei Änderungen an den Eingangsdaten transparent machen zu können. Diese Erfindung setzt genau hier an und beschreibt, wie solch ein Datenmodell iterativ, inkrementell, ganzheitlich und kollaborativ erstellt und gepflegt werden kann.
-
Wesentliche Merkmale dieser Lösung sind insbesondere:
- • Generisches Datenmodell: Objektorientierung wird als Basismethodik zur Strukturierung aller Inhalte eingeführt.
- • Die objektorientierte Methodik wird durch Anleihen aus einem merkmalbasierten Variantenmanagement erweitert, um eine Produktvarianz bedingt durch die Mass Customization Strategie, d. h. durch eine kundenindividuelle Massenproduktion, auch als individualisierte Massenfertigung bezeichnet, abzubilden.
- • Ganzheitlicher Ansatz: Software- und Hardwarekomponenten werden im Rahmen eines Systems Engineering Ansatzes gleichberechtigt behandelt.
- • Integration von Anforderungsebene und Architekturebene über Umsetzungsebene bis hin zu konkreten einzelnen Produkten in ein ganzheitliches Datenmodell.
- • Ganzheitliche Dokumentation sowohl von Informationen bezüglich eines Zusammenbaus von Systemkomponenten auf der einen Seite und bezüglich funktionaler Zusammenhänge auf der anderen Seite.
- • Die Fahrzeugtypbibliothek an sich ist ebenfalls ein Entwicklungsergebnis der beschriebenen Lösung und wird genauso wie Funktionssoftware behandelt, insbesondere bezüglich Implementierung, Qualitätssicherung, Versionierung und Freigabe.
- • Einsatz von Kl-Methoden, d. h. von Methoden künstlicher Intelligenz, um von einer Bestandsdokumentationswelt mit etlichen Silos evolutionär zu einer schnellen und effizienten Befüllung der Fahrzeugtypbibliothek zu gelangen.
- • Konkrete, automatisierte Erstellung und Aktualisierung der konkreten vollständigen Typkonfigurationen, inklusive der Abbildung auf konkrete Fahrzeuginstanzen.
- • Generischer Ansatz, um Constraints, d. h. Grenzen, von Produktlinien mit Hilfe partieller Typkonfigurationen abzubilden. Dadurch sind Fahrzeugbaureihen als Produktlinien ebenso modellierbar wie auch andere Teilsysteme, die im Sinne eines Modulbaukastens für andere Fahrzeug- oder Kooperationsprojekte eingesetzt werden können - wie z.B. Motoren, Antriebsstränge, Telematikplattformen etc.
-
Bei der hier beschriebenen Lösung ist somit insbesondere das erwähnte Software Update Management System (SUMS) vorgesehen, um Over-the-Air Updates von Fahrzeugflotten im Feld zu erreichen. Dafür ist es notwendig, ein Datenmodell für das Gesamtsystem „vernetztes Fahrzeug“ zu generieren. Die Lösung beschreibt insbesondere, wie solch ein Datenmodell, insbesondere basierend auf einer Verknüpfung von bekannten Modellen, erstellt und umgesetzt werden kann.
-
Alternativ zum hier beschriebenen unmittelbaren Anwendungsfall für Fahrzeuge kann die erfindungsgemäße Lösung auch auf jegliche andere komplexe und variantenreiche cyberphysikalische Systeme angewendet werden, zum Beispiel Flugzeuge, Anlagen, Maschinen, Landmaschinen, Baufahrzeuge, Schiffe, Schienenfahrzeuge, Lastkraftwagen, Busse usw.
-
Ausführungsbeispiele der Erfindung werden im Folgenden anhand von Zeichnungen näher erläutert.
-
Dabei zeigen:
- 1 schematisch eine Übersicht eines typbasierten Product Line Engineering,
- 2 schematisch ein UML-Klassendiagramm,
- 3 schematisch einen exemplarischen Ausschnitt aus einer Fahrzeugtypbibliothek,
- 4 schematisch einen exemplarischen Ausschnitt aus einer Artefaktbibliothek,
- 5 schematisch eine Übersicht eines Fahrzeugtypbibliothek-Autorensystems,
- 6 schematisch eine Übersicht eines Fahrzeugtypbibliothek-Freigabeprozesses, und
- 7 schematisch eine Übersicht eines Software-Konfiguration-Autorensystems.
-
Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
-
Anhand der 1 bis 7 wird im Folgenden ein Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek 12 beschrieben. Zusammengefasst werden dabei, wie insbesondere in den 5 und 6 dargestellt und im Folgenden noch detailliert beschrieben wird, einem Fahrzeugtypbibliothek-Autorensystem 25 mittels künstlicher Intelligenz KI Lösungsvorschläge zum Aufbau und/oder zur Weiterentwicklung der Fahrzeugtypbibliothek 12 unterbreitet. Die künstliche Intelligenz KI wird dabei insbesondere aus bestehenden Datenquellen D1 bis D5 gespeist. Das Fahrzeugtypbibliothek-Autorensystem 25 wird insbesondere von Domänenexperten 26 geführt, welche die Fahrzeugtypbibliothek 12 in einem Autorenprozess erstellen und pflegen.
-
Das Fahrzeugtypbibliothek-Autorensystem 25 weist insbesondere eine Ontologie 27 auf, welche ein Domänenwissen in strukturierter Form semantisch korrekt abbildet.
-
Insbesondere erfolgt in einem Fahrzeugtypbibliothek-Freigabeprozess eine Verifizierungsanfrage bezüglich einer neuen Version der Fahrzeugtypbibliothek 12n an einen Produktvariantensetverifikationsservice 31, wobei dem Produktvariantensetverifikationsservice 31 Produktvariantensetverifikationsregeln 34 bereitgestellt und von diesem angewendet werden, wobei ein positives Verifikationsergebnis an das Fahrzeugtypbibliothek-Autorensystem 25 übermittelt und die neue Version der Fahrzeugtypbibliothek 12n für ein Fahrzeugtypbibliothek-Laufzeitsystem 32 freigegeben wird.
-
Die UN-R 156 (SUP - Software update process) Regularie, (https://www.oica.net/wpcontent/uploads/The-future-UN-Regulations-on-Cybersecurity-and-SW-updates-PSA-Group-Kai-Frederik-ZASTROW.pdf (abgerufen am 27.07.2021)) schreibt Automobilherstellern vor, ein sogenanntes Software Update Management System (SUMS) aufzubauen und einzuführen, um Softwareupdates ihrer Fahrzeugflotten im Feld, d. h. der bereits ausgelieferten Fahrzeuge, planbarer und transparenter zu gestalten. Diese Softwareupdates können dabei sowohl Over-The-Air, d. h. drahtlos, als auch in Werkstätten erfolgen. Dafür ist es notwendig, ein Datenmodell für das Gesamtsystem „vernetztes Fahrzeug“ zu haben, um daraus die Abhängigkeiten und Auswirkungen auf Ausgangsprodukte bei Änderungen an Eingangsdaten transparent machen zu können.
-
Die im Folgenden näher beschriebene Lösung setzt genau hier an und beschreibt, wie solch ein Datenmodell iterativ, inkrementell, ganzheitlich und kollaborativ erstellt und gepflegt werden kann.
-
Wesentliche Merkmale dieser Lösung sind:
- • Generisches Datenmodell: Objektorientierung wird als Basismethodik zur Strukturierung aller Inhalte eingeführt.
- • Die objektorientierte Methodik wird durch Anleihen aus einem merkmalbasierten Variantenmanagement erweitert, um eine Produktvarianz bedingt durch die Mass Customization Strategie, d. h. durch eine kundenindividuelle Massenproduktion, auch als individualisierte Massenfertigung bezeichnet, abzubilden.
- • Ganzheitlicher Ansatz: Software- und Hardwarekomponenten werden im Rahmen eines Systems Engineering Ansatzes gleichberechtigt behandelt.
- • Integration von Anforderungsebene und Architekturebene über Umsetzungsebene bis hin zu konkreten einzelnen Produkten 5 in ein ganzheitliches Datenmodell.
- • Ganzheitliche Dokumentation sowohl von Informationen bezüglich eines Zusammenbaus von Systemkomponenten auf der einen Seite und bezüglich funktionaler Zusammenhänge auf der anderen Seite.
- • Die Fahrzeugtypbibliothek 12 an sich ist ebenfalls ein Entwicklungsergebnis der beschriebenen Lösung und wird genauso wie Funktionssoftware behandelt, insbesondere bezüglich Implementierung, Qualitätssicherung, Versionierung und Freigabe.
- • Einsatz von KI-Methoden, d.h. von Methoden künstlicher Intelligenz KI, um von einer Bestandsdokumentationswelt mit etlichen Silos evolutionär zu einer schnellen und effizienten Befüllung der Fahrzeugtypbibliothek 12 zu gelangen.
- • Konkrete, automatisierte Erstellung und Aktualisierung der konkreten vollständigen Typkonfigurationen, inklusive der Abbildung auf konkrete Fahrzeuginstanzen.
- • Generischer Ansatz, um Constraints, d. h. Grenzen, von Produktlinien 4 mit Hilfe partieller Typkonfigurationen abzubilden. Dadurch sind Fahrzeugbaureihen als Produktlinien 4 ebenso modellierbar wie auch andere Teilsysteme, die im Sinne eines Modulbaukastens für andere Fahrzeug- oder Kooperationsprojekte eingesetzt werden können - wie z.B. Motoren, Antriebsstränge, Telematikplattformen etc.
-
Auf Seite 10 der oben bereits genannten Präsentation https://www.oica.net/wpcontent/uploads/The-future-UN-Regulations-on-Cybersecurity-and-SW-updates-PSA-Group-Kai-Frederik-ZASTROW.pdf (abgerufen am 27.07.2021) ist eine Abbildung dargestellt, die zeigt, wie aus Behördensicht ein Beurteilungsprozess durchgeführt werden muss, um zu entscheiden, ob und inwieweit ein geplantes Softwareupdate bestehende Zertifizierungsumfänge betrifft. Für jede Nummer „x“ der Zertifizierungssysteme muss eine SWIN (Software Identification Number) dokumentiert werden, welche genau einen definierten Zustand des Produktes 5 referenziert, der den Behörden bekannt und somit zertifiziert ist. Im weiteren Verlauf wird diese Identification Number auch als RxSWIN bezeichnet. Die größte Herausforderung dabei ist, wie jedes neue Softwareupdate einschließlich Konfigurationsregeln auf seine Relevanz für beispielsweise über 150 spezifische Zertifizierungssysteme bewertet werden kann, ohne dass es Dokumentationssysteme gibt, die diese Abhängigkeitsinformationen explizit enthalten.
-
1 zeigt schematisch eine Übersicht eines typbasierten Product Line Engineering, d. h. einer Produktlinienentwicklung. Dabei zeigt 1, dass die Typbibliothek die Datenbasis oder Struktur für das gesammelte Wissen darstellt. Alle Architekturumfänge werden darin dokumentiert. Die Architekturumfänge sind generisch, beinhalten aber schon alle Architekturvarianten. Damit können einerseits die Informationen in einer Sammlung aller Artefakte 16, also Anforderungen, Spezifikationen, Modelle, Dokumentationen und zusätzliche Informationen von Hardware, Software und Systemen, direkt mit Architekturdefinitionen, also Funktionen, Eigenschaften usw., verknüpft werden. Zusätzlich ist die Typbibliothek der Ausgangspunkt zum Bilden von Typkonfigurationen. Das Product Line Engineering umfasst ein Typmanagement 1 und ein Artefaktmanagement 2 sowie eine Plattform 3, d. h. eine Fahrzeugplattform, Produktlinien 4, d. h. Fahrzeugproduktlinien, und Produkte 5, d. h. Fahrzeuge. Es sind des Weiteren eine Architekturgestaltung 6 und ein Entwurf 7 dargestellt.
-
In der Architekturgestaltung 6 werden beispielweise eine Managementarchitektur 8, eine EE-Architektur 9 (EE=Elektrik/Elektronik), eine Vernetzungsarchitektur 10 und eine Softwarearchitektur 11 berücksichtigt. Diese Informationen fließen in die Typbibliothek 12 ein, die eine Mehrzahl aller möglichen Produkttypen T1 bis T6 aufweist. Im Artefaktmanagement 2 ist hier eine Sammlung aller Artefakte 16 vorgesehen. Dies ist eine Sammlung aller verfügbaren Informationen. Im Entwurf 7 erfolgt dann für die Produktlinien 4 eine partielle Typkonfiguration 23, beispielsweise Produkttyp T3 und Produkttyp T4. Im Bereich Produkte 5 fließen Produkte 5, Prototypen 13 und digitale Modelle 14 in die Fahrzeugtypbibliothek 12 ein und es erfolgt eine vollständige Typkonfiguration 24, beispielsweise eine Auswahl von Produkttyp T3 und Produkttyp T4, für ein jeweiliges Fahrzeug. Im Artefaktmanagement 2 werden hier mittels eines Artefaktinstanzgenerators 15 Artefaktinstanzen 17 generiert.
-
2 stellt ein UML-Klassendiagramm (UML=Unified Modeling Language) dar, welches als Metamodell die Grundlage für die Fahrzeugtypbibliothek 12 darstellt. Zentrales Element ist eine Type-Metaklasse 18, welche sowohl als Zertifizierungstyp die behördlich vorgegebenen Systeme repräsentiert, als auch in der Variante als Produkttyp das Kernelement der Systembeschreibung darstellt. Innerhalb des Typs kann der Zusammenbau von Systemen in Form von referenzierten anderen Typen erfolgen. Die Type-Metaklasse 18 bietet alle Möglichkeiten der objektorientierten Beschreibungswelt, insbesondere Kapselung, Vererbung, Polymorphie. Ein System ist ein Systemelemente enthaltender Typ. Diese Systemelemente sind ebenfalls Typen, auf der untersten Aggregationsebene.
-
Das zweite wesentliche Element der Fahrzeugtypbibliothek 12 ist eine Function-Metaklasse 19, welche das Kernelement zur Beschreibung von Funktionen darstellt. Die Verkettung von Funktionen führt zu Wirkketten, d. h. zu einer Möglichkeit der Abbildung der funktionalen Zusammenhänge. Eine Wirkkette ist eine Funktion, die Funktionselemente enthält. Diese Funktionselemente sind ebenfalls Funktionen, auf einer niedrigeren Aggregationsebene. Um die Funktionen passend miteinander verketten zu können, werden deren Schnittstellen, d. h. Inputs und Outputs, durch die Interface-Metaklasse 20 dargestellt. Mit der Property-Metaklasse 21 werden die Eigenschaften des jeweiligen Typs beschrieben. Mithilfe der Option-Metaklasse 22 kann der Umfang des Typs anhand von Optionen um zusätzliche Funktionen, Eigenschaften und Bestandteile erweitert werden.
-
Die Mächtigkeit dieses Datenmodells besteht darin, die jeweiligen, aus diesen Metaklassen abgeleiteten Klassen und deren Beziehungen miteinander so aufzubauen, dass sie die tatsächlichen funktionalen Zusammenhänge der kompletten Software und Hardware von vernetzten Fahrzeugen eines Fahrzeugherstellers in allen Baureihen und allen Dimensionen, beispielsweise Onboard, Cloud, Hardware, Software, Configurationen, Software Base Layer, Software Application Layer, Software Features, Software Personalisation, hinreichend vollständig beschreiben.
-
Damit ist die Ausgangslage geschaffen, die jeweiligen konkreten Artefakte und deren Ausprägungen mit dieser Fahrzeugtypbibliothek 12 in Bezug zu bringen.
-
Dies ist wiederum Voraussetzung, um in der 1 rechts oben die vollständigen Typkonfigurationen 24 erstellen und pflegen zu können, inklusive der darin vergebenen RxSWINs.
-
Die vollständigen Typkonfigurationen 24 sind die Voraussetzung für die Dokumentation der Produktinstanzen rechts unten in 1, d. h. der Artefaktinstanzen 17, um somit die vollständigen Anforderungen der SUMS-Regularien erfüllen zu können.
-
Beispielsweise hat die UN-R89 Regularie „SpeedLimitationDevices“ einen Bezug auf die HeadUnit Variantencodierung „Vehicle Functions / TireSpeedLimit“. Wird die Regel der oben genannten Variantencodierung geändert, so hat dies Auswirkung auf die RxSWIN für x = 89 für die von der Änderung betroffenen Fahrzeuge, wie in 3 dargestellt. Dabei zeigt diese 3 einen exemplarischen Ausschnitt aus der Fahrzeugtypbibliothek 12 mit dem Produkttyp „TypeSpeedLimitationSystem“, der das Zertifizierungssystem bzw. den Zertifizierungstyp Nr. 89 „TypeCertificationSpeedLimitationDevices“ implementiert. Diese 3 zeigt exemplarisch einen kleinen Ausschnitt aus dem Bereich Fahrzeugtypbibliothek 12 links oben in 1.
-
4 zeigt einen exemplarischen Ausschnitt aus der Artefaktbibliothek für eine HeadUnit NTG5.5 und deren Variantencodierung im Segment Vehicle Functions, Fragment TireSpeedLimit. Damit zeigt diese 4 exemplarisch einen kleinen Ausschnitt aus dem Bereich Sammlung aller Artefakte 16 links unten in 1. Die Herausforderung besteht nun darin, dass sowohl die Fahrzeugtypbibliothek 12 als auch die Verknüpfung der einzelnen Artefaktelemente zu den passenden Typbibliothekelementen hinreichend vollständig aufgebaut und dauerhaft konsistent gepflegt werden muss.
-
5 zeigt eine Übersicht eines Fahrzeugtypbibliothek-Autorensystems 25, welches mit Hilfe von KI-Technologie, d. h. mittels künstlicher Intelligenz KI, aus bestehenden Datenquellen D1 bis D5 gespeist wird. Die künstliche Intelligenz KI macht dem Fahrzeugtypbibliothek-Autorensystem 25 entsprechende Vorschläge. Das Fahrzeugtypbibliothek-Autorensystem 25 wird von Domänenexperten 26 geführt. Es weist die Fahrzeugtypbibliothek 12 mit Ontologie 27, Vokabular 28, Regeln 29 und Abhängigkeiten 30 auf.
-
Eine Datenquelle D1 bilden beispielsweise schriftliche Aufzeichnungen von Aussagen und Interviews von Experten. Eine Datenquelle D2 bilden beispielsweise Anforderungen von Engineeringsystemen, d. h. von Entwicklungssystemen. Eine Datenquelle D3 bilden beispielsweise Produktdatenmanagementsysteme (PDM). Eine Datenquelle D4 bilden beispielsweise Sourcecode Repository Systems, d. h. Quellcodeablagesysteme. Eine Datenquelle D5 bilden beispielsweise Testdokumentationssysteme.
-
Diese 5 beschreibt, wie die fehlende Dokumentationsbasis von Hardware- und Softwarefunktionen und deren Wirkketten aufgebaut werden kann. Dieses Fahrzeugtypbibliothek-Autorensystem 25 folgt dem Grundprinzip des iterativen, agilen Vorgehensmodells. Dabei wird die Fahrzeugtypbibliothek 12 als solche auch als ein Artefakt betrachtet, welches Versionsstände aufweist und einem Freigabeprozess unterliegt. Somit ist es möglich, dass beispielsweise nach einem MVP-Ansatz (MVP=minimum viable product) eine erste Version der Fahrzeugtypbibliothek 12 veröffentlicht wird, welche im Gesamtverbund des typbasierten Product Line Engineering bereits integriert und getestet werden kann. Währenddessen können Verfeinerungen und Aktualisierungen parallel dazu in einer Arbeitsversion der Fahrzeugtypbibliothek 12 erstellt werden, welche dann als zweite Version wieder in den Gesamtverbund integriert werden können. Wichtig dabei ist, dass keine Widersprüchlichkeiten unaufgelöst verbleiben. Es ist darauf zu achten, dass neuere Versionen keine semantischen Brüche zu vorherigen Versionen aufweisen. Somit ist eine gewisse semantische Integrität über den Lebenszyklus der Fahrzeugtypbibliothek 12 hinweg oberste Prämisse.
-
Vorteilhafterweise sollten folgende Prämissen bei der Umsetzung dieses Konzeptes eingehalten werden:
- - Die konkretesten und stabilsten Datenquellen D1 bis D5 werden zuerst berücksichtigt. Das sind Testdokumentationen, beispielsweise Testfallbeschreibungen und Testergebnisse, sowie Quellcode, soweit vorhanden, Diagnosedaten (ODX incl. aller Metadaten), Produktdokumentationssystem-Artefakte, beispielsweise Variantencodierungen incl. aller Metadaten, und Software-Artefakte, beispielsweise Flashware, inklusive aller Metadaten.
- - Jegliche Dokumente, die zur Beschreibung der Anforderungen an die Systeme vorliegen, beispielsweise Anforderungsspezifikationen, mitgeltende Unterlagen, Architekturspezifikationen, werden berücksichtigt.
- - Zusammenhänge, insbesondere Erfahrungswerte und nicht triviale Abhängigkeiten, die nicht in Dokumenten beschrieben sind, müssen von den jeweiligen Experten hinterfragt und in Textform gebracht werden. Dies ist der weitaus am unklarsten vorliegende Bestandteil der Datenquellen D1 bis D5, hat aber mitunter den wesentlichen, signifikanten Mehrwert an Erkenntnisgewinn und stellt somit eine sehr wertvolle Grundlage zur Erstellung der Fahrzeugtypbibliothek 12 dar.
-
All diese Informationsquellen werden mit der jeweiligen passenden KI-Methodik und Technologie so weiterverarbeitet, dass die daraus resultierende „Recommendation“, d. h. der Lösungsvorschlag der künstlichen Intelligenz KI, ein sinnvoll nutzbares Ergebnis liefert, damit die Domänenexperten 26 schließlich im Autorenprozess zur Erstellung und Pflege der Fahrzeugtypbibliothek 12 optimal unterstützt werden.
-
Das Kernelement dieser gemeinsam zwischen Mensch und Maschine zu erarbeitenden Wissensbasis ist die Ontologie 27, welche das Domänenwissen in strukturierter Form semantisch korrekt abbildet. Diese Ontologie 27 wird bereits zur Umsetzung der Variantencodierungsregeln auf Basis technischer Merkmale zur Kopplung der Software- und Hardwaredokumentationswelten benötigt. Dabei ist darauf zu achten, dass die jeweiligen zu Grunde liegenden Sprachen berücksichtigt und sauber voneinander getrennt interpretiert werden. In möglichen Implementierungen dieses Konzeptes arbeitet das Gesamtsystem ausschließlich mit einer Sprache, beispielsweise Englisch, und Eingangsdaten werden zuvor in einem Übersetzungsprozess in diese Sprache übersetzt, bevor sie weiterverarbeitet werden.
-
6 zeigt eine Übersicht eines Fahrzeugtypbibliothek-Freigabeprozesses. Diese 6 beschreibt, wie der Fahrzeugtypbibliothek-Freigabeprozess gestaltet werden kann. Dabei kommt ein Product Variant Sets Verification Service, d. h. ein Produktvariantensetverifikationsservice 31, zum Einsatz, der im Grunde die Generalisierung der heutigen Baubarkeitsprüfungsservices darstellt. Diese basieren heute auf Baubarkeitsregeln, so genannten POFFs, welche in diversen Services und Systemen zum Einsatz kommen. Diese auf der LogicNG Technologie basierenden Services werden soweit ausgebaut, dass sie auch Konsistenzprüfungen für Software- bzw. Systemartefakte durchführen können. Beim Freigabeprozess für eine neue Version der Fahrzeugtypbibliothek 12n werden nun die neuen Daten gegen diese Regeln abgeprüft. Sollte die Prüfung erfolgreich durchlaufen werden, so wird die neue Version vom Fahrzeugtypbibliothek-Autorensystem 25 an ein Fahrzeugtypbibliothek-Laufzeitsystem 32 übergeben. Damit ist diese neue Version auch für weitere Services einsetzbar.
-
In dem Fahrzeugtypbibliothek-Freigabeprozess erfolgt somit zunächst eine Verifizierungsanfrage bezüglich einer neuen Version der Fahrzeugtypbibliothek 12n, d. h. bezüglich eines Freigabekandidaten 33 für eine neue Version eines Datenmodells der Fahrzeugtypbibliothek 12, an den Produktvariantensetverifikationsservice 31. Dem Produktvariantensetverifikationsservice 31 werden Produktvariantensetverifikationsregeln 34 bereitgestellt und von diesem angewendet. Wenn das Verifikationsergebnis in Ordnung ist, wird dies an das Fahrzeugtypbibliothek-Autorensystem 25 übermittelt und die neue Version der Fahrzeugtypbibliothek 12n wird freigegeben für das Fahrzeugtypbibliothek-Laufzeitsystem 32.
-
7 zeigt eine Übersicht eines Software-Konfiguration-Autorensystems 35. Hier wird das Software-Konfiguration-Autorensystem 35 von Domänenexperten 26 bedient. Die künstliche Intelligenz KI, auch als KI-Maschine bezeichnet, macht hier dem Software-Konfiguration-Autorensystem 35 entsprechende Vorschläge. Sie greift hier zusätzlich auf die Fahrzeugtypbibliothek 12 als weitere Datenquelle D6 zu.
-
Datenquellen D1 bis D6 bilden hier somit beispielsweise schriftliche Aufzeichnungen von Aussagen und Interviews von Experten, Anforderungen von Engineeringsystemen, d. h. von Entwicklungssystemen, Produktdatenmanagementsysteme (PDM), Sourcecode Repository Systems, d. h. Quellcodeablagesysteme, Testdokumentationssysteme sowie die Fahrzeugtypbibliothek 12.
-
7 beschreibt, wie aufgrund der freigegebenen Fahrzeugtypbibliothek 12, welche auch die Ontologie 27 enthält, die Kl-Maschine, d. h. die künstliche Intelligenz KI, dafür eingesetzt werden kann, dass das Software-Konfiguration-Autorensystem 35, eine Ausprägung zur Erstellung und Pflege der Artefakte, beispielhaft in 4 dargestellt, den Domänenexperten 26 bei der Autorenaufgabe optimal unterstützen kann. Im konkreten Fall, hier wie in 4 dargestellt, handelt es sich um die Regeln für die Erstellung der Variantencodierung von Steuergeräten. Die Recommendation-Engine kann dabei die passende Typklasse und deren Optionen aus der Fahrzeugtypbibliothek 12 vorschlagen, zu der das aktuell bearbeitete Segment oder Fragment funktional korrelieren könnte. Durch wiederkehrende Verlinkungen und inkrementellen Erweiterungen werden diese Vorschläge über die Zeit immer genauer und der Zusatzaufwand für den Domänenexperten 26 geht tendenziell gegen null.
-
Diese beschriebene Lösung ermöglicht es, dass aufgrund heutiger Dokumentationssilos in den Domänen Hardware und Software und der unzureichenden expliziten Dokumentation von Softwarefunktionen, insbesondere auch aufgrund fehlenden Zugriffs auf den Sourcecode, es trotzdem sukzessive möglich wird, diese Dokumentationsbasis mit vertretbarem menschlichem Pflegeaufwand teilautomatisiert zu erreichen. Damit wird die Kernforderung der SUMS-Regularien erreicht und somit auch eine bessere Ausgangsbasis für weitere Analysen und Qualitätssicherungsmaßnahmen geschaffen, die zur Beschleunigung der Entwicklungszeiten bei gleichzeitiger Qualitätssteigerung führen.
-
Bezugszeichenliste
-
- 1
- Typmanagement
- 2
- Artefaktmanagement
- 3
- Plattform
- 4
- Produktlinien
- 5
- Produkte
- 6
- Architekturgestaltung
- 7
- Entwurf
- 8
- Managementarchitektur
- 9
- EE-Architektur
- 10
- Vernetzungsarchitektur
- 11
- Softwarearchitektur
- 12
- Fahrzeugtypbibliothek
- 12n
- neue Version der Fahrzeugtypbibliothek
- 13
- Prototypen
- 14
- digitale Modelle
- 15
- Artefaktinstanzgenerator
- 16
- Sammlung aller Artefakte
- 17
- Artefaktinstanzen
- 18
- Type-Metaklasse
- 19
- Function-Metaklasse
- 20
- Interface-Metaklasse
- 21
- Property-Metaklasse
- 22
- Option-Metaklasse
- 23
- partielle Typkonfiguration
- 24
- vollständige Typkonfiguration
- 25
- Fahrzeugtypbibliothek-Autorensystem
- 26
- Domänenexperten
- 27
- Ontologie
- 28
- Vokabular
- 29
- Regeln
- 30
- Abhängigkeiten
- 31
- Produktvariantensetverifikationsservice
- 32
- Fahrzeugtypbibliothek-Laufzeitsystem
- 33
- Freigabekandidat
- 34
- Produktvariantensetverifikationsregeln
- 35
- Software-Konfiguration-Autorensystem
- D1 bis D6
- Datenquellen
- KI
- künstliche Intelligenz
- T1 bis T6
- Produkttyp
