DE102019003851A1

DE102019003851A1 - Systeme und Verfahren zum automatischen Realisieren von Modellen zu Co-Simulation

Info

Publication number: DE102019003851A1
Application number: DE102019003851.7A
Authority: DE
Inventors: Haihua Feng; Tao Cheng; John E. Ciolfi; Pieter J. Mostermann; Fu Zhang
Original assignee: MathWorks Inc
Current assignee: MathWorks Inc
Priority date: 2018-06-01
Filing date: 2019-05-31
Publication date: 2019-12-05

Abstract

Systeme und Verfahren erzeugen automatisch eine Realisierung eines Modells aus einer verfügbaren Menge von alternativen Co-Simulationskomponenten, wobei die Realisierung ein oder mehrere Ziele erfüllt, wie neben anderen etwa Präzision, Ausführungsgeschwindigkeit oder Speichernutzung. Die Systeme und Verfahren können das Realisierungsmodell erzeugen, indem sie ein Optimierungsproblem unter Randbedingungen aufstellen und lösen, welches bestimmte der alternativen Co-Simulationskomponenten auswählen mag, um die Ziele zu erfüllen. Die Systeme und Verfahren können die Realisierung konfigurieren und das realisierte Modell durch Co-Simulation ausführen. Die Systeme und Verfahren können unterschiedliche Ausführungs-Engines und/oder unterschiedliche Löser verwenden und verwalten, um die Realisierung des Modells auszuführen.

Description

Querverweis auf verwante Anmeldungen
Die vorliegende Anmeldung beansprucht die Priorität der provisionellen Patentanmeldung Anmeldenummer 62/775,023, eingereicht am 4. Dezember 2018, für „Systems and Methods for Automatically Realizing Models for Cosimulation“, der provisionellen Patentanmeldung Anmeldenummer 62/729,650, eingereicht am 11. September 2018, für „Systems and Methods for Automatically Realizing Models for Co-Simulation“, und der provisionellen Patentanmeldung Anmeldenummer 62/679,314, eingereicht am 1. Juni 2018, für „Systems and Methods for Automatically Realizing Implementations of Models for Co-Simulation“, welche Anmeldungen durch Bezugnahme hiermit in Gänze mit aufgenommen sind.
Figurenliste
Die nachfolgende Beschreibung bezieht sich auf die beigefügten Zeichnungen, in welchen:

1 ist eine schematische Darstellung einer beispielhaften Co-Simulationsumgebung in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
2 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
3 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
4 ist eine schematische Darstellung einer beispielhaften graphischen Affordanz in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
5 ist eine schematische Darstellung von beispielhaften Metadaten für eine Modellkomponente in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
6 ist eine schematische Darstellung von beispielhaften Metadaten für einen Knoten eines Computernetzwerks in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
7 ist eine schematische Darstellung eines beispielhaften Modells in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
8 ist eine schematische Darstellung eines weiteren beispielhaften Modells in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
9 ist eine teilweise, schematische Darstellung einer beispielhaften Integrationsplattform in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
10A-D sind teilweise Ansichten eines Flussdiagramms eines beispielhaften Verfahrens in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
11 ist eine schematische Darstellung eines beispielhaften Datenverarbeitungssystems in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
12 ist ein schematisches Diagramm einer beispielhaften verteilten Rechnerumgebung in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
13 ist eine schematische Darstellung einer beispielhaften Partitionierungsstufe in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
14 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
15 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen;
16 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen; und
17 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation eines Systemdesigns in einer Übersicht in Übereinstimmung mit einer oder mit mehreren Ausführungsformen.

