UTAS Saves Time, Money, and Labor by Developing a Unified Test Architecture for Electromechanical Systems

  Read in   |   Print Print

"We’ve perfected an architecture on which an entire test lab can run on a series of mobile common front ends, which eliminates the problem of aging, stationary electronics built for a single function on a single mechanical test bed."

- Scott Christensen, United Technologies Aerospace Systems (UTAS)

The Challenge:
UTAS needed to create a “cradle to grave” test architecture for electromechanical systems that was flexible enough to use for a wide range of aerospace controller and component tests across the product development cycle on new and existing programs.

The Solution:
We standardized on the NI PXI and CompactRIO hardware platforms and LabVIEW software to provide a modular test architecture that could be easily configured, customized, and maintained. We collaborated with NI Alliance Partners Wineman Technology on the software and Sierra Peaks on the instrumentation and actuation.

Author(s):
Scott Christensen - United Technologies Aerospace Systems (UTAS)

 

Video 1. NI Principal Solutions Manager Nate Holmes describes the UTAS distributed, deterministic, and dynamic (D3) test architecture that covers end-to-end program test needs from simulation through hardware validation, qualification, and MRO.

 

United Technologies Aerospace Systems (UTAS) is one of the world’s largest suppliers of technologically advanced aerospace and defense products, with approximately 42,000 employees and annual revenues in excess of $14 billion. The actuation systems business unit designs and manufactures high lift actuation systems for business, commercial, and military aircraft.  

 

Aerospace Test Needs

Aerospace line replaceable units (LRUs), components, and controllers require rigorous test, and aerospace companies like UTAS must test a wide range of configurations and variants of one type of part for a variety of OEM vehicle programs, from business jets to commercial airliners to military aircraft. UTAS designs many of components used in aircraft flight systems. The actuation group designs systems that translate cockpit control commands into movement of all the leading and trailing edge control surfaces (flaps, slats). These systems are comprised of slat and flap electronic control units (SFECUs), central power drive units (PDUs) and associated power transmission elements like torque tubes and gear boxes. All these system components need to be tested individually and in combination at the system and aircraft levels.

 

Figure 1. UTAS High Lift Actuation System

 

Challenges of a Traditional Test Approach

The design and test methodology from component to component is relatively similar. However, those of us in the actuation group were operating many test stands for various types of LRU test, including development, qualification, production, and repair. Furthermore, we were operating with hydraulic loading on big test systems (both for internal use and for customers) that were time consuming and costly to reconfigure. We were losing time re-creating architectures and procedures to run different tests across the product development cycle.

 

Figure 2. Actuation System Connection and Communications

 

For example, existing stands used hydraulic loading for mechanical LRU test. We were seeing a lot of similar rework across tests; we needed to replumb hydraulic systems and rewire whenever we wanted to reconfigure our test setup. Even for electronic test, the test stands required actual flight hardware, which made the test solutions rigid and inflexible. Automated test was minimal, and support for multiple configurations was limited. The “traditional approach” to test was costly and time consuming. Our group faced aggressive schedule and resource constraints that simply did not allow us to adapt the fragmented existing architecture quickly enough to meet the growing requirements. Also, UTAS still needed a competitive advantage over other suppliers to reduce cost and schedule to win future programs, so were driven to develop a new test architecture.

 

The Benefits of a Common Test Platform Across the Design Cycle

The upfront work and investment we put into our new distributed, deterministic, and dynamic (D3) architecture was a forward-looking approach that will pay off in the years to come. We saw great potential to optimize tests by standardizing on a common test architecture for all tests across the design cycle for a component. We implemented the following test types with the D3 architecture: model-in-the-loop (MIL), software-in-the-loop (SIL), and hardware-in-the-loop (HIL) tests; hardware and software validation and verification (V&V) test (fault insertion); life-cycle durability test; system integration lab (iron bird) test; aircraft-level system integration test; high-lift system test rig (HLSTR) including aircraft-level physical system test; system test rig (STR) including performance, endurance, and fatigue tests; slat/flap controller rig (SFCR) including software development, fly-the-box, software functional, software regression, system, and automated production (acceptance test procedures or ATP) tests; and physical tests including single wing and “right side” emulating tests based on total loading on left side.

We achieved several goals. First, we created a single common test platform that provides a “cradle to grave” test architecture and multipurpose tester. We used the same SFECU rig across the entire design “V” for development, ATP, iron bird test, system integration test stand (SITS) test, full production electronic controller test, and full production mechanical hardware test. Second, we incorporated modular hardware that is maintainable and reconfigurable. Now we can easily expand for larger system qualifications, reconfigure for different systems, and avoid hard wiring or plumbing to connect system components. Third, we have an open software architecture that is easy to integrate. The reflective memory architecture allows us to completely control our test stands with memory reads and writes. We can use this architecture separately or integrate it into larger test systems, and we can achieve distributed control that allows for more processing power as the system grows.

 

D3 Architecture Details

The D3 architecture is a highly adaptive, modular, multipurpose test solution that incorporates well-developed technology from industry with minimal new design. This technology includes distributed control based on the expansion capabilities of NI CompactRIO and FPGA hardware and a direct interface to servo-electric load control using an NI C Series drive interface module and Kollmorgen AKD servo drives and AKM servo motors.

 

Figure 3. LabVIEW-Developed System Test Rig and GUI Used for Physical Systems Test

 

