-
Technisches Gebiet
-
Die Erfindung betrifft ein computerimplementiertes Verfahren zum Vornehmen ausführbarer Spezifikationen bei der Systementwicklung und/oder Systemvalidierung eines funktionalen Systems für ein Zielgerät, insbesondere für ein Kraftfahrzeug. Sie betrifft auch ein entsprechendes Software-Werkzeug sowie eine Steuerungseinheit, die dazu eingerichtet ist, das genannte Verfahren auszuführen.
-
Technischer Hintergrund
-
Modellbasierte Ansätze zur Systementwicklung (Model-Based Systems Engineering, MBSE), wie beispielsweise eine aus „Advanced Model-Based Engineering of Embedded Systems - Extensions of the SPES 2020 Methodology“, Springer, 2016, von Pohl, Klaus, Manfred Broy, Heinrich Daembkes und Harald Hönninger bekannte Modellierungsplattform, finden immer weitere Verbreitung bei der Entwicklung komplexer funktionaler Systeme, die insbesondere innovative Funktionen in automotive Anwendungen zum automatisierten Fahren oder zur Verbesserung der Energieeffizienz von Fahrzeugen implementieren. Dabei sind beispielsweise Software-Werkzeuge, die sich einer als SysML oder OMG SysML (OMG Systems Modelling Language, eingetragene Marke, Object Management Group, Inc.) bekannten grafischen Modellierungssprache bedienen, oder E/E-Architekturentwicklungswerkzeuge (E/E-Architektur steht dabei für „elektrisch-elektronische Architektur“, die insbesondere beschreibt welche elektrischen und elektronischen Komponenten es im Fahrzeug gibt sowie diese miteinander interagieren), wie beispielsweise PREEvision (eingetragene Marke), geeignet, um in frühen Phasen der Systementwicklung die logisch-funktionalen Zusammenhänge bzw. die Wirkzusammenhänge auch komplexer Systeme in Form von funktionalen oder logischen Modellansichten zu beschreiben.
-
Die existierenden bekannten Ansätze dieser Art erlauben eine strukturelle Beschreibung der Systeme in Form von Funktionalitäten und deren Abhängigkeiten. Letztere werden in der Regel in Form von Schnittstellenbeschreibungen präzisiert. Derartige strukturelle Beschreibung funktionaler Systeme wird hierin auch als statische Systembeschreibung bezeichnet. Einem Nutzer bzw. Systementwickler stehen dabei statische Modellansichten zur Verfügung, wie beispielsweise eine statische funktionale Systembeschreibung umfassend eine oder mehrere funktionale Wirkketten (Englisch: Cause-effect-chain), die Wirkzusammenhänge zwischen eine physikalische Funktionalität im Zielgerät betreffenden Wirk- und Zielparametern beschreiben, oder eine funktionale Architektur, in der funktionale Gleichteile verschiedener Wirkketten aggregiert und nach funktionaler Zugehörigkeit in einer hierarchischen Dekomposition angeordnet sind.
-
Über eine strukturelle Beschreibung hinaus wird eine Verhaltensbeschreibung eines komplexen funktionalen Systems genutzt, die sich in der Regel auf kausale Zusammenhänge, Abfolgen mit Zeitanforderungen oder die Beschreibung zustandsorientierter Systeme mittels Zustandsautomaten beschränkt. Eine Beschreibung des dynamischen Systemverhaltens zeit-kontinuierlicher Regel- oder Steuerungssysteme erfolgt bei bekannten Ansätzen entkoppelt zur strukturellen Beschreibung mittels spezialisierter Software-Simulations-Werkzeuge, wie beispielsweise MATLAB/Simulink (eingetragene Marke).
-
Eine Kopplung einer strukturellen, statischen Modellansicht und der dynamischen Verhaltensbeschreibung ist dabei dem Anwender überlassen. Einzelne existierende Lösungen sind unidirektional und weisen, wenn überhaupt, nur eine beschränkte semantische Kopplung zwischen einzelnen Modellierungselementen der unterschiedlichen Modellansichten auf. Dies liegt an dem folgenden dem Fachmann bekannten Umstand: Genauso wenig wie SysML-Werkzeuge zur dynamischen Verhaltensbeschreibung geeignet sind, unterstützen auch die Software-Werkzeuge zur dynamischen Verhaltensbeschreibung nicht alle notwendigen statischen Modellsichten. Beispielsweise können gängige zu modellierende Artefakte, wie beispielsweise ganze Anwendungsfälle (use cases), einzelne Merkmale (features) und Funktionen mit deren Schnittstellen und Varianten, Wirkketten in der statischen oder dynamischen Beschreibung oder E/E-Architektur, in frühen Phasen der Systementwicklung jeweils nicht durch alle drei der unterschiedlichen Software-Werkzeuge: erstens ein geeignetes Anforderungs-Werkzeug (requirements tooling), zweitens SysML und drittens MATLAB/Simulink, - vollständig unterstützt werden. Deshalb ist es dabei auch keine Option, alle benötigten Modelle und Ansichten mit einem einzelnen Werkzeug zu beschreiben, um etwa die Konsistenz zwischen den unterschiedlichen Modellansichten sicherzustellen.
-
Offenbarung der Erfindung
-
Erfindungsgemäß sind ein computerimplementiertes Verfahren zum Vornehmen ausführbarer Spezifikationen bei der Systementwicklung und/oder Systemvalidierung eines funktionalen Systems gemäß Anspruch 1 sowie eine zur Ausführung des Verfahrens eingerichtete Steuerungseinheit, ein entsprechendes Software-Werkzeug (Computerprogramm) und ein maschinenlesbares Speichermedium, auf dem es gespeichert ist, gemäß den nebengeordneten Ansprüchen vorgesehen. Weitere Ausführungsformen sind in den abhängigen Ansprüchen angegeben. Alle in den Ansprüchen und der Beschreibung für das Verfahren genannten weiterführenden Merkmale und Wirkungen gelten auch in Bezug auf das Software-Werkzeug und die Steuerungseinheit, wie auch umgekehrt.
-
Gemäß einem ersten Aspekt ist ein computerimplementiertes Verfahren zum softwarewerkzeuggestützten Vornehmen ausführbarer Spezifikationen bei der Systementwicklung und/oder Systemvalidierung eines im Allgemeinen beliebig komplexen funktionalen Systems, das zur Implementierung diverser Funktionalitäten der Steuerung und/oder Regelung eines Zielgeräts, insbesondere eines Kraftfahrzeugs, ausgebildet sein kann, vorgesehen. Mit „softwarewerkzeuggestützt“ ist dabei ein hierin in den Ansprüchen oder weiter unten angegebenes neuartiges, eigens zum Umsetzen des vorliegenden Verfahrens in dessen Gesamtheit dienendes Software-Werkzeug gemeint, das zum Ausführen des Verfahrens beispielsweise in einem Computer, einer Steuerungseinheit oder einer anderen Datenverarbeitungsvorrichtung zur Systementwicklung und/oder Validierung installiert werden und ablaufen kann.
-
Eine Spezifikation, die mit dem vorliegenden Verfahren vorgenommen werden kann, ist beispielsweise eine Modifikation oder Änderung des Systems durch einen Nutzer wie Systementwickler oder Simulationsexperten. Sie kann insbesondere eine spezifische technische Wirkung bei der Ausführung des Systems in einer geeigneten Steuerungseinheit des Zielgeräts erzeugen, wie z. B. eine Messung, Anzeige und/oder Änderung einer aktuellen Fahrzeuggeschwindigkeit, Motordrehzahl, Temperatur oder eines beliebigen anderen physikalischen Betriebsparameters eines Kraftfahrzeugs oder anderen Zielgeräts. Das funktionale System umfasst dabei eine oder mehrere Funktionen zur Zielgerätsteuerung oder -Regelung. Beim funktionalen System kann es sich beispielsweise um ein Fahrerassistenzsystem wie einen Spurhalteassistenten (LKS, Lane Keeping Support) oder ein Abstandsregeltempomat (ACC, Adaptive Cruise Control), das Funktionen wie Empfangen und/oder Ermitteln aktueller Bewegungsparameter des eigenen Fahrzeugs und/oder voraus oder dahinter fahrender oder überholender Fremdfahrzeuge und davon abhängiges Ermitteln angepasster neuer Bewegungsparameter mit Veranlassung einer entsprechend geänderten Fahrzeugsteuerung umfassen kann, oder um ein Energiemanagement-System u.v.m. handeln.
-
„Ausführbarkeit“ der Spezifikation bedeutet dabei, dass mit dem vorliegenden Verfahren eine Verfolgung von durch die Spezifikation bewirkten Änderungen durch einen Nutzer zur Sicherstellung von deren Konsistenz mit dem gesamten System und beispielsweise mit vorbestimmten für seine Ausführbarkeit auf dem Zielgerät erforderlichen technischen Anforderungen gewährleistet werden kann. Hierzu umfasst das vorliegende Verfahren folgende Schritte:
- - Bereitstellen mindestens einer Modellansicht, insbesondere einer statischen funktionalen Systembeschreibung und/oder einer anderen strukturellen (oder auch statisch genannten) Beschreibung in Form von Funktionalitäten und deren Abhängigkeiten und/oder einer dynamischen Verhaltensbeschreibung (Simulationsmodell), des funktionalen Systems. Eine Modellansicht bedeutet dabei eine modellbasierte Systembeschreibung in einer für einen entsprechend qualifizierten Nutzer verständlichen, beispielsweise zumindest teilweise grafischen, Darstellungsweise oder Sprache. Zur Bereitstellung der jeweiligen Modellansichten können beispielsweise eingangs erwähnte oder andere bekannte geeignete Software-Werkzeuge zur Systementwicklung oder Simulation wie SysML, PREEvision oder MATLAB (jeweils eingetragene Marken) eingesetzt werden, auf die das erfindungsgemäße Software-Werkzeug der hierin dargelegten Art beispielsweise zugreifen kann.
- - Bereitstellen eines Auswahl-Interfaces, das zum Auswählen und/oder Ändern eines Systemteils, der beispielsweise einzelne Funktionen mit zugehörigen Schnittstellen oder andere Modellierungselemente des funktionalen Systems umfassen kann, in einer bereitgestellten ersten Modellansicht durch einen Nutzer ausgebildet ist;
- - Überführen und Anzeigen des in der ersten Modellansicht ausgewählten und/oder geänderten Systemteils, insbesondere vorgenommener Änderungen und/oder deren Auswirkungen und/oder Abhängigkeiten im restlichen System, in mindestens eine jeweils andere Modellansicht für einen Nutzer;
- - Bereitstellen eines Spezifikations- und Freigabe-Interfaces, das zum Auswählen und/oder Überprüfen und/oder weiteren Anpassen der angezeigten Änderungen in der mindestens einen jeweils anderen Modellansicht und zum Freigeben der in der ersten und/oder der mindestens einen jeweils anderen Modellansicht vorgenommenen Änderungen des Systems durch einen Nutzer ausgebildet ist;
- - automatisiertes Übernehmen der freigegebenen Änderungen des Systems in die mindestens eine jeweils andere Modellansicht und Fertigstellen des so geänderten Systems.
-
Der Begriff „Nutzer“ kann hierin sowohl eine einzelne als auch mehrere verschiedene Personen umfassen, beispielswese einen Systementwickler, der an der statischen funktionalen Systembeschreibung mitwirkt, einen Simulationsexperten, der mit der dynamischen Verhaltensbeschreibung betraut ist, und/oder eine Gruppe von Spezialisten auf verschiedenen technischen Gebieten, die für verschiedene Fahrzeugdomänen, wie z. B. Motorsteuerung, Fahrerassistenzsysteme, Energieversorgung, Klimaanlage etc., verantwortlich sind, auf die das funktionale System einwirkt. Änderungen können beim vorliegenden Verfahren nicht nur in einer einzigen, sondern bei Bedarf auch in mehreren verschiedenen Modellansichten, die als die obige erste Modellansicht oder als die genannten jeweils anderen Modellansichten fungieren, von einem einzigen oder von jeweils verschiedenen Nutzern, vorgenommen werden.
-
Eine Idee des vorliegenden Verfahrens besteht in einer im obigen Überführungs- und Anzeigeschritt implementierten semantischen Kopplung der in einer der verfügbaren Modellansichten von einem Nutzer vorgenommenen Änderungen auf das identische System in jeweils anderen Modellansichten mit einer werkzeugbasierten Unterstützung des Nutzers/Anwenders zur Verfolgung und Sicherstellung der Konsistenz von Änderungen und/oder deren Bewertung, bevor sie über das Spezifikations- und Freigabe-Interface zur endgültigen Übernahme im System freigegeben werden. Unter einer semantischen Kopplung der jeweils geänderten Modellelemente des Systems zwischen den verschiedenen Modellansichten wird hierin insbesondere eine inhaltliche, inhaltsabhängige, logische und/oder funktionale Kopplung dieser Modellelemente verstanden, die insbesondere die tatsächliche technische Auswirkung der jeweiligen Änderung des Systems in der jeweils anderen Modellansicht vollumfänglich widerspiegeln kann und es im Idealfall auch tut. Dadurch kann eine konsequente Verfolgung und Sicherstellung der Konsistenz von durch die Spezifikation bewirkten Änderungen mit dem gesamten System und vorbestimmten für seine Ausführbarkeit auf dem Zielgerät erforderlichen technischen Anforderungen gewährleistet werden. Insbesondere kann dabei eine semantische Kopplung einer statischen Modellansicht und einer dynamischen Verhaltensbeschreibung implementiert sein.
-
Durch eine solche semantische und softwarewerkzeuggestützte Kopplung von statischen und dynamischen Modellsichten nicht nur in frühen Phasen der Systementwicklung (linker, oberer Teil eines sogenannten bekannten V-Modells), sondern auch zur Systemvalidierung, d. h. zum rechten oberen Teil des V-Modells hin, können die eingangs beschrieben Defizite bis dahin bekannter Lösungen überwunden werden. Das sogenannte V-Modell ist eine anschauliche graphische Anordnung aufeinanderfolgender Entwicklungs- und Validierungsphasen eines Systems oder einer Software über der Zeit in Form eines „V“, wobei einzelne Entwicklungsphasen auf dem linken V-Zweig den jeweiligen Testphasen im rechten V-Zweig gegenübergestellt werden. Dabei werden beginnend am oberen linken Teil des „V“ nach unten zu dessen Spitze hin die zeitlich aufeinander folgenden Entwicklungsphasen, beispielsweise von einer Anforderungsanalyse (Anforderungs-Engineering) über die Entwicklung einer Systemarchitektur und eine immer tiefer detaillierte funktionale und technische Spezifikation bis zu einer Implementierungsgrundlage für die Software und Hardware an der V-Spitze angeordnet, die anschließend auf der rechten Seite validiert werden.
-
Die Erfindung ermöglicht somit eine ausführbare Spezifikation des funktionalen Systems (Simulation), deren Konsistenz zur statischen bzw. dynamischen Beschreibung durch eine softwarewerkzeuggestützte Kopplung relevanter Modellierungs-Artefakte, wie beispielsweise Wirkketten oder einzelner Funktionen oder deren Schnittstellen etc., sichergestellt werden kann. Bewusst zieht der hierin dargelegte Ansatz den Anwender/Nutzer mit ein, der Modifikationen und deren Abhängigkeiten mit seinem Expertenwissen plausibilisieren, prüfen und anschließend freigeben kann. Insbesondere kann vom Spezifikations- und Freigabe-Interface dabei eine Einzelfreigabe jeweiliger Änderungen, eine Freigabe einer gesamten vorbestimmten Artefaktmenge mit Änderungen und/oder eine pauschale Freigabe aller Änderungen unterstützt werden.
-
Insbesondere können beim vorliegenden Verfahren zusätzlich zu den über das Auswahl-Interface ausgewählten und/oder geänderten Funktionen auch deren definierte Abhängigkeiten, insbesondere Schnittstellen und deren Beschreibung, in die jeweils andere Modellansicht übertragen/überführt und dem Nutzer darin angezeigt werden. Dabei können die Abhängigkeiten dem Nutzer insbesondere übersichtlich angezeigt/dargestellt, z. B. nach Art der Beziehung, nach Ausgangs- und/oder Zielartefakt etc. sortiert, werden.
-
Insbesondere können die erste Modellansicht und die mindestens eine jeweils andere Modellansicht zwei oder mehr von folgenden Modellansichten des funktionalen Systems umfassen:
- - eine statische funktionale Systembeschreibung, die insbesondere mindestens eine funktionale Wirkkette, die Wirkzusammenhänge zwischen eine physikalische Funktionalität im Zielgerät betreffenden Wirk- und Zielparametern beschreibt, umfasst;
- - eine dynamische Verhaltensbeschreibung, die insbesondere eine mit einer Simulations-Software erzeugte Simulation des dynamischen Verhaltens des Systems umfasst;
- - eine funktionale Architektur, in der funktionale Gleichteile verschiedener Wirkketten aggregiert und nach funktionaler Zugehörigkeit in einer hierarchischen Dekomposition angeordnet sind;
- - eine technische Architektur, in der technische Gleichteile verschiedener Wirkketten aggregiert und nach technischer Zugehörigkeit in einer hierarchischen Dekomposition angeordnet sind;
- - ein Anforderungs-Engineering, das insbesondere technische Anforderungen an die einzelnen Systemteile darstellt.
-
Dabei kann beispielsweise die erste Modellansicht eine statische funktionale Systembeschreibung und eine der jeweils anderen Modellansichten eine dynamische Verhaltensbeschreibung sein, oder umgekehrt. Die obigen allgemein angegebenen Verfahrensschritte können dabei insbesondere so implementiert sein, dass:
- - der Nutzer über das Auswahl-Interface eine gesamte funktionale Wirkkette in deren statischer oder dynamischer Beschreibung oder einen oder mehrere Teile davon auswählt und/oder ändert;
- - beim Überführungsschritt aus einer statischen Beschreibung für jeden der ausgewählten und/oder geänderten Teile der Wirkkette automatisch ein Funktionsrumpf in der dynamischen Verhaltensbeschreibung mit einer Simulations-Software erzeugt und/oder aus einem existierenden Funktionsrumpf-Bestand ausgesucht und dem Nutzer angezeigt wird;
- - wobei das Spezifikations- und Freigabe-Interface insbesondere auch zum Vornehmen von Änderungen in der jeweils anderen Modellansicht, etwa in der dynamischen Verhaltensbeschreibung, und zu deren Rückführung in die erste Modellansicht oder generell in mindestens eine strukturelle Modellansicht, etwa in die statische funktionale Systembeschreibung und/oder in die funktionale Architektur, zum Überprüfen auf Widerspruchsfreiheit zu dem restlichen System ausgebildet ist.
-
Änderungen können hier beispielsweise veränderte, hinzugefügte oder gelöschte Funktionen oder Schnittstellen in der funktionalen Wirkkette sein und dem Nutzer insbesondere auch entsprechend als „verändert“, „hinzugefügt“ bzw. „gelöscht“ in der ersten und in den jeweils anderen Modellansichten angezeigt werden.
-
Ferner kann dabei das Spezifikations- und Freigabe-Interface insbesondere dazu ausgebildet sein, dem Nutzer eine Wahl zwischen einer oder mehreren der folgenden Optionen der zurückzuführenden Systemteile bereitzustellen:
- - alle Funktionen und Schnittstellen;
- - alle Funktionen bis zu einer vom Nutzer über das Spezifikations- und Freigabe-Interface zu definierenden Detailebene und alle zugehörigen Schnittstellen oder alle Primärfunktionen mit den zugehörigen Schnittstellen
- - vom Nutzer über das Spezifikations- und Freigabe-Interface zu wählende Funktionen und Schnittstellen.
-
Dabei stellen die primären Funktionen beispielsweise in an sich bekannter Weise einen Funktionsumfang dar, der zur Realisierung eines Merkmals (Features) oder eines Anwendungsfalls (Use Case) notwendig ist und die logischen bzw. physikalischen Zusammenhänge beschreibt. Um die genannte Wahl treffen zu können bzw. eine entsprechende Aufforderung des zugrundeliegenden Software-Werkzeugs bzw. der Steuerungseinheit zu erfüllen, kann oder muss der Nutzer beispielsweise in einer der Modellansichten kenntlich machen, ob es sich bei den Funktionen oder Schnittstellen um primäre oder sekundäre Funktion des Systems handelt. Dabei können sich sekundäre Funktionen von den primären Funktionen beispielsweise in an sich bekannter Weise wie folgt unterscheiden:
- Eine funktionale Betrachtung von Wirkketten und einer funktionalen Architektur beinhaltet in der Regel zwingend die primären Funktionen. Führt man beispielsweise eine iterative Entwicklung durch, wie etwa in der eingangs erwähnten Modellierungsplattform SPES beschrieben, so kann es Sinn machen auch eine funktionale Beschreibung von sekundären Funktionen zu ergänzen. Auch hier gibt es in der Regel unterschiedliche Lösungsmöglichkeiten, die man mittels einer funktionalen Betrachtung nutzerseitig verstehen und bewerten kann. Wichtig ist aber, dass man diese Funktionen als „sekundär“ kenntlich macht, da hinter der Berücksichtigung bestimmter sekundärer Funktionen ein entsprechend qualifizierter Designentscheider auf der Ebene der technischen Architektur steht, der über das notwendige technische Wissen verfügt, wie beispielsweise dass beim Einsatz eines Verbrennungsmotors bzw. ICE (internal combustion engine) ein Hochtemperatur-Kühlkreislauf benötigt wird. Nutzt man beispielsweise ein Sicherheitskonzept (Safety), dass Sicherheitsziele durch Redundanzen dekomponiert, so benötigt man ferner auch redundante Funktionen/Funktionalität, die erst auf geeignete Komponenten verteilt werden müssen/muss, was wiederum als sekundäre Funktionen kenntlich gemacht und berücksichtigt werden kann bzw. muss. Ändert sich eine Designentscheidung auf technischer Ebene, so hat dies ggf. Einfluss auf die sekundären Funktionen. Entsprechend werden diese Abhängigkeiten zwischen technischer und funktionaler Sicht dokumentiert.
-
Bei dieser und allen anderen Ausgestaltungen des vorliegenden Verfahrens kann die Überprüfung im Spezifikations- und Freigabe-Interface daher eine Aufforderung des Nutzers zur Kontaktaufnahme mit einer zur erforderlichen Prüfung oder Freigabe geeignet qualifizierten Organisationseinheit umfassen. Dies kann insbesondere auch durch Hinterlegung einer Telefonnummer und/oder Kontaktadresse eines entsprechend qualifizierten Nutzers und gegebenenfalls mindestens eines Vertreters im Software-Werkzeug bzw. der Steuerungseinheit der hierin dargelegten Art oder durch Implementierung eines automatisierten Abfrage- und Bereitstellungsvorgangs geeigneter Kontaktdaten für den Nutzer unterstützt werden.
-
Hinter der obigen Unterscheidung oder Kennzeichnung von primären bzw. sekundären Funktionen steht unter anderem die Tatsache, dass Funktionen in einem realen System immer eine Ausführungsplattform benötigen, auf der sie laufen. Diese Plattform setzt geeignete Technologien ein, wie beispielsweise Mikrocontroller, Speicherbausteine, Leistungshalbleiter, aber auch CAN-Bus, Ethernet, etc. Dies kann als die eigentliche Aufgabe von Technologie angesehen werden - eine Ausführungsplattform für Funktionen darzustellen. Dabei ist eine Technologie in der Regel nie perfekt (nicht ausreichend performant, zuverlässig, sicher, ...) und muss daher stets auf Einhaltung vorbestimmter technischer Anforderungen (z.B. funktionale Sicherheit) hin überprüft und gegebenenfalls angepasst werden. Ein Beispiel für eine sekundäre Funktion ist ein Thermalsystem zur Komponentenkühlung. Dieses wird beispielsweise notwendig, um ein Überhitzen einer Komponente zu vermeiden, die aufgrund eines geringen Wirkungsgrades ungewollt Energie in Wärme umwandelt.
-
Bei einer spezifischen Ausgestaltung umfasst das Verfahren der hierin dargelegten Art eine Überführung in die funktionale Architektur und/oder eine im Spezifikations- und Freigabe-Interface implementierte Überprüfung funktionaler Gleichteile verschiedener Wirkketten auf Änderungen und deren Übereinstimmung. Dabei kann bei mangelnder Übereinstimmung dies dem Nutzer gegebenenfalls mit einer automatischen Aufforderung zur Vornahme weiterer Änderungen in den betroffenen Funktionen, d. h. zum Erstellen von deren funktionalen Varianten, mit denen Übereinstimmung wiederhergestellt werden kann. Dabei können dem Nutzer insbesondere auch automatische Vorschläge in Form von möglichen Änderungsoptionen zum Erzielen einer übereinstimmenden funktionalen Varianten bereitgestellt werden. Beispielsweise kann bei einem Fahrerassistenzsystem ein funktionaler Gleichteil zweier verschiedener Wirkketten, von denen die eine Adaptive Cruise Control (ACC) und die andere Lane Keeping Support (LKS) verwirklicht, eine gemeinsame Funktion wie „Detektieren vorausliegender, nachfolgender und überholender Fahrzeuge“ sein.
-
Gemäß einem weiteren Aspekt ist eine Steuerungseinheit vorgesehen, die einen zum Ausführen eines Verfahrens der hierin dargelegten Art eingerichteten Prozessor umfasst. Die Steuerungseinheit kann beispielsweise Teil eines zur Systementwicklung oder -Validierung geeigneten Computers oder Computernetzwerks sein.
-
Gemäß einem weiteren Aspekt ist ein weiter oben bei der Beschreibung des Verfahrens bereits genanntes Software-Werkzeug (Computerprogramm) vorgesehen, das Befehle umfasst, die bei seiner Ausführung in einer Steuerungseinheit der hierin dargelegten Art oder einer anderen Datenverarbeitungseinrichtung diese veranlassen, das Verfahren der hierin dargelegten Art auszuführen.
-
Gemäß einem weiteren Aspekt ist ein maschinenlesbares Speichermedium vorgesehen, auf welchem ein solches Software-Werkzeug (Computerprogramm) gespeichert ist.
-
Mit dem Verfahren der hierin dargelegten Art kann somit insbesondere eine semantische und softwarewerkzeuggestützte Kopplung zwischen einer Wirkkette (Cause-effect-chain, CEC) in der statischen funktionalen Systembeschreibung und einer dynamischen Verhaltensbeschreibung (DVB) gewährleistet werden. Hierzu umfasst das Verfahren im Gegensatz zum eingangs beschriebenen Stand der Technik bei der Systementwicklung und/oder Systemvalidierung eine bidirektionale, automatisierte Überführung von Modellierungsartefakten zwischen CEC und DVB, die beispielsweise folgende Schritte aufweisen kann:
- - Übernahme von ganzen Wirkketten oder ausgewählten Teilen einer Wirkkette.
- - Bereitstellen/Anzeigen dem Nutzer einer anpassbaren Darstellung, welche Änderungen in der jeweils anderen Modellansicht vorgenommen wurden und welche Auswirkungen dies in der eigenen Modellansicht hat.
- - Beispielsweise werden dabei Artefakte wie Funktionen oder Schnittstellen als hinzugefügt, verändert oder gelöscht markiert.
- - Bei veränderten Artefakten werden die Änderungen dargestellt.
- - Der Nutzer kann mithilfe des Spezifikations- und Freigabe-Interfaces eine Bewertung der Änderungen durchführen, bevor deren endgültige Übernahme erfolgt.
- - Der Nutzer muss die Übernahme von veränderten Artefakten nach CEC oder DVB jeweils freigeben.
- - Es wird eine Einzelfreigabe, eine Freigabe einer Artefaktmenge und eine pauschale Freigabe aller Änderungen unterstützt.
- - Nur freigegebene Änderungen werden in die jeweils andere Modellansicht endgültig übernommen.
-
Neben dem Einfluss der Änderungen in CEC oder DVB können dem Nutzer dabei insbesondere auch Abhängigkeiten modifizierter Artefakte zu weiteren Modellansichten eines modellbasierten Ansatzes zur Systementwicklung, wie der eingangs erwähnten MBSE (Model-Based Systems Engineering), aufgezeigt werden. Dies können beispielsweise
- - Funktionale Architektur;
- - Requirements Engineering; und/oder
- - Technische Architektur
sein. Die verfügbare Information und das Vorgehen sind hierbei vergleichbar der oben beschriebenen CEC- und DVB-Kopplung.
-
Figurenliste
-
Die obigen Aspekte und deren Ausführungsformen und spezifische Ausgestaltungen werden nachfolgend anhand der in beigefügten Zeichnungen dargestellten Beispiele näher erläutert. Es zeigen:
- 1 ein Flussdiagramm eines Beispiels für ein Verfahren der hierin dargelegten Art zum Vornehmen ausführbarer Spezifikationen bei der Systementwicklung und/oder Systemvalidierung eines funktionalen Systems, hier eines Fahrerassistenzsystems für ein Kraftfahrzeug;
- 2a ein schematisches Beispiel einer statischen funktionalen Systembeschreibung mit drei verschiedenen Wirkketten, die als eine erste Modellansicht beim Verfahren gemäß 1 dient;
- 2b ein schematisches Beispiel einer der 2a entsprechenden funktionalen Architektur;
- 3a ein weiteres schematisches Beispiel einer statischen funktionalen Systembeschreibung zum Darstellen einer ACC-Wirkkette, die als eine erste Modellansicht beim Verfahren gemäß 1 dient;
- 3b ein schematisch dargestelltes Simulationsframework zur Entwicklung einer dynamischen Verhaltensbeschreibung in Bezug auf eine in 3a durch den Nutzer ausgewählte Funktionalität;
- 3c ein schematisch dargestelltes verfeinertes Simulationsmodell, das von einem Nutzer im bereitgestellten Simulationsframework gemäß 3b entwickelt wird; und
- 3d eine statische funktionale Systembeschreibung wie in 3a mit gemäß dem Verfahren der 1 zurückgeführten und dem Nutzer angezeigten Änderungen des Systems.
-
Beschreibung von Ausführungsformen
-
Alle weiter oben in der Beschreibung und in den nachfolgenden Ansprüchen erwähnten verschiedenen Ausführungsformen, Varianten und spezifischen Ausgestaltungsmerkmale des Verfahrens gemäß dem obigen ersten Aspekt sowie des entsprechenden Software-Werkzeugs, der Steuerungseinheit und des maschinenlesbares Speichermediums gemäß den obigen weiteren Aspekten können sinngemäß bei den in 1 bis 3d gezeigten Beispielen einzeln oder in oben erwähnten Kombinationen implementiert sein. Sie werden daher nachfolgend nicht alle nochmals wiederholt. Das Gleiche gilt entsprechend für die weiter oben bereits angegebenen Begriffsdefinitionen und Wirkungen in Bezug auf einzelne Merkmale, die in den 1 bis 3d gezeigt sind.
-
1 zeigt in einem Flussdiagramm ein Verfahren der hierin dargelegten Art zum Vornehmen ausführbarer Spezifikationen bei der Systementwicklung und/oder Systemvalidierung eines funktionalen Systems für ein Zielgerät, in diesem Beispiel eines Fahrerassistenzsystems für ein Kraftfahrzeug. Das Verfahren und einige seiner möglichen spezifischen Ausführungsformen werden zunächst allgemein, unter anderem mit Bezug auf das in 2a und 2b gezeigte Beispiel statischer Modellansichten M1 und M2 eines Fahrerassistenzsystems, beschrieben und anschließend in einem weiteren Beispiel einer ACC-Regler-Entwicklung anhand der 3a bis 3d weiter veranschaulicht.
-
Bei einem ersten Schritt S1 wird einem Nutzer die in 2a vereinfacht und schematisch dargestellte erste Modellansicht des Systems in Form einer statischen funktionalen Systembeschreibung M1 bereitgestellt, die in diesem Beispiel drei verschiedene Wirkketten W1, W2 und W3 umfasst. Die erste Wirkkette W1 beschreibt dabei ein einfaches Beispiel eines Abstandsregeltempomats (ACC, Adaptive Cruise Control), die zweite Wirkkette W2 ein einfaches Beispiel einer lateralen Spurzentrierung (Lateral Lane Centering) und die dritte Wirkkette W3 ein einfaches Beispiel eines Autobahnpiloten (Highway Pilot). 2b zeigt eine ergänzende weitere statische Modellansicht dieses Systems in Form einer der 2a entsprechenden funktionalen Architektur M2, worauf weiter unten nochmals im Detail eingegangen wird.
-
Neue innovative Funktionen und Systeme in Automotive-Anwendungen zum automatisierten Fahren oder zur Verbesserung der Energieeffizienz von Fahrzeugen beschränken sich in der Regel nicht auf eine einzelne Fahrzeugdomäne, sondern sind komplexe Wirkketten, die sich über mehrere Fahrzeugdomänen erstrecken. Diese komplexen Wirkketten lassen sich beispielsweise mittels Aktivitätsdiagrammen in Form einer Abfolge von Aktivitäten F, die hierin auch als Funktionen oder Funktionalitäten genannt sind, und deren Abhängigkeiten über Schnittstellen C beschreiben, wie in 2a schematisch durch einzelne Blöcke und diese verbindende Linien angedeutet. Diese kausale Darstellung der statischen Zusammenhänge mittels weiter oben erwähnter Systementwicklungswerkzeuge wie SysML (eingetragene Marke) kann unter Verwendung ebenfalls weiter oben erwähnter spezialisierter Simulations-Werkzeuge wie MATLAB/Simulink (eingetragene Marke) um eine dynamische Verhaltensbeschreibung M3 (nicht dargestellt, ein Modellelement in 3b und 3c schematisch angedeutet), die eine andere Modellansicht im obigen Sinne darstellt, erweitert.
-
Das Verfahren gemäß 1 ermöglicht nun eine neuartige, durch ein entsprechendes Software-Werkzeug der hierin dargelegten Art unterstützte semantische und bidirektionale Kopplung einzelner zu spezifizierender Modellelemente dieser statischer und dynamischer Modellansichten M1, M2, und M3 auf ein gemeinsames System während dessen Entwicklung und/oder Validierung. Der einheitliche Begriff „Nutzer“ steht dabei stellvertretend für alle nachfolgend erwähnten verschiedenen Personen, die an der Systementwicklung oder -Validierung im Rahmen des vorliegenden Verfahrens beteiligt sind, wie einen System entwickler, der an der statischen funktionalen Systembeschreibung M1 mitwirkt, einen Simulationsexperten, der mit der dynamischen Verhaltensbeschreibung M3 betraut ist, und/oder eine Gruppe von Spezialisten auf verschiedenen technischen Gebieten, die für verschiedene Fahrzeugdomänen wie Motorsteuerung oder Energieversorgung verantwortlich sind, auf die das System einwirkt.
-
In einem auf den obigen Schritt S1 folgenden weiteren Schritt S2 des Verfahrens wird dem Nutzer ein Auswahl-Interface bereitgestellt, das zum Auswählen und/oder Ändern eines Systemteils in der ersten Modellansicht, etwa der in 2a gezeigten statischen funktionalen Systembeschreibung M1, durch den Nutzer ausgebildet ist. Da es aufgrund der Komplexität oder des Aufwandes nicht immer sinnvoll ist, eine Wirkkette vollständig zu modellieren, kann der Nutzer dabei sowohl eine gesamte Wirkkette W1, W2 oder W3 als auch nur Teile davon auswählen.
-
In einem weiteren Schritt S3 erfolgt eine automatische Überführung der durch den Nutzer beim Schritt S2 in der ersten Modellansicht ausgewählten bzw. geänderten Systemteile in die dynamische Verhaltensbeschreibung M3 und deren Anzeige für den Nutzer. Hierzu werden für die ausgewählten Teile in diesem Beispiel automatisch Funktionsrümpfe in MATLAB/Simulink angelegt. Zudem werden die in der ersten Modellansicht definierten Abhängigkeiten, wie Schnittstellen C, und deren Beschreibung der ausgewählten/geänderten Systemteile übertragen (vgl. 3a). Diese Schnittstellen können durch geeignete typische Spezifikationen/Attribute wie etwa Name, logisch physikalische Größe, Wertebereich, Auflösung, Quantisierung, Latenzanforderungen und/oder weitere Spezifikationen zum „Quality of Service“ und dergleichen in an sich bekannter Weise beschrieben werden.
-
Für den Fall, dass für den ausgewählten Teil der Wirkkette bereits ein Simulationsmodell existiert, gibt das das Verfahren implementierende Software-Werkzeug dem Nutzer Hilfestellung, welche Funktionen bereits ein Pendant im Simulationsmodell besitzen. Zudem wird der Nutzer auf veränderte, hinzugefügte oder gelöschte Funktionen in der funktionalen Wirkkette W1, W2 bzw. W3 hingewiesen und bekommt die Art der Änderung angezeigt. Beispielsweise, ob sich eine Schnittstelle geändert hat und wo diese Änderungen liegen.
-
Entfernte Funktionen werden bei den Schritten S2 und S3 nur als „gelöscht“ gekennzeichnet, und der Nutzer kann im weiteren Verfahrensverlauf (Schritt S4) entscheiden, wie er mit der Situation umgeht. Bei Bedarf kann er zurückspiegeln, dass diese Funktion weiterhin benötigt wird, und eine Klärung etwa durch Hinzuziehen weiterer Experten/Nutzer herbeiführen.
-
In einem weiteren Schritt S4 wird dem Nutzer ein Spezifikations- und Freigabe-Interface bereitgestellt, das ihm das Auswählen und/oder Überprüfen und/oder weitere Anpassen der angezeigten Elemente und Änderungen in der dynamischen und gegebenenfalls noch weiteren Modellansichten (wie beispielsweise die funktionale Architektur M2 gemäß 2b) und das Freigeben der vorgenommenen Änderungen ermöglicht. Der Funktionsentwickler bzw. Simulationsexperte kann in diesem Beispiel nun auf Basis der oben genannten Funktionsrümpfe eine dynamische Verhaltensbeschreibung M3, typischerweise ein DAE-Modell (Differential Algebraic Equation), entwickeln, simulieren und auswerten. Dazu nutzt er die bereits in der ersten, statischen Modellansicht definierten und beim Schritt S2 in die dynamische Modellansicht übertragenen Schnittstellen und ergänzt oder verändert diese nach Bedarf. Ebenso können dabei Funktionen F erweitert, hinzugefügt oder in einer hierarchischen Dekomposition gemäß der funktionale Architektur M2 detailliert werden.
-
Dabei ist das Spezifikations- und Freigabe-Interface in diesem Beispiel auch zu einer automatischen Rückführung der Erkenntnisse der dynamischen Verhaltensbeschreibung M3 zur statischen funktionalen Systembeschreibung M1 beispielsweise gemäß 2a und/oder zur funktionalen Architektur M2 gemäß 2b ausgebildet, um sicherzustellen, dass die in der dynamischen Modellansicht durchgeführten Änderungen zur Restfunktion der betroffenen Wirkkette (bei der Simulation einer Teilwirkkette) bzw. zur Funktion des restlichen Systems oder des Restfahrzeugs (beispielsweise zu den anderen Wirkketten) passen, d. h. das hier keine Widersprüche oder Konflikte entstehen. Hierzu werden diese Änderungen im vorliegenden Beispiel in die funktionale Architektur M2 zurückgeführt und können so vom Nutzer auf Widerspruchsfreiheit überprüft werden.
-
Dabei kann der Funktionsentwickler bzw. der Simulationsexperte insbesondere auswählen, welche Teile des Simulationsmodells zurückgeführt werden sollen. Es können im Spezifikations- und Freigabe-Interface beispielsweise folgende Auswahlmöglichkeiten für die Funktionsrückführung in die statische Modellansicht M1 und/oder M2 unterstützt werden:
- - Alle Funktionen und Schnittstelle werden, z. B. in die funktionale Architektur M2, zurückgeführt;
- - Alle Funktionen bis zu einer vom Nutzer zu definierenden Detailebene und alle zugehörigen Schnittstellen oder alle Primärfunktionen mit den zugehörigen Schnittstellen werden zurückgeführt;
- - Es werden vom Nutzer ausgewählte Funktionen und Schnittstellen zurückgeführt.
-
Hat der Simulationsexperte diese Auswahl unter Berücksichtigung von primären und sekundären Funktionen (siehe weiter oben angegebene Details zu deren Unterscheidung) im Spezifikations- und Freigabe-Interface getroffen, so führt das Software-Werkzeug gemäß dem vorliegenden Beispielverfahren einen Abgleich zwischen den Funktionsrümpfen in MATLAB/Simulink einschließlich deren Schnittstellen und den Funktionen in der Wirkkettenbeschreibung in SysML durch. Dabei kann beispielsweise automatisch überprüft werden, ob Funktionen hinzugefügt oder entfernt wurden. Weiterhin kann automatisch geprüft werden, ob Funktionen verändert wurden, d. h. ob geänderte Funktionsbeschreibung oder Schnittstellen vorliegen.
-
Hierbei kann eine Fallunterscheidung zwischen zwei folgenden Fällen durch das Verfahren bzw. entsprechende Software-Werkzeug implementiert sein:
- - Es wird eine vollständige Wirkkette, beispielsweise W1, W2 oder W3 aus 2a, geschlossen zurückgeführt. In diesem Fall ist keine weitere Überprüfung dieser Wirkkette notwendig.
- - Es werden Teile einer Wirkkette zurückgeführt. In diesem Fall werden auf SysML-Seite die Abhängigkeiten von veränderten, hinzugefügten oder gelöschten Funktionen zur restlichen Wirkkette untersucht und diese dem Nutzer zur Bewertung vorgelegt, d. h. mit einer Aufforderung zur Bewertung im Spezifikations- und Freigabe-Interface angezeigt. Der Nutzer kann dabei jede Abhängigkeit einzeln oder mittels Sammelfreigabe quittieren/freigeben bzw. hat die Möglichkeit potentielle Konflikte zur dynamischen Verhaltensbeschreibung zurück zu spiegeln. Es werden nur freigegebene Änderungen übernommen.
-
In beiden Fällen können auf SysML-Seite insbesondere auch formale Modellierungsrichtlinien, Namenskonventionen, etc. automatisch überprüft werden. Der Nutzer wird auf mögliche Konventionsverletzungen, etc. mit einer geeigneten Anzeige bzw. Bewertungsaufforderung im Spezifikations- und Freigabe-Interface aufmerksam gemacht.
-
Veränderte Funktionen können dabei nicht nur Abhängigkeiten innerhalb einer Wirkkette haben. Daher kann die in 2b beispielhaft dargestellte funktionale Architektur M2 eine weitere wesentliche Modellansicht auf funktionaler, statischer oder struktureller Ebene sein. Ziel dieser statischen Modellansicht ist insbesondere die Identifikation von Gleichteilen zwischen Wirkketten und der Möglichkeit ein funktionales Variantenkonzept zu entwickeln:
-
2a zeigt die oben genannten drei verschiedenen Wirkketten W1, W2 und W3, und 2b zeigt die zugehörige funktionale Architektur. Diese aggregiert funktionale Gleichteile und ordnet diese nach funktionaler Zugehörigkeit in einer hierarchischen Dekomposition an. In diesem Beispiel weisen die Wirkketten W1-W3 ein funktionales Gleichteil G auf, das in der korrespondierenden funktionalen Architektur einer gemeinsamen Funktion, beispielsweise „Detektieren vorausliegender, nachfolgender und überholender Fahrzeuge“, entspricht. Wird bei einer der Wirkketten W1, W2 oder W3 in der Simulation die gemeinsame Funktion verändert, so kann im vorliegenden Verfahrensbeispiel auch für die anderen zwei Wirkketten eine Prüfung implementiert sein, ob die geänderte Funktion genutzt werden kann oder ob hier eine funktionale Variante benötigt wird, die wiederum für alle drei Wirkketten W1, W2 und W3 einsetzbar ist. Dazu kann der Nutzer auf diese Abhängigkeiten im Spezifikations- und Freigabe-Interface hingewiesen werden. Gegebenenfalls kann er dann durch überschaubare Änderungen an der Funktion wiederum eine gemeinsame Lösung für die unterschiedlichen Wirkketten W1, W2 und W3 finden.
-
Aber nicht nur die Abhängigkeit vorgenommener Änderungen zur funktionalen Architektur M2 sondern auch zu benachbarten Entwicklungsschritten wie zum Requirements-Engineering oder zur technischen Architektur können beim vorliegenden Verfahren in ähnlicher Weise implementiert sein. Alle modellierten Abhängigkeiten können dem Nutzer im Spezifikations- und Freigabe-Interface mit einer entsprechenden Aufforderung zur Bewertung und/oder Anpassung angezeigt werden.
-
Um eine gegebenenfalls größere Anzahl von Abhängigkeiten übersichtlich darzustellen, können diese beispielsweise nach Art der Beziehung, nach Ausgangs- und/oder Zielartefakt etc. gruppiert dargestellt werden.
-
Da in der Regel mehrere Experten aus unterschiedlichen technischen Bereichen benötigt werden, um mögliche Konsequenzen zu bewerten, können entsprechende Organisationseinheiten gegebenenfalls auch mit deren Kontaktdaten im vorliegenden Software-Werkzeug hinterlegt werden, um einen schnellen Kontakt zu ermöglichen. Eine entsprechende Aufforderung kann im Spezifikations- und Freigabe-Interface implementiert sein, sodass beispielsweise bestimmte Art von Änderungen nicht ohne deren Erfüllung freigegeben werden kann.
-
Im Folgenden wird das beschriebene Verfahren gemäß 1 weiter mit Bezug auf 3a-3d veranschaulicht, die ein Beispiel zeigen, wie auf Basis einer Wirkkette W4 für einen ACC-Regler die Entwicklung bzw. weitere Spezifikation für ein ausgewähltes Element dieser Wirkkette W4 mittels eines Simulationsmodells, also einer dynamischen Verhaltensbeschreibung M3, unter Verwendung des vorliegenden Verfahrens bzw. Software-Werkzeugs vorgenommen wird. Die in Bezug auf 2a und 2b beschriebenen Verfahrensschritte S1-S4 gelten sinngemäß auch für das in 3a-3d gezeigte Beispiel und werden daher nicht nochmals im Detail wiederholt.
-
Wie im vorausgegangenen Beispiel, werden auch hier die bei der Entwicklung in der dynamischen Modellansicht gewonnenen Erkenntnisse zum Schluss wieder in die Ausgangswirkkette W4 zurückgeführt, d. h. in die statische funktionale Beschreibung M1 gemäß 3a bzw. 3d. Dabei wird der Nutzer auf durchgeführte Veränderungen hingewiesen. Das Verfahren gemäß 1 bzw. das entsprechende Software-Werkzeug, das auf einem Computer abläuft, unterstützt dabei folgende Systementwicklungsschritte eines jeweiligen „Nutzers“:
- 1. Der Systemarchitekt beschreibt die funktionalen Zusammenhänge des Features ACC in Form einer Wirkkette W4, wie vereinfacht in 3a dargestellt. Die resultierende erste Modellansicht dieses Features oder Systems in Form einer statischen funktionalen Systembeschreibung M1 wird den weiteren Nutzern beim obigen Schritt S1 des Verfahrens gemäß 1 bereitgestellt.
- 2. Der Funktionsentwickler für eine Funktion bzw. Funktionalität F1, in diesem Beispiel „Berechnung der ACC-Trajektorie“, innerhalb dieses Features wählt diese Funktionalität F1 in der obigen ersten Modellansicht über das beim obigen Verfahrensschritt S2 bereitgestellte Auswahl-Interface aus.
-
Softwarewerkzeuggestützt wird nun beim nachfolgenden Verfahrensschritt S3 automatisch ein in 3b schematisch dargestelltes Simulationsframework zur Entwicklung einer dynamischen Verhaltensbeschreibung M3 in Bezug auf die Funktionalität F1 generiert. Dabei werden alle Informationen automatisch mit übernommen, die in der Wirkkettenbeschreibung der ersten Modellansicht gemäß der 3a für die Funktionalität F1 enthalten sind, wie beispielsweise
- - Schnittstellen C, C1... mit deren Signaturen
- - Qualitative Anforderungen an die Schnittstellen C, C1... wie beispielsweise quantitative Angaben für niedrige, mittlere oder hohe Datenvolumen, Taktzeitanforderungen und Latenzzeitanforderungen; Angaben zur funktionalen Sicherheit und dergleichen;
- - Attribute, die die Funktionalität F, F1... näher beschreiben, wie beispielsweise Angaben zur funktionalen Sicherheit, dem Operationssystem, der Rechenleistung, dem Speicher; und dergleichen;
- - Textuelle Beschreibungen der Funktionalität F, F1...
- - Referenzen zu Anforderungen, die diese Funktionalität F, F1... umsetzen sollen.
-
3. Wie in 3c gezeigt, kann der Funktionsentwickler im bereitgestellten Simulationsframework nun ein verfeinertes Simulationsmodell entwickeln, das das dynamische Verhalten der Funktionalität F1 definiert. Dazu führt er beispielsweise weitere Simulationselemente ein, die das Verhalten beschreiben, verbindet diese mit den verfügbaren Eingangs- und Ausgangsgrößen. Der Entwickler beschreibt diese Größen und definiert auf Basis der Simulation deren Wertebereiche, Auflösung, Einheit, Zeitanforderungen, etc.. Bei Bedarf kann er weitere Größen einführen, wie beispielsweise die Aufteilung der Eingangsgröße C1, die in diesem Beispiel „Objektdaten“ angibt, in eine Beschleunigung a, Geschwindigkeit v und Abstand gap zum vorausfahrenden Fahrzeug.
-
4. Bei Bedarf verfeinert der Funktionsentwickler dabei nicht nur Funktionalitäten wie F1, die in der Wirkkette W4 bereits enthalten sind, sondern führt auch neue Funktionen ein, wie beispielsweise die neu eingefügte Funktion F3 „Vorbereitung von Displaydaten für ACC“ in 3d. Dies resultiert auch in neuen Abhängigkeiten. So wird die Schnittstelle C3 für „Displaydaten“ neu eingeführt.
-
5. Hat die Reife der dynamischen Verhaltensbeschreibung M3 einen ausreichenden Stand erreicht, kann der Funktionsentwickler seine Änderungen werkzeuggestützt, d. h. im beim obigen Verfahrensschritt S4 bereitgestellten Spezifikations- und Freigabe-Interface, wieder in die statische funktionale Modellansicht M1 zurückführen lassen, wie in 3d schematisch dargestellt. Im ersten Schritt werden die durchgeführten Änderungen in der funktionalen ersten Modellansicht M1 nur kenntlich gemacht und müssen zur endgültigen Übernahme im Feature/System ACC-Regler erst über das Spezifikations- und Freigabe-Interface freigegeben werden.
-
6. Der Nutzer, beispielsweise wiederum der Systemarchitekt, erhält dabei beim vorliegenden Verfahren eine anpassbare Darstellung, welche Veränderungen in der jeweils anderen Modellansicht vorgenommen wurden und welche Auswirkungen dies in der eigenen Modellansicht hat. Dies ist im vorliegenden Beispiel in 3d in der statischen funktonalen Modellansicht M1 veranschaul icht:
- - Beispielsweise werden Artefakte wie Funktionen F, F1... oder Schnittstellen C, C1... als hinzugefügt, verändert oder gelöscht markiert.
- - Bei veränderten Artefakten werden die Änderungen dargestellt.
- - So ist in 3d die ausgewählte und/oder veränderte Ausgangsfunktionalität F1 kenntlich gemacht und ebenfalls die veränderte Eingangsgröße C1. Hier wird die verfeinerte Schnittstellenspezifikation dem Nutzer durch einen erläuternden Kasten E1 dargestellt.
- - Zudem wird der Nutzer durch die Anzeige gemäß 3d darauf hingewiesen, dass diese Schnittstellenänderung auch Einfluss auf die Funktionalität F2 hat, die diese Information, hier die veränderte Eingangsgröße C1, bereitstellen muss. So kann der Systemarchitekt diese Änderungen vor deren Freigabe mit dem Verantwortlichen von der Funktion F2 abstimmen.
- - Die Funktionalität F3 und deren Ausgangsgröße C3 sind als neu gekennzeichnet. Hier muss der Systemarchitekt deren Notwendigkeit bewerten und gegebenenfalls prüfen, ob es eine vergleichbare Funktionalität bereits gibt und Gleichteile G genutzt werden können. In jedem Fall sind die Auswirkungen auf eine in der Wirkkette W4 nachfolgende Funktionalität F4 zu bewerten und gegebenenfalls mit dem Funktionsverantwortlichen für F4 abzustimmen.
-
7. Dies ermöglicht dem Systemarchitekten die kenntlich gemachten Änderungen zu bewerten, bei Bedarf gemeinsam mit den Funktionsverantwortlichen der betroffenen Funktionalitäten F1, F2, F3 und F4. Der Systemarchitekt kann nun entscheiden, welche Änderungen er freigibt oder bei Bedarf mit dem Funktionsentwickler Rücksprache hält und Änderungen bewusst nicht übernimmt.
-
8. Es wird in diesem Beispiel eine Einzelfreigabe, eine Freigabe einer Artefaktmenge und eine pauschale Freigabe aller Änderungen im Spezifikations- und Freigabe-Interface unterstützt.
-
9. Nur freigegebene Änderungen werden in die jeweils andere Modellansicht endgültig übernommen.
-
Anwendungsgebiete des Verfahrens der hierin dargelegten Art sind nicht auf die Systementwicklung beschränkt. Beispielsweise lässt sich die oben beschriebene automatisierte Kopplung zwischen statischer, funktionaler Sicht und dynamischer Verhaltensbeschreibung für verschiedene Entwicklungsaktivitäten innerhalb des weiter oben beschriebenen V-Modells einsetzen. Zum einen kann das Verfahren bzw. das dieses implementierende Software-Werkzeug zur Entwicklung einer einzelnen Systemfunktion bzw. Teilfunktion eingesetzt werden, da eine Änderungsverfolgung und Kontrolle durch semantische softwarewerkzeuggestützte Kopplung einzelner Modellansichtselemente ermöglicht wird. Somit trägt der Ansatz dazu bei, das Systemdesign zu detaillieren bzw. eine Realisierung zu entwickeln. Es kann aber auch genauso zur Entwicklung von automatisierten System- oder Integrationstest oder zur Ermittlung geeigneter Stimuli und zugehöriger Systemreaktionen im Validierungsstadium eingesetzt werden.
