Five tips for successful aerospace communications system design

Nov. 29, 2011
Modern aerospace communications systems must be mobile, operate in harsh environments, overcome active and passive interference, and meet a variety of mission scenarios.  Interoperability requirements demand flexibility, while the proliferation of multimedia data streams demand high throughput.  Consider, for example, the Joint Tactical Radio System (JTRS), which must transmit and receive a number of waveforms with a significant variation in the form factor for the transceivers.  To meet all these requirements, designers must create systems that combine software and hardware, using both programmable DSPs and FPGAs. To create, test, and deploy these types of systems, engineers need a new paradigm for development that focuses on creating and testing models and prototypes before final hardware implementations, saving both time and money.  

By Mike Mulligan and Jon Friedman, MathWorks

Modern aerospace communications systems must be mobile, operate in harsh environments, overcome active and passive interference, and meet a variety of mission scenarios. Interoperability requirements demand flexibility, while the proliferation of multimedia data streams demand high throughput. Consider, for example, the Joint Tactical Radio System (JTRS), which must transmit and receive a number of waveforms with a significant variation in the form factor for the transceivers. To meet all these requirements, designers must create systems that combine software and hardware, using both programmable DSPs and FPGAs. To create, test, and deploy these types of systems, engineers need a new paradigm for development that focuses on creating and testing models and prototypes before final hardware implementations, saving both time and money.

Below are five tips for developing communications systems, distilled from years of experience working with customers throughout the aerospace industry:

1.Create an Executable System Level Model
The first tip, as well as the first step in development of a modern communication system, is to create a system level model that can be simulated to explore the design space, make trade-offs, and build confidence that the design will meet the customer requirements. The system level model will have a number of elements, including a detailed model of the transmit waveform, a channel model incorporating a variety of environmental and interference effects, and a receiver model that includes an RF front-end as well as a range of analog and digital signal processing algorithms, which may ultimately be implemented in software, hardware, or a combination.

One immediate benefit of the system level model is that it enables RF engineers who specify and analyze components in the frequency domain to collaborate with the system architects and signal processing engineers who develop their designs in the time domain. Using an executable system level model, engineers can analyze trade-offs that span the boundaries of these traditionally disparate disciplines. For example, it is possible to investigate the effect of using less expensive, lower performance RF components on the system level performance and determine if it is possible to correct for any resulting system degradation with a more sophisticated DSP algorithm. Hence, rather than partitioning system-level performance specifications into a set of worst-case component level requirements, as in a traditional communication system design based on a link budget, the system engineer can use an executable system level model to optimize the overall system level performance.
Simulink Model of a Comms System

2. Choose a Transparent and Flexible Algorithm Development Environment
Modern communications systems are typically built on a foundation of existing algorithms or intellectual property (IP). Working in an environment where existing IP can be easily reused greatly improves the efficiency of design teams. Moreover, it is important that the algorithms are transparent. Black-box implementations stifle innovation and make it difficult to fully explore alternatives. Additionally, the development environment should allow engineers to easily create test patterns or import signals to verify that the algorithm encodes or decodes the signal correctly. Effective technical computing environments enable engineers to seamlessly move between a data-centric workflow, where input signals are generated or read and output signals are visualized and analyzed, and an algorithm-centric workflow where IP is authored, tested, updated, and verified. This flexibility is a significant advantage over traditional environments in which data and algorithm workflows are disconnected.

3. Explore Receiver Design Alternatives While communication standards specify detailed waveform requirements to ensure interoperability, these requirements really only specify the transmitter design. It is at the receiver that the communications engineer faces the larger design challenges and has the best opportunity to improve overall system performance. Simulating both carrier and timing recovery algorithms in an executable model enables the designer to explore more alternatives before committing the design to hardware. Using a time-based simulator to model components, such as phase-locked loops, can yield useful insights into receiver performance for a wide range of channel conditions and RF receiver effects early in the design cycle.
Simulink Time Scope

4. Ensure a Seamless Translation to Fixed Point
Most designs are initially developed using floating point arithmetic, in which scaling and quantization are not considered. However, many modern communication systems are implemented using digital hardware. Thus, to ensure that the overall system design meets requirements, fixed point effects must be taken into account as early as possible. This challenge has grown more acute as new complex waveforms transmit more information in the same bandwidth, increasing the sensitivity to quantization errors caused by the fixed point implementation. Having one environment that enables engineers to start the design process in floating point, then easily convert to fixed point helps prevent fixed point translation errors from being introduced undetected. Ideally, the floating point model should always be available as a test bench. With an environment that supports a smooth transition from an initial floating point design to a fixed point design, engineers can explore the effects of different scaling factors and word lengths for each of their algorithms individually or collectively, and compare the final fixed point performance to the initial floating point design.

Fixed Point Parameter Selection


5. Reuse Executable Models for Hardware Implementation and Verification
The path to hardware from the design phase includes both the implementation, which may come from automatically generated C or HDL code, as well as the verification that the hardware implementation meets the requirements. If an engineering team has exercised the four tips outlined thus far, they have a model of the algorithm that is designed with fixed point details and then can be used for code generation. Modern tools provide support for generating both C/C++ and HDL code from these models that is ready for implementation. Moreover, the set of test patterns and vectors that were used to explore the design space within the modeling environment can be reused along with the executable system level model as a testbench to verify that the design implemented in hardware meets the requirements.

So, how can engineers put these five tips into practice? Using modern tools such as MATLAB and Simulink, engineers can develop communications systems more efficiently by exploring design options and performance trade-offs within a modeling environment rather than in prototype hardware. DSP engineers who use MATLAB to evaluate algorithm alternatives can easily convert their designs to fixed point and test their performance using a system level Simulink model. RF engineers can verify the performance of their designs by importing S-parameter models into the same Simulink model. Once the design is finalized, engineers can generate both C and HDL code directly from the Simulink model and then use the system level model as a verification testbench, linking to electronic design automation (EDA) simulators. The net effect of having a single integrated environment to link all these different engineering disciplines is an improved system design that meets requirements and reduces schedule risk.

Voice your opinion!

To join the conversation, and become an exclusive member of Military Aerospace, create an account today!