Detaillierte Beschreibung beispielhafter Ausführungsformen
Computersimulation wird häufig verwendet beim Entwerfen, Testen und Erstellen physikalischer oder Softwaresysteme. Simulation beinhaltet das Erstellen eines Computermodells eines Systems. Das Modell kann so erstellt sein, das Verhalten des Systems nachzubilden. In einigen Fällen kann das Modell ein Regelstreckenelement und ein Reglerelement beinhalten. Der Entwickler kann ein Softwaresimulationswerkzeug, wie etwa eine graphische Simulationsumgebung, verwenden, um auf manuelle Weise ein Modell in Form eines Blockdiagramms zu erstellen. Das Blockdiagramm kann eine ausführbare Spezifikation sein, und kann von der Simulationsumgebung unter Verwendung von einem oder von mehreren Simulationswerken simuliert werden, zum Beispiel ausgeführt oder exekutiert werden. Zumindest einige der graphischen Blöcke in dem Blockdiagramm können in einer deklarativen Sprache sein. Eine Simulationsumgebung, welche derartige graphische Blöcke unterstützt, kann unter anderem die Simulink® modellbasierte Entwurfsumgebung von The MathWorks, Inc. aus Natick, Massachusetts, beinhalten. Prüfstände können erstellt und am Modell verwendet werden zur Überprüfung und Validierung der Systemanforderungen. Code kann für das Modell generiert werden, und der generierte Code, der außerhalb des Simulationstools kompiliert und ausgeführt werden kann, kann auf einem eingebetteten oder einem anderen System zum Einsatz gebracht werden. Erzeugter Code kann auch verwendet werden, um Hardware-in-the-Loop (HIL), Software-in-the-Loop (SIL) und/oder Prozessor-in-the-Loop (PIL) Simulationen auszuführen.
Simulationsmodelle können hierarchisch sein, und können erstellt werden unter Verwendung von sowohl Top-Down als auch Bottom-Up Ansätzen. Ein Entwickler kann das Modell auf einer hohen Ebene betrachten und sich dann durch die Hierarchie hindurch nach unten arbeiten, um zunehmende Ausmaße an Modelldetail zu sehen. Ein Modell eines komplexen Systems, wie etwa ein Fahrzeug, kann mehrere miteinander verbundene Komponenten beinhalten. Die Komponenten können verschiedene Subsysteme repräsentieren, wie etwa den Fahrzeugmotor, das Getriebe, die Federung, Bremsen, Steuergeräte, wie etwa elektronische Steuergeräte („electronic control unit“, ECU), etc. Die Komponenten selbst können wiederum andere Komponenten beinhalten, was die Hierarchie des Modells erzeugt.
Eine Simulationsumgebung kann eine Ausführungs-Engine beinhalten, welches das Modell unter Verwendung von einem oder von mehreren Lösungseinheiten ausführen kann. Beispielsweise kann die Ausführungs-Engine für ein Modell eines dynamischen Systems die Zustände des Modells zu aufeinanderfolgenden Zeitschritten über eine spezifizierte Simulationszeit hinweg berechnen. Eine Simulationsumgebung kann mehrere Löser beinhalten, wobei jeder einen partikulären Ansatz zum Lösen eines Modells verkörpert. Beispielsweise können Löser allgemein als mit fester Schrittweite, mit variabler Schrittweite, kontinuierlich und diskret klassifiziert werden. Ein Löser mit variabler Schrittweite reduziert die Schrittgröße, wenn sich die Zustände eines Modells rasch ändern. Es kann auch die Schrittweite bei Nulldurchgangsereignissen verringern, um die Genauigkeit zu erhöhen, und die Schrittweite vergrößern, wenn sich die Zustände des Modells langsam ändern, um unnötige Schritte zu vermeiden. Kontinuierliche Löser verwenden numerische Integration, um kontinuierliche Zustände eines Modells zu einem aktuellen Zeitschritt basierend auf den Zuständen zu vorhergehenden Zeitschritten und den Ableitungen der Zustände zu berechnen. Beispiele von kontinuierlichen Lösern mit fester Schrittweite beinhalten das Eulersche Verfahren, das Heun'sche Verfahren, die Bogacki-Shampine Formel, die Runge-Kutta Formel und die Dormand-Prince Formel. Diskrete Löser werden hauptsächlich verwendet, um rein diskrete Modelle zu lösen. Diese berechnen nur einen nächsten Simulationszeitschritt für ein Modell. Diskrete Löser können diskrete Ereignis-Löser beinhalten, welche beispielsweise Max-Plus-Algebra, Ereigniskalender und so weiter verwenden. Andere beispielhafte Löser beinhalten unter anderem differential-algebraische Gleichung (DAE) Löser, dünnbesetzte Matrix Löser und nichtlineare Gleichungs-Löser.
In einigen Fällen kann ein Modell in einer einzelnen Simulationsumgebung erstellt werden, und kann simuliert werden, zum Beispiel ausgeführt werden, unter Verwendung der Ausführungs-Engine und eines ausgewählten Lösers der einzelnen Simulationsumgebung. In anderen Fällen kann ein Modell erstellt werden, welches Modellkomponenten enthält, welche gelöst werden unter Verwendung unterschiedlicher Ausführungs-Engines, Lösern, zum Beispiel Löser unterschiedlicher Typen oder unterschiedlicher Löser desselben Typs, und/oder unterschiedlicher Werkzeuge/Softwareanwendungen. In diesem Fall kann Co-Simulation verwendet werden, um ein solches Modell auszuführen. Modellkomponenten, welche ausgeführt werden unter Verwendung von Co-Simulation können auch als Co-Simulationskomponenten bezeichnet werden. Co-Simulationskomponenten können in unterschiedlichen Modellierungsumgebungen erstellt werden, zum Beispiel unterschiedlichen Softwaremodellierungswerkzeugen, und zu einem einzigen Modell zusammengefügt werden.
Wenn eine Co-Simulationskomponente erzeugt wird, kann ein Benutzer modellierte Abtastraten für die Elemente der Komponenten (zum Beispiel Blöcke, Linien, Ports und so weiter) spezifizieren. Der Benutzer kann modellierte Abtastraten für alle der Elemente spezifizieren, für einige der Elemente spezifizieren und/oder eine globale modellierte Abtastrate für die Komponenten einstellen. In derartigen Fällen kann eine Ausführungs-Engine automatisch die modellierten Abtastraten für Elemente einstellen, die nicht vom Benutzer spezifiziert wurden, basierend auf Beziehungen zwischen den Elementen und den Semantiken der Co-Simulationskomponente, um eine konsistente und ausführbare Komponente sicherzustellen. Zum Beispiel, selbst wenn der Benutzer keine modellierte Abtastrate für ein Signal zwischen zwei Elementen einer Komponente spezifiziert, kann das Signal eine modellierte Abtastrate erben oder automatisch auf eine solche gesetzt werden (zum Beispiel eine kontinuierliche Abtastrate oder eine diskrete Abtastrate).
Eine Integrationsplattform, die eine Master-Ausführungs-Engine und einen Master-Löser aufweist, kann verwendet werden, um ein Modell, das Co-Simulationskomponenten aufweist, auszuführen. Eine gegebene Co-Simulationskomponente kann unter Verwendung einer subordinären Ausführungs-Engine ausgeführt werden, welche dieselbe ist wie oder eine andere ist als die Master-Ausführungs-Engine. Wie hierin verwendet, bezieht sich der Ausdruck „subordinäre Ausführungs-Engine“ auf eine Ausführungs-Engine, zum Beispiel eine von der Master-Ausführungs-Engine unterschiedliche Ausführungs-Engine, die eine Schnittstelle mit der Master-Ausführungs-Engine hat. Der Ausdruck „subordinärer Löser“ bezieht sich auf einen Löser, der von der subordinären Ausführungs-Engine verwendet wird, und/oder einen Löser, der von der Master-Ausführungs-Engine verwendet wird, die sich von dem Master-Löser unterscheidet, um die Co-Simulationskomponente zu lösen. Während die subordinäre Ausführungs-Engine und/oder der subordinäre Löser verwendet werden können, um die gegebene Co-Simulationskomponente auszuführen, kann die Master-Ausführungs-Engine verwendet werden, um eine Schnittstelle mit den subordinären Ausführungs-Engines und/oder den subordinären Lösern für andere Co-Simulationskomponenten zu bilden und um Daten zwischen Co-Simulationskomponenten während der Ausführung des Modells auszutauschen.
Unterschiedliche Ausführungs-Engines, die während der Co-Simulation eines Modells verwendet werden, können unabhängig voneinander fortschreiten (zum Beispiel in physischer Zeit im Gegensatz zu logischer Zeit) und können Daten mit einer bestimmten Kommunikationsrate austauschen. Die Master-Ausführungs-Engine kann den Datenaustausch zwischen den Modellkomponenten, die unterschiedliche subordinäre Ausführungs-Engines und/oder Löser verwenden, steuern. Die Master-Ausführungs-Engine kann über Schnittstellen für die Co-Simulationskomponenten mit den Co-Simulationskomponenten kommunizieren. Die Master-Ausführungs-Engine mag nur Zugriff auf Inhalte und Funktionalität einer jeweiligen Co-Simulationskomponente haben, die über eine Schnittstelle für die Co-Simulationskomponente verfügbar sind. Beispielhafte Schnittstellen beinhalten die Functional Mock-Up Schnittstelle (FMI) - eine Open Source Schnittstelle, die vom Modelica Association Project verwaltet wird, die S-Funktion Anwendungsprogrammierungsschnittstelle (API) von The MathWorks, Inc., aus Natick, Massachusetts, und die GT-SUITE API von Gamma Technologies, LLC, aus Westmont, Illinois.
In einigen Fällen können Entwickler alternative Modellkomponenten für ein gegebenes Subsystem erstellen. Beispielsweise können Entwickler mehrere alternative Modellkomponenten erstellen, um den Betrieb des Motors eines Fahrzeugs zu modellieren. Eine derartige Modellkomponente kann das Verhalten des Motors mit einem hohen Maß an Präzision, zum Beispiel numerischer Genauigkeit, modellieren, mag aber eine lange Zeit zur Ausführung erfordern. Eine andere Modellkomponente mag relative schnell ausgeführt werden, aber auf Kosten der Präzision. Benutzer mögen wünschen, Simulationsmodelle zu erstellen und auszuführen, welche verschiedene Kombinationen dieser alternativen Modellkomponenten in einer Weise der Co-Simulation verwenden.
Kurz gesagt bezieht sich die vorliegende Offenbarung auf Systeme und Verfahren, um auf automatische Weise ein Modell zu realisieren aus einer Menge verfügbarer alternativer Modellkomponenten, wobei das realisierte Modell ein oder mehrere Ziele bzw. Zielvorgaben, wie unter anderem etwa Präzision, Ausführungsgeschwindigkeit oder Speichernutzung, erfüllt. Die Systeme und Verfahren können das Modell realisieren, indem sie ein Optimierungsproblem unter Randbedingungen aufstellen und lösen, welches ein High-Level-Systemdesign partitionieren und bestimmte der alternativen Modellkomponenten auswählen kann, um die Ziele zu erfüllen. Die Systeme und Verfahren können das realisierte Modell konfigurieren und können dieses in einer Weise der Co-Simulation ausführen. Die Systeme und Verfahren können unterschiedliche Ausführungs-Engines, unterschiedliche Löser und/oder unterschiedliche Werkzeuge/Softwareanwendungen verwenden und verwalten, um die Modellkomponenten auszuführen, die in den unterschiedlichen Partitionen enthalten sind, so dass die Modellkomponenten als Co-Simulationskomponenten ausgeführt werden können und die Partitionen Co-Simulationspartitionen repräsentieren können.
In einigen Ausführungsformen können die Systeme und Verfahren in Form einer Integrationsplattform implementiert sein, welche eine High-Level-Beschreibung eines Systemdesigns erhält, zum Beispiel für ein physisches System oder ein Softwaresystem. Die Integrationsplattform kann von einem Benutzer spezifizierte Ziele für die Realisierung erhalten, wie etwa Präzision, Ausführungsgeschwindigkeit, Speichernutzung, etc., für die gesamte Realisierung oder für unterschiedliche Teile. Die Integrationsplattform kann eine Komponentenentdeckung ausführen, um Modellkomponenten zu identifizieren, welche Teile des Systemdesigns implementieren können. Die Integrationsplattform kann eine Netzwerkerkennung durchführen, um verfügbare Datenverarbeitungsmaschinen zu identifizieren und die Prozessor-, Speicher- und Datenkommunikationsressourcen dieser Maschinen zu identifizieren. Die Integrationsplattform kann eine Softwarewerkzeugentdeckung ausführen, um verfügbare Softwarewerkzeuge und -versionen zu bestimmen, die auf den Maschinen laufen, wie etwa Simulationsumgebungen, einschließlich der Ausführungs-Engines und Löser, die von den Softwarewerkzeugen implementiert sind. Die Integrationsplattform kann Attribute der Modellkomponenten, die verfügbar sind, um Teile des Systemdesigns zu implementieren, erhalten.
Die Integrationsplattform kann eine Partitionierung des Systemdesigns bestimmen durch Lösen des Optimierungsproblems unter Randbedingungen. Beispielsweise kann die Integrationsplattform eine Zielfunktion aufstellen bzw. einrichten und lösen, die Variablen hat, die auf zumindest einem Teil der Netzwerkinformation, der Softwarewerkzeuginformation, den Attributen der Modellkomponenten und der spezifizierten Ziele für die Verwirklichung basieren. Beispielhafte Zielfunktionen beinhalten Kostenfunktionen, Energiefunktionen, Belohnungsfunktionen und Nutzenfunktionen. In einigen Ausführungsformen könnte die Integrationsplattform auch auf maschinellem Lernen basierte Funktionen verwenden (zum Beispiel basierend auf Statistiken, Deep Learning, etc.). Die Integrationsplattform kann die Zielfunktion lösen, um eine Partitionierung des Systemdesigns zu bestimmen. Die durch Lösen erhaltene Partitionierung kann die Identität bestimmter Modellkomponenten beinhalten, die in jeder Partition enthalten sein sollen, die Identität der Datenverarbeitungsmaschinen und der Softwarewerkzeuge zum Ausführen dieser Modellkomponenten und die Ausführungs-Engines und/oder Löser, die von diesen Softwarewerkzeugen zu verwenden sind. Die durch Lösen erhaltene Partitionierung kann auch Parameter oder andere Information zum Konfigurieren von Schnittstellen zwischen den Partitionen enthalten, wie etwa Kompensatoren, um Fehler zu korrigieren, die anderweitig während der Co-Simulation auftreten könnten. Neben anderen Vorteilen mag es beispielsweise für einen Benutzer wertvoll sein, in der Lage zu sein, unterschiedliche Löser, unterschiedliche Softwarewerkzeuge und unterschiedliche Modellkomponentenimplementierungen verwenden zu können, um mehr Möglichkeiten für eine bevorzugtere Gesamtkonfiguration von Co-Simulationskomponenten, deren partikulärer Implementierungen (Softwarewerkzeug, Löser, Löserparameter, Modellkomponenten, die auf die Co-Simulationskomponente abgebildet sind, Modellkomponentenimplementierungen), sowie die Kommunikationskonfiguration zu bieten, im Gegensatz dazu, eine homogene Konfiguration zu erfordern, indem beispielsweise nur ein einzelnes Softwarewerkzeug erlaubt ist. Die Möglichkeit, ein komplexes Optimierungsproblem zu lösen, welches die bevorzugte Konfiguration für eine gegebene Zielfunktion und gegebene Randbedingungen findet, kann dem Benutzer helfen, eine gewünschte Konfiguration zu erhalten, die auf andere Weise nicht oder nur schwer hätte ermittelt werden können, was ohne die Anwendung dieses Verfahrens zu einer minderwertigen Lösung geführt hätte.
In einigen Ausführungsformen kann die durch Lösen erhaltene Partitionierung des Systemdesigns dem Benutzer zur Evaluierung angezeigt werden. Die Integrationsplattform kann die durch Lösen erhaltene Partition bewerten. Die Plattform kann eine statische oder dynamische Analyse durchführen. Beispielsweise könnte4 es sich um eine Analyse gegenüber Eigenschaften der verschiedenen Elemente handeln, welche in das Konfigurationsproblem eingehen (zum Beispiel wie lange ein Modell brauchen mag, um jeden Zeitschritt im Worst Case auszuführen, wieviel Speicher es erfordern mag, auf was die Toleranz der Löser eingestellt ist, die Kommunikationsrate oder -raten zwischen den verschiedenen Co-Simulationskomponenten, etc.) Sie könnte auch darauf basieren, eine Anzahl an Simulationen auszuführen und dann das Ergebnis zu analysieren (zum Beispiel wie lange es im Durchschnitt dauert, um eine bestimmte Simulation auszuführen, wie viel Varianz es bei berechneten Werten gibt zwischen Lösern, zwischen Kommunikationsraten, zwischen Modellkomponentenimplementierungen, etc.). Die dynamische Analyse kann dem Benutzer zur statischen Analyse präsentiert werden, und basierend darauf mag eine bevorzugte Konfiguration ausgewählt werden. Beispielsweise kann diese gegenüber den spezifizierten Zielen evaluiert werden. Wenn der Entwickler nicht mit der durch Lösen aufgefundenen Partition zufrieden ist, kann der Entwickler ein oder mehrere Ziele ändern, und kann die Integrationsplattform anweisen, eine neue Partition zu bestimmen. Alternativ oder ergänzend kann der Entwickler eine oder mehrere Randbedingungen für die zu bestimmende Partition aufstellen. Beispielsweise kann der Entwickler verlangen, dass eine bestimmte Modellkomponente, eine bestimmte Datenverarbeitungsmaschine und/oder ein bestimmtes Softwarewerkzeug verwendet werden soll, um einen Teil des Systemdesigns zu implementieren. Die Integrationsplattform kann derartige Anforderungen beim Aufstellen bzw. Einrichten der Zielfunktion als harte Randbedingungen berücksichtigen. Neben anderen Vorteilen kann die Plattform dem Benutzer eine Einsicht in die Leistungsfähigkeit einer bestimmten Partition/Konfiguration verschaffen, was es ermöglicht, Präferenzen für die Zielfunktion und die Randbedingungen hinzuzufügen oder zu entfernen, so dass das Endergebnis der Partitionierung/Konfiguration einem gewünschten Ergebnis näher kommt. Genauer mag ein Benutzer, indem ihm oder ihr mehr Einsicht verschafft wird, in die Lage versetzt werden, die Wirkung bestimmter Präferenzen auf die globale Partition/Konfiguration zu verstehen, und so zu verstehen, was möglich ist in Begriffen eines Gesamtergebnisses, sowie auch wie das Partitionieren/Konfigurieren angeleitet werden soll, um bestimmte spezifische Bedenken über andere zu adressieren.
Wenn eine akzeptable Partition erreicht ist, kann die Integrationsplattform das realisierte Simulationsmodell implementieren. Beispielsweise kann die Integrationsplattform die ausgewählten Modellkomponenten auf die identifizierten Datenverarbeitungsmaschinen laden. Sie kann die Softwarewerkzeuge konfigurieren. Beispielsweise kann die Integrationsplattform die Softwarewerkzeuge konfigurieren, bestimmte Ausführungs-Engines/Löser zu verwenden, um die Modellkomponenten auszuführen. Sie kann auch die Schnittstellen zwischen den Co-Simulationspartitionen zu konfigurieren. Beispielsweise kann die Integrationsplattform Kompensatoren an den Schnittstellen von und/oder zwischen den Modellkomponenten in unterschiedlichen Co-Simulationspartitionen einzufügen. Eine Master-Ausführungs-Engine der Integrationsplattform kann Datenkommunikationsraten zwischen Komponenten einstellen, und/oder deren lokale Ausführungs-Engines konfigurieren. Sie kann auch Kompensatorkonfigurationen spezifizieren, wie etwa Kompensatortypen, Extrapolations-/Interpolationsverfahren und -koeffizienten, Signalkorrekturkoeffizienten, etc.
Einige Schritte der vorliegenden Offenbarung verbessern eine Benutzererfahrung und -interaktion mit der Simulationsumgebung. Einige Schritte verbessern eine Simulationseffizienz. Einige Schritte verbessern eine Maschineneffizienz und Maschinenspeichernutzung. Einige Schritte verbessern eine Simulationsgenauigkeit und Datennutzbarkeit.
Integrationsplattform
1 ist eine schematische Darstellung einer beispielhaften Co-Simulationsumgebung 100 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die Co-Simulationsumgebung 100 kann eine Integrationsplattform 102, eine Menge von Modellkomponenten, die allgemein bei 104 gezeigt sind, und ein Computernetzwerk 106 beinhalten. Die Modellkomponenten können von demselben Benutzer oder von verschiedenen Benutzern entwickelt sein zum Simulieren von Systemen. Die Integrationsplattform 102 kann ein Modellpartitionierungswerk 108, ein Co-Simulationskomponenten-Ladewerk 110, ein Schnittstellenkonfigurationswerk 112 und ein Beurteilungswerk 113 beinhalten. Das Modellpartitionierungswerk 108 kann ein Netzwerkentdeckungswerk 114, ein Softwarewerkzeug-Entdeckungswerk 116, ein Co-Simulationskomponenten-Entdeckungswerk 118, und einen Prozessor 120 zur Optimierung unter Randbedingungen beinhalten. Der Prozessor 120 zur Optimierung unter Randbedingungen kann einen Zielfunktionsauswähler 122, ein Zielfunktions-Aufstellwerk 124 und ein Zielfunktions-Löser 126 beinhalten. Das Computernetzwerk 106 kann miteinander verbundene Datenverarbeitungsknoten, wie etwa Knoten 140a, 140b und 140c, beinhalten. Die Knoten 140a-c können unterschiedliche Prozessor- und Speicherressourcen aufweisen, können unterschiedliche Betriebssysteme ausführen und können unterschiedliche Simulationswerkzeuge und/oder unterschiedliche Versionen von Simulationswerkzeugen hosten. Beispielhafte Prozessorressourcen beinhalten Einkern- und Mehrkern-CPUs, GPUs, FPGAs, etc.
Die Integrationsplattform 102 kann ein High-Level- bzw. Hochebenen-Systemdesign 128 und eine oder mehrere Ziele 130 erhalten, wie durch die Pfeile 132 und 134 angezeigt. Der Ausdruck „High-Level“ bzw. „Hochebene“ bedeutet, dass das Systemdesign 128 wenig Implementierungsdetails enthält. Beispielsweise mag das High-Level-Systemdesign 128 selbst nicht einmal ausführbar sein und mag nur eine rudimentäre Beschreibung der Elemente, die das High-Level-Systemdesign 128 bilden, enthalten. In einigen Ausführungsformen kann das High-Level-Systemdesign 128 in der Form einer funktionellen Spezifikation, eines Architekturmodells, einer Systemrepräsentation, einem Plattformmodell, einer strukturellen Spezifikation, einer verhaltenstechnischen Charakterisierung, einem verhaltenstechnischen Rahmenwerk, einer Annahme/Garantie-Struktur, einem Variabilitätsmodell oder einem Produktlinienmodell. Die Integrationsplattform 102 kann Zugriff auf die Vielzahl von Modellkomponenten 104 haben, wie durch den Pfeil 136 angezeigt. Beispielsweise kann ein Benutzer Speicheradressen der Modellkomponenten 104 an die Integrationsplattform 102 bereitstellen, um die Modellkomponenten 104 in die Plattform 102 zu laden. Die Integrationsplattform 102 kann auch Zugriff auf das Computernetzwerk 106 haben, wie durch den Pfeil 138 gezeigt, zum Beispiel über ein lokales Netzwerk (LAN), das Internet oder eine andere Datenverbindung. Beispielsweise kann die Integrationsplattform 102 auf einem oder auf mehreren der Knoten 140a-c laufen.
Die Integrationsplattform 102 kann ein oder mehrere Zielfunktionen verwenden, um automatisch ein Modell 142 für das High-Level-Systemdesign 128 zu realisieren, welches die Ziele 130 erfüllt, wie durch den Pfeil 144 angezeigt. Das Modell 142 kann ausgewählte der Modellkomponenten 104 enthalten, wie etwa Modellkomponenten 146-149, die in unterschiedliche Co-Simulationspartitionen organisiert sind. Das Modell 142 kann auch Auswahlen 150 bestimmter Hardwarevorrichtungen innerhalb des Computernetzwerks 106 enthalten. Es kann auch Auswahlen 152 bestimmter Softwaresimulationswerkzeuge in dem Computernetzwerk 106 enthalten. Das Modell 142 kann weiter Modelleinstellungen 154 enthalten. Die Modelleinstellungen 154 können Information zum Konfigurieren der bestimmten Simulationswerkzeuge enthalten, um die ausgewählten Modellkomponenten 146-149 auszuführen, und zum Konfigurieren von Schnittstellen und/oder Kommunikationsverbindungen zwischen den ausgewählten Modellkomponenten 146-149, die in unterschiedlichen Co-Simulationspartitionen enthalten sind. Das Modell 142 kann einen oder kann mehrere Kompensatoren 155 enthalten. Der eine oder die mehreren Kompensatoren 155 mögen nicht intrinsisch Teil des Modells sein. Er mag entweder in das Modell eingefügt werden basierend auf einer Analyse, die vor der Ausführung ausgeführt wird, oder er ist eingebaut als Teil des Lösers, ohne explizit in das Modell eingefügt zu werden. Jeder dieser Ansätze mag Vorteile haben. Wenn beispielsweise der Kompensator in das Modell eingefügt wird, kann der Benutzer sehen, wo der Kompensator eingefügt wurde (und diesen vielleicht verwerfen oder diesen einen permanenten Teil des Modells machen). Wenn der Kompensator Teil des Lösers ist, ändert sich das Modell nicht (was mögliche Verwirrungen ausschließt).
In einigen Ausführungsformen kann das Co-Simulationskomponenten-Ladewerk 110 die ausgewählten Modellkomponenten 146-149 auf bestimmte der Knoten 140a-c des Computernetzwerks 106 laden, wie durch die Auswahlen 150 von Hardwarevorrichtungen spezifiziert. Das Co-Simulationskomponenten-Ladewerk 110 kann auch die Simulationswerkzeuge der Knoten 140a-c konfigurieren, um die ausgewählten Modellkomponenten 146-149 auszuführen, wie durch die Auswahlen 152 von Softwarewerkzeugen spezifiziert. Das Schnittstellenkonfigurationswerk 112 kann Schnittstellen und/oder Kommunikationsverbindungen zwischen den ausgewählten Modellkomponenten 146-149, die in unterschiedlichen Co-Simulationspartitionen enthalten sind, konfigurieren, zum Beispiel durch Einfügen der Kompensatoren 155. Das realisierte Modell 142 für das High-Level-Systemdesign 128 kann dann co-simuliert werden, zum Beispiel ausgeführt werden, um Co-Simulationsergebnisse zu liefern. Das Setup oder die Konfiguration kann statisch ausgeführt werden, aber es mag Rekonfigurationen geben, zum Beispiel basierend auf Simulationsergebnissen, in welchem Fall eine solche Rekonfiguration auch einen dynamischen Aspekt hat.
Die Integrationsplattform 102 kann ein Softwaresimulationswerkzeug enthalten oder Zugriff auf ein solches haben, wie etwa eine Simulationsumgebung, die auf demselben Prozessor wie oder einem anderen Prozessor als die die Plattform 102 implementiert sein kann. Die Simulationsumgebung kann eine oder mehrere Ausführungs-Engines und einen oder mehrere Löser beinhalten. Die eine oder die mehreren Ausführungs-Engines und Löser können als eine Master-Ausführungs-Engine und ein Master-Löser zum Steuern der Ausführung des Realisierungsmodells 142 arbeiten, zum Beispiel indem sie subordinäre Ausführungs-Engines und subordinäre Löser, die durch andere Softwaresimulationswerkzeuge implementiert sind, verwalten.
In einigen Ausführungsformen kann ein oder können mehrere von dem Modellpartitionierungswerk 108, dem Co-Simulationskomponenten-Ladewerk 110, dem Schnittstellenkonfigurationswerk 112 und dem Beurteilungswerk 113 durch ein oder mehrere Softwaremodule oder Bibliotheken, welche Programmanweisungen enthalten, welche neben anderen Verfahren die hierin beschriebenen Verfahren ausführen. Die Softwaremodule können in einem oder in mehreren Speichern gespeichert sein, wie etwa einem Hauptspeicher, einem persistenten Speicher und/oder einem computerlesbaren Medium, eines Arbeitsplatzrechners, eines Servers oder einer anderen Datenverarbeitungsmaschine oder - vorrichtung, und ausgeführt durch einen oder durch mehrere Prozessoren. Andere computerlesbare Medien können auch verwendet werden, um diese Programmanweisungen zu speichern, wie etwa nichttransitorische computerlesbare Medien, einschließlich optischer, magnetischer oder magneto-optischer Medien.
High-Level-Systemdesign
2 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur 200 des High-Level-Systemdesigns 128 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das High-Level-Systemdesign 128 kann ein Fahrzeug repräsentieren, wie etwa ein Automobil, und die funktionelle Struktur 200 kann graphisch definiert sein und Elemente beinhalten, welche partikuläre Systeme und/oder Subsysteme des Automobils repräsentieren. Die funktionelle Struktur 200 kann beispielsweise ein Icon 202 für ein Fahrzeugelement, ein anderes Icon 204 für ein Antriebsstrangelement, ein nochmals anderes Icon 206 für ein Fahrermodul, ein weiteres Icon 208 für ein Fahrzeugumgebungselement und ein nochmals weiteres Icon 210 für ein Steuer- und/oder Regelelement beinhalten. Das Steuer- und/oder Regelelement kann ein elektronisches Steuergerät („electronic control unit“, ECU) sein, wie etwa ein Antiblockiersystem (ABS), ein Tempomatsystem, ein Fahrerassistenzsystem („Advanced Driver Assistance System“, ADAS), und so weiter. In einigen Ausführungsformen mag die funktionelle Struktur 200 des High-Level-Systemdesigns 128 selbst nicht ausgeführt werden können, um das Verhalten oder den Betrieb des Fahrzeugs zu simulieren. Stattdessen mag die funktionelle Struktur 200 lediglich eine Angabe über die Elemente geben, die notwendig sind, um das Steuer- und/oder Regelelement 210 zu entwerfen, zu test4en oder zu implementieren. In einigen Ausführungsformen können die Icons 202-210 Platzhalter für ausführbare Modellkomponenten sein, und mögen nicht selbst ausführbare Komponenten sein. Das High-Level-Systemdesign 128 sowie die funktionelle Struktur 200 können daher Softwaresimulationswerkzeug-unabhängig und Modellkomponenten-unabhängig sein.
Die funktionelle Struktur 200 kann auch Symbole beinhalten, welche Daten repräsentieren, die zwischen den Elementen des High-Level-Systemdesigns 128 ausgetauscht werden. Sie kann zum Beispiel Pfeile 212 und 214 zwischen den Icons 202, 204 und 206 beinhalten, welche anzeigen, dass Ausgaben, die von dem Fahrzeugelement berechnet werden, von dem Antriebsstrangelement und dem Fahrerelement als Eingänge gelesen werden. Die funktionelle Struktur 200 kann auch Pfeile 216 und 218 zwischen den Icons 204, 208 und 210 enthalten, welche anzeigen, dass die von dem Antriebsstrangelement berechneten Ausgaben von dem Fahrzeugumgebungselement und dem Steuer- und/oder Regelelement als Eingänge gelesen werden. Die Daten können physikalische Größen repräsentieren, wie etwa Druck, Temperatur, Spannung, etc., Steuer- und/oder Regelsignale und Sensorsignal, wie etwa Videostreams, Radarsignale, etc., sowie andere Daten. Die Form der zwischen Elementen des High-Level-Systemdesigns 128 ausgetauschten Daten kann abhängig von den Modellkomponenten, die verwendet werden, um die jeweiligen Elemente zu implementieren, und der Co-Simulations-Partitionierung des Designs 128 variieren. Beispielsweise können die Daten für eine Modellkomponente in Form von zeitlich variierenden Signalen sein. Für andere Modellkomponenten mögen die Daten in Form von Nachrichten, Ereignissen, Energieströmen, zum Beispiel in der Form von Durch- und Quervariablen, Signalen, wie etwa zeitbasierten Signalen, Tokenfluss, Datenfluss, Entitätsfluss, und Variablen mit geteiltem Zugriff. Zur Vereinfachung der Beschreibung werden die zwischen den Modellkomponenten ausgetauschten Daten hierin als zeitlich variable Signale beschrieben, wie etwa die Signale, die in der Simulink® modellbasierten Designumgebung definiert sind. Es sei jedoch verstanden, dass anstatt von Signalen andere Formen von Daten ausgetauscht werden können. Weiter sei verstanden, dass auch wenn in der Zeichnung unidirektionale Pfeile gezeigt sind, Daten auch über bidirektionale und ungerichtete Verbindungen ausgetauscht werden können.
Wie beschrieben können die Icons 202-210 Platzhalter für ausführbare Modellkomponenten sein. Das High-Level-Systemdesign 128 kann unter anderem beispielsweise ein Uniform Modeling Language (UML) Diagramm, ein Systems Modeling Language (SysML) Diagramm oder eine AUTomotove Open System Architektur (AUTOSAR) Spezifikation sein. In anderen Ausführungsformen kann einer oder können mehrere der Icons 202-210 ausführbare Modellkomponenten eines bestimmten SoftwareSimulationswerkzeugs repräsentieren. Beispielsweise können in einigen Implementierungen ein oder mehrere der Icons 202-210 Modellreferenzblöcke, Subsysteme, Virtual Instruments (VIs) und/oder Varianten der Simulink modellbasierten Designumgebung, Functional Mock-up Units (FMUs), Dynamische Link Libraries (DLLs), etc. sein. In einigen Ausführungsformen kann das High-Level-Systemdesign 128 textlich definiert sein.
Die funktionelle Struktur 200 kann auf einer Anzeige einer Datenverarbeitungsvorrichtung, wie etwa einem Arbeitsplatzrechner, einem Laptop, einem Tablet, etc. dargestellt werden. Beispielsweise kann die funktionelle Struktur 200 in einem Modelleditorfenster 220 dargestellt werden. Das Modelleditorfenster 220 kann eine Vielzahl von Benutzerschnittstellenelemente und/oder Fensterelemente (Widgets) beinhalten, von denen wenigstens einige von einem Benutzer bedient werden können, um ein High-Level-Systemdesign zu konstruieren, zu editieren und zu speichern, und um das Modellpartitionierungswerk 108 anzuweisen, aus dem High-Level-Systemdesign 128 automatisch ein Modell zu realisieren, neben anderen Operationen. Beispielsweise kann das Modelleditorfenster 220 einen Menübalken 222, einen Werkzeugbalken 224 und ein Canvas 226 enthalten. Der Menübalken 222 kann eine Vielzahl von Befehlen enthalten, und die Befehle können in Drop-Down Kategorien organisiert sein, wie etwa Datei, Editieren, Ansicht, Anzeige, etc. Der Werkzeugbalken 224 kann eine Vielzahl von graphischen Befehlsknöpfen beinhalten, um häufig verwendet Befehle auszuführen. Beispielsweise kann der Werkzeugbalken 224 unter anderem einen Öffnen Knopf 228, einen Speichern Knopf 230 und einen Partition Knopf 232 beinhalten.
Das High-Level-Systemdesign 128 kann implementiert sein in der Form von einem oder mehreren Objekten, Dateien oder anderen Datenstrukturen, die im Speicher gespeichert sind. Die Integrationsplattform 102 kann konfiguriert sein, um das High-Level-Design 128 zu öffnen und die funktionelle Struktur 200 zu verstehen.
Beispielhafte Integrationsplattformen beinhalten die MATLAB® Sprache/Programmierumgebung und die Simulink® Simulationsumgebung, beide von The MathWorks, Inc. aus Natick, Massachusetts, sowie das Simscape™ System für physikalische Simulationen, das SimEvent® Simulationswerkzeug für diskrete Ereignisse und das Stateflow® Zustandsdiagramm, ebenfalls von The MathWorks, Inc. Die MATLAB Sprache/Programmierumgebung ist eine mathematikorientierte textliche Programmierumgebung. Die Simulink Simulationsumgebung ist eine auf Blockdiagrammen basierte Entwurfsumgebung zum Modellieren und Simulieren von Systemen, wie etwa physikalischen Systemen. Die MATLAB Umgebung und die Simulink Umgebung stellen eine Anzahl von High-Level-Merkmalen bereit, welche die Entwicklung und Untersuchung von Algorithmen ermöglichen, und die Simulation und das modellbasierte Design unterstützen, einschließlich spätes Binden oder dynamische Typzuweisung, im Gegensatz zu einer spätes Binden unterstützenden Sprache oder einer dynamisch typisierten Sprache/Umgebung, Matrix-basierte Operationen, Inferieren von Datentypen, Inferieren von Abtastzeit(en) und Inferieren der Ausführungsreihenfolge, neben anderen.
Es sei verstanden, dass die funktionelle Struktur 200 von 2 lediglich zur Veranschaulichung gedacht ist, und dass das High-Level-Systemdesign 128 auf andere Weisen repräsentiert oder dargestellt werden kann. Beispielsweise kann das High-Level-Systemdesign 128 textlich anstatt graphisch dargestellt werden.
Identifikation alternativer Modellkomponenten zum Erstellen eines Modells
Die Menge 104 von Modellkomponenten kann Modellkomponenten enthalten, die entworfen oder konfiguriert sind, zum Beispiel von unterschiedlichen Benutzern derselben oder von unterschiedlichen Organisationen, zur Ausführung durch eine Anzahl unterschiedlicher Softwaresimulationswerkzeuge und/oder durch bestimmte Ausführungs-Engines und/oder Löser eines Softwaresimulationswerkzeugs. Beispielhafte Softwaresimulationswerkzeuge beinhalten die MATLAB® Sprache/Programmierumgebung, die Simulink® Simulationsumgebung, das Simscape™ System für physikalische Simulationen, das SimEvent® Simulationswerkzeug für diskrete Ereignisse, das Stateflow® Zustandsdiagrammwerkzeug, die CarMaker Fahrzeugtestplattform der IPG Automotive GmbH aus Karlsruhe, Deutschland, die GT-SUITE Simulationsumgebung von Gamma Technologies, LLC aus Westmont, Illinois, die COMSOL Multiphysik-Simulationssoftware von COMSOL AB aus Stockholm, Schweden, die ASCET-DEVELOPER Anwendungssoftware von ETAS GmbH in Stuttgart, Deutschland, die Simulia und Abaqus Simulationsprodukte von Dassault Systemes Simulia Corp. aus Velizy-Villacoublay, Frankreich, das SolidThinking Activate Produkt von Altair Engineering, Inc., aus Troy, Michigan, die ANSYS Simulationssoftware von Ansys, Inc., aus Canonsburg, Pennsylvania, die Siemens PLM Software von Siemens AG in Berlin, Deutschland, die Simulationswerkzeuge von MSC Software Corp. aus Newport Beach, Kalifornien, das LabVIEW virtuelle Instrumentensystem von National Instruments, Inc., aus Austin, Texas, das Saber Simulationswerkzeug von Synopsys, Inc., aus Mountain View, Kalifornien, und die Virtuoso® Entwurfsplattform von Cadence Design Systems, Inc., aus San Jose, Kalifornien, unter anderen.
Eines oder mehrere der Simulationswerkzeuge können eine deklarative Sprache implementieren und/oder unterstützen. Eine deklarative Sprache ist eine Sprache, welche die Logik einer Berechnung ausdrückt, ohne deren Kontrollfluss zu beschreiben. Eine deklarative Sprache mag beschreiben, was ein Programm in Begriffen der Problemdomäne erreichen muss, anstatt zu beschreiben, wie dies zu erreichen ist als eine Reihenfolge der Primitive der Programmiersprache. In einigen Fällen kann eine deklarative Sprache einfache Zuweisung implementieren, in welcher Variablen einmal und nur einmal zugewiesen werden. Beispiele deklarativer Sprachen beinhalten die Simulink® modellbasierte Designumgebung von The MathWorks, Inc. aus Natick, Massachusetts, die Modelica Simulationssprache von der Modelica Association, das Lab VIEW graphische Programmiersystem von National Instruments Corp., Hardware Description Language (HDL), die Prolog Sprache und die Haskell Sprache, neben anderen. Das Verhalten von zumindest einigen der Modellkomponenten kann rechnerische Implementierungen beinhalten, die implizit durch eine deklarativen Sprache definiert sind.
Für ein gegebenes Element des High-Level-Systemdesigns 128 kann es eine Anzahl an unterschiedlichen Modellkomponenten aus der Menge 104 geben, welche das gegebene Element modellieren können. Jede dieser Modellkomponenten kann einen alternativen Weg repräsentieren, das Element zu simulieren. Dementsprechend kann es eine Teilmenge von Modellkomponenten geben, welche das Fahrzeugelement modellieren, eine andere Teilmenge von Modellkomponenten, welche das Antriebsstrangelement modellieren, und so weiter. In einigen Fällen kann eine gegebene Modellkomponente mehrere Elemente des High-Level-Systemdesigns 128 modellieren, oder mehrere Modellkomponenten können ein einzelnes Element des Designs 128 modellieren. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann die Modellkomponenten, die in der Menge 104 enthalten sind, evaluieren und die Teilmenge der Modellkomponenten identifizieren, welche die verschiedenen Elemente des High-Level-Systemdesigns 128 modellieren. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auch Attribute der identifizieren, alternativen Modellkomponenten erhalten. Beispielsweise können zumindest einige Modellkomponenten in einer oder in mehreren Bibliotheken gespeichert sein, zum Beispiel einer Simulationsumgebung, und alternative Modellkomponenten, die als Varianten identifiziert sind. Eine Beispielhafte Bibliotheks- und Variantenfunktionalität ist in dem Simulink User's Guide (The MathWorks, Inc., März 2017) beschrieben, welcher hiermit durch Bezugnahme in Gänze aufgenommen ist.
3 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation 300 des High-Level-Systemdesigns 128 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die graphische Repräsentation 300 zeigt die Teilmenge von Modellkomponenten, die aufgefunden wurden, um die Elemente des High-Level-Systemdesigns 128 zu modellieren. Beispielsweise kann das Fahrzeugumgebungselement durch zwei alternative Modellkomponenten simuliert werden, die bei dem Icon 208 durch die Blöcke 302 und 304 mit Bezeichnung ‚A‘ und ‚B‘ repräsentiert sind. Das Steuergerätelement kann durch vier alternative Modellkomponenten simuliert werden, die bei dem Icon 210 durch die Blöcke 306-309 mit Bezeichnung ‚C‘, ‚D‘, ‚E‘ und ‚F‘ repräsentiert sind. Das Antriebsstrangelement und das Fahrerelement können jeweils durch zwei alternative Modellkomponenten simuliert werden, die bei den Icons 204 und 206 durch die Blöcke 310, 312, 314 und 316, mit Bezeichnung ‚G‘, ‚H‘, ‚I‘ und ‚J‘ repräsentiert sind. Das Fahrzeugelement kann durch drei alternative Modellkomponenten simuliert werden, die bei dem Icon 202 durch die Blöcke 318-320 mit Bezeichnung ‚K‘, ‚L‘ und ‚M‘ repräsentiert sind. In einigen Ausführungsformen kann die Integrationsplattform 102 die graphische Repräsentation 300 zum Beispiel auf dem Modelleditorfenster 220 präsentieren, anstelle von oder zusätzlich zur Funktionsstruktur 200.
In einigen Ausführungsformen können zumindest einige der Modellkomponenten, die in der Menge 104 enthalten sind, zugeordnete Metadaten aufweisen. Die Metadaten können eine Beschreibung oder Charakterisierung des Systems enthalten, das durch die jeweilige Modellkomponente simuliert wird, zum Beispiel Fahrzeugdynamik, Antriebsstrang, Fahrer, elektronisches Steuergerät (ECU), etc. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auf diese Metadaten Zugriff haben und diese analysieren, um die Modellkomponenten zu identifizieren, die ein gegebenes Element des High-Level-Systemdesigns 128 simulieren können. Beispielsweise kann die Plattform nach einer Modellkomponente suchen, die eine schnelle Simulationszeit, geringe Speichernutzung, aber mit einer geringeren Präzision, aufweist. In anderen Szenarien mag die Plattform nach einer Modellkomponente hoher Präzision mit einem höheren Bedarf an Rechnerressourcen suchen.
In einigen Ausführungsformen können die Metadaten einem Codierstandard entsprechen, wie etwa dem eXtensible Markup Language (XML) Standard, und das Co-Simulationskomponenten-Entdeckungswerk 118 kann konfiguriert sein, derartige XML Dateien zu lesen.
Die alternativen Modellkomponenten, welche ein gegebenes Element des High-Level-Systemdesigns 128 simulieren, können in unterschiedlichen Formen vorliegen und können unterschiedliche Eigenschaften und/oder Attribute aufweisen. Eine Eigenschaft einer Modellkomponente ist deren Simulationspräzision, was auch einfacher als Präzision bezeichnet werden kann. Simulationspräzision bezieht sich auf die numerische Genauigkeit, mit der eine Modellkomponente das Verhalten und/oder die Operation des Elemente oder des Systems, das modelliert wird, simuliert. Simulationspräzision kann grob kategorisiert werden als geringe Simulationspräzision, mittlere Simulationspräzision und hohe Simulationspräzision. Ein Modell mit geringer Simulationspräzision zum Beispiel kann vereinfachende Annäherungen und Annahmen treffen, wie etwa die Abwesenheit von Luftwiderstand, eine kleine Anzahl an Zuständen eines Zustandsautomaten, nur eine kleine Anzahl an Freiheitsgraden, Nachschlagtabellen („Lookup Table“, LUT) mit nur wenigen Datenpunkten, lineares Modellieren, reduzierte Ordnung, mit Daten- und/oder Merkmalskomprimierung und so weiter. Ein Modell mit geringer Simulationspräzision kann ein Modell sein, das mittels eines Algorithmus des maschinellen Lernens gelernt wurde, wie etwa logistische Regression, neuronales Netzwerk und so weiter. Andererseits mag ein Modell mit hoher Simulationspräzision Luftwiderstand berücksichtigen, über viele Zustände für einen Zustandsautomaten verfügen, viele Freiheitsgrade widerspiegeln, LUTs mit vielen Datenpunkten beinhalten und so weiter. Ein Modell mit mittlerer Simulationspräzision kann hinsichtlich der Fähigkeit, das Verhalten und/oder die Operation des modellierten Systems akkurat zu simulieren, zwischen ein Modell mit geringer Präzision und ein Modell mit hoher Präzision fallen.
Eine weitere Eigenschaft einer Modellkomponente ist deren Modellpräzision. Die Modellpräzision bezieht sich auf den Grad oder das Ausmaß, zu dem eine Komponente das System, das modelliert wird, physikalisch repräsentiert. Die Modellpräzision kann grob auch als geringe Modellpräzision, mittlere Modellpräzision und hohe Modellpräzision kategorisiert werden. Es sei beispielsweise angenommen, dass das System, das modelliert wird, ein Automobil ist. Eine Modellkomponente mit geringer Präzision des Automobils mag nur ein Radelement enthalten. Eine Modellkomponente mit mittlerer Präzision des Automobils mag zwei Radelemente enthalten. Eine Modellkomponente mit hoher Präzision mag vier Radelemente enthalten, wie das Automobil, sowie auch andere Elemente, welche andere Teile des Automobils repräsentieren. Die Modellkomponente mit hoher Präzision mag den physikalischen Eigenschaften des Automobils besser ähnelt als im Vergleich die Modellkomponenten mit mittlerer und geringer Präzision. Abhängig von der bzw. den Eigenschaft(en) des Automobils, die für einen Benutzer von Interesse ist bzw. sind, zum Beispiel die Beschleunigung, mag eine Modellkomponente mit geringer bis mittlerer Präzision genauso akkurat sein wie eine Modellkomponente mit hoher Präzision. In einigen Implementierungen kann ein Benutzer eine Modellkomponente mit hoher Präzision ausführen, um Parameter und Parameterwerte zu identifizieren, die in einer numerischen Simulation des Automobils mit hoher Genauigkeit resultieren. Diese Parameterwerte können dann mit einer Modellkomponente mit einer geringen oder mittleren Präzision verwendet werden, um eine ähnliche numerische Genauigkeit zu erzielen, aber mit der Modellkomponente mit geringer oder mittlerer Präzision. In anderen Ausführungsformen können Parameter und Parameterwerte unter Verwendung von experimentellen Daten identifiziert werden.
Eine weitere Eigenschaft einer Modellkomponente ist die Speichernutzung. Speichernutzung kann sich auf den Betrag von Speicherressourcen, wie etwa Speicher mit wahlfreiem Zugriff (RAM), einer Datenverarbeitungsmaschine beziehen, die erforderlich sind, um die Modellkomponente auszuführen. Beispielsweise mag eine Modellkomponente in der Form eines Blockdiagramms mit hunderten von Blöcken, welche jeweils ein dynamisches System implementieren, und vielen LUTs mit großen Anzahlen an Datenpunkten, um intermediäre Ergebnisse zu bestimmen, signifikante Speicherressourcen verbrauchen. Ein anderes Modell, das nur einige wenige Blöcke aufweist und welches Funktionen statt LUTs verwendet, um intermediäre Ergebnisse verwendet, mag weniger Speicherressourcen verbrauchen.
Eine nochmals weitere Eigenschaft einer Modellkomponente ist die Ausführungsgeschwindigkeit. Ausführungsgeschwindigkeit kann sich auf die physische Zeit beziehen, die erforderlich ist, um ein Modell auszuführen. Beispielsweise mag, abhängig von den Prozessorressourcen der Maschine, auf welcher es ausgeführt wird, ein Modell, das tausende von Blöcken enthält, viele Stunden oder gar Tage erfordern, um ausgeführt zu werden. Im Gegensatz dazu mag ein Modell, das eine kleine Anzahl von Blöcken enthält, zum Beispiel einige zehn Blöcke, in Sekunden oder schneller ausgeführt werden.
Eine weitere Eigenschaft einer Modellkomponente ist die Toleranz. In einigen Ausführungsformen mag ein oder mögen mehrere Löser mit variable Schrittweite Standardsteuertechniken verwenden, um den lokalen Fehler zu jedem Zeitschritt zu überwachen. Während jedem Zeitschritt können die Löser die Zustandswerte am Ende des Schritts berechnen und einen lokalen Fehler bestimmen - den geschätzten Fehler dieser Zustandswerte. Die Löser können dann den lokalen Fehler mit einem akzeptablen Fehler vergleichen, welcher eine Funktion von sowohl einer relativen Toleranz (rtol) und einer absoluten Toleranz (atol) sein kann. Wenn der lokale Fehler größer als der akzeptable Fehler für irgendeinen der Zustände ist, können die Löser die Schrittweite verringern und es noch einmal versuchen. Die relative Toleranz kann den Fehler relative zur Größe jedes Zustands messen. Die relative Toleranz mag einen Prozentsatz des Zustandswerts repräsentieren. Eine standardmäßig voreingestellte relative Toleranz von 1e-3 bedeutet, dass der berechnete Zustand auf 0,1% genau ist. Die absolute Toleranz kann ein Schwellwert sein, der einen akzeptablen Fehler repräsentiert, wenn der Wert des gemessenen Zustands sich null nähert. Eine Modellkomponente kann einen globalen absoluten Toleranzwert haben, der für alle Zustände in der Modellkomponente gilt. Der globale absolute Toleranzwert kann vom Benutzer einstellbar sein. Mit dem Fortschreiten der Simulation der Modellkomponente kann sich die absolute Toleranz für jeden Zustand zurücksetzen auf den maximalen Wert, den der Zustand bisher angenommen hat, multipliziert mit der relativen Toleranz für diesen Zustand. Absolute Toleranzwerte können auch für einige Modellelemente spezifiziert werden, zum Beispiel Blöcke, wie etwa die Integrator-, Zustandsraum- und Nullpol-Blöcke der Simulink® modellbasierten Designumgebung. Eine absolute Toleranz, die für einen Block spezifiziert ist, mag die globale absolute Toleranz, die für die Modellkomponente gesetzt ist, überstimmen. Ein Toleranzwert der Modellkomponente kann daher bestimmen, wie genau ein Integrationsergebnis einer Modellkomponente ist.
Es sei verstanden, dass für die Modellkomponenten andere Eigenschaften spezifiziert sein können, wie etwa Frequenzgang, Berechnungskomplexität, ob die Komponente Jacobi-Matrizen verwendet, ob die Komponente Massenmatrizen zur Simulation akausaler physikalischer Systeme verwendet, und Softwarekosten.
Softwaresimulationswerkzeuge können auch unterschiedliche Eigenschaften und/oder Attribute aufweisen. Beispielsweise ist eine Eigenschaft eines Simulationswerkzeug oder einer Suite von Simulationswerkzeugen die Codegenerierung. Das heißt, einige Simulationswerkzeuge und/oder einige Versionen eines Simulationswerkzeugs können die Generierung von Code entweder durch das Werkzeug selbst oder mittels einem verwandten Werkzeug, wie etwa einem verwandten Codegenerator, unterstützen. Weiterhin mögen die Simulationswerkzeuge, welche Code für Modellkomponenten generieren können, nur in der Lage sein, Code zu generieren, der bestimmten Programmiersprachen entspricht. Beispielhafte Programmiersprachen beinhalten Ada, Basic, C, C++, C#, SystemC, FORTRAN, VHDL, Verilog, einen lieferantenspezifischen oder zielspezifischen HDL Code, wie etwa Xilinx FPGA Bibliotheken, Assemblercode, etc. Andere Eigenschaften und/oder Attribute von Softwaresimulationswerkzeugen beinhalten Kommunikationsoverhead zwischen Anwendungen/Prozessen, Startup/Shutdown Ausführungskosten und Prozessor- und Speicherverbrauch, neben anderen.
Aufstellen von Zielen
In einigen Ausführungsformen kann ein oder können mehrere der Ziele 130 zur Realisierung einer Implementierung eines Simulationsmodells von einem Benutzer spezifiziert werden.
4 ist eine schematische Darstellung einer beispielhaften graphischen Affordanz 400 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die graphische Affordanz 400 kann in Form einer graphischen Benutzerschnittstelle (GUI) implementiert sein, die von einem Entwickler verwendet werden kann, um Werte für ein oder mehrere der Ziele 130 einzustellen. Die Integrationsplattform 102 kann die spezifizierten Werte erhalten. Wie beschrieben kann die Integrationsplattform 102 die Werte der Ziele 130 zusammen mit zusätzlicher Information verwenden, um das Modell 142 für das High-Level-Systemdesign 128 automatisch zu verwirklichen.
Die GUI 400 kann eine Vielzahl von Elementen zum Einstellen von Werten für die Ziele 130 beinhalten. Beispielsweise kann die GUI 400 ein Element 402 beinhalten, das eine Dateneingabebox 404 aufweist, über welche ein Wert für ein Ziel Präzision eingestellt werden. Die GUI 400 kann weiter ein anderes Element 406 beinhalten, das eine Dateneingabebox 408 aufweist, über welche ein Wert für ein Ziel Ausführungsgeschwindigkeit eingestellt werden kann. Die GUI 400 kann ein nochmals anderes Element 410 beinhalten, das eine Dateneingabebox 412 aufweist, über welche ein Wert für ein Ziel Speichernutzung eingestellt werden kann.
Ein Benutzer kann gewünschte Werte für die Ziele 130 spezifizieren, indem er oder sie diese Werte in die entsprechenden Dateneingabeboxen 404, 408 412 eingibt. In einigen Ausführungsformen können die Werte in Form von Gewichten sein, die als Prozentwerte angegeben sind. Der Benutzer kann zum Beispiel ein Gewicht von 40% für das Ziel Präzision, ein Gewicht von 30% für das Ziel Ausführungsgeschwindigkeit und ein Gewicht von 30% für das Ziel Speichernutzung eingeben. Es mag der Fall sein, dass die Summe der Gewichte gleich 100% ist.
Es sei verstanden, dass die GUI 400 als beispielhaft gedacht ist. Beispielsweise können in einigen Implementierungen andere graphische Affordanzen und/oder Kommandozeilenschnittstellen (CLIs) verwendet werden, die zusätzliche und/oder andere Ziele haben. Ein weiteres Ziel mag angeben, dass das realisierte Modell aus Modellkomponenten erzeugt werden soll, für welche Code, der einer bestimmten Programmiersprache entspricht, wie etwa C++ oder HDL Code, erzeugt werden kann. Dieses Ziel mag verwendet werden, wenn der Benutzer wünscht, das realisierte Modell mittels Testen mit Hardware-in-the-Loop (HIL) oder Software-in-the-Loop (SIL) zu evaluieren.
In einigen Ausführungsformen können die Ziele in anderen Formen als Gewichtungen und/oder Prozentwerten spezifiziert werden.
In einigen Ausführungsformen kann ein oder können mehrere der Ziele programmtechnisch bestimmt werden.
Eine beispielhafte Zielfunktion verwendet eine gewichtete Summe aller Modellkomponenten. Beispielsweise kann das Gesamtziel des integrierten Modells in der Form einer gewichteten Summe der Toleranz jeder Komponente, die relativ oder absolut sein kann, der Ausführungszeit und des Speicherverbrauchs sein. Diese Gewichtungen könnten von Benutzern spezifiziert sein oder könnten geschätzt werden aus einem Satz Trainingsdaten unter Verwendung von Techniken des maschinellen Lernens. Eine derartige Zielfunktion kann folgende Form annehmen: $E = \sum_{i = 1}^{N c} (λ_{i} * T o l_{i} + α_{i} * C_{i} + β_{i} * M_{i})$
wobei

