- Email: [email protected]
An Autopilot Testbed for IMA (Integrated Modular Avionics) Architectures*
19th IFAC Symposium on Automatic Control in Aerospace September 2-6, 2013. Würzburg, Germany
An Autopilot Testbed for IMA (Integrated Modular Avionics) Architectures ? H. Usach-Molina ∗ B. Fons-Albert ∗∗ J. Vila-Carb´ o ∗∗∗ A. Crespo-Lorente ∗∗∗∗ ∗
[email protected] [email protected] ∗∗∗ [email protected] ∗∗∗∗ [email protected] Instituto de Autom´ atica e Inform´ atica Industrial, Universitat Polit`ecnica de Val`encia, Valencia, Spain ∗∗
Abstract: This paper presents a testbed for designing autopilots that allows to easily derive implementations from a design model that can be analyzed, tested, and deployed on an IMA (Integrated Modular Avionics) architecture. Autopilots are designed using the Model Based Design (MBD) methodology. The paper reviews all the software development phases of the autopilot using this methodology: modeling, design, verification and deployment. Special emphasis is put on the deployment phase and the implications for porting a design to an IMA architecture based on XtratuM, a hypervisor developed in our research group. The main requirement of autopilot design has been flexibility to test different guidance and control strategies. In this sense, we provide a modular design template for efficiently designing and testing other guidance techniques that clearly separates position estimation, guidance and control modules, and allows several flight modes. Keywords: Integrated Modular Avionics, Model Based Design, Aircraft Control, Guidance Systems, Avionics. 1. INTRODUCTION The number of applications for avionics is increasing as fast as automatic control develops new procedures and functionalities. These applications must satisfy rigorous development and verification standards. Activities to satisfy these objectives can be time-consuming and expensive, specially those related to the design, coding, and integration processes. For this reason, it is essential to carefully consider the methods, languages, standards, and tools to be used during the development phase. This paper presents a testbed where a suite of methods and tools have been used to produce an autopilot design. The main paper contribution is presenting a framework for advanced aircraft control and presenting the software technologies for designing and implementing it. Two important phases have been considered in the autopilot development: the design phase and the deployment phase. The main goals of the design phase are to produce a cleanly structured software design to support different guidance and control strategies, to be able to produce an aircraft model and optimize the control parameters for this model, and to allow intensive testing of the model and control strategies. This stage is addressed using Model? This research has been financed by projects HI-PartES (High Integrity Partitioned Embedded Systems) of Spanish Ministerio de Ciencia e Innovaci´ on (TIN2011-28567-C03-03, COBAMI DPI201128507-C02-02) and Multipartes (Multi-cores Partitioning for Trusted Embedded Systems). ICT 7th Framework Programme EU Programme. 2011-14.
978-3-902823-46-5/2013 © IFAC
435
Based Design in Simulink. The benefits of this design methodology include easy modeling of complex systems (including non-linear systems), automatic coding generation and availability of tools to provide modeling standards compliance checking, and to document models. These tools make easier the processes of software deployment and software certification. The second important phase of the autopilot development is to deploy it for a target system based on XtratuM (see Masmano et al. (2009)). This is a hypervisor for real-time embedded systems that is based to a large extent on the IMA (Integrated Modular Avionics) concept standardized by ARINC 653 (Prisaznuk (2008)). This process basically requires solving the problems of application partitioning, real-time tasking, and application interfacing of Simulink applications. The proposed solution makes use of Simulink Referenced Models and the Embedded Coder which needs to be tuned for the target system. Using this framework we have designed an autopilot that allows implementing different guidance and control strategies. These strategies are specific for each flight phase, so the design allows several flight modes. At present time we have implemented two of them: en-route and approximation. Software designs, and guidance and control strategies are intensively tested using the system model and a flight simulator. They exhibit good performance and provide wind compensation as shown in the results shown in the paper. Once the model has been tested, it is deployed to the XtratuM platform and verified. 10.3182/20130902-5-DE-2040.00076
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
The paper is organized as follows: Section 2 introduces the design methodology for the autopilot, and the following sections introduce each phase of this methodology: modeling and design (Section 3), verification (Section 4) and Section 5 describes the deployment process to an IMA architecture (XtratuM). Finally Section 6 outlines some concluding remarks. 2. DESIGN METHODOLOGY Software systems deployed in safety-critical applications in aerospace must satisfy rigorous development and verification standards. One of the most widely used of these standards is DO-178B that deals with the safety level of airborne systems. Because an autopilot controls the aircraft, it usually must meet the highest level of safety. Therefore, it is very important to consider the autopilots design from the point of view of the software methodologies. DO-178B does not specify any particular software development technology, but some technologies like ModelBased Design (MBD) can help satisfying DO-178B objectives through the use of proper tools. The autopilot testbed has been developed following the steps of the MBD methodology using Simulink:
In our experience, the main advantages of the MBD methodology have been to easily relate models to software architectures, to automatically produce error-free code, to check functional requirements at very early stages of design, and to check real-time requirements. 3. AUTOPILOT MODELING AND DESIGN In order to meet the functional requirements of the autopilot with a flexible and modular design, the software architecture shown in Fig. 1 is proposed. In general, each module corresponds to a Simulink model. Additionally, each module has part which is executed off-line in the pre-flight phase and a part which is executed on-line in the flight phase. Next, we describe these modules in some more detail.
• System modeling. A mathematical model is created by connecting blocks that represent the physical elements that the plane consists of. The aircraft dynamic model is done using a state space representation. • Design and analysis of the guidance system. Guidance based on waypoints for all the phases of flight with wind compensation. • Design and analysis of the control system. Lateral and longitudinal control using Linear Quadratic Regulator (LQR) or Model Predictive Control (MPC). • Real-time simulation. This is performed by connecting the autopilot to a flight simulator. • Deployment. Automatic generation of C code from Simulink. Code generation for an ARINC 653 system based on XtratuM. The software development process of DO-178B roughly consists on the following steps: a) Defining and verifying software requirements, b) Defining the software design and architecture, c) Verifying the software design and the source code, and d) Generating and verifying the executable object code. The design workflow of DO-178B can be easily mapped to the steps of the MBD methodology. The first step in software design is defining software requirements. Requirements can be roughly classified into functional, performance and operational requirements. Basic functional requirements for autopilots are quite well known and we have not placed any special one. Regarding performance, the only noticeable requirements is that air wind compensation is a key feature and we use RNP (Required Navigation Performance) requirements of Eurocontrol as an upper bound for accuracy. Operational requirements have been much more important in our design. The autopilot presented in this paper intends to be a testbed for autopilot designs so the main requirement has been flexibility and modular design to test different guidance and control strategies. Another operational requirement is related to the execution platform: targeting at ARINC-653 is considered another key aspect in our design. 436
Fig. 1. Autopilot diagram. Navigation, guidance and control modules.
3.1 Navigation module The navigation module establishes the aircraft state. That comprises measuring or estimating the current position, the attitude, the angular velocities, and airspeed. This is fully performed on-line in each iteration of the control loop. The off-line part of this module only affects some initializations. 3.2 Guidance module The guidance module manages the flight path according to the aircraft state and a flight plan defined by waypoints, whose feasibility is analyzed off-line. Once in-flight, the autopilot calculates the target value of the variables to be controlled and establishes the right autopilot mode. The software design of this module has been fully derived from a Simulink model which enables automatic code generation and simulation.
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Flight Plan definition The flight plan consists of a sequence of waypoints defined by a list of attributes: name, coordinates, airspeed and phase of flight. Using these fields, the onboard computer calculates the distance and course between two consecutive waypoints (desired track DTK), and the distance at which each waypoint is considered to be reached (fly-by property). Guidance procedures and target calculation The control module switches between several autopilot modes along the different phases of flight. During climb and cruise, the Vertical Navigation (VNAV) system switches between VPATH HOLD and ALTITUDE HOLD modes, while the Lateral Navigation (LNAV) system can enter HEADING HOLD or TURN (ROLL HOLD) modes depending on the heading error and the guidance procedure. During the approach, another control mode is used: VNAV and LNAV control the vertical and lateral distance to the glide slope (G/S) in a similar way to an ILS system.
linearized model, built in terms of stability derivatives, the vertical and lateral dynamics are independent and can be grouped in two matrix systems, phase of flight-dependent, using an implicit state space representation. Trim calculation. The equations of motion are linearized with respect to an equilibrium point called trim condition. It is calculated off-line using a numerical algorithm developed in Stevens and Lewis (2003) that requires the non-linear model of the aircraft. Control system design. The design of the control module has been automatically derived from the Simulink model of Fig. 2. The control is decoupled into two independent problems, LNAV and VNAV, and there is a third block which is the throttle control. The throttle control is solved separately (out of the state space representation) because its corresponding linearized terms are not constant (Stevens and Lewis (2003)).
VNAV target calculation: The VNAV algorithm is responsible for setting the targets which in this case are the altitude of the next waypoint. In addition, during climbs or descents between different flight levels, the onboard computer generates a reference value for the vertical flight path angle as a function of the current altitude error. LNAV target calculation: The LNAV algorithm controls the lateral path using different strategies depending on the autopilot mode or phase flight. These strategies differ in the way they manage the cross-track error. The first strategy is based on setting the heading using the wind triangle. The main advantage of this method is its simplicity. However, it requires to make a wind estimation to calculate the wind correction angle (some methods are proposed by Langelaan et al. (2010) and Cho et al. (2006)). The second method is based on an adaptive path-planning algorithm developed in Park (2004) that calculates the required lateral acceleration to drive the aircraft to a reference point over the desired track. This is a powerful method since it does not require a heading control model neither a wind estimation. It can be used to track circles, and also adapt the flight path to correct a lateral deviation. 3.3 Control module Once the guidance module has calculated the target values of the state variables and selected the vertical and lateral navigation modes, the control module calculates the action over the aerodynamic surfaces and the engine thrust needed to lead the aircraft towards the next waypoint. Control adjustment is based on building an aircraft model. The off-line part of this module includes the definition of the aircraft model, the calculus of the trim conditions, and the computation of the control matrices. The on-line part carries out the execution of the control loop that will generate actions for the elevators, ailerons, rudder and throttle. Aircraft model. The selected aircraft model is a Cessna 172-SP, whose non-linear model can be found in Berndt and Peden (2012) while the linear one is developed in Roskam (2001), and both are computed off-line. In the 437
Fig. 2. Autopilot’s control flow. Guidance and control modules in Simulink. Different control approaches can be designed and tested for each Simulink block. Our proposal consists of using the LQR method for the vertical control and the MPC method for the lateral control. The LQR method is designed as a tracking problem. A state integrator is added to the controller system so that the controlled variable reaches the reference value given by the guidance module. Then, the problem is discretized and solved by state feedback. The optimal gain matrix is calculated as described in Ogata (2010) to determine the deflection of the elevators. The lateral control is based on a Model Based Predictive Control (MPC) available in the corresponding Matlab Toolbox. This choice is based on the possibility of handling constraints, so we are able to specify limits for roll rate or slip angle. Inputs in this case are ailerons and rudder deflections while outputs are roll, yaw, roll rate, yaw rate and the slip angle. Finally, the airspeed control is provided by an independent PD controller over the throttle position δt , developed in Allerton (2009).
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
3.4 Interface module The interface module connects the autopilot to the controlled system through a series of communication channels, which are set up off-line. Its implementation is systemdependent: there is a version for the different hardware platforms, and also a special version for the flight simulator, which uses User Datagram Protocol (UDP) communication. The interface module hides the complexity and specific details of each system.
the aircraft performs the flare maneuver engaging the VPATH HOLD mode to reduce the vertical flight path angle before landing. The control performance of the control modes used for navigating the G/S yield an error less than ±1 m in both vertical and lateral axes, thus fulfilling the RNP APCH/RNP 0.1 requirements for GPS approaches. Fig. 4 shows the difference in the vertical path during the landing with both wind conditions.
4. AUTOPILOT VERIFICATION The verification of the software design has been done through a series of real-time tests using a flight simulator. Although all aircraft systems must be finally validated through flight tests, simulation allows to verify important properties so only minor details need to be improved by flight tests. This section presents two of these tests: the first one is aimed to validate the LNAV system design, while the second one does the same for the VNAV. Both tests are performed under two different conditions: a) no wind, and b) wind blowing at 7.7 m/s (15 kt) from 20 ◦ . RNP requirements are used as an upper bound for accuracy. The first test analyzes the LNAV performance during the cruise phase. The route is a square of 12 × 12 km with four waypoints at the corners which is navigated with the ROLL HOLD mode. This mode is specially suited for small UAVs, but it can be tested with bigger planes by tuning the design parameters. The results of the test are shown in Fig. 3. In all wind conditions the aircraft remains inside a margin of ±500 m during the turns, and ±25 m in the legs, thus comfortably meeting the RNP 5 requirement of Eurocontrol for RNAV continental en-route flights.
Fig. 4. Landing test. Vertical path. Fig. 5 shows that the control mode used for landing provides a lateral deviation accurate enough to allow a landing in cross wind conditions. However, we noticed that the autopilot mode is very sensitive to initial errors, so the aircraft must be aiming the runway before engaging it.
Fig. 5. Landing test. Lateral deviation. 5. AUTOPILOT DEPLOYMENT TO XTRATUM
Fig. 3. Lateral path test under different wind conditions. The second test is a GPS landing at runway 30 of Valencia airport (ICAO: LEVC). The simulation starts in the Intermediate-Fix (IF) at an altitude of 670 m (2200 ft) over MSL, which remains constants until the aircraft intercepts the G/S in the Final Apporach Point (FAP). Then, a glide path of −3 ◦ leads the aircraft towards the threshold of the runway. Once on the FAP, the APProach mode is selected: the airspeed is maintained at 41.1 m/s (80 kt), and the flaps are automatically deflected. Finally, 438
The last step of the MBD methodology consists in the deployment of the autopilot to the target platform. This means to convert the Simulink design into a set of software units to be executed on an IMA architecture called XtratuM, developed in our research group. This section briefly introduces the IMA principles and how the Simulink design has been ported to XtratuM. 5.1 XtratuM and the IMA Concept XtratuM is a hypervisor for real-time embedded systems that is based to a large extent on the IMA concept. The IMA architecture is essentially an integrated architecture based on the partitioning concept. This concept emerges
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
for protection and separation among applications from the spatial and temporal point of views. XtratuM virtualises the essential hardware devices (memory, timers and interrupts) to execute concurrently several operating systems. One of these guest operating system (OS) is LithOS that implements the process concept presented in the ARINC 653 standard which is not present in XtratuM. Another way of implementing the concept process is using Partikle, a real-time OS that implements POSIX threads. The services provided by XtratuM either through LithOS or Partikle are the ones defined by the ARINC 653 specification and are summarized next. Partition management. Partitions are execution environments with independent memory spaces and strictly protected execution time. Partitions are scheduled according to a cyclic scheduler which is specified in the configuration file. Process management. A partition comprises one or more processes that interact dinamically to provide the partition functionality. Processes are the execution unit within a partition of ARINC 653. Time management is the basic module to manage time in the OS and ensures hard real-time requirements are met. Each partition runs for a specified duration, the OS provides time slicing for partition scheduling. Inter-partition communication. This module provides the communication mechanism between two or more partitions via sampling or queuing ports. When using sampling ports, each new instance of a message overwrites the current message. In queuing ports, messages are queued. Channels, ports, maximum message size and maximum number of messages are defined in the partition definition file at system configuration time. Intra-partition communication. This module provides blackboards and buffers for intra-partition communication. Semaphores and events are provided for intrapartition synchronization. Health monitoring. This module implements the mechanism proposed by the ARINC 653 for error reporting and monitoring. 5.2 The porting process Porting a Simulink design to a XtratuM run-time environment requires to solve a number of problems because Simulink does not know about the XtratuM execution platform. The main issues are related to the application partitioning, the communications channels definition, the operating system setting, tasks concurrency, etc. To solve these issues a workflow has been designed which affects the phases of design, code generation and configuration files generation. A brief description is presented next. Design Phase The first stage of the porting process concerns the Simulink design itself. It is related to the partitioning of the application that, in our context, means allocating Simulink blocks to different partitions. The proposed solution is based on the use of Simulink Referenced 439
models. Model referencing is a Simulink feature that allows to include one model into another by referencing it. A Referenced model has an interface that consists of its inputs and outputs ports and its parameter arguments, thus being a usefull abstraction that can be related to XtratuM partitions. In our procedure, Simulink blocks belonging to the same partition are grouped into a same Simulink Referenced Model. Once the application is partitioned, an interpreter is run which is able to identify the partitions (one per each Referenced Model in the top level diagram). But, even more, it is able to identify the communications channels existing between those partitions. Each of these channels is mapped to a XtratuM sampling port. We are using sampling ports because we don’t want the data to be queued, we just want to work with the last available data. In a subsequent process, the user is asked to set OS intended to run in each partition. If the selected supports multitasking and it has been enabled in Simulink Model, the user is asked to enable it in XtratuM application too.
the OS the the
Code Generation The next step of this process is code generation. Simulink Coder generates C/C++ codes from Simulink models, Stateflow charts, and Matlab functions. It is able to generate code for a number of platforms, hardware targets, including POSIX or ARINC 653 compliant systems, which are supported by XtratuM. Even though, there are some important aspects that need to be addressed: • External libraries. Simulink Coder assumes that the standard C libraries are available, and generates calls to their functions or defined constants, waiting for the links to be resolved when compiled. One of the most clear example of this is the necessity of a mathematical library which is not included in XtratuM. In this case, the user may have to provide the missing resources. • Concurrency model. The multitasking model must match the multitasking model of the target partition, so it has to be properly configured. For Linux systems, for example, POSIX is used. In bare applications (those running on XtratuM directly), there is no support for concurrent execution so no multitasking calls to the OS must be generated. • Customize generated code. Some Simulink generated code needs to be tuned to the target partition. This includes the sampling ports creation, reading and writing, the generation of support files with constants definitions, the way POSIX threads and semaphores are used, among others. The way to accomplish this is using the Target Language Compiler (TLC) to customize the generated code. This represents a powerfull tool when it comes to develop a project for a very specific target. We have created some TLC files and modified some of the provided in order to make the generated code runnable on XtratuM. Configuration Files The last step of the porting process is the generation of configuration files. Partitioning an XtratuM application is a matter of configuring two main files:
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
• The first one is a makefile that describes the rules to compile the source code, the partitions and the executable resident software. • The second one is a xml file, named the hypervisor Configuration File (XM CF). It defines the system resources, and how they are allocated to each partition. The main information contained in this file is related to the memory and the processor allocation, the peripherals, the health monitoring, the inter-partition communication, and the tracing. These two files can be almost completely and automatically generated from the information contained in the Simulink models and we have developed a tool to make this task. Regarding the makefile, Simulink generates its own makefile, but it is barely useful because does not describe the compilation rules in the appropriate way. For example, compiling applications for Partikle implies some particular rules. Compiling for XtratuM also implies additional compilation rules (see Masmano et al. (2009)). With respect to the hypervisor Configuration File, some of the fields can be set according to the partitioning definition previously explained. This includes aspects like the number of partitions and their communication ports, or the information about the cyclic plan. But there is also some information regarding memory allocation that must be supplied by the user at a later stage. We are now working on a new tool that allows to easily define all these system resources through a graphical user interface. 5.3 Autopilot Partitioning Following the workflow explained above, the porting of the autopilot to the XtratuM platform has been made. First, the application has been divided into two partitions. This layout does not actually correspond to isolation requirements, but to a need of providing the correct execution environment to each partition. • Partition 1 performs the interfacing either with the simulator or the real system. It has been carefully designed to easily switch from the simulator to a real system. This partition runs on a virtualized Linux environment. Linux is required because the TCP/IP suite is needed for interfacing the controlled system (X-Plane simulator). This partition communicates with the X-Plane simulator via UDP and exchanges the data with the other partition through two XtratuM sampling ports: one outputs the measures, and the other one receives the control actions. • Partition 2 allocates the control and guidance application, and runs on a virtualized Partikle. It reads the state of the aircraft from a sampling port and computes the target waypoint and the control actions according to the aircraft state, the flight plan, and so on. These outputs are sent to Partition 1 through a XtratuM sampling port. Regarding the process management, each partition consists of different concurrent tasks implemented, both in Linux and in Partikle, using POSIX threads. Partition 1 has two tasks in order to interface with the simulator. First task receives measures from X-Plane while second 440
one sends the control actions. Partition 2 also separates its two functions (control and guidance) in separate threads, specially on the basis of their different rates: Control module is executed at a 20 Hz frequency while guidance is only executed at 4 Hz (this maximum execution frequency is limited by the input/output rate of the flight simulator). Finally, aspects related to time management comprises the measurement of the Worst-Case Execution Time (WCET) of the guidance and control tasks that allows to establish the cyclic plan in the Hypervisor Configuration File. After a number of tests, this time can be set in 2 ms. Knowing this, the cyclic plan has a major frame of 50 ms (corresponding to the execution rate of 20 Hz mentioned above) with two time slots, one per partition. The slot for Partition 2 is 2 ms long, while the slot for Partition 1 is 48 ms long. 6. CONCLUSIONS This paper has presented an approach for autopilots design using Model-Based design in Simulink and porting those designs to an ARINC 653 compliant execution platform based on XtratuM. The experience has been fully satisfactory and it has revealed that this design methodology makes feasible to model complex control systems and to easily derive implementations from this design model. This methodology also allows to analyze, test, and deploy the implementations on an IMA architecture. The experience also contributes to validate XtratuM as an execution platform for avionics applications. The paper has also shown how to structure the software design of an advanced guidance and control system for airplanes. REFERENCES Allerton, D. (2009). Principles of flight simulation. John Wiley & Sons, Inc., 1st edition. Berndt, J. and Peden, T. (2012). JSBSim Open source flight dynamics model [online]. http://jsbsim.sourceforge.net. Accessed: 2012-02. Cho, A., Kim, J., Lee, S., and Kee, C. (2006). Wind estimation and airspeed calibration using the UAV with a single-antenna GNSS receiver and airspeed sensor. ION GNSS 19th International Technical Meeting of the Satellite Division. Langelaan, J.W., Alley, N., and Neidhoefer, J. (2010). Wind field estimation for small unmanned aerial vehicles. In Guidance, navigation and control conference. AAIA, Toronto. Masmano, M., Ripoll, I., Crespo, A., and Metge, J. (2009). XtratuM: a hypervisor for safety critical embedded systems. In Proc. of Real-Time Linux Workshop. Ogata, K. (2010). Modern control engineering. Prentice Hall, New Jersey, 5th edition. Prisaznuk, P. (2008). ARINC 653 role in integrated modular avionics (IMA). In Digital Avionics Systems Conference, 2008. DASC 2008. IEEE/AIAA 27th, 1–E. IEEE. Roskam, J. (2001). Airplane flight dynamics and automatic flight controls. Design, Analysis and Reseach Corporation, 3rd edition. Stevens, B.L. and Lewis, F.L. (2003). Aircraft control and simulation. John Wiley & Sons, Inc., 2nd edition.
An Autopilot Testbed for IMA (Integrated Modular Avionics) Architectures ? H. Usach-Molina ∗ B. Fons-Albert ∗∗ J. Vila-Carb´ o ∗∗∗ A. Crespo-Lorente ∗∗∗∗ ∗
[email protected] [email protected] ∗∗∗ [email protected] ∗∗∗∗ [email protected] Instituto de Autom´ atica e Inform´ atica Industrial, Universitat Polit`ecnica de Val`encia, Valencia, Spain ∗∗
Abstract: This paper presents a testbed for designing autopilots that allows to easily derive implementations from a design model that can be analyzed, tested, and deployed on an IMA (Integrated Modular Avionics) architecture. Autopilots are designed using the Model Based Design (MBD) methodology. The paper reviews all the software development phases of the autopilot using this methodology: modeling, design, verification and deployment. Special emphasis is put on the deployment phase and the implications for porting a design to an IMA architecture based on XtratuM, a hypervisor developed in our research group. The main requirement of autopilot design has been flexibility to test different guidance and control strategies. In this sense, we provide a modular design template for efficiently designing and testing other guidance techniques that clearly separates position estimation, guidance and control modules, and allows several flight modes. Keywords: Integrated Modular Avionics, Model Based Design, Aircraft Control, Guidance Systems, Avionics. 1. INTRODUCTION The number of applications for avionics is increasing as fast as automatic control develops new procedures and functionalities. These applications must satisfy rigorous development and verification standards. Activities to satisfy these objectives can be time-consuming and expensive, specially those related to the design, coding, and integration processes. For this reason, it is essential to carefully consider the methods, languages, standards, and tools to be used during the development phase. This paper presents a testbed where a suite of methods and tools have been used to produce an autopilot design. The main paper contribution is presenting a framework for advanced aircraft control and presenting the software technologies for designing and implementing it. Two important phases have been considered in the autopilot development: the design phase and the deployment phase. The main goals of the design phase are to produce a cleanly structured software design to support different guidance and control strategies, to be able to produce an aircraft model and optimize the control parameters for this model, and to allow intensive testing of the model and control strategies. This stage is addressed using Model? This research has been financed by projects HI-PartES (High Integrity Partitioned Embedded Systems) of Spanish Ministerio de Ciencia e Innovaci´ on (TIN2011-28567-C03-03, COBAMI DPI201128507-C02-02) and Multipartes (Multi-cores Partitioning for Trusted Embedded Systems). ICT 7th Framework Programme EU Programme. 2011-14.
978-3-902823-46-5/2013 © IFAC
435
Based Design in Simulink. The benefits of this design methodology include easy modeling of complex systems (including non-linear systems), automatic coding generation and availability of tools to provide modeling standards compliance checking, and to document models. These tools make easier the processes of software deployment and software certification. The second important phase of the autopilot development is to deploy it for a target system based on XtratuM (see Masmano et al. (2009)). This is a hypervisor for real-time embedded systems that is based to a large extent on the IMA (Integrated Modular Avionics) concept standardized by ARINC 653 (Prisaznuk (2008)). This process basically requires solving the problems of application partitioning, real-time tasking, and application interfacing of Simulink applications. The proposed solution makes use of Simulink Referenced Models and the Embedded Coder which needs to be tuned for the target system. Using this framework we have designed an autopilot that allows implementing different guidance and control strategies. These strategies are specific for each flight phase, so the design allows several flight modes. At present time we have implemented two of them: en-route and approximation. Software designs, and guidance and control strategies are intensively tested using the system model and a flight simulator. They exhibit good performance and provide wind compensation as shown in the results shown in the paper. Once the model has been tested, it is deployed to the XtratuM platform and verified. 10.3182/20130902-5-DE-2040.00076
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
The paper is organized as follows: Section 2 introduces the design methodology for the autopilot, and the following sections introduce each phase of this methodology: modeling and design (Section 3), verification (Section 4) and Section 5 describes the deployment process to an IMA architecture (XtratuM). Finally Section 6 outlines some concluding remarks. 2. DESIGN METHODOLOGY Software systems deployed in safety-critical applications in aerospace must satisfy rigorous development and verification standards. One of the most widely used of these standards is DO-178B that deals with the safety level of airborne systems. Because an autopilot controls the aircraft, it usually must meet the highest level of safety. Therefore, it is very important to consider the autopilots design from the point of view of the software methodologies. DO-178B does not specify any particular software development technology, but some technologies like ModelBased Design (MBD) can help satisfying DO-178B objectives through the use of proper tools. The autopilot testbed has been developed following the steps of the MBD methodology using Simulink:
In our experience, the main advantages of the MBD methodology have been to easily relate models to software architectures, to automatically produce error-free code, to check functional requirements at very early stages of design, and to check real-time requirements. 3. AUTOPILOT MODELING AND DESIGN In order to meet the functional requirements of the autopilot with a flexible and modular design, the software architecture shown in Fig. 1 is proposed. In general, each module corresponds to a Simulink model. Additionally, each module has part which is executed off-line in the pre-flight phase and a part which is executed on-line in the flight phase. Next, we describe these modules in some more detail.
• System modeling. A mathematical model is created by connecting blocks that represent the physical elements that the plane consists of. The aircraft dynamic model is done using a state space representation. • Design and analysis of the guidance system. Guidance based on waypoints for all the phases of flight with wind compensation. • Design and analysis of the control system. Lateral and longitudinal control using Linear Quadratic Regulator (LQR) or Model Predictive Control (MPC). • Real-time simulation. This is performed by connecting the autopilot to a flight simulator. • Deployment. Automatic generation of C code from Simulink. Code generation for an ARINC 653 system based on XtratuM. The software development process of DO-178B roughly consists on the following steps: a) Defining and verifying software requirements, b) Defining the software design and architecture, c) Verifying the software design and the source code, and d) Generating and verifying the executable object code. The design workflow of DO-178B can be easily mapped to the steps of the MBD methodology. The first step in software design is defining software requirements. Requirements can be roughly classified into functional, performance and operational requirements. Basic functional requirements for autopilots are quite well known and we have not placed any special one. Regarding performance, the only noticeable requirements is that air wind compensation is a key feature and we use RNP (Required Navigation Performance) requirements of Eurocontrol as an upper bound for accuracy. Operational requirements have been much more important in our design. The autopilot presented in this paper intends to be a testbed for autopilot designs so the main requirement has been flexibility and modular design to test different guidance and control strategies. Another operational requirement is related to the execution platform: targeting at ARINC-653 is considered another key aspect in our design. 436
Fig. 1. Autopilot diagram. Navigation, guidance and control modules.
3.1 Navigation module The navigation module establishes the aircraft state. That comprises measuring or estimating the current position, the attitude, the angular velocities, and airspeed. This is fully performed on-line in each iteration of the control loop. The off-line part of this module only affects some initializations. 3.2 Guidance module The guidance module manages the flight path according to the aircraft state and a flight plan defined by waypoints, whose feasibility is analyzed off-line. Once in-flight, the autopilot calculates the target value of the variables to be controlled and establishes the right autopilot mode. The software design of this module has been fully derived from a Simulink model which enables automatic code generation and simulation.
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Flight Plan definition The flight plan consists of a sequence of waypoints defined by a list of attributes: name, coordinates, airspeed and phase of flight. Using these fields, the onboard computer calculates the distance and course between two consecutive waypoints (desired track DTK), and the distance at which each waypoint is considered to be reached (fly-by property). Guidance procedures and target calculation The control module switches between several autopilot modes along the different phases of flight. During climb and cruise, the Vertical Navigation (VNAV) system switches between VPATH HOLD and ALTITUDE HOLD modes, while the Lateral Navigation (LNAV) system can enter HEADING HOLD or TURN (ROLL HOLD) modes depending on the heading error and the guidance procedure. During the approach, another control mode is used: VNAV and LNAV control the vertical and lateral distance to the glide slope (G/S) in a similar way to an ILS system.
linearized model, built in terms of stability derivatives, the vertical and lateral dynamics are independent and can be grouped in two matrix systems, phase of flight-dependent, using an implicit state space representation. Trim calculation. The equations of motion are linearized with respect to an equilibrium point called trim condition. It is calculated off-line using a numerical algorithm developed in Stevens and Lewis (2003) that requires the non-linear model of the aircraft. Control system design. The design of the control module has been automatically derived from the Simulink model of Fig. 2. The control is decoupled into two independent problems, LNAV and VNAV, and there is a third block which is the throttle control. The throttle control is solved separately (out of the state space representation) because its corresponding linearized terms are not constant (Stevens and Lewis (2003)).
VNAV target calculation: The VNAV algorithm is responsible for setting the targets which in this case are the altitude of the next waypoint. In addition, during climbs or descents between different flight levels, the onboard computer generates a reference value for the vertical flight path angle as a function of the current altitude error. LNAV target calculation: The LNAV algorithm controls the lateral path using different strategies depending on the autopilot mode or phase flight. These strategies differ in the way they manage the cross-track error. The first strategy is based on setting the heading using the wind triangle. The main advantage of this method is its simplicity. However, it requires to make a wind estimation to calculate the wind correction angle (some methods are proposed by Langelaan et al. (2010) and Cho et al. (2006)). The second method is based on an adaptive path-planning algorithm developed in Park (2004) that calculates the required lateral acceleration to drive the aircraft to a reference point over the desired track. This is a powerful method since it does not require a heading control model neither a wind estimation. It can be used to track circles, and also adapt the flight path to correct a lateral deviation. 3.3 Control module Once the guidance module has calculated the target values of the state variables and selected the vertical and lateral navigation modes, the control module calculates the action over the aerodynamic surfaces and the engine thrust needed to lead the aircraft towards the next waypoint. Control adjustment is based on building an aircraft model. The off-line part of this module includes the definition of the aircraft model, the calculus of the trim conditions, and the computation of the control matrices. The on-line part carries out the execution of the control loop that will generate actions for the elevators, ailerons, rudder and throttle. Aircraft model. The selected aircraft model is a Cessna 172-SP, whose non-linear model can be found in Berndt and Peden (2012) while the linear one is developed in Roskam (2001), and both are computed off-line. In the 437
Fig. 2. Autopilot’s control flow. Guidance and control modules in Simulink. Different control approaches can be designed and tested for each Simulink block. Our proposal consists of using the LQR method for the vertical control and the MPC method for the lateral control. The LQR method is designed as a tracking problem. A state integrator is added to the controller system so that the controlled variable reaches the reference value given by the guidance module. Then, the problem is discretized and solved by state feedback. The optimal gain matrix is calculated as described in Ogata (2010) to determine the deflection of the elevators. The lateral control is based on a Model Based Predictive Control (MPC) available in the corresponding Matlab Toolbox. This choice is based on the possibility of handling constraints, so we are able to specify limits for roll rate or slip angle. Inputs in this case are ailerons and rudder deflections while outputs are roll, yaw, roll rate, yaw rate and the slip angle. Finally, the airspeed control is provided by an independent PD controller over the throttle position δt , developed in Allerton (2009).
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
3.4 Interface module The interface module connects the autopilot to the controlled system through a series of communication channels, which are set up off-line. Its implementation is systemdependent: there is a version for the different hardware platforms, and also a special version for the flight simulator, which uses User Datagram Protocol (UDP) communication. The interface module hides the complexity and specific details of each system.
the aircraft performs the flare maneuver engaging the VPATH HOLD mode to reduce the vertical flight path angle before landing. The control performance of the control modes used for navigating the G/S yield an error less than ±1 m in both vertical and lateral axes, thus fulfilling the RNP APCH/RNP 0.1 requirements for GPS approaches. Fig. 4 shows the difference in the vertical path during the landing with both wind conditions.
4. AUTOPILOT VERIFICATION The verification of the software design has been done through a series of real-time tests using a flight simulator. Although all aircraft systems must be finally validated through flight tests, simulation allows to verify important properties so only minor details need to be improved by flight tests. This section presents two of these tests: the first one is aimed to validate the LNAV system design, while the second one does the same for the VNAV. Both tests are performed under two different conditions: a) no wind, and b) wind blowing at 7.7 m/s (15 kt) from 20 ◦ . RNP requirements are used as an upper bound for accuracy. The first test analyzes the LNAV performance during the cruise phase. The route is a square of 12 × 12 km with four waypoints at the corners which is navigated with the ROLL HOLD mode. This mode is specially suited for small UAVs, but it can be tested with bigger planes by tuning the design parameters. The results of the test are shown in Fig. 3. In all wind conditions the aircraft remains inside a margin of ±500 m during the turns, and ±25 m in the legs, thus comfortably meeting the RNP 5 requirement of Eurocontrol for RNAV continental en-route flights.
Fig. 4. Landing test. Vertical path. Fig. 5 shows that the control mode used for landing provides a lateral deviation accurate enough to allow a landing in cross wind conditions. However, we noticed that the autopilot mode is very sensitive to initial errors, so the aircraft must be aiming the runway before engaging it.
Fig. 5. Landing test. Lateral deviation. 5. AUTOPILOT DEPLOYMENT TO XTRATUM
Fig. 3. Lateral path test under different wind conditions. The second test is a GPS landing at runway 30 of Valencia airport (ICAO: LEVC). The simulation starts in the Intermediate-Fix (IF) at an altitude of 670 m (2200 ft) over MSL, which remains constants until the aircraft intercepts the G/S in the Final Apporach Point (FAP). Then, a glide path of −3 ◦ leads the aircraft towards the threshold of the runway. Once on the FAP, the APProach mode is selected: the airspeed is maintained at 41.1 m/s (80 kt), and the flaps are automatically deflected. Finally, 438
The last step of the MBD methodology consists in the deployment of the autopilot to the target platform. This means to convert the Simulink design into a set of software units to be executed on an IMA architecture called XtratuM, developed in our research group. This section briefly introduces the IMA principles and how the Simulink design has been ported to XtratuM. 5.1 XtratuM and the IMA Concept XtratuM is a hypervisor for real-time embedded systems that is based to a large extent on the IMA concept. The IMA architecture is essentially an integrated architecture based on the partitioning concept. This concept emerges
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
for protection and separation among applications from the spatial and temporal point of views. XtratuM virtualises the essential hardware devices (memory, timers and interrupts) to execute concurrently several operating systems. One of these guest operating system (OS) is LithOS that implements the process concept presented in the ARINC 653 standard which is not present in XtratuM. Another way of implementing the concept process is using Partikle, a real-time OS that implements POSIX threads. The services provided by XtratuM either through LithOS or Partikle are the ones defined by the ARINC 653 specification and are summarized next. Partition management. Partitions are execution environments with independent memory spaces and strictly protected execution time. Partitions are scheduled according to a cyclic scheduler which is specified in the configuration file. Process management. A partition comprises one or more processes that interact dinamically to provide the partition functionality. Processes are the execution unit within a partition of ARINC 653. Time management is the basic module to manage time in the OS and ensures hard real-time requirements are met. Each partition runs for a specified duration, the OS provides time slicing for partition scheduling. Inter-partition communication. This module provides the communication mechanism between two or more partitions via sampling or queuing ports. When using sampling ports, each new instance of a message overwrites the current message. In queuing ports, messages are queued. Channels, ports, maximum message size and maximum number of messages are defined in the partition definition file at system configuration time. Intra-partition communication. This module provides blackboards and buffers for intra-partition communication. Semaphores and events are provided for intrapartition synchronization. Health monitoring. This module implements the mechanism proposed by the ARINC 653 for error reporting and monitoring. 5.2 The porting process Porting a Simulink design to a XtratuM run-time environment requires to solve a number of problems because Simulink does not know about the XtratuM execution platform. The main issues are related to the application partitioning, the communications channels definition, the operating system setting, tasks concurrency, etc. To solve these issues a workflow has been designed which affects the phases of design, code generation and configuration files generation. A brief description is presented next. Design Phase The first stage of the porting process concerns the Simulink design itself. It is related to the partitioning of the application that, in our context, means allocating Simulink blocks to different partitions. The proposed solution is based on the use of Simulink Referenced 439
models. Model referencing is a Simulink feature that allows to include one model into another by referencing it. A Referenced model has an interface that consists of its inputs and outputs ports and its parameter arguments, thus being a usefull abstraction that can be related to XtratuM partitions. In our procedure, Simulink blocks belonging to the same partition are grouped into a same Simulink Referenced Model. Once the application is partitioned, an interpreter is run which is able to identify the partitions (one per each Referenced Model in the top level diagram). But, even more, it is able to identify the communications channels existing between those partitions. Each of these channels is mapped to a XtratuM sampling port. We are using sampling ports because we don’t want the data to be queued, we just want to work with the last available data. In a subsequent process, the user is asked to set OS intended to run in each partition. If the selected supports multitasking and it has been enabled in Simulink Model, the user is asked to enable it in XtratuM application too.
the OS the the
Code Generation The next step of this process is code generation. Simulink Coder generates C/C++ codes from Simulink models, Stateflow charts, and Matlab functions. It is able to generate code for a number of platforms, hardware targets, including POSIX or ARINC 653 compliant systems, which are supported by XtratuM. Even though, there are some important aspects that need to be addressed: • External libraries. Simulink Coder assumes that the standard C libraries are available, and generates calls to their functions or defined constants, waiting for the links to be resolved when compiled. One of the most clear example of this is the necessity of a mathematical library which is not included in XtratuM. In this case, the user may have to provide the missing resources. • Concurrency model. The multitasking model must match the multitasking model of the target partition, so it has to be properly configured. For Linux systems, for example, POSIX is used. In bare applications (those running on XtratuM directly), there is no support for concurrent execution so no multitasking calls to the OS must be generated. • Customize generated code. Some Simulink generated code needs to be tuned to the target partition. This includes the sampling ports creation, reading and writing, the generation of support files with constants definitions, the way POSIX threads and semaphores are used, among others. The way to accomplish this is using the Target Language Compiler (TLC) to customize the generated code. This represents a powerfull tool when it comes to develop a project for a very specific target. We have created some TLC files and modified some of the provided in order to make the generated code runnable on XtratuM. Configuration Files The last step of the porting process is the generation of configuration files. Partitioning an XtratuM application is a matter of configuring two main files:
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
• The first one is a makefile that describes the rules to compile the source code, the partitions and the executable resident software. • The second one is a xml file, named the hypervisor Configuration File (XM CF). It defines the system resources, and how they are allocated to each partition. The main information contained in this file is related to the memory and the processor allocation, the peripherals, the health monitoring, the inter-partition communication, and the tracing. These two files can be almost completely and automatically generated from the information contained in the Simulink models and we have developed a tool to make this task. Regarding the makefile, Simulink generates its own makefile, but it is barely useful because does not describe the compilation rules in the appropriate way. For example, compiling applications for Partikle implies some particular rules. Compiling for XtratuM also implies additional compilation rules (see Masmano et al. (2009)). With respect to the hypervisor Configuration File, some of the fields can be set according to the partitioning definition previously explained. This includes aspects like the number of partitions and their communication ports, or the information about the cyclic plan. But there is also some information regarding memory allocation that must be supplied by the user at a later stage. We are now working on a new tool that allows to easily define all these system resources through a graphical user interface. 5.3 Autopilot Partitioning Following the workflow explained above, the porting of the autopilot to the XtratuM platform has been made. First, the application has been divided into two partitions. This layout does not actually correspond to isolation requirements, but to a need of providing the correct execution environment to each partition. • Partition 1 performs the interfacing either with the simulator or the real system. It has been carefully designed to easily switch from the simulator to a real system. This partition runs on a virtualized Linux environment. Linux is required because the TCP/IP suite is needed for interfacing the controlled system (X-Plane simulator). This partition communicates with the X-Plane simulator via UDP and exchanges the data with the other partition through two XtratuM sampling ports: one outputs the measures, and the other one receives the control actions. • Partition 2 allocates the control and guidance application, and runs on a virtualized Partikle. It reads the state of the aircraft from a sampling port and computes the target waypoint and the control actions according to the aircraft state, the flight plan, and so on. These outputs are sent to Partition 1 through a XtratuM sampling port. Regarding the process management, each partition consists of different concurrent tasks implemented, both in Linux and in Partikle, using POSIX threads. Partition 1 has two tasks in order to interface with the simulator. First task receives measures from X-Plane while second 440
one sends the control actions. Partition 2 also separates its two functions (control and guidance) in separate threads, specially on the basis of their different rates: Control module is executed at a 20 Hz frequency while guidance is only executed at 4 Hz (this maximum execution frequency is limited by the input/output rate of the flight simulator). Finally, aspects related to time management comprises the measurement of the Worst-Case Execution Time (WCET) of the guidance and control tasks that allows to establish the cyclic plan in the Hypervisor Configuration File. After a number of tests, this time can be set in 2 ms. Knowing this, the cyclic plan has a major frame of 50 ms (corresponding to the execution rate of 20 Hz mentioned above) with two time slots, one per partition. The slot for Partition 2 is 2 ms long, while the slot for Partition 1 is 48 ms long. 6. CONCLUSIONS This paper has presented an approach for autopilots design using Model-Based design in Simulink and porting those designs to an ARINC 653 compliant execution platform based on XtratuM. The experience has been fully satisfactory and it has revealed that this design methodology makes feasible to model complex control systems and to easily derive implementations from this design model. This methodology also allows to analyze, test, and deploy the implementations on an IMA architecture. The experience also contributes to validate XtratuM as an execution platform for avionics applications. The paper has also shown how to structure the software design of an advanced guidance and control system for airplanes. REFERENCES Allerton, D. (2009). Principles of flight simulation. John Wiley & Sons, Inc., 1st edition. Berndt, J. and Peden, T. (2012). JSBSim Open source flight dynamics model [online]. http://jsbsim.sourceforge.net. Accessed: 2012-02. Cho, A., Kim, J., Lee, S., and Kee, C. (2006). Wind estimation and airspeed calibration using the UAV with a single-antenna GNSS receiver and airspeed sensor. ION GNSS 19th International Technical Meeting of the Satellite Division. Langelaan, J.W., Alley, N., and Neidhoefer, J. (2010). Wind field estimation for small unmanned aerial vehicles. In Guidance, navigation and control conference. AAIA, Toronto. Masmano, M., Ripoll, I., Crespo, A., and Metge, J. (2009). XtratuM: a hypervisor for safety critical embedded systems. In Proc. of Real-Time Linux Workshop. Ogata, K. (2010). Modern control engineering. Prentice Hall, New Jersey, 5th edition. Prisaznuk, P. (2008). ARINC 653 role in integrated modular avionics (IMA). In Digital Avionics Systems Conference, 2008. DASC 2008. IEEE/AIAA 27th, 1–E. IEEE. Roskam, J. (2001). Airplane flight dynamics and automatic flight controls. Design, Analysis and Reseach Corporation, 3rd edition. Stevens, B.L. and Lewis, F.L. (2003). Aircraft control and simulation. John Wiley & Sons, Inc., 2nd edition.