-
Dynamische Systeme, die vom Menschen entwickelte
Systeme sind, die auf eine bestimmte vorteilhafte Weise auf sich ändernde
Bedingungen innerhalb ihrer Umgebung ansprechen, stellen aufgrund
der Vielzahl von und der verschiedenen Bedingungen, die derartige
Systeme wirksam handhaben können
müssen,
eine wesentliche Herausforderung für die Entwerfer derartiger
Systeme dar. Elektrische und elektronische Schaltungen zum Beispiel,
die nur einen Typ eines dynamischen Systems darstellen, müssen oft
auf sich ständig ändernde
Eingangssignale reagieren, indem sie Ausgangssignale basierend auf
den Eingangssignalen liefern, wodurch eine bestimmte vorteilhafte
Aktion in der Umgebung bewirkt wird, in der das System wirkt. Elektrische
und elektronische Schaltungen werden mit großem Vorteil in einer Überfülle von
Anwendungen von alltäglichen
Verbrauchergeräten,
wie zum Beispiel Mikrowellenöfen
und Personalcomputern, bis hin zu hochtechnologischen Militärwaffen
eingesetzt. Zusätzlich umfassen
dynamische Systeme außerdem
einen Typ von Software, die geschrieben ist, um eine spezifische
nützliche
Funktion durchzuführen.
Ferner können
dynamische Systeme diejenigen umfassen, die auf elektrischen, Software-,
mechanischen, pneumatischen oder chemischen Prinzipien oder einer
Kombination derselben basieren, sind jedoch nicht darauf beschränkt.
-
Die Aufgabe eines Entwerfens dynamischer Systeme
wurde stark durch fortdauernde Verbesserungen in der Technologie
einer Systemsimulation verbessert. Eine derartige Simulation ermöglicht es, daß Modelle
von Dynamiksystementwürfen
zu Beginn ohne den Bedarf teurer Prototypen getestet werden, die
sowohl schwierig zu bauen als auch beibehalten sind.
-
Durch eine Simulation kann jeder
vorstellbare Satz von Testbedingungen eingesetzt werden, um einen
vorläufigen
Systementwurf gründlich
auszutesten. Die Ergebnisse dieser Tests können dann durch den Systementwerfer
verwendet werden, um die Leistung des Systems zu analysieren. Üblicherweise werden
dann Veränderungen
basierend auf den Ergebnissen der Tests durchgeführt, die Tests werden erneut
durchgeführt
und die Ergebnisse werden noch einmal analysiert, um die positive
oder die negative Auswirkung der Veränderungen zu bestimmen. So ermöglicht es
eine Simulation, daß der
Entwurf des dynamischen Systems mittels eines iterativen Verfahrens
vor dem tatsächlichen
Aufbau des zu testenden Systems verbessert wird, was zu einer schnelleren
und produktiveren Systementwicklung führt.
-
Ein spezifisches Beispiel einer derartigen Modellierungsumgebung
ist die Simulink®-Systemdefinition und
das -Simulationswerkzeug bzw. -tool von The Mathworks, Inc. Wie
in 2 gezeigt ist, ermöglicht es
eine Modellierungsumgebung 210 einem Systementwerfer, ein
dynamisches System, ob es elektrisch, mechanisch oder anders ist,
mittels eines Systemmodels 1 zu spezifizieren, das Charakteristika
besitzt, die durch den Entwerfer bestimmt sind. Ein Beispiel des
Systemmodels 1 ist in 1 gezeigt. Das
Systemmodel 1 besteht aus mehreren Funktionsblöcken 2,
wobei jeder derselben eine bestimmte identifizierbare Aufgabe innerhalb
des Systemmodels 1 durchführt. Normalerweise werden eines
oder mehrere Eingangssignale 3 und Ausgangssignale 4 (oder
kollektiv interne Variablen) durch das dynamische System, das durch
das Model 1 dargestellt ist, verwendet, um mit der umliegenden
Umgebung zu kommunizieren und dieselbe zu beeinflussen. Jedem Block 2 kann
einer oder mehrere Blockparameter 5 zugeordnet sein, die
beeinflussen, wie der Funktionsblock 2 seine bestimmte
Funktion durchführt.
Zusätzlich
ermöglichen
es interne Signale 6 des Systemmodels 1, daß die Funktionsblöcke 2 kommunizieren, wodurch
eine Kooperation unter den Funktionsblöcken 2 ermöglicht wird,
um die Gesamtfunktion des dynamischen Systems durchzufüh ren. Die
meisten Modellierungsumgebungen 210, wie zum Beispiel Simulink,
ermöglichen
außerdem
einen hierarchischen Entwurf, da jeder Block 2 des Systemmodels 1 ferner aus
Unterblöcken
(nicht gezeigt) bestehen kann, die verschiedene Funktionen innerhalb
des zugeordneten Blocks 2 auf höherer Ebene darstellen.
-
Wie in 2 zu
sehen ist, kann das Systemmodel 1, das in der Simulink-Umgebung
spezifiziert ist, dann innerhalb dieser gleichen Umgebung unter Verwendung
von Eingangssignalen 3 simuliert werden, die durch den
Systementwickler entwickelt werden. Die Analyse, nachfolgende Entwurfsveränderungen
und eine weitere Simulation des Models treten normalerweise alle
innerhalb des Gebietes des Simulink-Tools auf. Um diesen Prozeß zu verbessern,
ermöglicht
Simulink einen Zugriff auf die internen Signale 6, Blockparameter 5 und
andere wichtige interne Variablen des Systemmodels 1, die
das Verhalten des vorgeschlagenen Systems definieren. Die internen
Signale 6 ermöglichen
dem Entwerfer einen größeren Einblick
in die Operationen des Systemmodels, während eine Modifizierung der
Parameterblöcke 5 ein
Verfahren liefert, durch das der Entwerfer die Operation des Models 1 während einer
Simulation verändern
kann. So macht ein Zugriff auf diese internen Variablen den gesamten
Simulations- und Analyseprozeß effizienter.
-
Ein verwandtes Codeerzeugungstool 220, wie
zum Beispiel das, das von The Mathworks bereitgestellt wird, Real-Time
Workshop® (RTW)
genannt, nimmt Systemmodelle, die ursprünglich innerhalb der Modellierungsumgebung 210 entworfen
wurden, als einen Eingang und erzeugt eine Code oder eine Software,
der/die das Systemmodel (230 aus 2) darstellt. Der Code 230 kann
in einer von mehreren unterschiedlichen Programmierungssprachen,
einschließlich
C, Ada und anderer, erzeugt sein. Dieser Code 230 kann
dann zu einer anderen Plattform übertragen
und auf derselben ausgeführt
werden, wobei die Ausführung
des Codes 230 möglicherweise
abhängig
von der Natur der Plattform in Echtzeit ab läuft. In dem Fall von Elektroniksteuerungssystemen
kann die Plattform die Zielplattform sein, die letztendlich verwendet
wird, um das Steuerungssystem zu implementieren, wobei so ein nahezu
nahtloser Fortgang von einer Systemmodelerzeugung zu einem Produktebenencode
bereitgestellt wird.
-
Leider sind die systeminternen Variablen, wie
zum Beispiel die internen Signale 6 und Blockparameter 5 aus 1, die zu Beginn in der
Simulationsumgebung 210 zugänglich sind, oft ohne eine
zusätzliche
modellspezifische Software, die speziell durch den Entwerfer erzeugt
wurde, nicht mehr auf der Plattform zugänglich, die den Modellcode 230 ausführt. In
einer Bemühung,
diese Situation innerhalb der Mathworks-Umgebung zu beheben, liefert das RTW-Tool
eine „Externmodus"-Option, die es dem
Entwerfer ermöglicht,
auf die internen Variablen des RTW-erzeugten Codes zuzugreifen,
wenn auf denselben über
die Simulink-Umgebung zugegriffen wird. Bei einem Verwenden eines
externen Modus, ist ein derartiger Zugriff auf interne Variablen über Simulink
möglich,
ob der RTW-erzeugte Code nun auf der gleiche Plattform ausgeführt wird,
die Simulink ausführt,
oder auf einer anderen Plattform, die mit der Simulink-Plattform
mittels einer Kommunikationsverbindung, wie z. B. Übertragungssteuerungsprotokoll/Internetprotokoll
(TCP/IP), verbunden ist. In jedem Fall jedoch liegt eine Steuerung
der Simulation dennoch vollständig
bei der Simulink-Modellierungsumgebung. Als ein Ergebnis ist die
Fähigkeit,
den RTW-erzeugten Code auszuführen,
sowie auf denselben zuzugreifen und ihn möglicherweise zu verändern, wobei
die internen Variablen dieses Codes auf einer separaten Plattform
laufen, abhängig
von den Fähigkeiten
von Simulink sowie der Verfügbarkeit
einer Kommunikationsverbindung zwischen der Simulink-Plattform und
der Plattform, die den RTW-erzeugten Code unterbringt. Anders ausgedrückt ist
die Fähigkeit,
mittels eines Softwareclienten, der sich außerhalb der ursprünglichen
Modellierungsumgebung befindet, auf die internen Variablen eines
ausführenden
Softwaremodells zuzugreifen, sowie möglicher weise die Ausführung des
Softwaremodells in derartigen Fällen
zu steuern, gegenwärtig
nicht verfügbar.
-
Deshalb wären aus dem Vorangegangenen Verfahren,
die einem Softwareclienten außerhalb
der ursprünglichen
Modellierungsumgebung automatisch die Fähigkeit ermöglichen, auf die internen Variablen
eines Softwaremodells zuzugreifen, sowie möglicherweise die Ausführung eines
Softwaremodells zu steuern, von Vorteil. Derartige Verfahren würden dem
Systementwerfer eine große
Flexibilität
bei dem Typ und dem Ausmaß einer
Ausführung
des und eines Zugriffs auf das Softwaremodell, verfügbar in Abwesenheit
der ursprünglichen
Modellierungsumgebung, ermöglichen.
-
Es ist die Aufgabe der vorliegenden
Erfindung, ein Verfahren, ein Computersystem oder ein Programmspeichermedium
zu schaffen, die einen Zugriff auf interne Variablen im Rahmen einer
Systemsimulation vereinfachen.
-
Diese Aufgabe wird durch ein Verfahren
gemäß Anspruch
1 oder 22, ein Computersystem gemäß Anspruch 8 oder ein Programmspeichermedium gemäß Anspruch
15 gelöst.
-
Ausführungsbeispiele der vorliegenden
Erfindung, die unten detailliert erläutert sind, stellen ein Verfahren
zum Erzeugen eines Softwaremodells eines dynamischen Systems aus
einem vorläufigen Softwaremodell
dar. Normalerweise wird ein Systemmodell, das innerhalb einer Modellierungsumgebung spezifiziert
ist, verwendet, um das vorläufige
Softwaremodell, das die Aktionen des Systemmodells darstellt, zu
erzeugen. Das vorläufige
Softwaremodell ist außerhalb
der Modellierungsumgebung ausführbar,
die verwendet wird, um das ursprüngliche Softwaremodell
zu erzeugen, wobei die internen Variablen des Modells üblicherweise
nicht durch einen Softwareclienten zugänglich sind, der der Modellierungsumgebung
zugeordnet ist.
-
Um diese Situation zu lindern, wird
gemäß Ausführungsbeispielen
der Erfindung eine Schnittstellensoftware erzeugt, die zumindest
eine der internen Variablen der vorläufigen Softwaremodells freilegt.
Das Softwaremodell wird dann aus dem vorläufigen Softwaremodul und der
Schnittstellensoftware aufgebaut. Dieses resultierende Softwaremodell
ermöglicht
so einen Programmzugriff auf die internen Variablen und möglicherweise
eine Steuerung der Ausführung
des Softwaremodells von außerhalb
der Modellierungsumgebung.
-
Ein derartiges Softwaremodell ermöglicht eine
detaillierte Simulation und Analyse von Softwaremodellen, die dynamische
Systeme darstellen, mittels Softwareclienten mit potentiell größeren Simulations-
und Analysefähigkeiten,
als innerhalb der ursprünglichen
Modellierungsumgebung verfügbar wären. Ferner
wäre mit
einer erlaubten Modellausführungssteuerung
ein derartiger Softwareclient in der Lage, die Ausführung mehrerer
Softwaremodelle zu steuern, was es ermöglicht, daß diese Softwaremodelle miteinander über den
Softwareclienten in Wechselwirkung stehen. Zusätzlich könnten Softwaremodelle, die
eine derartige Programmschnittstelle verwenden, durch die Verwendung
ungleicher, inkompatibler Modellierungsumgebungen erzeugt werden,
wobei diese Softwaremodelle dennoch in der Lage wären, miteinander
mittels des Softwareclienten in Wechselwirkung zu stehen.
-
Bevorzugte Ausführungsbeispiele der vorliegenden
Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden
Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Blockdiagramm eines Systemmodells, das innerhalb der Simulink-Modellierungsumgebung,
sowie anderen Modellierungsumgebungen dargestellt sein kann;
-
2 ein
Flußdiagramm
eines Verfahrens des Stands der Technik zum Entwickeln einer Software,
die ein Modell eines dynamischen Systems darstellt;
-
3 ein
Flußdiagramm
eines Verfahrens gemäß einem
Ausführungsbeispiels
der Erfindung zum Entwicklung eines Softwaremodells eines dynamischen
Systems; und
-
4 ein
Blockdiagramm, das eine Mehrzahl ungleicher Softwaremodelle darstellt,
die miteinander durch einen Softwareclienten in Wechselwirkung stehen.
-
Ausführungsbeispiele der Erfindung,
die unten detailliert beschrieben sind, verwenden als einen Ausgangspunkt
ein Softwaremodell (unten als ein vorläufiges Softwaremodell bezeichnet),
das innerhalb der Simulink®-Modellierungsumgebung
von Mathworks erzeugt wird. Zusätzlich
sind die folgenden Ausführungsbeispiele
als Software zu finden, die innerhalb der Real-Time Workshop®-(RTW-)Codeerzeugungstool-Umgebung von Mathworks
integriert ist, um einen Code mit einer verbesserten Fähigkeit demgegenüber, was
normalerweise innerhalb RTW erzielbar ist, zu erzeugen. Andere Simulationsmodelle
und entsprechende Entwicklungstool-Umgebungen können jedoch auf eine ähnliche
Weise als die Basis für
andere Ausführungsbeispiele
der vorliegenden Erfindung verwendet werden.
-
Ferner kann die Software anderer
Ausführungsbeispiele
der Erfindung in variierenden Integrationspegeln mit der zugeordneten
Modellierungsumgebung erscheinen. Andere Ausführungsbeispiele können zum
Beispiel eine getrennte Folgesoftware umfassen, die separat von
dem Codeerzeugungstool installiert ist. Andere Ausführungsbeispiele,
wie zum Beispiel diejenigen, die hierin insbesondere erläutert sind,
können
eine Software beinhalten, die unabhängig von dem Codeerzeugungstool
entwickelt ist, jedoch innerhalb des Codeerzeugungstools als eines mehrerer
Sprachziele, die durch das Tool angeboten werden, integriert ist.
Außerdem
können
andere Ausführungsbeispiele
einen Code darstellen, der stark innerhalb des Codeerzeugungstools
bis zu dem Punkt integriert ist, daß ein derartiger Code durch
einen äußeren Betrachter
nicht von dem unterscheidbar ist, der den Rest des Tools aufweist.
-
3 zeigt
ein Flußdiagramm,
das ein Ausführungsbeispiel
eines Verfahrens 300 der vorliegenden Erfindung darstellt.
Als ein Eingang durch das Verfahren 300 empfangen wird
ein vorläufiges
Softwaremodell 230, das zum Beispiel der Code 230 sein kann,
der durch das Codeerzeugungstool 202 erzeugt wurde, wie
zum Beispiel RTW, wie in 2 gezeigt
ist. Das vorläufige
Softwaremodell 230 ist von einem Systemmodell 1 hergeleitet,
das innerhalb der Modellierungsumgebung 210, ebenso aus 2, erzeugt ist. Als ein
Ergebnis kann das Codeerzeugungstool 220 entweder alleine
oder in Kombination mit der Modellierungsumgebung 210 in
anderen Ausführungsbeispielen
der vorliegenden Erfindung enthalten sein.
-
Wie oben angegeben ist, ist das vorläufige Softwaremodell 230 in
der Lage, die in dem ursprünglichen
Systemmodell beschriebenen Funktionen durchzuführen. Abhängig von dem Ausführungsbeispiel
kann die Zielprogrammiersprache, die verwendet wird, um das Softwaremodell 230 zu
implementieren, C, Ada oder jede andere Programmiersprache, einschließlich objektorientierter
Programmiersprachen, wie zum Beispiel C++, sein. Bei dem Ausführungsbeispiel
aus 3 wird das vorläufige Softwaremodell 230 als
ein generisches Win32-Ziel erzeugt,
das üblicherweise
durch das RTW-Tool von Mathworks geliefert wird. Allgemein ausgedrückt erlaubt
das vorläufige
Softwaremodell 230 vor einer weiteren Verarbeitung durch
Ausführungsbeispiele der
vorliegenden Erfindung keinen Zugriff auf die internen Variablen,
wie zum Beispiel Blockparameter und interne Signale, außerhalb
der Simulink-Modellierungsumgebung.
Alternativ sind in Fällen,
in denen ein Zugriff auf die internen Variablen erlaubt ist, diese Variablen
nur mittels der Modellierungsumgebung zugänglich, die ebenso im wesentlichen
eine vollständige
Steuerung der Ausführungen
des vorläufigen
Softwaremodells 230 behält.
-
Um eine gleichzeitige Ausführungssteuerung und
einen Zugriff auf interne Variablen des Modells zu ermöglichen,
bewirken die Schritte des Verfahrens 300 die Erzeugung
einer Schnittstellensoftware 370 (aus 2), die diejenigen internen Variablen,
die sich innerhalb des vorläufigen
Softwaremodells 230 befinden, außerhalb der ursprünglichen
Modellierungsumgebung freilegt. Bei dem Ausführungsbeispiel aus 3 werden C++-Umhüller- bzw.
Wrapper-Klassen 340, die die internen Variablen des Systems
mittels Name und Datentyps beschreiben, sowie die Funktionen, die
einen Zugriff auf diese Variablen regeln, zuerst erzeugt (Schritt 310).
Die Verwendung von C++, wie anderen objektorientierten Sprachen,
ermöglicht
eine Freilegung einiger oder aller der internen Variablen auf eine
gesteuerte Weise, während
ein Zugriff auf andere Aspekte des vorläufigen Softwaremodells 230,
von denen ein Entwerfer normalerweise wünscht, daß sie versteckt bleiben, vermieden
wird. Während
C++ die Sprache ist, die für die
hierin offenbarten Ausführungsbeispiele
ausgewählt
ist, wird die Verwendung jeder anderen Sprache, die geeignet für andere
Anwendungen ist, ebenso erwogen.
-
Bei dem Ausführungsbeispiel aus 3 werden die C++-Wrapper-Klassen 340 dann
verwendet, um eine Software 350 zu erzeugen, die, wenn
sie ausgeführt
wird, einen Komponentenobjektmodell-(COM-)Server aufgebaut (Schritt 320).
COM ist eine weit verbreitete Softwarearchitekturdefinition, die
durch die Microsoft Corporation spezifiziert ist, die es ermöglicht,
daß Software-„Komponenten" oder Abschnitte
von Software, die durch separate Softwareentwickler in einer Vielzahl
von Sprachen geschrieben wurden, miteinander kommunizieren können. Grundlegend
erleichtert die COM-Architektur eine
Integration ungleicher Stücke
von Software zur Durchführung
einer integrierten Funktion durch ein Definieren einer Grundstruktur,
die verwaltet, wie diese Stücke
miteinander kommunizieren. Ein Hauptvorteil der Verwendung einer
COM-Technologie bei dem Ausführungsbeispiel
aus 3 besteht darin, daß die Technologie über im wesentli chen
alle Plattformen auf Win32-Basis verwendet wird, was die Aufgabe
einer Übertragung
und Ausführung
des resultierenden Softwaremodells auf einer derartigen Plattform
relativ elementar macht. Die Verwendung der COM-Technologie für andere
Ausführungsbeispiele der
vorliegenden Erfindung wird jedoch nicht benötigt, da andere Verfahren,
die einen Zugriff auf die internen Variablen des vorläufigen Softwaremodells 230 ermöglichen,
verwendet werden können.
Eine umfassendere Schnittstellentechnologie, wie zum Beispiel „.NET" von Microsoft, die
einen Satz von Erweiterbare-Markierungssprache-(XML-)Web-Diensten
verwendet, um eine Verbindbarkeit zwischen Abschnitten einer Software
zu ermöglichen,
kann ebenso verwendet werden. Alternativ kann eine Win32-Konsolenanwendung
direkt aus den C++-Wrapper-Klassen 340 und
dem vorläufigen
Softwaremodell 230 erzeugt werden, wodurch ein ausführbares
Simulationsprogramm erzeugt wird, das spezifisch für das bestimmte
Systemmodell erzeugt wird.
-
Als nächstes wird eine Dynamikverbindungsbibliothek
(DLL) 360 unter Verwendung des vorläufigen Softwaremodells 230,
der C++-Wrapper-Klassen 340 und der COM-Serveraufbausoftware 350 aufgebaut.
Allgemein ausgedrückt
ist eine DLL eine Softwaredatei, die mit einem ausführbaren
Programm zur Laufzeit, anstelle zu der Zeit, zu der das ausführbare Programm
aufgebaut wird, verbunden werden kann. DLLs werden häufig bei
Win32-Systemen verwendet, um eine Flexibilität bei Programmkonfigurationen
zu schaffen, indem sie es ermöglichen,
daß Entscheidungen
hinsichtlich dessen, welche Abschnitte von Software durch ein ausführbares
Programm betrieben werden sollen, während der Ausführung des
Programms getroffen werden können.
Wie bei der COM-Technologie werden DLLs weit verbreitet durch Win32-Anwendungen
verwendet.
-
Der gesamte Prozeß eines Umwandelns des innerhalb
Simulink erzeugten Systemmodells in die DLL 360 findet
automatisch innerhalb der RTW-Umgebung mittels Softwarescripten
statt, die durch den Systementwerfer als Teil des Codeerzeugungs verfahrens
eingeleitet werden. Üblicherweise
weist der Entwerfer eine Auswahl eines von mehreren Codezielen auf,
die das Simulink-erzeugte Systemmodell in Software beschreiben.
Diese Ziele umfassen normalerweise eine Software, die in C, C++,
Ada geschrieben ist, und verschiedene Typen eingebetteter Ziele
für verschiedene
Echtzeitprozessorarchitekturen. Die Ausführungsbeispiele dieser Erfindung
stellen eine weitere Auswahl eines Ziels dar, das für den Entwerfer
verfügbar
ist, wobei dieses Ziel die zuvor nicht verfügbare Fähigkeit eines Zugriffs auf
die internen Variablen des Systemmodells mittels eines Softwareclienten,
der sich außerhalb
der ursprünglichen Systemmodellierungsumgebung
befindet, liefert. Wenn dieses Ziel ausgewählt ist, wird eine Sammlung
von Softwarescripten innerhalb RTW ausgeführt, die die oben erläuterten
Schritte für
das bestimmte Systemmodell durchführen. Insbesondere wird gemäß dem Ausführungsbeispiel
aus 3 eine Visual C++-Projektdatei
erzeugt und C++ Visual Studio (auch durch Microsoft® entwickelt)
wird aufgerufen, um das Projekt aufzubauen, was zu der DLL 360 führt, die
dann durch das Betriebssystem gefragt wird, sich selbst in die Systemregistrierung
als einen COM-Server zu registrieren. Zusätzlich können auch andere Verfahren
zur Erzeugung der DLL 360 verwendet werden.
-
Sobald die DLL 360 aufgebaut
ist, kann sie zu jeder Win32-Computerplattform übertragen
werden, einschließlich
derer, die die Simulink-Entwicklungsumgebung nicht unterbringen.
Alle Informationen, die benötigt
werden, um das Systemmodell auszuführen und auf internen Variablen
dieses Modells zuzugreifen, sind in der DLL 360 enthalten.
So liefert die DLL 360 eine große Menge an Flexibilität hinsichtlich
der Typen und Anzahl von Plattformen, auf denen das resultierende
Systemmodell simuliert werden kann.
-
Um die DLL 360 zu verwenden,
wird ein Softwareclient (nicht gezeigt) oder ein ausführbares
Programm auf der ausgewählten
Plattform, die mit der DLL 360 verbunden ist, durch den
Systementwerfer eingeleitet. Mittels der COM-Technologie stellt
die DLL 360 eine standardisierte Schnittstellendefinition dar,
auf die der Softwareclient entworfen sein kann, so daß alle internen
Variablen des Systemmodells durch den Clienten zugänglich sind. Üblicherweise weist
der Client die Fähigkeit
auf, Simulationen auf dem Modell laufenzulassen, sowie das Modell
periodisch zu stoppen, so daß der
Entwerfer eine „Momentaufnahme" der Eingangssignale,
Ausgangssignale und internen Variablen des Systemmodells zu einem
bestimmten Punkt betrachten kann. Außerdem können ein Lese- und normalerweise
ein Schreibzugriff auf jedes dieser Signale und Variablen sowie
nützliche
Identifizierungsinformationen, wie zum Beispiel die Identität des Blocks,
dem jedes/jede der Signale oder Variablen zugeordnet ist, bereitgestellt
werden. Zusätzlich
können
graphische Darstellungen der Signale und Variablen bereitgestellt
werden, um dem Entwerfer eine andere Weise zum Analysieren der für jedes
Signal und jede Variable erfaßten
Werte zu liefern.
-
Der Softwareclient kann jeder einer
Anzahl von Formen annehmen. Das ausführbare Programm könnte zum
Beispiel ein „Modellbrowser" sein, der eine Spezialanwendung
ist, die insbesondere entwickelt ist, um dem Benutzer einen Zugriff
auf ein Softwaremodell und seine internen Variablen zu ermöglichen.
Der Browser ist üblicherweise
eine Win32-Anwendung,
die mit der DLL 360 verbunden ist, und erfaßt alle
internen Variablen und externen Signalinformationen, die dem durch
die DLL 360 dargestellten Modell zugeordnet sind. Diese
Informationen sind dann über
den Browser zum Überwachen
und eine mögliche
Modifizierung dieser Werte zugänglich.
Der Browser würde
sehr wahrscheinlich dem Benutzer auch die Fähigkeit liefern, Anfangsbedingungen
für das
Modell zu setzen, eine Ausführung
des Modells zu starten und zu stoppen und auf sowohl eine numerische
als auch graphische Darstellung der verschiedenen Signale und internen
Variablen, die betroffen sind, zuzugreifen.
-
Alternativ kann der Softwareclient
eine spezifische Instanzierung eines universaleren Programms, wie
zum Beispiel ei nes Microsoft Excel-Arbeitsbuchs bzw. -Workbooks,
sein. Ein derartiges Programm würde
den gleichen Typ von Zugriff auf das Modell und seine Signale und
Variablen ermöglichen.
Unterschiedliche Tabellen bzw. Spreadsheets des Arbeitsbuches könnten außerdem eine
unterschiedliche Ansicht des Betriebs des Modells liefern. Eine
Tabelle könnte
zum Beispiel jede der internen Variablen, ihre Datentypen und gegenwärtigen Werte darstellen.
Andere Blätter
können
eine graphische Darstellung spezifischer Variablen von Interesse
anzeigen.
-
Unabhängig von der spezifischen Form,
die der Softwareclient annimmt, ist ein wesentlicher potentieller
Vorteil von Ausführungsbeispielen
der Erfindung die Fähigkeit
mehrerer ungleicher DLLs 360, wobei jede möglicherweise
einen Abschnitt eines größeren Softwaremodells
darstellt, miteinander mittels des Softwareclienten in Wechselwirkung
zu stehen. Wie in 4 gezeigt
ist, steuert ein Softwareclient 400 die Ausführung vier
separater DLLs 360A, 360B, 360C und 360D.
Jede der DLLs 360A-D wurde unter Umständen innerhalb unterschiedlicher
Modellierungsumgebungen modelliert. Ein derartiger Umstand ist nicht
ungewöhnlich,
da Systementwerfer eine Modellierungsumgebung gegenüber einer
anderen zum Modellieren eines bestimmten Abschnitts eines Systems
bevorzugen können.
Zusätzlich
können die
DLLs 360A-D auf separaten Hardwareplattformen betrieben
werden, wobei jede derselben mit dem Softwareclienten 400 mittels
einer Kommunikationsverbindung kommunizieren kann. Da der Softwareclient 400 die
Ausführung
jeder DLL 360A-D steuern kann, sowie einen Zugriff auf
die internen Variablen und äußeren Signale
jeder derselben, weist der Softwareclient 400 die Fähigkeit
auf, es den DLLs 360A-D zu ermöglichen, miteinander durch
den Softwareclient 400 in Wechselwirkung zu stehen, wobei es
den DLLs 360A-D so ermöglicht
wird, als ein einzelnes System in Wechselwirkung zu stehen, während der
Softwareclient 400 ein Programmzugriff auf jede DLL 360A-D beibehält. Deshalb
können
verschiedene Softwaremodelle, ausgeführt als DLLs 360A-D,
die gemäß Ausführungsbeispielen
der vorliegenden Erfindung erzeugt werden, mit einander in Wechselwirkung
stehen, während
der Softwareclient höhere
Analysefähigkeiten über das
gesamte System mittels eines Zugriffs des Clienten auf die internen
Variablen jeder separaten DLL 360A-D beibehält.
-
Ein weiterer Vorteil der Verwendung
mehrerer DLLs 360A-D besteht darin, daß Systeme, die mehrere unabhängige Taktdomänen (in
dem Fall von Modellen auf Elektronik- oder Softwarebasis) verwenden,
genauer simuliert werden können.
Eine derartige Simulation kann durch ein Organisieren des Gesamtsystems
in separate DLLs 360A-D erzielt werden, wobei jede derselben
einen Abschnitt des Gesamtsystems darstellt, der innerhalb seiner
eigenen autonomen Taktdomäne
betrieben wird. Die DLLs 360A-D können dann auf separaten Hardwareplattformen
oder innerhalb der gleichen Plattform auf eine Multi-Tasking-Weise
ausgeführt
werden. Wie oben beschrieben ist, würde eine Wechselwirkung zwischen
den separat laufenden DLLs 360A-D dann mittels des Softwareclienten 400 ermöglicht.
-
Aus dem Vorangegangenen haben die
Ausführungsbeispiele
der Erfindung, die oben erläutert sind,
gezeigt, daß sie
ein Verfahren zum Erzeugen eines Softwaremodells eines dynamischen
Systems liefern, das mittels eines Softwareclienten ausführbar ist,
der sich außerhalb
der Modellierungsumgebung befindet, in der das ursprüngliche
Systemmodell spezifiziert wurde. Ferner sind auch andere spezifische Systeme
und Verfahren, die die Erfindung ausführt, möglich. Deshalb soll die vorliegende
Erfindung nicht auf die so beschriebenen und dargestellten spezifischen
Formen eingeschränkt
sein; die Erfindung ist nur durch die Ansprüche eingeschränkt.