Nc die Gesamtzahl an Modellkomponenten, die analysiert werden, ist;
λ das Gewicht für die Toleranz der Modellkomponente ist,
Tol die Toleranz der Modellkomponente ist;
α das Gewicht für die Rechenzeit der Modellkomponente ist,
C die Rechenzeit der Modellkomponente ist,
β das Gewicht für die Speichernutzung der Modellkomponente ist, und
M die Speichernutzung der Modellkomponente ist.

Eine Zielsetzung mag es sein, für jedes i eine Kandidatenkomponente zu wählen. Beispielhafte Tol Verte sind 1E-3, 1E-3. Werte C könnten normalisiert sein (0,1 bedeutet schnell und 1 bedeutet langsam). Werte M könnten ebenfalls normalisiert sein (0,1 bedeutet eine geringe Speichernutzung und 1 bedeutet eine hohe Speichernutzung). Die drei Gewichtungskoeffizienten λ, α und β können ebenfalls normalisiert sein.
In einigen Ausführungsformen mag die Zielfunktion beispielsweise die Form eines harmonischen oder geometrischen Mittels annehmen, abhängig von den gewünschten Zieleigenschaften.
Das Optimierungsproblem, das von der Zielfunktion gelöst wird, kann ein gemischtes diskret-kontinuierliches Optimierungsproblem sein, was Herausforderungen stellen kann, wie etwa, einen großen Lösungsraum zu durchsuchen und lokale Minima aufzufinden oder zu erhalten. Die Zielfunktion kann einen oder mehrere Algorithmen zur nichtlinearen Optimierung unter Randbedingungen verwenden, wie unter anderem etwa ein Trust Region Reflective Algorithmus, ein Active Set Algorithmus, ein sequentieller Quadratische Programmierung (SQP) Algorithmus oder ein Innerer-Punkt-Algorithmus.
Weitere Randbedingungen, welche der Zielfunktion auferlegt werden können, beinhalten die Größe des Such- bzw. Lösungsraums, eine Regularisierung, um die Varianz zu verringern, und die Anzahl an Ordnungen in der Zielfunktion. Ein oder mehrere dieser Randbedingungen mögen einstellbar sein, zum Beispiel durch einen Benutzer über eine oder über mehrere Benutzerschnittstellen.
Entdeckung von Simulationsmodellkomponenten
In einigen Ausführungsformen kann in den XML Daten einer Modellkomponente Information über die Präzision, Speichernutzung, Ausführungsgeschwindigkeit oder andere Ziele der Komponenten enthalten sein. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auf die Metadaten zugreifen und diese Information extrahieren.
5 ist eine schematische Darstellung von beispielhaften Metadaten 500 für eine Modellkomponente in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die Metadaten 500 können mit der Modellkomponente, die dem Block 302 (3) mit Bezeichnung ‚A‘ entspricht, assoziiert sein. Die Metadaten 500 können einen Eintrag 502 enthalten, welcher die Co-Simulationskomponente identifiziert, zum Beispiel als Modellkomponente ‚A‘. Die Metadaten 500 können einen Eintrag 504 enthalten, welcher eine Beschreibung der Modellkomponente bereitstellt. Die Beschreibung kann angeben, dass die Modellkomponente ein Fahrzeug simuliert. Die Metadaten 500 kann Ausführungseigenschaften für Modellkomponente enthalten. Beispielsweise können die Metadaten 500 einen Eintrag 506 für die Präzision, zwei Einträge 507 und 508 für die Speichernutzung, zum Beispiel durchschnittliche und maximale Speichernutzung, und zwei Einträge 509 und 510 für die Ausführungsgeschwindigkeit, zum Beispiel physische Ausführungszeit und Simulationsausführungszeit, enthalten.
In einigen Ausführungsformen können die Werte für die Präzision, die Speichernutzung und die Ausführungsgeschwindigkeit von einem Benutzer bestimmt werden und manuell in die Metadaten eingefügt werden. Beispielsweise können Werte von dem Autor, welcher die Modellkomponente erstellt hat, empirisch bestimmt werden. Wie angegeben, weist die Modellkomponente, welche durch den Block 302 repräsentiert wird, einen Präzisionswert von ‚2‘, einen mittleren Speichernutzungswert von 20 Megabytes (MB), eine maximale Speichernutzung von 40MB, eine Wert der Ausführungsgeschwindigkeit in physischer Zeit von 2 Sekunden (zum Beispiel auf einem Benchmark Prozessor, wie etwa einem Intel Core i7), und einer Simulationsausführungszeit pro Schritt von 0,1.
Die Metadaten 500 können Information betreffend dem Softwaresimulationswerkzeug enthalten, das benötigt wird, um die Modellkomponente, di durch den Block 302 repräsentiert wird, zu simulieren, zum Beispiel auszuführen. Die Metadatendaten 500 können beispielsweise drei Einträge 512-514 enthalten, welche den Namen des Werkzeugs angeben, zum Beispiel Simulink, die Version des Werkzeugs, zum Beispiel Release 2018a, und das Betriebssystem, zum Beispiel Linux, 64-bit. Soweit das Softwarewerkzeug mehrere Löser unterstützt, kann die Information betreffend dem Softwarewerkzeug auch Information über den partikulären Löser beinhalten. Beispielsweise können die Metadaten 500 drei Einträge 516-518 enthalten, welche den Typ und die Toleranz des Lösers angeben. Werte können spezifiziert sein durch den Autor, der die Modellkomponente erstellt hat. Beispielsweise kann der Block 302 einen kontinuierlichen Löser Runge-Kutta mit variable Schrittweite (ODE45) verwenden, mit einer relativen Toleranz von 10^-6 und einer absoluten Toleranz von 10^-3. Hätte die Modellkomponente einen Löser mit fester Schrittweite verwendet, dann mag eine Simulationszeitschrittgröße, zum Beispiel 0,01 Sekunden, spezifiziert sein, anstelle von relative und/oder absoluter Toleranz.
Die Metadaten 500 können weiter Information betreffend der Schnittstelle der Modellkomponente enthalten. Beispielsweise können die Metadaten 500 Einträge 520-524 für den oder die Ausgänge, Eingänge, Zustände und Ableitungen der Komponente enthalten. Wie gezeigt, beinhaltet die Modellkomponente einen Ausgang mit Namen ‚y‘, einen Eingang mit Namen ‚u‘, einen Zustand mit Namen ‚x‘ und zwei Ableitungen mit Namen ‚dy/du‘ und ‚dx/du‘.
In einigen Ausführungsformen können die Metadaten 500 auch Attribute für die Ausgabe(n), Eingabe(n), Zustand bzw. Zustände und Ableitung(en) enthalten, wie etwa Datentyp, nomineller oder Defaultwert, Minimum und Maximum Bereiche, Signalform, Größe, ob der Wert real oder komplex ist, Einheiten etc. In einigen Implementierungen kann die Schnittstelleninformation auch die Jacobi-Matrix enthalten.
Es sei verstanden, dass 5 lediglich zu Zwecken der Beschreibung gedacht ist und dass zusätzliche, weniger oder mehr Information enthalten sein kann.
Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auf Metadaten für die anderen alternativen Modellkomponenten zugreifen, die für das High-Level-Systemdesign 128 identifiziert wurden, und kann Parameter aus diesen Metadaten extrahieren. Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 die folgenden Parameter für die Modellkomponente extrahieren, welche dem Block 304 (3) mit Bezeichnung ‚B‘ entspricht:

Ausführungseigenschaften
- Präzision: 10
- Speichernutzung: 100MB
- Ausführungsgeschwindigkeit: 5 Sekunden
Softwarewerkzeug
- Anwendungsprogramm: GT SUITE
- Version: Release 2017
- Betriebssystem: Windows, 64-bit
Löser
- Typ: Löser (ODE113) Adams-Bashforth-Moulton PECE kontinuierlich mit variabler Schrittweite
- Relative Toleranz: 10^-8
- Absolute Toleranz: 10^-5
Schnittstelle
- Ausgabe: y
- Eingabe: u
- Zustand: x
- Ableitung Ausgabe-Eingabe: dy/du
- Ableitung Zustand-Eingabe: dx/du

Das Co-Simulationskomponenten-Entdeckungswerk 118 kann die folgenden Parameter für die Modellkomponente extrahieren, welche dem Block 318 mit Bezeichnung ‚K‘ entspricht:

Ausführungseigenschaften
- Präzision: 5
- Speichernutzung: 20MB
- Ausführungsgeschwindigkeit: 1 Sekunde
Softwarewerkzeug
- Anwendungsprogramm: CarMaker
- Version: Release 2016
- Betriebssystem: Windows, 64-bit
Löser
- Typ: Löser (ode1) Euler-Verfahren kontinuierlich mit fester Schrittweite Schrittweite: 0,01
Schnittstelle
- Ausgabe: y
- Eingabe: u
- Zustand: x
- Ableitung Ausgabe-Eingabe: dy/du
- Ableitung Zustand-Eingabe: dx/du

Wie beschrieben können mehrere, alternative Modellkomponenten verfügbar sein, um ein gegebenes Element des High-Level-Systemdesigns 128 zu simulieren, und jede Komponente kann ein Modell dieses Elements sein. Beispielsweise kann für das Antriebsstrangelement eine Modellkomponente ein GT-SUITE Modell sein, während eine andere Modellkomponente für das Antriebsstrangelement ein Simulink Modell sein kann.
Berechnen von Kompensationsparametern
Bei der Co-Simulation können die Daten, die zwischen den Co-Simulationskomponenten ausgetauscht werden, auf Kommunikationsraten in diskreter Zeit beschränkt sein. Dies mag der Fall sein, selbst wenn die Verbindung zwischen zwei Co-Simulationskomponenten mit einer Abtastrate modelliert sein mag, die sich von der Kommunikationsrate in diskreter Zeit, mit welcher Daten ausgetauscht werden, unterscheidet. Die Co-Simulation kann besonders herausfordernd sein, wenn eine Verbindung gedacht ist, mit einer kontinuierlichen Zeit modelliert zu sein (beispielsweise ist die Verbindung als zeitkontinuierlich deklariert). Wie hierin verwendet bezieht zeitkontinuierlich auf eine Verbindung, die gedacht ist, einen Wert zu haben oder zu repräsentieren, der sich kontinuierlich mit der Zeit ändert, der aber tatsächlich durch einen Löser diskretisiert werden mag, um gelöst zu werden. Dieser Wert kann durch einen Löser (zum Beispiel einen subordinären Löser) zu verschiedenen intermediären Punkten innerhalb eines Zeitschritts approximiert werden basierend auf einem numerischen Integrationsschema, um die kontinuierliche Zeit zu approximieren. Eine solche Diskretisierung und Approximation für kontinuierliche Zeit ist getrennt von der Diskretisierung, welche die Co-Simulation in die Verbindung zwischen zwei Co-Simulationskomponenten einführt. Wenn ein solches Modell in einer Co-Simulationsweise ausgeführt wird, mag die Kommunikationsrate für die Verbindung nicht dieselben sein wie die modellierte Abtastrate für die Verbindung (zum Beispiel jene, die modelliert wäre, wenn keine Co-Simulation verwendet würde).
Wie diskutiert kann ein Eingangs- oder Ausgangssignal einer Co-Simulationskomponente, welches deklariert ist, eine modellierte Abtastrate (zum Beispiel eine zeitkontinuierliche Rate oder eine zeitdiskrete Rate) aufzuweisen, in einem Modell diskretisiert werden basierend auf der Kommunikationsrate, welche für das Co-Simulations-Rahmenwerk gesetzt ist. Während das Signal beispielsweise aus der Perspektive eines Benutzers weiterhin ein zeitkontinuierliches Signal ist (zum Beispiel ein Signal, das einen Druck oder eine Spannung darstellt, der bzw. die sich mit der Zeit ändert), wird das Signal, da die Ausführung des Modells in der Co-Simulation auf diskrete Kommunikationszeiten beschränkt ist, nicht, wie vom Benutzer erwartet, als ein zeitkontinuierliches Signal simuliert.
Manchmal kann ein Co-Simulations-Rahmenwerk künstlich Eigenschaften eines Modells ändern, welche die diskreten Kommunikationszeiten zwischen Co-Simulationskomponenten verursachen. Dies kann zu Ungenauigkeiten oder Fehlern/Approximationen in dem simulierten Verhalten des Systems führen. Beispielsweise kann ein Ausgang einer Co-Simulationskomponente künstlich abgetastet und gehalten werden, bevor es an eine andere Co-Simulationskomponente kommuniziert wird. Aufgrund des künstlichen Abtastens und Haltens kann eine Kommunikation von Daten über das Signal zwischen den verbundenen Co-Simulationskomponenten eine zeitdiskrete Kommunikationsrate aufweisen, die sich von der zeitkontinuierlichen modellierten Abtastrate oder der zeitdiskreten modellierten Abtastrate, die für das Signal deklariert ist, unterscheiden. Dieser Unterschied in der Datenkommunikationsrate zwischen Co-Simulationskomponenten und der modellierten Abtastrate (zum Beispiel eine zeitkontinuierliche modellierte Abtastrate oder eine zeitdiskrete modellierte Abtastrate), die für das Signal deklariert ist, kann dazu führen, dass Daten, die von einer Co-Simulationskomponente zu bestimmten Zeitpunkten generiert werden, verloren gehen, nicht verfügbar sind, verzögert werden oder inakkurat sind. Diese Fehler können einen Benutzer verwirren, der ein Signal als zeitkontinuierlich oder zeitdiskret gesetzt hat, wenn das Signal mit einer unterschiedlichen Rate modelliert wird, weil das Modell in einem Co-Simulations-Rahmenwerk ausgeführt wird.
Das Co-Simulationskomponenten-Entdeckungswerk 118 kann automatisch (zum Beispiel unabhängig von Benutzereingaben) ein oder mehrere Diskrepanzen zwischen einer Abtastrate einer Verbindung zwischen zwei der verfügbaren Modellkomponenten 302-320 und der Kommunikationsrate, die eingestellt würde, wenn diese bestimmten Modellkomponenten in dem realisierten Modell enthalten und über eine Co-Simulationspartition hinweg verbunden wären, identifizieren. Darüber hinaus kann das - Entdeckungswerk 118 befinden, dass zwei Modellkomponenten eng gekoppelt sind, was bedeutet, dass deren Dynamiken eng gekoppelt sind und Signale zwischen diesen sich über die Zeit rasch ändern. Das -Entdeckungswerk 118 kann diese Signale identifizieren, und der Prozessor 120 zur Optimierung unter Randbedingungen kann die zwei Modellkomponenten in eine Co-Simulationspartition stecken, anstatt sie in unterschiedliche Partitionen aufzuspalten. Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 automatisch zeitkontinuierliche Signale zwischen zwei der verfügbaren Modellkomponenten identifizieren, welche, wenn sie in dem realisierten Modell enthalten wären, in der Co-Simulation diskretisiert würden. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann Kompensationsparameter berechnen, um eine Kompensation für die durch die Co-Simulation verursachte Ungenauigkeit zu schaffen. Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 die Parameter für einen Kompensator (zum Beispiel einen Algorithmus zum Kompensieren eines Fehlers, der auftritt während der Ausführung eines Modells, welches die zwei Modellkomponenten in unterschiedliche Co-Simulationspartitionen platziert), um den Fehler zu kompensieren. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auch einen Ort für den Kompensator bestimmen, wie etwa zwischen den zwei Co-Simulationskomponenten oder innerhalb einer von diesen. Wenn ein Kompensator zwischen zwei Co-Simulationskomponenten angeordnet wird, kann dies als explizite Kompensation bezeichnet werden, wohingegen wenn ein Kompensator innerhalb einer Co-Simulationskomponente angeordnet wird als implizite Kompensation bezeichnet werden kann.
In einigen Implementierungen kann eine Schnittstellenerweiterung (zum Beispiel eine API Erweiterung) für eine Schnittstelle einer Co-Simulationskomponente bereitgestellt werden, die es erlaubt, dass ein Callback in der Funktionalität der Co-Simulation für implizite Kompensation bereitgestellt wird. In einigen Implementierungen kann die Möglichkeit, eine implizite Kompensation auszuführen, indem ein Kompensator in eine Co-Simulationskomponente eingefügt wird, ein genaueres simuliertes Verhalten liefern, wenn das Modell ausgeführt wird, als mit expliziter Kompensation, bei der der Kompensator außerhalb der Co-Simulationskomponenten eingefügt werden. Beispielsweise kann die Master-Ausführungs-Engine bestimmen, eine implizite Kompensation auszuführen, und den Kompensator in die Co-Simulationskomponente einzufügen, basierend auf einem Bestimmen, dass die Co-Simulationskomponente eine nichtlineare Funktion auf ein Signal anwendet, bevor eine Integrationsfunktion ausgeführt wird.
In einigen Fällen kann die Schnittstelle für eine Co-Simulationskomponente eine Kompensation Callback Funktion bereitstellen, welche es der Master-Ausführungs-Engine ermöglicht, einen Kompensator in die Co-Simulationskomponente einzufügen. In einigen Implementierungen kann eine Sprache/Programmierumgebung oder die Master-Ausführungs-Engine derselben, welche die Schnittstelle für eine Co-Simulationskomponente erzeugt (zum Beispiel wenn die Co-Simulationskomponente erzeugt wird), bestimmen, dass die Co-Simulationskomponente eine nichtlineare Funktion auf das Signal anwendet bevor der Integrationsfunktion. Basierend auf dieser Bestimmung kann die Master-Ausführungs-Engine die Callback Funktion der Schnittstelle hinzufügen und es der Master Ausführung erlauben, die Callback Funktion aufzurufen, um eine implizite Kompensation während der Ausführung auszuführen. Anders gesagt mag die Schnittstelle eine bestimmte Callback Funktion aufweisen, die es erlaubt, dass ein Eingang in die Co-Simulationskomponente an einer bestimmten Stelle von einem Algorithmus transformiert wird. In einigen Implementierungen mag die Schnittstelle die Kompensation Callback Funktion nicht nativ enthalten. In solchen Fällen kann die Kompensation Callback Funktion durch die Master-Ausführungs-Engine und/oder die Integrationsplattform erzeugt und der Schnittstelle hinzugefügt werden, um die Schnittstelle mit der Funktionalität zu versehen, um eine implizite Kompensation auszuführen. Alternativ kann die Schnittstelle für eine Co-Simulationskomponente ursprünglich erzeugt sein, die Fähigkeit der Callback Funktion zu enthalten. In einigen Implementierungen kann eine API Spezifikation für die Schnittstelle einen Indikator (zum Beispiel ein Flag) aufweisen, welcher anzeigt, ob die Kompensation Callback Funktion verfügbar ist. Die Master-Ausführungs-Engine kann dieses Flag abfragen, um zu bestimmen, ob eine implizite Kompensation möglich ist, basierend darauf, ob das Flag anzeigt, dass die Kompensation Callback Funktion verfügbar ist.
Dementsprechend kann während der Ausführung des Modells, wenn die Master-Ausführungs-Engine die Co-Simulationskomponente anweist, einen Zeitschritt auszuführen, die Master-Ausführungs-Engine einen Kompensator inkludieren (zum Beispiel einen Kompensationsalgorithmus) als eine Eingabe in die bestimmte Callback Funktion, wenn die Callback Funktion aufgerufen wird, um die implizite Kompensation auszuführen. Auf diese Weise kann eine Master-Ausführungs-Engine den Fehler korrigieren, der in die Ausführung eines Modells eingeführt wird, das in einer Weise der Co-Simulation ausgeführt wird, unter Verwendung von expliziter Kompensation und/oder impliziter Kompensation.
Das Co-Simulationskomponenten-Entdeckungswerk 118 kann die Modellkomponenten 302-320 analysieren, um Eigenschaften von Eingangs- und Ausgangssignalen zu bestimmen. Die Signaleigenschaften können eine Zeitbereichsdomäne (zum Beispiel ein zeitkontinuierliches Signal, welches eine physische Größe repräsentiert, ein zeitdiskretes Signal, etc.), eine Frequenzbereichsdomäne und/oder vom Benutzer spezifizierte Information (zum Beispiel spezifiziert ein Benutzer ein gleitendes Durchschnittsfilter). Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 die modellierte Abtastrate eines Eingangs- oder Ausgangssignals erhalten basierend auf der modellierte Abtastrate, die für das Signal eingestellt wurde, wenn die jeweilige Modellkomponente erstellt oder kompiliert wurde.
Das Co-Simulationskomponenten-Entdeckungswerk 118 kann Information über die Modellkomponenten auf verschiedene Weisen erhalten. Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 die Modellkomponenten 302-320 über jeweilige Schnittstellen analysieren und Komponenteneigenschaften erhalten. Die Schnittstelle kann eine FMI oder ein S-Funktions-API sein. Die S-Funktions-API beinhaltet eine Aufrufsyntax, die von Systemfunktionen (zum Beispiel S-Funktionen) in der Simulink® modellbasierten Designumgebung verwendet wird, welche eine Interaktion mit der Ausführungs-Engine der Simulink® modellbasierten Designumgebung ermöglichen. Das Co-Simulationskomponenten-Entdeckungswerk 118 kann auch Information über die Modellkomponenten 302-320 mittels einer JavaScript Object Notation (JSON) Schnittstelle erhalten. Zusätzlich oder alternativ kann das Co-Simulationskomponenten-Entdeckungswerk 118 die Information aus einer oder mehreren Dateien (zum Beispiel eXtensible Markup Language (XML) Dateien) für die Modellkomponenten 302-320 erhalten.
Die Information kann Eigenschaften und/oder Fähigkeiten der Modellkomponenten 302-320 angeben, zum Beispiel gekennzeichnet durch Flags oder andere Mechanismen. Beispielsweise kann die Information einen Porttyp anzeigen (zum Beispiel einen Ableitungseingangsport), eine Verwendung von variable Kommunikationsschrittweiten oder eine Signalinterpolation höherer Ordnung oder andere Eigenschaften. Die Schnittstelle für eine Komponente kann Information an das Co-Simulationskomponenten-Entdeckungswerk 118 bereitstellen bezüglich der Eigenschaften der Dateneingabe und/oder -ausgabe der Komponente. Die Eigenschaften der Modellkomponenten 302-320 können eingestellt werden basierend auf einer Benutzereingabe und/oder von einer Co-Simulationsarchitektur (zum Beispiel indem direkt Werte übernommen werden, die in der Architektur eingestellt sind, Analysieren von Rechnerressourcen und setzen von Eigenschaften basierend auf den Fähigkeiten der Rechnerressourcen (zum Beispiel verfügbarer Speicher, Verarbeitungsgeschwindigkeit), etc.).
In einigen Implementierungen kann die Kommunikationsrate für ein Eingangs- oder Ausgangssignal einer Modellkomponente basierend auf einer Benutzereingabe bestimmt werden. In einigen Implementierungen kann die Kommunikationsrate automatisch durch das Co-Simulationskomponenten-Entdeckungswerk 118 bestimmt werden. Beispielsweise kann die Kommunikationsrate auf der Abtastraten, die für die Eingangs- oder das Ausgangssignale oder -ports der Modellkomponenten 302-320 basieren.
In einigen Fällen können Schnittstellen für eine oder mehrere der verfügbaren Modellkomponenten 302-320 beschränkt sein, indem das Co-Simulationskomponenten-Entdeckungswerk 118 nicht in der Lage sein mag, auf Information zuzugreifen, die sich auf den partikulären Inhalt der Modellkomponenten 302-320 bezieht, oder sich auf die Funktionalitäten der Blöcke, die in den Co-Simulationskomponenten enthalten sind, bezieht. Beispielsweise kann das Co-Simulationskomponenten-Entdeckungswerk 118 nur in der Lage sein, über die Schnittstelle auf Information zuzugreifen, die sich auf die Eingänge und Ausgänge von einigen der Modellkomponenten 302-320 bezieht. In einigen Implementierungen kann das Co-Simulationskomponenten-Entdeckungswerk 118 Zugriff auf begrenzte Information haben, wenn die Ausführungs-Engine, die von dem Co-Simulationskomponenten-Entdeckungswerk 118 verwendet wird, sich von der Ausführungs-Engine, die verwendet wird, um eine Modellkomponente in einem Modell auszuführen, unterscheidet.
Weiterhin mögen, während der Ausführung, nur Anweisungen, welche die Modellkomponente anweisen, einen Zeitschritt nach vorne und/oder zurück zu schreiten, einen Zustand zu aktualisieren, einen Zustand wiederherzustellen oder eine andere beschränkte Funktionalität über die Schnittstelle möglich sein. In einigen Implementierungen können einige der Co-Simulationskomponenten 302-320 Functional Mock-Up Units (FMUs) sein, wobei die Rechenoperationen, die auf Daten innerhalb der Komponenten angewandt werden (zum Beispiel Anwenden einer Wurzelfunktion auf das Eingangssignal und danach Anwenden eines Integrators), und die Verbindung zwischen den Rechenoperationen für das Co-Simulationskomponenten-Entdeckungswerk 118 unbekannt oder nicht verfügbar sind.
Beispielsweise kann ein GT-SUITE Modell implementiert sein als eine S-Funktion der Simulink® modellbasierten Designumgebung. Wenn das Co-Simulationskomponenten-Entdeckungswerk 118 die Simulink Ausführungs-Engine nutzt, um Komponenten zu analysieren, mag das Co-Simulationskomponenten-Entdeckungswerk 118 einen beschränkten Zugriff auf den Inhalt des GT-SUITE Modells haben.
Die Information, welche dem Co-Simulationskomponenten-Entdeckungswerk 118 über die Schnittstelle zur Verfügung steht, mag die Rechenoperationen angeben, welche von der Modellkomponente 318 angewandt werden. In einigen Implementierungen kann das Co-Simulationskomponenten-Entdeckungswerk 118 Zugriff auf derartige Information haben, wenn die Ausführungs-Engine, welche von dem Co-Simulationskomponenten-Entdeckungswerk 118 verwendet wird, dieselbe Ausführungs-Engine ist, die verwendet wird, um die Modellkomponente 318 auszuführen. Das Co-Simulationskomponenten-Entdeckungswerk 118 mag jedoch Zugriff auf derartige Information unabhängig davon haben, ob dieselben Ausführungs-Engines und/oder Softwareanwendungswerkzeuge verwendet werden.
Netzwerkressourcenentdeckung
Das Netzwerkentdeckungswerk 114 kann das Computernetzwerk 106 scannen und Information betreffend der Datenverarbeitungsvorrichtungen in dem Computernetzwerk 106 erhalten. Die Information kann Hardware- und Softwareressourcen der Knoten 140a-c umfassen.
6 ist eine schematische Darstellung von beispielhaften Metadaten 600 für den Knoten 140a des Computernetzwerks 106 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das Netzwerkentdeckungswerk 114 kann auf die Metadaten 600 zugreifen und Parameter für den Knoten 140a, der als ‚Host 1‘ identifiziert werden kann, abrufen. Die Metadaten 600 können einen Eintrag 602 umfassen, welcher das Betriebssystem (OS) des Knotens 140a angibt, zum Beispiel Windows, 64-bit. Die Metadaten 600 können einen Eintrag 604 umfassen, welcher die Softwaresimulationswerkzeuge, die auf den Knoten 140a geladen sind, nach Name und Release angibt, zum Beispiel Simulink - Release 2018a, GT SUITE - Release 2017. Die Metadaten 600 können Information über die Prozessorressourcen auf den Knoten 140a beinhalten. Beispielsweise können die Metadaten 600 fünf Einträge 606-610 umfassen, welche den bzw. die Typ(en) von Prozessor(en) angeben, zum Beispiel Intel Core i9, die Prozessortaktrate, zum Beispiel 4,3 GHz, die Anzahl an Prozessorkernen, zum Beispiel 16, Prozessorcachespeicher, zum Beispiel 64 Kibibytes (KiB) pro Kern und die Busgeschwindigkeit, zum Beispiel 8 Gigatransfers pro Sekunde (GT/s). Die Metadaten 600 können auch einen Eintrag 612 für den Hauptspeicher des Knotens enthalten, zum Beispiel 8 Gigabyte (GB) an Speicher mit wahlfreiem Zugriff (RAM), einen Eintrag 614 für den persistenten Speicher des Knotens, zum Beispiel 1 Terabyte (TB), und einen Eintrag 614 für den Typ der Datenkommunikationsverbindung(en), welche von dem Knoten 140a verwendet wird bzw. werden, um auf das Computernetzwerk 106 zuzugreifen, zum Beispiel Gigabit Ethernet.
Das Netzwerkentdeckungswerk 114 kann die folgende Information für die Knoten 140b und 140c des Computernetzwerks 104 erhalten:

