-
Die Erfindung betrifft ein Verfahren zur flexiblen automatisierten Verbindung von Teilmodellen eines Gesamtmodells unter Berücksichtigung einer gegebenen Systemarchitektur in einer Simulationsumgebung. Die Erfindung betrifft ferner eine Rechneranordnung mit einer Simulationsumgebung, die zur Ausführung des Verfahrens ausgebildet ist, sowie ein korrespondierendes Computerprogramm.
-
Verfahren, Entwicklungssysteme und Simulationsumgebungen zur Modellierung und/oder Simulation von Systemen sind im Stand der Technik hinreichend bekannt.
-
Reale Systeme, beispielsweise Fahrzeugregelsysteme, Produktionssteuerungen, Maschinensteuerungen und ähnliche mehr oder weniger aufwändig gestaltete Einrichtungen mit Steuerungs- und/oder Regelungsfunktionalität sind regelmäßig zu komplex, um mit vertretbarem Aufwand formelmäßig erfasst und gehandhabt werden zu können. Insbesondere ist es häufig der Fall, dass derartige Systeme nicht eindeutig und explizit beschrieben bzw. berechnet werden können.
-
Somit empfiehlt es sich, derartige Systeme unter Zuhilfenahme von Systemsimulationen zu entwickeln, zu testen und zu verbessern. Im Stand der Technik sind verschiedene Werkzeuge zur Modellierung und Simulation von Systemen bekannt. Beispielsweise erlauben die Programmsysteme Simulink® oder SystemBuildTM eine graphikunterstützte Modellierung, Anpassung und Simulation von dynamischen Systemen. Derartige Simulationsumgebungen können auch dazu genutzt werden, ein dort modelliertes System, also ein System in der Modellierebene (oder: Modellebene), in ein implementiertes System, also ein System in einer Zielebene, zu überführen. Zu diesem Zweck können die erzeugten Modelle durch manuelle und/oder automatisierte Codegenerierung in Seriencode überführt werden, der auf dem Zielsystem lauffähig ist. Simulationsumgebungen können jedoch beispielsweise auch dazu dienen, lediglich teilweise implementierte Systeme zu testen. Zu diesem Zweck kann beispielsweise ein bestimmtes Steuergerät eines Gesamtsystems simuliert werden, wobei andere Steuergeräte oder Systemkomponenten bereits in der Zielebene realisiert sind. Es ist jedoch auch vorstellbar, das Simulationsmodell bereits in einen Seriencode zu überführen, diesen jedoch weiterhin in einer Simulationsumgebung laufen zu lassen, um Tests durchzuführen und gegebenenfalls Optimierungen oder Veränderungen einfließen lassen zu können.
-
Im Stand der Technik sind verschiedene Ansätze bekannt, wie ein Simulationsmodell (das in der Modellebene ansässig ist) möglichst automatisiert und ohne manuellen Eingriff in Seriencode für ein Zielsystem überführt werden kann. So zeigt beispielsweise die
DE 103 47 891 A1 ein Verfahren zur Erzeugung eines ausführbaren Gesamt-Steuerungsprogramms zur Steuerung eines Steuerungssystems, wobei mithilfe eines durch eine graphische Modellierungsumgebung erstellten Blockdiagramms ein Funktions-Steuerungsprogramm erzeugt wird, wobei mindestens eine Signallinie des Blockprogramms als symbolischer Modell-I/O-Zugriffspunkt für den Zugriff auf ein sogenanntes I/O-Gerät eindeutig gekennzeichnet wird, wobei ein Übersetzungsprogramm das Blockdiagramm unabhängig von dem Steuerungssystem und/oder dem I/O-Gerät und deren Eigenschaften in ein auf dem Steuerungssystem ausführbares Funktions-Steuerungsprogramm übersetzt, das durch Modell-I/O-Zugriffspunkte verursachte korrespondierende Programm-I/O-Zugriffspunkte aufweist, und wobei mittels einer zusätzlichen Konfigurationsumgebung ein I/O-Steuerungsprogramm erzeugt wird, das zusammen mit dem Funktions-Steuerungsprogramm das auf dem Steuerungssystem lauffähige Gesamt-Steuerungsprogramm bildet, wobei das Funktions-Steuerungsprogramm über seine Programm-I/O-Zugriffspunkte auf Elemente des I/O-Steuerungsprogramms zugreift.
-
Ferner zeigt die
DE 103 33 087 A1 ein Verfahren zum Zerlegen eines Systemmodells eines dynamischen Systems, wobei das Systemmodell eine Mehrzahl von Funktionsblöcken aufweist, wobei das Verfahren die folgenden Schritte aufweist: einem Entwickler ermöglichen, das Systemmodell einzurichten, was zu einem eingerichteten Systemmodell mit einer Mehrzahl von separaten Abschnitten führt; automatisches Erzeugen eines Systemteilmodells von dem eingerichteten Systemmodell für jeden von der Mehrzahl von separaten Abschnitten des eingerichteten Systemmodells, während eine Konsistenz von allen kritischen Systemebenen Informationen von jedem Systemteilmodell mit dem eingerichteten Systemmodell beibehalten wird; einem Entwickler ermöglichen, eine Zielplattform zu identifizieren, die jedem von der Mehrzahl von separaten Abschnitten des eingerichteten Systemmodells zuzuordnen ist; und Erzeugen eines Softwaremodells von zumindest einem Systemteilmodell zum Ausführen auf der Zielplattform, die diesem Systemteilmodell zugeordnet ist.
-
Die bekannten Verfahren befassen sich daher vordringlich mit der Aufgabe, das modellierte System in ein Zielsystem zu überführen und insbesondere eine Systemimplementierung vereinfachen zu können. Auf diesem Gebiet konnten bereits verschiedene Fortschritte erzielt werden.
-
In jüngerer Zeit ist zu beobachten, dass die Vielfalt, insbesondere die Variantenvielfalt zu entwickelnder dynamischer Systeme, stetig zunimmt. Beispielhaft wird auf die zunehmende Durchdringung von Kraftfahrzeugen mit dynamischen Systemen verwiesen, beispielsweise Sicherheitssysteme, Assistenzsysteme oder Unterhaltungssysteme. Gleichzeitig nimmt jedoch die Modellvielfalt zu, so dass insgesamt mit einem überproportionalen Anstieg zu modellierender und umzusetzender Regelsysteme zu rechnen ist. Es ist in verschiedenen Branchen zu beobachten, dass bekannte mechanische oder hydraulische Systeme durch mechatronische Systeme ersetzt werden, welche wiederum einer Steuerung bzw. Regelung bedürfen.
-
Vor diesem Hintergrund liegt der Erfindung die Aufgabe zugrunde, ein Verfahren zur Handhabung von Teilmodellen eines Gesamtmodells in einer Simulationsumgebung anzugeben, das dazu beitragen kann, einen Modellierungsaufwand, Simulationsaufwand und/oder Implementationsaufwand beim Umgang mit einer Vielzahl von Modellen, insbesondere bei solchen mit einer hohen Variantenvielfalt, zu reduzieren und möglichst unempfindlich gegenüber Modellierungsfehlern und Ähnlichem zu sein. Insbesondere soll möglichst eine Vielzahl von Varianten eines aus Teilmodellen bestehenden Gesamtmodells ohne übermäßigen Bedienungsaufwand mit einer gegebenen Systemarchitektur ausgeführt bzw. berechnet werden können.
-
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur flexiblen automatisierten Verbindung von Teilmodellen eines Gesamtmodells unter Berücksichtigung einer gegebenen Systemarchitektur in einer Simulationsumgebung gelöst, das die folgenden Schritte aufweist:
- – Bereitstellen zumindest eines Schnittstellen-Eingangsblocks und zumindest eines Schnittstellen-Ausgangsblocks für zumindest ein gegebenes Teilmodell zum Signalaustausch mit zumindest einem weiteren Teilmodell, wobei dem zumindest einen Schnittstellen-Eingangsblock und dem zumindest einen Schnittstellen-Ausgangsblock jeweils zumindest ein definierter Signal-Identifikator zuweisbar ist, der eine zu übertragende Signalgröße kennzeichnet;
- – Bereitstellen einer Eingabemöglichkeit zur Zuordnung des zumindest einen Teilmodells zu einer gewählten Systemarchitekturkomponente der Systemarchitektur zur Ausführung auf der Systemarchitekturkomponente; und
- – Erzeugen von Signalverknüpfungen zum Signalaustausch zwischen der Systemarchitekturkomponente und zumindest einer weiteren Systemarchitekturkomponente unter Berücksichtigung der zugewiesenen definierten Signal-Identifikatoren sowie der gewählten Zuordnung zwischen den Teilmodellen und den Systemarchitekturkomponenten.
-
Die Aufgabe der Erfindung wird auf diese Weise vollkommen gelöst.
-
Erfindungsgemäß kann nämlich etwa ein aus verschiedenen Teilmodellen bestehendes Gesamtmodell besonders einfach für Simulationsgänge oder eine Code-Generierung vorbereitet werden. Teilmodelle, die beispielsweise Teilfunktionen eines Gesamtsystems entsprechen können, können zunächst grundsätzlich unabhängig voneinander erzeugt bzw. modelliert werden. Den Teilmodellen können in einfacher Weise Signal-Identifikatoren (auch: Signal-Bezeichner) zugeordnet werden. Die Signal-Identifikatoren können eingangsseitig oder ausgangsseitig eines Teilmodells vorgesehen sein. Der Benutzer muss die einzelnen Teilmodelle des Gesamtmodells nicht zwingend bereits in einer Modellierungsumgebung (”starr”) miteinander verbinden. Vielmehr ist es ermöglicht, bei den Teilmodellen jeweils zumindest einen Schnittstellen-Eingangsblock oder zumindest einen Schnittstellen-Ausgangsblock vorzusehen, die gewissermaßen als Platzhalter für zu definierende Signalpfade dienen.
-
Ein Signalaustausch erfolgt üblicherweise in einer definierten Richtung von einem Teilmodell zu einem anderen Teilmodell. Der Signalaustausch kann daher grundsätzlich auch als Signalfluss bezeichnet werden. Es ist grundsätzlich auch vorstellbar, dass zwei Teilmodelle wechselseitig miteinander kommunizieren. Dies kann durch eine entsprechende Konfiguration der jeweiligen Schnittstellen-Eingangsblöcke und Schnittstellen-Ausgangsblöcke und Vergabe entsprechender Signal-Identifikatoren umgesetzt werden.
-
Die vorhandene Systemarchitektur kann eine Mehrzahl von Systemarchitekturkomponenten umfassen. Eine Systemarchitekturkomponente kann beispielhaft durch einen Prozessor (oder eine Prozessoreinheit) einer Mehrzahl von Prozessoren (oder Prozessoreinheiten) gebildet sein. Die Systemarchitektur kann als gebündelte (konzentrierte) Systemarchitektur oder als verteilte Systemarchitektur ausgeführt sein. Die Systemarchitekturkomponenten können virtuelle oder diskrete Bauteile (etwa Prozessoren) umfassen. Die Systemarchitekturkomponenten sind grundsätzlich dafür vorgesehen, das Gesamtmodell oder zumindest Teilmodelle davon auszuführen. Zu diesem Zweck kann es erforderlich sein, das (graphisch) modellierte Gesamtmodell in einen interpretierbaren Code zu überführen, der auf den Systemarchitekturkomponenten lauffähig ist. Dabei kann es sich etwa um einen Maschinencode (oder einen Programmcode einer höheren Sprache) handeln.
-
Das beschriebene Verfahren ist nicht vorrangig darauf ausgerichtet, das durch das Gesamtmodell verkörperte Systemmodell von der Modellebene in eine Implementation auf einer Zielebene (also etwa ein tatsächlich realisiertes Fahrzeugsteuerungssystem) zu überführen. Vielmehr kann ein Schwerpunkt des Verfahrens darin gesehen werden, Modellierungs- und/oder Simulationsvorgänge in der Simulationsumgebung zu vereinfachen. Dies soll insbesondere im Hinblick darauf erfolgen, dass beim Entwurf des Gesamtmodells eine Mehrzahl oder Vielzahl von Varianten berücksichtigt ist. Diese Varianten können etwa verschiedene Signalpfade oder Signalrichtungen umfassen, die üblicherweise von Hand je nach Variante abgeändert werden müssten. Es sind etwa auch Systeme bekannt, die einen zentralen Bus aufweisen, der alle Teilmodelle eines Gesamtmodells zentral referenziert. Ein solcher Ansatz ist jedoch inflexibel und führt zu erhöhtem Änderungsaufwand, wenn viele Teilmodelle und (Teilmodell-)Varianten auftreten und eine Mehrzahl von Systemarchitekturkomponenten beteiligt ist. Das Vorsehen von ”Platzhaltern”, nämlich den Schnittstellen-Eingangsblöcken und den Schnittstellen-Ausgangsblöcken für die Teilmodelle, ermöglicht eine mittelbare Zuordnung von Signalpfaden. Dies erfolgt unter Berücksichtigung der zugewiesenen definierten Signal-Identifikatoren. Mit anderen Worten kann ein Benutzer durch eine definierte Vergabe der den Schnittstellen-Eingangsblöcken bzw. den Schnittstellen-Ausgangsblöcken zugeordneten Signal-Identifikatoren Verknüpfungen zwischen den Teilmodellen verändern, entfernen oder neu anlegen. Derartige Abwandlungen können in einfacher Weise auf der Ebene der Systemarchitektur (etwa: Prozessorebene) nachvollzogen werden. Mit anderen Worten können die Signalverknüpfungen zwischen den Systemarchitekturkomponenten, die zum Ausführen des Gesamtmodells auf der Systemarchitektur erforderlich sind, automatisch generiert und nachgezogen werden, wenn sich die Vergabe und Zuordnung der Signal-Identifikatoren in der Modellebene durch Neuzuweisung von Signal-Identifikatoren ändert.
-
Es kann einem Benutzer sogar ermöglicht sein, ein Teilmodell in einem Simulationsgang einer ersten gewählten Systemarchitekturkomponente und in einem weiteren Simulationsgang einer weiteren Systemarchitekturkomponente zuzuweisen. Die Signalverknüpfungen zum Signalaustausch zwischen den Systemarchitekturkomponenten werden automatisch angepasst.
-
Ein Schnittstellen-Eingangsblock kann grundsätzlich dazu ausgebildet sein, ein Eingangssignal, das durch einen Signal-Identifikator bezeichnet ist, zu empfangen und dem entsprechenden Teilmodell zuzuleiten. Ein Schnittstellen-Ausgangsblock kann grundsätzlich dazu ausgebildet sein, ein in dem entsprechenden Teilmodell erzeugtes oder verändertes Signal, das durch einen definierten Signal-Identifikator gekennzeichnet ist, weiterzuleiten. Somit können die Teilmodelle mit Schnittstellen versehen sein, deren Verknüpfung durch den Benutzer individuell und flexibel festlegbar ist.
-
Es versteht sich, dass das Gesamtmodell grundsätzlich hierarchisch untergliedert sein kann. Beispielsweise kann das Gesamtmodell aus zumindest zwei Teilmodellen bestehen. Es ist jedoch auch vorstellbar, ein Teilmodell wiederum in zumindest zwei Untermodelle zu zergliedern. Auch auf einer hierarchischen Unterebene können verfahrensgemäß Schnittstellen-Eingangsblöcke und Schnittstellen-Ausgangsblöcke bei den jeweiligen Untermodellen vorgesehen sein, um es dem Benutzer zu erlauben, Signal-Identifikatoren zuzuweisen. Die weitere Funktionalität kann auch auf hierarchisch untergeordneten oder hierarchisch übergeordneten Ebenen umgesetzt werden.
-
Es ist besonders bevorzugt, wenn das Verfahren dazu ausgestaltet ist, eine doppelte Zuordnung oder Zuweisung eines einzigen Signal-Identifikators zu vermeiden. Zu diesem Zweck kann es vorgesehen sein, die Signal-Identifikatoren jeweils mit einer das Teilmodell kennzeichnenden Kennung sowie einer zumindest innerhalb des jeweiligen Teilmodells einmaligen Bezeichnung zu versehen.
-
Gemäß einer bevorzugten Ausgestaltung umfasst das Erzeugen der internen Signalverknüpfungen ein Erzeugen von System-Variablen zum Signalaustausch zwischen den zumindest zwei Systemarchitekturkomponenten.
-
Mit anderen Worten kann eine Zuordnung (auch bezeichnet als ”Mapping”) zwischen den Signal-Identifikatoren der Modellebene und den System-Variablen der Systemarchitekturebene erfolgen. Vorzugsweise erfolgt das Erzeugen der System-Variablen automatisiert ohne Benutzereingriffe. Eine Abwandlung der funktionalen Verknüpfung zwischen den Teilmodellen, etwa durch abgewandelte Vergabe der Signal-Identifikatoren, wird beim Erzeugen der lokalen System-Variablen automatisch mit berücksichtigt. Die System-Variablen können als Bezeichner für Signale aufgefasst werden, die auf der Ebene der Systemarchitektur zwischen Systemarchitekturkomponenten ausgetauscht werden. System-Variablen, die nur einer Systemarchitekturkomponente zugeordnet sind, können als lokale System-Variablen bezeichnet werden.
-
Gemäß einer weiteren Ausgestaltung umfasst das Erzeugen der internen Signalverknüpfungen ein Erzeugen zumindest eines flexiblen eingangsseitigen Systemarchitekturkomponentenverbindungsblocks und zumindest eines flexiblen ausgangsseitigen Systemarchitekturkomponentenverbindungsblocks. Die Systemarchitekturkomponentenverbindungsblocks (nachfolgend auch als ”Verbindungsblocks” bezeichnet) dienen zur Kontrolle des Signalaustauschs zwischen den zumindest zwei Systemarchitekturkomponenten. Die Komponentenverbindungsblocks können auf der Modellebene in der Simulationsumgebung automatisiert erzeugt werden, um Signalverbindungen zwischen den Systemarchitekturkomponenten bereitzustellen.
-
Gemäß einer Weiterbildung dieser Ausgestaltung weist das Verfahren ferner den Schritt des Bereitstellens zumindest eines Systemarchitekturkomponentenkommunikationsblocks zur Kommunikation mit den Systemarchitekturkomponenten auf, wobei der zumindest eine eingangsseitige Systemarchitekturkomponentenverbindungsblock sowie der zumindest eine ausgangsseitige Systemarchitekturkomponentenverbindungsblock mit dem zumindest einen Systemarchitekturkomponentenkommunikationsblock gekoppelt wird, und wobei die System-Variablen abhängig von definierten System-Variablen-Charakteristika, insbesondere abhängig von einer gewählten Signalverzögerung, dem zumindest einen Systemarchitekturkomponentenkommunikationsblock zugeordnet werden.
-
Der zumindest eine Systemarchitekturkomponentenkommunikationsblock (nachfolgend auch bezeichnet als ”Kommunikationsblock”) stellt die Kommunikation mit den Systemarchitekturkomponenten sicher. Davon ist insbesondere die Kommunikation zwischen den Systemarchitekturkomponenten umfasst. Ein Kommunikationsblock kann beispielsweise eine verzögerte Signalweiterleitung bewirken. Ein anderer Kommunikationsblock kann für Signale konfiguriert sein, deren Weiterleitung ohne Verzögerung erfolgen soll.
-
Gemäß einer weiteren Ausgestaltung weist das Verfahren ferner den Schritt des Bereitstellens eines Zugriffs auf eine vordefinierte Datenbasis, insbesondere eine Datenbank, auf, wobei die Datenbasis Signal-Identifikatoren enthält, die selektiv auswählbar und dem zumindest einen Schnittstellen-Eingangsblock und/oder dem zumindest einen Schnittstellen-Ausgangsblock zur Kennzeichnung der zu übertragenden Signalgrößen zuordenbar sind.
-
Vorzugsweise kann die Datenbasis ferner auch dazu dienen, eine Benennung und einen grundsätzlich möglichen Signalpool für die Teilmodelle bereitzustellen. Mit anderen Worten kann die Datenbasis etwa als relationale Datenbasis ausgestaltet sein und eine Mehrzahl von Tabellen umfassen, die jeweils einem Teilmodell zuordenbar sind. Innerhalb jeder der Tabellen können die Signal-Identifikatoren verzeichnet sein, also die Bezeichner für auszutauschende Signale. Vorzugsweise steht es dem Benutzer frei, aus der Datenbasis gewünschte Signal-Identifikatoren auszuwählen, um die Teilmodelle und somit auch das Gesamtmodell gewissermaßen vorzukonfigurieren. Der Benutzer ist nicht gezwungen, sämtliche vorhandenen in der Datenbasis hinterlegten Signal-Identifikatoren, die für ein gegebenes Teilmodell wählbar sind, auch tatsächlich auszuwählen.
-
Die Vergabe eines Bezeichners für das Teilmodell und des zumindest einen diesem Teilmodell zugehörigen Signal-Identifikators kann eindeutig erfolgen. Auf diese Weise kann die Gefahr fehlerhafter oder falsch zugeordneter Benutzereingaben weiter verringert werden. Die Manipulation der Datenbasis, also etwa das Hinzufügen oder Entfernen von Einträgen, kann grundsätzlich außerhalb der Simulationsumgebung erfolgen. Alternativ oder zusätzlich ist es vorstellbar, eine Manipulation der Datenbasis innerhalb der Simulationsumgebung zu erlauben.
-
Gemäß einer Weiterbildung wird zumindest ein Schnittstellen-Eingangsblock des zumindest einen Schnittstellen-Eingangsblocks mit einer Mehrzahl von Signal-Identifikatoren verknüpft, wobei eine entsprechende Mehrzahl von Signalgrößen zuführbar ist und selektiv weitergeleitet wird.
-
Auf diese Weise können einem Schnittstellen-Eingangsblock eines Teilmodells mehrere Eingangsgrößen zugeführt werden. Gleichwohl ist es bevorzugt, wenn der zumindest eine Schnittstellen-Eingangsblock dazu ausgebildet ist, lediglich eine Signalgröße an das Teilmodell durchzuleiten. Somit ist es von Vorteil, eine definierte Auswahlfunktion vorzusehen, um sicherzustellen, dass aus einer theoretisch möglichen Mehrzahl von eingehenden Signalgrößen lediglich eine gewünschte Signalgröße dem Teilmodell zugeführt wird. Die selektive Durchleitung einer Signalgröße aus einer Mehrzahl potentiell möglicher Signalgrößen kann die Verarbeitung variantenreicher Gesamtmodelle oder Teilmodelle vereinfachen.
-
Gemäß einer Weiterbildung dieser Ausgestaltung wird an dem zumindest einen Schnittstellen-Eingangsblock eine Signalgröße einer Mehrzahl von Signalgrößen prioritätsbasiert selektiv weitergeleitet.
-
Dies kann etwa derart erfolgen, dass den Signalgrößen Prioritätswerte zugewiesen werden. Am Schnittstellen-Eingangsblock kann zunächst grundsätzlich die höchstpriorisierte Signalgröße weitergeleitet werden. Die Priorisierung kann etwa durch Zuweisung eines entsprechenden Wertes zu den Signal-Identifikatoren erfolgen. Sollte beispielhaft für einen hochpriorisierten Signal-Identifikator keine Signalgröße anliegen, kann ein nächstpriorisierter Signal-Identifikator dahingehend geprüft werden, ob eine entsprechende Signalgröße anliegt. Auf diese Weise kann eine definierte Hierarchie abgearbeitet werden, so dass aus einer Mehrzahl potentiell möglicher Signalgrößen die höchstpriorisierte und tatsächlich vorhandene Signalgröße gewählt wird.
-
Gemäß einer weiteren Ausgestaltung wird an dem zumindest einen Schnittstellen-Eingangsblock des zumindest einen Schnittstellen-Eingangsblocks eine definierte Ersatzreaktion ausgeführt, wenn keine Signalgröße vorhanden ist.
-
Unabhängig davon, ob es vorgesehen ist, dem zumindest einen Schnittstellen-Eingangsblock einen Signal-Identifikator oder eine Mehrzahl von Signal-Identifikatoren zuzuweisen, kann eine definierte Ersatzreaktion unerwünschte Systemzustände vermeiden, die etwa dann eintreten könnten, wenn statt einer erwarteten Signalgröße keine Signalgröße zugeführt wird. Die definierte Ersatzreaktion kann vorzugsweise aus einer Mehrzahl möglicher verschiedener Ersatzreaktionen gewählt werden.
-
Eine beispielhafte Ersatzreaktion kann das Ausgeben einer Fehlermeldung umfassen. Eine alternative Ersatzreaktion kann das Durchleiten einer ”Null-Größe” umfassen. Eine weitere alternative Ersatzreaktion kann das Ersetzen des (nicht vorhandenen) Signaleingangs durch eine vordefinierte Konstante umfassen. Mit Hilfe von definierten Ersatzreaktionen kann beispielsweise eine Modellentwicklung bzw. eine Modellweiterentwicklung vereinfacht werden. Es kann etwa sichergestellt werden, dass nicht jede fehlerhafte Signalzuordnung bzw. nicht jedes Nichtvorhandensein einer erforderlichen Signalgröße zu nachteiligen Folgereaktionen, etwa Überlastungen, bei verknüpften Teilmodellen führt. Auf diese Weise kann die Weiterentwicklung mit hoher Flexibilität erfolgen. Es kann ferner bei der Weiterentwicklung eine Vorgehensweise nach dem Versuch-und-Irrtum-Prinzip (trial and error) angewandt werden, ohne dass dies im Fehlerfall zu übermäßig großen Auswirkungen führt.
-
In bevorzugter Weiterbildung wird an dem zumindest einen Schnittstellen-Eingangsblock des zumindest einen Schnittstellen-Eingangsblocks eine Integrationsschrittverzögerung für zumindest einen zugewiesenen Signal-Identifikator ausgeführt.
-
Die mit dem Signal-Identifikator bezeichneten zugeführten Signalgrößen werden dann, wenn eine Integrationsschrittverzögerung vorgesehen ist, nicht unmittelbar weitergeleitet. Vielmehr kann etwa vor der Weiterleitung eine definierte Verzögerungszeit eingehalten werden. Auf diese Weise kann etwa auf Modellumstände Rücksicht genommen werden, bei denen ein Teilmodell, dem über einen Schnittstellen-Eingangsblock eine Signalgröße zugeführt werden soll, auf eine Signalgröße warten muss, die in einem anderen Teilmodell erzeugt wird und über dessen Schnittstellen-Ausgangsblock bereitgestellt wird.
-
Eine Integrationsschrittverzögerung kann auch dazu beitragen, Performance-Unterschiede bei den beteiligten oder geplanten Systemarchitekturkomponenten zu berücksichtigen und gegebenenfalls auszugleichen. Eine Integrationsschrittverzögerung kann etwa auch dann vorteilhaft zur Anwendung kommen, wenn Ausgangssignale einer Systemarchitekturkomponente direkt von einem (gleichzeitigen) Eingangssignal abhängen (auch bezeichnet als: direct feedthrough).
-
Vorzugsweise kann die Integrationsschrittverzögerung nach Wahl des Benutzers verschiedene Charakteristika aufweisen. So ist es möglich, zu definieren, dass keinerlei Integrationsschrittverzögerung erfolgen soll. Eine weitere wählbare Integrationsschrittverzögerungsstrategie kann etwa darin bestehen, nur diejenigen Signale zu verzögern, die der aktuellen Systemarchitekturkomponente von einer anderen Systemarchitekturkomponente zugeführt werden. Alternativ kann jedoch auch vorgesehen sein, stets eine Integrationsschrittverzögerung vorzusehen. Gemäß einer weiteren Alternative kann die Integrationsschrittverzögerung dahingehend konfiguriert sein, eingehende Signale dann automatisch zu verzögern, wenn im Programmablauf eine Schleife generiert ist oder zumindest die mögliche Generierung einer Signalschleife droht.
-
Gemäß einer weiteren Ausgestaltung weist das Verfahren ferner den Schritt des Bereitstellens einer Eingabemöglichkeit zur Zuordnung des zumindest einen Teilmodells zu einer gewählten Systemarchitekturkomponente der Systemarchitektur zur Ausführung auf der Systemarchitekturkomponente auf.
-
Auf diese Weise können Teilmodelle flexibel und einfach zwischen den Systemarchitekturkomponenten ”verschoben” werden. Dies kann etwa dazu dienen, die Auslastung der einzelnen Systemarchitekturkomponenten bei der Berechnung zu optimieren. Die Systemarchitektur kann verschiedene Systemarchitekturkomponenten aufweisen, die sich hinsichtlich ihrer Leistungsfähigkeit unterscheiden. Demzufolge können etwa rechenintensive Teilmodelle leistungsfähigen Systemarchitekturkomponenten zugeordnet werden, wogegen Teilmodelle, die einen geringen Rechenaufwand erfordern, entsprechend weniger leistungsfähigen Systemarchitekturkomponenten zugewiesen werden können.
-
Diese Ausgestaltung wird dadurch weitergebildet, dass ferner der Schritt des Bereitstellens einer Eingabemöglichkeit zur Zuordnung einer Mehrzahl von Teilmodellen zu einer gewählten Systemarchitekturkomponente der Systemarchitektur zur gemeinsamen Ausführung auf der Systemarchitekturkomponente vorgesehen ist.
-
Somit können auf einer Systemarchitekturkomponente eine Mehrzahl von Teilmodellen ausgeführt werden. Auf diese Weise kann die Auslastung der einzelnen Systemarchitekturkomponenten sowie die allgemeine Leistungsfähigkeit des Gesamtsystems weiter verbessert werden. Es versteht sich, dass die System-Variablen zur Kommunikation auf der Architekturebene – abhängig davon, ob Teilmodelle, zwischen denen ein Signalfluss vorgesehen ist, auf der gleichen Systemarchitekturkomponente oder auf verschiedenen Systemarchitekturkomponenten ausführbar sind – unterschiedlich gehandhabt werden sollten. Innerhalb der einen Systemarchitekturkomponente können die System-Variablen lokal gehandhabt werden.
-
Die Anzahl der zwischen den Systemarchitekturkomponenten auszutauschenden Variablen kann reduziert werden. Dies kann die Leistungsfähigkeit weiter erhöhen. Etablierte Lösungen erlauben häufig keine flexible Zuordnung zwischen den Teilmodellen und den Systemarchitekturkomponenten. Vielmehr erfolgt die Zuordnung häufig starr, wobei ein ”Verschieben” von Teilmodellen mit umfangreichen Anpassungen verbunden ist. Ebenso ist es häufig erforderlich, sämtliche potentiell benötigten Signalgrößen über einen Kommunikationsblock bereitzustellen, unabhängig davon, ob diese von einer aktuellen Variante benötigt werden oder nicht. Die führt insgesamt bei bekannten Systemen zu einer erhöhten Belastung der Kommunikationsblöcke.
-
Gemäß einer weiteren Ausgestaltung weist das Verfahren ferner den Schritt des erneuten Erzeugens von internen Signalverknüpfungen zum Signalaustausch zwischen der Systemarchitekturkomponente und der zumindest einer weiteren Systemarchitekturkomponente auf, wenn die Zuordnung zwischen den Teilmodellen und den Systemarchitekturkomponenten verändert wird.
-
Dies kann vorteilhaft automatisiert und ohne das Erfordernis eines Benutzereingriffs erfolgen. Somit kann der Benutzer Teilmodelle in einfacher Weise zwischen Systemarchitekturkomponenten (beispielsweise verschiedenen Prozessoren oder Prozessoreinheiten) ”verschieben”, ohne die entsprechenden Signalwege in der Modellebene und der Systemarchitekturebene anpassen zu müssen.
-
Gemäß einer weiteren bevorzugten Ausgestaltung umfasst der Schritt des Erzeugens von internen Signalverbindungen ferner Folgendes:
- – Erzeugung einer lokalen Systemvariable bei der verwendeten Systemarchitekturkomponente für jeden Ausgangs-Signal-Identifikator des zumindest einen zugewiesenen Teilmodells;
- – Abarbeitung der folgenden Teilschritte für jede zu verwendende Systemarchitekturkomponente:
- – Teilschrittterminierung, sofern jedem Eingangs-Signal-Identifikator eine lokale System-Variable zuweisbar ist; andernfalls:
- – Teilschrittterminierung, sofern jedem Eingangs-Signal-Identifikator, dem keine lokale System-Variable zuweisbar ist, eine System-Variable einer weiteren Systemarchitekturkomponente zuweisbar ist; andernfalls:
- – Ausführung einer definierten Ersatzreaktion.
-
Mögliche Charakteristika der Ersatzfunktion können wie vorstehend beschrieben etwa das Ausgeben einer kontrollierten Fehlermeldung, das Weiterleiten eines ”Null-Wertes”, oder das Weiterleiten einer definierten Konstante umfassen.
-
Die Aufgabe der Erfindung wird ferner gelöst durch eine Rechneranordnung mit einer Simulationsumgebung, insbesondere einer Umgebung zur Simulation dynamischer Systeme, die dazu ausgebildet ist, das Verfahren nach einem der vorhergehenden Aspekte auszuführen.
-
Auch auf diese Weise wird die Aufgabe der Erfindung vollständig gelöst. Bei der Rechneranordnung kann es sich etwa um einen Personalcomputer mit zumindest einem Prozessor, vorzugsweise einer Mehrzahl von Prozessoren oder Prozessorkernen, handeln. Ferner sind Rechneranordnungen vorstellbar, die eine Server-Terminal-Gestaltung umfassen. Grundsätzlich sind auch Rechneranordnungen denkbar, die als verteilte Systeme realisiert sind.
-
Die Aufgabe der Erfindung wird ferner auch gelöst durch ein Computerprogramm, das Programmcode aufweist, der dazu ausgebildet ist, die Schritte des Verfahrens nach irgendeinem der vorhergehenden Aspekte auf einem Computer durchzuführen, wenn das Computerprogramm auf dem Computer ausgeführt wird.
-
Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung eines bevorzugten Ausführungsbeispiels unter Bezugnahme auf die Zeichnungen. Es zeigen:
-
1 eine stark vereinfachte schematische Darstellung eines Systemmodells;
-
2 eine stark vereinfachte schematische Darstellung eines Teilmodells, dem Schnittstellen-Eingangsblöcke und Schnittstellen-Ausgangsblöcke zugeordnet sind, die durch eine Datenbasis definierbar sind;
-
3 eine stark vereinfachte symbolhafte Darstellung einer Simulationsumgebung mit einem Gesamtmodell;
-
4a eine stark vereinfachte symbolhafte Darstellung einer Systemarchitektur mit einer Mehrzahl von Systemarchitekturkomponenten;
-
4b eine stark vereinfachte schematische Veranschaulichung verschiedener Systemarchitekturkomponentenkommunikationsblöcke, die mit Systemarchitekturkomponentenverbindungsblöcken verknüpft sind;
-
5 eine stark vereinfachte erläuternde Darstellung eines Teilmodells etwa gemäß 3, wobei dem Teilmodell zugeordnete Schnittstellen-Eingangsblöcke und Schnittstellen-Ausgangsblöcke veranschaulicht werden;
-
6 eine vereinfachte schematische Veranschaulichung einer Systemarchitektur mit einer Mehrzahl von Systemarchitekturkomponenten, zwischen denen Signale ausgetauscht werden, die ein modelliertes System beschreiben;
-
7 ein stark vereinfachtes Blockdiagramm zur Beschreibung eines Verfahrens zur flexiblen automatisierten Verbindung von Teilmodellen eines Gesamtmodells; und
-
8 ein vereinfachtes Blockschaltbild zur Veranschaulichung von Verfahrensschritten, die ein Erzeugen von internen Signalverknüpfungen zum Signalaustausch zwischen Systemarchitekturkomponenten umfassen.
-
1 zeigt eine exemplarische Darstellung eines beispielhaften Systemmodells 10 anhand eines graphischen Blockschaltbilds. Simulationsumgebungen, die zur graphischen Modellierung von dynamischen Systemen ausgebildet sind, können durch Bereitstellung vordefinierter Bibliotheken und Funktionen in anschaulicher Weise eine einfache Modellierung des Systemmodells 10 ermöglichen. Bei dem Systemmodell 10 kann es sich um ein globales Systemmodell oder ein Teilmodell oder Submodell handeln.
-
Beispielhaft weist das Systemmodell 10 eine Mehrzahl von Modulblöcken 12a, 12b, 12c auf, die verschiedene Funktionalitäten repräsentieren. So können in den Modulblöcken 12a, 12b, 12c mehr oder weniger komplexe Steuerungsfunktionen oder Regelungsfunktionen hinterlegt werden. Mit anderen Worten können die Modulblöcke 12a, 12b, 12c wiederum ein internes Systemmodell oder zumindest ein internes Teilsystemmodell repräsentieren. Die Modulblöcke 12a, 12b, 12c können jedoch ebenso eine Eingabe- oder Ausgabefunktionalität aufweisen. Auf diese Weise können die Modulblöcke 12a, 12b, 12c zur Kommunikation mit einer (systemfremden) Umgebung ausgestaltet sein. Hierzu können etwa das Erfassen von Messwerten oder die Ausgabe von Steuerungsbefehlen gezählt werden. Ein Modulblock 12 weist üblicherweise zumindest einen Eingang 16a, 16b sowie ferner etwa zumindest einen Ausgang 18a, 18b auf. Über den zumindest einen Eingang 16a, 16b können dem Modulblock 12a, 12b, 12c Signale zugeführt werden, die vom Modulblock 12a, 12b, 12c verarbeitet werden. Der Modulblock 12a, 12b, 12c kann an dem zumindest einen Ausgang 18a, 18b ein Ausgangssignal bereitstellen, das etwa durch eine Verarbeitung oder Beeinflussung eines Eingangssignals erzeugbar ist. In 1 sind beispielhafte Signalverläufe in üblicher Weise durch Pfeile angedeutet, die zumindest mit einem Eingang 16 oder einem Ausgang 18 gekoppelt sind. Die Signalpfade 14 können sich zwischen den einzelnen Modulblöcken 12a, 12b, 12c erstrecken. In diesem Fall wird üblicherweise ein Ausgang 18 eines Modulblocks 12 durch den Signalpfad 14 mit einem Eingang 16 eines weiteren Modulblocks 12 verknüpft. Die Signalpfade 14 können jedoch auch eine (gedachte) Systemgrenze überschreiten und somit etwa als globale Eingangssignalpfade oder globale Ausgangssignalpfade dienen.
-
Wie vorstehend bereits erwähnt, existieren im Stand der Technik Simulationsumgebungen, die eine graphikgestützte Modellierung von Systemmodellen 10 erlauben. Üblicherweise obliegt es einem Benutzer dabei, sowohl die Modulblöcke 12 als auch die Signalpfade 14 hinreichend genau zu definieren. Hierzu kann insbesondere ein explizites Einfügen und Darstellen von Signalpfaden 14 gezählt werden. Sollten sich jedoch Veränderungen bei einem oder mehreren Modulblöcken 12 des Systemmodells 10 ergeben, die beispielhaft das Erzeugen neuer Signalverknüpfungen erforderlich machen, ist es regelmäßig erforderlich, die Signalpfade 14 manuell an die geänderte Konfiguration anzupassen. Diese notwendige Tätigkeit betrifft häufig nicht nur das Systemmodell 10 in der Modellierungsumgebung (also auf der Modellebene), sondern ebenso auch die Verknüpfung (auch: das Mapping) des Systems in einer Systemarchitekturebene. Der Begriff Systemarchitektur kann stellvertretend für Rechner strukturen stehen, mit deren Hilfe eine Berechnung des Systems 10 erfolgen kann. Beispielhaft kann die Systemarchitektur als Anordnung mehrerer Prozessoren oder mehrerer Prozessorkerne aufgefasst werden, denen einzelne oder mehrere der Modulblöcke 12a, 12b, 12c zur Abarbeitung zugeordnet sind. Somit muss die Entwicklungsumgebung dafür Sorge tragen, dass Änderungen im Signalverlauf, die sich auf der Modellebene ergeben, auch auf der Systemarchitekturebene nachvollzogen werden können.
-
Anhand der nachfolgenden Figuren wird ein vorteilhafter Ansatz erläutert, der dazu beitragen kann, eine Modellierung insbesondere variantenreicher Systementwürfe zu vereinfachen und eine Umsetzung oder Implementierung zu erleichtern, wobei möglichst wenige Benutzereingaben zur Verknüpfung oder Neuverknüpfung von Systemteilen erforderlich sein sollen.
-
In 2 ist ein Teilmodell 24 dargestellt, das etwa einem der Modulblöcke 12a, 12b, 12c in 1 entsprechen kann. Das Teilmodell 24 kann eine Mehrzahl von Untermodellen 26a, 26b, 26c, 26d aufweisen. Das Teilmodell 24 kann Bestandteil eines Gesamtmodells sein. Das Gesamtmodell, eine Mehrzahl von Teilmodellen 24 und gegebenenfalls weitere Untermodelle 26 können hierarchisch gegliedert sein. Das Teilmodell 24 kann zunächst eigenständig modelliert bzw. entwickelt werden. Somit ist es bei der Entwicklung des Teilmodells 24 nicht unbedingt erforderlich, bereits notwendige Signalverknüpfungen mit weiteren Teilmodellen zu definieren und einzurichten. Vielmehr kann das Teilmodell 24 mit ”Platzhaltern” für Eingänge und Ausgänge versehen werden, die eine mittelbare Verknüpfung mit weiteren Teilmodellen in der Simulationsumgebung ermöglichen.
-
Beispielhaft ist das in 2 gezeigte Teilmodell 24 mit Eingangsblöcken 28a, 28b, 28c und Ausgangsblöcken 30a, 30b versehen. Die Eingangsblöcke 28 bzw. die Ausgangsblöcke 30 können als Platzhalter oder Stellvertreter für auszutauschende Signale dienen. Zu diesem Zweck kann jeder der Eingangsblöcke 28 und jeder der Ausgangsblöcke 30 mit einem eindeutigen Bezeichner (auch bezeichnet als Signal-Identifikator) versehen werden. Zu diesem Zweck kann auf eine Datenbasis 22 zurückgegriffen werden, in der für das Teilmodell 24 denkbare Signal-Identifikatoren sowie diesen zugeordnete Eigenschaften verzeichnet sind. Die Datenbasis 22 kann im Vorfeld durch einen Benutzer definiert und befüllt werden. Die Datenbasis 22 kann eine Mehrzahl von Datensätzen umfassen, die jeweils einem Teilmodell 24 zugeordnet sind. In einem der Datensätze, die auf ein Teilmodell 24 bezogen sind, können sämtliche für dieses Teilmodell 24 denkbare Signal-Identifikatoren verzeichnet sein. Es ist nicht notwendig, sämtliche in der Datenbasis 22 hinterlegte Signal-Identifikatoren auch tatsächlich bei der Beschreibung des Teilmodells 24 zu verwenden.
-
In der vorbezeichneten Weise können eine Mehrzahl von Teilmodellen 24 zunächst grundsätzlich unabhängig voneinander modelliert werden, wobei sich zwischen diesen ergebende Signalverbindungen ”mittelbar” und flexibel erzeugbar sind.
-
3 veranschaulicht in symbolhaft stark vereinfachter Weise eine Simulationsumgebung 34, in der ein Gesamtmodell 36 modelliert ist, das beispielhaft durch einen gestrichelt dargestellten Block abgegrenzt ist. Das Gesamtmodell 36 besteht aus einer Mehrzahl von Teilmodellen 38, 40, 42, 44, 46. Die Teilmodelle 38, 40, 42, 44, 46 können analog dem in 2 gezeigten Teilmodell 24 mit Eingangsblöcken 28 und Ausgangsblöcken 30 versehen werden, denen entsprechende Signal-Identifikatoren zugeordnet werden können. Jedem der Teilmodelle 38, 40, 42, 44, 46 kann eine Information zugeordnet werden, die eine Zielarchitekturkomponente bezeichnet, auf der das Teilmodell ausgeführt (auch: berechnet oder simuliert) werden soll. Insbesondere dann, wenn die Simulationsumgebung 34 auf eine Systemarchitektur zurückgreifen kann, die eine Mehrzahl von Systemarchitekturkomponenten aufweist, können die Teilmodelle 38, 40, 42, 44, 46 verschiedenen Systemarchitekturkomponenten zugeordnet werden. Beispielhaft sind in 3 die Teilmodelle 38 und 40 mit gleichartig schraffierten Blöcken 58a' versehen, die eine Zuordnung zu einer gemeinsamen Systemarchitekturkomponente 58a (vgl. 4a) kennzeichnen. Demgegenüber sind die Teilmodelle 42, 44 und 46 mit gleichartig schraffierten Blöcken 58b' versehen, deren Schraffur sich von den Blöcken 58a' unterscheidet. Dies verdeutlicht, dass die Teilmodelle 42, 44 und 46 beispielhaft einer anderen Systemarchitekturkomponente 58b zugewiesen sind. Die Zuweisung jedes Teilmodells der Teilmodelle 38, 40, 42, 44, 46 kann in einfacher Weise geändert werden, wobei sich entsprechende Signalverknüpfungen auf der Systemarchitekturebene automatisiert und flexibel anpassen lassen.
-
In 3 sind weitere Funktionselemente der Simulationsumgebung 34 in vereinfachter Darstellung veranschaulicht. Beispielhaft kann die Simulationsumgebung 34 einen Einrichtungsblock oder Setupblock 48 aufweisen. Der Setupblock 48 kann Funktionen bereitstellen, die beispielhaft die Anbindung einer Datenbasis 22 (vgl. 2) erlauben. Der Setupblock 48 kann ferner dazu dienen, eine Systemarchitektur mit einer Mehrzahl von Systemarchitekturkomponenten zu beschreiben und Randbedingungen zur Kommunikation zwischen den Systemarchitekturkomponenten zu definieren. Der Setupblock 48 kann ferner dazu verwendet werden, die Zuordnung der Teilmodelle 38, 40, 42, 44, 46 zu einer der Systemarchitekturkomponenten 58a, 58b (4a) zu erlauben.
-
Die Simulationsumgebung 34 kann ferner Blöcke oder Schaltflächen aufweisen, die eine Verbindung oder Trennung des Gesamtmodells 36 (in der Modellebene und in der Zielarchitekturebene) bewirken können. Wie vorstehend bereits erwähnt, erlaubt die Simulationsumgebung 34 eine Modellierung der Teilmodelle 38, 40, 42, 44, 46 unabhängig voneinander, wobei Signalpfade zwischen diesen nicht explizit definiert werden müssen. Vielmehr können die Teilmodelle 38, 40, 42, 44, 46 mit Stellvertretern für Eingänge und Ausgänge versehen werden, die unter Zuhilfenahme von Signal-Identifikatoren verknüpfbar sind. Beispielhaft kann ein Verbindungsblock 50 nach Aktivierung eine Verknüpfung oder Neuverknüpfung des Gesamtmodells 36 bewirken, wenn einzelne oder alle Teilmodelle 38, 40, 42, 44, 46 geändert oder variiert worden sind. Ein Trennblock 52 kann betätigt werden, um eine bestehende etablierte Verknüpfung des Gesamtmodells 36 zu lösen.
-
4a veranschaulicht in stark vereinfachter Weise lediglich zu Veranschaulichungszwecken eine Systemarchitektur 56. Beispielhaft kann die Systemarchitektur 56 eine Mehrzahl von Systemarchitekturkomponenten 58a, 58b und gegebenenfalls weitere Systemarchitekturkomponenten aufweisen. Die Systemarchitekturkomponenten 58a, 58b können etwa einzelne Prozessorkerne, Prozessoren oder Prozessoreinheiten der Systemarchitektur 56 darstellen. Die Systemarchitekturkomponenten 58a, 58b können grundsätzlich explizit-diskret, virtuell oder in anderer Weise verwirklicht sein. So können die Systemarchitekturkomponenten 58a, 58b etwa auch ”virtuelle” Prozessorkerne kennzeichnen. Beispielhaft können die in 3 gezeigten Teilmodelle 38 und 40 der Systemarchitekturkomponente 58a zugewiesen sein. Ferner können die Teilmodelle 42, 44 und 46 der Systemarchitekturkomponente 58b zugewiesen sein. Diese Zuordnung oder Zuweisung kann unter Zuhilfenahme etwa des Setupblocks 48 geändert werden.
-
4b veranschaulicht verschiedene Systemarchitekturkomponentenkommunikationsblöcke 60a, 60b, 60c (nachfolgend auch: Kommunikationsblöcke). Die Kommunikationsblöcke 60a, 60b, 60c können eine Kommunikation mit und zwischen den Systemarchitekturkomponenten 58a, 58b der Systemarchitektur 56 beschreiben. Dies kann eine Umsetzung des Gesamtmodells 36 oder von Teilmodellen 38, 40, 42, 44, 46 des Gesamtmodells 36 in Daten beinhalten, die für die Systemarchitekturkomponenten 58a, 58b interpretierbar sind.
-
Mit anderen Worten können die Kommunikationsblöcke 60a, 60b, 60c dazu dienen, das ursprünglich in der Modellebene beheimatete Gesamtmodell 36 in der Zielarchitekturebene wiederzugeben. In der Zielarchitekturebene ist insbesondere der Signalaustausch zwischen einzelnen Systemarchitekturkomponenten 58a, 58b von Belang. Auszutauschende Signale (gekennzeichnet etwa durch System-Variablen) und deren Verläufe oder Pfade können mittels sogenannter Systemarchitekturkomponentenverbindungsblöcke 62, 64 (nachfolgend auch bezeichnet als Verbindungsblöcke) beschrieben werden. Jedem der Kommunikationsblöcke 60a, 60b, 60c können System-Variablen zugeführt werden, denen bestimmte Eigenschaften zugeordnet sind. Diese Eigenschaften können insbesondere Signalverzögerungseigenschaften betreffen. Beispielhaft kann der Kommunikationsblock 60a für Signale vorgesehen sein, die direkt und ohne Verzögerung transportiert werden sollen. Demgegenüber kann etwa der Kommunikationsblock 60b für Signale vorgesehen sein, die mit Verzögerung transportiert werden sollen. Es ist auch vorstellbar, etwa beim Kommunikationsblock 60c sowohl direkt zu verarbeitende als auch mit Verzögerung zu verarbeitende Signale anzuordnen.
-
Die Verbindungsblöcke 62a, 62b, 62c sowie 64a, 64b, 64c können nach Bedarf von der Simulationsumgebung 34 automatisiert erzeugt werden. Den Kommunikationsblöcken 60a, 60b, 60c können richtungsgebundene Signalpfade 66, 68 zugeordnet werden. Beispielhaft kann der Verbindungsblock 62a zur Beschreibung von Signalen dienen, die von der Systemarchitekturkomponente 58a zugeführt werden und entlang des Signalpfads 66 dem Kommunikationsblock 60a zugeleitet werden. Der Verbindungsblock 64a kann etwa zur Beschreibung von Signalen dienen, die ausgehend vom Kommunikationsblock 60a über den Signalpfad 68 der Systemarchitekturkomponente 58b zugeführt werden. Es versteht sich, dass etwa dann, wenn auf mehr als zwei Systemarchitekturkomponenten 58 zugegriffen werden soll, weitere denkbare Signalverläufe zwischen diesen entstehen können und entsprechend beschreibbar sind. Die Signalpfade 66, 68 können grundsätzlich richtungsgebunden sein. Es sind jedoch auch bidirektionale Signalpfade denkbar.
-
5 zeigt eine weitere Veranschaulichung eines Teilmodells, etwa des Teilmodells 38, das beispielsweise ein Teilelement des in 3 dargestellten Gesamtmodells 36 darstellen kann. Das Teilmodell 38 kann in üblicher Weise mit einem Funktionsmodell 70 versehen sein, das beispielsweise Regelungsfunktionen oder Steuerungsfunktionen beinhaltet, mit deren Hilfe Teile des Gesamtmodells 36 beschreibbar sind.
-
Zur Kopplung des Teilmodells 38 bzw. von dessen Funktionsmodell 70 mit weiteren Teilmodellen des Gesamtmodells 36 können sogenannte Schnittstellen-Eingangsblöcke 72 sowie Schnittstellen-Ausgangsblöcke 74 definiert werden. Die Schnittstellen-Eingangsblöcke 72a, 72b, 72c, 72d können dazu ausgestaltet sein, Eingangssignale 78a, 78b, 78c, 78d zu empfangen und in das Funktionsmodell 70 einzuleiten. Die Ausgangsblöcke 74a, 74b können dazu ausgestaltet sein, Ausgangssignale 80a, 80b, die im Funktionsmodell 70 erzeugt werden, abzuführen. Die Eingangsblöcke 72 und die Ausgangsblöcke 74 können unter Rückgriff auf die Datenbasis 22 (2) mit Signal-Identifikatoren 82, 84 verknüpft werden, die als Bezeichner für Signale dienen können. Bei den Signal-Identifikatoren kann es sich insbesondere um Eingangs-Signal-Identifikatoren 82a, 82b, 82c, 82d, 82e sowie um Ausgangs-Signal-Identifikatoren 84a, 84b handeln. Üblicherweise sind die Ausgangsblöcke 74a, 74b (auch bezeichnet als Schnittstellen-Ausgangsblöcke) dazu ausgebildet, jeweils genau ein Ausgangssignal 80a, 80b zu verarbeiten. Es versteht sich jedoch, dass die Identifikatoren nicht unbedingt eingangsspezifisch bzw. ausgangsspezifisch gewählt werden müssen. Das heißt mit anderen Worten, zumindest bei einigen bevorzugten Ausgestaltungen kann ein und derselbe Identifikator sowohl ein Ausgangssignal als auch ein Eingangssignal bezeichnen. Die Bezeichnungen Eingangs-Signal-Identifikator und Ausgangs-Signal-Identifikator sind in diesem Zusammenhang aus Veranschaulichungsgründen gewählt. Es handelt sich allgemein um Signal-Identifikatoren.
-
Demgegenüber können die Eingangsblöcke 72a, 72b, 72c, 72d (auch bezeichnet als Schnittstellen-Eingangsblöcke) dazu ausgebildet sein, aus einer Mehrzahl möglicher Signale, die durch eine Mehrzahl von Eingangs-Signal-Identifikatoren 82 bezeichnet sind, ein Signal auszuwählen und als Eingangssignal 78 dem Funktionsmodell 70 zuzuführen. Die Schnittstellen-Eingangsblöcke 72 und die Schnittstellen-Ausgangsblöcke 74 dienen als Platzhalter für direkte Signalpfade zwischen verschiedenen Teilmodellen. Die Schnittstellen-Eingangsblöcke 72 und die Schnittstellen-Ausgangsblöcke 74 erlauben eine ”Umleitung” der zu transferierenden Signale, wobei in einer Signalverknüpfungsebene in flexibler Weise eine (mittelbare) Verknüpfung mehrerer Teilmodelle 38, 40, 42, 44, 46 (vgl. 3) erfolgen kann. Diese Verknüpfungsebene kann etwa auf Daten zurückgreifen, die im Setupblock 48 hinterlegt sind. Diese Daten können vom Benutzer gewünschte Signalpfade wiedergeben und sind leicht manipulierbar, so dass Abwandlungen und Veränderungen in einfacher Weise eingepflegt werden können. Die mittelbare Verknüpfung erlaubt ein flexibles Anpassen der Signalverknüpfungen in der Simulationsumgebung, ohne dass jedes Mal auf der Modellebene Signalpfade manuell angepasst werden müssen.
-
Beispielhaft ist der Schnittstellen-Eingangsblock 72a in 5 dazu ausgebildet, eine Mehrzahl von Eingangssignalen zu verarbeiten, die durch Eingangs-Signal-Identifikatoren 82a, 82b repräsentiert sein können. Auf diese Weise kann der Schnittstellen-Eingangsblock 72a grundsätzlich auf eine Mehrzahl von Signalquellen zugreifen bzw. von diesen versorgt werden. Da es jedoch beabsichtigt ist, lediglich ein Eingangssignal 78a dem Funktionsmodell 70 zuzuführen, ist es bevorzugt, wenn eine Priorisierung der Eingangs-Signal-Identifikatoren 82a, 82b bzw. der durch diese bezeichneten Signale erfolgt.
-
Alternativ oder zusätzlich können die Schnittstellen-Eingangsblöcke 72 dazu ausgebildet sein, eine definierte Ersatzreaktion auszuführen, wenn kein Signal anliegt, das als Eingangssignal 78 dem Funktionsmodell 70 zuführbar ist.
-
Die Erzeugung von Signalpfaden (auch als Mapping bezeichnet) kann das Erzeugen von Signalpfaden zwischen mehreren Teilmodellen 38, 40, 42, 44, 46 umfassen. Eingänge (bzw. Eingangssignale) und Ausgänge (bzw. Ausgangssignale), die mit demselben Signal-Identifikator 82, 84 bezeichnet sind, können auf diese Weise verknüpft oder verbunden werden. Dies erfolgt mittelbar unter Einbeziehung der Kommunikationsblöcke 60, vgl. auch die Verbindungsblöcke 62, 64, die Eingänge bzw. Ausgänge der Kommunikationsblöcke 60 beschreiben können. Es versteht sich, dass ein Signalpfad regelmäßig ”virtuell” erzeugt wird.
-
6 veranschaulicht in vereinfachter Weise eine Systemarchitektur 56a, die beispielhaft verschiedene Systemarchitekturkomponenten 58a, 58b, 58c aufweisen kann. Bei den Systemarchitekturkomponenten 58 kann es sich etwa um einzelne Prozessoreinheiten oder Prozessoren aus einer Mehrzahl an Prozessoreinheiten oder Prozessoren handeln. Die Systemarchitektur 56a kann grundsätzlich als räumlich verteilte Systemarchitektur oder als integrierte Systemarchitektur ausgeführt sein.
-
6 zeigt ferner zu Veranschaulichungszwecken eine beabsichtigte Zuordnung von Teilmodellen 38, 40, 42, 44, 46 zu den Systemarchitekturkomponenten 58a, 58b, 58c. So kann etwa durch eine geeignete Eingabemöglichkeit am Setupblock 48 bestimmt werden, dass das Teilmodell 38 und das Teilmodell 40 auf der Systemarchitekturkomponente 58a auszuführen sind. Gleichsam kann bestimmt werden, dass das Teilmodell 42 auf der Systemarchitekturkomponente 58b laufen soll. Ebenso kann definiert werden, dass das Teilmodell 44 und das Teilmodell 46 der Systemarchitekturkomponente 58c zuzuweisen sind. Die auf der Modellebene lediglich mittelbar definierten Signalverknüpfungen zwischen den einzelnen Teilmodellen 38, 40, 42, 44, 46 müssen auf der in 6 gezeigten Systemarchitekturebene nachgezogen werden. Die Begriffe ”Nachziehen” oder ”Nachvollziehen” können das Erzeugen interner Signalverknüpfungen unter einer Erzeugung von System-Variablen umfassen, um die auf der Modellebene mittelbar definierten Signalverknüpfungen zwischen den Teilmodellen 38, 40, 42, 44, 46 unter Berücksichtigung der gegebenen Systemarchitektur 56a nachbilden zu können. Zu diesem Zweck müssen einerseits Modell-basierte Signalpfade, andererseits jedoch ebenso auch Systemarchitektur-bedingte Signalpfade berücksichtigt sein.
-
Mit anderen Worten ist darauf zu achten, die Signalpfade zwischen den Teilmodellen 38, 40, 42, 44, 46 des Gesamtmodells 36 unter Berücksichtigung der tatsächlichen Zuweisung der Teilmodelle 38, 40, 42, 44, 46 zu einer der Systemarchitekturkomponenten 58a, 58b, 58c nachzubilden und dabei in geeigneter Weise eine Kommunikation zwischen den Systemarchitekturkomponenten 58a, 58b, 58c zu ermöglichen. Dies kann einerseits einen (gedachten) Signalfluss innerhalb einer der Systemarchitekturkomponenten 58 umfassen, etwa wenn eine Mehrzahl von Teilmodellen 38, 40, 42, 44, 46 einer einzigen Systemarchitekturkomponente 58a, 58b, 58c zugewiesen sind. Ist jedoch ein Signalaustausch zwischen Teilmodellen 38, 40, 42, 44, 46 vorgesehen, die verschiedenen Systemarchitekturkomponenten 58a, 58b, 58c zugewiesen sind, so muss auch zwischen den Systemarchitekturkomponenten 58a, 58b, 58c ein Datenaustausch erfolgen.
-
Jedes der Teilmodelle 38, 40, 42, 44, 46 kann analog zur in 5 gezeigten, das Teilmodell 38 betreffenden Ausgestaltung mit entsprechenden Schnittstellen-Eingangsblöcken 72 und Schnittstellen-Ausgangsblöcken 74 versehen sein, die mit Eingangs-Signal-Identifikatoren bzw. Ausgangs-Signal-Identifikatoren verknüpft sind. Aus Veranschaulichungsgründen sind in 6 System-Variablen (oder: Signalgrößen) mit verschiedenen Großbuchstaben bezeichnet. Richtungsgebundene Pfeile verkörpern jeweils Signalrichtungen. Die System-Variablen A, B, C, D, E, G, X können gleichsam als Eingangssignale als auch als Ausgangssignale fungieren, sofern verschiedene Teilmodelle 38, 40, 42, 44, 46 involviert sind. Beispielhaft kann das Teilmodell 38 dazu ausgebildet sein, System-Variablen D, E zu erzeugen. Das Teilmodell 38 kann ferner dazu ausgebildet sein, System-Variablen A, B, X, C zu empfangen. Einem Schnittstellen-Eingangsblock des Teilmodells 38 können zwei System-Variablen B, X zugeführt werden. Der entsprechende Schnittstellen-Eingangsblock kann die Signale B, X priorisieren und ein Signal mit einer höheren Priorität bevorzugt weiterleiten. Das an einem Schnittstellen-Ausgangsblock des Teilmodells 38 anliegende Ausgangssignal (System-Variable E) wird lokal an das Teilmodell 40 übertragen und dient diesem als Eingangssignal. Der entsprechende Signalfluss oder Signalpfad kann sich innerhalb der Systemgrenzen der Systemarchitekturkomponente 58a erstrecken. Hingegen wird die System-Variable D, die vom Teilmodell 38 ausgegeben wird, eingangsseitig vom Teilmodell 42 erwartet, das der Netzarchitekturkomponente 58b zugewiesen ist. Somit muss die System-Variable D eine Grenze zwischen den Systemarchitekturkomponenten 58a, 58b überwinden. Dies kann unter Zuhilfenahme von Komponentenverknüpfungsinstanzen 86a, 86b, 86c erfolgen, die dem Signalaustausch zwischen den verschiedenen Systemarchitekturkomponenten 58a, 58b, 58c dienen.
-
Jede der Komponentenverknüpfungsinstanzen 86a, 86b, 86c kann zumindest einen Ausgangsport 88a, 88b, 88c, 88d, 88e, 88f aufweisen. Jeder der Ausgangsports 88 kann der definierten Leitung von System-Variablen A, B, C, D, E, G, X von genau einer Systemarchitekturkomponente 58 zu genau einer weiteren Systemarchitekturkomponente 58 dienen. So kann beispielsweise der Ausgangsport 88a der Komponentenverknüpfungsinstanz 86a dazu dienen, Signale auszugeben, die von der Systemarchitekturkomponente 58a in Richtung zur Systemarchitekturkomponente 58c zu leiten sind. Dementsprechend kann der Ausgangsport 88b für diejenigen Signale zuständig sein, die von der Systemarchitekturkomponente 58a zur Systemarchitekturkomponente 58b zu leiten sind.
-
In ähnlicher Weise können die übrigen Ausgangsports 88c, 88d, 88e, 88f gestaltet werden und jeweils die Verknüpfung mit den übrigen Systemarchitekturkomponenten 58 regeln. Mit anderen Worten können die Komponentenverknüpfungsinstanzen 86a, 86b, 86c als Schnittstellen zwischen den einzelnen Systemarchitekturkomponenten 58a, 58b, 58c fungieren. Auf diese Weise können definierte Signalverknüpfungen 90a, 90b, 90c, 90d definiert werden, die auf der Systemarchitekturebene einen Datenaustausch zwischen den Teilmodellen 38, 40, 42, 44, 46 ermöglichen, der auch Systemarchitekturkomponenten-übergreifend erfolgt, also auch zwischen verschiedenen Systemarchitekturkomponenten 58.
-
Der Benutzer kann etwa durch entsprechende Eingabe am Setupblock 48 die Zuordnung oder Zuweisung der Teilmodelle 38, 40, 42, 44, 46 zu den einzelnen Systemarchitekturkomponenten 58a, 58b, 58c verändern. Dabei können die Signalverknüpfungen 90 zwischen den einzelnen Systemarchitekturkomponenten 58 automatisiert angepasst werden.
-
7 veranschaulicht in vereinfachter Weise mithilfe eines Blockdiagramms ein Verfahren zur flexiblen automatisierten Verbindung von Teilmodellen eines Gesamtmodells unter Berücksichtigung einer gegebenen Systemarchitektur in einer Simulationsumgebung. In einem ersten Schritt 94 werden zumindest ein Schnittstellen-Eingangsblock und ein Schnittstellen-Ausgangsblock für zumindest ein gegebenes Teilmodell zum Signalaustausch mit zumindest einem weiteren Teilmodell bereitgestellt. Die Schnittstellen-Eingangsblöcke und die Schnittstellen-Ausgangsblöcke können als Platzhalter fungieren und eine mittelbare Signalverknüpfung ermöglichen. Dem zumindest einen Schnittstellen-Eingangsblock und dem zumindest einen Schnittstellen-Ausgangsblock kann jeweils zumindest ein definierter Signal-Identifikator zugewiesen werden, der eine zu übertragende Signalgröße kennzeichnet. Vorzugsweise ist der Signal-Identifikator derart eindeutig definiert, dass Fehlzuweisungen nicht möglich sind. Beispielhaft kann der definierte Signal-Identifikator aus einem definierten Namen für das Teilmodell sowie einem definierten Signalnamen gebildet sein. Es besteht ferner die Möglichkeit, einen Zugriff auf eine Datenbasis bereitzustellen, in der verwendbare Teilmodelle sowie jeweils für die Teilmodelle verwendbare Signal-Identifikatoren verzeichnet sind.
-
In einem weiteren Schritt 96 kann eine Eingabemöglichkeit oder Auswahlmöglichkeit bereitgestellt werden, die eine Zuordnung des zumindest einen Teilmodells zu einer gewählten Systemarchitekturkomponente der Systemarchitektur erlaubt. Auf diese Weise können Teilmodelle flexibel und einfach einzelnen Systemarchitekturkomponenten zugewiesen werden. Bei den Systemarchitekturkomponenten kann es sich etwa um einzelne Prozessoren oder Prozessoreinheiten handeln. Die Zuweisung des Teilmodells kann darauf gerichtet sein, festzulegen, dass das entsprechende Teilmodell auf der entsprechenden Systemarchitekturkomponente ausgeführt wird.
-
Es kann sich ein Schritt 98 anschließen, der das Erzeugen von internen Signalverknüpfungen zum Signalaustausch zwischen den gewählten Systemarchitekturkomponenten umfasst, wobei die den Teilmodellen zugewiesenen Signal-Identifikatoren sowie die gewählte Zuordnung zwischen den Teilmodellen und den Systemarchitekturkomponenten berücksichtigt werden. Auf diese Weise kann ein Abgleich (auch bezeichnet als Mapping) erfolgen, bei dem Signalverläufe in einer Modellebene (zwischen den Teilmodellen) in korrespondierende Signalverläufe in einer Systemarchitekturebene (zwischen Systemarchitekturkomponenten) überführt werden.
-
Der Schritt 98 kann verschiedene Teilschritte umfassen. Beispielhaft kann der Schritt des Erzeugens von internen Signalverknüpfungen ein Erzeugen von System-Variablen umfassen, die einen Signalaustausch zwischen den verschiedenen Systemarchitekturkomponenten erlauben. Dies wird durch einen Schritt 100 veranschaulicht. Alternativ oder zusätzlich kann ein Schritt 102 vorgesehen sein, der das Bereitstellen zumindest eines Systemarchitekturkomponentenkommunikationsblocks zur Kommunikation mit den Systemarchitekturkomponenten und das Erzeugen zumindest eines eingangsseitigen und eines ausgangsseitigen Systemarchitekturkomponentenverbindungsblocks umfasst, die eine Definition des Austauschs von System-Variablen zwischen den Systemarchitekturkomponenten ermöglichen.
-
8 veranschaulicht ein vereinfachtes Ablaufdiagramm, das ein mögliches Ablaufschema von Teilschritten bei der Erzeugung von internen Signalverknüpfungen beschreibt. Das Ablaufschema kann etwa eine Funktionalität wiedergeben, die der Komponentenverknüpfungsinstanz 86 einer Systemarchitekturkomponente 58 zugewiesen ist. Ein Start-Ereignis ist durch einen mit 104 bezeichneten Block beschrieben. Eine Terminierung des Ablaufs ist durch einen mit 124 bezeichneten Block beschrieben.
-
In einem Schritt 106 können die Eingangs-Signal-Identifikatoren 82 und die Ausgangs-Signal-Identifikatoren 84 der Teilmodelle gelistet werden, die der aktuellen Systemarchitekturkomponente 58 zugewiesen sind. Dabei kann es sich beispielhaft bei der Systemarchitekturkomponente 58a um die Teilmodelle 38 und 40 handeln.
-
Ein nächster Schritt 108 kann das Erzeugen einer lokalen System-Variablen für jeden der gelisteten Ausgangs-Signal-Identifikatoren 84 umfassen. Beim vorliegenden Beispiel, das auf 6 beruht, kann es sich dabei etwa um die System-Variablen D, E und G handeln.
-
In einem nächsten Schritt 110, der eine Verzweigung (ja-oder-nein-Entscheidung) enthält, wird geprüft, ob einem der Schnittstellen-Eingangsblöcke (bzw. Eingangs-Signal-Indikatoren 82) der aktuell betrachteten Teilmodelle 38, 40 eine der erzeugten System-Variablen zugeordnet ist. Dies ist zunächst zu Beginn noch nicht der Fall. Keinem der Eingangs-Signal-Indikatoren 82 ist eine System-Variable zugeordnet. Demzufolge kann noch nicht terminiert werden.
-
Es kann sich daher für jeden unverknüpften noch nicht behandelten Eingang ein Schritt 112 anschließen, bei dem für einen der (unverknüpften) Eingangs-Signal-Indikatoren 82 ein zuordenbarer Wert gesucht wird. Dies erfolgt beim Schritt 112 lokal für die aktuelle Systeminfrastrukturkomponente 58a. Im vorliegenden Beispiel findet sich für einen Eingang des Teilmodells 40 mit der System-Variable E vom Ausgang des Teilmodells 38 eine Entsprechung. Über einen Verzweigungsschritt 114 (ja-oder-nein-Entscheidung) kann somit in diesen Fall zu einem Schritt 122 übergegangen werden, bei dem die System-Variable E vom Ausgang des Teilmodells 38 einem korrespondierenden Eingang (und somit einem Eingangs-Signal-Identifikator 82) des Teilmodells 40 zugewiesen werden kann.
-
Im vorliegenden Beispiel wird beim jeweiligen Durchlauf der Verknüpfungsschleife (für jeden der Eingänge der Teilmodelle 38 und 40) jedoch beim Schritt 114 festgestellt, dass die übrigen Eingänge und Ausgänge der Teilmodelle 38 und 40 nicht lokal verknüpft werden können. Wäre dies der Fall, könnte insgesamt zum Schritt 124 übergegangen werden, der eine Terminierung des Gesamt-Ablaufs beinhalten kann, wenn kein Eingang mehr ”übrig” ist.
-
Solange jedoch nicht sämtliche Eingänge der Teilmodelle 38 und 40 abgearbeitet sind, ist für jeden Eingang gesondert zu prüfen, ob bei einer der anderen Systemarchitekturkomponenten 58b, 58c eine passende System-Variable zur Verfügung steht. Dies kann bei einem Schritt 116 erfolgen, der auch eine Verzweigung (ja-oder-nein-Entscheidung) umfasst.
-
Im vorliegenden Beispiel gemäß 6 kann etwa festgestellt werden, dass geeignete Eingangssignale von den Systemarchitekturkomponenten 58b, 58c zugeliefert werden können. Es kann sich insbesondere um die System-Variablen C, A und B handeln. Diese können der Systemarchitekturkomponente 58a über geeignete Signalverknüpfungen zugeführt werden. Dies wird durch einen Schritt 120 veranschaulicht. Der Schritt 120 kann die Schaffung einer Systemarchitekturkomponenten-übergreifenden Verknüpfung beinhalten. Zu diesem Zweck kann auf die Systemarchitekturkomponentenverbindungsblöcke zurückgegriffen werden. Ferner kann dies beinhalten, dass korrespondierend innerhalb der aktuellen Systemarchitekturkomponente eine Entsprechung der jeweiligen System-Variablen lokal erzeugt wird, also etwa die System-Variablen A, B und C. Es kann sich der Schritt 122 anschließen, der in geeigneter Weise das Verknüpfen der Eingänge mit den System-Variablen umfassen kann. Nach dem Schritt 122 folgt üblicherweise (wiederum) der Schritt 110, so dass eine Schleife realisiert ist, in der alle Schnittstellen-Eingangsblöcke bzw. Eingangs-Signal-Indikatoren abgearbeitet werden.
-
Sollte beim Schritt 116 festgestellt werden, dass für einen Eingang eines der Teilmodelle 38, 40 kein Eingangssignal vorhanden ist, weder lokal in der Systemarchitekturkomponente 58a noch in den weiteren Systemarchitekturkomponenten 58b, 58c, kann im Rahmen eines Schritts 118 eine Ersatzstrategie angewandt werden. Die Ersatzstrategie kann verschiedene Gestaltungen aufweisen. Beispielsweise kann eine definierte Fehlermeldung ausgegeben werden. Es kann jedoch auch dahingehend auf ein fehlendes Signal reagiert werden, dass ein Null-Wert oder ein konstanter Wert weitergegeben wird, der das Signal ersetzt. Weitere ähnliche Variationen sind denkbar. Dies kann bei der in 6 gezeigten beispielhaften Gestaltung etwa auf die System-Variable X zutreffen, die in der Systemarchitekturkomponente 58a eingangsseitig erwartet wird, aber von keiner der Systemarchitekturkomponenten 58a, 58b, 58c zur Verfügung gestellt werden kann. Nach dem Abarbeiten des Schritts 118 kann die Schleife geschlossen werden, indem (wiederum) der Schritt 110 folgt, bei dem geprüft wird, ob einem weiteren Schnittstellen-Eingangsblock (bzw. Eingangs-Signal-Indikator 82) der aktuell betrachteten Teilmodelle 38, 40 eine der erzeugten System-Variablen zugeordnet ist. Somit können schrittweise alle Eingangsblöcke behandelt werden. Es kann sich die Terminierung 124 anschließen, wenn keine unbehandelten Eingänge mehr vorhanden sind.
-
Das anhand der Darstellung in 8 veranschaulichte Ablaufschema kann auf jede der Systemarchitekturkomponenten 58a, 58b, 58c angewandt werden. Auf diese Weise kann in einfacher Weise die Erzeugung von Signalverknüpfungen auf der Systemarchitekturebene unter Berücksichtigung der auf der Modellebene mittelbar definierten Signalverknüpfungen erfolgen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 10347891 A1 [0005]
- DE 10333087 A1 [0006]
