Dave Buckley, Chief Architect at Curtiss-Wright discusses telemetry in a network paradigm. This video is about all the options that you have to telemeter flight test data to the ground.
Video Transcript
Okay, so this next presentation is about all the options that you have to telemeter flight test data to the ground. In the beginning, there was a single PCM encoder, so this is a single box that gathers all of the sensors and the data that's acquired and formats it to be sent to the ground. It was generally a single box but as the flight test systems got bigger and bigger and more test points were added the single box moved to a multi-box scenario where you had multiple chassis gathering the data and all of that data was being sent to an encoder chassis which would send the data to the ground.
The format of the data that was sent to the ground was standardized as IRIG 106 Chapter 4 and oftentimes the data that was sent between the chassis from the chassis that were acquiring the data to the encoder chassis was also encoded in IRIG 106 Chapter 4. In the last 15 years, flight test networks have moved from PCM-based to network-based. There are many good reasons for this and there have been many, many papers over the last five, ten years given at this conference and many other conferences about the reasons why the flight test world has moved to networks. I won't go into it right now - you've heard it all before enough times.
The fact that we have an onboard network which is ethernet and oftentimes PCM being transmitted to ground means that there are many different options for how you move data about the aircraft and how you telemeter it to ground. There's the old-fashioned option which is still quite popular which is IRIG 106 Chapter 4 sent from the chassis on the aircraft to the encoder chassis and then that gathers all that data and puts it out in another IRIG 106 Chapter 4 frame and sends it to ground.
There is also the total ethernet solution where the chassis format the data as network packets. These network packets are sent via switch network to an ethernet radio and the ethernet is sent directly to ground as ethernet. Renaut Urly from Airbus will give a presentation later on about how he has got on with such a system - his experiences with the pure ethernet system.
Today I'm going to talk about a hybrid option - a mixture of IRIG 106 Chapter 4 PCM and ethernet. There are several different ways of doing such a hybrid system. The first is to use the traditional IRIG 106 Chapter 4 PCM format for telemetering the data. So this is where you define each parameter and its exact location in the PCM frame before sending it down to ground. The challenge here is getting data from the asynchronous ethernet network into a synchronous PCM frame before sending it to ground - this is known as the coherency challenge and I'll talk about that in a while.
There are several other options that you can use. Another one is IRIG 106 Chapter 7 which uses the PCM infrastructure that exists to send ethernet packets asynchronously to ground so you gather up the ethernet packet, wrap it in a header, stick it in the PCM frame and send it down. There's also a third option which is the new variant of IRIG 106 Chapter 7 - the 2017 version which allows you to mix both chapter 4 and chapter 7 together.
If we take a look at a typical network system with an IRIG 106 Chapter 4 output we see that there are multiple data acquisition chassis - some of them KAM-500, some of them Axon in this example and they're sending data to a network switch or a number of network switches. All this data is gathered up and passed to the ethernet PCM bridge chassis at the bottom left corner of the diagram. This chassis also contains acquisition modules so you can if you like gather some data in this chassis and also pass it to the outgoing frame.
There's also a recorder in there which typically is ethernet and a PC which will program via ethernet so everything in the system is typically ethernet apart from this ethernet PCM bridge chassis. If we take a look at a typical or a simplified IRIG 106 Chapter 4 PCM frame we see that it is a major frame that is fully defined which means every parameter in the system every location in the frame is defined in advance by the user and it says exactly where each parameter and each sample goes.
It will consist of multiple minor frames - each minor frame will have a sync pattern and the sync pattern is used to allow the ground station to track exactly where we are in terms of the frame and also and to lock and also for the analysis software to figure out exactly where each parameter is. The analysis software will use the sync pattern and the location of the frame to tell exactly where each parameter is and exactly where each sample of each parameter is. If we look at the diagram we see that we have three parameters being sampled - p1, p2, and p3. P1 is sampled once, p2 is sampled twice and p3 is sampled four times per acquisition per minor frame.
Now the software will know that p1s1, the first sample of p1, p2s2, the first sample of p2 and p3s1, the first sample of p3 will all be sampled at the start of the minor frame. Based on the location the software will know that. P2S2 will be sampled halfway through the minor frame and p3 will be sampled at the start of the minor frame, a quarter way through, halfway through, and three-quarters way through. Using this system it is possible to understand exactly when each parameter was sampled by simply placing one single timestamp at the minor frame.
This is a very efficient way of encoding exactly when the parameters were sampled and it works very well and it has worked very well provided you have a synchronous regular source stream into the PCM frame. If you have an asynchronous network, for example, an Ethernet network, it becomes much more difficult to make sure that the data received from the slave chassis gets into the master chassis and gets in the right window.
You can have a problem if your ethernet packets arrive too late, that you end up with stale data or duplicate data, and if your ethernet data arrives too soon that you end up with lost data potentially. So you also have a challenge when you want to handle asynchronous data sources in that even if you sample them at the exact same rate that they are transmitted at you will not necessarily get all the parameters. So even if the asynchronous data source is transmitting data at 100 hertz and you're sampling at 100 hertz you won't be locked together - the clocks from the source and from your PCM frame won't be locked together - they will drift against each other and sooner or later you will get lost or skipped data.
So the coherency challenge is a problem when you're trying to take asynchronous packets and populate a synchronous PCM frame. The reason this is a problem is that when the packets are sent by the slave chassis through a switch network you will get variable delay through the switches. If the packets are late you end up with potentially repeat samples. If the packets are early you can end up with lost samples. There is a way to solve this and you can solve this by creating a software tool that schedules the traffic so it sends packets from the slave chassis at exactly the right time so that it knows what the delay through the switch network will be so they arrive at the PCM chassis at the encoder chassis in time to be output in the right window.
The positive thing about this setup is that it allows the software to automatically generate all the packages that get sent from slave chassis so the user doesn't have to worry about building those packets - he goes into his software, he looks at the frame, he sees all the parameters from everywhere in the system and then he places them into whatever locations of the PCM frame he wants to put them in and the software automatically generates the inter-chassis frames and looks after all the detail.
If we look at a typical IRIG 106 Chapter 4 system with an Axon chassis, first of all we see an Axon chassis with an ENC/401 encoder, BCU/402, and some parameters placed in various modules. So this p1 is an analog parameter on the ADC/401. P2 is an ARINC 429 parameter on the ABM/401. So the ENC/401 will build an IRIG 106 Chapter 4 frame that will include both parameters - it will have a sync word and p1 and p2. If we then add some more chassis, another Axon chassis, and a KAM-500 and we want to get parameters p3 and p4 from these two chassis, the software will automatically generate the inter-chassis frames and send them via ethernet to the BCU/402. The BCU/402 will then send those parameters across the backplane to the ENC/401 which will extract the parameters and place p3 and p4 into the outgoing IRIG 106 Chapter 4 frame.
All of this is under the DAS studio MCS control which means that it's all guaranteed to be coherent. P1, p2, p3, and p4 will always end up in the right location in the outgoing IRIG 106 Chapter 4 frame. If we want to add an external parameter - p5 - we will see that that can also be added to the system - it will be sent via the ethernet packet, again across the backplane, and into the outgoing IRIG 106 Chapter 4 frame.
Now because this is an external ethernet data source, because it's not under our control we cannot schedule it to guarantee coherency which means it can suffer from lost or duplicate packets. If we look at the diagram here we see that p5s3, so parameter 5 sample 3, is repeated and this will typically be caused by the fact that the packet that is being sent from the external data source does not arrive in time.
This is caused by the fact that the two clocks are not locked together even if we sample at exactly the same rate because the clocks aren't locked they will drift against each other and sooner or later we will get lost or duplicate packets. We can also see that p5s6 is missing and it's been replaced by p5s7 and it is lost. Again this is caused by the packets arriving from the external data source at not exactly the same time as we expect them.
We can avoid lost samples because typically lost samples are worse than duplicate samples. As long as the software has some way of figuring out what duplicate samples are it can throw them away. So in order to avoid lost samples what we will typically do is we will sample a little bit faster than the rate of the data coming in and there's also a status bit which we can place on a packet basis into the PCM frame which tells us whether any bits are duplicate and then the software can throw these away. That works quite well if you've got regular data but if you've got bursty data then sampling slightly faster than the incoming upcoming data source doesn't work so good and the problem here is that rather than getting regular packets you will get a burst of data so you might get four, five, six packets all at the one time coming out and then a big gap.
If you oversample at the burst rate rather than the average rate at the instantaneous burst rate what you will see is that you will capture all the data but you will then end up with a lot of duplicate data so you'll waste a lot of bandwidth. If you sample at the average rate rather than the burst rate you'll lose a lot of data. One way around this is to buffer a lot of the burst on the encoder so the encoder will have a buffer, it will take all the burst in, and then it will slowly but surely release that out into the PCM frame. On the ENC/401 you have the option of tailoring your memory so that you can either have a lot of parser slots or you can have deep buffering.
So if you want, if you have a lot of streams and you want to use all 256 parser slots you'll have a buffer depth of four but as you go down through the list you can increase your buffer depth and reduce your power slots if you have highly bursty sources of data coming into your system. Now, this avoids data loss without having to oversample but you still can't get away from the point that you'll have a duplicate parameter anytime you have an asynchronous source going into a synchronous source like the PCM frame you will end up with some duplication of some sort.
So there are other ways to do it that mean that you can place asynchronous data into the PCM frame and into the PCM infrastructure without necessarily having to have duplicates and IRIG 106 Chapter 7 is one of ways of doing this. The original standard in 2015 enabled users to use the existing IRIG 106 Chapter 4 PCM frame structure infrastructure and simply add ethernet packets as they arrived into the PCM frame. If we look at the diagram here we see that there are three frame headers, three minor frames, each with a frame sync pulse.
Each one has a minor frame header which tells us exactly where the packet starts. Now the packet doesn't have to start straight after the minor frame header because packets can overrun from one frame into another. The packet itself has a packet header and that packet header indicates the type and the length of the frame. The type of the frame can be TMNS, Chapter 10 raw ethernet, or fill packets.
Fill packets are added if there's nothing else to send so if every time a packet is received it's put into the outgoing PCM frame - if there's nothing to send a fill packet is sent instead to fill up the space. The length will tell the software exactly where to look for the next packet so if it gets a packet in it will decom that packet, it will know the size of it and then it will know where to find the next one in the line. The important information in the minor frame header and in the packet header are protected with a Golay code and this is an error-correcting code that allows you to correct up to 3 bits and twenty-four.
So if you think about it, if you were to to flip or lose one or two bits in your minor frame header or in your packet header you would lose an entire minor frame of data so that's key data that's protected by this Golay code header. Looking again at the diagram we see that we have three frames here each with a frame sync pulse and a minor frame header. The first minor frame header points to the start of packet N+1 which is midway through the section. The second minor frame header doesn't point to any packet at all because packet N+1 runs over the whole length of the minor frame header so there is no packet start in that particular minor frame.
The third minor frame header points to packet N+2 and then N+2, the size of N+2 allows the software to pull out packet N+3 and packet N+4 and so on. Now there is some concern with this method in that if you have a purely asynchronous system and you have a lot of data going in relatively randomly into the encoder your time-critical parameters, your safety of flight parameters, may get stuck behind large packets or a burst of large packets. So IRIG 106 Chapter 7 introduced two priorities and a concept of low latency packets and the low latency packets can be dropped into the outgoing frame after each minor frame header.
And even if you're midway through a packet, even if the existing - the non-low latency packet - hasn't finished yet the low latency packets can still be dropped into the front of the frame in order to allow them to get through in time so that you get some level of guaranteed latency on these packets and they don't get stuck too far behind the other packets in the system.
So if we look at how the Axon ENC/402 deals with IRIG 106 Chapter 7 again we have an Axon chassis - instead of an axon ENC/401 now we have an ENC/402 and we're not dealing with parameters, we're dealing with entire ethernet frames or ethernet packets. We see F1 on the ABM/401 and ARINC 429 packetizer packet and we see a place packet on the BCU/402 which can contain parameters from anywhere else in the system. These get added by the ENC/402 to an outgoing IRIG 106 Chapter 7 frame. We see the sync pulse and we have a bunch of wrapped packets (wrapped frames). If we then add in some extra frames we see we have frames three, four, and five on some external chassis within our system and also chassis that don't necessarily belong to the system.
They are sent via ethernet into the BCU/402 and across the backplane to the ENC/402 which wraps the frames and places them in the IRIG 106 Chapter 7 stream so it's all frame-based -there's no parameters involved here at all. In 2017 the IRIG 106 Chapter 7 standard was updated to allow a mix of Chapter 4 and Chapter 7 so the idea here is that you can both place wrap teeth in the packets into your PCM frame and define certain locations in the PCM frame where you can place your parameters - your time-critical, your low latency parameters.
If we look at the diagram we see that we have three types of packets - ethernet, Chapter 10, and TMNS. They again have packet headers added onto them which tell you the type of the frame and the size - these are gathered up and put into a packet telemetry packet stream which is chopped up and put into packet telemetry frames. Now, these packet telemetry frames also have a header added and that tells you exactly where each packet starts in the packet telemetry frame.
This might all sound very familiar because it's another way of describing exactly what happened in IRIG 106 Chapter 7 2015 and if you want to drop these packet telemetry streams straight into your minor frame and use up all of your minor frame then what you get is effectively the 2015 version of the standard. But you also have an option with 2017 that you can put them into the minor frame alongside PCM data, alongside your parameters that you choose and you explicitly define go into the PCM frame.
IRIG 106 Chapter 7 2017 also supports low latency and the idea is very similar to 2015. Rather than start a very minor frame at the start of every packet telemetry frame, you can drop in a bunch of low latency parameters. Even if you're halfway through another packet you get to drop in these low latency packets at the start of the frame and that gives you some level of guarantee of the latency that you can have on these vital parameters. If we look at how that works in an ENC/402 in the diagram here we have the same chassis as before. This time we have a parameter, an analog parameter, on the ADC/401 P1 which gets placed into the outgoing IRIG 106 Chapter 7 frame.
If we want to add more parameters, p2 from an external chassis and p3 from the external chassis again they get sent via ethernet to the BCU/402, passed across the backplane where the parameters are extracted by the ENC/42 from the ethernet packets and placed at the outgoing frame. It can also handle ethernet frames so you see an ethernet frame for the packetizer on the ABM/401 and an ethernet frame for the BCU/402 which also get placed as wrapped ethernet packets into the frame. Again it can also handle external frames - frames from the Axon chassis, from the KAM-500 chassis, and from an external box, for example, an IP camera can be sent to the BCU/402 across the backplane where the frame is wrapped and then they get placed into the outgoing Chapter 7 stream.
So if we look at the IRIG 106 Chapter 7 frame in a little more detail and take a simplified example on the screen here we see that the minor frame is split into two sections. There is the parameters p1, p2, and p3 which are defined by the user, explicitly defined. He puts it to the software this is exactly what parameter is going to stay in this location every time and then the remaining sections of the minor frame are available for the ethernet packet so any ethernet packet that comes along will be wrapped, a header will be added and will be placed into the outgoing stream. All or none of the frames can be used for place parameters or for the packet stream.
If you want to use all of the parameters for placed then this is effectively an IRIG 106 Chapter 4 frame. If you want to use all of the minor frames for the packet stream it's the same as an IRIG 106 Chapter 7 2015 frame. 2017 gives you the option of mixing and matching as you choose. The place parameter section is usually suitable for time-critical and synchronous data sources and the packet stream is suitable for bus monitors, videos, etc.
So if we look at the Axon encoder family we see that we have two encoders right now. One is the axon ENC/401 which supports IRIG 106 Chapter 4. It has a built-in parsing engine for parameter extraction so you don't need an external EBM or any sort of bus monitor - the ethernet packets are passed across the backplane for the BCU/402 and the ENC/401 extracts the parameters, puts them into telemetry and sends them out. There's also a deparser option for bursty traffic - this means that if you get a high burst of data followed by very little from a particular source the encoder will gather it up in a buffer and then slowly release those out to the PCM so you don't lose any data and you don't have to highly oversample.
It has a bit rate of up to 40 megabits per second. This module was released last year and it is operating in quite a few configurations right now. The ENC/402 will support IRIG 106 Chapter 7 2017 and IRIG 106 Chapter 4. It also has a built-in parsing engine for parameter extraction and it also has a deparser option for bursting traffic. It has a bit rate also of up to 40 megabits per second and this module is released in q3 of next year but there are early access units available for anybody who'd like to try and get their hands on this Chapter 7 encoder and play with it in the lab.