Knoten 140b
Host 2
OS: Linux, 64-bit
Softwarewerkzeuge: Simulink Release 2017b, CarMaker Release 2016,
Prozessor
- Typ: Intel i3
- Taktrate: 1,2 GHz
- Anzahl Kerne: 2
- Cachespeicher: 64 KiB pro Kern
- Busgeschwindigkeit: 2,5 GT/s
Speicher: 2 GB
Persistenter Speicher: 500 GB
Datenkommunikation: Fast Ethernet
Knoten 140c
Host 3
OS: macOS 10.13
Softwarewerkzeuge: Simulink Release 2018a, GT Suite Release 2017,
Prozessor
- Typ: Intel i5
- Taktrate: 1,2 GHz
- Anzahl Kerne: 4
- Cachespeicher: 64 KiB pro Kern
- Busgeschwindigkeit: 2,5 GT/s
Speicher: 4 GB
Persistenter Speicher: 500 GB
Datenkommunikation: WiFi 802.11

Geeignete Werkzeuge, die verwendet werden können, um Netzwerkserkennung auszuführen, beinhalten Server/Cluster Managementwerkzeuge und Cloud-Dienste, wie etwa Amazon Web Services von Amazon.com, Inc., aus Seattle, Washington, und Microsoft Azure von Microsoft Corp., aus Seattle, Washington, neben anderen, und Container-verwaltende Werkzeuge, wie etwa Docker von Docker, Inc., aus San Francisco, Kalifornien, und Kubernetes von der Cloud Native Computing Foundation.
Partitionierung des High-Level-Systemdesigns, um ein Modell zu verwirklichen
Auswählen, Aufstellen und Lösen der Zielfunktion
Der Zielfunktionsauswähler 122 kann eine partikuläre Zielfunktion zum Partitionieren des High-Level-Systemdesigns 128, um ein Modell zu realisieren, auswählen. Geeignete Zielfunktionen beinhalten Kostenfunktionen, Energiefunktionen, Belohnungsfunktionen und Nutzenfunktionen. Die Zielfunktion kann ein Problem der Optimierung unter Randbedingungen lösen.
Die Zielfunktion kann repräsentiert werden als:

argmin j(P, C, T, M) unter der Bedingung R(H) > 0 P,C,T,M

argmin für ‚Argument des Minimums‘ steht und eine Zielfunktion ist, welche die Werte der Punkte P, C, T und M bestimmt, für welche die Funktion J() einen verringerten Wert, zum Beispiel einen Minimalwert, annimmt.
P die Partition des High-Level-Systemdesigns 128 ist,
C die Ausgewählten Modellkomponenten sind,
T die Kommunikationsrate zwischen zwei Modellkomponenten ist,
M die Kompensationsparameter sind, und
H die Rechnerressourcen sind, zum Beispiel Prozessor- und Speicherressourcen.