Figure 4. The UTAS system test rig uses NI hardware and software for load control.

 

The SFECU test rig is a rack-mounted platform that contains all real or a combination of real and simulated controllers. If only one controller is installed, we can simulate the other via CANbus. We use the system to simulate the electromechanical components that make up the aircraft. Proprietary simulation tools allow us to simulate aircraft failure modes. The rig is fully programmable to offer any automated duty cycle or specific functional test. In all cases, we can replace simulated hardware with actual hardware or vice versa.  

 

Figure 5. This test solution can conduct both physical tests and simulations. It uses the same controller and software to test the product throughout the design cycle.

 

Figure 6. Typical 2-Channel SFECU Test Rig

 

The hardware within these test racks provides switching to real aircraft hardware or simulated transducers that are contained within subchassis of the test racks. The test racks also contain hardware to monitor discrete, analog, and power voltages and currents along with signals to and from the aircraft controller. Specifically, these test racks house AC and DC power control and monitoring chassis; brake load simulation, switching, and monitoring chassis; internal DC power supplies; resolver simulation, switching, and monitoring assemblies; discrete simulation, switching, and monitoring assemblies; ARINC 429 and CAN transmit and receive assemblies; an emergency stop control and monitoring assembly; signal breakout assemblies; data acquisition assemblies; generic LRU interface to custom LRU adapter assemblies; and a Windows-based PC with an uninterruptible power supply.

The test racks also provide external electrical interfaces to the shared desktop workspace (human machine interfaces), real flight hardware interfaces, external ARINC 429 sources and sinks, and external AC/DC power assemblies to support power quality test.  

We use LabVIEW-based software to run the SFECU test rig so we can both manually and automatically configure and operate the test stand. We can also control and monitor test stand functions over a deterministic reflective memory data bus.

 

Uses for Different GUIs and Stand Configurations

We can customize, save, and reconfigure the software to support many different GUIs and stand configurations. For example, with the slat and flap ECU SITS, we can use the core test stand with a PDU model running in the test stand and fully simulate all transducers and discrete signals. We can reverse the system, overspeeds, underspeeds, and other surface faults by using the SITS cockpit (flight hardware) and simulation to send the slat flap control lever command to the slat and flap ECU and model. We can apply faults to the slat and flap ECU to validate engine indicating and crew alerting system (EICAS) logic, and we can test maintenance screens with the rig attached to the slat and flap ECU because we can simulate all communications, loads, discrete signals, and transducers. For slat and flap ECU ATP, we can use the SFCR to run the same ATP the production facility runs. We can choose from a variety of ATP methods including circuit by circuit or full simulation with flight software (fly-the-box test). We can also automate test with a custom, minimalist GUI and test sequencer running Python scripts.

In addition, the D3 architecture offers configurations for integrated system test certification rig (ISTCR), slat and flap ECU return to service (for example, to diagnose fault conditions that caused a latched fault), logging and display (reflective memory data logging configuration utility to help log values from the reflective memory at a 200 Hz rate), CAN and ARINC data logging, data display (the aircraft GUI displays the readings for each of the resolvers, currents, voltages, and so on; we can build, customize, and save GUIs based on the building blocks of standard custom blocks), and automation (scripting via TestStand, Python, or any language via socket and JSON serialization; automation from external applications/systems with access to the RFM; stimulus profiles for exercising the controller through the custom LabVIEW code; macro recording and playback; automated software functionality; and automated ATP).

 

Figure 7. This view of the flexible architecture shows how we built it to allow switching between simulated and real hardware. Each module communicates with the other modules via reflective memory.

 

Figure 8. This test configuration and GUI management screen demonstrates the variety of devices under test that can be handled with this common architecture and how an application can be configured on the subsystem level.

 

Figure 9. Example Aircraft GUI

 

UTAS Cost, Time, and Labor Savings

By using NI’s distributed measurement and control products, we were able to cut test reconfiguration times from weeks to a day. Our D3 architecture is multipurpose (same load tables used for system, ATP, and iron bird; same SFECU rig used for development, ATP, iron bird, SITS, ESIM), modular (no hard wiring or plumbing to connect; software and hardware are built on designs common to multiple aircraft), easy to integrate (open software architecture; script writing in any language; proven RFM architecture that allows test stand to run in segregated or integrated mode), maintainable (eliminates traditional harness construction through extensive use of printed wiring boards), and forward looking (our team has patentable designs).

By developing a common test platform to address our HIL, V&V, system integration, and production test needs across a variety of projects and even aircraft architectures, we were able to cut our test equipment development time while positioning ourselves to better address future needs including a more digital test lab. We’ve saved months of development time and hundreds of thousands of dollars on new platforms while operating with less test lab labor. We’ve perfected an architecture on which an entire test lab can run on a series of mobile common front ends, which eliminates the problem of aging, stationary electronics designed for a single function on a single mechanical test bed. Now we are striving to complete the integration of this new architecture into our daily technical and business systems to achieve a fully automated test lab where concerns over labor rates are a thing of the past, which frees investment for further innovation.  

 

Author Information:
Scott Christensen
United Technologies Aerospace Systems (UTAS)

Bookmark and Share


Explore the NI Developer Community

Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.

‌Check‌ out‌ the‌ NI‌ Community


Who is National Instruments?

National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.

‌Learn‌ more‌ about‌ NI