-
Dynamische Systeme, die durch Menschen entwickelte
Systeme, die in einer bestimmten vorteilhaften Weise auf sich verändernde
Konditionen innerhalb ihrer Umgebung ansprechen, sind, stellen eine
beträchtliche
Herausforderung für
die Entwickler von solchen Systemen aufgrund der tausenden und unterschiedlichen
Konditionen dar, die solche Systeme effektiv handhaben müssen. Elektrische
und elektronische Schaltungen, die aber einen Typ eines dynamischen
Systems darstellen, müssen
zum Beispiel häufig
auf sich immer wieder verändernde
Eingabesignale reagieren, indem Ausgabesignale basierend auf den
Eingabesignalen geliefert werden, wodurch eine günstige Aktion in der Umwelt
verursacht wird, in der das System arbeitet. Elektrische und elektronische
Schaltungen werden äußerst vorteilhaft
bei einer Fülle
von Anwendungen verwendet, von alltäglichen Verbraucheranwendungen,
wie z. B. Mikrowellenherden und Personalcomputern, zu High-Tech-Militärwaffen.
Zusätzlich
umfassen dynamische Systeme auch einen beliebigen Typ von Software,
die geschrieben ist, um eine spezifische nützliche Funktion auszuführen. Ferner
können
dynamische Systeme jene, jedoch nicht ausschließlich solche Systeme umfassen,
die auf elektrischen, softwaretechnischen, mechanischen, pneumatischen oder
chemischen Prinzipien oder einer gewissen Kombination aus denselben
basieren.
-
Die Aufgabe des Entwickelns von dynamischen
Systemen ist durch kontinuierliche Verbesserungen in der Technologie
von einer Systemsimulation in hohem Maße verbessert worden. Eine
solche Simulation erlaubt, daß Modelle
von dynamischen Systementwürfen
anfänglich
ohne die Notwendigkeit für
teuere Prototypen, die sowohl schwierig zu bauen als auch schwierig
zu warten sind, getestet werden können. Durch die Simulation
kann ein beliebiger imaginärer
Satz von Testbe dingungen verwendet werden, um einen vorläufigen Systementwurf
sorgfältig
zu testen. Die Ergebnisse dieser Tests können dann durch die Systementwickler
verwendet werden, um das Verhalten des Systems zu analysieren. Typischerweise
werden dann, basierend auf den Ergebnissen der Tests, Veränderungen
vorgenommen, die Tests erneut durchgeführt und die Ergebnisse noch einmal
analysiert, um die positive oder negative Auswirkung der Veränderung
zu bestimmen. Somit ermöglicht
die Simulation, daß der
Entwurf des dynamischen Systems mittels eines iterativen Prozesses
vor der tatsächlichen
Konstruktion des sich im Test befindlichen Systems verbessert werden
kann, was zu einer schnelleren und produktiveren Systementwicklung
führt.
-
Ein spezifisches Beispiel einer solchen
Modellierungsumgebung ist das Simulink®-Systemdefinitions-
und – simulationswerkzeug
von The Mathworks, Inc. Wie in 2 gezeigt
ist, ermöglicht
eine Modellierungsumgebung 210 einem Systemdesigner, ein
dynamisches System, sei dies elektrisch, mechanisch oder anderweitig,
mittels eines Systemmodells 1 zu spezifizieren, das Charakteristika
besitzt, die durch den Entwickler bestimmt werden. Ein Beispiel
des Systemmodells 1 ist in 1 gezeigt.
Das Systemmodell 1 besteht aus mehreren Funktionsblöcken 2,
von denen ein jeder eine gewisse identifizierbare Aufgabe innerhalb
des Systemmodells 1 ausführt. Jeder Funktionsblock 2 kann
durch den Entwickler verwendet werden, um einen identifizierbaren Abschnitt
des Systemmodells 1 zu bezeichnen, das mittels eines spezifischen
Ziels (Target) implementiert ist, wie zum Beispiel einer Software,
die auf einem DSP (DSP = digital signal processor = digitaler Signalprozessor)
ausgeführt
wird, einer Software, die auf einem Win32-Rechensystem läuft, oder
einem Element von einer Spezialhardware, wie z. B. einem DRC (DAC
= digital-to-analog converter = Digital-Analogwandler). Üblicherweise werden ein oder mehrere
Eingabesignale 3 und Ausgabesignale 4 (die zusammen
als externe Variablen bezeichnet werden) durch das dynamische System
verwendet, das durch das Systemmodell 1 dargestellt ist,
um mit der umgebenden Umgebung zu kommunizieren und dieselbe zu
beeinflussen. Interne Signale 5 des Systemmodells 1 ermöglichen
dem Funktionsblock 2, zu kommunizieren, wodurch eine Kooperation
unter den Funktionsblöcken 2 ermöglicht wird,
um die Gesamtfunktion des dynamischen Systems auszuführen. Die meisten
Modellierungsumgebungen 210, wie z. B. Simulink, ermöglichen
auch einen hierarchischen Entwurf, da jeder Block 2 des
Systemmodells 1 ferner aus Teilblöcken (nicht gezeigt) bestehen
kann, die verschiedene Funktionen innerhalb eines zugeordneten Blocks 2 höherer Ebene
darstellen.
-
Zusätzliche können beliebige Funktionsblöcke innerhalb
des Systemmodells 1 vordefinierte Funktionsblöcke sein
(z. B. Differenzierungs- oder Integrationsfunktionsblöcke), die
normalerweise innerhalb der Modellierungsumgebung 210 verfügbar gemacht
werden, während
andere später
definierte Funktionsblöcke
sind, deren Verhalten durch den Systementwickler spezifiziert sein
kann. Solche später
definierten Blöcke
können
innerhalb der Simulink-Umgebung mittels „S-Funktionen" spezifiziert sein, die ermöglichen,
daß das
Verhalten des Blocks mittels einer vom Benutzer bereitgestellten
oder von einer dritten Partei bereitgestellten Software, die in einer
beliebigen von mehreren unterschiedlichen Sprachen einschließlich C,
Ada und Fortran geschrieben sein kann, spezifiziert werden kann.
-
Jedem Funktionsblock 2 (und
den Teilblöcken)
des Systemmodells 1 sind typischerweise verschiedene Zeitgebungsparameter
und Blockprioritäten
zugeordnet, die beim Definieren des Betriebsverhaltens von jedem
Funktionsblock 2 helfen, insbesondere, da sich dieses Verhalten
auf jenes von anderen Funktionsblöcken 2 innerhalb des
Systemmodells 1 bezieht. Die Zeitgebungsparameter zeigen an,
welche Zeitdauer erforderlich ist, bis eine Ausgabe eines Funktionsblocks 2 (oder
eines Teilblocks) den Zustand, ansprechend auf eine Veränderung
an einem der Eingänge
während
des Simulation des Systemmodells 1, verändert. Die Blockprioritäten hel fen,
zu bestimmen, welcher Funktionsblock 2 (oder Teilblock)
seine Veränderung
des Ausgabezustands in dem Fall zuerst bekannt gibt, daß zwei Funktionsblöcke 2 die
Ausgangszustände
gleichzeitig verändern
können.
Zusammen bestimmen die Zeitgebungsparameter und Blockprioritäten von
jedem der Funktionsblöcke 2 eine
Ausführungsreihenfolge
für jeden
Funktionsblock 2 über
dem gesamten Systemmodell 1.
-
Wie in 2 zu
sehen ist, kann das Systemmodell 1, das in der Simulink-Umgebung
spezifiziert ist, dann innerhalb der gleichen Umgebung unter Verwendung
von Eingabesignalen 3 simuliert werden, die durch den Systementwickler
entwickelt wurden. Die Analyse, anschließenden Entwurfsveränderungen
und die weitere Simulation des Modells tritt normalerweise innerhalb
des Wirkungsbereichs des Simulink-Werkzeugs auf. Um diesen Prozeß zu verbessern,
ermöglicht
Simulink einen Zugriff auf die internen Signale 5 des Systemmodells 1,
die dabei helfen, das Verhalten des vorgeschlagenen Systems zu definieren.
Speziell ermöglichen
die internen Signale 5 dem Entwickler einen besseren Einblick
in die Operationen des Systemmodells 1. Somit gestaltet
ein Zugriff auf diese internen Signale 5 den gesamten Simulations-
und Analyseprozeß effizienter.
-
Ein darauf bezogenes Code-Erzeugungswerkzeug 220,
wie jenes, das von The Matchworks bereitgestellt wird, das als Real
Time-Workshop (RTW) bezeichnet wird, nimmt die Systemmodelle 1, die
ursprünglich
innerhalb der Modellierungsumgebung 210 entwickelt wurden,
als Eingabe und erzeugt einen Code, der ein Softwaremodell 230 ist,
das das Systemmodell darstellt. Das Systemmodell 230 kann in
einer von mehreren unterschiedlichen Programmiersprachen einschließlich C,
Ada und andere erzeugt werden. Das Softwaremodell 230 kann
dann an eine andere Plattform übertragen
und dort ausgeführt
werden, wobei die Ausführung
des Softwaremodells 230 möglicherweise in Echtzeit fortschreitet, was
von der Beschaffenheit der Plattform abhängt. Im Fall von Softwaresystemen
kann die Plattform eine Zielplattform sein, die letztend lich zum
Implementieren des Systems verwendet wird, wodurch eine nahezu nahtlose
Progression von der Systemmodellerzeugung zum Produktionspegelcode
ermöglicht
wird.
-
Die meisten Modellierungsumgebungen
ermöglichen
lediglich die Erzeugung von Systemmodellen 1, die in ihrer
Beschaffenheit monolithisch sind. In anderen Worten wird jedes Systemmodell 1, das
durch einen Entwickler spezifiziert ist, innerhalb der Modellierungsumgebung
als eine einzelne Entität behandelt,
die en masse simuliert wird. Zusätzlich weisen
die Systemmodelle 230, die anhand jener Systemmodelle 1 mittels
eines Codeerzeugungswerkzeugs 220 erzeugt werden, die gleiche
Charakteristik auf. Viele dynamische Systeme, die heutzutage entwickelt
werden, sind jedoch nicht monolithisch, das heißt, daß solche Systeme häufig mittels
einer Mischung aus unterschiedlichen Typen von einer Hardware und
einer Software implementiert sind, wobei diese jeweils eine andere
Funktion ausführen.
Die kollektive Operation dieser verschiedenen Stücke ermöglicht dem Systemmodell 1,
letztendlich seinen gewünschten
Zweck zu erreichen. Jeder der Funktionsblöcke 2 des Systems 1 (wie
in 1 gezeigt ist) kann
beispielsweise einen Abschnitt des Systems darstellen, der auf einer
anderen Hardware/Softwareplattform implementiert werden soll. Der
FUNKTIONSBLOCK 1 soll beispielsweise als Software implementiert
sein, die auf einem Win32-Computersystem läuft, der FUNKTIONSBLOCK 2 ist
eine Software, die auf einem eingebetteten Mikroverarbeitungssystem
ausgeführt
werden soll, und der FUNKTIONSBLOCK 3 ist eine Software,
die auf einem DSP ausgeführt
wird. Um jeden dieser Funktionsblöcke 2 ausführlicher
zu simulieren, wäre
es vorteilhaft, ein Teilmodell vorliegen zu haben, das jedem Abschnitt des
Systems zugeordnet ist, der mittels einer unterschiedlichen Plattform
implementiert sein soll, da die Simulation auf einer Plattform ausgeführt werden würde, die
der letztendlichen Implementierung des Systems besser nahe kommt
und möglicherweise dasselbe
vervielfältigt.
Zusätzlich
kann ein Aufteilen einer Simulation in mehrere „Teilmodelle", die jeweils auf einer
separaten Plattform laufen, komplexere Simulationen beschleunigen,
da die Verarbeitung, die erforderlich ist, auf mehrere Plattformen,
die gleichzeitig laufen, verteilt werden würde. Abwechselnd können ein
oder mehrere der Teilmodelle durch die tatsächliche Komponente, wie z.
B. einen Elektromotor, ersetzt werden, den ein spezielles Teilmodell
darstellt, um das Gesamtsystem exakter zu testen.
-
Derzeit, um die Simulation in einer
solchen Weise zu verbessern, kann das Systemmodell 1 manuell
durch den Entwickler in separate Systemteilmodelle getrennt werden,
wie z. B. jeden der Funktionsblöcke 2 des
Systemmodells 1. Jedes der Systemmodelle würde dann
mittels eines Codeerzeugungswerkzeugs, wie zum Beispiel ein RTW,
verwendet werden, um Softwareteilmodelle zu erzeugen, von denen
ein jedes dann auf separaten Zielplattformen simuliert werden könnte.
-
Leider entstehen infolge eines manuellen
Erzeugens der Teilmodelle mehrere Probleme. Erstens führt der
Prozeß des
Erzeugens der Systemmodelle von dem Systemmodell per Handeingabe
möglicherweise
dazu, daß Fehler
in die Teilmodelle eingebracht werden, da keine automatische Verbindung zwischen
dem Originalsystemmodell 1 und den Teilmodellen besteht.
Zweitens muß eine
spezifische Software jedem Softwareteilmodell hinzugefügt werden,
um eine Kommunikation zwischen den verschiedenen Teilmodellen, die
auf unterschiedlichen Zielplattformen laufen, zu liefern.
-
Drittens, da zumindest ein Teil des
Betriebsverhaltens eines Teilmodells durch seine Interaktion mit
dem Rest des Systems bestimmt wird, müßten jene System-Ebene-Charakteristika,
die das Teilmodellverhalten beeinflussen, als ein Teil von jedem Teilmodell
erfaßt
werden, um den Teilmodellen zu ermöglichen, sich ordnungsgemäß als ein
Abschnitt des Gesamtsystems zu verhalten. Der Entwickler muß z. B.
sicherstellen, daß jedes
der Softwareteilmodelle konsistente Zeitgebungsparameter und Blockprioritäten einbehält, die
die Ausführungsreihenfolge bestimmen,
in der die Blöcke
während
eines Zeitschritts der Simulation verarbeitet werden. Ansonsten
kann die Simulation über
den verschiedenen Softwareteilmodellen zu einer Systemblockade (bzw. Deadlock)
führen,
die bewirkt, daß die
Simulation vor einer erfolgreichen Beendung anhält. Die Typen von Daten, die
jedem Teilmodell präsentiert
werden, können
ebenfalls durch andere Abschnitte des Systems bestimmt werden. Bis
jedes Teilmodell konfiguriert ist, um den ordnungsgemäßen Datentyp
zu akzeptieren, ist somit eine ordnungsgemäße Ausführung der Teilmodelle nicht
wahrscheinlich, da die eingegebenen Daten fehlinterpretiert werden
können.
Diese Probleme resultieren von dem separaten Systemteilmodellen,
die manuell erzeugt werden, da jedes solche Teilmodell innerhalb
der Umgebung des Systemmodells 1 nicht als ein Ganzes erzeugt
und validiert wird. Auch werden die Veränderungen, die in dem Systemmodell 1 vorgenommen
werden, nicht in früher
erzeugten Systemteilmodellen reflektiert, und umgekehrt, was zu
einer separaten, aufwendigen Wartung von sowohl dem Systemmodell 1 als
auch den Systemteilmodellen führt.
-
Daher wären, anhand des Vorstehenden, Verfahren
von Vorteil, die eine automatische Zerlegung von einem Systemmodell
in separate Systemteilmodelle, gemäß einer Anweisung durch einen Systementwickler
ermöglichen.
Jedes Systemteilmodell könnte
dann möglicherweise
eingesetzt werden, um ein Softwareteilmodell zu erzeugen, das auf
einer Zielplattform nach dem Ermessen des Entwicklers ausführbar ist,
wodurch sowohl die Genauigkeit als auch die Geschwindigkeit der
Simulation des integrierten Systems verbessert wird.
-
Es ist eine Aufgabe der vorliegenden
Erfindung, ein Verfahren zum automatischen Zerlegen von dynamischen
Systemmodellen in Teilmodelle zu schaffen.
-
Diese Aufgabe wird durch ein Verfahren
gemäß Anspruch
1, ein Computersystem gemäß Anspruch
14 sowie ein Programmspeicherungsmedium gemäß Anspruch 21 gelöst.
-
Die Ausführungsbeispiele der vorliegenden Erfindung,
die nachstehend ausführlich
erörtert
werden, stellen ein Verfahren zum automatischen Zerlegen eines Systemmodells
in Systemteilmodelle dar, wodurch die Simulation des Modells auf
mehreren diversen Zielplattformen gleichzeitig geschehen kann. Als
eine Vorstufe zu den Verfahren, die nachstehend beschrieben sind,
organisiert der Systementwickler das Systemmodell in separate Abschnitte,
von denen ein jeder ein spezielles Systemteilmodell darstellt, das
auf einer Zielplattform ausgeführt
werden soll. Die Ausführungsbeispiele
der Erfindung liefern dann eine Möglichkeit für den Entwickler, um anzuzeigen, welche
Abschnitte des Systemmodells Teilmodelle werden sollen. Optional
kann der Benutzer auch die zugeordnete Zielplattform für die Ausführung von
jedem Teilmodell anzeigen. Ein Code, der durch die Ausführungsbeispiele
der Erfindung bereitgestellt wird, erzeugt dann ein Systemteilmodell
für jeden
Abschnitt, der durch den Entwickler bezeichnet wird, wobei alle
kritischen System-Ebene-Informationen, wie z. B. Zeitgebungsparameter
und Blockprioritäten erhalten
bleiben, die im gesamten Systemmodell konsistent sind. Jedes dieser
Systemteilmodelle kann dann verwendet werden, um ein Softwareteilmodell
zu erzeugen, das dann an die korrekte Zielplattform für eine Ausführung übertragen
werden kann. Alternativ können
ein oder mehrere Systemteilmodelle durch die tatsächlichen
Komponenten des Systems, die durch diese Systemteilmodelle dargestellt werden,
ersetzt werden.
-
Den verschiedenen Ausführungsbeispielen der
Erfindung können
mehrere Vorteile zugeordnet sein. Da die Erzeugung der Systemmodelle
automatisch ausgeführt
wird, ist die Möglichkeit,
daß Fehler in
die Systemteilmodelle eingebracht werden, im wesentlichen ausgeschaltet.
Die gesamte Software, die den Softwareteilmodellen hinzugefügt werden
muß, um
eine Kommunikation zwischen den verschiedenen Teilmodellen zu vereinfachen,
wird ebenfalls automatisch erzeugt. Da das Systemmodell direkt verwendet
wird, um die Systemteilmodel le zu erzeugen, werden zusätzlich konsistente
Zeitgebungsparameter und Blockprioritäten zwischen den Funktionsblöcken innerhalb
und zwischen jedem Teilmodell beibehalten, um eine Systemblockade
zu verhindern. Da die Systemteilmodelle automatisch von dem Systemmodell
erzeugt werden, können
ferne alle Veränderungen
an dem System ausschließlich
auf der Systemmodellebene vorgenommen werden, wobei Veränderungen
an den Teilmodellen automatisch berücksichtigt werden, immer wenn
die Systemteilmodelle gebaut werden.
-
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
dargestellt werden kann, sowie andere Modellierungsumgebungen,
-
2 ein
Flußdiagramm
eines Verfahrens aus dem Stand der Technik zum Entwickeln eines Systemmodells
und eines Softwaremodells eines dynamischen Systems,
-
3 ein
Blockdiagramm des Systemmodells von 1,
das durch einen Entwickler gemäß eines
Ausführungsbeispiels
der Erfindung eingerichtet bzw. dekoriert worden ist,
-
4 ein
Flußdiagramm
eines integrierten Gesamtprozesses zum Erzeugen eines Systemmodells
und zum Zerlegen dieses Systemmodells in zugeordnete Systemteilmodelle
und Softwareteilmodelle,
-
5 ein
Flußdiagramm
eines Verfahrens gemäß einem
Ausführungsbeispiel
der Erfindung zum automatischen Erzeugen eines separaten Systemteilmodells von
einem dekorierten Systemmodell, wie in 4 angemerkt ist,
-
6 ein
vereinfachtes Blockdiagramm der Zwischenbeziehung von einem Satz
von Softwareteilmodellen, die von dem dekorierten Systemmodell von 3 erzeugt werden, die auf
unterschiedlichen Zielplattformen ausgeführt werden.
-
Die Ausführungsbeispiele der Erfindung,
die nachstehend ausführlich
beschrieben sind, nutzen die vorstehend beschriebene Mathworks-Simulink®-Modellierungsumgebung
als Ausgangspunkt. Andere Simulationsmodellumgebungen können jedoch
in einer ähnlichen
Weise als die Grundlage für alternative
Ausführungsbeispiele
der vorliegenden Erfindung verwendet werden.
-
Ferner kann die Software von alternativen Ausführungsbeispielen
der Erfindung in verschiedenen Integrationspegeln mit der zugeordneten
Modellierungsumgebung manifestiert sein. Alternative Ausführungsbeispiele
können
eine unterscheidbare Anschlußsoftware
umfassen, die beispielsweise separat von der Modellierungsumgebung
installiert ist. Andere Ausführungsbeispiele,
wie jene die speziell hierin erörtert
sind, können
eine Software involvieren, die unabhängig entwickelt wurde, aber
in die Modellierungsumgebung integriert ist. Andere Ausführungsbeispiele
können
auch einen Code darstellen, der zu dem Punkt in hohem Maße integriert
ist, daß ein
solcher Code durch einen externen Beobachter von dem nicht unterscheidbar
ist, der den Rest der Modellierungsumgebung aufweist.
-
4 zeigt
eine integrierte Darstellung 400 der Schritte, die durch
die Ausführungsbeispiele
der Erfindung geliefert werden, die in die Schritte eingeschoben
worden sind, die durch den Systementwickler oder andere Benutzer
ausgeführt
werden. Die direkt den Ausführungsbeispielen
der Erfindung zugeordneten Schritte sind mit Hilfe der Blöcke mit
gestrichelten Grenzen angezeigt.
-
Zuerst liefern die Ausführungsbeispiele
der vorliegenden Erfindung einen Satz von Zerlegungsfunktionsblöcken 6, 7 und 8 (aus 3) zur Verwendung in einem
Modell, das durch den Entwickler (Schritt 410 von 4) definiert ist. Die Zerlegungsfunktionsblöcke 6, 7, 8 sind
typischerweise vordefinierte Blöcke
oder durch Dritte definierte Blöcke,
die sich in einer Bibliothek innerhalb der Modellierungsumgebung
befinden. Wie andere Funktionsblöcke stehen
die Zerlegungsfunktionsblöcke 6, 7, 8 zur
Verfügung,
um durch den Systementwickler verwendet und modifiziert zu werden.
-
In 4 modifiziert
der Systementwickler ein Systemmodell 1 (von 1), indem dem Systemmodell
eine Mehrzahl von Zerlegungsfunktionsblöcken 6, 7, 8 hinzugefügt wird
oder das Systemmodell 1 mit denselben dekoriert wird (Schritt
420 von 4), was zu einem
dekorierten Systemmodell 100 führt, das in 3 ausführlich gezeigt ist. Jeder der
möglichen Zerlegungsblöcke 6, 7, 8 weist
typischerweise ein maskiertes Dialogfeld auf, das denselben zugeordnet ist,
das dem Entwickler nach einer Instantiierung eines solchen Blocks
innerhalb des dekorierten Systemmodells 100 präsentiert
wird. Solche Dialogfelder ermöglichen
eine spezifische Ausführung
des Funktionsblocks, dem es zugeordnet ist.
-
Die Zerlegungsfunktionsblöcke 6, 7, 8 bestehen
aus mehreren unterschiedlichen Typen von Blöcken, von denen ein jeder einem
speziellen Zweck dient. In den beigefügten Ausführungsbeispielen wird ein Systeminformationsblock 6 beispielsweise
pro dekoriertes Systemmodell 100 verwendet. Der Systeminformationsblock 6 wird
verwendet, um globale Systeminformationen, wie z. B. den Namen oder
den Identifizierer des dekorierten Gesamtsystemmodells 100,
allen Systemteilmodellen zur Verfügung zu stellen, um später erzeugt
zu werden. Der Entwickler kann die Informationen mittels eines maskierten
Dialogfelds spezifizieren, die demselben zugeordnet sind, das dem
Entwickler nach einer Instantiierung des Blocks innerhalb des dekorierten
Systemmodells 100 präsentiert
wird. Der Systeminformationsblock 600 wird normalerweise
innerhalb der Obere-Ebene-Darstellung des dekorierten Systemmodells 100, wie
jenes, das in 3 dargestellt
ist, plaziert. Da der Systeminformationsblock 6 nicht in „funktioneller" Weise mit dem Rest
des dekorierten Systemmodells 100 arbeitet, ist der Systeminformationsblock 6 nicht mit
beliebigen anderen Funktionsblöcken
mittels interner Signale an und von diesen Blöcken verbunden.
-
Ein weiterer Typ von Zerlegungsfunktionsblock,
der vorgesehen ist, ist der Zielinformationsblock 7, von
dem einer auf der oberen Ebene für
jedes Systemteilmodell plaziert ist. In dem spezifischen Fall des
dekorierten Systemmodells 100 von 3, wird ein Zielinformationsblock 7 in
der Beschreibung der oberen Ebene dieses Modells verwendet. Da drei unterschiedliche
Systemteilmodelle innerhalb der dekorierten Systemmodells 100 definiert
sind, die jeweils dem FUNKTIONSBLOCK 1 (Win32-Zielplattform),
dem FUNKTIONSBLOCK 2 (der in der Mikroprozessorzielplattform
eingebettet ist) und dem FUNKTIONSBLOCK 3 (digitaler Signalprozessor-Zielplattform) entsprechen,
werden insgesamt drei Zielinformationsblöcke 7 verwendet. Der
FUNKTIONSBLOCK 2 und der FUNKTIONSBLOCK 3 enthalten
jeweils einen Zielinformationsblock auf der nächsten untersten Ebene der
Abstraktion (nicht gezeigt) für
jedes dieser Teilmodelle. Bei diesem speziellen Ausführungsbeispiel
enthält
der FUNKTIONSBLOCK 1 keinen separaten Zielinformationsblock 7, da
das Diagramm auf hoher Ebene, das in 3 gezeigt
ist, als die tatsächliche
hohe Ebene für
das Win32-Teilmodell in diesem Fall dient, wie durch den Zielinformationsblock 7,
der in 3 gezeigt ist,
bezeichnet ist. Somit beinhaltet das Win32-Teilmodell nicht nur
den FUNKTIONSBLOCK 1, sondern auch Eingabesignale 3,
Ausgabesignale 4 und beliebige Hardwarefunktionen, die
innerhalb dieses speziellen Teilmodells simuliert werden. Jeder
Zielinformationsblock 7 weist ein zugeordnetes Dialogfeld
auf, das dem Entwickler ermöglicht,
das spezielle dargestellte Systemteilmodell, die Identität des Gesamtsystemmodells,
mit dem das Systemteilmodell verwandt ist, und einen Hinweis auf
die spezielle Zielplattform (Win32-System, DSP, feldprogrammierbares
Gatterarray, usw.) zu nennen, woraufhin das resultierende Softwareteilmodell
ausgeführt
wird. Ein Hinweis auf ein „NULL"-Ziel innerhalb des
Dialogfelds zeigt an, daß die
zugeordnete Komponente des tatsächlichen
Systems den Platz des Teilmodells in dem zerlegten Simulationsmodell
einnehmen wird. Die resultierenden Informationen für jeden
Zielinformationsblock werden in einem Schablonenmodell zur späteren Verwendung
während
der Erzeugung der Systemteilmodelle gespeichert.
-
Der Entwickler besiedelt auch das
dekorierte Systemmodell 100 mit I/O-Blöcken 8 (I/O = input/output
= Eingabe/Ausgabe), wie in 3 gezeigt
ist, wobei die Position und Beschaffenheit der Kommunikationsverknüpfungen
gezeigt ist, die durch die verschiedenen Systemteilmodelle verwendet
werden, um miteinander zu kommunizieren. Jeder I/O-Block 8 umfaßt typischerweise
ein einfaches I/O-Teilsystem mit Eingangs- und Ausgangsports zusammen
mit einem I/O-Simulationscode
(nicht gezeigt) und einen I/O-Informationsblock
(ebenfalls nicht gezeigt). Der I/O-Simulationscode wird verwendet, wenn
das zugeordnete Teilmodell in einer vollen System-Ebene-Simulation
verwendet wird. Der I/O-Informationsblock liefert einen Hinweis
darauf, welcher Satz des Codes in die Teilmodelle verknüpft werden
soll, um die I/O tatsächlich
zu implementieren. Der durch den I/O-Informationsblock ausgewählte Code
kann ein Code sein, der eine I/O-Kommunikation mit einem anderen
Teilmodell liefert, oder der Code sein, der eine Kommunikation mit
der tatsächlichen
Komponente, die laut Entwurf ein weiteres Teilmodell darstellen
soll, liefert. Dem I/O-Informationsblock
ist ein Dialogfeld zugeordnet, das dem Entwickler erlaubt, anzuzeigen,
welcher Satz des I/O-Kommunikationscodes
verwendet werden soll. Der I/O-Informationsblock
kann auch Informationen bezüglich
der Zielplattform enthalten, die jedem der Eingabe- und Ausgangsports
des I/O-Blocks für
eine Teilmodellinterkommunikation zugeordnet ist; alternativ können diese
Informationen während
der tatsächlichen
Erzeugung der Systemteilmodelle abgeleitet werden, da jeder Abschnitt
eines dekorierten Systemmodells 100 eine Zielplattform
an diesem Punkt zugeordnet ist. In dem spezifischen Fall des dekorierten
Systemmodells 100 von 3 weist
jede Kommunikationsverknüpfung
zwischen den Teilmodellen einen I/O-Block 8 auf, der derselben
zugeordnet ist.
-
Die I/O-Technologie, die für die Kommunikation
zwischen den Softwareteilmodellen genutzt wird, die von dem Systemteilmodellen
resultieren, können eine
beliebige Kommunikationsverknüpfung
sein, die innerhalb oder zwischen den Rechensystemen verwendbar
ist. Beispielsweise kann die COM-Technologie
(COM = Component Object Model = Komponentenobjektmodell), die durch
die Firma Microsoft Corporation® entwickelt
wurde, verwendet werden. Die COM ist eine in weiten Kreisen verwendete
Softwarearchitekturdefinition, die „Softwarekomponenten" oder Abschnitten
einer Software, die durch separate Softwareentwicklung in einer
Vielfalt von Sprachen geschrieben worden sind, ermöglicht,
miteinander zu kommunizieren. Im Grunde vereinfacht die COM-Architektur eine
Integration von ungleichartigen bzw. disparaten Stücken einer
Software, um eine integrierte Funktion durch Definieren eines Rahmens
auszuführen,
der reguliert, wie diese Stücke
miteinander kommunizieren. Eine weitere I/O-Technologieoption ist „.NET" von Microsoft, die
eine umfassendere Schnittstellenverbindungstechnologie als COM ist, die
einen Satz von XML-Webdiensten verwendet, um eine Interkonnektivität von Abschnitten
einer Software zu ermöglichen.
Viele andere I/O-Technologien, die heutzutage verfügbar sind,
wie z. B. eine gemeinsam verwendete Speicher-I/O, können ebenfalls
verwendet werden. In dem Fall, das das zugeordnete Teilmodell mit
einer tatsächlichen
Komponente des Systems kommunizieren soll, die simuliert wird, kann die
I/O-Technologie, die verwendet wird, ein hardware spezifischer Gerätetreiber
sein, der speziell mit dieser Komponente schnittstellenmäßig verbunden werden
soll.
-
Bei den offenbarten Ausführungsbeispielen, die
sich auf Simulink beziehen, sind die Zerlegungsfunktionsblöcke 6, 7, 8 als „S-Funktionen" implementiert, wie
vorstehend beschrieben ist. In anderen Worten sind die Zerlegungsfunktionsblöcke 6, 7, 8 mittels Abschnitten
von einer Software definiert, die die Funktionalität der zugeordneten
Zerlegungsfunktionsblöcke 6, 7, 8 beschreiben
und aufweisen.
-
Nachdem der Entwickler das dekorierte
Systemmodell 100 beendet hat, initiiert der Entwickler den
Prozeß,
wodurch die verschiedenen Systemteilmodelle automatisch erzeugt
werden. Gemäß den offenbarten
Ausführungsbeispielen
wird dieser Prozeß durch
eine Anzahl von Softwareskripten ausgeführt, die innerhalb der Modellierungsumgebung 210 geliefert
werden.
-
Der Zerlegungsprozeß (Schritt
440 von 4, der in 5 ausführlicher gezeigt ist) beginnt mit
einer Validierung des dekorierten Systemmodells 100, um
sicherzustellen, daß es
ordnungsgemäß in Systemteilmodelle
(Schritt 510) zerlegt werden kann. Wenn das dekorierte Systemmodell
die Validierung nicht besteht, wird der Zerlegungsprozeß angehalten.
-
Anschließend wird die Ausführungsreihenfolge
eines dekorierten Systemmodells 100 erzeugt (Schritt 520).
Die Ausführungsreihenfolge
ist im wesentlichen die sequentielle Reihenfolge, in der die Funktionsblöcke des
dekorierten Systemmodells 100 für jeden Zeitschritt während der
Simulation ausgeführt
werden. Die Ausführungsreihenfolge
wird anhand von kritischen Systemebeneinformationen erzeugt, wie
z. B. die Zeitgebungsparameter und Blockprioritäten, die dem dekorierten Systemmodell 100, wie
vorstehend beschrieben, zugeordnet sind. Die Erzeugung der Ausführungsreihenfolge
ist notwendig, um sicherzustellen, daß die verschiedenen Funktionsblöcke von
jedem Systemteilmodell in der ordnungsgemäßen Reihenfolge ausgeführt werden, um
eine Systemblockade oder andere Zeitgebungsprobleme zu verhindern,
wenn die verschiedenen Teilmodelle gemeinsam ausgeführt werden.
-
Jeder der Funktionsblöcke des
dekorierten Systemmodells 100 wird dann analysiert, so
daß sie in
den entsprechenden Systemteilmodellen organisiert sein können (Schritt
530). Jeder I/O-Block 8, der während dieses Schritts angetroffen
wird, wird jedem der Teilmodelle zugewiesen, dem er zugeordnet ist. Jeder
Zielinformationsblock 7, der angetroffen wird, zeigt den
oberen Block oder „Wurzelblock" für jedes Teilmodell
an.
-
Unter Verwendung von jedem Zielinformationsblock 7 wird
dann das Systemteilmodell für
diesen Zielinformationsblock 7 erzeugt. Zuerst wird das Systemteilmodell
unter Verwendung von Schablonenmodellinformationen von dem Zielinformationsblock 7 (Schritt
540) erzeugt. Die innerhalb des Systeminformationsblocks 6 gespeicherten
Informationen werden auch an das neue Teilmodell kopiert, um dasselbe
wieder auf das dekorierte Systemmodell 100 zu beziehen
(Schritt 550). Alle Blöcke,
die sich unter dem Wurzelblock für
dieses Teilmodell befinden, werden dann an das neue Teilmodell kopiert,
zusammen mit ihren zugeordneten Zwischenverbindungen (Schritt 560).
Beliebige I/O-Blöcke 8,
die an das neue Teilmodell kopiert werden, werden dann mit dem ordnungsgemäßen Informationen
bezüglich
der Beschaffenheit bezüglich
der zugeordneten Kommunikationsverknüpfung aktualisiert (Schritt
570). In diesem Schritt ist enthalten, ob jeder I/O-Block 800 eine Senke
bzw. einen Verbraucher oder eine Quelle von Daten ist. Diese Informationen
sind üblicherweise von
dem dekorierten Systemmodell 100 erhältlich, da die meisten Modellierungsumgebungen,
wie z. B. Simulink, die Richtung des Datenflusses für ein beliebiges
internes Signal 5 innerhalb eines Systemmodells anzeigen.
In diesem Aktualisierungsschritt ist auch die Ersetzung von I/O-Komponenten abhängig von den
Informationen in den I/O-Block 8 bezüglich dessen, ob eine tatsächliche
Komponente oder ein anderes Systemteilmodell durch den I/O-Block
kommuniziert wird, enthalten. Schließlich wird jeder Block innerhalb
des Teilmodells der Ausführungsreihenfolge zugeordnet,
die von dem dekorierten Systemmodell 100 erzeugt wird (Schritt
580).
-
Nachdem jedes der Systemteilmodelle
erzeugt worden ist, wird eine Systeminformationsdatei, die Informationen
bezüglich
der Zerlegung des Systemmodells in verschiedene Systemteilmodelle
hält, erzeugt
(Schritt 440 von 4).
In den beigefügten Ausführungsbeispielen
ist die Systeminformationsdatei in einem XML-Format (XML = eXtensible
Markup Language = erweiterbare Markierungssprache), jedoch kann
ein beliebiges geeignetes Datenformat verwendet werden. Die Informationen
innerhalb dieser Datei werden dann anschließend verwendet, um die resultierenden
Softwareteilmodelle auf ihre angeforderten Zielplattformen herunterzuladen.
Zusätzlich kann
die Systeminformationsdatei, die gelegentlich als das Manifest für das System
bezeichnet wird, auch Informationen zum Leiten der Konstruktion
des tatsächlichen
Systems, das modelliert wird, umfassen. Diese Informationen können beispielsweise
verwendet werden, um bei der Einordnung von elektronischen Teilen,
der Kombination des Quellencodes und dergleichen zu helfen.
-
Jedes der Systemteilmodelle wird
dann verwendet, um zugeordnete Softwareteilmodelle zu erzeugen (Schritt
450 von 4), die auf
die spezifischen Zielplattformen, für die ein jedes eingeplant war, übertragen
werden sollen. Dieser Prozeß wird normalerweise
mittels eines Codeerzeugungswerkzeugs erreicht, das in den beigefügten Ausführungsbeispielen
das RTW-Werkzeug von The Matchworks ist. Informationen von den Schablonenmodul
für jedes
Systemteilmodul unterstützen
diesen Prozeß. Während der
Codeerzeugung werden Informationen bezüglich jedem der Softwareteilmodelle
der XML-Systeminformationsdatei hinzugefügt.
-
Nach dem Ermessen des Entwicklers
kann dann jedes der Softwareteilmodelle an die entsprechende Zielplattform,
auf der das Softwareteilmodell ausgeführt werden kann, übertragen
werden. Typischerweise führt
ein Dienst innerhalb der Modellierungsumgebung 210 diese
Aufgabe, die durch die Informationen, die zuvor in der XML-Systeminformationsdatei
gespeichert wurden, unterstützt
wird, automatisch aus.
-
Nachdem die verschiedenen Softwareteilmodelle
an die entsprechenden Ziele übertragen
wurden, kann ein resultierendes verteiltes Systemteilmodell 600 für Simulationszwecke
ausgeführt
werden, wie in Fig. 6 gezeigt
ist. Unter Verwendung des spezifischen Falls des dekorierten Systemmodells 100 von 3 wird jedes der drei Softwareteilmodelle 610, 620 und 630 gleichzeitig
ausgeführt,
wobei eine Kommunikation zwischen jedem der Teilmodelle 610, 620, 630 über die
Kommunikationsverknüpfungen 640 stattfindet.
Angesichts einer angemessenen Auswahl von Zielplattformen durch
den Entwickler, wird die Ausführung
von jedem Teilmodell 610, 620, 630 aufgrund
der Beziehung zwischen dem Teilmodell und der ausgewählten Zielplattform
potentiell effizienter. Das Win32-Teilmodell 610 könnte beispielsweise
am besten auf einem aktuellen Win32-Rechensystem simuliert werden.
Andererseits arbeitet das DSP-Softwareteilmodell 630 aller
Wahrscheinlichkeit nach am effizientesten auf einem aktuellen DSP-System
oder einem DSP-Emulator. Durch Zerlegen des Systemmodells in separate
Teilmodelle, von denen ein jedes auf einer Zielplattform läuft, die einen
Abschnitt des Produktionssystems tatsächlich implementiert oder demselben
ziemlich angenähert ist,
ist die resultierende Systemebene-Simulation wahrscheinlich eine bessere
Darstellung dessen, was unter normalen Betriebsbedingungen geschieht.
-
Wie vorstehend erwähnt, ist
ein weiteres Beispiel einer potentiellen Zielplattform ein FPGA.
FPGAs können
viele Berechnungen viele Male schneller als Mikroprozessoren ausführen. Infolgedessen sind
FPGAs speziell für
DSP-Anwendungen,
wie zum Beispiel aktuelle simulierte Kommuni kationssysteme, besonders
geeignet, was zu einem im hohen Maße verbesserten Verhalten gegenüber anderen Alternativen
führt.
-
Zusätzlich, da die resultierende
Systemsimulation auf mehreren Plattformen ausgeführt wird, kann die Gesamtsimulationszeit
aufgrund der Menge der Simulationsverarbeitung, die gleichzeitig
zwischen den Zielplattformen geschieht, beträchtlich reduziert werden, wodurch
die Gesamtsimulationszeit potentiell reduziert wird, wodurch eine
Marktreifezeit für
das tatsächliche
dynamische System verbessert wird.
-
Wie vorstehend erwähnt, können ein
oder mehrere Systemteilmodelle durch tatsächliche Komponenten ersetzt
werden, die schließlich
im dynamischen System, das simuliert wird, verwendet werden. Eine
solche Ersetzung von tatsächlichen
Komponenten für
Teilmodelle kann ferner die Gesamtgenauigkeit und Effizienz der
Simulation des gesamten Systems verbessern.
-
Aus vorstehendem wird ersichtlich,
daß die vorstehend
erörterten
Ausführungsbeispiele
der Erfindung nachweislich ein Verfahren zum automatischen Zerlegen
von dynamischen Gesamtsystemmodell in separate Systemteilmodelle
schafft. Ferner sind auch andere spezifische Systeme und Verfahren,
die die Erfindung verkörpern,
möglich.
Daher ist die vorliegende Erfindung nicht auf die spezifischen Formen,
die beschrieben und dargestellt sind, begrenzt, die Erfindung ist
nur durch die Ansprüche
begrenzt.