 I'm Michael Roberts, Senior Solutions Architect for ADLINK Technologies Advanced Technology Office. Andre Odermatt and myself will be co-presenting this. Andre? Hello, Odermatt. I'm a self-integration engineer with RTI and as Mike said, this is about interoperability between two different implementations of the phase TSS. So a little history about this, a year ago, September 21st, actually I presented this at the phase TAM in Dayton, a demo that I wrote that integrates, takes the bulk of data about and integrates live ADSB data from the internet and then visualizes it on the screen. And then after we did that, Andre and Chip and Downing and I from RTI got together and decided, wouldn't it be nice if we did an interoperability demo? So Andre and I started that in September and we've actually presented that at the phase TAM in Phoenix this past March. So the goals of this were to show that OMG Data Distribution Service as a standard would be an ideal solution for interoperability between phase TSS. And also we wanted to get live ADSB data from the internet and then send that over to the phase TSS to visualize that. Yeah, and since the two phase conforming implementation of a TSS are actually based, both based on DDS, we thought it was perfect to actually show interoperability since DDS is a perfect standard to use for the TSS and it really does all the functionality that the TSS specifies on the data distribution and it's really leaves it all, does it all handle itself and is actually, doesn't need the application know where data is sent and all this like the TSS, like the idea of the TSS. So yeah, so we're going to talk about how do we get this live ADSB data. So next slide. So what we do is there's a network out there, a web server called openskynetwork.org and using a REST API, you can specify a region of space, time by Latin month coordinates to get live ADSB data and what this demo does is it has a app that gathers the data from the opensky network, sends it to via DDS topic to the publishers and subscribers and in this demo we have both a publisher that's publishing data from ADLINK and being received by RTI and in vice versa we have an RTI publisher that's sending data to ADLINK and of course on both sides we have a visualizer that takes this alive ADSB data and actually draws an aircraft on the map and updates that periodically once every 10 seconds which is what the openskynetwork allows. Next slide. So before we go into the demo and how it's gone, let me give a little background on DDS what DDS is. So in DDS you have the concept of a virtual data space and then you have applications that can publish or subscribe to that virtual data space. So you're basically defining topics with just information that you want to exchange and then you as I said you can publish it and then whoever subscribes it who is interested in it can receive it and you can subscribe with different attributes which is in the DDS standard called quality of service. So you can say I only want it on a certain time interval or I only want data if it meets a certain conditions. I want it reliable. I want it best effort. There's a lot of attributes that you can attach your communication. It also has the concept of dynamic discovery. So once you start up you can say I'm here. I'm interested in that data and depending on how it's configured you may or may not get historical data so you don't have to go and query and say what happened in the past you can actually configure it so that the moment you start up you get all this information. So when it maps to the TSS so a connection that you create in the TSS actually gets mapped to the DDS topic. So we're talking about the Balsa demo application, ADC data, the config data and I think there's one more data element that's being sent or connection that's being made from the Balsa application. They all map to a DDS topic. And what we did in this demo is basically take, we took the air config data which has that string information and used that in order to send data across. Okay, so the way this works is we actually had two computers, each one running all four applications. We had a console, Apple, from Sky to Jason, a publisher, a subscriber, and a visualizer. And as Andre was mentioning, because DDS has a wonderful wealth of quality services, one of them being a partition. We actually partitioned the data. If you'll see the message on the left, the published data was published under the RTI partition which lower two apps on the right for RTI received the data only coming from the RTI partition. Advice versus RTI had the same console app and the PubFace TSS publisher publishing on the AD link partition and the application running on the AD link side, the subscriber and the visualizer. They received the data only from the AD link partition and would visualize it. And one note about this visualizer, it's fully interactive. You can actually grab the screen and drag it around to a new location, zoom in, zoom out. And it actually sends data back to the Open Sky to Jason on the other side with new set of coordinates. And so it will update where on the map it's being visualized. So in this demo, it's actually pretty simple. It has just a few components to it. But DDS itself can actually handle much larger setups as well. So the way it is designed, it can be a large, a small network, local network it can have, then interfaces to bigger networks so it really scales well to large application. So this slide here is just a small example of how it can be used, where you have basically some localized DDS network that then, like the edge processing that has its own data bus from all the sensor and does some processing and publishes it on a different domain and a different data bus that's then used by the flight control or other application. So it really scales nicely from a small setup like the demo we have to watch the systems with hundreds of endpoints, et cetera. So some of the DDS applications out there run the controls of big power plants and the dams or hospitals, et cetera. So it doesn't necessarily have to be a small thing like our demo. The other thing with DDS, as we mentioned before, it's message, it's not message centric, it's data centric. So the data is the king. That's what I usually try to describe it. So if you look at it, what makes it message centric versus data centric? Let's say if you want to schedule a meeting and you do this over email and say, hey, let's meet Monday at 10 a.m. And then you send out another email and say, here's the dial-in photo that we should use. And then something comes up and said, oh, you mail out and say, let's move the meeting to Tuesday. And then at the end, when it comes around for the meeting, you're trying to figure out, so what time is actually the meeting? What's the information? And maybe even, who all did I invite? Who all did I send the meeting to? If you look at, that's what I describe actually as message centric. If you look at data centric, it's like your calendar application. So you're just writing the information in the calendar about what the event is with all the information attached to it. And then if you make update, you put it in there and you have one view of it that describes what the event is. So that's what I use as an example for data centric because the data is really the key, the information that you go off. Now, the other beautiful thing with this is with the public subscribe and data centric approach is as an application, you don't have to worry about whom to send it to because the DDS takes care of that. You don't have to worry about storing information because you can have histories and you can have durability and all this things in the DDS layer. And you don't have to worry about addressing and marshaling as DDS has this automatic discovery. It does marshaling between platforms. So you can have a Java application on a power PC, talk to a C++ application and then Intel PC and the data comes across correct. So this is actually the boundary diagram of our demo. So we really just created two simple P3S that get data in and then write data back out because the idea was to show interoperability of using different transport segment services implementation. We didn't really wanted to build a big application and all this. We tried our applications according to the phase standard but the goal was to show how we can actually use different implementation of the TSS service and within the same application. And we built actually both applications with both of the different TSS implementations. Say next slide. Oh, there we go, thanks. Yes. So the important thing to note here is that the publishers and subscribers are both using base conformant TSSs, ADLinks of TSSs to the 2.1 profile. And we have that available for both C++ and or Java. And it's interesting to note because we're using DDS it would be just as easy to have interoperability between a 2.1 and a 3.0 as long as the underlying protocol is DDS. And another important thing to note is that when we get to the diagram, you'll see we got the upper of the console that opens guide to JSON and the visualizer which are both non-conformant, non-face applications. But because of DDS, we can actually use the same IDL data model that was generated with the base conformant TSS, and those applications can publish and communicate with those base conformant TSSs using legacy application. Next slide. Yeah, and this is the other TSS that we use, the RDI Connect TSS, which is also a base conformant to 2.1 right now. We're working on 3.0. You can find the information, the phase registry, it's all in there. It's actually certified for the safety base and safety extended, and we're using it in conjunction with our next microimplementation for which we also have D0178LA evidence. So if safety and certification is of an importance, we can address this as well. But let me go down here to see how we actually put the demo together. And since we, as Mike mentioned, presented it at the BITS event in March, it was easy for us to actually put it on a laptop with Windows, even though I would never claim that Windows is a phase conformant operating system, but it was just easy for us to do the demo there. It works on Linux as well, but it was just easy to do it on Windows and laptops were really easy for us to move around. So the way it works, we have an application that queries the REST API, as Mike mentioned, from OpenSky, and then publishes it out as the ADS as a data that's being used in the phase data model. But that application, since it uses REST interfaces, et cetera, is actually using C-Sharp and does not use the TSS. It just publishes it out on the ADS layer. And the publisher is the one that has the TSS stack implemented, receives the data, actually splits it up in separate ADSB messages, sends them to the phase subscriber, which then combines them again into one big string, sends it out onto the map display, which is also an application that was written in C-Sharp since it uses the G-Map package. And it's also just straight ADS doesn't use the TSS. So the publisher and subscriber to two phase combine applications or phase, following the phase standard. And then since the data model of it for balls at two and three is the same, we actually just run one of the balls applications as well to subscribe to the data. And we could use there the two dot one or three dot O example. So again, to reiterate, both AD-Link and RTI, we had a phase conformance two dot one certified TSS. We actually did a live demonstration of ADSB data. I actually a year ago in Dayton, I actually demoed with live data and everybody said, you're crazy to use live data in an environment like this, but I did it anyway, it didn't work. And so I shared all the source code to Andre and he put it together and it really didn't take long. I think it was 20 to 40 hours, something like that to get the system going. And by the way, I have all the source code to this entire demo on my GitHub and I will make that available to anybody who wants access to it. I've also got a YouTube video that I did that I will make available to anybody who wants to watch the video of this demo in action. So once the ADSB JSON grabs the data, it sends it to the publisher and then the publisher breaks it apart, sends it as individual tracks over to the subscriber and the subscriber takes the data and puts it back together, sends it to the visualizer. And of course the visualizer, the visualizer, like I said earlier on, it actually takes the data, part of the ADSB data is a field called TrueTrack and it actually takes the TrueTrack, which is the vector of the airplane, rotates the bitmap and then draws that bitmap in the exact lat long it is and you can actually take your mouse and hover over any aircraft and it'll show you that aircraft's altitude and I think it comes in meters from ADSB, but I converted to feed because we're here in the US. Next slide. Yeah, so to put the whole thing together was actually very easy and I was somewhat surprised how easy it was and the goal, what makes it easy was really that we both use the same wire protocol. So having interoperate with each other was very simple. We didn't need any of the optional components, TPM, et cetera, so we could keep the TSS layer really small and simple. Also, the other thing that I was actually surprised and cute as to the phase technical standard is how easy it was to take the application, the publish and subscriber that Mike has written and then plug in a different TSS since the API is well-defined and in the phase technical standard it was actually just kind of relinking it with a different set of libraries. It was actually pretty simple to do that. And as a side effect, I think an additional bonus that we had here is that it was easy to actually use existing TDS applications like our visualizer and all those that use T-Shar which we don't have language binding for the TSS and we will probably never use it in an aircraft anyway but it's easy to put those in and write some applications. So if you want to do some testing, it's really easy to just build some straight-up TDS applications. And with that, you open it up to questions. So we had two questions come in the chat. We have one minute left, so we'll do the question and then I can send you the follow-up question via email afterwards. Okay. So the first question is, the phase specification in API doesn't contain concepts like topic name, DDS, keyword loss, nor sample keys within its data model types. How do apps manage to interoperate with some controls in the API to degree these values between senders and receivers? Okay, so the way our phase TSS now let Andrea answer for RTI, we have a configuration file where you specify the information for the publisher, subscriber, and each element connection in the TSS and you can specify all that in an external configuration file. Yeah, it's the same for us. We have a configuration file where you basically map the TSS connection to a topic name. You can attach a QS to it. And if you wanted to use certain things like keys, there are ways to actually configure things I'm only interested in that key value for this connection. You could do that as well, but I don't think the TSS API itself right now does a good job in supporting keys and some of those advanced features which would be nice to have. Right, it would. Yes. Great, thank you. And since we don't have enough time to answer the other questions, I will send that to both of you gentlemen via email and I have the submitter's email as well so we can get him an answer. So this concludes our presentation today. Thank you very much, Andrea and Mike.