Die Zielfunktion J(P, C, T,M) kann eine Kostenfunktion sein, die aus den vom Benutzer spezifizierten Zielen abgeleitet ist, zum Beispiel eine gewichtete Summe von einem oder mehreren von Präzision, Ausführungsgeschwindigkeit, Speichernutzung und Toleranz.
Eine beispielhafte Funktion ist die MATLAB ‚fmincon‘ Funktion, welche das Minimum einer mit Randbedingungen versehenen nichtlinearen Funktion in mehreren Variablen findet: $[P, C, T, M] = f m i n c o n (J, \dots)$
Die Funktion ‚fmincon‘ ist in dem Optimization Toolbox User's Guide (The MathWorks, Inc., März 2018) beschrieben, hiermit durch Bezugnahme mitaufgenommen.
Das Zielfunktions-Aufstellwerk 124 kann die Zielfunktion mit einer oder mit mehreren harten Randbedingungen konfigurieren. Beispielsweise kann das Simulationswerkzeug zum Ausführen einer bestimmten Modellkomponente nur mit einem Windows Betriebssystem kompatibel sein. Eine Modellkomponente, die von einem Simulationswerkzeug ausgeführt wird, das auf einem anderen Betriebssystem, wie etwa Linux, kann in der Lösung nicht enthalten sein.
Die Präzision, die Ausführungsgeschwindigkeit, die Speichernutzung und die Toleranz können als weiche Randbedingungen bezeichnet werden, da die Zielfunktion danach trachtet, diese Parameter zu minimieren (oder zu maximieren).
Weiterhin kann der Benutzer eine oder mehrere harte Randbedingungen für die Zielfunktion spezifizieren. Beispielsweise mag der Benutzer angeben, dass keine der ausgewählten Modellkomponenten einen bestimmten Typ von Modellelement aufweisen darf, wie etwa einen Merge Block der Simulink® modellbasierte Designumgebung. In diesem Fall kann das Co-Simulationskomponenten-Entdeckungswerk 118 die verfügbaren Modellkomponenten 302-320 analysieren, um zu bestimmen, ob irgendeine von diesen einen Merge Block enthalten. Falls ja, kann das Co-Simulationskomponenten-Entdeckungswerk 118 derartige Co-Simulationskomponenten markieren, und das Zielfunktions-Aufstellwerk 124 kann diesen markierten Modellkomponenten hohe Gewichte zuweisen oder diese aus der Zielfunktion entfernen. Auf ähnliche Weise mag ein Benutzer angeben, dass er oder sie nur über Lizenzen zum Ausführen einer bestimmten Anzahl von Instanzen eines gegebenen Simulationswerkzeugs verfügt. Das Zielfunktions-Aufstellwerk 124 kann die Zielfunktion so parametrieren, dass die Lösung die von dem Benutzer erhaltene Randbedingung der Lizenzen erfüllt.
Weiter kann ein Benutzer ein oder mehrere Elemente des High-Level-Systemdesigns 128 an bestimmte Modellkomponenten und/oder Simulationswerkzeuge binden. Der Benutzer mag zum Beispiel angeben, dass das Steuergerätelement durch die Modellkomponente von Block 308 implementiert werden soll. Alternativ oder zusätzlich kann der Benutzer angeben, dass die Modellkomponenten für das Fahrzeugelement und das Fahrerelement durch ein gegebenes Simulationswerkzeug ausgeführt werden sollen, wie etwa die Simulink® modellbasierte Designumgebung. Der Benutzer kann auch eine Priorität für bestimmte Modellkomponenten und/oder Simulationswerkzeuge spezifizieren. Beispielsweise könne der Benutzer angeben, dass das realisierte Modell, wo möglich, Modellkomponenten enthalten sollte, welche durch die Simulink® modellbasierte Designumgebung ausgeführt werden. Auf ähnliche Weise könnte der Benutzer eine Reihenfolge von Präferenzen angeben, wie etwa Modellkomponenten, welche von der Simulink® modellbasierten Designumgebung ausgeführt werden, dann CarMaker, dann GT-SUITE.
Alternativ oder zusätzlich könnte der Benutzer ein oder mehrere Dienstequalität („Quality of Service“, QoS) Ziele für das realisierte Modell spezifizieren. Beispielsweise könnte der Benutzer angeben, dass die Kommunikationsverbindungen zwischen Modellkomponenten Verzögerung minimieren, verlustlose Kommunikation sicherstellen, Reihenfolge, zum Beispiel der Reihenfolge von Daten, garantieren sollte. Das Zielfunktions-Aufstellwerk 124 kann die Zielfunktion konfigurieren, ein Modell zu realisieren, welches solche Ziele erfüllt.
In einigen Ausführungsformen kann eine Modellkomponente deklarieren, dass dessen Schnittstelle Nulldurchgangsereignisse offenbart. Beim Bestimmen, wie das High-Level-Systemdesign 128 partitioniert werden soll, kann der Prozessor 120 zur Optimierung unter Randbedingungen vermeiden, eine Partitionsgrenze über eine Schnittstelle mit Nulldurchgangsereignissen zu platzieren.
Wenn während einem Ausführungsschritt (Simulationsschritt) ein Nulldurchgang auftritt, kann der Nulldurchgang behandelt werden, indem die Ausführungs- (Simulations-) Schrittweite verringert wird, um einen Schritt zu machen, der nahe (zum Beispiel mit etwas zeitlicher Toleranz oder für variable Werte) dem Zeitpunkt ist, an dem der Nulldurchgang auftritt. Wenn Nulldurchgangsfunktionen in mehreren Modellkomponenten vorhanden sind, kann die Konfigurierung/Partitionierung diese Modellkomponenten auf eine Co-Simulationskomponente abbilden, so dass die Schrittweitenvariation innerhalb der einen Co-Simulationskomponente eingeschlossen ist. Alternativ kann die Partitionierung/Konfiguration, abhängig von der Zielfunktion, bestimmen, den Nulldurchgangsort für eine Modellkomponente nicht zu verwenden, um die Ausführungsgeschwindigkeit gegenüber Effizienz einzutauschen.
Ein Benutzer kann auch Information bereitstellen, die eine oder mehrere der Randbedingungen aufweicht. Beispielsweise kann eine der verfügbaren Modellkomponenten auf einer gegebenen Version, zum Beispiel Release 2017, eines Softwaresimulationswerkzeugs ablaufen. Der Benutzer kann jedoch dem Modellpartitionierungswerk 108 gegenüber angeben, dass die Modellkomponente auch durch eine andere Version ausgeführt werden kann, zum Beispiel Release 2018. Das Zielfunktions-Aufstellwerk 124 kann die Zielfunktion so parametrisieren, dass die Lösung erlaubt, dass die Modellkomponente durch eine der beiden Versionen des Simulationswerkzeugs ausgeführt wird.
Lösungen
Präzision
Angenommen, dass die von dem Benutzer spezifizierten Ziele 130 ein hohes Gewicht auf die Präzision legen würden, wenn verblichen mit den Gewichten, die auf die Ausführungsgeschwindigkeit und die Speichernutzung gelegt werden.
Wie beschrieben, kann es einen Präzisionswert für jede Modellkomponente oder zumindest einige von diesen geben. Es mag auch einen Genauigkeitswert geben, welcher aus den Kommunikationsraten von Schnittstellen zwischen ausgewählten Komponentenresultiert. Beispielsweise mag die Abtastrate und/oder Schrittweite einer Schnittstelle einen Einfluss auf die Genauigkeit von ausgetauschten Daten haben.
Nachdem die Zielfunktion aufgestellt wurde, kann sie von dem Zielfunktions-Löser 126 gelöst werden. Die Lösung kann ausgewählte Modellkomponenten identifizieren, um die Elemente des High-Level-Systemdesigns 128, Co-Simulationspartitionen, Knoten 140 des Computernetzwerks, Simulationswerkzeuge und -versionen, Kommunikationsraten und Kompensatoren zu implementieren.
Wie beschrieben kann jede der zwei Modellkomponenten, welche dem Block 302 mit Bezeichnung ‚A‘ und dem Block 304 mit Bezeichnung ‚B‘ entsprechen, das Umgebungselement des High-Level-Systemdesigns 128 simulieren. Weiterhin weist die Modellkomponente von Block 302 (‚A‘) einen Präzisionswert von 2 auf, wohingegen die Modellkomponente von Block 304 (‚B‘) einen Präzisionswert von 10 aufweist. Eine Lösung der Zielfunktion, bei der dem Ziel Präzision eine hohe Gewichtung zugewiesen wird, wird wahrscheinlich in der Auswahl der Modellkomponente von Block 304 (‚B‘) resultieren.
Die zwei Modellkomponenten, welche dem Block 310 mit Bezeichnung ‚G‘ und Block 312 mit Bezeichnung ‚H‘ entsprechen, können jeweils das Antriebsstrangelement simulieren. Es sei angenommen, dass die Modellkomponente von Block 312 (‚H‘) einen höheren Präzisionswert aufweist als die Modellkomponente von Block 310 (‚G‘). Die drei Modellkomponenten, welche dem Block 318 mit Bezeichnung ‚K‘, dem Block 319 mit Bezeichnung ‚L‘ und dem Block 320 mit Bezeichnung ‚M‘ entsprechen, können jeweils das Fahrzeugelement simulieren. Es sei angenommen, dass unter diesen dreien die Modellkomponente von Block 318 (‚K‘) den höchsten Präzisionswert aufweist. Die zwei Modellkomponenten, welche dem Block 314 mit Bezeichnung ‚I‘ und dem Block 316 mit Bezeichnung ‚J‘ entsprechen, können jeweils das Fahrerelement simulieren. Es sei angenommen, dass unter diesen zweien die Modellkomponente von Block 314 (‚I‘) den höchsten Präzisionswert aufweist. Die vier Modellkomponenten, welche den Blöcken 306-309 mit Bezeichnungen ‚C‘, ‚D‘, ‚E‘ und ‚F‘ entsprechen, können jeweils das Steuergerätelement simulieren. Es sei angenommen, dass unter diesen vieren die Modellkomponente von Block 308 (‚E‘) den höchsten Präzisionswert aufweist.
In einigen Ausführungsformen kann ein oder können mehrere Ausführungseigenschaften einer gegebenen Modellkomponente geändert werden. Beispielsweise kann in einigen Fällen eine Präzision einer Modellkomponente geändert werden, indem der Typ des Lösers, der verwendet wird, um die Modellkomponente auszuführen, geändert wird. Beispielsweise weisen Löser für Differenzialgleichungen Toleranzen (absolute und relative), Schrittweiten (feste oder variable), maximale Schrittweiten, minimale Schrittweiten, Fehlerterme, polynomiale Ordnung, maximale Konvergenz Iterationen, etc. auf. Alle diese verschiedenen, unterschiedlichen Optionen tragen zur Genauigkeit einer numerischen Approximation durch einen Differentialgleichungslöser bei. Wurzel findende Löser weisen Toleranzen (relative, absolute), Schrittweiten, maximale Iterationen für Konvergenz, Interpolationsschemata, Suchschemata (zum Beispiel Bisektion, Gradientenabstieg, Kombinationen von Schemata), etc. Alle diese verschiedenen, unterschiedlichen Optionen haben einen Einfluss auf die Zeit, die erforderlich ist, um eine Lösung zu berechnen, und den erforderlichen Speicher (zum Beispiel wird ein Löser höheren Grads mehr Zeit und Speicher erfordern, um eine Lösung zu berechnen.)
Es sei weiter angenommen, dass die Modellkomponenten der Blöcke 304 (‚B‘) und 312 (‚H‘) Simulationsmodelle sind, die von dem GT SUITE Simulationswerkzeug ausgeführt werden. Es sei angenommen, dass die Modellkomponente von Block 308 (‚E‘) ein Modell ist, das durch die Simulink® modellbasierte Designumgebung ausgeführt wird. Es sei angenommen, dass die Modellkomponenten der Blöcke 318 (‚K‘) und 314 (‚I‘) Simulationsmodelle sind, die von dem CarMaker Softwarewerkzeug ausgeführt werden.
7 ist eine schematische Darstellung eines beispielhaften Modells 700, welches automatisch realisiert wurde durch das Modellpartitionierungswerk 108 für das High-Level-Systemdesign 128 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das Modell 700, das als ein Co-Simulations-Rahmenwerk bezeichnet werden kann, repräsentiert eine Lösung der Zielfunktion wie durch den Zielfunktions-Löser 126 berechnet, wobei dem Ziel Präzision eine hohe Gewichtung gegeben ist relative zu den anderen Zielen. Die von dem Zielfunktions-Löser 126 bestimmte Lösung kann vorsehen, dass das High-Level-Systemdesign 128 an zwei Stellen aufgetrennt werden sollte, um dadurch drei Co-Simulationspartitionen 702-704 zu erzeugen. Beispielsweise mag die Lösung vorsehen, dass die Modellkomponenten für das Fahrzeugelement und das Fahrerelement in eine Co-Simulationspartition platziert werden sollen, zum Beispiel die Partition 702, dass Modellkomponenten für den Antriebsstrang und Umgebungselemente in eine andere Co-Simulationspartition platziert werden sollen, zum Beispiel die Partition 703, und dass eine Modellkomponente für die Steuer- und/oder Regeleinheit in eine nochmals weitere Co-Simulationspartition platziert werden soll, zum Beispiel die Partition 704. Dementsprechend kann die Lösung versehen, dass ein Schnitt an der Verbindung 212 zwischen den Fahrzeugelement und dem Antriebsstrangelement, und dass ein anderer Schnitt gemacht werden sollte an der Verbindung 218 zwischen dem Antriebsstrangelement und dem Steuergerätelement. Zusätzlich kann der Zielfunktions-Löser 126 bestimmen, dass aus der Menge von verfügbaren Modellkomponenten 302-320 das Modell 700 die Modellkomponenten enthalten sollte, die den Blöcken 318 (‚K‘), 312 (‚H‘), 314 (‚I‘), 304 (‚B‘) und 308 (‚E‘) entsprechen, für das Fahrzeugelement, das Antriebsstrangelement, das Fahrerelement, das Umgebungselement bzw. das Steuergerätelement.
Die Lösung kann weiter vorsehen, dass die Partition 702 durch ein Simulationswerkzeug ausgeführt werden soll, wie etwa das CarMaker Simulationswerkzeug, auf einem Knoten, wie etwa dem Knoten 140a, des Computernetzwerks 106. Die Lösung kann auch vorsehen, dass die Partition 703 durch ein anderes Simulationswerkzeug ausgeführt werden soll, wie etwa das GT SUITE Simulationswerkzeug, auf einem anderen Knoten, wie etwa dem Knoten 140b, des Computernetzwerks 106. Die Lösung kann auch vorsehen, dass die Partition 704 durch ein nochmals anderes Simulationswerkzeug ausgeführt werden soll, wie etwa der Simulink® modellbasierten Designumgebung, auf einem anderen Knoten, wie etwa dem Knoten 140c, des Computernetzwerks 106. Schnittstellen können vorgesehen werden an den Schnitten, die an dem High-Level-Systemdesign 128 vorgenommen wurden. Beispielsweise kann die Lösung eine Schnittstelle 706 zwischen den Partitionen 702 und 703, und eine andere Schnittstelle 708 zwischen den Partitionen 703 und 704 definieren.
Eine Lösung der Zielfunktion kann Eigenschaften der Signale, die durch die Pfeile 212, 214, 216 und 218 repräsentiert sind, berücksichtigen. Sie kann auch Attribute der Datenkommunikationsverbindungen zwischen den Knoten 140a-c des Computernetzwerks 106 berücksichtigen. Es sei beispielsweise angenommen, dass das Signal, das durch den Pfeil 214 repräsentiert wird, ein Videostream ist. Um den Videostream zu unterstützen, der einen Datentransfer mit großer Bandbreite erfordern mag, kann die Lösung danach trachten, das Fahrzeugelement und das Fahrerelement in dieselbe Partition und/oder auf denselben Knoten zu platzieren. Es sei angenommen, dass das Signal, das durch den Pfeil 212 repräsentiert wird, manchmal Steuer- und/oder Regelnachrichten überträgt. Die Lösung kann es erlauben, dass das Fahrzeugelement und das Antriebsstrangelement in unterschiedliche Partitionen auf unterschiedlichen Knoten platziert werden, die mittels einer Datenkommunikationsverbindung mit geringer Bandbreite verbunden sind.
Die Lösung, die von dem Zielfunktions-Löser 126 berechnet wird, kann Information zum Konfigurieren der Co-Simulationspartitionen 702-704 beinhalten. Beispielsweise kann die Lösung Information 710 zum Konfigurieren der Partition 702, weitere Information 711 zum Konfigurieren der Partition 703 und nochmals weitere Information 712 zum Konfigurieren der Partition 704 beinhalten. Die Information 710-712 kann lokale Ausführungs-Engines und/oder Löser identifizieren, die von den Simulationswerkzeugen zu verwenden sind, die in den jeweiligen Partitionen 702-704 ausgeführt werden. Die Information 710-712 kann die Schrittweiten angeben, die von den lokalen Ausführungs-Engines und/oder Lösern verwendet werden sollen, und lokale Löserparameter, wie etwa relative und absolute Toleranz, Schrittweite, etc.
Das Ändern von einem oder von mehreren Konfigurationsparametern einer Modellkomponente kann eine oder mehrere Eigenschaften der Modellkomponente ändern. Beispielsweise kann das Ändern des Lösers und/oder der Toleranz die Simulationspräzision der Modellkomponente ändern. In einigen Ausführungsformen kann die Lösung, die von dem Zielfunktions-Löser 126 bestimmt wird, das Ändern und/oder Setzen von einem oder von mehreren Parameter für eine Modellkomponente basierend auf einer spezifizierten Gewichtung unter Präzision, Ausführungsgeschwindigkeit und Speichernutzung beinhalten, um zum Beispiel die spezifizierte Gewichtung unter Präzision, Ausführungsgeschwindigkeit und Speichernutzung zu erhalten. Eine einzelne Modellkomponente kann daher mehrere Alternativen repräsentieren durch Ändern von einer oder von mehreren Parametern. Es sei zum Beispiel angenommen, dass eine einzelne Modellkomponente für ein Motorsteuer- und/oder -regelelement vorgesehen ist, und die Präzision höher Gewichtet wird relativ zu der Ausführungsgeschwindigkeit und Speichernutzung. Basierend auf diesem Ziel kann die Lösung den partikulären Löser und Toleranzparameter für die Modellkomponente bestimmen, welche das Motorsteuer- und/oder -regelelement modelliert.
Mit Bezug auf die Simulink Simulationsumgebung kann der Zielfunktions-Löser 126 Werte/Einstellungen für ein oder mehrere Parameter ändern betreffend: Wahl von Löser(n), Pufferwiederverwendung, Diagnoseoptionen, Loggen/Visualisierung, Parametertuning, Modus (Normal, Rapid Accelerator), Ausführung out-of-process vs. in-process, Optimierungsoptionen und/oder Registereinstellungen.
Das Ändern des Lösers kann die Simulationspräzision und/oder die Ausführungsperformance, wie etwa Geschwindigkeit, Speichernutzung, Ressourcennutzung, Dateizugriff etc. verbessern. Beispielhafte verfügbare Löser können diskrete Löser mit fester Schrittweite und kontinuierliche Löser mit fester Schrittweite beinhalten, wie etwa das Eulersche Verfahren (ode1), das Heun'sche Verfahren (ode2), die Bogacki-Shampine Formel (ode3), die Runge-Kutta vierter Ordnung (RK4) Formel (ode4), die Dormand-Prince (RK5) Formel (ode5), Dormand-Prince RK8(7) (ode8), und Löser mit variable Schrittweite, wie etwa Runge-Kutta, Dormand-Prince (4, 5) Paar (ode45), Runge-Kutta (2, 3) Paar von Bogacki & Shampine (ode 23), PECE Implementierung von Adams-Bashforth-Moulton (ode113) und nichtadaptives Runge-Kutta (odeN).
Das Abschalten der Signalpufferwiederverwendung verringert die Speichernutzung, beeinflusst aber die Fähigkeit zum Debuggen. Das Abschalten von Laufzeitdiagnosen, wie etwa Feldindex-Grenzüberschreitungsdiagnosen, kann die Ausführungsgeschwindigkeit verbessern, beeinflusst aber ebenso die Fähigkeit zum Debuggen. Das Abschalten von Loggen, Visualisierung und/oder Parametertuning kann die Ausführungsgeschwindigkeit verbessern. Das Auswählen des Rapid Accelerator Modus und eines gemeinsam genutzte Bibliothek-Target kann gegenüber dem Normalmodus die Ausführungsgeschwindigkeit erhöhen und die Speichernutzung verbessern, hat aber Auswirkungen auf die Interaktivität und das Debugging. Das Auswählen einer In-Process Ausführung gegenüber einer Out-of-Process Ausführung kann die Ausführungsgeschwindigkeit verbessern, mag aber eine weniger robuste Umgebung bereitstellen, in welcher die Modellausführung die Simulationsumgebung zum Absturz bringen kann und Symbolkonflikte zwischen Softwareanwendungen ungelöst bleiben können. Optimierungsoptionen, wie etwa „verwende Bitsets“, können die Speichernutzung reduzieren, können aber die Ausführungsgeschwindigkeit/Simulationszeit verlangsamen. Registereinstellungen, wie etwa bündig auf null („flush to zero“, FTZ) und Denormale sind null („denormals are zero“, DAZ) können die Ausführungsgeschwindigkeit verbessern, können aber weniger akkurat sein.
Es sei verstanden, dass diese Parameter beispielhaft sind und dass der Zielfunktions-Löser 126 einen oder mehrere andere Parameter ändern kann.
Die Lösung, welche von dem Zielfunktions-Löser 126 bestimmt wird, kann weiter Information zum Konfigurieren der Schnittstellen zwischen Modellkomponenten, die in unterschiedliche Co-Simulationspartitionen platziert wurden, enthalten. Beispielsweise kann die Lösung Information 714 zum Konfigurieren der Schnittstelle 706 zwischen den Modellkomponenten 318 und 312 in den Co-Simulationspartitionen 702 und 703, und andere Information 716 zum Konfigurieren der Schnittstelle 708 zwischen den Modellkomponenten 312 und 308 in den Co-Simulationspartitionen 703 und 704 enthalten. Beispielsweise können sich die Informationen 714 und 716 auf Kompensatoren für die Schnittstellen 706 und 708 beziehen. Die Informationen 714 und 716 können den Ort von und Parameter für derartige Kompensatoren enthalten.
Ein Kompensator kann in dem Modell 700 graphisch repräsentiert werden (zum Beispiel in dem Modell als ein Block angezeigt werden), um diesen dem Benutzer zu zeigen, oder dieser kann virtuell sein, so dass der Benutzer keinen Hinweis erhält, dass ein Kompensator angewandt wird und/oder eingefügt wird in das Modell 700.
Zusätzlich oder alternative kann die Kommunikationsrate für das Signal 212 zwischen den Modellkomponenten 318 und 312, wie durch die Schnittstelle 706 im Modell implementiert, von dem Schnittstellenkonfigurationswerk 112 automatisch bestimmt werden. Die Komponenten 318 und 312 können als Co-Simulationskomponenten bezeichnet werden. Beispielsweise kann die Kommunikationsrate der Schnittstelle 706 gleich der modellierten Abtastrate des Signals 212 gesetzt werden. In einigen Implementierungen kann die Schnittstellenbildung, die erforderlich ist, um eine Kommunikation zwischen subordinären Lösern in einem Co-Simulations-Rahmenwerk zu ermöglichen, eine Kommunikationsrate erfordern, die sich von der modellierte Abtastraten für eine Co-Simulationskomponente unterscheidet. Wenn beispielsweise angenommen wird, dass das Signal 218 eingestellt ist, eine zeitkontinuierlich modellierte Abtastrate aufzuweisen, kann die Kommunikationsrate der Schnittstelle 708 damit nicht in Übereinstimmung eingestellt werden, da die zeitkontinuierlich modellierte Abtastrate (zum Beispiel eine diskrete Rate basierend auf der Schrittweite eines numerischen Integrationsschemas, das verwendet wird, um die zeitkontinuierliche zu modellieren) höher sein als die diskrete Kommunikationsrate, die für eine Kommunikation zwischen den Co-Simulationskomponenten 312 und 308 möglich ist. Als ein anderes Beispiel, wenn angenommen wird, dass das Signal 218 eingestellt ist, eine zeitdiskret modellierte Abtastrate aufzuweisen, kann die Kommunikationsrate der Schnittstelle 708 auf ein Mehrfaches der zeitdiskret modellierten Abtastrate eingestellt werden, wenn die Prozessorressourcen keine Kommunikationsrate unterstützen, die so schnell ist, wie die modellierte Abtastrate.
Das Schnittstellenkonfigurationswerk 112 kann bestimmen, dass eine explizite Kompensation angebracht ist, wenn Information, die zur Ausführung einer impliziten Kompensation notwendig ist, nicht verfügbar war. Alternativ kann das Schnittstellenkonfigurationswerk 112 eine explizite Kompensation anwenden, unabhängig davon, ob die Information, die notwendig ist, um eine implizite Kompensation auszuführen, verfügbar war. Beispielsweise kann das Schnittstellenkonfigurationswerk 112 programmiert sein, immer eine explizite Kompensation auszuführen.
Ein Block, der einen Kompensator repräsentiert, kann in das Modell 700 zwischen den Co-Simulationskomponenten 318 und 312 eingefügt werden, um die explizite Kompensation auszuführen. In einigen Ausführungsformen kann eine visuelle Darstellung eines Kompensators (zum Beispiel ein Block, ein Koppelelement, das Blöcke oder andere Modellelemente verbindet, etc.) bereitgestellt werden, auch wenn keine visuelle Repräsentation notwendig ist für eine explizite Kompensation. Beispielsweise kann die Funktionalität eines Kompensatorblocks in die Co-Simulationskomponente 312 eingefügt werden durch Ändern der Eigenschaften des Signals, welches die Co-Simulationskomponenten 318 und 312 verbindet, ohne einen neuen Block einzufügen. In einigen Implementierungen kann der Pfeil 212, welcher das Signal repräsentiert, modifiziert werden, um visuell anzuzeigen, dass eine Kompensation ausgeführt wird, und/oder dass die Kompensatorfunktionalität dem Signal hinzugefügt wurde. In einigen Implementierungen kann die Funktionalität eines Kompensators in eine Repräsentation des realisierten Modells im Speicher eingefügt werden, und mag in der Visualisierung des realisierten Modells nicht angezeigt werden.
In einigen Implementierungen kann der Kompensator ein Algorithmus sein, der auf das Signal angewandt wird, das von der Co-Simulationskomponente 318 ausgegeben wird, welcher das Signal modifiziert, um eine Kompensation zu schaffen für die intermediären Datenpunkte, welche von der Co-Simulationskomponente 318 erzeugt werden, welche während der Co-Simulation verloren gehen. Die Kompensation des Signals modifiziert das Signal, das in die Co-Simulationskomponente 312 eingegeben wird. Beispielsweise kann die Modifikation des Signals dazu führen, dass ein Integrationswert, der von der Co-Simulationskomponente 318 ausgegeben wird, näher einem Integrationswert ist, der berechnet worden wäre unter Verwendung aller intermidärer Datenpunkte, die von der Co-Simulationskomponente 318 berechnet wurden, als wenn keine Kompensation ausgeführt würde.
In einigen Implementierungen kann ein Kompensator auch für Schnittstellen zwischen Co-Simulationskomponenten, die in dieselbe Partition platziert sind, erforderlich sein. Beispielsweise mag ein Kompensator für das Signal 214 zwischen den Co-Simulationskomponenten, die den Blöcken 318 und 314 entsprechen, erforderlich sein.
Geeignete Techniken zum Bestimmen und Platzieren von Kompensatoren für Co-Simulation sind beschrieben in der Anmeldung Anmeldenummer 15/612,501, eingereicht am 2. Juni 2017 für Systeme und Methoden zur Co-Simulation von Tao Cheng et al., welche Anmeldung hiermit durch Bezugnahme in Gänze aufgenommen ist.
Stufenweise Partitionierung
In einigen Ausführungsformen kann der Zielfunktions-Löser 126 das Partitionierungsproblem in Stufen lösen, und die Ergebnisse von einer oder von mehreren dieser Stufen können dem Benutzer dargestellt werden, zum Beispiel zur Bestätigung bzw. Zustimmung und/oder Anpassung. Wenn der Benutzer die aktuelle Stufe bestätigt, kann der Zielfunktions-Löser 126 zur nächsten Stufe des Partitionierungsproblems fortschreiten.
13 ist eine schematische Darstellung einer beispielhaften Stufe 1300 eines Partitionierungsprozesses für das High-Level-Systemdesign 128 in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die Partitionierungsstufe 1300 repräsentiert eine partielle Lösung der Zielfunktion, wie durch den Zielfunktions-Löser 126 berechnet. Die Partitionierungsstufe 1300 kann vorsehen, dass das Fahrzeugelement 202 durch die Modellkomponente, die dem Block 318 (‚K‘) entspricht, implementiert wird, und dass das Fahrerelement 206 durch die Modellkomponente, die dem Block 314 (‚I‘) entspricht, implementiert wird. Die Partitionierungsstufe 1300 kann weiter vorsehen, dass die Modellkomponenten der Blöcke 318 (‚K‘) und 314 (‚I‘) in eine Partition platziert werden sollten, zum Beispiel die Partition 1302. Die partielle Lösung kann weiter vorsehen, dass die Partition 1302 durch ein Simulationswerkzeug ausgeführt werden sollte, wie etwa einem Synopsys Simulationswerkzeug, auf einem Knoten, wie etwa dem Knoten 140a, des Computernetzwerks 106. Die Partitionierungsstufe 1300 mag jedoch keine ausgewählten Modellkomponenten für das Antriebsstrangelement 204, das Fahrzeugelement 208 oder das Steuer- und/oder Regelelement 210 haben. Die Partitionierungsstufe 1300 mag auch keine Partitionierung für das Antriebsstrangelement 204, das Fahrzeugelement 208 oder das Steuer- und/oder Regelelement 210 bestimmt haben.
Wenn angenommen wird, dass ein Benutzer die Auswahl der Modellkomponenten der Blöcke 318 (‚K‘) und 314 (‚I‘) und deren Platzierung in einer Co-Simulationspartition akzeptiert, kann der Benutzer diese Auswahl sperren. Beispielsweise kann eine graphische Affordanz dargestellt werden, zum Beispiel indem die Co-Simulationspartition 1302 ausgewählt wird, über welche der Benutzer die Partition 1302 sperren kann. Der Zielfunktions-Löser 126 kann dann damit fortfahren, das Partitionierungsproblem zu lösen. Beispielsweise kann der Zielfunktions-Löser 126 eine Zielfunktion generieren, welche die Blöcke 318 (‚K‘) 314 (‚I‘) als harte Randbedingungen beinhaltet, und nur nach dem Antriebsstrangelement 204, dem Fahrzeugumgebungselement 208 und dem Steuer- und/oder Regelelement 210 löst.
In einigen Ausführungsformen kann ein Benutzer eine partielle Lösung für das Antriebsstrangelement 204, das Fahrzeugumgebungselement 208 und das Steuer- und/oder Regelelement 210 einfrieren und eine oder mehrere Lösungen, die für das Fahrzeugelement 202 und das Fahrerelement 206 bestimmt wurden, evaluieren.
Die Nutzung einer stufenweisen Partitionierung kann die Benutzererfahrung und -Interaktion mit der Simulationsumgebung verbessern.
Modellverwirklichungsbewertung
Das realisierte Modell 700 kann ausgeführt werden, um beispielsweise das Verhalten des High-Level-Systemdesigns 128 zu simulieren und Co-Simulationsergebnisse zu produzieren. Die ausgewählten Modellkomponenten 146-149 können von unterschiedlichen Ausführungs-Engines, unterschiedlichen Lösern und/oder unterschiedlichen Simulationswerkzeugen in einer Weise der Co-Simulation ausgeführt werden. Die Integrationsplattform 102 kann mit unterschiedlichen Simulationswerkzeugen interagieren, um Funktionalitäten für die ausgewählten Modellkomponenten 146-149 auszuführen, um das realisierte Modell 700 in einer Weise der Co-Simulation auszuführen. Alternativ kann die Integrationsplattform 102 ein Simulationswerkzeug implementieren und die Komponenten des realisierten Modells 700 unter Verwendung unterschiedlicher Ausführungs-Engines und/oder Löser innerhalb desselben Simulationswerkzeugs ausführen.
Das Beurteilungswerk 113 kann verwendet werden, um zu bestimmen, ob die Ziele 130 von dem realisierten Modell 700 erfüllt werden. Wenn beispielsweise die Präzision als das Ziel mit der höchsten Gewichtung spezifiziert wurde, kann das Beurteilungswerk 113 die Genauigkeit der Co-Simulationsergebnisse evaluieren, die von dem realisierten Modell 700 produziert werden. Das Beurteilungswerk 113 kann bestimmen, dass die Co-Simulationsergebnisse akkurat Resultate modellieren, die von einem tatsächlichen System, das durch das High-Level-Systemdesign 128 repräsentiert wird, erwartet würden. Es können Validierungstechniken angewandt werden. Beispielsweise kann ein Gesamtmodell ohne Co-Simulationskonfiguration und unter Verwendung des genauesten verfügbaren Lösers ausgeführt werden, um Referenzergebnisse zu erhalten. Danach können die Referenzergebnisse mit dem Ergebnis einer Simulation in Co-Simulation verglichen werden, um die Genauigkeit zu bestimmen. Eine andere Bewertung kann sein, zu prüfen, ob Instabilität auftritt (zum Beispiel angezeigt durch exzessive Werte in einer Simulation). Ein anderes Verfahren zum Erhalten der Referenz ist es, eine hohe Kommunikationsrate zu verwenden und dann diese Referenz mit der Co-Simulation zu vergleichen, die gemäß der Benutzerzielfunktion konfiguriert ist. Alternativ können Co-Simulationskonfigurationen erzeugt und deren Ausgaben verglichen werden. Wenn dieser Vergleich größere (zum Beispiel größer als eine Toleranz) Abweichungen zeigt, dann kann eine oder beide der Co-Simulationskonfigurationen verworfen werden. In anderen Ausführungsformen kann ein Benutzer eine Expertenbewertung der Genauigkeit der Simulationsergebnisse vornehmen. Andere Bewertungen können einen jeden der hierin diskutierten Parameter involvieren, wie etwa ob das Modell innerhalb einer bestimmten Zeitdauer ausgeführt wird, ob es in den Speicher passt, ob die Kommunikationsraten erfüllt werden, etc.
In einigen Ausführungsformen kann das Beurteilungswerk 113 eine Erkennung über Randbedingungen vornehmen. Beispielsweise können die Ergebnisse, die von dem realisierten Modell 142 produziert werden, mit einem hohen Grad an Genauigkeit mit den Ergebnissen übereinstimmen, die von dem High-Level-Systemdesign 128 erwartet werden, aber es mag viel länger dauern, um das realisierte Modell 142 auszuführen, als von dem Benutzer erwartet. In diesem Fall kann der Benutzer das Ziel Präzision aufweichen und das Ziel Ausführungsgeschwindigkeit erhöhen, und das Modellpartitionierungswerk 108 dirigieren, eine neue Partitionierung des High-Level-Systemdesigns 128 vorzunehmen.
Ausführungsgeschwindigkeit
Wie beschrieben ist das Modell 700 eine Realisierung des High-Level-Systemdesigns 128, bei der dem Ziel Präzision eine hohe Gewichtung gegeben ist, relative zu den anderen Zielen. Es sei verstanden, dass das Modellpartitionierungswerk 108 automatisch eine andere Realisierung des High-Level-Systemdesigns 128 erzeugen kann, wenn einem anderen Ziel, wie etwa der Ausführungsgeschwindigkeit, eine hohe Gewichtung gegeben wird. Beispielsweise kann das Zielfunktions-Aufstellwerk 124 die Zielfunktion so aufstellen, dass die Lösung die Ausführungszeit minimiert. Der Zielfunktions-Löser 126 kann dann diese neue Zielfunktion lösen, um ein anderes Modell zu realisieren.
Es sei angenommen, dass für die zwei Modellkomponenten, die dem Block 302 mit Bezeichnung ‚A‘ und dem Block 304 mit Bezeichnung ‚B‘, welche das Umgebungselement des High-Level-Systemdesigns 128 simulieren, entsprechen, die Co-Simulationskomponente von Block 302 (‚A‘) eine höheren Ausführungsgeschwindigkeitswert aufweist. Dementsprechend resultiert eine Lösung der Zielfunktion, bei der dem Ziel Ausführungsgeschwindigkeit eine hohe Gewichtung zugewiesen ist, wahrscheinlich in der Auswahl der Co-Simulationskomponente von Block 302 (‚A‘). Wenn weiter angenommen wird, dass für die zwei Co-Simulationskomponenten, die dem Block 310 mit Bezeichnung ‚G‘ und dem Block 312 mit Bezeichnung ‚H‘, welche das Antriebsstrangelement simulieren, die Co-Simulationskomponente von Block 310 (‚G‘) einen höheren Ausführungsgeschwindigkeitswert aufweist. Es sei weiter angenommen, dass für die drei Co-Simulationskomponenten, welche dem Block 318 mit Bezeichnung ‚K‘, dem Block 319 mit Bezeichnung ‚L‘ und dem Block 320 mit Bezeichnung ‚M‘, welche das Fahrzeugelement simulieren, die Co-Simulationskomponente von Block 319 (‚L‘) den höchsten Ausführungsgeschwindigkeitswert aufweist. Es sei auch angenommen, dass für die zwei Co-Simulationskomponenten, welche dem Block 314 mit Bezeichnung ‚I‘ und dem Block 316 mit Bezeichnung ‚J‘, welche das Fahrerelement simulieren, entsprechen, die Co-Simulationskomponente von Block 316 (‚J‘) den höchsten Ausführungsgeschwindigkeitswert aufweist. Es sei auch angenommen, dass für die vier Co-Simulationskomponenten, die den Blöcken 306-309 mit Bezeichnung ‚C‘, ‚D‘, ‚E‘ und ‚F‘, welche das Steuergerätelement simulieren, entsprechen, die Co-Simulationskomponente von Block 307 (‚D‘) den höchsten Ausführungsgeschwindigkeitswert aufweist.
Es sei weiter angenommen, dass die Co-Simulationskomponenten der Blöcke 302 (‚A‘) und 310 (‚G‘) Simulationsmodelle sind, die von der Simulink® modellbasierten Designumgebung ausgeführt werden. Es sei weiter angenommen, dass die Co-Simulationskomponente von Block 319 (‚L‘) ein Modell ist, das von dem ANSYS Simulationswerkzeug ausgeführt wird, dass die Co-Simulationskomponente von Block 316 (‚J‘) ein Modell ist, das von dem CarMaker Simulationswerkzeug ausgeführt wird, und dass die Co-Simulationskomponente von Block 307 (‚D‘) ein Modell ist, das von dem Siemens PLM Simulationswerkzeug ausgeführt wird.
8 ist eine schematische Darstellung eines beispielhaften Modells 800, das automatisch von dem Modellpartitionierungswerk 108 für das High-Level-Systemdesign 128 realisiert wird, in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das Modell 800 repräsentiert eine Lösung der Zielfunktion, wie von dem Zielfunktions-Löser 126 berechnet, wobei dem Ziel Ausführungsgeschwindigkeit eine hohe Gewichtung gegeben wurde relativ zu den anderen Zielen. Hier kann die Lösung vorsehen, dass das High-Level-Systemdesign 128 an drei Stellen getrennt werden sollte, wodurch vier Partitionen 802-805 erzeugt werden. Beispielsweise kann die Lösung vorsehen, dass eine Modellkomponente für das Fahrzeugelement in eine Co-Simulationspartition platziert werden sollte, zum Beispiel die Co-Simulationspartition 702, dass die Modellkomponenten für das Antriebsstrangelement und das Umgebungselement in eine andere Co-Simulationspartition platziert werden sollten, zum Beispiel die Co-Simulationspartition 803, dass eine Modellkomponente für die Steuer- und/oder Regeleinheit in eine nochmals weitere Co-Simulationspartition platziert werden sollten, zum Beispiel die Co-Simulationspartition 804, und dass eine Modellkomponente für das Fahrerelement in eine abermals weitere Co-Simulationspartition platziert werden sollte, zum Beispiel die Co-Simulationspartition 805. Dementsprechend kann die Lösung vorsehen, dass ein Schnitt an der Verbindung 212 zwischen dem Fahrzeugelement und dem Antriebsstrangelement gemacht werden sollte, dass ein anderer Schnitt an der Verbindung 218 zwischen dem Antriebsstrangelement und dem Steuergerätelement vorgenommen werden sollte, und dass ein weiterer Schnitt an der Verbindung 214 zwischen dem Fahrzeugelement und dem Fahrerelement vorgenommen werden sollte. Zusätzlich kann der Zielfunktions-Löser 126 bestimmen, dass, aus der Menge 104 von verfügbaren Modellkomponenten, das Modell 800 die Modellkomponenten enthalten sollte, die den Blöcken 319 (‚L‘), 310 (‚G‘), 316 (‚J‘), 302 (‚A‘) und 307 (‚D‘) für das Fahrzeugelement, das Antriebsstrangelement, das Fahrerelement, das Umgebungselement bzw. das Steuergerätelement entsprechen.
Die Lösung kann weiter vorsehen, dass die Co-Simulationspartition 802 von einem Simulationswerkzeug ausgeführt werden sollte, wie etwa das ANSYS Simulationswerkzeug, auf einem Knoten, wie etwa dem Knoten 140a, dass die Co-Simulationspartition 803 von einem anderen Simulationswerkzeug ausgeführt werden sollte, wie etwa der Simulink® modellbasierten Designumgebung, auf einem anderen Knoten, wie etwa dem Knoten 140b, dass die Co-Simulationspartition 804 von einem nochmals anderen Simulationswerkzeug ausgeführt werden sollte, wie etwa dem Siemens PLM Simulationswerkzeug, auf einem anderen Knoten, wie etwa dem Knoten 140c, und dass die Co-Simulationspartition 805 von einem nochmalig anderen Simulationswerkzeug ausgeführt werden sollte, wie etwa dem CarMaker Simulationswerkzeug, auf einem nochmalig anderen Knoten.
An den Schnitten, die in dem High-Level-Systemdesign 128 vorgenommen wurden, können Schnittstellen etabliert werden. Beispielsweise kann die Lösung eine Schnittstelle 806 zwischen den Co-Simulationspartitionen 802 und 803, eine andere Schnittstelle 807 zwischen den Co-Simulationspartitionen 803 und 804 und eine weitere Schnittstelle 808 zwischen den Co-Simulationspartitionen 802 und 805 vorsehen.
Die Lösung, die von dem Zielfunktions-Löser 126 berechnet wird, kann Information zum Konfigurieren der Co-Simulationspartitionen 802-805 enthalten. Beispielsweise kann die Lösung Information 810 zum Konfigurieren der Co-Simulationspartition 802, andere Information 811 zum Konfigurieren der Co-Simulationspartition 803, nochmals andere Information 812 zum Konfigurieren der Co-Simulationspartition 804 und weitere Information 813 zum Konfigurieren der Co-Simulationspartition 805 enthalten. Die Information 810-813 kann lokale Löser identifizieren, welche von den Simulationswerkzeugen verwendet werden sollen, welche die jeweiligen Co-Simulationspartitionen 802-805 ausführen.
Die Lösung, die von dem Zielfunktions-Löser 126 bestimmt wird, kann weiter Information zum Konfigurieren der Schnittstellen zwischen den Modellkomponenten, die in unterschiedlichen Co-Simulationspartitionen platziert wird, enthalten. Derartige Modellkomponenten können als Co-Simulationskomponenten bezeichnet werden. Beispielsweise kann die Lösung Information 814 zum Konfigurieren der Schnittstelle 806 zwischen den Co-Simulationskomponenten 319 und 310 in den Co-Simulationspartitionen 802 und 803, andere Information 815 zum Konfigurieren der Schnittstelle 807 zwischen den Co-Simulationskomponenten 310 und 307 in den Co-Simulationspartitionen 803 und 804 und weitere Information 816 zum Konfigurieren der Schnittstelle 808 zwischen den Co-Simulationskomponenten 319 und 316 in den Co-Simulationspartitionen enthalten. Beispielsweise kann sich die Information 814-816 auf Kompensatoren für die Schnittstellen 806-808 beziehen. Die Information 814-816 den Ort von und Parameter für solche Kompensatoren enthalten.
Das realisierte Modell 800 kann ausgeführt werden, wobei Co-Simulationsergebnisse produziert werden. Wie das Modell 700 kann das Modell 800, wenn es ausgeführt wird, das Verhalten High-Level-Systemdesigns 128 simulieren. Die Integrationsplattform 102 kann mit den unterschiedlichen Simulationswerkzeugen interagieren, um Funktionalitäten für die ausgewählten Co-Simulationskomponenten auszuführen, um das realisierte Modell 800 in einer Weise der Co-Simulation auszuführen.
Das Beurteilungswerk 113 kann verwendet werden, um zu bestimmen, ob die Ziele 130 von dem realisierten Modell 800 erfüllt werden. Beispielsweise kann das Beurteilungswerk 113, nachdem das Ziel Ausführungsgeschwindigkeit als höher als die anderen Ziele spezifiziert wurde, dann Evaluieren, wie lange es braucht, um das realisierte Modell 800 auszuführen. Es sei angenommen, dass der Benutzer bestimmt, dass das Modell 800 viel weniger Zeit erfordert, um ausgeführt zu werden, als der Benutzer erwartet hat, dass aber die Präzision des realisierten Modells 800 geringer als erwartet ist. In diesem Fall könnte der Benutzer die Ziele ändern, zum Beispiel das Gewicht für die Ausführungsgeschwindigkeit erniedrigen und das Gewicht für die Präzision erhöhen, und das Modellpartitionierungswerk 108 anzuleiten, eine neue Partitionierung für das High-Level-Systemdesign 128 zu berechnen.
Für andere Ziele, wie etwa HDL Codegenerierung, kann das Modellpartitionierungswerk 108 ein anderes realisiertes Modell generieren. In diesem Fall kann das Modellpartitionierungswerk 108 eine hohe Gewichtung auf diejenigen Co-Simulationskomponenten setzen, welche die Codegenerierung unterstützen. Allgemein kann das Generieren von Code die Ausführungsgeschwindigkeit verbessern. Es mag jedoch länger dauern, bi seine Simulation startet, aufgrund der Zeit, die erforderlich ist, um den Code zu generieren und diesen zu kompilieren. Wenn daher der Verwendung der Codegenerierung eine höhere Gewichtung verliehen wird, kann die Konfiguration mehr Implementierungen von Modellkomponenten beinhalten, welche Codegenerierung unterstützen (selbst wenn deren Präzision geringer sein mag, gegeben die gewichtete Präferenz von dem Benutzer). Auch kann sich die Partitionierung ändern, indem Modellkomponenten gruppiert werden, welche die Codegenerierung für dasselbe Ziel unterstützen. Beispielsweise können Modellkomponenten, welche die HDL Codegenerierung (mit einigen ihrer Implementierungen) unterstützen, in eine Co-Simulationskomponente gruppiert werden, welche dann die HDL Codegenerierung unterstützt (und ähnlich für C Codegenerierung). Auch kann die Codegenerierung allgemein konfiguriert sein, effizienter zu sein in Begriffen der Ausführungszeit (auch Latenz und Durchsatz), Größe (Speichernutzung, Logikgatterverwendung, Stacknutzung, etc.) und Leistung. Diese Parameter können Teil der Zielfunktion für die Co-Simulationspartitionierung/Konfiguration sein.
Wenn der Ausführungsgeschwindigkeit eine höhere Gewichtung gegeben wird, kann dies in einem realisierten Simulationsmodell resultieren, das weniger Prozessorressourcen zur Ausführung erfordert, indem es zum Beispiel eine verbesserte Simulationseffizienz aufweist, wenn verglichen mit realisierten Modellen, bei denen anderen Zielen als der Ausführungsgeschwindigkeit höhere Gewichtungen gegeben werden. Darüber hinaus kann, wenn der Speichernutzung eine höhere Gewichtung gegeben wird, dies in einem realisierten Simulationsmodell resultieren, welches in weniger Rechnerspeicher einer Datenverarbeitungsvorrichtung gespeichert werden muss, wodurch die Speichererfordernisse der Datenverarbeitungsvorrichtung verringert werden, wenn verglichen mit realisierten Modellen, bei welchen anderen Zielen anstatt der Speichernutzung ein höheres Gewicht gegeben wird. Wenn zum Beispiel der Simulationspräzision, zum Beispiel numerische Genauigkeit, eine höhere Gewichtung gegeben wird, kann dies in einem realisierten Simulationsmodell resultieren, welches akkuratere Simulationsergebnisse liefert als realisierte Modelle, bei welchen anderen Zielen als der Simulationspräzision eine höhere Gewichtung gegeben wird.
Echtzeitimplementierungen
In einigen Ausführungsformen kann das Modellpartitionierungswerk 108 ein High-Level-Systemdesign so partitionieren, dass einige, und bevorzugt alle, der ausgewählten Modellkomponenten in einer Echtzeitumgebung ausgeführt werden. Beispielsweise kann das Computernetzwerk 106 Knoten beinhalten, welche Middleware und/oder Betriebssysteme ausführen, welche einen Echtzeitbetrieb unterstützen. Das Modellpartitionierungswerk 108 kann eine Partition erzeugen, welche ausgewählte Modellkomponenten enthält, die konfiguriert sind, mit der Echtzeit Middleware zu interoperieren. Beispielhafte Middleware, die einen Echtzeitbetrieb unterstützen, beinhalten das Robot Betriebssystem (ROS) und den Data Distribution Service für Echtzeitsysteme (DDS) Standard von der Object Management Group (OMG). Das Co-Simulationskomponenten-Ladewerk 110 kann eine oder mehrere Datenstrukturen erzeugen, um die Middleware zu nutzen, wie etwa ein Wörterbuch der Nachrichten, die von den ROS-kompatiblen Knoten geteilt werden, welche die ausgewählten Co-Simulationskomponenten ausführen.
HIL/SIL/PIL
Ein realisiertes Modell kann auch beim HIL, SIL und/oder PIL Testen verwendet werden. Beispielsweise kann Code für ein realisiertes Modell generiert werden und der generierte Code kann auf Hardwareressourcen zum Einsatz gebracht werden, wie etwa einer Hardwaretestplattform, welche mit einer Datenverarbeitungsvorrichtung, wie etwa einem Arbeitsplatzrechner, verbunden sein mag. Der generierte Code kann ausgeführt werden und Ergebnisse der Ausführung können dem Arbeitsplatzrechner bereitgestellt werden, zum Beispiel für eine Evaluierung durch einen Benutzer. Die Verwendung von SIL, HIL oder PIL für eine bestimmte Co-Simulationskomponente kann ein Teil der Konfiguration/Partitionierung sein. Beispielsweise könnten Modellkomponenten, welche SIL, HIL oder PIL unterstützen, in einer Co-Simulationskomponente, welche in einem SIL, HIL oder PIL Modus ausgeführt wird, zusammengruppiert werden, auf eine Weise, die ähnlich zu derjenigen ist, die mit der C und HDL Codegenerierung beschrieben wurde.
Integrationsplattform
9 ist eine teilweise, schematische Darstellung einer beispielhaften Integrationsplattform, wie etwa die Integrationsplattform 102, in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die Integrationsplattform 102 kann das Modellpartitionierungswerk 108, das Co-Simulationskomponenten-Ladewerk 110, das Schnittstellenkonfigurationswerk 112 und das Beurteilungswerk 113 beinhalten. Die Integrationsplattform 102 kann auch eine Simulationsumgebung 900 beinhalten. Die Simulationsumgebung 900 kann ein Benutzerschnittstellen- (UI) Werk 902, einen Modelleditor 904, eine Modellelementbibliothek 906, einen Codegenerator 908, einen Compiler 910 und eine Master-Ausführungs-Engine 912 beinhalten. Das UI Werk 902 kann eine oder mehrere Benutzerschnittstellen (Uls), wie etwa graphische Benutzerschnittstellen (GUIs) und/oder Kommandozeilen-Schnittstellen (CLIs), erzeugen und auf der Anzeige eines Arbeitsplatzrechners, Laptops, Tablets oder einer anderen Datenverarbeitungsvorrichtung anzeigen. Die GUIs und CLIs können eine Benutzerschnittstelle zu der Integrationsplattform 102 und/oder der Simulationsumgebung 900 bieten. Die Modellelementbibliothek 906 kann eine Vielzahl von Modellelementtypen enthalten, von denen zumindest einige im Voraus geladen mit der Simulationsumgebung 900 kommen, und wobei einige kundenspezifisch erstellt und in der Bibliothek 906 gespeichert sein können, zum Beispiel durch einen Benutzer. Ein Benutzer kann Modellelementtypen aus der Bibliothek auswählen, um Instanzen der ausgewählten Modellelementtypen einem Modell und/oder einem High-Level-Systemdesign, das entworfen und/oder editiert wird, hinzuzufügen. Der Modelleditor 904 können ausgewählte Operationen an einem Modell vornehmen, wie etwa Öffnen, Erzeugen, Editieren und Speichern, in Antwort auf Benutzereingaben oder programmtechnisch.
Die Master-Ausführungs-Engine 912 kann einen Interpreter 916, einen Modellcompiler 918 und einen oder mehrere Master-Löser, wie etwa Löser 920a-c, beinhalten. Beispielhafte Löser umfassen einen oder mehrere zeitkontinuierliche Löser mit fester Schrittweite, welche numerische Integrationstechniken verwenden können, und einen oder mehrere Löser mit variabler Schrittweite, welche zum Beispiel auf dem Runge-Kutta und Dormand-Prince Paar basieren können. Bei einem Löser mit fester Schrittweite verbleibt die Schrittweite über die Simulation des Modells hinweg konstant. Bei einem Löser mit variabler Schrittweite kann die Schrittweite von einem Schritt zum nächsten variieren, um zum Beispiel Fehlertoleranzen einzuhalten. Eine nicht erschöpfende Beschreibung geeigneter Löser kann im Simulink User's Guide von The MathWorks, Inc. (Ausgabe März 2018) gefunden werden.
Der Modellcompiler 918 kann einen oder mehrere Intermediäre Repräsentation (IR) Bildungseinheiten beinhalten, wie etwa die IR Bildungseinheit 922. In einigen Implementierungen kann ein oder können mehrere IR Bildungseinheiten in den Lösern 920 enthalten oder mit diesen assoziiert sein. Ein oder mehrere der IRs, welche von der IR Bildungseinheit 922 erstellt werden, kann von dem Interpreter 916 verwendet werden, um eine Simulation auszuführen, oder kann von dem Codegenerator 908 verwendet werden, um Code zu generieren, wie etwa den generierten Code 924.
Die Integrationsplattform 102 kann automatisch ein Modell realisieren, wie etwa das realisierte Modell 142, für ein High-Level-Systemdesign, wie etwa das Design 128. Wie beschrieben kann das realisierte Modell 142 ein computerbasiertes, ausführbares Modell sein, wie etwa ein graphisches Modell. Die Master-Ausführungs-Engine 912 kann die Ausführung des realisierten Modells 142 in einer Weise der Co-Simulation ausführen und/oder verwalten.
Der Codegenerator 908 kann Codegenerieren, wie etwa den generierten Code 924, für die Gesamtheit oder einen Teil des realisierten Modells 142. Beispielsweise kann das UI Werk 902 einen Codegenerierungsknopf in einer GUI bereitstellen oder unterstützen, welcher von dem Benutzer ausgewählt werden kann, oder das UI Werk 902 kann einen Codegenerierungsbefehl empfangen, der von dem Benutzer eingegeben wird, zum Beispiel in die GUI oder die CLI. Der Codegenerierungsbefehl kann auch programmtechnisch aufgerufen werden, beispielsweise wenn ein bestimmtes Ereignis auftritt. In Antwort auf die Aktivierung des Codegenerierungsbefehls kann der Codegenerator 908 den Code 924 generieren, für das realisierte Modell 142 oder einen Teil davon. Das Verhalten des generierten Codes 924 kann funktionell dem Verhalten des realisierten Modells 142 oder dem Teil davon äquivalent sein. Beispielhafte Codegeneratoren beinhalten, ohne hierauf beschränkt zu sein, die Produkte Simulink Coder, Embedded Coder und Simulink HDL Coder von The MathWorks, Inc. aus Natick, Massachusetts, und das TargetLink Produkt von dSpace GmbH aus Paderborn Deutschland.
Der generierte Code 924 kann Textcode sein, wie etwa ein textlicher Quellcode, der kompiliert werden kann, zum Beispiel durch den Compiler 910, und auf einer Zielmaschine oder -vorrichtung ausgeführt werden kann, welche keine Simulationsumgebung und/oder kein Modell Ausführungs-Engine aufweisen mag. Der generierte Code 924 kann mit einer oder mit mehreren Programmiersprachen übereinstimmen, wie etwa Ada, Basic, C, C++, C#, SystemC, FORTRAN, VHDL, Verilog, einem hersteller- oder zielspezifischen HDL Code, wie etwa Xilinx FPGA Bibliotheken, Assemblercode, etc. Der generierte Code 924 kann Header-, Main-, make und andere Quelldateien umfassen. Der Compiler 910 kann den generierten Code zur Ausführung durch eine Zielhardware kompilieren, wie etwa einen Mikroprozessor, einen digitalen Signalprozessor (DSP), eine Zentralverarbeitungseinheit (CPU), etc. In einigen Ausführungsformen kann auf den generierten Code 924 zugegriffen werden durch eine Hardwaresynthese-Werkzeugkette, die aus dem generierten Code 924 eine programmierbare Hardwarevorrichtung konfigurieren kann, wie etwa eine feldprogrammierbare Gatterlogik (FPGA), ein System-on-a-Chip (SoC), etc. Das realisierte Modell 142 und der generierte Code 924 können in einem Speicher gespeichert sein, zum Beispiel einem persistenten Speicher, wie etwa eine Festplatte oder ein Flash Speicher, einer Datenverarbeitungsvorrichtung. Die Simulationsumgebung 900 kann in den Hauptspeicher einer Datenverarbeitungsvorrichtung geladen und aus diesem heraus ausgeführt werden.
In einigen Implementierungen kann der Codegenerator 908 und/oder der Compiler 910 separat von der Simulationsumgebung 900 sein, zum Beispiel kann einer oder können beide von diesen separate Anwendungsprogramms sein. Der Codegenerator 908 und/oder der Compiler 910 können auch auf anderen Datenverarbeitungsvorrichtungen als die Datenverarbeitungsvorrichtung, welche die Simulationsumgebung 900 ausführt, ausgeführt werden. In solchen Ausführungsformen kann der Codegenerator 908 auf das realisierte Modell 142 zugreifen, zum Beispiel aus dem Speicher, und den generierten Code 924 generieren, ohne mit der Simulationsumgebung 900 zu interagieren.
Flussdiagramme
10A-D sind teilweise Ansichten eines Flussdiagramms einer beispielhaften Verfahrens in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das Flussdiagramm von 10A-D ist allein,zu beschreibenden Zwecken gedacht. In einigen Ausführungsformen kann ein oder können mehrere Schritte ausgelassen erden, zusätzliche Schritte können hinzugefügt werden, die Reihenfolge der Schritte kann geändert werden und/oder eine oder mehrere Sequenzen, die durch die Pfeile der 10A-D angezeigt sind, können ausgelassen werden.
Die Integrationsplattform 102 kann auf das High-Level-Systemdesign 128 zugreifen, wie gezeigt beim Schritt 1002. Die Integrationsplattform kann auf ein oder mehrere Ziele zum Partitionieren des High-Level-Systemdesigns 128 zum Realisieren eines Modells des High-Level-Systemdesigns 128 zugreifen, wie gezeigt beim Schritt 1004. Die Integrationsplattform 102 kann auf eine oder mehrere Randbedingungen für die Partitionierung zugreifen, wie gezeigt beim Schritt 1006. In einigen Ausführungsformen kann die eine oder können die mehreren Randbedingungen von einem Benutzer spezifiziert werden. Das Modellpartitionierungswerk 108 kann verfügbare Co-Simulationskomponenten und/oder Information, welche verfügbare Modellkomponenten beschreibt, analysieren, um Modellkomponenten zu identifizieren, welche die unterschiedlichen Elemente des High-Level-Systemdesigns 128 simulieren können, wie gezeigt beim Schritt 1008. Das Modellpartitionierungswerk 108 kann eine Entdeckung auf einem oder auf mehreren Computernetzwerken ausführen, wie etwa dem Netzwerk 106, um verfügbare Hardware-, Software- und Kommunikationsressourcen zum Ausführen der identifizierten Co-Simulationskomponenten zu identifizieren, wie gezeigt beim Schritt 1010.
Das Modellpartitionierungswerk 108 kann verschiedene Arrangements der Modellkomponenten betrachten und bestimmen, ob Fehler auftreten können, wenn bestimmte Paare von Modellkomponenten über Co-Simulationspartitionen hinweg miteinander verbunden würden, wie gezeigt beim Schritt 1012. Beispielsweise kann eine Master-Ausführungs-Engine 912 eine Verbindung (zum Beispiel ein Signal) zwischen zwei möglichen Modellkomponenten analysieren, um Verbindungseigenschaften für die Verbindung zu bestimmen. Die Verbindungseigenschaften können eine Zeitbereichsdomäne der Verbindung beinhalten (zum Beispiel eine zeitkontinuierliche Verbindung, ein zeitdiskretes Signal, etc.). Die Master-Ausführungs-Engine 912 kann die modellierte Abtastrate für die Verbindung bestimmen, die eine zeitkontinuierliche oder eine zeitdiskrete Verbindung sein kann, zum Beispiel basierend auf dem Verbindungsparameter, erhalten durch Analysieren der Verbindung. Die Master-Ausführungs-Engine 912 kann eine Kommunikationsrate für die Verbindung bestimmen. Beispielsweise kann die Master-Ausführungs-Engine 912 basierend darauf, dass die Modellkomponenteneigenschaft eine zeitdiskrete Abtastrate einer Modellkomponente anzeigt, welche Daten über die Verbindung ausgibt, bestimmen, dass entlang der Verbindung Daten mit einer zeitdiskreten Rate ausgetauscht werden.
Die Master-Ausführungs-Engine 912 kann bestimmen, dass die modellierte Abtastrate sich von der Kommunikationsrate für die Verbindung unterscheidet. Beispielsweise kann die Master-Ausführungs-Engine 912 das Signal als eine diskret-kontinuierliche Abtastzeit Verbindung identifizieren. Alternativ kann die Master-Ausführungs-Engine 912 identifizieren, dass die Verbindung eine modellierte Abtastrate hat, die sich von der Kommunikationsrate unterscheidet, basierend darauf, dass die modellierte Abtastrate eine andere zeitdiskrete Rate ist als die Kommunikationsrate.
Das Modellpartitionierungswerk 108 kann Kompensationsparameter berechnen, welche Fehler bereinigen, die auftreten können, wenn bestimmte Paare der Modellkomponenten in das realisierte Modell aufgenommen und über Co-Simulationspartitionen hinweg verbunden würden, wie gezeigt beim Schritt 1014 (10B). Die Master-Ausführungs-Engine 912 kann bestimmen, ob ein Fehler eingeführt wird in die Ausführung eines Modells, welches die Modellkomponenten enthält, die evaluiert werden. Die Bestimmung kann darauf basieren, dass die Daten, die über die Verbindung kommuniziert werden, mit der zeitdiskreten Rate ausgetauscht werden, und basierend darauf, dass die Verbindung eine andere modellierte Abtastrate aufweist. Beispielsweise kann die Master-Ausführungs-Engine 912 bestimmen, dass ein Fehler eingeführt wird basierend darauf, dass eine diskret-kontinuierliche Abtastzeit Verbindung identifiziert wird.
Es kann eine Bestimmung gemacht werden, ob ein Zugriff auf Rechenoperationen von einer oder von beiden der Modellkomponenten, die evaluiert werden, möglich ist. Beispielsweise kann die Master-Ausführungs-Engine 912 bestimmen, ob sie einen Zugriff auf Information hat, welche interne Rechenoperationen von einer oder von beiden der Modellkomponenten betreffen, basierend darauf, ob Schnittstellen für die Modellkomponenten die Information verfügbar machen. Falls ja, kann die Master-Ausführungs-Engine 912 über deren Schnittstellen Information erhalten, welche sich auf die Rechenoperationen beziehen, welche von einer oder von beiden der Modellkomponenten angewandt werden.
Das Modellpartitionierungswerk 108 kann eine Zielfunktion auswählen zum Lösen für eine Partition des High-Level-Systemmodells 128, wie gezeigt beim Schritt 1016. Es sei verstanden, dass dieser Schritt optional ist. Beispielsweise kann das Modellpartitionierungswerk 108 eine einzelne Zielfunktion implementieren. Das Modellpartitionierungswerk 108 kann die Zielfunktion aufstellen mit Information über das eine oder die mehreren Ziele, der einen oder den mehreren Randbedingungen, der identifizierten Modellkomponenten, der Hardware, Software und Kommunikationsressourcen des Netzwerks, und der Kompensationsparameter, wie gezeigt beim Schritt 1018. Das Modellpartitionierungswerk 108 kann eine Lösung für die Zielfunktion berechnen, wie gezeigt beim Schritt 1020. Die Lösung der Zielfunktion kann ausgewählte Modellkomponenten enthalten, zum Beispiel die Komponenten 146-149, Co-Simulationspartitionen zwischen den ausgewählten Modellkomponenten, Designationen von Hardware, Software und Kommunikationsressourcen, zum Beispiel Auswahlen 150 und 152, zum Ausführen der ausgewählten Modellkomponenten, Modelleinstellungen, zum Beispiel die Modelleinstellungen 154 und Kompensatoren, zum Beispiel die Kompensatoren 155, zum Beheben von Fehlern über Co-Simulationspartitionen während der Ausführung des Modells in einer Weise der Co-Simulation.
In einigen Ausführungsformen kann das Modellpartitionierungswerk 108 die Berechnung der Lösung ein oder mehrere Male anhalten und pausieren und eine intermediäre Lösung zum Beispiel einem Benutzer anzeigen, wie gezeigt beim Schritt 1022. Das Modellpartitionierungswerk kann die Zielfunktion basierend auf empfangener Information, zum Beispiel von dem Benutzer, überarbeiten, wie gezeigt beim Schritt 1024 (10C). Das Modellpartitionierungswerk 108 kann die Berechnung unter Verwendung der ursprünglichen Zielfunktion wiederaufnehmen, wenn keine Information empfangen wurde, oder mit einer überarbeiteten Zielfunktion, wie gezeigt beim Schritt 1026.
Das Modellpartitionierungswerk 108 kann die Lösung verwenden, um ein Modell für das High-Level-Systemdesign 128 zu realisieren, wie etwa das Modell 142, wie gezeigt beim Schritt 1028. Das realisierte Modell 142 kann die ausgewählten Modellkomponenten, Co-Simulationspartitionen und Kompensatoren zum Beheben von Fehlern während der Ausführung des Modells in einer Weise der Co-Simulation. Das realisierte Modell kann zum Beispiel in einem Modelleditorfenster, das von dem UI Werk 902 erzeugt wird, dargestellt werden, wie gezeigt beim Schritt 1029. Das Co-Simulationskomponenten-Ladewerk 110 kann die ausgewählten Modellkomponenten auf die Hardwareressourcen des Netzwerks 106 laden, die in der Lösung für die Zielfunktion identifiziert wurden, wie gezeigt beim Schritt 1030.
Das Schnittstellenkonfigurationswerk 112 kann Kompensatoren, welche in der Lösung für die Zielfunktion identifiziert werden, an Schnittstellen zwischen den Co-Simulationspartitionen einfügen, wie gezeigt beim Schritt 1032 (10D). In einigen Implementierungen kann das Schnittstellenkonfigurationswerk 112 automatisch einen Typ von zu generierendem Kompensator auswählen, um den Kompensator basierend auf Modellinformation, dem Fehler und/oder der Art des Kompensators zu erzeugen. Zusätzlich oder alternativ kann das Schnittstellenkonfigurationswerk 112 Information präsentieren (zum Beispiel anzeigen), welche den automatisch bestimmten Ort der Kompensation einem Benutzer angibt, dem Benutzer Information geben, welche unterschiedliche Arten an Kompensatoren anzeigen, aus denen ausgewählt werden kann, und/oder einen benutzerdefinierten Kompensator über eine Benutzereingabe empfangen, und einen zu verwendenden Kompensator basierend auf der Benutzereingabe auszuwählen.
Das Schnittstellenkonfigurationswerk 112 kann einen Ort für einen Kompensator bestimmen, wie etwa zwischen den zwei Co-Simulationskomponenten, die evaluiert werden (zum Beispiel explizite Kompensation). In einigen Implementierungen kann eine explizite Kompensation bestimmt werden, wenn Information bezüglich der Rechenoperationen einer Ziel-Co-Simulationskomponente (zum Beispiel eine Co-Simulationskomponente, welche die Daten über die Verbindung von einer anderen Co-Simulationskomponente empfängt) nicht verfügbar ist. Wenn ein Ort der Kompensation bestimmt wird, innerhalb einer Co-Simulationskomponente zu sein, kann das Schnittstellenkonfigurationswerk 112 weiter das Erzeugen einer Callback Funktion (zum Beispiel einer Kompensation Callback Funktion), welche es einer Master-Ausführungs-Engine erlaubt, einen Kompensator in die Co-Simulationskomponente hinein einzufügen, beinhalten. Und von diesem kann die Information (welche potentiell ein Flag beinhalt, welches angibt, dass es eine zu verwendende Callback Funktion gibt) für die Co-Simulationskomponente dann mit einer anderen Datei geteilt werden (zum Beispiel als eine XML Repräsentation/Datei). Das Schnittstellenkonfigurationswerk 112 kann ein Bedürfnis für die Kompensation Callback Funktion bestimmen basierend darauf, ob eine inhärente Kompensation bestimmt ist.
Das Schnittstellenkonfigurationswerk 112 kann mittels dem Callback einen Kompensator in das realisierte Modell einfügen. Beispielsweise kann das Schnittstellenkonfigurationswerk 112 den Kompensator in eine Co-Simulationskomponente einfügen, indem der Kompensator in die Callback eingefügt wird, wenn die Callback Funktion aufgerufen wird.
Die Integrationsplattform 102 kann das realisierte Modell in einer Weise der Co-Simulation ausführen, wie gezeigt beim Schritt 1034. Während der Ausführung kann die Integrationsplattform 102 dynamisch eine Schrittweite einer Kommunikationsrate entlang einer Verbindung mit diskret-kontinuierlicher Abtastrate aktualisieren. Beispielsweise kann die Integrationsplattform 102 ein realisiertes Modell ausführen, welches Co-Simulationskomponenten enthält, die über eine Verbindung verbunden sind. In einigen Implementierungen kann die Verbindung eine Verbindung mit diskret-kontinuierlicher Abtastrate sein und das Modell kann Daten von der ersten Co-Simulationskomponente zu der zweiten Co-Simulationskomponente über die Verbindung zu Kommunikationsschritten mit einer Schrittweite kommunizieren. Bei jedem Kommunikationszeitschritt wird eine Kompensation durch einen Kompensator angewandt, welche einen Fehler kompensiert, der während der Ausführung des Modells in Verbindung mit dem Ausführen des Modells in einer Weise der Co-Simulation aufgetreten ist.
Die Integrationsplattform 102 kann dynamisch einen Fehler überwachen, der während der Ausführung des realisierten Modells auftritt. Der überwachte Fehler kann den Fehler beinhalten, der während der Ausführung des Modells in Verbindung mit dem Ausführen des Modells in einer Weise der Co-Simulation aufgetreten ist (zum Beispiel der Fehler, der in die Ausführung des realisierten Modells eingeführt wird, der darauf basiert, dass die Daten über die Verbindung mit der zeitdiskreten Rate kommuniziert werden, und dass die Verbindung als die zeitkontinuierliche Verbindung oder mit einer anderen zeitdiskreten Rate deklariert ist). Zusätzlich oder alternativ kann der Fehler ein akkumulierter Fehler sein, der verbleibt, nachdem die Kompensation angewandt wurde und der sich über Phasen der Ausführung akkumuliert.
Die Integrationsplattform 102 kann dynamisch eine Sensitivitätsanalyse einer Co-Simulationskomponente ausführen. Eine Sensitivitätsanalyse kann bestimmen, wie eine Unsicherheit in einer Ausgabe einer Co-Simulationskomponente einer Unsicherheit in der Eingabe der Co-Simulationskomponente zugeordnet werden kann. Wenn die Sensitivitätsanalyse ausgeführt wird, kann die Integrationsplattform 102 bestimmen, wie sehr eine Änderung einer Eingabe einer Co-Simulationskomponente die Ausgabe der Co-Simulationskomponente beeinflusst. Basierend auf der Sensitivitätsanalyse kann mit der Zeit eine dynamische Sensitivität der Verbindung bestimmt werden, basierend darauf, wie sensitiv die Co-Simulationskomponenten sind, die durch die Verbindung verbunden sind.
Die Master-Ausführungs-Engine 912 kann dynamisch eine Schrittweite einer Kommunikationsrate entlang einer Verbindung zwischen Co-Simulationskomponenten aktualisieren. Die Master-Ausführungs-Engine 912 kann basierend auf der Sensitivitätsanalyse und/oder dem Fehler eine Schrittweite der Kommunikationsrate von Daten entlang der Verbindung in dem Modell aktualisieren. In einigen Implementierungen kann, wenn die Sensitivität der Verbindung mit der Zeit zunimmt, die Schrittweite der Kommunikationsrate verringert werden, um die Möglichkeit eines Fehlers oder einer Ungenauigkeit in der Simulation zu verringern. Andererseits kann, wenn die Sensitivität der Verbindung mit der Zeit abnimmt, die Schrittweite der Kommunikationsrate erhöht werden, um Prozessorressourcen, die zum Ausführen des Modells erforderlich sind, zu verringern. Zusätzlich oder alternativ kann, wenn der überwachte Fehler mit der Zeit zunimmt, die Schrittweite der Kommunikationsrate verringert werden, um den Fehler zu verringern. Andererseits kann, wenn der überwachte Fehler mit der Zeit abnimmt, die Schrittweite der Kommunikationsrate erhöht werden, um Prozessorressourcen, die zum Ausführen des Modells erforderlich sind, zu verringern.
Zusätzlich oder alternativ kann die Master-Ausführungs-Engine 912 eine Schwellwertsensitivität für eine Verbindung setzen. Wenn die Sensitivitätsanalyse anzeigt, dass die Sensitivität der Verbindung die Schwellwertsensitivität erfüllt oder überschreitet, kann die Master-Ausführungs-Engine die Schrittweite der Kommunikationsrate verringern (oder erhöhen). Ähnlich kann, wenn der überwachte Fehler einen Schwellwertfehler erfüllt oder überschreitet, die Master-Ausführungs-Engine 912 die Schrittweite der Kommunikationsrate verringern (oder erhöhen).
Zusätzlich oder alternativ kann die Schrittweite der Kommunikationsrate iterative angepasst werden. Beispielsweise kann die Schrittweite für die Kommunikationsrate iterativ erhöht oder verringert werden, bi seine gewünschte Sensitivität (zum Beispiel eine minimale Sensitivität) und/oder eine Schwellwertsensitivität für die Verbindung erreicht wird. In einigen Implementierungen kann die Schrittweite der Kommunikationsrate bestimmt werden basierend auf der Sensitivitätsanalyse einer vorhergehenden Schrittweiten-Sensitivitätsanalyse.
Das Beurteilungswerk 113 kann die Ausführung des realisierten Modells evaluieren, zum Beispiel in Begriffen der Ziele 130, wie gezeigt beim Schritt 1036. Es kann eine Bestimmung getroffen werden, ob das realisierte Modell die Ziele 130 erfüllt, wie beim Entscheidungsschritt 1038 angegeben. Die Bestimmung kann eine Benutzereingabe involvieren. Beispielsweise kann ein Benutzer bestimmen, ob die Ziele erfüllt sind. Falls nicht, können Modifikationen an dem High-Level-Systemdesign 128 vorgenommen, neue oder überarbeitete Ziele spezifiziert und/oder neue oder überarbeitete Randbedingungen gesetzt werden, wie bei dem Nein Pfeil 1040, der zu Schritt 1042 führt, angezeigt. Die Verarbeitung kann dann zum Schritt 1002 zurückkehren, und es kann eine neue Lösung und ein neues realisiertes Modell automatisch generiert werden, wie bei dem Gehe Zu Schritt 1044 angezeigt.
Wenn das realisierte Modell die Ziele erfüllt, zum Beispiel zur Zufriedenheit des Benutzers, dann mag die Verarbeitung beendet sein, wie durch den Ja Pfeil 1046 angezeigt, der zu dem Erledig Schritt 1048 führt.
Wie bemerkt, kann die vorliegende Offenbarung, neben dem High-Level-Systemdesign 128 von 1 und der funktionellen Struktur 200 von 2, mit anderen High-Level-Systemdesigns und Funktionsmodellen verwendet werden.
14 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur 1400 eines Systemdesigns in einer Übersicht für ein Flugsicherungs- („air traffic control“, ATC) Radarsystem in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die funktionelle Struktur 1400 kann graphisch definiert sein und kann Elemente beinhalten, welche Systeme und/oder Subsysteme des ATC Radarsystems repräsentieren. Beispielsweise kann die funktionelle Struktur 1400 ein Icon 1402 für eine Radareinheit, ein Icon 1404 für ein Flugzeug und ein Icon 1406 für das Wetter beinhalten. Die funktionelle Struktur 1400 kann auch Icons für Anzeigen oder Oszilloskope aufweisen, wie etwa Oszilloskopblöcke 1408 und 1410 mit Namen ‚Flugzeugentfernung‘ und ‚Gewünschte SNR?‘ und einen Multiplexer Block 1412. In einigen Ausführungsformen mag die funktionelle Struktur 1400 selbst nicht ausführbar sein, um das Verhalten oder die Operation des ATC Radarsystems zu simulieren. Stattdessen kann die funktionelle Struktur 1400 eine Angabe der Elemente bereitstellen, die notwendig sind, um ein ATC Radarsystem zu entwerfen, zu testen oder zu implementieren. In einigen Ausführungsformen können die Icons 1402, 1404 und 1406 Platzhalter für ausführbare Modellkomponenten sein, und mögen nicht selbst ausführbare Komponenten sein. Die funktionelle Struktur 1400 kann daher unabhängig vom Software-Simulationswerkzeug und unabhängig von der Modellkomponente sein.
Die funktionelle Struktur 1400 kann auch Symbole beinhalten, welche Daten, Steuer- oder andere Information repräsentieren, welche unter den Elementen des High-Level-Systemdesigns ausgetauscht werden. Beispielsweise kann sie Pfeile 1414 und 1416 zwischen den Icons 1404, 1406 und 1402 aufweisen, welche anzeigen, dass das Radarelement als Eingabe auf die Ausgaben zugreift, die von dem Flugzeug- und dem Wetterelement berechnet werden. Die funktionelle Struktur 1400 kann auch Pfeile 1418 und 1420 zwischen dem Icon 1402, dem Multiplexer 1412 und dem Oszilloskopblock 1408 beinhalten, welche anzeigen, dass eine Ausgabe, die von dem Radarelement berechnet wird, bei dem Oszilloskopblock 1408 angezeigt wird. Die funktionelle Struktur 1400 kann weiter einen Pfeil 1422 zwischen den Icons 1402 und 1404 beinhalten, welcher anzeigt, dass eine Ausgabe, die von dem Radarelement berechnet wird, von dem Flugzeugelement 1404 als eine Eingabe gelesen wird. Die funktionelle Struktur 1400 kann auch Pfeile 1424 und 1426 zwischen den Icons 1402 und 1406 beinhalten, welche anzeigen, dass Ausgaben, die von dem Radarelement berechnet werden, von dem Wetterelement als Eingaben gelesen werden. Die Form der Daten, Steuer- oder anderer Information, die zwischen Elementen des High-Level-Systemdesigns wie durch die funktionelle Struktur 1400 repräsentiert ausgetauscht werden, kann abhängig von den Modellkomponenten, die verwendet werden, um die jeweiligen Elemente zu implementieren, und der Co-Simulations-Partitionierung des Designs variieren.
Wie beschrieben können die Icons 1402, 1404 und 1406 Platzhalter für ausführbare Modellkomponenten sein. Beispielsweise kann das High-Level-Systemdesign unter anderem ein Uniform Modeling Language (UML) Diagramm oder ein Systems Modeling Language (SysML) Diagramm sein. In anderen Ausführungsformen kann ein oder können mehrere der Icons 1402, 1404 und 1406 ausführbare Modellkomponenten eines spezifischen Softwaresimulationswerkzeugs repräsentieren. In einigen Implementierungen kann ein oder können mehrere der Icons 1402, 1404 und 1406 zum Beispiel Modellreferenzblöcke, Subsysteme, Virtuelle Instrumente (VIs), und/oder Varianten der Simulink modellbasierten Designumgebung, „Functional Mock-up Units“ (FMUs), dynamisch verlinkbare Bibliotheken (DLLs), etc. sein.
15 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation 1500 der High-Level-Systemdesign für das ATC Radarsystem in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die graphische Repräsentation 1500 zeigt die Teilmengen der aufgefundenen Modellkomponenten zum Modellieren der Elemente des High-Level-Systemdesigns für das ATC Radarsystem. Das Radarelement kann beispielsweise durch drei alternative Modellkomponenten simuliert werden, welche beim Icon 1402 durch Blöcke 1502-1504 repräsentiert sind, die mit ‚A‘, ‚B‘ und ‚C‘ bezeichnet sind. Das Flugzeugelement kann durch zwei alternative Modellkomponenten simuliert werden, welche an dem Icon 1404 repräsentiert sind durch Blöcke 1506 und 1508, die mit ‚D‘ und ‚E‘ bezeichnet sind. Das Wetterelement kann durch zwei alternative Modellkomponenten simuliert werden, welche bei dem Icon 1406 durch Blöcke 1510 und 1512, die mit ‚F‘ und ‚G‘ bezeichnet sind, repräsentiert sind.
In einigen Ausführungsformen kann die Integrationsplattform 102 die funktionelle Struktur 1400 und/oder die graphische Repräsentation 1500 anzeigen, zum Beispiel in dem Modelleditorfenster 220.
Die alternativen Modellkomponenten, welche ein gegebenes Element des High-Level-Systemdesigns für das ATC Radarsystem simulieren, können in unterschiedlichen Formen vorliegen und können unterschiedliche Eigenschaften und/oder Attribute aufweisen. Wie beschrieben können die unterschiedlichen Eigenschaften und/oder Attribute Simulationspräzision, Speichernutzung, Ausführungsgeschwindigkeit und/oder Toleranz beinhalten.
Ein oder mehrere Modelle können für die funktionelle Struktur 1400 und/oder die graphische Repräsentation 1500 für das ATC Radarsystem realisiert werden. Beispielsweise kann eine Zielfunktion aufgestellt werden, die Benutzerziele berücksichtigt, welche Benutzerziele berücksichtigt, welche Wert legen auf eines oder mehrere von Simulationspräzision, Speichernutzung, Ausführungsgeschwindigkeit und/oder Toleranz. Die Zielfunktion kann durch den Zielfunktions-Löser 126 gelöst werden. Die Lösung kann ausgewählte Modellkomponenten identifizieren, um die Elemente des High-Level-Systemdesigns für das ATC Radarsystem zu implementieren, die Co-Simulationspartitionen, die Knoten 140 des Computernetzwerks, die Simulationswerkzeuge und -versionen, Kommunikationsraten und Kompensatoren.
Es sei angenommen, dass beispielsweise die Ziele 130, welche von dem Benutzer spezifiziert wurden, ein hohes Gewicht auf die Simulationspräzision legen, im Vergleich zur Ausführungsgeschwindigkeit und Speichernutzung. Das Modellpartitionierungswerk 108 kann automatisch ein Co-Simulationsmodell für das High-Level-Systemdesign für das ATC Radarsystem realisieren, das eine Lösung der Zielfunktion, wie durch den Zielfunktions-Löser 126 berechnet, wobei dem Ziel Präzision eine hohe Gewichtung gegeben ist relative zu den anderen Zielen, repräsentiert. Die Lösung, welche von dem Zielfunktions-Löser 126 bestimmt wurde, kann vorsehen, dass die Verbindungen in dem High-Level-Systemdesign für eine Entität getrennt werden sollten, wodurch zwei Co-Simulationspartitionen 1514 und 1516 erzeugt werden. Beispielsweise kann die Lösung vorsehen, dass eine oder mehrere Modellkomponenten für das Radarelement und das Flugzeugelement in eine Co-Simulationspartition platziert werden sollten, zum Beispiel die Partition 1514 und dass eine oder mehrere Modellkomponenten für das Wetterelement in eine andere Co-Simulationspartition platziert werden sollten, zum Beispiel die Partition 1516. Dementsprechend kann die Lösung vorsehen, dass Schnitte an den Verbindungen, die durch die Pfeile 1416, 1424 und 1426 zwischen dem Radar- und dem Wetterelement 1402 und 1406 repräsentiert sind, vorgenommen werden sollten. Zusätzlich kann der Zielfunktions-Löser 126 bestimmen, dass aus der Menge von verfügbaren Modellkomponenten das Modell die Modellkomponenten enthalten sollte, welche dem Block 1503 (‚B‘) für das Radarelement entsprechen, die Modellkomponente des Blocks 1506 (‚D‘) für das Flugzeugelement und die Modellkomponente des Blocks 1512 (‚G‘) für das Wetterelement.
Die Lösung kann weiter vorsehen, dass die Partition 1514 von einem Simulationswerkzeug ausgeführt werden sollte, wie etwa der Simulink® Simulationsumgebung, auf einem Knoten des Computernetzwerks 106. Die Lösung kann auch vorsehen, dass die Partition 1516 durch ein anderes Simulationswerkzeug ausgeführt werden soll, wie etwa dem Weather Radar Simulation System (WRSS) von Rockwell Collins aus Cedar Rapids, Iowa. An den Schnitten, die in dem High-Level-Systemdesign vorgenommen wurden, können Schnittstellen eingerichtet werden. Beispielsweise kann die Lösung eine oder mehrere Schnittstellen zwischen den Partitionen 1514 und 1516 definieren.
Die Lösung, die von dem Zielfunktions-Löser 126 bestimmt wurde, kann Information zum Konfigurieren der Co-Simulationspartitionen 1514 und 1516 beinhalten. Die Information kann lokale Ausführungs-Engines und/oder Löser identifizieren, welche zu verwenden sind von den Simulationswerkzeugen, welche die jeweiligen Partitionen 1514 und 1516 ausführen. Die Information kann die Schrittweiten angeben, welche von den lokalen Ausführungs-Engines und/oder Lösern zu verwenden sind, und lokale Löserparameter, wie etwa relative und absolute Toleranz, Schrittweite, etc.
Die Lösung, die von dem Zielfunktions-Löser 126 bestimmt wurde, kann weiter Information zum Konfigurieren der Schnittstellen zwischen Modellkomponenten, die in unterschiedliche Co-Simulationspartitionen platziert wurden, enthalten. Beispielsweise kann die Lösung Information zum Konfigurieren der Schnittstelle zwischen Modellkomponenten 1503 (‚B‘) und 1512 (‚G‘) in den Co-Simulationspartitionen 1514 und 1516 enthalten. Die Information kann sich auf Kompensatoren beziehen, wie etwa den Ort von und Parameter für Kompensatoren.
In einem anderen Beispiel können die Ziele 130 ein hohes Gewicht auf die Ausführungsgeschwindigkeit legen. In diesem Fall kann eine Lösung der Zielfunktion in einer anderen Partitionierung des High-Level-Systemdesigns für das ATC Radarsystem resultieren, und einer anderen Auswahl von Modellkomponenten für das Radarelement, das Flugzeugelement und das Wetterelement.
Darüber hinaus können Unterschiede zwischen den Kommunikationsraten von Daten zwischen Co-Simulationskomponenten und modellierten Abtastraten, falls existent, identifiziert werden. In einigen Ausführungsformen können diese Komponenten in dieselbe Partition platziert werden. Zusätzlich oder alternativ kann ein oder können mehrere Kompensatoren inkludiert werden.
Die vorliegende Offenbarung kann auch mit Fabrikautomatisierungssystemen verwendet werden.
16 ist eine schematische Darstellung einer beispielhaften funktionellen Struktur 1600 eines Systemdesigns in einer Übersicht für ein Fabrikautomatisierungssteuer- und/oder - regelsystem in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die funktionelle Struktur 1600 kann graphisch definiert sein und kann Elemente enthalten, welche Systeme und/oder Subsysteme des Fabrikautomatisierungssteuer- und/oder -regelsystems zu repräsentieren. Beispielsweise kann die funktionelle Struktur 1600 ein Icon 1602 für eine Steuer- und/oder Regeleinheit, ein Icon 1604 für einen Roboterarm und ein Icon 1606 für ein Controller Area Netzwerk (CAN) Buselement enthalten. In einigen Ausführungsformen mag die funktionelle Struktur 1600 selbst nicht ausführbar sein, um das Verhalten oder den Betrieb des Fabrikautomatisierungssteuer- und/oder -regelsystems zu simulieren. Stattdessen mag die funktionelle Struktur 1600 eine Angabe der Elemente bereitstellen, die erforderlich sind, um ein Fabrikautomatisierungssteuer- und/oder -regelsystem zu entwerfen, zu testen oder zu implementieren. In einigen Ausführungsformen können die Icons 1602, 1604 und 1606 Platzhalter für ausführbare Modellkomponenten sein, und mögen selbst keine ausführbaren Komponenten sein. Die funktionelle Struktur 1600 kann somit Softwaresimulationswerkzeugunabhängig und Modellkomponenten-unabhängig sein.
Die funktionelle Struktur 1600 kann auch Symbole enthalten, welche Daten, Steuer- oder andere Information repräsentieren, welche zwischen den Elementen des High-Level-Systemdesigns ausgetauscht werden. Beispielsweise kann sie Pfeile 1608 und 1610 zwischen den Icons 1602 und 1604 enthalten, welche angeben, dass Ausgaben, die von dem Steuer- und/oder Regelelement berechnet werden, von dem Roboterarmelement als Eingänge gelesen werden. Die funktionelle Struktur 1600 kann auch Pfeile 1612 und 1614 zwischen den Icons 1604, 1606 und 1602 enthalten, die anzeigen, das eine Ausgabe, die von dem Roboterarm berechnet wird, von dem CAN Buselement gelesen wird, und dass eine Ausgabe des CAN Buselements von dem Steuergerätelement gelesen werden kann. Die Form der Daten, Steuer- oder anderen Information, welche zwischen Elementen des High-Level-Systemdesigns, wie durch die funktionelle Struktur 1600 repräsentiert, ausgetauscht werden, kann abhängig von den Modellkomponenten, die verwendet werden, um die jeweiligen Elemente und die Co-Simulations-Partitionierung des Designs zu implementieren, variieren.
Wie beschrieben können die Icons 1602, 1604 und 1606 Platzhalter für ausführbare Modellkomponenten sein. In anderen Ausführungsformen kann eines oder können mehrere der Icons 1602, 1604 und 1606 ausführbare Modellkomponenten eines spezifischen Softwaresimulationswerkzeugs repräsentieren.
17 ist eine schematische Darstellung einer beispielhaften graphischen Repräsentation 1700 des High-Level-Systemdesigns für das Fabrikautomatisierungssteuer- und/oder -regelsystem in Übereinstimmung mit einer oder mit mehreren Ausführungsformen.
Die graphische Repräsentation 1700 zeigt die Teilmengen von aufgefundenen Modellkomponenten, um die Elemente des High-Level-Systemdesigns für das Fabrikautomatisierungssteuer- und/oder -regelsystem zu modellieren. Beispielsweise kann Steuergerätelement durch zwei alternative Modellkomponenten simuliert werden, welche bei dem Icon 1602 durch den Block 1702 mit Bezeichnung ‚A‘ und den Block 1704 mit Bezeichnung ‚B‘ repräsentiert sind. Das Roboterarmelement kann durch zwei alternative Modellkomponenten simuliert werden, die bei dem Icon 1604 durch den Block 1706 mit Bezeichnung ‚C‘ und den Block 1708 mit Bezeichnung ‚D‘ repräsentiert sind. Das CAN Buselement kann durch drei alternative Modellkomponenten simuliert werden, die bei dem Icon 1606 durch die Blöcke 1710-1712 mit Bezeichnung ‚E‘, ‚F‘ und ‚G‘ repräsentiert sind.
In einigen Ausführungsformen kann die Integrationsplattform 102 die funktionelle Struktur 1600 und/oder die graphische Repräsentation 1700 anzeigen, zum Beispiel auf dem Modelleditorfenster 220.
Die alternativen Modellkomponenten, welche ein gegebenes Element des High-Level-Systemdesigns für das Fabrikautomatisierungssteuer- und/oder -regelsystem simulieren, können in unterschiedlichen Formen vorliegen und können unterschiedliche Eigenschaften und/oder Attribute aufweisen. Wie beschrieben können die unterschiedlichen Eigenschaften und/oder Attribute Simulationspräzision, Speichernutzung, Ausführungsgeschwindigkeit und/oder Toleranz beinhalten.
Es können für die funktionelle Struktur 1600 und/oder die graphische Repräsentation 1700 für das Fabrikautomatisierungssteuer- und/oder -regelsystem ein oder mehrere Modelle realisiert werden. Beispielsweise kann eine Zielfunktion aufgestellt werden, welche Benutzerziele berücksichtigt, welche Wert legen auf eines oder mehrere von Simulationspräzision, Speichernutzung, Ausführungsgeschwindigkeit und/oder Toleranz. Die Zielfunktion kann von dem Zielfunktions-Löser 126 gelöst werden. Die Lösung kann ausgewählten Modellkomponenten identifizieren, um die Elemente des High-Level-Systemdesigns für das Fabrikautomatisierungssteuer- und/oder -regelsystem zu implementieren, Co-Simulationspartitionen, Knoten 140 des Computernetzwerks, Simulationswerkzeuge und -versionen, Kommunikationsraten, und Kompensatoren.
Es sei angenommen, dass beispielsweise die Ziele 130, welche von dem Benutzer spezifiziert wurden, ein hohes Gewicht auf die Ausführungsgeschwindigkeit legen, im Vergleich zu Simulationspräzision und Speichernutzung. Das Modellpartitionierungswerk 108 kann automatisch ein Co-Simulationsmodell für das High-Level-Systemdesign für das Fabrikautomatisierungssteuer- und/oder -regelsystem realisieren, welches eine Lösung der Zielfunktion repräsentiert, wie von dem Zielfunktions-Löser 126 berechnet, wobei dem Ziel Ausführungsgeschwindigkeit eine höhere Gewichtung gegeben wurde als den anderen Zielen. Die von dem Zielfunktions-Löser 126 bestimmte Lösung kann vorsehen, dass das High-Level-Systemdesign für eine Entität getrennt werden sollte, wodurch zwei Co-Simulationspartitionen 1716 und 1718 geschaffen werden. Beispielsweise kann die Lösung vorsehen, dass ein oder mehrere Modellkomponenten für das Steuergerätelement und das CAN Buselement in eine Co-Simulationspartition platziert werden sollten, zum Beispiel die Partition 1716, und dass eine oder mehrere Modellkomponenten für das Roboterarmelement in eine andere Co-Simulationspartition platziert werden sollten, zum Beispiel die Partition 1718. Dementsprechend kann die Lösung vorsehen, dass ein Schnitt an den Verbindungen gemacht werden sollte, die durch die Pfeile 1608 und 1610 zwischen dem Steuer- und/oder Regelelement und Roboterarmelement repräsentiert sind, und dass ein anderer Schnitt an der Verbindung gemacht werden sollte, welche durch den Pfeil 1612 zwischen dem Roboterarmelement und dem CAN Buselement repräsentiert ist. Zusätzlich kann der Zielfunktions-Löser 126 bestimmen, dass das Modell aus der Menge von verfügbaren Modellkomponenten die Modellkomponenten enthalten sollte, welche dem Block 1704 (‚B‘) für das Steuergerätelement entsprechen, die Modellkomponente des Blocks 1706 (‚C‘) für das Roboterarmelement, und die Modellkomponente des Blocks 1712 (‚E‘) für das CAN Buselement.
Die Lösung kann weiter vorsehen, dass die Partition 1716 von einem Simulationswerkzeug ausgeführt werden sollte, wie etwa der Simulink® Simulationsumgebung, auf einem Knoten des Computernetzwerks 106. Die Lösung kann auch vorsehen, dass die Partition 1718 von einem anderen Simulationswerkzeug ausgeführt werden sollte, wie etwa der RoboDK Simulationsumgebung von RoboDK Inc. aus Montreal, Kanada. An den Schnitten, die in dem High-Level-Systemdesign ausgeführt wurden, können Schnittstellen errichtet werden. Beispielsweise kann die Lösung eine oder mehrere Schnittstellen zwischen den Partitionen 1716 und 1718 definieren.
Die von dem Zielfunktions-Löser 126 berechnete Lösung kann Information zum Konfigurieren der Co-Simulationspartitionen 1716 und 1718 beinhalten. Die Information kann lokale Ausführungs-Engines und/oder Löser identifizieren, welche von den Simulationswerkzeugen, welche in den jeweiligen Partitionen 1716 und 1718 ablaufen, ausgeführt werden sollen. Die Information kann die Schrittweiten angeben, welche von den lokalen Ausführungs-Engines und/oder Lösern zu verwenden sind, sowie lokale Löserparameter, wie etwa relative und absolute Toleranz, Schrittweite, etc.
Die von dem Zielfunktions-Löser 126 bestimme Lösung kann weiter Information zum Konfigurieren der Schnittstellen zwischen Modellkomponenten, die in unterschiedliche Co-Simulationspartitionen platziert sind, enthalten. Beispielsweise kann die Lösung Information zum Konfigurieren der Schnittstelle zwischen den Modellkomponenten 1704 (‚B‘) und 1706 (‚C‘) und zwischen den Modellkomponenten 1706 (‚C‘) und 1712 (‚E‘) enthalten. Die Information kann sich auf Kompensatoren beziehen, wie etwa den Ort von und Parameter für Kompensatoren.
In einem anderen Beispiel mögen die Ziele 130 ein hohes Gewicht auf die Speichernutzung legen. In diesem Fall kann eine Lösung der Zielfunktion in einer anderen Partitionierung des High-Level-Systemdesigns für das Fabrikautomatisierungssteuer- und/oder -regelsystem resultieren, sowie einer anderen Auswahl von Modellkomponenten für das Steuergerätelement, das Roboterarmelement und das CAN Buselement.
Darüber hinaus können Unterschiede, falls vorhanden, zwischen der Datenkommunikationsrate zwischen Co-Simulationskomponenten und modellierten Abtastraten identifiziert werden. In einigen Ausführungsformen können diese Komponenten in dieselbe Partition platziert sein. Zusätzlich oder alternativ kann ein oder können mehrere Kompensatoren enthalten sein.
Datenverarbeitungsvorrichtung
11 ist eine schematische Darstellung eines beispielhaften Computer- oder Datenverarbeitungssystems 1100, in welchem Systeme und/oder Verfahren der vorliegenden Offenbarung implementiert werden können in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Das Computersystem 1100 kann ein oder mehrere Prozessorelemente, wie etwa einen Prozessor 1102, einen Hauptspeicher 1104, eine Benutzereingabe/-ausgabe (I/O) 1106, eine persistente Datenspeichereinheit, wie etwa ein Plattenlaufwerk 1108, und ein Wechselmedienlaufwerk 1110 beinhalten, welche über einen Systembus 1112 miteinander verbunden sind. Das Computersystem 1100 kann auch eine Kommunikationseinheit enthalten, wie etwa eine Netzwerkschnittstellenkarte (NIC) 1114. Die Benutzereingabe/-ausgabe 1106 kann eine Tastatur 1116, eine Zeigervorrichtung, wie etwa eine Maus 1118, und eine Anzeige 1120 beinhalten. Andere Benutzereingabe-/-ausgabekomponenten beinhalten Stimm- oder Sprachbefehlssysteme, Berührungsfelder und Berührungsbildschirme, Drucker, Projektoren, etc. Beispielhafte Prozessoren beinhalten einkernige oder mehrkernige Zentralverarbeitungseinheiten (CPUs), Graphikverarbeitungseinheiten (GPUs), feldprogrammierbare Gatterlogiken (FPGAs), anwendungsspezifische integrierte Schaltungen (ASICs), Mikroprozessoren, Mikrocontroller, etc.
Der Hauptspeicher 1104, der ein Speicher mit wahlfreiem Zugriff (RAM) sein kann, kann eine Vielzahl von Programmbibliotheken und -modulen speichern, wie etwa ein Betriebssystem 1122, und ein oder mehrere Anwendungsprogramme, welche mit dem Betriebssystem 1122 interagieren, wie etwa die Integrationsplattform 102.
Das Wechselmedienlaufwerk 1110 kann ein computerlesbares Medium 1126 aufnehmen und lesen, wie etwa eine CD, eine DVD, eine Diskette, ein Halbleiterlaufwerk, ein Band, einen Flashspeicher oder ein andere nichttransitorisches Medium. Das Wechselmedienlaufwerk 1110 kann auch auf das computerlesbare Medium 1126 schreiben.
Geeignete Computersysteme beinhalten PCs, Arbeitsplatzrechner, Server, Laptops, Tablets, handgehaltene Computer, Smartphones, elektronische Lesegeräte und andere tragbare Computervorrichtungen, etc. Die Fachleute werden dennoch verstehen, dass das Computersystem 1100 von 11 lediglich zur Veranschaulichung gedacht ist, und dass die vorliegende Erfindung mit anderen Computer-, Datenverarbeitungs- oder Rechnersystemen und -vorrichtungen genutzt werden kann. Die vorliegende Erfindung kann auch in einem Computernetzwerkarchitektur verwendet werden, zum Beispiel eine Client-Server Architektur, oder einer öffentlichen und/oder privaten Cloudrechenanordnung. Beispielsweise kann die Simulationsumgebung 1100 auf einem oder auf mehreren Cloudservern oder - Vorrichtungen gehostet werden und es kann auf sie durch entfernte Clients über ein Webportal oder ein Anwendungs-Hosting-System, wie etwas das Remote Desktop Verbindungswerkzeug von Microsoft Corp., zugegriffen werden.
Geeignete Betriebssysteme 1122 beinhalten unter anderem die Windows Reihe von Betriebssystemen von Microsoft Corp. aus Redmond, Washington, die Android und Chrome OS Betriebssysteme von Google Inc. aus Mountain View, Kalifornien, das Linux Betriebssystem, die MAC OS® Reihe von Betriebssysteme von Apple Inc. aus Cupertino, Kalifornien, und die UNIX® Reihe von Betriebssysteme. Das Betriebssystem 1122 kann Dienste oder Funktionen für Anwendungen und Module bereitstellen, wie etwa das Allozieren von Speicher, Organisieren von Datenobjekten oder Dateien gemäß einem Dateisystem, Priorisieren von Anforderungen, Verwalten von I/O, etc. Das Betriebssystem 1122 kann auf einer virtuellen Maschine ablaufen, welche von dem Datenverarbeitungssystem 1100 bereitgestellt werden kann.
Wie oben angegeben kann ein Benutzer, wie etwa ein Ingenieur, Wissenschaftler, Programmierer, Entwickler, etc., ein oder mehrere Eingabevorrichtungen, wie etwa die Tastatur 1116, die Maus 1111 und die Anzeige 1120, verwenden, um die Integrationsplattform 102 zu bedienen, um automatisch ein Modell von einem High-Level-Systemdesign zu realisieren, und um das realisierte Modell in einer Weise der Co-Simulation ausführen zu lassen. Wie beschrieben können Co-Simulationskomponenten berechenbar sein und ausführbare Semantiken haben. Insbesondere können die Co-Simulationskomponenten simuliert oder ausgeführt werden. Insbesondere können die Co-Simulationskomponenten ein oder mehrere bereitstellen von zeitbasierten, ereignisbasierten, zustandsbasierten, nachrichtenbasierten, frequenzbasierten, steuerflussbasierten und datenflussbasierten Ausführungssemantiken. Die Ausführung eines realisierten Modells kann die Operation des High-Level-Systemdesigns simulieren. Der Ausdruck graphisches Modell ist gedacht, ein graphisches Programm zu beinhalten.
Verteiltes Netzwerk
12 ist ein schematisches Diagramm einer beispielhaften verteilten Rechnerumgebung 1200, in welcher Systeme und/oder Verfahren der vorliegenden Offenbarung implementiert sein können in Übereinstimmung mit einer oder mit mehreren Ausführungsformen. Die Umgebung 1200 kann Client- und Servervorrichtungen beinhalten, wie etwa zwei Server 1202 und 1204 und drei Clients 1206-1208, welche mittels einem oder mehreren Netzwerken, wie etwa dem Netzwerk 1210, verbunden sind. Die Vorrichtungen der Umgebung 1200 können über drahtgebundene Verbindungen, drahtlose Verbindungen oder eine Kombination von drahtgebundenen und drahtlosen Verbindungen. Die Server 1202 und 1204 können eine oder mehrere Vorrichtungen beinhalten, die eingerichtet ist, Information zu empfangen, zu erzeugen, zu speichern, zu verarbeiten, auszuführen und/oder bereitzustellen. Beispielsweise können die Server 1202 und 1204 eine Rechnervorrichtung beinhalten, wie etwa einen Server, einen Arbeitsplatzrechner, einen Laptopcomputer, einen Tabletcomputer, einen handgehaltenen Computer oder eine ähnliche Vorrichtung. Die Server 1202 und 1204 können eine oder mehrere Anwendungen hosten. Beispielsweise kann der Server 1202 die Integrationsplattform 102 hosten.
Die Clients 1206-1208 können eingerichtet sein, um Information zu empfangen, zu erzeugen, zu speichern, zu verarbeiten, auszuführen und/oder bereitzustellen. Die Information kann jeden Typ von maschinenlesbarer Information beinhalten, mit im Wesentlichen jedem Format, das zur Nutzung geeignet ist, zum Beispiel in einem oder in mehreren Netzwerken und/oder mit einer oder mit mehreren Vorrichtungen. Die Information kann digitale Information und/oder analoge Information beinhalten. Die Information kann weiter in Pakete gruppiert und/oder nicht in Pakete gruppiert sein. In einer Ausführungsform können die Clients 1206-1208 Daten und/oder Code von den Servern 1202 und 1204 über das Netzwerk 1210 herunterladen. In einigen Implementierungen können die Clients 1206-1208 Schreibtischcomputer, Arbeitsplatzrechner, Laptopcomputer, Tabletcomputer, handgehaltene Computer, Mobiltelefone (zum Beispiel Smartphones, Funktelefone, etc.), elektronische Lesegeräte oder ähnliche Vorrichtungen sein. In einigen Implementierungen können die Clients 1206-1208 Information von den Servern 1202 und 1204 empfangen und/oder Information an diese senden.
Das Netzwerk 1210 kann ein oder mehrere drahtgebundene und/oder drahtlose Netzwerke beinhalten. Beispielsweise kann das Netzwerk 1210 ein Mobilfunknetz, ein öffentliches terrestrisches Mobilfunknetz (PLMN), ein lokales Netzwerk (LAN), ein Weitbereichsnetzwerk (WAN), ein Stadtbereichsnetzwerk (MAN), ein Telefonnetz (zum Beispiel das Telefonnetz (PSTN)), ein Ad-hoc-Netzwerk, ein Intranet, das Internet, ein faseroptisches Netzwerk und/oder eine Kombination dieser oder anderer Typen von Netzwerken beinhalten. Information zwischen Netzwerkvorrichtungen ausgetauscht werden unter Verwendung eines Netzwerkprotokolls, wie etwa, ohne hierauf beschränkt zu sein, das Internet Protocol (IP), Asynchronous Transfer Mode (ATM), Synchronous Optical Netzwerk (SONET), das User Datagram Protocol (UDP), Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc.
Die Anzahl an Vorrichtungen und/oder Netzwerken, die in 12 gezeigt sind, ist als ein Beispiel gegeben. In der Praxis mag es zusätzliche Vorrichtungen und/oder Netzwerke, weniger Vorrichtungen und/oder Netzwerke, andere Vorrichtungen und/oder Netzwerke oder anders angeordnete Vorrichtungen und/oder Netzwerke als die in 12 gezeigten geben. Weiter können zwei oder mehr Vorrichtungen, die in 12 gezeigt sind, in einer einzelnen Vorrichtung implementiert sein, oder eine einzelne Vorrichtung, die in 12 gezeigt ist, kann als mehrere, verteilte Vorrichtungen implementiert sein. Zusätzlich kann eine oder können mehrere der Vorrichtungen der verteilten Rechnerumgebung 1200 eine oder mehrere Funktionen ausführen, die beschrieben wurden, als von einer anderen oder mehreren anderen Vorrichtungen der Umgebung 1200 ausgeführt zu werden.
Die vorstehende Beschreibung von Ausführungsformen ist zur Illustration und Beschreibung gedacht, aber ist nicht dazu gedacht, erschöpfend zu sein oder die Offenbarung auf die präzise offenbarte Form zu beschränken. Es sind Abwandlungen und Variationen möglich im Licht der vorstehenden Lehren oder mögen sich bei der Verwirklichung der Offenbarung ergeben. Beispielsweise kann, während eine Reihe von Aktionen vorstehend beschrieben wurde mit Bezug auf die Flussdiagramme, in anderen Implementierungen die Reihenfolge der Aktionen geändert werden. Darüber hinaus können die Aktionen, Operationen und Schritte von zusätzlichen oder anderen Modulen oder Entitäten ausgeführt werden, welche kombiniert oder getrennt werden können, um andere Module oder Entitäten zu bilden. Weiter können nicht voneinander abhängige Aktionen parallel ausgeführt werden. Auch ist der Begriff „Benutzer“, wie hierin verwendet, dazu gedacht, breit ausgelegt zu werden, so dass er beispielsweise ein Computer- oder Datenverarbeitungssystem oder einen menschlichen Benutzer eines Computer- oder Datenverarbeitungssystems umfasst, solange nicht anderweitig angegeben.
Weiter können bestimmte Ausführungsformen der Offenbarung als Logik implementiert sein, die eine oder mehrere Funktionen ausführt. Diese Logik kann hardwarebasiert, softwarebasiert oder eine Kombination von hardwarebasiert und softwarebasiert sein. Ein Teil oder die gesamte Logik kann in einem oder in mehreren greifbaren, nichttransitorischen, computerlesbaren Speichermedien gespeichert sein und kann von einem Computer ausführbare Anweisungen umfassen, welche von einem Computer- oder Datenverarbeitungssystem, wie etwa dem System 1100, ausgeführt werden. Die von einem Computer ausführbare Anweisungen können Anweisungen beinhalten, welche eine oder mehrere Ausführungsformen der Offenbarung implementieren. Die greifbaren, nichttransitorischen, computerlesbaren Speichermedien können flüchtig oder nichtflüchtig sein und können beispielsweise Flash Speicher, dynamische Speicher, entfernbare Platten und nicht entfernbare Platten beinhalten.
Keine Element, keine Aktion und keine Anweisung, die hierin verwendet werden, soll als kritisch oder essentiell für die Offenbarung sein, solange nicht ausdrücklich so angegeben. Auch ist der Artikel „ein“, wie hierin verwendet, dazu gedacht, ein oder mehrere Elemente zu beinhalten. Wo nur ein Gegenstand gedacht ist, wird der Ausdruck „ein“ oder ein ähnlicher Ausdruck verwendet. Weiter ist der Ausdruck „basierend auf“ so gedacht, „zumindest zum Teil basierend auf“ zu bedeuten, solange nicht ausdrücklich anders angegeben.
Im Lichte des Vorhergehenden offenbart die vorliegende Anmeldung unter anderem die folgenden Gegenstände:
Gegenstand 1. Computerimplementiertes Verfahren, umfassend: Zugreifen auf ein High-Level-Systemdesign eines Systems, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; Zugreifen auf ein oder mehrere Ziele, die assoziiert sind mit dem High-Level-Systemdesign, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute eine Präzisionsgüte, eine Ausführungsgeschwindigkeitsgüte und/oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten; Berechnen von Kompensationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Kompensationsparameter Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten; Aufstellen bzw. Einrichten einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und der Kompensationsparameter; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und Kompensatoren für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen, welche ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Gegenstand 2. Computerimplementiertes Verfahren nach Gegenstand 1, weiter umfassend: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt bzw. eingerichtet ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Gegenstand 3. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 2, weiter umfassend: Ausführen einer Netzwerkerkennung eines Computernetzwerks, um Eigenschaften abzuleiten, welche verfügbare Hardwareressourcen identifizieren, welche Netzwerkknoten zum Hosten der Simulationswerkzeuge und Verarbeitungsfähigkeit und Speicherfähigkeit der Netzwerknoten und verfügbare Kommunikationsverbindungen zwischen den Netzwerkknoten beinhalten, wobei die Zielfunktion weiter aufgestellt bzw. eingerichtet ist, die Eigenschaften zu berücksichtigen, welche von dem Computernetzwerk abgeleitet wurden, und wobei das realisierte Modell ausgewählte Netzwerkknoten aus den verfügbaren Hardwareressourcen und ausgewählte Kommunikationsverbindungen aus den verfügbaren Kommunikationsverbindungen beinhaltet.
Gegenstand 4. Computerimplementiertes Verfahren nach Gegenstand 3, weiter umfassend: Konfigurieren der ausgewählten Simulationswerkzeuge, um die ausgewählten ausführbaren Co-Simulationskomponenten auszuführen; und Konfigurieren der ausgewählten Netzwerkknoten zum Hosten der ausgewählten Simulationswerkzeuge.
Gegenstand 5. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 4, weiter umfassend: Zugreifen auf eine oder mehrere von einem Benutzer spezifizierten harten Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen bzw. Einrichten der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und wobei das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.
Gegenstand 6. Computerimplementiertes Verfahren nach Gegenstand 5, wobei die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen zumindest eines spezifiziert von einem gegebenen Simulationswerkzeug, einer gegebenen Co-Simulationskomponente, einem Modellblock, einem gegebenen Netzwerkknoten und/oder einer gegebenen Kommunikationsverbindung zur Aufnahme in oder zum Weglassen aus dem realisierten Modell.
Gegenstand 7. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 6, wobei das Lösen stufenweise ausgeführt wird und ein Ergebnis einer aktuellen Stufe präsentiert wird, bevor zu einer nächsten Stufe fortgeschritten wird.
Gegenstand 8. Computerimplementiertes Verfahren nach Gegenstand 7, weiter umfassend: Empfangen einer Benutzerzustimmung der aktuellen Stufe, bevor zur nächsten Stufe fortgeschritten wird.
Gegenstand 9. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 8, weiter umfassend: Bewerten der Ausführung des realisierten Modells gegen das eine oder die mehreren Ziele; Modifizieren des einen oder der mehreren Ziele; und Wiederholen der Schritte des Analysierens, Berechnens, Aufsetzens, Lösens und Ausführens.
Gegenstand 10. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 9, wobei die Zielfunktion eine Kostenfunktion, eine Energiefunktion, eine Belohnungsfunktion und/oder eine Nutzenfunktion ist.
Gegenstand 11. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 10, wobei die Elemente des High-Level-Systemdesigns nicht ausführbar sind.
Gegenstand 12. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 11, wobei das eine oder die mehreren Ziele von einem Benutzer spezifiziert sind, und wobei das eine oder die mehreren Ziele in der Zielfunktion in der Form von Gewichten enthalten sind.
Gegenstand 13. Computerimplementiertes Verfahren nach einem oder mehreren der Gegenstände 1 bis 12, wobei das realisierte Modell von einer Master-Ausführungs-Engine und einem Master-Löser ausgeführt wird, welche eine subordinäre Ausführungs-Engine und einen subordinären Löser auf einem oder auf mehreren der ausgewählten Netzwerkknoten verwalten.
Gegenstand 14. Ein oder mehrere nichttransitorische computerlesbare Medien, auf welchen Anweisungen gespeichert sind, welche, wenn sie von einer Rechnervorrichtung ausgeführt werden, die Rechnervorrichtung dazu veranlassen, Operationen auszuführen, welche umfassen: Zugreifen auf ein High-Level-Systemdesign eines Systems, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; Zugreifen auf ein oder mehrere Ziele, die mit dem High-Level-Systemdesign assoziiert sind, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute beinhalten eine Präzisionsgüte, eine Ausführungsgeschwindigkeitsgüte und/oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten; Berechnen von Kompensationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Kompensationsparameter Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten; Aufstellen bzw. Einrichten einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und der Kompensationsparameter; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und Kompensatoren für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen, welche ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Gegenstand 15. Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach Gegenstand 14, wobei die Anweisungen die Rechenvorrichtung dazu veranlassen, Operationen auszuführen, welche weiter umfassen: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt bzw. eingerichtet ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Gegenstand 16. Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach einem oder mehreren der Gegenstände 14 bis 15, wobei die Anweisungen die Rechenvorrichtung dazu veranlassen, Operationen auszuführen, welche weiter umfassen: Zugreifen auf eine oder mehrere von einem Benutzer spezifizierte harte Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen bzw. Einrichten der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.
Gegenstand 17. Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach einem oder mehreren der Gegenstände 14 bis 16, wobei das Lösen stufenweise ausgeführt wird, und ein Ergebnis einer aktuellen Stufe präsentiert wird, vor zu einer nächsten Stufe fortgeschritten wird.
Gegenstand 18. Vorrichtung, umfassend: ein oder mehrere Speicher, welche ein High-Level-Systemdesign eines Systems speichern, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; und ein oder mehrere Prozessoren, welche mit dem einen oder den mehreren Speichern gekoppelt sind, wobei der eine oder die mehreren Prozessoren konfiguriert sind zum: Zugreifen auf ein oder mehrere Ziele, die mit dem High-Level-Systemdesign assoziiert sind, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute beinhalten eine Präzisionsgüte, an Ausführungsgeschwindigkeitsgüte und/oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten; Berechnen von Kompensationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Kompensationsparameter Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten; Aufstellen bzw. Einrichten einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und den Kompensationsparametern; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit und/oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und Kompensatoren für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen, welche ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Gegenstand 19. Vorrichtung nach Gegenstand 18, wobei der eine oder die mehreren Prozessoren weiter konfiguriert sind zum: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt bzw. eingerichtet ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Gegenstand 20. Vorrichtung nach einem oder mehreren der Gegenstände 18 bis 19 wobei der eine oder die mehreren Prozessoren weiter konfiguriert sind zum: Zugreifen auf ein oder mehrere von einem Benutzer spezifizierte harte Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen bzw. Einrichten der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und wobei das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.
Die vorstehende Beschreibung wurde auf spezifische Ausführungsformen der vorliegenden Offenbarung gerichtet. Es wird jedoch ersichtlich sein, dass andere Variationen und Abwandlungen an den beschriebenen Ausführungsformen vorgenommen werden können, wobei einige oder alle deren Vorteile erreicht werden. Beispielsweise kann generierter Code vorteilshaft mit anderer eingebetteter Hardware verwendet werden, wie etwa eingebetteter Hardware, welche Fließkommakerne beinhaltet. Es ist daher das Ziel der beigefügten Ansprüche, alle solchen Varianten und Abwandlungen zu umfassen, welche in den wahren Geist und Bereich der Offenbarung kommen.

