 Okay. I want to welcome everybody to the safe software supplier getting started guide and balsa overview two part webinar series with today being part two where we'll be discussing balsa. This webinar will be recorded just like yesterday's was recorded. So if you need the recording at a later date that will be provided and I believe everybody who's registered for this webinar will get an email link to them after the meeting closes. I want to start by introducing myself. My name is Lauren Russo. I work for the open group and I'm the form coordinator for the future airborne capability environment consortium. I also have here with me Dave Launsbury, the chief technical officer of the open group. And I'd like to introduce our panelists we have today. We have Dr. Alicia Taylor project and planning analyst supporting us army, PO aviation, and she also serves as the chair of the integration workshop standing committee. And we have Chris crook. He is a senior software analyst supporting us army PO aviation and an active member of the integration workshop. For those of you who are not familiar with the face consortium for government and industry collaborative organization that operates under the open group umbrella, which is a global organization that focuses on achieving business objectives through the use of open standards. The face consortium approach is a government industry software standard and business strategy that we use to enable folks to acquire affordable software systems rapidly integrate portable capabilities across global defense programs and attract innovation and deploy it quickly and I mentioned earlier that we developed through industry and government collaboration and we now have 90 plus organizations and over 1100 participants on our roster, which has grown exponentially over the last six years. The benefits of the government for using open standards collaborative approach between industry and government is better buying power, you increase competition, achieve affordability and control life cycle costs of the multiple programs for the various aircraft that are out there. We want to incentivize productivity and innovation and industry and government, and then ultimately reduce the software develop time, saving time and money through modularity and portability. Also for cross platform decision making for uses the primary use of the face approach, not investing multiple time for the same capability and enabling integration of cross program requirements. The industry benefits as well. The face approach enables industry to create software center product line opportunities to develop capabilities wants and use it for multiple customers across multiple platforms. It also provides opportunity for software capability across multiple aircraft types, which may have not been available before when they were supplying for one customer. It enables them to get into a market where multiple customers can benefit from the capability. It also lowers the cost of doing business if it's developed once the quality assurance is done once, and if it's proven once it's proven to work in the multiple environments. Standardization allows for rapid development of capabilities and reuse of software application enabled integrators to optimize platform performance. If they tested it once and integrated it once, the learning curve goes down and folks can do things more rapidly. And the ultimate goal is getting high quality capability to the warfighter faster and in a more cost effective way. For more information about the approach, you can find that on the face consortium landing page, www.opengroup.org. This is our public site. We do have a collaboration site that's used for members only. And if you're interested in joining the consortium or want some more information, we can get that to you by sending an email to ogface-admin at opengroup.org. On the landing page, it will give you information on the current consortium activities, membership, published documents and tools that we use for developing the face software, recent procurements, and a link to the face registry as well as how to navigate the conformance program. On our landing page, you'll find a section called documents and tools. And under that section, you can find our newly published documents as well as the newly published software supplier getting started guide, which will give you a little bit more information about shortly. And then also on the main open group website, www.opengroup.org, under publications, you can search for the software supplier getting started guide in the bookstore and you can download a copy of it like it shows on the screen. With that, I'd like to introduce our next presenter, Alicia Taylor, who's going to give you a bit of background on the integration workshop standing committee and the software supplier getting started guide. Thank you, Lauren. The integration workshop standing committee has actually developed a software supplier getting started guide. And I put our charter up here and I wanted just to kind of touch on a couple of things. Notice the second bullet in our charter says that we are to discover, evaluate and produce face reference implementation examples, facilitate adoption and publication of those reference examples. So this is a perfect example of what we've done with the software supplier getting started guide and then also Balsa. I've also included a couple of things that the integration workshop is responsible for. We typically read and review the papers that are presented at the TIM meeting in conjunction with a technical working group. Notice that I've got some information about Balsa, which I'll talk about a little bit later and Chris will go into much more detail, but most of the exhibitors at the TIMs and the conferences actually are using Balsa as an example code. And then we do the bits event, which is also just an integration event which allows companies to integrate their product with Balsa just as a learning by doing approach. And then we've done a code challenge. The code challenge actually started with five college students or actually university students. Four were undergraduate and one was a graduate student. They developed the first kind of the initial code for Balsa. And they did that working with Joel Sherrill, who's been one of our primary developers of Balsa, and then also John Stow, who was a previous chair or co-chair of the integration workshop standing committee. If you would like to get involved in the face consortium and interested in the integration workshop, we would love to have you. So I just wanted to touch on a few things, and then I'm going to jump in. I'll provide just a little bit of overview on the kind of the table of contents and then the lead-in to what Chris is going to talk about. So just bear with me and let me share my screen. Looking at the table of contents, notice the software supplier getting started guide is relatively short. And I use that in terms of some of the other face consortium documents. The idea behind it was to reference something. If we can pull it down, show you a little bit of how to work it. That's what we want to do, and then kind of get you on to something else or have it reference additional documentation. So each one of these sections, notice there are about five pages or less. It starts out with just a background and scope, highlighting some of the primary documents to the face consortium, some of the publications that would benefit you as a software supplier. Setting up the environment, 2.2, 2.3, 2.4, those deal primarily with Balsa, and then there are additional appendices that go into more examples. So let's skip down to the background and scope. Software supplier getting started guide is designed to be a navigational quick start guide for software suppliers. The software supplier getting started guide is not an introduction to the overall face approach. There are other documents that we recommend that if you're looking for an introduction to the face approach, this is primarily for software suppliers, meaning anyone who's interested in finding out more information about our programming to the face approach or the face technical standard. I mentioned Balsa. Balsa is the basic avionics lightweight source archetype. It's an application being used as just an on-ramp example. The whole philosophy behind this was learning by doing, using a hands-on approach allows you to learn better. There are four primary goals to provide start-up guidance, direction to basic primary documents. I saw Lauren earlier reference the face landing page, and then she also showed the documents and tool page. All of these documents are available on that documents and tool link. They're available to download and free to you. It introduces you to an example face application. It provides the user to software to increase your knowledge. Again, I mentioned learning by doing, and then it allows you to gain understanding of the basic verification process. Hopefully, if you're developing software, you want to take it through the VA and the CA. Primary documents. As I mentioned, Lauren referenced the main web page. Under that, you can do documents and tools. We recommend that you use the most current additions available unless you are contractually required to do otherwise. I mentioned that you are able to download these. However, you will need to sign up with basic information and name and a valid email address. The face technical standard is basically our keystone document. With each technical standard, we have a corresponding rig, shared data model, data model and governance plan, conformance matrix verification, and conformance test suite. Just a quick information. The rig or the reference implementation guide supports the technical standard. It presents best practices. It also provides implementation scenarios. In other words, it provides you more of a guide on how to do some things with a lot more information. Conformance publication documents. It's very important that we have the business aspect, the technical aspect. We also want to make sure that software is conformant with a face technical standard. You do that by testing through the conformance test suite. Then there's basic information there as well. With that, I want to point out that it's very important if you're running the conformance test suite, you want to run it from the very beginning on. Then you also want to make sure that the conformance test suite aligns with the same face technical standard that you're working with. Third party website or third party tools are available on the face website as well. Those are just vendor provided products that are available. They have not been through or vetted through the open group for the face consortium. I just wanted to point that out. If you were on the website or if you were on the WebEx yesterday, we also looked a lot more in-depth at this PRCR process. We looked at a little bit at data modeling, but Steven Simi from TS Savvy actually pulled up a conformance test suite around the data model through there to show that it did conform. Any additional questions before I turn it over to Chris to talk a little bit more about Chapter 2 and Balsa? Then if not, Chris, I will pass the ball to you. Thank you. Thank you, Alicia. You ready here? So good afternoon, everyone. Today I'll be going through the Balsa overview, which is summarized in the chapter that Alicia left off on in the software supplier getting started guide. This overview is just a more in-depth dive than the chapter in the software supplier getting started guide. So I'll just, without further ado, we'll go ahead and jump in. So Balsa is something that if you've been around the face consortium for a day or so you've probably heard of. It's an acronym that stands for Basic Avionics Lightweight Source Archetype. It serves as a working example of a implemented face architecture, which includes backend implementations of a transport service segment, an input outputs service segment, and a partially implemented OSS. It also includes a PCS and four PEE-TRIPLE-S applications that run within it. And by right now what is known as Balsa, the name includes the reference implementation and those five applications. So it includes examples of an iOSS, TSS, one PCS, four PEE-TRIPLE-S UOCs, which all are aligned to the safety base OS profile, with the exception of the TSS. Those are currently aligned to safety extended. There is an HMFM API that is located in the OSS segment. And there's also a early adaptation of the 3.0-aligned configuration API, which since it's everything in Balsa right now is aligned to 2.1, it's just treated as a custom API. But it was a way for us to kind of get started and see and kind of realize what one aspect of what was soon to be 3.0. For the operating system segment, we assume the POSIX API. And for our applications that actually run in the reference architecture, we base it off of ADS-B as a real-world open example of a small avionics process that would effectively demonstrate all face segments. The goals of Balsa, the primary one, is just to kind of get people involved in face and kind of serve as something that technical people could put their hands on and really see how the face technical standard can be realized. It's not an end-all be-all of a face reference architecture. It is merely an example of what you could do. And for a lot of people, myself included, it's when you really start connecting the dots, you actually put your hands on a piece of code and see a realization of a TSS and IOSS and say, oh, I see what they did there. Okay. And then see how the APIs are an example of how the APIs are meant to be realized. One of the secondary goals is to provide a trading pattern and a code base that we can use for advancing the technical standard. The 2.1-aligned Balsa served as a area of back for the technical standard. We followed a great number of CRs to the technical standard by basically just going through Balsa, creating it, and adding capabilities to it. A secondary goal is also just to provide vendors an example that they can use to integrate their own components that basically say you have a vendor that is going to create a PCS and they need a TSS to test with it. This is a great way for them to have a baseline that they can use that way they don't have to go out on their own. And Balsa is a really good tool for that. I know there are a few companies that are using pieces of Balsa in that aspect already. So it's just a baseline out there for people to use. Target audience, primarily face application developers, but also consortium members and working groups evaluating potential changes is a good way for, like, say, the Transport Service segment subcommittee can advance it and use it to test out possible changes in future versions of the technical standard just as an example. Those evaluating, integrating face in other standard environments and for vendors to use as a baseline architecture for demonstrations. A lot of vendors use Balsa as their architecture when they demonstrate things at the technical interchange meetings and things of that nature. So what Balsa does, once again, is a simple version of a basic ambionics process. It has one PCS that combines logical inputs from two PCS components. I'm sorry, PSS components, sorry. To provide information to a third PSS component, which writes ADSB output using an ADSB encoding library. The two inputs the PCS gets from the two PSSs are position and altitude from one and from the other call sign and aircraft ID. And the system output is, that actually goes out of the PSS layer and into the iOSS and out to wherever it's going is two messages that are encoded using the ADSB library and they are position and call sign. I won't read through all of this, but this is the actual data flow complete with the connection names that the TSS uses. The TSS currently has three connections. One is EGI data, that is your position and altitude data that comes in. Your air config data or AIR CFG, which we call it for short data. That's your call sign and aircraft ID that comes up through the TSS to the PCS component. And then the combined message that the ATC manager PCS component creates based off of all that data is the ATC data connection, which goes back into the TSS and down back to the P3S where it is encoded using the ADSB library and then sent out over in iOS. Here is the face boundary diagram for Balsa. At the top in the segment you have your ATC manager. In your platform specific service segment you have your forward P3S components, your EGI controller, your aircraft config, your ADSB out and an ADSB in. That ADSB in basically just reads in the data that goes out over ADSB out and listens for other traffic out as well. In your iOS services segment you have your UDP reader and writer, which uses just an internet device driver at the OSS. You have an EGI input output adapter, which the default one uses just basic file IO device drivers. In your operating service segment you have your health monitoring fault management. And if this was 3.0 we would have our configuration services down there, but since it's not actually part of the OSS profile for 2.1, it's not on this diagram because it's considered a custom API. Over on the far right on your transport service segment we utilize the type abstraction API and that's where we store all of our capabilities in the TSS with the config UOC. And in the type abstraction we have transport, distribution, configuration, and marshaling capabilities all within that UOC. Here's just an example of the data flow in Balsa just as default, which currently the EGI controller reads its information from a comma separated value file, which has an IO adapter that reads directly from that. Aircraft config gets its call sign and tail number from just a hard coded file, which it reads in via configuration services. Both of those inputs go out to the TSS. ATC manager receives those from the TSS, creates its new message, sends that back out to the TSS, ADSB out, receives that message, encodes the ADSB call sign and position message, and sends those out using the UDP writer instance. Ethernet device driver sends it out, UDP reader at the iOSS receives in that data, and the ADSB in listens for any ADSB messages that are received. Okay, Balsa EGI details. Now what this basically means is the way we designed the EGI, and this is just another example of separation of concerns in face, we tried to leave the EGI controller and the P-TRIPLE-S as agnostic as it can be as far as how it gets its data. So basically it has no clue where it's getting its data, it just knows it's supposed to receive a position message, and that's it. So we abstracted the actual method for how it gets its data into an IO adapter. And right now we have as default just an IO adapter that reads from a comma separated value file. There was one that was developed in cohesion with AMRDEC that allows you to use a GPS device driver. And really all you need to do is if you bring in your own device driver, I'm sorry not device driver, IO adapter for the EGI to use, all you need to do is just recompile with that particular IO adapter, and it's ready to go. You don't actually have to touch the EGI whatsoever. There's also as an optional IO adapter, there's one that allows you to receive a position message from a disk stream. So that's in the source distribution as well. Current Balsa status is currently designed using shared data model version 2.1.34, which has been through PAO approval, and it's aligned to TechStandard 2.1.1. The UOP supplied model does pass the conformance test suite. There are artifacts available for the ATC manager PCS component. Those are complete. We sent them to the VA and we're having to make some modifications and we're currently awaiting some of those back. And that's about it for that. All 2.1 UOCs currently pass the conformance test suite. Here's pretty much the details on all of that, the HMFM. We have never tested because it's an OSS provided API, and the configuration services is a capability that's going to be realized in version 3.0 of the TechStandard, so there's not a method to test for it as of right now. And once again, it's considered an OSS provider. But as you can see, all except the TSS are aligned to safety base. With the exception of the type specific, it passes this type abstraction and the TSS combined UOC are aligned to and pass the safety extended OS profile. Here's just another expanded view of the conformance status for each UOC, whether or not they pass, and artifacts, and just notes on what the status is as of right now. One of the big ones is the TSS type abstraction. It'll pass TS 2.1, but it would notionally fail a 2.1.1 test. Just some expanded views on some of the components before I actually run the program itself. At the PEE-TRIPLE-S layer, you have the aircraft config. As stated before, reads intel number and aircraft ID via configuration services, sends data in the form of aircraft config message to the TSS. And there's an example window of the console window that it creates once you instantiate the software and just a diagram view of the components that it uses. Over at the EGI, PEE-TRIPLE-S component reads in position and time, which the time is realized as duration in seconds, and it reads those in via the iOSS, sends data in the form of an EGI data message to the TSS, and it currently uses an IO adapter which reads data from the CSV file. There's an example console window of it processing its inputs. There's an expanded view of it, of the APIs that it touches. ATC manager, PCS component, receives the aircraft config and EGI data messages from the TSS, combines the input messages into ATC data message, sends them to the TSS. And once again, there's the console window and expanded view of the APIs it touches. ADSB out, PEE-TRIPLE-S, that's the one that receives the ATC data message from the TSS and encodes data received, an ADSB call sign and position message using the ADSB library, and it sends ADSB messages to the iOSS, which in turn sends those out in its manner. ADSBN receives incoming ADSB message from the iOSS. It decodes the message using the ADSB library and updates known aircraft with new position and call sign. And here's just an expanded view of how the Balsa TSS is designed. It currently uses three UOCs. It's got a type specific, a type abstract, and then a combined library for every configured connection. It creates an instance of both a protocol and a transport that are managed by a connection class instance. And currently it's capable of using UDP multicast, TCP multicast, or a face multiplex connection, which relies on UDP protocol. Here's an expanded view of the iOSS design for Balsa. It's built into a single UOC that uses UDP multicast to read and write, and additional IO transports can be added with minimal impact to existing UOC, and the EGI uses an application-specific layer, meaning that the EGI IO adapter is compiled separately. That's considered a Balsa specific and not a part of the reference architecture, if that makes sense. And also, the way that we designed the iOSS and the TSS, we designed it to where it can be easily added onto. So you can add on your own connection types, like for instance, let me back up to Transport Service. You can add your own transport or protocol classes without actually having to touch anything else. And the same goes for the iOSS. You can add your own capabilities without impacting the rest of it. Here's just a breakout view of the file structure for Balsa. Pretty much anything that's Balsa specific. And what I mean by that is PCS, P3S components, your data structures, for the EGI, its IO adapter, pretty much anything that's specific to applications that will function in the reference architecture are located in the Balsa subdirectory. That way they're completely separate from all the reference architecture back-end services. Those are in a FACE subdirectory, which you can see has configuration HMFM, iOSS, TSS, and then there's a Helpers API, which helps the applications use certain services. And then there's the ADSB encoding and decoding library. This list is separate. So basically the three of these are three separate entities. You have your Balsa applications and application-specific code. You have your reference architecture directories and you have your ADSB library. Compiling and running Balsa. Balsa was designed to basically run on a Unix-like environment. Currently, it will operate on Red Hat, CentOS, 6N7, Raspbian, and Ubuntu. It's built, compiled using a simple make file. Just do a simple make, make clean to clean your build, and there's a launch script that launches everything. So it's meant to operate on open source operating systems, was not designed with anything proprietary in mind. However, from what we've heard, there's been some success with running it on different operating systems. And that's it. Let me demonstrate it actually working. Here is your ATC manager receiving its two inputs. Here's your aircraft ID, which once again reads in its information via configuration services. There's nothing for it to scroll through because it just reads it in once. There's your ADSB out, your ADSB in, and your EGI that is sending to your ATC manager. One main feature that usually people notice is if you notice the altitude for ADSB in and out, they are seemingly rounded. That is just a limitation of the ADSB library and the ADSB standard. It's specific to, I think, 25 feet, which is why it looks rounded to every 25 feet. But that's it. Just to stop it, just return, and that's it. Great. Thanks, Chris. For those of you who are attending this, if you have any questions, we have a Q&A feature where you can chat a question if you have any for Chris or Alicia in the box. And we'll give you a few minutes to see if anybody has any questions. What information is available related to Balsa if I'm someone new trying to get everything up and going? What do I have access to to help me get Balsa up and running? Well, there is a very detailed readme file that goes through setting up Balsa, running it, and also setting up a conformance test suite build to test Balsa with and how to compile for conformance versus compiling for operation. There's also a Balsa guide that is available to the consortium, and it's on the BITS Play Doh website, and it's got, it has detailed all the way down to the individual files in Balsa, and the reference architecture builds all the way down to what each file does. So it's detailed on how it's not only designed but built and how it runs. Okay, I see a couple of questions coming in. Mark wants to know, does the Balsa example require Corba tools to build? No. No, it does not. And Phil wants to know when and where can we get these updated slides? I can post these to the BITS website. This is just my, the slides I showed was just my personal copy, but there should be an updated slide deck on the BITS Play Doh website. If not, I can just post the ones that I did for this webinar to there. And just to follow up as well, everybody who did attend this session will get an email link to this recording. So you can go back that way as well, but they can be posted to the base consortium Play Doh site. And Chris, other people are creating questions. I noticed on the call yesterday there was some questions about Balsa migrating to Text Standard 3.0. I know that it's currently aligned with Text Standard 2.1. Can you kind of talk about the plans to align Balsa with 3.0? Good question. As of right now, we are doing a very minimal 3.0 implementation using, we've taken the HMFM and done a 3.0 realignment of that. We're working on configuration service right now. And all this is basically to reinforce testing out 3.0 and the new IDL bindings. Currently, we've built the new support classes aligned to the 3.0 Text Standard and checked those out. In the future, we'll add a minimum grade over the TSS, leave the IOSS, and create a new PCS and P3S instance design. And we'll see when and how long that will take to implement. At this time, I do not know. Great. So we haven't had any additional questions come in at this point. So if you do have questions after the fact, the webinar ends, you can send them over to ogface-admin at opengroup.org. And we'll definitely go ahead and get those questions answered for you. And with that, I'd like to thank Alicia and Chris for taking the time to present. Thank you, everybody, for joining. Thank you, Simon, for running this for us. And everybody keep an eye on your email and you'll have a copy of the recording later on today. Thanks, everyone.