Suchen

Systembeschreibung

Dynamische Softwarearchitektur für eingebettete Systeme

Seite: 6/6

Firma zum Thema

zeitliche Einschränkungen (Constraints)

Danach wird der funktionale Systementwurf durch die Annotation von Constraints an Anwendungs-Elemente (z.B. Signale) verfeinert und kann nun als ein Input in den Plattformentwurf dienen.

Um 200kHz Signale sicher zu erfassen ist die doppelte Sampling-Rate notwendig. Im Sonar-System wird die Sampling-Rate der Analog-Digital-Wandlung auf 1MHz festgelegt um Ungenauigkeiten im Low-Pass-Filter abzufangen und Signalanteile über 200kHz Frequenz zu erfassen. Daher werden in diesem Schritt drei Zeit-Constraints annotiert, die sich aus den nicht-funktionalen Anforderungen ergeben:

Bildergalerie

Bildergalerie mit 10 Bildern
  • Die Sampling-Rate der Analog-Digital-Wandung,
  • die maximale Zeit für die Objekterkennung und
  • die gesamte Berechnungszeit des Systems .

Die maximale Zeit für die Objekterkennung ermittelt sich daraus, dass im Erkennungsbereich von bis zu 50m ein Objekt-Echo innerhalb von 71ms empfangen wird. Daher muss das Sonar-System diese Zeit warten bevor ein neues Signal ausgesendet werden kann. Innerhalb dieser Zeit muss das System ein Echo auswerten und die Objekterkennung durchführen können. Die Objekterkennung wird mittels Kreuzkorrelation durchgeführt. Dafür ist ein weiterer Zeit-Constraint notwendig, der sich aus dem bestehenden funktionalen Systementwurf und den Systemanforderungen ergibt. Das Fourier-transformierte ausgesendete Signal muss gespeichert werden bevor die ersten Echos empfangen werden. Die maximale Zeit bis zum Speichern ergibt sich daraus, dass der Erkennungsbereich bei 2m beginnt. Innerhalb von 3ms können die ersten Echos empfangen werden. Damit muss zusätzlich die maximale Zeit bis zum Speichern (T_Speichern) bei weniger als 3ms liegen. Abbildung 7 zeigt wie dieser Constraint im funktionalen Systementwurf annotiert wird.

Plattformentwurf

In unserer Entwurfsstudie wird für den Plattformentwurf eine bestehende Hardware-Plattform wiederverwendet. Sie ist als Plattform-Komponenten-Modell (vgl. Bild 8 in der Bildergalerie) verfügbar und besteht aus sechs Plattform-Modulen, dem FPGA-Motherboard, dem FPGA-Extension Board, dem A/D-Converter Board, dem Transducer Interface, dem Transducer selbst und einem Spannungsversorgungs-Modul.

Hier wird erkennbar, dass die Prozessor-Elemente (PWM und NIOS) physikalisch durch den Avalon-Bus miteinander verbunden sind. Der Avalon-Bus dient auch als Verbindung zum CAN-Controller und den SPI-Controllern “AD-Controller1” und “AD-Controller2” die sich auf dem FPGA-Extension Board befinden. Die Prozessor-Elemente erfüllen unterschiedliche Aufgaben. Um sie logisch zu trennen werden bei der Erstellung des Plattform-Domänen-Modells der Hardware-Plattform drei Domänen erzeugt die die Prozessor-Elemente kapseln (vgl. Bild 9 in der Bildergalerie). Damit wird auch die physikalische Trennung der Plattform-Module überwunden und relevante Ressourcen den logischen Domänen bereitgestellt werden.

Alle Hardware-Komponenten werden durch passende Ressourcen repräsentiert, beispielsweise werden die Speicher-Elemente MEM2 und MEM3 als Speicher-Ressourcen modelliert. Alle Ressourcen die von mehreren Domänen genutzt werden, sind als geteilte Ressourcen (shared resource) modelliert und in der Domänen-Sicht im Zwischenraum zwischen den nutzenden Domänen visualisiert.

Die Domäne NiosMainSystem die das Prozessor-Element NIOS kapselt, stellt eine Speicherpartition dar (mittels der Ressource MEM3). Im Gegensatz dazu ist PwmSubsystem nur eine Rechenzeitpartition.

Nachdem die Hardware-Domänen modelliert sind, werden höherwertige Domänen wie beim NiosMainSystem ein Betriebssystem modelliert. Hier werden 2 Tasks (Sub-Domänen) modelliert, die verschiedene Dienste anbieten. Ein Scheduler (Ressourcen-Manager) kann hier bis zu 64 Tasks bereitstellen (vgl. Bild 9 in der Bildergalerie). Die Hardware-Domäne PwmSubsystem benötigt keine zusätzliche Software-Schicht, die Anwendungs-Elemente werden hier direkt an die Dienste der Hardware-Domäne gebunden.

