Critical SW Application at High Speeds Featuring a Digital Signal Processor (DSP)

By David Rivera, Software Development Engineer

Co-authors: Isabel Lucía Vera del Campo, Software Development Engineer & Juan Manuel Oñivenis, Project Head GMV´s Aerospace and Defense sector

The EMA4FLIGHT & VALEMA projects are framed within the Clean Sky 2 program, which embraces and follows the More-Electric Aircraft (MEA) concept. This trend aims to progressively replace the secondary aircraft power systems (electric, hydraulic and pneumatic) with a globally-optimized electrical system. In this context, EMA4FLIGHT targets the design, development, and manufacture of an innovative Electro-Mechanical Actuator (EMA) for aileron/spoiler flight control surfaces, whereas VALEMA focuses on the formal validation of the previous development in order to obtain a Permit To Fly.

Both projects have received funding from the European Union’s Horizon 2020 research and innovation program under grant agreements No. 738042 and No. 755615, respectively.

The activities carried out by GMV within both projects are aimed to design, develop and validate the software integrated into an Electronic Control Unit (ECU) in charge of the control and monitoring of this aileron/spoiler EMA. The main operations of this control and monitoring application are the following: (i) implementation of a suitable control strategy regarding the dynamic and physical characteristics of the associated EMA, (ii) discrete and analogue, input and output, interfaces management; (iii) communication via standard avionics data bus protocol (ARINC429) and maintenance interface and (iv) failure detection, isolation and recovery tasks.

Those activities pose some stringent requirements for the software application, which have to be met considering the hardware constraints defined by the target platform. The next sections briefly describe those restrictions and the strategies implemented to overcome them.

Timing Performance Constraints

The control algorithm is the central element of the software application, supported by other activities quoted before, mainly focused on interface and failure management. The control strategy considered is a Field Oriented Control (FOC), which offers combined control of speed and current for the EMA. The dynamic characteristics and the performance requirements applicable impose an update rate of 10 kHz for this FOC algorithm.

Besides, there is an additional timing constraint related to the ECU external interface with the aircraft control electronics. The standard avionics data bus protocol ARINC429 establishes a messaging rate of 125 Hz with the EMA Control Electronics (EMACE). The ECU must transmit messages containing status, sensors, and monitoring data and receive control commands at this rate.

Those two rates, 10 kHz and 125 Hz, and the tasks associated with them define the timing performance constraints that the application has to meet, and condition the implementation and time management strategies considered.

Hardware Resources

Target Processing Unit

For this application, a DSP was chosen as the target processing unit. The selected device was P/N: TMS320C6742 from Texas Instruments, featuring the following relevant characteristics:

• Low-power optimized application processor
• Specially optimized for floating-point operations to be performed within the control algorithm
• Relatively high base clock speed (200 MHz)
• Broad range of interfaces (UART, SPI, I2C, EMIF, DDR2, extensive number of input/output discrete, etc) and Pulse Width Modulator (PWM) modules available, including Enhanced High-Resolution PWM modules
• Highly configurable and customizable. Among others:
  • Power and Sleep Controllers (PSC) allow fine power control of chip modules and peripherals.
  • Phased-Locked Loop (PLL) Controllers enable a flexible clocking architecture which allows the definition of an extensive set of bounded clock domains.
• Considered as Simple Electronics Hardware (with implications in terms of certification)

The following image represents the DSP internal modules and peripherals:

Redundancies and synchronization

Aligned with the application dependability needs, a redundant configuration was considered whereby two identical DSPs with complementary, but almost identical roles, are integrated into the ECU. This allows the implementation of efficient and robust monitoring and control strategies to ensure the fulfilment of the system requirements. For that purpose, a specific discrete-based parallel port was defined for the communication between both DSPs.

This redundant configuration was extended to other various HW resources and peripherals integrated within the ECU (ADCs, sensors, etc), so that each DSP interfaces with its own instance of a given ECU peripheral. Nevertheless, this strategy was not addressed as a whole, and some resources were conceived to be shared by both DSPs, enforcing synchronized access. This, added to the low-level inter-DSP communication, emphasized the need for a synchronized timer-based scheduling strategy.

Memory Resources

Regarding SW loading and execution, each DSP has access to the following memory resources:

• External non-volatile flash memory: persistent storage of the application binary
• Volatile memories: execution of the application
  • External RAM
  • Internal RAM

The usable internal RAM of a highly power-efficient DSP, such as TMS320C6742, is limited to 64 KB. The application binary developed far exceeds this size, which means an external SDRAM is required for a complete allocation of the binary. This incurs a performance penalty due to the less efficient external memory interfaces compared to internal memory, being those the lowest level and, hence, the fastest.

Application Implementation and Timing Strategy

Considering all the aforementioned constraints and limitations, the approach chosen for the application implementation was an ad-hoc bare-metal. This means full control is taken over the hardware resources, with no scheduler, nor operating system providing an abstraction layer for the software application.

This extensive control of the resources must start from the limited memory available. To meet the demanding timing requirements, a fine-tuned code allocation scheme ensures that the most performance-critical sections of the code are executed from the faster, internal RAM while guaranteeing that the memory size constraint is met.

The application is structured based on two different time cycles handled by two timer modules:

• Main cycle: Updated at 125 Hz (8 ms of period), this is the main application where all non-control related tasks (and hence non-performance critical) are carried out. The communication via ARINC429 with the external EMACE imposes this rate, but many other tasks are updated within this cycle at slower rates.
• Control cycle: Updated at 10 kHz (100 µs of period), defined within a periodic interrupt. It comprises all control-related tasks and some others that require some kind of synchronization between DSPs (inter-DSP communication and access to shared hardware resources).

The synchronization is something that cannot be overlooked and it is not trivial to achieve, since two different timers cannot run exactly at the same speed. One will always be faster than the other, making the DSP coordination unpredictable and conflictive. This will lead to a lack of certainty on when the shared HW resources are accessed making impossible both DSP coordination and time performance optimization.

This problem is solved by adjusting the timer count of a “slave” DSP regarding a periodic interrupt coming from a “master” DSP, which acts as a true 10 kHz reference. This permits the definition of a common time reference and defines when the synchronization events will occur, laying the foundations for an optimized task scheduling for both DSPs.

Having just a single thread to execute all those tasks, the major challenge is to avoid a timeout in any of the cycles defined. The time spent within the control cycle must be minimized to the greatest extent to permit the main cycle to complete all the tasks required. This is why the activities requiring synchronization are carried out within this interruption, at slower rates, and fractioned into minimum actions to avoid blocking the main cycle for too long and causing a timeout.

This leads to the need for a really efficient implementation of all routines invoked within the interruption cycle, to the point where each µs counts. Here is where DSP optimized floating-point operations, low-level optimized register access routines, code allocation into internal fast memory, and many other optimization strategies come into place and are required to meet the timing constraints.

Conclusions

The main idea ruling the application described and conditioning the performance requirements is the timing performance. Both the control algorithm and the ECU communication protocol with the aircraft systems demand challenging processing speeds.

This, combined with a platform seeking hardware redundancy to fulfill dependability requirements, but, at the same time, prioritizing efficiency and hardware simplicity, leads to a scenario in which the processing capacities of the target DSP have to be exploited to the maximum.

The bare-metal implementation proposed defines a software application in absolute control of the hardware platform. Synchronization between DSPs becomes a central idea of the strategy selected, defining an efficient timer-based task scheduling to meet the timing requirements.