Claims

Computerimplementiertes Verfahren, umfassend: Zugreifen auf ein High-Level-Systemdesign eines Systems, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; Zugreifen auf ein oder mehrere Ziele, die mit dem High-Level-Systemdesign assoziiert sind, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute eine Präzisionsgüte, eine Ausführungsgeschwindigkeitsgüte oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten; Berechnen von Schnittstellenkonfigurationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Schnittstellenkonfigurationsparameter zwischen den Kandidatenpaaren von Modellkomponenten ausgetauschte Daten verwalten; Aufstellen einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und der Schnittstellenkonfigurationsparameter; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und ausgewählte Schnittstellenkonfigurationsparameter für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Computerimplementiertes Verfahren nach Anspruch 1, wobei die Schnittstellenkonfigurationsparameter Kompensationsparameter beinhalten, welche Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten, und wobei die ausgewählten Schnittstellenkonfigurationsparameter des realisierten Modells ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, weiter umfassend: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und wobei das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Computerimplementiertes Verfahren nach Anspruch 3, weiter umfassend: Ausführen einer Netzwerkerkennung eines Computernetzwerks, um Eigenschaften abzuleiten, welche identifizieren: verfügbare Hardwareressourcen, welche Netzwerkknoten zum Hosten der Simulationswerkzeuge, und Verarbeitungsfähigkeit und Speicherkapazität der Netzwerkknoten beinhalten, und verfügbare Kommunikationsverbindungen zwischen den Netzwerkknoten, wobei die Zielfunktion weiter aufgestellt ist, die Eigenschaften zu berücksichtigen, welche von dem Computernetzwerk abgeleitet wurden, und wobei das realisierte Modell ausgewählte Netzwerkknoten von den verfügbaren Hardwareressourcen und ausgewählte Kommunikationsverbindungen von den verfügbaren Kommunikationsverbindungen beinhaltet.
Computerimplementiertes Verfahren nach Anspruch 4, weiter umfassend: Konfigurieren der ausgewählten Simulationswerkzeuge zum Ausführen der ausgewählten ausführbaren Co-Simulationskomponenten; und Konfigurieren der ausgewählten Netzwerkknoten, um die ausgewählten Simulationswerkzeuge zu hosten.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, weiter umfassend: Zugreifen auf ein oder mehrere von einem Benutzer spezifizierte harte Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.
Computerimplementiertes Verfahren nach Anspruch 6, wobei die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen zumindest eines spezifizieren von: einem gegebenen Simulationswerkzeug, einer gegebenen Co-Simulationskomponente, einem Modellblock, einem gegebenen Netzwerkknoten, oder einer gegebenen Kommunikationsverbindung zur Aufnahme in oder zum Auslassen aus dem realisierten Modell.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei das Lösen stufenweise ausgeführt wird, und wobei ein Ergebnis einer aktuellen Stufe präsentiert wird, bevor zu einer nächsten Stufe fortgeschritten wird.
Computerimplementiertes Verfahren nach Anspruch 8, weiter umfassend: Empfangen einer Benutzerzustimmung der aktuellen Stufe, bevor zur nächsten Stufe fortgeschritten wird.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, weiter umfassend: Bewerten der Ausführung des realisierten Modells gegen das eine oder die mehreren Ziele; Modifizieren des einen oder der mehreren Ziele; und Wiederholen der Schritte des Analysierens, Berechnens, Aufstellens, Lösens und Ausführens.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die Zielfunktion eine Kostenfunktion, eine Energiefunktion, eine Belohnungsfunktion oder eine Nutzenfunktion ist.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die Elemente des High-Level-Systemdesigns nicht ausführbar sind.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei das eine oder die mehreren Ziele von einem Benutzer spezifiziert sind, und wobei das eine oder die mehreren Ziele in der Zielfunktion in der Form von Gewichten enthalten sind.
Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei das realisierte Modell von einer Master-Ausführungs-Engine und einem Master-Löser ausgeführt wird, welche eine subordinäre Ausführungs-Engine und einen subordinären Löser auf einem oder auf mehreren der ausgewählten Netzwerkknoten verwalten.
Ein oder mehrere nichttransitorische computerlesbare Medien, auf welchen Anweisungen gespeichert sind, welche, wenn sie von einer Rechnervorrichtung ausgeführt werden, die Rechnervorrichtung dazu veranlassen, Operationen auszuführen, welche umfassen: Zugreifen auf ein High-Level-Systemdesign eines Systems, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; Zugreifen auf ein oder mehrere Ziele, die mit dem High-Level-Systemdesign assoziiert sind, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute eine Präzisionsgüte, eine Ausführungsgeschwindigkeitsgüte oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten; Berechnen von Schnittstellenkonfigurationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Schnittstellenkonfigurationsparameter zwischen den Kandidatenpaaren von Modellkomponenten ausgetauschte Daten verwalten; Aufstellen einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und den Schnittstellenkonfigurationsparametern; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und ausgewählte Schnittstellenkonfigurationsparameter für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach Anspruch 15, wobei die Schnittstellenkonfigurationsparameter Kompensationsparameter beinhalten, welche Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten, und wobei die ausgewählten Schnittstellenkonfigurationsparameter des realisierten Modells ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren.
Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach Anspruch 15 oder 16, wobei die Anweisungen die Rechenvorrichtung dazu veranlassen, Operationen auszuführen, welche weiter umfassen: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und wobei das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach einem der Ansprüche 15 bis 17, wobei die Anweisungen die Rechenvorrichtung dazu veranlassen, Operationen auszuführen, welche weiter umfassen: Zugreifen auf eine oder mehrere von einem Benutzer spezifizierte harte Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.
Das eine oder die mehreren nichttransitorischen computerlesbaren Medien nach einem der Ansprüche 15 bis 18, wobei das Lösen stufenweise ausgeführt wird und ein Ergebnis einer aktuellen Stufe präsentiert wird, vor zu einer nächsten Stufe fortgeschritten wird.
Vorrichtung, umfassend: ein oder mehrere Speicher, welche ein High-Level-Systemdesign eines Systems speichern, wobei das High-Level-Systemdesign Elemente beinhaltet, welche Teile des Systems repräsentieren; und einen oder mehrere Prozessoren, welche mit dem einen oder den mehreren Speichern gekoppelt ist bzw. sind, wobei der eine oder die mehreren Prozessoren konfiguriert ist bzw. sind zum: Zugreifen auf ein oder mehrere Ziele, die mit dem High-Level-Systemdesign assoziiert sind, wobei das eine oder die mehreren Ziele zumindest eines beinhalten von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung; Analysieren von ausführbaren Modellkomponenten, um Attribute einer Vielzahl von alternativ ausführbaren Modellkomponenten zu identifizieren, welche die Elemente des High-Level-Systemdesigns modellieren, wobei die Attribute eine Präzisionsgüte, eine Ausführungsgeschwindigkeitsgüte oder eine Speichernutzungsgüte der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten; Berechnen von Schnittstellenkonfigurationsparametern für Verbindungen zwischen Kandidatenpaaren von Modellkomponenten aus der Vielzahl von alternativen Modellkomponenten, wobei die Schnittstellenkonfigurationsparameter die zwischen den Kandidatenpaaren von Modellkomponenten ausgetauschten Daten verwalten; Aufstellen einer Zielfunktion unter Verwendung des einen oder der mehreren Ziele, der Attribute der Vielzahl von alternativ ausführbaren Modellkomponenten und den Schnittstellenkonfigurationsparametern; Lösen der Zielfunktion, um das High-Level-Systemdesign in ein realisiertes Modell zu partitionieren basierend auf dem einen oder den mehreren Zielen von zumindest einem von Präzision, Ausführungsgeschwindigkeit oder Speichernutzung, wobei das realisierte Modell beinhaltet: zwei oder mehr Co-Simulationspartitionen, welche ausgewählte ausführbare Modellkomponenten aus der Vielzahl von alternativ ausführbaren Modellkomponenten beinhalten, und ausgewählte Schnittstellenkonfigurationsparameter für Schnittstellen zwischen den zwei oder mehr Co-Simulationspartitionen; und Ausführen des realisierten Modells in einer Weise der Co-Simulation.
Vorrichtung nach Anspruch 20, wobei die Schnittstellenkonfigurationsparameter Kompensationsparameter beinhalten, welche Fehler korrigieren, welche während dem Datenaustausch zwischen den Kandidatenpaaren von Modellkomponenten auftreten, und die ausgewählten Schnittstellenkonfigurationsparameter des realisierten Modells ausgewählte Kompensationsparameter von den Kompensationsparametern implementieren.
Vorrichtung nach einem der Ansprüche 20 oder 21, wobei der eine oder die mehreren Prozessoren weiter konfiguriert sind zum: Identifizieren von verfügbaren Simulationswerkzeugen zum Ausführen der Vielzahl von alternativen Modellkomponenten, wobei die Zielfunktion weiter aufgestellt ist, das eine oder die mehreren der verfügbaren Simulationswerkzeuge zu berücksichtigen, und das realisierte Modell ausgewählte Simulationswerkzeuge aus den verfügbaren Simulationswerkzeugen beinhaltet.
Vorrichtung nach einem der Ansprüche 20 bis 22, wobei der eine oder die mehreren Prozessoren weiter konfiguriert ist bzw. sind zum: Zugreifen auf eine oder mehrere von einem Benutzer spezifizierte harte Randbedingungen, die mit dem High-Level-Systemdesign assoziiert sind, wobei das Aufstellen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen verwendet, und das Lösen der Zielfunktion weiter die eine oder die mehreren von einem Benutzer spezifizierten harten Randbedingungen erfüllt.