Bindung von Sonar-Anwendung und Plattform

Nachdem sowohl die Anwendung als auch die Plattform modelliert wurden, kann die Bindung der Anwendungs-Elemente an die Plattform erfolgen. Abbildung 10 zeigt beispielhaft die Bindung von Tasks an Domänen und deren Ausführungs-Dienste. Die Bindung von Tasks an Domänen erfolgt, indem die Tasks im Ausführungs-Bereich der Domänen, der freien Fläche, platziert werden. Die Bindung von Kommunikation (Ports und Links) oder Spezial-Tasks wie Speicher und Zeit wird hier nicht dargestellt.

Die Plattform stellt eine Domäne FftSubsystem bereit, die speziell für die Berechnung von Fast-Fourier-Transformationen geeignet ist. Deshalb werden das Modul CrossCorrelation und der Task IFFT zur Ausführung an den Ausführungs-Dienst dieser Domäne gebunden. Der Anwendungs-Task SignalGenerator wird an die Domäne PwmSubsystem gebunden. Wie in Abbildung 10 dargestellt, werden die Tasks des Moduls TargetDetection auf 2 unterschiedliche Domänen aufgeteilt. Die Tasks EnvelopeFilter und ThresholdFilter werden durch die Domäne NiosMainsystem bzw. deren Sub-Domäne Task1 ausgeführt. Die Domäne Task2 bindet das Modul Management und ermöglicht damit eine nebenläufige Ausführung von Management und TargetDetection auf einem Prozessor.

Zusammenfassung

Wir zeigen mit unserer Entwurfsmethodik und dem zugehörigen Metamodell wie die Besonderheiten des dynamischen Verhaltens eingebetteter Software berücksichtigt werden können. Ein besonderes Augenmerk gilt dabei der Dynamik der Hardware/Software-Schnittstelle.

In unseren weiteren Forschungsarbeiten wollen wir die Bindung von Anwendung und Plattform - insbesondere deren intuitive grafische Darstellung - analysieren und uns verstärkt um die Anbindung von Constraints an Anwendungs- und Plattform-Elemente kümmern. Als Basis dafür soll eine Implementierung der Entwurfsmethodik und des Metamodells erfolgen.

Literatur- und Quellenverzeichnis

[1] L. P. Carloni, F. De Bernardinis, C. Pinello, A. L. Sangiovanni-Vincentelli, and M. Sgroi. Platform-Based Design for Embedded Systems. In R. Zurawski, editor, Embedded systems handbook, Industrial information technology series, pages 1–26. Taylor & Francis, Boca Raton, 2006.

[2] C. Hausner and F. Slomka. Abstract Modeling of Embedded Systems Hardware. In Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2013), pages 251–258, 2013.

[3] I. Jacobson. Object-oriented software engineering: A use case driven approach. Addison-Wesley, Harlow, revised printing edition, 1998.

[4] G. Karsai. Modeling Cyber-Physical Systems: Challenges and Recent Advances, 05.09.2014.

[5] Object Management Group. OMG Systems Modeling Language, version 1.2 (OMG SysML). Object Management Group, Needham, 1.2 edition, 2010.

[6] Object Management Group. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems. Object Management Group, Needham, 1.1 edition, 2011.

[7] Object Management Group. Unified Modeling Language (UML), 2013.

[8] A. L. Sangiovanni-Vincentelli. Defining Platform-based Design. 2002.

[9] F. Slomka, S. Kollmann, S. Moser, and K. Kempf. A Multidisciplinary Design Methodology for Cyber-physical Systems. In S. V. Baelen, S. Gérard, I. Ober, T. Weigert, H. Espinoza, and I. Ober, editors, Proceedings of the 4th International Workshop on Model Based Architecting and Construction of Embedded Systems ACES-MB 2011, CEUR Workshop Proceedings, 2011.


* Frank Slomka ist seit 2007 Professor am Institut für eingebettete Systeme der Uni Ulm. Zu seinen Forschungsinteressen zählen der Entwurf eingebetteter Systeme insbesondere im Bereich der Nachrichten- und Energietechnik, die Entwurfsautomatisierung in der Mikroelektronik (EDA) und die Echtzeitanalyse und -modellierung.

* Christian Hausner ist seit 2012 externer Doktorand am Institut für eingebettete Systeme der Uni Ulm. Seine Forschungsinteressen sind der Entwurf eingebetteter Systeme, die Entwurfsautomatisierung sowie die Modell-basierte und Modell-getriebene Entwicklung.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 44199816)