EN 
DE Automatic parallelization of a model-based design
Authors: Peer Ulbig, Umut Durak, David Müller, German Aerospace Center (DLR), Oliver Oey, Timo Stripf, Michael Rückauer, emmtrix Technologies GmbH
Contribution – Embedded Software Engineering Congress 2018
The aerospace sector demands new methods and approaches for cost-effectively increasing application performance while maintaining safety and programmability. A promising approach is the use of multicore architectures. However, to fully exploit their potential, in addition to the necessary certification, there is also a need for programming tools and processes. Support for model-based design is crucial for simplifying system modeling, verification, and validation of design decisions. This paper therefore presents a model-based design for multicore architectures. As a case study, a Terrain Awareness and Warning System (TAWS) is developed using a model-based approach and parallelized for execution on an Infineon Aurix TC297B microcontroller using the interactive parallelization solution emmtrix Parallel Studio (ePS).
The increasing importance of cyber components in aircraft, such as avionics systems, sensors, actuators, and data buses, has led to a paradigm shift from distributed onboard system architectures to Integrated Modular Avionics (IMA) [1]. Instead of decentralized and dedicated computing units, IMA is characterized by multiple applications sharing the same computing unit [2]. Higher throughput requirements have become increasingly important, and multicore and multiprocessor systems have also become significant.
Many efforts to parallelize the development of flight systems with multicore architectures have focused on applicability with regard to safety constraints in the field of avionics [3, 4, 5, 6, 7, 8, 9]. Segregation, integrity, computability, certification costs, and performance are key challenges that need to be addressed [8]. Furthermore, an effective and efficient development methodology for avionics applications with multicore architectures remains a research question. In the aerospace sector, complex toolchains and programming processes still need to be developed to fully exploit the potential of these next-generation heterogeneous parallel platforms.
ARGO (WCET-Aware Parallelization of Model-Based Applications for Heterogeneous Parallel Systems) is a project funded under the European Union’s Horizon 2020 research and innovation program. It focuses on code generation for worst-case execution time (WCET)-aware parallelization of model-based applications for multicore systems [10, 11].
This paper presents a case study in which a Terrain Awareness and Warning System (TAWS) was developed using a model-based approach and optimized for execution on the Infineon AURIX using the interactive parallelization solution emmtrix Parallel Studio (ePS). A simulation of the Enhanced Ground Proximity Warning System (EGPWS) was chosen as a specific example.
ARGO's model-based design workflow
Model-based development promotes the creation of models and the generation of executable software through successive model-to-model and model-to-text transformations [12]. Model-based design is a variant of model-based development. It is characterized by the seamless use of executable and graphical, data-flow-oriented block diagram models and state machines for system specification, design, and implementation. Model-based design and simulation tools such as Scilab/Xcos or MATLAB/Simulink are used in this process [13].
The model-based ARGO workflow (Fig. 1, p. PDFThe process begins with controller modeling, where the application models are implemented in the Scilab/Xcos environment. Scilab/Xcos is a model-based, open-source design and simulation environment [14]. The Scilab scripting language can be used in individual graphical blocks of the model, enabling a combined graphical and imperative description. The target architecture is also defined at the outset using an architecture description language (ADL).
In the first step (frontend tools), model-to-text transformation is used to generate platform-independent, sequential C source code from the Scilab/Xcos models. Based on this, the GeCoS Source-to-Source Transformation Framework [15] performs program transformations aimed at, for example, parallelization or optimization. For this purpose, the C program is first transformed into a hierarchical task graph (HTG) [16].
The HTG contains information about dependencies and execution times. For example, two tasks are dependent on each other if they access the same data. During the scheduling phase, the HTG is mapped to the individual cores of the multicore target platform. This determines which tasks are executed on which core and in what order. If two tasks are dependent on each other, they must be executed sequentially in the schedule. This is described in the "Data Management, Synchronization and Code Generation" step from Figure 1 (see...). PDFThe results of the scheduling are used to generate an explicit parallel program representation with communication, synchronization, and address mappings. The WCET step at the code and system levels computes the multi-core WCET for the target architecture. A parallel C program is generated as a result.
Terrain Awareness and Warning Systems (TAWS)
Controlled Flight Into Terrain (CFIT) was responsible for many fatalities in civil aviation until the installation of Terrain Awareness and Warning Systems (TAWS) was mandated by many aviation authorities (see Federal Aviation Administration, [17]). Several TAWS options are available on the market, providing a range of features to mitigate the risk of CFIT. T3CAS from ACSS [18] and TAWS from Universal Avionics [19] are two examples. A brief comparison of these systems can be found in [20]. The Enhanced Ground Proximity Warning System (EGPWS) is another example of a TAWS, developed by Honeywell [21], and serves as a model in the following sections.
The core function of the EGPWS is to generate visual and audible warnings between 30 ft and 2450 ft above ground (AGL) to prevent CFIT. These warnings are divided into five modes:
- Mode 1 Dangerous sinking speed: Warnings of excessive descent speed in all flight phases.
- Mode 2 Dangerous ground approach rate: Warnings to protect the aircraft from impact with the ground when the terrain rises rapidly relative to the aircraft.
- Mode 3 Altitude loss after takeoff: Warnings are issued when a significant loss of altitude is detected after takeoff or during a go-around maneuver at low altitude.
- Mode 4 Unsafe terrain: Warnings are issued if there is insufficient ground clearance with regard to flight phase, aircraft configuration, and speed.
- Mode 5 Deviation under glide path: Warnings are issued if the aircraft flies too far below the glide path during an instrument landing.
Figure 2 (see. PDFThe diagram illustrates the first mode of the EGPWS. The three aircraft are at the same altitude of approximately 2,000 ft, but have different rates of descent, as shown by their position and orientation in the diagram. While the green aircraft is in a safe flying condition, the rate of descent of the orange aircraft triggers a warning. The red aircraft is descending far too quickly relative to its low altitude and requires immediate pilot intervention, resulting in a more urgent warning.
In addition to the five modes mentioned, the EGPWS offers several advanced functions, such as "Terrain Look Ahead Alerting" and "Terrain Alerting and Display," which are based on a terrain database. With Terrain Look Ahead Alerting, the system uses the terrain database to determine whether a collision with terrain is imminent, up to a distance equivalent to 60 seconds of flight time at the current flight speed. In such a case, the system would issue a warning. If a collision is likely to occur within the next 30 seconds of flight time, the system issues a more intense warning. These relationships are illustrated in Figure 3 (see below). PDF).
Modeling the TAWS in Xcos
Following ARGO's model-based design workflow, the five basic modes of the EGPWS were modeled in Scilab/Xcos. Figure 4 (see below). PDF) shows, as an example, the simulation of EGPWS mode 1 (Fig. 2) in the Scilab/Xcos model.
Terrain Look Ahead Alerting and Terrain Alerting and Display were also implemented as Scilab scripts.
Automatic parallelization of TAWS
The parallelization of the TAWS, modeled after the EGPWS, is being carried out with the overarching goal of enabling the system to subsequently communicate with the Air Vehicle Simulator (AVES) of the DLR Braunschweig via various methods for testing purposes. Initially, a processor-in-the-loop test series is planned, in which the data buses typically used for the EGPWS, such as ARINC 429, will be replaced by a single Ethernet connection to the simulator.
The target system for the processor-in-the-loop test series is the Aurix TC297 Starter Kit, which features an Aurix TC297B microcontroller with three cores and an integrated Ethernet interface (MAC). The physical layer (PHY) is integrated on the Starter Kit. Furthermore, the real-time operating system FreeRTOS is used in a version ported to the target system. Asynchronous communication with the flight simulator is performed on one core as an Ethernet task (eth_task). The hardware-independent parallelized logic of the EGPWS is executed on the two remaining cores as an application task (app_task).
Theoretically, all cores execute both tasks; however, depending on the specific core, one of the two tasks releases the corresponding CPU by immediately going to sleep. Data exchange between the tasks occurs via a shared memory area (shared memory) in the Local Memory Unit (LMU) of the Aurix TC297B, protected by a mutex. In this way, the physical interfaces for the TAWS logic are abstracted through memory accesses. Figure 5 (see below). PDF) illustrates these approaches.
The starting point of the ARGO workflow for parallelizing the TAWS is Scilab. Here, the TAWS Xcos model is translated into Scilab code. In addition to the TAWS step function, data input and output functions, as well as a scenario file, are generated. This scenario file initializes input, output, and state variables and calls the aforementioned functions sequentially. The resulting Scilab scenario then serves as the basis for the actual parallelization using the ePS. A new project with the target hardware Aurix TC297 Starter Kit and the input programming language Scilab is created in the ePS, and the previously generated Scilab code is integrated.
In the next step, sequential C code is generated from the Scilab code. This step significantly influences the subsequently generated parallel C code. Code optimizations regarding the value ranges of the input, output, and state variables in the specific Scilab scenario are suppressed. This ensures that the C code correctly reproduces the TAWS step function for all possible combinations and sequences of input values, regardless of the chosen Scilab scenario. Furthermore, the data input and data output functions are moved to separate source code. This way, only their function calls are considered during subsequent parallelization, unlike the TAWS step function itself, which contains the data itself. This approach is useful for TAWS because the data input and data output functions will later be rewritten for accessing the shared memory using the Ethernet Task.
The automatic generation of parallel C code from the sequential C code follows. As previously described, this code is intended to be parallelized as an application task for only two cores. To achieve this, a "core constraint" is set for the first core, excluding it from parallelization. This core is thus exclusively available for asynchronous communication with the simulator. The result of the parallelization is dedicated functions for the respective cores and the `app_task()` function, which calls these functions depending on the identified core.
The `main_p0()` function of the Application Task for the first core is empty, as expected. `main_p1()` and `main_p2()` contain the respective portions of the parallelized TAWS logic, calls to the data input and output functions, and additional API calls used for data exchange and to ensure synchronization. Unlike the Application Task, the Ethernet Task is not a result of parallelization but is manually implemented for execution on the first core.
In ePS, the result of automatic parallelization can be graphically visualized in the "Multicore Schedule View" with dedicated tracks for each core. Clicking on code elements indicates their relationships to other code elements with arrow connections. In Figure 6 (see below). PDFFor example, core 1 (Tricore#1 in Fig. 6) can only calculate the for loop „For16“ when core 2 (Tricore#2 in Fig. 6) has finished the code element „BB236“.
The WCET predicted by ePS for the parallelized TAWS is reduced by 25% compared to the sequential code. The system-specific high additional communication overhead and the associated waiting times of individual cores explain the deviation from the theoretically maximum possible runtime reduction of 50% for two cores.
Summary
This paper presents a model-based design for multicore processors. As a case study, a Terrain Awareness and Warning System (TAWS), modeled after the Enhanced Ground Proximity Warning System (EGPWS), was developed using a model-based approach in Xcos. The Xcos model was first converted into Scilab code. Using the interactive parallelization solution emmtrix Parallel Studio (ePS), the Scilab code was first transformed into sequential C code and then parallelized and optimized for execution on an Infineon Aurix TC297B microcontroller. Initial results show a runtime reduction of 25% due to parallelization. Future plans include optimizing communication with ePS and porting to the next generation of Infineon Aurix with six cores.
Bibliography and list of sources
[1] Prisaznuk, PJ 1992. “Integrated modular avionics”. In Proceedings of the IEEE 1992 National Aerospace and Electronics Conference, Dayton, OH.
[2] Watkins, CB and R. Walter. 2007. “Transitioning from federated avionics architectures to integrated modular avionics”. In IEEE/AIAA 26th Digital Avionics Systems Conference, Dallas, TX.
[3] Nowotsch, J. and M. Paulitsch. 2012. “Leveraging multi-core computing architectures in avionics”. In 9th European Dependable Computing Conference (EDCC), Sibiu, Romania.
[4] Karray, H., M. Paulitsch, B. Koppenhöfer, and D. Geiger. 2013. “Design and implementation of a degraded vision landing aid application on a multicore processor architecture for safety-critical application”. In 16th International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing (ISORC), Paderborn, Germany.
[5] Koppenhöfer, B., and D. Geiger. 2016. “EMC2 Use Case:Hybrid Avionics Integrated Architecture Demonstrator”. In HiPEAC, Workshop EMC², Prague, Czech Republic.
[6] Agrou, H., P. Sainrat, M. Gatti, and P. Toillon. 2012. “Mastering the behavior of multi-core systems to match avionics requirements”. In AIAA 31st Digital Avionics Systems Conference (DASC), Williamsburg, VA.
[7] Löfwenmark, A., and S. Nadjm-Tehrani. 2014. “Challenges in future avionic systems on multi-core platforms”. In International Symposium on Software Reliability Engineering Workshops (ISSREW), Naples, Italy.
[8] Sander, O., F. Bapp, L. Dieudonne, T. Sandmann, and J. Becker. 2017. “The promised future of multi-core processors in avionics systems”. CEAS Aeronautical Journal vol.8, no. 1, pp. 143-155
[9] Bapp, F., and J. Becker. 2018. “Advances in Avionic Platforms: Multi-Core Systems”. In Advances in Aeronautical Informatics: Towards Flight 4.0, edited by U.Durak, J.Becker, S.Hartmann and N.Voros, Springer.
[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. “WCET-aware parallelization of model-based applications for multi-cores: The ARGO approach”. In 2017 Design, Automation & Test in Europe Conference & Exhibition (DATE), Lausanne, Switzerland.
[11] Durak, U., D. Müller, J. Becker, N. Voros, P. Alefragis, T. Stripf, PA Agnel, G. Rauwerda and K. Sunesen. 2016. “Model-based development of Enhanced Ground Proximity Warning System for heterogeneous multi-core architectures”. In ASIM 2016, Dresden, Germany.
[12] Gasevic, D., D. Djuric, and V. Devedic. 2009. Model driven engineering and ontology development. Springer Science & Business Media.
[13] Sturmer, I., M. Conrad, I Fey and H Dörr. 2006. “Experiences with model and autocode reviews in model-based software development”. In Proceedings of the 2006 International Workshop on Software Engineering for Automotive Systems, Shanghai, China.
[14] Campbell, SL, JP Chancelier, and R. Nikoukhah. 2010. Modeling and Simulation in Scilab/Scicos with ScicosLab 4.4. Springer New York.
[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. “GeCoS: A framework for prototyping custom hardware design flows”. In IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM), Eindhoven, Netherlands.
[16] Girkar, M. and CD Polychronopoulos. 1994. “The hierarchical task graph as a universal intermediate representation”. International Journal of Parallel Programming, vol.22, no.5, pp.519-551.
[17] Federal Aviation Administration. 2000. “Installation of Terrain Awareness and Warning Systems (TAWS) Approved for Part 23 Airplanes,” Advisory Circular 23-18, Washington, DC.
[18] ACSS. 2018. “T3CAS”Last accessed on August 16, 2018.
[19] Universal Avionics. 2018. “TAWS | Terrain Awareness and Warning System”. https://www.uasc.com/home/shop/avionics/taws. Last accessed on 16 August 2018.
[20] Smith, D. 2005. “Traffic Alert Collision Avoidance Systems—TCAS Buyer's Guide.”. Pilot's Guide to Avionics 2005, pp. 34-41.
[21] Honeywell. 2018. “Terrain & Traffic Awareness”https://aerospace.honeywell.com/en/product-listing/terrain-and-traffic-awareness. Last accessed on August 16, 2018.
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
