Automatische Parallelisierung eines modellbasierten Designs<\/p>\n
Autoren: Peer Ulbig, Umut Durak, David M\u00fcller, Deutsches Zentrum f\u00fcr Luft- und Raumfahrt e.V., Oliver Oey, Timo Stripf, Michael R\u00fcckauer, emmtrix Technologies GmbH<\/p>\n
Der Luft- und Raumfahrtsektor verlangt nach neuen Methoden und Ans\u00e4tzen zur kosteneffizienten Steigerung der Performanz von Anwendungen unter Beibehaltung des Sicherheitsniveaus und der Programmierbarkeit. Ein vielversprechender Ansatz besteht in der Verwendung von Multicore-Architekturen. Um ihr volles Potenzial aussch\u00f6pfen zu k\u00f6nnen, besteht neben der notwendigen Zertifizierung allerdings auch ein Bedarf an Programmierwerkzeugen und -prozessen. Dabei ist die Unterst\u00fctzung des modellbasierten Entwurfs zur Vereinfachung der Systemmodellierung, der Verifikation und der Validierung von Designentscheidungen entscheidend. In diesem Paper wird daher ein modellbasierter Entwurf f\u00fcr Multicore-Architekturen vorgestellt. Als Fallstudie wird ein „Terrain Awareness and Warning System“ (TAWS) modellbasiert entwickelt und mit Hilfe der interaktiven Parallelisierungsl\u00f6sung emmtrix Parallel Studio (ePS) f\u00fcr die Ausf\u00fchrung auf einem Infineon Aurix TC297B Mikrocontroller parallelisiert.<\/strong><\/p>\n Der Bedeutungszuwachs der Cyberanteile in Flugzeugen, wie Avioniksysteme, Sensoren, Aktoren und Datenbusse, f\u00fchrte zu einem Paradigmenwechsel von verteilten Onboard-Systemarchitekturen hin zu „Integrated Modular Avionics“ (IMA) [1]. Statt dezentraler und dedizierter Recheneinheiten verbindet man IMA damit, dass mehrere Anwendungen dieselbe Recheneinheit verwenden [2]. Dabei wurden h\u00f6here Durchsatzanforderungen immer wichtiger und schlie\u00dflich auch Multicore- und Multiprozessor-Systeme zu einem wichtigen Thema.<\/p>\n Viele Bem\u00fchungen zur Parallelisierung bei der Entwicklung von Flugsystemen mit Multicore-Architekturen konzentrierten sich auf die Anwendbarkeit hinsichtlich der Sicherheitseinschr\u00e4nkungen im Bereich der Avionik [3, 4, 5, 6, 7, 8, 9]. Segregation, Integrit\u00e4t, Berechenbarkeit, Zertifizierungskosten und Leistung sind wichtige Herausforderungen, die es zu bew\u00e4ltigen gilt [8]. Dar\u00fcber hinaus bleibt eine effektive und effiziente Entwicklungsmethodik f\u00fcr Avionik-Anwendungen mit Multicore-Architekturen eine Forschungsfrage. Im Bereich der Luft- und Raumfahrt m\u00fcssen noch komplexe Werkzeugketten und Programmierprozesse entwickelt werden, um das volle Potenzial dieser heterogenen parallelen Plattformen der n\u00e4chsten Generation aussch\u00f6pfen zu k\u00f6nnen.<\/p>\n ARGO (WCET-Aware PaRallelization of Model-Based Applications for HeteroGeneOus Parallel Systems) ist ein im Rahmen des Forschungs- und Innovationsprogramms Horizon 2020 der Europ\u00e4ischen Union gef\u00f6rdertes Projekt. Es befasst sich mit der Codegenerierung f\u00fcr Worst Case Execution Time (WCET)-bewusste Parallelisierung von modellbasierten Anwendungen f\u00fcr Multicore-Systeme [10, 11].<\/p>\n Dieses Paper stellt eine Fallstudie vor, in der ein Terrain Awareness and Warning System (TAWS) modellbasiert entwickelt und mit Hilfe der interaktiven Parallelisierungsl\u00f6sung emmtrix Parallel Studio (ePS) f\u00fcr die Ausf\u00fchrung auf dem Infineon AURIX optimiert wurde. Als konkretes Beispiel wurde eine Nachbildung des Enhanced Ground Proximity Warning Systems (EGPWS) gew\u00e4hlt.<\/p>\n Die modellbasierte Entwicklung f\u00f6rdert den Aufbau von Modellen und die Generierung ausf\u00fchrbarer Software durch sukzessive Modell-zu-Modell- und Modell-zu-Text-Transformationen [12]. Der modellbasierte Entwurf ist eine Variante der modellbasierten Entwicklung. Er zeichnet sich durch den nahtlosen Einsatz von ausf\u00fchrbaren und grafischen datenflussorientierten Blockdiagrammmodellen und Zustandsautomaten f\u00fcr die Systemspezifikation, sowie den Entwurf und die Implementierung aus. Dabei kommen modellbasierte Entwurfs- und Simulationswerkzeuge wie Scilab\/Xcos oder MATLAB\/Simulink zum Einsatz [13].<\/p>\n Der modellbasierte ARGO-Workflow (Abb. 1, s.\u00a0PDF<\/a>) beginnt mit der Regler-Modellierung, bei der die Anwendungsmodelle in der Scilab\/Xcos-Umgebung implementiert werden. Scilab\/Xcos ist eine modellbasierte Open Source Design- und Simulationsumgebung [14]. Dabei kann die Scilab-Skriptsprache in einzelnen graphischen Bl\u00f6cken des Modells verwendet werden, wodurch eine kombinierte graphische und imperative Beschreibung im Modell erm\u00f6glicht wird. Die Zielarchitektur wird ebenfalls gleich zu Beginn mit Hilfe einer Architekturbeschreibungssprache (ADL) festgelegt.<\/p>\n Im ersten Schritt (Frontend Tools) wird die Modell-zu-Text-Transformation verwendet, um aus den Scilab\/Xcos-Modellen plattformunabh\u00e4ngigen, sequentiellen C-Quellcode zu generieren. Ausgehend davon f\u00fchrt das „GeCoS Source-to-Source Transformation Framework“ [15] Programmtransformationen durch, die z.B. auf Parallelisierung oder Optimierung abzielen. Dazu wird zun\u00e4chst das C Programm in einen hierarchischen Task-Graphen (HTG) [16] \u00fcberf\u00fchrt.<\/p>\n Der HTG enth\u00e4lt Informationen \u00fcber Abh\u00e4ngigkeiten und Ausf\u00fchrungszeiten. So sind zwei Tasks voneinander abh\u00e4ngig, wenn sie auf die gleichen Daten zugreifen. In der Schedulingphase wird der HTG auf die einzelnen Kerne der Multicore-Zielplattform abgebildet. Dabei wird festgelegt, welche Tasks in welcher Reihenfolge auf welchem Kern ausgef\u00fchrt werden. Wenn zwei Tasks voneinander abh\u00e4ngig sind, dann m\u00fcssen die Tasks im Schedule nacheinander ausgef\u00fchrt werden. Im Schritt „Data Management, Synchronization and Code Generation“ aus Abbildung 1 (s.\u00a0PDF<\/a>) werden die Ergebnisse des Schedulings verwendet, um eine explizite parallele Programmdarstellung mit Kommunikation, Synchronisationen und Adress-Mappings zu erzeugen. Der WCET-Schritt auf Code- und Systemebene berechnet die Multi-Core WCET f\u00fcr die Zielarchitektur. Als Ergebnis wird ein paralleles C-Programm generiert.<\/p>\n Controlled Flight Into Terrain (CFIT) war f\u00fcr viele Todesf\u00e4lle in der Zivilluftfahrt verantwortlich, bis die Installation von Terrain Awareness and Warning Systems (TAWS) von vielen Luftfahrtbeh\u00f6rden vorgeschrieben wurde (vgl. Federal Aviation Administration, [17]). Es gibt verschiedene TAWS-Optionen auf dem Markt, die eine Reihe von Funktionen zur Verf\u00fcgung stellen, um dem Risiko von CFIT entgegenzuwirken. T3CAS von ACSS [18] und TAWS von Universal Avionics [19] sind zwei davon. Ein kurzer Vergleich dieser Systeme ist in [20] zu finden. Das Enhanced Ground Proximity Warning System (EGPWS) ist ein weiteres Beispiel f\u00fcr ein TAWS, es wurde von Honeywell [21] entwickelt und dient in den folgenden Abschnitten als Vorbild.<\/p>\n Die Kernfunktion des EGPWS besteht darin, visuelle und akustische Warnungen zwischen 30\u00a0ft und 2450\u00a0ft \u00fcber Grund (AGL) zu erzeugen, um CFIT zu vermeiden. Diese Warnungen sind in f\u00fcnf Modi unterteilt:<\/p>\n Abbildung 2 (s.\u00a0PDF<\/a>) verdeutlicht den ersten Modus des EGPWS. Die drei Flugzeuge haben die gleiche H\u00f6he von etwa 2000\u00a0ft, aber unterschiedliche Sinkgeschwindigkeiten, was durch ihre Position und Ausrichtung in der Grafik verdeutlicht wird. W\u00e4hrend sich das gr\u00fcne Flugzeug in einem sicheren Flugzustand befindet, wird durch die Sinkrate des orangefarbenen Flugzeugs eine Warnung ausgel\u00f6st. Das rote Flugzeug sinkt in Relation zu seiner geringen H\u00f6he viel zu schnell und erfordert ein sofortiges Eingreifen des Piloten, weshalb eine eindringlichere Warnung ausgegeben wird.<\/p>\n Zus\u00e4tzlich zu den f\u00fcnf genannten Modi bietet das EGPWS einige erweiterte Funktionen, wie das „Terrain Look Ahead Alerting“ und das „Terrain Alerting and Display“, die auf einer Gel\u00e4ndedatenbank basieren. Beim Terrain Look Ahead Alerting wird bis zu einer Entfernung, die bei der aktuellen Fluggeschwindigkeit 60\u00a0s Flugzeit entspricht, anhand der Gel\u00e4ndedatenbank bestimmt, ob eine Kollision mit dem Gel\u00e4nde droht oder nicht. In einem solchen Fall w\u00fcrde das System eine Ermahnung ausgeben. Kann es dar\u00fcber hinaus bereits innerhalb der n\u00e4chsten 30\u00a0s Flugzeit zu einer Kollision kommen, kommt es zu einer intensiveren Warnung durch das System. Diese Zusammenh\u00e4nge verdeutlicht Abbildung 3 (s.\u00a0PDF<\/a>).<\/p>\n Dem modellbasierten Design-Workflow von ARGO entsprechend wurden die f\u00fcnf Basismodi des EGPWS in Scilab\/Xcos nachgebildet. Abbildung 4 (s.\u00a0PDF<\/a>) zeigt beispielhaft die Nachbildung des EGPWS-Modus 1 (Abb. 2) im Scilab\/Xcos-Modell.<\/p>\n Das Terrain Look Ahead Alerting und das Terrain Alerting and Display wurden zudem als Scilab-Skripte implementiert.<\/p>\n Die Parallelisierung des TAWS nach Vorbild des EGPWS erfolgt mit dem \u00fcbergeordneten Ziel, dass das System anschlie\u00dfend f\u00fcr Testzwecke auf verschiedenen Wegen mit dem Air VEhicle Simulator (AVES) des DLR Braunschweig kommunizieren k\u00f6nnen soll. Zun\u00e4chst ist eine Processor-in-the-Loop Testreihe geplant, bei der f\u00fcr das EGPWS \u00fcblicherweise eingesetzte Datenbusse, wie beispielsweise ARINC 429, durch eine einzige Ethernet-Verbindung zum Simulator ersetzt werden.<\/p>\n Das Zielsystem f\u00fcr die Processor-in-the-Loop Testreihe ist das Aurix TC297 Starter Kit, welches einen Aurix TC297B Mikrocontroller mit drei Kernen und integrierter Ethernet-Schnittstelle (MAC) bietet. Die Bit\u00fcbertragungsschicht (PHY) ist als integrierter Schaltkreis auf dem Starter Kit vorhanden. Weiterhin wird das Echtzeitbetriebssystem FreeRTOS in einer f\u00fcr das Zielsystem portierten Version eingesetzt. Auf einem Kern soll als Ethernet Task (eth_task) die asynchrone Kommunikation mit dem Flugsimulator betrieben werden. Auf den beiden verbleibenden Kernen wird die hardwareunabh\u00e4ngige parallelisierte Logik des EGPWS als Application Task (app_task) ausgef\u00fchrt.<\/p>\n Theoretisch f\u00fchren zwar alle Kerne beide Tasks aus, in Abh\u00e4ngigkeit vom jeweiligen Kern gibt jedoch einer der beiden Tasks durch unmittelbares Schlafenlegen die entsprechende CPU wieder frei. Der Datenaustausch zwischen den Tasks erfolgt \u00fcber einen gemeinsamen, durch einen Mutex gesch\u00fctzten Speicherbereich (Shared Memory) in der Local Memory Unit (LMU) des Aurix TC297B. Auf diese Weise werden die physikalischen Schnittstellen f\u00fcr die TAWS-Logik durch Speicherzugriffe abstrahiert. Abbildung 5 (s.\u00a0PDF<\/a>) verdeutlicht diese Ans\u00e4tze.<\/p>\n Der Ausgangspunkt des ARGO-Workflows f\u00fcr die Parallelisierung des TAWS ist zun\u00e4chst Scilab. Hier wird das Xcos-Modell des TAWS in Scilab-Code \u00fcbersetzt. Dabei werden neben der TAWS-Schrittfunktion Dateneingangs- und -ausgangsfunktionen sowie eine Szenario-Datei erzeugt, welche Eingangs-, Ausgangs- und Zustandsvariablen initialisiert und die genannten Funktionen nacheinander aufruft. Das so erzeugte Scilab-Szenario ist wiederum die Ausgangsbasis f\u00fcr die eigentliche Parallelisierung mit Hilfe des ePS. Ein neues Projekt mit der Zielhardware Aurix TC297 Starter Kit und der Eingangsprogrammiersprache Scilab wird im ePS erstellt und der zuvor generierte Scilab-Code eingebunden.<\/p>\n Im n\u00e4chsten Schritt wird aus dem Scilab-Code sequentieller C-Code generiert. Dieser Schritt beeinflusst bereits ma\u00dfgeblich den sp\u00e4ter erzeugten parallelen C-Code. Codeoptimierungen in Bezug auf Wertebereiche der Eingangs-, Ausgangs-, und Zustandsvariablen im konkreten Scilab-Szenario werden unterdr\u00fcckt. So wird sichergestellt, dass der C-Code die TAWS-Schrittfunktion f\u00fcr alle m\u00f6glichen Kombinationen und Abfolgen von Eingangswerten unabh\u00e4ngig vom gew\u00e4hlten Scilab-Szenario richtig wiedergibt. Zudem werden die Dateneingangs- sowie die Datenausgangsfunktion in separaten Quellcode ausgelagert. Auf diese Weise werden nur deren Funktionsaufrufe bei der sp\u00e4teren Parallelisierung ber\u00fccksichtigt, im Gegensatz zur TAWS-Schrittfunktion jedoch nicht deren Inhalte. Dieses Vorgehen ist beim TAWS sinnvoll, da die Dateneingangs- und die Datenausgangsfunktion nachtr\u00e4glich f\u00fcr den Zugriff auf den gemeinsamen Speicher mit dem Ethernet Task umgeschrieben werden sollen.<\/p>\n Es folgt die automatische Generierung des parallelen C-Codes aus dem sequentiellen C-Code. Wie zuvor beschrieben, soll dieser nur f\u00fcr zwei Kerne als Application Task parallelisiert werden. Dazu wird f\u00fcr den ersten Kern ein sogenanntes „Core Constraint“ gesetzt, das diesen Kern von der Parallelisierung ausschlie\u00dft. Dieser Kern steht somit exklusiv f\u00fcr die asynchrone Kommunikation mit dem Simulator zur Verf\u00fcgung. Das Resultat der Parallelisierung sind dedizierte Funktionen f\u00fcr die jeweiligen Kerne und die Funktion app_task(), die diese in Abh\u00e4ngigkeit des ermittelten Kernes aufruft.<\/p>\n Die Funktion main_p0() des Application Tasks f\u00fcr den ersten Kern ist wie erwartet leer. Main_p1() und main_p2() enthalten die jeweiligen Anteile der parallelisierten TAWS-Logik, Aufrufe der Datenein- und -ausgangsfunktion und zus\u00e4tzliche API-Aufrufe, welche zum Datenaustausch untereinander und zur Sicherstellung der Synchronit\u00e4t genutzt werden. Der Ethernet Task ist im Gegensatz zum Application Task kein Resultat der Parallelisierung, sondern wird manuell f\u00fcr die Ausf\u00fchrung auf dem ersten Kern implementiert.<\/p>\n Im ePS l\u00e4sst sich das Ergebnis der automatischen Parallelisierung im „Multicore Schedule View“ mit dedizierten Spuren f\u00fcr jeden Kern grafisch nachvollziehen. Durch Klicken auf Codeelemente werden deren Beziehungen zu anderen Codeelementen mit Pfeilverbindungen angedeutet. In Abbildung 6 (s.\u00a0PDF<\/a>)\u00a0 kann beispielsweise Kern 1 (Tricore#1 in Abb. 6) die For-Schleife „For16“ erst berechnen, wenn Kern 2 (Tricore#2 in Abb. 6) das Codeelement „BB236“ beendet hat.<\/p>\n Die vom ePS prognostizierte WCET des parallelisierten TAWS wird im Vergleich zum sequentiellen Code um 25% verringert. Der systemspezifische hohe zus\u00e4tzliche Kommunikationsaufwand und damit teilweise verbundene Wartezeiten einzelner Kerne begr\u00fcnden die Abweichung von der theoretisch maximal m\u00f6glichen Laufzeitreduzierung um 50% f\u00fcr zwei Kerne.<\/p>\n In diesem Paper wird ein modellbasierter Entwurf f\u00fcr Multicore-Prozessoren vorgestellt. Als Fallstudie wurde ein Terrain Awareness and Warning System (TAWS) nach Vorbild des Enhanced Ground Proximity Warning Systems (EGPWS) modellbasiert in Xcos entwickelt. Das Xcos-Modell wurde zun\u00e4chst in Scilab-Code \u00fcberf\u00fchrt. Mit Hilfe der interaktiven Parallelisierungsl\u00f6sung emmtrix Parallel Studio (ePS) wurde der Scilab-Code zun\u00e4chst in sequentiellen C-Code transformiert und danach f\u00fcr die Ausf\u00fchrung auf einem Infineon Aurix TC297B Mikrocontroller parallelisiert und optimiert. Die ersten Ergebnisse zeigen durch die Parallelisierung bereits eine Reduzierung der Laufzeit von 25%. F\u00fcr die Zukunft ist bez\u00fcglich des ePS eine Optimierung der Kommunikation geplant sowie eine Portierung auf die n\u00e4chste Generation von Infineon Aurix mit sechs Kernen angedacht.<\/p>\n [1] Prisaznuk, P. J. 1992. \u201cIntegrated modular avionics\u201d. In\u00a0Proceedings of the IEEE 1992 National Aerospace and Electronics Conference<\/em>, Dayton, OH.<\/p>\n [2] Watkins, C. B. and R. Walter. 2007. \u201cTransitioning from federated avionics architectures to integrated modular avionics\u201d. In\u00a0IEEE\/AIAA 26th Digital Avionics Systems Conference<\/em>, Dallas, TX.<\/p>\n [3] Nowotsch, J. and M. Paulitsch. 2012. \u201cLeveraging multi-core computing architectures in avionics\u201d. In\u00a09th European Dependable Computing Conference (EDCC)<\/em>, Sibiu, Romania.<\/p>\n [4] Karray, H., M. Paulitsch, B. Koppenh\u00f6fer, and D. Geiger. 2013. \u201cDesign and implementation of a degraded vision landing aid application on a multicore processor architecture for safety-critical application\u201d. In\u00a016th International Symposium on Object\/Component\/Service-Oriented Real-Time Distributed Computing (ISORC)<\/em>, Paderborn, Germany.<\/p>\n [5] Koppenh\u00f6fer, B., and D. Geiger. 2016. \u201cEMC2 Use Case:Hybrid Avionics Integrated Architecture Demonstrator\u201d. In\u00a0HiPEAC, Workshop EMC\u00b2<\/em>, Prague, Czech Republic.<\/p>\n [6] Agrou, H., P. Sainrat, M. Gatti, and P. Toillon. 2012. \u201cMastering the behavior of multi-core systems to match avionics requirements\u201d. In\u00a0AIAA 31st Digital Avionics Systems Conference (DASC)<\/em>, Williamsburg, VA.<\/p>\n [7] L\u00f6fwenmark, A., and S. Nadjm-Tehrani. 2014. \u201cChallenges in future avionic systems on multi-core platforms\u201d. In\u00a0International Symposium on Software Reliability Engineering Workshops (ISSREW)<\/em>, Naples, Italy.<\/p>\n [8] Sander, O., F. Bapp, L. Dieudonne, T. Sandmann, and J. Becker. 2017. \u201cThe promised future of multi-core processors in avionics systems\u201d.\u00a0CEAS Aeronautical Journal<\/em>\u00a0vol.8, no. 1, pp. 143-155<\/p>\n [9] Bapp, F., and J.Becker. 2018. \u201cAdvances in Avionic Platforms: Multi-Core Systems\u201d. In\u00a0Advances in Aeronautical Informatics: Towards Flight 4.0<\/em>, edited by U.Durak, J.Becker, S.Hartmann and N.Voros, Springer.<\/p>\n [10] Derrien, S., I. Puaut, P. Alefragis, M. Bednara, H. Bucher, C. David, Y. Debray, U. Durak, I. Fassi, C. Ferdinand, and D. Hardy. 2017. \u201cWCET-aware parallelization of model-based applications for multi-cores: The ARGO approach\u201d. In\u00a02017 Design, Automation & Test in Europe Conference & Exhibition (DATE)<\/em>, Lausanne, Switzerland.<\/p>\n [11] Durak, U., D. M\u00fcller, J. Becker, N. Voros, P. Alefragis, T. Stripf, P.A. Agnel, G. Rauwerda and K. Sunesen. 2016. \u201cModel-based development of Enhanced Ground Proximity Warning System for heterogeneous multi-core architectures\u201d. In\u00a0ASIM 2016<\/em>, Dresden, Germany.<\/p>\n [12] Gasevic, D., D. Djuric, and V. Devedic. 2009.\u00a0Model driven engineering and ontology development.<\/em>\u00a0Springer Science & Business Media.<\/p>\n [13] St\u00fcrmer, I., M. Conrad, I Fey and H D\u00f6rr. 2006. \u201cExperiences with model and autocode reviews in model-based software development\u201d. In\u00a0Proceedings of the 2006 International Workshop on Software Engineering for Automotive Systems<\/em>, Shanghai, China.<\/p>\n [14] Campbell, S.L., J.P. Chancelier, and R. Nikoukhah. 2010.\u00a0Modeling and Simulation in Scilab\/Scicos with ScicosLab 4.4<\/em>. Springer New York.<\/p>\n [15] Floch, A., T. Yuki, A. El-Moussawi, A. Morvan, K. Martin, M. Naullet, M. Alle, L. L’Hours, N. Simon, S. Derrien, and F. Charot. 2013. \u201cGeCoS: A framework for prototyping custom hardware design flows\u201d. In\u00a0IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM)<\/em>, Eindhoven, Netherlands.<\/p>\n [16] Girkar, M. and C.D. Polychronopoulos. 1994. \u201cThe hierarchical task graph as a universal intermediate representation\u201d.\u00a0International Journal of Parallel Programming<\/em>, vol.22, no.5, pp.519-551.<\/p>\n [17] Federal Aviation Administration. 2000. \u201cInstallation of Terrain Awareness and Warning Systems (TAWS) Approved for Part 23 Airplanes\u201d, Advisory Circular 23-18,\u00a0 Washington, D.C.<\/p>\n [18] ACSS. 2018. \u201cT3CAS<\/a>\u201d. Letzter Zugriff am 16.08.2018.<\/p>\n [19] Universal Avionics. 2018. \u201cTAWS | Terrain Awareness and Warning System\u201d. https:\/\/www.uasc.com\/home\/shop\/avionics\/taws. Letzter Zugriff am 16.08.2018.<\/p>\n [20] Smith, D.\u00a0 2005. \u201cTraffic Alert Collision Avoidance Systems\u2014TCAS Buyer\u2019s Guide\u201d.\u00a0Pilot\u2019s Guide to Avionics 2005<\/em>, pp. 34-41.<\/p>\n [21] Honeywell. 2018. \u201cTerrain & Traffic Awareness<\/a>\u201d. https:\/\/aerospace.honeywell.com\/en\/product-listing\/terrain-and-traffic-awareness. Letzter Zugriff am 16.08.2018.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nDer modellbasierte Design-Workflow von ARGO<\/h2>\n
Terrain Awareness and Warning Systems (TAWS)<\/h2>\n
\n
Modellierung des TAWS in Xcos<\/h2>\n
Automatische Parallelisierung des TAWS<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h3>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n