In making ECU and LRU testers, we come across a lot of common signal types; then there's the rest.  While almost every high channel count system has one or two signals that are fairly unique, even the uniques begin to fall into some common buckets after a while.  These signals usually represent 10% or less of a given system, though nearly 100% of systems have something more custom than not.  It goes without saying that when we find an uncommon signal type - whether it’s on this list or not - we first start by fully assessing the requirements and go from there.  Here's what we see, where we tend to see it, and how we commonly approach the solution for acquiring or generating it.

(These are expressed from the tester's point of view.  Our input is your ECU or LRU's output.)

Custom high-speed digital protocols

What is it? This trend is high-speed custom digital protocols.  They are usually TTL-level (or similar low voltage), and sometimes very high bandwidth.  The protocol is something unique to the system at hand, not like a standard, well-used protocol such as ethernet or one of the common ECU/LRU communication buses (link to common signals article).

Where do we commonly see it? Typically this is to communicate between ECUs or LRUs within a system, or crossing a boundary from one system to another.  These can be a challenge to implement at all.  They can be challenging in software for performance reasons, and difficult in hardware because of the extraordinary cost.

Our typical approach: Using an NI FPGA card usually let us implement these protocols with a fraction of the cost of designing custom hardware.  Such an FPGA card lets us implement designs in software that will execute at hardware rates. Depending on needs, we may approach this with NI R-series cards (such as the PXIe-7820) or NI-FlexRIO cards.

Custom discrete digital

What is it? These signals are custom, but closer to the standard discrete digital signals we commonly see (link to common signals article), such as nonstandard voltage levels or "dry contacts".  A dry contact is a circuit designed for high isolation, where instead of directly communicating with discrete signals, ECU or LRU A opens and closes a relay where source and sink both come from ECU B.  

Where do we commonly see it?  Between ECUs or LRUs, or between ECUs and simpler external sensors.  These can be used to convey discrete signals (binary) or things such as frequency or duty cycle, as well.

Our typical approach:  We prefer to use signal conditioning external to the IO card, and then use an NI DAQmx card similar to standard discrete signals (link to other article).  Most cards that have these niche voltages tend to not have high sampling performance.  Sometimes, requesting a single sample from a card with a slow driver (even if at a low rate) can monopolize system resources such as CPU and the chassis bus so much that it can slow down your other IO and make loops run late.

Thermocouple simulation

What is it? Simulating the signal coming from a Thermocouple, which involves precise voltages in the mV range.  The accuracy and precision required can make this an expensive requirement.  To further complicate it, Cold Junction Compensation (CJC) is often required.   Here is a good explanation of Cold Junction Compensation and how it is commonly approached.   https://blog.beamex.com/thermocouple-cold-junction-compensation  What that article does not cover is the kinds of strategies needed for the simulator to work with the cold junction compensation of the ECU or LRU.

Where do we commonly see it? In order to test ECU or LRU functions where there is a thermocouple involved, a simulation is sometimes necessary.  

Our typical approach: Because properly working with the ECU or LRU's CJC can be so problematic, we prefer to use something like an SLSC Thermocouple Simulator Module from Bloomywhen possible: https://www.bloomy.com/products/slsc-and-crio-modules-and-accessories/thermocouple-simulator-module-slsc

Large loads

What is it? Switching power to loads is one of the main jobs of an ECU or LRU.  Large loads is one trend that continues - though each system implements the details differently.  This includes things such as large motors or heaters.  Many large loads are resistive, but some include fixed inductive loads such as ignition coils.  There are highly dynamic inductances (such as simulating the load of an electric motor to a motor controller's power electronics controller) but those are far more rare for us.

Where do we commonly see it? In the Automotive space, large loads such as turbochargers and ignition coils have long been a part of these test systems.  More recently with the trend of electrification, electrical actuators are appearing with more frequency.  That trend of electrification is now starting to permeate the aerospace industry as well.

Our typical approach: These are largely custom each time.  Usually, fixed lumped impedances in a cooling box are the go-to solution because of their low cost.  Occasionally programmable e-loads are required.  The standard approach is to add analog or digital cards in parallel to sense the on/off state, timing, voltage, or current to the load, as required by the ECU.

RF as part of a general ECU/LRU tester

What is it? Most commonly, RF tests are part of a common standard on a pre-certified module such as a wifi or bluetooth module.  In contrast to those, the type of RF that makes this list is part of a protocol custom to the system under test.  Usually this is part of the ECU or LRU such as the *link to Flight Termination System Tester article* .  We see RF tests focused on the physical layer and on the signaling layer.

Where do we commonly see it?  Automotive and aerospace systems occasionally have custom protocols - for example, for items such as key fobs or custom telemetry for a missile test.

Our typical approach:  Making physical layer measurements (e.g., power, bandwidth, spurious emissions) is less costly to implement than understanding or testing protocols, since physical measurements can be made directly.  Signaling, or communicating across the protocol, can be done but often requires significant investment since the protocol logic needs to be re-implemented on the test instrument in addition to the ECU or LRU platform.  NI FPGA-powered cards such as the VST make this possible in a way that would be extremely difficult otherwise.

We've seen many testers and many approaches. Even if it's something a little bit new to us, we handle similar situations all the time.  We have a good sense of what will get the job done and done right.